Looking for connector wiring pinouts?

DECconnect DEC-423 MMJ pinout:
Note: MMJ #6 is keyed
  1. Data Terminal Ready (DTR)
  2. Transmit (TXD)
  3. Transmit Ground (TXD-)
  4. Receive Ground (RXD-)
  5. Receive (RXD)
  6. Data Set Ready (DSR)

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 (older) standard pinout, and uses the following EIA-232-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.

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

The BC16-E-nn cross-over wiring looks like this:

Host MMJ
DTR 1 --->-------->--- 6 DSR
TXD 2 --->-------->--- 5 RXD
3 ---------------- 4
4 ---------------- 3
RXD 5 ---<--------<--- 2 TXD
DSR 6 ---<--------<--- 1 DTR
Also see:
For adapters and connectors, see MISC4.

					[Stephen Hoffman]
                                        [Mike Thompson]


Where can I find information on escape and control sequences?

Information on escape and control sequences can be found in the OpenVMS I/O User's Reference Manual, in the section on the terminal driver.
This section includes details on the general format and content of these sequences.

Specific details on the escape and control sequences supported by a particular serial device are typically found in the documentation provided with the specific device. Information on the sequences supported by DECwindows DECterm terminal emulator are included in the DECwindows documentation.

Examples of common escape and control sequences - those typically used by the OpenVMS screen management package - can be found in the OpenVMS system file SYS$SYSTEM:SMGTERMS.TXT.

The following refers to the function keys on the VTxxx series terminals, and compatibles.
In the following, <CSI> is decimal code 155 and can be replaced by the sequence "<ESC>[" (without the quotes), <SS3> is decimal code 143 and can be replaced by "<ESC>O", particularly for seven-bit operations. Older VT1xx terminals and any other terminals operating with seven-bit characters should not be sent eight-bit operators such as <CSI> and <SS3>.

PF1=<SS3>P PF2=<SS3>Q PF3=<SS3>R PF4=<SS3>S
KP0=<SS3>p KP1=<SS3>q KP2=<SS3>r KP3=<SS3>s
KP4=<SS3>t KP5=<SS3>u KP6=<SS3>v KP7=<SS3>w
KP8=<SS3>x KP9=<SS3>y
F6=<CSI>17~ F7=<CSI>18~ F8=<CSI>19~
F9=<CSI>20~ F10=<CSI>21~ F11=<CSI>23~
F12=<CSI>24~ F13=<CSI>25~ F14=<CSI>26~
HELP=<CSI>28~ DO=<CSI>29~
F17=<CSI>31~ F18=<CSI>32~ F19=<CSI>33~ F20=<CSI>34~

These and other control sequences can be found in SYS$SYSTEM:SMGTERMS.TXT


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

Older DIGITAL keyboards (with RJ modular jacks), older DIGITAL mice (with 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 standards, and are neither interchangable nor compatible with typical PC peripheral device controllers. LK201, LK401, VSXXX, VR260, VR290, etc., are incompatible with most PC systems.

Newer DIGITAL keyboards (with DIN plugs), newer DIGITAL mice (with PC-pin DIN plugs), 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, LK471, PC7XS-CA, VRC16, VRC21, etc., are compatible with most PC systems.

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 more recent system, it will probably work with a PC peripheral controller. 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.

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.

                                        [Steve Hoffman]

Software Integrators sells a video adapter card called Gemini P1 which will drive many of the older Digital fixed-frequency monitors on a PC.



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) and the H8571-D for use with DECconnect.

More recent DIGITAL and Compaq systems will use either the DECconnect MMJ wiring or (more common on recent systems) the PC-compatible DB9 pinout.

DECconnect MMJ adapters:

Part: Converts BC16E MMJ male to fit into:
H8575-A EIA232 25 pin female (common)
H8575-B EIA232 9 pin male (MicroVAX II console)
H8571-D EIA232 25 pin male (modem-wired)
H8571-J PC/AT 9 pin male (PC serial port)
H8572-0 0BC16E MMJ male (MMJ extender)
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).
Also see:

For wiring and pinouts, see MISC1

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.

					[Stephen Hoffman]
                                        [Eric Dittman]


Where can I find performance info and specs for older systems?



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

The destination node is running DECnet-Plus, and its naming service cannot locate a name to assocate with the source node's address. In other words, the destination node cannot determine the name of the source node.

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 source node namespace, 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:

    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:

                                        [Steve Hoffman]


How to determine the network hardware address?

Most Alpha and 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.

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

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



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

    $ TCPIP SHOW INTERFACE/FULL  ! TCP/IP versions V5.0 and later
A program can be created to display the hardware address, reading the necessary information from the network device drivers. An example C program for reading the Ethernet hardware address (via sys$qio calls to the network device driver(s)) is available at the following URL:
To use the DECnet Phase IV configurator tool to watch for MOP SYSID activity on the local area network:
Let the DECnet configurator run for at least 20 minutes. Then issue the following commands:
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.


Why does my system halt when I powercycle 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.

                                               [Stephen Hoffman]


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

OpenVMS Alpha 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.
                                               [Stephen Hoffman]


Which video monitor works with which graphics controller?

To determine the answer to the will this monitor 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 monitor and 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.

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:

Also see MISC3.


Where can I get information on storage hardware?

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


Does DECprint (DCPS) work with the LRA0 parallel port?

The parallel printing port LRA0: found on many OpenVMS Alpha systems is capable of some bidirectional communications, with enough for basic operations with most parallel printers.

DECprint (DCPS) requires more than just the simple handshaking provided by the LRA0: port, therefore DCPS does not work with the LRA0: port.

                                     [Paul Anderson]


How do I check for free space on a (BACKUP) tape?

You cannot know for certain, though you can certainly estimate the remaining capacity.

Tape media is different than disk media, as disks have a known and pre-determined fixed capacity. Modern disks also appear logically perfect, based on bad block revectoring support and the extra blocks hidden within the disk structure for these bad block replacements.

The capacity of tape media is not nearly as pre-determined, and the capacity can vary across different tape media (slightly different media lengths or different foil markers or other variations, for instance) and even on the same media over time (as bad spots in the media arise). Tapes can vary the amount of recording media required, depending on the remaining length of the tape, the numbers of correctable and uncorrectable media errors that might occur, the numbers and sizes of the inter-record gaps and related tape structure overhead, the particular media error recovery chosen, the tape density, the efficiently of any data compression in use, and the storage overhead required by BACKUP, tar, and other similar commands.

Next Back