VT interactions involve two systems: the system that initiates the interaction and the system that responds. These two systems are often referred to as the terminal implementation and the host implementation.

With some VT software, terminal and host implementations can both initiate an interaction, or respond to one. With the DECnet-Plus VT software, the terminal implementation can only initiate an interaction, and the host implementation can only respond. Therefore, the documentation refers to these systems as the initiator and the responder.

When an initiator requests a connection to a responder and the responder accepts the request, this is referred to as negotiating an association. Both systems must then agree on the context in which the virtual terminal will exist. This context, the virtual terminal environment (VTE), is a set of predefined values both sides use to translate information (by means of local mapping) that the virtual terminal transfers to both systems. These predefined values describe the capabilities of the Virtual Terminal, such as cursor addressing, forms processing, and color capabilities.

The systems only communicate changes to the conceptual communications area; both sides of the virtual terminal association assume that the rest of the data store's contents remain unchanged. A virtual terminal protocol machine on each side of the virtual terminal association maintains a separate copy of the conceptual communications area.

Figure 1.1, “Components of a VT Interaction” shows the components of a VT interaction.

The user sees no difference between the behavior of VT and that of a terminal directly connected to a responder.

A terminal's needs vary with the application. Virtual terminals meet these needs in virtual terminal environments (VTEs) called profiles.

Each profile has a unique character map, or translation of characters and keys. See Appendix F, Virtual Terminal Profile Mapping for a description of the individual character maps.

Each profile also has a unique name that the initiator sends to the responder to establish a context for data transfer. If the responder supports the specified profile, an association is established; otherwise the responder returns an error message.

A repertoire contains a set of representations of symbols such as numeric, graphic, and control characters. When you specify a profile during a virtual terminal association, it uses a specific repertoire. An example of a repertoire is the American Standard Code for Information Interchange (ASCII) character set. A repertoire could also be a subset of the ASCII character set.

rms-file-designation
appl-address::rms-file-designation
appl-address::"non-rms-file-designation"
appl-address"initiator-id password account"::rms-file-designation
appl-address"initiator-id password account"::"non-rms-file-designation"

The following sections describe the file specification components.

device-name:[directory-name]file-name.file-extension;version-number

On UNIX, the FTAM file-specification format has two components: an application address and a path name. Its syntax is:

application-address::pathname

The FTAM software provides a series of file-specification formats. Select one that meets the needs of a particular situation. The valid formats are:

unix-file-designation

application-address::unix-file-designation

application-address::'non-unix-file-designation'

The following sections describe the file specification components.

alias/user/password/account

On OpenVMS, when the FTAM responder is activated, a log file is created in the home directory of the user specified by the FTAM operation. The name of the log file is OSIF$RESPONDER.LOG.

The OSIF$RESPONDER.LOG log file contains any errors that may be generated by the FTAM responder. It also contains a list of all files that are accessed by an F-OPEN-REQUEST, including the processing mode of the access.

$ copy/app=ftam test.dat amiguita"fencer thrust"::test.dat

On system amiguita, in the home directory of user fencer, there is an OSIF$RESPONDER.LOG file corresponding to the operation that you can use to check on the status of the copy command.

The copying facility allows you to copy a single input file to a single output file, within or between FTAM systems.

The FTAM copying facility operates on any combination of local-to-remote files, remote-to-local files, and remote-to-remote files. However, local-to-local file copies are only supported by the OpenVMS copy command.

On OpenVMS, the copy command has the following format:

copy/app=ftam [/qualifier(s)] input-file-spec [,...] output-file-spec

$ copy/app=ftam test.dat amiguita::"\dir\file"

%COPY-F-OPENIN, error opening AMIGUITA::\DIR\FILE as input
-RMS-F-SYN, file specification syntax error

For a complete description of the copy command and its qualifiers, see Appendix A, FTAM Command Summary (OpenVMS).

On UNIX, the ocp command has the following format:

ocp [options...] [application-address::] file1 [application-address::] file2

% ocp test.dat  lesamies::'test.dat;25'

