DECnet-Plus is the implementation of the fifth phase of the DIGITAL Network Architecture (DNA). Phase V integrates the Open System Interconnection (OSI) protocols with DECnet protocols. In addition, Phase V includes support for the Internet standard RFC 1006 and the Internet draft RFC 1859, allowing OSI and DECnet applications to run over TCP/IP. Thus, applications that use DECnet-Plus can communicate with peer OSI and DECnet applications on any DECnet Phase IV-based system or OSI-based system, whether from VSI or from other vendors.

A DECnet-Plus network can use one name service exclusively, or it can have a mixture of systems using one or more of the name services. While configuring DECnet-Plus,you specify one or more of the three available name services to use on the node. To determine which name service(s) to use, check which name services are already being used by other nodes in your network. For example, if the other nodes in your network are already using DECdns, you will most likely want to use DECdns and join the existing namespace. The following sections include additional criteria and dependencies on the name services.

The DIGITAL Distributed Time Service (DECdts) synchronizes the system clocks in computers connected by a network. The DECnet-Plus for OpenVMS configuration procedure autoconfigures the DECdts clerk. If your network uses multiple DECdns servers, or if you need network clock synchronization, VSI recommends that you install at least three DECdts servers on each LAN. See the VSI DECnet-Plus for OpenVMS DECdts Management guide for more information.

In large networks and networks requiring high throughput, one or more dedicated routers are recommended for the network. VSI recommends using host-based routers to replace DECnet Phase IV host-based routers or in environments not requiring high throughput.

The DECnet-Plus for OpenVMS VAX systems license includes the right to use X.25 Access software (formerly known as VAX P.S.I. Access) or X.25 Native mode software (formerly known as VAX P.S.I.), which requires an additional license.

The X.25 software in DECnet-Plus for OpenVMS is backwards compatible with systems running the older VAX P.S.I. products. For further information on X.25, refer to Chapters 2 and 4.

To develop OSI applications, you need to use the OSI application development interfaces (API) installed with the base system. These tools allow you to build network applications that adhere to the OSI standards defined by the International Organization for Standardization (ISO).

Where ISO standards exist, the APIs conform to these standards.

In the DECnet-Plus distributed processing environment, you can physically distribute multiple resources or tasks that perform various functions between systems on the network.

A distributed application is a collection of processes that use resources, such as processing elements, databases, and physical devices, located on other systems in the network. As a single logical application, the elements or tasks are physically divided. A task is a modular component of work that the application programmer defines within an application. The work of a distributed application is divided among tasks that can communicate with each other.

In an OpenVMS operating system, a task is executed within the context of a process. The process context defines the environment in which the task executes. OpenVMS software controls the access and allocates the resources required by the task, based on the process context.

In a distributed application, each task is distinct and can be placed in different locations in the network. The system interface for the application allows you to run the application locally or remotely without any apparent difference.

You can distribute an application so that each task is assigned to a system with appropriate resources. For instance, one task computes on a powerful processor while another stores the information in a database on a system with extensive disk storage capabilities. A common example of a distributed application is an implementation of the client/server model, such as DECdns, in which the client task(on the DECdns clerk system) requests service from the server task on a different system (the DECdns server).

Interprocess communication is the movement of data and control from one task running within a process to another task in the network. Interprocess communication allows the various tasks on the different processes to cooperate and communicate with each other, exchanging message packets over the connection established between the tasks.

DECnet-Plus for OpenVMS supports the use of multiple cluster aliases. The alias node identifier (a node name or node address) is common to some or all nodes in the cluster and permits users to address it as though it were one node.

For management purposes, the cluster alias is viewed by the DECnet-Plus software as a separate Node entity that is manageable through NCL commands. The Alias entity differs from a regular Node entity in some characteristics; for example, the Alias entity does not support a Circuit entity. The cluster alias appears to the network as a multicircuit end node, which is an end node with several active circuits. In an OpenVMS cluster system that consists of DECnet-Plus for OpenVMS systems on a LAN, the alias node appears as an end node with multiple points for attachment to the LAN.

DECnet-Plus for OpenVMS supports the ability to access nodes in an OpenVMS cluster using a separate alias node address, while retaining the ability to address each node in the cluster individually. Not all network objects may be accessed using this mechanism. The maximum number of nodes supported for a cluster alias is 96. The maximum number of cluster aliases for a single node is three.

