| Previous | Next | 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 |