Note that because the output-file designation is enclosed in single quotation marks ('), the characters entered in the command are retained in the output-file designation sent to the remote FTAM system.

For a complete description of the ocp command and its options, see Appendix B, FTAM Command Summary (UNIX).

% ocp -D FTAM-1 -C General -M 512 petrie::ftam.tst ftam.txt

copy/app=ftam [/qualifier(s)] input-file-spec[,...] appl-address::
copy/app=ftam [/qualifier(s)] input-file-spec[,...] appl-address"initiator-id password account"::

$ copy/app=ftam ftam.txt amiguita::

The FTAM append facility can append multiple input files together to form a new output file through concatenation. Concatenation takes each input file in its input order and appends its contents to the end of the output file. The output file is a new file.

The append facility also allows you to append an input file to a single output file, and concatenate two or more input files to a single output file. (When using FTAM on a UNIX system, the output file must be local.)

On an OpenVMS system, if the output-file designation identifies an existing local file, the new output file receives the next highest version by default.

On a UNIX system, the new output file overwrites the existing file. When concatenating to a remote output file, the effect of specifying an existing remote file name depends on the file management procedures of the remote operating system.

Concatenation primarily affects three RMS file attributes: file organization, record format, and record attributes. Use the directory command to display these attributes for any local or remote file (see Section 2.2.5, “Listing Files”). Taken together, these RMS file attributes equate to an FTAM file attribute called contents type.

During concatenation, the appending facility monitors the contents type of the first input file to determine the contents type of the output file. If the input-file list begins with a wildcard file designation, the output contents type is determined by the file whose file specification is first alphabetically. Note that using wildcards for the local input file succeeds only if the local file designation is compatible with the file-designation format of the remote system. (For an explanation of wildcards, see Section 2.1.1.5, “Using Wildcards with the Directory Facility (OpenVMS)”.)

On OpenVMS, the append command has the following format:

append/app=ftam [/qualifier(s)] input-file-spec [,...] output-file-spec

$ append/app=ftam/new_ver freunde::"^vol>main>file.ext",-
_$ test.dat largetest.dat

%DCL-W-PARMDEL, invalid parameter delimiter - check ... \^VOL\

For a complete description of the append command and its qualifiers, see Appendix A, FTAM Command Summary (OpenVMS).

On UNIX, the ocat command has the following format:

ocat [options...] application-address::file [application-address::file...]

% ocat freunden/fencer/thrust::/usr/user1/file1 > file2

Note the use of user name fencer, and password thrust in the application address of the remote UNIX responder.

The contents of remote files can only be appended by redirecting the output to a local file. You must specify whatever type of information the remote FTAM system requires for specifying files. Refer to the user documentation for the remote FTAM system.

For a complete description of the ocat command and its options, see Appendix B, FTAM Command Summary (UNIX).

$ copy/concatenate/app=ftam *.dat freunde::newfile.dat

%ocp -A petrie::'user2:[ami]ftam.tst' ftam.txt

The delete facility allows you to delete any combination of local or remote files. For local OpenVMS files, you must specify a version number. For remote files, you must specify whatever type of information the remote FTAM system requires for deleting files. Refer to the user documentation for the remote FTAM system.

delete/app=ftam [/qualifier(s)] file-spec[,...]

$ delete/app=ftam amiguita::"/main/sub/file/ext"

For a complete description of the delete command and its qualifiers, see Appendix A, FTAM Command Summary (OpenVMS).

orm [options...] application-address::file [application-address::file...]

% orm -i petrie::ftam.txt
orm: remove ftam.txt? 

If you type y followed by any other character, the file is deleted. Otherwise, the file is not removed.

For a complete description of the orm command and its associated options, see Appendix B, FTAM Command Summary (UNIX).

Each file has a set of file attributes. File attributes are characteristics whose values identify and describe a file and record its history. The FTAM directory facility allows you to display FTAM file attributes for remote files. You can produce a minimal display containing only the FTAM application address and the file designation, or a full display, containing information on all the supported FTAM file attributes.

directory/app=ftam [/qualifier(s)] file-spec [,...]

$ directory/app=ftam amiguita::"\dir\file\ext", test.dat

Directory AMIGUITA::
\DIR\FILE\EXT
Total of 1 file
Directory USER$75:[USERNAME]
TEST.DAT;7
Total of 1 file
Grand total of 2 directories, 2 files.

For a complete description of the directory command and its qualifiers, see Appendix A, FTAM Command Summary (OpenVMS).

ols [options...] application-address::file [application-address::file...]

% ols freunden::/

NBS-9 dr--------        512     Jan 25 14:01 /.
NBS-9 dr--------        512     Jan 25 14:01 /..
NBS-9 dr--------        2048    Jul 30 1996 /bin
NBS-9 dr--------        4608    Jan 28 13:21 /etc
NBS-9 drw-------        512     Jan 30 09:57 /tmp
NBS-9 dr--------        512     Jan 25 15:31 /usr
NBS-9 dr--------        2560    Jan 24 13:01 /dev
FTAM-3 -r--------       3418740 Jan  4 16:11 /vmunix
FTAM-3 -r--------       512     May 23 1996 /var
FTAM-1 -r--------       172     Apr  5 1996 /.profile
FTAM-3 -r--------       512     May 23 1996 /sys
NBS-9 dr--------        512     May 23 1996 /opr
FTAM-3 -r--------       2560    Jan 28 13:27 /lib
FTAM-1 -r--------       89      Apr  1 1996 /.login
FTAM-1 -r--------       241     Apr  1 1996 /.cshrc

For a complete description of the ols command and its associated options, see Appendix B, FTAM Command Summary (UNIX).

The FTAM renaming facility allows you to rename any combination of files. You can change the directory specification, file name, file type, or file version of an existing file. For remote files, you must specify whatever type of information the remote FTAM system requires for specifying files. Refer to the user documentation for the remote FTAM system.

rename/app=ftam [/qualifier] input-file-spec[,...] output-file-spec

$ rename/app=ftam ami::"/main/file" "/new/file"

Note that it is not necessary to include the name of the remote system (ami) in the output file specification because it must be the same system as that of the input file specification.

For a complete description of the rename command and its qualifiers, see Appendix A, FTAM Command Summary (OpenVMS).

omv [options...] application-address::file1 file2

% omv freunden/fencer/thrust::/user1/file2 file1

For a complete description of the omv command and its associated options, see Appendix B, FTAM Command Summary (UNIX).

% ftp gateway-node
Name (gateway-node:): alias::user 
Password (alias::user): password

The name of the user who initiated the FTP session appears next to the gateway node name when the system prompts you for the login name on the FTAM system. The password is not displayed on the screen.

The DECnet–Internet Gateway invokes the FTAM–FTP Gateway if you supply an alias at the username prompt that is in the /etc/isoapplications file, regardless of the application (FTAM or VT) for which the alias is defined.

Different operating systems use different syntax for path names. A path name is the order in which a directory is concatenated to a subdirectory and then concatenated to a file. The syntax is the concatenation character (or characters)used to represent the concatenation.

/usr/users/smith/bin

\usr\users\smith\bin

The FTAM–FTP Gateway always requires an argument to the append, delete, get, put, recv, rename, send, and cd commands. An argument is also required for the ls and dir commands until you specify a path name using the cd command.

To perform FTAM operations on a remote system, you must use a syntax the remote operating system understands. Since the FTAM–FTP Gateway software has no knowledge of what operating system or path name syntax the remote system uses, you must specify which concatenation character (syntax) you will use. This must be done with the quote CCAT command before using any FTAM–FTP command that requires or makes use of an argument.

quote CCAT character

ftp> quote CCAT /

specifies that the slash (/) is used as the concatenation character.

     $ ftp snozar
    Connected to snozar.nac.dec.com.
    220 snozar.nac.dec.com FTP server (Version 4.1 Thu Dec 5 19:16:40 EST 1996) ready.
    Name (snozar:smith): snozar_regtster::smith
    331 Password required for FTAM Gateway access to snozar_regtster.
    Password:
    230 User smith logged in.

     ftp> pwd
    257 "(null)" is current directory.
    ftp> ls
    200 PORT command successful.
    501 Directory path must be specified via the CWD command.

     ftp> cd /tmp
    250 CWD command successful.

     ftp> cd /
    501 Concatenation character must be specified via the quote CCAT
    command.

     ftp> quote CCAT /
    200 Concatenation character is set to ’/’.

     ftp> cd /usr/users/smith
    250 CWD command successful.
    ftp> pwd
    257 "/usr/users/smith" is current directory.

     ftp> ls utils
    200 PORT command successful.
    150 Opening data connection for /usr/users/smith/utils
    (16.20.0.89,1180) (0 bytes).
    /usr/users/smith/utils
    /usr/users/smith/utils/.
    /usr/users/smith/utils/..
    /usr/users/smith/utils/orm_dir
    /usr/users/smith/utils/omv_dir
    /usr/users/smith/utils/ocat_dir
    /usr/users/smith/utils/ocp_dir
    /usr/users/smith/utils/ols_dir
    /usr/users/smith/utils/lis
    /usr/users/smith/utils/ftamd
    226 Transfer complete.
    remote: utils
    316 bytes received in 0.63 seconds (0.49 Kbytes/s)

     ftp> bye
    221 Goodbye.

To use FTP, start an FTP session by issuing the ftp command. The session lasts until you end it with either the quit, close, bye, or disconnect command. During an FTP session, you see the ftp> prompt. You also establish a connection with the remote OSI node that you want to access. Once connected, you can use FTP commands to manipulate files and directories on that node.

The following sections describe specific tasks you can perform using FTP commands.

To access files on a remote OSI node using FTP, you first need to establish a connection to that node. Once you are connected to a node, you can use FTP commands to work with files and directories on that node.

% ftp boston

When the gateway prompts you for a user name, specify the alias of the FTAM system to which you want to connect and your login name on that system. Enter the information in this format:

alias::user

Name (boston::doe): freunde::smith

Password (freunde::smith): secret

% ftp boston
Connected to boston.
220 boston FTP server (Version 4.1 Fri Feb 15 19:42:25 EDT 1996) ready.
Name (boston::doe): freunde::smith
Password (freunde::smith): secret
331 Password required for FTAM gateway access freunde::smith.
230 User smith logged in.
ftp>

ftp> close
221 Goodbye.
ftp>

Note that the close command does not end the FTP session. The Internet connection is still in effect, but the FTAM association is terminated.

While connected to a remote OSI node, you can view different directories on that node, as follows:

ftp> cd /usr/users/smith/memos
250 CWD command successful.
ftp>

ftp> cd
(remote-directory) /usr/user/smith/memos
250 CWD command successful.
ftp>

To return to the home directory after accessing a subdirectory in FTP, specify the full path name and the correct directory syntax with the cd command. You should use the cd command to set your default directory when opening your connection. Doing so allows you to use the ls and dir commands without an argument.

ftp> ls /smith/memos/tasks
200 PORT command successful.
150 Opening data connection for /smith/memos/tasks (123.45.6).
bc.txt
status.sdml
tips.txt
226 TRANSFER COMPLETE.

54 bytes received in 0.83 seconds (0.064 Kbytes/s)
ftp>

ftp> dir tasks
200 PORT command successful.
150 Opening data connection for /smith/memos/tasks (123.45.6).
FTAM-1 -rwx------     29266 Mar 13 1996 bc.txt
FTAM-1 -rw-------     6534 Apr 19 1996 status.sdml
FTAM-1 -rwx------     7718 May 15 12:55 tips.txt
226 TRANSFER COMPLETE.
300 bytes received in 0.71 seconds (0.41 Kbytes/s)
ftp>

ftp> get team.txt -
200 PORT command successful.
150 Opening data connection for
    /smith/memos/team.txt (123.45.6)
This file lists all the reviewers for the book:
Donna
Geeta
John
Larry
Michael
Ravi
Scott
Tracy
226 Transfer complete.
remote: team.txt
111 bytes received in 0.15 seconds (0.72 Kbytes/s)
ftp>

The hyphen indicates that you want the file displayed at the terminal. If you omit the hyphen, the system copies the remote file to your current working directory, without displaying anything.

The recv command works exactly like get.

You can transfer, or copy, ASCII and binary files using ftp commands. Set the FTAM–FTP Gateway file transfer type to ASCII when you transfer ASCII files (FTAM-1 files) and to binary (image mode) when you transfer binary files (FTAM-3 files). ASCII is the default.

You can set the file transfer type using the FTP commands shown in the following examples.

ftp> ascii
200 Type set to A.
ftp>

ftp> binary
200 Type set to I.
ftp>

To display the current settings of the FTP variables, use the status command.

When connected to a remote OSI node, you can copy files to and from that node. To copy a remote file, type either the get or recv command, followed by the remote file name. If you want the local file to have a different name, also specify a local file name. The get and recv commands are interchangeable.

The following examples illustrate the different ways you can copy files with FTP commands.

gateway-alias"user@node password"::"filename"

Note that the file name is enclosed within quotation marks to ensure that the Internet host receives the file name in lowercase letters as required.

% ols gateway-alias/user@node/password::filename

where the format is the same as for OpenVMS, except that the conventions of the UNIX operating system are followed.

From your OpenVMS system prompt, you can use five OpenVMS FTAM commands to work with files and directories on an Internet host: append, copy, delete, directory, and rename. The following sections on gateway-supported OpenVMS FTAM commands explain how to type command lines and which tasks you can perform with these commands.

$ delete/appl=ftam boston"kiko@tokyo secret"::"report.1"

Notice that the file name must be in lowercase type enclosed within quotation marks to ensure that the Internet host receives the file name in lowercase letters as required.

$ rename/appl=ftam boston"a_lima@bean secret"::"team.txt" team.lis 

$ rename/appl=ftam notes.lis boston"a_lima@bean secret"::"notes.lis" 

Note that the file name is enclosed within quotation marks to ensure that the Internet host receives the file name in lowercase letters as required.

To access any remote OSI node in your network that supports OSI Virtual Terminal operations, you must first establish a VT association with that node. An OSI Virtual Terminal responder must already be running on the remote system in order to establish the VT association.

Use the appropriate command to establish a VT association with a remote VT application.

OpenVMS:

set host/vtp application [qualifiers]

application specifies an alias listed in the sys$system:isoapplications.dat file, or an X.500 Distinguished Name. If you supply an X.500 Distinguished Name, you must enclose it in quotes.

If you do not enter a value for application, the software prompts you to do so. See Appendix C, VT Command Summary (OpenVMS) for a complete list of the command qualifiers.

UNIX:

ologin application [options]

application specifies an alias listed in the /etc/isoapplications file, or an X.500 Distinguished Name.

If you do not supply a value for application, then the software displays an error and exits. See Appendix D, VT Command Summary (UNIX) for a complete list of the command options.

Contact your system administrator for the aliases available to you.

If the input is an alias, then it is looked up in the isoapplications file. See Chapter 9, The OSI Application-Entity Database for additional information on aliases and the isoapplications file.

OpenVMS

On OpenVMS, the following examples show the set host/vtp command being used to establish a VT association with the VT applications specified by the alias rnode in sys$system:isoapplications.dat, and the Distinguished Name /c=us/o=abacus/cn=rnode/cn=vtp.

$ set host/vtp rnode /log=myfile.out
$ set host/vtp "/c=us/o=abacus/cn=rnode/cn=vtp:" /log=myfile.out
$ set host/vtp "template=my_template:/c=us/o=abacus/cn=rnode/cn=vtp:" /log=myfile.out

UNIX:

On UNIX, the following examples show the ologin command being used to establish a VT association with the VT applications specified by the alias rnode in /etc/isoapplications, and the Distinguished Name /c=us/o=abacus/cn=rnode/cn=vtp.

% ologin  rnode -o myfile.out
% ologin /c=us/o=abacus/cn=rnode/cn=vtp: -o myfile.out
% ologin template=my_template:/c=us/o=abacus/cn=rnode/cn=vtp: -o myfile.out

Once you have accessed the remote node, you can enter command mode and issue commands to control and monitor the association. Press the appropriate key sequence to enter command mode.

On OpenVMS, enter Ctrl/@, and VT_PAD> appears as the prompt.

On UNIX, enter Ctrl/], and ologin appears as the prompt.

