|
Using Digi async cards in a VMS clustered environment Using Digi async cards in a VMS clustered environment Here are some notes which may help clarify how the driver might operate in a
clustered environment.
This is NOT intended as a "cluster primer", nor is it intended to describe the
ONLY method one might use to achieve clustered operation. It is intended
for those with some VMS clustering experience, who need to know the
particulars of how Digi drivers install in this context.
Cluster Environment Crib Notes:
In a VMS cluster, machines are able to use shared devices, including the
system disk. In the case of the system disk, directories are typically
structured so that there are a number of parallel directory trees... one
tree which is COMMON among all cluster members, and then system SPECIFIC
versions of the same tree. VMS then allows one to refer to a virtual
"super" directory which appears, logically, to be a combination of each
machine's system specific directory followed by the cluster common
directory. In such a model, a file which appears in the system specific
directory will be "found" first, and thus used instead of a cluster
common version, if one exists.
It is important to remember that ownership of devices is still critical in
a clustered environment. In general, each machine has its own local set of
devices, some of which may be exported to other machines in the
cluster.
How Digi Interacts with a Cluster by Default
The Digi device driver package installs itself into the cluster common
directory tree. On most systems, this directory is found in the following
location on the system disk:
[SYSn.SYSCOMMON.DGDRIVER]
... where the "n" in SYSn is replaced with the system's number (used to
distinguish between the SPECIFIC directories of the cluster's systems).
We also suggest that one create a logical called DIGI$DRIVER,
which refers to this specific directory. Files created in this logical
location will thus be placed in the cluster common directory tree, not a
system specific directory tree.
When one runs DG_SETUP.COM to configure the driver, it
creates a number of files including SPACE.MAR (which captures
the current configuration), the actual driver binary, and also a
"startup" program called an ICBM. The SPACE.MAR
file it leaves in the location specified by DIGI$DRIVER,
which normally is the cluster common directory. The driver binary it
places in a system specific directory by default. The ICBM it
also places in a system specific directory.
When loading and running the driver, one more file gets created: the
download daemon log file. This file is also left in
DIGI$DRIVER, which normally points to the cluster common
directory.
If one were to run DG_SETUP.COM from two different systems in
the cluster, the SPACE.MAR and download daemon log files
would conflict, but they would get their own individual driver binaries
and ICBMs because those get stored in a system specific
directory.
Because of VMS' architecture, when the driver is loaded on any system, it
will have its own "personal" set of device files associated with its
"personal" set of adapters. These devices are not, by default, available
to other machines in the cluster.
One Method to Run Digi Drivers on Multiple Machines in a
Cluster:
If one has Digi adapters in multiple machines, and one wishes to create
Digi serial devices on these machines so that those machines are able to
communicate with their own adapters, and one does NOT wish to share serial
ports physically located on machine with other machines in the cluster,
then the notes below apply.
- First, install the Digi adapters in those cluster machines which need
to have Digi serial devices.
- Second, install the Digi driver software on ONE of the machines in the
cluster. Because it installs the software to the cluster common directory
tree, other machines in the cluster will thus be able to access the
software. Do NOT install the software on more than one machine in the
cluster... it will get thoroughly confused (as multiple machines will
believe that they are the owners of the same files).
- Third, on the machine which you used to install the Digi driver
software,
get rid of the definition of the logical
DIGI$DRIVER (which
currently points to a system common area), i.e.:
DEASSIGN /SYS DIGI$DRIVER
- Fourth: create a directory tree in a system specific area for each
machine
which has an adapter. Suggested is:
CREATE/DIRECTORY SYS$SPECIFIC:[DGDRIVER]
... which, if a default VMS installation is assumed, points to the current
system's machine specific area.
- Fifth: change the MAKE_DIGI_LOGICAL.COM file to create a slightly
different version of the DIGI$DRIVER logical... we want it to point FIRST
to the system
specific DGDRIVER directory, then to the COMMON DGDRIVER directory. If the
instructions above are followed (so the naming is consistent across machines),
the following should work:
In [SYSn.SYSCOMMON.DGDRIVER]MAKE_DIGI_LOGICAL.COM change the
line:
DEFINE DIGI$DRIVER/SYSTEM drive:[SYSn.SYSCOMMON.DGDRIVER]
to...
DEFINE DIGI$DRIVER/SYSTEM SYS$SYSROOT:[DGDRIVER]
... because, by default, SYS$SYSROOT points first to the
machine specific area (and thus the DGDRIVER subdirectory
there), and then to the common area.
- Sixth: execute the new
MAKE_DIGI_LOGICAL.COM on each
machine,
so that they all have the new definition.
- Seventh: on each machine, execute:
@DIGI$DRIVER:DG_SETUP.COM
... which configures each specific machine for the adapters that they have
installed. "SPACE.MAR" should now appear in the
[SYSn.DGDRIVER]
directory instead
of the [SYSn.SYSCOMMON.DGDRIVER] directory.
- Eighth: change the system startup files on each system to create the
logical and then to call
DIGI_INSTALL_EPCA.COM. This process
can be exactly the same as the one suggested during the install. If the
commands are followed as above AND they are added to cluster common
startup scripts, you shouldn't need system specific versions of them. In
one file (one for logicals, probably), you would simply execute:
@SYS$SYSROOT:[DGDRIVER]MAKE_DIGI_LOGICAL.COM
In another file (one for standard startup, probably), you would simply
execute:
@DIGI$DRIVER:DIGI_INSTALL_EPCA.COM
- Finally: on each system (so you don't have to reboot) execute:
@DIGI$DRIVER:DIGI_INSTALL_EPCA.COM
... in order to load the driver and create the local device files.
Each system should now have their own independent set of TXA, TXB, etc.
Running DIGI$DRIVER:DPA.EXE will have the appropriate effect
no matter which system you are on, etc.
|