The OpenVMS Frequently Asked Questions(FAQ)


Previous Contents Index

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


The DECconnect DEC-423 Modified Modular Jack (MMJ) pinout: 
 
  1: Data Terminal Ready (DTR) 
  2: Transmit (TXD) 
  3: Transmit Ground (TXD-) 
  4: Receive Ground (RXD-) 
  5: Receive (RXD) 
  6: Data Set Ready (DSR) 
 
   +------------------+ 
   | 1  2  3  4  5  6 | 
   +------------+    ++ 
                +____+ 
 

The PC-compatible DB9 connector pinout follows:


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

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


  1: Protective Ground 
  2: Transmited Data 
  3: Received Data 
  4: Request To Send (RTS) 
  5: Data Terminal Ready (DTR) 
  6: Data Set Ready (DSR) 
  7: Signal Ground 
  8: Shorted to pin 9 on MicroVAX and VAXstation 2000... 
  9:    ...series systems, otherwise left floating. 
 
  When pin 8 is shorted to pin 9, this is a BCC08 (or variant) cable, 
  most commonly used as a console cable on the MicroVAX 2000 and 
  VAXstation 2000 series.  (Other systems may or may not tolerate 
  connecting pin 8 to pin 9.) 

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


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

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


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

The BN24H looks like this:


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

The BN24J looks like this:


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

Also see:

14.28 What connectors and wiring adapters are available?

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

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

DECconnect MMJ adapters:


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

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

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

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

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

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

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 well-configured DECnet generally avoids triggering any underlying (out-of-band) flow control mechanism.)

14.30 CD-R and DVD device requirements?

Read and write access to CD-ROM, CD-R and CD-RW devices on ATA (IDE) is generally handled transparently by SYS$DQDRIVER, and SYS$DQDRIVER will transparently block and 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 CD-ROM, CD-R and CD-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. SCSI drives with UNIX or 512-byte selectors will generally operate.

At least some of the Plextor PlexWriter SCSI drives can be accessed from OpenVMS, and 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 ATA (IDE) bus.

For some related information (and details on a commercial DVDwrite package), please see:

Recording of CD and DVD media requires an application, and both commercial and non-commercial options are available. Please see CDRECORD (both non-DVD and DVD versions are available, and a commercial version is available), and also see DVDwrite (commercial) or DVDRECORD (open source).

For information on the GKDRIVER (SYS$GKDRIVER) interface that is utilized by most CD and DVD recording tools to send commands to SCSI or ATAPI devices (most ATA devices can use SCSI-like command packets), please see SYS$EXAMPLES:GKTEST.C, and please see the various sections of the OpenVMS I/O User's Reference Manual.


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

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:

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.

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.

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. comment>(------------------------------------------------------------ )

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

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

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:

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 

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

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:

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.


Previous Next Contents Index