To exit command mode, press Return, or enter resume.

Local> connect service-name [node node-name [destination port-name]]

If you do not specify the gateway node name, the system connects to the first available node that is announcing the LAT/VT Gateway service.

For UNIX, if you specify a remote node name port-name without specifying a gateway node-name, you receive an error message.

See Appendix C, VT Command Summary (OpenVMS) and Appendix D, VT Command Summary (UNIX) for more information on the connect command.

In the following examples, two gateway systems (systems where the LAT/VT Gateways reside) are used. The name of the OpenVMS gateway system is intrpd, and the name of the UNIX gateway system is discvr. The name of the LAT service for the LAT/VT Gateways is LAT_VT_GTWY.

Local> connect lat_vt_gtwy node intrpd

Local> connect lat_vt_gtwy node discvr destination serchr

$ set host/lat lat_vt_gtwy/node=intrpd

$ set host/lat lat_vt_gtwy/node=discvr

See Appendix D, VT Command Summary (UNIX) or enter help set host /lat for more information on the set host/lat command.

See also Appendix C, VT Command Summary (OpenVMS) and Appendix D, VT Command Summary (UNIX) for information on the sethost command to access the LAT/VT Gateway from a PC.

Welcome to the LAT/VT gateway on INTRPD

Enter remote alias name:

At the gateway prompt, enter the alias or the X.500 Distinguished Name of the remote OSI system you want to access. The alias must be known by the gateway system (for example, it must be defined in the isoapplications.dat file on the gateway system). If you enter an X.500 Distinguished Name, be sure to terminate it with a colon (:). After the VT connection is established to the remote system, it prompts you to log in as usual.

UNIX:

