MISC1. Moved to WIRES1


MISC2.

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
KPCOMMA=<SS3>l KPMINUS=<SS3>m KPPERIOD=<SS3>n
ENTER=<SS3>M
DNARROW=<CSI>B UPARROW=<CSI>A LFARROW=<CSI>D RTARROW=<CSI>C
FIND=<CSI>1~ INSERT=<CSI>2~ REMOVE=<CSI>3~
SELECT=<CSI>4~ PREV=<CSI>5~ NEXT=<CSI>6~
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

An example of working with escape sequences (in DCL) follows: 

  $ esc5m = "*[5m"
  $ esc5m[0,8] = 27
  $ esc0m = "*[0m"
  $ esc0m[0,8] = 27
  $ write sys$output esc5m + "blinking text" + esc0m
Documentation on an ANSI terminal relatively similar to the VT525 series is available at: 
   ftp://ftp.boundless.com/pub/text/adds/docs/260_prog/
   ftp://ftp.boundless.com/pub/text/adds/docs/260_user/
Also see the various documentation and manuals available at: 
     http://www.vt100.net/
Information on the ReGIS graphics character set is available at: 
   
     http://www.cs.utk.edu/~shuford/terminal/dec_regis_news.txt
Also see DECW9, DCL12.


MISC3. Moved to SUPP4


MISC4. Moved to WIRES2


MISC5.

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

MISC5 relocated to ALPHA5 
    http://www.compaq.com/alphaserver/archive/index.html


MISC6.

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]


MISC7.

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: 
  >>> SHOW DEVICE
  >>> SHOW ETHER
  >>> 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. 

    $ MCR NCP SHOW KNOWN LINE CHARACTERISTICS    ! DECnet Phase IV

    $ MCR NCL SHOW CSMA-CD STATION * ALL STATUS  ! DECnet-Plus

    $ 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: 
    http://www.openvms.compaq.com/wizard/swdev/ethernVMS.html
To use the DECnet Phase IV configurator tool to watch for MOP SYSID activity on the local area network: 
  $ NCP SET MODULE CONFIGURATOR KNOWN CIRCUIT SURVEILLANCE ENABLED
Let the DECnet configurator run for at least 20 minutes. Then issue the following commands: 
  $ NCP SHOW MODULE CONFIGURATOR KNOWN CIRCUIT STATUS TO filename.txt
  $ NCP 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.


MISC8. Moved to SUPP4.


MISC9.

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]


MISC10. Moved to SUPP5


MISC11. Moved to SUPP6


MISC13.

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.

BACKUP using with the default settings results in approximately 15% overhead, in terms of saveset size. (eg: Assuming a 500 KB input, the total size would be 575 KB.)

