MAILTOOL has recently been updated to v8.10 which includes a couple of changes.
Easier Version Updates
With previous versions of MAILTOOL there were many commands you had to run to copy old data to the new MAILTOOL library when performing an update.
This latest version includes the command MAILTOOL Update (MLTUPDATE) which simply asks for the "old" MAILTOOL library where your old files exist and the "new" MAILTOOL library that was just installed.
This command will copy all the necessary data from the old library to the new, as well as any data areas and configuration files. We hope this makes the updating process easier for you!
Configuration File Processing Updates
The latest version also has a few changes regarding Configuration File processing for both the MAILTOOL command and the ILE subprocedures.
With the old MAILTOOL Command it would look for the defaults configuration files every time. This means if you forgot to restore them, the command would error. On the latest version it will only look for the default configuration files if the value of *DFT is specified on the Configuration File (CONFIG) parameter. If a specific configuration file is specified it will look for this file and only this file. In the past if your configuration file couldn't be found it would then look for the default values. This will no longer happen. The MAILTOOL command will, in the case of not finding a specific configuration file, issue an error.
Also with the MAILTOOL Command any non-blank values in the configuration file will override anything on the command. This means if a value is blank or the label simply doesn't exist in the configuration file the value specified on the command will not be overridden.
With the MAILTOOL ILE Functions there is a small coding change needed if you are using configuration files. In the past, the #mailtool_init() subprocedure would load values from the configuration file (or default configuration file). This means you had to use the #mailtool_setValue() subprocedure to set the configuration file before initialization. After some use, we found this to be less intuitive and useful than originally thought.
With this update we've added the #mailtool_loadDefaults() subprocedure available so that you can choose when to load defaults from a configuration file.
Your old code may have looked like this:
rc = #mailtool_setValue('configuration_file': '/bvstools/bvstone_mailtool.json'); if (#mailtool_init() >= 0); rc = #mailtool_addTORecipient('email@example.com'); rc = #mailtool_setValue('subject':Subject); rc = #mailtool_setValue('message':Message); rc = #mailtool_sendMail(errMsg); endif;
With the latest version we will need to set the value for the configuration_file AFTER the #mailtool_init() subprocedure and then call the #mailtool_loadDefaults() subprocedure to load those values. The new updated version would be as follows:
if (#mailtool_init() >= 0); rc = #mailtool_setValue('configuration_file': '/bvstools/bvstone_mailtool.json'); rc = #mailtool_loadDefaults(); rc = #mailtool_addTORecipient('firstname.lastname@example.org'); rc = #mailtool_setValue('subject':Subject); rc = #mailtool_setValue('message':Message); rc = #mailtool_sendMail(errMsg); endif;
We understand this update will require you to make code changes to anything already using the old method, but in the long run I hope you'll find, as we have, that this allows much more flexibility and is much more intuitive. You could even set up multiple partial configuration files and load more than one for different sets of defaults. So, we feel this update adds a lot of value and options to the email processing procedures.
Also, remember that unless you change the ignore_blanks value (which defaults to *YES) any blank value or non-existing value in the configuration file will not override any already value that has been set by the #mailtool_setValue() subprocedure.
As always, feel free to contact us at BVSTools for any questions or clarifications.