Parameters in the installation options data set

The installation options data set is an intended programming interface.

When specifying parameter values within parentheses, leading and trailing blanks are ignored. Embedded blanks may cause unpredictable results.

Support is provided for the use of system symbols in the installation options data set. System symbols can be used as values for any of the parameters. System symbols are specified in the IEASYMxx member of SYS1.PARMLIB; the IEASYM statement of the LOADxx member of SYS1.PARMLIB specifies the IEASYMxx member or members to be used for the resolution of system symbols. This example shows the use of a system symbol for specifying the domain to be used for the start of ICSF:

 DOMAIN(&PARDOM.)

When the Installation Options Data Set is processed during the start of ICSF, the value of the system symbol PARDOM will be substituted as the value of the DOMAIN parameter.

For the first start, you specified an empty VSAM data set name for the CKDS in the CKDSN option and an empty VSAM data set name for the PKDS in the PKDSN option. You may want to change these and other options for subsequent starts. Here is a complete list of installation options:

AUDITKEYLIFECKDS(TOKEN(YES or NO),LABEL(YES or NO))

Provides a set of options that control auditing of events related to the lifecycle of symmetric CCA tokens. The audit logs are in the form of Type 82 SMF records.

TOKEN(YES or NO)

Controls lifecycle auditing of CKDS tokens.

Value: Indication
YES: Indicates ICSF should audit lifecycle events related to CKDS tokens. An SMF type 82 subtype 40 record is logged for each event.
NO: No lifecycle auditing of CKDS tokens occurs.

LABEL(YES or NO)

Controls lifecycle auditing of CKDS labels.

Value: Indication
YES: Indicates ICSF should audit lifecycle events related to CKDS labels. An SMF type 82 subtype 40 record is logged for each event. The subtype 40 record replaces the subtype 9 record.
NO: No lifecycle auditing of CKDS labels occurs. ICSF continues to log an SMF type 82 subtype 9 record for CKDS updates.

If the AUDITKEYLIFECKDS option is not specified, the default is AUDITKEYLIFECKDS (TOKEN(NO),LABEL(NO)).

Note:

An event that involves a token is considered to be any request that uses a token as opposed to a label. This is true regardless of Key Store Policy enablement.
If auditing of CKDS labels is enabled, the Key Generator Utility Program (KGUP) needs access to the CSFGKF profile in the CSFSERV class in order to generate the key fingerprint for keys it processes.

For more information about the events that are audited as well as the information contained in the audit record, see Appendix B in z/OS Cryptographic Services ICSF System Programmer's Guide for the description for the subtype 40 record.

The auditing of key lifecycle events can also be controlled via the SETICSF operator command. See the description of the SETICSF command in z/OS Cryptographic Services ICSF System Programmer's Guide for more information.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

AUDITKEYLIFEPKDS(TOKEN(YES or NO),LABEL(YES or NO))

Provides a set of options that control auditing of events related to the lifecycle of asymmetric CCA tokens. The audit logs are in the form of Type 82 SMF records.

TOKEN(YES or NO)

Controls lifecycle auditing of PKDS tokens.

Value: Indication
YES: Indicates ICSF should audit lifecycle events related to PKDS tokens. An SMF type 82 subtype 41 record is logged for each event.
NO: No lifecycle auditing of PKDS tokens occurs.

LABEL(YES or NO)

Controls lifecycle auditing of PKDS labels.

Value: Indication
YES: Indicates ICSF should audit lifecycle events related to PKDS labels. An SMF type 82 subtype 41 record is logged for each event. The subtype 41 record replaces the subtype 13 record.
NO: No lifecycle auditing of PKDS labels occurs. ICSF continues to log an SMF type 82 subtype 13 record for PKDS updates.

If the AUDITKEYLIFEPKDS option is not specified, the default is AUDITKEYLIFEPKDS (TOKEN(NO),LABEL(NO)).

Note: An event that involves a token is considered to be any request that uses a token as opposed to a label. This is true regardless of Key Store Policy enablement.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

AUDITKEYLIFETKDS(TOKENOBJ(YES or NO),SESSIONOBJ(YES or NO))

Provides a set of options that control auditing of events related to the lifecycle of PKCS #11 objects. The audit logs are in the form of Type 82 SMF records.

TOKENOBJ(YES or NO)

Controls lifecycle auditing of PKCS #11 token objects.

Value: Indication
YES: Indicates ICSF should audit lifecycle events related to PKCS #11 token objects. An SMF type 82 subtype 42 record is logged for each event. The subtype 42 record replaces the subtype 23 record.
NO: No lifecycle auditing of PKCS #11 token objects occurs. ICSF continues to log an SMF type 82 subtype 23 record for TKDS updates.

SESSIONOBJ(YES or NO)

Controls lifecycle auditing of PKCS #11 session objects.

Value: Indication
YES: Indicates ICSF should audit lifecycle events related to PKCS #11 session objects. An SMF type 82 subtype 42 record is logged for each event.
NO: No lifecycle auditing of PKCS #11 session objects occurs.

If the AUDITKEYLIFETKDS option is not specified, the default is AUDITKEYLIFETKDS (TOKENOBJ(NO),SESSIONOBJ(NO)).

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

AUDITKEYUSGCKDS(TOKEN(YES or NO),LABEL(YES or NO),INTERVAL(n))

Provides a set of options that control auditing of events related to the usage of symmetric CCA tokens. The audit logs are in the form of Type 82 SMF records.

TOKEN(YES or NO)

Controls usage auditing of CKDS tokens.

Value: Indication
YES: Indicates ICSF should audit usage events related to CKDS tokens. An SMF type 82 subtype 44 record is logged for each event.
NO: No usage auditing of CKDS tokens occurs.

LABEL(YES or NO)

Controls usage auditing of CKDS labels.

Value: Indication
YES: Indicates ICSF should audit usage events related to CKDS labels. An SMF type 82 subtype 44 record is logged for each event.
NO: No usage auditing of CKDS labels occurs.

INTERVAL(n)

