Specifying the MAINPACK (example)

The following example shows how you can define different MAINPACK specifications for different plans. In this example, different MAINPACK specifications for plans DISTSERV and CICSA are defined.

DISTSERV is used as the plan name for all DBATs initiated by non-DB2 requesters. Therefore it can be useful to be able to distinguish between the different DISTSERV plans according to the packages they contain.

The plan CICSA is a large plan consisting of several packages and it is used for many different kinds of transactions. The goal is to distinguish between the different executions of this plan.

The following figure shows the MAINPACK Definition Member Editor panel with the specifications.

Figure 1. Defining the MAINPACK


 DGOPPMDS            MAINPACK Definition Member Editor          Row 1 to 3 of 3

 Select one of the following MAINPACK definition codes for each
 specified combination of Requesting Location, Connection ID and
 Plan Name. Request EXIT when complete.

  Code      Description
   1        Package    ID of the first executed package
   2        Package    ID of the last executed package
   3        Collection ID of the first executed package
   4        Collection ID of the last executed package
   5        Location   of the first executed package
   6        Location   of the last executed package

 Action  Requesting Location  Connection ID  Plan Name  Code
 ____    *                    *              *          4
 ____    *                    *              DISTSERV   1
 ____    *                    *              CICSA      2
 ******************************* Bottom of data ********************************




 Command ===> ______________________________________________________________
  F1=Help    F2=Split   F3=Exit    F7=Up      F8=Down    F9=Swap   F12=Cancel

In this case, the default entry is for packages that do not have a specific entry. For these plans, the collection ID of the last executed package is used as the MAINPACK.

For plan DISTSERV, the representative package was defined as the first executed package in this example. This was done because it is likely that for the DBATs initiated by non-DB2 requesters the first package usually provides the necessary information to identify the plan. The assumption for this plan was that the package identifier was the most convenient identifier value.

For plan CICSA, the representative package was defined as the last executed package. The reason for doing this was that for this particular plan, in this example, the last executed package best identifies the transaction. The package ID was used as the value of the identifier.