# DIGITAL TCP/IP Services for OpenVMS
Concepts and Planning

Previous | Contents

The DIGITAL TCP/IP Services for OpenVMS product supports both TCP and UDP.

Transmission Control Protocol

TCP provides connection-oriented, reliable, sequenced data transfers between local or remote hosts. Before transmitting data, participants must establish a connection. TCP guarantees that data reaches its destination, and retransmits any data that does not get through.

User Datagram Protocol

UDP provides connectionless data transfers between local and remote hosts. It allows application programs to send and receive datagrams to applications that reside on a different host. UDP adds a checksum and addressing information, then uses IP to deliver the datagrams. UDP provides fast communications for applications that do not require delivery receipts at the Transport layer.

# 1.6 Application Layer

The user interacts with network applications at the Application layer. Data is received as commands from the user and as data from the network application on the other end of the connection. TCP/IP applications communicate in client/server pairs at this layer.

Because of the large number of Application layer protocols supported by the DIGITAL TCP/IP for OpenVMS product, it is useful to group them in five general categories:

- Remote computing
- File transfer
- Resource sharing
- Electronic mail
- Network services

Sections 1.6.1 through 1.6.5 include summaries of each of the primary Application level components included in the UCX product. See the DIGITAL TCP/IP Services for OpenVMS User's Guide for detailed user information about remote computing, file transfer, resource sharing, and electronic mail components and the DIGITAL TCP/IP Services for OpenVMS Management guide for network services information and tools.

## 1.6.1 Remote Computing

Remote computing applications enable networked users to run software on remote systems. UCX includes the following remote computing application components:

- TELNET provides remote login to other hosts in the network.
- RLOGIN command provides remote login.
- RSH command provides remote shell capabilities.
- REXEC command allows users to execute commands to a remote host.
- RMT and RCD commands allow remote users to access tape or CD drives.
- Finger utility displays user information.

TELNET

TELNET is a standard protocol that provides remote terminal connection or login service. TELNET enables users at one site to interact with a remote system at another site, as if the user terminals were connected directly to the remote system.

The DIGITAL TCP/IP Services for OpenVMS product implements TELNET to provide:

- Simultaneous multiple sessions
- IBM 3270 model terminal emulation (TN3270)
- Two supported interface formats:
  - DCL-style
  - UNIX-style

Remote Commands

The remote commands, called R commands, enable users to work in accounts on remote internet hosts that are either UNIX or other OpenVMS systems. The DIGITAL TCP/IP Services for OpenVMS software supports the RLOGIN, RSH, REXEC, and RMT/RCD commands, as explained below. Users issue these commands at the system command line prompt ($).

Remote Command | Function
--- | ---
RLOGIN | Allows users of one system to log into other systems across an internet and interact as if they were directly connected. RLOGIN offers the same service as TELNET, except it also passes information about the user's environment, such as the user identification, to the remote system.
RSH | Allows users to send a command, shell script, or command procedure to a remote host for execution. RSH does not require login to the remote host to execute commands.
REXEC | Authenticates and executes the R commands that users issue based on password information stored in the user authentication file (UAF).
RMT/RCD | Allows remote users to access magnetic tape and CD drives.

For detailed information about the RLOGIN, RSH, and REXEC commands, see the DIGITAL TCP/IP Services for OpenVMS User's Guide. For information about RMT/RCD, see the DIGITAL TCP/IP Services for OpenVMS Management guide.

Finger Utility

The Finger utility is implemented by the FINGER command, which displays information about users on the local or remote system. By default, information about each user on the host is displayed.

When you specify a user name or a list of user names with the FINGER command, the Finger utility returns the following information:

- Full name
- Account name
- Program the user is running
- User's home directory
- Any plan in the file named .PLAN in the user's home directory
- The project on which the user is working from the file named .PROJECT in the user's home directory

If you do not specify a host, the information listed is about users on the local host; otherwise, the information is about users at the specified host. You can specify a user on a remote host by using the form user@host. If you specify @host, the standard format listing is displayed on the remote system. The specified host must have the Finger service enabled.

