Sending and receiving messages using X.25 Mail is very similar to the same tasks using OpenVMS Mail. The only difference is the form in which you specify the address of the recipient.

To send mail using X.25 Mail, do the following:

The following example shows how to send mail using OpenVMS Mail over X.25 to user LONG at DTE address 328740975776 in DTE class CLASSY.

$ mail
MAIL> send
To: PSI%classy.328740975776::long
CC:
Subj: This month’s results
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
Hi there,
Have you got them yet?
JB
MAIL>

You can send one mail message to a mixture of destinations using X.25 Mail for some and OpenVMS Mail for others. Simply use the X.25 Mail address format for users you are contacting over X.25 and the OpenVMS Mail format for users you are contacting with OpenVMS Mail.

For example, in the following mail session, OpenVMS Mail is used to send the message to user M_MONEY and X.25 Mail is used to send the message to users JONES and EVANS.

$ mail
MAIL> send
To: BANK::M_MONEY,PSI%CLASSY.234273412345::JONES,EVANS
CC:
Subj: This month’s results
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
Hi there,
Have you got them yet?
JB
CTRL/Z
MAIL>

You can simplify use of X.25 Mail by using logical names for combinations of DTE class and DTE address. For example, suppose you assign the logical name SHORT to the following combination:

DTE class: CLASSY
DTE address: 328740975776

By using this logical name, the following X.25 Mail address

CLASSY.328740975776::LONG

can be shortened to:

SHORT::LONG

There are two types of logical names you can use:

X.25 Mail provides a number of facilities that allow you to control the mail sent to and from your system and to make using X.25 Mail as easy as possible. For example, you can set up templates for outgoing calls, filters for incoming calls, and logical names for DTE addresses.

This chapter describes how to:

Templates define the values for the call parameters of outgoing calls.

When you configure your system, a template called Default is set up. It is possible to change the Default template, to give different values to all outgoing calls. You can alter the existing call parameter values or add new call parameters to the template.

It is also possible to create new templates for different types of outgoing calls. If you create a new template you should define the logical name PSI$MAIL_ TEMPLATE to point to the new template.

The recommended method of creating and modifying templates for use by X.25 Mail is to run the X.25 configuration program, which includes a section for configuring templates. For details on configuring templates for X.25 for OpenVMS on OpenVMS IA-64 and OpenVMS Alpha systems, refer to the VSI X.25 for OpenVMS Configuration Guide. For details on configuring templates for DECnet-Plus for OpenVMS VAX systems, refer to the VSI OpenVMS DECnet-Plus Installation and Configuration manual.

Once created, a template can be modified using either the X.25 configuration program, or by issuing NCL commands interactively:

Filters determine which applications receive an incoming call.

When you configure your system to include X.25 Mail support, a filter called X25_MAIL is set up. If you want to modify any of the existing filter attributes or add new attributes, you can modify the X25_MAIL filter. Like templates, a filter can be modified using either the X.25 configuration program, or by issuing NCL commands:

You can send mail using X.25 Mail in the same way as sending mail using OpenVMS Mail except that you must specify a DTE address (rather than a node name) in response to the following prompt:

To:

DTE addresses are lengthy and difficult to remember. Therefore, it is a good idea to define logical names to point to DTE addresses. Users can then send mail by specifying a short name rather than a long string of numbers.

You can define personal logical names (refer to Chapter 1, Using X.25 Mail), or system-wide logical names (refer to Section 2.4.1, “Defining System-Wide Logical Names”).

$ DEFINE/TABLE=PSI$DTE_TABLE logical-name [dte-class.]dte-address

$ DEFINE/TABLE=PSI$DTE_TABLE PSI$MAIL_DTE_[dte-class.]dte-address logical-name

$ DEFINE/TABLE=PSI$DTE_TABLE ERIC CLASSY.23427341234567
$ DEFINE/TABLE=PSI$DTE_TABLE PSI$MAIL_DTE_CLASSY.23427341234567 ERIC

To: PSI%ERIC::username

From: PSI%ERIC::username

In a DECnet-Plus for OpenVMS system, the configuration parameters and access control information for incoming X.25 Mail calls are contained in the object database. Users who want to use X.25 Mail to send mail must have the privilege NETMBX. This privilege allows users to assign a channel to the NET device, and is required to create a logical link to a remote node.

During configuration of the X.25 software, security information can be entered that defines which users are permitted to make and receive X.25 calls.

2.5.2. Preventing Poor Man’s Routing

Figure 2.1, “X.25 Security and MAIL” illustrates a typical network configuration consisting of 6 nodes and two PSDNs. In conjunction with descriptions in Section 2.5.2.1, “Preventing Indiscriminate Use of OpenVMS Mail” and Section 2.5.2.2, “Preventing Indiscriminate Use of X.25 Mail”, this figure will be used to illustrate potential security problems caused by PMR and how such problems can be prevented.

2.5.2.1. Preventing Indiscriminate Use of OpenVMS Mail

In Figure 2.1, “X.25 Security and MAIL”, users on Node B (a non-X.25 node) and Node A (an X.25 Connector node) in Paris can send and receive OpenVMS Mail to and from other nodes on their local DECnet.

