Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!news-hog.berkeley.edu!ucberkeley!nntp-relay.ihug.net!ihug.co.nz!news.compaq.com!news.cpqcorp.net!53ab2750!not-for-mail

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!news-hog.berkeley.edu!ucberkeley!nntp-relay.ihug.net!ihug.co.nz!news.compaq.com!news.cpqcorp.net!53ab2750!not-for-mail
Newsgroups: comp.os.vms,comp.sys.dec,vmsnet.alpha,vmsnet.misc,comp.answers,news.
Distribution: world
X-Newsreader: mxrn 6.18-32C
Expires: 03 Jul 2004 00:00:00 GMT
Followup-To: poster
References: <[email protected]>
Approved: [email protected]
From: [email protected] (Hoff Hoffman)
Reply-To: [email protected]
Organization: HP
Subject: OpenVMS Frequently Asked Questions (FAQ), Part 8/9
Summary: This posting contains answers to frequently asked questions about
the OpenVMS operating system from HP, and the computer systems on
which it runs.
Lines: 2354
Message-ID: <[email protected]>
Date: Thu, 03 Jul 2003 17:17:17 GMT
NNTP-Posting-Host: 16.32.80.251
X-Complaints-To: [email protected]
X-Trace: news.cpqcorp.net 1057252637 16.32.80.251 (Thu, 03 Jul 2003 10:17:17 PDT)
NNTP-Posting-Date: Thu, 03 Jul 2003 10:17:17 PDT
Xref: senator-bedfellow.mit.edu comp.os.vms:389894 comp.sys.dec:98156 vmsnet.alpha:12773 vmsnet.misc:6472 comp.answers:54094

Hardware Information

__________________________________________________________
14.24 Problem - My LK411 sends the wrong keycodes or some keys
are dead

Check the firmware revision on the keyboard. Hardware
revision B01 introduced an incompatability with the
device driver which causes the keyboard to not be
recognized correctly. There is a patch available to
fix this problem: [AXPDRIV06_061] - the fix is also
included in OpenVMS V6.2. The rev A01 keyboard, and the
LK450 should work without problems.

If you are working from another operating system
platform, please see the DECxterm tool and related
information on OpenVMS Freeware V5.0.

__________________________________________________________
14.25 Which DE500 variant works with which OpenVMS version?

Ensure you have a version of the Alpha SRM console
with support for the DE500 series device. Apply ALL
mandatory ECO kits for the OpenVMS version in use, and
also apply the CLUSIO, ALPBOOT, and ALPLAN kits, and
apply any available ALPCPU ECO kit for the platform.

o DE500-XA
auto-detection, no auto-negotiation,
OpenVMS V6.2-1H1 and ALPBOOT ECO, also V7.0 and
later and ECO.
Device hardware id 02000011 and 02000012.
Component part number 54-24187-01

o DE500-AA
auto-detection, auto-negotiation,
OpenVMS V6.2 and ALPBOOT and ALPLAN ECOs, or V7.1
and later and ECO.
Device hardware id 02000020 and 20000022.
Component part number 54-24502-01

o DE500-BA
auto-detection, auto-negotiation,
OpenVMS V6.2-1H3 and CLUSIO, ALPBOOT, ALPLAN and
ALPCPU ECOs, or V7.1-1H1 or later and ECO.
Device hardware id 02000030 (check connector, vs
DE500-FA) (other values on old Alpha SRM firmware)
Component part number 54-24602-01

14-38

Hardware Information

o DE500-FA (100 megabit fibre optic Ethernet)
OpenVMS V7.1-1H1 and later
Device hardware id 02000030 (check connector, vs
DE500-BA) (other values possible on old Alpha SRM
firmware)
Component part number 54-24899-01

To check the DE500 device hardware id from OpenVMS, use
the following command:

$ ANALYZE/SYSTEM
SDA> SHOW LAN/DEVICE=EWcu:

The "hardware id" will be displayed.

To set the DE500 speed via the Alpha SRM console
environment variable:

EWx0_MODE setting Meaning
-------------------------- --------------------------------
Twisted-Pair 10 Mbit/sec, nofull_duplex
Full Duplex, Twisted-Pair 10 Mbit/sec, full_duplex
AUI 10 Mbit/sec, nofull_duplex
BNC 10 Mbit/sec, nofull_duplex
Fast 100 Mbit/sec, nofull_duplex
FastFD (Full Duplex) 100 Mbit/sec, full_duplex
Auto-Negotiate Negotiation with remote device

To override the console setting and use LANCP:

$ RUN SYS$SYSTEM:LANCP
LANCP> SET DEV EWA0/SPEED=10
LANCP> SET DEV EWA0/SPEED=100/full_duplex

Fast Ethernet (100Base, 100 megabit) controllers
such as the DE500 series have a pair of connections
available-while traditional Ethernet (10Base, 10
megabit) is inherently a half-duplex protocol, Fast
Ethernet can be configured to use one or both of the
available connections, depending on the controller.
Fast Ethernet can thus be half- or full-duplex
depending on the configuration and the capabilities
of the network controller and the Ethernet network
plant. Some Fast Ethernet controllers can also operate
at traditional Ethernet speeds, these controllers are
thus often refered to as 10/100 Ethernet controllers.

14-39

Hardware Information

__________________________________________________________
14.26 Third-party disk/tape/controllers/SCSI/widgets on
OpenVMS?

A wide variety of third-party widgets-SCSI and ATA
(IDE) disks and tapes, graphics controllers, etc-are
obviously widely available and are used on various
platforms.

If you purchase third-party "generic" SCSI or ATA
(IDE) storage devices, you and your device vendor
will be responsible for the testing and the support
of the devices. In general, you can expect that Compaq
will address non-standards-compliance problems within
OpenVMS (changes that will also not prevent operations
with other supported devices, of course), but you
and/or the device vendor and/or the device manufacturer
are responsible for finding and fixing problems in
the particular third-party device and or controller
involved.

In particular, realize that neither SCSI nor ATA (IDE)
is a particularly standard interface, these interfaces
tend to be a collection of optionally-implemented and
standardized interface features. You should not and can
not simply assume that all SCSI nor ATA (IDE) storage
devices are interchangeable. If you want to try to use
a generic SCSI device, use V6.2 or later, or (better)
V7.1-2 or later. If you wish to try to use ATA (IDE),
use OpenVMS V7.1-2 or later.

On older OpenVMS releases, see the disk capacity limits
(Section 9.5).

With SCSI disks on releases prior to V6.2, ensure
that you have the ARRE and ARWE settings configured
correctly (disabled). (If not, you will see DRVERR
fatal drive errors and error log entries.)

Some SCSI disks set the medium type byte as part of
the SCSI size field-this is a SET CAPACITY extension to
SCSI specs. This problem also applies to VAX V7.1 and
later.

14-40

