DB2 subroutine called from IMS, CICS, and TSO Batch
Campbell, James A
>> programming. If a DB2 module will be called from different
>> environments (IMS, CICS, and TSO Batch), can the same DB2 object
>> module (compiled and link-edited) be used for each environment?
>> I understand how to compile and link-edited for each environment, but
>> would prefer not to manage three different load libraries for each
DB2
>> module.
>>
>> Thanks in advance,
>> James
Never done it, but in theory the following *might* work. (It's all totally
unsupported so even if it works now, it might not at some time in the
future.)
Essentially the user code calls the entry point 'DSNHLI' and each
environment has a different attach module (with a DSNHLI entry point) to
hook into the DB2 code appropriate to the environment.
The first possible method would be to write two modules to intercept this
function.
Module 1 would have the DSNHLI entry point and be linked into the
application programs. When it's invoked (i.e. the program is executing some
SQL), it would determine the environment (CICS, TSO or IMS depending on the
what else is in the address space) and dynamically call (i.e. load and call)
an appropriate version of module 2.
Each environment would have its own version of module 2. It would be linked
with the appropriate attach module. So when it's invoked, it does a static
call to DSNHLI and thus invoke DB2's attachment.
An alternative method might be to copy DSNCLI (CICS attach) and DFSLI000
(IMS attach) into other libraries and create the DSNHLI alias on them. (In
the standard product its DSNELI (TSO attach) which has the alias.) Use an
appropriate set of STEPLIB libraries and a dynamic link to get the desired
attach module at execution time.
Good luck
James Campbell
Telstra Corporation
JCam...@VITGSYSA.TELECOM.com.au
+61 3 9295 4649
Paul Elliott
After reading the above, I thought about DB2 Stored Procedures in DB2
version 4. Usage of DB2 Stored procedures is not restricted to Distrubuted
applications, even though IBM promotes this feature as a Client/Server
enchancement. I think use of Stored Procedures will avoid messing around
with multiple versions of code for the same DB2 subroutine like this in
future as they access DB2 from the Stored Procedures Address Space (SPAS??)
via the Call Attach Facility (CAF). This means you can just prepare all your
DB2 data access modules as CAF applications.
I believe that DB2 Stored Procedures are going to be a very popular little
item. DB2 Stored Procedures would allow one to write an entire data access
layer (to DB2 or other data) completely independent of the application
environment (ie CICS, IMS, Batch, etc).
Has anybody out there thought about using DB2 Stored Procedures in this way?
Cheers,
Paul ....
______________________________________________________________________
Paul Elliott
Senior Consultant
ADC Consultants
Australia
Ph: +61 2 9955 9998
Fax: +61 2 9955 9707
Greg Hunt
In any case, there are a number of IBM products that use dynamic
linkage in order to avoid the problem of having to relink if DB2
development do something unfortunate to the linkage CSECT. The
simplest approach is to differentiate the environments based on
STEPLIB.
Be careful though because the linkage may not be implemented as only
one module - you may load and call something that subsequently loads
and calls something else (this is certainy the case with CAF). What
this means is that it is not entirely safe to use (for example) ISPF
LIBDEF to get the module into the JPA and then use LOAD to get the CDE
attached to your TCB when you have multiple tasks (such as you might
implicitly have with an ISPF application) because the load module
search order can be different in different tasks.
Send me a note if you want more detail on this.
Terry Doner
> We are providing a common DB2 data layer service for application
> programming. If a DB2 module will be called from different
> environments (IMS, CICS, and TSO Batch), can the same DB2 object
> module (compiled and link-edited) be used for each environment?
>
> James
Do it all the time. We do not link DSNHLI with the application code but call it
dynamically. In IMS, DSNHLI is an alias of DFSLI000. A similar alias exists for
CICS (do remember the name).
Terry Doner
Senior Systems Consultant
Toronto-Dominion Bank
Toronto, Ontario, Canada
voice: (416) 944-5227
fax : (416) 944-6288
email : don...@tdbank.ca