Compiling the MTA Configuration

Whenever an MTA configuration file such as imta.cnf, mappings, aliases, or option.dat is modified, you must recompile the configuration. This compiles the configuration files into a single image in shared memory (on UNIX) or a dynamic link library (NT).

The compiled configuration has a static and dynamic reloadable part. If the dynamic part is changed, and you run an imsimta reload, a running program will reload the dynamic data. The dynamic parts are mapping tables, aliases, and lookup tables.

The main reason for compiling configuration information is performance. Another feature of using a compiled configuration is that configuration changes can be tested more conveniently since the configuration files themselves are not “live” when a compiled configuration is in use.

Whenever a component of the MTA (such as a channel program) must read the configuration file, it first checks to see if a compiled configuration exists. If it does, the image is attached to the running program. If the image attach operation fails, the MTA falls back on the old method of reading the text files instead.

If you make changes to the reverse, forward, or general databases, then issue the command imsimta reload to get the changes to take effect. If you make changes to the imta.cnf, mappings file, aliases, conversions, or option.dat files that do not affect the job controller, then you should issue an imsimta cnbuildfollowed by an imsimta restart smtp. If you make changes to dispatcher.cnf you need to do an imsimta restart dispatcher. If you make changes to the configuration files that are included in the compiled configuration that affect the job controller, but not the SMTP server, in many cases you should issue the following commands: imsimta cnbuild and imsimta restart job_controller.

If you make changes to the configuration files that are included in the compiled configuration that affect both the SMTP server and the job controller, you should issue the following commands:

imsimta cnbuild
imsimta restart smtp 
imsimta restart job_controller

(See MTA Commands in Sun Java System Messaging Server 6 2005Q4 Administration Reference for details on these commands.)

Other instances where you must restart the job controller:

• Changes to the controller configuration files, job_controller.cnf or job_controller.site, or any files included into job_controller.cnf

• Adding or changing use of the channel keywords pool, maxjobs, master, slave, single, single_sys, or multiple in the imta.cnf file. Adding or changing a threaddepth channel keyword in imta.cnf can be dealt with instead via imsimta cache -change -thread_depth=...

• If you want changes to master channel jobs to take effect immediately (rather than waiting for the controller to time-out existing channel jobs), then any relevant (which means almost all) changes to the MTA configuration or channel option files. (Changes to the mappings file or to MTA databases: (1) aren't usually relevant for outbound channel jobs, though they may matter to “intermediate“ channels such as conversion, process, reprocess, and (2) if those intermediate channels are a concern, changes to the mappings file or to databases can often be handled via imsimta reload avoiding a restart of the Job Controller.) The desire to have changes take effect immediately needs to be balanced against the damage that restarting the Job Controller will do--and also consider just how much longer a particular sort of job is going to run anyhow.

The MTA configuration includes imta.cnf and all files it includes (such as internet.rules), the alias file, the mappings file, the conversions file, the option.dat file (and any files any of the preceding include), and imta.filter, and the reverse, forward, and general data files, and potentially some configutil parameters.

Note that any changes above (such as additions/changes to keywords on channel definitions) to imta.cnf also require an imsimta cnbuild--that's a basic, regardless of whether a Job Controller restart is needed.

Try to avoid restarting the Job Controller, especially at times of large numbers of messages in the queues, unless one of the above conditions necessitates a restart.

We do not recommend use of the imsimta refresh command on production systems because it is often not necessary to restart the job controller and restarting the job controller will reset message retries, delayed notification messages, bounced messages, and so on.