OpenVMS System Manager's Manual
184.108.40.206.1 Configuring ISA Devices on the ISA Bus
In previous versions of OpenVMS Alpha, ISA devices on an ISA bus
required an entry in the SYS$MANAGER:ISA_CONFIG.DAT file that defined
the hardware and the use of the console command ISACFG to reserve
system resources like IRQs.
Beginning with OpenVMS Alpha Version 7.2, the ISA_CONFIG.DAT file is no
longer supported. Refer to Section 8.5.4 for more information.
220.127.116.11.2 Configuring ISA Devices on the EISA Bus
ISA devices must be manually configured using the EISA Configuration
Utility (ECU) which is run from the console. Devices must have a CFG
file provided on a DOS floppy. The CFG file provides a string (up to 7
characters) as the device ID.
See your card manufacturer, or the EISA Bus Specification for details
on CFG file format.
The ECU floppy (DOS format) contains an example ISA CFG file
(ISA000.CFG) that may be used as a model for new configuration files.
For more information, refer to the EISA Bus Support chapter in
Writing OpenVMS Alpha Device Drivers in C.
Once the ECU has been run, the device can be configured using
ISA devices cannot be easily autoconfigured on EISA bus systems on
versions prior to OpenVMS Alpha Version 7.1 because the ID is not
copied from the ECU data into the OpenVMS bus structures.
8.5.4 SYS$MANAGER:ISA_CONFIG.DAT Unsupported
Support for using the SYS$MANAGER:ISA_CONFIG.DAT file to configure ISA
devices was discontinued in OpenVMS Alpha Version 7.2. If you use this
file, you should convert to using the ISACFG utility from the console
and the file-based autoconfiguration method described in the following
Table 8-2 contains a list of keywords from ISA_CONFIG.DAT and their
equivalents in either file-based autoconfiguration or the ISACFG
Table 8-2 ISA_CONFIG.DAT Keywords and Equivalents
Bit 1 (unsupported)
Bit 2 (FLAG=NOVECTOR)
An entry in ISA_CONFIG.DAT is matched to internal data kept for an ISA
device using the number specified with the NODE keyword. When you use
the SYS$USER_CONFIG.DAT file to configure an ISA device, however, the
ID keyword is used to match the block, which defines the device, to
data entered from the console with the ISACFG command. The value given
to the ID keyword must be the same as the value specified with the
Any identification string can be used for an ISA device. It should be
eight characters or less. The ISACFG command does not set the -handle
value to upper case, so two methods can be used to force the value to
match one specified using the configuration keyword ID. You can specify
the ID value in the correct case inside of quotation marks (matching
the case you used for the -handle value). Or you can use the
configuration keyword FLAGS=CASE_BLIND, which will cause a blind
comparison to be done.
For example, if you use the following in ISACFG:
>>>isacfg -slot 3 -dev 0 -mk -enadev 1 -type 1 -handle MyDevice
you can match that to the following entry in SYS$USER_CONFIG.DAT:
DEVICE = "My Device"
ID = MYDEVICE
FLAGS = CASE_BLIND
Descriptions of the conversion for each parameter in ISA_CONFIG.DAT are
NAME = xx
Use the NAME keyword in SYS$USER_CONFIG.DAT. Use the same value, where
xx is the device code. (The device code is usually 2 letters.)
Example: NAME = ER
DRIVER = driver_name
Use the DRIVER keyword in SYS$USER_CONFIG.DAT. Use the same value for
file-based autoconfiguration. driver_name is the name of the driver in
Example: DRIVER = SYS$ERDRIVER
IRQ = i
Use IRQx in the ISACFG utility. You can express four IRQs:
-IRQ0 through -IRQ3. Use the same value used for ISA_CONFIG.DAT. The
IRQ is a value from 0 to 15, which specifies which ISA IRQ the device
uses to report interrupts.
This example assigns IRQs 10 and 5 to the device.
>>>isacfg -slot 3 -dev 0 -mk -handle MYDEV -enadev 1 -etyp 1 -irq0 10 -irq1 5
NODE = n
Use -slot in the ISACFG utility. The slot number (n) does not represent
the slot in which the device resides. It is a logical, not a physical
number. However, the number must be between 1 and the maximum number of
slots on the machine. Slot number 0 is not available to users.
>>>isacfg -slot 3 -dev 0 -mk -enadev 1 -etyp 1 -handle MYDEV -dmachan0 1 -irq0 10
This example assigned values to a device represented by slot 3. There
must be at least 3 slots on the machine on which this command is
executed. To see which logical slots are being used, enter the
DMA = (j,k, ...)
Use -dmachanx in the ISACFG utility. Values j,k, and so on are
values 0 through 7, which specify the channels of the DMA controller
that the device is using to relay information. Use the same values for
j, k, and so on with ISACFG, but assign each one to a different DMA
channel. You can specify four DMA channels, using the keywords
-dmachan0 through -dmachan3.
>>>isacfg -slot 3 -dev 0 -mk -enadev 1 -etyp 1 -handle MYDEV -irq0 10 -dmachan0 1 -dmachan1 3
This example assigned two dma channels, 1 and 3, to the device.
PORT = (aa:b, cc:d, ... )
Use -iobasex in the ISACFG utility. You can specify six ports
using the keywords -iobase0 through -iobase5. There is no equivalent
for the length fields b, d etc. The ISACFG utility assumes
that the driver knows the length of the port. Drivers that called the
IOC$NODE_DATA routine with the keyword IOC$K_EISA_IO_PORT to obtain the
length in the upper word of the returned longword should stop examining
the upper word. With ISA_CONFIG.DAT, the length was returned; but with
ISACFG, the length is always 8.
>>>isacfg -slot 3 -dev 0 -mk -enadev 1 -etyp 1 -handle AAA321 -irq0 10 -iobase0 2F8
This example assigned port 2F8 to the device.
MEM = (ee:f, gg:h, ...)
Use the ISACFG keywords -membasex to specify the memory base,
and -memlenx to specify the memory length. Use the same values
for ee, gg etc. and f, h etc. as you used for ISA_CONFIG.DAT. You can
specify three memory regions using the keywords membase0 through
membase2 and memlen0 through memlen2.
>>>isacfg -slot 3 -dev 0 -mk -enadev 1 -etyp 1 -handle MYDEV -irq0 10 -membase0 80000 -memlen0 20
FLAGS = n
The FLAGS field in ISA_CONFIG.DAT had 2 meaningful bits:
Bit 0 indicates the device being configured is a SCSI adapter.
Bit 1 indicates that no interrupt is required for the device.
Because it was never possible to use bit 0, it is not currently
supported in file-based autoconfiguration. Bit 1 can be expressed with
the file-based autoconfiguration FLAGS=NOVECTOR statement.
USER_PARAM = text
Use the PRIVATE_DATA keyword in file-based autoconfiguration to
represent this value. If you used quotation marks with the USER_PARAM
value, you must use BEGIN_PRIVATE and END_PRIVATE to continue to pass
the quotation marks to the driver. For ISA devices, the PRIVATE_DATA
values can be obtained the same way as USER_PARAM (that is, by using
the IOC$NODE_DATA routine with the IOC$K_ISA_USER_PARAM keyword).
While using ISACFG, you must also be familiar with the following
To return the configuration to its initial state:
To save your changes:
To delete an entry:
>>>isacfg -slot 1 -dev 0 -rm
To see all the devices currently configured:
To modify a device, use -mod:
>>>isacfg -slot 2 -dev 0 -mod (etc.)
The following keywords do not have equivalents in ISA_CONFIG.DAT:
Takes the numbers 0 (disabled) and 1 (enabled). It allows you to
disable a device so that it will not be used in resource allocation
Defines an entry type for this entry. OpenVMS supports only the values
0 and 1. It should always be specified as a 1. It takes the following
0 Causes the entry to be deleted
1 Single option
2 Embedded multiport device
3 Multiport option device
8.6 Managing Terminals
To manage terminals, perform the following tasks:
- Physically attach terminals to the system
- Set terminal characteristics
- Set up virtual terminals
The following sections explain setting terminal characteristics and
setting up virtual terminals.
8.6.1 Setting Terminal Characteristics
Terminal device characteristics---for example, the number of characters
displayed on a line---have certain default values. Changing these
values might be necessary, depending on the characteristics you use
with each terminal.
To change the terminal device characteristics, use a SET TERMINAL
command with the appropriate qualifiers in the following format:
SET TERMINAL[/qualifier,...] [device-name[:]]
For example, the following command indicates that the width of terminal
lines is 132 characters and that the size of each page is 60 lines. The
/NOBROADCAST qualifier disables the reception of broadcast messages.
The /PERMANENT qualifier allows you to keep terminal characteristics
between terminal sessions. (You must reset characteristics each time
the system reboots by adding these commands to a site-specific startup
$ SET TERMINAL/WIDTH=132/PAGE=60/NOBROADCAST/PERMANENT
For more detailed information about the SET TERMINAL command and its
qualifiers, refer to the OpenVMS DCL Dictionary.
18.104.22.168 Setting Default Characteristics with System Parameters
To change the default terminal characteristics for all terminals on a
node, you can specify values for the system parameters TTY_DEFCHAR and
TTY_DEFCHAR2. For more information about these parameters, refer to the
OpenVMS System Management Utilities Reference Manual. For more information about setting system parameters,
see Section 15.5.
22.214.171.124 Setting Characteristics in System Startup
To execute SET TERMINAL commands each time your system boots, add these
commands to a site-specific startup command procedure. If your
configuration is simple, you can add the commands to SYSTARTUP_VMS.COM.
If your configuration requires a large number of commands, create a
separate command procedure (for example, TERM_SETUP.COM) and execute it
from the SYSTARTUP_VMS.COM. When the device setup command procedure
finishes executing, control returns to SYSTARTUP_VMS.COM.
Compaq recommends that you limit the number of SET TERMINAL commands
you include in startup command procedures. Large numbers (for example,
hundreds) of SET TERMINAL commands can significantly slow down system
startup. If you have a large number of terminals, change the default
characteristics using the system parameters TTY_DEFCHAR and
TTY_DEFCHAR2 as explained in Section 126.96.36.199.
You may want to include comments to provide the names of terminal
owners, as shown in the following example.
The following example provides sample commands you could include in
your startup procedure to set up terminal devices:
$ SET TERMINAL TTC2:/SPEED=300/DEVICE_TYPE=LA36/PERMANENT !JONES
$ SET TERMINAL TTD1:/SPEED=9600/PERMANENT !WRENS
$ SET TERMINAL TTD4:/SPEED=1200/PERMANENT !JRSMITH
$ SET TERMINAL TTG4:/SPEED=1200/MODEM/PERMANENT !DIALUP1
8.6.2 Managing Virtual Terminals
Virtual terminals allow users to disconnect from a physical terminal
without terminating a process; the process remains active on a virtual
terminal. Virtual terminals are used for the following purposes:
- To reconnect to a process when a modem line connection is lost
- To maintain sessions on more than one disconnected terminal
- To use dynamic asynchronous DECnet communication
Enabling Virtual Terminals
On VAX systems, you set up virtual terminals by entering the following
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONNECT VTA0/NOADAPTER/DRIVER=TTDRIVER
On Alpha systems, you set up virtual terminals by entering the
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> IO CONNECT VTA0/NOADAPTER/DRIVER=SYS$TTDRIVER
Virtual terminals are identified by the VTAn: device name.
After the SYSGEN or IOGEN command is entered, any terminal with the
TT2$M_DISCONNECT characteristic set prior to login is treated as a
LAT terminals (LTAn:) can be disconnected if the
TT2$M_DISCONNECT characteristic is set, but remote terminals
(RTAn:) cannot be disconnected.
You can set the TT2$M_DISCONNECT characteristic in one of two ways:
- Enable the feature on a systemwide basis by setting the appropriate
bit in the system parameter TTY_DEFCHAR2. You must use this method for
dynamically created terminal devices; for example, LTAn:
- Enable the feature on a per-terminal basis by using the DCL command
Controlling the Use of Virtual Terminals
You can control the use of virtual terminal sessions in the following
- In SYLOGIN, include a user-written DCL procedure that enforces a
system-wide or user-specific policy for the use of virtual terminals at
- Specify the maximum number of detached processes that individual
users can create by specifying a value for the UAF resource limit
MAXDETACH. See the documentation of the MAXDETACH user quota in
Table 7-9 for the implications of using this quota, as well as
information about how to set this quota.
- Using the system parameter TTY_TIMEOUT, specify the length of time
a disconnected session remains before being logged out.
- Restrict the use of virtual terminals by enabling them on a
- Restrict individual users from being able to reconnect to
disconnected terminal sessions by specifying the UAF flag DISRECONNECT.
- Create a site-specific LGI callout module that provides the
preferred policy at your site. Information about LGI callouts is in the
OpenVMS Utility Routines Manual.
188.8.131.52 Using Virtual Terminals for Dynamic Asynchronous DECnet for OpenVMS (VAX Only)
Virtual terminals are required for dynamic asynchronous DECnet
communication. A dynamic asynchronous line differs from a static
asynchronous line or other DECnet line in that it is normally switched
on for network use only for the duration of a dialup connection between
two nodes. Dynamic switching of terminal lines to asynchronous DDCMP
lines can occur if the following requirements are met:
- Both nodes have DECnet licenses registered and loaded
- Both nodes have the asynchronous DDCMP driver NODRIVER loaded
- Both nodes have DYNSWITCH installed as a privileged shareable image
- The remote node has virtual terminals enabled
See the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration for a detailed description of the procedure for
setting up dynamic asynchronous DECnet lines.
184.108.40.206 Determining the Physical Terminal Type of a Virtual Terminal
You can determine the physical terminal type associated with a virtual
terminal. Because both direct connect and LAT lines can be virtual, you
might not know the terminal characteristics of a LAT terminal at system
startup time. You can set the characteristics of direct connect lines
startup; however, you must enter a SET TERMINAL/INQUIRE command to
determine the characteristics of a LAT line. (See Section 26.1 for
more information about LAT software.)
Using the command SET TERMINAL/INQUIRE clears the type-ahead buffer.
The following command procedure determines the physical terminal
characteristics of both direct and LAT lines at system startup. Insert
the following lines in your systemwide login procedure (SYLOGIN.COM).
(This procedure assumes that your startup procedure has set all
switches and LAT lines to "unknown.")
$ DEVCLASS = 'F$GETDVI ("SYS$COMMAND","DEVCLASS")'
$ IF DEVCLASS .ne. 66 then goto alldone !Not a terminal
$ DEVTYPE = 'F$GETDVI ("SYS$COMMAND","DEVTYPE")'
$ IF DEVTYPE .ne. 0 then goto got_devtype
$ SET TERMINAL/INQUIRE !Try to determine the device type
$ DEVTYPE = 'F$GETDVI ("SYS$COMMAND","DEVTYPE")'
$! Can now dispatch on 'devtype' to do different things depending
$! on the type of terminal.
You can uniquely identify a LAT terminal by using the F$GETDVI lexical
function and specifying the item TT_ACCPORNAM. The function returns the
terminal server node name and port name.
8.7 Managing Modems
A modem is a device that converts electronic signals
from one data format to another. Modems usually perform conversions
bidirectionally, that is, they can convert the local data into another
data format and transmit the results; modems can also receive and
convert data back to the local data format. Most modems convert data
from digital format to analog format, and from analog format back to
With a pair of modems, you can transmit digital communications over
analog media such as telephone lines, and then convert the
communications back into digital signals at a remote location. Pairs of
modems are used to connect a terminal or a local computer to a remote
computer system, and to connect two remote computers to each other.
The following sections discuss these topics:
- Understanding modems
- Setting up modems
- Troubleshooting modems