JPH029247A - Data communication system and method of establishing communication path - Google Patents

Abstract

PURPOSE: To enable a host to execute normal control for host application or a terminal user by defining a local SNA(system network architexture) network in each SNA host by a front end processor connected to a channel. CONSTITUTION: A function between an SNA terminal and an SNA host can connect remote products such as a cluster controller 3274 and relative terminals such as 3273, 3180 and attain the direct connection of a PC for emuting a device 3270. A centralized network control function attains a centralized control communication network manager by using IBM network control program products such as a network communication control function, a network direct control function and a network problem discrimination application. An inter-host function attains a communication function, mutually addresses MVS and VM host systems and executes communication beween these host systems through a DDN.

Description

[Detailed description of the invention] The present invention will be explained in the following order.

A. Industrial field of application B. Prior art C0 Problems to be solved by the invention Means for solving one problem E. Embodiment SNA terminal-SNA host function centralized network control function Host-to-host function・Interface design System structure ACP structure Network notification structure Network access protocol description MVS distributed database support Basic knowledge about DB/VTM interfaces ACP
/Basic knowledge about VTAM interface New DB-ACP interface DDN/SNA
Design FEP/RAF-DDN Connection Overview Network Control Overview Host-to-Host Physical Unit 4 Support DDN/SNA
Prototype System Example AnalysisPerformance ModelDescription of Input RequirementsDescription of Output ResultsMore Detailed Description of the Invention5NAy'J end-SNA host-to-host softwareSNA host-to-host software Centralized network control softwareTCP/IP/X, 25 MC68000 Partial network management in contact with the coprocessor card Flow control Multiple TCP instances EDX Operating system enhancement System wide operator function Interpartition data area services Buffer management function SNl'J terminal-8NA host-to-host software PU2
FEP design RAF design SNA host-to-host software PU4 channel input/output function PU4 DDN input/output function PU4 route control function PU4 network control support Centralized setwork control software NCH design NCF design FEP network control module RAF network control module DDN/ SAN Front End Processor (FEP)
) 1) DN/SNA FEP interface FEP/
SNA PU2 interface FEP/SNA
PU4 interface
A Remote Access Function (RAF) DDN/SNA RA
F interface RAF/TMP interface RAF asynchronous terminal interface DDN/SNA, 1. Network Control Front End Processor (NCF) DDN/SNA NCF In9-7. -SuNCF/I
MF Interface Additional Features of the Invention Introduction Maintenance Functions and Partition Boundary Buffer Management Functions, Queue Management Functions, and Main Queue Data Flow Error Handling DNAM API DNA Management Tasks Error Recovery and Error Handling F8 Effects of the Invention A, Industrial FIELD OF THE INVENTION This invention relates to data processing, and specifically to a method and apparatus for coupling SNA data processing equipment over a packet-switched communications network.

B. Prior Art In 1974, IBM's System Network Architecture (S
NA) has significantly advanced the technology of teleprocessing software systems. E.

H. Sussenguth, Systems Network Architecture: A Perspective (Sys.
msNetwork Architecture:
A Perspective) J.X. 1978
Collection of abstracts from the International Conference on Computer Communications (Confer)
ence Proceedings, 1978 Tn
InternationalConference on
Computer Communications)
N Kyoto, Japan, 4978, pp. 353-358, and Doll I, IBM Strengthens i
ts Architecture) J, Data C
communicationsz 8 (1979),
pp.

See 56-87. SNA provides an integrated design of functionality and structure for data communications products. Prior to the introduction of SNA, teleprocessing networks had many problems. Terminals were often dedicated to one application, and many different line control procedures and terminal types were inserted into support programs, application programs, and network operations. Multiple access methods were commonly used, hindering attempts to partition resources among applications. Each of these programs made it difficult to extend traditional applications or add new applications. S
NA was introduced to solve these problems and make teleprocessing applications easier to install, run, and scale.

SNA was also rooted in advances in hardware technology in the 1970s. At that time, it became economically possible to incorporate small processors into the design of many terminals.

Prior to these microcomputers, terminals were commanded directly by their host computers. For example, each keystroke generated an input character that was sent independently at the rate of production. Each output character was sent at a speed no greater than the speed of the printing device.

In new microcomputer-based designs, a processor within the terminal handles many functions independently of the host computer, and transmissions between the host and the terminal are complete messages sent at high speed. This has the effect of reducing the processing power required by the host, or allowing a host of the same size to accommodate many terminals, or both. But the more important change was in the structure of the system. Tight coupling between terminal and host is no longer necessary, and device control can be located at or near the terminal rather than at the host. That is, system commands, protocols and procedures designed for tight coupling are no longer needed; instead, new ones designed specifically for distributed processing are needed.

Currently, terminal processors handle device control, but they can also easily become application processors. From a system perspective, applications can now be executed in multiple locations within the network: on the host computer, on the control device, and even on the terminal itself.

This is a new structure that did not exist before 1974 and required the definition of control for such a system. The advent of distributed processing, whether for device control or distributed application processing, was the underlying technical rationale for the development of SNA.

From an architectural perspective, SNA is a top-down design consisting of multiple layers. R,J
, Cypser, “Communications Architectures for Distributed Systems”
To hitecture for Distribution
ed Systems) J) Addison
Unizuri Publishing Co., Reading, Massachusetts, 1978; rSNA Technology Overview (SNA T
GC30-3073 (available from IBM sales offices). The lowest layer, the data link control layer, directly manages the physical resources, ie, the transmission equipment that connects the nodes. Each subsequent layer performs other services. For example, the routing layer provides routing services in such a way that its users are blind to the physical geometry of the network. Some nodes include a control point that controls multiple nodes (eg, terminals and controllers) and lines of the node portion of the network. Other layers provide services to the application. These services include transparent access to local or remote resources, mapping of data streams to and from application data structures (known as presentation services), access to other local or remote programs, and buffer commitments. management, and encryption of data before transmission and decryption upon receipt.

In SNA, network addressable unit) (
A NAU) is a location in an SNA network that supports one or more boats for communication over the network. Each NAU has a network address.

In SNA, three types of NAU are defined.

1. System Service Control Point (SSCP): Dedicated NAU used for network management, SNA network can contain one or more SSCP, each 5s
Each cp manages a portion of the network. 5
The function of the scp is the general management of the control domain, including assisting in network formation, forming logical connections between other NAUs, and assisting in recovery and maintenance as needed. It also provides an interface to network operator services for that domain.

2. Physical Unit (PU): Serves as 5scp's companion in managing SNA network configuration. Each node defined for 5scp has at least one PU. The PU is where configuration-related services that must be performed on a particular node are provided. Together, the 5SCP and PU control the network configuration and data transfer resources provided by the nodes within the 5SCP's domain.

3. tPl unit) (LU): End user SN
The NAU, LU which is the window or port to access the A network is also the port used by the end user to access the services provided by the 5scp to help establish logical connections between the LUs. . LUs support communication between end users (or LUs) by editing or transforming requests, grouping requests, associating requests with responses, and other forms of bridging with the end user's environment. be able to.

In SNA, nodes, host computers, communication controllers, collective controllers, and terminal nodes are designated as types T5, T4, T2, and T1, respectively. The architectural differences between them are the layers and subset of functionality used for each type. These type numbers correspond to the PU types (PU5, PU4, PU2 and PUI) of each node. These PU types are lower layer,
In particular, it represents data link control and route control functions.

PUI Type 1 (Terminal) Node A terminal is a lower-level node to which one or more input/output devices can be attached that (1) transforms a network address into a local address format or vice versa; ,
(2) When processing normal flow sequence numbers, rely on the boundary function of adjacent hosts or communication controllers.

PU2 Type 2 (Central Controller) Node A Collective Controller (CLC) node can control a wide range of equipment and have data processing capabilities.

A collective controller is used to assist in backing up data flow within a station, to transform network addresses to local address format and vice versa, and to assist in session control of PUs and LUs. relies on the boundary capabilities of the host node or communication controller to which it is connected.

PU4 Type 4 (Communication Control Unit) A node communication control unit (COMC) is a node that processes transmission services for a subarea of the network and controls communication lines and related resources such as line buffers. The communication controller provides intermediate functions and also provides boundary functions for collective controller mates and terminal nodes. There are typically no logical units in the COMC, but there are no architectural restrictions to it.

Architecturally, for example, the COMC may include a portion of the LU of an attached device that cannot accommodate its own LU functionality. Type 4 routing can have segmentation and blocking functions.

PUS Type 5 (Host) Node A host is a type 5 node of a network that has general purpose data processing functionality and may also have intermediate and boundary functions (for example, the boundary functions of a collective controller connected to a channel on the host). The system service control point functions for the control area of a network often reside in hosts. The host hosting the 5SCP is often referred to as the controlling host. Type 5 routing can have both segmentation and blocking functions. A host has all the processing engines necessary to perform its role,
Storage and management functions are included.

Networking refers to a computer complex (usually one
or the same number of computers in 10 or more locations);
This is the concept of geographically distributing the total amount of land (including 1,000 units).

As the need for general-purpose networking functionality increases, conceptual designs must be codified so that hardware and software products work together and each deployed system can be easily tuned for performance and reliability. has also increased. Such systems/370 products, VT
SNA implemented in AM, TCAM and NCP currently provides enhanced networking capabilities. Scott, S., r VTAM is a more logical network management software (VTAM
MeansSoftware for More L
logical Network Management)
J 1Data Communications
8) No.

1 (1979), pp. 77-90; L, Esau, rIBM's How to Access a Network via TCAM.
aNeshi work via IBM's TCA
M) J Data Communications
v8, No. 2 (1979), pp, 89-106
;A, tledeen, rNetworking: Building a Software Bridge between Multiple Hosts (Networking: Building a S
ofware BridgeBetween Mu
lmu1ple l1osts)J) DataC
communications, 8, No. 3
(1979), pp. 87-100.

SNA enabled multiple host networks. J.
P, Gray and T, B, Pine nail (
McNeill), rSNA Multiple-System Networking (SNA Multiple-System N
etvorking) J, IBM 83'st, J,
18 (1979), 1) I), 2θ3-29
See 7. This included the ability for a terminal controlled by one host to access applications on any host on the network, and even establish host-to-host sessions. Single control points and hierarchical control (for the Serashiron establishment and configuration services) have been generalized to networks of multiple control points acting on equal footing with each other. Other enhancements include features such as parallel links, transmission priorities, and multiple active routes for data transmission. Parallel links can be used between adjacent nodes in a network to provide additional bandwidth and backup, and these parallel links can be logically grouped to automatically direct traffic across a group of links. It can also be dispersed. Using this concept, performance degradation resulting from errors on any link in the group is also compensated, since transmission is interrupted only if the last remaining link in the group fails. Improves network availability by providing multiple paths between the same points in a network to reroute traffic (reconnect interrupted sessions) and avoid failed intermediate nodes or links. can also be increased. Multiple routes are also useful for leveling traffic loads. These features gave SNA a mesh network with complete configuration flexibility, unlike previous tree structures and tree connections.

To save costs, networks are typically designed such that the peak rate of traffic into the network sometimes exceeds the maximum network throughput. Network queuing helps smooth peak loads, but flow control mechanisms are needed to prevent significant throughput degradation or even deadlock when the supplied load exceeds the network's capabilities. be. G,A
.

Deaton and J. France (
Franse), ・``Computer Network・
Flow control research (A Computer Network
k Flow Control Study) J, 1
Proceedings of the 978 International Conference on Computer Communications, Kyoto, Japan, 1978, pp.

135-140; V, Routing and Flow Control in System Network Architecture.
ol inSystems Network Arch
item) JNI BM 5Vst,
J., 18 (1979), pp. 298-314.
reference. Flow control operates by limiting the rate at which traffic is accepted into the network. The SNA product receives a pacing response from one end before a specified number of message units are sent from the other end of the path.
Use a flow control mechanism based on pacing. This number is adjusted dynamically by checking the queue depth at multiple nodes along the path.

Using this dynamically adjusted pacing value increases throughput over statistically determined values used in other systems. Another aspect of SNA flow control is the use of message priorities.

That is, on each trunk line, messages are transmitted in the order of priority given to each session in question.

SNA uses predefined routing with pacing, unlike the routing scheme for packet-switched networks, where routing decisions can be made based on every message without establishing an explicit physical path for session traffic. Based on.

Packet switching uses asynchronous time division multiplexing (ATDM) of messages on each segment of each path. Within the switching facility, the line is set up by special signaling messages passing through the network aware of the channels in the path.

Once the path is established, a return signal informs the resource that data transmission can begin, and all channels in the path are used simultaneously. A given message passing between nodes connects the entire link between that pair of nodes.

In packet switching, a storage and forwarding node is provided between two nodes of a subscriber. The packet carrier is (bucket carrier)
(between carrier nodes) to be shared with other subscribers. There may be a series of storage and forwarding nodes in the path, in which case each segment can be time-shared individually among the subscribers. A circuit provided by a packet carrier is called a virtual circuit because it appears to be available to the subscriber, but is actually shared with other subscribers that the subscriber does not know.

A packet-switched network must have an independent signaling phase for the user to exchange control packets with the network to inform the network of the called party's address. After access is granted and initial signaling is completed,
Each user information record must include packet header fields as well as normal data link controls. Once the system determines that the end of the packet header field has been reached, the user is free to use the coded information or any code or bit string for the uncoded information.

SNA's method of accommodating variable length messages from various types of work stages is to provide the ability to segment long messages into more manageable segments. The size of these segments is
The buffers along the route can also be selected and adjusted according to line reliability issues or response time requirements.

The architecture must identify this segmentation and provide the necessary control to effect reassembly of the entire message at the destination point.

Reassembling segments that arrive out of order poses another set of problems because the segments can take different paths. SNA must prevent this out-of-order arrival by routing each source/destination pair through the same physical path. However, in packet-switched networks, additional segment heads and buffer management are used to re-establish the correct order.

In message exchange, the entire message is sent to a central mate where it is stored for as long as necessary until a proper connection can be made to the destination.

On the other hand, in the packet switching process, the source and destination first agree on a logical connection. If necessary to avoid line monopolization, messages are segmented into smaller parts and the segments or packets are routed in real time to their destination via intermediate nodes. Using each intermediate node's destination table, a message can "find its way" to its destination at each node. The primary purpose of message exchange systems is usually to provide final delivery of messages in a reasonable amount of time. This could take minutes, hours, or even days, depending on line availability and load conditions. The main purpose of packet switching is to ensure rapid response times, on the order of a few seconds, while at the same time reducing costs by sharing lines (sometimes high-speed trunk lines).

Message exchange systems have large capacity secondary storage devices and are capable of accumulating relatively large message queues. In a message exchange system, an intermediate node with message exchange functionality assumes responsibility for final delivery. That node acts as a "recovery node" because it is assumed that messages are safe and recoverable once they arrive at that message exchange node. In contrast, a packet-switched system begins with a source-to-destination connection that is pre-established so that a valid interaction between the source and destination names can occur, allowing efficient data flow. To make this possible, the buffering scheme and pacing must be agreed upon in advance. The size of buffers and the management of queues at multiple intermediate nodes can then be made more economical.

Data terminal equipment (DTE) is defined as any type of user equipment ranging from large computer systems to very simple terminals. Data circuit termination equipment (D
A CE) is defined as one that terminates access lines from a carrier's data exchange equipment (DSE) and performs the signal conversion necessary for carrier operation.

Real digital circuits extend from a DCE to another DCE through a DSE network. On the other hand, in a packet-switched network, a real circuit runs from each DCE to a DSE, and virtual circuits are provided between the DSEs.

It requires sharing broadband facilities among multiple unrelated subscribers. This technique utilizes asynchronous time division multiplexing of each message (ie, fixed size packet).

In packet switching, all messages (user information and network call control information) are in the form of discrete units called packets. Packets include headers that specify packet control functions and the packet network destination. Although a packet network appears to be a virtual circuit, or point-to-point connection between a pair of DTEs, it is actually (partially) shared by many DTEs through multiplexing by packet carriers (asynchronous time division multiplexing). Provide a line to be used. These virtual circuits can be switched (
In this case, virtual call setup and clear procedures are required on the DTE).

One of the desirability of data processing systems is the ability to multiplex a number of different sessions through a single interface when different messages each have different destinations. This can be accomplished by creating a logical channel ID to locally specify each virtual circuit. To do this, specify a logical channel group number and a logical channel number locally for each virtual call or permanent virtual circuit. For virtual calls, these are specified during the call setup stage.

In that case, the logical channel ID (logical channel group number plus logical channel number) must be carried in every packet header (other than the resume bucket ID, where these ID fields are zero). The virtual line is
all different logical units in the same logical channel)
(LU) can carry a number of different SNA sessions. A transmission header (TH) (carried within the data field of the data packet) identifies each session. Alternatively, a separate virtual circuit (and logical channel) may be used for each session.

The data exchange equipment (DSE) of a packet-switched network is configured to recognize packets.

All data sent between DTEs is preceded by a packet header. In addition, all network control messages are prefixed with a packet head. Each packet header also includes the virtual circuit's local logical channel ID and packet type indicator.

ARPANET was the first packet-switched network. This network was designed in the 1969 DARPA Research and Development Program. Initially, ARPANET was an experimental network built to test the concepts of packet switching and resource sharing. As ARPANET matured, users began to use it for production rather than experimental requirements.

In April 1982, the US Department of Defense directed the Defense Data Network (DDN) to be implemented as a DoD common user data communications network based on ARPANET technology and architecture. Defense Data Network E.J. Feinler
, rDDN (Defense Data Network) protocol
Handbook (DDN (Def'ense Data)
Network) Protocol Handboo
k) J NVol, 1, US Department of Defense Military Standard Protocol, NTl5 Publication No. AD-A166324, 1985 1
February, and its sister volumes 2 and 3 (DDN Standard). Additional information is available in the Defense Data Network
ce Data Network X, 2511ost
5 specifications)
JNNTIS Publication AD-A137427.19
It was also released in December 1983.

FIG. 2 is a graphical representation of an architectural model of a DoD protocol set. This architecture is based on the International Standards Organization (ISO) Open Systems Interconnection (O
8I) Similar but not identical to the architecture (
The DoD Internet Architecture Model is described in ComputerNetworks, Vo 1.7.
, No. 5, (October 1983) I) p., 293-
328).

The DDN standard establishes a standard for Internet Protocol (IP) that supports the interconnection of communication subnetworks. The standard
It introduces the role and purpose of the protocol, defines the services provided to users, and specifies the mechanisms needed to support these services. This standard also defines the services required of lower protocol layers, describes upper and lower interfaces, and outlines the execution environment services required for implementation.

