|
HP OpenVMS Systems Documentation |
|
The OpenVMS Frequently Asked Questions (FAQ)
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
|
$ 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 |
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.
15.3.4 How to flush the DECnet-Plus session cache?
$ RUN SYS$SYSTEM:NCL FLUSH SESSION CONTROL NAMING CACHE ENTRY "*" |
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 |
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 |