Similarly, users on Node D (an X.25 Client node) and Node E (an X.25 Connector node) in London can send and receive OpenVMS Mail to and from other nodes on their local DECnet.

However, a user on Node B in Paris can also send OpenVMS Mail calls across PSDN1 to Node E in London (or any other node on that DECnet) using PMR and X.25 Mail. This can be achieved by specifying a mail command in the form:

MAIL> SEND TEXT.TXT
To: A::PSI%dte-class.remote-dte::user-name

where:

dte-class	is the DTE class name (usually the network name).
remote-dte	is the remote DTE address of Node E.

Note that in this example, Node A is charged for the X.25 call.

Normally, you would grant the rights identifier PSI$X25_USER to the processes and users who are permitted to make outgoing X.25 calls. This rights identifier ensures that other users cannot make outgoing X.25 calls.

However, for users on non-X.25 nodes in your network, PMR using an accessible X.25 Connector node can be used because outgoing X.25 calls use the DECnet MAIL object’s user name.

To prevent the indiscriminate use of PMR by users on non-X.25 nodes in your network, do not grant the DECnet MAIL process the PSI$X25_USER rights identifier.

To restrict the use of PMR only to specified remote DTEs, use X.25 Security to restrict X.25 Mail access only to the specified remote DTEs. You can do this by defining X.25 Mail as a local application and giving that application rights identifiers that allow restricted outgoing access only to known specific DTEs.

2.5.2.2. Preventing Indiscriminate Use of X.25 Mail

Incoming X.25 Mail to Non-X.25 Nodes

In Figure 2.1, “X.25 Security and MAIL”, users on Node A in Paris could use PMR to send mail using X.25 Mail to remote nodes across PSDN1. They could send mail using X.25 Mail to a user on Node F in London (a non-X.25 node), by specifying each node in the route from their node to the destination node. For example, to send mail using X.25 Mail to a user on Node F, a mail command in the following format can be used:

MAIL> SEND TEXT.TXT
To: PSI%dte-class.remote-dte::F::user-name

where:

dte-class	is the DTE class name (usually the network name).
remote-dte	is the remote DTE address of Node E.

In this example, Node A is charged for the X.25 call.

Preventing Incoming X.25 Mail to Non-X.25 for OpenVMS Nodes on Your Network

X.25 Security performs remote DTE address verification on the X.25 Connector node for incoming X.25 Mail calls before X.25 Mail runs. However, the X.25 Connector node requires a DECnet logical link to forward mail to the non-X.25 nodes. This DECnet logical link requires NETMBX privilege.

To prevent remote DTEs using PMR to send mail to non-X.25 nodes in your network:

1. Create an account in which to run X.25 Mail. This should be a different account to the DECnet MAIL object account.

2. Grant the PSI$X25_USER rights identifier to the user name associated with the X25_MAIL object.

3. Do not grant the NETMBX privilege to the user name associated with the X25_MAIL application.

Note that this prevents all redirection of incoming X.25 Mail calls to non-X.25 nodes on your network.

Forwarding X.25 Mail Calls Via Connector Nodes

In Figure 2.1, “X.25 Security and MAIL”, users on Node A in Paris (an X.25 node) could use Node E (an X.25 Connector node) in London to forward X.25 Mail calls to Node C in New York (an X.25 node), using a command of the form:

MAIL> SEND TEXT.TXT
To: PSI%dte-class1.remote-dte1::PSI%dte-class2.remote-dte2::
user-name

where:

dte-class1 and dte-class2	are the DTE class names for node E and C respectively.
remote-dte1 and remote-dte2	are the remote DTE addresses of node E and C respectively.

In this case, Node A is charged only for the X.25 call to Node E; Node E is charged for the X.25 call to Node C.

Indiscriminate use of your node by users on remote nodes to forward X.25 Mail calls could lead to large network costs for your system. In addition, it may be illegal to inadvertently forward third party traffic via your system.

Preventing Remote Nodes Using Your Node to Forward Third Party Traffic

You can prevent your node from forwarding third party traffic by setting up X.25 Security and privileges for incoming and outgoing calls:

1. Create an account in which to run X.25 Mail. This should be a different account from the DECnet MAIL object account.

2. Set up X.25 Security to restrict incoming X.25 Mail calls to accept only those calls from specified remote DTEs. You can do this by creating rights identifiers and access levels for incoming calls to the X25_MAIL application.

3. Set up X.25 Security to prevent outgoing X.25 Mail calls that use the user name associated with the X25_MAIL application.

4. Grant the PSI$X25_USER rights identifier to the user name associated with the X25_MAIL application.

5. Do not grant NETMBX privilege to the user name associated with the X25_MAIL application.

In this way, you can prevent remote nodes from using your node to forward third party traffic.

To connect to a remote system, issue the following command:

$ SET HOST/X29 dte-class.dte-address

where:

For example, to use a DTE in class CLASS_A to connect to a DTE with address 7608657086, enter the command:

$ SET HOST/X29 CLASS_A.7608657086

