HP OpenVMS Systems Documentation

Content starts here

The OpenVMS Frequently Asked Questions (FAQ)


Previous Contents Index

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

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. See Section 9.7 for related details on 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).

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.


Chapter 15
Information on Networks and Clusters

If you are searching for something here, please consider using the text-format FAQ.

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

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 (ATW) 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.8.

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

  • DECdns: DECnet-Plus distributed name services.
  • LocalFile: a local file containing names and addresses.
  • DNS/BIND: the TCP/IP distributed name services mechanism.
  • 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.3.4 How to flush the DECnet-Plus session cache?


$ RUN SYS$SYSTEM:NCL
FLUSH SESSION CONTROL NAMING CACHE ENTRY "*"

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.

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.

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:

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

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.

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.

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.


Previous Next Contents Index