HP OpenVMS Systems Documentation

The Local namespace is a discrete, nondistributed namespace that exists on a single node and provides that node with a local database of name and addressing information. Depending on the number of address towers stored, the Local names are designed to scale to at least 100,000 nodes.

The DECdns distributed namespace is not a requirement of DECnet-Plus, and is not dependent on DECdns. However, the DECdns clerk software is still required on each node. Use decnet_register to manage the node name and address information stored in your namespace. The decnet_register tool is described in the DECnet-Plus for OpenVMS Network Management guide.

2.2.8 Time Service

The DIGITAL Distributed Time Service (DECdts) synchronizes the system clocks in computers connected by a network. DECdts enables distributed applications to execute in the proper sequence even though they run on different systems.

The DECnet-Plus for OpenVMS configuration procedure autoconfigures the DECdts clerk software. If your network uses multiple DECdns servers, or if you need network clock sychronization, DIGITAL recommends that you install at least three DECdts servers on each LAN.

2.3 X.25

X.25 is a CCITT recommendation that specifies the interface to packet switching data networks (PSDNs). It implements the lower three layers of the OSI Reference Model. Conceptual information about X.25 is provided in Chapter 4, and platform-specific information is provided in the X.25 for OpenVMS Management Guide.

Figure 2-2 shows the relationship between the individual components in the DECnet-Plus environment on an OpenVMS system.

Figure 2-2 Component Relationships

The X.25 native software allows suitably configured DECnet-Plus systems to connect to packet switching data networks (PSDNs) conforming to CCITT recommendation X.25 (1980 or 1984) and/or to international standards ISO 7776 and 8208. This allows a DECnet-Plus system to function as data terminal equipment (DTE) or be addressed as data circuit-terminating equipment (DCE) as follows:

• A packet-mode DTE connected to a supported PSDN conforming to CCITT Recommendation X.25 (1980, 1984)
• A packet-mode DTE connected to a CSMA-CD LAN conforming to ISO 8802-3 using ISO logical link control type 2 (LLC2) as specified in ISO 8881
• A packet-mode DTE/DCE connected to a DCE/DTE conforming to ISO 7776 and 8208

X.25 can be configured for native operation to support direct connections from a VAX system to one or more PSDNs, each of which may have one or more DTEs. It also allows communication with any non-DIGITAL X.25 system on the same LAN that supports the ISO logical link control type 2 (LLC2) protocol.

2.3.2 X.25 Access Software

X.25 Access uses a connector node to provide the physical connection to a PSDN. A connector node can be a DECNIS router 500 or 600 or X.25 configured in multihost mode.

DECnet-Plus logical links are established by OpenVMS to connect the X.25 Access system to the X.25 Connector system. These links may use any supported DECnet-Plus communications path between the X.25 Access system and the Connector system, provided they themselves do not use an X.25 connection. X.25 Access uses these links to transmit X.25 or X.29 messages between the Connector system and the X.25 Access system.

X.25 software provides Connection-Oriented Network Service (CONS) to allow mapping between a destination NSAP address and a destination DTE address according to ISO 8348.

The X.25 software can be used in the following ways:

• Process-to-process (X.25) communications
• Process-to-terminal (X.29) communications
• Terminal-to-process (X.29) communications

The WAN device drivers included in DECnet-Plus for OpenVMS support synchronous communications. The device drivers all offer a supported user ($QIO) interface.

The device drivers all support full-duplex and half-duplex operation, where appropriate to the protocol. See the Software Product Description (SPD) for supported device drivers.

WAN device drivers include a pseudodriver (WANDRIVER) that provides a programming interface to the data link level for the LAPB, DIGITAL HDLC, and DDCMP protocols.

2.5 OSAK

The OSI Applications Kernel (OSAK) software allows you to run applications that can communicate with other applications running in an OSI environment. These applications can be DIGITAL products, or they can be applications that you have written specifically for an OSI environment using the OSAK API. Writing OSI applications requires the OSI Application Developer's Toolkit which is installed with the base system.

To run a DIGITAL application using OSAK software, install the OSAK software wherever you run the application. For example, an application running on two DECnet-Plus systems uses the OSAK software on both systems, as shown in Figure 2-3.