A successful LAT connection command to a UNIX gateway system with a remote OSI node alias supplied on the connection command results in the LAT/VT gateway automatically attempting to establish a VT connection with the alias specified. Note that unlike at the gateway prompt, you cannot specify an X.500 Distinguished Name on the LAT connection command; only aliases are accepted.

Welcome to the LAT/VT gateway on discvr.org.com
Connecting to serchr

After the VT connection is established to the remote system, it prompts you to log in as usual.

If your network has one or more VT/LAT Gateways enabled, you can access a remote system that supports the LAT protocol from an OSI system.

The gateway system administrator assigns a unique OSI address to the VT/LAT Gateway and creates an alias pointing to the gateway. To access the gateway, specify the gateway alias on the VT connect command.

In the following examples, intrpd is the name of the OpenVMS gateway system (system where the VT/LAT Gateway resides). The alias defined for the VT/LAT Gateway on the intrpd system is intrpd$lat.

$ set host/vtp intrpd$lat

See Appendix C, VT Command Summary (OpenVMS) for more information on the set host command.

% ologin intrpd$lat

See Appendix D, VT Command Summary (UNIX) for more information on the ologin command.

Welcome to the VT/LAT gateway on INTRPD

Enter LAT service name:

At the gateway prompt, enter the LAT service name of the remote LAT system you want to access. After the LAT connection is established to the remote system, it prompts you to log in as usual.

If your network has one or more Telnet/VT Gateways enabled, you can use the telnet command from an Internet system to access a remote OSI system that has a Virtual Terminal responder installed.

If the gateway system is an OpenVMS system, you may need to specify the port number. The default port number on OpenVMS is 30324. If the gateway system is a UNIX system, you do not need to specify the port number.

In the following examples, two gateway systems (systems where the Telnet/VT Gateways reside) are used. The name of the OpenVMS gateway system is intrpd, and the name of the UNIX gateway system is discvr.

$ telnet intrpd/port=30324
$ telnet intrpd 30324

$ telnet discvr

See Appendix C, VT Command Summary (OpenVMS) or enter help telnet for more information on the telnet command.

% telnet intrpd 30324

% telnet discvr -l serchr::

The -l option on the telnet command specifies the input to the login prompt (see below). The -l option is required on the telnet command if you are logged in to a UNIX system and you want to use the Telnet/VT Gateway that is installed on another UNIX system. Otherwise, telnet automatically specifies your user name at the login prompt.

See Appendix D, VT Command Summary (UNIX) or the telnet(1c) reference page for more information on the telnet command.

Trying...16.63.96.230
Connected to INTRPD
Escape character is ’^]’.

Welcome to the Telnet/VT gateway on INTRPD

Enter remote alias name:

At the gateway prompt, enter the alias or X.500 Distinguished Name of the remote OSI system you want to access. The alias must be known by the gateway system (for example, it must be defined in the isoapplications.dat file on the gateway system). If you enter an X.500 Distinguished Name, be sure to terminate it with a colon (:). After the VT connection is established to the remote system, you are prompted to log in as usual.

Trying...16.62.96.231
Connected to DISCVR.
Escape character is ’^]’.

Digital UNIX (discvr.org.com) (ttyp4)

login:

If you are connecting from a UNIX system, you must supply your response to the login prompt via the -l option on the telnet command. All of the information presented here about the alias entered at the login prompt also applies to the alias entered at the -l option.

At the login prompt (or at the -l), enter the alias of the remote OSI system you want to access, followed by a double colon (::). The alias must be defined on the gateway system. The double colon indicates that you want to connect using the DECnet–Internet Gateway.

The DECnet–Internet Gateway invokes the Telnet/VT Gateway if you supply an alias that is in the /etc/isoapplications file on the gateway system, regardless of the application (FTAM or VT) for which the alias is defined.

If you supply an alias that does not exist in the /etc/isoapplications file, then the gateway software attempts to establish a CTERM connection with the system specified.

$ telnet discvr
Trying...16.62.96.231
Connected to DISCVR.
Escape character is ’^]’.

Digital UNIX (discvr.org.com) (ttyp4)

Login: serchr::

Digital UNIX (serchr.org.com) (ttyp1)

Login: nobel
Password: password

If your network has one or more VT/Telnet Gateways enabled, you can access a remote Internet system that supports the telnet protocol from an OSI system.

For OpenVMS, the gateway system administrator assigns a unique OSI address to the VT/Telnet Gateway and creates an alias pointing to the gateway. To access the gateway, specify the gateway alias on the VT connect command.

In the following examples, two gateway systems (systems where the VT/Telnet Gateways reside) are used. The name of the OpenVMS gateway system is intrpd, and the name of the UNIX gateway system is discvr. The alias defined for the VT/Telnet Gateway on the intrpd system is intrpd$telnet.

$ set host/vtp intrpd$telnet

$ set host/vtp discvr

See Appendix C, VT Command Summary (OpenVMS) for more information on the set host/vtp command.

% ologin intrpd$telnet

% ologin discvr

See Appendix D, VT Command Summary (UNIX) for more information on the ologin command.

Welcome to the VT/Telnet gateway on INTRPD

Enter remote host name:

At the gateway prompt, enter the host name of the remote Internet system you want to access. After the telnet connection is established to the remote system, it prompts you to log in as usual.

UNIX (discvr.org.com) (ttyp4)login:

% ologin discvr

Digital UNIX (discvr.org.com) (ttyp4)

Login: @serchr
Trying...16.63.96.230
Connected to serchr.org.com
Escape character is ’^]’.

Digital UNIX (serchr.org.com) (ttyp1)

Login: root
Password:
root login refused on this terminal.
Login incorrect
Login: nobel
Password: password

If your network has one or more CTERM/VT Gateways enabled, you can access a remote OSI system that has a Virtual Terminal responder installed from a DECnet system.

In the following examples, discvr is the name of the UNIX gateway system (system where the CTERM/VT Gateway resides).

$ set host discvr

% dlogin discvr

Refer to online help for more information on the set host command and see the dlogin(1dn) reference page for more information on the dlogin command.

UNIX (discvr.org.com) (ttyp4)
login:

At the login prompt, enter the alias of the remote OSI system you want to access, followed by a double colon (::). The alias must be defined on the gateway system.

The CTERM/VT Gateway is invoked if you supply an alias at the login prompt that is in the /etc/isoapplications file, regardless of the application (FTAM or VT) for which the alias is defined.

If you supply an alias that does not exist in the /etc/isoapplications file, then the gateway software attempts to establish a CTERM connection with the system specified.

$ set host discvr

UNIX (discvr.org.com) (ttyp4)

Login: serchr::

UNIX (serchr.org.com) (ttyp1)

Login: nobel
Password: password

If your network has one or more VT/CTERM Gateways enabled, you can access a remote DECnet system from an OSI system.

In the following examples, discvr is the name of the UNIX gateway system (the system where the CTERM/VT Gateway resides).

$ set host/vtp discvr

See Appendix C, VT Command Summary (OpenVMS) for more information on the set host/vtp command.

% ologin discvr

See Appendix D, VT Command Summary (UNIX) for more information on the ologin command.

UNIX (discvr.org.com) (ttyp4)
login:

At the login prompt, enter the node name of the remote DECnet system that you want to access, followed by a double colon (::). After the CTERM connection is established to the remote system, it prompts you to log in as usual.

$ set host/vtp discvr

Digital UNIX (discvr.org.com) (ttyp4)

Login: serchr::

