Step 1 - how does DB2 identify the correct package?
In the precompile SQL statements are removed (well commented out)
the statement requires DB2 processing, a call to DSNHLI is
parms to the DSNHLI call are generally called a PLIST. The mapping
a PLIST is SDSNMACS(DSNXRDI). Part of the Plist is
1. the member name for the DBRM
2. the CONTOKEN value (connection token) which is a 8 byte unique
is generated at the time of the precompile. Yes, it is derived from
format but that really doesn't matter.
NOTE - the VERSION is generated at the same time but it is only
the DBRM. The PLIST doesn't know or care about versioning.
So, at run time, DB2
1. already knows the plan name - that has to be specified for
2. has the DBRM name and the contoken value from the PLIST.
3. searches the package list for that combination.
Now, for my options 1 and 2, the precompile only happened one time.
means there is only one value for CONTOKEN. That means versioning
Option 3 involves 2 precompiles, once in the CICS style link edit
the end and the other with IMS link edit coming out the back. Now
two CONTOKEN values and to implement both load modules, you will
have to use
And, yes some of us have spent way to much time debugging DB2
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Jim
Sent: Tuesday, January 18, 2011 8:27 AM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 for z/OS V8 - package name
On Tue, Jan 18, 2011 at 1:49 PM, Mike Bell
<[login to unmask email]> wrote:
Cutting out the previous messae - short answers
1. yes, it can be done
2. no, it does not require versioning
3. yes, it does require custome link-edit process
4. depending on you source management tool, you may have to
The basic issue is the version of DSNHLI that is included in the
1. convert all the calls to dynamic calls and make sure that
DSNHLI is first for the correct implementation. This will let
same load module for all environments.
2. link edit the program two times - once into the CICS library
(for the DSNHLI entry point) and another into the IMS library
(for the IMS DSNHLI entry point). You now have 2 copies of the
module and you have to remember to change both of them.
3. compile the same source two times (once as CICS and another
hope the load module ends up in the correct places. This would
versioning because each load module will have a different
4. Create a 'magic' DSNHLI stub that will look around, decide if
running in CICS or IMS and then call the correct DSNHLI entry
seen this debated at several companies but I never participated
There is no standard IBM documented call that will tell you
you are running in.
Note, options 2 and 3 will NOT make you a favored son of any
management group. Either they will have to create a new
supports splitting copies of a load module into mulitple
source management tool will never have full and complete
rebuild a module. This is a very old topic. I haven't seen it
it looks like new people are running into old limitations.
Mike, I don't have a problem with the CICS/IMS bits. I can compile
link both programs to their respective loadlibs with the necessary
bits included, no problem. The only problem I have is being able
identify the 2 different packages to the DB2 subsystem which is the
Independent, not-for-profit, User Run - the IDUG difference!
The IDUG DB2-L Listserv is only part of your membership in IDUG. If
not already an IDUG member, please register here.
* IDUG North America * Anaheim, California * May 2-6 2011 *
* Your only source for independent, unbiased, and trusted DB2
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's Listserv