MAINFRAME > Administrator > Systems Management

Converting to Packages

DB2 9 for z/OS necessitates package-based plans

DB2 9 for z/OS has deprecated the support of Database Request Module (DBRM)-based plans. Its installation guide notes the following: “A future release of DB2 might not handle plans that contain DBRMs. In preparation, ensure that all of your plans contain only package lists.” This means you shouldn’t build any new DBRM-based plans and you need to start planning for the conversion of existing plans to packages.

History of Package Availability and Use

The use of packages in a DB2 plan is nothing new, however many systems were built with DBRM-based plans before packages became available. IBM first introduced plans with packages in DB2 V2R3, which became generally available October 1991. IBM began delivering packages to solve several problems with DBRM-based plans.

The biggest problem was related to change management. If a program was changed, then it had to be recompiled–which produces a new DBRM and requires a rebind to every plan using that DBRM. This isn’t really a problem with batch programs, since most plans contained only one DBRM. The batch program name and DBRM name and plan name was usually the same. It became a big problem for CICS environments. If a CICS transaction was going to call any other CICS transaction, then that DBRM had to be included in the plan that was allocated for the initial transaction. This became a change management nightmare. If transaction TRN1 called TRN2 or TRN3 then DBRMs for TRN1 and TRN2 and TRN3 must be included in the TRN1plan. These three DBRMs must also be in plan TRN2 and in plan TRN3. When a change was made to any one of these DBRMs. a rebind had to occur for each plan. First you’d have to rebind plan TRN1 with all three DBRMs, then plan TRN2 and finally plan TRN3. This not only took a long time to process–especially if the PLAN had 20 or 30 DBRMs in it–but it also became error prone. For example, if a change was made to program TRN1, it required a rebind of TRN1, and as I mentioned above also to TRN2. However, you could easily forget to rebind plan TRN3, which can also call TRN1. Everything would work fine at first, but a few days later someone would try to call TRN1 from TRN3 and fail, because the DBRM in bound in TRN3 is not the most current DBRM.

Troy L. Coleman is an IBM-certified Certified database administrator, specializing in DB2 9 for z/OS and Linux, UNIX and Windows. Troy can be reached at

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Active Energy Manager Pulls Resources Together

Integration with InfraStruXure Centeral provides single management interface.

Amplifying Your Energy Efficiency

IBM BladeCenter and virtualization team up for greener data centers

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters