gtpc3m27Concepts and Structures

Message Routing Overview

The basic tasks of communications control are the gathering of input messages from various sources (the input message is the primary unit of work in the TPF system) and the scheduling of that work according to its priority with respect to other tasks already in progress (see CPU Loop (Dispatching Work)).

Figure 58 shows the various steps of communications control that enable the message processing flow within the TPF system. In the following sections, the various components are described in greater detail to give you insight into message processing.

Evolution of Communications Control

Before tracking the path of a typical message through the TPF system, some history is helpful to define the terminology.

One Application and a Simplistic Network

In the 1960s, the TPF system was designed for the airline reservation application, the only application in a TPF system. Therefore, by default, all terminals in a network attached to a TPF processing facility were logged onto the only application (the airline reservation application). Also, at that time, the technology of terminal networks was rather simplistic, with communication controllers providing little more function than line multiplexing. As such, the TPF system (also called a host system) was responsible for:

An application program addressed terminals by physical addresses. The TPF system handled the unique interfaces that were required for each different device type (similar to a communication protocol). The application recognized a terminal by its terminal address in the form of line number (LN), interchange address (IA), and terminal address (TA) or LNIATA.

Multiple Applications and Multiple Destinations

With the advent of the message router in the TPF system, the concepts of multiple applications and message destination were introduced. The concept of destination is the idea that an application can send a message (data) to a terminal or another application. Prior to this, it was assumed that only a terminal could send a message to an application. Also, remember that prior to this, the only application was RES0. The concept of multiple applications introduced the ability to run other applications such as fare quotation and cargo in the airlines industry on the same TPF system. This marked a turning point in the evolution of the TPF system: the separation of system functions from the application functions enabled the TPF system to perform more like an operating system.

To manage the multiple applications and message destinations, the routing control parameter list (RCPL) was invented to carry the origin and destination of an input message throughout the processing of the message in the TPF system. Valid combinations of origins and destinations are:

Origin Destination
terminal application
application application
application terminal

Another change in communications control at this time was the way in which terminals were identified. Instead of a very specific identification (that is, LNIATA), which is closely related to hardware addressing, terminals were given a symbolic address called a logical end-point identifier (LEID).

In this same era, the log processor was developed because a terminal could log onto one of several applications. The log processor controls which application a terminal logs onto.

SNA and Larger Networks

In the 1970s, system network architecture (SNA) support was added to communications control in the TPF system. This allowed the TPF system to be attached to much larger networks that controlled thousands of terminals and workstations.

To maintain the performance factor in the TPF system, use of SNA allowed much of the communications protocol handling to be off-loaded from communications control in the TPF system and to be performed by communication controllers running an NCP. This meant that the TPF system was not responsible for polling input or scheduling output as in the earlier simplistic networks.

In keeping with the trend started with multiple applications and multiple destinations to identify devices symbolically, the resources in an SNA network are called logical units (LU). Each logical unit has an 8-character LU name and a network address. Both an LU name and its network address map into a resource identifier (RID). The RIDs associated with the origin and destination of an input message are carried in the RCPL of the message throughout its processing.

Old and New Applications

Using this history lesson, the terms old application and new application can now be defined.

The applications that recognize the origin of an input message in LEID form are called old applications. And, by default, those applications that recognize an RID as well as an LEID are called new applications.

Summary

There are two forms of symbolic identification for resources in a network:

A Communications Overview of Message Processing

The following sections describe the processing that occurs within the TPF system at each stage of the process, from the acceptance of an input message, to the delivery of the output response, to communication facilities.

Figure 58 provides an overview of communications control for both SNA and non-SNA networks and shows the processing paths both for a normal input message and a transaction message. Both of these types of messages arrive at the TPF system in the same way. However, once within the TPF system, the processing paths of the messages diverge until responses are generated; then, the processing paths for delivery of the responses for both types of messages come together again. The processing path of a normal input message is described in this section while the processing path of a transaction message is described in TPF Advanced Program-to-Program Communications (TPF/APPC).

Figure 58. Communications Control Overview


Input Processing

This section describes how an input message arrives at the TPF system through the interrupt mechanism of an I/O interrupt. The I/O interrupt handler passes control to the I/O interrupt handler associated with the communication protocol, which then schedules the input message for processing by placing a work item (associated with the input message) on the input list, a CPU loop list. (The term work item is used here because the exact format of what is put on the input list is dependent on the protocol.)

