| Previous | Contents | Index |
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 |
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).
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 |