The OpenVMS Frequently Asked Questions(FAQ)
Previous Contents Index

15.6.3 Tell me about SET HOST/DUP and SET HOST/HSC

The OpenVMS DCL commands SET HOST/DUP and SET HOST/HSC are used to connect to storage controllers via the Diagnostics and Utility Protocol (DUP). These commands require that the FYDRIVER device driver be connected. This device driver connection is typically performed by adding the following command(s) into the system startup command procedure:

On OpenVMS Alpha: 


$ RUN SYS$SYSTEM:SYSMAN 
SYSMAN> IO CONNECT FYA0/NOADAPTER/DRIVER=SYS$FYDRIVER

On OpenVMS VAX: 


$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> CONNECT FYA0/NOADAPTER

Alternatives to the DCL SET HOST/DUP command include the console SET HOST command available on various mid- to recent-vintage VAX consoles:

Access to Parameters on an Embedded DSSI controller: 


SET HOST/DUP/DSSI[/BUS:{0:1}] dssi_node_number PARAMS

Access to Directory of tools on an Embedded DSSI controller: 


SET HOST/DUP/DSSI[/BUS:{0:1}] dssi_node_number DIRECT

Access to Parameters on a KFQSA DSSI controller: 


SHOW UQSSP ! to get port_controller_number PARAMS 
SET HOST/DUP/UQSSP port_controller_number PARAMS

These console commands are available on most MicroVAX and VAXstation 3xxx series systems, and most (all?) VAX 4xxx series systems. For further information, see the system documentation and---on most VAX systems---see the console HELP text.

EK-410AB-MG, _DSSI VAXcluster Installation and Troubleshooting_, is a good resource for setting up a DSSI VMScluster on OpenVMS VAX nodes. (This manual predates coverage of OpenVMS Alpha systems, but gives good coverage to all hardware and software aspects of setting up a DSSI-based VMScluster---and most of the concepts covered are directly applicable to OpenVMS Alpha systems. This manual specifically covers the hardware, which is something not covered by the standard OpenVMS VMScluster documentation.)

Also see Section 15.3.3, and for the SCS name of the OpenVMS host see Section 5.6.

15.6.4 How do I rename a DSSI disk (or tape?)

If you want to renumber or rename DSSI disks or DSSI tapes, it's easy---if you know the secret incantation...

From OpenVMS: 


$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> CONNECT FYA0/NOADAPTER 
SYSGEN> ^Z 
$ SET HOST/DUP/SERV=MSCP$DUP/TASK=PARAMS <DSSI-NODE-NAME> 
... 
PARAMS> STAT CONF 
<The software version is normally near the top of the display.> 
PARAMS> EXIT 
...

From the console on most 3000- and 4000-class VAX system consoles... (Obviously, the system must be halted for these commands...)

Integrated DSSI: 


SET HOST/DUP/DSSI[/BUS:[0:1]] dssi_node_number PARAMS

KFQSA: 


SET HOST/DUP/UQSSP port_controller_number PARAMS