NB: There are no inter-record gaps on DAT tapes. (When determining media capacity, you have to consider these with nine-track magtape media. Not with DAT (DDS). However, the block structure underneath the variable length record recording is based on a block size of circa 124 KB. Further, writing double filemarks etc. can cause a loss of up to the underlying block size. Thus even though there are no inter-record gaps on DAT, larger savesets are still usually best.

The compression algorithms used on various devices are generally not documented - further, there is no way to calculate the effective data compression ratio, the tape mark overhead, and similar given just the data to be stored on tape - short of actually trying it, of course.

A typical compression ratio found with "everyday" data is somewhere around 1:1.8 to 1:2.

NB: OpenVMS often uses the term COMPACTION for compression control, as in the qualifier /MEDIA_FORMAT=COMPACTION. 

                                          [Hoffman, Froehlin, Williams]


MISC14.

So what happened to sys$cmsuper?

There is no SYS$CMSUPR service.

The typical wisdom for getting into supervisor access mode (from user mode) is to execute a routine in executive mode (via a call to SYS$CMEXEC and the appropriate privilege) and then issue a SYS$DCLAST with the ASTADR parameter pointing to your routine entry point and the ACMODE parameter specified as PSL$C_SUPER.

Alternatively, you can reset mode in the call stack return path and unwind from executive or kernel out into supervisor mode. 


                                    [Brian Schenkenberger]


MISC15.

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

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 email directly to the pager.

See SOFT1 for information on the available catalog of products.


MISC16. Moved to WIRES3


MISC17.

How do I reset the LAN (DECnet-Plus NCL) counters?

On recent OpenVMS releases: 
  LANCP> SET DEVICE/DEVICE_SPECIFIC=FUNCTION="CCOU" devname


MISC18.

What are the prefixes for the powers of ten?

PowerPrefixAbbreviation
10-18attoa
10-15femtof
10-12picop
10-09nanon
10-06microµ
10-03millim
10-02centic
10-01decid
10+01decada
10+02hectoh
10+03kilok
10+06megaM
10+09gigaG
10+12teraT
10+15petaP
10+18exaE


MISC19.

OpenVMS Cluster (SCS) over DECnet? Over IP?

The OpenVMS Cluster environment operates over various network protocols, but the core of clustering uses the System Communications Services (SCS) protocols, and SCS-specific network datagrams. Direct (full) connectivity is assumed.

An OpenVMS Cluster DOES NOT operate over DECnet, nor over IP.

No SCS protocol routers are available.

Many folks have suggested operating SCS over DECnet or IP over the years, but SCS is too far down in the layers, and any such project would entail a major or complete rewrite of SCS and of the DECnet or IP drivers. Further, the current DECnet and IP implementations have large tracts of code that operate at the application level, while SCS must operate in the rather more primitive contexts of the system and particularly the bootstrap - to get SCS to operate over a DECnet or IP connection would require relocating major portions of the DECnet or IP stack into the kernel. (And it is not clear that the result would even meet the bandwidth and latency expectations.)

The usual approach for multi-site OpenVMS Cluster configurations involves FDDI, Memory Channel (MC2), or a point-to-point remote bridge, brouter, or switch. The connection must be transparent, and it must operate at 10 megabits per second or better (Ethernet speed), with latency characteristics similar to that of Ethernet or better. Various sites use FDDI, MC2, ATM, or point-to-point T3 link.


MISC20.

Correctly using license PAKs and LMF.

If you have multiple LMF$LICENSE.LDB databases in your OpenVMS Cluster, then each and every PAK must be installed in each and every license database present in an OpenVMS Cluster. Even if you use /EXCLUDE or /INCLUDE, you need to have a consistent set of PAKs registered across all licensing databases present in the OpenVMS Cluster.

If your software license permits it, you can use the following two commands to transfer license PAKs: 

    $ LICENSE COPY...
    $ LICENSE ISSUE/PROCEDURE/OUTPUT=file product,...
To display the particular license(s) required (such as when you receive a NOLICENSE error), use the following DCL sequence: 
    $ SET PROCESS/PRIVILEGE=ALL
    $ REPLY/ENABLE
    $ DEFINE/SYSTEM/EXECUTIVE LMF$DISPLAY_OPCOM_MESSAGE
This logical name will cause all license failures to generate OPCOM messages, and this will hopefully show which license(s) you need -- there may well also be additional license failures displayed, as various products can check for and can be enabled by multiple license PAKs. You will want to deassign this logical name when done.

Some of the more common license PAKs:

Various NET-APP-SUP (NAS) license packages are available, each with differing collections of products authorized. See the various NAS Software Product Description (SPD) documents for specific details. 
    http://www.compaq.com/info/spd/
To determine which license PAK is failing (via a license check failure OPCOM message), use the command: 
    $ DEFINE/SYSTEM/EXECUTIVE LMF$DISPLAY_OPCOM_MESSAGE TRUE
Realize that defining this logical name will cause license checks that are otherwise hidden (unimplemented, latent, or part of a check for any of a series of licenses) to become visible. In other words, expect to see some spurious license check calls when you define this.


MISC21.

Third-party disk/tape/controllers/SCSI/widgets on OpenVMS.

A wide variety of third-party widgets - SCSI and IDE disks and tapes, graphics controllers, etc - are available for various platforms.

If you purchase third-party "generic" SCSI or IDE storage devices, you and your device vendor will be responsible for the testing and the support of the devices. I would tend to 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 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 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 IDE, use OpenVMS V7.1-2 or later.

On older OpenVMS releases, see the disk capacity limits (FILE5.)

With SCSI disks on older releases, ensure that you have the ARRE and ARWE settings configured correctly (disabled). (If not, you will see DRVERR fatal drive errors.)

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 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 IDE commands that are (hopefully) architecturally-compatible SCSI or IDE command extensions. (Also see UTIL1 and FILE7.)

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, and on a variety of other platforms. (You might or might not see success booting OpenVMS on any of these platforms.) 

					[Stephen Hoffman]

Next Back