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.

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.

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

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:

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.

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

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:

• http://www.hp.com/go/openvms/wizard/
• http://www.airborn.com.au/rs232.html
• http://www.stanq.com/cable.html
• For adapters and connectors, see Section 14.28.

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.

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:

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

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

• http://home.tiscali.de/dvd4openvms/supported_hardware.html

No device driver currently presently permits direct block-oriented recording on DVD-RAM nor DVD+RW media, nor other recordable or rewritable media.

Recording (writing) of CD and DVD optical media requires a recording or media mastering application or tool, and both commercial and non-commercial options are available. 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.