gtpc3m27 | Concepts and Structures |
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.
Before tracking the path of a typical message through the TPF system, some history is helpful to define the terminology.
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:
In a network where communication controllers provide only minimal function, the host system (the TPF system in this case) must check whether data has been input from terminals. Contrast this with a modern communication controller that performs this function on behalf of the host to which it is attached.
In a network where communication controllers provide only minimal function, if a device is not ready to receive data, the data (that is, a response) must be queued by the host system (that is, the TPF system) until the device is ready to receive it. Compare this to a modern communication controller that takes the data from the host and buffers it until the device is ready to receive it.
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.
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.
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.
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.
There are two forms of symbolic identification for resources in a network:
Optionally, SNA terminals can also have LEIDs; an LEID allows an SNA terminal to access old applications, in which case the TPF system transforms the input RID to an LEID, and on output, the LEID is transformed to an RID.
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
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.
In a BSC network, the TPF system can play several roles:
or
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.
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.
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.
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.
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:
The buffer remains at the top of the input list until the buffer is exhausted. This ensures that messages are processed in the order they are received, a requirement for communications control.
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 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.
The primary functions of COMM SOURCE are:
See Determining the Destination of the Input Message for additional information.
The RCPL contains information such as the origin of the input message and the destination to route the input message (that is, the name of an application or terminal).
This information includes a count of input messages and a running total of the lengths of each message.
User exit processing allows user installation unique processing to be performed.
See User Exit Processing for additional information.
COMM SOURCE uses system tables to determine the application program segment to process the input message.
See Schedule Input Message for Processing by the Application for additional information.
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
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.
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.
Some facilities provided by the TPF system for application use are:
The purpose for providing the 3270 simulation facility is to shield applications from device dependencies. In particular, 3270 simulation provides transformation of:
Note that 6-bit character codes are a remnant of the early days of the TPF system and that the applications written for 6-bit character codes can be used with 3270 simulation services for processing 8-bit character code data streams.
Typically, an application input message editor and its corresponding output message sender intercept messages directed between the TPF system and the 3270 to request simulation services.
The purpose for providing the 3270 mapping facility is to shield application design from being device dependent. Secondly, the application program does not need modification when the end user of the application requires changes to an input message format, display format, or print listing.
Maps, which are designed by a user installation for a particular application, specify field definitions and constant text (such as titles in a display or column headings in a print listing) for input and output displays and print listings (output only) that are associated with the application.
An application requests input mapping services to remove the constant text and device-dependent control characters from an input message. The resulting input message consists of only the data that is necessary for processing. An input map is used to control the removal of the constant text.
Output mapping is used when an application formats an output message that only contains the variable data in an output display or print listing. The application requests output mapping services to add the constant text and device-dependent control characters to the output message. The resulting output message is then in the proper format for the receiving device.
Despite its name, 3270 mapping is applicable to devices other than 3270-type devices, such as 1980-24 and 1977 devices.
The applications invoked by COMM SOURCE are frequently installation-written transaction processing editors that select one of the many message processing programs. If the processing of the current message is dependent on previous message processing, the transaction processing editor can retrieve a terminal control block. The terminal control block is used to accumulate data from the many messages that make up a transaction. (Single message transactions do not require the retrieval of a terminal control block.)
The TPF system supports several such blocks:
A terminal control block is obtained by using the origin address field of the RCPL that is associated with the input message as the basis of an index into a file holding these blocks.
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.
The type of destination is:
or
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
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.
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.
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.
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.
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.
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), 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.