Important tables in CICS

PPT - Processing Program Table
                Define application programs and BMS maps in this table. We define program names in this table to make CICS to identify programs.

PCT - Program Control Table
                Define TransactionID (1 to 4 characters) eg: "A054" for main program which executes input data comming from front end or other source. Here we give program name and corresponding TransactionID by which this program can get executed.
When user enters TransID on the terminal, CICS checks this table to get the corresponding program to be executed.

FCT - File Control Table
               Define files used in the CICS program.
All the files being used in our programs needs to be registered in this table.

TST - Temporary Storage Table
               Define TSQ's used in CICS program.

DCT - Destination Control Table
               Define TDQ's used in CICS program.

RCT - Resource Control Table
               Define DB2 plan details that are created during the compile and execution of the source program.

Difference between Plan & Package

Difference between Plan & Package
Both contain optimized code for SQL statements - a package for a single program, module or subroutine contained in the data base request module (DBRM) library. A plan may contain multiple packages and pointers to packages.
A plan is an executable module containing the access path logic produced by the DB2 optimizer. It can be composed of one or more DBRMs and packages. Before a DB2 for Z\OS program(with static SQL) can be run, it must have a plan associated with it.
Plans are created by the BIND command. The plan is stored in the DB2 directory and accessed when its program is run. Information about the plan is stored in the DB2 catalog.
A package is a single, bound DBRM with optimized access paths. By using packages, the table access logic is "packed" at a lower level of granularity than a plan--at the package(or program) level.
To execute a package, you first must include it in the package list of a plan. Packages are not directly executed, they are only indirectly executed when the plan in which they are contained executes--as discussed previously, UDFs and triggers are execeptions to this rule. A plan can consist of one or more DBRMs, one or more packages or, a combination of packages and DBRMs.

COBOL-DB2 compilation process

Step 1- DB2 PRECOMPILE

The DB2 Precompile performs three functions.

• It checks the SQL in the program for errors.
• It adds working storage areas and source code compatible statements that are used to invoke DB2. One of the working storage areas contains a literal "timestamp" called a consistency token.
• Finally, all the SQL statements are extracted from the program source and places into a member called the DataBase Request Module(DBRM), which also contains the consistency token.

Step 2- COMPILE

The modified source from the precompile is then compiled. The code is checked for errors, and a compiled version of the code is created.

Step 3- LINK-EDIT

The compiled code is link-edited along with statically called source language and DB2 run-time modules to create a Load Module. Imbedded in this module is the same consistency token that was generated in the precompile. If multiple DB2 module contains a consistency token for each one.

Step 4- DB2 BIND

The bind process reads the DBRM that was created in the precompile and prepares an access path to the data. This access path, along with the consistency token is stored in the DB2 catalog as a package. Every package is bound into a package List, or a collection. The name of the Collection is specified by the PACKAGE parameter. A collection is a group of packages that are included in one or more plans. The QUALIFIER parameter of the bind is used to direct the SQL to the specific set of DB2 objects(tables, Views, aliases or synonyms) qualified by this name.

EXECUTION COBOL-DB2 PROGRAM

When COBOL-DB2 program executes, the plan name must be specified. For online CICS programs, the plan name is specified  by Tran ID in the Resource Control Table(RCT). For a batch program, the plan name is specified in the SYSTSIN input DD. The packages for all DB2 programs executed under a Tran ID or batch job step must be included in collection bound into this plan. When the first SQL statement of each program is executed, DB2 searches the collections within the plan using the package name and consistency token from the load module. If an exact match is not found a -805 SQLCODE is returned.