This chapter describes the steps that should be taken prior to installing the Message Exchange software. (Prerequisite Software\INSTALL_GUIDE_8)

MX requires OpenVMS Alpha [version tbd] or later, and/or OpenVMS Industry Standard 64 [version tbd] or later. The SMTP support option requires a NETLIB-supported TCP/IP package (refer to the NETLIB release notes for further information). SMTP-over-DECnet requires DECnet, but does not require either NETLIB or any TCP/IP package. (Upgrading from Previous Versions of MX\install_upgrading_req)

Starting with MX V6.0, upgrades from versions of MX prior to V6.0 are not supported. (VMScluster Support and MX Clusters\mxclus)

MX fully supports VMScluster systems in both homogeneous and heterogeneous configurations.

An (MX cluster) consists of one or more VMScluster nodes that meet the following criteria: (numbered) All nodes in the MX cluster share one User Authorization File (SYSUAF.DAT) and one VMS Mail profile (VMSMAIL_PROFILE.DATA). All nodes have mounted the disk that contains the MX images and directories. All nodes have mounted the disk that contains the message queue. If MX is to be used for network mail, at least one node in the MX cluster is running the networking software required for each type of network link desired. The logical name MAIL$SYSTEM_FLAGS is defined to a value of at least 3. (Refer to (mailutil) for further information on MAIL$SYSTEM_FLAGS.)

For homogeneous VMScluster systems, the MX cluster will usually include all nodes in the VMScluster. (Answering VMScluster-related Installation Questions\INSTALL_GUIDE_51)

The MX installation procedure automatically detects that you are in a VMScluster and will ask additional questions during installation about where in the cluster each installed MX processing agent should run. The processing agents are programs which are run as detached processes. They can be run on any or all nodes in the cluster (following the MX Cluster guidelines outlined above), and will automatically cooperate in providing their respective services.

When asked to provide a cluster node name for running the processing agents, be sure to specify the SCSNODE name (or use an asterisk ((*)) to have an agent run on all nodes in the cluster). (Mixed-Architecture VMSclusters\INSTALL_GUIDE_MIXED_CLUSTER)

Mixed-architecture VMSclusters (those containing a combination of VAX, Alpha, and/or IA64 systems) are fully supported by MX. The MX directory tree can be shared by all three systems if it resides on a common disk. When systems share a common MX directory, agents may be run on any or all types of systems.

When MX is first installed, and the installation procedure determines that the node is part of a cluster, it will record installation information in the MX directory tree. A subsequent installation of the same version of MX in the same directory tree, but on a system of a different architecture, will cause the installation procedure to ask whether or not just architecture-specific files should be installed. MX (must) be installed (multiple times) on a mixed-architecture VMScluster: once for each architecture. Only the first installation needs to include all of the architecture-independent files.

The MX_ROOT: directory tree contains architecture-specific directories for executables: MX_ROOT:[EXE] for VAX executables, MX_ROOT:[ALPHA_EXE] for Alpha executables, and MX_ROOT:[IA64_EXE] for IA64 executables. The logical MX_EXE:, which is used in all examples below, will automatically be defined appropriately on each system in the cluster. (Determining Your Node Name\detnode)

MX requires two node names for its operation. The first, the (MX cluster name), is used by MX to coordinate access to the message queue. (unnumbered) For a stand-alone (non-clustered) system, the MX cluster name usually corresponds to your DECnet node name. If you are not running DECnet, you can use any 1-to-6 character name. For a VMScluster system, the MX cluster name should correspond to your DECnet cluster alias node name. If do not have a cluster alias, you should use the DECnet node name of one of the nodes in the MX cluster.

The second node name is the (MX network node name). This is the name that is used by the MX software to identify mail originating locally. You should decide on a node name for your system before installing the MX software. If your host has a registered Internet domain name, you should use that name. If you are on a UUCP network and do not have a registered Internet domain name, you should use your UUCP host name. Otherwise, you should use a host name that fits with the naming conventions at your site.

In an MX cluster environment, MX will use a single network name to identify the entire cluster. If you have several nodes with their own network node names, and your networking software does not support the use of a cluster-wide alias, you could either pick one node to be the (master) for E-mail purposes or use the MX_VMSMAIL_FROM_FORMAT logical name (described in (mgmtguide)) to have each node insert its own host name in return addresses on outgoing messages. What you do will depend on your network software and setup. (Accessing the Online Release Notes\INSTALL_GUIDE_9)

MX provides online release notes, which you can display or print by using VMSINSTAL with the OPTIONS N parameter. After the installation, you can read the release notes by printing the file SYS$HELP:MXvvn.RELEASE_NOTES, where (vvn) denotes the version number of the software. For example, for version V5.2 of MX, the file name would be MX052.

The release notes for NETLIB are provided in the file SYS$HELP:NETLIBvvn.RELEASE_NOTES, where (vvn) identifies the version of NETLIB shipped with the MX distribution kit. This file is created during NETLIB installation and is not accessible through VMSINSTAL OPTIONS N. (Mailer Accounts\mailacc)

You can run the detached processes MX uses under the SYSTEM account, or, if you prefer, under a separate (mailer) account.

Note, however, that using a mailer account may complicate the process for starting up MX on your system; see (adding) for further information on MX startup procedures.

If you intend to use an account other than SYSTEM for running the MX detached processes, you should create the account before installing MX. The mailer account should have the following attributes: (unnumbered) a username of eight characters or less. full batch access, no interactive access. network access, (only if) SMTP-over-DECnet is used (and) you do not wish to create a dedicated account for the SMTP-over-DECnet object. the INTERNET_ACCESS identifier, if needed for CMU-Tek TCP/IP access. the ARPANET_ACCESS identifier, if needed for CMU-Tek TCP/IP access. the following authorized and default privileges: CMKRNL, SYSNAM, DETACH, WORLD, PHY_IO, SYSPRV, SYSLCK, EXQUOTA, TMPMBX, and NETMBX. (BYPASS may also be required if using DECUS UUCP.) a subprocess limit (PRCLM) of at least 1. no detached process limit (MAXDETACH of 0). a login directory that is owned by the account.

(macct) shows the UAF entry for a typical Mailer account. (SMTP-over-DECnet Dedicated Account\dedacct)

If you intend to use the MX SMTP-over-DECnet support, you may want to establish a special server account to be used exclusively for the DECSMTP DECnet object. If so, you should ensure that the accounts have NETWORK access and the privileges TMPMBX, NETMBX, SYSPRV, and SYSLCK (both authorized and default). (objacct) shows the UAF entry for a typical SMTP-over-DECnet server account. See (install_guide_53a) for more information on setting up the MX SMTP-over-DECnet support.