You can simplify the SET HOST/X29 command by using a DTE logical name instead of entering the DTE class and DTE address. For example, if the DTE you are connecting to has the logical name PARIS, you can connect to that DTE with the command:

$ SET HOST/X29 PARIS

Note that the logical name PARIS is defined using the command:

$ DEFINE/TABLE=PSI$DTE_TABLE PARIS CLASS_A.7608657086

Details of using and setting up DTE logical names are given in Section 1.2, “Using Logical Names for Addresses”.

Note that if you do not specify a DTE class in the command line, X.25 for OpenVMS uses the X29Login template on OpenVMS IA-64 and OpenVMS Alpha systems or the Default template on OpenVMS VAX systems. For details of the X29Login template, refer to Part III, “Managing X.29 Communications”.

You can control the characteristics of your connection to the remote DTE by adding qualifiers to the SET HOST/X29 command. Chapter 4, Controlling the Connection to the Remote DTE describes how to do this.

There are two ways to disconnect from a remote system:

When you connect to a remote DTE using the SET HOST/X29 command, you can control the way in which:

3.3.1. Setting PAD Parameters Using the SET HOST/X29 Command

When you establish a SET HOST/X29 connection, X.25 for OpenVMS uses several files to set the PAD parameters. This results in some of the PAD parameters being set and reset several times. In addition, the PAD parameters may be reset during the X.29 session if you specify new values for one or more of the parameters.

If you want to control the behavior of the PAD during your SET HOST/X29 session, you need to know:

• Which files and command qualifiers X.25 for OpenVMS uses to set the PAD parameters.

• In what order X.25 for OpenVMS processes these files and command qualifiers. This is important because each time X.25 for OpenVMS sets a PAD parameter, the new setting overrides any previous settings.

The files that X.25 for OpenVMS uses to set and reset PAD parameters are:

The PAD initial profile

This file is supplied with X.25 for OpenVMS, and contains default values for some of the PAD parameters. These values are listed in Appendix B, Host-Based PAD Initial Profile.

The PSI$PAD_INIT file

PSI$PAD_INIT is a logical name that should be used to point to a PAD initialization file (if one has been set up). An initialization file is useful if you want to set certain PAD parameters and execute certain DCL commands each time you establish a SET HOST/X29 connection.

To set up a PAD initialization file, create a file containing any PAD commands you want to issue each time you make a SET HOST/X29 connection. Then define the logical name PSI$PAD_INIT to point to your initialization file.

The PAD parameter profile file

The PAD parameter profile file contains a set of PAD parameter profiles. Each PAD parameter profile is a named list of settings for certain PAD parameters. PAD parameter profiles are useful if you regularly need to set certain PAD parameters to particular values, for example, to access a non-OpenVMS system.

If you have defined a PAD parameter profile for a remote system, you can set the parameters you need simply by naming the profile. You do not need to specify each parameter individually. You can specify PAD parameter profiles either in the SET HOST/X29 command line, or by issuing commands to the PAD during a SET HOST/X29 session.

For details of how to create and use a PAD parameter profile file, refer to Section 3.3.2, “Creating the PAD Initialization File and PAD Parameter Profiles”.

In addition to the above files:

• X.25 for OpenVMS reads certain PAD parameters (for example, SPEED) from your terminal’s characteristics.

• You can set individual parameters yourself, either at the start of your SET HOST/X29 session, by using qualifiers to the SET HOST/X29 command, or during your session, by issuing commands to the PAD.

Figure 3.2, “Sequence in which PAD Parameters are Set After Issuing a SET HOST/X29 Command” illustrates the order in which X.25 for OpenVMS processes the files and qualifiers following a SET HOST/X29 command.

For example, if you specify a PAD parameter profile which gives parameter 4 (TIMEOUT) the value 10, and specify TIMEOUT individually as 20, TIMEOUT will take the value 20, because the /PARAMETER qualifier is processed after the /PROFILE qualifier.

The qualifiers to the SET HOST/X29 command are described in Chapter 4, Controlling the Connection to the Remote DTE.

PROFILE profile-name parameter-list

!
! Profile for connection to Machine 5
!
PROFILE MACHINE_5 -
   ECHO, NOEDIT, BREAK=2, FORWARDING_CHARACTERS=2

If you want to create a log of your SET HOST/X29 session, you can use one of two types of log file. These are the NETWORK log file and the TERMINAL log file:

Note that you cannot change the log file type during a PAD session.

The type of log file is controlled by the logical name PSI$PAD_LOG. This logical name can be defined as either NETWORK or TERMINAL. If the logical name is not defined, the log file type defaults to TERMINAL.

If you specify a type other than NETWORK or TERMINAL, the PAD session will terminate and the following error message will be displayed:

%PAD-F-INITERROR, error occurred during initialization 
-PAD-E-INVLOGTRAN, invalid translation of PSI$PAD_LOG logical name 

This section describes how to set the characteristics of the X.25 for OpenVMS host-based PAD when you use the SET HOST/X29 command.

$ SET HOST/X29/PARAMETERS=(TIMEOUT=10,NOWRAP,DELETE) PARIS

