DSNULI Module is a Time-Saver

Applications running on z/OS communicate to DB2 through an attachment facility. Attachment facilities communicate through a language interface. When developing your application, you must select a supported attachment facility to connect with. The options are abundant:

• The time-sharing option (TSO) attachment facility uses the DSNELI language interface. Use this facility in a TSO or batch environment to communicate to a local DB2. The TSO facility is executed through the DSN command processor.
• The CICS attachment facility uses the DSNCLI language interface. Use this facility when accessing DB2 from a CICS environment.
• The IMS attachment facility uses the DFSLI00 language interface. Use this facility to access DB2 from an IMS environment.
• The call attach facility (CAF) uses the DSNALI attachment. Use this facility in a TSO or batch environment as an alternative to TSO attachment facility when your program needs tight control over the session environment.
• The Resource Recovery Service (RRS) uses the RRSAF attachment facility. Use this facility for stored procedures that run in a WLM-established address space or as an alternative to CAF. RRSAF provides support for z/OS RRS as the recovery coordinator and supports other capabilities not present in CAF.

To build an executable program, first precompile to convert the SQL statements to native statements within your program language (e.g., COBOL or Assembler). Next, compile then link-edit into an executable program, also known as a load module.

The link-edit process is where you must decide what environment the program will execute in: CICS, TSO batch or a stored procedure. This poses a challenge to application developers, because once the link-edit step is complete, the load module can only be executed in that given environment. If you want to deliver your application with a one load module library, you must make copies of the application and change the name to represent the environment the program will run in. For example, I may have PYR100T, which is linked with the TSO attach, and PYR100C, which is linked with CICS. Another option is to have one name, such as PYR100, and run multiple link-edit steps pointing to a different load library named for the given environment. For example when link-edit is for TSO, store the load module in PROD.TSO.LOADLIB; when executing in CICS, use PROD.CICS.LOADLIB. I prefer the latter option--that way I simply add multiple link-edit steps to generate the module in each library.

DB2 10 for z/OS introduces a universal language interface module (DSNULI) that can be used  during the link-edit step instead of DSNRLI, DSNALI, DSNELI or DSNCLI. With DSNULI, you can basically link-edit once and apply the changes to all your environments. It can be used with RRS, CAF, TSO and CICS applications, including stored procedures that use RRS. (However, DSNULI doesn't support dynamic loading or IMS applications.) DSNULI determines the runtime environment needed, and then dynamically loads and branches to the appropriate language interface module (DSNRLI, DSNALI, DSNELI, DSNCLI).

To learn more about application preparation and the use of DSNULI see, "DB2 10 for z/OS Application Programming and SQL Guide."

Are you using DSNULI language interface? It would be good to hear about your experiences with it.