ISET

CA-GSS/ISERV Commands › CA-GSS Initialization Parameters › ISET

ISET

Use the ISET parameter to define an ISET for loading or reloading IMODs.

Syntax

Use this format for the ISET parameter:

ISET name [DSN dsname] [loadoption|accessoption] [DESC /desc/]

[SSID ssid]

Arguments

The ISET parameter takes these arguments.

Argument	Description
Name	1- to 16-character name for the ISET. If the ISET is to be available for reloading (from TSO), this ISET name must match the ISET name as defined to the TSO user. Throughout an installation, each ISET name should point to the same data set, although each data set can be referred to by multiple ISET names.
Dsname	Name of a VSAM KSDS that contains the ISET. When a reload request for an IMOD is processed by CA‑GSS, both the ISET name and dsname, as defined to both CA‑GSS and the requestor, must be an exact match.
loadoption	Indicates whether an IMOD should be loaded. Specify one of these options: FORCE Loads an IMOD and, if another IMOD is currently loaded, replaces it with the new IMOD. LOAD Loads an IMOD; however, does not replace any currently loaded IMOD. NOFORCE Negates a FORCE specification. NOLOAD Negates a LOAD specification.
accessoption	Default access level for the ISET when accessed from the IMOD editor. Specify READ (read-only) or WRITE (read/write).
Desc	1- to 52-character description of the ISET's contents. The IMOD editor displays this description. Because a description can contain blanks, the first non-blank character that follows the DESC parameter is assumed to be the delimiting character.
Ssid	Default subsystem ID that the IMOD editor should use for dynamic IMOD loading and execution.

Usage Notes

Only valid IMODs can be loaded into CA‑GSS. A valid IMOD (for an ISERVE address space) is one that compiled without errors and is in production or force status. In batch mode, a valid IMOD is one that compiled without errors and is in test, production, or force status.
If loading of the IMOD would cause a previously loaded IMOD of the same name to be replaced, the operation is suppressed for an IMOD in production status (or test status, if batch).
To force the load of an IMOD from the internal (system) ISET, you must either code FORCE and force-load the entire ISET, or change the status of one or more IMODs to force.
If neither LOAD nor FORCE is coded, the ISET is merely defined and can be used later for dynamic IMOD loading.
Each ISET that is to be accessible to CA‑GSS, for the purpose of loading or reloading IMODs, must be defined by an ISET statement. These statements are processed in the same order that they are encountered and can merely define an ISET or cause the contained IMODs to be loaded into CA‑GSS.
The contents of the INTERNAL ISET, as shipped by CA, have been link-edited into the CA‑GSS load module. Hence, this ISET should be defined only if there is a need to modify or reload an IMOD.
In the case of duplicate IMODs, the first occurrence is retained unless the FORCE attribute is specified for the IMOD.
During the course of loading an IMOD, if the compiler version does not match the current interpreter version, the IMOD will automatically be re-compiled. This process affects only the execution copy, and the updated version is not written to the ISET. To reduce start-up overhead, you should recompile all IMODs in an ISET under the current compiler version. The SRVMAINT utility's UPGRADE option provides this capability.
If duplicate ISET statements are encountered (same ISET name), the arguments are applied to the existing definition, either by adding new information or overriding an option.
The READ, WRITE, DESC, and SSID parameters are not used by the CA‑GSS address space - they're recorded and furnished to the ISPF-based IMOD editor during the execution of the editor's LINK command.

Tell Technical Publications how we can improve this information