Defines the time interval over which the audit records are aggregated. Specify n as a decimal value in hours from 1 through 24. Individual usages with the same user, service, and key are aggregated over the interval into a single SMF record with a usage count. For performance reasons, ICSF may temporarily reduce the length of an interval from what was specified.

If the AUDITKEYUSGCKDS option is not specified, the default is AUDITKEYUSGCKDS(TOKEN(NO),LABEL(NO),INTERVAL(24)).

Note: An event that involves a token is considered to be any request that uses a token as opposed to a label. This is true regardless of Key Store Policy enablement.

For more information about the information contained in the audit record, see Appendix B in z/OS Cryptographic Services ICSF System Programmer's Guide for the description for the subtype 44 record.

The auditing of key usage events can also be controlled via the SETICSF operator command. See the description of the SETICSF command in z/OS Cryptographic Services ICSF System Programmer's Guide for more information.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

AUDITKEYUSGPKDS(TOKEN(YES or NO),LABEL(YES or NO),INTERVAL(n))

Provides a set of options that control auditing of events related to the usage of asymmetric CCA tokens. The audit logs are in the form of Type 82 SMF records.

TOKEN(YES or NO)

Controls usage auditing of PKDS tokens.

Value: Indication
YES: Indicates ICSF should audit usage events related to PKDS tokens. An SMF type 82 subtype 45 record is logged for each event.
NO: No usage auditing of PKDS tokens occurs.

LABEL(YES or NO)

Controls usage auditing of PKDS labels.

Value: Indication
YES: Indicates ICSF should audit usage events related to PKDS labels. An SMF type 82 subtype 45 record is logged for each event.
NO: No usage auditing of PKDS labels occurs.

INTERVAL(n)

If the AUDITKEYUSGPKDS option is not specified, the default is AUDITKEYUSGPKDS(TOKEN(NO),LABEL(NO),INTERVAL(24)).

Note: An event that involves a token is considered to be any request that uses a token as opposed to a label. This is true regardless of Key Store Policy enablement.

For more information about the information contained in the audit record, see Appendix B in z/OS Cryptographic Services ICSF System Programmer's Guide for the description for the subtype 45 record.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

AUDITPKCS11USG(TOKENOBJ(YES or NO),SESSIONOBJ(YES or NO),NOKEY(YES or NO),INTERVAL(n))

Provides a set of options that control auditing of usage events related to PKCS #11 services. The audit logs are in the form of Type 82 SMF records.

TOKEN(YES or NO)

Controls usage auditing of PKCS #11 token objects.

Value: Indication
YES: Indicates ICSF should audit usage events related to PKCS #11 token objects. An SMF type 82 subtype 46 record is logged for each event.
NO: No usage auditing of PKCS #11 token objects occurs.

SESSIONOBJ(YES or NO)

Controls usage auditing of PKCS #11 session objects.

Value: Indication
YES: Indicates ICSF should audit usage events related to PKCS #11 session objects. An SMF type 82 subtype 46 record is logged for each event.
NO: No usage auditing of PKCS #11 session objects occurs.

NOKEY(YES or NO)

Controls usage auditing of PKCS #11 services that do not involve an object.

Value: Indication
YES: Indicates ICSF should audit relevant usages that do not pertain to a PKCS #11 object. Relevant usages include use of the PKCS #11 One-way hash, sign, or verify (CSFPPRF) and PKCS #11 Pseudo-random function (CSFPOWH) services. An SMF type 82 subtype 47 record is logged for each event.
NO: No usage auditing of PKCS #11 services that do not involve an object occurs.

INTERVAL(n)

If the AUDITPKCS11USG option is not specified, the default is AUDITPKCS11USG(TOKENOBJ(NO),SESSIONOBJ(NO),NOKEY(NO), INTERVAL(24)).

For more information about the information contained in the audit record, see Appendix B in z/OS Cryptographic Services ICSF System Programmer's Guide for the description for the subtypes 46 and 47 records.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

BEGIN(fmid)

Specifies that parameters following this BEGIN parameter are supported in release fmid and later. There must be an END statement to complete the current section. If not, an error message will be issued and ICSF will terminate.

There may be any number of BEGIN/END pairs in the data set, but they cannot be nested within each other. A BEGIN must have a matching END before another BEGIN can be specified.

If the release of ICSF you are running is at this release or later, the parameters will be parsed and processed. If release of ICSF you are running is an earlier release, the parameters will be ignored.

It is recommended that when your systems are all running releases that support newer parameters that the BEGIN/END pair be removed.

The following FMIDs are supported: HCR7740, HCR7750, HCR7751, HCR7770, HCR7780, HCR7790, HCR77A0, HCR77A1, HCR77B0, HCR77B1, HCR77C0, HCR77C1, and HCR77D0.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

Here is an example of the usage of the BEGIN/END parameters.

parameter4       /* parameter4 is supported by all releases */
BEGIN(HCR7751) 
parameter1       /* parameter1 added in HCR7751 */
parameter3       /* parameter3 added in HCR7751 */
END
BEGIN(HCR7770)
parameter2       /* parameter2 added in HCR7770 */
END
parameter5       /* parameter5 is supported by all releases */

CHECKAUTH(YES or NO)

Indicates whether ICSF performs security access control checking of Supervisor State or System Key callers. If you specify CHECKAUTH(YES), ICSF issues RACROUTE calls to perform the security access control checking and the results are logged in RACF SMF records that are cut by RACF. If you specify CHECKAUTH(NO), the authorization checks against resources in the CSFSERV, CSFKEYS, and XCSFKEY classes are not performed.

If you do not specify the CHECKAUTH option, the default is CHECKAUTH(NO).

If you configure CHECKAUTH(YES) in the ICSF options dataset, the Health Checker address space user identity must be authorized to the CSFRKL profile in class CSFSERV for the ICSFMIG7731_ICSF_RETAINED_RSAKEY migration check to successfully execute. However, you have no action to take if you choose not to run the migration check. If you configure CHECKAUTH(NO), there is no requirement to authorize the Health Checker user identity for any ICSF profiles or classes, since the check routine executes in supervisor state. This is not an implementation consideration, but rather a check deployment or activation time customer administration consideration.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

