Choosing link list options

Before you run the SMP/E jobs to load the Db2 libraries, you can choose your link list options.

Procedure

To choose your link list options, complete the following steps:

Consider and choose your link list options based on the following information about the load module libraries:

prefix.SDSNLINK

Contains Db2 modules that are referred to as early (ERLY) code, which must reside in an APF-authorized library. You must place early code modules in the link list because they are loaded at subsystem initialization during IPL. In the link list, you can have only one level of the early code. That early code can be shared by multiple subsystems and releases of Db2. So, you must choose the level of early code that is appropriate for all subsystems that use the link list. If your system is at the prerequisite maintenance level, your Db2 11 early code is compatible with Db2 12. The Db2 12 early code is compatible with Db2 11. Start of change If you plan to run Db2 10 subsystems on the same LPAR as Db2 12, choose Db2 11 ERLY code. End of change

If you are migrating, maintenance to early code or an installation of new early code requires that you activate the early code, which can be done in a couple of ways:

Activate the early code by doing an IPL of z/OS®.
Another option to activate maintenance to early code is to issue the REFRESH Db2,EARLY command. If you use this command, the subsystem that is having its early code refreshed must be stopped when the command is issued.

To initialize a new Db2 subsystem, you can issue the z/OS SETSSI command, which executes the early code initialization routine and update the subsystem vector table (SSVT).

Schedule an IPL of z/OS before or during a migration to Db2 12. This IPL is necessary because changes that migration job DSNTIJMV makes in SYS1.PARMLIB are not recognized by z/OS until the next IPL. Alternatively, you can use the SETSSI, SETPROG APF, and SETPROG LNKLST commands to define the subsystem to z/OS until the next IPL. Changes that DSNTIJMV makes to the SYS1.PARMLIB might affect the following libraries:

New subsystem definitions in IEFSSNxx
New APF libraries in IEAAPFxx
New load module libraries in LNKLSTxx

prefix.SDSNLOAD

Is a main load module repository.
Can be shared by multiple subsystems at the same release level.
Allows only Db2 to modify code.
Holds default exit routines.
Is APF-authorized.
Must be a PDSE.

prefix.SDSNLOD2

Start of change A PDSE data set that contains DLLs for products and features such as IBM® Data Server Driver for JDBC and SQLJ, Db2 for z/OS ODBC, XML Toolkit for z/OS, and the HDFS_READ function. End of change

Db2 does not require that SDSNLOD2 is APF-authorized. However, if this data set is in a STEPLIB data set concatenation of an address space that does need APF authorization, SDSNLOD2 must also be APF-authorized.

prefix.SDSNEXIT

Holds the subsystem parameter module, DSNHDECP, and user-written exit routines.
Is modified by user.
Is APF-authorized.

Link list recommendation for IRLM

Adding the IRLM load module DXRRL183 to the link list is highly recommended so that IBM Support can help you diagnose and resolve potential problems. IRLM can operate without this load module. However, if the DXRRL183 load module is not in the link list, users cannot run CT TRACE commands to externally start and stop IRLM component traces, which are critical for diagnosing problems. To add DXRRL183 to the link list if it is not already there, you need to copy the module into a link-listed library. After you apply maintenance to IRLM that affects DXRRL183, remember to copy the updated module to the link list.

Integrated Cryptographic Services Facility link list requirement

If you plan to use encryption with your Db2 subsystem, you must include in the link list the Integrated Cryptographic Services Facility library that contains the SCSFMOD0 load module. The SQL statement SET ENCRYPTION PASSWORD and the following built-in functions require this support:

ENCRYPT
DECRYPT_BIT
DECRYPT_DB
DECRYPT_CHAR
GETHINT
HASH_MD5
HASH_SHA1
HASH_SHA256

Supporting one Db2 subsystem

You can choose among several methods of maintaining a single Db2 subsystem. The following steps describe what is probably the easier method for most sites:

Change the SMP/E procedure DSNALLOC to assign all load modules to prefix.SDSNLOAD. You can do so by changing the data set name for DDDEF (SDSNLINK) from prefix.SDSNLINK to prefix.SDSNLOAD.
Remove the allocation for prefix.SDSNLINK from the allocation job DSNALLOC.
Include prefix.SDSNLOAD (instead of prefix.SDSNLINK) in the LNKLSTxx member of SYS1.PARMLIB.

Supporting multiple Db2 subsystems

Supporting multiple subsystems can mean several things. You can have two or more Db2 subsystems at the same release and service level (for example, two Db2 12 subsystems). Create separate libraries for DSNHDECP and user-written exit routines of each Db2 subsystem.

You can also have two or more Db2 subsystems at the same release level, but at different service levels. For example, you can have a Db2 12 production subsystem and a Db2 12 test subsystem at different service levels. Alternately, you can have two Db2 subsystems at different release levels. For example, you can have a Db2 12 subsystem and a Db2 11 subsystem.

In either of these cases, you can use an INCLUDE statement in JCL or a started task to identify the necessary load modules.

The Db2 subsystem must use the appropriate release level of prefix.SDSNLOAD, but the application attachment code (for example, CICS®, CAF, or TSO attachment facilities) can use code that is either one release earlier or one later from prefix.SDSNLOAD. To use application attachment code from the earlier or later release, place the attachment code in a different STEPLIB data set from the STEPLIB data set that Db2 executes.