$ SET HOST/X29/PROFILE=(MACHINE_2,SYSTEM_A) PARIS

$ SET HOST/X29/PROFILE=SYSTEM_A/PARAMETERS=(TIMEOUT=10,NOWRAP) PARIS

$ SET HOST/X29/DEFAULT_ESCAPE_CHARACTER=J PARIS

$ SET HOST/X29/BREAK_CHARACTER=K PARIS

When you connect to a remote terminal, you can add qualifiers to the SET HOST/X29 command to set the characteristics of the connection between the X.25 for OpenVMS host-based PAD and the remote DTE. This can be achieved by specifying individually the characteristics you want to set. This procedure is described in Section 4.2.1, “Using a Local Subaddress” to Section 4.2.1, “Using a Local Subaddress”.

Note that if you do not specify a DTE class and DTE address in the SET HOST/X29 command, X.25 for OpenVMS uses the X29Login template on OpenVMS IA-64 and OpenVMS Alpha systems or the Default template on OpenVMS VAX systems. In addition, any characteristics you specify using a qualifier will override the value specified in the X29Login or Default template.

Note that the availability of the facilities described in Section 4.2.1, “Using a Local Subaddress” to Section 4.2.1, “Using a Local Subaddress” depends on the network you are using. For details of the facilities supported by a specific network, see the documentation supplied by your network provider.

The following sections list the SET HOST/X29 command qualifiers, with a summary of their defaults and uses. Table 4.1, “SET HOST/X29 Qualifiers Which Control the PAD” lists the command qualifiers you can use to control the host-based PAD. Table 4.2, “SET HOST/X29 Qualifiers Which Control the Connection” lists the command qualifiers you can use to control the connection between the host-based PAD and the remote DTE.

To enter PAD command mode, press the Escape character. The default Escape character is Ctrl/P, but if you have set a different Escape character for your session, use that character. (Section 4.1.2, “Setting the Escape Character” describes how to set an Escape character when you connect to a remote system.) If there is no Escape character defined, press Ctrl/Y twice.

This section describes how you can use the PAD commands to control a PAD session.

You can request online help at any time by entering:

PAD> HELP

PAD> SPAWN [command] [qualifiers]

PAD> SPAWN/PROCESS=FRED/OUTPUT=FRED.TXT

PAD> ATTACH process-name
PAD> ATTACH/IDENTIFICATION=pid

PAD> attach harry

PAD> DEFINE/KEY key-name "equivalence-string" [qualifiers]

PAD> INTERRUPT [data] [qualifier]

%PAD-W-WARNINT, Previous interrupt incomplete

PAD> RESET [diagnostic]

PAD> @file

PAD> @BOB

This section describes how to change the characteristics of a host-based PAD.

PAD> SET PARAMETERS parameter-value-list

PAD> SET PARAMETERS TIMEOUT=10, NOFORWARDING_CHARACTERS, DELETE

PAD> SET PARAMETERS 4=10, 3=0, 16

PAD> SET PROFILE profile-name

PAD> SET PROFILE MACHINE_2

PAD> SET PROFILE/INITIAL

PAD> SET PARAMETERS ESCAPE_CHARACTER=[value]

PAD> SET [NO]DEFAULT_ESCAPE_CHARACTER [character]

PAD> SET DEFAULT_ESCAPE_CHARACTER J

PAD> SET BREAK_CHARACTER character

PAD> SET BREAK_CHARACTER K

PAD> SET NOBREAK_CHARACTER

PAD> SET NOBREAK_CHARACTER
PAD> SET BREAK_CHARACTER character

PAD> SET VMS_MODE

PAD> SET LOG_FILE file [qualifier]

PAD> SET NOLOG_FILE

PAD> SET PROMPT prompt-string [qualifier]

PAD> SET INPUT file [qualifier]

During a PAD session, you can examine the present settings of the PAD parameters and other information about the PAD and your use of it.

To see information about the PAD, use the PAD SHOW command. This command allows you to examine:

The following tables list the PAD commands, with a summary of their defaults and uses. Table 5.1, “Commands Used to Control a PAD Session” lists the commands you use to control a PAD session, Table 5.2, “Commands Used to Change the PAD Characteristics” lists the commands which change the PAD parameters, and Table 5.3, “Commands Used to Examine the PAD Characteristics” lists the commands you use to examine the characteristics of the PAD. The PAD commands are listed in alphabetical order within each table.

To connect to a remote system, using the host-based PAD in CCITT mode, enter the following command:

$ SET HOST/X29/CCITT [[dte-class].dte-address]

where:

If you do not specify a DTE class, X.25 for OpenVMS will use the DTE class specified in the PAD template. If there is no DTE class specified in the PAD template, X.25 for OpenVMS will use the DTE class specified in the system default template. If neither template specifies a DTE class, the command will fail.

To simplify the command, you can replace dte-class and dte-address with a logical name. Refer to Section 1.2, “Using Logical Names for Addresses” for details of setting up and using logical names.

When you specify the remote DTE address, you can use any of the qualifiers described in Chapter 3, Using an X.29 Terminal to Connect to a Remote System.