The cluster_config.com command procedure for performing a OpenVMS cluster configuration invokes the DECnet-Plus for OpenVMS net$configure.com command procedure to perform any required modifications to NCL initialization scripts. Use cluster_config.com to create a configuration for each satellite node in the cluster.

DECnet-Plus for OpenVMS offers task-to-task communications, file management, and downline system and task loading. Network WAN connectivity is provided by WAN device drivers supporting host-based synchronous communications options for wide area networking.

DECnet-Plus for OpenVMS is available in two forms: End System and Extended Function. Extended Function provides all the features of End System plus the OSI application gateways (FTAM–DAP Gateway, VT-Telnet, LAT/VT and VT/LAT), the DECdns server (on VAX platforms), and host-based routing, and cluster alias.

The DECnet over TCP/IP feature allows users to run standard DECnet applications in an Internet Protocol (IP) routing environment.

$ set host node.site.company.com

$ COPY/FTP myfile *

For more information on running DECnet over TCP/IP, refer to the DECnet-Plus Network Management and the installation and configuration guides. This feature requires any valid DECnet license and a licensed and installed TCP/IP product that supports the PATHWORKS Internet Protocol (PWIP) interface.

A DECnet-Plus for OpenVMS system functions as an OSI end node if, during configuration, you configure OSI Transport. An application can set up a transport connection to another application on any other system, either VSI or multivendor, running software that implements the OSI Transport Protocol.

DECnet-Plus for OpenVMS software includes the Network Services Protocol (NSP) for DECnet Phase IV compatibility. You can use the proprietary NSP and the open OSI Transport Protocols simultaneously.

Section 3.10, “Network Management” introduces the concepts of DECnet-Plus network management.

The DECnet-Plus Session Control layer requires a name service to map node names to addresses. A DECnet-Plus network can use one namespace exclusively, or it can have a mixture of systems using the Local namespace, the DECdns distributed namespace, and/or DNS/BIND.

While configuring DECnet-Plus, the system administrator specifies one or more of the following name services to use on the node: the Local namespace, DECdns, or Domain (for DNS/BIND).

DECnet-Plus includes a new in-memory naming cache to improve performance of name and address resolution for all supported name services.

DECnet-Plus includes features to ease namespace management including decnet_register (a namespace management tool), numerous NCL commands, and Common Trace Facility (CTF) support for monitoring node name and address resolution. In some instances, this simplified access to multiple name services is referred to as CDI or the common directory interface.

In addition to the Local namespace and DECdns, for node-name-to-address mapping your network can use, if it has one, an existing VAX Distributed Name Service (DNS) Version 1 namespace.

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 synchronization, VSI recommends that you install at least three DECdts servers on each LAN.

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-VSI X.25 system on the same LAN that supports the ISO logical link control type 2 (LLC2) protocol.

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.

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 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 UNIX systems, you can use an ASN.1 (Abstract Syntax Notation One) compiler to help you do this.

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.

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

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.

$ run sys$system:net$mgmt

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, VSI cannot guarantee that all layered products can be installed and used. For information on support for specific layered products, contact VSI.

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.

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

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.

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.

The DECnet-Plus for OpenVMS Event Dispatcher (EVD) software reports significant events that occur during network operation. An event is an occurrence of a normal or abnormal condition that an entity detects. As directed by you, DECnet-Plus for OpenVMS maintains records of specific or general categories of events. These records can help you track the status of network components.

Many events are informational. They record changes that you or the DECnet-Plus for OpenVMS software makes to components of the local system, or to those remote system entities that the local system's Event Dispatcher is tracking. Other events report potential or current problems in the physical parameters of the network.

You can set up event dispatching on a particular system, between two systems, or across multiple, distributed systems. The event-dispatching component can report events that occur on any system that runs DECnet-Plus software, and it is also capable of logging the events of remote Phase IV nodes via the DECnet-Plus Event Dispatcher relay.

The CMIP Management Listener (CML) is the DECnet-Plus management module that implements DNA Common Management Information Protocol (DNA CMIP). CMIP defines the exchange of network management information.

CML provides access to CMIP. NCL accesses management directives defined for DECnet-Plus entities using CMIP.

A protocol is a set of rules and procedures. Protocols govern the behavior of open systems at each layer. Some layers (for example, the Application layer) have several protocols.

A protocol machine is software that implements a particular protocol.