Figure 2-3 OSAK Software on DECnet-Plus for OpenVMS Systems

The OSAK API provides routines you can use, linked with your own programs, to manage interactions between two open systems. The OSAK software is DIGITAL's implementation of:

• The Session layer
• The Presentation layer
• The Association Control Service Element (ACSE) of the Application layer

The OSAK API is made up of three sets of routines:

• A set for making outbound requests and responses
• A set for receiving inbound indications and confirmations
• A set of housekeeping routines, which do not result in protocol exchanges

All calls to OSAK services are nonblocking because the OSAK API allows data to be passed to OSAK either in a single call or spread over osak_select, which you can use to block until a service request is complete.

You can check for completion of a nonblocking call by polling or, on an OpenVMS system, by asynchronous event notification. Asynchronous event notification is not available on an ULTRIX or DIGITAL UNIX system.

The OSAK programming guides contain more information about blocking and nonblocking calls.

OSAK uses a parameter block interface. You can allocate memory for the parameter block and the data structures it contains either statically or dynamically. The parameter block contains all possible parameters for all possible services. OSAK uses only the relevant parameters in each service call.

You must always pass parameters between your application and OSAK in encoded form. On OpenVMS or DIGITAL UNIX systems, you can use an ASN.1 (Abstract Syntax Notation One) compiler to help you do this.

2.5.2 OSAK Software and Management Facilities

OSAK software consists of:

• An OSI upper layer protocol machine (see Section 2.5.2.1)
• Network control and management facilities (see Section 2.5.2.2)
• OSAK trace utility (see Section 2.5.2.3)

The protocol machine contains data structures and routines that implement the Session, Presentation, ACSE, and ROSE protocols, according to the standards listed in Table 2-2.

The OSAK software is largely automatic, but you may want to manage the software for two purposes:

• Monitoring the OSI network
• Creating a passive address (see Section 2.5.3)

You can use Network Control Language (NCL) commands to manage the OSAK software.

Address management facilities for applications that run over OSI Applications Kernel software are provided through the OSAK module entity. The OSAK module entity is an immediate subordinate of the global entity node. Note that OSAK does not provide facilities for managing the applications themselves.

You can find details of NCL command syntax for the OSAK module entity and its subordinate entities in the DECnet-Plus Network Control Language Reference guide or in the NCL on-line help.

2.5.2.3 OSAK Trace Utility

The OSAK trace utility consists of two components: the trace emitter and the trace analyzer. This utility enables you to trace the activity of the protocol machine, and can help you track the source of any problems that occur when applications are running.

You can use the OSAK trace utility to trace protocol activity in the OSI upper layers:

• At the ACSE level, trace information includes the ACSE protocol control information (ACSE-PCI) and user data. User data is traced in either hexadecimal or generic ASN.1 form.
• At the Presentation layer, you can trace session service data units (SSDUs) containing user data and presentation protocol control information (PPCI).
• At the Session layer, you can trace transport service data units (TSDUs) passed between the OSAK software and the transport service, which contain session protocol control information (SPCI) and user data.

An OSAK address can be either active or passive.

• Active
  An active address is available continuously to receive incoming connections. As soon as the OSAK software receives an incoming connection, the software passes the contents of the call directly to the appropriate application.
• Passive
  A passive address is registered in NCL in an osak application invocation subentity. As soon as the OSAK software receives an incoming connection, the software confirms the transport connection and creates a process to handle the call. See the DECnet-Plus Network Control Language Reference guide for details of setting up a passive address. Also see the DECnet-Plus OSAK Programming guide for details of the advantages and disadvantages of active and passive addresses.

The File Transfer, Access, and Management (FTAM) software in DECnet-Plus for OpenVMS implements several standards that define the upper three OSI layers of the OSI Reference Model, including FTAM and ACSE components of the Application layer.

FTAM performs file operations and management between OSI-compliant systems. When implemented by different vendors, the FTAM standard enables the use of files on these vendors' systems. FTAM can transfer unstructured files with binary data and sequential text files with either a stream or variable record format.

To create and manage local files, FTAM uses the OpenVMS Record Management Services (RMS).