When the work item gets to the top of the input list (as a result of the other items on the list being removed for processing), control is given to the OPZERO program associated with the communication protocol.

The processing for all sources of messages is described here because this is where the most noticeable differences between SNA and non-SNA are seen.

SNA

Non-SNA -- Binary Synchronous Communication (BSC)

In a BSC network, the TPF system can play several roles:

Although the concepts of BSC input can be stated simply, the processing required by the TPF system in the management of BSC links is very complex; therefore, its detail is omitted from this discussion.

Non-SNA -- Synchronous Link Communication (SLC)

SLC is unique in that the TPF system is always ready to accept data from an SLC line. Although you might think that the TPF system is always ready to accept data from other protocols, the difference is that for SLC, the TPF system is constantly issuing I/O commands to read data, whereas for the other protocols, the TPF system only issues I/O commands to read data when it knows there is data to be read.

Suffice it to say, the process required to receive data from SLC is much more complex than the corresponding process to receive data from an SNA network. This is because the TPF system must manage the link, whereas for SNA, similar functions are performed by the NCP.

Non-SNA -- 3270 Local

Operation Zero Program (OPZERO)

OPZERO refers to a collection of system programs associated with communications control in the TPF system. Essentially, there is one OPZERO program for each type of communication protocol.

OPZERO executes only in the main I-stream engine, which is the I-stream engine accepting interrupts associated with all communication facilities except MPIF.

OPZERO Functions for All Protocols

The primary functions of OPZERO are:

OPZERO is activated when the CPU loop removes a work item that is associated with an input message from the input list.

SNA OPZERO

For the BSC, SLC, and 3270 local protocols, the work item is associated with only one input message. However, for the SNA protocol, the work item is associated with an input buffer that contains one or more input messages. Therefore, SNA OPZERO must deblock the input buffer, message by message. For each message, SNA OPZERO:

SNA OPZERO verifies that the proper protocol has been followed by the originating source. If an input message fails protocol verification, a reply, called a negative response, is generated to indicate the reason the message is rejected.

COMM SOURCE

COMM SOURCE refers to a collection of system programs that transform input messages from their individual protocol-dependent formats into the common system format that is recognized by applications. This relieves the application from knowing the details of the various communication protocols supported by the TPF system.

COMM SOURCE executes only in the main I-stream engine, which is the I-stream engine accepting interrupts from the communication facilities.

COMM SOURCE for All Protocols

The primary functions of COMM SOURCE are:

Determining the Destination of the Input Message

Non-SNA terminals are dedicated to the TPF system. This means that all input flows directly to the TPF system. However, non-SNA terminals can either select (through a special input message called LOGON) the application in the TPF system they are to be connected with or be permanently logged into one specific application. The application is the destination of the message.

SNA devices are shared resources, which means that SNA devices are associated with more than one host. A LOGON input message specifies the host and application to be connected (that is, associated) with an SNA device. If an SNA device is always associated with the same application in a host, it can be permanently logged. Again, the application is the destination of the message.

Figure 59 shows the tables used to locate the application package necessary to process an input message. A routing control parameter list (RCPL) is constructed in the ECB with fields to hold the origin and destination of the message and the characteristics of the message.

There are several terminal identification tables in the TPF system:

A terminal identification table is indexed (accessed) based on the origin of the input message, and the origin is dependent on the communication protocol involved. The tables contain a pointer for each user terminal and workstation and are used to locate the application that the user selected previously.

A program called the log processor is used to interpret a logon input message, which permits a terminal or workstation user (who is the source of input) to select an application package, such as the Airlines Reservation Application Package ( ). In this publication, application packages refers to installation-produced software. The log processor sets up the pointer in the appropriate terminal identification table (RVT or WGTA).

The pointer in the appropriate terminal identification table locates an item in the application name table (ANT), which has a field to hold an application name (such as RES0) to which the user is connected, and another field to point to an item in the routing control application table (RCAT). The RCAT item holds the online linkage to an application program segment. A large application, such as RES0, consists of many program segments, (ranging from hundreds to thousands), only one of which is identified in the RCAT.

The program segment located through the RCAT represents the departure from TPF system programs into installation-written programs. Keep in mind, however, that COMM SOURCE runs in the ECB-controlled environment as does the installation-written program, invoked by COMM SOURCE. For some applications, in particular RES0, terminals and workstations are permanently logged on to a single application. A permanent logon is, in essence, done during system generation.

