Performance implications of installation libraries
The performance of your system might be degraded by including modules in the libraries that are included in the link list and you might want to consider the strategies below. These general suggestions might not match the specific needs of your site.
Regardless of which attachment facilities you use, the modules in prefix.SDSNLINK must always be in the link list. Adding many modules to the libraries that are included in the link list can reduce system performance. However, adding only a few modules to the libraries requires additional STEPLIB or JOBLIB statements. Because these STEPLIB or JOBLIB statements must be searched before the link list is searched, this approach can also reduce system performance. The approach that produces the best performance for your site depends on the environment in which you use Db2.
If you run multiple Db2 subsystems on the same LPAR, but the Db2 subsystems are at different releases or service levels, the copy of prefix.SDSNLINK in the link list must have the PTFs to support compatibility of those releases or service levels. If you also include a copy of prefix.SDSNLOAD in the link list for use by Db2 programs, prefix.SDSNLOAD must also have the PTFs to support compatibility of those releases or service levels.
- Include prefix.SDSNLINK, but not prefix.SDSNLOAD, in the link list. Place the needed STEPLIB or JOBLIB statements in the IMS procedures. This is the simpler solution because the IMS RESLIB and prefix.SDSNLOAD have the DSNHLI alias.
- If you want to include prefix.SDSNLOAD as well as prefix.SDSNLINK in the link list, you need to ensure that the library concatenation for prefix.SDSNLOAD and the IMS RESLIB are correct for your site.
If you are using Db2 with CICS®, put prefix.SDSNLINK in the link list, but do not put prefix.SDSNLOAD in the link list. Place the needed STEPLIB or JOBLIB statements in the CICS procedures.
If you use the TSO attachment facility, RRS attachment facility, or call attachment facility, you might need to handle placement of load modules somewhat differently, as follows:
- If you use the DSN command and its subcommands infrequently, place only prefix.SDSNLINK in the link list. Provide the necessary STEPLIB or JOBLIB statements in your in your JCL if you are using batch, or in your TSO logon procedures.
- If you use the DSN command and its subcommands frequently, move the TSO attachment facility load modules (DSNECP00, DSNECP10, DSNESM00, and DSNELI.) to a library that is defined in the link list.
- If you use the call attachment facility (CAF) frequently, move the CAF load modules (DSNACAB, DSNACAF, and DSNALI) to a library that is defined in the link list.
- If you use the RRS attachment facility (RRSAF) frequently, move the RRSAF load modules (DSNARRS and DSNRLI) to a library that is defined in the link list.
- If you use the CAF, RRSAF, and the DSN command and its subcommands frequently, you might improve performance by moving the eligible load modules to a library that is defined in the link pack area (LPA).
- The TSO load modules that you can place in the LPA are DSNECP00, DSNECP10, DSNESM00, and DSNELI. If you include these modules in the LPA, you also need to include the appropriate aliases for DSNECP00 (DSN) and DSNELI (DSNHLI).
- The CAF load modules that you can place in the LPA are DSNACAF and DSNALI. If you include these modules in the LPA, you also need to include the appropriate aliases for DSNALI (DSNHLI2 and DSNWLI2). Do not include DSNACAB in the LPA because it is a data-area-only, non-executable load module.
- The RRSAF load modules that you can place in the LPA are DSNARRS and DSNRLI. If you include these modules in the LPA, you also need to include the appropriate aliases for DSNRLI (DSNHLIR and DSNWLIR).
Tip: Placing the DSNULI load module in the LPA is not recommended. You should link-edit DSNULI with your applications.