PMDF Installation Guide
OpenVMS Edition

The following is a list of additional post-installation tasks that must be completed following an upgrade from V5.0 or earlier of PMDF, PMDF-MTA, or PMDF-LAN. Sites upgrading from PMDF V5.1 or later should skip this section.

1. The PMDF multithreaded Service Dispatcher now handles various services formerly handled by separate resident processes. If you are upgrading from PMDF V5.0 or an earlier version of PMDF and were previously using the multithreaded SMTP server (i.e., TCP_* channels), or PMDF POP3 or IMAP servers, you must now configure the PMDF Service Dispatcher to handle these services. (You should have previously shut down the old servers as directed in Section 1.5.1.) The PMDF CONFIGURE DISPATCHER utility generates a basic PMDF Service Dispatcher configuration. See Chapter 5 and Chapter 6 for a description and sample configuration of the PMDF Service Dispatcher. If you are also using PMDF POP3 or IMAP servers, you should also run the PMDF CONFIGURE MAILBOX_SERVERS utility and then include the configuration file it generates into the basic PMDF Service Dispatcher configuration file. Note also that POP3 and IMAP server options are defined as of PMDF V5.1 via server option files (and in some case via options in the PMDF Service Dispatcher configuration file) rather than with logical names as in PMDF V5.0 and earlier. If you were previously using logical names to set certain options you should now instead set the corresponding options in the appropriate option file; see the PMDF System Manager's Guide for details. You should add the command:

   $ PMDF STARTUP DISPATCHER

   to your system startup procedure so that the Dispatcher will be started up automatically upon future system reboots.
   

   Note The commands PMDF STARTUP SMTP, PMDF STARTUP POP3, and PMDF STARTUP IMAP are all obsolete as of PMDF V5.1, having been subsumed by the PMDF STARTUP DISPATCHER command. If you have any such commands in your system startup, replace them with a single PMDF STARTUP DISPATCHER command.

   
   
2. PMDF-MTA includes a facility called DELIVER, which is an adjunct to VMS MAIL that makes it possible for incoming mail messages to be handled and processed automatically based on information provided in a user supplied file. DELIVER is now an integral part of PMDF and is not installed separately. If you are upgrading from a version of PMDF prior to PMDF V5.0-6, you might have been using an older, standalone version of DELIVER, and might have commands to set up DELIVER in your system startup command file. These commands should be removed. You should change references to DELIVER% to IN% format. See the PMDF System Manager's Guide and the PMDF User's Guide for details on the integrated DELIVER component of PMDF.
   
3. To better support multiple architectures, PMDF's directory structure has been changed as of the V4.2 release. Most importantly, the former PMDF_ROOT:[exe] directory has been split into several directories, each referenced by a logical name. Upgrading sites that use SMTP servers, DECnet objects, UUCP, or any of the command procedures to start detached PMDF processes are impacted by these changes. Also, any site developed procedures which reference executables or command procedures in PMDF_ROOT:[exe] must be modified to use either PMDF_EXE: or PMDF_COM: to access, respectively, executables or command procedures which formerly resided in PMDF_ROOT:[exe]. The command procedure PMDF_COM:find_pmdf_root.com can be executed to help you locate any references to PMDF_ROOT:[exe]. This procedure checks many of the places where PMDF_ROOT:[exe] is likely to be used. However, it is not omniscient and can miss noticing some occurrences. Likely usages to check include:

   DECnet objects (PhoneNet or SMTP over DECnet channels)

   The definitions for PhoneNet and SMTP DECnet objects need to be modified. For PhoneNet over DECnet channels, use the commands:

   $ RUN SYS$SYSTEM:NCP NCP> DEFINE OBJECT PMDF - FILE PMDF_COM:dn_slave.com ... NCP> SET OBJECT PMDF - FILE PMDF_COM:dn_slave.com ...

   For SMTP over DECnet channels, use the commands:

   $ RUN SYS$SYSTEM:NCP NCP> DEFINE OBJECT PMDFSMTP - FILE PMDF_COM:dsmtp_slave.com ... NCP> SET OBJECT PMDFSMTP - FILE PMDF_COM:dsmtp_slave.com ...

   Consult the appropriate Installing PMDF As a Known Object subsection in the DECnet Channels chapter of the PMDF System Manager's Guide.

   UUCP

   Consult the section "Setting up the slave program" in the UUCP Channels chapter of the PMDF System Manager's Guide. You will most likely have to change the rmail definition in UUCP_BIN:uuxqt_dcl.com to

   rmail = "$PMDF_EXE:uucp_slave.exe"

   after which you need to restart your UUXQT job so that it will see this change.

   Command procedures

   Command procedures such as start_ucx_smtpd.com and start_fax_receive.com should now be referenced via the PMDF_COM: logical. Update your system startup procedures accordingly.

   Shareable image hooks

   Logical name definitions for shareable image hooks (e.g., PMDF_FAX_VALIDATE and PMDF_FAX_LOG_USAGE) may need to be changed depending upon where you used to keep the actual shareable images. For instance, if you previously kept them in PMDF_ROOT:[exe], then the logicals need to be changed to now use PMDF_EXE: instead of PMDF_ROOT:[exe].

   
   
4. If you are upgrading from PMDF 4.1 or earlier and were using the queue to e-mail symbiont, then note that as of PMDF V4.2 the name of the symbiont image has been changed to pmdf_q2email.exe so that it can be clearly identified in the SYSEXE directory. You will need to modify the /PROCESSOR qualifier specifications in your startup procedure which initializes any queue to e-mail queues.
   
5. If you are upgrading from version 3.1 or earlier of PMDF, you must use the command procedure PMDF_COM:convert_queue.com to convert old queue entries produced by versions of PMDF prior to 3.2 to the current subdirectory format. (This new format was introduced with version 3.2 of PMDF.)