FTAM offers the following features:

• FTAM operates on files stored on both local FTAM systems (local files) and remote FTAM systems (remote files).
• Using the DCL interface, you can copy, append, delete, rename, and inspect the file attributes of files on OSI-compliant FTAM systems.
• Journaling supports FTAM's recovery and restart capability by maintaining a docket of recovery information. In the event of a recoverable error, FTAM tries to negotiate with the peer FTAM system for a recovery or restart.

The DAP--FTAM gateway allows a DECnet-Plus node to participate in an OSI network in a simplified way. You can think of this software as a server that receives Data Access Protocol (DAP) messages through DECnet and uses that information to establish and maintain a connection with a remote FTAM system.

The DAP--FTAM gateway simplifies communications for DECnet-Plus nodes because users can issue DCL commands to communicate with remote OSI systems through the gateway. For the DCL user, communication with a remote FTAM application is handled the same as any DECnet dialogue.

2.7 Virtual Terminal (VT)

The DECnet-Plus for OpenVMS Virtual Terminal (VT) software in DECnet-Plus for OpenVMS is an implementation of the ISO Virtual Terminal Protocol (VTP):

• ISO 9040 Virtual Terminal Basic Class Service
• ISO 9041-1 Virtual Terminal Basic Class Protocol --- Part 1: Specification

VTP is an Applications layer protocol. This protocol allows remote logins and access to remote applications between DECnet-Plus systems and any remote systems, including multivendor systems, that also run an ISO-compliant VT implementation.

VT allows you to access remote OSI systems from a DIGITAL terminal in the following ways:

• Entering a DIGITAL Command Language (DCL) command at your terminal
• Using the Telnet/VT gateway
• Using the VT/Telnet gateway
• Using the LAT/VT gateway
• Using the VT/LAT gateway

For VT concepts information, see the DECnet-Plus FTAM and Virtual Terminal Use and Management guide.

2.7.1 VT Gateways

The VT gateways allow any DECserver terminal server, DECnet node with LATmaster, or TCP/IP Telnet node to participate in an OSI VT network. These gateways can be thought of as servers that receive messages of one protocol and use that information to establish and maintain a connection with a remote system using another protocol:

• Telnet/VT gateway --- Telnet messages are received and translated into VTP messages.
• VT/Telnet gateway --- VTP messages are received and translated into Telnet protocol messages.
• LAT/VT gateway --- LAT messages are received and translated into VTP messages.
• VT/LAT gateway --- VTP messages are received and translated into LAT protocol messages.

With the VT gateways, systems that do not have a VT implementation can access systems that do.

2.7.1.1 LAT/VT and VT/LAT Gateways

Without logging in to an account on the local system, you can use the LAT/VT gateway or the VT/LAT gateway to connect to a remote OSI system that has a Virtual Terminal responder installed. The only requirement for this function is that at least one LAT/VT gateway or VT/LAT gateway is enabled on your LAN on a system that runs DIGITAL's local area transport (LAT) protocol. This is true for any terminal server that supports LAT, for example:

• Any computer terminal
• Any personal computer running MS-DOS, OS/2, or Macintosh
• Any OpenVMS or VMS V5.5 (or later) system
• Any VMS V5.4 (or later) system, running the optional LAT software

You can also use the appropriate command from a remote OSI VT system to access a system using the LAT protocol.

2.7.1.2 VT/Telnet and Telnet/VT Gateways

If you have a VT/Telnet gateway on your network, you can use the telnet command from an Internet system to access a remote OSI system that has a Virtual Terminal responder installed. If you have a Telnet/VT gateway, you can access the OSI system using the set host/vtp gateway alias name command line.

2.8 Management Tools and Utilities

Network management is provided with the Network Control Language (NCL). Network management implements the DECnet-Plus layered model, based on the DIGITAL hierarchical structure called Enterprise Management Architecture (EMA).

The DECnet-Plus for OpenVMS network management software allows:

• System or network managers to control and monitor the operation of a network and provide information related to network traffic and performance.
• Network operating parameters to be configured.
• The manager to start up and shut down network components as needed once repaired.

In addition, network management software can provide information warning network managers of faulty or failing network components, both hardware and software.

2.8.1 Network Control Language (NCL)

NCL is the DECnet-Plus network management command-line interface. The structure and syntax of NCL reflects the DECnet-Plus internal structure of the network management components. NCL directives, or commands, let you manage DECnet-Plus entities by means of their unique network entity names.

NCL can also be used to test specific components of the network. NCL enables transmission and reception of test messages either between systems or through controller loopback arrangements. The messages can then be compared for possible errors. NCL aids in isolating network problems.

2.8.1.1 Network Management Graphical User Interface (NET$MGMT)

You can access NCL through either a command-line interface or a graphical user interface (GUI). The GUI allows you to view the status of network components and control those components from a Motif-based window interface. As such, it can be invoked using the same methods you use to invoke any other Motif application. You can run this application locally by issuing the following command:

$ run sys$system:net$mgmt

The application will check for and load the Helvetica 12-point 75-pitch font. In the unlikely event that this font is not present, the application will exit with an error message.

Once you have started NET$MGMT, you can refer to the on-line help pull down menus for more information. Also, refer to the DECnet-Plus for OpenVMS Network Management guide.

2.8.2 Network Control Program (NCP)

DECnet-Plus for OpenVMS allows the use of NCP for the remote management of DECnet Phase IV nodes.

To aid the transition from DECnet Phase IV to DECnet-Plus for OpenVMS, the NCP emulator tool provides a necessary interface for the installation and use of layered products that issue DECnet Phase IV NCP commands.

The NCP emulator tool is not intended for management of DECnet-Plus for OpenVMS. It may be used to manage remote DECnet Phase IV nodes with the TELL and SET EXECUTOR NODE commands.

Because some NCP commands do not have equivalent NCL commands, DIGITAL cannot guarantee that all layered products can be installed and used. For information on support for specific layered products, contact your local DIGITAL office.

The installation procedure places documentation for the NCP emulator tool in the file SYS$UPDATE:NCP_EMULATOR.TXT.

During installation, the DECnet Phase IV version of NCP is renamed SYS$COMMON:[SYSEXE]NCP_PHASEIV.EXE and the NCP emulator tool is placed in the file SYS$COMMON:[SYSEXE]NCP.EXE.

2.8.3 Common Trace Facility (CTF)

CTF software assists in network problem solving. CTF lets you collect and display information about specific protocol exchanges between systems. This information is often useful when you attempt to solve the following problems:

• Suspected configuration problems
• Failures while establishing or using network links
• Network overload
• Interoperability problems
• Problems with name and address resolution

CTF is not supported by all DECnet-Plus software products. Refer to your Software Product Description (SPD) for further information.

2.8.4 CMISE API

DECnet-Plus for OpenVMS supports an ISO CMISE application programming interface (API) conforming to the Service Definitions in ISO 9595. The API allows for development of applications that can communicate with other management applications conforming to ISO 9595 on remote nodes in the network.

2.8.5 Network Management Support Tools

The decnet_register tool assists with setting up Local namespaces, DECdns distributed namespaces, and managing the node names and addressing information they contain. The decnet_migrate tool helps you perform network management tasks and learn NCL.

These tools perform the following functions:

• The decnet_register tool manages node names in the namespaces used within your network.
  • Registers node names, node synonyms, and addresses in your namespaces.
  • Adds addresses to a node registration.
  • Removes addresses from a node registration.
  • Modifies a node registration's synonym or addresses.
  • Displays a node registration and verifies its internal consistency.
  • Exports node registration information from a namespace to a text file.
  • Imports node registration information from a text file into a namespace.
  • Updates a node's registered address information with information it obtains from the node itself.
  • Renames a registered node in a namespace.
  • Deregisters a node from a namespace.
  
  The decnet_register manage command invokes the decnet_register_decdns.com command procedure (located in sys$manager:) to create and manage the required DECdns namespace directories and to set their protections.
• The decnet_migrate tool is useful for network management support:
  • Converts NCP commands to NCL commands.
  • Creates and edits NCL files using a Language-Sensitive Editor (LSE).
  • Gathers and reports detailed information about the network's current configuration.
  • Sets up interphase routing link-creation commands for use by Phase V routers.