Transmission Control Protocol (TCP) is a transport protocol that provides reliable data transmission between connection-oriented terminals in packet-switched computer subnetworks and internetworks.

Internet Protocol (IP) and Transmission Control Protocol (TCP) are NDO packet-switched networks that have the potential to connect or take advantage of connectivity across network or subnetwork boundaries. Must be used.

TCP/IP is implemented in network-to-1' elements (hosts, front ends, bus interface units, gateways, etc.) in networks used for Internetization.

Internet protocols are designed to interconnect packet-switched communication subnetworks to form internetworks. IP sends blocks of data called Internet datagrams from a source to a destination over the Internet. The source and destination are hosts on the same subnetwork or connected subnetworks. IP is intentionally limited in scope to only providing the basic functionality needed to deliver blocks of data. Each Internet datagram is an independent entity, unrelated to other Internet datagrams. IP does not create connections or logical circuits and has no mechanisms to facilitate data reliability, flow control, ordering, or other services typically found in virtual circuit protocols.

DDN standards specify host IPs. As defined in the DoD architecture mode, the Internet Protocol resides at the internetwork layer. That is,
IP provides services to transport layer protocols and relies on the services of lower network protocols. At each gateway (a system that interconnects two or more subnets), IP is above two or more subnet protocols. Gateways implement Internet protocols to transfer data durams between networks. The gateway also implements Gateway-to-Gateway Protocol (GGP) to coordinate signaling and other Internet control information.

In an April 1982 directive, the US Department of Defense stated that the Defense Data Network would be implemented as a common user data communications network. With DDN, the Department of Defense will lower costs, improve reliability, and gain interoperability of all information systems and data networks.

Therefore, all major Department of Defense requests for proposals that include communications networking requirements require the use of DDN.

In the early 1970s, IBM adopted Systems Network Architecture (SNA) as the standard for communications networking. IBM communications products developed since that time, including hardware and software, support SNA. But DDN! :SNA is an incompatible standard. Both standards consist of a seven-layer architectural concept that performs various networking functions such as routing and flow control, but the separation of functions into layers and the theory of how the functions are performed differ.

The cost reduction and increased reliability benefits of DDN are not realized for many SNA deployment systems currently within the US Department of Defense because these two standards are not compatible.

The terms used in this specification are as follows.

$5IIA: S/1 for SNA PU function
Product 1 FREEBUF: DDN/SNA buffer management macro to free bar/7 y nGETBUF: 17 to get bar/77
) DDN/SNA buffer management macro IRSTRBUF: D for restoring the buffer
DN/SNA buffer management macro n S A VE B UF: DDN/SNA buffer management macro for saving buffer ABEND: Task abnormal termination ΔDM: Management 8 MOD: Access module PI RJE CAM MF LIST PU SI DDN DDN LC RAM oD SAF SX BCDIC DL DX R Application Program Interface Expansion Remote Job Entry Basic Channel Access Method Buffer Management Function Command Arrival Central Processing Unit Console Service Interface Defense Data Network Direct Data Duram Request Data Link Control DDN Access Method Destination Subarea - Field Distributed System Executive Extended Binary Coded Decimal Code Event Driven Language Event Driven Executive Explicit Route RR EP 5GETQ 5PUTQ 1cF +1LI +1140D P PF PL CL t1 ACLIB MNCI+ 4Vs CCF CD Explicit Route Number Front 5W OF macro to get an element from the end processor queue 5W OF macro to put an element into the queue Host command fist program High-level interface Hardware module input/output Internet protocol initialization parameter file Initial program・Load job control language logical unit macro ・Library mask ・Network control host Multiple virtual storage area Network communication control function Network control area NCF MCI+ NCF N) IVT RD NRI) l, SI DS PI port P140I) PS/2 U IJ2 U4 t15 RΔF ECFMS M OS YSGEN Network Control FEP Network Control Host Network Control Program Network Management Vector Transport Node Resource Distribution Node Resource Distribution List Open System Interconnection Classification Data Set Route Information Unit Virtualization Module Personal System/2 Physical Unit Physical Unit 2 Physical Unit 4 Physical Unit 5 Remote Access Facility Record Format Maintenance Statistics Remote Manager Read Only Storage DDN/SNA System Generation Function DS DLC SNA NAPS SNAP-2: SNAP-5: SNMP-LINK: 5NAP-TIIR Port: scp WOF wap CI NCF G GB Sequential Data Set Synchronous Data Link Control System Network Architecture S NA Portability Software by Data Connections Inc. SNA PU Type 2 Secondary Products SNA PU Type 5 Primary Products 5 DLC Primary and Secondary Link Level Products SNA Inter-domain pass-through Primary product system Φ Service control point system Tatami wide φ Operator function system Wide operator program Transmission control interface Transmission control protocol Transmission group Transmission group Control block TSO: Time division function [IDP: User・Datagram protocol vH: Virtual machine vR: Virtual route VSA14: Virtual memory access method VTA1
4: Virtual Memory Communication Access System Pending Related Patent The related concept of input/output control is filed in April 1987 at 290 and assigned to the present applicant by S. L. Estrada (
U.S. Patent Application Ser.
rent Multi-Protocol Ilo C
controller) J. This disclosure is incorporated herein by reference.

PROBLEM SOLVED BY THE INVENTION It is an object of the present invention to provide network interoperability from a host computer to enable communication between SNA-implemented systems over a packet-switched network such as a DDN. It is in.

Objects of the present invention also include providing SNA terminal-to-SNA host functionality that allows connection of remote products such as collective controllers and associated terminals, as well as direct connection of personal computers.

It is also an object of the present invention to provide a centralized network control that provides a centralized communications network manager.

Objects of the present invention also include providing host-to-host communication functionality that allows MVS and VM host systems to address and communicate with each other via a DDN - resulting in a direct communication database.

SUMMARY OF THE INVENTION The above and other objects, features and advantages are achieved by the invention disclosed herein. The overall function of the present invention is to provide basic operational capabilities of the SNA for host-based inter-arrival access and remote terminal full-screen access via the Defense Data Network (DDN). The problem that arises with the integration of these two technologies is that SNA is a connection-oriented technology and DD
N is a connectionless packet switching technology that requires Internet Protocol (IP) headers for all information transmitted over a network or across networks.

One of the two key concepts utilized in this system is to define a local SNA network for each SNA host with a front end processor (FEP) attached to the channel. These FEPs present SNA LU2 definitions or 5NAPU4 definitions to the host, allowing the host to exercise regular control over the host application or terminal user.

The second key concept implemented in this system is the provision of a primary SNA support (PU5) in the Remote Access Facility (RAF). Thereby, each R
The AF can control all SNA terminals and devices connected to it as an individual network. R.A.
The F and FEP work together to embed SNA protocols into IP datagrams and provide proper SNA connectivity and control.

This technology also allows any terminal to access any authorized host. This is currently not allowed in normal 5NAX, 25 networks.

Accordingly, the present invention provides SNA terminal-to-SNA host functionality that allows connection of remote products such as 3274 aggregate controllers and associated terminals such as 3278 and 3180 devices, and direct connection of PCs that emulate 3270 devices. Realize. The present invention also implements centralized network control for a centralized communications network manager using IBM network control program products such as Network Communications Control Facility (NCCF) and Network Problem Determination Authority (NPDA). The present invention further realizes an inter-host communication function, and
and VM host systems to address each other, D
can be communicated via DN, realizing direct communication between database products.

E. Embodiments The present invention solves problems in using DDN communication networks in an SNA environment. FIG. 1 shows the development of the system's own protocol of the present invention.

The invention has three basic functions.

SNA terminal-SNA host function - This function supports 327
Remote products such as 4-set controllers and 3278 and 3180
It allows related terminals such as 3270 to be connected, and also realizes direct connection of a PC that emulates a 3270 device.

Centralized Network Control Facility - This implements a centrally controlled communications network manager using IBM's network control program products, such as the Network Communications Control Facility (NCCF) and Network Problem Determination Application (NPDA).

Host-to-host functionality - This provides communication functionality and allows MVS and VM host systems to address each other and connect to DDN.
can be communicated via an information management system (I
It enables direct communication between data-based products such as MS) and office system products such as Professional Office System (PROFS) and Distributed Office Support System (DISO8S).

This technical solution requires the use of a Series/1 (S/1) processor as an interface between commercially available hardware/software and the DDN.

The S/1 processor is configured to perform the following three functions. (1) IBM SN/A host and DD
N's interface';: ll12 LD D N
/SNA Front End Processor (FE)
P), (2) Downstream SNA DDN/SNA that performs the terminal collection function that interfaces between PU2 and DDN.
a remote access facility (RAF) and (3) a network control front-end processor (NCF) that provides communications network management (CNM) support for the S/1 from a centralized network control host.

SNA Terminal-SNA Host Function The present invention provides basic SNA terminal bus-through functionality using DDN communication functionality. This is a full-scale software development that includes three main activities. Firstly,
A series of portable SNA products will be ported to the 68-based coprocessor to provide primary SNA (PU5) capabilities to the RAF and FEP. Second, we develop channel interface code for the f38-based coprocessor in FEP. Third, for overall control of SNA functionality, a set of event-driven executives (EDX), input/output drivers, and EDX for external style (68K) SNA services.
Application Program Interface (A
PI) and system support functions (ie, loaders, dumpers, debuggers, compilers, etc.) and/or port them to the 68 card. As a result, the IBM SNA terminal (3270)
A hardware/software package is obtained that allows access to any IBM SNA host on N. This package has a FEP interface to the DDN and allows application programs in the IBM SNA host to access any printing device connected directly to the RAF printing device or to any printing device connected to downstream PU2. .

Centralized Network Control Function This is a software function that provides a single point of control of the IBM FEP/RAF interface to the DDN. Existing IBM Communications Network Management (CNM) products for SNA networks can be used. The Network Communication Control Function (NGCF) and Network Problem Determination Application (NPDA) program products are utilized on the network control host. The S/1 RAF and FEP generate asynchronous problem notifications (SNA alerts) for the NPDA to inform the NPDA terminal operator of faults detected in the network.

The Host Command Facility (HCF) is used by the network control host to control each FEP/RAF on the network.
Provide remote operator support for S/1. N.C.F.
A terminal operator can operate any S/1 as if he were sitting in front of the S1/EDX console.

This HCF terminal operator can introduce tasks, cancel tasks, query resource status, activate resources, and deactivate resources.

The Distributed System Executive (DSX) program product is utilized on the network control host. DSX functionality is used to centrally control software distribution, configuration data, user authorization files, and audit trail files on a network control host.

This results in an integrated set of software residing on the FEPlRAF and NCF. This set, NCC
When used with FlNPDAlHCF and DSX program products, IBM S/I connected to the DDN
Centralized network control of RAF and FEP is achieved.

Host-to-Host Functionality The present invention provides host-to-host functionality that allows IBM SNA host-based program products to communicate with each other over the DDN. With this host-to-host capability, IBM SNA supports Distributed Office Support System (DISO8S), Systems Network Architecture Distributed System (SNADS) and Customer Information Control Subsystem (
CI C8) Effective use of DDN for host-resident applications such as intersystem communication
NA hosts can communicate with each other.

Host-to-host functionality resides in the FEP. This feature is
A host-to-host product is used to provide a communications vibe for a Virtual Telecommunications Access Method (VTAM) to communicate with other VTAMs connected to the DDN by other FEPs.

The SNA explicit routine/virtual path function normally executed in PU4 (37x5) is SNA implemented in S/1 using the TCP/IP/X, 25 communications card. The result is an integrated set of software functionality that resides on the FEP, allowing commercially available IBM software program products that use SNA VTAM to communicate between IBM hosts and use DDN for their host-to-host communications.

Designing the Host Interface The VM Host system includes a VM TCP/IP interface program. The FEP program is
Allows users to send data files to hosts connected to the DDN. The host system is
Includes image mode file transfer functionality for VM DDN programs, allowing users to send executable code files through a VM host and retaining the ability for the files to be executed on the receiving host.

The MVS host system uses MVS's TCP/IP to connect MVS to the DDN.

25 interface, including a high-level data link control remote host (HDH) interface using S/1 to connect the MVS to the DDN.

For this reason, all existing (HDH) installation systems
It can be converted to X,25 when necessary without any hardware changes.

The S/1 front end processor (FEP) is
, DDN MVS and VM using 25 interfaces
can be connected to.

The following sections explain how to adapt X,25 to the system architecture and why the ACP is changed.

System Structure The communication layers required for DDN are implemented across the host and FEP. The host provides the session layer, presentation layer and application layer. This includes Te
lnets SMTPN FTP'%TCP&IP
is included. The S/I FEP provides a network access layer (X, 25), a data link layer (HDLC) and a physical layer.

On the host, these services are
System (MvS), vTAM and AcP. In S/1, the remaining services are the system's operating system (EDX) and
(X,25 Network Layer Program). See Figure 3.

ACP Structure The ACP resides on the host and consists of three main components:

1. User e-level Φ protocol service-user
FTPN Tel for level protocol services
ne and SMTP.

2. Transport level fist protocol service - transport level
Protocol services include Transmission Control Protocol (TC
P), Internet Protocol (IP), Internet Control Message Protocol (ICMP), and User Datagram Protocol (UDP). These services communicate with higher level protocol services through an internal ACP interface called the "A-Level Service Interface." It also communicates with network layer services.

3. MVS secondary operating system (ICT) -
The Engineering CT is a "mini" operating system that acts as the MvS system service interface. Higher level protocol services and transport level
Both protocol services are referred to as "P-level services.
It interfaces with ICT through an interface called "interface". -See Figure 4.

network layer structure The network layer is primarily represented in S/i.

The EDX operating system manages input and output to and from the host and the DDN network. XN
LP runs as an application program under EDX. It communicates with the ACP's Network Access Protocol (NAP) via a channel interface on the one hand and the X
, 25 to manage communications.

NAP exists only between the host (ACP) and S/1 (SNLP). Its functions are the IP layer of ACP and
The goal is to provide a path between the X and 25 layers. N.A.P.
provides a reliable flow-controlled interface between these two components via host input/output channels.

Network Access Protocol Description The procedures present in this protocol are
P datagram interface, as implemented in S/1.

25 upward facing interface.

IP generates network binding datagrams for host higher level protocols. Host resident NAP
generates an X,25 data terminal equipment (DTE) address using a simple conversion algorithm. NAP prepends this field to each datagram and forwards it to S/1. In S/1, this field is examined and X,
25 virtual circuit exists at that address in a predetermined priority order. If found, the appended address is removed and the datagram is forwarded on the existing wire. If not found, XNLP establishes the circuit using the ACP generated X,25 DTE address. Once established, datagrams are transferred.

For inbound traffic, datagrams are
XNLP receives the call via the 25 virtual circuit. These datagrams are queued to the host and are forwarded to the host in the order they are received from the network.

X,25DTE address is not added. In the host, the NAP and IP receive the datagram and forward it to the appropriate receiver represented by the host's higher level protocol.

X,25 Virtual Circuit Management - Due to the explicit layering in this example, the ACP cannot see the X,25 virtual circuit. The ACP's only involvement in the X,25 specific functionality is that an X,25 DTE address is generated when the ACP forwards an IP datagram to S/1. That is, S71 independently manages the virtual circuit.

As mentioned above, when a datagram arrives from a host destined for a remote destination where no circuit yet exists,
A line is established by LP.

A circuit may be established as a result of incoming X,25 calls from the network. The ACP only sees this as the arrival of a datagram with a different datagram address.

A virtual circuit can be cleared from the remote end of the virtual circuit or by XNLP itself. In the latter case, clearing occurs when S/1 detects line inactivity for a predetermined period of time.

Finally, S/1 has provisions to ensure that flow control conditions on one virtual circuit do not throttle the flow of data on other virtual circuits leading into the network.

Since the host is not aware of virtual circuits, this flow control is only implemented by S/1 using an internal buffering scheme. The flow of datagrams on the channel interface from the host is throttled only if S/1 encounters a system-wide buffer exhaustion condition, not because flow control stops on a particular virtual circuit.

Support for MVS Distributed Databases To provide a distributed database using DDN, the ARPANET Control Program (ACP) user
Level interfaces are extended to enable the DDN Internet to establish communication links between multiple hosts running relational database systems (DBs). Every host must run the UCLA ACP in order to run an instance of the DB and communicate over the Internet. Therefore, each DB can communicate with any of the other DBs. The degree of parallelism is limited only by the inherent limitations of the DB itself and the limitations of resources such as the main storage device.

Basic knowledge about the DB/VTM interface A DB runs in its own MVS address space and
Al is a relational database that calls a module called ET and communicates with other DBs using the SNA protocol. The DNET module runs under ClC8 and locally interfaces with VTAM to obtain SNA communications services. DNET is SNA
Use the lowest level of communication. Specifically, it interfaces with VTAM as a type zero (LUO) logical unit. Using LUO, management of VTAM sessions is essentially the same as when a remote terminal (a "secondary logical unit" or 5LU) is in contact with an application program (a "primary logical unit" or PLU). Becomes asymmetrical. SLU plays an active role and PLO is passive. That is,
They correspond to the ``user'' (active) side and the ``server'' (passive) side in Internet terminology.

VTAM provides DNETs with a communication interface that is completely independent of the physical location of remote DNETs. SN
Within A, physical locations are defined by routing local host generated tables to the front end processor.

Communication between two DBs is not continuous, but consists of bursts called "transactions." A transaction is initialized by a DB called a "client" and another DB called a "server." A single transaction typically consists of a single request message from the client to the server, followed by a single response message from the server to the client. A new SNA session is set up for each transaction. A single message can be up to 85 bytes, but the average is 3 to 4 bytes.

Basic knowledge about the ACP/VTAM interface ACP is the DOD Internet Protocol (IP)
For user processing and server processing under MVS,
Provides a communication interface to the DDN. ACP
uses VTAM to perform throughput communication within the local host (
IPC). VTAM provides IPC functionality in the form of inter-LU sessions. In each inter-LU session, a logical terminal communicates with a terminal handler program. That is, the secondary LU or terminal requests VTAM to establish communication with the primary LU, typically a terminal handler in a server subsystem. Each primary instance can be connected to any number of secondary LUs simultaneously. ACP can operate in either primary or secondary order. This is the IP term server (passive)
corresponds to the side and the user (active) side.

Each user or server session within an ACP has one or more User Level Protocol Processing (ULP
P) processed by a routine.

ULPP generally uses Internet Protocol and virtual I
Converts between BM terminal protocols.

User ULPP is a local user who connects VTAM to A.
Created when a connection is requested to a CP program. The user ULPP then interfaces with TCP/IP to establish a DDN connection with the remote host via a well-known port. On remote hosts, TC
Since the P/IP connection has been established, the server ULPP is created.

The server ULPP must open a VTAM connection to complete the translation path.

New DB-ACP Interface By modifying the ACP to interface with VTAM as a virtual DNET on each host, you can create transparent data connections between two DNETs running on different hosts.
A channel was set up. That is, the SN
A communication is executed. However, data is encapsulated and sent over a TCP connection between ACPs on two real hosts.

FIG. 5 reduces the communication path between a client and a server that performs Internet communication using ACP.

In DNET applications, TCP is an end-to-end transport service (ISO terminology) that provides a reliable, flow-controlled, full-duplex virtual circuit called a "connection."

A TCP connection acts as a simple byte pipe with no inherent record structure. TCP is responsible for disassembling the byte system into packets and reassembling the packets into receive buffers as necessary.

Each end of a TCP connection is called a "socket" and is marked with a pair of tffi2 ("host address", "port"). However, "port" is a 16-bit port number. Ports in the range 1-255 are each assigned (by convention) to a specific service, and these are
It is called a "well-known" port (WKP).

The client/server model is a natural fit for TCP. For example, a client program on a remote host sends a TCP connection request and specifies WKP on the local host. The ACP uses the appropriate server program (ULP
P) and send it the identification of the local and remote sockets. ULPP can then complete the TCP connection and provide services.

One socket can participate in any number of connections to multiple sockets. Therefore, there may be multiple parallel connections to the same WKP for a given server host.

Communication between DNETs required the protocol hierarchy shown in FIG.

The DB application protocol is independent of the underlying layers. DB messages are (of course encrypted in some way) a completely arbitrary stream of bytes.

However, DNET was designed for SNA transport services with characteristics that differ from TCP in several respects. In these applications, I! It was necessary to insert a small or thin protocol layer to provide the missing functionality expected by the application. This was called the DNETN Reverse T-Vis Protocol (DTSP). SNA has an implicit definition of message boundaries, whereas TCP does not.

Therefore, it was necessary to include some kind of message delimitation mechanism in the DTSP.

The standard method is to divide the message into segments,
Each segment was preceded by a header containing (1) the length of the segment and (2) the end of message bit.

FIG. 7 shows a 4-byte header.

That is, one segment consists of up to 2" IF5 - 1 byte. If it was necessary to add other DTSP functions, the filed "instruction code" was used, but now it is ignored. .

The following LU VTAM usage profile for DNET was established. This VTAM usage is such that the ACP's existing VTAM Application Program (PLU) and Virtual Line Terminal (SLU) modules have been adapted to meet the following requirements.

1. No bind image check 2. Maximum buffer size E35, average buffer size 4-6 3. No chaining, no blanket 4. No SNA response 5.1 No order number 6. Receive-only element and send Using Only Dedicated Elements 7.3 The LU serves as the session initiator.

8. The PLU must support up to 4 SLUs.

DDN/SNA Design This design of integrating SNA with DDN (DDN/SNA system) allows IBM commercial SNA products to effectively use DDN to communicate between these SNA products, and allows non-IBM DDNj- -The IBM MVS
Applications running on /VTAM hosts or IBM concentrators can be accessed, allowing terminal users connected to IBM concentrators to access applications on non-IBM DDN hosts.

Insert an S/1 processor between the IBM SNA product and the DDN. The functions performed by this intermediate S/1 convert the SNA protocol into a transport level protocol (TC
P) Encapsulation within an envelope to allow SNA sessions to be established over the DDN, 18M
Performing the necessary protocol conversions when terminal users access DDN-compatible applications to provide interoperability to remote SNA terminal users even when they go to the host, and for non-IBM terminal users connected to the DDN. to install the DDN on the IBM host.
The goal is to provide access to compatible applications. The main features provided by the IBM DDN/SNA design are:

Provides network virtual terminal users access to IBM MVS/VTAM applications running on 18M hosts.

IBM MvS/VTAM host or IBM S/
1) Allows network virtual terminal users to access DI) N-authorized first-level protocols (NET, FTP, SMTP) running on one concentrator.

While maintaining the flexibility and functionality of IBM SNA products, IBM
Enable SNA products to communicate.

An 18M terminal user locally connected to an IBM MVS/VTAM host is connected to a non-IBM terminal user connected to r) DN.
Allows access to kill the DI N-authorized first-level protocol running on the host.

An 18M terminal user connected to an IBM S/1 concentrator is connected to a DDN running a non-IBM host connected to the DDN.
Provides access to DN authorization upper level protocols.

Provides IBM S/1 centralized control used to interconnect SNA networks with DDN.

What is provided by the present invention will be described below.

FEP/RAF-DDN Continuation Overview IBM SNA products provide DDN through the IBM S/L processor, which performs the roles of communications server and communications concentrator.
Connected to DN. For IBM MVS/VTAM hosts, S/1 supports multiple SNA P to DDN
Provides a U2 interface, SNA, one PU4 interface and one ACP interface. S/ connected to IBM MVS/VTAM host
1 communication server (tDDN/SNA called Front End Processor (FEP). Downstream S
For NA PU2, S71 provides a communications concentrator interface to the DDN. downstream SNA
S/1 concentrator that supports PU2 is DDN/SNA
It is called a remote access facility (RAF).

Network Control Overview All DDN/SNA S/1 nodes, F'EPs and RAFs are provided by IBM for network control services.
MVS/VTAM host is affected. This host is called the Network Control Host (NCR).

The NCH has a dedicated S dedicated to executing network control functions.
/1 is prefixed. This S/1 is the network control FE
It is called P (NCF).

The area of network control encompasses the network of S/1 computers used to interconnect the DDN with IBM equipment connected to the S/1 computers.

The network control function investigates problems on the physical links connected to the DDN.

There are three functions used to perform network control. Those functions are implemented by the remote manager program product for S/1.

1. Problems detected by RAF or FEP are
Reported asynchronously to the network control host as an NA alarm message. These messages are spooled by the NCCF/NPDA program product running on the network control host. The NCCF terminal operator can scan the alert spool file using the alert history display screen. In addition to supporting alert files, alert messages are filtered by the NPDA to immediately output a recent event display screen to the active NPDA. NCCF terminal operators with activity alert screens can monitor whether they have received a summary of critical alerts from NCCF/NPDA. This operator can request event detail display to examine each alarm in detail.

2. The NGCF terminal operator shall, based on the data received in the alarm message, send the S/NGCF terminal operator that issued the alarm message.
An HCF session with one Host Operator Function (HOF) can be obtained. While remotely operating the S/1, the NCCF/HCF terminal operator can query the status of various S/1 components to further determine the cause of the problem. The basic problem determination tool is
Operator commands/responses are used to implement problem determination processing that is the same whether the S/1 is running locally or remotely.

3. The NCFF terminal operator is the D
An SNA session between the SX program product and the relay function of a remote management facility running on an RAF or FEP can be invoked to transfer files between a designated S/1 and a network control host (NCH). These files can also be installed in new network configuration tables or in new program programs distributed across the S/i.
It can also be a load module. It may also be an error log maintained by S/1 that is retrieved for further analysis at the NCR.

Host-to-Host Physical Unit 4 Support The S/IFEP provides physical unit type 4 subarea routing functionality. This subarea routing feature allows IBM
MVS/VTAM7 program residing on the host
'/a can communicate with MVS/VTAM applications running on other IBM hosts connected to the DDN with S/IFEP. The types of applications that utilize this SNA host-to-host functionality include:

VTAM Cross-Domain Resource Management Program (CDRM) CICS Intersystem Communications (ISO) DISO8S SNA Distribution Services (SNADS) The subarea routing function supports explicit route (ER) and virtual route (VR) functions in SNA networks. . Supported Path Information Units (PIUs) include:
There are the following:

Activating Explicit Routes Activating Virtual Routes Deactivating Virtual Routes Deactivating Explicit Routes The S/I FEP performs subarea routing functions between PU5 hosts with a minimum PU4 suffet,
Provides physical unit services (PUS). These services enable physical link activation to DDNIMP, establishment of appropriate ER and VR to remote hosts,
Asynchronous notification by the locally attached 5SCP (VTAM) of any network failures detected by the FEP, asynchronous notification by the designated network control host of any network failures detected by the FEP, and orderly control of FEP network resources. Deactivation is achieved. Supported SNA format PIUs include:
There are the following:

Activate a physical unit Start data traffic Activate a link Set control vector Contact Contacted Inoperable Network service lost Subarea Explicit route Inoperable Virtual route Inoperable Deactivate a link Deactivate a physical unit Example of DDN/SNA prototype system Figure 8D
An example of a DN/SNA prototype system is to:

1.8/I External (88000) resident S in EDX environment
We prove the feasibility of the NA protocol.

2. 5NAPS products for 68000808 environment
Check the port.

5NAP-L I NK -5DLC Data Link Control 5NAP-2-SNA Physical Unit Type 5NAP-
5-SNA Physical Unit Type 5NAP-THRU
-5NAPS bridge between 5NAP-5 and 5NAP-2 3.5NAPS products and commercially available IBM SNA products (MV
S/VTAM137X5/NCP and 3274-81C
) to test their interoperability.

4. Designated DDN/S for Front End Processor (FEP) and Remote Access Facility (RAF)
Provides the basic building blocks for implementing NA functionality.

5. Provides real storage space allocation and size for external SNA functions.

6. Provides a prototype configuration of a DDN/5NAFEP/RAF environment for obtaining benchmark throughput and response time measurements.

An example of the configuration is shown in the configuration diagram shown in FIG. DDN in Figure 8
The components of the /SNA configuration example include the following:

1.68000 External SDL resident on communication card2.6
External NS PU2 resident on 8000 coprocessor 3. External SN P resident on 68000 coprocessor
U5 4.68000 coprocessor operating system and input/output drivers to S/1 S/I EDX access method 6 for communicating with 5.88000 output processors, external 5NAPs not residing on the same external 68000
S/IEDX Routing Module 7 for sending data between S products, S/I EDX application with external 5 NAPS products 1
)-based Defense Data Network (DDN) communications system. This model is created to predict transaction response times for different S/1 configurations of user-loaded transaction scenarios. This model has information that describes the hardware, software, protocols, and workload characteristics of the architecture.

The features of this model are then translated into mathematical equations that constitute the network of queuing representations of this architecture. This model uses two mathematical algorithms to perform performance measurements. The model is based on queuing theory networks (using standard queuing algorithms), which can be solved by Jackson's theorem and heuristic techniques.

The results of this model consist of a combination of components of transaction delay and reports that describe specific details of resource utilization and memory usage.

This model calculates response times in the normal configuration shown in FIG. Assume that the SNA controller is a 3274 with a display head, such as a 3180 or 3278, or a PC emulating secondary SNA functionality. These control devices are connected to terminal S/1, which is connected to the DDN.

Host Front End Processor (FEP)
is connected to the DDN and then channeled to an IBM or equivalent host. The configurations of terminal S/1 and host S/1 are shown in FIGS. 10 and 11.

Input Requirements Description The input parameters listed below are used in the system performance model. These parameters will vary depending on system requirements and user application date.

1. Packet header size - This parameter
/1 Specifies the size of each type of packet that requires resources. The value of the parameter is derived from the protocol specification,
It is a constant value.

An example of a packet header size is the TCP/IP packet length.

2. Software execution time - This parameter is S/1
It describes the entire service requirements for each protocol and software. An example of software execution time is S/
1 SNA protocol processing time.

3. Interface/Channel Transmission Rate - This parameter contains information about the data transmission rate of two types of serial lines: the S/1 output bus and the National Defense Data Network. An example of interface/channel transmission rate is DDN packet transfer delay.

4. Workload Information - This parameter describes the transaction arrival rate and chain size values.

An example of workload information is the size of request and response chains.

5. Configuration information - This parameter is modeled S/1
Define one hardware architecture. An example of configuration information is the amount of serial links from S/1 to DDN.

Explanation of output results 1. An example of the output of this model is described below.

This model output is an example of a "basic result report" for a particular combination of system parameters, including output timing. A summary of the key human parameters and output results is shown below (all times are in seconds).

Input parameter number of users: 100 terminals S/1
Number = 5DL per 4 terminals S/1
Number of C links = 8 Number of request packets
: Number of 1 response packets : 5
Transaction throughput through host S/1 = 2 host delay 1 output result average response time (first packet of response): 2.
21 Average response time (last packet of response):
3.21 Request bucket delay (first packet in chain)
: 0.591 Request packet delay (last packet in chain) : 0.591 Response packet delay (first bucket in chain) : 0.620 Response packet delay (last packet in chain): 1.612, below The detailed delay breakdown shown represents information regarding the various components of the one-way bucket delay.

DDN delay: 0.122 SDLC link delay request: 0.227 SDLC link delay response:
0.240DDN I/F delay request: 0.1
10 DDN I/F Delay Response: 0.125 Processing Delay: 0.130 Output Channel Delay: 8.293, Resource Utilization List shows S/1 processor, serial line and channel utilization.

More Detailed Description of the Invention A portion of the software for the DDN/SNA design was developed by IBM
Series/1 (S/1), resident on MC68000 hardware and SNA hosts.

This software enables the flow of SNA host-to-SNA terminal traffic, SNA host-to-host traffic, and SNA network control traffic over the DDN. FIG. 12 shows the hardware configuration used in system testing to test data flow. The diagram also shows what commercially available hardware and software can be used for testing.

System traffic flows between SNA remote terminals and
This may be between NA hosts, between SNA hosts, and for SNA network control traffic. Figure 13 shows
It shows how data flows in terminal-to-host traffic, host-to-host traffic, and network control traffic. This diagram shows the S/1 Front End Processor (F'EP), Remote Access Facility (RAF) and Network Control FEP (NCF).
) possible combinations of functions are also shown. Note that the NCH can also be part of a network and can communicate with remote terminals and hosts.

The software hood between SNA terminal and SNA host is S/
Contains all the code necessary to support 3270 devices connected to the I RAF and connects those devices to S/I
It communicates with the SNA host as a locally attached device via FEP.

Physical Unit 2 (PU2) terminal traffic may operate on the DDN and RAF Support Physical Unit 5 (PU5) I-RAF to control attached terminals.

The code also generates and distributes the tables necessary to define the configuration of SNA terminals and SNA hosts. These tables are generated on the central MVS SNA host and distributed from there to the S/I FEP and S/I RAF.

SNA host-to-host software code implements all functionality and error recovery logic. This code allows users to obtain host-to-host physical unit 4 (PU4) traffic over the DDN. An example of a host application that sends PU4 data is the 1MS1 Customer Information Control System (CIC).
8), Job Entry Subsystem 2 (JES2), Job Entry Subsystem 3 (JES3), and Remote Spooling Communications Subsystem (R3C8).

The code also generates and distributes the tables necessary for this function to define configuration and routing between SNA hosts. These tables are generated at the central MVS SNA host and distributed to the S/IFEPs from there. The code cross-checks the routing information because the tables for all hosts are generated on a single host. This check finds invalid routing information and changes
Corrected by host before dissemination to EP. This feature saves user time when modifying existing systems and creating new systems.

Centralized network control software code connects commercially available host network control products to commercially available S/1 network control products. The product on the host has Netviewz host command functionality (H
CF) and Distributed System Executive (DSX). The product on S/i is a remote manager (RM)
and the Host Operator Function (HOF). This code provides the user with the MVS SN, called NCR.
Provides the ability to monitor and control all FEPs and RAFs from the A host.

The code also connects all F
Performs distribution of any code updates to be sent to EP and RAF. This code minimizes problems associated with applying and tracking new releases of code on a user's network.

The part that touches the TCP and IP S/1 connection processor is
This included providing an X, 25 packet, and frame level below these protocol layers. On host S/1, the connection process.

An application program interface was designed under the EDX operating system to allow convenient access to TCP connections maintained by code running on the system.

Moving network management protocol processing to connection processors makes their functionality and configuration difficult to access.

For example, there are no terminals directly connected to machines that have these protocol capabilities. In fact, there may be no terminals on S/1 at all. Network management and default location discovery becomes very difficult if no attention is paid to protocol porting design.

Protocol code has been woefully inadequate in these fundamentally important network management issues.

What was originally perceived as an "implant" actually included tracking points and event counters at key points within the various protocol layers, providing critical performance from the diagnostician who may be far removed from the S/1 under examination. It has been painstakingly designed to allow convenient access to and history items.

Analysis of intermittent failures at lower levels of communication protocols is often overlooked because the affected levels are more tolerant and robust to failures. For example, line errors are automatically corrected at the X,25 frame level and are not visible to users within the facility unless performance degradation is felt by the user or the error is severe enough to cause an outage. From the user's point of view, it is difficult to infer anything simply by sensing a decrease in performance. The error may be occurring at a lower level, or the system may simply be using more than normal. Resolving these ambiguous and often time-consuming conditions requires examining the low-level behavior of the protocol in real time, ideally without removing the faulty connection from use.

With this in mind, we defined a strategy to detect fault locations online at various protocol layers in a manner that minimizes perturbation of the operating system and is easy to implement. This type of code can be as long and complex as the actual protocol code in use.

In the layered model of flow control DDN, TCP is a connection-oriented protocol. This has a cloud that connects the user and the server, and
At the same time, the receiving end of a TCP connection is not exceeded by the sending end of the connection, ensuring reliable data transfer and controlling the flow of such data on a connection-by-connection basis.

At the network layer below, X,25 is similarly connection-oriented, but in this case on a per-virtual circuit basis. Flow control ensures that the sender of a packet at one end of a virtual circuit does not exceed the receiver of a packet at the other end of the circuit.

There is no correlation between TCP connections and X.25 virtual circuits, and the flow control protocol implemented by these two layers
Ja operates autonomously.

There is an IP layer between TCP and X,25. IP is unconnected. This layer simply sends and receives datagrams from the lower layers (X, 25) and is not aware of the virtual circuits or flow control procedures operating over the TCP connection.

Since IP is connectionless, it does not participate in any connection-oriented flow control procedures. That is, the flow control stop is induced at the remote end of the virtual circuit, so that the lower layer
When a layer is "backed up," it actually only has a simple on/off plunger that can be used when decompressing IP to provide more datagrams. Since decompression is applied uniformly to all datagrams leaving IP, it is possible that one or more virtual circuits owned by the
All flow from P to that layer may stop. IP
When all flows from the X,25 link stop, all TCs on the
This has the effect of denying access to user P.

