ICSF system resource planning for the CKDS

Like the PKDS and TKDS, ICSF manages a mirror copy of the CKDS data set in protected, private virtual storage to optimize cryptographic workload access to symmetric keys in the normal course of workload operation. This copy is kept current as keys are dynamically added to, and removed from, the active CKDS key store. Like any set of control information that is maintained in virtual storage, the in-storage CKDS copy must be accommodated with sufficient system central storage and auxiliary paging space resources.

Installations need to understand and plan for the system resources that are required for managing the CKDS copy in virtual storage, particularly when the installation is deploying a large CKDS. Note that “very large” is a relative assessment depending upon the installation, and might be expressed, for example, in terms of tens or hundreds of thousands of symmetric keys in the CKDS, or even millions of keys.

An in-storage copy of a CKDS that is not experiencing significant dynamic key creation or deletion activity consumes a stable amount of virtual storage, and therefore a stable amount of system backing resource. However, certain occasional but unavoidable ICSF functions such as CKDS refresh do generate a significant spike in the amount of used virtual storage, and therefore a greater temporary demand for system resources backing that virtual storage.

Given these circumstances, it is important to calculate and plan for the system central storage and auxiliary paging space that is required to support an active in-storage copy. For a CKDS shared across a sysplex environment, every active ICSF in the sysplex has an equivalent resource requirement.

Each symmetric key in the CKDS is managed with one VSAM record. Installations need to plan for the appropriate amount of combined central storage and auxiliary paging space for each VSAM record, per active ICSF. The following formula is provided to help you calculate the required system virtual storage backing resource for an active in-storage CKDS. In this formula HI-A-RBA is the allocated relative byte address for the data component of a CKDS VSAM data set. The IDCAMS LISTCAT command output for a CKDS VSAM data set can be consulted to determine the HI-A-RBA value for the data component. The

%Free
Space

used in this formula represents the percentage of free space in the CKDS VSAM data set. The IDCAMS EXAMINE DATATEST command output can be consulted to determine the percentage of free space.

HI-A-RBA x ( ( 100 - %Free Space ) / 100 ) x 6

For example, the central storage and auxiliary paging space requirement for a CKDS VSAM data set with a HI-A-RBA of 481,787,904 for its data component entry and 16 percent free space can be calculated as follows.

481,787,904 x ( ( 100 - 16 ) / 100 ) x 6 = 2,428,211,036.16 bytes

This CKDS VSAM data set requires 2.26 Gigabytes of combined central storage and auxiliary paging space for system backing resource.

As is the case with all virtual storage usage, central storage is the preferred medium to optimize the workload performance, and to avoid system paging overhead. Excessive system paging due to any virtual storage usage can cause degradation across the workload and system operation, and an extreme shortage of central storage and auxiliary paging space can lead to a catastrophic system failure.

Note: The output from the preceding formulas should be added to the outputs calculated from the formulas in ICSF system resource planning for the PKDS and ICSF system resource planning for the TKDS and session object memory areas. This gives you the required system virtual storage backing resource for all of ICSF’s KDS data sets. This value represents the required amount of virtual storage for a given instance of ICSF. For a set of KDS data sets shared across a sysplex environment, every active ICSF in the sysplex has an equivalent resource requirement.