PMDF System Manager's Guide


Previous Contents Index

1.4.3 The Periodic Message Delivery Retry Job

A periodic job is one which reschedules itself for execution each time it runs. This section will discuss the first of PMDF's two main periodic jobs, the periodic delivery job. This job's primary purpose is to reattempt delivery of messages not yet delivered. (Note that in normal PMDF configurations, normal messages get an immediate delivery attempt by an immediate job, as described above in Section 1.4.1. Thus the periodic delivery job is primarily a delivery retry job---it is not the main mechanism for initial message delivery attempts.) The periodic delivery job is embodied on OpenVMS by the command procedure PMDF_COM:post.com, which runs every four hours by default (this value can be changed easily by setting the PMDF_POST_INTERVAL logical), or is embodied on UNIX by the shell script /pmdf/bin/post.sh, which the cron daemon is normally scheduled to run every four hours, or is embodied on NT by the program post_job.exe located in the PMDF binary image directory (normally C:\pmdf\bin\) which the at command normally schedules to run every four hours under the Task Scheduler.

The post job, whether embodied by the post.com command procedure or the post.sh shell script or the post_job.exe program, runs the post program which scans through all the channels currently defined in the configuration file. It also checks the corresponding queues for messages. Processing jobs are unconditionally submitted to run the master channel programs for any channels marked with the keyword master so as to poll remote systems that cannot establish their own connections. Jobs are also submitted for channels that support master channel programs and have messages queued. After this is done the post job then terminates. It will run again in another four hours.

The jobs post creates run in the queue appropriate to the channel (specified with the queue channel keyword); this can be a queue other than the one in which post itself runs.

1.4.3.1 Adjusting Periodic Delivery Retry Job Frequency

PMDF's suggested default behavior of running the periodic delivery job once every four hours is appropriate for most sites. Indeed, at busy sites, running the periodic delivery job too frequently tends to be counterproductive. Even if particular channels need to run more frequently, perhaps due to needing to poll to check for new incoming messages (e.g., LAN channels), it is often best to leave the regular PMDF post job running at its usual frequency and to instead set up a special batch job that runs more frequently for the special channels; this is, in fact, the role played by the pc_post job for PMDF-LAN channels.

However, if a site does have a special need to run the periodic job more frequently, consider the following.

First, note that RFC 1123, Requirements for Internet Hosts, requires that Internet mail wait at least 30 minutes before being retried. Do not run your channel to the Internet more frequently than every half hour.

Next, if you must set PMDF_POST_INTERVAL to some small interval (OpenVMS) or have cron running the periodic jobs at some small interval (UNIX), or have the Task Scheduler running the periodic job at some small interval (NT), consider using a


defaults period n 
channel, with n a suitable integer, to set the default channel periodicity back to something more like the usual four hour period, and mark only the channels that need to run more frequently with period 1 so that only they run every time the periodic post job runs.

Finally, PMDF normally performs some periodic clean up tasks when the periodic delivery job runs. PMDF's defaults are tuned for the case where the periodic job only runs every couple of hours. If you will be running the periodic job more frequently, you should adjust PMDF's clean up task frequency, so that clean up tasks are not being executed needlessly often; see Section 1.4.3.2 below.

1.4.3.2 Clean Up Tasks Performed by the Periodic Delivery Job

The periodic delivery job normally performs some clean up tasks when it runs, such as purging back old versions of log files and every so often re-synchronizing the PMDF queue cache database.

By default, old log file versions are purged every time the periodic delivery job runs. The frequency at which this purging is performed can be controlled via the PMDF_VERSION_LIMIT_PERIOD logical (OpenVMS) or PMDF tailor file option (UNIX) or Registry entry (NT). The number of log file versions retained is controlled by the PMDF_VERSION_LIMIT logical (OpenVMS) or PMDF tailor file option (UNIX) or Registry entry (NT) and defaults to 5, if not specified.

By default, the PMDF queue cache database is re-synchronized every couple of times the periodic delivery job runs. The frequency of this re-synchronization can be controlled via the PMDF_SYNCH_CACHE_PERIOD logical (OpenVMS) or PMDF tailor file option (UNIX) or Registry entry (NT).

Note

On OpenVMS, the PMDF_SYNCH_CACHE_PERIOD and PMDF_VERSION_LIMIT_PERIOD logicals should not be used if MAIL$BATCH runs on more than one node in a cluster, as this can lead to unpredictable results.


Previous Next Contents Index