Note that specifying the remote DTE in the command line is optional. This gives you the option of connecting to the remote DTE in the usual way, or entering PAD command mode (from which you can make a call to the remote DTE). Section 6.1.1, “Entering PAD Command Mode from the Local DTE” and Section 6.1.2, “Entering PAD Command Mode from the Remote DTE” describe how to enter PAD command mode from the local and remote DTEs respectively.

$ SET HOST/X29/CCITT

This section describes how you can control a CCITT PAD session.

PAD> A remote--dte

%PAD-I-COM, Call connected

PAD> EXIT

PAD> EXIT

PAD> STAT 
%PAD-I-ENGAGED, PAD engaged
PAD>

PAD> CLR

PAD> U cccc

PAD> BREAK

PAD> PAR? 7

PAD> INT

%PAD-W-WARNINT, Previous interrupt incomplete

PAD> RESET

You can change the characteristics of individual PAD parameters by issuing the command:

PAD> SET parameter-list

where parameter-list is a list of parameter numbers and parameter values, in the form:

parameter-number:parameter-value

For example, to set the values of PAD parameters 3, 4, 5 and 10, to 48, 160, 0 and 132, respectively, enter the following command:

PAD> SET 3:48, 4:160, 5:0, 10:132

Alternatively, if you want to change some parameter values and have the new values displayed, enter the following command:

PAD> SET? parameter-list

For a description of the parameters and their values refer to Chapter 10, Changing Default X.29 Terminal Characteristics.

Note that when you use the PAD in CCITT mode, you cannot use keywords to refer to the parameters. You have to reference the parameters by number.

To display the current values for the PAD parameters, enter the following command:

PAD> PAR? [parameter-list]

where parameter-list is a list of PAD parameter numbers. If you do not specify a list of PAD parameter numbers, the PAD will display the values for all the parameters.

For example, to display the current values for PAD parameters 3, 4 and 9, enter the following command:

PAD> PAR? 3,4,9

For a description of the parameters and their values refer to Chapter 10, Changing Default X.29 Terminal Characteristics.

This section describes how you can use the SET TERMINAL/X29 command to change:

In addition, you can use the SET TERMINAL/X29 command to alter:

For information about changing the PAD parameter templates and the hold timer, refer to Chapter 10, Changing Default X.29 Terminal Characteristics.

$ SET TERMINAL/X29/PARAMETERS=(parameter-specification)

$ SET TERMINAL/X29/PARAMETERS=(TIMEOUT=10), NOFORWARDING_CHARACTERS, DELETE

$ SET TERMINAL/X29/PARAMETERS=(4=10, 3=0, 16)

$ SET TERMINAL/X29/NETWORK_SPECIFIC=(parameter-list)

$ SET TERMINAL/X29/NETWORK_SPECIFIC=(120=35,24=19,56=8)

$ SET TERMINAL/X29/NETWORK_SPECIFIC=(0=0,120=35,24=19,56=8)

$ SHOW TERMINAL/X29

$ SET TERMINAL/X29/LOG

To display the characteristics of your X.29 terminal and the PAD, enter the following command:

$ SHOW TERMINAL/X29

This will display your terminal characteristics and the PAD parameters. By adding qualifiers to this command, you can:

For a full description of this command, refer to Chapter 11, Displaying Terminal Characteristics.

Table 7.1, “SET TERMINAL/X29 Command Qualifiers” and Table 7.2, “SHOW TERMINAL/X29 Command Qualifiers” list in alphabetical order the qualifiers for the SET TERMINAL/X29 and SHOW TERMINAL/X29 commands, respectively.

The X.29 protocol defines the procedures for exchange of control information and user data between a Packet Assembler/Disassembler (PAD) and a remote packet-mode DTE. Figure 8.1, “An X.29 Communications Link” shows an example of an X.29 link.

A packet-mode DTE that recognizes the X.29 protocol can use an X.29 program to communicate with a remote X.29 terminal. In X.29 communications, data passes between the X.29 terminal and the NV device through X.25 for OpenVMS. The NV device converts the data to the X.29 protocol.

This chapter describes the following tasks:

X25 Access Templates define the values for call parameters of outgoing calls.

When you configure your system to include X.29 support, a template called X29Login (OpenVMS IA-64 and OpenVMS Alpha) or Default (OpenVMS VAX) is set up. It is possible to change this template, to give different values to all outgoing calls. You can alter the existing call parameter values or add new call parameters to the template.

It is also possible to create new templates for different types of outgoing call. If you create a new template you should define the logical name PSI$X29_X25_ TEMPLATE to point to the new template.

The recommended way of creating and modifying templates is to run the X.25 configuration utility.

An alternative method of creating and modifying templates is to use the Network Control Language (NCL) utility. This utility can be used to make temporary or permanent changes to a template. It is recommended that:

X25 Access Filters determine which applications receive the incoming calls.

When you configure your system to include X.29 support, a filter called X29 (OpenVMS IA-64 and OpenVMS Alpha) or X29_LOGIN (OpenVMS VAX) is set up. If you want to change any of the values or add more attributes, you can modify this filter using the Network Control Language (NCL) utility. As in the case of templates, this utility can be used to make either temporary or permanent changes to the filter. It is recommended that:

A PAD can operate in two modes:

For each mode, some PAD parameters must be set to specific values for communication across the network. Other PAD parameters, which are optional, can be set to optimize or change features of communication across the network.

The NV device keeps a list of PAD parameters for each mode. Each list is called a PAD parameter template. Each PAD parameter template contains mandatory values for some parameters, and the user’s preferred values for other parameters.

In addition to the PAD parameter templates for local-echo and host-echo mode, there is a PAD parameter template for use by the NV device when it receives a HANGUP request from the X.29 terminal.

Table 8.1, “PAD Parameter Template Defaults” shows the parameters which must be included in the PAD parameter templates for correct operation of the NV device. Make sure you include these parameters each time you modify the PAD parameter templates. Parameters which are not required in the PAD parameter templates, but which can be specified, are indicated by a dash (-).

Some of the values can be set by the user for one or more of the PAD parameter templates. This is indicated in the rightmost column.

You can control your X.29 communications links by setting up system-wide default characteristics for X.29 terminals before you start X.25 for OpenVMS.

There are two ways to do this:

The system template command procedure helps you set up all characteristics correctly. More experienced users may prefer to use system logical names. Refer to Chapter 9, Setting Default X.29 Terminal Characteristics for details of both methods.

You can control your X.29 communications link by changing the default X.29 terminal characteristics for individual sessions after you have started X.25 for OpenVMS.

To do this, you need to change the PAD parameter values that control the operation of the NV device. There are two ways to change the PAD parameter values:

The user template command procedure helps you set up all characteristics correctly. More experienced users may prefer to change terminal characteristics directly, using SET TERMINAL/X29 commands. Refer to Chapter 10, Changing Default X.29 Terminal Characteristics for details of both methods.

X.29 terminals, like local OpenVMS terminals, can be spooled or non-spooled. Spooled devices put requests into a queue; for example, a spooled printer puts print requests in a waiting line and prints the requests one after another. Refer to Chapter 12, Spooling an X.29 Terminal for details of how to set up your X.29 terminal as a spooled device.

You can create a file that records site-specific PAD profiles, each with a different name. These PAD profiles are useful if you are accessing non-OpenVMS systems at regular intervals. Non-OpenVMS systems often demand that your PAD parameters are set to particular values.

The file contains PROFILE commands with profile names and the parameter settings associated with them. The PROFILE command should be entered using the following format:

$ PROFILE profile-name parameter-list

where the variable profile-name is the name of the profile, and parameter-list is a list of parameters and their values.

You should set up a default profiles file called PSI$PAD_PROFILES.DAT in the SYS$MANAGER: directory. Use a text editor to create this file in the same way as you would create any other file. You may use the comment character for inserting comments. Use a hyphen if you continue a profile for more than one line. An example profile is shown below:

!
! Profile for connection to machine 5
!
PROFILE MACHINE_5 -
   ECHO, NOEDIT, BREAK=2, -
   FORWARDING_CHARACTERS=2

Here, the profile name is MACHINE_5 and the parameters that distinguish the profile for this machine are: ECHO, NOEDIT, BREAK=2, and FORWARDING_CHARACTERS=2.

For more information about using the system-wide PAD profile file and creating and using user-level PAD profile files, see Chapter 3, Using an X.29 Terminal to Connect to a Remote System.

Table 9.1, “Logical Names and Example Settings” lists the X.29 configuration logical names that are available. The table shows the parameters each name represents. If you do not set up any values, the X.25 startup command procedure, X25$STARTUP.COM (OpenVMS IA-64 and OpenVMS Alpha systems) or PSI$STARTUP.COM (OpenVMS VAX systems), uses the values given in Table 9.1, “Logical Names and Example Settings” to set up the NV device.

Use the logical names as necessary to assign values to the relevant PAD parameters. These parameters will be set up when you run the X.25 startup command procedure.

For example, you can set any of the CCITT PAD parameters 1 to 22 using the logical name PSI$X29_PARAMETERS.

Table 9.2, “Parameter Attributes” shows the parameter attributes you can use with the logical names.

To use the logical names listed in Table 9.1, “Logical Names and Example Settings”, issue the DCL DEFINE command in the following format:

$ DEFINE logical-name equivalence-string

where the variable logical-name is one of those in Table 9.1, “Logical Names and Example Settings” and variable equivalence-string is a PAD parameter name, a parameter attribute (if required), and a value setting.

For example:

