| Previous | Contents | Index |
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
|
MMJ RJ45
1---------8
2---------2
3---------1
4---------3
5---------6
6---------7
|
MMJ RJ45
1---------7
2---------6
3---------3
4---------1
5---------2
6---------8
|
Also see:
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.
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:
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 |
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 |