Attach Module Changes
Each attach module needs to be linked into its own library. Figure 3 shows an example of a link-edit for the CAF attach module.
For any run-time execution, the appropriate special attach library must be concatenated to the STEPLIB before SDSNLOAD. Figure 4 shows an example of the run-time STEPLIB for the CAF attach.
For CICS, the special load library for DSNCLI must be placed in the RPL DD allocation before SDSNLOAD. In addition, an entry must be made into the CICS Processing Program Table (PPT) for the programs named DSNADDR, DSNADDR2, and DSNHLI (which is the renamed DSNCLI). Also, keep in mind these modules will now be dynamically called, so you could take a performance hit (the price generally made for generic design).
Two IBM manuals refer to generic attach: the Application Programming manual (SC18-7415) and the Redbook, DB2 for z/OS Stored Procedures: Through the CALL and Beyond (SG24-7083-00). The application programming guide indicates that you need to write a stub program for CAF and RRSAF to properly pass the generic calls. It also indicates that the CICS attach module must be statically linked. These instructions are no longer valid. In the Redbook, the link-edit examples for the various attach modules are incorrect. Those examples are missing the entry point card.
Optional Database Connection
The concept of a generic module can be taken a step further. Suppose you need to provide a service module that uses DB2, but you’re not sure whether the systems requiring that service are connected to DB2. The module can perform an RRS or CAF attachment. If the caller has already attached to DB2 via CICS, TSO, or any other attach, then the attempt to open another connection will result in failure—with a reason code of X’00F30049’ (duplicate connection attempted). The program can tolerate this code and continue. No matter which environment is being used, the appropriate attach module is already in use and the generic attachment will simply use that module. Cool!
Managing common reusable modules can be a challenge, especially when they can be called from various execution environments. Typically, this means multiple copies of load modules and special considerations for change management. DB2 generic attach solves this problem by letting the program execute the DB2 calls in any environment from a process that may or may not have already connected to DB2. Once you get the compiler option changed, and the various attach modules linked into their special libraries, you’re good to go! Z