## 1.6.2 File Transfer

The DIGITAL TCP/IP Services for OpenVMS product includes the following file transfer components that let users transfer data files between local and remote systems:

- FTP (File Transfer Protocol) transfers files between hosts.
- Trivial File Transfer Protocol (TFTP) downloads and transfers files.
- The remote copy (rcp) command copies files to or from remote hosts.

File Transfer Protocol

FTP is a TCP/IP standard, high-level protocol used to transfer files bi-directionally. FTP enables users to interactively access files, list directories on a remote host, delete and rename files on the remote host, and transfer files between hosts using a wildcard character.

FTP also provides authentication control, which requires users or clients to correctly enter a login name and password to the server before requesting file transfers. The server can refuse access due to invalid login and password combinations.

FTP allows users who do not have a login name or a password to access certain files on a system using an anonymous login name. This functionality is called anonymous FTP and may include the following restrictions:

- Limited browsing through the file system. Users may have access only to the anonymous guest, or "home," directory and a public directory. The public directory may contain general bulletin information to which the user has read-only access.
- Accessing files from (get) or copying files to (put) the guest directory only.
- Accessing files (get) from the public directory only.
- Deleting privileges for files in the guest directory that are owned by the anonymous account.

Trivial File Transfer Protocol

TFTP provides a simple, unsophisticated file transfer service. It is intended for applications that do not need complex interactions between a client and server. TFTP is small and can be encoded in read-only memory to obtain a bootstrap program. TFTP allows the bootstrapping code to use the same underlying protocols that the operating system uses once it begins execution. This makes it possible for one host to boot from a server on another physical network.

The DIGITAL TCP/IP Services for OpenVMS product supports downloading of system images and other types of information for requesting client hosts with TFTP.

## 1.6.3 Resource Sharing

Resource sharing lets users access remote system resources such as disk storage space or printers as if they were directly connected to the user's local systems. With resource sharing, users can access these resources directly after the initial connection is made. This is different from file transfer programs where files must be completely transferred from the remote system before they can be used.

The resource-sharing components of DIGITAL TCP/IP Services for OpenVMS include:

- Line printer/line printer daemon (LPR/LPD), which provides print services to remote and local hosts.
- TELNET Print Symbiont (TELNETSYM), which provides for remote printing using the TELNET protocol.
- Network File System (NFS) and PC-NFSd, which authenticate requests and provide access to remote files.

Line Printer Protocol and Line Printer Daemon Protocol

The DIGITAL TCP/IP Services for OpenVMS software provides network printing through LPR/LPD. LPD provides remote printing services for UNIX and OpenVMS client hosts. Each print queue is either local or remote. Local print queues handle inbound jobs. Remote print queues handle outbound jobs for remote printers.

The print setup utility (UCX$LPRSETUP) provides the following capabilities:

- Updates the related printcap database
- Creates and starts queues
- Allows you to add commands to the automatic startup and shutdown command procedures

To print, users at an OpenVMS client issue the DCL-style PRINT command.

Users working on UNIX clients typically issue the lpr command.

TELNET Print Symbiont

The TELNET print symbiont (TELNETSYM) provides remote printing using the TELNET protocol. With TELNETSYM, the local OpenVMS system drives a remote printer as if it were directly connected. This is achieved by attaching a printer to a remote TCP/IP terminal server.

The TELNET print symbiont has the following functions:

- Transfers record-oriented data to and from disks and printers
- Configures printers attached to terminal servers that support TELNET
- Supports outbound functions (to a remote printer) and offers preformatting to outbound print jobs

> Note

> TELNET does not work with terminal servers that use only the local area transport (LAT) protocol.

The system that originates the print jobs handles the standard print control functions, such as header page generation, pagination, queuing, and handling of multiple forms.

TELNET printing allows the standard OpenVMS output format features not available with the LPR/LPD service. The /ON="UCX$QUEUE=name" qualifier allows you to requeue a job to another local OpenVMS queue after formatting, rather than using TELNET to send the job across the network.

