Common modules are becoming, well, more common. These are generic modules that perform a certain function that can be called from a variety of applications. One example might be a module that retrieves name and address information for a customer. This module may be called from the customer support application, the accounts receivable application, or from a Web interface. This module may be executed from one of several online, batch, or distributed execution environments.

Typically, to use this module in these different execution environments requires a link to a different DB2 attach module. This requires additional maintenance when the module has to be modified and perhaps even the creation of separate copies of the module. In addition, what if you don’t know whether the caller of the module has already established a DB2 connection for the environment under which they’re operating? The generic attach technique liberates the developer from this burden by letting the module use DB2 services, in any execution environment, without linking to a specific attach module and without necessarily having to explicitly connect.

Generic Development

Generic development involves the creation of various modules to serve specific business functions. This could be retrieving data from a table, sending a message, or performing some sort of calculation. This type of development has become more prominent as more applications are being developed in DB2, and many applications are being migrated from legacy systems into DB2.

Once these generic modules are created, everyone wants to use them because they speed up the development process. They would like to use these modules wherever they’re executing. However, what if the site’s application isn’t using DB2? What if they don’t know if the business functionality module they want uses DB2? For these reasons, companies taking this approach find themselves challenged with providing the flexibility of the reusable modules while minimizing the maintenance involved with managing the modules in multiple environments (see Figure 1).

Execution Environments on z/OS

If we’re creating generic reusable modules, they must be flexible; the modules must be accessible from several execution environments, including:

  • TSO (online and batch)
  • Batch
  • CICS
  • Stored procedures.

The development team should seek to make these modules easy to use, and flexible enough to automatically adapt to each environment.

IBM provides an attachment program for DB2. The attachment program is actually a collection of various attachment load modules—each specific to a particular execution environment. Traditionally, programs would statically link the DB2 attachment load module specific to their execution environment into their program’s load module.

4 Pages