The DB2 Precompiler splits the program into two parts: a COBOL and a DB2 part. The embedded SQL is stripped out of the program and put into a partitioned data set (PDS) member, called a DBRM. Just as the COBOL part has to be compiled, the DBRM part has to go through BIND process to create the run-time executable code for the DB2 portion of the COBOL program. To help the COBOL and DB2 part to find each other later at run time, the precompiler engraves each with identical timestamps called consistency tokens.
You can BIND the DBRM into a PLAN (the old way), or you can BIND the instructions into a PACKAGE.
A PLAN is an executable module containing the access path logic produced by the DB2 optimizer. The DBRMs of more than one program or PACKAGES can be bound into a PLAN.
A PACKAGE is a single, bound DBRM with optimized access paths. The DBRM of a single program is bound into a PACKAGE. To execute a PACKAGE, it should be included in the package list of a PLAN. PACKAGEs are not directly executed, they are only indirectly executed when the PLAN in which they are contained executes.
The relationship between a DBRM and a PLAN is one-to-many, the relationship between a DBRM and a PACKAGE is always one-to-one.
As the number of DBRMs bound to a PLAN increases, binding the DBRM into a PLAN is not recommended. If we need to precompile and bind a new program or one of the programs changes and it is to be precompiled and bound again, all the programs (not just the modified/added program) will be rebound into the PLAN again. Then the BIND process could take hours to complete.
On the other hand, if a DBRM is bound to a PACKAGE and if the program is modified, only that PACKAGE would have to be rebound.
A collection is simply a way of grouping PACKAGEs into meaningful groups. You could use COLLECTIONs to separate programs for different application areas, such as payroll and inventory. Another use might be to have customized set of BIND parameters associated with different COLLECTIONs.
At run time, the load module starts up and eventually hits a paragraph containing a CALL to DB2. Then the COLLECTIONs named in the PLAN are searched for the PACKAGE with the same name and consistency token. If you don't find it anywhere in DB2, you get an -805 error. If you're using the older technique of binding DBRMs directly into PLANs, then an unsuccessful search will result in an -818 error code.