The following sections give an overview of how PMDF may be installed and used in an OpenVMS cluster environment.
1.3.1 OpenVMS cluster installation
If you have a completely homogeneous OpenVMS cluster, that is, a single
authorization file (SYSUAF), rightslist (RIGHTSLIST), mail profile
(VMSMAIL_PROFILE), queue file (JBCSYSQUE or SYS$QUEUE_MANAGER.*), and
network database are shared across the OpenVMS cluster, installing PMDF
is essentially the same as on a single node. All individual host names
are essentially aliases for a single host, and should be rewritten to
the local host name. The automatic configuration generator is capable
of building most of such a configuration automatically.
If you have a more heterogeneous OpenVMS cluster, especially one with multiple authorization files (SYSUAF), the simplest thing to do is install separate copies of PMDF for each homogeneous group of systems. In particular, multiple QUEUE, LOG, and TABLE directory areas will be needed. Other directories may be shared.
There is no great difficulty in installing PMDF in multiple locations. The startup command files will need to be moved to system specific areas once they have been created, but other than that the installation should require no unusual modifications. The command definitions for PMDF all use the PMDF_ROOT logical name to find needed files and as such separate DCLTABLES should not be needed.
1.3.2 Mixed architecture cluster installation
The PMDF installation procedure will automatically install the
executables for the architecture of the system on which the
installation is performed; when installing PMDF for use in a mixed
architecture cluster, be sure to answer YES to the
installation question asking whether the other architecture executables
should be installed also. If you are adding Alpha systems to your VAX
cluster, you would need to install PMDF again on the new architecture
to get the new executables. As long as they still constitute a
homogeneous OpenVMS cluster, they can share the same PMDF configuration
and directory. The only difference as far as PMDF is concerned is the
additional installation of the architecture-specific directories
containing the executables and other files.
This may be performed by running the post_install.com
procedure on a system of the other architecture type, as the
installation procedure will instruct you. The same is true in a
heterogeneous mixed architecture OpenVMS cluster.
1.3.3 Installation of PMDF-ACCESS on additional cluster members
Once PMDF-MTA has been installed and configured on at least one system
at your site, then there are several alternate ways of using any
PMDF-ACCESS licenses you may also have. The options depend on whether
systems are clustered and if so, on whether the cluster is homogeneous;
(a homogeneous cluster is one where the systems share the same
authorization file (SYSUAF), rightslist (RIGHTSLIST), mail profile
(VMSMAIL_PROFILE), queue file (JBCSYSQUE or SYS$QUEUE_MANAGER.*), and
network database).
The simplest case is where you have a completely homogeneous cluster of systems of the same architecture type (VAX or Alpha) with PMDF-MTA installed and configured on at least one of the cluster members, so that via logical names, the PMDF-ACCESS system can use the PMDF executable images and configuration files installed on the PMDF-MTA system. In this case, "installing" PMDF-ACCESS on another system in the cluster consists of installing the PMDF-ACCESS license, and then also performing steps 1, 2, 3, and 4 of Section 1.8 on that PMDF-ACCESS system.
The next case is where the cluster is homogeneous, but the PMDF-MTA
system is of a different architecture type (VAX or Alpha) than that of
the PMDF-ACCESS system. The only differences from the previous case are
that you must make sure to answer YES
when asked during the original PMDF-MTA installation whether or not to
install executable images of the other architecture type, so that the
PMDF directory structure will include executable images for both
architecture types, and that, as the installation procedure will
instruct you, you must run the post_install.com procedure
on a system of the other architecture type, e.g., the
PMDF-ACCESS system. When performing the above-mentioned steps from
Section 1.8 , note that the post_install.com procedure
will run the pmdf_startup.com procedure itself, to
correctly define the logicals to point to the executable images
corresponding to the architecture type.
In both of the above cases, installing the PMDF-ACCESS license
before running pmdf_startup.com allows the
pmdf_startup.com procedure to also perform the PMDF
LICENSE LOAD command necessary for activating the PMDF-ACCESS license;
if you happen to install the PMDF-ACCESS license after running
pmdf_startup.com, you will have to execute the PMDF
LICENSE LOAD command manually. You should also ensure that your system
startup procedure executes pmdf_startup.com.
The final case is where the cluster is heterogeneous or the PMDF-ACCESS system is not clustered with the PMDF-MTA machine. In this case, installing PMDF-ACCESS corresponds to performing an entire additional PMDF installation and a PMDF-ACCESS configuration, as described later in this chapter and in Chapters 7 and 8 ; the PMDF-ACCESS system will have its own copy of the PMDF distribution files and its own PMDF configuration files.
For the sample site ACME.COM shown in Figure 6-1 , the RDRUNR system is assumed to be clustered homogeneously with the PMDF-MTA COYOTE system, and so one of the first two types of setup would be feasible; i.e., RDRUNR merely needs a PMDF-ACCESS license and logical definitions pointing to the PMDF directory structure on the PMDF-MTA COYOTE system. On the other hand, the rabbit.acme.com system is an example of the final sort of PMDF-ACCESS system, one needing its own copy of the PMDF distribution files and its own PMDF-ACCESS configuration.