RTCS initialization member
This topic presents the contents of the RTCS initialization member.
RTCS initialization member
+----------------------------------------------------------------------+
| |
| Runtime Component System (RTCS) Initialization Parameters |
| |
|- VENDOR_IDENTIFICATION --------------------------------------------- |
| |
| VENDOR: BMC Software, Inc. |
| COPYRIGHT: NONE. Intended to be copied to SYS1.PARMLIB(OSZINI00) |
| or some other member and/or Logical PARMLIB data set, |
| configured and commented by the customer as required. |
| |
|- PRODUCT_IDENTIFICATION -------------------------------------------- |
| |
| PRODUCT_NAME: RTCS COMPONENT_ID: KERNEL |
| PRODUCT_FMID: ZOSZ310 DIAGNOSIS_PIDS: ZOSZ-310 |
| CURRENT_RMID: BP00526 LAST_UPDATE: 11/08/23 |
| |
|- MEMBER_DESCRIPTION ------------------------------------------------ |
| |
| MEMBER: OSZPARMS.jcl Source management system file name |
| OSZ$PARM Distributed in SMP/E DLIB .DOSZCNTL |
| OSZ$PARM Installed into SMP/E TLIB .TOSZCNTL |
| OSZINI00 Customized in z/OS Logical PARMLIB |
| |
| STATUS: Product installation/customer configuration material |
| |
| CONTENTS: Sample Logical PARMLIB RTCS Initialization Member |
| |
|- USAGE_NOTES ------------------------------------------------------- |
| |
| 1. OSZ$PARM is customized by the installation and then |
| copied into a z/OS image Logical PARMLIB data set |
| (usually DSN=SYS1.PARMLIB). The RTCS Initiator will |
| attempt to locate and read the RTCS Initialization |
| Parameters member from an MVS Logical PARMLIB data |
| set (or SYS1.PARMLIB if no MVS image-specific data |
| set has been established). |
| |
| 2. The default member name is OSZINI00, which can be |
| changed by specifying the INI=nn parameter in the |
| RTCS Initiator START command parameter field (the |
| 4th positional parameter). For example: |
| |
| START OSZINIT,,,(INI=42),SUB=MSTR |
| |
| 3. Initialization Statement Syntax Rules |
| |
| A. Statements are free-form, but do not flow from |
| one line to the next. Individual tokens must be |
| contained wholly on one line. |
| |
| B. Columns 1-72 are used. Columns 73-80 are ignored. |
| |
| C. Comments begin with "/*" and extend to the end of |
| the line. It is not necessary (but is recommended) |
| to close such comments with a "*/" should this be |
| supported in the future. |
| |
| D. Lines that begin with * | + = ; in column 1 are |
| treated as comments. While all comments will be |
| ignored, comment lines that begin with a "=" in |
| column 1 will be listed on SYSLOG IF the "LIST=Y" |
| parameter is specified when the RTCS Initiator is |
| started. For example: |
| |
| START OSZINIT,,,(LIST=Y),SUB=MSTR |
| START OSZINIT,,,(LIST=Y,INI=42),SUB=MSTR |
| |
| MVS requires that the commas and the enclosing |
| parentheses be specified. The parameter field |
| on the MVS operator START command is the fourth |
| positional parameter. |
| |
| E. MVS system symbolic parameters such as &SYSNAME |
| may be used and will be expanded automatically. |
| |
| F. Parameters take two forms: FLAGs and OPTIONs. |
| |
| G. FLAG parameters are binary options that are |
| either set ON (i.e., positive) or set OFF |
| (i.e., negative). To specify the negation |
| of a FLAG parameter, simply prefix the name |
| of the parameter with 'NO'. For example, if |
| 'SUMMARY' were a defined and supported FLAG |
| parameter, then to indicate the opposite of |
| whatever that was defined to mean you would |
| specify 'NOSUMMARY' instead. |
| |
| H. OPTION parameters take a value specification |
| that follows an "=" sign after the name of |
| the option. For example, to specify the value |
| of the (character-valued) option named MONTH, |
| you could use the following statement: |
| |
| MONTH = December |
| |
| I. Multiple OPTIONs and FLAGs can appear on any |
| one line. For example: |
| |
| SUMMARY MONTH=December TYPE=Wide DAYS=0 |
| |
| J. FLAG and OPTION names are simply contiguous |
| strings of characters with no embedded blanks. |
| Except for certain punctuation characters, |
| of which more will be said later, virtually |
| any EBCDIC character can be specified. Only |
| a blank terminates the FLAG or OPTION name, |
| and an OPTION value. |
| |
| K. OPTION values may be numeric or character. |
| |
| L. A numeric-valued OPTION must have valid |
| decimal numerals specified for its value. |
| |
| M. A character-valued OPTION may have blanks |
| embedded in its value by enclosing the |
| value either in apostrophes ('value 1') or |
| in quotation marks (" odd string no. 2"). |
| |
| N. A character-valued OPTION may be given a |
| hexadecimal value of any length (up to the |
| maximum that can fit on one card) by using |
| the following syntax: |
| |
| KEY = 'F4BF96DE69421388'X BYTE = '42'X |
| |
| O. FLAG and OPTION names are case-sensitive, |
| as are OPTION values. No lower or mixed- |
| case FLAGs or OPTIONs are currently defined. |
| All FLAGs and OPTIONs must be specified in |
| upper case. The natural case of most OPTION |
| values is upper. For example, all data set |
| name OPTIONs must specify the DSNAME value |
| in upper case. RTCS does NOT automatically |
| convert a DSNAME to upper case (nor any |
| other OPTION value, for that matter). |
| |
+----------------------------------------------------------------------+
== Runtime Component System (RTCS) Initialization Parameters ==
+-------------------------------------+
| OSZINIT PROC Required DD Statements |
+-------------------------------------+
| //STEPLIB RTCS Subsystem Program Library (.TOSZRTCS, or a copy)
+-------------------------------------+
| OSZINIT PROC Optional DD Statements |
+-------------------------------------+
| //PARMLIB Initialization Parameter Partitioned Data Set
|
| If no //PARMLIB DD statement is present, then the MVS
| MVS Logical PARMLIB data set / concatenation is used.
|
| RTCS initialization parameters will be obtained from
| member name "OSZINI00" by default. This member name
| can be changed by indicating a different member name
| suffix, or a completely different member name, using
| either the INI=nn or the MBR=member option in the 4th
| positional parameter of the START command itself. For
| example, to cause the RTCS initialization parameters
| to be read from member name OSZINI22, either of the
| following START commands could be used:
|
| START OSZINIT,,,(INI=22),SUB=MSTR
| START OSZINIT,,,(MBR=OSZINI22,LIST=Y),SUB=MSTR
|
| The member name does not have to begin with 'OSZINI'.
| The MBR=name parameter in the START command parameter
| field specifies the complete member name of the RTCS
| RTCS initialization parameters member:
|
| START OSZINIT,,,(MBR=OSZPARMS,LIST=N),SUB=MSTR
|
+----------------------------------------------------------------------+
| RTCS Initialization Parameters in Logical PARMLIB member 'OSZINIxx' |
| which are used by the RTCS Initiator, PROC OSZINIT (PGM=OSZSIRIS). |
+----------------------------------------------------------------------+
*
* MVS Subsystem Name to be used by the RTCS Subsystem.
*
+ SSID=RTCS
|
| The MVS Subsystem Name (SSID, or Subsystem ID) that is to
| be used by the RTCS Subsystem address space (OSZRTCS).
*
* Installation Verification Procedure (IVP) Mode
*
NOIVP /* [NO]IVP */
|
| In IVP mode, the RTCS Initiator performs all
| normal parameter verification and processing
| but does not START the RTCS Subsystem address
| space. IVP mode can also be specified in the
| parameter field (the 4th positional parameter)
| of the RTCS Initiator START command, as follows:
|
| START OSZINIT,,,(IVP=Y,LIST=Y)
|
| If IVP mode is requested on the START command,
| a specification of NOIVP in the Logical PARMLIB
| member will NOT disable IVP mode. Once IVP mode
| is in effect (either from the START command or
| from this member), it cannot then be disabled by
| specifying NOIVP (in this member).
|
*
* RTCS Subsystem address space started task PROC name.
*
+ OSZRTCS-PROC=OSZRTCS
|
| If not specified, then the default is the same PROC
| name that was used to start the RTCS initiator with
| 'RTCS' substituted for 'INIT', provided that 'INIT'
| appears in the RTCS Initiator PROC name. Else the
| default is OSZRTCS.
*
* RTCS Generalized Server started task PROC name.
*
+ OSZEXEC-PROC=OSZEXEC
|
| If not specified, the default is the RTCS Subsystem
| PROC name with 'EXEC' substituted for 'RTCS',
| provided that 'RTCS' appears in the RTCS Subsystem
| PROC name. Else the default is OSZEXEC.
*
* RTCS Product Program Library (.TOSZLINK, or a copy)
*
+ POSZLINK=
|
| If not specified, then this value will default to
| STEPLIB-DSName-prefix.[xosz]LINK, provided that the
| low-level qualifier of //STEPLIB is '.[xosz]RTCS'.
| Else the default is the same DSNAME as //STEPLIB.
*
* DSNAME of RTCS SYSTEM Registry VSAM Linear Data Set (VLDS)
*
+ SREGVLDS=SYS2.&SYSPLEX..RTCS.SYSTEM.REGISTRY
|
| If not specified, then this value will default to
| STEPLIB-DSName-prefix.REGISTRY, provided that the
| low-level qualifier of //STEPLIB is '.[xosz]RTCS'.
| Otherwise, there is no default, and this parameter
| must be specified.
|
| The SYSTEM Registry contains configuration data for
| RTCS, the BMC AMI Ops CAS, RTCS-based products, and
| RTCS-dependent products that have elected to use it.
| It must be a VSAM Linear Data Set (VSAM LDS or VLDS).
|
| The Registry data set MUST be cataloged, since it is
| a VSAM cluster. It is allocated using only its DSNAME.
| The SYSTEM Registry VSAM LDS is read/write and cannot
| physically be shared, although it may be allocated on
| shared DASD. Only one RTCS Subsystem will be able to
| allocate a VSAM LDS for use as a Registry because it
| will be allocated DISP=OLD as required by the MVS DIV
| service.
|
| But the data in the SYSTEM Registry VLDS can be shared
| among members of a Sysplex using XCF. When the SYSTEM
| Registry is being shared among RTCS Subsystems running
| in a Sysplex, then only one RTCS Subsystem will have
| dynamically allocated the Registry VLDS. That system
| is called the Local Owner. Other systems can access
| data in the Registry (which is allocated to the Local
| Owner) using XCF to transmit requests and retrieve the
| requested data in response. An RTCS Subsystem that is
| accessing data in the SYSTEM Registry on the Local
| Owner via XCF is termed a Remote [Registry instance].
|
| It is not recommended, but it is possible to have a
| private, dedicated SYSTEM Registry VLDS for each RTCS
| Subsystem. But the BMC AMI Ops CAS will not be able to
| share data with other CASs in the Sysplex if you do.
|
| The first time an RTCS Subsystem becomes the Local
| Owner of the VLDS and encounters a newly-allocated,
| uninitialized, never-before-used Linear Data Set,
| the RTCS Subsystem will initialize the contents of
| the Registry, populating it with all the structures
| required for RTCS Subsystem components and products.
|
*
* SYSTEM Registry DIV Services Default Performance Parameters
*
DIV-SAVE-MINIMUM = 1 /* DIV Services interval 1: minimum */
DIV-SAVE-MAXIMUM = 6 /* DIV Services interval 2: maximum */
DIV-SAVE-LIMIT = 4000 /* DIV Services batch update limit */
|
| The above parameters indicate the time that the Registry
| DIV Services subtask will wait prior to requesting that
| changes to the SYSTEM Registry data space be hardened in
| the backing VSAM LDS. After the VLDS is updated, it will
| wait a minimum amount of time before the next request to
| update the VLDS will again be made, but no longer than
| the indicated maximum (after which a VLDS update will be
| forced).
| The amount of time that pending Registry VLDS updates are
| delayed is heuristically determined according to request
| frequency and arrival pattern, and will never less than
| the indicated minimum value, nor greater than the maximum.
| Regardless of the enforced minimum and maximum intervals
| that will cause the VLDS to be updated, if the number of
| changes exceeds the specified limit then the backing VLDS
| will be updated, hardening all pending changes on DASD.
|
| A MINIMUM interval of zero (0) indicates that all changes
| to the SYSTEM Registry are to be immediately hardened in
| the backing VSAM LDS, without waiting or attempting to
| batch multiple changes together into a single update. We
| recommend that you do NOT specify DIV-SAVE-MINIMUM = 0.
*
* RTCS SYSTEM Registry Sysplex Sharing Parameters
* -----------------------------------------------
*
+ REGISTRY-XCF-GROUP = OSZRTCSR /* SYSTEM Registry XCF Group Name */
/* This parameter will be used only */
/* if some form of Sysplex Registry */
/* Sharing (see below) is specified.*/
ELIGIBLE-OWNER /* This member is ELIGIBLE to */
/* ALLOCATE (and then EXPOSE) */
/* the SYSTEM Registry VLDS. */
/* RTCS Subsystem XCF members which */
/* are not eligible to own the RTCS */
/* SYSTEM Registry VLDS will not be */
/* able to assist in recovery when */
/* the image that does own the */
/* Registry fails for any reason. */
/* */
/* RTCS Subsystems on small or */
/* slow MVS images should only */
/* remotely access an exposed */
/* SYSTEM Registry and should */
/* not be eligible to allocate */
/* and expose/own the Registry. */
*
* RTCS SYSTEM Registry Sysplex Sharing Options
* --------------------------------------------
*
| The following five options are mutually exclusive. Only
| one of them should be specified without the 'NO' prefix.
| The other four may be omitted (or specified with the 'NO'
| prefix as illustrated below). If more than one positive
| [not prefixed with 'NO'] option is specified, then the
| most restrictive one will become effective. The Registry
| sharing options are listed below in that precedence order
| (the most restrictive first, the least restrictive last).
| In other words, the first (in the order they are listed
| below) positive (not prefixed with 'NO') option specified
| is the one that will be effective and override any others.
+-------------------------+ +------------------------------------+
| SYSTEM Registry Sysplex | | Meaning of positive FLAG parameter |
| Sharing Parameter FLAG. | | value (when not prefixed by "NO"). |
+-------------------------+ +------------------------------------+
NOPRIVATE-REGISTRY /* Exclusively allocate the SYSTEM */
/* Registry VLDS on this image but */
/* do not establish any capability */
/* to share it with other images. */
/* The Registry cannot subsequently */
/* be exposed to other MVS images. */
/* If the SYSTEM Registry VLDS can */
/* not be allocated DISP=OLD, then */
/* RTCS initialization will fail. */
NOALLOC-REGISTRY /* ALLOCate the SYSTEM Registry on */
/* this MVS image, but do not (yet) */
/* EXPOSE it for the REMOTE images */
/* to be able to CONNECT to it. It */
/* can be exposed at a later time */
/* via an RTCS operator command. */
/* If the SYSTEM Registry VLDS can */
/* not be allocated DISP=OLD, then */
/* RTCS initialization will fail. */
NOEXPOSE-REGISTRY /* ALLOCATE and EXPOSE the SYSTEM */
/* Registry on this MVS image. */
/* If the SYSTEM Registry VLDS can */
/* not be allocated DISP=OLD, then */
/* RTCS initialization will fail. */
SHARED-REGISTRY /* Setup a REMOTE Registry on this */
/* MVS image, then CONNECT to the */
/* SYSTEM Registry if it is already */
/* EXPOSEd on another MVS image. */
/* If the Registry is not already */
/* EXPOSEd, then (if it has not yet */
/* been ALLOCated) ALLOCATE and */
/* EXPOSE the SYSTEM Registry on */
/* this MVS image (if possible). */
/* If the SYSTEM Registry VLDS can */
/* not be allocated DISP=OLD or if */
/* this system is unable to CONNECT */
/* to an already-EXPOSEd Registry */
/* on some other MVS image, then */
/* RTCS initialization will fail. */
NOREMOTE-REGISTRY /* CONNECT to a SYSTEM Registry */
/* that has already been EXPOSEd */
/* on another MVS image. If this */
/* system is unable to CONNECT to */
/* an EXPOSEd SYSTEM Registry, then */
/* RTCS initialization will fail. */
+--------------------------------------------------------------------+
| |
| RTCS Data Compression Component Parameters |
| |
| The RTCS Data Compression Facility can optionally be |
| enabled for use by the RTCS Registry Component when |
| a Registry is being shared among members of a Sysplex |
| using XCF. This applies to the RTCS Subsystem SYSTEM |
| Registry and to product-specific Registry instances. |
| |
| When any of the supported data compression algorithms |
| or mechanisms are enabled, all Sysplex-shared Registry |
| instances will be eligible to use the Data Compression |
| facility to compress Registry data to be returned from |
| the Local Owner to REMOTE Registry instances (provided |
| Data Compression is enabled for the RTCS Subsystem for |
| both systems). In other words, RTCS Data Compression |
| must be enabled on the system where the Local Owning |
| Registry instance exists, as well as on the system |
| where the REMOTE Registry instance exists, or no data |
| compression will be possible. |
| |
+--------------------------------------------------------------------+
*
* Data Compression Facility Algorithm/Mechanism Enablement
*
+ COMPRESS-ALL /* [NO]COMPRESS-ALL */
|
|
| NOTE: NOCOMPRESS-ALL is the current default value for
| this flag parameter. Specify COMPRESS-ALL if you want
| to enable data compression for RTCS Registry instances.
|
|
| - if NOCOMPRESS-ALL is specified:
|
| ALL compression algorithms (mechanisms) are disabled.
| The RTCS Registry Component will not be eligible to
| send or receive Registry data for Registry instances
| established on this MVS system.
|
| - if COMPRESS-ALL is specified:
|
| ALL compression algorithms (mechanisms) will be able
| to be used by the RTCS Registry Component on this MVS
| system. Those that can actually be used depend upon
| the MVS systems hardware and software configuration.
| The RTCS Registry Component will select an available
| data compression mechanism that has been enabled on
| both MVS systems where the Registry instances are
| executing.
|
+--------------------------------------------------------------------+
| |
| RTCS External Security Manager Component Parameters |
| |
+--------------------------------------------------------------------+
*
* External Security Manager (ESM) Type
*
+ ESMTYPE=AUTO
|
| External Security Manager (ESM) that is in
| use on this MVS image and which RTCS is to
| interface with. The default, and the value
| which most installations should specify, is
| AUTO. RTCS is usually able to determine the
| ESM that is being used on an MVS image, but
| under certain circumstances, it cannot do so.
| If this situation occurs, you may explicitly
| indicate which ESM is (or will be) used on
| this MVS image using the ESMTYPE= parameter.
|
| ESMTYPE= Description
| -------- -----------
| AUTO RTCS is to automatically determine,
| if possible, which ESM is in use.
| RACF RTCS is to assume RACF will be used.
| ACF2 RTCS is to assume ACF2 will be used.
| TSS RTCS is to assume TSS (Top Secret)
| will be used.
|
*
* Accept or reject attempts to use undefined ESM User IDs
*
+ UNDEFINEDUSERINHERIT=ACCEPT
|
+ UNDEFINEDUSERSIGNON=REJECT
|
| These two parameters specify the behavior
| when an undefined ESM User ID is provided
| (either by an end user or an application)
| as part of original system entry signon,
| or when attempting to inherit credentials
| on this image from an existing environment.
|
| The following values can be specified:
|
| Action Description
| ------ -----------
| ACCEPT RTCS is to allow the INHERIT or the
| SIGNON to proceed. RTCS or the ESM
| will provide a default User ID for
| the security environment that will
| be created as a consequence.
| REJECT RTCS is disallow the INHERIT or the
| SIGNON.
|
| By default, RTCS allows INHERITs to proceed,
| since it would then be assumed that the User
| ID being presented was at least valid in the
| Sysplex or CASplex somewhere, and disallows
| SIGNONs with an undefined User ID, since it
| is usually the case that an invalid User ID
| (that is, one that is not defined) is never
| to be allowed.
*
* Default ESM User ID used in place of an undefined one
*
+ DEFAULTUSERID=' '
|
| This parameter specifies the ESM User ID that
| is to be substituted for an undefined/invalid
| User ID presented for authentication, and the
| UNDEFINEDUSERINHERIT or the UNDEFINEDUSERSIGNON
| option, as appropriate, specifies ACCEPT, which
| indicates that the INHERIT or the SIGNON is to
| be allowed. The value of this parameter should
| usually be set to blanks, which triggers ESM-
| specific behavior to generate its own default
| User ID (USER, LOGONID, or ACID) according to
| well-documented ESM behavior or if allowed by
| ESM-specific security options and parameters.
*
* How to process GROUP IDENT credential during an INHERIT
*
+ GROUPINHERIT=ALWAYS
|
| This parameter specifies how the GROUP IDENT
| credential (GROUP name) is to be processed
| when a security identity is being INHERITed.
|
| The following values can be specified:
|
| Action Description
| ------ -----------
| ALWAYS RTCS is to pass the GROUP IDENT to
| the ESM unchanged. In order to be
| successful, the ESM must allow the
| use of that specific GROUP IDENT.
| In the case of RACF, specifically,
| this means that the User ID being
| INHERITed must be CONNECTed to the
| same, exact GROUP IDENT specified
| in the credentials in the RACF data
| base being used on this system image.
| NEVER RTCS is to ignore any specification
| of a GROUP IDENT (GROUP name) in the
| authentication credentials presented
| when attempting to INHERIT a User ID.
|
*
* ESM Security Interface diagnostic tracing
*
+ SECTRACE=NONE
|
| This parameter specifies the default level of
| diagnostic tracing that is to be performed for
| the RTCS External Security Manager interface.
|
| The following values can be specified:
|
| Action Description
| ------ -----------
| NONE No ESM interface tracing is to be done.
| SIMPLE Issue only simple trace messages.
| EXTENDED Extended tracing is to be performed.
| COMPLETE Complete tracing is to be performed.
|
| Security diagnostic tracing can be activated
| dynamically via an RTCS operator command, so
| NONE should normally be specified. However,
| if there is a need to perform ESM diagnostic
| tracing during RTCS initialization, this can
| be initially activated using this parameter.
|
*
* ESM SAF Subsystem (RACROUTE SUBSYS) to be used by RTCS
*
+ SAFSUBSYS=&SSID
|
| This parameter specifies the RACROUTE SUBSYS
| (SAF Subsystem ID) that is to be used by the
| RTCS Security Manager. Specifying this value
| is usually not required. But when using a
| recent release of ACF2 on a system that was
| customized before ACF2 Release 6.0 for use
| with the BMC AMI Ops Enhanced Security
| Interface to recognize and process RACROUTE
| invocations using a specific SAF SUBSYS
| value, such as 'BBI3', then that value might
| need to be specified here.
|
| The following values can be specified:
|
| SAFSUBSYS Description
| --------- -----------
| &SSID The MVS SSID that was specified in
| this initialization member, or was
| provided as a default by RTCS.
| &PRODUCT The internal (security) product
| name in whose product address space
| an ESM security environment is being
| created (via SIGNON or INHERIT).
| '' or ' ' Null, or one or more blanks: No
| SUBSYS= parameter is to be used
| on any SAF RACROUTE invocation.
| 'xxxxxxxx' A specific RACROUTE SUBSYS= value,
| consisting of up to 8 characters.
|
| Under most circumstances, RACF and Top Secret
| will effectively ignore the RACROUTE SUBSYS=
| specification. However, a value may still be
| usefully provided here, since the SUBSYS can
| be used to filter requests to be traced when
| using the Top Secret SECTRACE facility (as
| well as the ACF2 SECTRACE facility), and to
| subset RACROUTE requests to be traced if an
| IBM or OEM vendor facility (using RACF exits)
| has been installed to facilitate such tracing.
| So, a suitable value should be provided, even
| if RACF or TSS is in use, simply in support
| of any existing ESM-level diagnostic tracing
| facility.
|
*
* Default ESM RACROUTE system entry validation APPL ID
*
+ SECURITYAPPLID=&PRODUCT
|
| This parameter specifies the RACROUTE APPL
| (application name) that is to be used as the
| default SAF APPLication by the RTCS Security
| Manager (if none is specified by the product
| or the caller does not have an RTCS product
| definition, or the definition in the product
| or SYSTEM Registry is null or blanks).
|
| The following values can be specified:
|
| SAFSUBSYS Description
| --------- -----------
| &SSID The MVS SSID that was specified in
| this initialization member, or was
| provided as a default by RTCS.
| &PRODUCT The internal (security) product
| name in whose product address space
| an ESM security environment is being
| created (via SIGNON or INHERIT) or
| a resource being authorized.
| &PRDAPPL The default product security APPL
| name, usually specified in the
| RTCS product definition in the
| package, or via the RTCS SYSTEM
| Registry product, context, or
| server (instance) definition.
| '' or ' ' Null, or one or more blanks: No
| APPL= parameter is to be used
| on any SAF RACROUTE invocation.
| 'xxxxxxxx' A specific RACROUTE APPL= value,
| consisting of up to 8 characters.
|
*
* Security domain
*
+ SDOMAIN=
|
| This parameter specifies the security domain for
| this RTCS instance. The security domain can be
| used to differentiate between different ESM
| instances where user identity is different because
| they do not share the same ESM type or definitions.
|
| When a different security domain is detected RTCS
| will attempt to resolve the user's identity using
| the ESM's distributed identity function by
| creating the user name filter and registry name
| filter based on the user's previously authenticated
| security identity extracted from another security
| identity. The resolution of the user name filter
| is defined by the DIDUN= parameter. The resolution
| of the registry name filter is defined by the
| DIDRN= parameter.
|
| If no security domain is specified then a default
| value of ++++++++ is set by RTCS. A default
| security domain disables distributed identity
| because RTCS will not attempt to authenticate a
| user with the distributed identity function when
| the default security domain has been detected.
|
| The security domain can be from 1 to 8 characters.
|
*
* Distributed identity user name rules string
*
+ DIDUN=
|
| This parameter specifies the distributed identity
| user name rules string. The rules string is used
| to construct the distributed identity user name
| filter. The user name filter will be passed by
| RTCS to the ESM when authenticating a user with
| the user's distributed identity.
|
| If no distributed identity user name is specified
| then the default value of * will be set by RTCS
| when constructing the distributed identity user
| name filter.
|
| The rules string can be from 1 to 64 characters.
|
| The symbols for the user name are as follows:
| &EXTUSER, &INTUSER, &GROUP, &SNAME, &SPLEX, &SSDMN
|
| When RTCS resolves the rules string the symbols
| will be replaced as follows:
| &EXTUSER will use the external user id.
| &INTUSER will use the internal user id.
| &GROUP will use the group value.
| &SNAME will use the system value.
| &SPLEX will use the sysplex value.
| &SSDMN will use the security domain.
|
| When constructing a X.500 format user name filter
| a period <.> must be specified before a comma <,>
| that denotes the next X.500 pair.
|
| For example DIDUN="UID=&EXTUSER.,SYSTEM=&SNAME"
|
*
* Distributed identity registry name rules string
*
+ DIDRN=
|
| This parameter specifies the distributed identity
| registry name rules string. The rules string is
| used to construct the distributed identity registry
| name filter. The registry name filter will be
| passed by RTCS to the ESM when authenticating a
| user with the user's distributed identity.
|
| If no distributed identity registry name is
| specified then the default value of * will be set
| by RTCS when constructing the distributed identity
| registry name filter.
|
| The rules string can be from 1 to 64 characters.
|
| The symbols for the registry name are as follows:
| &EXTUSER, &INTUSER, &GROUP, &SNAME, &SPLEX, &SSDMN
|
| When RTCS resolves the rules string the symbols
| will be replaced as follows:
| &EXTUSER will use the external user id.
| &INTUSER will use the internal user id.
| &GROUP will use the group value.
| &SNAME will use the system value.
| &SPLEX will use the sysplex value.
| &SSDMN will use the security domain.
|
| When constructing a X.500 format registry name
| filter a period <.> must be specified before a
| comma <,> that denotes the next X.500 pair.
|
| For example DIDRN="SYSTEM=&SNAME.,PLEX=&SPLEX"
|
== Runtime Component System (RTCS) Initialization Parameters ==
| |
| Runtime Component System (RTCS) Initialization Parameters |
| |
|- VENDOR_IDENTIFICATION --------------------------------------------- |
| |
| VENDOR: BMC Software, Inc. |
| COPYRIGHT: NONE. Intended to be copied to SYS1.PARMLIB(OSZINI00) |
| or some other member and/or Logical PARMLIB data set, |
| configured and commented by the customer as required. |
| |
|- PRODUCT_IDENTIFICATION -------------------------------------------- |
| |
| PRODUCT_NAME: RTCS COMPONENT_ID: KERNEL |
| PRODUCT_FMID: ZOSZ310 DIAGNOSIS_PIDS: ZOSZ-310 |
| CURRENT_RMID: BP00526 LAST_UPDATE: 11/08/23 |
| |
|- MEMBER_DESCRIPTION ------------------------------------------------ |
| |
| MEMBER: OSZPARMS.jcl Source management system file name |
| OSZ$PARM Distributed in SMP/E DLIB .DOSZCNTL |
| OSZ$PARM Installed into SMP/E TLIB .TOSZCNTL |
| OSZINI00 Customized in z/OS Logical PARMLIB |
| |
| STATUS: Product installation/customer configuration material |
| |
| CONTENTS: Sample Logical PARMLIB RTCS Initialization Member |
| |
|- USAGE_NOTES ------------------------------------------------------- |
| |
| 1. OSZ$PARM is customized by the installation and then |
| copied into a z/OS image Logical PARMLIB data set |
| (usually DSN=SYS1.PARMLIB). The RTCS Initiator will |
| attempt to locate and read the RTCS Initialization |
| Parameters member from an MVS Logical PARMLIB data |
| set (or SYS1.PARMLIB if no MVS image-specific data |
| set has been established). |
| |
| 2. The default member name is OSZINI00, which can be |
| changed by specifying the INI=nn parameter in the |
| RTCS Initiator START command parameter field (the |
| 4th positional parameter). For example: |
| |
| START OSZINIT,,,(INI=42),SUB=MSTR |
| |
| 3. Initialization Statement Syntax Rules |
| |
| A. Statements are free-form, but do not flow from |
| one line to the next. Individual tokens must be |
| contained wholly on one line. |
| |
| B. Columns 1-72 are used. Columns 73-80 are ignored. |
| |
| C. Comments begin with "/*" and extend to the end of |
| the line. It is not necessary (but is recommended) |
| to close such comments with a "*/" should this be |
| supported in the future. |
| |
| D. Lines that begin with * | + = ; in column 1 are |
| treated as comments. While all comments will be |
| ignored, comment lines that begin with a "=" in |
| column 1 will be listed on SYSLOG IF the "LIST=Y" |
| parameter is specified when the RTCS Initiator is |
| started. For example: |
| |
| START OSZINIT,,,(LIST=Y),SUB=MSTR |
| START OSZINIT,,,(LIST=Y,INI=42),SUB=MSTR |
| |
| MVS requires that the commas and the enclosing |
| parentheses be specified. The parameter field |
| on the MVS operator START command is the fourth |
| positional parameter. |
| |
| E. MVS system symbolic parameters such as &SYSNAME |
| may be used and will be expanded automatically. |
| |
| F. Parameters take two forms: FLAGs and OPTIONs. |
| |
| G. FLAG parameters are binary options that are |
| either set ON (i.e., positive) or set OFF |
| (i.e., negative). To specify the negation |
| of a FLAG parameter, simply prefix the name |
| of the parameter with 'NO'. For example, if |
| 'SUMMARY' were a defined and supported FLAG |
| parameter, then to indicate the opposite of |
| whatever that was defined to mean you would |
| specify 'NOSUMMARY' instead. |
| |
| H. OPTION parameters take a value specification |
| that follows an "=" sign after the name of |
| the option. For example, to specify the value |
| of the (character-valued) option named MONTH, |
| you could use the following statement: |
| |
| MONTH = December |
| |
| I. Multiple OPTIONs and FLAGs can appear on any |
| one line. For example: |
| |
| SUMMARY MONTH=December TYPE=Wide DAYS=0 |
| |
| J. FLAG and OPTION names are simply contiguous |
| strings of characters with no embedded blanks. |
| Except for certain punctuation characters, |
| of which more will be said later, virtually |
| any EBCDIC character can be specified. Only |
| a blank terminates the FLAG or OPTION name, |
| and an OPTION value. |
| |
| K. OPTION values may be numeric or character. |
| |
| L. A numeric-valued OPTION must have valid |
| decimal numerals specified for its value. |
| |
| M. A character-valued OPTION may have blanks |
| embedded in its value by enclosing the |
| value either in apostrophes ('value 1') or |
| in quotation marks (" odd string no. 2"). |
| |
| N. A character-valued OPTION may be given a |
| hexadecimal value of any length (up to the |
| maximum that can fit on one card) by using |
| the following syntax: |
| |
| KEY = 'F4BF96DE69421388'X BYTE = '42'X |
| |
| O. FLAG and OPTION names are case-sensitive, |
| as are OPTION values. No lower or mixed- |
| case FLAGs or OPTIONs are currently defined. |
| All FLAGs and OPTIONs must be specified in |
| upper case. The natural case of most OPTION |
| values is upper. For example, all data set |
| name OPTIONs must specify the DSNAME value |
| in upper case. RTCS does NOT automatically |
| convert a DSNAME to upper case (nor any |
| other OPTION value, for that matter). |
| |
+----------------------------------------------------------------------+
== Runtime Component System (RTCS) Initialization Parameters ==
+-------------------------------------+
| OSZINIT PROC Required DD Statements |
+-------------------------------------+
| //STEPLIB RTCS Subsystem Program Library (.TOSZRTCS, or a copy)
+-------------------------------------+
| OSZINIT PROC Optional DD Statements |
+-------------------------------------+
| //PARMLIB Initialization Parameter Partitioned Data Set
|
| If no //PARMLIB DD statement is present, then the MVS
| MVS Logical PARMLIB data set / concatenation is used.
|
| RTCS initialization parameters will be obtained from
| member name "OSZINI00" by default. This member name
| can be changed by indicating a different member name
| suffix, or a completely different member name, using
| either the INI=nn or the MBR=member option in the 4th
| positional parameter of the START command itself. For
| example, to cause the RTCS initialization parameters
| to be read from member name OSZINI22, either of the
| following START commands could be used:
|
| START OSZINIT,,,(INI=22),SUB=MSTR
| START OSZINIT,,,(MBR=OSZINI22,LIST=Y),SUB=MSTR
|
| The member name does not have to begin with 'OSZINI'.
| The MBR=name parameter in the START command parameter
| field specifies the complete member name of the RTCS
| RTCS initialization parameters member:
|
| START OSZINIT,,,(MBR=OSZPARMS,LIST=N),SUB=MSTR
|
+----------------------------------------------------------------------+
| RTCS Initialization Parameters in Logical PARMLIB member 'OSZINIxx' |
| which are used by the RTCS Initiator, PROC OSZINIT (PGM=OSZSIRIS). |
+----------------------------------------------------------------------+
*
* MVS Subsystem Name to be used by the RTCS Subsystem.
*
+ SSID=RTCS
|
| The MVS Subsystem Name (SSID, or Subsystem ID) that is to
| be used by the RTCS Subsystem address space (OSZRTCS).
*
* Installation Verification Procedure (IVP) Mode
*
NOIVP /* [NO]IVP */
|
| In IVP mode, the RTCS Initiator performs all
| normal parameter verification and processing
| but does not START the RTCS Subsystem address
| space. IVP mode can also be specified in the
| parameter field (the 4th positional parameter)
| of the RTCS Initiator START command, as follows:
|
| START OSZINIT,,,(IVP=Y,LIST=Y)
|
| If IVP mode is requested on the START command,
| a specification of NOIVP in the Logical PARMLIB
| member will NOT disable IVP mode. Once IVP mode
| is in effect (either from the START command or
| from this member), it cannot then be disabled by
| specifying NOIVP (in this member).
|
*
* RTCS Subsystem address space started task PROC name.
*
+ OSZRTCS-PROC=OSZRTCS
|
| If not specified, then the default is the same PROC
| name that was used to start the RTCS initiator with
| 'RTCS' substituted for 'INIT', provided that 'INIT'
| appears in the RTCS Initiator PROC name. Else the
| default is OSZRTCS.
*
* RTCS Generalized Server started task PROC name.
*
+ OSZEXEC-PROC=OSZEXEC
|
| If not specified, the default is the RTCS Subsystem
| PROC name with 'EXEC' substituted for 'RTCS',
| provided that 'RTCS' appears in the RTCS Subsystem
| PROC name. Else the default is OSZEXEC.
*
* RTCS Product Program Library (.TOSZLINK, or a copy)
*
+ POSZLINK=
|
| If not specified, then this value will default to
| STEPLIB-DSName-prefix.[xosz]LINK, provided that the
| low-level qualifier of //STEPLIB is '.[xosz]RTCS'.
| Else the default is the same DSNAME as //STEPLIB.
*
* DSNAME of RTCS SYSTEM Registry VSAM Linear Data Set (VLDS)
*
+ SREGVLDS=SYS2.&SYSPLEX..RTCS.SYSTEM.REGISTRY
|
| If not specified, then this value will default to
| STEPLIB-DSName-prefix.REGISTRY, provided that the
| low-level qualifier of //STEPLIB is '.[xosz]RTCS'.
| Otherwise, there is no default, and this parameter
| must be specified.
|
| The SYSTEM Registry contains configuration data for
| RTCS, the BMC AMI Ops CAS, RTCS-based products, and
| RTCS-dependent products that have elected to use it.
| It must be a VSAM Linear Data Set (VSAM LDS or VLDS).
|
| The Registry data set MUST be cataloged, since it is
| a VSAM cluster. It is allocated using only its DSNAME.
| The SYSTEM Registry VSAM LDS is read/write and cannot
| physically be shared, although it may be allocated on
| shared DASD. Only one RTCS Subsystem will be able to
| allocate a VSAM LDS for use as a Registry because it
| will be allocated DISP=OLD as required by the MVS DIV
| service.
|
| But the data in the SYSTEM Registry VLDS can be shared
| among members of a Sysplex using XCF. When the SYSTEM
| Registry is being shared among RTCS Subsystems running
| in a Sysplex, then only one RTCS Subsystem will have
| dynamically allocated the Registry VLDS. That system
| is called the Local Owner. Other systems can access
| data in the Registry (which is allocated to the Local
| Owner) using XCF to transmit requests and retrieve the
| requested data in response. An RTCS Subsystem that is
| accessing data in the SYSTEM Registry on the Local
| Owner via XCF is termed a Remote [Registry instance].
|
| It is not recommended, but it is possible to have a
| private, dedicated SYSTEM Registry VLDS for each RTCS
| Subsystem. But the BMC AMI Ops CAS will not be able to
| share data with other CASs in the Sysplex if you do.
|
| The first time an RTCS Subsystem becomes the Local
| Owner of the VLDS and encounters a newly-allocated,
| uninitialized, never-before-used Linear Data Set,
| the RTCS Subsystem will initialize the contents of
| the Registry, populating it with all the structures
| required for RTCS Subsystem components and products.
|
*
* SYSTEM Registry DIV Services Default Performance Parameters
*
DIV-SAVE-MINIMUM = 1 /* DIV Services interval 1: minimum */
DIV-SAVE-MAXIMUM = 6 /* DIV Services interval 2: maximum */
DIV-SAVE-LIMIT = 4000 /* DIV Services batch update limit */
|
| The above parameters indicate the time that the Registry
| DIV Services subtask will wait prior to requesting that
| changes to the SYSTEM Registry data space be hardened in
| the backing VSAM LDS. After the VLDS is updated, it will
| wait a minimum amount of time before the next request to
| update the VLDS will again be made, but no longer than
| the indicated maximum (after which a VLDS update will be
| forced).
| The amount of time that pending Registry VLDS updates are
| delayed is heuristically determined according to request
| frequency and arrival pattern, and will never less than
| the indicated minimum value, nor greater than the maximum.
| Regardless of the enforced minimum and maximum intervals
| that will cause the VLDS to be updated, if the number of
| changes exceeds the specified limit then the backing VLDS
| will be updated, hardening all pending changes on DASD.
|
| A MINIMUM interval of zero (0) indicates that all changes
| to the SYSTEM Registry are to be immediately hardened in
| the backing VSAM LDS, without waiting or attempting to
| batch multiple changes together into a single update. We
| recommend that you do NOT specify DIV-SAVE-MINIMUM = 0.
*
* RTCS SYSTEM Registry Sysplex Sharing Parameters
* -----------------------------------------------
*
+ REGISTRY-XCF-GROUP = OSZRTCSR /* SYSTEM Registry XCF Group Name */
/* This parameter will be used only */
/* if some form of Sysplex Registry */
/* Sharing (see below) is specified.*/
ELIGIBLE-OWNER /* This member is ELIGIBLE to */
/* ALLOCATE (and then EXPOSE) */
/* the SYSTEM Registry VLDS. */
/* RTCS Subsystem XCF members which */
/* are not eligible to own the RTCS */
/* SYSTEM Registry VLDS will not be */
/* able to assist in recovery when */
/* the image that does own the */
/* Registry fails for any reason. */
/* */
/* RTCS Subsystems on small or */
/* slow MVS images should only */
/* remotely access an exposed */
/* SYSTEM Registry and should */
/* not be eligible to allocate */
/* and expose/own the Registry. */
*
* RTCS SYSTEM Registry Sysplex Sharing Options
* --------------------------------------------
*
| The following five options are mutually exclusive. Only
| one of them should be specified without the 'NO' prefix.
| The other four may be omitted (or specified with the 'NO'
| prefix as illustrated below). If more than one positive
| [not prefixed with 'NO'] option is specified, then the
| most restrictive one will become effective. The Registry
| sharing options are listed below in that precedence order
| (the most restrictive first, the least restrictive last).
| In other words, the first (in the order they are listed
| below) positive (not prefixed with 'NO') option specified
| is the one that will be effective and override any others.
+-------------------------+ +------------------------------------+
| SYSTEM Registry Sysplex | | Meaning of positive FLAG parameter |
| Sharing Parameter FLAG. | | value (when not prefixed by "NO"). |
+-------------------------+ +------------------------------------+
NOPRIVATE-REGISTRY /* Exclusively allocate the SYSTEM */
/* Registry VLDS on this image but */
/* do not establish any capability */
/* to share it with other images. */
/* The Registry cannot subsequently */
/* be exposed to other MVS images. */
/* If the SYSTEM Registry VLDS can */
/* not be allocated DISP=OLD, then */
/* RTCS initialization will fail. */
NOALLOC-REGISTRY /* ALLOCate the SYSTEM Registry on */
/* this MVS image, but do not (yet) */
/* EXPOSE it for the REMOTE images */
/* to be able to CONNECT to it. It */
/* can be exposed at a later time */
/* via an RTCS operator command. */
/* If the SYSTEM Registry VLDS can */
/* not be allocated DISP=OLD, then */
/* RTCS initialization will fail. */
NOEXPOSE-REGISTRY /* ALLOCATE and EXPOSE the SYSTEM */
/* Registry on this MVS image. */
/* If the SYSTEM Registry VLDS can */
/* not be allocated DISP=OLD, then */
/* RTCS initialization will fail. */
SHARED-REGISTRY /* Setup a REMOTE Registry on this */
/* MVS image, then CONNECT to the */
/* SYSTEM Registry if it is already */
/* EXPOSEd on another MVS image. */
/* If the Registry is not already */
/* EXPOSEd, then (if it has not yet */
/* been ALLOCated) ALLOCATE and */
/* EXPOSE the SYSTEM Registry on */
/* this MVS image (if possible). */
/* If the SYSTEM Registry VLDS can */
/* not be allocated DISP=OLD or if */
/* this system is unable to CONNECT */
/* to an already-EXPOSEd Registry */
/* on some other MVS image, then */
/* RTCS initialization will fail. */
NOREMOTE-REGISTRY /* CONNECT to a SYSTEM Registry */
/* that has already been EXPOSEd */
/* on another MVS image. If this */
/* system is unable to CONNECT to */
/* an EXPOSEd SYSTEM Registry, then */
/* RTCS initialization will fail. */
+--------------------------------------------------------------------+
| |
| RTCS Data Compression Component Parameters |
| |
| The RTCS Data Compression Facility can optionally be |
| enabled for use by the RTCS Registry Component when |
| a Registry is being shared among members of a Sysplex |
| using XCF. This applies to the RTCS Subsystem SYSTEM |
| Registry and to product-specific Registry instances. |
| |
| When any of the supported data compression algorithms |
| or mechanisms are enabled, all Sysplex-shared Registry |
| instances will be eligible to use the Data Compression |
| facility to compress Registry data to be returned from |
| the Local Owner to REMOTE Registry instances (provided |
| Data Compression is enabled for the RTCS Subsystem for |
| both systems). In other words, RTCS Data Compression |
| must be enabled on the system where the Local Owning |
| Registry instance exists, as well as on the system |
| where the REMOTE Registry instance exists, or no data |
| compression will be possible. |
| |
+--------------------------------------------------------------------+
*
* Data Compression Facility Algorithm/Mechanism Enablement
*
+ COMPRESS-ALL /* [NO]COMPRESS-ALL */
|
|
| NOTE: NOCOMPRESS-ALL is the current default value for
| this flag parameter. Specify COMPRESS-ALL if you want
| to enable data compression for RTCS Registry instances.
|
|
| - if NOCOMPRESS-ALL is specified:
|
| ALL compression algorithms (mechanisms) are disabled.
| The RTCS Registry Component will not be eligible to
| send or receive Registry data for Registry instances
| established on this MVS system.
|
| - if COMPRESS-ALL is specified:
|
| ALL compression algorithms (mechanisms) will be able
| to be used by the RTCS Registry Component on this MVS
| system. Those that can actually be used depend upon
| the MVS systems hardware and software configuration.
| The RTCS Registry Component will select an available
| data compression mechanism that has been enabled on
| both MVS systems where the Registry instances are
| executing.
|
+--------------------------------------------------------------------+
| |
| RTCS External Security Manager Component Parameters |
| |
+--------------------------------------------------------------------+
*
* External Security Manager (ESM) Type
*
+ ESMTYPE=AUTO
|
| External Security Manager (ESM) that is in
| use on this MVS image and which RTCS is to
| interface with. The default, and the value
| which most installations should specify, is
| AUTO. RTCS is usually able to determine the
| ESM that is being used on an MVS image, but
| under certain circumstances, it cannot do so.
| If this situation occurs, you may explicitly
| indicate which ESM is (or will be) used on
| this MVS image using the ESMTYPE= parameter.
|
| ESMTYPE= Description
| -------- -----------
| AUTO RTCS is to automatically determine,
| if possible, which ESM is in use.
| RACF RTCS is to assume RACF will be used.
| ACF2 RTCS is to assume ACF2 will be used.
| TSS RTCS is to assume TSS (Top Secret)
| will be used.
|
*
* Accept or reject attempts to use undefined ESM User IDs
*
+ UNDEFINEDUSERINHERIT=ACCEPT
|
+ UNDEFINEDUSERSIGNON=REJECT
|
| These two parameters specify the behavior
| when an undefined ESM User ID is provided
| (either by an end user or an application)
| as part of original system entry signon,
| or when attempting to inherit credentials
| on this image from an existing environment.
|
| The following values can be specified:
|
| Action Description
| ------ -----------
| ACCEPT RTCS is to allow the INHERIT or the
| SIGNON to proceed. RTCS or the ESM
| will provide a default User ID for
| the security environment that will
| be created as a consequence.
| REJECT RTCS is disallow the INHERIT or the
| SIGNON.
|
| By default, RTCS allows INHERITs to proceed,
| since it would then be assumed that the User
| ID being presented was at least valid in the
| Sysplex or CASplex somewhere, and disallows
| SIGNONs with an undefined User ID, since it
| is usually the case that an invalid User ID
| (that is, one that is not defined) is never
| to be allowed.
*
* Default ESM User ID used in place of an undefined one
*
+ DEFAULTUSERID=' '
|
| This parameter specifies the ESM User ID that
| is to be substituted for an undefined/invalid
| User ID presented for authentication, and the
| UNDEFINEDUSERINHERIT or the UNDEFINEDUSERSIGNON
| option, as appropriate, specifies ACCEPT, which
| indicates that the INHERIT or the SIGNON is to
| be allowed. The value of this parameter should
| usually be set to blanks, which triggers ESM-
| specific behavior to generate its own default
| User ID (USER, LOGONID, or ACID) according to
| well-documented ESM behavior or if allowed by
| ESM-specific security options and parameters.
*
* How to process GROUP IDENT credential during an INHERIT
*
+ GROUPINHERIT=ALWAYS
|
| This parameter specifies how the GROUP IDENT
| credential (GROUP name) is to be processed
| when a security identity is being INHERITed.
|
| The following values can be specified:
|
| Action Description
| ------ -----------
| ALWAYS RTCS is to pass the GROUP IDENT to
| the ESM unchanged. In order to be
| successful, the ESM must allow the
| use of that specific GROUP IDENT.
| In the case of RACF, specifically,
| this means that the User ID being
| INHERITed must be CONNECTed to the
| same, exact GROUP IDENT specified
| in the credentials in the RACF data
| base being used on this system image.
| NEVER RTCS is to ignore any specification
| of a GROUP IDENT (GROUP name) in the
| authentication credentials presented
| when attempting to INHERIT a User ID.
|
*
* ESM Security Interface diagnostic tracing
*
+ SECTRACE=NONE
|
| This parameter specifies the default level of
| diagnostic tracing that is to be performed for
| the RTCS External Security Manager interface.
|
| The following values can be specified:
|
| Action Description
| ------ -----------
| NONE No ESM interface tracing is to be done.
| SIMPLE Issue only simple trace messages.
| EXTENDED Extended tracing is to be performed.
| COMPLETE Complete tracing is to be performed.
|
| Security diagnostic tracing can be activated
| dynamically via an RTCS operator command, so
| NONE should normally be specified. However,
| if there is a need to perform ESM diagnostic
| tracing during RTCS initialization, this can
| be initially activated using this parameter.
|
*
* ESM SAF Subsystem (RACROUTE SUBSYS) to be used by RTCS
*
+ SAFSUBSYS=&SSID
|
| This parameter specifies the RACROUTE SUBSYS
| (SAF Subsystem ID) that is to be used by the
| RTCS Security Manager. Specifying this value
| is usually not required. But when using a
| recent release of ACF2 on a system that was
| customized before ACF2 Release 6.0 for use
| with the BMC AMI Ops Enhanced Security
| Interface to recognize and process RACROUTE
| invocations using a specific SAF SUBSYS
| value, such as 'BBI3', then that value might
| need to be specified here.
|
| The following values can be specified:
|
| SAFSUBSYS Description
| --------- -----------
| &SSID The MVS SSID that was specified in
| this initialization member, or was
| provided as a default by RTCS.
| &PRODUCT The internal (security) product
| name in whose product address space
| an ESM security environment is being
| created (via SIGNON or INHERIT).
| '' or ' ' Null, or one or more blanks: No
| SUBSYS= parameter is to be used
| on any SAF RACROUTE invocation.
| 'xxxxxxxx' A specific RACROUTE SUBSYS= value,
| consisting of up to 8 characters.
|
| Under most circumstances, RACF and Top Secret
| will effectively ignore the RACROUTE SUBSYS=
| specification. However, a value may still be
| usefully provided here, since the SUBSYS can
| be used to filter requests to be traced when
| using the Top Secret SECTRACE facility (as
| well as the ACF2 SECTRACE facility), and to
| subset RACROUTE requests to be traced if an
| IBM or OEM vendor facility (using RACF exits)
| has been installed to facilitate such tracing.
| So, a suitable value should be provided, even
| if RACF or TSS is in use, simply in support
| of any existing ESM-level diagnostic tracing
| facility.
|
*
* Default ESM RACROUTE system entry validation APPL ID
*
+ SECURITYAPPLID=&PRODUCT
|
| This parameter specifies the RACROUTE APPL
| (application name) that is to be used as the
| default SAF APPLication by the RTCS Security
| Manager (if none is specified by the product
| or the caller does not have an RTCS product
| definition, or the definition in the product
| or SYSTEM Registry is null or blanks).
|
| The following values can be specified:
|
| SAFSUBSYS Description
| --------- -----------
| &SSID The MVS SSID that was specified in
| this initialization member, or was
| provided as a default by RTCS.
| &PRODUCT The internal (security) product
| name in whose product address space
| an ESM security environment is being
| created (via SIGNON or INHERIT) or
| a resource being authorized.
| &PRDAPPL The default product security APPL
| name, usually specified in the
| RTCS product definition in the
| package, or via the RTCS SYSTEM
| Registry product, context, or
| server (instance) definition.
| '' or ' ' Null, or one or more blanks: No
| APPL= parameter is to be used
| on any SAF RACROUTE invocation.
| 'xxxxxxxx' A specific RACROUTE APPL= value,
| consisting of up to 8 characters.
|
*
* Security domain
*
+ SDOMAIN=
|
| This parameter specifies the security domain for
| this RTCS instance. The security domain can be
| used to differentiate between different ESM
| instances where user identity is different because
| they do not share the same ESM type or definitions.
|
| When a different security domain is detected RTCS
| will attempt to resolve the user's identity using
| the ESM's distributed identity function by
| creating the user name filter and registry name
| filter based on the user's previously authenticated
| security identity extracted from another security
| identity. The resolution of the user name filter
| is defined by the DIDUN= parameter. The resolution
| of the registry name filter is defined by the
| DIDRN= parameter.
|
| If no security domain is specified then a default
| value of ++++++++ is set by RTCS. A default
| security domain disables distributed identity
| because RTCS will not attempt to authenticate a
| user with the distributed identity function when
| the default security domain has been detected.
|
| The security domain can be from 1 to 8 characters.
|
*
* Distributed identity user name rules string
*
+ DIDUN=
|
| This parameter specifies the distributed identity
| user name rules string. The rules string is used
| to construct the distributed identity user name
| filter. The user name filter will be passed by
| RTCS to the ESM when authenticating a user with
| the user's distributed identity.
|
| If no distributed identity user name is specified
| then the default value of * will be set by RTCS
| when constructing the distributed identity user
| name filter.
|
| The rules string can be from 1 to 64 characters.
|
| The symbols for the user name are as follows:
| &EXTUSER, &INTUSER, &GROUP, &SNAME, &SPLEX, &SSDMN
|
| When RTCS resolves the rules string the symbols
| will be replaced as follows:
| &EXTUSER will use the external user id.
| &INTUSER will use the internal user id.
| &GROUP will use the group value.
| &SNAME will use the system value.
| &SPLEX will use the sysplex value.
| &SSDMN will use the security domain.
|
| When constructing a X.500 format user name filter
| a period <.> must be specified before a comma <,>
| that denotes the next X.500 pair.
|
| For example DIDUN="UID=&EXTUSER.,SYSTEM=&SNAME"
|
*
* Distributed identity registry name rules string
*
+ DIDRN=
|
| This parameter specifies the distributed identity
| registry name rules string. The rules string is
| used to construct the distributed identity registry
| name filter. The registry name filter will be
| passed by RTCS to the ESM when authenticating a
| user with the user's distributed identity.
|
| If no distributed identity registry name is
| specified then the default value of * will be set
| by RTCS when constructing the distributed identity
| registry name filter.
|
| The rules string can be from 1 to 64 characters.
|
| The symbols for the registry name are as follows:
| &EXTUSER, &INTUSER, &GROUP, &SNAME, &SPLEX, &SSDMN
|
| When RTCS resolves the rules string the symbols
| will be replaced as follows:
| &EXTUSER will use the external user id.
| &INTUSER will use the internal user id.
| &GROUP will use the group value.
| &SNAME will use the system value.
| &SPLEX will use the sysplex value.
| &SSDMN will use the security domain.
|
| When constructing a X.500 format registry name
| filter a period <.> must be specified before a
| comma <,> that denotes the next X.500 pair.
|
| For example DIDRN="SYSTEM=&SNAME.,PLEX=&SPLEX"
|
== Runtime Component System (RTCS) Initialization Parameters ==
Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*