PMDF System Manager's Guide

In addition to message transport problems, there are three other common issues which can lead to messages sitting around unprocessed---or temporarily unprocessed---in the message queues:

1. The message has a low priority. By default, PMDF pays attention to Priority: headers in scheduling message delivery jobs: only messages of normal or urgent Priority: get an immediate delivery attempt, while messages of non-urgent Priority: wait until the next run of the PMDF periodic delivery job.
2. The queue cache database is not synchronized with the messages in the queue directories.
   Message files in the PMDF queue subdirectories which are awaiting delivery are entered into the queue cache database. When channel programs run in order to deliver messages in their queues, they consult the queue cache to determine what messages to process. There are circumstances which can lead to message files in the queue that do not have a corresponding queue cache entry: for example, if the queue cache database has incorrect ownership and protection; see Section 34.2.3. Channel programs will ignore queued messages which do not have a cache entry. On OpenVMS, you can use the DUMP/RECORD command on the queue cache database to check if a particular file is in the queue cache; if it is not, then the queue cache needs to be synchronized.
   The queue cache is normally resynchronized daily. If required, you can manually resynchronize the cache using the OpenVMS command

   $ PMDF CACHE/SYNCHRONIZE

   Once resynchronized, upon the next running of the PMDF periodic delivery job the channel programs should process all messages in their queue.
   On OpenVMS, if you are having trouble with the queue cache which is not remedied by a resynchronization, there is an additional command you should use to try to mollify the database:

   $ @PMDF_COM:convert_cache.com

   There is a more drastic step, rebuilding the queue cache database, which should only be performed as a last resort, e.g., if disk problems have corrupted your queue cache database, as it will cause loss of some information from the queue cache database. (The sort of information lost includes, but is not limited to, message creation dates, message deferral dates, message expiration dates, and the original message owner information used by the PMDF QM/USER utility to allow users to bounce their own messages.) You can want to consult Process Software before taking this step. To rebuild the queue cache database, use the OpenVMS commands

   $ PMDF CACHE/REBUILD $ PMDF CACHE/CLOSE $ PMDF CACHE/SYNCHRONIZE

   
   

3. Channel processing programs fail to run because they cannot create their execution log file (e.g., batch log file).
   Check the access permissions, disk space and quotas, and that there are no version limits set on the PMDF log directory and that none of the files therein have reached a version number of 32,767.

34.4.6.1 Checking Version Limits and Numbers

PMDF will detect that log file version numbers are getting high and try to shuffle them back down to a safe level. If it is unable to do so, then warning messages will be sent to the postmaster. Certain situations, however, can prevent the warning from getting through. In any case, if you have detected a situation where log file version numbers are getting too high and PMDF has not fixed them for you, you should delete all versions of the log files in question. After that, new logs with the same name will start over from version 1.

Additional version limit problems will occur if version limits are set on the PMDF log directory. Consider the following scenario: A message is enqueued and a delivery job is started, but delivery processing takes an unusually long time due to network congestion. As this first job runs other messages are enqueued and dequeued from the channel, their delivery jobs producing additional log files. Now, if a version limit is ever reached, subsequent jobs will not be able to run because the log file associated with the first job is still open and cannot be purged. The resulting failures in turn lead to significant delivery delays.

The inevitable outcome here is that file version limits cannot be used as a means to control the number of PMDF log files that are created. For this reason, PMDF incorporates facilities to automatically purge accumulated log files back to the limit set by the PMDF_VERSION_LIMIT logical. (The default is 5 if this logical is not set.) Version limits are therefore unnecessary and must not be imposed on the PMDF log directory.