Link-editing an application with DSNULI
To create a single load module that can be used in more than one attachment environment, you can link-edit your program or stored procedure with the Universal Language Interface module (DSNULI) instead of with one of the environment-specific language interface modules (DSNELI, DSNALI, DSNRLI, DSNCLI, or DFSLI000).
About this task
DSNULI should be link-edited with TSO, CAF, RRSAF applications (including Stored Procedures), CICS® applications and IMS applications. DSNULI determines the run time environment, then dynamically loads and branches to the appropriate language interface module (DSNELI, DSNALI, DSNRLI, DSNCLI, or DFSLI000).
The following considerations apply:
- If maximum performance is the primary requirement, link-edit with DSNELI, DSNALI, DSNRLI, DSNCLI, or DFSLI000 rather than DSNULI. If maintaining a single copy of a load module is the primary requirement, link-edit with DSNULI.
- If CAF implicit connect functionality is required, link-edit your application with DSNALI instead of with DSNULI. DSNULI defaults to RRSAF implicit connections if an attachment environment has not been established upon entry to DSNHLI. Attachment environments are established by calling DSNRLI or DSNALI initially, or by running an SQL application under the TSO command processor or under CICS or IMS.
- DSNULI will not explicitly delete the loaded DSNELI, DSNALI, DSNRLI or DSNCLI. If an application cannot tolerate having these modules deleted only at task termination, use DSNELI, DSNALI, DSNRLI or DSNCLI instead of DSNULI.
- DSNULI is shipped with the linkage attributes AMODE(31) and RMODE(ANY) and must be entered in AMODE(31).
Procedure
To link-edit an application with DSNULI:
You can include DSNULI when you link-edit your load module. For example, you can use a linkage editor control statement like this in your JCL:
INCLUDE SYSLIB(DSNULI)