Cobol DYNAM subroutines - usage of DSNULI

Currently DB2's Universal Lanugage Interface (DSNULI) is useless for Option-DYNAM-compiled Cobol subroutines. Please make Cobol fully fit for DSNULI.

Local situation:

Many DB2-programs at our site are written in COBOL and are used in TSO/Batch, are used with CAF, in CICS and in DB2-stored procedures. We have many subprograms called by programs in all of our DB2-environments.

In general we compile our COBOL-main- and sub-programs with compiler option DYNAM, which has the effect, that called programs are fetched dynamically. This mechanism also applies to the called DB2-interface!

We have many ?central? subprograms, which are used equally in all of our DB2-Environments. Compiling such a subprogram and choosing a particular ATTACH-precompiler option, the DB2-interface is NOT correct for at least 2 DB2-environments. In our programs we use ATTACH(TSO), which means ? together with the COBOL-compiler-option DYNAM ? that DSNHLI is called dynamically. Using exact this subprogram in CAF (needs DSNALI) or in stored procedures (needs DSNRLI), a wrong DB2-interface is invoked. Please consider, that this problem arises only when using COBOL-option DYNAM, for statically called subprograms and linkedited loadmodules the relevant DB2-interface is supplied by including it or DSNULI at first in the loadmodul.

Potential, available but unsatisfying solutions:

1.) To precompile+compile one and the same subprogram several times for each DB2-environment, where it is needed (arises redundancy and more complex source- and program-management)

2.) To go out of using cobol option DYNAM, so that the calls become static and the subprograms incl. DB2-stubs are included into the loadmodule. This would result in much more complex and error-prone source- and program-management.

Local solution:

We continue to use COBOL compiler option DYNAM, exploiting its benefits.

a) For CAF-mainprograms we load at program-start DSNALI, IDENTifying it as DSNHLI, so that any dynamic call to DSNHLI results in DSNALI being invoked.

b) For stored procedures we prepared a dynamically callable loadmodul named DSNHLI, which dynamically calls DSNHLIR using the same parameters.

Business value of the requested enhancement:

- Transparency in the program source: It becomes visible, that the subprogram might be used in different DB2-environments.

- ?Un-kludge?: It's an official supported feature of the product and avoids bending? of modul-names like in "local solution".

- Usability: It can be used for static and dynamic calls and loadmoduls

- Consistent concept: Dynamic calling of subprograms (faciliated by COBOL option DYNAM) corresponds to the DB2-concept of dynamic package-lists in the DB2-Plan. (In contrast to static Plans + static loadmodules in the past)