A protocol data unit (PDU) is information made up of protocol control information (PCI) from the current layer and, possibly, user data from the layer above. PDUs are exchanged between peer protocol machines using service primitives. A given service primitive can correspond to zero, one, or more PDUs. The integrity and identity of a PDU remains intact while it is being exchanged.

The underlying layer places each PDU received from the above layer into a service data unit (SDU). The SDU becomes user data in the PDU of its underlying layer. PDUs remain intact until they arrive at the protocol machine of the peer entity. The peer's protocol machine separates the PCI from user data and processes the PCI. Figure 3.3, “The Relationship of PDUs, User Data, and SDUs” shows the relationships among the PCI, user data, SDUs, and PDUs.

Applications can communicate with each other only if they agree on the protocols they both will use and the operational parameters of these protocols. Also, exact address information is needed to indicate to each layer of protocol where to deliver data. This required information is encoded in a protocol stack or protocol tower, which is a data structure for encoding address and protocol information about a service user (application). The tower is a protocol sequence (an ordered list of protocol identifiers for each layer from the Network layer upward) with associated address and protocol-specific information.

OSI protocol machines ensure that open systems can establish message exchanges, called dialogues. Though many dialogues can occur simultaneously, each dialogue is independent of other dialogues. Protocol machines cooperate to conduct a dialogue through a predictable sequence of states. The portion of a dialogue conducted at the Application layer is called an association; the portions of dialogues conducted at other layers are called connections.

Associations or connections are established between service users by their peer service providers; for example, the Association Control Service Element (ACSE) establishes FTAM associations. Connections use the name of the service provider that establishes them; for example, a connection established by Presentation for ACSE is called a presentation connection.

Protocol machines operate within system-specific implementations, or processes. For every dialogue, one or more processes activate the protocol machines of each layer independently. An instance of such protocol-machine activity is called an entity. OSI entities, which are the manageable components that make up the network, relate to entities on other systems for example, a routing circuit. The relationship between processes and entities is implementation-specific.

Each entity communicates with equivalent entities on different systems, called peer entities.

A service is an interface provided by a service element or a layer for accessing one or more functions. An application service element (ASE) is a component that provides an application-level function. FTAM and ACSE are examples of service elements.

The service element or layer that provides a service is called a service provider. An application program, service element, or layer that uses a service is called the service user.

3.3.5.2. Service Access Points (SAPs)

A service provider delivers services to a service user at an interface called a service access point (SAP). A SAP is the point at which an entity provides a service to a user entity in the layer above.

Figure 3.4, “Service User, Service Provider, and SAP Interaction” shows how a service user, a service provider, and a SAP interact.

Except for the Application and Physical layers, SAPs exist at the boundaries of all OSI layers. SAPs are named according to the layer providing the services. For example, transport services are provided at a Transport SAP (TSAP) at the top of the Transport layer and any SAP that the Presentation layer provides is called a Presentation SAP (PSAP). Figure 3.5, “SAPs at Different OSI Layers” 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 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 has SAPs at three layers: Transport, Session, and Presentation. A p-address is used for upper-layer addressing and has SAPs at four layers: Network, Transport, Session, and Presentation.

In addition, on a LAN, the Data Link layer uses the source service access point (SSAP) and the destination service access point (DSAP):

• SSAP — 1-byte field in an LLC frame that identifies the link service access point (LSAP) of the sending client protocol. (The LSAP is the ISO 8802-2 (LLC) protocol identifier that identifies a Network layer entity.)

• DSAP — 1-byte field in a LLC frame that identifies the LSAP of the receiving client protocol.

Presentation and Session entities provide the Presentation and Session connections. To form an association, an OSI application entity requires a corresponding Presentation entity and Session entity. For the FTAM software, for example, these Presentation and Session entities occur within the same process as the FTAM entity.

The sequence of protocol identifiers in a protocol tower typically extends from the Network layer up to the DNA application. Session Control builds and maintains multiple towers for the local node object: one tower for each protocol and each address through which Session Control can access the object. A protocol tower set includes all the protocol towers that the system builds for the object.

When a DNA application on one node requests a connection to another node, Session Control requests that DECdns provides DNA$Towers attribute information for the remote node. Session Control compares the tower information with the tower information it maintains for the local node and selects a protocol tower common to both nodes. The connection is then made automatically without a user or application needing to know what lower-layer protocols the nodes are using.

You can autoconfigure addresses for DECnet-Plus systems, which can change over time. Session Control creates and maintains the protocol and address information in the towers in the namespace for the node object entry.