Hardware Information

Disks with SCSI disk sizes past 8.58 GB and/or with
the SET CAPACITY extension require ALPSCSI07 ECO or the
OpenVMS Alpha V7.1-2 or later release. (See Section 9.5
for further details.)

Based on the displays of the (undocumented)
SYS$ETC:SCSI_INFO tool; this tool is present in OpenVMS
V6.2 and later:

Issuing 6-byte MODE SENSE QIOW to get current values for page 01h
Page Code ................. 01h
Page Name ................. Read-Write Error Recovery
Saveable .................. Yes
Size ...................... 10
Hex Data .................. E6 08 50 00 00 00 08 00
00 00

The E6 indicates that the AWRE and ARRE bits are set,
and this is not acceptable on OpenVMS versions prior to
V6.2. Further along in the SCSI_INFO display, if you
also see:

Issuing 6-byte MODE SENSE QIOW to get changeable values for page 81h
Page Code ................. 01h
Page Name ................. Read-Write Error Recovery
Saveable .................. Yes
Size ...................... 10
Hex Data .................. C0 08 50 00 00 00 08 00
00 00

The C0 value means that the AWRE and ARRE values can
be changed on this particular SCSI device. (This is
not always the case.) Use RZDISK from the OpenVMS
Freeware, and reset the E6 flag byte to hexadecimal
26 (or whatever the remaining mask when you remove bits
C0) on page one.

Each SCSI and ATA (IDE) host contains non-trivial
SCSI and IDE driver software, and each device contains
equally non-trivial firmware- taken together with the
mechanical and electronic components, this software
and firmware will determine whether or not a particular
device will function as expected.

14-41

Hardware Information

Also note that various devices-such as various SCSI
CD-R devices -can implement and can require vendor-
specific protocol extensions, and these extensions can
require modifications to OpenVMS or the addition of
various utilities. In various of these cases, these
devices perform functions that will require them to
use SCSI or ATA (IDE) commands that are (hopefully)
architecturally-compatible SCSI or ATA (IDE) command
extensions. (Also see Section 7.1 and Section 9.7.)

In order for OpenVMS to officially support a particular
device, integration and testing work is mandated. There
can be no certainty that any particular device will
operate as expected in any particular configuration
without first performing this (non-trivial) work.

It is quite possible to find two devices-both entirely
compliant with applicable standards or interface
documents-that will not interoperate.

The same general statement holds for OpenVMS
bootstrapping on an unsupported VAX or Alpha platform.
It might or might not work. In particular, please see
the OpenVMS Software Product Description (SPD) for
the list of platforms supported by OpenVMS. OpenVMS
is not supported on the Personal Workstation -a
series, on the Digital Server series platforms, on
the AlphaServer 2100 series 5/375 CPU, on the Multia,
on the AlphaServer DS20L, and on a variety of other
platforms. (You might or might not see success booting
OpenVMS on any of these platforms.)

_____________________________
14.26.1 Lists of third-party widgets on OpenVMS?

Various folks have successfully used common third-
party disk disk devices with OpenVMS, such as the
ATA (IDE) and SCSI variants of the Iomega Zip250
removable disk device. Common SCSI CD-R/CD-RW devices
such as the Plextor PlexWriter 12/10/32S SCSI series
have also been successfully utilized with various
AlphaStation and VAXstation systems, and with tools
such as CDRECORD. (A Plextor burn of 614400000 bytes
(300000 sectors) requires just over six minutes at

14-42

Hardware Information

12x, using an AlphaStation XP1000 666 MHz EV67 system
UltraSCSI host.)

If you choose to attempt to use third-party devices,
ensure that you have the current OpenVMS version and
the current ECO kit(s) applied. In the case of the
ATA (IDE) Zip250 drive, ensure that you have the most
current revision of SYS$DQDRIVER installed.

_____________________________
14.26.2 Are the 2X-KZPCA-AA and SN-KZPCA-AA LVD Ultra2 SCSI?

Yes. Both of these controllers are Ultra2 low-voltage
_________differential_(LVD)_SCSI controllers.

14.26.3 Resolving DRVERR fatal device error?

If this is on an OpenVMS version prior to V6.2, please
see the AWRE and ARRE information included in section
Section 14.26.

__________________________________________________________
14.27 How do I convert? Disk Blocks? KB, MB, GB, TB?

The smallest granularity of disk storage addressing is
called a disk block, or sometimes a disk sector. Groups
of disk blocks are usually organized together into
the smallest unit of storage that can be allocated,
and this unit is called a disk cluster. The number
of blocks in a cluster is the cluster factor, and is
established when the disk volume is initialized.

Each individual disk block is composed of five hundred
twelve (512) bytes, or one-half kilobyte. Each byte is
comprised of eight bits. A bit represents the smallest
unit of information, typically refered to as a one or a
zero.

OpenVMS tends to uses base two notation for disk
storage, while disk storage capacity specifications
from most storage vendors (including Compaq) will
generally use base ten notation.

An OpenVMS disk block is 512 bytes in size; this is
one-half kilobyte in base two notation.

14-43

Hardware Information

The following table describes the prefix, the
abbreviation, and the associated base ten (marketing)
and base two (OpenVMS) values.

Base Ten Base Two
----------------------------- ----------------------
Kilobyte (KB) 10**3 1000 2**10 1024
Megabyte (MB) 10**6 1000000 2**20 1048576
Gigabyte (GB) 10**9 1000000000 2**30 1073741824
Terabyte (TB) 10**12 1000000000000 2**40 1099511627776
Petabyte (PB) 10**15 1000000000000000 2**50 1125899906842624

The base ten representation of the 2**40 value is
1099511627776, which is obviously rather ugly. When
viewed as a base eight or base sixteen (octal or
hexadecimal, respectively) value, the value is far
nicer. Specifically, the value is 10000000000 and
40000000 when represented in octal and hexadecimal,
respectively.

Notational note: Within the OpenVMS FAQ, a thousand
bits is a kilobit, and is always represented by the
appreviation Kb, while a Kilobyte is always represented
as KB. OpenVMS operating system references to system
and storage are generally to the base-two version
(eg: 1024, in the case of a kilobyte or kilobit) while
storage hardware references and hardware specifications
are generally to the base-ten version (eg: 1000).

To convert OpenVMS disk blocks to (base two) kilobytes
(KB; 1024 bytes), simply divide by two. To convert
blocks to (base two) megabytes, divide by 2048. Blocks
to (base two) gigabytes (GB), divide by 2097152.
These particular divisions can also be performed using
bitshifts: to divide a value by two, shift the binary
value rightwards by one bit position.

To convert OpenVMS disk blocks to (base ten) kilobytes,
divide by approximately 1.953125.

And for those rummaging around deep within SYSGEN, a
microfortnight is approximately one second.

14-44

Hardware Information

