The systems sharing a TKDS may be different LPARs on the same system
or different systems across multiple zSeries processors. It is not
required to share the TKDS across a sysplex. Each system may have
its own TKDS. A sysplex may have a combination of systems that share
a TKDS and individual systems with separate TKDSs. There is no requirement
that the DOMAINs must be the same to share a TKDS.
In a sysplex environment, a set of ICSF instances all sharing the
same active TKDS can be described as a TKDS sysplex cluster. Other
ICSF instances configured with different active TKDSs can join the
same sysplex group to create multiple TKDS sysplex clusters.
When sharing the TKDS, a few precautions should be observed:- Dynamic TKDS services update the DASD copy of the active TKDS
and the in-storage copy on the system where it is run. The SYSPLEXTKDS
option in the ICSF installation options data set provides consistent
sysplex-wide update of the DASD copy of the active TKDS and the in-storage
copies of the active TKDS for all members of the sysplex sharing the
same active TKDS. If SYSPLEXTKDS(YES,FAIL(xxx)) is specified in the
installation options data set, sysplex messages will be issued to
sysplex members configured with the same active TKDS. The messages
will inform them of the TKDS update and request them to update their
in-storage TKDS copy. If SYSPLEXTKDS(NO,FAIL(xxx)) is specified in
the installation options data set, sysplex messages will not be sent
to sysplex members for TKDS updates.
- If multiple sysplexes share a TKDS, or if a sysplex and other
non-sysplex systems share a TKDS, there is no provision for automatic
update of the in-storage copies of the TKDS on the systems which are
not in the same sysplex as the system initiating the TKDS update.
- There are two formats of the TKDS:
- 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.
Starting with release HCR77A0, a new communication protocol has
been added to TKDS sysplex support to facilitate the coordinated TKDS
change master key function. This new protocol provides performance
enhancements for TKDS update processing in a sysplex environment.
All systems in the sysplex, regardless of their active TKDS, must
be at the HCR77A0 level or higher in order for ICSF to use this new
protocol. To determine if ICSF is using the new communication protocol,
check the ICSF job log for the following message:
CSFM624I ICSF COMMUNICATION LEVEL CHANGED FROM 0 TO 2.
If
an ICSF instance at a level lower than HCR77A0 joins the TKDS sysplex
group, the prior release protocol will be used and the coordinated
TKDS change master key functions will be unavailable. To determine
if ICSF is using the prior release protocol, check the ICSF job log
for CSFM624I messages. If there are no CSFM624I messages, then ICSF
is using the prior release protocol. If there are multiple CSFM624I
messages and the last message indicates that the communication level
changed from 2 to 0, then ICSF is using the prior release protocol.
For example:
CSFM624I ICSF COMMUNICATION LEVEL CHANGED FROM 2 TO 0.
For
more information about the coordinated TKDS change master key function,
refer to
Performing a coordinated change master key.
Note: The ICSF communication
protocol is not configurable. ICSF determines the communication protocol
internally based on the ICSF instances that have joined the sysplex
group.