This problem is considered to be a serious drawback fixed in layered architectures that include connectionless layers.

This problem is rooted in the lack of buffering schemes for the communications subsystem. The term "decompression" above refers to X, 25
The IP layer guarantees a TCP connection window value for each TCP connection using the IP service.
This indicates that the data durum cannot be buffered. X.

If T.25 can absorb all the TCP data outbound enough to force the window to close on all TCP connections, then the TCP
P flow control procedure is triggered.

TC is responsible for buffering large amounts of data at the X, 25 level.
Since the P window is very large and there may be a large number of connections operating through a common X,25, it is impractical in many cases (including the work being done).

Therefore, buffer anno I'i at various levels and connections
J. A set of prompts for managing resources at various levels of the protocol in order to balance requirements and allow fairly fair compromises to be dynamically established based on the instantaneous demands placed on the buffer system. -Developed Java.

These blowers operate across all levels of the sub-stem. In fact, if X,25 starts consuming too many buffers queued for transmission, a control is implemented to start restricting the flow from TCP to IP. Similarly, this decompression operation can also be applied between the interface to TCP and S/1. Even if the IP is disconnected, this control procedure developed
5 and TCP flow control in response to each TCP in use.
Maintain a fair allocation of buffers across connections. In practice, I
A "shell" was developed around P.

A design requirement throughout the development of multiple TCP instances was to have multiple interface cards to the DDN. This requirement was deemed important both to increase the bandwidth between S/1 and the network and to provide alternative paths between these two points.

Each card connected to the network is connected to the network layer and transport layer of the DDN, namely, X, 25, IP and T
Holds CP. That is, multiple cards imply multiple instances of X,25 and TCP on a common S/i.

While working on this implementation, several important issues have emerged. Not only DDN but also open system interconnection (O
8I) Regarding standards, it has also become clear that shortcomings exist in the set of protocols.

That is, the actual routing of transport connections within a host with multiple instances of the transport layer cannot be determined. I think the drawback is that the physical instance of TCP (!J: or O3I TP) does not have an address itself. Instead, the network address value that defines a TCP connection (boat) consists of an Internet address (host address) and a boat on TCP.

By implication, the terms "host" and "rTCP" appear to be synonymous since there is no specification of the address of an instance of TCP within the host.

On top of these multiple TCPs are higher level protocols (
Suppose that there is one instance of S/1 (Telnet, FTP, SMTP) and that we want to represent S/1 as a single host to the Internet from this point of view.

Assuming that a connection to a common service is established through one of these TCPs, there is no problem as long as the virtual circuit backing the connection lasts for the duration of the TCP connection. However, if none are free and available, the virtual circuit may be preempted by other higher priority connections. TCP allows this preemption because it has no specific knowledge of the underlying X,25 operation. Therefore, the TCP connection can survive even if the X,25 virtual circuit is deleted. If the virtual circuit for that connection can be re-established before a timeout occurs within TCP, the user will not know about the temporary loss of the circuit.

However, if there are multiple hardware connections, the re-established circuit may take a different physical path to S/1 on other network interface cards under other instances of TCP. . The net result of taking a different physical path is that the TCP connection fails because the virtual circuit cannot be re-established to the appropriate TCP.

There is no solution to this problem. When researching this problem, we thought it would only be a significant issue if the virtual circuits were preempted, and therefore the X
, a strategy of providing 25 logical channels on each card was adopted.

Having multiple TCPs on a single host introduces other problems. Supports arbitrary link selection by the Interface Message Processor (IMF) when routing incoming active ovens for a higher level service to be provided as a common host over multiple physical links. To do this, a passive TCP oven must be established on each such link.

A third issue has arisen regarding the possibility of "crossed" active ovens. A "cross-over" active oven occurs when each end of the connection to be established exhibits an active oven relative to the other end. However, due to an uncontrollable selection strategy imposed by the IMF, these active ovens flow on two different hardware links. Since individual TCPs do not know about each other's activities, connection deadlocks can occur.

These issues suggest that a common point of control is needed to manage the establishment of TCP connections over multiple TCPs on S/1. Therefore, we have studied TCP implementations and determined that the S/1 control code can be activated in a way that monitors the connection establishment process but does not burden the normal TCP functionality on the connection processor.

This design is complete and satisfies the above issues. When viewed from the upper level, the existence of multiple TCPs is hidden and only one TCP is visible. That is, only one passive open needs to be performed.

Blocks incoming active ovens from the network, and if a match with a passive open is found, tells the attachment mechanism to accept the oven and complete the connection. It no longer matters which card entered and carried the active oven. In the case of "crossed" active oven requests, an arbitration scheme was established based on the numeric values of the source and destination addresses that guarantees the completion of the connection over a single virtual circuit.

Although intervention by the S/1 code is required during TCP connection establishment, this solution is designed not to interfere with TCP functioning in the connection processor, and when offloading TCP from S/1, performance benefits are preserved.

EDX operating system enhancement DDN/
SNA required a number of enhancements to EDx. 1) System-wide operator functionality that effectively and efficiently handles message exchange between programs and provides a single operator interface; 2) S
/1:+-1' inter-partition data area services that allow access to common data areas across partitions, and 3) buffer management system-wide operator functions that allow buffers to pass through S/1 code partitions. Enhancements have been made to EDX to handle the exchange of messages between programs in S/1 storage and to provide a common operator interface for users. These extensions are designed in packages called System Wide Operator Functions (SWOF),
Coded, tested and documented. Message exchange provides interpartition queuing and message buffering between programs. Timing measurements show that it takes approximately 1.4 milliseconds to ``enter'' or ``read'' a message.

A common operator interface with message exchange functionality allows program modules to send information (logs), trace and error/alarm messages in a common format to a single service routine. This service routine records the message to the appropriate disk file and displays the message on the console. Ability to scan files by message type, severity, or date is provided.

Interpartition Data Area Services Interpartition Data Area Services is a method for providing common data areas for two or more programs in different partitions of a DDN/5NAFEP or RAF. These services were designed, coded, and tested in 1986.
Documented.

Common data areas are typically used when a program must share data fields with other programs in different partitions. Interpartition data areas are mapped to only one partition, and users of other partitions typically use interpartition macros to handle shared data items. Interpartition data areas are used for data fields that are referenced less frequently. Up to 16 different data areas can be defined, each identified by a unique logical value (independent of the partition in which it resides) ranging from 0 to 15.

The inter-partition data area O is reserved and identifies a data area physically located in partition 1 and contains global data common to multiple functions or intervals, such as S/1 logical names and buffer management statistics. The first 32 words also contain vectors (address and key) used to address data areas 0-15.

There are two mechanisms for defining interpartition data areas for use. When commanded, the system defaults to
Modules are loaded into designated partitions and store vector information. Alternatively, the administrator may define and initialize the data area itself and pass the vector information to system initialization. In any case, all interpartition data areas must be defined by the time initialization is complete.

Fourteen macros are provided to the operator when one or more operands reside in the interpartition data area. These macros follow the normal syntax of event-driven language (EDL-) statements.

1abel IXopcode opndl, opn
d2. KEYWORDs or 1abel 1Xopcode opndl, KEY
WORDs Each location parameter is a local (LOG) or cross-partition (XPD) data reference. The interpretation and syntax of local operands is the same as in regular EDL. XP
The D operand has the same syntax as EDL, but has a different interpretation. At least one operand must be interpartition. Keyword parameters To and FRO
M designates opnd 1 and opnd 2 as local or interpartition data references, respectively. If a keyword is present, the corresponding positional parameter is XPD.

If a keyword is omitted, the corresponding positional parameter is LOG.

The value specified for To/FROM is opndl or o
Indicates a predetermined inter-logical partition data area referenced by pnd2.

This defines the physical interval number and data address of the target/source data structure. The corresponding location parameters are used to determine the valid addresses of data items in this structure.

Buffer Management Facility The Buffer Management Facility (BMF) provides the following services to user programs.

By mapping unmapped storage to user partitions,
A buffer can be accessed from unmapped storage outside the user partition (see the EDX manual for a description of mapped and unmapped storage) A buffer that results in a buffer that is less than 2 bytes in a 2 byte block Achieve very large buffers by viewing them as a chain of operations.Perform interpartition moves that create smaller buffers from larger ones when only a portion of the larger buffer is needed to accommodate the user's data. A user program that allows buffers to be sent between partitions by queuing the buffer's address instead of Services can be requested from the BMF using the statements and commands shown below. #DEFBUF, #GETBWA, #FREEBW
A, #GETBUF1#RSTRBUF1#FREEB
UF, #5AVEBUF.

The #DEFBUF statement controls buffer management control (
BMC) block and give the user a single #GET
Lets you specify the maximum size of the buffer that can be acquired by BUF. The maximum size of this buffer allows #GETB
The size of the buffer work area obtained by the WA instruction is limited. "Maximum Buffer Size" or rMA
When used, XS I ZEJ shall refer to the maximum buffer size defined based on the #DEFBUF statement. The #D E F B U F' statement is not executable (see the EDX Language Reference manual for an explanation of the difference between statements and instructions).

The #GETBWA command acquires the buffer work area of the user partition. If the maximum buffer size is less than or equal to 2 bytes, the buffer work area size is always equal to 2 bytes. Otherwise, the user can specify the buffer work area to be a multiple of two bytes and less than or equal to the maximum buffer size. Once a buffer work area is acquired, it is used to accommodate buffers from unmapped storage.

Its size determines the maximum amount of storage that can be obtained by a single #GETBUF.

The #FREEBWA instruction frees the buffer work area in the user partition.

The #GETBUF instruction can access a buffer from unmapped storage by mapping the unmapped storage into a buffer work area.

The amount of buffer storage acquired by one #GETBUF cannot exceed the size of the buffer work area.

The #R8TRBUF instruction restores the buffer identification previously saved by #5AVEBUF' and maps the corresponding buffer, or a portion thereof, into the buffer work area.

The buffer storage restored by one #R8TRBUF is equal to the smaller of the buffer work area size and the buffer size.

The #FRFEBUF instruction specifies the buffer that currently exists in the buffer work area or n2 that currently exists in the buffer work area.
Free a buffer chain with k-byte blocks.

The #5 AVEBUF instruction saves the identification of the buffer currently residing in the buffer work area, or the identification of the buffer chain with n2 kbyte blocks currently residing in the buffer work area. This instruction then exchanges a portion of the buffer or chain of buffers from the buffer work area.

If the user does not want to store the entire buffer,
#5 AVEBUF instruction operand BUFS I ZE
You can use this to specify the amount of storage you want to save.

#GETBWA1#FREEBUF1#5AVEBUF
or #5 After issuing WAPBUF OUT, the buffer work area does not contain any buffers from unmapped storage;
Users can use it for other purposes. #GETBUA
1#R8TRBUF.

After issuing #5 WAPBUF IN, the buffer work area contains the buffer from unmapped storage and can be sent between partitions as needed. BUF
After issuing #5AVEBUF with S I ZE, the buffer work area is partially filled and is not available to the user as a private work area.

After issuing #FREEBWA, the buffer work area no longer exists.

Each user program that attempts to use BMF must #
The DEBUF statement must be used to specify the maximum buffer size and then the #GETBWA instruction is issued to obtain the buffer work area. Once this is done, any buffer management function that affects that buffer work area must refer to the label of the corresponding #DEFBUF statement.

BMF can provide less than two byte buffers, but can handle only one small buffer size at a time. A smaller buffer size can be selected at system generation time, but with the following value: 256.51
2. Only either byte can be specified for 1024 or 2. Its default value is 2 bytes.

Number of byte blocks available in 2 of unmapped storage (
When the number of available queue elements (reserved for BMF) or available (in the queue class reserved for BMF) falls below its associated input slow threshold, the system enters slow mode. When the system is in slow mode, only critical buffer requests are accepted and all other buffer requests are rejected. User programs that issue non-critical buffer requests must wait and then be notified by the BMF when the system exits slow mode. The system exits slow mode when both the number of available two-byte blocks and the number of available queue elements become greater than their corresponding exit slow thresholds.

SNA terminal/SNA host software SNA terminal/
To be able to operate on SNA host-to-host traffic DNs, several elements must be supported by the FEP and/or RAF. These elements include SNA PU2, SNA PU5,
Includes NA Data Link Control (DLC), SNA Pass Through Applications, and SNA Logon Security Applications. Primary SNA (PU5)
, Secondary SNA (PU2), Pass Through and DLC
The functionality is provided by software known as SNA Portability Software (SNAPS). Porting code to different environments requires customization at a separate layer and a design/coding access method called an access module (AMOD).

5NAPS PU2, PU5 and link separation layer AMO
D, Verticalization module (PMOD), HM
OD and Console Service Interface (C
High-level and low-level designs for 3I) have been completed and documented. It includes AMOD for DLC, high-level interface for application programs (
Includes error handling/alarm messages from the PMOD1 and 5NAPS codes for console services and alarm handling.

For this function, there are two S/1 configurations: a FEP SNA PU2 processor between the 370 host and the DDN, and an RAF between the DDN and the SNA terminal control unit.
SNA PU5 was specified. See Figure 14 for components used in the PU2 FEP and RAF configuration.

PU2 FEP Design The FEP is an S/1 channel connected to a 370 host. This appears to the host as an N5A3274 device, ie, multiple physical units (PUs) with multiple logical units (LUs). The 5NAPSPU2 code residing in the Mcesooo coprocessor provides PU2 and LU support for this channel interface. S/1 pass through module is another MC
Provides support and interfacing from PU2 to the TCP interface for TCP code residing on the 68000 coprocessor.

High-level and low-level designs for the FEP system have been completed and documented. It includes the following modular design:

Pass-through functionality between 370 channel 3274 Application Program Interface (API) and DLCAMOD for 5NAP PU2 5NAPS PU2 TCI AMOD and TCP
Pass-Through Function between APIs 5 WOF Interface to Common Operator Support and Message Coprocessor to control program loading to S/1 Resource manager manages module interface routing/connection and program ordering Control street blocking and reloading. This module is RAF and N
This is also common to CF.

RAF Design The RAF is an S/1 that serves as an interconnect between the DDN and downstream SNA devices such as the 3274.

To the downstream SNA device, S/1 appears as an SNA host (primary PU5). 5NAP resident in MC68000
The S PU5 code provides support for the PU5 System Services Control Point (SSCP) and connects other MC6800
The 5NAP LINK on the 0 coprocessor provides primary interperiod DL, C (SDLC) support for the terminal. The S/1 pass-through module is PH1TCI
Provides support and interface between AMOD and TCP.

High-level and low-level designs for the RAF system have been completed and documented. It includes first-order modular design.

5NAPS PH1TCI AMOD and TCP
Pass-through function between API H between application program of S/1 and HLI AMOD of PH1
Resource manager PU5 as described in the LI API FEP section
DLC modification made to S/1 $SNA program product to interface to pass-through module PH1DLCAMOD between DLCAMOD and 5NAP LINK AMOD. This modification applies to S/1 extended remote job entry (ARJE).
) program product provides remote job entry (RJE) support for local S/1 printing devices.

The SNA host-to-host software SNA PU4 node provides the data link control functions that provide four main functions: - Provides the functionality necessary to send and receive data over 370 channels and DDNs.

Routing Function - Data Link Control Function Provides the functionality necessary to route data between each other.

Border Node Function - Provides an interface to connected PU2 peripheral nodes.

PU4 Physical Unit Services - Provides local SNA host control of network resources owned by the host. S
NA hosts can track, dump, activate or deactivate these resources.

Of these four functions, only the first two are PH4
Supported on FEP. Since the PU2 node is only connected to the RAF, the third function is not required. The fourth feature is not supported for the reasons listed below.

This overlaps and conflicts with the concept of centralized network control functions. Many of the functions provided by NCP physical unit services need to be made available to remote network control hosts rather than locally attached SNA hosts.

Each SNA host requires knowledge of attached PH4FEP resources and is dependent on configuration changes to these FEPs. In the current PH4FEP design, all SNA hosts are treated as "data hosts" and
Therefore, it has no knowledge of network resources.

This feature supports PH4F'EP and 5scp on SNA hosts.
requires the establishment of a session between 5scp and PH
Supporting sessions between 4 and 4 requires handling many types of PIUs and is therefore more dependent on future changes to SNA. Current PH4F
The EP design requires processing of six PIU types.

Achieving this functionality requires considerable effort (
(estimated to be almost double the total PU4 support).

Support code for H.370 channels and DDN data link control functions, routing functions, and converged network functions is described. See Figure 15 for an overview of these functions.

PU4 Channel I/O Function The PU4 channel I/O data link control function interfaces with channel-attached MC68000 cards and communicates with one host via one PU4 channel. The PU4 Channel I/O Function and Channel Connections MC68000 card performs data link control and therefore responds to all channel commands as the NCP3725 communications controller. The PU4 channel input/output functions include the following:

Handles contact/uncontact/error sequences and informs the routing function when a channel's activated/deactivated state changes.

It takes the PIU from the host and passes it to the routing function to route it to its destination.

It receives PIUs from the routing function and sends them to their final destination host.

The high-level and low-level designs for this feature have been completed and coding has begun.

PU4DI) The N-input, recessed, and 11-female DDN input/output data link control function interfaces with the TCP API and communicates with remote PU4 FEPs over the DDN. Together, the DDN I/O functions and the TCP API perform data link control for the DDN interface.

The DDN access method (DNAM) resides in the EDX supervisor partition. The DDN I/O function does the following:

handles open, close and error sequences;
DI) Informs the routing function when the active or inactive state of a N connection changes.

For each remote PU4 FEP, one or more (up to eight defined at system generation) single DN connections are established during initial configuration or at the request of the operator.

It receives PIUs from remote PU4 FEPs via the DDN connection and passes them to the routing function for routing them to their final destination.

It receives PIUs from the routing function and sends them to the far FiPU4 FEP via the DDN connection. Then P.I.
It is remote PU4 F that forwards U to its final host destination.
It is the EP's responsibility.

PU4 Routing Function The routing function routes data between a source SNA host and a destination SNA host and
Control traffic. Specifically, the route control function performs the following.

Performs PIU validation, prioritization, tracking and routing.

Monitor whether the virtual route (VR) is congested or not
Execute pacing.

Manages and maintains the state of Explicit Routes (ER) and broadcasts this information to all affected nodes as needed.

PU4 Network Control Support Network Control Support is a utility function that would normally be implemented by the "Physical Unit Services" function of a normal SNA node.

These functions interface with the FEP network control monorules and are invoked by the network control operator. This functionality includes:

Activate or deactivate channel tracking or DDN connections.

