The systems sharing a PKDS may be different LPARs on the same
system or different systems across multiple zSeries Processors. The
only requirement for sharing the PKDS is that the same asymmetric
master keys be installed on all systems sharing that PKDS. It is not
required to share the PKDS across a sysplex. Each system may have
its own asymmetric master keys and its own PKDS. A sysplex may have
a combination of systems that share a PKDS and individual systems
with separate PKDSs.
In a sysplex environment, a set of ICSF instances all sharing the
same active PKDS can be described as a PKDS sysplex cluster. Other
ICSF instances configured with different active PKDSs can join the
same sysplex group to create multiple PKDS sysplex clusters.
It is not required for each ICSF instances sharing the same active
PKDS to be configured with the same DOMAIN. Cryptographic Coprocessor
DOMAINs may be split up across LPARs all sharing the same active PKDS.
When sharing the PKDS, a few precautions should be observed:
- Dynamic PKDS services update the DASD copy of the active PKDS
and the in-storage copy on the system where it is run. The SYSPLEXPKDS
option in the ICSF installation options data set provides consistent
sysplex-wide update of the DASD copy of the active PKDS and the in-storage
copies of the active PKDS for all members of the sysplex sharing the
same active PKDS. If SYSPLEXPKDS(YES,FAIL(xxx)) is specified in the
installation options data set, sysplex messages will be issued to
sysplex members configured with the same active PKDS. The messages
will inform them of the PKDS update and request them to update their
in-storage PKDS copy. If SYSPLEXPKDS(NO,FAIL(xxx)) is specified in
the installation options data set, sysplex messages will not be sent
to sysplex members for PKDS updates. When configured this way, either
a coordinated refresh or a local refresh must be performed to load
the updates into ICSF's in-storage copy of the PKDS. To perform a
coordinated PKDS refresh, see Performing a coordinated refresh in Running in a Sysplex Environment. To perform a local PKDS refresh on each
ICSF instance configured with the affected PKDS, see Performing a Local PKDS Refresh in Managing CCA Master Keys depending
on your coprocessor type. Optionally, you may use CSFPUTIL to perform
a local PKDS refresh. See Refreshing the in-storage copy of the PKDS in Using the ICSF Utility Program CSFPUTIL for more information.
- If multiple sysplexes share a PKDS, or if a sysplex and other
non-sysplex systems share a PKDS, there is no provision for automatic
update of the in-storage copies of the PKDS on the systems that are
not in the same sysplex as the system initiating the PKDS update.
When configured this way, either a coordinated PKDS refresh or a local
PKDS refresh will be required on the systems that are sharing the
same active PKDS but are not in the same sysplex as the initiating
system in order to update the in-storage copy on each system. To perform
a coordinated PKDS refresh, see Performing a coordinated refresh in Running in a Sysplex Environment. To perform a local PKDS refresh on each
ICSF instance configured with the affected PKDS, see Performing a Local PKDS Refresh in Managing CCA Master Keys depending
on your coprocessor type. Optionally, you may use CSFPUTIL to perform
a local PKDS refresh. See Refreshing the in-storage copy of the PKDS in Using the ICSF Utility Program CSFPUTIL for more information.
- The PKDS must be initialized for PKA callable services to be enabled.
Use the TSO panels to initialize a new PKDS.
- There are two formats of the PKDS:
- Variable-length record (supported by all releases of ICSF).
- KDSR record (supported by HCR77A1 and later releases).
The KDSR record format can be shared only by
systems running ICSF HCR77A1 or later.