For detailed information on configuring and managing TELNETSYM, see the DIGITAL TCP/IP Services for OpenVMS Management guide.

Network File System

NFS is a protocol developed by Sun Microsystems, Inc., that uses IP to allow computers to access remote files as if they were local files. With NFS, when you access files and directories from a remote system, they appear to reside on your local system regardless of operating system, hardware type, or architectural differences between the local and remote systems.

This is accomplished in a client/server environment where specific implementations of NFS exist on both the client and the server machines. In its simplest form, here is how it works: When an application program executes, it calls the operating system to open a file. If the file does not reside on the local system, the request is passed to the NFS client, which knows how to contact the NFS server on the remote machine. The remote machine then performs the requested operation and replies to the client software.

In addition to NFS server and NFS client software, the DIGITAL TCP/IP Services for OpenVMS product includes PC-NFS daemon software for sharing files with personal computers. The functions of NFS server, NFS client, and PC-NFS are summarized in Table 1-2.

Table 1-2 NFS Components
NFS Component | Function
--- | ---
NFS server | Enables remote users to access files that physically reside on an OpenVMS system running UCX software. The remote host must support an NFS client. UNIX supports only sequential, byte-stream file formats. OpenVMS supports index, relative, and sequential files that have various record formats. The DIGITAL TCP/IP Services for OpenVMS implementation of NFS allows access to the following record formats: Fixed length Variable length Variable with fixed-length control (VFC) Stream (including STREAM_LF and STREAM_CR) Undefined
NFS client | Accepts file operation requests from the operating system and contacts the appropriate NFS server on the remote system to perform the requested operation. Supports STREAM_LF formatted files.
PC-NFS daemon | Allows the NFS client software to run on a personal computer. A PC using the NFS client mounts a remote UNIX, OpenVMS, or mainframe disk volume and accesses files as if they reside locally on the PC. The PC-NFS daemon software provides: Authentication Network security in the NFS model is accomplished by identifying every user with a user identification (UID) and group identification (GID) pair. Personal computers, lacking this information, must request their UID and GID from a remote server. They obtain this information from the UCX proxy database. With this information, PC users can then mount remote NFS file systems. Printing From your PC, you can: Associate a DOS or Windows printer name with an OpenVMS print queue Print a file to the associated queue From the OpenVMS server, you can: List queued jobs Cancel queued jobs Obtain a list of available print queues Obtain the status of a particular print queue On the OpenVMS system, you can log into a privileged account or to the same account your PC uses as its proxy account.

## 1.6.4 Electronic Mail

Communication functions such as electronic mail are vital both within an organizational internetwork and across the worldwide Internet. The electronic mail components of DIGITAL TCP/IP Services for OpenVMS are:

- Simple Mail Transfer Protocol (SMTP) for electronic mail
- Post Office Protocol (POP) to store electronic mail for PC users

Simple Mail Transfer Protocol

SMTP is the TCP/IP standard protocol for transferring electronic mail messages from one system to another. SMTP specifies how systems interact and the format of the mail messages they exchange. The UCX SMTP implementation uses the OpenVMS mail facility.

With OpenVMS Versions 6.2 and later, the OpenVMS mail facility automatically recognizes an SMTP host address, as shown in the following example:

    $ MAIL
    MAIL> SEND
    To:    jones@widgets.com

With SMTP mailing lists, you can send electronic mail messages to multiple users. The mailing list is a file with SMTP-style addresses of mail recipients.

An SMTP mailing list, as implemented by UCX, is considered an "alias." It operates by "forwarding" rather than by "redistributing" the mail message.

Post Office Protocol (POP)

The DIGITAL TCP/IP Services for OpenVMS Post Office Protocol (POP) server and the SMTP server work together to provide a reliable mail service.

POP is a mail repository used primarily by PCs to ensure that mail is accepted even when the PC is turned off. With POP, the PC user need not be concerned with configuring the system as an SMTP server. The user logs into the client system's mail application, and the POP server forwards any new mail messages from the OpenVMS NEWMAIL folder.