Display channel status or D i) N connections and their associated ERs.

Activate or deactivate DDN connections. Note that channels are not activated or deactivated by the network control operator. - This feature can only be initialized by the operator of a locally connected SNA host.

The high-level design for this feature has been completed. The low-level design is complete and the tracking sub-features are well advanced in coding.

Centralized Network Control Software The network control design provides a single point of control for all FEPs and RAFs. This design is an existing IBM
Use communications network management (CNM) products. This design uses an NCR channel connected to the NCF that communicates with the FEP and RAF software components.

Design of the NCH The NCH is from which the network operator can
370 host that runs the SNA network.

An NCR connects to one or more NCs in the same manner that other network hosts connect to their associated FEPs.
Channel connected to F. NCF is NCH and DDN/S
Provides connectivity between NA networks.

NCH brings CNM capabilities to the network and standard I
Perform this task by using the BM CNM product. These products include:

Netv iew - Main product for CNM function.

Using Netview, operators can monitor network resources and receive a comprehensive view of network activity.

A product used by network operators to perform bulk data transfers between DSX-NCH and any FEP or RAF in the network. This feature is used to download new configurations, distribute passwords and user profiles, and retrieve dump and audit trail information.

HCF - A product used to enable network operators to enter S/1 commands on remote FEPs or RAFs.

The NCH- operator appears to be a local S/1 operator and can enter any S/1 command that a local operator can enter.

The NCH environment is designed to utilize IBM standard products to minimize operator training requirements, implementation efforts, and the impact of future software changes to the host.

The Netview product is included as a replacement for functionality previously provided by the Network Communication Control Function (NCCF) and Network Problem Determination Application (NPDA) products.

NCF Design The NCF was S/1 channel connected to 370 hosts (F
It is a front end processor (similar to EP). This processor is 5NA3274 to the host.
It looks like a device (PU2 FEP to be exact). The NCF function interfaces with the DDN, receives and receives SNA alerts generated by FEPs and RAFs connected to the DDN, and also communicates with the NCH functions in the FEP and RAF for HOF and DSX setups from the host. It also acts as an interface between RM functions.

NCF system module design includes alarm handling and $SN
Contains all programs in the FEP except the A/RM interface. Interfacing with TCP API to receive and receive alarm messages from FEP and RAF and send them to 5NAPS PU2 HLI A
An alarm processor receiving module is required that passes to the host via the MOD interface.

FEP Network Control Module The network control module communicates with the NCH. These modules work with commercially available S/1 products to send alerts and dumps to the NCH, and receive and receive operator commands, configuration tables, and new code from the NCH.

The F'EP system module design, coupled with S/1 standard products $SNA and RM, handles error messages from F'EP hardware and software;
Contains an alarm processor module that sends it as an SN, If alert message to the NCF via a TCP interface.

RAF Network Control Module The RAF Network Control Module communicates with the NCR. These modules work with commercially available S/i products to send alerts and dumps to the NCH, and receive and receive operator commands, configuration tables, and new code from the NCH.

A console service module FEP that provides an S/1 interface between the SW OF operator and the P M Ol of PU5 so that the operator can control (activate or deactivate) the PU and LU. S to HLI API to provide the Alarm Processor user logon screen and select host/application for the user as described in section
/' To perform security checks on logon application program user identification and passwords in 1 and to maintain an audit file of all logon attempts.
Security and Audit S/1 Program U) I) N/SNA Front End Processor (FEP) The S/1 that interfaces between the IBM MVS/VTAM host and the Defense Data Network is shown in Figure 30. and the DDN/5NA70 tip shown in Figure 31.
It is called Endo Bromo Sosa (FEP). ,
1) ■) N/SNA The main wave characteristics for FEP are as follows.

In case of FID2PIU, DDN/5N
between AFEP and l) I) N/SNA and in case of FID4 PIU, DDN/SNA FE
5 NAPIU between P and other DDN/SNA FEP
Insert. Provides TCP/IP envelope services.

DI) 5NAPU2 and MVS/V'TAM; -Take a second.

sNA PU2 and MVS-VTA, for a session initialized by a host requesting access to the SNA logical unit resident in the SNA far-E access facility (RAF); Take the interface of the M host.

SNA host-to-host communication over the Defense Data Network
For J1, S N A F U 4 and MVS /
VTA? , take the ink-face of 4.

SNA PU2/LU1 and MvS/VTA for host NVT device NET operations with non-IBM terminal users connected to the National Defense Data Network
Take the interface of the M host.

Supports internal control of S/IF EP from a remote network control host.

The basic components constituting the S/IFEP are shown in FIGS. 30 and 31. Each S/IFEP supports IBM Channel
Support functions (for PU2, PU4 and :3272 interfaces), DDN interface messages,
Processor (IMF) support function, network control support function (consisting of remote manager and network control service), and SNA P
U2 terminal-host application, SNA PU
4. Host-to-host applications or X, 25 paths.
Consists of one of the through applications.

X, 25 pass through completed Brigage June is M V
MVS/VTA on M host, M
Base ARPAN'ET control program or VT/VTAM host-L's VM/TCI)/rP
Provides X, 25 services for program products.

1) DN/SNA FEP Interfaces The FEP has four types of external interfaces necessary to perform the required functions:

A PU2 channel interface with IBM MVS/VTAM hosts, a hard-wired input/output channel connection interface that supports host-resident TCP/IP applications, and
R8449/HDLC/X for network, 25
It is an interface.

FEP/SNA, PU2 Interface The FEP provides access to multiple SNA PUs for the host processor.
Looks like 2. FEP is a physical unit activated PIU and physical unit y) deactivated PI in 5scp-PU session.
Accept and process U.

Upon receipt of a physical unit deactivation PrU, the FEP terminates all connections and connections associated with the LIJ of the deactivated PU, deactivates all associated LUs, and deactivates all allocated LUs. Collect resources. 5
REQMS received via SCP-PU mission
The PMU is rejected with a negative response that the feature is not supported. At least 8 PU2s in a single FE
Supported by P. Physical unit activation (ER)
P) PIU is not supported. Each LU associated with a channel-attached PU is assigned to one of the following three LU classes during -stem configuration.

1. Interactive 3270 terminal LU2 The LU2 associated with the interactive 3270 terminal session is:
First, if the 3270 terminal user connected to the RAF is assigned to the pool of available 3270 LU2.
When requesting a DDN Pi connection to a P-connected host,
FEPs can be dynamically allocated from that pool.

The FEP responds to the Logical Unit Activation PIU initialized in VTAM with an acknowledgment for each constituent LU2 and a control vector indicating that the LU is unavailable (powered off), and L, tJ responds to the session assignment. Depending on the availability. Activated Logical Unit (ERO) PIUs are treated as Activated Logical Unit (COLD) PIUs.

Upon receiving a logical unit deactivation PIU, the FEP removes the LU from the pool of L U 2 available for session allocation.

2. Interactive 3787 terminal LUI The LU1 to be connected to the interactive 3767 terminal session is:
First, it is assigned to a pool of 3787 L U 1 available. When an NVT terminal user connected to a DDN requests a DDN connection to an FEP connection host,
FEPs can be dynamically allocated from this pool. The FEP responds to the VTAM-initialized logical unit activation PIU with an acknowledgment for each configured LUI and a control vector indicating that the LU is unavailable (powered off) and makes the LUI available for session B allocation. become. The Activate Logical Unit (ERP) PIU is processed by the Activate Logical Unit (COLD) PT (1.5).When a Activate Logical Unit (ERP) PIU is received,
The FEP removes the LU from the pool of LUs available for sesong-yeon allocation.

3. Host initialization session LU2 (LUI and LU3
) An LU in which a host application can initialize its session (VTAM 0PNDSTACQU
IRE) is an L
It is U. A single LU must be defined to the host-resident VTAM and JES subsystems for each RAF-attached print device to which a host-based application, such as JES2, must send data. L.U.
The specified iLt must match the SEN Yong protocol supported by the RAF-based SNA support package. Within the FEP, each LU is assigned to the appropriate RA by defining a RAF DDN network address, a RAFDDN host address, and a single TCP boat address defined for the RAF LU.
Associated with F base LtJ. F these addresses
E P uses SNA BIND PIU to V
When received from the TAM/Host, a DDN/TCP connection is established. The FEP responds to LUs of this class that respond to the logical unit activation PIU initialized in VTAM with an acknowledgment and a control vector indicating that the LU is available (powered on). Logical Unit Activation (ERP) The PIU performs Logical Unit Activation (ERP).
OLD) is processed as a PIU. Logical unit deactivation PIU is supported.

FEP/SNA PU4 interface S/I
FEP channel support supports locally attached IB
M VTAM data host (i.e. PU4 with
NCP between a host that does not own or control the resource and one or more remote IBM VTAM data hosts
Provides a subset of physical units, type 4 interfaces. S/I FEP channel support is based on NCP version 4 and interfaces with TAM version 3. Note that TCAM version 3 is a subsystem that uses VTAM as the access method and is therefore supported by S/IFEP.

The following access method dependent requirements are supported:

5NA4.2 channel command sequence. rIB
NCP Diagnosis Manual for M3725 (HCP Diagno
sis Reference for the IBM
3725) Appendix G of J contains commands, starting I/O condition codes, channel status, and sensing instructions for this channel interface. During the contact sequence, the S/I FEP responds to the host of XID data with "already loaded".

To determine the loss of channel contact (S/I FE
An attention delay function used (by the S/I FEP) to ensure that interruptions to the host access method are kept to a minimum before each PIU transferred to the host. Embedded byte. In VTAM, the number of padding bytes is always zero.

Host command chaining between buffers. To enable the host to chain commands, the S/I FEP ensures that each PIU transferred to the host begins in a new host buffer. To do this, the size and number of buffers used by the host access method must be
FEP must know.

The attention timeout value, attention delay value, number of padding bytes, buffer unit size and time allocated by the access method are specified by the customer during customization of the VTAM/PU4 host-to-host application and are determined by the channel contact sequence. Bused in XID data in between. Note that a non-zero bad byte count in the XID data causes the XID data to be rejected by the S/IFEP channel support.

The S/I FEP supports up to two channel-attached data hosts. Each data host has a separate I
The B M Jaybird/Bluebird channel attachment set must be used to connect to the S/I FEP. Data host has multiple S/I FEPs
Can be connected to S. Data host is the same S/I FE
It is not possible to have multiple connections to P.

X, 25 support for FEP/unique output channel to the TCP/IP program in the host processor
, 25 interface is a solid input/output channel interface. The ARPANET control program communicates with the FEP using the EXCP functionality of MVS I/O, and the VM/TCP/IP program communicates with the FEP using native VM I/O channels. The use of I/O channels and the definition of new channel commands are controlled by the host FE.
Directed by the P-to-P design and corresponds to the 370 channel connection architecture.

F'EP/I MF Interface DDN Interface The interface to the Message Processor (IMF) is an R8449 type SR physical interface (ISO level 1). The link level protocol is HDLC (ISO level 2). Packet level protocols include X,25 (ISO level 3a) and Internet Protocol (I
P) (ISO level 3b). The transfer protocol is
Transmission Control Protocol (TCO) (ISO Level 4).

The specifications used to implement these protocols are as follows.

1. R5449 type SR-MI L (US military standard)
2.HDLC-FIPSloo-F'ED STD
1041 3, X, 25 -DDN X, 25 Host Interface Specification 4, IP -MIL-8TD-17775, T
The CP-MIL-8TD-1778 IMP interface connection card records the number of packets sent, number of packets received, total bytes sent, total bytes received, number of retransmissions received, and Maintains current status and activity counts, such as number of requested retransmissions. This data is available to the S/1 resident DDN IMP support function upon request.

DDN I with IMF interface connection card
The MP support function provides a TCP and X.25 interface to S/I FEP applications. The DDNIMP support function is
Multiple physical IMF interfaces to single or multiple IMFs F! can support additional cards.

The IMF Interface Support Package allows all FEP-resident applications to use the same physical IM
It is designed so that the F interface can be shared. (i.e. PU4, PU2 and
, 25 applications can access external TCP/X, 25 services on a single physical IMF connection card.

) The S/1 resident TCP/X, 25 support package is designed so that higher level S/1 resident applications requesting TCP services do not know the actual number of lower level physical IMF connection cards. TCP/X, 2
5 support packages must perform some level of load balancing when processing external connection requests.

The TCP support package provides an optional record mode interface that supports the transmission of SNA PIUs. This option TCP
IU services are selected by requesting applications at TCP 0PEN. The TCP support service provides the TCP reception operation initiation program with the following information:
A data block (PIU) as supplied to the TCP support service at the other end of the connection during a TCP send operation
). Record service option is TC
It is up to the F-level TCP application to ensure that it is selected at both the sending and receiving ends of the P connection. A TCP active open connection request with the record option will not connect to a TCP passive open or active open request that did not select the record option.

The TCP support package uses "logical addressing" to establish TCP connections to remote DDN hosts. The TCP support package enables S/1 resident applications to convert long character names for DDN hosts or dotted decimal names for DDN hosts to 32-pinto binary IP addresses required by other TCP services. , provides name conversion services.

The TCP/X, 25 support package detects when a hard failure is detected by the connection card or the S/1 support package, and when there are other significant changes in conditions such as loss of carrier or excessive retransmissions. Appropriate SNA
Supports generation of alert messages.

DDN/SNA Remote Access Facility (RA r
') The S/1, which provides concentrator functionality for downstream asynchronous and synchronous terminals and interfaces these terminals with the Defense Data Network, is the DDN/SNA Remote Access Facility (RAF) shown in Figure 32. It is called.

TC for passing SNA PIU2 PIU between DDN/SNA RAF and DDN/5NAFEP
Provides P/IP envelope services.

Provides primary SNA support functions for RAF resident PU2 and downstream PU2.

RAF resident DDN upper level protocol
Provides locally attached terminal access for ET, FTP and SMTP.

Provides user "mail box" services to local users who have access to RAF connected terminals.

Any MVS/V on 18M hosts on the Defense Data Network prefixed with DDN/SNA FEP
Provides downstream 5NA3270 terminal access to TAM applications.

MVS/VTAM on 18M hosts on the Defense Data Network fronted by DDN/SNA FEP
Provides access to RAF resident logical units such as printing devices by applications.

Supports centralized control of S/IRAF from a remote network control host.

I) DN/SNA RA F Interface RAF/SNA PU2 Interface. The RAF shown in Figure 32 is in normal response mode.
Supports downstream SNA PU2 connected by R3232C attachment running C. The PU2 to be supported is a 5NA3274 model 51C/61C or IBM PC that emulates a remote 5NA3274 with one or more defined LU2 (windows). RA F becomes the primary station on the 5DLC link. 5 for 5NA3274
DLC links are point-to-point links. A PC emulating H.3274 can branch to up to four terminals supported on a given 5DLC line. The RAF supports internal switched connections to the IBMPC (ie, a terminal user can dial into a 5DLC boat connected to the RAF). External switched connections are not supported (i.e. RAF does not initialize switched connections to the terminal)
.

The supported configurations are:

1. In a switched environment, the RAF supports 32 dial-in lines (automatic answering). This configuration includes eight 5D
Requires LC connection card.

Auto-attendant (dial-in) support is limited to fixed configurations only (i.e., RAF is configured as a dial-in terminal/
(must be pre-configured for cluster functionality). All downstream 0C7J terminals may have the same configuration, such as PU2 with one LU2 indicator and one LUI printer. In that case, the terminals/clusters with also any R
You can connect to the AF automatic response boat by dialing. If you need dial-in support for clusters with various configurations, each! 11 - The cluster must have dedicated dial-in boats, and those boats can be preconfigured to the desired configuration. Cluster definitions determined by IID data during dial-in processing are not supported.

2. In the branch configuration, the RAF supports 16 branch circuits with 4 terminals connected to each line.

This configuration supports 64 terminal users and 4
Requires DLC connection card.

In a 3.5NA 3274 configuration, the RAF has eight downstream 5N terminals with eight 3270 terminals on each 3274.
Supports A3274.

This configuration requires two 5DLC connection cards.

, L configurations can be mixed as long as the total number of configured terminals does not exceed 64.

The PU2 interface connection card displays the number of I-frames sent, the number of I-frames received, the total number of bytes sent, the total number of bytes received, the number of RRs sent, and the number of RRs received. It maintains current status and history counts, such as the number of retransmissions received, retransmissions taken, and number of retransmissions requested. This data is available to S/1 applications upon request.

RAF/IMF Interface DDN Interface Message Processor (I
The interface to MF) is R8449 type SR.
Physical interface (ISO level 1). Link level protocol is HDLC (ISO level 2)
It is. The packet level protocol is
(ISO level 3a) and Internet Protocol (IP) (ISO level 3b). The transport protocol is the Transmission Control Protocol (TCO) (ISO level 4).

The specifications used to implement these protocols are as follows.

1, R8449 type SR-MIL-1882, HDL
C-FIPSloo-FED STD 1041 3, X, 25- DDN X, 25 Host Interface Specification 4, I P -MI L-8TD-17775, TCP
- The MIL-8TD-1778 IMP interface connection card reports the number of packets sent, the number of packets received, the total number of bytes sent, the total number of bytes received, the number of retransmissions received, and the number of retransmissions received. Maintains current status and activity counts, such as number of retransmissions performed. This data is available to the S/1 resident DDN IMP support function upon request.

DDN I with IMF interface connection card
The MP support function provides a TCP and X.25 interface to S/I FEP applications. The DDNIMP support function may support multiple physical IMF interface connection cards to one or more IMFs.

The IMF Interface Support Package is designed to allow all FEP-resident applications to share the same physical IMF interface (i.e., FEP-resident PU4, PU2-, and external TCP/X, 25 services on the physical IMF connection card).

The S/1 resident TCP/X, 25 support package is
The design is such that upper level S/1 resident applications requesting TCP services are unaware of the number of lower level physical IMP connection card implementations. TCP/X, 25
Support packages must perform some level of load balancing when processing external connection requests.

The TCP support package provides an optional recording mode interface that supports the transmission of 5 NAPIUs. This optional TCP PIU service is selected by requesting the application at TCP 0PEN. The TCP support service provides the initiator of the TCP receive operation with data blocks (P I U) as provided to the TCP support service at the other end of the connection during the TCP send operation. It is the responsibility of the higher level TCP application to ensure that record service options are selected at both the sending and receiving ends of the TCP connection. A TCP active open connection request with the record option will not connect to a TCP passive or active oven request that did not select the record option.

The TCP support package uses "logical addressing" to establish TCP connections to remote DDN hosts. TCP support package is S/1
A resident application can pass the long character name for the DDN host or the dotted decimal name for the DDN host to another TCP.
Provides name translation services so that services can translate to the required 32-bit binary IP address.

The TCP/X, 25 support package provides the appropriate Supports generation of SNA alert messages.

RAF Asynchronous Terminal Interface RAF supports locally attached asynchronous ASCII block mode terminals. The asynchronous ASC ■ terminal interface is a standard commercial terminal to S/1 interface supported by commercial connection cards and EDX device handlers. RAF asynchronous terminal support is limited to DDN User Equipment NET and DDN File Transfer Protocol (F''TP) only.

DDN/SNA network control front end processor The network control front end processor in Figure 33 is
IBM MVS/VTAM hosts running NCFF1NPDA1HCF and DSX program products and DDN/SNA connected to the Defense Data Network
A dedicated S/1 that provides an interface between the FEP and DDN/SNA RAF. The main functions provided by the network control FEP are as follows.

RECF generated by DDN/5NAFEP and DDN/SNA RAF for network problem determination
MS/NMVT PIU message to host resident NC
Provides connection point services to CF/NPDA products.

Provides access to FEP resident logical units subordinate to RAFI and remote managers to support remote operator functionality.

Provides access to the RAF and FEP resident logical units subordinate to the remote manager to support remote operator functionality.

Network control functions for the S/I NCF are supported only from logically connected S/1 operator consoles. NCF is all 1 in the network?
'EP(!:) brings a network control interface to the RAF, so if remote network control support is required on the NCF, there will be repeat requirements. This introduces another level of complexity, and
Because F is physically located at the network control host installation site, requiring the network control operator to use a locally attached S/I NCF operator console does not result in significant loss of functionality.

DDN/SNA NCF Interface NCF/S
NA PU2 interface. NCF is a host
To the processor, it appears to be multiple NSA PU2s. The NCF accepts and processes physical unit activation PIUs and physical unit deactivation PIUs in 5scp-pU sessions.

Upon receiving a physical unit deactivation PIU, the NCF:
All sessions and connections associated with the LU of the deactivated PU are terminated, all associated LUs are deactivated, and all allocated resources are reclaimed. Up to 8 PU2
are supported by a single NCF. Physical unit activation (ERP) PIUs are not supported.

A host application can initiate a session or the U can connect HCF/HOF and DSX/RE controlled by the RAF/FEP resident remote manager (RM) function.
This is the LU that defines the RAF/FEP connection logical unit for the LAY session. Each RAF/FE with which a host-based application must communicate
A single LU must be defined for each P-attached logical unit to the host-resident VTAM subsystem.

The LU definition must match the session protocol supported by the RAF/FEP-based remote manager support package.

Each LU in the NCF has a DDN network address,
By defining the RAF/FEP DDN host address and a single TCP port address defined for the remote manager LU,
Associated with an EP-based remote manager LU. This address is used by NCF to send SNA BIND
When a PIU is received from a VTAM host, the DDN
/Establish a TCP connection. The NCF adds the L of this class to the logical unit activation PIU initialized in VTAM.
For U, it responds with an 11 constant response and a control vector indicating that the LU is available (power on). Logical Unit Activation (ERP) The PIU performs a Logical Unit Activation (COL)
D) Treated as a PIU.