In the above examples, the use of quotation marks follows DCL rules (refer to the VSI OpenVMS User's Manual or VSI OpenVMS DCL Dictionary Part One and Part Two).

$ DEFINE/SYSTEM PSI$X29_TERMINAL_CHARACTERISTICS "/NOEIGHT -
_$ /PARITY=EVEN"

The system template command procedure lets you define system-wide defaults for all NV devices within the system. To use the command procedure, enter the following command:

$ @SYS$MANAGER:X25$X29_SYSTEM_TEMPLATE.COM parameter  (OpenVMS I64/OpenVMS Alpha)
$ @SYS$EXAMPLES:PSI$X29_SYSTEM_TEMPLATE.COM parameter (OpenVMS VAX)

where the variable parameter is one of the values given in Table 9.3, “X25$X29_SYSTEM_TEMPLATE.COM Parameter Values”.

For example, to set the default template on an OpenVMS IA-64 or OpenVMS Alpha system, use the system template command procedure as follows:

$ @SYS$MANAGER:X25$X29_SYSTEM_TEMPLATE DEFAULT
$ define psi$x29_host_echo_parameter_template -
_$ "(parameter=echo,value=off),(parameter=timeout,user_value), -
_$ (parameter=new_line,value=off),(parameter=wrap,value=off), -
_$ (parameter=edit,value=off)"
$ define psi$x29_local_echo_parameter_template -
_$ "(parameter=echo,value=on),(parameter=timeout,value=off), -
_$ (parameter=new_line,value=4),(parameter=edit,value=on)"
$ define psi$x29_hangup_parameter_template -
_$ "(parameter=echo,value=on),(parameter=edit,value=on)"

You can change the values of PAD parameters and the characteristics of X.29 terminals using the SET TERMINAL/X29 command. The format of this command is:

$ SET TERMINAL/X29/qualifier [device-name]

where the variable device-name is the terminal device that you want to change. Omit the device name if you want to alter the characteristics of your own terminal.

You can use the /LOG qualifier with the SET TERMINAL/X29 command to display information messages sent to the terminal, for example, the terminal name and the state of the Hold Timer. Issue the command in the form:

$ SET TERMINAL/X29/LOG

$ SET TERMINAL/X29/PARAMETERS=(parameter-value-list)

$ SET TERMINAL/X29/HOLD_TIMER=(n)

$ SET TERMINAL/X29/HOLD_TIMER=(2)

$ SHOW TERMINAL/X29

When the mode of the PAD changes, the NV device uses the appropriate template to update the PAD parameters. Section 10.2.1, “Specifying PAD Parameter Templates Using SET TERMINAL/X29” describes how to specify PAD parameter templates using the SET TERMINAL/X29 command. Section 10.2.2, “Specifying PAD Parameter Templates Using the User Template Command Procedure” describes how to specify PAD parameter templates using the user template command procedure.

$ SET TERMINAL/X29/TEMPLATE=template-name=template

((PARAMETER=name-or-number,[attribute]),
 (PARAMETER=name-or-number,[attribute]),
 (...))

$ SET TERMINAL/X29/TEMPLATE=LOCAL_ECHO=( -
_$ (parameter=echo,calculated), -
_$ (parameter=timeout,value=off), -
_$ (parameter=wrap,calculated,add_value=1), -
_$ (parameter=new_line,value=4), -
_$ (parameter=edit,value=on))

$ @SYS$MANAGER:X25$X29_USER_TEMPLATE.COM parameter  (OpenVMS I64/OpenVMS Alpha) 
$ @SYS$EXAMPLES:PSI$X29_USER_TEMPLATE.COM parameter (OpenVMS VAX) 

$ @SYS$MANAGER:X25$X29_USER_TEMPLATE DEFAULT
$ set terminal/x29/template=( -
_$ host_echo= -
_$      (parameter=echo,value=off), -
_$      (parameter=timeout,user_value), -
_$      (parameter=new_line,value=off), -
_$      (parameter=wrap,value=off), -
_$      (parameter=edit,value=off), -
_$ local_echo= -
_$      (parameter=echo,value=on), -
_$      (parameter=timeout,value=off), -
_$      (parameter=new_line,value=4), -
_$      (parameter=edit,value=on), -
_$ hangup= -
_$      (parameter=echo,value=on), -
_$      (parameter=edit,value=on))

The format of the SHOW TERMINAL/X29 command is:

$ SHOW TERMINAL/X29/qualifier [device-name:]

where the variable device-name is the name of the terminal device for which you want the characteristics displayed. Omit the device name if you want to display the characteristics of your own terminal.

There are two qualifiers you can use with the SHOW TERMINAL/X29 command:

In the examples used in this chapter, the PAD parameters have been set up as shown in Table 11.1, “PAD Parameter Settings”.

The example below shows the result of issuing the SHOW TERMINAL/X29 command:

$ SHOW TERMINAL/X29

X.29 Terminal: _NVA1:     Network.Remote DTE: 000056789010

   Interrupt action: String: ’\^Y’ Flags: Purge type ahead
   Break action:     String: ’\^O’ Flags: None
   Hold timer:       0

PAD parameters:
    PAD escape               No Echo
    Forward on buffer full   Forward on ’\^A’-’\^_’
    Forward on ’DEL’         Timeout 1
    Hostsync for data        PAD prompt
    PAD messages             Interrupt on break
    Send indication of break Discard output on break
    Normal output            No CRfill
    No Wrap                  Speed: 9600
    TTsync                   No Newlines
    No LFfill                No PAD Editing
    Delete char ’DEL’        Line delete ’\^U’
    Redisplay line ’\^R’     Scope edit display
    Do not echo ’\^A’-’\^L’  Do not echo ’\^N’-’\^_’
    Do not echo edit keys    Do not echo ’DEL’
    No Parity                No Page Wait

To display the PAD parameters and their values in numeric form for an X.29 terminal, use the SHOW TERMINAL/X29/NUMERIC command:

$ SHOW TERMINAL/X29/NUMERIC

X.29 Terminal: _NVA1:     Network.Remote DTE: 000056789010

    Interrupt action: String: ’\^Y’ Flags: Purge type ahead
    Break action:     String: ’\^O’ Flags: None
    Hold timer:       0

PAD parameters:
      1 =   1 (Escape character)         2 =   0 (Echo)
      3 = 126 (Forwarding characters)    4 =   1 (Timeout)
      5 =   1 (Hostsync)                 6 =   5 (Messages)
      7 =  21 (Break)                    8 =   0 (Discard output)
      9 =   0 (CRfill)                  10 =   0 (Wrap)
     11 =  14 (Speed)                   12 =   1 (TTsync)
     13 =   0 (New line)                14 =   0 (LFfill)
     15 =   0 (Edit)                    16 = 127 (Delete)
     17 =  21 (Line delete)             18 =  18 (Redisplay line)
     19 =   2 (Display edit)            20 = 254 (Restrict echo)
     21 =   0 (Parity)                  22 =   0 (Page wait)

To display the PAD parameter templates and PAD parameter values for an X.29 terminal, use the SHOW TERMINAL/X29/FULL command:

$ SHOW TERMINAL/X29/FULL

X.29 Terminal: _NVA1:     Network.Remote DTE: 000056789010

    Interrupt action: String: ’\^Y’ Flags: Purge type ahead
    Break action:     String: ’\^O’ Flags: None
    Hold timer:       0

Local echo parameter template:
        Parameter             Value   Flags
        ---------             -----   -----
        Echo                      1   None
        Timeout                   0   None
        New line                  4   None
        Edit                      1   None

Host echo parameter template:
        Parameter             Value   Flags
        ---------             -----   -----
        Echo                      0   None
        Timeout                   0   User value
        Wrap                      0   None
        New line                  0   None
        Edit                      0   None

Hangup parameter template:
        Parameter             Value   Flags
        ---------             -----   -----
        Echo                      1   None
        Timeout                   0   None
        Edit                      1   None

PAD parameters:
    PAD escape               No Echo
    Forward on buffer full   Forward on ’\^A’-’\^_’
    Forward on ’DEL’         Timeout 1
    Hostsync for data        PAD prompt
    PAD messages             Interrupt on break
    Send indication of break Discard output on break
    Normal output            No CRfill
    No Wrap                  Speed: 9600
    TTsync                   No Newlines
    No LFfill                No PAD Editing
    Delete char ’DEL’        Line delete ’\^U’
    Redisplay line ’\^R’     Scope edit display
    Do not echo ’\^A’-’\^L’  Do not echo ’\^N’-’\^_’
    Do not echo edit keys    Do not echo ’DEL’
    No Parity                No Page Wait

There are two ways to set up an X.29 terminal as a spooled device:

Section 12.2, “Command Procedure to Spool the Current Terminal” and Section 12.3, “Command Procedure to Set Up the NV Device as a Terminal Queue” contain example command procedures that you can use to spool an X.29 terminal.

The following command procedure spools the current terminal as a terminal queue.

$  !
$  !  Spool current interactive terminal as a terminal queue
$  !
$  if f$mode() .eqs. "BATCH" then goto set_up_queue
$
$  priv = f$setprv("log_io,phy_io")
$  term_name = f$getdvi("TT:","tt_phydevnam") - "_" - ":"
$
$  !
$  !  Note that in a cluster this job must be submitted on a
$  !  queue which will run on the same node.
$  !
$  submit/noprint/parameter=’term_name -
    ’f$environment("procedure")
$
$  set terminal/permanent -
    /device=la100/pasthru/notypeahead/form/lower -
    /page=66/width=132/nowrap/nohangup/nomodem
$  if f$getdvi("TT:","tt_disconnect") then disconnect
$  if .not. f$getdvi("TT:","tt_disconnect") then logout
$  exit
$
$  set_up_queue:
$   set process/priv=(oper,phy_io)
$   wait 0:0:30
$   set device ’p1 /spooled
$   initialize/queue ’p1
$   start/queue ’p1/default=(flag=one,noburst)/prot=w=rw
$   exit

The following command procedure sets up the NV device as a terminal queue.

$  !
$  !  Command procedure for X29_SERVER destination
$  !  to spool terminal as a terminal queue
$  !
$
$  set process/privilege=(oper,phy_io)
$
$  open sys_net sys$net
$
$  read sys_net connect_message
$  close sys_net
$  unit = f$cvui(16,16,connect_message)  ! Get NV unit number
$
$  set terminal nva’unit’ /permanent -
    /device=la100/pasthru/notypeahead/form/lower -
    /page=66/width=132/nowrap/nohangup/nomodem
$
$  set device nva’unit’ /spooled
$
$  initialize/queue nva’unit’
$  start/queue nva’unit’ /default=(flag=one,noburst)/prot=w=rw
$