Digital UNIX (serchr.org.com) (ttyp1)

Login: nobel
Password: password

DECnet-Plus Virtual Terminal Version 1.0 for VAX ULTRIX and for OpenVMS VAX do not properly handle updates to the SY control object, such as with the SEND SYNCH command. The Version 1.0 responder either aborts the Virtual Terminal connection or gives an error if it receives an SY control object update.

DECnet-Plus Virtual Terminal Version 1.0 for OpenVMS VAX and for RISC ULTRIX does not support the VT-BREAK service as a responder. The Version 1.0 responder aborts the Virtual Terminal association if it receives a VT-BREAK indication.

DECnet-Plus Virtual Terminal Version 1.0 for VAX ULTRIX does not properly support the VT-BREAK service as a responder. Once the VT-BREAK request has been issued, the VT connection hangs if you attempt to log out. You can terminate the Virtual Terminal association by issuing the quit command from local command mode.

When interoperating with DECnet-Plus Virtual Terminal Version 1.0 for OpenVMS, you must use the DCL set terminal command to successfully switch between line mode and character mode, as well to switch into binary mode.

When using the OpenVMS Version 1.0 initiator to communicate with the UNIX responder, enter the DCL command set terminal/eightbit before entering the set host/vtp command.

The Telnet/VT Gateway uses the Generalized Telnet profile. This profile is not supported by DECnet-Plus Virtual Terminal for ULTRIX.

To request or receive indications of a service, peer entities exchange messages called service primitives. A service primitive carries parameter values for a specific service. There are two pairs of service primitives: request and indication primitives and response and confirm primitives. The request and indication primitives exist for all services. The response and confirm primitives, however, exist only for confirmed services. Each pair of service primitives generates only one unit of user data (a protocol data unit or PDU).

Request and response primitives originate with service users, which use those primitives to request services and negotiate parameter values. Indication and confirm primitives originate with service providers, which use those primitives to pass on information that comes in for their users.

The service primitives of each service are interdependent and together form that service. Each type of service has a standard set of primitives, which always occur in a standard order. The following descriptions of service primitives appear in the order of their occurrence. The number beside each primitive reflects the order of its origin. The type of the entity (service user or service provider) that generates a primitive appears alongside the primitive.

Figure 6.1, “Movement of Service Primitives Between Service Users and Providers” illustrates the movement of the service primitives between service users and providers.

Before passing parameter values to a protocol machine, a service implementation verifies whether the parameter values proposed by its service user conform to constraints created by the service definition and the current dialogue.

A service provider delivers services to a service user at an interface called a service access point (SAP). Figure 6.2, “Relationship of a Service User, Service Provider, and SAP ” illustrates the relationship of a service user, a service provider, and a SAP.

Except for the Application and Physical layers, SAPs exist at the boundaries of all OSI layers. SAPs are designated by using the name of their layer; for example, any SAP that the Presentation layer provides is called a Presentation SAP (PSAP). Figure 6.3, “SAP Nomenclature” illustrates SAP nomenclature.

SAPs are logical constructs defined by an identifier called a SAP selector. To create a SAP, a system manager or application user defines a unique SAP selector for a specific layer. SAP selectors are the building blocks of the addresses. A given address takes the name of the uppermost SAP that contributes a selector to the address. For example, a presentation address accesses the Application layer. A presentation address (p-address) contains one or more SAP selectors at the upper layers. The composition of a given address depends on the purpose of the address. For example, an address that allows the Transport layer to access the Application layer contains SAPs at three layers: Transport, Session, and Presentation. A p-address is used for upper-layer addressing and contains SAPs at four layers: Network, Transport, Session, and Presentation.

To help negotiate services between peer entities, service elements or layers classify their services into functional units. A functional unit is a predefined set of interdependent services, which together perform a high-level function such as transferring data. Session, Presentation, ACSE, VT, and FTAM all have functional units. When establishing connections or associations, an entity requests one or more specific functional units of a peer entity. The peer can accept requests only for functional units that it supports.

Two basic asymmetries characterize the roles of FTAM entities during an association: initiator/responder pairs and sender/receiver pairs. The FTAM standard allows FTAM implementations to support either or both of the roles in each pair. The FTAM implementation supports all four roles.

A fundamental goal of FTAM is to accommodate a wide variety of file structures and possible actions on files. However, different vendors' file systems often differ substantially in how they organize, store, and access files. The virtual-filestore model masks local differences by applying a common generalized description of the structure and attributes of files and the actions on them. By describing a file in terms of the virtual-filestore model, an initiator and a responder can establish a common view of any file. This involves each entity establishing a virtual filestore, which is an idealized filestore defined by the virtual-filestore model.

Virtual file stores are mapped to the real filestore of each FTAM system. A real filestore is the actual method of data storage and access on a particular system. For example, the real filestore on a UNIX system is provided by the UNIX File System, and for OpenVMS, by the Record Management Service (RMS).

Figure 7.1, “Relationship Among Filestores During Data Transfer ” illustrates the relationship among the file stores during data transfer. The sender's real filestore is mapped to a virtual filestore before being sent to the receiver. Once sent, the receiver then maps the virtual filestore to its own entity-specific real filestore format.

The virtual-filestore model describes an idealized hierarchical file structure together with its formal properties (file attributes) and possible types of file data (file contents). The model also describes the possible actions on a file (filestore actions). For selecting among these possibilities, the model provides several descriptive mechanisms (access contexts, constraint sets, and document types). For conveying current information about a file and an association, the model provides a set of descriptive properties (activity attributes). The following sections briefly describe each of these elements of the virtual-filestore model.

7.2.2.3. File Structure

The virtual-filestore model defines an idealized file structure called the hierarchical file model. The hierarchical file model recognizes structural elements called nodes, which are ordered into a generalized tree structure. Schematically, this structure is represented as an upside-down tree, with a root node at the top and levels of subordinate nodes beneath. Figure 7.2, “Schematic Representation of a File Tree” shows the schematic structure of a small 3-level tree structure.

The hierarchical file model describes file data as being organized into file-contents data units. A file-contents data unit is a collection of file data that is associated with a specific node in a file. (Not all nodes, however, have associated file-contents data units.) A given file contains zero or more file-contents data units. Figure 7.3, “Relationship of File Data and Structural Nodes” illustrates the relation of file-contents data units to structural nodes.

Files are divided into units called file-access data units. A file-access data unit ( FADU) is a data structure that is made up of one or more nodes and their associated file-contents data units. A FADU includes either a whole file tree or a specific segment of a file tree (subtree). Potentially, any node can be the entry point of a FADU that encompasses the entry node and all of its subordinate nodes. Figure 7.4, “Division of a File into File-Access Data Units (FADUs )” illustrates a possible segmentation of nodes (and their associated file-contents data units) into series of FADUs of decreasing size.

As the examples of file structures in Figure 7.5, “Examples of File Structures” show, the hierarchical file model accommodates a wide range of actual file structures: for example, unstructured, sequential, and hierarchical file structures. An unstructured file has a single node; binary files are often unstructured. A sequential file has an entry node and, directly below it, one or more subordinate nodes; for example, text files are often sequential and each node could represent a separate text record. A hierarchical file has two or more levels of subordinate nodes below its root node.

The file-service model is a description of the communications features that support filestore actions. The file-service model defines services. (For an overview of service concepts, see Section 7.2.3.2, “FTAM Services”.) The model also defines intervals of FTAM communications called regimes, each of which accommodates a distinct set of file services.

