 





                   Hardware Information



          __________________________________________________________
          14.16  What are the VAX processor (CPU) codes?

                      CPU:    Platform:
                      -----   ---------
                      KA41-A : MicroVAX 3100 Model 10 and 20
                      KA41-B : VAXserver 3100 Model 10 and 20
                      KA41-C : InfoServer
                      KA41-D : MicroVAX 3100 Model 10e and 20e
                      KA41-E : VAXserver 3100 Model 10e and 20e
                      KA42-A : VAXstation 3100 Model 30 and 40
                      KA42-B : VAXstation 3100 Model 38 and 48
                      KA43-A : VAXstation 3100 Model 76
                      KA45   : MicroVAX 3100 Model 30 and 40
                      KA46   : VAXstation 4000 Model 60
                      KA47   : MicroVAX 3100 Model 80
                      KA48   : VAXstation 4000 VLC
                      KA49-A : VAXstation 4000 Model 90/90A
                      KA49-B : VAXstation 4000 Model 95
                      KA49-C : VAXstation 4000 Model 96
                      KA50   : MicroVAX 3100 Model 90
                      KA51   : MicroVAX 3100 Model 95
                      KA52   : VAX 4000 Model 100
                      KA53   : VAX 4000 Model 105
                      KA54   : VAX 4000 Model 106
                      KA55   : MicroVAX 3100 Model 85
                      KA56   : MicroVAX 3100 Model 96
                      KA57   : VAX 4000 Model 108
                      KA58   : MicroVAX 3100 Model 88
                      KA59   : MicroVAX 3100 Model 98
                      KA85   : VAX 8500
                      KA86   : VAX 8600
                      KA88   : VAX 8800
                      KA600  : VAX 4000-50 (aka VAXbrick)
                      KA610  : MicroVAX I, VAXstation I (aka KD32)
                      KA620  : rtVAX (VAXeln)
                      KA62A  : VAX 6000-200
                      KA62B  : VAX 6000-300
                      KA630  : MicroVAX II, VAXstation II
                      KA640  : MicroVAX 3300, MicroVAX 3400
                      KA650  : VAXstation 3200, MicroVAX 3500, MicroVAX 3600, MicroVAX III
                      KA64A  : VAX 6000-400
                      KA655  : MicroVAX 3800, MicroVAX 3900, MicroVAX III+
                      KA65A  : VAX 6000-500

                   14-38

 





                   Hardware Information




                      KA660  : VAX 4000-200, VAX 4 upgrade
                      KA66A  : VAX 6000-600
                      KA670  : VAX 4000-300
                      KA675  : VAX 4000-400
                      KA680  : VAX 4000-500
                      KA681  : VAX 4000-500A
                      KA690  : VAX 4000-600
                      KA691  : VAX 4000-605A
                      KA692  : VAX 4000-700A
                      KA693  : VAX 4000-605A
                      KA694  : VAX 4000-705A
                      KA730  : VAX-11/730
                      KA750  : VAX-11/750
                      KA780  : VAX-11/780, VAX-11/782
                      KA785  : VAX-11/785
                      KA7AA  : VAX 7000-600
                      KA7AB  : VAX 7000-700
                      KA7AC  : VAX 7000-800
                      KA800  : VAXrta
                      KA820  : VAX 8200, VAX 8300
                      KA825  : VAX 8250, VAX 8350
                      KA865  : VAX 8650

          __________________________________________________________
          14.17  Where can I get software and hardware support
                 information?

                   Please contact the HP Customer Support Center. Services
                   and information, manuals, guides, downloads, and
                   various other information is available via the support
                   link at:

                   o  http://www.hp.com/products/openvms/

                   Various hardware and system documentation is available
                   at:

                   o  http://www.compaq.com/support/techpubs/user_
                      reference_guides/

                   o  http://www.adenzel.demon.nl/vaxes/microvax3100/

                   o  http://www.adenzel.demon.nl/vaxes/infoserver150/

                                                                     14-39

 





                   Hardware Information




                   TSM (Terminal Server Manager), DEChub, DECserver, etc.
                   information:

                   o  http://www.compaq.com/support/digital_networks_
                      archive/

                   The owner and maintainer of current DECserver and
                   related hardware is DIGITAL Network Products Group
                   (DNPG):

                   o  http://www.dnpg.com/

          __________________________________________________________
          14.18  Where can I get hardware self-maintenance support
                 assistance?

                   The HP Parts Directory and the HP Parts Reference
                   Guide (arguably the most direct descendents of the
                   HP Assisted Services program, of the Compaq Assisted
                   Services program, and of the now-ancient DECmailer
                   program) are available to customers that wish to
                   maintain their own system(s) (self-maintenance),
                   but that wish some level of assistance in acquiring
                   specific parts, hardware diagnostics and hardware
                   manuals for the system(s), and that wish to have
                   access to spares and module-level repairs for customer-
                   performed hardware module swaps:

                   o  http://www.hp.com/go/parts/

                   o  http://www.hp.com/buy/parts/

                   The HP Parts Reference Guide replaces the CAS-Catalog
                   and DAS-Catalog parts catalogs and related resources.

                   Details of the available self-maintenance programs and
                   services can vary by geography and by the particular
                   services channel(s), and current program specifics are
                   available via the above URLs.





                   14-40

 





                   Hardware Information



          __________________________________________________________
          14.19  Why does my system halt when I power-cycle the console
                 terminal?

                   Various VAX and Alpha consoles are designed to process
                   the BREAK signal, treating it as a HALT request.

                   A BREAK is a deliberately-generated serial line framing
                   error.

                   When a serial line device such as a terminal
                   powers up (or sometimes when powering down) it can
                   generate framing errors. These framing errors are
                   indistingushable from a BREAK signal.

                   When a BREAK is received on a serial line console
                   for various VAX systems-including most VAXstation,
                   MicroVAX, and VAX 4000 series-it is typically
                   interpreted as a HALT. Alpha systems will also often
                   process a BREAK in a similar fashion, halting the
                   system.

                   There is no uniform or generally-available way to
                   disable this behaviour on every VAX or Alpha system. On
                   some systems, BREAK processing can be disabled in favor
                   of [CTRL/P], or [CTRL/P] is the only way to halt the
                   processor.

                   The most common way to avoid these halts is to disable
                   the serial line console or to simply not power-cycle
                   the console terminal. There is certain important
                   system state information that is displayed only on
                   the console, OpenVMS expects to always have access to
                   the system console.

                   Also see Section 5.6.

          __________________________________________________________
          14.20  Can I reuse old keyboards, mice and monitors with a PC?

                   Older HP keyboards (those with the DIGITAL logo and
                   the RJ modular jacks), older HP mice (those with the
                   DIGITAL logo and with the RJ modular jacks, or with
                   a DIN connector with pins in a configuration other
                   than the PC-standard DIN connector pin orientation),
                   and older video monitors (with RGB synch-on-green
                   video signaling) all use signaling formats and/or
                   communications protocols that differ from the PC

                                                                     14-41

 





                   Hardware Information




                   standards, and are not (easily) interchangable nor
                   (easily) compatible with typical PC peripheral device
                   controllers. The LK201 and LK401 keyboards, the VSXXX
                   series mice, the VR260 and VR290 monitors, etc., are
                   incompatible with most PC systems and with most KVM
                   switches.

                   Newer HP (and Compaq) keyboards (those with with PC-
                   style DIN plugs, and the HP, Compaq or DIGITAL logo),
                   newer HP mice (with PC-pin DIN plugs, and the HP,
                   Compaq or DIGITAL logo), and newer video monitors
                   (multi-synch) are often interchangeable with "industry
                   standard" PC systems, and can often be used with
                   most PC peripheral device controllers. LK461, LK463,
                   LK46W, LK471, PC7XS-CA, VRC16, VRC21, TFT-series LCD
                   flat-panel displays, etc., are typically reasonably
                   compatible with most PC systems, and will usually
                   perform as expected within the limits of the hardware.
                   (For details of CRT and LCD display compatibility,
                   please see Section 14.21.)

                   Rule of thumb: if the peripheral device component
                   was sold for use with the DEC 2000 (DECpc 150 AXP),
                   an AlphaServer series, an AlphaStation series, or a
                   more recent Alpha system, it will probably work with a
                   PC peripheral controller or with a PC-compatible KVM
                   switch. If the peripheral device component was sold
                   for use with an VT420 or older terminal, most VAX, most
                   VAXstation, and most Alpha systems with names in the
                   format DEC [four-digit-number], it probably won't work
                   on a PC system or with a PC-compatible KVM.

                   Note that the above is a general guideline, and should
                   not be read to indicate that any particular peripheral
                   device will or will not work in any particular
                   configuration, save for those specific configurations
                   the device is explicitly supported in.

                   Software Integrators sells a video adapter card
                   called Gemini P1 which will drive many of the older
                   HP (DIGITAL-logo) fixed-frequency monitors on a PC
                   system:

                   o  http://www.si87.com/

                   14-42

 





                   Hardware Information




                   The DIGITAL (classic 2-5-2-style) part number 29-
                   32549-01 converts the output from the RGB cable (3 BNC,
                   synch-on-green) that comes with the VAXstation 3100 and
                   VAXstation 4000 series to a female SVGA D connector.
                   You may be able to find third-party converters or
                   adapters (3 BNCs with synch-on-green signaling to 5
                   BNCs with VGA/SVGA, or to 15-pin VGA/SVGA.

                   This adapter will allow PC multisync monitors with
                   the needed frequency specifications to be used with
                   the VAXstation series synch-on-green video connection.
                   It may well also work with a VAXstation 2000 series
                   systems, but specifics and performance of that
                   combination are not immediately known at this writing.

                   The protocol definition for the old DIGITAL keyboard
                   and mouse interfaces is buried at the back of the QDSS
                   section in the old VAXstation II manual, specifically,
                   in the back of the VCB02 Video Subsystem Technical
                   Manual (EK-104AA-TM). The keyboard wiring and protocol
                   is in appendix B, and occupies circa 44 pages. The
                   mouse is in appendix C, circa 12 pages.

                   Also see Section 14.21.

          __________________________________________________________
          14.21  Which video monitor works with which graphics controller?

                   To determine the answer to the "will this video monitor
                   or this LCD panel work with this graphics controller?"
                   question, please first locate the resolution(s) and the
                   frequencies that are possible/supported at both ends
                   of the video cable (on the display and on the graphics
                   controller, in other words), and then determine if
                   there are any matching settings available. If there are
                   multiple matches, you will need to determine which one
                   is most appropriate for your needs.

                   You will also need to determine if the video monitor or
                   graphics controller requires the 3 BNC signaling with
                   the synchronization signals on the green wire, or the 5
                   BNC signalling common on many PCs, or other connections
                   such as the DB15 video connector or USB connector used
                   on various systems.

                                                                     14-43

 





                   Hardware Information




                   If there are no matches, you will likely need to change
                   the hardware at one or both ends of the video cable.

                   The refresh frequencies for many devices have been
                   posted to comp.os.vms and/or other newsgroups. Search
                   the archives for details. Also see:

                   o  http://www.repairfaq.org/

                   o  http://www.mirage-mmc.com/faq/

                   o  http://www.geocities.com/SiliconValley/Foothills/4467/fixedsync.html

                   o  http://saturn.tlug.org/sunstuff/ffmonitor.html

                   o  http://hawks.ha.md.us/hardware/monitor.html

                   LCD-based and plasma-based flat-panel displays are
                   generally compatible with all recent OpenVMS Alpha
                   systems and supported graphics controllers. For
                   best results, you should generally set the graphics
                   controller to match the native LCD or plasma display
                   resolution and (for LCD displays) also set the
                   controller refresh rate to 60Hz. Check your graphics
                   controller and your display documentation for any
                   device-specific requirements and/or configuration
                   recommendations.

                   Also see Section 14.20.

          __________________________________________________________
          14.22  Where can I get information on storage hardware?

                   Information on various HP (Compaq, DIGITAL) OpenVMS
                   and other disk storage hardware and controllers, and
                   related technical information on SCSI, device jumpers,
                   etc., is available at:

                   o  http://theref.aquascape.com/

                                             Note

                      the aquascape website appears to have become
                      unavailable, and the FAQ maintainer is unaware
                      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:

                      14-44

 





                   Hardware Information




                      o  http://www.archive.org/

          __________________________________________________________
          14.23  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.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.

                                                                     14-45

 





                   Hardware Information




                   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

                   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



                   14-46

 





                   Hardware Information




                   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-47

 





                   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-48

 





                   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-49

 





                   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 and the HP DVD200i
                   series (recording CD-R) have also been successfully
                   utilized with various AlphaStation and VAXstation
                   systems, and with tools such as CDRECORD. (A Plextor

                   14-50

 





                   Hardware Information




                   PlexWriter burn of 614400000 bytes (300000 sectors)
                   requires just over six minutes at 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 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.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  Looking for connector wiring pin-outs?

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

                     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 pin-out found on Alpha
                   and Integrity COM serial ports follows:

                                                                     14-51

 





                   Hardware Information




                     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.28), and uses a then-common (and older)
                   standard pin-out, 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.

                     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 implicitly "flips over" (crosses-over) the
                   signal wires, so all DECconnect MMJ connectors are
                   wired the same.

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



                   14-52

 





                   Hardware Information




                   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:

                        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.28.

                                                                     14-53

 





                   Hardware Information



          __________________________________________________________
          14.28  What connectors and wiring adapters are available?

                   The H8571-B converts 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.27) and
                   the H8571-C or the H8571-D DB25-to-MMJ adapter for use
                   with DECconnect.

                   More recent 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.

                   DECconnect MMJ adapters:

                       Part:      Converts BC16E MMJ male to fit into:

                       H8571-B  Older MicroVAX (other than the MicroVAX 2000) DB9 EIA232 serial port
                         Note: Cannot be used on a PC/AT nor Alpha 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/AT, 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)
                       H8575-B  Older MicroVAX (other than the MicroVAX 2000) DB9 EIA232 serial port
                         Note: Cannot be used on a PC/AT nor Alpha DB9 9-pin connector
                       H8575-D  25 Pin to MMJ W/EOS and 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 _OPEN DECconnect Building Wiring Components
                   and Applications Catalog_, as well as descriptions of
                   the above-listed parts.

                   14-54

 





                   Hardware Information




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

                   Also see the adapter-, cable- and pin-out-related
                   discussions at:

                   o  http://www.hp.com/go/openvms/wizard/

                   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.
                   The LK463 provides a classic OpenVMS keyboard, on USB-
                   based system configurations.

                   For information on the Alpha console COM port or on the
                   VAX console port, please see Section 14.3.

          __________________________________________________________
          14.29  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-55

 





                   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-56

 





                   Hardware Information




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

          __________________________________________________________
          14.30  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.

                   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.

                                                                     14-57

 





                   Hardware Information




                   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. Please see 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). A port of
                   CDRECORD is present in OpenVMS V7.3-1 and later; see
                   SYS$MANAGER:CDRECORD.COM.

                   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-58

 










                   _______________________________________________________

          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.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.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.9.

                   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.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. 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

                   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

                   15-8

 





                   Information on Networks and Clusters




                   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.

                   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.

                                                                      15-9

 





                   Information on Networks and Clusters




                   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.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.

                   15-10

 





                   Information on Networks and Clusters




                   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.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.

                                                                     15-11

 





                   Information on Networks and Clusters




                   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.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.


                   15-12

 





                   Information on Networks and Clusters




                   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
                   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.

                                                                     15-13

 





                   Information on Networks and Clusters




                   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.

                   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

                   15-14

 





                   Information on Networks and Clusters




                   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
                   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-15

 





                   Information on Networks and Clusters



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

                   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

                   15-16

 





                   Information on Networks and Clusters




                   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.

                   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.


                                                                     15-17

 





                   Information on Networks and Clusters




                   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.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-18

 





                   Information on Networks and Clusters



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

                                                                     15-19

 





                   Information on Networks and Clusters




                   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:

                   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:

                   15-20