NCF/IMF Interface DDN Interface Message Processor (I
The interface to the MP) is an R8449 type SR physical interface (ISO level 1).

The link level protocol is HDLC (ISO level 2). The packet level protocol is
5 (ISO level 3a) and Internet Protocol (IP) (ISO level 3b). The transport protocol is the Transport Control Protocol (TCO) (ISO level 4).

The specifications used to implement these protocols are as follows.

1, R5449 type SR-MIL-1882, HDL
C-F I PS 10O-FEDSTD 1041 3, X, 25- DDN X, 25 Host Interface Specification 4, IP-MIL-8TD-1777 5, TCP-MIL-8TD-1778 Current status and activity counts, including number of packets received, total bytes sent, total bytes received, number of retransmissions taken, and number of retransmissions requested. maintain. This data is sent to the S/1 resident DDN IMP upon request.
Support functions are available.

DDN via IMP interface connection card
The IMP support function provides both TCP and X.25 interfaces to S/I FEP applications.

The DDN IMP support function supports one or more IMPs.
Multiple physical IMF interface connection cards to the MF can be supported.

The IMP Interface Support Package is designed to allow all FEP-resident applications to share the same physical IMF interface (i.e., PU4, PU2 and
The application cage has a single physical IMP connection card external TCP/X.

25 services).

The S/1 resident TCP/X, 25 support package is
The design is such that upper level S/1 resident applications requesting TCP services do not know the actual number of lower level physical IMF connection cards. TCP/X, 25
Support packages must perform some level of load balancing when processing external connection requests.

The TCP support package provides an optional record mode interface that supports the transmission of SNA PIUs. This optional TCP PIU
Services are selected by requesting applications at TCP OPEN. TCP support/
The service specifies the TC
P provides data blocks (PIUs) as provided to the TCP support service at the other end of the connection during a send operation. To ensure that the record service option is selected on both the sending and receiving ends of a TCP connection,
It is the responsibility of the upper level TCP application. Any TCP active oven connection request with the record option will be sent to a TC that did not select the record option.
P Not connected to passive open or active open requests.

The TCP support package provides "logical addressing" for establishing TCP connections to remote DDN hosts.
use. The TCP support package allows S71 resident applications to convert long character names for DDN hosts or dotted decimal names for DDN hosts to 32-bit binary IP addresses required by other TCP services. Provide name conversion services.

The TCP/X, 25 support package provides the appropriate Supports generation of SNA alert messages.

Additional Features of the Present Invention The present invention handles both local and remote SNA users. According to the present invention, PU4 traffic (inter-host traffic), PU2 traffic (terminal/inter-host traffic),
host-to-host traffic) and network control traffic can flow over the DDN. The system also allows users to build system elements (code and tables) at one central site and distribute them over the network.

This system consists of a host, a network control host (N
CR), front end processor (FEP),
It consists of a remote access facility (RAF) and a network control FEP (NCF). The host is
A System 370 architecture computer running a multiple virtual storage (MVS) or virtual machine (VM) operating system.

The FEP and NCF are channel-attached S operating systems running event-driven executive operating systems.
/1. The RAF is also an S/1 running the EDX operating system. These are directly connected to the network using an X.25 interface. S/1 was chosen in 1985 because it is an open architecture that allows existing network control products to be used and coprocessor cards can be added to the machine. The RAF can handle up to 64 downstream SI) LC terminals. Any of these terminals can connect to any SNA host defined within the network. The FEP can handle up to 128 terminal sessions per PU2 connection card and can handle up to 8 connection cards. FEP is also used for PU4 traffic, up to 2
Can handle two channel-connected hosts. A PU4 environment can have more than 250 subarea addresses. That is, 150 or more hosts can be connected to the PU4 environment. Up to 1000 FEs across the network
P, RAF or NCF components.

This system was tested in an environment using the commercially available products listed below. MV81 Time Sharing Option (TSO), N
e tVi eWs Distributed System-x Executive (D
SX), EDX1$SNA, RM, 4381 host,
4956 S/1.3274 controller and 3278 terminal.

System generation and distribution The system generation/distribution function is called 5YSGEN.

Figure 16 shows the DDN/
The SNA system is shown.

The purpose of 5YSGEH is to provide installation, node customization and distribution, and maintenance functions on the Masked Network Control Host (MN CH) for DDN/SNA systems.

One large installation package includes everything needed to install a DDN/SNA system.

The installation package includes:

S/ with documentation on how to implement the boot system.
A set of boot diskettes for initially installing a node. Boot diskette connects new S/1 node to DDN
/Used when adding to the SNA system. These diskettes include:

- Required path components for the executable EDX core and EDX utility nodes to be able to communicate with the MNCH (Required path components are the components required to establish communication with the MNCH via the DDN) Same A boot diskette set is used for every S/1 node, including the NCF channel-attached to the MNCH. In NCF, assuming all required physical units (PUs) and logical units (LUs) are accurately defined for Virtual Telecommunications Access Method (VTAM), , MNCH
Previous D of NCF EDX1 program and table
A DN/SNA system generated version can be downloaded. From that point on, the installer can send software resources to any S/1 node in the system-generated DDN/SNA system. After transmission, S
/1 node, NCF is DD by $SNA and TCP
It is configured to have mutual LU sessions between DSX and RM via N.

For a new S/1 node to operate, the site operator must allocate all databases on the local S/1 according to instructions contained in the documentation distributed on diskette.

Site operators follow scripts that have instructions for:

Create the required EDX volumes and data sets Install EDX on the hard disk Copy the data sets from the non-diskette to the S/1 hard disk Initial program load (IPL) the S/1 At this point, the new S/1 The operator at one node is
Call the operator at MNCH and say the S/1 node is ready to receive the software load. The MNCH operator then sends the DSX-RM LU
Software load via mutual session
It can be distributed to one node and remotely installed on the node to use the new DDN/SNA system generation software load. This means that the S/1 node was previously created during DDN/SNA and the resources required for that node are available from the MNCH's DSX resource repository;
means ready for distribution.

DDN/SNA 5YSGEN Software Tape and Related Macros DDN/SNA Baseline DSX Resource Repository VSAM Tape User (7) Programs and tables are distributed from the IBM development site to install the MNCH site. M
NCH is the NCH where the user runs 5YSGEN, from which all 5YSGEN outputs are sent to the remote primary NCH.
A remote secondary NC with a CF and as an opcidin, to which alarms are reported by the NCF's network control code.
It is distributed so that it also has F. The exception is DDN/SNA
This is when there is at least one NCFL in the system.

In that case, the NCF is configured as its own NCF. Each NCF uses the SET command to cause all locally generated alerts to appear on the local NCF terminal, but the alerts are typically sent to a remote NCF for alarm processing and corrective measures.

If two NCFs are channel-attached to the same NCH, these NCFs are
It can play the role of primary and secondary NCF for a set of nodes. The same applies for two logical NCFs connected to the same NCH, or one logical NCF and two physical NCFs connected to the same NCH.

Each new release of DDN/SNA software is identified by a version number (1-99) and modification level (0-99). Two pieces of software with embedded version and fix numbers for that release: 5YSGEN version/fix macro and S/1
Node initialization software must always be distributed with its release. MMC) (and each S
/1 provides a means of maintaining the integrity of the user's software configuration management on the node.

5YSGEN Version/Modification Macro This macro is placed by the installer in the MACLIB that contains all 5YSGEN macros. This includes new Bergeron numbers and modification numbers. 5YSGEN uses this macro to allow the installer to create
DDN/S specified in the SGEN source statement
Make sure you are running 5YSGEN for the Virgilon and Modified levels of NA software.

S/1 Node Initialization Software Each release of the initialization software includes two sets of version numbers and modification numbers. i.e. new software version number and fix number, and table
Version/fix compatibility level. The new software version number and modification number are entered into the Initialization Parameter File (IPF) table by 5YSGEH. The table version fix compatibility level, which indicates the oldest table level with which a new software release is compatible, is hard-coded in the initialization software.

The user must run 5YSGEN to distribute new software releases to each node. Figure 17 shows the DDN/
The elements of the SNA system are shown.

Node customization occurs in three stages.

The code for each stage is executed on the MNCH by the user. FIGS. 17, 18, and 19 provide an overview of each stage. Each description is preceded by a schematic diagram of the process at that stage.

Phase I Overview (Figure 17) The Phase I code checks the consistency of all definitions in the Phase I input file, analyzes the connectivity defined in the system, and uses the user-provided Phase I input file. For each node defined, an intermediate 5 that reflects network connectivity
Output a dataset containing YSGEN macro statements. Phase I resolves all inter-node relationships defined in the Phase I input file and separates all information needed for each node into separate data sets.

These Stage I output files, when assembled in Stage 1, generate intermediate 5YSGEN macros that generate tables that reflect the connectivity of the network, specific to each node.
Contains statements.

In stage ■, the output is six partitioned data cells (
PDS) and three sequential data sets (SD) are generated.

Each element of the PDS is connected to a specific S/1 node or VTA
For M statements, it contains definitions for specific SNA hosts within the DDN/SNA system.

The user must modify the VTAM via DSX to reflect the DDN/SNA 5YSGEN.
Distribute the AM 5YSGEN statement data set to the SNA host. Those data sets are not used in stages ■ or ■. All other data sets generated in Stage I are used as input to Stage ■.

Phase I runs as a separate job on the MVS system.

Overview of Stage H (Figure 18) Stage ■ The code creates the table and generates the node 5 YSGEN statement PDS, PU4 in Stage I.
FEP 5YSGEN statement PDS1 and PU4 PATH5YSGEN statement PD
Process intermediate 5YSGEN macro statements from S. In step 2, a table is created that details all the programs needed for each S/1 node, both EDX programs and application programs, which can be customized. A detailed list of resources (EDX load modules, program load modules and tables) is generated for each node. These lists, one for each S/1, are called node resource distribution lists (NRD lists or NRDLs).

The master S/1 list output from stage I (see table attached at the end) is used to create a working S/1 list that includes only the nodes that the installer wants to generate during a specific execution of stages ■ and ■. used for. This allows the installer to activate a small number of S/1 mates at a time.

Basically, stage H allows the user to perform successive partial generations on the same stage I output. The granularity of the partial generation at stage H is that the partial generation is based on the master S created at stage ■.
The S/1 nodes appearing in the /1 list are such that all of these sets of subdivisions constitute the working S/IIJ list for a given execution of step (2). It is assumed here that nodes that were not processed during the current or previous execution of stage H are not included in subsequent executions. rn
Phase I for J nodes takes longer than Phase I for 'n' nodes because the multiple assembler runs are directly related to the number of nodes generated during a given Phase H execution.

The table created for the S/1 node generated during a given run of stage H contains all the information necessary to describe its topology. The topology is defined in the Phase I input file as if all other S/1 nodes were created together with this S/1 node, including all control information related to the PU4 and PU2 applications. It concerns the entire network.

The Job Control Language (JCL) for Stage ■ creates a job that automatically executes Stage ■ as another set of job steps. The JCL is such that the Stage ■ job step is executed only if Stage ■ is successfully completed.

Overview of Step ■ (Figure 19) Step ■ The code transfers the programs and tables specified in the NRDL to the user's DDN/SNA baseline DSX resource repository. The code then creates the DSX transmission plan and JCL needed to distribute the file. These files contain all of the executable load modules and tables necessary to perform a given S/1 node operation from the DSX resource repository to the desired subset of S/1 nodes.

When step m is completed, the installer can use the D created in step ■
Complete the SX transmission plan. The installer adds scheduling information that specifies the date and time of transmission of DSX resources to the nodes in the plan.

Step ■ creates three resource groups in the DSX for each S/1 node in the working S/1 list. namely, programs, tables, and EDX core and utilities. These groups are made up of list items contained in the NRDIJ STEP PDS passed from step (3). The installer can specify the type of data to be distributed in the 5YSGEN statement, which is required as a special global statement in the user-supplied Phase I input file. That is, if only the tables are changed, it is unnecessary to redistribute versions of the program and EDX that already exist on the nodes. This reduces transmission time for small productions and increases flexibility for installers. However, when an installer adds a node to the system, all resources must be distributed to that node, even if only tables are distributed to previously installed nodes.

Distributing resources in this manner requires the following:

Send the CL I ST to the S/1 node, then send the DSX resource. C on the S/1 node using the DSX initiation function.
Execute LIST. The CLIST automatically uses the new E
Create a DX volume and copy the entire contents of the EDX volume, including the most recent software load, to the newly created EDX volume.

All resources to be sent to the node are then sent to the new volume. These resources replace older versions of resources with the same name, but leave behind resources on volumes that are not updated by DSX. In this way, a new software load is constructed from old and new resources.

Even if some resources do not need to be distributed to nodes for a given production, these resources can be allocated to nodes in the DSX's resource repository, and those resources can be distributed to the nodes in the current 5YS.
Must be associated with a software load with a volume number of GEH. This applies to some DSX resources, e.g. all EDs assigned to an S/1 node.
Since the X resources did not change in subsequent 5YSGEH executions, this means that they can be associated with multiple software loads. This association is
This is done by defining a new group of DSX resources that includes one or more resources that are not newly created by 5YSGEN. This DSX resource group is a new set of resources, but not necessarily a new set of resources.

Each software load is contained in its own EDX volume on that node. The name of the EDX volume associated with a particular software load is used in DSX as part of the group name of the DSX resource group that makes up the software load. That is, the EDX volume name is embedded in the group name. Note that the actual DSX resource name (on the host) may be different than the name on the S/1 node.

The only difference is the VOLUME field of the resource name.

When the volume name pointed to by a DSX resource group name differs from the volume name field of a resource in that group, the name of that resource on that node is not the volume name on the resource's host; Bo'J s indicated by the containing resource group name
- Contains program name.

This situation occurs when resources already exist to satisfy the requirements of the new 5YSGEN software load. That is, old resources are included in the new software load. In this case, the volume field of the resource name at the host will always reflect the EDX volume name of the software load in which it was originally created.

An expedited route in 5YSGEN Adopter can specify an expedited route in 5YSGEN. There are three situations that require small-scale processing by 5YSGEH. In all cases, the creation of the Stage I input files and tables that make up the majority of the processing in Stages I and H is not necessary, and in fact doing so would only introduce significant delays in performing each task. be. So to run 5YSGEN in quick route mode, we need another JCL
Set up files. This rapid route mode bypasses the time-consuming steps and processing of step
Run specific utility programs that perform the necessary functions on behalf of the SGEH.

These three situations are as follows.

1. Create and distribute only the host name server table.

2. Create and distribute only the user profile and password file.

3. Distribute the program without executing table creation.

In any of these three situations, if 5YSGEN has previously been fully run on all nodes in the DDN/SNA system, a master S/1 list database exists, and you only want to distribute the program, the program Assume that it has already been moved to the DSX with the distributed resources directory entry.

Maintenance of Mengyu DDN/SNA resources is performed using DSX version 3 release 2. DSX maintains the status and records of all resources assigned to a given node in the network. 5YSGEN uses the DSX batch function to allocate - sets of DSX resources to each S/1 node that completes stage 3 of 5YSGEN. The set of resources assigned to an S/1 node for a given production is the complete set of programs and tables necessary for that node to operate with respect to that production.

DSX allows batch functions to define nodes and resources.

Having multiple software load sets allows a given node to perform chained backups of software loads on the S/1 nodes. For this reason, 5
YSGEN and configuration management do not automatically replace or remove versions and modification levels from the DSX resource repository on the MNCH,
The old version of the resource set specification for the /1 node must be maintained.

Since user commands are available to remove obsolete software loads from the S/1/-D, it is also necessary that the system administrator be able to delete and preserve obsolete software loads from the DSX resource repository.

This is performed using the DSX batch facility. Users must provide their own archiving method.

Host-to-Host Applications This section describes PU4 host-to-host applications. FIG. 20 provides an overview of the DDN/SNA system as it relates to PU4 host-to-host applications. A DDN/SNA system consists of two or more V
Consisting of TAM data hosts, each host has an S/I FEP that connects it to the DDN and a network control subsystem (network control host and network control S/I FEP). Each VTAM data host and S/I FEP is assigned a unique identification called a subarea address between 1 and 255. The PU4 host-to-host application is
A routing information unit (P) that resides in a S/I FEP and that transfers routing information units (Ps) from one VTAM data host to another through logical connections called transmission groups (TGs).
Send T U).