CICSAUDIT(YES or NO)

Indicates whether ICSF logs CICS client identity information on SAF calls that check the CICS address space access to the CSFSERV, CSFKEYS, and XCSFKEY classes. CICSAUDIT(NO) is the default.

If you specify CICSAUDIT(YES), when a CICS transaction running on the Quasi Reentrant (QR) task calls an ICSF service, ICSF subsequently calls a CICS service to obtain the client identity information. This information is then constructed into a log string, which is passed to the security product.

The following identity information is collected:

Userid.
X500 certificate information:

X500_IDN

The IDN string is truncated to 255 bytes if a longer value is present.

X500_SDN

The SDN string is truncated to 255 bytes if a longer value is present.
Distributed Identity Data (IDID):
- IDID user name (in UTF8 format).
- IDID user name format.
- Distributed registry name (in UTF8 format).

CICSAUDIT(YES) should only be specified if you are collecting SMF type 80, event code 2 (resource access) records.

By processing the resulting SMF log, you can determine which CICS users are accessing which ICSF services and which keys are being used.

CKDSN(data-set-name)

Specifies the CKDS name the system uses to start ICSF. Whenever you restart ICSF, the CKDS named in the CKDSN option becomes the active in-storage CKDS. (At first-time startup, you should specify the name of an empty VSAM data set you created to use as the CKDS.)

If you do not specify this keyword, you will not be able to use secure CCA symmetric keys or use ICSF to manage CCA symmetric keys. ICSF must be restarted in order to switch between having a CKDS and not having a CKDS.

See Steps to create the installation options data set for the data set naming format requirements.

CKTAUTH(YES or NO)

This keyword is no longer supported, but is tolerated.

COMPAT(YES, NO, or COEXIST)

Indicates whether ICSF runs in compatibility mode, non-compatibility mode, or coexistence mode with PCF.

YES: Indicates compatibility mode.
In compatibility mode, you can run a PCF application on ICSF because ICSF supports the PCF macros. You do not have to reassemble PCF applications to do this. You cannot start PCF at the same time as ICSF on the same operating system.
NO: Indicates non-compatibility mode. In noncompatibility mode, you run PCF applications on PCF and ICSF applications on ICSF. You cannot run PCF applications on ICSF because ICSF does not support the PCF macros in this mode. PCF can be started at the same time as ICSF on the same operating system. You can start ICSF and then start PCF, or you can start PCF and then start ICSF.
You should use noncompatibility mode unless you are migrating from PCF to ICSF.
COEXIST: Indicates coexistence mode.
In coexistence mode, you can run a PCF application on PCF, or you can reassemble the PCF application to run on ICSF. To do this, you reassemble the application against coexistence macros that are shipped with ICSF. You can start PCF at the same time as ICSF on the same operating system.

If you do not specify the COMPAT option, the default value is COMPAT(NO). See Running PCF and z/OS ICSF on the same system for a complete description of the COMPAT options.

When you initialize ICSF for the first time, noncompatibility mode must be active. Therefore, at first-time startup, you must specify COMPAT(NO)

or allow the default to be used.

COMPENC(DES or CDMF)

This keyword is no longer supported, but is tolerated.

COMPLIANCEWARN(PCIHSM2016(YES or NO or SAF))

Indicates whether ICSF should generate compliance warning events for a compliance mode. Compliance warning events can be used to help migrate an application to a given compliance mode. Compliance warning events are written in the form of SMF type 82 subtype 48 records. If you do not specify the COMPLIANCEWARN option, the default is NO for all compliance modes.

PCIHSM2016(YES or NO or SAF)

Controls warning events for the PCI-HSM 2016 compliance mode. If you do not specify the PCIHSM2016 option, the default is NO.

Value: Indication
YES: Generate compliance warning events for all applications.
NO: No compliance warning events are generated.
SAF: Generate compliance warning events for applications which have READ access to the CSF.COMPLIANCEWARN.PCIHSM2016 profile in the XFACILIT SAF class.

For more information about the information contained in the SMF record, see ICSF SMF records for the description of the subtype 48 record.

A compliance warning event is only written when a DES key is used in a callable service. See Migration for more information on how you can use compliance warning events to help migrate an application.

The generation of compliance warning events can also be controlled with the SETICSF,OPT REFRESH operator command. For more information, see SETICSF.

CTRACE(CTICSFxx)

Specifies the CTICSFxx ICSF CTRACE configuration data set to use from PARMLIB. CTICSF00 is the default ICSF CTRACE configuration data set that is installed with ICSF FMID HCR77A1 and later releases. CTICSF00 may be copied to create new PARMLIB members using the naming convention of CTICSFxx, where xx is a unique value specified by the user.

This parameter is optional. If the specified PARMLIB member is incorrect or absent, ICSF CTRACE will attempt to use the default CTICSF00 PARMLIB member. If the CTICSF00 PARMLIB member is incorrect or absent, ICSF CTRACE will perform tracing using an internal default set of trace options. By default, ICSF CTRACE support will trace with the KdsIO, CardIO, and SysCall filters using a 2M buffer. For more information refer to Creating an ICSF CTRACE configuration data sets.

DEFAULTWRAP(internal_wrapping_method,external_wrapping_method)

Specifies the default key wrapping for DES keys. Any token generated or updated by a service will be wrapped using the specified method unless overridden by rule array keyword or a skeleton token. The default wrapping method for internal and external tokens is specified independently.

Valid values for internal_wrapping_method and external_wrapping_method are:

ORIGINAL: Specifies the original CCA token wrapping be used: ECB wrapping for DES.
ENHANCED: Specifies the new X9.24 compliant CBC wrapping is used. The enhanced wrapping method with SHA-1 is available on IBM zEnterprise 196, IBM zEnterprise 114 and newer servers.

If the DEFAULTWRAP parameter is not specified, the default wrapping method is ORIGINAL for both internal and external tokens.

