Using a control table to control program flow

You are recommended to use packages instead of this technique to control program flow.

The design principle presented is an example of a standard method that can be used to implement different types of application design. It allows the use of, for example, one large plan or many small plans without changing the programs.

Table 1 shows an example of the contents of a control table. The example is based on the design situations described in Figure 1.
Table 1. Control table for sample application
Function name Program Transaction Plan name New TRANS ID
  P0 TRX0 PLAN0 *
Sales P1 TRX0 PLAN0  
Order P2 TRX0 PLAN0  
Pay P3 TRX0 PLAN0  
         
  PA TRXA PLANA *
Price PB TRXA PLANA  
Order PC TRXA PLANA  
Parts PD TRXA PLANA  
         
Price PB TEMP PLANX *
Function name
The function name field of the table supplements the program field. It works in exactly the same way. It is used in the cases where the terminal user enters a function name in a command field, eventually supplied with a key. The PFCP program can accept either a function name or a program name.

PFCP then uses the function column to search for a valid transaction.

In this way, the logic to interpret the user's choices is also removed from the programs and placed in the table, where it is easy to maintain.

Program
The name of the program described in this row.
Transaction
The transaction ID name under which the program in the program column can be executed.
Plan name
The plan name field is not used. It is shown for illustration purposes only. It shows the plan name used by the corresponding transaction.
New TRANS ID
An * in this column of the table means that the corresponding row can be used when searching for a new transaction ID to start a given program.
The control table reflects the following main relationships:
  • Relationships between plans and programs/DBRMs, which are described in the Db2® catalog table SYSIBM.SYSDBRM
  • Relationships between transaction codes and plans, which are described using the DB2ENTRY and DB2TRAN CICS® definitions

The control table can be implemented in different ways. The most useful solutions are probably either a Db2 table or a main storage table.

A Db2 table is the simplest to develop and maintain. One or two SELECT calls are needed for each invocation of PFCP. These SELECTs should return only one row and indexes can be used. The data and index pages are referenced often and probably stay in the buffer pool. The response time impact is thus minimal.

A main storage table is faster to access, at least until a certain number of rows in the table is reached. It is more complicated to maintain.

The principle in the program flow is shown in Figure 1.
Figure 1. Table-controlled program flow
The diagram shows a program flow diagram including a program flow control program (PFCP).The process is further explained in the text following the diagram. In summary, the user sends a transaction to CICS, and a program receives the terminal map. After processing, the program can either send back a map to the user, or it can transfer control to the program flow control program (PFCP) to start a new program or function. If it transfers control to PFCP, it passes a commarea. PFCP receives the commarea and looks up the new program. PFCP can now transfer control directly to the new program, passing on the commarea. Alternatively, PFCP can transfer control to a relay program, passing on the commarea, and the relay program can start the new program and pass it the commarea. The new program picks up the commarea and performs processing. If this is the end of the process, the new program sends back a map to the user. Alternatively, the new program can name another program that needs to be run, and pass control back to PFCP again for PFCP to run the new program.
The flow for the application design used in Figure 1 is as follows:
  1. The terminal user sends a transaction to CICS. The transaction ID is TRX0.
  2. The transaction definition points to program P0.
  3. Program P0 receives the map, does some processing, and decides that program P3 is needed.
  4. Instead of transferring control to program P3 (the DBRM for P3 could be part of another plan), P0 transfers control to the program flow control program (PFCP in this example). P0 also passes a COMMAREA.
  5. PFCP does a table lookup in the control table to see if program P3 is included in the plan currently in use (PLAN0). This is done by checking if P3 is specified in the same row as the current transaction ID (TRX0). In the example, this is the case (line 4 in the table).
  6. PFCP then transfers control to program P3. It also passes the COMMAREA it received from P0 to P3.
  7. P3 processes the necessary SQL calls and finishes either by sending a map to the terminal or by transferring control to PFCP (not shown) to execute another program.
  8. Assuming that this other program is PB, PFCP again checks whether PB is allowed to run under the current transaction ID, which still is TRX0.

    The table shows that PB must not be executed under TRX0. PFCP then examines the table to find a transaction ID under which program PB can be executed. In the example, both TRXA and TEMP are valid transaction IDs. However, TRXA is pointing to program PA in the transaction definition. The New_TRANS_ID column of the table shows that only the rows with an * can be used when searching for a new transaction ID to start a given program. In this case, it is the TEMP transaction.

    There are two possibilities for program names in the RDO transaction definition entry for the TEMP transaction ID:
    • The RDO transaction definition can point directly to the new program (PB). In this case, there must be a transaction ID for each program that could be started in this way. Also, to use the COMMAREA, the program being started must contain logic to find out whether it is being started by START or by gaining control from an XCTL.
    • The RDO transaction definition can point to a common program, here called the RELAY program. In this case, one or more transaction IDs can be used. All of them point to the RELAY program in the RDO transaction definition. The purpose of the RELAY is to transfer control to the appropriate program. All these programs are then never begun with START and do not need to handle this situation.

      The solution with the RELAY program is shown in Figure 1.

  9. PFCP starts the transaction TEMP, passing the COMMAREA.
  10. The RELAY program is started. It must use an EXEC CICS RETRIEVE command to retrieve the COMMAREA.
  11. From the COMMAREA, RELAY picks up the program name PB.
  12. RELAY transfers control to PB, passing the COMMAREA.
  13. The plan switch is completed.