Session Control supports a RegisterObject function to maintain the address attribute of an object entry if the underlying protocol tower address element of the node changes. Applications can request that Session Control perform this function for their objects.

The Session Control layer initiates a connection based on the address of a system and the Session Control application being connected to that system. It receives a list of common protocol towers with the address-resolution function and looks for a set of mutually supported protocols. It tries to make a connection using all towers in common; the connection fails if all towers are tried and none works. The selected protocols and address information are used for communication with the remote system.

The Session Control layer performs connection services for Session Control applications. It requests, maintains, and disconnects or aborts transport connections. Session Control can request a connection using the destination address. It can receive a connect request, validate the access control information supplied with the request, and identify the remote application making the request. The Session Control layer sends and receives data over transport connections.

The Session Control layer forms the interface between all DNA applications and the Transport layer. It allows use of the NSP Transport and OSI Transport protocols.

Session Control applications in DECnet-Plus for OpenVMS provide general-purpose network services. A Session Control layer application is identified by application type, which is a discrete numeric identifier for either a user task or a DECnet-Plus program, such as file access listener (FAL). DECnet-Plus for OpenVMS uses application type numbers to enable logical link communications using the NSP Transport Service or the OSI Transport Service.

DECnet-Plus uses a mechanism called logical link for communication between processes. A Phase IV logical link in DECnet-Plus terms is either a Transport layer port or a Session layer port.

A logical link is a temporary connection either between processes on source and destination systems or between two processes on the same system. A logical link carries a stream of regular data and interrupt data of full-duplex traffic between two user-level processes. Each logical link is a temporary data path that exists until one of the two processes terminates the connection.

The OSI Transport Protocol, the implementation of which provides the OSI Transport Service, bridges the gap between the service provided by the network and the service desired by the transport user.

The Transport layer supports both the NSP and the OSI Transport Protocols. An OSI application makes a connection request to the Transport layer to access the OSI transport. The choice of protocol for a non-OSI connection is made during connection establishment: either the connect request specifies a Transport protocol, or the Session layer selects an appropriate Transport Protocol. Multiple transport connections, using any of the Transport Protocols, can be made simultaneously.

The Transport layer provides the OSI transport service, which fulfills communications requirements for clients in the higher layers. The OSI transport service software implements the OSI Transport Protocol, allowing two OSI transport users to set up and use an OSI transport connection. A transport user uses the OSI transport service to set up a transport connection with another transport user.

The OSI transport service is a consistent interface to transport users, regardless of the type of network over which they make OSI transport connections.

DECnet-Plus for OpenVMS offers three classes of OSI transport service, each of which is appropriate to a particular network service because each provides the additional functions not provided by that service. TP 0, 2, and 4 identify the different classes of OSI transport service offered in DECnet-Plus for OpenVMS (see Table 3.3, “Functions of the OSI Transport Protocol Classes”).

An OSI transport connection between two OSI transport users is supported by a network connection between the end systems on which the OSI transport users are running. This network connection is set up and maintained by the Network layers of the two end systems. The Network layer, therefore, provides a network service to the OSI transport service.

Service-type conversion takes place only in the Transport and Network layers. This means, for example, that a presentation connection must be supported by a session connection, but that a change to using the connectionless network service can be done through the functions of the Transport layer.

The type of network service used depends on the topology of the network between the two end systems. The transport user selects the type of network service for a transport connection by supplying in the connection request a transport template that specifies the desired service.

With CLNS, the Network layer receives user data from the Transport layer and determines the path along which the data travels to its destination. This decision process is the main function of routing. The Network layer provides end-to-end data transfer, or routing, as a service to clients in the Transport layer. This data transfer between the two communicating systems is called a network connection.

An end system (ES) is either the source or destination of data sent over a network connection. An end system receives data units, called packets, addressed to it and sends data units to other systems on the same subnetwork. DECnet Phase IV calls this type of system an "end node" and the "subnetwork" an area.

An intermediate system (IS) is a routing system that receives data packets from a source end system, or from the previous intermediate system on the route, and passes them on to the destination end system, or to the next intermediate system on the route. (DECnet Phase IV calls this type of system a "router.")

An intermediate system interconnects two subnetworks. A subnetwork is a network, within a group of interconnected networks, of OSI systems that all use a common addressing format. A subnetwork forms an autonomous whole, for example: ISO 8802-3 (CSMA-CD) LAN, HDLC data link, or X.25 connections.