For information on how to get out into the PARAMS subsystem, also see the HELP at the console prompt for the SET HOST syntax, or see the HELP on SET HOST /DUP (once you've connected FYDRIVER under OpenVMS).

Once you are out into the PARAMS subsystem, you can use the FORCEUNI option to force the use of the UNITNUM value and then set a unique UNITNUM inside each DSSI ISE---this causes each DSSI ISE to use the specfied unit number and not use the DSSI node as the unit number. Other parameters of interest are NODENAME and ALLCLASS, the node name and the (disk or tape) cluster allocation class.

Ensure that all disk unit numbers used within an OpenVMS Cluster disk allocation class are unique, and all tape unit numbers used within an OpenVMS Cluster tape allocation class are also unique. For details on the SCS name of the OpenVMS host, see Section 5.6. For details of SET HOST/DUP, see Section 15.6.3.

15.6.5 Where can I get Fibre Channel Storage (SAN) information?

15.6.6 How can I split up an OpenVMS Cluster?

Review the VMScluster documentation, and the System Management documentation. The following are the key points, but are likely not the only things you will need to change.

OpenVMS Cluster support is directly integrated into the operating system, and there is no way to remove it. You can, however, remote site-specific tailoring that was added for a particular cluster configuration.

First: Create restorable image BACKUPs of each of the current system disks. If something gets messed up, you want a way to recover, right?

Create standalone BACKUP kits for the OpenVMS VAX systems, and create or acquire bootable BACKUP kits for the OpenVMS Alpha systems.

Use CLUSTER_CONFIG or CLUSTER_CONFIG_LAN to remove the various system roots and to shut off boot services and VMScluster settings.

Create as many architecture-specific copies of the system disks as required. Realize that the new systems will all likely be booting through root SYS0---if you have any system-specific files in any other roots, save them.

Relocate the copies of the VMScluster common files onto each of the new system disks.

Reset the console parameters and boot flags on each system for use on a standalone node.

Reset the VAXCLUSTER and NISCS_LOAD_PEA0 parameters to 0 in SYSGEN and in MODPARAMS.DAT.

Clobber the VMScluster group ID and password using SYSMAN.

Reboot the systems seperately, and run AUTOGEN on each.

Shut off MOP services via NCP or LANCP on the boot server nodes.

Permanent seperation also requires the duplication of shared files. For a list of the files commonly shared, please see the most current version of SYS$STARTUP:SYLOGICALS.TEMPLATE, and specifically a version from OpenVMS V7.2 or later. The following files are typically shared within a cluster: 


  Filename:              default directory (in common root) and file type: 
    SYSUAF                      SYS$SYSTEM:.DAT 
    SYSUAFALT                   SYS$SYSTEM:.DAT 
    SYSALF                      SYS$SYSTEM:.DAT 
    RIGHTSLIST                  SYS$SYSTEM:.DAT 
    NETPROXY                    SYS$SYSTEM:.DAT 
    NET$PROXY                   SYS$SYSTEM:.DAT 
    NETOBJECT                   SYS$SYSTEM:.DAT 
    NETNODE_REMOTE              SYS$SYSTEM:.DAT 
    QMAN$MASTER                 SYS$SYSTEM: (this is a set of related files) 
    LMF$LICENSE                 SYS$SYSTEM:.LDB 
    VMSMAIL_PROFILE             SYS$SYSTEM:.DATA 
    VMS$OBJECTS                 SYS$SYSTEM:.DAT 
    VMS$AUDIT_SERVER            SYS$MANAGER:.DAT 
    VMS$PASSWORD_HISTORY        SYS$SYSTEM:.DATA 
    NETNODE_UPDATE              SYS$MANAGER:.COM 
    VMS$PASSWORD_POLICY         SYS$LIBRARY:.EXE 
    LAN$NODE_DATABASE           SYS$SYSTEM:LAN$NODE_DATABASE.DAT

Also see the topics on "cluster divorce" in the Ask The Wizard area.

For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.9.

Information on changing node names is included in Section 5.6.

15.6.7 Details on Volume Shadowing?

This section contains information on host-based volume shadowing; on the disk mirroring capabilities available within OpenVMS.

15.6.7.1 Does volume shadowing require a non-zero allocation classes?

Yes, use of host-based Volume Shadowing requires that the disk(s) involved be configured in a non-zero allocation class.

Edit SYS$SYSTEM:MODPARAMS.DAT to include a declaration of an non-zero allocation class, such as setting the host allocation class to the value 7: 


ALLOCLASS = 7

Then AUTOGEN the system, and reboot.

You should now be able to form the shadow set via a command such as the following: 


$ MOUNT dsa1007: /SHADOW=($7$dkb300:,$7$dkb500:) volumelabel

When operating in an OpenVMS Cluster, this sequence will typically change the disk names from the SCSNODE prefix (scsnode$dkann) to the allocation-class prefix ($7$dkannn). This may provide you with the opportunity to move to a device-independent scheme using logical name constructs such as the DISK$volumelabel logical names in your startup and application environments; an opportunity to weed out physical device references.

Allocation class one is used by Fibre Channel devices; it can be best to use another non-zero allocation class even if Fibre Channel is not currently configured and not currently planned.

Index Contents