gtpc3m12Concepts and Structures

Action on the Cross List (Switching I-Stream Engines)

A useful abstraction for describing the dispatching of processing work in a tightly coupled multiprocessing environment is shown in Figure 24. This abstraction suppresses the fact that in reality, the CPU loop program comes in two versions: one version is given an affinity to the main I-stream engine and the other version is shared by all other I-stream engines. The distinction between the two versions is not necessary to describe the action taken on cross list items. In Figure 24, I-stream engines are shown as "CPU n" because this is the way they are identified in online system tables.

The ideas emphasized in Figure 24 are:

Also, remember that most of the main storage resident control program is reentrant across I-stream engines, but is only serially reusable within an I-stream engine. Keeping all of the previous ideas in mind is not always easy. After reflecting upon Figure 24, you should be ready to consider the following description of I-stream engine switching.

Conceptually, the cross lists represent a communication mechanism (mail boxes of sorts) for moving processing work among I-stream engines in a tightly coupled multiprocessing environment. Each I-stream engine must be given the location of every other cross list, a rudimentary form of routing. The cross list references are done through the I-stream status table; the pointers to this table are handled during system initialization. During IPL, each I-stream engine is assigned a number known as the I-stream engine ID. This ID is, for example, placed in a field in an ECB and is passed from one I-stream engine to another through system control blocks such as IOBs. This permits a response to be returned to the I-stream engine on which a request was made; for example, the results of servicing a tape I/O request.

All processing work transferred to another I-stream engine must be done by means of a cross list, which reduces the amount of locking that would be necessary if all CPU loop lists could be accessed by any I-stream engine. Furthermore, multiple cross lists reduce the number of instructions needed to find an item of work for any given I-stream engine; scanning and processor IDs would be required if there was a single shared cross list.

The structure of a cross list item reveals the essence of the cross list interface. An item on a cross list has the following 4-byte fields:

Field
Definition

Parameter 1
The data in this field is particular to the post-interrupt routine that is to receive control.

Parameter 2
The data in this field is particular to the post-interrupt routine that is to receive control.

Forward pointer
The items in the cross list are forward chained.

Backward pointer
The items in the cross list are backward chained.

PI vector
This field points to the routine that is given control when the item of work reaches the top of the cross list.

I/S originator
This field identifies the I-stream engine from which the processing work originated. It is used primarily by system tracing facilities.

Figure 24. Multiple I-Stream Engine Processing Abstraction


Switching an Entry to Another I-Stream Engine

An outline of the procedure for moving an Entry from the main I-stream engine to an application I-stream engine is given in Step 4c. COMM SOURCE Invokes the Application. The detailed processing flow when the SWISC macro is

executed on the main I-stream engine as well as subsequent processing follows here:

  1. COMM SOURCE issues an SWISC macro request on the main I-stream engine. The SWISC macro expansion is found in the routing control application table (RCAT). The SWISC macro input parameters, in this case, include the name of the program segment to be entered and the option to allow the load balancing routine to select the I-stream engine on which the Entry should be dispatched. As a result of electing to execute the Entry on an application I-stream engine, the need arises to place a work item on the ready list of an application I-stream engine.

    In switching an Entry, the Entry is always dispatched from the ready list and not directly from the cross list. The cross list is the highest priority dispatch list and is used for control program services of relatively short duration, with the goal of keeping the list empty or short. An item is only removed from a list when the work associated with a previous item has completed or is suspended. Although an Entry is characterized as expeditious processing, an Entry is a long-running process in comparison to control program services.

  2. The SWISC service routine, executing on the main I-stream engine, uses the $ADPC macro (add to designated list in designated I-stream) to build the following parameters:
  3. The $ADPC macro service routine always passes four parameters to the $CRISC (add to cross list in designated I-stream) macro service routine, which, in this case, places a four-field item on the cross list of the designated I-stream engine.
  4. When the item reaches the top of the cross list on the application I-stream engine, the PI vector to $ADPC (the PI vector of the cross list) causes the terminating portion of the $ADPC routine to receive control, which places the ECB address and the PI vector to the SWISC routine on the ready list, and a return is made to the top of the CPU loop program.
  5. The two-field item of ECB addr and PI to SWISC is now at the bottom of the application I-stream engine's ready list. When this item reaches the top of the ready list, the terminating portion of the SWISC service routine that was originally invoked on the main I-stream engine is given control. This terminating routine is the equivalent of an ENTDC (enter and drop all existing programs) macro request.

Starting an Entry on the application I-stream engine requires the use of the control transfer interface to get from OPZERO to COMM SOURCE on the main I-stream engine, the SWISC macro to place an item on the cross list of the application I-stream engine, and the ENTDC macro service routine to invoke the first segment of an application package on the application I-stream engine. Although the SWISC macro is always invoked by COMM SOURCE on the main I-stream engine, in a uniprocessing environment, the Entry is never switched but is dispatched from the ready list of the engine in which the SWISC macro is issued, because the ID of the engine to receive the work is the main I-stream engine itself. This can also happen in a multiple I-stream engine environment if, for example, all the application I-stream engines are busier than the main I-stream engine.

Switching I/O Processing Between I-Stream Engines

To uncover the processing sequence to handle an I/O request, consider the case where an Entry, executing on an application I-stream engine, uses a FINDC macro request followed by a WAITC macro request. You should now refer to Figure 18, and keep the description provided by Figure 24 in mind.

  1. The FINDC macro service routine creates an IOB that points to the ECB of the requesting Entry and is used to control an I/O operation on behalf of the Entry.
  2. If the DASD device needed to complete the request is busy, the IOB is put on the device queue. If the DASD device is not busy, the I/O is started immediately from the I-stream that issued the FINDC request.
  3. The FINDC service routine, running on an application I-stream engine, restores registers with the register save area found in the active ECB. Thereafter, the old SVC PSW is loaded and processing continues in the entry on the application I-stream engine from which the FINDC I/O request was made.
  4. The entry ultimately issues the WAITC macro request. If the I/O has not started (because the device queue contained other IOBs) or the I/O has not completed, the ECB will be suspended and another entry will be dispatched on the I-stream.
  5. If the DASD device to which the I/O was queued was busy, the I/O will eventually be started by the I-stream that processed the last interrupt for the IOB before our FINDC request on that device.
  6. Finally, the I/O will be completed and issue an I/O interrupt on any I-stream. By using the $ADPC macro, the IOB is put back on the ready list of the I-stream that initially issued the FINDC macro.
  7. When the IOB reaches the top of the ready list, the FINDC post-interrupt routine is called to place a pointer in the ECB that locates the data read from disk. This routine also releases the main storage block used to hold the IOB. Assuming no other I/O is pending, a return is made to the entry that issued the FINDC macro request. If additional I/O is pending for the ECB, control is returned to the CPU loop.