Easytrieve with SQL statements calling a COBOL subroutine with SQL statements and two plans involved

Products

• Easytrieve Report Generator
• PAN/SQL

Issue/Introduction

May an Easytrieve program with SQL statements call a COBOL subroutine with SQL statements and have two plans involved?

 

 

Resolution

Often programs call other programs, which then call even more programs. The PACKAGEs for all of these programs may have been bound into the same COLLECTION or different COLLECTIONs. To tell our load module (Twin 1… in this case, the COBOL program) where to look for the PACKAGE (Twin 2), we give it a list of COLLECTIONs that it is allowed to search, by creating a PLAN.

To create the PLAN, we perform another BIND. This BIND (BIND PLAN) specifies the search chain. It lists each COLLECTION that is a possible location for the PACKAGE(s) that will be needed by our EXECUTE PROGRAM statement in our JCL. By providing this PLAN, we tell our COBOL load module exactly where to search for its PACKAGE. And at run time, at the first CALL to DB2, Twin 1 will search for Twin 2 in each COLLECTION named in the PLAN until it finds its twin—with the same name and the same “tattoo.” If it does not find its twin, the program will receive a -805 SQLCODE. A -805 means, “I searched for my twin in every COLLECTION that you gave me in the PLAN list, and I could not find him.” (ref: PLANS, COLLECTIONS & PACKAGES ). 

The PACKAGE should point to the COLLECTION and the PLAN should point to the PACKAGEs. I’m thinking that you may have bound your COBOL program to the same plan name as with your Easytrieve program without specifying multiple PACKAGES and that’s why EZT isn’t matching the COLLECTION. Also, since the COBOL pre-compiler produces the DBRM for the COBOL program (i.e. all the SQL EXEC statements), that object must also be linked into the object for the Easytrieve program as well as the object for its DBRM. 

The concise answer is not two different PLANS, but one PLAN must be used pointing to two different packages.