Consistency tokens ensure that a program's load module and the database package are used together. When preprocessing, you can instruct the preprocessor to place a consistency token in both the load module and the package (see CTOKEN parameter ***. If the two tokens do not match, the application server prevents the program from running.
| Note: | If you inadvertently forget to compile or link-edit a new version of a program, you can run an old version of a program with a new version of the package. Conversely, with multiple application servers, you can inadvertently run a new version of a program with an old version of the package. In either situation, you will probably get program errors or incorrect results if you have not used consistency tokens. |
The package that the preprocessors or CBND stored carries out the SQL request. When the application server loads the package, it checks that the package is still valid. A package may not be valid if one of its dependencies has been dropped. For example, some index that the package uses may have been dropped.
Packages are also invalidated when primary keys and referential constraints are added to, dropped from, activated, or deactivated on tables that the modules depend on. The following rules apply:
The system has an internal change management facility that keeps track of whether packages are valid or not. If a package is valid, the system begins running the program; if the package is not valid, the system tries to re-create it. The original SQL statements are stored with the package when you preprocess the program. The system uses them to automatically bind the program again. It does this dynamically (that is, while it is running). If the rebinding works, a new package is created and stored in the database and the system then continues execution of the program. If the rebinding does not work, an error code is returned to the program in the SQLCA, and the program stops running.
A successful rebinding has no negative effect on your program except for a slight delay in processing your first SQL statement. To minimize this delay, you can use the DBSU REBIND PACKAGE command to rebind the invalid package after it has been invalidated, but before it is executed. See the DB2 Server for VSE & VM Database Services Utility manual for information on this command.
The job control for multiple user mode executes the application program; the application server must already be initialized. The application program communicates with the application server, which resides in a separate partition, through the DB2 Server for VSE linkage module (ARIPRDID or ARIRRTED). The linkage module is given control for each SQL statement in the application program.
You can invoke the application with standard job control statements or CICS/VSE procedures. It is recommended that you specify SIZE=AUTO. (Specify SIZE=750K for PL/I programs.) Figure 50 shows job control for invoking programs in multiple user mode:
Figure 50. Invoking a User Program in Multiple User Mode
// JOB USER PROGRAM // EXEC PGM=MYPROG,SIZE=AUTO /* /& |
The job control for single user mode invokes the application server and passes to the system the name of the application to be run. The system then loads and invokes the application program. Once the single user mode application receives control, it accesses the application server in the same way as multiple user mode applications.
The system supports the VSE register save conventions. See the DB2 Server for VSE System Administration manual for more about single user mode execution using the VSE register save conventions.
The DB2 Server for VSE & VM Operation manual lists all the initialization parameters you can specify when you start the system in single user mode. A system programmer can also determine the best initialization parameters for your installation and pass them on to you.
Figure 51 shows job control for invoking programs in single user mode. The SIZE=AUTO specification is required. (Specify SIZE-AUTO, 750K for PL/I programs.)
Figure 51. Invoking a User Program in Multiple User Mode
// JOB SINGLE // EXEC PGM=ARISQLDS,SIZE=AUTO,PARM='SYSMODE=S,PROGNAME=name' /* /& |
If your program or the system abnormally ends, you may receive a mini-dump (depending on what initialization parameters were specified when the system was started). Mini-dumps are described in the DB2 Server for VSE System Administration manual.
DB2 Server for VSE-CICS/VSE support must be initialized before applications can be run as CICS/VSE transactions. Usually the CICS/VSE support is initialized when the system is started. Once the support is started, you can use normal CICS/VSE procedures to invoke transactions that use the system. See the DB2 Server for VSE System Administration manual for more information on starting and stopping CICS/VSE support.
If your VSE/ESA has been initialized as a VSE/ESA guest system under VM, your (multiple user mode) VSE application can access a DB2 Server for VM application server. Therefore, if the application was designed to run in single user mode it must be converted to multiple user mode. This conversion can be accomplished by modifying the job control language (JCL). See the DB2 Server for VSE System Administration manual for more information on VSE Guest Sharing.
Your online CICS/VSE application can also use the DRDA protocol to access other DB2 Family application servers, including DB2 Server for VM, DB2 Universal Database Server for OS/390, or DB2 Universal Database (UDB). Before doing this, the DRDA requester code must be installed on your VSE system. Also each DB2 Family server to be accessed must be defined to the DB2 Server for VSE online resource adapter as a remote application server. See the DB2 Server for VSE System Administration manual for more details on defining remote application servers.