7.2.3.1. Regimes

A regime is an interval during which communicating FTAM entities share a common state that accommodates a distinct set of file services. FTAM regimes and their purposes are as follows:

1. The FTAM regime controls the binding of two FTAM entities to an association.

2. The file-selection regime describes the procedure by which an initiator selects and deselects a file. The selection process allows an initiator to create a file and then select it. The deselection process allows an initiator to deselect or delete a file.

   An initiator can select only one file at a time. However, after deselecting a file, the initiator may be able to select another file during an ongoing FTAM regime. Where available, this capability enables manipulation of a series of files during a single FTAM regime. Note that for the FTAM software, each FTAM command initiates a unique association and file-selection regime.

3. The file-open regime controls access to the contents of a currently selected file.

4. The data-transfer regime controls data transfer. A sequence of read, write, or both read and write data-transfer regimes is possible during a given open regime.

Regimes are nested within one another in the same order in which they have just been listed. Figure 7.6, “Nesting of FTAM Regimes” illustrates this nesting order.

An FTAM regime is always the first to be formed and the last to be terminated. Normally, each regime persists until any nested regime ceases, thereby ensuring that files receive predictable and orderly treatment.

7.2.3.3. Relationship of Services to Regimes

Except for the grouping services, each service always occurs within a single type of regime. Furthermore, each constituent service of a regime occurs during a specific phase of the regime. The only other exceptions are the F-P-ABORT and F-U-ABORT services, which can occur at any time once the FTAM regime is established. Figure 7.7, “Relationship of File Services to Regimes” shows the general relationship of services to their regimes.

The FTAM file protocol implements a series of operational rules that govern the FTAM communications and the operations of file services during an association. These rules are implemented by the FTAM protocol machine (FPM). Acting for an initiator, the FPM issues request service primitives, and acting for a responder, the FPM issues indication service primitives.

The FPM ensures that a requested progression of valid file services occurs.

The interplay among the elements of the virtual-filestore and file-service models and the protocol machines allows open systems to build common views of each other's files and to act on each other's files in controlled, mutually understood ways.

For each association, ACSE establishes an application context. An application context is an explicitly identified set of one or more application service elements (in this case, FTAM), related options, and any other necessary information or rules for an association.

When requesting an association, the FTAM protocol machine supplies the information that the FTAM regime requires. Using an association-establishment service (A-ASSOCIATE), ACSE passes this information down to the Presentation layer as user information in a connection request. Presentation then specifies it as user information to Session.

The resulting presentation and session connections have a one-to-one correspondence to the association. A-ASSOCIATE also carries parameters that affect the behavior of Presentation and Session for the current connection. For example, A-ASSOCIATE negotiates which Session functional units are available during a connection.

When the FTAM initiator issues an F-TERMINATE request, ACSE submits an A-RELEASE request to the Presentation release (P-RELEASE) service. This is a confirmed service. If the negotiated-release functional unit is negotiated, the acceptor can refuse the release. Data in transit is preserved.

The addresses of the local FTAM and VT applications can be registered in the X.500 Directory by means of dxim, the DEC X.500 Administration Facility. On UNIX, you can do this by means of the /usr/sbin/osiapplsetup procedure. On OpenVMS, you must register these applications manually.

If you want to configure the FTAM and Virtual Terminal software to work in conjunction with the X.500 Directory, then you must have the base component of the DEC X.500 Directory Service product installed on your system.

On OpenVMS, you must choose the "base kit" component from the DEC X.500 Installation menu.

On UNIX, you must install the DXDABASE nnn (DEC X.500 base) subset, where nnn is the product version number.

Configuring FTAM and VT to retrieve addressing information from the X.500 Directory is optional. The FTAM and VT software does not require that the DEC X.500 Directory Service software be installed for FTAM and VT to work properly.

The rest of the documentation assumes that you are familiar with basic X.500 concepts and terminology. For additional information on the X.500 Directory, or X.500 Directory Service, refer to DEC X.500 Directory Service Management.

The isoapplications file is readable by all, but it can be written to only by a privileged user. The database entries can be modified using any text editor, or on UNIX you can use the /usr/sbin/osiapplsetup procedure. For information on the /usr/sbin/osiapplsetup procedure, see Chapter 12, Managing FTAM and Virtual Terminal (UNIX).

The entries in the isoapplications database must conform to the Address, Distinguished Name, or Pattern formats. See Section 9.2, “Entry Formats in isoapplications” for information on these formats.

Entries of the Address format support the first category of information mentioned in Section 9.1, “About The OSI Applications Database”.

alias :application-name:ap-title:ae-qualifier:psel.ssel.tsel.nsap, transport_options;
                                                             nsap, transport_options;
                                                                :
                                                             nsap, transport_options:

remote_system :FTAM:::psap.ssap.tsap.%x4145418715004108002B0DC29621:

remote_system :VT:::psap.ssap.tsap.%x4145418715004108002B0DC29621:

Table 9.1, “ISO Application-Entity Database Address Format Components” describes each component in the Address format entry.

PSAP..TSAP.NSAP

remote_system :FTAM:::psap.ssap.%x0001.%x4945418715004108002B0DC29621,
\provider=osi,template=default;%x47004AA000400351121,provider=osi,template=cons;
\120.0.0.1.102,provider=rfc1006:

remote_system :VT:::psap.ssap.%x0002.%x4945418715004108002B0DC29621,
\provider=osi,template=default;%x47004AA000400351121,provider=osi,template=cons;
\120.0.0.1.102,provider=rfc1006:

Entries of the Distinguished Name format support the second category of information mentioned in Section 9.1, “About The OSI Applications Database”.

alias   :application-name:transport_template_list:x500_distinguished_name:

The application-name field contains the name of the application associated with the entry. The value of this field can be either FTAM or VT.

template=template1, template2,...:

The x500_distinguished_name field contains an X.500 Distinguished Name of a particular FTAM or Virtual Terminal application. In the X.500 Directory, the object entry identified by this Distinguished Name is associated with a presentation address. The X.500 Distinguished Name is used to query the X.500 Directory for the presentation address of the FTAM or VT application in question.

The colon (:) at the end of the Distinguished Name denotes the end of the Distinguished Name. It is not considered to be a part of the Distinguished Name.

The templates are used in conjunction with the presentation address of the application, as returned by the X.500 Directory. For example, the presentation address of the application may contain more than one NSAP. In establishing a connection with the application, the first template is used with the first NSAP in the presentation address. If the connection attempt fails, then the first template is used with the next NSAP in the presentation address. If there are no more NSAPs to try, the next template in the list of templates is used with the first NSAP in the presentation address, and so on, until either a connection is established with the application or you run out of templates.

foo   :VT:template=template1,template2:/c=us/o=widgetco/cn=alias/cn=vt:

psel.ssel.tsel.nsap1,nsap2,nsap3

template1,  psel.ssel.tsel.nsap1
template1,  psel.ssel.tsel.nsap2
template1,  psel.ssel.tsel.nsap3
template2,  psel.ssel.tsel.nsap1
template2,  psel.ssel.tsel.nsap2
template2,  psel.ssel.tsel.nsap3

Entries of the Pattern format support the second category of information mentioned in Section 9.1, “About The OSI Applications Database”.

*   :application-name:transport_template_list:incomplete_distinguished_name:

The asterisk (*) is a special form of the alias. It is considered to match all input provided to the FTAM and VT commands.

The application-name field contains the name of the application associated with the entry. The value of this field can be either FTAM or VT.

The incomplete_distinguished_name also contains one or more asterisks (*). At run time, each asterisk is replaced by the input provided to the FTAM and VT commands, thereby creating a complete X.500 Distinguished Name. For FTAM, user names and passwords are not included in any of the substitutions.

The x500_distinguished_name field contains the X.500 Distinguished Name of a particular FTAM or Virtual Terminal application. In the X.500 Directory, the object entry identified by this Distinguished Name is associated with a presentation address. The X.500 Distinguished Name is used to query the X.500 Directory for the presentation address of the FTAM or VT application in question.

The colon (:) at the end of the Distinguished Name denotes the end of the Distinguished Name. It is not considered to be a part of the Distinguished Name.

template=template1, template2,...:

See the description in Section 9.2.2, “The Distinguished Name Format” to understand how templates used in conjunction with the presentation address of the application.

*      :VT:template=default:/c=us/o=widgetco/cn=*/cn=vt:

The PSEL and SSEL values in the application address are optional and can be any string, including a hexadecimal string. A hexadecimal string is preceded by %x (or %X). You specify the TSEL value in the same way as the PSEL and SSEL values; however, the TSEL value must be unique for each responder or alias that resides on the same system as another responder or alias. Using the same TSEL value for another alias on the same system can cause addressing problems.

To get the NSAP value for remote systems, ask the system manager or the network manager of the remote system for this information. To get the NSAP value for a local system, use the ncl show osi transport local nsap command.

ncl> show osi transport local nsap * name

Node 0 OSI Transport Local NSAP %X490004AA000400351121
    AT 1991-06-26-16:11:03.775-04:00I0.138

Identifiers

Name                         = %X490004AA000400351121


-------

Node 0 OSI Transport Local NSAP %X4145418715004108002B0DA48721
    AT 1991-06-26-16:11:03.815-04:00I0.138

Identifiers

Name                         = %X4145418715004108002B0DA4872


-------

The X.25 Access module can be set up such that either X.25 NSAPs or X.25 DTE addresses are passed to it. If X.25 NSAPs are passed to the X.25 Access module, specify the NSAP in the alias definition in isoapplications.dat in the normal NSAP location.

local_ftam_nsap  :FTAM:::RMS.FTAM.OSIF.%x103631346175551111,provider=osi,template=osit$loop_cons:

If DTE addresses are passed to the X.25 Access module, you must define a logical name in the OSIT$NAMES logical name table for the DTE of the remote system. You then specify this logical name in the NSAP field of the alias definition in isoapplications.dat.

$ define/table=OSIT$NAMES REMOTE_DTE 031346175551111

local_ftam_dte  :FTAM:::RMS.FTAM.OSIF.REMOTE_DTE,provider=osi,template=osit$loop_cons:

The DECnet-Plus for OpenVMS distribution kit requires that the OpenVMS OSI default account (whose default name is osit$default) has approximately 20,000 units of BYTLM. The FTAM installation procedure locates or creates this default account and ensures that it has sufficient BYTLM.

Refer to your OSAK installation documentation for the required BYTLM quotas.

For a general description of application processes and entities, see Section 7.1, “FTAM Application Processes and Entities ”.

AE-titles for inbound connections are not supported by the OSAK upper-layer software. AE-titles for inbound connections are therefore meaningless to this implementation and consequently cannot be defined in NCL. AE-titles for outbound connections may, however, be meaningful to a remote OSI implementation.

AE-titles for outbound connections may be specified by including the AE-title specification in the sys$system:isoapplications.dat file as part of the alias definition.

For outbound connections, see Chapter 9, The OSI Application-Entity Database for a description on how to define an AE-title.

The local application address is an upper-layer address that contains transport, session, and presentation selectors. Upper-layer addresses take the following format:

p-selector . s-selector . t-selector .

Any of these selectors could be null.

Together, the service access point (SAP) selectors form an upper-layer address for the local FTAM responder. You can create a new address for each remote application by adding it to the osak application database. You can also locate an existing address within this database that you want a remote system to use. Give the selected upper-layer address to the system manager of the remote system. Note that you must also give your system's NSAP to that system manager. For additional information on upper-layer addresses, see Chapter 9, The OSI Application-Entity Database.

This is the name of the FTAM responder command file that is to be executed by the OSAKserver upon receiving an inbound FTAM connection request. A responder command file is mandatory. The installation verification procedure (IVP) creates a responder command file for FTAM called sys$system:osif$responder.com, which you can use in its original form or copy to another file name and adapt to your needs. For example, to research interoperability issues, you might want to modify your osif$responder.com file to enable tracing only under testing conditions.

This is the user name of the OpenVMS account in which inbound connections reside. The responder has owner privileges whenever it runs in a user's account. By default, owner privileges allow complete access to files, which allows the responder to read, write, and delete files. You can restrict these privileges for a given file or directory by using the DCL set protection command.

This is the login password associated with the specified user name. If the user's account is password protected, accessing the FTAM responder requires that both the password and the user name reside in the address database. If the user's account lacks password protection, omit this parameter from the address database.

This is the OpenVMS account name corresponding to the user name. You can specify an account name for billing purposes. Note that OpenVMS ignores the account name. For information about accounts on OpenVMS systems, refer to the DECnet-Plus management documentation.

The OSI standards define five different protocol classes for the Transport layer. These protocol classes are labeled 0, 1, 2, 3, and 4. OSI Transport implements three transport classes (0, 2, and 4). All three classes are available for negotiation at connection time. The class selected is negotiated based on the classes supported by the peer user. In negotiation, the highest class supported by both entities is selected.

The transport options that are available to FTAM include checksums, expedited, extended format, and flow control. You can specify any combination of these options. For more information, refer to your DECnet/OSI for UNIX management documentation.

Remote file access for FTAM is equivalent to remote file access on a DECnet node. The OpenVMS OSI default account serves the same functions as the DECnet default account. The default name of the OpenVMS OSI default account is osit$default.

On OpenVMS operating systems for Version 5.7 and later, you need a password to access the osit$default account.

When the DAP–FTAM Gateway (also referred to as the gateway) is installed, the installation procedure creates the gateway account. The name of the default gateway account is osigtwy and the name of the default directory is [OSIF$GTWY].

Account Parameters

When the gateway account is created, several critical flags and UAF (User Authorization File) fields are set by the installation procedure. For the DAP–FTAM Gateway to function effectively, these should not be modified.

The FAL Session Control Application

The Network Control Language (NCL) database contains a number of session control applications. One of the objects in the NCL database is the file access listener (FAL), which is the target for requests made by remote nodes. A command file (sys$system:fal.exe) is associated with the FAL. This file contains the program or procedure used to start the FAL object.

When FTAM is installed, a file (sys$system:osif$gtwy.com) is created which replaces sys$system:fal.exe in the NCL database. The old file name (sys$system:fal.exe) is then assigned to a symbol that is stored in sys$system:osif$gtwy.com. In the Gateway account's login.com, another symbol is assigned to point to sys$system:osif$gtwy.com.

When a request is directed to the Gateway account, the symbol is redefined to execute the DAP–FTAM Gateway image. However, if the incoming request was directed to any other account, the symbol does not get changed and the old file (sys$system:fal.exe) is executed.

