[Comp.Sci.Dept, Utrecht] Note from archiver<at>cs.uu.nl: This page is part of a big collection of Usenet postings, archived here for your convenience. For matters concerning the content of this page, please contact its author(s); use the source, if all else fails. For matters concerning the archive as a whole, please refer to the archive description or contact the archiver.

Subject: OpenVMS Frequently Asked Questions (FAQ), Part 10/11

This article was archived around: Sun, 04 Sep 2005 20:09:33 GMT

All FAQs in Directory: dec-faq/vms
All FAQs posted in: comp.os.vms, comp.sys.dec
Source: Usenet Version


Archive-name: dec-faq/vms/part10 Posting-Frequency: quarterly Last-modified: 02 Sep 2005 Version: VMSFAQ_20050902-10.TXT
Hardware Information of a new or replacement server. You may or may not have some success looking for this or of any other now-unavailable sites using the world-wide web archives at: o http://www.archive.org/ __________________________________________________________ 14.21 Why does my LK401 keyboard unexpectedly autorepeat? There are several modes of failure: o Pressing 2 and 3 keys at the same time causes one key to autorepeat when released. Check the hardware revision level printed on the bottom of the keyboard. If the revision level is C01, the keyboard firmware is broken. Call field service to replace the keyboard with any revision level other than C01. o Pressing certain keys is always broken. Typical symptoms are: delete always causes a autorepeat, return needs to be pressed twice, etc. This is frequently caused by having keys depressed while the keyboard is being initialized. Pressing ^F2 several times or unplugging and replugging the keyboard frequently fix this problem. (Ensure you have current ECO kits applied; there is a patch available to fix this problem.) o A key that was working spontaneously stops working correctly. This may be either of the two previous cases, or it may be bad console firmware. Ensure that you have the most recent firmware installed on your Alpha system. In particular, an old version of the DEC 3000 SRM firmware is known to have a bug that can cause this keyboard misbehaviour. 14-50 Hardware Information __________________________________________________________ 14.22 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.23 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-51 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=EWc: The "hardware version" will be displayed. To set the DE500 speed and duplex settings via the associated Alpha SRM console environment variable, see Table 14-4. ________________________________________________________________ Table 14-4 DE500 Speed and Duplex Settings ________________________________________________________________ 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 DEVICE EWA0/SPEED=10 LANCP> DEFINE DEVICE EWA0/SPEED=10 LANCP> SET DEVICE EWA0/SPEED=100/full_duplex LANCP> DEFINE DEVICE EWA0/SPEED=100/full_duplex 14-52 Hardware Information 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.24 How do I set the speed and duplex on OpenVMS I64? OpenVMS I64 on Integrity servers does not provide a console-level environment variable akin to the SRM console variables used to manage the network speed and duplex settings on OpenVMS Alpha and Alpha systems. On OpenVMS I64 on Integrity servers, LANCP is used to manage the speed and the duplex setting of the network controllers. $ RUN SYS$SYSTEM:LANCP LANCP> SET DEVICE EWA0/SPEED=10 LANCP> DEFINE DEVICE EWA0/SPEED=10 LANCP> SET DEVICE EWA0/SPEED=100/full_duplex LANCP> DEFINE DEVICE EWA0/SPEED=100/full_duplex The EFI-level network bootstrap operations for a network-based upgrade or a network-based installation of OpenVMS I64 require the use of autonegotiation and a switch capable of supporting it. See Section 14.23 for a related discussion. __________________________________________________________ 14.25 Third-party or Unsupported disk/tape/controllers/SCSI/widgets? A wide variety of third-party and formally-unsupported widgets-SCSI and ATA/ATAPI (IDE) disks and tapes, graphics controllers, etc-are obviously widely available, and are used on various platforms. 14-53 Hardware Information If you purchase third-party or unsupported or generic SCSI, ATA/ATAPI (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 HP 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/ATAPI (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/ATAPI (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/ATAPI (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. 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: 14-54 Hardware Information 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 shown indicates that the AWRE and ARRE bits are set, and this is incompatible with OpenVMS versions prior to V6.2. Further along in the same 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.) If the bits are set, you can use RZDISK from the OpenVMS Freeware, and can 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/ATAPI (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. 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/ATAPI (IDE) commands that are (hopefully) architecturally-compatible SCSI or ATA/ATAPI (IDE) command extensions. (Also see Section 7.1 and Section 9.7.) 14-55 Hardware Information Some SCSI tapes lack odd-byte transfer support, making operations with OpenVMS problematic at best, as OpenVMS expects odd-byte support. Examples of such include LTO-1 devices such as the HP Ultrium 230 series tape, and the DLT VS80 series tapes. Due to the lack of odd- byte transfer support, LTO-1 devices are not supported by OpenVMS. LTO devices in the LTO-2 and later series do reportedly presently all have odd-byte transfer support, and operations are reportedly rather easier. Do check for formal support, of course. 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.25.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 and the HP DVD200i series (recording CD-R) have also been successfully utilized with various AlphaStation and VAXstation 14-56 Hardware Information systems, and with tools such as CDRECORD. (A Plextor PlexWriter burn of 614400000 bytes (300000 sectors) requires just over six minutes at 12x, using an AlphaStation XP1000 666 MHz EV67 system UltraSCSI host.) (See Section 9.7 for detailed discussions of recording optical media on OpenVMS, and the available tools.) If you choose to attempt to use third-party devices, ensure that you have the most current OpenVMS version and the most current ECO kit(s) applied. In the specific case of the ATA (IDE) Iomega Zip250 drive, ensure that you have the most current revision of SYS$DQDRIVER installed. _____________________________ 14.25.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.25.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.25. __________________________________________________________ 14.26 Looking for connector wiring pin-outs? The DECconnect DEC-423 Modified Modular Jack (MMJ) appears similar to a telphone or network modular jac, though with the key offset to one side. The DECconnect MMJ connector pin-out is listed in Table 14-5, with an end-on view of the connector pins and the connector key shown below. ________________________________________________________________ Table 14-5 DEC MMJ Pin-out _______________________________________________________ Pin_____Description____________________________________ 1 Data Terminal Ready (DTR) 2 Transmit (TXD) 3 Transmit Ground (TXD-) 14-57 Hardware Information ________________________________________________________________ Table 14-5 (Cont.) DEC MMJ Pin-out _______________________________________________________ Pin_____Description____________________________________ 4 Receive Ground (RXD-) 5 Receive (RXD) _________6_______Data_Set_Ready_(DSR)___________________________ +------------------+ | 1 2 3 4 5 6 | +------------+ ++ +____+ The BC16E-nn (where the "-nn" indicates the cable length) cabling and keying "flips over" or "crosses- over" the signal wires, and this allows all DECconnect MMJ connections to be wired identically; the ends of the BC16E are symmetrical and fully interchangeable, and allows either end of the cable to be connected either to the terminal or to the host. Specifically, 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 DECconnect parts and connections are available from HP, and MMJ crimping dies for use in typical telco- style crimping tools, and MMJ connectors, are available from Blackbox and from other communications equipment vendors. The PC-compatible DB9 connector pin-out found on Alpha and Integrity COM serial ports-and on most PC systems is listed in Table 14-6. 14-58 Hardware Information ________________________________________________________________ Table 14-6 PC DB9 Pin-out _______________________________________________________ Pin_____Description____________________________________ 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 pin-out predates the PC-style DB9 pin-out (adapters discussed in Section 14.27), and uses a then-common (and older) standard pin-out, and uses the EIA-232 series standard signals shown in Table 14-7. ________________________________________________________________ Table 14-7 MicroVAX DB9 Pin-out _______________________________________________________ Pin_____Description____________________________________ 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.____ When pin 8 is shorted to pin 9, this is a BCC08 (or variant) cable, most commonly used as a console cable 14-59 Hardware Information on the MicroVAX 2000 and VAXstation 2000 series. (Other systems may or may not tolerate connecting pin 8 to pin 9.) The BN24H looks like this: MMJ RJ45 1---------8 2---------2 3---------1 4---------3 5---------6 6---------7 The BN24J looks like this: MMJ RJ45 1---------7 2---------6 3---------3 4---------1 5---------2 6---------8 Also see: o http://www.hp.com/go/openvms/wizard/ o http://www.airborn.com.au/rs232.html o http://www.stanq.com/cable.html o For adapters and connectors, see Section 14.27. __________________________________________________________ 14.27 What connectors and wiring adapters are available? The H8571-B and H8575-B convert the (non-2000-series) MicroVAX DB9 to the DECconnect DEC-423 Modified Modular Jack (MMJ) pin-out; to the MMJ DECconnect wiring system. The MicroVAX 2000 and VAXstation 2000 requires a BCC08 cable (which has the 8-9 short, see Section 14.26) and the H8571-C or the H8571-D DB25-to- MMJ adapter for use with DECconnect. (For a discussion of the console bulkhead on the MicroVAX II series and on other closely-related series systems, please see Section 14.3.3.4.) 14-60 Hardware Information Somewhat less ancient HP (HP, Compaq or DIGITAL logo) systems will use either the DECconnect MMJ wiring directly or-on most (all?) recent system designs- the PC-compatible DB9 9-pin pin-out; the PC-style COM serial port interface and connection. There are two DB9 9-pin pin-outs, that of the H8571- B and similar for the MicroVAX and other and older systems, and that of the H8571-J for the PC-style COM port, AlphaStation, Integrity, and other newer systems. The older MicroVAX DB9 and the PC-style DB9 pin-outs are not compatible. ________________________________________________________________ Table 14-8 DECconnect MMJ Connectors and Adapters _______________________________________________________ Part________Converts_BC16E_MMJ_male_to_fit_into________ H8571-A EIA232 DB25 25-pin female (common). Functionally similar to the H8575-A, though the H8575-A has better ESD shielding. H8571-B Older MicroVAX (other than the MicroVAX 2000) DB9 EIA232 serial port. Functionally similar to the H8575-B, though the H8575-B has better ESD shielding. Note: Cannot be used on a PC, Alpha nor Integrity DB9 9-pin connector. 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, Alpha, Integrity 9 pin (DB9) male (PC- style COM serial port) Note: Cannot be used on the older MicroVAX DB9 9-pin connector H8572-0 BC16E MMJ double-female (MMJ extender) H8575-A EIA232 DB25 25-pin female (common). Functionally similar to the H8571-A, though the H8575-A has better ESD shielding. 14-61 Hardware Information ________________________________________________________________ Table 14-8 (Cont.) DECconnect MMJ Connectors and Adapters _______________________________________________________ Part________Converts_BC16E_MMJ_male_to_fit_into________ H8575-B Older MicroVAX (other than the MicroVAX 2000) DB9 EIA232 serial port. Functionally similar to the H8571-B, though the H8575-B has better ESD shielding. Note: Cannot be used on a PC, Alpha nor Integrity DB9 9-pin connector H8575-D 25 Pin to MMJ with better ESD Protection H8575-D 25 Pin to MMJ with better and ESD Protection H8575-E 25 Pin Integrity rx2600 Management Processor (MP) port to MMJ, with ESD Protection H8577-AA 6 pin Female MMJ to 8 pin MJ BC16E-** MMJ cable with connectors, available in _____________________various_lengths____________________________ Numerous additional adapters and cables are available from the (now out of print) OPEN DECconnect Building Wiring Components and Applications Catalog, as well as descriptions of the above-listed parts. The DECconnect wiring system has insufficient signaling for modems, and particularly lacks support for modem control signals. The H8571-A and H8575-A are MMJ to DB25 (female) and other connector wiring diagrams and adapter-, cable- and pin-out-related discussions are available at: o http://www.hp.com/go/openvms/wizard/ Jameco has offered 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. The LK463 provides the classic OpenVMS keyboard and 14-62 Hardware Information keyboard layout on USB-based system configurations, including operations with the USB connection on specific Alpha systems (and specifically on those with supported USB connections) and on Integrity servers. For information on the Alpha console COM port(s) or on the VAX console port, please see Section 14.3. __________________________________________________________ 14.28 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. 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 14-63 Hardware Information 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 well-configured DECnet generally avoids triggering any underlying (out-of-band) flow control mechanism.) __________________________________________________________ 14.29 CD and DVD device requirements? Read access to DVD-ROM, DVD+R/RW, DVD-R/RW, CD-ROM, and CD-R/RW devices on ATAPI (IDE) connections is generally handled transparently by SYS$DQDRIVER, and SYS$DQDRIVER will transparently de-block the media-native 2048 byte disk blocks with the 512-byte blocks expected by OpenVMS and by native OpenVMS software. 14-64 Hardware Information Read access to DVD-ROM, DVD+R/RW, DVD-R/RW, CD-ROM, and CD-R/RW devices on SCSI is handled by DKDRIVER, though SYS$DKDRIVER will not transparently de-block the native 2048-byte disk blocks into the 512-byte blocks expected by OpenVMS. The drive or external software is expected to provide this de-blocking, thus either a 512-byte block capable drive (such as all RRD-series SCSI CD-ROM drives) is required, or host software is required for a 2048-byte block drive. Third-party SCSI drives with UNIX references in their support documentation or with explicit 512-byte selectors or swiches will generally (but not always, of course) operate with OpenVMS. At least some of the Plextor PlexWriter SCSI drives can be successfully accessed (for read and write) from OpenVMS, as can at least one Pioneer SCSI DVD drive (for CD media). The Pioneer SCSI DVD drive switches to 2048 byte blocks for DVD media, and a block-size conversion tool (written by Glenn Everhart) or other similar tool can be applied. OpenVMS also has supported HP DVD drives for the ATAPI (IDE) bus. For some related information (and details on a commercial DVDwrite package), please see: o http://home.tiscali.de/dvd4openvms/supported_ hardware.html No device driver currently presently permits direct block-oriented recording on DVD-RAM nor DVD+RW media, nor other recordable or rewritable media. Recording (writing) of CD and DVD optical media requires a recording or media mastering application or tool, and both commercial and non-commercial options are available. See Section 9.7 for related details on CDRECORD (both non-DVD and DVD versions are available, and at least one commercial version is available), and also see DVDwrite (commercial) or DVDRECORD (open source). 14-65 Hardware Information For information on the GKDRIVER (SYS$GKDRIVER) generic SCSI device driver and of the the IO$_DIAGNOSE $qio[w] interfaces (of SYS$DKDRIVER, SYS$DNDRIVER and SYS$DQDRIVER) that are utilized by most CD and DVD recording tools to send commands to SCSI, USB or ATAPI devices (most USB and ATA devices-or more correctly, most ATAPI devices-can use SCSI-like command packets), please see the SYS$EXAMPLES:GKTEST.C example, and see DECW$EXAMPLES:DECW$CDPLAYER.C example and please see the various associated sections of the OpenVMS I/O User's Reference Manual. For information on creating bootable optical media on OpenVMS, please see Section 9.7.3. 14-66 _______________________________________________________ 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.hp.com/go/openvms/wizard/ 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.8. __________________________________________________________ 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 (ATW) area topics- starting with topic (1020)-for additional information on IP-based network printing. o http://www.hp.com/go/openvms/wizard/ 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.8. Please see Section 15.2.3 for information on Postscript printing. _____________________________ 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.hp.com/go/openvms/wizard/ 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.8. 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.3.4 How to flush the DECnet-Plus session cache? $ RUN SYS$SYSTEM:NCL FLUSH SESSION CONTROL NAMING CACHE ENTRY "*" __________________________________________________________ 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. 15-6 Information on Networks and Clusters 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. 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 15-7 Information on Networks and Clusters 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. 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. A complete example C program for reading the Ethernet or IEEE 802.3 network controller hardware address (via sys$qio calls to the OpenVMS network device driver(s)) is available at the following URL: o http://www.hp.com/go/openvms/wizard/ 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 15-8 Information on Networks and Clusters 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 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. 15-9 Information on Networks and Clusters 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 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-10 Information on Networks and Clusters __________________________________________________________ 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. 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-11 Information on Networks and Clusters _____________________________ 15.6.1 OpenVMS Cluster Communications Protocol Details? The following sections contain information on the OpenVMS System Communications Services (SCS) Protocol. Cluster terminology is available in Section 15.6.1.2.1. _____________________________ 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 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-12 Information on Networks and Clusters _____________________________ 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. 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 15-13 Information on Networks and Clusters 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.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. Prior to enhancements found in V7.3-1 and later, the load class is static and 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). With V7.3-1 and later, the load class values are dynamic. 15-14 Information on Networks and Clusters 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. In addition to the load class mechanisms, you can also use the "preferred path" mechanisms of MSCP and TMSCP services. This allows you to control the SCS connections used for serving remote disk and tape storage. The preferred path mechanism is most commonly used to explicitly spread cluster I/O activity over hosts and/or storage controllers serving disk or tape storage in parallel. This can be particularly useful if your hosts or storage controllers individually lack the necessary I/O bandwidth for the current I/O load, and must thus aggregate bandwidth to serve the cluster I/O load. For related tools, see various utilities including LAVC$STOP_BUS and LAVC$START_BUS, and see DCL commands including SET PREFERRED_PATH. _____________________________ 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 15-15 Information on Networks and Clusters 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.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. 15-16 Information on Networks and Clusters 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. 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. Note The quorum disk must be on a non-host-based shadowed disk, though it can be protected with controller-based RAID. Because host-based volume shadowing depends on the lock manager and the lock manager depends on the connection manager and the connection manager depends on quorum, it is not technically feasible (nor even particularly reliable) to permit host-based volume shadowing to protect the quorum disk. 15-17 Information on Networks and Clusters 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. (IPC is not available on OpenVMS I64 V8.2.) 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, and because some Alpha consoles and most (all?) Integrity consoles do not permit a restart after a halt. 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 more difficult- the quorum mechanism was specifically implemented to keep your data from getting scrambled. 15-18 Information on Networks and Clusters _____________________________ 15.6.2.1.1 Why no shadowing for a Quorum Disk? Stated simply, Host-Based Volume Shadowing uses the Distributed Lock Manager (DLM) to coordinate changes to membership of a shadowset (e.g. removing a member). The DLM depends in turn on the Connection Manager enforcing the Quorum Scheme and deciding which node(s) (and quorum disk) are participating in the cluster, and telling the DLM when it needs to do things like a lock database rebuild operation. So you can't introduce a dependency of the Connection Manager on Shadowing to try to pick proper shadowset member(s) to use as the Quorum Disk when Shadowing itself is using the DLM and thus indirectly depending on the Connection Manager to keep the cluster membership straight-it's a circular dependency. So in practice, folks simply depend on controller- based mirroring (or controller-based RAID) to protect the Quorum Disk against disk failures (and dual- redundant controllers to protect against most cases of controller and interconnect failures). Since this disk unit appears to be a single disk up at the VMS level, there's no chance of ambiguity. _____________________________ 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 15-19 Information on Networks and Clusters 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.) 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 15-20 Information on Networks and Clusters 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 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: 15-21 Information on Networks and Clusters 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.7. 15-22 Information on Networks and Clusters _____________________________ 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 15-23 ---------------------------- #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