DB2 Attach and the Risks for Generic Modules

To interface with DB2, programs must be processed by the DB2 pre-compiler. The pre-compiler translates DB2 SQL calls into calls to particular subprograms. The subprogram being called, otherwise known as the attach module, is controlled by a pre-compiler option called ATTACH. IBM provides different attach modules for each execution environment:

  • DSNELI for TSO
  • DSNALI for call attach
  • DSNRLI for Recovery Resource Services (RRS) attach.

For example, if ATTACH(TSO) is specified as a pre-compiler option, then all SQL calls will be translated by the pre-compiler into subprogram calls to program DSNELI. When the programmer link-edits the program, the DSNELI module is included in the load module, and all calls to it are static. Likewise, if ATTACH(CICS) is specified, then calls are made to module DSNCLI, and so on. This is why you need different load modules for different execution environments, and why developers have to maintain separate libraries for their programs that are common modules called in several execution environments. They need one version for TSO, one for CICS, or for stored procedures (RRS), and so on.

Usually, this presents problems in the area of change management. These problems revolve around the automation and approval process for programs moving from one environment to another. Sometimes, the tools and approvals can be attached only to one load module. Sometimes, the load module has to be attached to source code in the change management tool. In these cases, the developers are forced to manage multiple copies of the source programs and load modules. These multiple program copies can lead to incomplete or mismatched deployments and possibly unstable systems.

If no ATTACH option is specified for the pre-compiler, then something else happens.

Generic Attach

When no ATTACH pre-compiler option is specified, the pre-compiler will substitute the SQL calls in the program with calls to a generic module named DSNHLI. This is the generic attachment call. By default, the DSNHLI module is a replica of the DSNELI TSO attach module. However, all the attach modules have a DSNHLI entry point, so all the generic calls will work for any of the attach modules statically linked into the target load module.

It’s possible to not include the appropriate attach module at link-edit time; instead, you can call it dynamically. This technique is useful when a particular program that accesses DB2 tables needs to be called from several execution environments. If the appropriate attach module is available in the load library accessed in each execution environment, then a generic dynamic call to DSNHLI will pick it up. The trick is to name each specific attach module DSNHLI in a load library specific to each environment. This generic attach technique is described in the IBM Redbook DB2 for z/OS Stored Procedures: Through the Call and Beyond (SG24- 7083-00) and requires these steps:

  1. Don’t specify the ATTACH option for the DB2 pre-compiler.
  2. Allow for dynamic calls from the user program. This can be done by including the “PROCESS DYNAM” keywords at the beginning of a COBOL program, or via specifying the DYNAM COBOL compiler option.
  3. Don’t include a DB2 attach module during link-edit.
  4. Link-edit the attach module for the appropriate execution environment into its own special load library, and rename it DSNHLI.
  5. Concatenate the special load library ahead of the SDSNLOAD library at execution time.

If you do these things properly and specifically to the various execution environments, then the generic attach calls will execute the appropriate environment attach module.

This is beneficial because only one user program load module is then required for multiple execution environments. Moreover, only one user program load library is required for any execution environment that needs its services.

4 Pages