__________________________________________________________
14.28 Looking for connector wiring pinouts?

The DECconnect DEC-
423 Modified Modular Jack (MMJ) pinout:

1: Data Terminal Ready (DTR)
2: Transmit (TXD)
3: Transmit Ground (TXD-)
4: Receive Ground (RXD-)
5: Receive (RXD)
6: Data Set Ready (DSR)

+------------------+
| 1 2 3 4 5 6 |
+------------+ ++
+____+

The PC-compatible DB9 connector pinout follows:

1: Data Carrier Detect (DCD)
2: Received Data
3: Transmit Data
4: Data Terminal Ready (DTR)
5: Ground
6: Data Set Ready (DSR)
7: Request To Send (RTS)
8: Clear To Send
9: floating

The MicroVAX DB9 console connector pinout predates the
PC-style DB9 pinout, and uses a then-common (and older)
standard pinout, and uses the following EIA-232 series
standard signals:

1: Protective Ground
2: Transmited Data
3: Received Data
4: Request To Send (RTS)
5: Data Terminal Ready (DTR)
6: Data Set Ready (DSR)
7: Signal Ground
8: Shorted to pin 9 on MicroVAX and VAXstation 2000...
9: ...series systems, otherwise left floating.

14-45

Hardware Information

When pin 8 is shorted to pin 9, this is a BCC08 (or variant) cable,
most commonly used as a console cable on the MicroVAX 2000 and
VAXstation 2000 series. (Other systems may or may not tolerate
connecting pin 8 to pin 9.)

The BC16E-nn (where -nn indicates the cable length)
cable key impliicitly "flips over" (crosses-over) the
signal wires, so all DECconnect MMJ connectors are
wired the same.

//
---- ----
| |---------------------------------| |
---- ----
\\

The BC16E-nn cross-over wiring looks like this:

Terminal Host
MMJ MMJ

DTR 1 --->---------->----------->--- 6 DSR
TXD 2 --->---------->----------->--- 5 RXD
3 ------------------------------ 4
4 ------------------------------ 3
RXD 5 ---<----------<-----------<--- 2 TXD
DSR 6 ---<----------<-----------<--- 1 DTR

The BN24H looks like this:

MMJ RJ45

1---------8
2---------2
3---------1
4---------3
5---------6
6---------7

The BN24J looks like this:

14-46

Hardware Information

MMJ RJ45

1---------7
2---------6
3---------3
4---------1
5---------2
6---------8

Also see:

o http://www.openvms.compaq.com/wizard/padapters.html

o http://www.airborn.com.au/rs232.html

o http://www.stanq.com/cable.html

o For adapters and connectors, see Section 14.29.

__________________________________________________________
14.29 What connectors and wiring adapters are available?

The H8571-B converts the (non-2000-series) MicroVAX
DB9 to MMJ DECconnect. The MicroVAX 2000 and VAXstation
2000 requires a BCC08 cable (which has the 8-9 short,
see Section 14.28) and the H8571-D for use with
DECconnect.

More recent HP (HP, Compaq or DIGITAL logo) systems
will use either the DECconnect MMJ wiring or (on all
recent system designs) the PC-compatible DB9 pinout.

DECconnect MMJ adapters:

Part: Converts BC16E MMJ male to fit into:

H8571-C 25 pin DSUB Female to MMJ, Unfiltered
H8571-D EIA232 25 pin male (modem-wired)
H8571-E 25 pin DSUB Female to MMJ, Filtered
H8571-J PC/AT 9 pin male (PC serial port)
H8572-0 BC16E MMJ double-female (MMJ extender)
H8575-A EIA232 25 pin female (common)
H8575-B EIA232 9 pin male (MicroVAX II console)
H8575-D 25 Pin to MMJ W/EOS and ESD Protection
H8577-AA 6 pin Female MMJ to 8 pin MJ
BC16E-** MMJ cable, available in various lengths

14-47

Hardware Information

Numerous additional adapters and cables are available
from the _OPEN DECconnect Building Wiring Components
and Applications Catalog_, as well as descriptions of
the above-listed parts.

The H8571-A and H8575-A are MMJ to DB25 (female) and
are wired as follows:

Also see:

o http://www.openvms.compaq.com/wizard/padapters.html

Jameco offers a USB-A to PS/2 Mini DIN 6 Adapter (as
part 168751), for those folks wishing to (try to) use
PS/2 Keyboards via USB-A connections. The LK463 USB
keyboard is also a potential option, for those wishing
to connect an OpenVMS keyboard to USB systems or (via
the provided adapter) to PS/2 systems.

__________________________________________________________
14.30 What is flow control and how does it work?

XON/XOFF is one kind of flow control.

In ASCII, XON is the <CTRL/Q> character, and XOFF is
the <CTRL/S>.

XON/XOFF flow control is typically associated with
asynchronous serial line communications. XON/XOFF is an
in-band flow control, meaning that the flow control is
mixed in with the data.

CTS/RTS is another type of flow control, and is
sometimes called hardware flow control. Out-of-band
means that seperate lines/pins from the data lines
(pins) are used to carry the CTS/RTS signals.

Both kinds of flow control are triggered when a
threshold is reached in the incoming buffer. The flow
control is suppose to reach the transmitter in time to
have it stop transmitting before the receiver buffer is
full and data is lost. Later, after a sufficient amount
of the receiver's buffer is freed up, the resume flow
control signal is sent to get the transmitter going
again.

14-48

Hardware Information

