Updated: 11 December 1998

OpenVMS System Manager's Manual

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 file-based autoconfiguration.

Support for using the SYS$MANAGER:ISA_CONFIG.DAT file to configure ISA devices has been 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 sections.

Table 7-2 contains a list of keywords from ISA_CONFIG.DAT and their equivalents in either file-based autoconfiguration or the ISACFG utility.

Table 7-2 ISA_CONFIG.DAT Keywords and Equivalents

ISA_CONFIG.DAT	File-based Autoconfigure	ISACFG
Not used	ID	-handle
NAME	NAME
DRIVER	DRIVER
IRQ		irq x
NODE		slot
DMA		dmachan x
PORT		iobase x
MEM		membase x
FLAGS	Bit 1 (unsupported)
	Bit 2 (FLAG=NOVECTOR)
USER_PARAM	PRIVATE_DATA

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 ISACFG-handle keyword.

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

Descriptions of the conversion for each parameter in ISA_CONFIG.DAT are as follows:

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 SYS$LOADABLE_IMAGES.

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.

Example:

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.

Example:

>>>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 following command:

>>>isacfg -all

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.

Example:

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

Example:

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

Example:

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

To return the configuration to its initial state:

>>>isacfg -init

To save your changes:

>>>init

To delete an entry:

>>>isacfg -slot 1 -dev 0 -rm

To see all the devices currently configured:

>>>isacfg -all

To modify a device, use -mod:

>>>isacfg -slot 2 -dev 0 -mod (etc.)

The following keywords do not have equivalents in ISA_CONFIG.DAT:

-enadev a_number	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 calculations.
-etyp a_number	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 values: 0 Causes the entry to be deleted 1 Single option 2 Embedded multiport device 3 Multiport option device

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.

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

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

7.6.1.1 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 14.5.

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

You may want to include comments to provide the names of terminal owners, as shown in the following example.

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

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

$ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT VTA0/NOADAPTER/DRIVER=TTDRIVER SYSGEN> EXIT

On Alpha systems, you set up virtual terminals by entering the following commands:

$ RUN SYS$SYSTEM:SYSMAN SYSMAN> IO CONNECT VTA0/NOADAPTER/DRIVER=SYS$TTDRIVER SYSMAN> EXIT

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 virtual terminal.

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: devices.
• Enable the feature on a per-terminal basis by using the DCL command SET TERMINAL/DISCONNECT.

Controlling the Use of Virtual Terminals

You can control the use of virtual terminal sessions in the following ways:

• In SYLOGIN, include a user-written DCL procedure that enforces a system-wide or user-specific policy for the use of virtual terminals at your site.
• 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 6-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 per-terminal basis.
• 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.

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.

7.6.2.2 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 at system startup; however, you must enter a SET TERMINAL/INQUIRE command to determine the characteristics of a LAT line. (See Section 24.1 for more information about LAT software.)

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")' $ got_devtype: $! Can now dispatch on 'devtype' to do different things depending $! on the type of terminal. $ alldone:

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.

7.7 Managing Modems

A modem is a device that converts electronic signals from one data format to another. Modems usually perform conversions bi-directionally, 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 digital format.

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

A modem converts a digital signal to an analog signal by modulating the digital information on a carrier signal; a modem converts analog to digital signals by demodulating---or extracting---digital information from analog signals on an analog transmission facility such as a telephone line. The two words MOdulator and DEModulator form the basis for the device name: modem.

Figure 7-1 represents communications between a terminal and a remote computer system, but the principles apply equally to communications between two computer systems. One modem converts digital to analog signals on the local end of the analog telephone connection, and another modem converts analog to digital signals on the remote end of the connection.

Figure 7-1 Basic Modem Configuration

Modems are always used in pairs; each one of the pair can act as both a transmitter and a receiver.

When configuring modems, you must check that:

• The receiving and transmitting modems are wired correctly.
• The modems support compatible analog data formats and speeds.
• Each modem supports a digital format compatible with the attached terminal or computer.

Once a modem connection has been established, you can layer data communications over the connection. You can layer at least one, and sometimes more, of a wide variety of communications protocols on the basic asynchronous serial ASCII protocol that most modems provide. Point-to-Point Protocol (PPP) and asynchronous DECnet are examples of protocols that can operate over a modem link.

Table 7-3 lists references to OpenVMS documentation that discuss other communications protocols and topics relevant to the use of modems:

Table 7-3 Related Modem Documentation

Reference	Description
DECnet-Plus for OpenVMS Network Management	Explains the use of modems to establish a dynamic asynchronous DECnet connection between two nodes. Asynchronous DECnet is a protocol that can operate over a modem datalink.
OpenVMS Guide to System Security	Discusses how to maintain the security of DECnet modem connections and dial-in modem lines.
TCP/IP Networking on OpenVMS Systems	Explains the use of PPP on OpenVMS Alpha and OpenVMS VAX to communicate with remote systems.
Section 7.6.2	Explains how to configure and manage virtual terminals.
OpenVMS DCL Dictionary and online help	The DCL command SET HOST/DTE discusses the use of modems to connect to a remote system. The DCL commands CONNECT and DISCONNECT explain how to set up and disconnect virtual terminals.

Direct and Indirect Connections

Part of the job of configuring a modem to a computer or a terminal is to decide what type of access the modem will have to your computing environment and which serial communications ports best meet your requirements.

You can choose to connect a modem directly to a host system, or you can connect the modem indirectly to an intermediate network server device such as a DECserver. Explanations of these two types of connections follow.

• Direct connection
  A direct connection dedicates the modem to a particular host system. This reduces the amount of access available to the modem caller, and can reduce to one the number of systems that you must protect against unauthorized access through this modem.
  This is often the configuration of choice for smaller computing environments, or for connecting a modem to a single computer or terminal.
• Indirect connection
  An indirect connection creates a pool of modems for a variety of computer systems on the local area network, including servers that communicate with the host computers using protocols such as LAT and Telnet. This type of connection makes better use of the available telephone lines but increases security requirements.
  This is often the configuration of choice for larger computing environments. An indirect connection is commonly used when you use LAT or Telnet protocols to configure a number of modems, called a modem pool, to share access to a number of computer systems.

With either type of connection, you cannot use the modem if the host or the server the modem is connected to is not operational.

Figure 7-2 depicts direct and indirect modem configurations. The remote devices T1 and T2 are indirectly connected to both Host1 and Host2 host computers using the DECserver and the LAT protocol; T3 is connected directly to Host2.

Figure 7-2 Direct and Indirect Modem Configurations

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6017PRO_026.HTML