gtpc3m0uConcepts and Structures

Message Flow Through the TPF System

This processing necessary to respond to an input message is described in more detail in this section. This message trace is meant to be a pragmatic introduction to TPF system conventions and structure. Keep in mind that this section describes the flow of a single message through the system in contrast to a TPF transaction (see Transaction Defined).

The arrangement of this section is important. Figure 18 contains a conventional flow diagram (that is, the lines are meant to represent processing sequence). The circled numbers identify the sequence of processing and correspond to the numbers given in the following text. An oval symbol is used to show a point of processing that is taken when an I-stream engine is interrupted; the point of processing is dependent on the type of interruption. Occasionally, two different numbers appear side by side, which means the process has returned to the system component where the different numbers are given. Also, the same number appears at different points on the chart. This means that various components are involved with the same processing step.

Important detail is included in the following sections that trace a single message, including discussion of tightly coupled multiprocessing where necessary. This detail keeps the essence of message processing relatively concise. Upon first reading, it should be possible to obtain an accurate conceptual idea of message processing without bothering with too much detail. This trace of a message through the system and the remaining sections of this chapter introduce the management of resources provided by the TPF system.

Now, refer to Figure 18 as you read the following steps that trace the flow of a message.

Figure 18. Message Processing Flow Diagram






Step 1. The System is Initialized

Start by assuming that the TPF system has been initialized and the CPU loop is in control.

Step 2. CPU Loop Checks for Work on the Cross, Ready, and Input Lists

The CPU loop finds nothing on the cross list, ready list, and input list, and because the timer has not yet caused an external interrupt, continues looping.

Step 3. Input Messages Arrive

In the TPF system, there are several ways that input messages arrive:

Data Communications discusses this topic in more detail. However, for now, the actions initiated by the CPU loop are used for this discussion.

The CPU loop finds that it is time to request input messages and invokes the communications control input routine, which starts an I/O operation to read the data from the communication network.

Observe that the willingness to accept an unlimited number of input messages could exhaust main storage. The system avoids this problem by placing an upper bound on input messages, known as a shutdown level. In a properly configured TPF system, the input list shutdown level only occurs if the system is driven beyond its design limits, and normally shows up as response time degradation. A goal of most TPF installations is to tune the system so that the shutdown level is virtually never observed.

Step 4. Create an ECB and Select an Application

The CPU loop finds an item on the input list. The following functions are accomplished through the programs OPZERO and COMM SOURCE.

Step 4a. Message Preprocessing

The format of an input message arriving from a communications facility is specific to a communication protocol. (There are multiple protocols supported both on the SNA and non-SNA networks.) For each communication protocol, there is an associated OPZERO program that handles the details peculiar to that communication protocol. However, for the present, we can ignore these details. From this point on, the term OPZERO refers to the common functions of the various OPZERO programs. Furthermore, assume that an input message fits into a single storage block so that our discussion does not need to include such details as chaining a message and the isolation of separate messages from a collection of messages that can be in an input buffer.

The details of communication protocols and message preprocessing performed in OPZERO and COMM SOURCE are discussed in Data Communications.

Step 4b. OPZERO Creates and Initializes an ECB

The ECB is a main storage area, private to a specific input message or, more accurately, to a specific Entry. A subroutine invoked by OPZERO creates the ECB that defines the Entry. A pointer to the input message is placed in the ECB.

A transition is made from the supervisor state of the control program to the problem state of the application (Entry) environment, where all the system services designed to work in conjunction with an ECB can be invoked. At this point, the ECB register is loaded (initialized) with the address of the ECB. The ECB register is an Entry's indirect reference to a private main storage block -- the cornerstone of the application program reentrant structure. The reentrant programs that refer to private data through the use of an ECB are called ECB-controlled programs (or E-type programs).

When processing an input message, COMM SOURCE is the first system program that is ECB-controlled.

Step 4c. COMM SOURCE Invokes the Application

COMM SOURCE places the input message into the common message format used by the application environment. This format is known as AMSG.

COMM SOURCE initializes the routing control parameter list (RCPL) associated with an input message throughout its processing.

The ECB associated with the input message is placed on the cross list of an appropriate I-stream engine by COMM SOURCE through an SWISC macro request.

The details of COMM SOURCE is a topic in Data Communications.

Step 4d. An Application is Selected

The programs 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 upon previous message processing, the transaction processing editor can retrieve the terminal control block associated with the source of the input message.

The combined functions performed by COMM SOURCE, the log processor and the retrieval of the terminal control block are in the box labeled Application Selection in Figures Figure 12 and Figure 18.

In summary, messages move in (and out of) a central processing complex (CPC) through the use of interrupt handling routines for communication controllers, the communications control input routines, OPZERO, COMM SOURCE, and the macro decoder (for output). Although these functions occur at different times, all except the macro decoder are considered to be part of the communications control function.

Step 5. Fetch Application Program from File

Generally, some segment of the application program package necessary for processing the message must be retrieved from file. If this is the case, the appropriate I/O is started for accessing the necessary program segment. (See Enter/Back (Program Linkage) for information about the procedure for invoking file resident application programs.)

At this point, further processing related to this input message is delayed until the I/O completes. During this delay, the CPU loop can process other work (Entries).

Step 6. Starting Program

Eventually, the program segment needed to continue message processing is read into main storage. As a result of this completed I/O, an item is ultimately placed on the ready list of the I-stream engine that initiated the request. Moving I/O work between two I-stream engines is described in Action on the Cross List (Switching I-Stream Engines). When the CPU loop finds this item on the ready list, the suspended application Entry once again receives control. The ECB, terminal control block, and input message are still in main storage at this point. For each I/O delay, the CPU loop continues its processing as described in CPU Loop (Dispatching Work).

Step 7. Running Applications

Assuming the input message requires a response, an Entry obtains a block of main storage in which the output message is built. During the processing of an input message, the Entry makes (I/O) requests to access file storage by using find and file macro requests. If the Entry informs the system that further processing should be delayed until the I/O is complete, through the WAITC macro request, this type of delay is handled like the delay described in Steps 5 and 6. (This is the delay shown as an "I/O gap" in Figure 5.)

Step 8. Sending the Reply

When processing of the input message is complete, the output message is transmitted to the end user over communication facilities. The Entry can issue a ROUTC macro request for this transmission. This implies I/O processing that is not shown in Figure 18.

An application can request system services to format the output message to accommodate a communication protocol (because of unique device characteristics). The formatting services program is an application interface (API) to the function of message transmission in the TPF system.

Step 9. Release Resources and Cleanup

When all the processing required by an Entry is complete, an EXITC macro is issued. This causes the TPF system to release all main storage utilized for processing the input message, as well as to perform other system housekeeping.

Summary of Message Flow

The flow of a message has hopefully demonstrated that communications control, as well as other I/O support, is an integral part of the TPF system. The intimate relationship between the communications control and the other system control components in the TPF system is a processing philosophy used to improve performance. The introduction of the following components represents the principal interfaces between the communications control and the application environment:

Some important system functions and detail are not readily identified by the pragmatic approach of describing the flow of a single message. These system facilities and conventions are described in the following sections.