Products Applications Support Partners News About Digi Where to Buy
   
 
 
Technical Support

drivers
firmware upgrades
FAQs
product documentation
cabling
support tools
legacy products
about digi support
knowledge base
online support request
support feedback
support feedback
FTP site
inside out networks
 
 
Using Digi async cards in a VMS clustered environment
www.digi.com
  Advanced Search
Product Selector
     
  Technical Support
Drivers

Firmware Upgrades

FAQs

Product Documentation

Cabling

Support Tools

Legacy Products

About Digi Support

Knowledge Base

Online Support Request

FTP Site



Related Links
Inside Out Networks


 
Solutions Partners Support and Training Corporate Info Where to Buy Order Where to Buy Site Map Contact Us
Home > Support >kbase >
Using Digi async cards in a VMS clustered environment
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.

 

solutions | partner programs | corporate info | support and training | where to buy
site map | contact us | press releases |
events | promotions | advertising

Copyright © 1996-2001 Digi International. All rights reserved.

products | applications | support | partners | news | about Digi | where to buy | contact us | site map

Copyright © 1996-2002 Digi International. All rights reserved.



Contact Us Site Map Product Selector Digi Homepage