Switching transaction IDs to switch plans

Once a transaction has started, you cannot control the plan used by the transaction ID, but you can control the transaction ID itself. Therefore, you can switch plans by switching transaction IDs. However, you are not recommended to do this. Instead of switching transaction IDs to switch plans, you are recommended to bind the DBRM from the missing program into a package, and add the package to a package list in the existing plan.

About this task

If you have to switch transaction IDs, note that in most cases, the first program transfers data to the next program. The preferred method of doing this is to use an EXEC CICS RETURN IMMEDIATE command. Alternatively, you can start a new CICS® task against the same terminal, using an EXEC CICS START command, or using a transient data queue with a trigger level of one. The old program should issue RETURN to CICS to make the new task start. For both of these switching techniques, the work done in one user transaction is split up into more than one UOW. If the new task is backed out, the work done in the first task remains committed.

If you switch transaction IDs to switch plans, the application programs contain the logic to decide when to switch transaction ID. This means that if you want to change the plan structure (for example for performance and operational reasons), you need to change the application programs as well.

A different technique is to have the program flow controlled by a table, instead of having code to do this in several programs. The main idea is that it is simpler to maintain the relationship between the plans, programs, and transaction IDs in a table than to maintain code in each application program to do the logic. Developing the application programs is also simpler if a standard interface is provided.

Advantages
  • This method allows you to implement different types of application design, such as using one large plan or many small plans.
  • The decision of when to switch plans is taken away from the development process, and is not part of the coding.
  • Only the control table needs to be updated when new programs are set into production. The existing programs do not need to be changed, even if they can call the new functions.
  • The relationship between the transaction IDs, the Db2® plans, and the programs can be changed without changing the programs. However, the control table must then be changed.
  • Information from the Db2 catalog (SYSPLAN and SYSDBRM) can be used to build the control table.
  • Alternatively, the control table can be used to generate information about the DBRM structure of the plans.
  • The control table contains information that can assist in defining the DB2ENTRYs and DB2TRANs in CICS,(if the plan name column is available).
  • Other functions can be included in a control table structure, for example, information about which transaction ID to use in the TRANSID option of the EXEC CICS RETURN command.
Disadvantages
The two major disadvantages to switching transaction IDs to switch plans are the costs of designing and developing the solution and the execution time overhead.

The cost of getting from program to program is approximately doubled. However, this should normally not correspond to more than a few percent increase in the processor time for the transaction. To decide whether or not to use such a solution, you should balance these disadvantages against the advantages.