Frage: Das COBOL-DB2-Programm wurde geändert, um die Länge der Variablen von PIC X(5) auf PIC X(8) zu erhöhen. Es gibt jedoch keine Änderungen am SQL des Programms. Was würde passieren, wenn die Pläne/Pakete des Programms nicht an diese Änderungen gebunden wären?
Die Änderung der Variablenlänge von PIC X(5) zu PIC X(8) ist keine DB2-Änderung und die SQL-Anweisungen im Programm müssen nicht geändert werden. Allerdings müssen wir seinen Plan/sein Paket noch binden, andernfalls erhalten wir den SQL-Fehlercode -818, der besagt: „Der vom Precompiler im geladenen Modul generierte Zeitstempel x unterscheidet sich vom aus DBRM z erstellten Bindungszeitstempel y.“ p>
Der Grund für diesen SQL-Fehler ist wie folgt: Bei jeder Ausführung eines COBOL-DB2-Programms werden die Zeitstempel der geladenen Module und Pakete/DBRM verglichen. Wenn sich die Länge der Variablen im Programm ändert (und keine SQL-Änderungen) und kompiliert wird, erhält das geladene Modul einen neu generierten Zeitstempel. Wenn BIND hingegen nicht ausgeführt wird, erhält das geladene Modul einen neu generierten Zeitstempel . Paket/DBRM wird einen alten Zeitstempel haben. Wenn das Programm ausgeführt wird, schlägt der JCL-Schritt, der das Programm aufruft, mit dem SQL-Fehlercode -818 fehl.
Wenn wir ein COBOL-DB2-Programm haben, dessen SQL-Anweisungen sich in Zukunft nie ändern werden, können wir das Programm mit der Option LEVEL vorkompilieren. Das Folgende ist ein Beispiel für einen BIND-Schritt mit der LEVEL-Option.
//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) /*
Das obige ist der detaillierte Inhalt vonWas sind die Ausführungsergebnisse, wenn in einem Programm ohne BIND Nicht-SQL-Änderungen vorgenommen werden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!