What are the execution results when non-SQL changes are made in a program without BIND?

Problem: The COBOL-DB2 program was changed to increase the length of the variable from PIC X(5) to PIC X(8). However, there are no changes to the program's SQL. What would happen if the program's plans/packages were not bound for these changes?

Solution

The variable length change from PIC X(5) to PIC X(8) is not a DB2 change, and the SQL statements in the program do not need to be modified. However, we still need to bind its plan/package, otherwise we will receive SQL error code -818 which states "The timestamp x generated by the precompiler in the loaded module is different from the binding timestamp y built from DBRM z ". p>

The reason for this SQL error is as follows - On every execution of a COBOL-DB2 program, the timestamps of the loaded module and package/DBRM are compared. If the length of the variable changes in the program (and no SQL changes) and is compiled, then the loaded module will have a newly generated timestamp, on the other hand if BIND is not executed, the loaded module will have a newly generated timestamp. Package/DBRM will have an old timestamp. When the program is executed, the JCL step calling the program fails with SQL error code -818.

If we have a COBOL-DB2 program whose SQL statements will never change in the future, we can precompile the program using option LEVEL. The following is an example of a BIND step using the LEVEL option.

Example

//BIND EXEC PGM=IKJEFT01
//STEPLIB DD DSN=DIS.TEST.LOADLIB,DISP=SHR
//SYSOUT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(TB3)
BIND PLAN(PLANA) -
PKLIST(PACKA) -
LEVEL -
ACQUIRE(ALLOCATE) -
ISOLATION (RS)
/*

The above is the detailed content of What are the execution results when non-SQL changes are made in a program without BIND?. For more information, please follow other related articles on the PHP Chinese website!