Modified source+Bind+Plans + DBRMS + Packages + Collections + Versions = Confusion

till now , we had done a PRECOMPILE to separate our COBOL program into twins: Arnold (that's Governor Arnold now) as the modified source code (the SQL commented out and DCLGENs now INCLUDEd) and Danny as the DBRM containing the SQL that used to be in the source code. The COBOL source code (without any SQL) was compiled into run-time executable instructions for the COBOL portion of the program; DBRM Danny (all the SQL that used to be in the source module) went through BIND to generate run-time instructions for the SQL in our COBOL program.

but some question still running in mind ...like how Arnold, over in the COBOL loadlib, will find his long-lost twin —  exactly what we were binding and where we would put it when we finished.


so ...study continue..

The Modified Source Code (Arnold)

At precompile time, when the SQL was stripped out of our program and moved into the DBRM (Danny) leaving only COBOL in the modified source code, you must have wondered how COBOL Arnold would ever find DB2 SQL Danny; in other words, how the COBOL would ever execute any SQL.

The explanation is simple. All of the executable SQL (and not all SQL is executable — a DECLARE CURSOR isn't, for example) in the COBOL program was replaced with a CALL statement (in our example, a COBOL CALL). The modified source code, complete with its calls to DB2 SQL Danny, was compiled and "linked" into a LOAD module. When this LOAD module is executed and hits a paragraph that once contained SQL (but now contains a CALL to Danny), there will be run-time executable code that knows how to link to a COBOL-DB2 interface module and connect to DB2, where it will find Danny and the run-time executable code for the SQL statement that previously had been in the paragraph.

Remember that we tattooed the twins? Well, this CALL contains the information DB2 needs to confirm not only that this LOAD MODULE is Arnold (complete with requisite tattoo), but also that it's the exact same Arnold that came out of the exact same precompile step as Danny. The CALL looks at the PLAN named in the execute statement of the job control language (JCL) and searches for the Danny out in DB2 with the same tattoo.

next post about  most important member of this function called  DBRM