Explain the steps for db2-cobol's execution process if both are db2 -cobol programs

How to run two sub programs from a main program if both are db2-cobol programs?

My main program named 'Mainpgm1', which is calling my subprograms named 'subpgm1' and 'subpgm2' which are a called programs and I preferred static call only.

Actually, I am now using a statement called package instead of a plan and one mem开发者_如何转开发ber, both in 'db2bind'(bind program) along with one dbrmlib which is having a dsn name.

The main problem is that What are the changes affected in 'db2bind' while I am binding both the db2-cobol programs.

Similarly, in the 'DB2RUN'(run program) too.

Each program (or subprogram) that contains SQL needs to be pre-processed to create a DBRM. The DBRM is then bound into a PLAN that is accessed by a LOAD module at run time to obtain the correct DB/2 access paths for the SQL statements it contains.

You have gone from having all of your SQL in one program to several sub-programs. The basic process remains the same - you need a PLAN to run the program.

DBA's often suggest that if you have several sub-programs containing SQL that you create PACKAGES for them and then bind the PACKAGES into a PLAN. What was once a one step process is now two:

• Bind DBRM into a PACKAGE
• Bind PACKAGES into a PLAN

What is the big deal with PACKAGES?

Suppose you have 50 sub-programs containing SQL. If you create a DBRM for each of them and then bind all 50 into a PLAN, as a single operation, it is going to take a lot of resources to build the PLAN because every SQL statement in every program needs to be analyzed and access paths created for them. This isn't so bad when all 50 sub-programs are new or have been changed. However, if you have a relatively stable system and want to change 1 sub-program you end up reBINDing all 50 DBRMS to create the PLAN - even though 49 of the 50 have not changed and will end up using exactly the same access paths. This isn't a very good apporach. It is analagous to compiling all 50 sub-programs every time you make a change to any one of them.

However, if you create a PACKAGE for each sub-program, the PACKAGE is what takes the real work to build. It contains all the access paths for its associated DBRM. Now if you change just 1 sub-program you only have to rebuild its PACKAGE by rebinding a single DBRM into the PACKAGE collection and then reBIND the PLAN. However, binding a set of PACKAGES (collection) into a PLAN is a whole lot less resource intensive than binding all the DBRM's in the system.

Once you have a PLAN containing all of the access paths used in your program, just use it. It doesn't matter if the SQL being executed is from subprogram1 or subprogram2. As long as you have associated the PLAN to the LOAD that is being run it should all work out.

Every installation has its own naming conventions and standards for setting up PACKAGES, COLLECTIONS and PLANS. You should review these with your Data Base Administrator before going much further.

Here is some background information concerning program preperation in a DB/2 environment: Developing your Application