In the Network layer, the ES-IS protocol (ISO 9542) provides the communication between an end system and the nearest intermediate system. ES-IS is a connectionless protocol. IS-IS protocol (ISO 10589) provides the communication between two intermediate systems. The Internet standard provides the end-to-end connectionless link between end systems. Figure 3.6, “ES-IS and IS-IS Protocols” shows how ES-IS relates to other ISO protocols.

For additional information on routing, see the VSI DECnet-Plus Planning Guide.

The Data Link layer allows the transmission of data over a local area network cable by means of the CSMA-CD (Carrier Sense Multiple Access with Collision Detection) protocol. CSMA-CD ensures equal access to multiple systems connected to the LAN. DECnet-Plus for OpenVMS supports both the existing Ethernet protocol and the protocol that complies with ISO 8802 (also known as IEEE 802).

The Ethernet and ISO 8802 protocols are compatible, with only slight differences in packet format. A DECnet-Plus system transmits in both ISO and Ethernet formats, and listens for frames in ISO and Ethernet formats. If a Phase IV system is connected to the LAN, the DECnet-Plus system also transmits in Ethernet format.

CSMA-CD LANs are similar to LANs defined by ISO 8802-3. LANs are privately owned, reliable, high-speed networks that connect information-processing systems in a limited geographic area, such as an office, a building, or a complex of buildings. It is a best-effort delivery system.

CSMA-CD allows multiple stations to access the broadcast channel at will, avoids contention by means of carrier sense and deference, and resolves contention by means of collision detection and retransmission. Each station awaits an idle channel before transmitting and can detect overlapping transmissions by other stations.

CSMA-CD stations provide for multiaccess connection between a number of systems on the same broadcast circuit. This kind of routing circuit is a path to many systems. Each system on one CSMA-CD station is considered adjacent to every other system on that station and equally accessible.

The media is passive coaxial cable or shielded twisted-pair cable that uses Manchester-encoded, digital baseband signaling, with interconnections containing all active components so that no switching logic or central computer is needed to establish or control communications.

At the Data Link layer, network control for the LAN is multiaccess, fairly distributed to all systems. The frame length allocation is from 64 to 1518 bytes (including an 18-byte envelope).

When manufactured, LAN controllers are given a 48-bit hardware address.

A particular ISO 8802-3 system is identified by the hardware address of its station (line); this hardware address is stored in read-only memory in the LAN controller. When DECnet-Plus starts a CSMA-CD station, it constructs a physical address for the system. When you shut off machine power or change the state of the CSMA-CD station to off, the LAN controller resets the physical address to the original hardware address.

ISO 8802-3 (CSMA-CD) LANs support a bus topology, a single communications medium to which all the systems are attached as equals. The single network cable replaces the numerous interconnecting cables usually required in traditional WANs. This type of network is also called a broadcast LAN. The maximum possible distance between systems on the LAN is 2.8 kilometers (1.74 miles).

High-level Data Link Control (HDLC) protocol data links are ISO, synchronous, point-to-point links that are basically the same in function as existing DDCMP synchronous links. However, HDLC is a bit-oriented protocol, whereas DDCMP is a byte-oriented protocol.

HDLC operates over synchronous, switched, or nonswitched communications links. HDLC supports a broad range of existing subsets, including the subset used in X.25 networks.

HDLC links use UI frames and XID frames. A UI frame is an unnumbered, information frame that carries data not subject to flow control or error recovery. An XID frame exchanges operational parameters between participating stations.

DDCMP is designed to provide an error-free communications path between adjacent systems. It operates over serial lines, delimits frames by a special character, and includes checksums at the link level.

DDCMP provides a low-level communications path between systems. The protocol detects any bit errors that are introduced by the communications channel and requests retransmission of the block. The DDCMP module provides for framing, link management, and message exchange (data transfer). Framing involves synchronization of bytes and messages.

DDCMP pipelining permits several packets to be sent before an acknowledgment is received. Piggybacking permits an acknowledgment to be transmitted on a data packet.

The DDCMP protocol moves information blocks over an unreliable communication channel and guarantees delivery of routing messages. Individual systems on DDCMP routing circuits are addressed directly because no multicast or broadcast addressing capability is available.

The Data Link layer supports point-to-point, DDCMP links, either synchronous or asynchronous. The two types of asynchronous links are static (permanent) and dynamic (switched temporary).