The LAT/VT Gateway has two additional logical names: VT$LAT_SERVICE and VT$LAT_SERVICE_IDENT. VT$LAT_SERVICE specifies the name of the LAT service offered for incoming LAT connections. By default, the service name is LAT_VT_GTWY. VT$LAT_SERVICE_IDENT specifies the identification string for the LAT service. By default, the identification string is "LAT/VT Gateway".

If you want to change these values, you may edit the sys$startup:vt_systart.com file. If the logical name VT$LAT_SERVICE is not defined, the gateway will not allow incoming LAT connections.

The LAT/VT Gateway does not support any LAT options for initiating a LAT connection from the VT environment. If you need special options, you must log in interactively and issue the appropriate set host/lat command.

When you configure local addresses via either the autoconfiguration or manual configuration procedure (refer to DECnet/OSI for UNIX Installation and Configuration Guide), you have the option of adding the FTAM and VT listeners to the /sbin/osi_applstartup file and of starting up those listeners.

The /sbin/osi_applstartup file is executed automatically at system startup time. When executed, the /sbin/osi_applstartup file enables local listeners that wait for incoming connection requests at that particular alias' transport address.

# %ftamvtSTART%echo 'OSI Application Listeners:\c'              >/dev/console
[ -f /usr/sbin/ftam_listener ] &&
{
        echo ' FTAM...\c'

       /usr/sbin/ftam_listener -q 10 serchr   >/dev/console 2>&1
}
[ -f /usr/sbin/vt_listener ] &&
{
        echo ' VT...\c'

          /usr/sbin/vt_listener -q 10 serchr     >/dev/console 2>&1
}
echo ' done.'
# %ftamvtEND%

If you want to start more listeners on your system after completing the installation, you can edit the /sbin/osi_applstartup file by using a text editor, or you can use the /usr/sbin/osiapplsetup procedure to update the file.

If you use osiapplsetup, run the procedure and select option 4, "Add Commands to Start Listeners to /sbin/osi_applstartup". In response to the prompts, enter the FTAM and VT aliases for the local listeners that you want to add with a queue length for each one. The procedure also asks you if you want to start the listeners. Refer to DECnet/OSI for UNIX Installation and Configuration Guide for more information about running osiapplsetup.

If you edit /sbin/osi_applstartup directly, duplicate the lines that invoke the listeners, replace the aliases with the new aliases you want to enable, and rerun the file.

For FTAM, VT, and their listeners to accept inbound connections over both OSI and RFC 1006 networks, you must start separate FTAM and VT listeners for OSI Transport and RFC 1006 Transport.

Use the /usr/sbin/osiapplsetup procedure to configure the OSI and RFC 1006 Transport aliases for the local listeners. With both the autoconfiguration and manual configuration procedures, you have the option of defining aliases in /etc/isoapplications for both OSI Transport listeners and RFC 1006 Transport listeners. Refer to DECnet/OSI for UNIX Installation and Configuration Guide for more information.

The alias name provided to the OSI Transport listeners must contain an OSINSAP. The OSI Transport listeners will accept connections from both CLNS and CONS/X.25. The alias name provided to the RFC 1006 Transport listeners must contain an NSAP address in the form of an Internet address. See Section 9.1, “About The OSI Applications Database” for more information about NSAP and Internet addresses.

Error during call to XTI service t_close Connection refused

For more information on managing the RFC 1006 daemon, refer to your DECnet-Plus programming documentation.

You may start local FTAM and VT listeners by either running the /usr/sbin/osiapplsetup procedure or by executing listener commands directly.

If you use osiapplsetup, run the procedure, choose option 2, "Manually Configure Local Addresses" from the main menu, and then choose option 5, "Start Listeners" from the manual configuration menu. In response to the prompts, enter the FTAM and VT aliases for the listeners that you want to start with a queue length for each one.

/usr/sbin/ftam_listener [-q queue-length] [-r responder [-T trace-file]] alias

/usr/sbin/vt_listener [-q queue-length] [-r responder] alias

If you are a superuser, you can start and stop the listener by issuing commands on the command line. To start a listener, issue the listener command with the appropriate options as follows.

# /usr/sbin/ftam_listener [-q queue-length] [-r responder] alias

# /usr/sbin/vt_listener [-q queue-length] [-r responder] alias

The FTAM or VT listener may pause before you are returned to the shell prompt. The listener is ready to accept incoming connections only after you are returned to the shell prompt.

To stop a listener, you need to determine its process identifier (PID) and then terminate that process by using the following commands.

% ps axuw | grep ftam_listener
            .
            .
            .
# kill pid

% ps axuw | grep vt_listener
            .
            .
            .
# kill pid

Where the pid is the PID of the listener that you want to stop.

If you have the DEC X.500 Directory Service product installed on your system, you may register the addresses of the local FTAM and VT listeners in the X.500 Directory. Do this by either running the /usr/sbin/osiapplsetup procedure or by executing DEC X.500 Administration Facility (dxim) commands manually.

If you use osiapplsetup, run the procedure, choose option 2, "Manually Configure Local Addresses" from the main menu, and then choose option 4, "Register Listeners in X.500 Directory" from the manual configuration menu. In response to the prompts, enter the information needed to complete the X.500 Distinguished Names for the listeners. The osiapplsetup procedure also asks if you want to add aliases to /etc/isoapplications for the X.500 entries of the local listeners.

dxim create entry /c=country/o=org/ou=org_unit/cn=node attributes \
    objectclass=applicationProcess
dxim create entry /c=country/o=org/ou=org_unit/cn=node/cn=ftam attributes \
    objectclass=applicationEntity, \
    presentationaddress="'0001'H/'0001'H/'0001'H/NS+4700240408002BBC4EC321"
dxim create entry /c=country/o=org/ou=org_unit/cn=node/cn=vt attributes \
    objectclass=applicationEntity, \
    presentationaddress="'0001'H/'0001'H/'0002'H/NS+4700240408002BBC4EC321"

/usr/sbin/ftam_listener -r /usr/sbin/ftam2ftpd alias

The alias is the name you use to represent the gateway host system. This entry must be in the /etc/isoapplications file.

The part of the FTAM–FTP Gateway that translates FTP protocol messages into FTAM protocol messages is the FTP–FTAM daemon (/usr/sbin/ftp2ftamd). The FTAM–FTP Gateway is an integral part of the DECnet–Internet Gateway and provides transparent access to OSI networks from the Internet. The DECnet–Internet Gateway examines login information specified by the FTP client and determines which gateway is invoked. The DECnet–Internet Gateway supports Internet File Transfer Protocol (FTP), DECnet Data Access Protocol (DAP), and OSI File Transfer, Access, and Management (FTAM) protocols.

Because the format of the FTAM–FTP Gateway file specification is the same as that of the DECnet–Internet Gateway, this information determines the protocol that should be supported. If the specified login information does not contain a pair of colons (::), then an FTP daemon is started for the user. If colons are included, the DECnet–Internet Gateway searches for the name to the left of the colons in the /etc/isoapplications file. If the name is not found in the file, the name is a DECnet node name and the DECnet–Internet daemon is started. If the name is in the file, the name is an FTAM alias and the FTP–FTAM daemon is started.

$ ncl := mcr ncl

$ ncl
ncl> sho osi transport template * all

Determine from the following chart which network service to use. Then you must either request that your system manager create a transport template for that service, or use NET$CONFIGURE to create the template yourself.