Note: Triple-length DES keys are always wrapped with the enhanced method with SHA-256. The setting of this parameter has no effect on the wrapping of triple-length DES keys except DATA keys with a zero control vector.

During initialization, ICSF changes the setting of the default wrapping method for all CCA coprocessors to match the value that is specified by this parameter.

Notes:

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).
Starting with ICSF FMID HCR77C1 on IBM z14 servers, the ENHANCED wrapping method should be used if you are using PCI-HSM compliant tagged keys.

DOMAIN(n)

Specifies the number of the domain that you want to use for this start of ICSF. You can specify only one domain in the options data set. The domain value must match the activation profile.

DOMAIN is an optional parameter. The DOMAIN parameter is only required if more than one domain is specified as the usage domain on the PR/SM panels. If specified in the options data set, it will be used and it must be one of the usage domains for the LPAR.

If DOMAIN is not specified in the options data set, ICSF determines which domains are available in this LPAR. If only one domain is defined for the LPAR, ICSF will use it. If more than one is available, ICSF will issue error message CSFM409E.

The cryptographic processors support multiple sets of master key registers, which the specific domain values identify.

The PCIXCC/CEX2C has master key registers for the DES-MK, AES-MK and RSA-MK master keys. Each domain has a master key register for the current, new, and old DES-MK, AES-MK and RSA-MK.
CCA cryptographic coprocessors that are CEX3C or later have master key registers for the DES-MK, AES-MK, RSA-MK, and ECC-MK master keys. Each domain has a master key for the current, new, and old DES-MK, AES-MK, RSA-MK, and ECC-MK.
The PKCS #11 cryptographic coprocessors have master key registers for the P11-MK master key. Each domain has a master key for the current and new P11-MK.

Note: The domain number that ICSF uses has no meaning for regional cryptographic servers. Regional cryptographic servers use the port number to identify the master key register to use.

For more information about partitions and running different configurations, see z/OS Cryptographic Services ICSF Overview.

If you run ICSF in compatibility or coexistence mode, you cannot change the domain number without re-IPLing the system. A re-IPL ensures that a program does not access a cryptographic service with a key that is encrypted under a different master key. If you are certain that no cryptographic applications are still running, you can:

Stop CSF
Start CSF in COMPAT(NO) mode with a different domain number
Stop CSF
Start CSF in compatibility or coexistence mode with a different domain number.

END

Specifies the end of a section of parameters for the fmid from the BEGIN(fmid). There must be a BEGIN(fmid) prior to the END. There must be an END for each BEGIN(fmid). See the description for BEGIN for an example of the usage of the BEGIN and END parameters.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

EXIT(ICSF-name,load-module-name,FAIL(fail-option))

Indicates information about an installation exit.

The ICSF -name is the identifier for each exit. Resource names for CCA and ICSF entry points lists all the ICSF exit names and explains when ICSF calls each exit. The load module name is the name of the module that contains the exit. The name can be any valid name your installation chooses.

Using the FAIL keyword of the EXIT statement, you specify the action ICSF, the KGUP, or the PCF conversion program takes if the exit ends abnormally. The fail action that you specify applies to subsequent calls of the exit. If an exit ends abnormally, ICSF takes a system dump. The exit is protected with an ESTAE or the ICSF service functional recovery routine (FRR).

In general, you can specify one of these values for a fail option:

NONE: No action is taken. The exit can be called again and will end abnormally again.
EXIT: The exit is no longer available to be called again.
SERVICE: The service or program that called the exit is no longer available to be called again.
ICSF: ICSF or the key generator utility program or the PCF conversion program is ended, depending on the exit.

Some fail options are not valid for a specific exit. If you specify a fail option that is not valid, ICSF uses the next valid fail option. For example, if SERVICE is not a valid fail option for an exit, ICSF uses the EXIT option. EXIT is responsible for logging in SMF the results of any authorization checks that are made.

See Installation exits for a detailed description of each ICSF exit, including the valid fail options.

Note: z/OS no longer ships IBM-supplied security exit routines; the security exit points remain. Users of z/OS should use Security Server (RACF) or an equivalent product to obtain access checking of services and keys. ICSF no longer needs these exit routines.

FIPSMODE(YES, FAIL(fail-option) or COMPAT, FAIL(fail-option) or NO,FAIL(fail-option))

Indicates whether z/OS PKCS #11 services must run in compliance with the Federal Information Processing Standard Security Requirements for Cryptographic Modules, referred to as FIPS 140-2. FIPS 140-2, published by the National Institute of Standards and Technology (NIST), is a standard that defines rules and restrictions for how cryptographic modules should protect sensitive or valuable information. The standard is available at Security Requirements For Cryptographic Modules.

By configuring z/OS PKCS #11 services to operate in compliance with FIPS 140-2 specifications, installations or individual applications can use the z/OS PKCS #11 services in a way that allows only the cryptographic algorithms (including key sizes) approved by the standard, and restricts access to the algorithms that are not approved. For more information, see z/OS Cryptographic Services ICSF Writing PKCS #11 Applications.

YES

Indicates that the z/OS PKCS #11 services will operate in FIPS standard mode. Any application using the PKCS #11 services will be forced to use those services in a FIPS-compliant manner. Applications will not have access to the algorithms or key sizes not approved by FIPS 140-2. In addition, ICSF initialization will test that it is running on an IBM Z® model type, and a version and release of z/OS, that supports FIPS. If so, then ICSF will perform a series of cryptographic known answer tests as required by the FIPS 140-2 standard. If any of these initialization tests should fail, the action the ICSF initialization process takes will depend on the fail-option specified.

The fail-option is either YES or NO and indicates the action that the ICSF initialization process should take if any of the initialization tests should fail.

YES

Indicates ICSF is to terminate abnormally if there is a failure in any of the tests performed.

NO

Indicates ICSF initialization processing is to continue even if there is a failure in any of the tests performed. However, PKCS #11 support will be limited or nonexistent depending on the test that failed:

If ICSF is running on an IBM Z model type or with a version of z/OS that does not support FIPS, most FIPS processing is bypassed. PKCS #11 callable services will be available, but ICSF will not adhere to FIPS 140 restrictions. Requests to generate or use a key with CKA_IBM_FIPS140=TRUE or those requests that explicitly ask for FIPS processing will result in a failure return code.
If a known answer test failed, all ICSF PKCS #11 callable services will be unavailable.

COMPAT

Indicates that the z/OS PKCS #11 services will operate in FIPS compatibility mode. This mode is intended for installations where only certain z/OS PKCS #11 applications must comply with the FIPS 140-2 standard, while other applications do not. In this mode, the PKCS #11 services can be further configured so that the applications that do not need to comply with the FIPS 140-2 standard are not restricted from using any of the PKCS #11 algorithms, while applications that must comply with the standard are restricted from using the non-approved algorithms. By default, the COMPAT option will have the same effect as the YES option, and all applications using the PKCS #11 services will be forced to use those services in a FIPS-compliant manner. However, additional specifications can be made:

at the PKCS #11 token and application level, by creating FIPSEXEMPT.token-label resource profiles in the CRYPTOZ class. A FIPSEXEMPT.token-label resource exists for each token. User IDs with READ access authority to a FIPSEXEMPT.token-label are exempt from FIPS compliance, while user IDs with access authority NONE can only use the PKCS #11 services in a FIPS-compliant manner.
within applications themselves for individual keys. When an application creates a key, the application can specify that the key must be used in a FIPS 140-2 compliant fashion. The application can specify this by setting the Boolean key attribute CKA_IBM_FIPS140 to TRUE.

When the COMPAT option is specified, ICSF initialization will test that it is running on an IBM Z model type, and a version and release of z/OS, that supports FIPS. If so, then ICSF will perform a series of cryptographic known answer tests as required by the FIPS 140-2 standard. If any of these initialization tests should fail, the action the ICSF initialization process takes will depend on the fail-option specified.

The fail-option is either YES or NO and indicates the action that the ICSF initialization process should take if any of the initialization tests should fail.

YES

Indicates ICSF is to terminate abnormally if there is a failure in any of the tests performed.

NO

If ICSF is running on an IBM Z model type or with a version of z/OS that does not support FIPS, most FIPS processing is bypassed. PKCS #11 callable services will be available, but ICSF will not adhere to FIPS 140 restrictions. Requests to generate or use a key with CKA_IBM_FIPS140=TRUE or those requests that explicitly ask for FIPS processing will result in a failure return code.
If a known answer test failed, all ICSF PKCS #11 callable services will be unavailable.

NO

Indicates that ICSF should operate in FIPS no enforcement mode, also known as FIPS on-demand mode. Applications may request strict adherence to FIPS 140 restrictions when requesting ICSF services. However, applications not requesting FIPS processing are not required to adhere to FIPS 140 restrictions. FIPSEXEMPT.token-label profiles, if they exist in the CRYPTOZ class, will not be examined. If ICSF is running on an IBM Z model type that does not support FIPS, requests to generate or use a key with CKA_IBM_FIPS140=TRUE or those requests that explicitly ask for FIPS processing will result in a failure return code.

ICSF initialization will test that it is running on an IBM Z model type and version/release of z/OS that supports FIPS. If so, ICSF initialization will also perform a series of cryptographic known answer self tests. Should a test fail, the action ICSF initialization takes is dependent on the fail option.

The fail-option is either YES or NO and indicates the action that the ICSF initialization process should take if any of the initialization tests should fail.

YES

Indicates ICSF is to terminate abnormally if there is a failure in any of the tests performed.

NO

If ICSF is running on an IBM Z model type or with a version of z/OS that does not support FIPS, most FIPS processing is bypassed. PKCS #11 callable services will be available, but ICSF will not adhere to FIPS 140 restrictions. Requests to generate or use a key with CKA_IBM_FIPS140=TRUE or those requests that explicitly ask for FIPS processing will result in a failure return code.
If a known answer test failed, all ICSF PKCS #11 callable services will be unavailable.

If the FIPSMODE option is not specified, the default is FIPSMODE(NO, FAIL(NO)).

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

HDRDATE(YES or NO)

This keyword is no longer supported, but is tolerated.

KDSREFDAYS(n)

Specifies, in days, how often a record should be written for a reference date/time change. A key is referenced when it is used to perform a cryptographic operation. If a key is referenced ICSF will check the date and time the key was referenced previous to the current reference. If the number of days between the current date and time and the date and time the key was last referenced is greater than or equal to the number of days specified in the KDSREFDAYS installation option then the key reference date/time in the KDS will be updated to the current date and time. Otherwise the reference date/time will remain the same. Note, in this context days are 24 hour periods not necessarily beginning or ending at midnight.

For example: If KDSREFDAYS(7) was specified and a key was referenced on Monday, January 1st at 8 AM, and the reference date/time for the key was updated at that time, then any key reference before Monday, January 8th at 8 AM (7 days) will not update the reference date/time in the key record. If the key is referenced again at 7:50 AM on Monday, January 8th, the reference date/time for the key in the KDS will remain January 1st at 8 AM because fewer than seven days have passed. The reference date/time will not be updated until the next time the key is used again Monday, January 8th at 8 AM or after.

KDSREFDAYS applies to all KDS that are in the format that supports key reference tracking. In an environment of mixed KDS formats, where some support reference date tracking and some do not (for example, the CKDS supports reference date tracking, but the PKDS does not) key references will not be tracked for keys in a KDS does not support it, regardless on the value of KDSREFDAYS, until that KDS is updated to the new format. In a SYSPLEX, all systems must be started with the same value of KDSREFDAYS to ensure proper tracking of reference date/times.

KDSREFDAYS(0) means that ICSF will not keep track of key reference dates. The default is KDSREFDAYS(1). The maximum value allowed is KDSREFDAYS(30).

Note: Updates to records using the Key Generator Utility Program (KGUP) are not subject to the value specified in the KDSREFDAYS option. All updates made via KGUP will update the reference date/time if the CKDS is in a format that supports reference date tracking (KDSR).

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

