Set Processing

This section describes Sets and their attributes, how the approval process works, and the Set scheduling system.

Set Overview and Attributes

What is a Set?

Sets are used to group together components for processing and to control the approval process. Task operations that need to be approved must be performed using a Set. Sets can also be used to carry out task operations asynchronously from the user’s online session. ISPW’s optional Deploy feature also requires that Sets be used for the creation of Deploy Requests.

See the ISPW User Guide for details on creating and using Sets.

Set Attributes

Each set has a number of attributes to describe the status of phases of the set processing. The main statuses are:

• Task Status – whether tasks can be altered
• Approval Status – the state of approval
• Processing Status – describes the state of execution.

Task Status

This indicates whether the set has been Locked or Unlocked and represents the action that can be taken on tasks that are associated with the set. It can be specified on the set create.

The Task States are described in the following table.

Task States

Unlock and Lock Commands

It is possible to toggle between the Task states by issuing the Unlock and Lock commands against the Set. See the ISPW User Guide for details.

If an unlocked Set is locked, the approval rules are used to build an approver list, which is attached to the Set. If a locked Set is unlocked, the approver list is discarded and any approvals that have been granted are lost.

Approval Status

The Approval status is maintained by ISPW and indicates the approval state of the Set. It can be one of the values listed in the following table.

Approval States

Processing Status

This shows the different states of execution for the Set. The user can specify when the execution will begin by choosing one of the two user-specified states. ISPW maintains the Processing status once Set execution begins. All of the Processing states are described below.

Processing States – User-Specified

The processing states listed in the following table indicate how the execution of the Set will begin. It can be specified on Set creation or the Set Modify.

Processing States

Processing States – ISPW Maintained

ISPW maintains this status to show what stage the Set execution is in. The states are described in the following table.

Processing States - ISPW Maintained

Starting Sets on Other LPARs

Overview

By default, Sets are started on the same LPAR as theISPW CM Task. (The CM Task issues the START command.) ISPW provides the capability to start Sets on other LPARs, if this is required.

How it Works

Special M.ER variables are recognized to map the Set Class to a SystemID.

If such a variable is defined, the START command for the Set is wrapped in a ROUTE command, targeted at the required system (LPAR).

M.ER Variable

The format of the M.ER variable name is SX$CLS$ followed by the class name (for example SX$CLS$D for Set Class D). The value assigned to this variable must be a valid CT name executing on the LPAR the Set is to run on.

Example

The following figure shows an example M.ER variable for class D.

M.ER Variable for Class D

In the above example, Sets that are started with an ISPW Class of “D”, will be routed to the system “S390” for execution.

Approval Process

Task operations can be controlled through an approval process. The approval process can only be used as part of Set processing.

Approval and Approval Rules

The authorization process is referred to as an approval. The rules that define which authorizations are required are called approval rules.

Approval Rules

These are the rules that control which Approvers must grant their approval before the operation can be processed on the components that are covered by the rule.

Approvers

The user or group of users who can grant approval are called Approvers. This is a 10-character name that is mapped to a resource controlled by the external security system (for example, RACF, ACF/2, etc.). Therefore, the actual UserIDs who are authorized to grant approvals are controlled by the external security system and not by ISPW. See Security for details.

Is Approval Required?

Each approval in the approval list is marked as Required or Not Required. Required means that approval must be granted before the Set can be executed. Not Required means that the Set can be executed without the approval being granted, but the Set will still be listed as requiring approval. It can be useful where emergency fixes are necessary when some of the normal approvers, such as Audit, are not available to make the approval but want to be able to approve the Set after the event.

Quorums

Quorums are supported so that a specified number of distinct UserIDs must grant approval for a given approval rule.

Viewing Approval Information

The container list can be used to view Sets and their components. It can also be used to make approvals. The approver group name can be specified so that all the Sets that require approval by that approver will be displayed. See the ISPW User Guide for details.

Change Types

Change types relate to the type of change that a Set was created for and provide additional flexibility. They allow Sets to be grouped to specify different:

• approval rules
• scheduling priorities.

ISPW places no inherent meaning in these types; it merely uses them to determine the processing to use for any given Set.

Default Change Types