DECnet Phase IV on OpenVMS VAX supports the use of
asynchronous serial communications as a network
line; of asynch DECnet. The communication devices
(eg. modems, and drivers) must not be configured
for XON/XOFF flow control. The incidence of these
(unexpected) in-band characters will corrupt data
packets. Further, the serial line device drivers
might normally remove the XON and XOFF characters
from the stream for terminal applications, but DECnet
configures the driver to pass all characters through
and requires that all characters be permitted. (The
communication devices must pass through not only the
XON and XOFF characters, they must pass all characters
including the 8-bit characters. If data compression is
happening, it must reproduce the source stream exactly.
No addition or elimination of null characters, and full
data transparency.

An Ethernet network is rather different than an
asynchronous serial line. Ethernet specifies the
control of data flow on a shared segment using CSMA/CD
(Carrier Sense Multiple Access, with Collision Detect)
An Ethernet station that is ready to transmit listens
for a clear channel (Carrier Sense). When the channel
is clear, the station begins to transmit by asserting
a carrier and encoding the packet appropriately. The
station concurrently listens to its own signal, to
permit the station to detect if another station began
to transmit at the same time-this is called collision
detection. (The collision corrupts the signal in a
way that can reliably be detected.) Upon detecting the
collision, both stations will stop transmitting, and
will back off and try again a little later. (You can
see a log of this activity in the DECnet NCP network
counters.)

DECnet provides its own flow control, above and beyond
the flow control of the physical layer (if any). The
end nodes handshake at the beginning to establish
a transmit window size-and a transmitter will only
send that much data before stopping and waiting for
an acknowledgement. The acknowledgement is only sent
when the receiver has confirmed the packet is valid. (A

14-49

Hardware Information

well-configured DECnet generally avoids triggering any
underlying (out-of-band) flow control mechanism.)

14-50

_______________________________________________________

15 Information on Networks and Clusters

The following sections contain information on OpenVMS
Networking with IP and DECnet, and on clustering and
volume shadowing, on Fibre Channel, and on related
products and configurations.

__________________________________________________________
15.1 How to connect OpenVMS to a Modem?

Please see the Ask The Wizard area topics starting with
(81), (1839), (2177), (3605), etc.

o http://www.openvms.compaq.com/wizard/

o http://www.openvms.compaq.com/wizard/wizard.zip

For additional information, please see Section 3.9.

__________________________________________________________
15.2 OpenVMS and IP Networking?

The following sections contain information on OpenVMS
and IP networking, as well as IP printing topics.

_____________________________
15.2.1 How to connect OpenVMS to the Internet?

Some tutorial information and tips for connecting
OpenVMS systems to the Internet are available at:

o http://www.tmesis.com/internet/

_____________________________
15.2.2 Connecting to an IP Printer?

To connect a printer via the IP telnet or lpr/lpd
protocols, you will need to install and configure an IP
stack on OpenVMS, and configure the appropriate print
queue.

15-1

Information on Networks and Clusters

With current OpenVMS IP implementations, the choice
of telnet or lpr/lpd really amounts to determining
which of these works better with the particular printer
involved.

To support network printing, the printer must include
an internal or external NIC or JetDirect; an adapter
connecting the network and the printer.

While it is normally possible to use a host-connected
printer-when the host supports an LPD or telnet daemon,
and OpenVMS and most other operating systems have the
ability to serve locally-attached printers to other
hosts on the network-it is generally far easier and
far more effective to use a printer that is directly
attached to the network. If your present printer does
not have a NIC or a JetDirect, acquire an internal (if
available) or external NIC or JetDirect. Or replace the
printer. And obviously, most any operating system that
can serve its local printers usually also provides
a client that can access remote network-connected
printers.

please see the Ask The Wizard area topics-starting with
topic (1020)-for additional information on IP-based
network printing.

o http://www.openvms.compaq.com/wizard/

o http://www.openvms.compaq.com/wizard/wizard.zip

For additional information, please see Section 3.9.

Please see Section 15.2.3 for information on Postscript
printing. comment>(--------------------)

_____________________________
15.2.3 How do I connect a PostScript printer via TCP/IP?

Using TCP/IP Services (UCX) as the TCP/IP stack, it is
possible to configure queues using the UCX$TELNETSYM
(TCP/IP Services prior to V5.0) or TCPIP$TELNETSYM
(with V5.0 and later) in order to print to Postscript
printers. This assumes however that the printer itself
can convert whatever is passed to it into something
intelligible. As an example, if the printer has an IP

15-2

Information on Networks and Clusters

address of 123.456.789.101 and jobs should be passed to
port 9100 then :

$ INITIALIZE/QUEUE/ON="123.456.789.101:9100" -
/PROCESSOR=UCX$TELNETSYM -
my_ip_queue

$ INITIALIZE/QUEUE/ON="123.456.789.101:9100" -
/PROCESSOR=TCPIP$TELNETSYM -
my_ip_queue

The port number of 9100 is typical of HP JetDirect
cards but may be different for other manufacturers
cards.

As a better alternative, DCPS Version 1.4 and later
support IP queues using either HP TCP/IP Services
for OpenVMS software or Process Software Multinet
for OpenVMS. The usage of this type of interface is
documented in the DCPS documentation or release notes,
and the DCPS$STARTUP.TEMPLATE startup template file.

For general and additional (non-Postscript) IP printing
information, please see topic (1020) and other topics
referenced in that topic elsewhere within the Ask The
Wizard area.

o http://www.openvms.compaq.com/wizard/

o http://www.openvms.compaq.com/wizard/wizard.zip

For additional information, please see Section 3.9.
Also see:

o http://www.wotsit.org/

Please see Section 15.2.2 for pointers to an
introduction to IP printing.

_____________________________
15.2.4 How do I set a default IP route or gateway on OpenVMS?

If you have TCP/IP Services, then use the command for
TCP/IP Services V5.0 and later:

$ TCPIP
SET ROUTE/GATE=x.x.x.x/DEFAULT/PERMANENT

15-3

Information on Networks and Clusters

And for earlier TCP/IP Services versions, use the
command:

$ UCX
SET ROUTE/GATE=x.x.x.x/DEFAULT/PERMANENT

_____________________________
15.2.5 How can I set up reverse telnet (like reverse LAT)?

Though it may seem obvious, Telnet and LAT are quite
different-with differing capabilities and design goals.

Please see the documentation around the TCP/IP Services
for OpenVMS TELNET command CREATE_SESSION. This command
is the equivilent of the operations performed in
LTLOAD.COM or LAT$SYSTARTUP.COM. There is no TELNET
equivilent to the sys$qio[w] control interface for
LTDRIVER (as documented in the I/O User's Reference
Manual) available, though standard sys$qio[w] calls
referencing the created TN device would likely operate
as expected.

_____________________________
15.2.6 Why can't I use PPP and RAS to connect to OpenVMS Alpha?

OpenVMS Alpha IP PPP does not presently support
authentication, and the Microsoft Windows NT option
to disable authentication during a RAS connection
apparently doesn't currently work-RAS connections will
require authentication-and this will thus prevent RAS
connections.

Future versions of OpenVMS and TCP/IP Services may
add this, and future versions of Microsoft Windows may
permit operations with authentication disabled.

__________________________________________________________
15.3 OpenVMS and DECnet Networking?

The following sections contain information on OpenVMS
and DECnet networking.

15-4

Information on Networks and Clusters

_____________________________
15.3.1 Can DECnet-Plus operate over IP?

Yes. To configure DECnet-Plus to operate over IP
transport and over IP backbone networks, install and
configure DECnet-Plus, and install and configure the
PWIP mechanism available within the currently-installed
IP stack. Within TCP/IP Services, this is a PWIPDRIVER
configuration option within the UCX$CONFIG (versions
prior to V5.0) or TCPIP$CONFIG (with V5.0 and later)
configuration tool.

_____________________________
15.3.2 What does "failure on back translate address request"
mean?

The error message:

BCKTRNSFAIL, failure on the back translate address request

indicates that the destination node is running DECnet-
Plus, and that its naming service (DECnet-Plus DECdns,
LOCAL node database, etc) cannot locate a name to
associate with the source node's address. In other
words, the destination node cannot determine the node
name for the node that is the source of the incoming
connection.

Use the DECNET_REGISTER mechanism (on the destination
node) to register or modify the name(s) and the
address(es) of the source node. Check the namespace
on the source node, as well.

Typically, the nodes involved are using a LOCAL
namespace, and the node name and address settings are
not coherent across all nodes. Also check to make sure
that the node is entered into its own LOCAL namespace.
This can be a problem elsewhere, however. Very rarely,
a cache corruption has been known to cause this error.
To flush the cache, use the command:

$ RUN SYS$SYSTEM:NCL
flush session control naming cache entry "*"

15-5

Information on Networks and Clusters

Also check to see that you are using the latest ECO for
DECnet-Plus for the version you are running. DECnet-
Plus can use the following namespaces:

o DECdns: DECnet-Plus distributed name services.

o LocalFile: a local file containing names and
addresses.

o DNS/BIND: the TCP/IP distributed name services
mechanism.

o The TCP/IP Services (UCX) local host file.

Of these, searching DNS/BIND and LocalFile,
respectively, is often the most appropriate
configuration.

_____________________________
15.3.3 Performing SET HOST/MOP in DECnet-Plus?

First, issue the NCL command SHOW MOP CIRCUIT *

$ RUN SYS$SYSTEM:NCL
SHOW MOP CIRCUIT *

Assume that you have a circuit known as FDDI-0
displayed. Here is an example of the SET HOST/MOP
command syntax utilized for this circuit:

$ SET HOST/MOP/ADDRESS=08-00-2B-2C-5A-23/CIRCUIT=FDDI-0

Also see Section 15.6.3.

__________________________________________________________
15.4 How to determine the network hardware address?

Most Alpha and most VAX systems have a console command
that displays the network hardware address. Many
systems will also have a sticker identifying the
address, either on the enclosure or on the network
controller itself.

The system console power-up messages on a number of VAX
and Alpha systems will display the hardware address,
particularly on those systems with an integrated
Ethernet network adapter present.

15-6

Information on Networks and Clusters

If you cannot locate a sticker on the system, if
the system powerup message is unavailable or does
not display the address, and if the system is at the
console prompt, start with the console command:

HELP

A console command similar to one of the following is
typically used to display the hardware address:

SHOW DEVICE
SHOW ETHERNET
SHOW CONFIG

On the oldest VAX Q-bus systems, the following console
command can be used to read the address directly off
the (DELQA, DESQA, or the not-supported-in-V5.5-and-
later DEQNA) Ethernet controller:

E/P/W/N:5 20001920

Look at the low byte of the six words displayed by
the above command. (The oldest VAX Q-bus systems-such
as the KA630 processor module used on the MicroVAX II
and VAXstation II series-lack a console HELP command,
and these systems typically have the primary network
controller installed such that the hardware address
value is located at the system physical address
20001920.)

If the system is a VAX system, and another VAX system
on the network is configured to answer Maintenance
and Operations Protocol (MOP) bootstrap requests
(via DECnet Phase IV, DECnet-Plus, or LANCP), the
MOM$SYSTEM:READ_ADDR.EXE tool can be requested:

B/R5:100 ddcu
Bootfile: READ_ADDR

Where ddcu is the name of the Ethernet controller in
the above command. The primarly local DELQA, DESQA,
and DEQNA Q-bus controllers are usually named XQA0.
An attempt to MOP download the READ_ADDR program will
ensue, and (if the download is successful) READ_ADDR
will display the hardware address.

15-7

Information on Networks and Clusters

If the system is running, you can use DECnet or
TCP/IP to display the hardware address with one of
the following commands.

$! DECnet Phase IV
$ RUN SYS$SYSTEM:NCP
SHOW KNOWN LINE CHARACTERISTICS

$! DECnet-Plus
$ RUN SYS$SYSTEM:NCL
SHOW CSMA-CD STATION * ALL STATUS

$! TCP/IP versions prior to V5.0
$ UCX
SHOW INTERFACE/FULL

$! TCP/IP versions V5.0 and later
$ TCPIP
SHOW INTERFACE/FULL

A program can be created to display the hardware
address, reading the necessary information from the
network device drivers. An example C program for
reading the Ethernet hardware address (via sys$qio
calls to the network device driver(s)) is available at
the following URL:

o http://www.openvms.compaq.com/wizard/swdev/ethernVMS.html

To use the DECnet Phase IV configurator tool to watch
for MOP SYSID activity on the local area network:

$ RUN SYS$SYSTEM:NCP
SET MODULE CONFIGURATOR KNOWN CIRCUIT SURVEILLANCE ENABLED

Let the DECnet Phase IV configurator run for at least
20 minutes, and preferably longer. Then issue the
following commands:

$ RUN SYS$SYSTEM:NCP
SHOW MODULE CONFIGURATOR KNOWN CIRCUIT STATUS TO filename.txt
SET MODULE CONFIGURATOR KNOWN CIRCUIT SURVEILLANCE DISABLED

The resulting file (named filename.txt) can now be
searched for the information of interest. Most DECnet
systems will generate MOP SYSID messages identifying
items such as the controller hardware address and the

15-8

Information on Networks and Clusters

controller type, and these messages are generated and
multicast roughly every ten minutes.

Information on the DECnet MOP SYSID messages and other
parts of the maintenance protocols is included in the
DECnet network architecture specifications referenced
in section DOC9.

_____________________________
15.4.1 How do I reset the LAN (DECnet-Plus NCL) error counters?

On recent OpenVMS releases:

$ RUN SYS$SYSTEM:LANCP
SET DEVICE/DEVICE_SPECIFIC=FUNCTION="CCOU" devname

_____________________________
15.4.2 How do I install DECnet Phase IV on VMS 7.1?

On OpenVMS V7.1, all DECnet binaries were relocated
into separate installation kits-you can selectively
install the appropriate network: DECnet-Plus (formerly
known as DECnet OSI), DECnet Phase IV, and HP TCP/IP
Services (often known as UCX).

On OpenVMS versions prior to V7.1, DECnet Phase IV was
integrated, and there was no installation question. You
had to install the DECnet-Plus (DECnet/OSI) package on
the system, after the OpenVMS upgrade or installation
completed.

During an OpenVMS V7.1 installation or upgrade, the
installation procedure will query you to learn if
DECnet-Plus should be installed. If you are upgrading
to V7.1 from an earlier release or are installing V7.1
from a distribution kit, simply answer "NO" to the
question asking you if you want DECnet-Plus. Then-after
the OpenVMS upgrade or installation completes - use
the PCSI PRODUCT INSTALL command to install the DECnet
Phase IV binaries from the kit provided on the OpenVMS
software distribution kit.

If you already have DECnet-Plus installed and wish
to revert, you must reconfigure OpenVMS. You cannot
reconfigure the "live" system, hence you must reboot
the system using the V7.1 distribution CD-ROM. Then

15-9

Information on Networks and Clusters

select the DCL ($$$ prompt) option. Then issue the
commands:

$$$ DEFINE/SYSTEM PCSI$SYSDEVICE DKA0:
$$$ DEFINE/SYSTEM PCSI$SPECIFIC DKA0:[SYS0.]
$$$ PRODUCT RECONFIGURE VMS /REMOTE/SOURCE=DKA0:[VMS$COMMON]

The above commands assume that the target system device
and system root are "DKA0:[SYS0.]". Replace this with
the actual target device and root, as appropriate.
The RECONFIGURE command will then issue a series of
prompts. You will want to reconfigure DECnet-Plus off
the system, obviously. You will then want to use the
PCSI command PRODUCT INSTALL to install the DECnet
Phase IV kit from the OpenVMS distribution media.

Information on DECnet support, and on the kit names, is
included in the OpenVMS V7.1 installation and upgrade
documentation.

Subsequent OpenVMS upgrade and installation procedures
can and do offer both DECnet Phase IV and DECnet-Plus
installations.

__________________________________________________________
15.5 How can I send (radio) pages from my OpenVMS system?

There are third-party products available to
send messages to radio paging devices (pagers),
communicating via various protocols such as TAP
(Telocator Alphanumeric Protocol); paging packages.

RamPage (Ergonomic Solutions) is one of the available
packages that can generate and transmit messages to
radio pagers. Target Alert (Target Systems; formerly
the DECalert product) is another. Networking Dynamics
Corp has a product called Pager Plus. The System
Watchdog package can also send pages. The Process
Software package PMDF can route specific email
addresses to a paging service, as well.

Many commercial paging services provide email contact
addresses for their paging customers-you can simply
send or forward email directly to the email address
assigned to the pager.

15-10

Information on Networks and Clusters

Some people implement the sending of pages to radio
pagers by sending commands to a modem to take the
"phone" off the "hook", and then the paging sequence,
followed by a delay, and then the same number that a
human would dial to send a numeric page. (This is not
entirely reliable, as the modem lacks "call progress
detection", and the program could simply send the
dial sequence when not really connected to the paging
company's telephone-based dial-up receiver.)

See Section 13.1 for information on the available
catalog of products.

__________________________________________________________
15.6 OpenVMS, Clusters, Volume Shadowing?

The following sections contain information on OpenVMS
and Clusters, Volume Shadowing, and Cluster-related
system parameters.

_____________________________
15.6.1 OpenVMS Cluster Communications Protocol Details?

The following sections contain information on the
OpenVMS System Communications Services (SCS) Protocol.

_____________________________
15.6.1.1 OpenVMS Cluster (SCS) over DECnet? Over IP?

The OpenVMS Cluster environment operates over various
network protocols, but the core of clustering uses
the System Communications Services (SCS) protocols,
and SCS-specific network datagrams. Direct (full)
connectivity is assumed.

An OpenVMS Cluster does not operate over DECnet, nor
over IP.

No SCS protocol routers are available.

Many folks have suggested operating SCS over DECnet
or IP over the years, but SCS is too far down in
the layers, and any such project would entail a
major or complete rewrite of SCS and of the DECnet
or IP drivers. Further, the current DECnet and IP
implementations have large tracts of code that operate
at the application level, while SCS must operate in

15-11

Information on Networks and Clusters

the rather more primitive contexts of the system and
particularly the bootstrap-to get SCS to operate over a
DECnet or IP connection would require relocating major
portions of the DECnet or IP stack into the kernel.
(And it is not clear that the result would even meet
the bandwidth and latency expectations.)

The usual approach for multi-site OpenVMS Cluster
configurations involves FDDI, Memory Channel (MC2), or
a point-to-point remote bridge, brouter, or switch. The
connection must be transparent, and it must operate at
10 megabits per second or better (Ethernet speed), with
latency characteristics similar to that of Ethernet or
better. Various sites use FDDI, MC2, ATM, or point-to-
point T3 link.

_____________________________
15.6.1.2 Configuring Cluster SCS for path load balancing?

This section discusses OpenVMS Cluster communications,
cluster terminology, related utilities, and command and
control interfaces.

_____________________________
15.6.1.2.1 Cluster Terminology?

SCS: Systems Communication Services. The protocol used
to communicate between VMSCluster systems and between
OpenVMS systems and SCS-based storage controllers.
(SCSI-based storage controllers do not use SCS.)

PORT: A communications device, such as DSSI, CI,
Ethernet or FDDI. Each CI or DSSI bus is a different
local port, named PAA0, PAB0, PAC0 etc. All Ethernet
and FDDI busses make up a single PEA0 port.

VIRTUAL CIRCUIT: A reliable communications path
established between a pair of ports. Each port in a
VMScluster establishes a virtual circuit with every
other port in that cluster.

All systems and storage controllers establish "Virtual
Circuits" to enable communications between all
available pairs of ports.

15-12

Information on Networks and Clusters

SYSAP: A "system application" that communicates using
SCS. Each SYSAP communicates with a particular remote
SYSAP. Example SYSAPs include:

VMS$DISK_CL_DRIVER connects to MSCP$DISK
The disk class driver is on every VMSCluster system.
MSCP$DISK is on all disk controllers and all VMSCluster
systems that have SYSGEN parameter MSCP_LOAD set to 1

VMS$TAPE_CL_DRIVER connects to MSCP$TAPE
The tape class driver is on every VMSCluster system.
MSCP$TAPE is on all tape controllers and all VMSCluster
systems that have SYSGEN parameter TMSCP_LOAD set to 1

VMS$VAXCLUSTER connects to VMS$VAXCLUSTER
This SYSAP contains the connection manager, which
manages cluster connectivity, runs the cluster state
transition algorithm, and implements the cluster quorum
algorithm. This SYSAP also handles lock traffic, and
various other cluster communications functions.

SCS$DIR_LOOKUP connects to SCS$DIRECTORY
This SYSAP is used to find SYSAPs on remote systems

MSCP and TMSCP
The Mass Storage Control Protocol and the Tape MSCP
servers are SYSAPs that provide access to disk and
tape storage, typically operating over SCS protocols.
MSCP and TMSCP SYSAPs exist within OpenVMS (for OpenVMS
hosts serving disks and tapes), within CI- and DSSI-
based storage controllers, and within host-based MSCP-
or TMSCP storage controllers. MSCP and TMSCP can be
used to serve MSCP and TMSCP storage devices, and can
also be used to serve SCSI and other non-MSCP/non-TMSCP
storage devices.

SCS CONNECTION: A SYSAP on one node establishes an SCS
connection to its counterpart on another node. This
connection will be on ONE AND ONLY ONE of the available
virtual circuits.

15-13

Information on Networks and Clusters

_____________________________
15.6.1.2.2 Cluster Communications Control?

When there are multiple virtual circuits between two
OpenVMS systems it is possible for the VMS$VAXCLUSTER
to VMS$VAXCLUSTER connection to use any one of these
circuits. All lock traffic between the two systems will
then travel on the selected virtual circuit.

Each port has a "LOAD CLASS" associated with it. This
load class helps to determine which virtual circuit
a connection will use. If one port has a higher load
class than all others then this port will be used. If
two or more ports have equally high load classes then
the connection will use the first of these that it
finds. Normally all CI and DSSI ports have a load class
of 14(hex), while the Ethernet and FDDI ports will have
a load class of A(hex).

For instance, if you have multiple DSSI busses and
an FDDI, the VMS$VAXCLUSTER connection will chose the
DSSI bus as this path has the system disk, and thus
will always be the first DSSI bus discovered when the
OpenVMS system boots.

To force all lock traffic off the DSSI and on to
the FDDI, for instance, an adjustment to the load
class value is required, or the DSSI SCS port must
be disabled.

Note that with PE ports, you can typically immediately
re-enable the path, permitting failover to occur should
congestion or a problem arise-a running average of the
path latency is checked when the virtual circuit is
formed, and at periodic intervals (circa every three
seconds), and when a problem with a virtual circuit
arises.

In the case of PEDRIVER, the driver handles load
balancing among the available Ethernet and FDDI
connections based on the lowest latency path available
to it. Traffic will be routed through that path until
an event occurs that requires a fail-over.

15-14

Information on Networks and Clusters

_____________________________
15.6.1.2.3 Cluster Communications Control Tools and Utilities?

In most OpenVMS versions, you can use the tools:

o SYS$EXAMPLES:LAVC$STOP_BUS

o SYS$EXAMPLES:LAVC$START_BUS

These tools permit you to disable or enable all SCS
traffic on the on the specified paths.

You can also use a preferred path mechanism that tells
the local MSCP disk class driver (DUDRIVER) which path
to a disk should be used. Generally, this is used with
dual-pathed disks, forcing I/O traffic through one of
the controllers instead of the other. This can be used
to implement a crude form of I/O load balancing at the
disk I/O level.

Prior to V7.2, the preferred path feature uses the
tool:

o SYS$EXAMPLES:PREFER.MAR

In OpenVMS V7.2 and later, you can use the following
DCL command:

$ SET PREFERRED_PATH

The preferred path mechanism does not disable nor
affect SCS operations on the non-preferred path.

With OpenVMS V7.3 and later, please see the SCACP
utility for control over cluster communications, SCS
virtual circuit control, port selection, and related.

_____________________________
15.6.2 Cluster System Parameter Settings?

The following sections contain details of configuring
cluster-related system parameters.

15-15

Information on Networks and Clusters

_____________________________
15.6.2.1 What is the correct value for EXPECTED_VOTES in a
VMScluster?

The VMScluster connection manager uses the concept
of votes and quorum to prevent disk and memory data
corruptions-when sufficient votes are present for
quorum, then access to resources is permitted. When
sufficient votes are not present, user activity will be
blocked. The act of blocking user activity is called
a "quorum hang", and is better thought of as a "user
data integrity interlock". This mechanism is designed
to prevent a partitioned VMScluster, and the resultant
massive disk data corruptions. The quorum mechanism is
expressly intended to prevent your data from becoming
severely corrupted.

On each OpenVMS node in a VMScluster, one sets two
values in SYSGEN: VOTES, and EXPECTED_VOTES. The
former is how many votes the node contributes to the
VMScluster. The latter is the total number of votes
expected when the full VMScluster is bootstrapped.

Some sites erroneously attempt to set EXPECTED_VOTES
too low, believing that this will allow when only a
subset of voting nodes are present in a VMScluster. It
does not. Further, an erroneous setting in EXPECTED_
VOTES is automatically corrected once VMScluster
connections to other nodes are established; user data
is at risk of severe corruptions during the earliest
and most vulnerable portion of the system bootstrap,
before the connections have been established.

One can operate a VMScluster with one, two, or many
voting nodes. With any but the two-node configuration,
keeping a subset of the nodes active when some nodes
fail can be easily configured. With the two-node
configuration, one must use a primary-secondary
configuration (where the primary has all the votes), a
peer configuration (where when either node is down, the
other hangs), or (preferable) a shared quorum disk.

15-16

Information on Networks and Clusters

Use of a quorum disk does slow down VMScluster
transitions somewhat - the addition of a third
voting node that contributes the vote(s) that would
be assigned to the quorum disk makes for faster
transitions-but the use of a quorum disk does mean
that either node in a two-node VMScluster configuration
can operate when the other node is down.

If you choose to use a quoum disk, a QUORUM.DAT file
will be automatically created when OpenVMS first
boots and when a quorum disk is specified - well, the
QUORUM.DAT file will be created when OpenVMS is booted
without also needing the votes from the quorum disk.

In a two-node VMScluster with a shared storage
interconnect, typically each node has one vote, and
the quorum disk also has one vote. EXPECTED_VOTES is
set to three.

Using a quorum disk on a non-shared interconnect is
unnecessary-the use of a quorum disk does not provide
any value, and the votes assigned to the quorum disk
should be assigned to the OpenVMS host serving access
to the disk.

For information on quorum hangs, see the OpenVMS
documentation. For information on changing the
EXPECTED_VOTES value on a running system, see the
SET CLUSTER/EXPECTED_VOTES command, and see the
documentation for the AMDS and Availability Manager
tools. Also of potential interest is the OpenVMS
system console documentation for the processor-specific
console commands used to trigger the IPC (Interrrupt
Priority Level %x0C; IPL C) handler. AMDS, Availability
Manager, and the IPC handler can each be used to clear
a quorum hang. Use of AMDS and Availability Manager is
generally recommended over IPC, particularly because
IPC can cause CLUEXIT bugchecks if the system should
remain halted beyond the cluster sanity timer limits.

The quorum scheme is a set of "blade guards"
deliberately implemented by OpenVMS Engineering to
provide data integrity-remove these blade guards at
your peril. OpenVMS Engineering did not implement
the quorum mechanism to make a system manager's life

15-17

Information on Networks and Clusters

more difficult- the quorum mechanism was specifically
implemented to keep your data from getting scrambled.

_____________________________
15.6.2.2 Explain disk (or tape) allocation class settings?

The allocation class mechanism provides the system
manager with a way to configure and resolve served and
direct paths to storage devices within a cluster. Any
served device that provides multiple paths should be
configured using a non-zero allocation class, either
at the MSCP (or TMSCP) storage controllers, at the
port (for port allocation classes), or at the OpenVMS
MSCP (or TMSCP) server. All controllers or servers
providing a path to the same device should have the
same allocation class (at the port, controller, or
server level).

Each disk (or tape) unit number used within a non-
zero disk (or tape) allocation class must be unique,
regardless of the particular device prefix. For the
purposes of multi-path device path determination, any
disk (or tape) device with the same unit number and the
same disk (or tape) allocation class configuration is
assumed to be the same device.

If you are reconfiguring disk device allocation
classes, you will want to avoid the use of allocation
class one ($1$) until/unless you have Fibre Channel
storage configured. (Fibre Channel storage specifically
requires the use of allocation class $1$. eg:
$1$DGA0:.)

_____________________________
15.6.2.2.1 How to configure allocation classes and Multi-Path
SCSI?

The HSZ allocation class is applied to devices,
starting with OpenVMS V7.2. It is considered a port
allocation class (PAC), and all device names with a PAC
have their controller letter forced to "A". (You might
infer from the the text in the "Guidelines for OpenVMS
Cluster Configurations" that this is something you have
to do, though OpenVMS will thoughtfully handle this
renaming for you.)

15-18

Information on Networks and Clusters

You can force the device names back to DKB by setting
the HSZ allocation class to zero, and setting the PKB
PAC to -1. This will use the host allocation class, and
will leave the controller letter alone (that is, the
DK controller letter will be the same as the SCSI port
(PK) controller). Note that this won't work if the HSZ
is configured in multibus failover mode. In this case,
OpenVMS requires that you use an allocation class for
the HSZ.

When your configuration gets even moderately complex,
you must pay careful attention to how you assign
the three kinds of allocation class: node, port and
HSZ/HSJ, as otherwise you could wind up with device
naming conflicts that can be painful to resolve.

The display-able path information is for SCSI
multi-path, and permits the multi-path software to
distinguish between different paths to the same device.
If you have two paths to $1$DKA100, for example by
having two KZPBA controllers and two SCSI buses to the
HSZ, you would have two UCBs in a multi-path set. The
path information is used by the multi-path software to
distinguish between these two UCBs.

The displayable path information describes the path;
in this case, the SCSI port. If port is PKB, that's
the path name you get. The device name is no longer
completely tied to the port name; the device name now
depends on the various allocation class settings of the
controller, SCSI port or node.

The reason the device name's controller letter is
forced to "A" when you use PACs is because a shared
SCSI bus may be configured via different ports on the
various nodes connected to the bus. The port may be PKB
on one node, and PKC on the other. Rather obviously,
you will want to have the shared devices use the same
device names on all nodes. To establish this, you
will assign the same PAC on each node, and OpenVMS
will force the controller letter to be the same on
each node. Simply choosing "A" was easier and more
deterministic than negotiating the controller letter
between the nodes, and also parallels the solution used

15-19

Information on Networks and Clusters

for this situation when DSSI or SDI/STI storage was
used.

To enable port allocation classes, see the SYSBOOT
command SET/BOOT, and see the DEVICE_NAMING system
parameter.

This information is also described in the Cluster
Systems and Guidelines for OpenVMS Cluster
Configurations manuals.

_____________________________
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

15-20

Information on Networks and Clusters

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

15-21

Information on Networks and Clusters

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?

o http://www.openvms.compaq.com/openvms/fibre/index.html

_____________________________
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?

15-22

Information on Networks and Clusters

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:

15-23

Information on Networks and Clusters

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.

o http://www.openvms.compaq.com/wizard/

o http://www.openvms.compaq.com/wizard/wizard.zip

For additional information, 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.

15-24

Information on Networks and Clusters

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.

_____________________________
15.6.7.2 Volume Shadowing MiniCopy vs MiniMerge?

MiniMerge support has been available for many years
with OpenVMS host-based volume shadowing, so long as
you had MSCP controllers (eg: HSC, HSJ, or HSD) which
supported the Volume Shadowing Assist called "Write
History Logging".

If you want minimerges on HSG80 (Fibre Channel)
controllers, please see the "Fibre Channel in a
Disaster-Tolerant OpenVMS Cluster System" whitepaper
at:

o http://www.openvms.compaq.com/openvms/fibre/fc_hbvs_
dtc_wp.pdf

Minimerge support on HSG80 is expected to require ACS
8.7 and OpenVMS Alpha V7.3-1, assuming the development
goes according to plan.

15-25

Information on Networks and Clusters

The following sections describe both MiniCopy and
MiniMerge, and can provide a basis for discussions.

_____________________________
15.6.7.2.1 MiniCopy?

A Shadowing Full Copy occurs when you add a disk to an
existing shadowset using a MOUNT command; the entire
contents of the disk are effectively copied to the
new member (using an algorithm that goes through in
127-block increments and reads one member, compares
with the target disk, and if the data differs, writes
the data to the target disk and loops back to the
read step, until the data is equal for that 127-
block section). (This is one of the reasons why the
traditional recommendation for adding new volumes to
a shadowset was to use a BACKUP/PHYSICAL copy of an
existing shadowset volume, simply because the reads
then usually matched and thus shadowing usually avoided
the need for the writes.)

If you warn OpenVMS ahead of time (at dismount time)
that you're planning to remove a disk from a shadowset
but re-add it later, OpenVMS will keep a bitmap
tracking what areas of the disk have been modified
while the disk was out of the shadowset, and when you
re-add it later with a MOUNT command OpenVMS only has
to update the areas of the returned disk that the bit-
map indicates are now out-of-date. OpenVMS does this
with a read source / write target algorithm, which is
much faster than the shenanigans the Full Copy does,
so even if all of the disk has changed, a MiniCopy is
faster than a Full Copy.

_____________________________
15.6.7.2.2 MiniMerge?

A Shadowing Merge is initiated when an OpenVMS node
in the cluster (which had a shadowset mounted) crashes
or otherwise leaves unexpectedly, without dismounting
the shadowset first. In this case, OpenVMS must ensure
that the data is identical, since Shadowing guarantees
that the data on the disks in a shadowset will be
identical. In a regular Merge operation, Shadowing uses

15-26

Information on Networks and Clusters

an algorithm similar to the Full Copy algorithm (except
that it can choose either of the members' contents
as the source data, since both are considered equally
valid), and scans the entire disk. Also, to make things
worse, for any read operations in the area ahead of
what has been merged, Shadowing will first merge the
area containing the read data, then allow the read to
occur.

A Merge can be very time-consuming and very I/O
intensive, so some controllers have Shadowing Assists
to make it faster. If the controllers support Write
History Logging, the controllers record the areas
(LBNs) that are the subject of Shadowing writes, and
if a node crashes, the surviving nodes can query the
controllers to find out what exact areas of the disk
the departed node was writing to just before the crash,
and thus Shadowing only needs to merge just those few
areas, so this tends to take seconds as opposed to
hours for a regular Merge.

15-27

---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com