PMDF Installation Guide
OpenVMS Edition
PMDF-INST-VMS-6.0

The following is a list of tasks which must be completed following an upgrade installation of PMDF, PMDF-MTA, PMDF-ACCESS, PMDF-DIRSYNC, PMDF-FAX, PMDF-LAN, PMDF-MB400, PMDF-MR, PMDF-MSGSTORE, PMDF-POPSTORE, PMDF-X400, and PMDF-XGS.

• If PMDF was installed on a running cluster, the image SYS$LIBRARY:dcltables.exe must be reinstalled manually across the cluster using the command:

  $ INSTALL REPLACE SYS$LIBRARY:dcltables.exe
  

  In addition, if you are installing or upgrading PMDF in a mixed architecture cluster, then you must issue, prior to the above INSTALL command, the command

  $ SET COMMAND/TABLE=SYS$COMMON:[syslib]dcltables.exe -
      /OUTPUT=SYS$COMMON:[syslib]dcltables.exe PMDF_COM:pmdf.cld
  

  Issue this command on a cluster member of architecture type different from that of the system on which you installed PMDF. That is, if you installed PMDF on an Alpha member of the cluster, then issue the above SET command on a VAX cluster member. If instead you installed PMDF on a VAX cluster member, then issue that command on an Alpha cluster member.
  
• If you are installing PMDF on multiple systems in a mixed architecture cluster, or in a cluster with system with multiple system disks, you should execute the PMDF_COM:post_install.com procedure on a system of the "other" architecture, or on each system having a distinct system disk.
  
• The installation procedure replaces the old version of the file pmdf_startup.com in the SYS$STARTUP directory with a new version. (This is the procedure normally executed during system startup to define PMDF logicals and install PMDF images.) If PMDF is running in a cluster, you should execute pmdf_startup.com on any other cluster members sharing this PMDF configuration to ensure that all such systems have current logical name definitions.

  ---

  Note:

  The PMDF installation has no way to merge local changes made in an old pmdf_startup.com into the new version of this file. As such, the installation procedure preserves any existing pmdf_startup.com file as pmdf_startup.old so that changes can be retrofitted manually. It is far preferable, however, for sites to refrain from adding private commands, logical definitions, etc., to the pmdf_startup.com command procedure.

  ---

  Rather than customizing pmdf_startup.com itself, which will be replaced when you upgrade PMDF, you may create a PMDF_COM:pmdf_site_startup.com procedure and put your site specific PMDF definitions in that file. When pmdf_startup.com executes, it checks for the existence of such a site-supplied pmdf_site_startup.com procedure and executes it, if it exists.
  
• If you use a compiled PMDF configuration, you must recompile and reinstall your PMDF configuration; e.g.:

  $ PMDF CNBUILD
  $ INSTALL REPLACE PMDF_CONFIG_DATA
  

  You cannot copy over an old compiled configuration for use with PMDF V6.0; the compiled configuration format always changes with each new release of PMDF. You will also need to reinstall the configuration image on any other cluster members running PMDF. If you use PMDF in a mixed architecture cluster, then you will need to recompile your configuration on a cluster member of each architecture type, so that both forms of the compiled configuration will be available for reinstallation.
  
• The format of the PMDF queue cache database has changed (storage efficiency has been improved) between PMDF V5.2 and PMDF V6.0. If you are upgrading from PMDF V5.2 or earlier, you must rebuild your queue cache database with the command:

  $ PMDF CACHE/REBUILD
  

  Note that it is also a good idea to rebuild the PMDF queue cache database after even minor dash upgrades.
  