ISPW provides three default change types:

• Standard – normal changes
• Emergency – urgent fixes
• Incidental – a special non-urgent change.

A site may add additional user-defined changed types. See CH – Change Types.

Set Exits

This section describes the sample Set exits provided for optional Set processing.

Set Exit PROCEXIT

This Process Exit can be used to do any processing that is required once the set has been created.

A Process Exit is invoked by initializing the variable PROCEXIT in a generate panel. The following panel example shows how a process exit might be defined in the panel )PROC section to implement the exit when variable WSXOPTN is set to DBUG:

IF (&WSXOPTN NE &Z)
&EXTNCLAS = 'WSXEXTN'
&EXTNVARS = 'WSXOPTN' VPUT (EXTNVARS WSXOPTN) IF (&WSXOPTN EQ 'DBUG')
&PROCEXIT = 'WSX@DBUG'A Process Exit can be used to manipulate the extension variables (EXTNVARS) defined to an extension class (EXTNCLAS). The manipulated values are then passed into the remaining Set process.

Example Exits can be found in the CLIST members WSX@DBUG and WSX@DML.

Set Exit OPEREXIT

Similar to the Process Exit, the Operation Exit can be used to do any processing that is required for a specific operation once the Set has been created. It is executed immediately following any specified Process Exit.

An Operation Exit is invoked by initializing the variable OPEREXIT in a generate panel. The following panel example shows how a process exit might be defined in the panel )PROC section to implement the exit for operation UD (Update Deploy Component Details):

IF (&OP EQ 'UD')
&OPEREXIT = 'WZU@UDS#'
&EXTNCLAS = 'WSXEXTN'An Operation Exit can be used to manipulate the variables defined to an extension class (EXTNCLAS). The manipulated values are then passed into the remaining Set process.

An example Exit can be found in the CLIST member WZU@UDS#.

Set Pre-Exit for Operations

These exits are defined to M.EX (see EX – Exits) to run prior to the Set Create Panel being displayed.

These exits provide support for an Exit Validation point which would enable an interactive dialog with the user based on the Operation code for which the Set is being created. Other operation pre-exits defined in M.EX run in the background as part of the Set Processing, so they cannot provide the sort of end user interaction that is sometimes required.

To enable this feature in ISPW, the M.ER (see ER – External References) variable WZUOPVER must be set to 'Y'. This just enables support for the new exit point and ensures that the appropriate validation exits will be called for any operations that are defined with an exit key of @@@@.

A new Exit is activated to validate the operation if the M.EX table has an entry with an Exit Key of @@@@ for the applicable operation code and Member Environment. If the exit wants to fail the operation, it should return with a code of 4; otherwise it should return with code 0.

Set Create Pre-Exit

This exit is similar to the Set Operation Pre-exit in that it is executed prior to the Set Create Panel being displayed, but this exit is executed regardless of the OPCODE being processed by the set and does not require M.EX table entries.

To enable this feature in ISPW, the M.ER (see ER – External References) variable WSETCRPX must be added to the table.

The following figure shows a sample definition of this variable which instructs ISPW to execute CLIST WZUSETPX prior to displaying the Set Create Panel.

Set Create Pre-Exit

If the key value, View Code, is set to $TAB, the selected tasks being passed to the Set Create process will be made available in the table $WSETCRn, where n=current value assigned to variable ZSCREEN.

Set Lock Exit

Set Lock Exits are executed after the user has pressed Enter on the Set Create Panel or when the user enters the command to Lock the Set from the Modify/Approve Set Panel. See the ISPW User Guide for details.

To enable this feature in ISPW, the M.ER (See ER – External References) variable EXSTLOCK must be added to the table.

Below is a sample definition of this variable which instructs ISPW to execute CLIST WZUAPPR prior to locking the Set.

Set Lock Exit

Set Post Exit WZUSETX

This exit is provided with the ISPW base code and is called when all standard set processing has been completed. The provided sample version of this exit sends email messages to the designated addressees for set completion notification and submits a batch job to perform any needed CICS NEWCOPY requests and/or LLA refresh requests via a provided skeleton.

Customer sites can check this sample CLIST out to their SITE application and modify it to suit their post-set requirements.