Design overview

This section describes how FEPI works at a high level. It discusses how the FEPI functions are provided within CICS®.

FEPI as a CICS transaction

The main functions of FEPI are provided through the CSZI transaction, which is defined in group DFHFEPI. CSZI runs the FEPI Resource Manager, which is responsible for most of the functions of FEPI.

The FEPI Resource Manager transaction is attached during a late stage of CICS initialization. CSZI runs as a high-priority CICS system task, and cannot be canceled by an operator; it is terminated during CICS shutdown processing.

The FEPI commands communicate with the Resource Manager through the FEPI adapter program, which is loaded when CICS initializes, and is part of the CICS nucleus.

The FEPI adapter receives information from FEPI commands through two EXEC stubs, DFHESZ and DFHEIQSZ. DFHESZ handles the FEPI application programming commands, while DFHEIQSZ handles the system programming commands.

These two EXEC stubs call the adapter to do FEPI work. The adapter communicates with the Resource Manager through work queues. See Application flows for details of these flows.

Application flows

FEPI as a CICS transaction outlined the main components of FEPI. This section shows the pathways followed by a FEPI command.

Application programming command flows

The FEPI application programming commands flow through the normal EXEC CICS route into DFHEIP, from where they are routed to DFHESZ. DFHESZ passes the command parameter list to the FEPI adapter. After checking and other processing, the adapter generates another parameter list in internal format, and places it on a queue for the FEPI Resource Manager to process.

While the adapter is waiting for the Resource Manager to process the command, it issues a wait. The event control block (ECB) for this wait is contained in the parameter list queued to the Resource Manager. Consequently, the application that issued the FEPI command is in a wait state while the Resource Manager is processing the FEPI command. For information about wait processing, see the CICS Problem Determination Guide.

When the Resource Manager has retrieved the command from its queue, and processed it, the ECB is posted, thus ending the wait.

Control returns from the adapter to DFHEIP, and the application program in the normal fashion.

Figure 51 shows this processing. Note that the details are for illustration only.

Figure 51. FEPI application programming command flows
 This figure shows the command flows in FEPI application programming, as described in the text above.

System programming command flows

The FEPI system programming commands flow through DFHEIQSZ rather than DFHESZ, but the overall picture is the same as for FEPI application programming requests.

However, some system commands can flow directly to the FEPI Resource Manager, bypassing the EXEC stub. These commands are mainly concerned with FEPI processing to be done at "special" events, such as task termination and CICS shutdown.

Figure 52 shows this processing. The details are for illustration only.

Figure 52. FEPI system programming command flows
 This figure shows the command flows in FEPI system programming, as described in the text above.

Logic flow within the FEPI adapter

Figure 53 shows the logic flow within the FEPI adapter in more detail. In particular, it shows the points at which the FEPI global user exits, XSZBRQ and XSZARQ, and the FEPI journaling function, are invoked.

Journaling of data occurs after the Resource Manager has processed the request, but before XSZARQ is called (if active). Data is not journaled if your XSZBRQ exit program rejects the request.

Figure 53. Logic flow within the FEPI adapter
 The logic flow is as follows: A request enters the FEPI adapter. The adapter performs a syntax check and a lexical check, then calls XSZBRQ if present. It invokes RM and waits while the request goes to and from the FEPI Resource Manager. Next, it journals if required, calls XSZARQ if present, and returns a response to the caller.

The FEPI adapter and Resource Manager

The FEPI adapter runs as part of the invoking CICS task, and so runs under the QR task control block (TCB). The FEPI Resource Manager, running as CSZI, runs under the SZ TCB (reserved for use by the Resource Manager).

Consequently, the interface between the adapter and the Resource Manager uses waits and queues to synchronize access. The control block used to pass information between the adapter and the Resource Manager is called the DQE.

Figure 54 shows this interaction. The details are for illustration only.

Figure 54. Interaction of the FEPI adapter and Resource Manager
 This figure illustrates the relationship between the FEPI adaptor and the FEPI resource manager, as described in the text above.

The FEPI Resource Manager work queues

When organizing its work, the FEPI Resource Manager uses a mechanism that is optimized for the FEPI environment. Each DQE is chained to a queue representing the work to be done next.

The most common mechanism used for this movement between queues is the connection on which the original FEPI command is operating.

Summary of Resource Manager work queues

In addition to the application queue, there are other queues used only by the Resource Manager. They are:

API/Norm
Used for FEPI application requests
API/Expd
Used for FEPI high-priority application requests
PRB
Used for Resource Manager internal work
PRB/Time
Used for Resource Manager internal time-dependent work
IRB
Used to control work done in VTAM® exits
IRB/Time
Used to control time-dependent work done in VTAM exits
TPEND8
Used to process VTAM TPEND8 conditions
Timer
Used to control timer-related work
Free
Used to hold VTAM RBs that have to be freed
Discard
Used to control requests initiated by FEPI DISCARD commands.
CICS work
Used to schedule work that has to run under the CICS QR TCB.
[[ Contents Previous Page | Next Page Index ]]