The FEP-to-host TG is implemented using an H.370 channel interface. Each 3 on S/I FEP
Only one TG per 70 channel connection card can be defined, and it is always identified as a TGI. S/I FE
P can have up to two channel connection cards.

Inter-FEP TG is implemented using logical connections via DDN. Multiple TGs can be defined for each DDN connection card on the S/I FEP. Each TG is 1 to 25
5, and need only be unique between any two subareas within the network. The PU4 host-to-host application can handle up to 8 DDN connection cards.

As used herein, the term PU4 host-to-host applications includes routing functions, channel support functions, and network control support services functions. The following four sections explain the following:

1. Overview of the main functions that make up the PU4 host-to-host application and the layout of partition boundaries used by these functions 2. Buffer management, queue management and main queues used by these functions 3, and their functions 4, PU4 Host-to-Host Application Error Handling Concepts Note that the terms "inbound" and "outbound" used throughout the description of the PU4 Host-to-Host Application are with respect to the FEP (i.e., (meaning into the inside and out of the FEP). The term rTGJ is generally only used by routing functions.

Otherwise, a "channel" or "rDDN connection" is used. The term rFEP-to-host TGJ is synonymous with "channel TGJ" or "channel," and the term rFEP
TGJ between EPs is synonymous with "rDDNTGJ or rDDN connection".

Functions and Partition Boundaries This section describes four major functions of host-to-host applications. It explains the primary purpose of those functions and indicates in which S/1 partition the code resides.

FIG. 21 shows the three PU4 channel input/output sections. The first partition, viewed from left to right, contains the PU4 channel I/O functions.

Channel input/output functions are provided using the basic channel access method (
BCAM) and one PU4
Communicate with one host via a channel. Together, the PU4 channel I/O function and the BCAM perform data link control functions and therefore respond to all channel commands as a Network Control Program (NCP) 3725 communications controller. BCAM resides in one of the EDX supervisor partitions. The PU4 channel input/output function performs the following:

Processes contact sequences, non-contact sequences, and error sequences and informs the routing function when the channel active/inactive state changes.

It takes the PIU from the host and passes it to the routing function to route it to its destination.

It receives the PIU from the routing function and sends it to the final destination host.

If there is a second channel attachment, there is another partition identical to the first attachment that processes channel commands for that channel.

DDN I/O Functions The last section shown in Figure 21 primarily contains DDN I/O functions. The DDN input/output function uses the DDN access method (DNA
remote PU on the DDN
4 Communicate with FEP. DDN input/output function and DNAM
Together, they perform the data link control function of the DDN interface. DNAM resides in one of the EDX supervisor partitions. The DDN I/O function does the following:

Handles open sequences, close number sequences, and error sequences and informs the routing function when the DDN connection's active/inactive state changes. Each remote PU4
For each FEP, one or more unique DDN connections are established by DDN input/output codes.

It receives a PIU from a remote PU4 FEP via a DDN connection and passes it to a routing function to route it to its final destination.

It receives the PIU from the routing fi function and sends it to the remote PU4 FEP via the DDN connection. Then P.I.U.
The remote PU4 FE transports the
It is P's responsibility.

Route Control Function The middle section shown in FIG. 21 includes a route control function and a network control service function. The route control function does the following:

Validate, prioritize, track, and route PIUs.

Monitor whether the virtual route (VR) is congested and -V
Adjust the pace of R.

Manages and maintains Explicit Route (ER) status and broadcasts this information to all affected Mates as needed.

Routing functionality primarily resides in one partition, but a small portion resides in each other partition. The part residing in another partition performs a validity check on the PIU, passes the PIU to and from the routing function, notifies the routing function of changes in the status of T(?, -, and transmits it from the routing function. This is the code generated by the macro to obtain group information.

NETWORK CONTROL SERVICES Network control services are utility functions that would normally be performed by physical unit services functions in a typical SNA node.

Those services are called by the network control operator and include:

Activate and deactivate tracking of TGs Display the status of TGs and their associated ERs Collect and display buffer usage statistics Activate and deactivate inter-FEP TGs.

Note that the FEP-to-host TG cannot be activated or deactivated by the network control operator.

Buffer management and queue management functions are used by all programs that need access to the PIU. Typical situations in which the buffer management and queuing functions are used are as follows.

The first program that requires a buffer for PIU is #
#5AVEB to issue GETBUF and pass it to other programs in other partitions when the buffer is used up.
Issue UF, then FSPUTQ.

A second program issues FSGETQ then #R8TRBUF to access the PIU buffer. P.I.
When the U buffer is used up, the program passes it to another program by calling #5AVEBUF primary iteration Fs.
Issue PUT-Q.

The third program executes FSGETQ1 then #R8TR
When the BUF is issued and the PIU buffer is used up, #FRFEBU is used to release the buffer γ and return it to the free pool.
Give an F.

All queues used to pass PIU buffers use the same queue class and are first-in, first-out queues. Currently, four main queue types are defined to bridge functionality within each partition, as shown in FIG. Other queues defined for use within specific functions (e.g., intermediate queues and hold queues for PU4 channel I/O functions and TG work queues for routing functions) are not discussed herein. do not. These four main queue types are logically part of the routing function, but can physically reside in any partition.

PU4 Receive Queue There is one PU4 receive queue. The routing function adds all PIUs received via all FEP-to-host and FEP-to-FEP TGs to this queue. The routing function dequeues one PIU at - time and places them in the other three queues based on the routing information.

PU4 Channel Transmit Queue There is one PU4 Channel Transmit Queue for each channel connection card, up to two cards.

Each transmit queue includes four physical queues, one for each of the four SNA transmit priorities. The routing function adds all PIUs destined for the locally connected host to the associated transmit queue via the H.370 channel connection card.

Upon request, the routing function removes the PI from the transmit queue.
Remove U and send it to the host through the PU4 channel input/output function. A channel attachment card and its transmit queue services only one FEP-to-host TG.

PU4 DDN Transmit Queue There is one PU4 DDN transmit queue for each DDN attachment queue. Each transmit queue includes four physical queues, one for each of the four SNA transmit priorities. The routing function adds all PIUs destined for remote hosts to the associated transmission queue via the DDN connection card. Upon request, the routing function removes the PIU from the transmission queue and sends it over the DDN by the DDN I/O function. A DDN connection card and its transmission queue can service multiple FEP-to-FEP TGs. DNAM, when a DDN connection is established,
Associate the FEP-to-FEP TG with the connection card.

The ER manager processing queue routing function adds all PIUs destined for this PU4 FEP to the ER manager processing queue. The routing function processes them and creates additional PIUs as necessary to maintain ER integrity.

Data Flow Figure 22 shows the overall data flow within the PU4 host-to-host application. Numbers below the arrows in the drawings indicate the steps described below.

1° The TG must be operational before a PIU flows through the network. That happens because FE
When the contact sequence is completed on the P-Host TG,
and when TCP open is completed on the TG between FEPs.

2. By calling the route control macro, the PU4 channel I/O function and the DDN I/O function inform the route control function that the FEP-to-host TG and the FEP-to-FEP TG are operational.

3. The path control function in the channel I/O partition or the DDN I/O partition places the TG control block (TGB) in the ER manager processing queue with an ER operation PIU creation request. This PIU is destined for the node, host, or PU4 FEP at the other end of the TG that has become operational.

4. The Routing ER Manager dequeues the PIU. The ER manager uses this TG to manage all E
Update the route operation table to reflect any changes in R's state. The ER manager then creates additional PIUs if necessary and forwards them to neighboring nodes by placing them in the PR4 receive queue.

5. Once the TG is operational, the PIU can start flowing. PIU can be local host or remote PU4
Uke can be taken from FEP. From the local host, the PU4 channel I/O function uses BCAM to receive and take the PIU. PIU is remote PU4 FE
In the case from P, the DDN input/output function uses DNAM,
PIU is received.

6. The receiving side function, PU4 channel input/output function or DDN input/output function, passes the PIU to the route control function.

7. The routing function in the channel I/O partition or DDN I/O partition validates the PIU and sends it to the P
Place in U4 receive queue.

8. The routing function removes the PIU from the PU4 receive queue and fills the PIU's destination subarea field (DSAF
) and the Explicit Route Number (ERN) to route to the appropriate send or processing queue. If the PIU is intended for this subarea, the routing function places it in the ER Manager processing queue. Otherwise, the routing function uses the DSAF and ERN to obtain an index into the routing table to determine which outbound TG to use to route the PIU towards its final destination.

9. When a PU4 channel I/O function or a DDN I/O function is ready to send a PIU through the TG, that function will remove the PIU from the appropriate transmit queue and pass it to the I/O function within its partition. Calls the route control function.

If none are available, the routing function waits until a PIU is available.

10, then the PU4 channel I/O function or DDN I/O function sends the PIU to the neighboring node using BCAM or DNAM to perform the actual I/O. For the PU4 channel I/O function, an intermediate queue (not shown) actually stores PIUs until enough PIUs are ready to be sent to the host. This reduces the number of interrupts to the host.

11. The TG may become inoperable due to critical errors or controlled deactivation requests. The latter case occurs upon completion of the shutdown sequence on the FEP-to-host TG and upon completion of the TCP close on the FEP-to-FEP TG.

12. The PU4 channel I/O function and the DDN I/O function inform the path control function that the FEP-to-host TG and FEP-to-FEP TG have become inoperable, respectively.

13. The route control function in the channel I/O partition or the DDN I/O partition requests TGB to create an ER non-operating PIU.
into the ER manager processing queue. This PIU is addressed to all neighboring nodes, hosts, or PU4 FEPs affected by the inactive TG.

Error Handling The PU4 host-to-host application error handling concept is based on the error handling concept of the entire DDN/SNA system. There are five categories of detected errors:

Program (Software) Error When the program detects an "unable to occur" condition, the system abnormal termination service routine (#ABEND) is called. The first (leftmost) byte of the abend code passed to this service routine is the EBCDIC character assigned to the functional component that calls the system abend service routine. The second byte is a decimal number assigned to the subfunction of the functional component. The third byte is the system abnormal termination service.
Identify a specific call to a routine. This third byte is specific to each call to the system abend service routine. The last byte contains zero or the return code, as appropriate. Return codes apply when a service routine detects an abend condition and reports it to the calling program.

Intermittent Hardware Errors Intermittent hardware errors, as used herein, refer to errors that can be immediately retried and have a chance of success on an immediate retry. If successful, the intermittent hardware error does not affect any other functionality internal or external to the FEP.

The PU4 host-to-host application cannot receive and receive intermittent hardware errors from the BCAM interface for the FEP-to-host TG via the channel. Intermittent errors returned by BCAM are immediately retried up to rnJ times. However, “n
” is the equalization value determined by the programmer. If it is not successful after rnJ retries, the PU4 channel I/O function changes the state of the TG to inoperable, closes the channel, and issues an alert to the network operator that there is a failure. Treat intermittent errors as permanent errors (described below).

Persistent Hardware Errors Permanent hardware errors occur during I/O operations and
Retried without success, or error that cannot be retried. PU4 host-to-host applications are EDX
Read/print statement or FEP-to-host T
Only permanent hardware errors can be accepted from the G's BCAM interface.

The only use of EDX read/print statements is in network control services. Since these functions are not critical to the system, the program issues seven alarms to detect problems and then shuts down. Permanent errors from BCAM are treated as temporary errors (described later). This reduces the need for additional code and allows you to handle cases where what appears to be a permanent error is actually a temporary error that will disappear over time.

Temporary Errors A temporary error, as used herein, refers to an error that will generally not succeed if immediately retried, but will generally succeed if retried later. - errors can occur both within the S/1 (missing buffers or queue elements, etc.) and on the TG (no resources available for this DDN connection, local VTAM
Data host is down, mate in DDN is down,
This can also occur even if the remote FEP is down, etc.). -When errors occur, buffer management function (BMF), BCAM, DNA
M, or can be detected by the PU4 channel input/output function using timeout. Host-to-host applications handle these errors as follows.

- Buffer Management Function Error Return Codes The virtual path pacing function minimizes congestion within the FEP and minimizes the possibility of buffer/queue element exhaustion. However, the virtual route pacing function does not eliminate the possibility of these resources being exhausted. Therefore, a slowdown mechanism is added to the BMF to inform the user program through a return code when the buffer/queue element is almost empty. When the host-to-host application program receives this slowdown notification, it stops requesting buffers, unless absolutely necessary, until the buffers and queue elements are no longer exhausted. As a result, during slowdown, channel input/output functions and DDN input/output functions are
It no longer requests or accepts subsequent PIUs from other nodes, but continues to send PIUs to those nodes. Sending PIUs frees up buffers and queue elements, which eventually causes the host-to-host application program to come out of the slowdown and begin receiving and receiving PIUs from other nodes again.

The network operator is notified by an alarm when entering or exiting a slowdown.

- BCAM and DNAM return codes These temporary errors occur in the TG. As a result, the TG is always inactive and the associated channel or connection is closed. The network operator is informed of this error and the change in TG status by an alert. In a FEP-to-host TG, the host-to-host application immediately and every rmJ minutes thereafter attempts to reopen the channel and wait for a contact sequence on that channel. In a FEP-to-FEP TG, the host-to-host application immediately and every rmJ minutes thereafter
N Attempt to reopen the connection. The value rmJ is 5YS
Specified by the user during GEN. The network operator is notified by an alert when the TG becomes operational again.

- PU4 channel I/O timeout These temporary errors are generally caused by a lost event, such as a channel error, the host not responding, or the host being re-IPLed. As a result, the TG becomes inoperable, but the channel remains open. The PU4 channel I/O function notifies the network operator of its errors and changes in TG status by means of an alarm. A connection sequence from the host makes the non-operational TG operational again.

- Configuration Errors Configuration errors (table inconsistencies) are caused by invalid or inconsistent user-supplied parameters on the 5YSGEN statement, or by program bugs or instruction code bugs in the 5YSGEN macro.

During execution, the host-to-host application program cannot determine which of the above caused the error. Therefore, if an error may have been introduced by the user at 5YSGEN, and if the TG causing the error can be identified, the program enters degraded mode (ie, the TG becomes permanently inactive). If the configuration error is caused by a program bug, or if the causing TG cannot be identified (i.e.
If the error is global and therefore normally detected during initialization), the PU4 program issues #ABEND. Most configuration errors result in #ABEND.

An example of a user parameter error that does not result in #ABEND is an invalid DDN network address for the S/I FEP. 5YSGEN cannot perform complete validation of this parameter.

Terminal-to-host functions and network control functions Terminal-to-host functions include resource managers, system wide
Operator Functions (SWOF), SNA Pass Through, High Level Interface (HLI), Application Program Interface (API), Logon, Security/Audit, $SNA Data Link Control (D
LC) interface, 5NAS inter-access module (AMOD), HL I AMODlDL
CAMOD1 Console Fist Service Large Service Interface (C8I) Personality Module (PMOD)
, Transmission Control Interface (TCI) AMOD, Common AMOD, 5NAP-LINK AMOD, 5NAP
Includes S Hardware Module (HMOD), Operator Interface, Console Services, and Channel DLC.

Network control functions include channel DLC1SNA pass through, resource manager, FEP and RAF alert processor, $SNA TCP interface, NC
F alarm processor, DLCAMODlTCI AMO
Includes DlHLI AMOD1C3I PMODl and console services.

These features, coupled with 5NAPS products, make FEPl
Configure RAF and NCF. F.E.P.

The functional relationship of NCP or RAF is shown in Figure 22, 2.
This is shown in Figures 3 and 24.

With FEP and RAF, IBM SNA standard products: 1. Can connect to DDN using EM S/1 processor. These prosensors act as communication servers and concentrators. An S/1 communication server connected to an IBM MVS/VTAM host is a DDN/SAN F
It is called EP and provides multiple PU2 interfaces to VTAM.

An S/1 communication concentrator called RAF is used for the downstream PU2. This allows multiple downstream ports such as 3270
U2 is provided with PU5/5SCP functionality. FEPlR
The AF combination interfaces with the DDN;
Provides the ability to pass SNA PIU data over DDN media.

For network management, FEP/RAF uses standard #ED
The X product provides the following functionality through the Remote Manager (RM) in each FEP and RAF.

Problems detected in the S/1 hardware and EDX software are asynchronously reported by the alarm processor as SNA alarm messages to the network control host.

The terminal operator of the Network Communications Control Function (NCCF) can obtain a Host Command [1 (HCF) session with the S/1 Host Operator Function (HOF).

The RM's relay function on each FEP and RAF can receive and take files from the network control host program rDSX.

The standard EDX $SNA product has been modified to implement the ability to transport these SNA functions over the DDN medium using a TCP/IP interface instead of a 5DLC interface.

All SNA support within the FEP/NCF and RAF is provided by 5NAPS software (SNAP2.5NAP-
5,5NAP-LINK, 5NAP-THRU). This code has been ported to S/1 68000 coprocessor hardware. This porting consists of implementing a specific interface (AMOD).

VTAM views the FEP as a channel connection 3274.

Therefore, 5NAP-2 provides PU2 functionality to the channel. In RAF, 5NAP-5 is the primary PU5 5NAP support for downstream PU2 equipment connected to RAF.
(SSCP). 5NAP-L I NK is
Together with the associated SDLCHMOD, it provides the DLC layer for communicating with downstream SNA devices. 5NAP THR
The U product provides pass-through functionality that allows RAF logical units to have SNA sessions with applications on VTAM hosts.

A remote 5NA3270 terminal user connected to the RAF
Terminal-to-host functionality was provided that allows the user to select and access a TAM host and establish an SNA session with the host application. The LOGON program, in conjunction with the HLI interface to the 5NAP-5, provides menu-driven services to the user. These services include logon and password authorization by security/auditing programs and host system and application selection by the user.

Logon is TCP/IP to the selected host FEP
Establish a connection via. Upon successful "establishment" from the host, control of the session passes to the pass-through module. Pass through module is 5NAP TH
Provides an interface between the RU and TCP/IP. All messages in 5NAPS format are standard 5NAPS.
It is converted to a PIU message and transported over the local DN network to the FEP and host application. Upon acceptance of "Deestablish", control is returned to the LOGON program, the TCP/IP connection is terminated, and the default menu reappears on the user terminal.

The terminal-to-host function implements host-initiated sessions and SNA sessions between the host and the RAF Extended Remote Jijibu Entry (ARJE) function, and $SN
Establish network control via A/RM functionality. These functions are provided by the 5NAPS pass-through function. Remote job input function is standard EDX A
RJE program, $SNA version 2, and $5N
Provided by the $DLC module, which is an alternative to the ASDLC interface.

The network control element on the FEP or RAF is
An alarm message can be generated for H. These messages are standard NMVT or RECFMS
format and is compatible with processing by NETVIEW. The F'EP and RAF' generate alarms when errors are detected in all software modules, SNAPS software, and downstream SNA devices such as the 3274. The downstream SNA alarm message is 5NAP-
5, console service fist interface P
Via MOD and console service programs,
Directly to the alarm processing program, which interfaces with TCP/IP and transports alarm messages to the NCF host. All other software messages use the common functionality of 5WOF/5WOP (System Wide Operator Program) to send these messages to swap for processing.

swap formats the alert to standard NMVT, logs the message to a common log file, and converts the formatted NMV
Pass T to the alarm processor. The alarm processor is TCP
/IP to the NCF Alert Processor, which is connected to the NCF Host. If the FEP or RAF cannot connect to the primary NCF host, it will try another NCF host. If a connection is not possible, the FEP or RAF queues an alert message on disk for later transmission to the NCH.

The resource manager on each FEP1NCF and RAF is
Synchronizes the loading of all non-critical elements and subsystems in an EP or RAF environment so that operators can
Allow subsystems to be restarted through an interface. The functions performed by the resource manager are as follows.

Read and interpret configuration files.

Load the coprocessor program and S/1 program as specified in the configuration file.

Provides connections and routing between coprocessor services/programs and S/1 programs.

Coprocessor 5 Processes errors reported from the NAPS program and sends alarm messages to the swap and alarm processors.

Maintain the current status of all managed components/subsystems.

Request a coprocessor storage dump.

Reload subsystems at operator request.

DDN Access Method Support DNAM provides a set of generic instructions and associated data structures (DNAM API) defined in the EDL and implemented within the EDX operating system. The set covers TCP1 User Data Program Protocol (UDP), IP and MI L
- Provide the basic services defined in the 8TD document. Extensions to the basic services are made using additional EDL instructions and keyword parameters for generic instructions.

Specifically, record mode extensions are added to maintain message boundaries across byte-based TCP connections. Additionally, connection groups allow connections with similar characteristics to be grouped together to reduce the total amount of resources required to receive and receive data and reduce the complexity of the application engine required to manage connections. Added expansion.

This connection group extension also facilitates the flow of data between the DNAM API and the connections within the group. When receiving data, an application can issue a single receive instruction for all connections in a group, alleviating the need for the application to pre-allocate buffer space for each open connection. When transmitting data, the completion of a send command is affected by whether its completion is based on the flow state of the entire group or on the flow state of an individual connection. The added last zero extension allows application programs to obtain asynchronous or synchronous notification when a DNAM API completes.

DNAM is functionally composed of the following elements:

DNA for initializing DNAM after system restart
M initialization task Captures DNAM API routines and related task structure status and statistical information for executing EDL commands issued by the application, processes commands to track data in DNAM, and controls operations of DNAM. D to interface with system operators in order to
DNAM utility program for formatting storage dumps from NAM Management Task Structure 68000 attachments. This utility also formats and prints status, trace, error, and statistical information previously output to disk data sets.

DNAM API The DNAM API uses an EDL to define a set of generic instructions (OPEN, CLO8E, 5END1RECEI).
VE1STATUS, and HO8TNAM) and related data structures (COND and BUFD). These EDL instructions and data structures provide an S/1 application program with a way to communicate with another application on an external host via the DDN using one of multiple protocol layers. To access DI)H at a particular protocol layer, combine the generic instruction with the appropriate prefix.

The prefixes accepted by the DNAM API are TCP, A
DM and DDR. DDR allows S/'1 application programs to use DDN direct services to
Enables sending and receiving IP data duram on DN.

ADM allows the DNAM management task to control the 68000 attachment microcode and monitor attachments for statistics and tracking information. TCP allows S/1 application programs to use TCP services to
Enable communication on DN. TCP generic instructions and data structures include:

TCP Open a 0PEN-TCP connection.

TCP 5END - Send data over a TCP connection.

TCP RECEIVE - Receives data over a TCP connection.

TCP Close the CLO8E-TCP connection.

TCP 5TATUS-TCP connection status TCP
HO3TNAM-TCP hostname to Internet address.

TCP C0ND-TCP connection descriptor TCP BU
FD-TCP sends and receives buffer descriptors.

To communicate with an application on an external host over the DDN, the local application must first access 0PE
A communication connection to the DDN must be established by issuing the N command. From the information in the 0PEN command, an application can access the DDN at a particular protocol layer. After the DNAM establishes a connection with an external application, the DNAM EDL instruction routine provides services that allow the local application to send and receive data over the full-duplex virtual connection.

Finally, the DNAM EDL instruction routine terminates the connection in order when the application executes the CLO3E instruction.

DNAM EDL instruction routines return synchronous or asynchronous control to the application. The application is
The DNAM EDL instruction specifies which one is desired to be returned.

FIG. 26 shows the steps required to process synchronization instructions from an application program via the DNAM API. Numbers in the drawings indicate the steps described below.

1. The application program specifies synchronous processing and executes the DNAM API EDL command.

2. The DNAM instruction routine validates the parameters of the instruction, allocates any resources on behalf of the application, forwards the appropriate request to the attachment, and waits for an answer from the attachment.

3. Upon receiving the answer from the network, the attachment forwards the answer to the DNAM inbound service task in response to the previous request.

4. Having updated the control block structure and processed the response, the DNAM Inbound Service Task notifies the DNAM Instruction Routine of the results of the request.

5. If the connection card successfully executes all such requests, or if the connection card encounters a termination error,
Control is returned to the application with a return code describing the result.

If other requests are needed, repeat steps 2-4.

FIG. 27 illustrates the steps required to process asynchronous instructions from an application program via the DNAM API. Numbers in the drawings indicate the steps described below.

1. An application program executes a DNAM API EDL instruction specifying asynchronous processing.

2. The DNAM instruction routine validates the parameters of the instruction, allocates resources on behalf of the user application, and forwards the appropriate request to the attachment.

3. Instead of waiting until the DNAM command routine receives and receives an answer from the connection card, control is returned to the user application immediately after the request is successfully transferred to the connection card. The application then uses the same DNA
Processing can continue until it is desired to issue the EDL command a second time. When issuing the command a second time, the application must wait for the result of the first DNAM EDL command.

4. Once the connection card receives the answer from the network, it forwards the answer to the DNAM inbound service task in response to the previous request.

5. Now that the control block structure has been updated and the response has been processed, the DNAM inbound service task
Notify the NAM asynchronous service task to complete processing on behalf of the user application.

6. If other requests are required, those requests are forwarded to the attachment and the DNAM asynchronous service task
Wait for the next request from the inbound service task.

7. If all such requests are successfully executed by the connection card, or if a termination error is encountered, control is returned to the application with a return code describing the result.

I) N A M Management Task DNAM Management Task software consists of three 1) N
Provides AM-related functions. First, the system operator has the ability to view all connections with respect to the level of demand, such as a single specified connection view that contains more information.
You can view detailed status of connections, connection groups, and DNAM attachments. The DNAM connection display shows control parameters and generated statistics related to the protocol layers provided by the connection mechanism. Second, users can terminate activity on specified connections, groups, and attachments. Third
In addition, the user extracts and kills traces of messages at various protocol layers on the S/1 and attachment mechanisms.

