Message flow through the z/TPF system

Step 1. The system is initialized

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

Step 2. CPU loop checks for work on the cross, time dispatch, ready, and input lists

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

Step 3. 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. z/TPF system A goal of most z/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 Figure 2.

In summary, messages move in (and out of) a central processor 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 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 1.)

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 2.

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 z/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 z/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

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.