Figure 59. Tables Used to Locate an Application


User Exit Processing

The SNA communications control user exit can be entered to permit user-installation unique processing to be done, such as:

The user exit returns control to COMM SOURCE for additional processing.

Schedule Input Message for Processing by the Application

In a central processing complex (CPC) with multiple I-stream engines, the remainder of the ECB-controlled process can be dispatched to one of several I-stream engines. If the user exit specified the I-stream engine in which to execute the application, a work item for the ECB is placed on the cross list of this I-stream engine. Otherwise, there is a load balancing routine in the TPF system that places the work item on the cross list of the I-stream engine that is least busy.

The appropriate application program segment on an application I-stream engine is invoked as a result of COMM SOURCE (executing in the main I-stream engine), placing an item on the cross list of an application I-stream engine. Pointing to an ECB of a particular I-stream engine is the essence of moving an Entry between two I-stream engines: the ECB itself remains in the same main storage location while the processing of the Entry is assumed by another I-stream engine in the CPC.

Application Services

Some facilities provided by the TPF system for application use are:

Output Message Router

The output message router is the service routine for the ROUTC macro. Based on the destination specified in the RCPL, the message characteristics (one working storage block with or without pool records), and network activity, the output message router transforms the message into a device-dependent format and transmits the message over the network.

Message Destination

The type of destination is:

The destination of the message is associated with a CPC, which is either local relative to the CPC that is transmitting the message, or remote. Local implies that the destination CPC is the same as the originating CPC. If the destination CPC is remote, the destination CPC is either in complex or out of complex.

In complex implies that the complex is loosely coupled and that the destination CPC is within the loosely coupled complex. Out of complex implies that the destination CPC is not one of the CPCs in the loosely coupled complex of the CPC that is originating the message.

In Figure 60, if the originating CPC is A, and

Message Buffering

In order to transmit a message, it must be sent in increments that are acceptable to the device. Communications control performs the buffering of messages based on the characteristics of the device.

Message Queuing

To regulate the rate of message flow from the TPF system to prevent an overload of traffic on the network, messages are queued on DASD (in pool records), if necessary, until traffic permits transmission. This is called pacing.

Message Recovery

When a network is defined, message recovery can be specified for a range of resources. This means that there must be the capability to retransmit any message sent by or received by the resource.

In the TPF system, by definition, when the input message is recoverable, the output message is recoverable. This is accomplished by saving a copy of the message on file storage (in a pool record) until positive indication is received by the TPF system that the message has reached its destination.

Transmission of Output Message

A message transmitted over an SNA network is sent from the TPF system using the SOUTC macro. A message for the non-SNA network is sent from the TPF system using the SENDC macro.

Functional Management Message Router (FMMR)

FMMR processing occurs when the output message router detects, through the content of an RCPL destination routing, that a message is to be sent to an application in a CPC in a TPF system whose CPU ID is external (that is, remote and out of complex) to the originating complex. The output message router is invoked to do this either through a ROUTC macro request or as a result of an enter from COMM SOURCE.

In effect, COMM SOURCE serves as an intermediate routing node.

Interprocessor Communication (IPC)

IPC processing occurs when the output message router detects, through the content of an RCPL destination routing, that a message is to be sent to another CPC in the LC complex (that is, remote and in complex).

Figure 60. Destination -- Output Message Routing


TPF Advanced Program-to-Program Communications (TPF/APPC)

TPF Advanced Program-to-Program Communications (TPF/APPC), an implementation of IBM's Advanced Program-to-Program Communications (APPC), is an interface that allows TPF transaction programs to communicate with nodes that have implemented APPC.

The alternate processing path out of OPZERO shown in Figure 58 pertains to the processing of a transaction message. A transaction message is an input message that originates from an LU 6.2 type SNA resource. A transaction message is processed by a special type of application program called a transaction program.

A conversation takes place between a transaction program in the TPF system and a transaction program residing in another LU 6.2 resource. That is, the transaction programs take turns processing the information received from each other.

When COMM SOURCE recognizes a transaction message, it passes the message to the input function of TPF/APPC presentation services, which uses the transaction program name table (TPNT) to determine the specific transaction program to perform message processing for a new conversation. For an established conversation, the transaction program handles the message. On the output side, the output functions of TPF/APPC presentation services use ROUTC macro services.