KEYARCHMSG(YES or NO)

Controls whether a joblog message is issued when an application successfully references a key data set record that has been archived. The message is only issued for the first successful reference of a record. The results of the service request is not affected by this control. The default is NO.

Value: Indication
YES: ICSF issues a message the first time an archived record is referenced by an application.
NO: ICSF does not issue a message when an archived record is referenced by an application.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

KEYAUTH(YES or NO)

This keyword is no longer supported, but is tolerated.

MASTERKCVLEN(2 or 3 or 4 or 5 or 6 or ALL)

Defines the number of hexadecimal digits to display on the ICSF Coprocessor Hardware Status panel (CSFCMP40) for the verification and hash patterns for the master keys. The patterns are also referred to as key check values. When an integer value is specified, that number of digits will be displayed. When ALL is specified, all the digits will be displayed.

Defines the number of hexadecimal digits recorded in the SMF82KV field for the SMF 82, subtype 7 record. MASTERKCVLEN also limits the number of hexadecimal digits displayed when the D ICSF,MKVPS command is issued. Regardless of the MASTERKCVLEN value, the maximum number of hexadecimal digits displayed when the D ICSF,MKVPS command is issued is six.

The default is ALL.

This option can be used for compliance with the ISO11568 and other standards for the display of the key check values for master keys.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

MAXLEN(n)

Defines the maximum length of characters in a text string, including any necessary padding, for some callable service requests. For example, this option defines the maximum length of the text the encipher service encrypts for each call. Specify n as a decimal value from 1024 through 2147483647. If you do not specify the MAXLEN option, the default value is MAXLEN(65535).

The MAXLEN parameter may still be specified in the options data set, but only the maximum value limit will be enforced (2147483647). If a value greater than this is specified, an error will result and ICSF will not start.

Note: MAXLEN is no longer displayed on the Installation Option Display panel.

MAXSESSOBJECTS(n)

Defines the maximum number of PKCS #11 session objects and states an unauthorized (problem state, non-system key) application may own at any one time. Specify n as a decimal value from 1024 through 2147483647. If you do not specify the MAXSESSOBJECTS option, the default value is MAXSESSOBJECTS(65535).

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

PKDSCACHE

This keyword is no longer supported, but is tolerated.

PKDSN(data-set-name)

Specifies the PKDS name the system uses to start ICSF. Whenever you restart ICSF, the PKDS named in the PKDSN option becomes the active PKDS. (At first-time startup, you should specify the name of an empty VSAM data set you created to use as the PKDS.)

If you do not specify this keyword, you will not be able to use secure CCA asymmetric keys or use ICSF to manage CCA asymmetric keys. ICSF must be restarted in order to switch between having a PKDS and not having a PKDS.

See Steps to create the installation options data set for the data set naming format requirements.

REASONCODES(ICSF or TSS)

Specifies which set of reason codes are to be returned from callable services. If you do not specify the REASONCODES option, the default of REASONCODES(ICSF) is used. If you specify REASONCODES(TSS), reason codes used by the IBM 4765 PCIe, IBM 4767 PCIe, and IBM 4764 PCI-X cryptographic coprocessors will be returned. If there is a 1-to-1 mapping, the codes will be converted.

If you specified REASONCODES(ICSF) and your service was processed on a CCA coprocessor, a cryptographic coprocessor reason code may be returned if there is no corresponding ICSF reason code.

REMOTEDEVICE(index-number, ip-addr-or-hostname, port-number, number-sockets)

Specifies the connection information for a remote regional cryptographic server device that ICSF is to use for regional cryptographic server requests. There may be up to 16 of these entries.

Notes:

Each regional cryptographic server (as identified by ip-addr-or-hostname and port-number) must be configured identically regarding master keys and other settings. An incorrect master key value will cause the connection to not be used.
For use of standalone, network-attached regional cryptographic servers, IBM zEnterprise EC12 or later hardware is required as well as servers running z/OS V1R13 or later and ICSF FMID HCR77B1 or later.
For use of Linux LPAR regional cryptographic servers, IBM z13 or later hardware is required as well as servers running z/OS V1R13 or later and ICSF FMID HCR77B1 or later.

The options are as follows:

index-number

Specify a number between 1 and 16, inclusive. Each operational REMOTEDEVICE must have a unique number. For indexes that are repeated, ICSF will only save the last one specified. Additionally, if remote devices are shared between sysplex members, it is strongly recommended that the same index number is used for each member. This simplifies remote device management using the SETICSF operator command.

ip-addr-or-hostname

Specify either the dotted-decimal Internet protocol (IP) version 4 address or the hostname of the remote device. Each ip-addr-or-hostname must locate a single device with fixed serial number. Reverse proxy arrangements where one ip-addr-or-hostname is backed by multiple devices (with different serial numbers) is not supported. The opposite arrangement (one serial number assigned to multiple ip-addr-or-hostnames) is supported, but not recommended.

Notes:

Internet protocol (IP) version 6 is not supported.
Hostnames are not case-sensitive and are stored and displayed by ICSF in lowercase.
For long hostnames, the REMOTEDEVICE entry may be split at any comma to span multiple physical records. For example:
```
REMOTEDEVICE(5,some.very.long.hostname.company.com,
6901,8)
```

port-number

Specify the port number to be used in conjunction with the IP address or hostname when connecting.

Note: No two ICSF instances may share the same port on a regional cryptographic server. Additionally, it is expected that different workloads (for example, ICSF instances using different token data sets) sharing a regional cryptographic server would use different master keys (RCS-MKs) and that the required RCS-MK for the TKDS would be assigned on a per port basis.

number-sockets

Specify the maximum number of sockets ICSF is to open for connections with the remote device. This is a value between 1 and 8, inclusive. Multiple sockets are required in order for ICSF to process multiple simultaneous requests. Consult the remote device's documentation to determine this value. There is an ICSF limit of 8 sockets per server or port. If you desire more than 8 socket connections to a single server, define multiple REMOTEDEVICE entries for the server, assigning a unique port number for each entry. Make sure the same master key is defined for each port that will be connected to systems sharing the same TKDS.