Figures 28A and 28B show the components of the S/I DNAM management software. Each box in the diagram is 1
represents one task. Each parallelogram represents a queue used to pass messages between tasks. The large rectangle represents the DNAM connection interface software as well as the attachment hardware and software.

Error recovery and error handling DNAM error recovery and error handling is performed by DDN/SNA
It is based on a system-wide error handling concept. D.N.
There are four categories of errors that AM detects, and the processing for each category of errors will be explained below.

EDL Instruction Error DNAM returns EDL instruction errors to the user application in the form of a return code. The user application is responsible for performing appropriate error recovery. This range 1
The errors can be classified into five groups.

Transient conditions (retry errors) that would normally complete successfully if retried later (i.e., out of buffer) EDL instruction sequences that are inconsistent with the current state of the communication connection (i.e., an error on a connection that does not exist) Invalid or missing input parameters detected during validation of an EDL instruction Invalid EDL instruction parameters detected by the communication network (i.e., no network path to the remote host exists) The EDL instruction also has a communication connection Failures not under the control of the application (ie, communication network failures) that also terminate the DNAM perform only limited parameter validation. Most parameters, such as storage addresses, are used when bussed in an instruction. These parameters can cause addressing exceptions or other S/1 programming errors, and the EDX operating
Processed by the system and returned to the user application for recovery.

esooo attachment hardware/microcode
Error - To recover the Motorola 68000 Attachment ROS microcode and application microcode,
Indicates DNAM error recovery when an error is detected on the 8000 attachment. A hardware error occurs on the attachment or between the attachment and S/1. : Communication between the DNAM and the application microcode on the attachment is lost. Errors in the application microcode software (such as bus errors or division by zero) may cause the ROS microcode to terminate the attachment. In both cases, 68,000
The attachment hardware returns error information to the DNAM detailing the error condition in the 68000 attachment hardware or microcode. DNA error
A task is notified by a DNAM routine that has encountered a hardware or software error. D
The NAM Error Task analyzes the error information, generates the appropriate IFM 7, and performs any necessary error recovery.

If the communication connection that causes the error can be identified, and the attachment microcode continues to run validly, only that connection is aborted and other communication connections on the attachment are terminated.
The user application is not notified of the error and continues normally.

However, if reloading the attachment microcode and reinitializing the attachment is required for error recovery, D
The NAM terminates all communication connections on the attachment and an appropriate error code is returned to the user application. Additionally, some types of microcode errors
The DNAM Error Task attempts to transfer the attachment status and attachment storage postmortem dump to the S/1 data center before attempting to reload the attachment with microcode.

During the recovery period, the attachment is temporarily removed from the host configuration (ie, the attachment is taken offline). The installed system continues to operate and runs in degraded mode. DNA
M rejects requests from remote hosts to establish communication connections with reference to the DDN physical or logical Internet address of the attachment during the recovery period. D
The NAM also rejects requests from local hosts to establish communication connections with reference to DDN physical or logical Internet addresses during the recovery period.

If the recovery operation is successful, the DNAM updates its configuration to reflect the return of the attachment. The installation system then returns to normal operation.

If the recovery operation is not successful and the attachment is not the last one in the configuration, the installation system continues to operate in degraded mode. DNAM moves the DDN logical Internet address of the failed attachment to another physical attachment. D
The NAM accepts attempts to establish a communication connection from remote hosts using DDN logical addresses, but rejects attempts using DDN physical addresses.

But if it is the last attachment in the configuration, AB
The END service routine is called to automatically re-IPL the system.

S/1 Program (Software) Errors When a program detects a program logic error (an impossible condition), it takes appropriate error recovery actions and calls the ABEND service routine at 17 to log the error and repair the bug. The necessary data is captured on the S/1 hard disk in a timely manner, and the IPL of the S/1 is started.

Configuration and Input Parameter Errors DNAM generates appropriate alerts that identify configuration and input parameter errors found during DNAM initialization. These are fatal system errors, so
DNAM calls the ABEND service routine to cause S/] to automatically re-PLL, re-IPL twice, and then automatically remove the constituent volume from the hierarchy.

FEPlRAF and NCF have been disclosed above as being implemented in an S/1 processor. IBM S/1
For example, IBM Publications rIBM S/i Overview (IBM 5eries/I System Summa)
ry) JNGA 34-0035-5.197
It is listed in 9th year. However, other types of processors, such as the 18M Personal System/2 (R
3/2) Processors can be similarly applied.

F2 Advantages of the Invention The present invention provides network interoperability from a host computer to enable communication between SNA-implemented systems over a packet-switched network such as a DDN. In addition, SNA terminals and S
Interoperability between NA hosts is provided.

Table (DDN/SNA system elements)

[Brief explanation of the drawing]

FIG. 1 is a diagram showing the system protocol. FIG. 2 is an architectural diagram of a defense data network according to the prior art. FIG. 3 is an MVS/DI)N system configuration diagram. FIG. 4 is a diagram showing the MVS/DDN ACP structure. FIG. 5 is a diagram illustrating Internet communication using ACP between a client and a server. FIG. 6 is a diagram showing the DNET-DNET layer of the protocol. FIG. 7 is a diagram showing the header format. FIG. 8 is a configuration diagram. FIG. 9 is a diagram illustrating transaction delay, resource usage, and memory usage. FIG. 10 is a diagram showing the S/1 configuration of the terminal. FIG. 11 is a diagram showing the S/1 configuration of the FEP. FIG. 12 is a diagram showing the DDN/SNA configuration. FIG. 13 is a diagram illustrating the flow of SNA data traffic over the DDN. FIG. 14 is a diagram showing PU2 2FEP components and RAF components. FIG. 15 is a diagram showing FEP components of PU4. FIG. 16 is a diagram showing an overview of the DDN/SNA system 5YSGEH. FIG. 17 is a diagram showing an overview of the processing in stage I. FIG. 18 is a diagram showing an outline of the processing in stage (2). FIG. 19 is a diagram showing an outline of the processing in stage (2). FIG. 20 is a diagram showing an overview of the DDN/SNA host-to-host system. FIG. 21 is a diagram showing an outline of an application between PU4 hosts. FIG. 22 is a diagram showing the flow of application data between the PU4 hosts. Figure m23 is a diagram showing a DDN/SNA front end processor. FIG. 24 is a diagram showing a DDN/SNA and NCF FET. FIG. 25 is a diagram illustrating a DDN/SNA remote access facility. FIG. 26 is a diagram showing the DNAM synchronization EDL command flow. FIG. 27 is a diagram showing the DNAM asynchronous EDL instruction flow. Figures 28A and 28B are diagrams showing DNAM management function tasks. FIG. 29 is a diagram showing an overview of the FEP function of S/1. Figure m30 is a diagram showing the S/1 front end processor. FIG. 31 is an S/1 remote access facility diagram. FIG. 32 is a diagram illustrating a network control front end processor.゛/Sudem 790 Tokoruri 1st difficulty MVS/DON Filling in the system 3 Mouth MVS/DDN ACP product it ¥ 4 Mouth host and Tsukat field! L [I 17t DoD 7 Futogol Archite 7 Chii γ Fig. 7 Fig. FKi 21 Hamasue S/lme Seijutsu 10 Mouth host FEPS/I's Maki Seiho 11 Fig. Tranjikushi 1-no-henshi 11' A sum I and 7. Pufu old D
ON/SNA structure 1212 ■ Figure PIJ4 FEP composition 15 Figure Pu2 FEP composition and RAF vines 14
EB Atsushi ODN/SNA system's 5YSGEN [F] Celebration of events in the country] Measures P17N In 2 Schematic diagram of the theory Katsuzuzaka Sui T1's 40th review ￥ Zuzume strike phase Masama〉Stem nH χ2 Post-Jun 1r47zu゛Liashi 1/Rikiri ti- Narudai N
And 1 false whistle PIJ4 upper strike m! Take flow of L-maarial 71 No. 11 EDL command flow flute diagram DMAM 閤i EDL command flow flute diagram 28th day to mouth 2F3B 112? 28A し〕Death λ9 i 28 A 6:”-ヮDN∆M management fi ability Kusufu〕information)

Claims (4)

[Claims] (1) First SNA via packet-switched network
A data communication system for establishing a communication path from a host computer to a second SNA host computer, the system comprising: first SNA interface means coupled to the first SNA host computer; and first SNA interface means coupled to the packet switching network. a first front for transferring data and control messages between the first SNA host computer according to the SNA protocol and the packet switching network according to the packet switching protocol; - an end processor; second SNA interface means coupled to said second SNA host computer; and second packet switched interface means coupled to said packet switched network; a second front end processor for transferring data and control messages between a second SNA host computer and the packet switched network according to a packet switched protocol. (2) A method for establishing a communication path from a first SNA host computer to a second SNA host computer via a packet-switched network in a data communications system, the method comprising: said first SNA interface means according to an SNA protocol using a first front end processor having first SNA interface means coupled to said packet switched network;
transferring data and control messages between an A host computer and the packet-switched network according to a packet-switched protocol; and a second SNA interface means coupled to the second SNA host computer and the packet-switched network. said second SN according to the SNA protocol using a second front end processor having second packet switching interface means coupled to a network;
A. Transferring data and control messages between a host computer and the packet switching network according to a packet switching protocol. (3) A data communications system that establishes a communication path from an SNA host computer to an SNA terminal device via a packet-switched network, the system comprising: a first SNA device coupled to the SNA host computer;
NA interface means and first packet-switched interface means coupled to said packet-switched network for data and control communication between said SNA host computer according to an SNA protocol and said packet-switched network according to a packet-switched protocol. a front end processor for forwarding messages, second SNA interface means coupled to said SNA terminal, and second packet switched interface means coupled to said packet switched network; a remote access facility for transferring data and control messages between the SNA terminal device and the packet-switched network according to a packet-switched protocol. (4) SNA from an SNA host computer via a packet-switched network in a data communications system.
A method for establishing a communication path to a terminal device, the method comprising: a first SNA coupled to the SNA host computer;
an interface between the SNA host computer according to the SNA protocol and the packet-switched network according to the packet-switched protocol using a front end processor having an NA interface means and a first packet-switched interface means coupled to the packet-switched network; a second SNA interface means coupled to the SNA terminal and a second packet switched interface means coupled to the packet switched network; Transferring data and control messages between the SNA terminal device according to the SNA protocol and the packet switching network according to the packet switching protocol using the SNA protocol.