The Physical layer supports the CSMA-CD interface, which complies with ISO standard 8802-3 and the IEEE 802.3 standard. The Physical layer also allows CSMA-CD LAN connections based on the DECnet Phase IV Ethernet interface.

The structure of DECnet-Plus network management defines formal relationships between the management software at the various layers and the directors that communicate with the layers on behalf of network managers.

The two major components of network management are directors and entities. Directors are interfaces for managing the entities. They are typically used by the network manager and usually involve a command language. NCL management entities, which are the manageable components that make up the network, relate to other entities on the same system.

For further information on NCL commands, refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide.

The Network Control Language (NCL) is a command line interface to the director, which interprets the input NCL commands, sends these commands to a target entity for processing, and presents the results back to the network manager.

Directors use common mechanisms to communicate with the entities they manage. The same director can manage both local and remote entities. If the managed entity resides on the local system, the director uses the local interface to access it. If the managed entity resides on a remote system, the director converts the NCL message to CMIP and sends the converted message to the entity agent on the remote system.

You can also use net$configure.com to reconfigure all or some of the DECnet-Plus for OpenVMS system. Rerunning the configuration procedure modifies or replaces relevant initialization script files but does not affect running systems. You then execute the modified initialization script files to effect these changes.

The initialization scripts create and enable all required entities. Each entity is initialized through execution of a separate NCL script file. Using NCL scripts to initialize DECnet-Plus for OpenVMS systems replaces the Phase IV requirement of establishing a DECnet permanent configuration database at each node. Remote node information resides in either a local or distributed DECdns namespace.

For further information, refer to the VSI DECnet-Plus for OpenVMS Network Management Guide.

Packet switching is a method of sending data across a network. In this method, data is divided into blocks, called packets, which are then sent across a network. Networks using this method are referred to as packet switching data networks (PSDNs) or X.25 networks.

Figure 4.1, “Packet Switching Equipment” shows an example of the equipment involved in sending data across a PSDN. PSDNs are made up of packet switching exchanges(PSEs), and high-speed links that connect the PSEs. Each PSE contains data circuit-terminating equipment (DCE). The DCE is the point where all data enters and leaves a PSDN.

The user's computer that sends data to the DCE, and receives data from the DCE, is known as the data terminal equipment (DTE). Outside a PSDN, packets travel between the DTE and DCE. Inside a PSDN, packets travel between PSEs.

A PSDN is either owned by a country's Postal, Telegraph, and Telephone (PTT), Authority or it is privately run. Public PSDNs can be used by anyone, on payment of connection fees and regular bills. Private PSDNs are used to serve a single body, such as a large corporation.

Public and private PSDNs can be interconnected. It is, therefore, possible to pass data packets from one DTE to another no matter where in the world the DTEs are located.

The PSDN sends each packet to its destination by the best available route at the time. The packets that make up a data message may take different routes to reach the same destination; this will occur if certain routes are busy or if there is a line failure within the PSDN. Figure 4.2, “Packets Traveling Over a PSDN” shows an example of packets traveling by different routes across a PSDN.

When the packets reach their destination, they are reassembled so that the original order of the packets in the data message is maintained.

This level defines the procedures for formatting packets, sequencing packets, and establishing virtual circuits. Virtual circuits are the logical connections between two DTEs (see Section 4.4.2.1, “Virtual Circuits”). Most packets contain user data, but some are for control purposes. Control packets are used for functions such as initiating and terminating virtual circuits between two DTEs and for interrupt messages.

The amount of user data allowed in a packet is known as the packet size. The maximum amount of user data allowed in a packet is set by the PSDN you use. A typical packet size is 128 bytes.

This level initiates communications between the DTE and the DCE and ensures that data is transferred between DTE and DCE without errors.

Figure 4.6, “Structure of a Frame” shows the structure of a typical frame.

This level defines the mechanical and electrical connections between a DTE and a DCE. It specifies electrical characteristics, data transmission speeds, and connector types.

Figure 4.7, “CCITT Packet-Switching Recommendations” illustrates the main packet switching recommendations.

The physical line between a DTE and a DCE is divided into a number of logical channels. Logical channels allow many virtual circuits to exist on the physical line. Each logical channel is identified by a logical channel number (LCN), contained in the packet header of every packet sent across a PSDN.