RNGCACHE(YES or NO)

Indicates whether ICSF should maintain a cache of random numbers to be used by services that require them. When YES is specified for this option, a noticeable performance improvement may be realized by workloads requesting a significant amount of random data.

If you do not specify the RNGCACHE option, the default value is RNGCACHE(YES).

Value: Indication
YES: ICSF maintains a random number cache.
NO: ICSF does not maintain a random number cache.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

SERVICE(service-number,load-module-name,FAIL(fail-option))

Indicates information about an installation-defined service.

ICSF allows an installation to define its own service similar to an ICSF callable service. The service-number specifies a number that identifies the service to ICSF. The valid service numbers are 1 through 32767, inclusive. This set of service numbers is valid for both installation-defined services and UDX services. The service number of an installation-defined service must not be the same as the service number of a UDX service. The load-module-name is the name of the module that contains the service. During ICSF startup, ICSF loads this module and binds it to the service-number you specified.

The fail-option is YES or NO, indicating the action ICSF should take if loading the service ends abnormally.

YES: Specifies that ICSF ends abnormally if your service cannot be loaded.
NO: Specifies that ICSF continues to start if your service cannot be loaded.

If the service itself ends abnormally, ICSF does not end, but takes a system dump instead. The ICSF service functional recovery routine (FRR) protects the service.

See Installation-defined Callable Services for a description of how to write and run an installation-defined callable service.

SERVICELIBS(YES or NO)

Indicates whether ICSF will be loaded using service data sets.

YES: Specifies that ICSF will be loaded using service data sets.
NO: Specifies that ICSF will not be loaded using service data sets and parameters SERVSCSFMOD0 and SERVSIEALNKE are ignored.

If the SERVICELIBS option is not specified, the default is SERVICELIBS(NO).

For more information about utilizing service libraries, see Dynamic service update.

SERVSCSFMOD0(dsn[,volser])

Specifies the name of the service data set to be used in a dynamic service update for SCSFMOD0. volser is optional. Must be specified in conjunction with SERVICELIBS(YES).

dsn: The data set name of the service data set.
volser: The volume of the service data set.

If the SERVSCSFMOD0 option is not specified, ICSF is initialized using LNKLST.

SERVSIEALNKE(dsn[,volser])

Specifies the name of the service data set to be used in a dynamic service update for SIEALNKE. volser is optional. Must be specified in conjunction with SERVICELIBS(YES).

dsn: The data set name of the service data set.
volser: The volume of the service data set.

If the SERVSIEALNKE option is not specified, ICSF is initialized using LNKLST.

Example:

SERVICELIBS(YES)
SERVSCSFMOD0(CSF.SCSFMOD0,VOL177)
SERVSIEALNKE(SYS1.SIEALNKE,CSFDR1)

SSM(YES or NO)

Specifies whether or not an installation can enable special secure mode (SSM) while running ICSF. SSM lowers the security of your system to let you enter clear keys and generate clear PINs. You must enable SSM for KGUP to permit generation or entry of clear keys and to enable the secure key import, secure key import2, multiple secure key import, or clear pin generate callable services.

YES: Indicates that you can enable the SSM.
NO: Indicates that you cannot enable the SSM.

If you do not specify the SSM option, the default value is SSM(NO).

The SSM option can be changed from NO to YES while ICSF is running by defining the CSF.SSM.ENABLE SAF profile within the XFACILIT resource class. To revert to your startup option, delete the CSF.SSM.ENABLE profile. The XFACILIT class must be refreshed after each change for it to take effect.

Note: When using the SAF profiles to set the SSM, all ICSF instances sharing the SAF database will be affected.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

When the CSF.SSM.ENABLE SAF profile is defined within the XFACILIT resource class, attempts to update the SSM option using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6) will be ignored. The SSM option value will be saved and used should the CSF.SSM.ENABLE SAF profile ever be deleted.

STATS(value1[,...,value3])

Enables usage tracking for various cryptographic statistics. Keywords may be combined to track multiple statistics.

ENG: Enables usage tracking of cryptographic engines. Supports Crypto Express cards, regional cryptographic servers, CPACF, and software.
SRV: Enables usage tracking of cryptographic services. Supports ICSF callable services and UDXes only.
ALG: Enables usage tracking of cryptographic algorithms. Supports cryptographic algorithms that are referenced in cryptographic operations. Limited support for key generation, key derivation, and key import.

For more information on the cryptographic utilization statistics monitoring, see z/OS Cryptographic Services ICSF Administrator's Guide.

STATSFILTERS(value)

Filters the criteria that is used to aggregate crypto usage statistics when STATS is enabled. Excluding this option means that ICSF uses all available criteria (that is, HOME job id, HOME job name, SECONDARY job name, HOME user id, task level user id, and ASID) to aggregate the crypto usage statistics.

NOTKUSERID: Excludes the task level user id from the stats aggregation criteria. Enable this option in environments that have a high volume of operations that are running under task level user ids. This option reduces the number of SMF records written.

For more information on the cryptographic utilization statistics monitoring, see z/OS Cryptographic Services ICSF Administrator's Guide.

SYSPLEXCKDS(YES or NO,FAIL(fail-option))

SYSPLEXCKDS(YES,FAIL(fail-option))

ICSF will join the ICSF sysplex group SYSICSF and this system will participate in sysplex-wide consistency for CKDS data.

SYSPLEXCKDS(YES,FAIL(YES)): Indicates ICSF initialization will end abnormally if the ICSF cross-system services environment cannot be established during ICSF initialization due to a failure creating the CKDS latch set or a failure to join the ICSF sysplex group.
SYSPLEXCKDS(YES,FAIL(NO)): Indicates ICSF initialization processing will continue even if the request to join the ICSF sysplex group fails. The system will not be notified of updates to the CKDS by other members of the ICSF sysplex group. A value of either FAIL(YES) or FAIL(NO) will be ignored with SYSPLEXCKDS(NO,...).