• The pmdf_submit_jobs.com command file created during the installation is used to resubmit PMDF service jobs after a system queue failure or initialization, or after the jobs have been deleted, as during the pre-installation steps. You must resubmit the PMDF periodic jobs now by issuing the command

  $ @SYS$STARTUP:pmdf_submit_jobs.com
  

  (Your system startup procedure should issue this command as well, so that the jobs will be submitted after a system reboot.)

  ---

  Note:

  The PMDF installation has no way to merge local changes made in an old version of pmdf_submit_jobs.com into the new version of this file. Therefore the installation procedure preserves any existing pmdf_submit_jobs.com file as pmdf_submit_jobs.old so that changes can be retrofitted manually. It is far preferable, however, for sites to refrain from adding private commands, logical definitions, etc., to the pmdf_submit_jobs.com command procedure; instead, add them to the procedure which invokes pmdf_submit_jobs.com.

  ---

  
  
• If you have performed an upgrade from a previous version of PMDF you may continue to use your existing configuration files. You might still run the configuration generator and compare the output with your old configuration. You can always redirect the output of the configuration generator utility to avoid overwriting your working configuration. In many cases, the automatically generated configuration will contain new rules and useful techniques you can apply to your own configuration.
  
• If there were messages in your old queue created by an earlier version of PMDF, you can move them into the new PMDF queue at this time.
  
• pmdf_startup.com installs a number of images using the OpenVMS INSTALL utility. These images are listed in the file pmdfimage.dat in the PMDF_COM: directory. The pmdfimage.dat file is reserved for PMDF use and should not be modified. Site-specific images can be installed by using the file siteimage.dat in the PMDF_COM: directory. pmdf_startup.com checks to see if this file exists and installs the images listed in it if it does exist. The siteimage.dat file has the same format as pmdfimage.dat. This format is extremely simple---a file name is specified followed by the appropriate qualifiers for OpenVMS INSTALL. The file name must be separated from the qualifiers by at least one space or tab character. The siteimage.dat file is not provided by the installation process; it must be created manually. If you have installed a new version of PMDF in a different location you should copy over any old siteimage.dat file you have previously built. Once you have built or copied over this file you can either re-run pmdf_startup.com to install the additional images it specifies or use the command:

  $ PMDF INSTALL CREATE
  

  In either case the images specified by pmdfimage.dat will be reinstalled, but this will not hurt anything.
  
• Versions of the DEC Pascal RTL (Run Time Library) earlier than V5.0-15 (VAX) or V5.0-18 (Alpha) were not fully thread-safe; PMDF's multithreaded SMTP server and multithreaded SMTP client were liable to exercise these problems. Digital Equipment Corporation has given Innosoft permission to distribute an updated version of their Pascal RTL. As of PMDF V5.0-6, the PMDF installation procedure will check the version of the Pascal RTL installed on the system on which you install PMDF, and will install an updated Pascal RTL, pasrtl.exe (VAX) or pas$rtl.exe (Alpha), if your system is running OpenVMS 6.1 or later and is using an older version of the RTL. This new version of the Pascal RTL will be included in the next releases of OpenVMS and DEC Pascal for OpenVMS. If you are running a shared PMDF configuration on a cluster, then note that the PMDF installation will only update the Pascal RTL on the node on which you perform the installation; you must separately update the Pascal RTL on any other system disks. (Sites running PMDF on a mixed architecture cluster or on a cluster with multiple system disks should note that post_install.com does not update the Pascal RTL; you must still update the Pascal RTL separately.) See Appendix A for details.
  
• If you also installed PMDF-DIRSYNC, PMDF-FAX, PMDF-LAN, PMDF-MB400, PMDF-MR, PMDF-X400, or PMDF-XGS for the first time, or are using PMDF-MSGSTORE or PMDF-POPSTORE for the first time, then you should configure them now. Configuration instructions for PMDF-MSGSTORE and PMDF-POPSTORE may be found in Chapters 11 and 12 . Configuration instructions for PMDF-FAX may be found in Chapters 15 and 16 ; configuration instructions for PMDF-LAN may be found in Chapters 13 and 14 ; configuration instructions for PMDF-MB400 may be found in Chapters 17 and 18 ; configuration instructions for PMDF-MR may be found in Chapters 19 and 20 ; configuration instructions for PMDF-X400 may be found in Chapters 21 and 22 ; configuration instructions for PMDF-XGS may be found in Chapters 23 through 26 .
  