Before data can be sent across a PSDN, a virtual circuit must be established between a logical channel at the calling DTE and a logical channel at the called DTE. The circuits are referred to as "virtual" because a number of virtual circuits may use the same physical circuit to transmit packets from the calling DTE to the called DTE.

It is important to realize that the logical channel used between a DTE and DCE only has local significance. It is the responsibility of the PSDN to map the logical channels used by the calling and called DTEs into an end-to-end virtual circuit. This means that although a virtual circuit has end-to-end significance between the DTEs, different logical channels can be used by the virtual circuit on each side of the PSDN.

This concept is illustrated in Figure 4.8, “Virtual Circuits Versus Logical Channels” in which two virtual circuits are depicted. Virtual Circuit A establishes an end-to-end connection using LCN 2 between the calling DTE and its associated DCE, and LCN 1 between the called DTE and its associated DCE. Similarly, Virtual Circuit B establishes an end-to-end connection using LCN 4 on both sides of the PSDN.

DTE addresses may consist of up to 15 digits. However, for internetworking X.121 restricts international data numbers (that is, DTE addresses) to 14 digits.

An example of an X.121 format DTE address is shown in Figure 4.9, “DTE Address Example”.

Some networks use an abbreviated form of addressing to refer to DTEs on the same network. In such networks, an extra digit is often prefixed to the DTE address to indicate that the address of the called DTE is on a different network to the calling DTE.

When a packet has been received by a called (remote) DTE, the PSDN sends a message to the calling (sending) DTE. This message is known as an acknowledgment. Because of the time it takes a packet to travel across a network, it is inefficient to wait for the acknowledgment of the packet before sending more. For this reason, PSDNs let you send a number of packets before you receive acknowledgment for the first one.

The maximum number of unacknowledged packets you are allowed to have on a virtual circuit is called the window size. Once the window size is reached, and acknowledgments for previously sent packets are received, more packets can be sent. Acknowledgments are often carried by incoming packets of data.

You can specify the window size you want to use, up to the maximum set by the PSDN. You may want to subscribe to larger window sizes if you have large amounts of data, or if there is a long delay between sending a packet and receiving the acknowledgment of that packet.

DTE parameters govern the frame- and packet-level operation of DTEs. They specify properties such as window size and packet size. Various PSDNs support different parameters. For more information on the parameters supported, contact your PSDN supplier.

PSDNs offer optional PAD facilities that are represented by variables known as PAD parameters. You can set PAD parameters to indicate that you want to use a PAD facility and how you want to use it.

A set of PAD parameters is a profile; most networks define several profiles to suit different types of character-mode DTEs (X.29 terminals). When you connect to a PAD, you can select a profile to control the actions of the PAD. During a call, you can read and reset most of the PAD parameters.

Refer to the VSI X.25 for OpenVMS Management Guide which describes the CCITT-defined PAD parameters, all supported by DECnet-Plus for OpenVMS.

Because a full name consists of the complete directory path from the root directory to the target object entry, directory, or soft link, full names can be long if a namespace has several levels of directories.

DECnet-Plus supports a 6-character Phase IV-style node name called the node synonym. A node synonym is a soft link that points to the full name of a node object entry. Node synonym soft links enable applications that do not support the length of full names to continue to use 6-character node names.

Node synonyms should not be viewed as a way for users to avoid typing the full name of a node. Logical names, and a feature called the local root, are faster and more convenient methods of shortening names. Both logical names and local roots are for use only on the system where they are defined; unlike node synonyms, they do not have global meaning throughout the namespace. Also, logical names and local roots can be used to name any resource (such as a disk or an application), not just node names.

The local root is a prefix that DECnet-Plus obtains automatically by stripping off the rightmost simple name of the local node's DECnet-Plus full name. For example, a node named IAF:.DIST.QA01 would have IAF:.DIST as its local root. Users will likely want to refer frequently to other names in the hierarchy in which their local node is named. The local root capability makes such name references more convenient by allowing users to omit the part of the full name that is also part of their node's full name.

DECnet-Plus Session Control creates the local root under the fixed name dnsroot in the dns$system logical name table.

$ show logical net$startup_status
   "net$startup_status" = "running-all" (lnm$system_table)

This command returns with a display indicating that all network software is loaded and running.

After you log in to a network node, you may be able to log in to other nodes on the same network. If you are authorized to access an account on another OpenVMS node or on a non-OpenVMS node that supports DECnet, you can log in to that node over the network. To log in to the other node, enter the DCL command SET HOST, specifying the remote node name, and follow the login procedure the remote node uses. Once you are logged in to the remote node, you can perform all general user operations on that system as though it were the local node:

$ set host node-name

$ set host node-name

$ set host namespace:.abc.xyz

You can access remote files by simply including in the file specification the name of the remote node on which the file is located. You can access files that are protected if the owner has granted you access, either by a proxy account or by providing you with the name and password of the account.

node"username password"::device:[directory]filename.type;version

boston"cmiller techwriter"::dba1:[information]example.lis

$ define public concord::disk1:[comments.public]

$ directory public$ type public::freedom.txt)

They can also copy the file to the local node and then print it, as described in the next section.

Use the COPY command to copy a file from one node to another. As part of the copy operation, you can create a new file from existing files.

$ copy boston::disk:liberty.dat;2
_To: britain::dba0:[product]liberty.dat

$ copy boston::"/usr/users/user/test" liberty.dat

$ copy traitors.lis concord::disk1:[patriots]traitors.lis
$ copy traitors.lis concord::disk1:[patriots]

$ copy *.* lexington::[british]*.*

$ copy user1.dat,user2.dat lexington::[british]users.dat

$ copy lexington"revere silver"::[statistics]summary.lis *

$ append lexington"revere silver"::[liberty]data1.lis,data2.lis
_To: britain::dba0:[product]results.lis

$ copy witches.lis salem::work:[project]
$ print/remote salem::work:[project]report

$ copy report.lis salem::lpa0:

To contact OpenVMS users over the network, you can also use the Phone utility, which allows you to have an “online” conversation with a user on another OpenVMS node that supports Phone.

To address a user on a remote node, use the format nodename::username. Your outgoing connection identifies your local node. During your conversation, Phone creates a number of incoming links addressed to your node. You should not use a cluster alias node name with the Phone utility because links addressed to a cluster alias node name can be assigned to any node in the cluster.

The file systems used by UNIX or ULTRIX and OpenVMS are dissimilar in many respects. A fundamental difference between them involves the handling of file attribute information. When you create a file on an OpenVMS operating system, attribute information about the file is stored in a header block on disk for use when the file is subsequently opened.

The implication is that the structure of an established file cannot change. In contrast, UNIX or ULTRIX does not save attribute information such as file format with a file; it expects you to provide this information when you open the file. File attribute information, however, is not an input to OpenVMS RMS when a file is opened.

To provide transparent access to files on a remote UNIX or ULTRIX operating system, OpenVMS RMS restricts the types of files you can create and open on the remote node. When you access a UNIX or ULTRIX file in record mode, OpenVMS RMS treats the file as having STREAM_LF (STMLF) format.

$ CONVERT/FDL=STMLF.FDL input-file output-file

FILE
        ORGANIZATION          sequential
RECORD
        FORMAT                STREAM_LF
        CARRIAGE_CONTROL      none

The file systems used by MS-DOS and OpenVMS are dissimilar in many respects. A fundamental difference between them involves the handling of file attribute information. When you create a file on an OpenVMS operating system, attribute information about the file is stored in a header block on disk for use when the file is subsequently opened. The implication is that the structure of an established file cannot change. In contrast, MS-DOS does not save attribute information such as file format with a file; it expects you to provide this information when you open the file. File attribute information, however, is not an input to OpenVMS RMS when a file is opened.

To provide transparent access to files on a remote MS-DOS system, OpenVMS RMS restricts the types of file that you can create and open on the remote node. When you access an MS-DOS file in record mode, OpenVMS RMS treats the file as having stream format.

$ CONVERT/FDL=STM.FDL input-file output-file

FILE
        ORGANIZATION          sequential
RECORD
        FORMAT                stream
        CARRIAGE_CONTROL      none

$ DIRECTORY PC::[REPORT]

$ DIRECTORY PC::\report\*.*

Of the OpenVMS DCL commands that you can use over the network, the OPEN/WRITE command is not supported between OpenVMS and an RMS-based RSX node.

$ copy a.dat;9 rsx::*.*
%COPY-E-OPENOUT, error opening rsx::a.dat;9 as output
-RMS-F-FNM, error in file name

$ copy a.dat;9  rsx::a.dat;11
$ copy b.dat;28 rsx::*.*;
$ copy b.dat;28 rsx::*.*;0
$ copy *.dat    rsx::*.*;0