The POP server is an OpenVMS implementation of the Post Office Protocol, Version 3 (RFC 1725), and is based on the Indiana University POP server (IUPOP3).

## 1.6.5 Network Services

The DIGITAL TCP/IP Services for OpenVMS product provides services that are used by system or network managers rather than directly by users. The following TCP/IP management protocols and services enable the UCX network manager to provide consistent, reliable, and efficient network services with minimal interruption:

- Simple Network Management Protocol (SNMP) to monitor and manage network devices (particularly routers and servers) from across an internetwork
- Network Time Protocol (NTP) to synchronize time between hosts in a TCP/IP network
- Berkeley Internet Name Domain (BIND), a name and address resolution service to distribute and manage host information so that hosts do not need to know the address of every other host on the internet
- Portmapper service to enable client programs to determine port numbers that another service uses
- Auxiliary server to simplify application writing and manage overhead
- Bootstrap Protocol (BOOTP) to answer bootstrap requests from remote devices

Simple Network Management Protocol

SNMP uses the network management data standard known as the Management Information Base (MIB) to monitor gateways, networks, and hosts. The MIB specifies information about a host's network objects; information that a gateway or network management station needs in order to manage that host.

DIGITAL TCP/IP Services for OpenVMS implements an SNMP Version 1 agent and two subagents: a subset of the Host Resources MIB and MIB II. Configuring the SNMP agent on your system allows a remote SNMP network management station (also known as network management director) to obtain information about your host and set network parameters.

When a management station or other SNMP management entity first sends a request to your host, the auxiliary server invokes the SNMP agent. From then on, the agent listens for incoming requests at port 161 and responds with requested MIB data. Authentication is limited to the validation of the community name and the associated address.

The DIGITAL TCP/IP Services for OpenVMS implementation of SNMP includes an application programming interface (API) for programmers to create subagents for their specific applications. See Section 1.7 for more information about the SNMP API.

For more information on SNMP, see the DIGITAL TCP/IP Services for OpenVMS eSNMP Programming and Reference guide.

Network Time Protocol

NTP is used to synchronize the time between a computer client or server and another server or reference time source such as a radio, satellite receiver, or modem. Synchronized timekeeping means that hosts with accurate system time send accurate time quotes to each other. Hosts running NTP are either time servers or clients.

Time synchronization is important in client/server computing. For example, systems that share common databases require coordinated transaction processing and time-stamping of instrumental data.

Domain Name Service (BIND Service)

The Domain Name Service (DNS) is a distributed database system that enables TCP/IP applications to convert --- or resolve --- a host name into a correct IP address. UCX implements DNS with the Berkeley Internet Name Domain (BIND) software.

BIND software, based on a client/server model, is a lookup service for the internet. BIND is divided into two components: a resolver and a name server. The resolver queries a name server and the name server responds to a resolver query:

BIND Component | Function
--- | ---
BIND resolver | Client software that requests host names, addresses, and other network information from BIND servers that maintain extensive information, rather than from the more limited local database.
BIND server | Server software that translates host names into numeric Internet addresses and numeric Internet addresses into host names. BIND servers maintain databases of host names, addresses, mail records, text records, and other network objects. When client systems require this information, they query the servers with the BIND resolver.

Portmapper

Internet hosts can simultaneously run multiple industry-standard and custom-developed services. With the portmapper, you do not need to preconfigure client applications with port numbers for each service. Instead, each server registers itself and the portmapper allocates the port. Each server process listens for connections on a designated port.

The portmapper maintains a database of the following:

- Registered server programs
- Unique identifiers for each server program (program number)
- Port numbers for the server program

Remote clients request port numbers to connect to particular applications.

Auxiliary Server

The DIGITAL TCP/IP Services for OpenVMS product implements the portmapper, or inetd function, through the security and event and error logging of the auxiliary server process. The auxiliary server simplifies application writing and manages overhead by reducing simultaneous server processes on the system. In addition, the auxiliary server does the following:

- Eliminates high overhead due to nonstop running of all service processes
- Uses proxy and service databases to provide system security through authentication of service requests
- Supports event and error logging

Bootstrap Protocol

Every computer attached to a TCP/IP internet needs to know its IP address before it can send or receive datagrams. Network booting with BOOTP allows a diskless machine to determine its IP address at startup so it can connect to an internet. BOOTP also allows the computer to determine the address of file servers that store and retrieve data and the address of the nearest IP gateway.

BOOTP uses UDP to transport information. A single BOOTP message specifies items needed at startup, including the IP address, gateway address, server address, and a field for general-purpose or vendor-specific information, such as subnet masks or hardware information.

# 1.7 Additional UCX Management and Programming Features

In addition to standard TCP/IP protocols, the DIGITAL TCP/IP Services for OpenVMS software provides the following mechanisms for managing the UCX software and developing customized applications:

- Configuration procedure
- UCX Management Control Program (UCP)
- Startup and shutdown command procedures
- Logical names
- Application programming interfaces
- Application support

Configuration Procedure

The configuration procedure is a menu-driven command file that you use to enable the DIGITAL TCP/IP Services for OpenVMS software components. See the DIGITAL TCP/IP Services for OpenVMS Installation and Configuration guide for more information about the menu-driven configuration procedure.

Management Control Program

The UCX Management Control Program is a comprehensive, easy-to-use network management tool that includes over 100 OpenVMS-style commands. These commands allow you to locally configure, monitor, and tune UCX components and to write customized applications by issuing management commands at the UCX> prompt.

To invoke the program, enter:

    $ UCX

You can use the UCX Management Control Program to manage most components of UCX.

Startup and Shutdown Command Procedures

The management tools include startup and shutdown command procedures for all the components. The configuration procedure automatically runs these command procedures. The system manager can also run the procedures.

Logical Names

The DIGITAL TCP/IP Services for OpenVMS product provides logical names to help manage various applications, such as FTP, NFS, and SMTP. Logical names are short names assigned to a portion or an entire file specification or to a command that decreases the keystrokes necessary to complete a task. These logical names are for use by both local and remote OpenVMS users and provide backward compatibility with prior releases of DIGITAL TCP/IP Services for OpenVMS. Sometimes logical names manage UCX applications when there are no applicable UCX management commands.

For more information about how individual components use logical names, see the DIGITAL TCP/IP Services for OpenVMS Management guide.

Application Programming Interfaces

The DIGITAL TCP/IP Services for OpenVMS product supports the following application programming interfaces (APIs) for developing customized applications:

- $QIO programming interface
  Extends OpenVMS system services for socket communications. Sockets provide access to IP, TCP, and UDP. $QIO supports any programming language.
- SRI $QIO programming interface
  An SRI $QIO emulator that translates older, non-UCX $QIO interfaces first developed at Stanford Research Institute (SRI) in 1980--81 into $QIO programming interfaces.
- Standard C Sockets interface and C Sockets library
  Provides UNIX-like access to the TCP, UDP, and raw IP protocols. The C sockets interface supports the C programming language, which helps with portability of applications between OpenVMS and UNIX systems.
  This interface is integrated with both the DEC C Run-Time Library and VAX C Run-Time Library.
- Sun RPC programming interface
  An industry-standard, portable API that is an efficient alternative to application development with sockets. Programmers do not need an in-depth knowledge of networking protocols.
  You can program with this API using all data types, regardless of their byte order, floating-point presentation, string representation, or alignment.
  This API includes:
  - Library of RPC function calls
  - Portmapper service
  - External data representation (XDR) routines
- eSNMP programming interface
  Provides the following eSNMP routines:
  - Basic protocol data unit (PDU) handling
  - Authentication handling
  - Variable binding handling
  - Object identifier handling
  - MIB interface
  - Program control
  - Clock control
  - Terminal printing
  - Access control handling
  - eSNMP packet transmission and reception

Previous | Next | Contents