Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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:

  • Name is the name of a variable preceded with @. For example: *@DATE1.
  • Value is the value you want to set to the variable. For example: 20110601.

Step 4

When the JCL is submitted for execution, the parameter *@DATE1 (shown in the following example) will be substituted with the value 20110601 in the JCL or
in any in-stream data. The example also shows the *@DATE1 parameter being used in an in-stream data and in a JCL IF statement:
 

Panel
//INPUT DD *
@DATE1
/*


Panel
//AIF   IF @DATE1 > 20110101 THEN

 
If a Universal Controller parameter must be concatenated with a non-space character, end the parameter name with a period (.). The example below
uses the *@DATE1 parameter concatenated with a non-space character in an in-stream data set:
 

Panel
//INPUT DD *
DATE@DATE1.ACT9898
/*


Anchor
Skipping Steps during Initial Run
Skipping Steps during Initial Run

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.

...

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:

  • Name = SKIPSTAA (SKIPST is a required string. AA is any combination of alphanumerics used to make this SKIPST command unique. (You can add as many SKIPST commands as needed.)
  • Value = STEPNAME (JCL step name)

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.
 
For example, you could enter parameters:

  • SKIPST01, STEP03
  • SKIPST02, STEPo5

Anchor
Overriding Key JCL Parameters from Universal Controller
Overriding Key JCL Parameters from Universal Controller

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.

Anchor
Disabling Automatic Data Set Deletion
Disabling Automatic Data Set Deletion

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.

...

The Re-run Report will indicate if the feature has been disabled.

Anchor
Re-running a z/OS Task Instance
Re-running a z/OS Task Instance

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.

...

Note
titleNote

UAG does not check for changes to steps which will not run.

Anchor
Re-running a z/OS Task Instance in Start Failure Status
Re-running a z/OS Task Instance in Start Failure Status

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.

Anchor
Re-run a z/OS Task Instance from a Specific Step
Re-run a z/OS Task Instance from a Specific Step

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.
 

 
Check the Restartable column to see from which steps you can start the re-run (Yes or No).
 
If applicable, the Failed column indicates at which step(s) the task failed.

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:

  1. Click the first step that you want included in the re-run.
  2. Press and hold the <Shift> key.
  3. Click the last step that you want included in the re-run.
  4. Right-click any step in the selected group to display an Action menu.
  5. Click Select for 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.)
 
If you want to de-select a job step in the group for inclusion in the re-run, right-click the step and, in the Action menu, click Deselect for 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.
 
To confirm the changes:

  1. From the Activity Monitor, open the task instance.
  2. Click the Confirm JCL Changes tab to display a list of all changes that were made to the JCL.
  3. Click the Confirm button at the top of the list.
  4. Click the z/OS Task Instance tab. Verify that the JCL Changes Confirmed field is checked and then click the Re-run button.
Note
titleNote

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
titleNote

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.


Anchor
Restartable Job Steps List Column Descriptions
Restartable Job Steps List Column Descriptions

Restartable Job Steps List Column Descriptions

The following table describes each column on the z/OS Restartable Job Steps 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.

Anchor
Interactively Ignoring a Step Code to Force a Task to Complete
Interactively Ignoring a Step Code to Force a Task to Complete

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.

...

Note
titleNote

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.

Anchor
CA7/CA11 Toleration
CA7/CA11 Toleration

CA7/CA11 Toleration

Anchor
Non-Restartable Customized Job Steps
Non-Restartable Customized Job Steps

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.

...

  • CA11NR - CA11 Non-Restartable
  • UCC11NR - UCC11 Non-Restartable
  • OPSNR000 - Opswise Non-Restartable


SCHID - Overriding the CA7 Schedule ID

Anchor
SCHID
SCHID

The Schedule ID field in the z/OS Task Details allows you to override the CA7 SCHID (Schedule ID).

...

Panel
//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
/*
//

Anchor
Non-Restartable Job Steps
Non-Restartable Job Steps

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=...

Anchor
Viewing Re-run Reports
Viewing Re-run Reports

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:
 

Anchor
Viewing Audit Trails on a Restart
Viewing Audit Trails on a Restart

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.
 

...