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 on page ***). 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 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.
When the database manager has been started in multiple user mode, the user machine should have IPLed CMS and been initialized for DB2 Server for VM processing (by the SQLINIT EXEC).
If the program has any input or output files, file definitions may be required. The CMS FILEDEF command is described in the VM/ESA: CMS Command Reference manual.
In addition, if your application was compiled using a Language Environment Compiler, the Language Environment must be available at runtime for your application to use the dynamic library routines. One way to do this is by including SCEERUN LOADLIB on the GLOBAL LOADLIB list. For more information, see the compiler documentation.
If a module was created, you can execute the program by specifying the name of the module followed by any user program parameters. For example, the following command starts assembler program SAMPLE1 in multiple user mode, and passes the user parameters directly to the program:
SAMPLE1 parm1 parm2 |
If a module was not created, you can execute the program by first specifying the CMS LOAD command, as described in the previous section, and then the CMS START command. For example, to execute the program SAMPLE1, enter:
LOAD SAMPLE1 ARIRVSTC START SAMP parm1 parm2 |
where:
When parameters are passed on the START command, the requirements of both CMS and the language of the application program must be met. See the VM/ESA: CMS Command Reference manual, for a description of the CMS START command and the appropriate language guide or reference manuals for details on how to pass parameters.
Single user mode application programs are programs that run in the same machine as the DB2 Server for VM code and that are under the control of the database manager. In this case, the user machine and the database machine are the same.
Single user mode programs are invoked by starting the application server with the SQLSTART EXEC. (Before invoking the system, you must enter IPL CMS.) You must specify both the mode (SYSMODE=S) and your program name (PROGNAME=name) when you enter the SQLSTART EXEC.
When SQLSTART is invoked, the systems loads the program (identified by the PROGNAME parameter) and passes control to it after the system is initialized. For single user mode, the module must be available.
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 system and pass them on to you.
The following is an example of the SQLSTART EXEC for invoking programs in single user mode with no user parameters:
SQLSTART DB(SQLDBA) PARM(SYSMODE=S,LOGMODE=A,DUMPTYPE=N,PROGNAME=SAMPLE1) |
| Note: | If your program or the database manager ends abnormally, you may receive a minidump (depending on what initialization parameters were specified). Mini-dumps are described in the DB2 Server for VSE & VM Diagnosis Guide and Reference manual. |
When starting the database manager in single user mode, you can also specify user parameters to be passed to your application program using the PARM keyword of the SQLSTART EXEC. The SQLSTART EXEC purges the CMS program and console stacks. Thus, any program run in single user mode cannot rely on console or program stack input.
Place a slash (/) between the initialization parameters and the user parameters. For example:
SQLSTART DB(SQLDBA)
PARM(SYSMODE=S,LOGMODE=A,DUMPTYPE=N,PROGNAME=SAMPLE1/parm1,parm2)
| Note: | Only the first 130 characters of the command line are read by CMS. The exception to this rule occurs when SQLSTART is called from a user-written EXEC; then CMS reads the first 256 characters. If you specify many initialization parameters and user parameters, they will not fit on the command line. Thus, you must use a CMS file for some of the parameters. Because user parameters cannot be specified in a CMS file, you should specify the initialization parameters in the CMS file, and the user parameters on the command line. |
A program written in C, PL/I, COBOL or FORTRAN requires an interface routine to process the user parameters.