SYSPLEXCKDS(NO,FAIL(fail-option))

CKDS update processing proceeds as it does today (i.e. no Cross-System Services task will be initialized, nor will any XCF signalling be performed when an update to a CKDS record occurs).

If you do not specify the SYSPLEXCKDS option, the default value is SYSPLEXCKDS(NO,FAIL(NO)).

SYSPLEXPKDS(YES or NO,FAIL(fail-option))

ICSF will join the ICSF sysplex group SYSICSF and this system will participate in sysplex-wide consistency for PKDS data.

SYSPLEXPKDS(YES,FAIL(fail-option))

ICSF will join the ICSF sysplex group SYSICSFP and this system will participate in sysplex-wide consistency for PKDS data.

SYSPLEXPKDS(YES,FAIL(YES)): Indicates ICSF initialization will fail to join the sysplex if the ICSF cross-system services environment cannot be established during ICSF initialization due to a failure creating the PKDS latch set or a failure to join the ICSF sysplex group.
SYSPLEXPKDS(YES,FAIL(NO)): Indicates ICSF initialization processing will continue even if the request to join the ICSF sysplex group fails. The system will not be notified of updates to the PKDS by other members of the ICSF sysplex group. A value of either FAIL(YES) or FAIL(NO) will be ignored with SYSPLEXPKDS(NO,...).

SYSPLEXPKDS(NO,FAIL(fail-option))

PKDS update processing proceeds without trying to join the ICSF sysplex group.

If you do not specify the SYSPLEXPKDS option, the default value is SYSPLEXPKDS(NO,FAIL(NO)).

SYSPLEXTKDS(YES or NO,FAIL(fail-option))

ICSF will join the ICSF sysplex group SYSICSF and this system will participate in sysplex-wide consistency for TKDS data.

Note: TKDSN needs to be specified for this to work. See TKDSN(data-set-name).

SYSPLEXTKDS(NO,FAIL(fail-option)): Indicates no XCF signalling will be performed when an update to a TKDS record occurs.

SYSPLEXTKDS(YES,FAIL(fail-option))

Indicates the system will be notified of updates made to the TKDS by other members of the sysplex who have also specified SYSPLEXTKDS(YES,FAIL(fail-option)).

SYSPLEXTKDS(YES,FAIL(YES)): Indicates ICSF will terminate abnormally if there is a failure creating the TKDS latch set.
SYSPLEXTKDS(YES,FAIL(NO)): Indicates ICSF initialization processing will continue even if the request to join the ICSF sysplex group fails. This system will not be notified of updates to the TKDS by other members of the ICSF sysplex group.

If you do not specify the SYSPLEXTKDS option, the default value is SYSPLEXTKDS(NO,FAIL(NO)) is the default.

TKDSN(data-set-name)

The name of an existing TKDS or an empty VSAM data set to be used as the TKDS. To enable applications to create and use persistent PKCS #11 tokens and objects that use the PKCS #11 services, this option must be specified.

See Steps to create the installation options data set for the data set naming format requirements.

TRACEENTRY(n)

This keyword is no longer supported, but is tolerated.

UDX(UDX-id,service-number,load-module-name,'comment_text',FAIL(fail-option))

ICSF allows the development of User Defined Extensions for the coprocessors. The UDX-id is supplied to the installation when the UDX is developed. The service-number specifies a number that identifies the service to ICSF. The valid service numbers are 1 to 32767, inclusive. This set of service numbers is valid for both installation-defined services and UDX services. The service number of a UDX service must not be the same as the service number of an installation-defined service. The load-module-name is the name of the module that contains this service. During ICSF startup, ICSF loads this module and binds it to the service-number that was specified. A comment may be specified. The positional parameter is required. The comment consists of up to 40 EBCDIC characters, and may include imbedded blank characters. The comment text is enclosed by single quotes. If no comment text is desired, two contiguous single quotes should be specified.

The fail-option is YES or NO, indicating the action ICSF should take if loading the service ends abnormally. If the service itself ends abnormally, ICSF does not end, but takes a system dump instead.

YES: Specifies that ICSF ends abnormally if your service cannot be loaded.
NO: Specifies that ICSF continues to start if your service cannot be loaded.

The User Defined Extension (UDX) is responsible for logging in SMF the results of any authorization checks that were made.

USERPARM(value)

Specifies an 8-byte field for installation use. The Installation Option Display panel displays this value, which is stored in the Cryptographic Communication Vector Table (CCVT) in the CCVT_USERPARM field. An application program or installation exit can examine this field and use it to set system environment information. The default is eight blanks.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).

WAITLIST(data_set_name)

This optional parameter can be used if you have ICSF with CICS installed. It specifies a customer modifiable data set will be used to determine names of the services to be placed into the ICSF CICS Wait List. A sample data set is provided by ICSF via member CSFWTL01 of SYS1.SAMPLIB. The sample data set contains the same entries as the default ICSF CICS Wait List (i.e., the data set contains the names of all ICSF callable services which, by default, will be driven through the CICS TRUE). Non-CICS customers will not need to specify the WAITLIST keyword. The WAITLIST option should be added to the Installation Options data set under these conditions.

CICS customers who do not want to make use of CICS TRUE must either not enable the TRUE or must specify a WAITLIST keyword and point to an empty wait list data set (or specify WAITLIST(DUMMY)) in the Installation Options data set.
CICS customers who wish to modify the ICSF default CICS Wait List should modify the sample Wait List data set supplied in member CSFWTL01 of SYS1.SAMPLIB. The WAITLIST keyword in the Installation Options Data Set should be set to point to this modified data set.

To ensure maximum performance, any existing CICS applications which invoke any of the ICSF services in the Wait List that were linked with ICSF stubs prior to HCR7770 should be re-linked with the current ICSF stubs. For additional information on the CICS Attachment Facility, see CICS-ICSF Attachment Facility.

Starting with ICSF FMID HCR77C0, the value for this option can be updated without restarting ICSF by using either the SETICSF command or the ICSF Multi-Purpose service (CSFMPS or CSFMPS6).