• If you are upgrading PMDF-MR, then you are encouraged to re-run the PMDF CONFIGURE MR utility so as to generate new FROM_MR and TO_MR mapping rules. More versatile mappings are now generated by this utility.
  
• If you were using the PMDF popstore in PMDF V5.1, note that to accelerate certain management functions (e.g., generating listings of user accounts, using wild cards in conjunction with account management commands), a database of user accounts was added as of PMDF V5.2. This database, referred to as the popstore user database, is located in the PMDF_POPSTORE_PROFILES:[000000] directory. This database is only used for management functions and does not in any way impact the performance of the popstore. Sites which were using the popstore under PMDF V5.1 should issue the command

  $ PMDF POPSTORE X-BUILD-USER-DB
  

  after upgrading to PMDF V6.0. This command will scan the profile directory tree and build a user database. Sites upgrading from V5.1 of the popstore should note that the popstore will continue to function without this command being issued. At issue is that some management operations will not function until this command is executed.
  
• Update configuration:
  • a. As Web500 is no longer provided, you should remove any WEB500 service definition from your dispatcher.cnf file and any WEB500 path definition from your http.cnf file.
  • b. Sites with existing popstore users who wish to use the PMDF MessageStore should issue the command

    $ PMDF POPSTORE UPGRADE 
    

    to cause their popstore user account names to be properly modified for compatibility with PMDF MessageStore profiles.
  • c. If you are upgrading from PMDF V5.1 and are using PMDF-X400 or PMDF-MB400 and were using the former MIME-CONTENT-TYPES-TO-X400 mapping table to control the mapping of MIME attachments to X.400 attachments, then note that that mapping table became obsolete as of PMDF V5.2, having been superseded by the new MIME-TO-X400-CONTENT-TYPES mapping table which is a bit more general. You must convert the name of the mapping table to the new name, and also include the new channel name argument on the left hand (pattern) side; the file PMDF_TABLE:x400_mappings.sample may provide a useful sample starting point.
  • d. If you are upgrading from PMDF V5.1 and using the POP or IMAP server, be aware that some password handling changed as of PMDF V5.2:
    • As of PMDF V5.2, the POP and IMAP servers now check whether a user's password has expired, and will not allow authentication with an expired password. Check that your users do not have expired passwords.
    • The new, configurable authentication source control used as of PMDF V5.2 by, for instance, the POP and IMAP servers has default behavior that is intended to operate "naturally" and usually means no visible change to users. But a few users with less natural setups (for instance, non-popstore users who have PMDF password database entries different from their system password) can see a change in behavior. The current (PMDF V5.2 and later) behavior is preferable for most sites. But if you need to achieve the PMDF V5.1 behavior in PMDF V6.0, you would need to configure the following. Use a PORT_ACCESS to segregate POP and IMAP connections into different rulesets, e.g.,

      PORT_ACCESS 
       
       TCP|*|110|*|*        $YPOP-RULES 
       TCP|*|143|*|*        $YIMAP-RULES 
       
      

      Then you would need corresponding security configuration ruleset definitions of:

      [RULESET=DEFAULT] 
      ENABLE=MSGSTORE/*,PASSDB/*,SYSTEM/* 
      ! 
      [RULESET=POP-RULES] 
      ENABLE=MSGSTORE/*,PASSDB/CRAM-MD5,PASSDB/APOP,SYSTEM/* 
      ! 
      [RULESET=IMAP-RULES] 
      ENABLE=SYSTEM/* 
      

  • e. As of PMDF V5.2, the IMAP server supports hierarchical folders. As part of that support, IMAP users can no longer use the slash character, /, in normal folder names. If you are upgrading from PMDF V5.1 or earlier, IMAP users with existing folder names containing the slash character will need to rename those folders using something other than IMAP, e.g., using VMS MAIL or PMDF MAIL, in order to see the folders from IMAP. You may find the FIND_SLASHES program helpful for spotting (and optionally renaming) such folders, as discussed in Section 1.5 .
  • f. If you are upgrading from PMDF V5.1, note that as of PMDF V5.2 the LOG_CONNECTION PMDF option for controlling logging of connection information takes a bit-encoded value for specific controls rather than simply an an on/off setting as in PMDF V5.1, so you may wish to change your setting of this option; see the PMDF System Manager's Guide for a discussion of the current meanings of values for this option.
  • g. If you are upgrading PMDF-MTA and use PMDF's MAILSERV facility you should update your site-specific MAILSERV help and index files to reflect the new version and new capabilities. Sample versions of these files are provided as the files mailserv_help.sample and mailserv_index.sample, respectively, in the PMDF_TABLE: directory. These files should be compared against their site-specific equivalents help.txt and index.txt, both located in the PMDF_MAILSERV_FILES_DIR:[000000] directory, and the site-specific files updated appropriately.
  • h. For sites upgrading from PMDF V5.1 using the PMDF Lotus Notes channel, if you have not already done so you must now switch to using the two independent Server Add-ins PNGATECIN and PNGATECOUT in place of the single PNGATEC Add-in originally released in PMDF V5.1: change the line in the Lotus Notes initialization file, notes.ini, defining server tasks from

    ServerTasks=...,PNGATEC 
    

    to

    ServerTasks=...,PNGATECIN,PNGATECOUT 
    

  • i. The old (obsolete as of PMDF V5.2) single threaded, package-specific PMDF TCP/IP channels, e.g., MTCP, PTCP, UTCP, and WTCP channels, are no longer provided having been superseded by the newer, higher performance, multithreaded TCP/IP channel. If you were using those old channels, you will need to update your configuration to use the multithreaded TCP/IP channel instead; see Section 1.7.2 for a discussion of converting to use of the multithreaded TCP/IP channel.
  
  
• If you are upgrading from PMDF V5.0 or earlier, there are additional steps you will need to perform, described below in Section 1.7.1 .
  
• If you are using the PMDF-LAN Lotus Notes channel, PMDF-DIRSYNC Lotus Notes directory agent, or PMDF-XGS, be sure to upgrade the PMDF images used on the Lotus Notes server or XGS transport bridge system. These are OS/2 or NT PMDF images, available under the PMDF_ROOT:[other] directory on the PMDF system, or available directly off the PMDF distribution CD-ROM under the other directory. Note that this is an ISO 9660 with Rockridge extensions CD-ROM, readable from many different platforms including OS/2 and NT.
  • a. For PMDF-XGS, shutdown all the PMDF-XGS processes on the transport bridge, copy the respective files to the transport bridge system, and restart the processes.
  • b. For a PMDF-LAN Lotus Notes channel, shut down the PMDF Lotus Notes Server Add-ins, using Lotus Notes server console commands such as TELL PNGATECIN QUIT, and TELL PNGATECOUT QUIT (or just TELL PNGATEC QUIT if you were using just the one Server Add-in). Then copy the new server Add-ins to the Lotus Notes server, and start them back up (e.g., LOAD PNGATECIN and LOAD PNGATECOUT).
    
  • Once all the above post-installation tasks have been completed (including those described in Section 1.7.1 and Section 1.7.2 , if appropriate), it is time to start PMDF back up:
    • a. Start up the PMDF Dispatcher with the command

      $ PMDF STARTUP DISPATCHER
      

    • b. Start up the MAIL$BATCH queue and any other PMDF queues.
    • c. If you are using PMDF-MR in MR TS replacement mode (no real Message Router), you should restart your MailWorks server and ALL-IN-1 Sender and ALL-IN-1 Fetcher so that they can reconnect to the new version of PMDF-MR and resume running.

      ---

      Previous | Next | Contents