Special Processing on z/OS Tasks
Overview
The following special processing features are available for running z/OS tasks:
- Using Variables in JCL and In-Stream Data Sets
- Skipping Steps during Initial Run
- Overriding Key JCL Parameters from Universal Controller
- Disabling Automatic Data Set Deletion
The following failure processing features are available for handling job failures:
- Re-running a z/OS Task Instance
- Interactively Ignoring a Step Code to Force a Task to Complete
The Controller supports compatibility with other schedulers:
- CA7/CA11 Toleration
The Controller provides the following reports that track error processing:
- Viewing Re-run Reports
- Viewing Audit Trails on a Restart
Each of these features is described in detail below.
Using Variables in JCL and In-Stream Data Sets
There are two categories of variables that can be defined in z/OS task Details:
- JCL Symbolic Parameters
- Universal Controller Parameters
Parameter values can use Universal Controller built-in or user-defined variables.
JCL Symbolic Parameters
Use the z/OS Task Details Parameters field to specify JCL symbolic parameters to be used in the JCL.
Any parameter name that does not start with *@
is considered a JCL symbolic parameter. JCL symbolic parameters result in the Controller adding a JCL SET statement to the JCL before the first step EXEC statement.
As an example, a z/OS Task parameter name of PHLQ and value of APP.PROD will result in the following JCL SET statement being added to the JCL:
// SET PHLQ=APP.PROD
The PHLQ symbolic parameter in the example above can then be used in the remaining JCL as described by the IBM JCL Reference.
Universal Controller Parameters
Use the z/OS Task Details Parameters field to specify parameters that can be used in any JCL statement and in in-stream data sets.
In-stream data sets are typically defined with a DD * JCL statement. the Controller will substitute the parameter values in the JCL statements and in the in-stream data before the JCL is submitted to JES.
Universal Controller parameters are defined with a parameter name that starts with the character sequence *@
. The parameters are referenced in the JCL and in-stream data by prefixing the parameter name with the @
character.
The following steps add a Universal Controller parameter with the name *@DATE1
and a value of 20110601:
Step 1 |
Open the z/OS task. |
---|---|
Step 2 |
In the Parameters field, click the + icon. |
Step 3 |
Add a parameter in the following format:
|
Step 4 |
When the JCL is submitted for execution, the parameter //INPUT DD * @DATE1 /* //AIF IF @DATE1 > 20110101 THEN //INPUT DD * DATE@DATE1.ACT9898 /* |
Skipping Steps during Initial Run
In a z/OS task, you can specify that one or more steps from the JCL should be skipped when the Controller launches the job. You achieve this by adding SKIPSTNN variables (or parameters) to your z/OS task record.
To configure your z/OS task to skip specific JCL steps:
Step 1 |
Open the z/OS task. |
---|---|
Step 2 |
In the Parameters field, click the + icon. |
Step 3 |
Add a parameter in the following format:
|
Step 4 |
Repeat Steps 2 and 3 for each step you want to skip. Change the AA portion of the SKIPST for each parameter you add. Each Name must be unique.
|
Overriding Key JCL Parameters from Universal Controller
When you launch a z/OS task from the Controller, you can specify a different Jobname, Jobclass, Msgclass, Schedule ID or add a JOBPARM card. This enables you to run your JCL jobs from the Controller without having to go in and modify your JCL. You can do so by entering new value into the appropriate field in the z/OS Task Details.
Disabling Automatic Data Set Deletion
Universal Automation Center Agent (UAG) will automatically detect and delete data sets that would cause a NOT CATLGD 2 condition. The data set deletion takes place before the job is started. Automatic data set deletion can be disabled for a z/OS task by defining the OPSDSDEL parameter with a value of NO in the z/OS task definition.
To configure your z/OS task with automatic data set deletion disabled:
Step 1 |
Open the z/OS task. |
---|---|
Step 2 |
In the Parameters field, click the + icon. |
Step 3 |
Add a parameter in the following format:
|
The OPSDSDEL parameter accepts a value of YES (the default) or NO.
- A value of YES specifies that automatic data set deletion is enabled for the z/OS task.
- A value of NO specifies that automatic data set deletion is disabled for the z/OS task.
The Re-run Report will indicate if the feature has been disabled.
Re-running a z/OS Task Instance
When you re-run a z/OS task, you must select job steps in the task to include in the re-run; you cannot simply click a Re-run button or Re-run in an Action menu, as with other tasks.
The Restartable Job Steps tab in the z/OS Task Instance Details provides a list of all job steps in the task and indicates from which steps you can start the re-run.
When you re-run a z/OS task, the Controller automatically performs the following:
- Deletes data sets that were created in dependent steps.
- Maintains Generation data group.
Note
You must re-run a z/OS task from the Universal Controller user interface in order for these clean-up procedures to be performed. Do not re-run the task from the z/OS prompt.
You also can re-run a z/OS task in the In Doubt status (see Re-run a z/OS Task Instance in the In Doubt Status).
Confirming JCL Changes
If you make any JCL changes, the Controller will prompt you for a confirmation, as described in Re-run a z/OS Task Instance from a Specific Step, below.
During the confirmation process, UAG checks for the following JCL changes:
- Job name has changed.
- Step name had changed.
- Steps have been re-ordered.
- Program name has changed for a step.
- New steps.
- Removed steps.
- New DD statements.
- Removed DD statements.
- Dataset name changed for a DD.
Note
UAG does not check for changes to steps which will not run.
Re-running a z/OS Task Instance in Start Failure Status
If a z/OS task instance is in Start Failure status, the existence or non-existence of Restartable Job Steps will determine the outcome of a Re-run command.
- If Restartable Job Steps exist, you can re-run the task instance from any steps identified as Restartable under the Restartable Job Steps tab.
- If Restartable Job Steps do not exist, you must re-submit the task instance from the beginning, as when re-running a z/OS task instance from the In Doubt status.
Re-run a z/OS Task Instance from a Specific Step
Step 1 |
On the Activity Monitor, click the Details icon next to the Instance Name of the task you want to re-run. The z/OS Task Instance Details displays. |
---|---|
Step 2 |
Click the Restartable Job Steps tab to display a list of all job steps in the task. |
Step 3 |
Assuming any failures were caused by error(s) in the JCL, examine the JCL and make your corrections. The Controller uses a background process to determine whether changes have been made to the JCL. Any changes trigger a confirmation process. |
Step 4 |
Click the Details icon next to the Step Number of any step to see detail information about that step.
|
Step 5 |
From the Restartable Job Steps list, select the steps that you want included in the re-run:
(You also can right-click a step and select Select to End for Re-run to include that selected step and all following steps in the re-run.) |
Step 6 |
Click the z/OS Task Instance tab to redisplay the z/OS Task Instance Details. |
Step 7 |
Click the Re-run button to re-run the task for the selected job steps. |
Step 8 |
If you have made changes to the JCL, the task instance goes into a status of Confirmation Required on the Activity Monitor.
Note If a z/OS task instance transitions into the Confirmation Required status, and the Controller determines that the number of steps did not change, it preserves the step re-run selection. However, if the Controller detects a change in the number of steps, all steps will be de-selected. |
Step 9 |
After the re-run is complete, the Failed column in the Restartable Job Steps list should show No for each step. Note If you repeat the above process on the same task instance, the previous list of JCL changes, if any, is replaced with the most recent list of changes. |
Restartable Job Steps List Column Descriptions
The following table describes each column on the z/OS Restartable Job Steps list.
Column Name |
Description |
---|---|
Step Number |
Number assigned to this step by the Controller. |
Restartable |
If the JCL job fails, the Controller determines the latest step that you can restart from. Yes indicates that you can restart from this step. |
Selected for Re-run |
Indicates (Yes or No) whether or not this step has been selected for re-run (the Selected for Re-run field is enabled in the Restartable Job Steps Details). |
Depends On |
Specifies which other step(s), if any, must be completed successfully before you can run this step. |
Step |
Name of the JCL step (extracted from the JCL). |
Procedure |
Procedure step name from within the JCL step. |
Program |
Name of the program being executed by the step. |
Step Code |
Extracted from the JCL. Exit code for this step of the program. |
Failed |
Indicates (Yes or No) whether or not this step failed. |
Updated By |
Name of the user that last updated this step. |
Updated |
Date and time that this step was last updated. |
Confirm JCL Changes Tab Column Descriptions
The following table describes each column on the Confirm JCL Changes list.
Column Name |
Description |
---|---|
Job Id |
Number assigned to this step by the Controller. |
Step Number |
JCL step number that was modified. |
Error Message |
Description of the change. |
Old Data |
JCL before the change. |
New Data |
JCL after the change. |
Confirmed |
Indicates (Yes or No) whether or not this JCL change was confirmed. |
Updated By |
Name of the user that last updated the JCL. |
Updated |
Date and time that the JCL was last updated. |
Interactively Ignoring a Step Code to Complete a Task
If the step code (exit code) on a previous step is causing a step failure, but you still want to finish the job, you can change the step code in order to complete the task.
Step 1 |
From the Activity Monitor, open the task instance. |
---|---|
Step 2 |
From the Restartable Steps tab, click on the step whose code you want to change. The Restartable Job Step Details for this job step displays: |
Step 3 |
Enter the new code in the Step Code field and click . |
Step 4 |
Click the z/OS Task Instance tab and then click the Re-run button. |
Note
By default, on a re-run, the return code in the restarted step will revert to the original return code.
To retain the new step code, change the Retain Overridden Step Codes On z/OS Task Re-run Universal Controller system property to true.
CA7/CA11 Toleration
Non-Restartable Customized Job Steps
The Controller can read and interpret JCL DD names that have been customized for CA11 and UCC. This allows you to launch your existing CA11 and UCC jobs from the Controller without modifying the JCL.
When the Controller encounters one of the following DD names in the JCL for a job step, the Controller will mark the step as non-restartable during a restart:
- CA11NR - CA11 Non-Restartable
- UCC11NR - UCC11 Non-Restartable
- OPSNR000 - Opswise Non-Restartable
SCHID - Overriding the CA7 Schedule ID
The Schedule ID field in the z/OS Task Details allows you to override the CA7 SCHID (Schedule ID).
For example, the JCL shown below contains CA7 Scheduled Overrides statements #JI and #JEND. This JCL will set CLASS =A if the SCHID is between 1 thru 39, and set CLASS=B if the SCHID is between 40 thru 79. The user can set the SCHID by entering it into the Schedule ID field. The Agent scans for #JI and #JEND, and generates the appropriate JCL, as shown in the following example.
//SCHID JOB (IMS,001),JIM,MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=&SYSUID, #JI,ID=1-39 // CLASS=A #JEND #JI,ID=40-79 // CLASS=B #JEND //S1 EXEC PGM=IGWSPZAP //SYSLIB DD DSN=OPS01.JS01.LOAD,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSIN DD * DUMPT WMSSETRC WMSSETRC /* //
Non-Restartable Job Steps
A z/OS Agent determines that a job step is non-restartable if the step contains any of the following:
- One of the special DDNAMEs: CA11NR, UCC11NR, or OPSNR000.
- DD statement with DISP=(NEW,PASS) or (OLD,DELETE). (Note that the third DISP value is not considered by the agent.)
- A backwards volume reference. For example: VOL=REF=...
Viewing Re-run Reports
The Controller keeps a detailed record of task re-runs. This data is written to the Output tab on the task instance record, as shown in the sample below:
Viewing Audit Trails on a Restart
The Controller maintains detailed audit records on all system activity. The following audit record is for a launch on a z/OS task.