CA Scheduler

Unicenter CA-Scheduler
 
Job Management for VSE
User Guide
r7.3
K01171-1E
This documentation and related computer software program (hereinafter referred to as the “Documentation”) is for
the end user’s informational purposes only and is subject to change or withdrawal by Computer Associates
International, Inc. (“CA”) at any time.
This documentation may not be copied, transferred, reproduced, disclosed or duplicated, in whole or in part, without
the prior written consent of CA. This documentation is proprietary information of CA and protected by the copyright
laws of the United States and international treaties.
Notwithstanding the foregoing, licensed users may print a reasonable number of copies of this documentation for
their own internal use, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only
authorized employees, consultants, or agents of the user who are bound by the confidentiality provisions of the
license for the software are permitted to have access to such copies.
This right to print copies is limited to the period during which the license for the product remains in full force and
effect. Should the license terminate for any reason, it shall be the user’s responsibility to return to CA the reproduced
copies or to certify to CA that same have been destroyed.
To the extent permitted by applicable law, CA provides this documentation “as is” without warranty of any kind,
including without limitation, any implied warranties of merchantability, fitness for a particular purpose or
noninfringement. In no event will CA be liable to the end user or any third party for any loss or damage, direct or
indirect, from the use of this documentation, including without limitation, lost profits, business interruption,
goodwill, or lost data, even if CA is expressly advised of such loss or damage.
The use of any product referenced in this documentation and this documentation is governed by the end user’s
applicable license agreement.
The manufacturer of this documentation is Computer Associates International, Inc.
Provided with “Restricted Rights” as set forth in 48 C.F.R. Section 12.212, 48 C.F.R. Sections 52.227-19(c)(1) and (2) or
DFARS Section 252.227-7013(c)(1)(ii) or applicable successor provisions.
 2005 Computer Associates International, Inc.

All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Contents
Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

1.1 Beginning with the Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
1.2 How Unicenter CA-Scheduler Works . . . . . . . . . . . . . . . . . . . . 1-7
1.3 Additional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
1.4 Summing Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Chapter 2. Startup Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.1.1 Logging On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.1.2 Using the Main Menu . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
2.1.3 Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
2.1.4 Logging Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
2.2 Maintaining Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
2.2.1 Defining Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
2.2.2 Updating Station Records . . . . . . . . . . . . . . . . . . . . . . . 2-10
2.2.3 Deleting Workstations . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
2.2.4 Displaying Workstations . . . . . . . . . . . . . . . . . . . . . . . . 2-15
2.2.5 Summary of Station Maintenance . . . . . . . . . . . . . . . . . . 2-18
2.3 Maintaining User Records . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
2.3.1 User Authority Levels . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
2.3.2 The Role of Passwords . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
2.3.3 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
2.3.4 Defining Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
2.3.5 Updating User Records . . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.3.6 Deleting User Records . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
2.3.7 Displaying User Records . . . . . . . . . . . . . . . . . . . . . . . . 2-30
2.3.8 Summary of User Maintenance . . . . . . . . . . . . . . . . . . . . 2-34
Chapter 3. Maintaining the Database . . . . . . . . . . . . . . . . . . . . . 3-1

3.1 Defining Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
3.1.1 Planning Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
3.1.2 Defining a Schedule Base Record . . . . . . . . . . . . . . . . . . . 3-3
3.1.3 Checking Default Values for Schedule Base Records . . . . . . . . 3-7
3.1.4 Learning the Basics About a Schedule Record . . . . . . . . . . . . 3-9
3.1.4.1 When Will this Schedule Be Selected? . . . . . . . . . . . . . 3-10
3.1.4.2 When Will a Schedule's Jobs Actually Run? . . . . . . . . . 3-11
3.1.4.3 What JCL Does Unicenter CA-Scheduler Submit for These
Jobs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
3.1.4.4 Which CPU Should Control These Jobs? . . . . . . . . . . . 3-14
Contents iii
3.1.4.5 What Schedule Fields Are Used for Simulation? . . . . . . . 3-15
3.1.4.6 What General Users Can Update this Schedule Record? . . 3-16
3.1.4.7 What Happens When Schedules Run Late? . . . . . . . . . . 3-16
3.1.4.8 Creating Optional Schedule Records? . . . . . . . . . . . . . 3-17
3.2 Defining Optional Schedule Records . . . . . . . . . . . . . . . . . . . 3-19
3.2.1 Defining a Schedule Criteria Record . . . . . . . . . . . . . . . . . 3-21
3.2.2 Defining a Schedule Reason Code Record . . . . . . . . . . . . . 3-24
3.2.3 Defining a Schedule Information Record . . . . . . . . . . . . . . 3-26
3.2.4 Defining a Schedule Message Record . . . . . . . . . . . . . . . . 3-27
3.3 Copying Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
3.4 Displaying Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
3.5 Deleting Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36
3.6 Analyzing Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40
3.7 Automatic Console Replies for Schedules . . . . . . . . . . . . . . . . 3-44
3.7.1.1 To ADD a New Reply . . . . . . . . . . . . . . . . . . . . . . 3-45
3.7.1.2 ALTer or REPlace an Auto-Reply Record . . . . . . . . . . . 3-47
3.7.1.3 To DELete an Auto-Reply Record . . . . . . . . . . . . . . . 3-49
3.8 Summary of Schedule Maintenance . . . . . . . . . . . . . . . . . . . . 3-51
3.9 Defining Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53
3.9.1 Defining a Job Base Record . . . . . . . . . . . . . . . . . . . . . . 3-53
3.9.2 Checking Default Values for Job Base Records . . . . . . . . . . 3-56
3.9.3 Learning the Basics About a Job Record . . . . . . . . . . . . . . 3-58
3.9.3.1 Which Users Can Work with Job Records? . . . . . . . . . . 3-58
3.9.3.2 When Will Jobs Be Selected? . . . . . . . . . . . . . . . . . . . 3-58
3.9.3.3 When Will Jobs Actually Run? . . . . . . . . . . . . . . . . . 3-59
3.9.3.4 Does This Job Record Describe a Job Performed on the CPU? 3-64
3.9.3.5 What JCL Does Unicenter CA-Scheduler Submit for CPU
Jobs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-65
3.9.3.6 On Which CPU Should Jobs Be Run? . . . . . . . . . . . . . 3-66
3.9.3.7 Once a Job Starts, How Can You Intervene? . . . . . . . . . 3-68
3.9.3.8 What Happens When Jobs Don't End Successfully? . . . . . 3-68
3.9.3.9 How Do You Phase Unicenter CA-Scheduler into
Production? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70
3.9.3.10 What Job Fields are Used for Simulation? . . . . . . . . . . 3-71
3.9.3.11 How and When Can You Display Documentation
Automatically? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-72
3.9.3.12 What Happens When Jobs Run Late? . . . . . . . . . . . . . 3-72
3.9.3.13 How Do You Create Optional Job Records? . . . . . . . . . 3-74
3.9.3.14 Copying Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75
3.9.4 Defining Optional Job Records . . . . . . . . . . . . . . . . . . . . 3-77
3.9.4.1 Defining a Job Criteria Record . . . . . . . . . . . . . . . . . 3-77
3.9.4.2 Defining a Job's Reason Code Record . . . . . . . . . . . . . 3-79
3.9.4.3 Defining a Job Information Record . . . . . . . . . . . . . . . 3-82
3.9.4.4 Creating a Job Message Record . . . . . . . . . . . . . . . . . 3-83
3.9.4.5 Defining a Job Resource Record . . . . . . . . . . . . . . . . . 3-85
3.9.4.6 Defining Job Node Records . . . . . . . . . . . . . . . . . . . 3-89
3.10 Displaying and Updating a Job Definition . . . . . . . . . . . . . . . 3-91
3.11 Deleting Job Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97
3.12 Analyzing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-101
3.13 Automatic Console Replies for Jobs . . . . . . . . . . . . . . . . . . . 3-104
3.13.1.1 To ADD a New Reply . . . . . . . . . . . . . . . . . . . . . . 3-105
iv Unicenter CA-Scheduler User Guide

3.13.1.2 ALTer or REPlace an Auto-Reply Record . . . . . . . . . . 3-107
3.13.1.3 To DELete an Auto-Reply Record . . . . . . . . . . . . . . . 3-109
3.14 Summary of Job Maintenance . . . . . . . . . . . . . . . . . . . . . . . 3-111
Chapter 4. Online Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.1 Online Monitoring Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
4.2 Displaying Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
4.2.1 Displaying a Specific Queue . . . . . . . . . . . . . . . . . . . . . . 4-5
4.2.2 Displaying Status for Specific Schedules and Jobs . . . . . . . . . 4-9
4.2.3 Displaying Status in Sequence . . . . . . . . . . . . . . . . . . . . 4-10
4.2.4 Different Types of Displays . . . . . . . . . . . . . . . . . . . . . . 4-11
4.2.4.1 Default Status Display . . . . . . . . . . . . . . . . . . . . . . 4-12
4.2.4.2 Sample Time Status Display . . . . . . . . . . . . . . . . . . . 4-13
4.2.4.3 Sample History Status Display . . . . . . . . . . . . . . . . . 4-14
4.2.4.4 Sample Schedule Summary Status Display . . . . . . . . . . 4-15
4.2.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
4.2.6 The Meaning of Status . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
4.3 Handling Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
4.3.1 Displaying Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
4.3.2 Sending Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
4.4 Handling Predecessor Conditions . . . . . . . . . . . . . . . . . . . . . 4-25
4.4.1 Posting Predecessors . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
4.4.2 Unposting Predecessors . . . . . . . . . . . . . . . . . . . . . . . . 4-25
4.5 Handling Global Parameters . . . . . . . . . . . . . . . . . . . . . . . . 4-27
4.5.1 Displaying Global Parameters . . . . . . . . . . . . . . . . . . . . 4-27
4.5.2 Setting Global Parameters . . . . . . . . . . . . . . . . . . . . . . . 4-28
4.6 Displaying Date and Autoscan Information . . . . . . . . . . . . . . . 4-29
4.7 Displaying Data Set Mask Names . . . . . . . . . . . . . . . . . . . . . 4-30
4.8 Displaying Network Information . . . . . . . . . . . . . . . . . . . . . 4-31
4.9 Controlling Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
4.10 Controlling Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
4.10.1 Running Jobs With The ADD Command . . . . . . . . . . . . . 4-36
4.11 Summing Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-39
Chapter 5. Criteria Language . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

5.1 Criteria Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
5.1.1 Reserved Words for Use in Boolean Expressions . . . . . . . . . . 5-3
5.1.2 Reserved Words Used for Selection . . . . . . . . . . . . . . . . . . 5-3
5.1.3 Reserved Words for Use in Predecessors . . . . . . . . . . . . . . . 5-5
5.1.4 Combining Selection and Predecessor Criteria Vocabulary . . . . 5-6
5.1.5 Using Multiple Conditions with ANDs and ORs . . . . . . . . . . 5-7
5.1.6 Affect of NOT Condition on Predecessors . . . . . . . . . . . . . . 5-8
5.1.7 Recommended Method for Defining Selection Criteria . . . . . . . 5-8
5.2 Calendar Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
5.2.1 Gregorian Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
5.2.2 Datetables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
5.2.2.1 Workday Keywords . . . . . . . . . . . . . . . . . . . . . . . . 5-12
5.2.2.2 Accounting-Period Keywords . . . . . . . . . . . . . . . . . . 5-12
5.2.2.3 Summary of Datetables . . . . . . . . . . . . . . . . . . . . . . 5-15
5.2.2.4 Date Translation Table Report . . . . . . . . . . . . . . . . . . 5-15
Contents v
5.2.3 Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
5.2.3.1 Step 1: Define the prototype calendar . . . . . . . . . . . . . 5-17
5.2.3.2 Step 2: Define daily, weekly and monthly calendars . . . . 5-19
5.3 Some Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
5.4 What Is Wrong with These Examples? . . . . . . . . . . . . . . . . . . 5-25
5.5 Summing Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
Chapter 6. Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

6.1 Commonly Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
6.1.1 Startup Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
6.1.1.1 When Should Autoscan Be Performed? . . . . . . . . . . . . . 6-3
6.1.1.2 What Is the General Standard for Numbering Stations? . . . 6-3
6.1.1.3 Should I Use Datetables or Calendars? . . . . . . . . . . . . . 6-4
6.1.1.4 When Should I Define a New Datetable Versus a New Cycle
in an Existing Datetable? . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
6.1.2 Maintaining the Database . . . . . . . . . . . . . . . . . . . . . . . . 6-4
6.1.2.1 How Should I Organize My Schedules? . . . . . . . . . . . . . 6-4
6.1.2.2 Is There a Fast Way to Add Data to the Database? . . . . . . 6-5
6.1.2.3 When Should a Job Be Staged? . . . . . . . . . . . . . . . . . . 6-5
6.1.2.4 When Is a Job Submitted? . . . . . . . . . . . . . . . . . . . . . 6-7
6.1.2.5 What Are Global Parameters and When Are They Used? . . 6-7
6.1.2.6 How Can I Run a Job Like an Edit Check Repeatedly until Its
Output Is Correct? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
6.1.2.7 How and When Can I Display Documentation Automatically? 6-9
6.1.2.8 What Are My Options When a Job Abends? . . . . . . . . . 6-10
6.1.3 Analyzing the Database . . . . . . . . . . . . . . . . . . . . . . . . 6-10
6.1.3.1 How Can I Prevent Predecessor Loops? . . . . . . . . . . . . 6-10
6.1.3.2 When Should I Run Forecasts? . . . . . . . . . . . . . . . . . 6-11
6.1.3.3 When Should I Run Simulation? . . . . . . . . . . . . . . . . 6-11
6.1.3.4 How Do I Plan when To Run a New Application? . . . . . 6-12
6.1.3.5 How Do I Verify a New Application? . . . . . . . . . . . . . 6-12
6.1.3.6 Is There a Way that I Can Create My Own Reports? . . . . 6-14
6.1.4 Daily Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
6.1.4.1 From Where Can I Issue Unicenter CA-Scheduler Operator
Commands? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
6.1.4.2 What Is the Difference Between FORCE, SUBMIT, RERUN,
RUN, ADD, REQUEST, and SREQ? . . . . . . . . . . . . . . . . . . 6-16
6.1.4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
6.1.4.4 When Is the PRED Flag Reset? . . . . . . . . . . . . . . . . . 6-18
6.1.4.5 What Happens If There Was a System Crash? . . . . . . . . 6-18
6.2 Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
6.2.1 Using Operator Commands on the Status Display Panel . . . . 6-20
6.2.2 Cancelling and Purging a Job . . . . . . . . . . . . . . . . . . . . . 6-20
6.2.3 Changing Criteria on Selected Jobs . . . . . . . . . . . . . . . . . 6-20
6.2.4 Backlogging Over Two Autoscans . . . . . . . . . . . . . . . . . . 6-21
6.2.5 Resetting Global Parameters . . . . . . . . . . . . . . . . . . . . . 6-21
Chapter 7. Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

7.1 On-Request Schedules and Jobs . . . . . . . . . . . . . . . . . . . . . . . 7-2
7.1.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
7.1.2 Criteria Language Subtleties . . . . . . . . . . . . . . . . . . . . . . 7-3
vi Unicenter CA-Scheduler User Guide

7.1.2.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.1.2.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.1.2.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.1.2.4 Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.1.2.5 Example 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
7.1.2.6 Example 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
7.1.2.7 Example 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
7.1.2.8 Example 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
7.1.2.9 Example 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
7.1.2.10 Example 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
7.2 Backlogged Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
7.2.1.1 In Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
7.3 Issuing Online Commands in Batch . . . . . . . . . . . . . . . . . . . . 7-10
7.3.1 Transaction Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
7.3.2 Status Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
7.3.3 Some Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
7.3.3.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
7.3.3.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
7.4 Restart/Recovery of Scheduled Jobs . . . . . . . . . . . . . . . . . . . 7-16
7.4.1 Inquiring About Jobs to Be Recovered . . . . . . . . . . . . . . . 7-16
7.4.2 Automatic Recovery Options . . . . . . . . . . . . . . . . . . . . . 7-17
7.4.3 Unicenter CA-Driver Considerations . . . . . . . . . . . . . . . . 7-18
7.5 Multiple CPU Considerations . . . . . . . . . . . . . . . . . . . . . . . 7-19
7.5.1 Installation Considerations . . . . . . . . . . . . . . . . . . . . . . 7-20
7.5.2 Control Of Jobs in a Multi-CPU Environment . . . . . . . . . . . 7-20
7.5.3 Recovery Of Jobs in a Multi-CPU Environment . . . . . . . . . . 7-23
7.5.4 Non-Shared POWER Considerations . . . . . . . . . . . . . . . . 7-25
7.6 NJE Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26
7.6.1 Cross-Node Job Submission . . . . . . . . . . . . . . . . . . . . . . 7-26
7.6.2 Cross-Node Dependencies . . . . . . . . . . . . . . . . . . . . . . . 7-28
7.6.2.1 NJE Job Dependencies . . . . . . . . . . . . . . . . . . . . . . 7-29
7.6.3 Cross-Node Command Processing . . . . . . . . . . . . . . . . . . 7-29
7.6.4 Installation Considerations . . . . . . . . . . . . . . . . . . . . . . 7-31
7.6.4.1 CAIJGEN Macro . . . . . . . . . . . . . . . . . . . . . . . . . . 7-31
7.6.4.2 VTAM Communications . . . . . . . . . . . . . . . . . . . . . 7-31
7.6.5 Control Commands for Checking The NJE Network . . . . . . . 7-32
7.7 Summing Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34
7.7.1 On-Request Schedules and Jobs . . . . . . . . . . . . . . . . . . . 7-34
7.7.2 Backlogged Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34
7.7.3 Online Commands in Batch . . . . . . . . . . . . . . . . . . . . . . 7-34
7.7.4 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-35
7.7.5 Multi-CPU Considerations . . . . . . . . . . . . . . . . . . . . . . . 7-35
7.7.6 NJE Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-36
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-9
Contents vii
Chapter 1. Introduction
Unicenter CA-Scheduler Job Management for VSE (Unicenter

CA-Scheduler) is designed to automate production control and oversee
operations at VSE sites. To accomplish this, Unicenter CA-Scheduler centralizes
all scheduling information into a single database. As you begin implementing
Unicenter CA-Scheduler, focus on scheduling CPU processing first. However,
this database can ultimately control every production task in the data center,
from data preparation through output delivery.
Unicenter CA-Scheduler automates production control by scanning the

database to identify each day's workload. It oversees operations by
■ Ensuring that tasks are performed in proper sequence
■ Allowing you to monitor the work flow online
■ Permitting you to adjust the day's workload as needed
Because Unicenter CA-Scheduler is so versatile, it allows you to choose only

those features and options appropriate to your site.
This chapter provides a high-level introduction to the terminology, key

concepts, and basic capabilities of Unicenter CA-Scheduler. Succeeding topics
expand on these topics in more detail.
Chapter 1. Introduction 1-1

1.1 Beginning with the Basics

Ironically, job scheduling for multi-million-dollar computers is often handled
with an in-box or a chalk board. With Unicenter CA-Scheduler, you can use
the computer you already have to automate production.
Unicenter CA-Scheduler looks at job processing the same way you do: jobs
start and end with the user and a job is not done until the output is delivered.
If you trace the path of a job through your data center, it passes through
different areas before and after CPU processing:
Unicenter CA-Scheduler calls each of these areas a workstation and has you
assign numbers to them. Since all sites have JCL setup and CPU processing,
Unicenter CA-Scheduler assigns those station numbers automatically (stations
39 and 40). Notice that pre-CPU station numbers are in ascending order up to
39. Post-CPU stations are also numbered sequentially and can range from
41-99. This manual will reference the station numbers shown in the diagram
preceding.
Unicenter CA-Scheduler has you number workstations in ascending order for a

reason: that sequence tells Unicenter CA-Scheduler the logical flow of work
through your data center. Not all jobs are processed at every workstation:
some only run on the CPU, but if a job is scheduled at stations 39 and 40,
Unicenter CA-Scheduler knows that JCL setup should finish at station 39
before the job can be submitted to the CPU (station 40). To prevent mistakes
and reruns, Unicenter CA-Scheduler enforces workstation sequences: all of a
job's pre-CPU work must complete before its CPU processing can begin.
Unicenter CA-Scheduler can also think about work the same way you do. If
your production jobs are called AR004 or ARDAILY, use those same names
1-2 Unicenter CA-Scheduler User Guide

when you define jobs to Unicenter CA-Scheduler. Even if ARDAILY is a group

of jobs, you can still retain your familiar names. Because VSE sites run so
much production work, Unicenter CA-Scheduler has you group related jobs
together under one name, a schedule name.
Think of a schedule as a timetable: it tells Unicenter CA-Scheduler when

certain jobs run and which workstations they stop at. All jobs in the database
belong to some schedule.
Since you are allowed to have multiple schedules, you need to devise an
organized way of grouping jobs into schedules. Many sites group jobs by
application and frequency. If ARDAILY is one schedule, ARMNTHLY could be
another. When grouping jobs into schedules, keep in mind one thing: options
defined for a schedule apply to all jobs in that schedule which means you can
save time by defining options for an entire schedule, but you will always find
jobs that are exceptions. Unicenter CA-Scheduler allows you to override
schedule options by defining different values for the exceptional jobs: most
options defined at the job level override options set for a schedule.
Schedule Name When Jobs Run Job Names

ARDAILY Every day AR001
.
Most options defined for a
.
schedule apply to all the
AR014
jobs in that schedule.
ADDSTOCK
ADDSALES
ARMNTHLY Each weekend and AR030
each month end.
Override schedule options
with job options.
ARMNTHLY Only each weekend. ARPAID
ARDUE
Since Unicenter CA-Scheduler does not want to change how you name jobs, it
organizes its database using a method that works for all sites.
Unicenter CA-Scheduler uniquely identifies a task by knowing four values:

■ Job name
■ Job number
■ Workstation number
■ Schedule name
Four values are needed. First, job name alone usually is not enough to single
out every task performed at your site: too many applications have a JOB1 or
JOBA, but when job name is linked to schedule name, you come up with a
unique job ID. If you omit telling Unicenter CA-Scheduler the other two
values, workstation defaults to 40 and job number defaults to 01.

To show how a job passes through your data center, you define that job at
each workstation. But what if it takes three people to enter the data for JOBA?
Just define three workstations for data entry and schedule JOBA at all three
workstations. That keeps JOBA from running on the CPU until it ends at those
pre-CPU stations.
How does job number fit in? Suppose that you want to run JOBB twice a day,
at noon and after 9 p.m. at night. By varying job numbers, you can schedule
the same job several times a day.
That gives you a glimpse of how thoroughly Unicenter CA-Scheduler can

manage your data center, and why you could need all four values to find a

specific job definition in the database. When you are first implementing
Unicenter CA-Scheduler, you will start by just defining jobs at station 40 (CPU
processing). You will have the time to extend Unicenter CA-Scheduler to other
workstations once it starts automating some of your daily workload.
When defining schedules and jobs to the database, you specify when jobs
should run. Unicenter CA-Scheduler offers two methods for defining when
jobs run: calendars and selection criteria. The calendar method is less versatile
and requires more annual maintenance so will not be discussed here.
The preferred method for scheduling jobs uses Unicenter CA-Scheduler criteria
language. Keywords make it easy to define when to select jobs for the day's
workload:
DAILY Every day

MON OR WED OR FRI On Monday, Wednesday or Friday
MWF On Monday, Wednesday or Friday
APRIL AND 1ST On April 1st
WEEK-DAY On weekdays (Monday - Friday)
WEEK-END On weekends (Saturday and Sunday)
If you say that a schedule runs daily, Unicenter CA-Scheduler workload

includes all the jobs in that schedule every day. That is the most efficient way
to schedule daily jobs because you only specify the frequency once for all jobs
in the schedule.
Not all jobs run on the same days. Jobs within the same schedule do not have
to run every day the schedule does. For example, a schedule may run daily
but some jobs may only run on Monday and others may only run Friday. You
control when exceptional jobs run by defining a more limited frequency on
their job records. Remember that a job can only run on days when its
schedule is selected.
Whether Unicenter CA-Scheduler includes a job in the daily workload depends

on whether its selection criteria are met. The examples preceding show how
self explanatory the criteria language can be. However, its flexibility can
address every scheduling need.
Defining a job to run on Mondays is easy, but what happens when Monday is
a holiday? Unicenter CA-Scheduler knows when holidays occur because they
are defined on a datetable. Therefore, you can ensure that jobs run on the first
work day of every week by scheduling it on WDOW1 instead of Mondays. The
datetable tells Unicenter CA-Scheduler:
■ Which days are work days and holidays
■ When you need to perform special processing

This last feature allows you to define different accounting, production or sales
cycles that impact your operations workload. Using other criteria keywords,
Unicenter CA-Scheduler allows you to refer to these important days in your
selection criteria. For added flexibility, Unicenter CA-Scheduler allows you to
define up to 20 different kinds of cycles in each datetable, for endless numbers
of datetables. Just specify which datetable the criteria statements refer to when
you define schedules.
The criteria language tells Unicenter CA-Scheduler more than just what days
jobs run: it also shows when jobs must run in a special order. To indicate job
sequences, you define predecessors for jobs. These are events that have to occur
before that job can begin. Since you define job sequences along with selection
criteria, both schedules and jobs can have predecessors:
Schedule's Criteria Job's Criteria When A Job Can Run

JOBA After JOBA on the days
JOBA runs
MON JOBA After JOBA runs on
Mondays
WEEK-DAY AND When schedule SCHEDA
SCHEDA finishes on weekdays
The types of events that can be defined as predecessors include waiting:

■ For a specific job to start or finish
■ Until all jobs in a schedule end successfully
■ For a specific output data set to close
Before Unicenter CA-Scheduler can begin automating your production

workload, those jobs need to be defined in the Unicenter CA-Scheduler
database. Online, menu-driven panels prompt you for the scheduling
information that Unicenter CA-Scheduler stores in its database. After the
database has been created, Unicenter CA-Scheduler can begin to automate
your production workload.

1.2 How Unicenter CA-Scheduler Works

Unicenter CA-Scheduler database contains all of your scheduling information
including days, start times and events that impact job processing. Unicenter
CA-Scheduler automatically selects, schedules and submits jobs on the right
days, at the right time, in the right order, based on the information stored in
the database. How that process works is shown following.
Once a day, Unicenter CA-Scheduler scans the database to identify

■ Which schedules qualify for today's workload and
■ Which jobs in those schedules should run today
Unicenter CA-Scheduler calls this step autoscan. Authorized users can override
defined schedules when necessary and run a schedule or job at any time.
Schedules and jobs that are not normally selected can be added at the last
minute. Today's workload is copied to the Unicenter CA-Scheduler tracking
file along with any work that has carried over from yesterday as backlog.

Unicenter CA-Scheduler automatically submits jobs to the operating system

when they are ready to run. Unicenter CA-Scheduler decides that a job is
ready to be submitted to the operating system when
■ Its early start time has been reached
■ All predecessor conditions have been satisfied
■ The job has ended at all pre-CPU workstations
■ The job's defined resources are available
Jobs without early start times, without pre-CPU workstations, without

predecessors, and without defined resources are submitted when the database
is scanned. Unicenter CA-Scheduler locates the library in which the
appropriate JCL resides, retrieves it and submits it to the operating system.
Customarily, sites store the JCL for each job in a production JCL library.
Unicenter CA-Scheduler supports a wide variety of JCL library types:
■ CONDOR
■ Unicenter CA-Driver procedure library
■ AllFusion CA-Librarian
■ Allfusion CA-Vollie
■ VM/CMS files
■ AllFusion CA-Panvalet
■ User defined library
■ VSE PROC library
■ ICCF member
■ SLI member
Different jobs can have their JCL stored in different types of libraries. An
optional feature of Unicenter CA-Scheduler triggers the display of free-form
documentation on the operator's console at specified times. Your site might
implement this feature to display:
■ Job instructions when jobs become available to start, or
■ Restart instructions when a job abends
Customarily, sites store the JCL for each job in a production library. When
selecting the day's workload, Unicenter CA-Scheduler copies the JCL for jobs
requiring setup to the staging library.
Typically, setup means adding something like a date card to the JCL. For
easier online staging, Unicenter CA-Scheduler can highlight JCL statements
that require changes and can protect those that do not. The changes you make
affect the staged JCL without changing your production libraries. Using
Unicenter CA-Scheduler, the setup staff can
■ Display the jobs selected for staging
■ Display the staged JCL for each job
■ Make the changes online
■ Expand Unicenter CA-Driver procedures that are embedded in the JCL

■ Display the current values of Unicenter CA-Driver reserved variable

parameters
■ Change the values of any Unicenter CA-Driver reserved variable
parameters before each job's staging at workstation 39 is posted as
complete.
Unicenter CA-Scheduler assists in managing production job rerun/restart in

many different ways:
■ A backout job can be automatically submitted to undo the effect of an
abended job.
■ A schedule can be automatically added to the workload when a job
abends. The schedule can include any number of jobs to recover from or
restart the abended job.
■ The Unicenter CA-Scheduler utility program can be embedded in the
production JCL after strategic job steps, and can trigger different recovery
schedules depending on the abended step.
■ Unicenter CA-Driver procedures can be developed to automatically
generate different job streams depending on the abending step when a job
is submitted for a rerun.
False job completion frequently occurs. It is a case in which a job appears to

have run successfully (that is, no abend conditions or fail code returned from
the job), but in reality the job did NOT run successfully. The evidence is on the
job output (job log), or in the contents of the report produced by the job, or in
a message issued to the operator console by the job. False job completion
could be very costly when passed undetected since Unicenter CA-Scheduler
could submit numerous successors to a job that appeared to have run
successfully. Through the Auto-Reply processing facility false job completion
can be automatically detected and prevented. This is done by checking
console output for a job before Unicenter CA-Scheduler posts the job as
complete.
Users can communicate with Unicenter CA-Scheduler in online or batch mode.

All of the Unicenter CA-Scheduler monitoring functions are available from the
operator console as well. Online access is supported for CICS, CMS and ICCF.
Unicenter CA-Scheduler users can be assigned three levels of authority to

control what they can and cannot do. Controlling schedules can be limited to
authorized users. Users can also be limited to controlling jobs at certain
stations.
Security exits are also available for enhanced protection.
Unicenter CA-Scheduler automatically updates the status of all CPU jobs in the
tracking file. Unicenter CA-Scheduler assigns status conditions to jobs to
indicate the state of their progress within production. Only authorized users
can issue the commands that alter the status of tasks performed at other
stations.

Using Unicenter CA-Scheduler menu-driven panels, users at different

workstations can monitor the workload. Status displays allow authorized
users to monitor the entire day's workload or to selectively view different
categories of jobs such as
■ Those that are late
■ Those that are waiting for predecessors to complete
■ Those that have ended, comparing their scheduled start and end times to
actual run times
Now you have an idea of how Unicenter CA-Scheduler automates data center
scheduling, production control management and online tracking. Other
Unicenter CA-Scheduler features that can be implemented in your data center
are shown following.

1.3 Additional Features

Once you have implemented Unicenter CA-Scheduler at station 40, you are
ready to consider what the next implementation phase will be. The
possibilities are
■ Extending job definitions to other workstations
■ Running forecast, simulation and history reports
■ Activating the Unicenter CA-Scheduler progress notification feature
■ Expanding scheduling to multiple CPUs
Once Unicenter CA-Scheduler is automating production control for station 40

(CPU processing), think about extending that control to pre- and post-CPU
workstations. This would allow you to monitor key applications from start to
finish and alert you to possible production problems before they become
serious.
The Unicenter CA-Scheduler reporting facility provides a variety of reports

online or on hardcopy. These reports focus on different facets of production
control to help you address your most pressing concerns.
The Date Translation Table report shows when work day, accounting, and
Gregorian conditions (like MON) are true.
Production summaries report on various aspects of daily production that you

may want to monitor more closely:
■ Abended jobs
■ Completed jobs
■ Closed data sets
■ Job averages
History reports provide statistics on how long it should take to perform every
task and show how long it actually took.
Forecasts show you in advance which schedules and jobs will be selected on
any day in the future and what the workload will be like at any station. A
summary report shows at a glance which schedules and jobs will be selected
for an entire month. Additional forecast reports provide lists of required
resources, lists of predecessors, and run books for all selected jobs.
Simulation reports answer the question "what if." Unicenter CA-Scheduler can
run simulations without affecting the live scheduling operation and its reports
show
■ Which jobs would be selected
■ What resources would be required
■ When and where each job would be processed
■ The extent to which each device would be utilized
■ Which jobs would be late

■ Which jobs would have to be carried over in backlog to the next day
What if your system goes down? You can run revised simulation reports that
examine the current status of your workload and project what will happen
given the time remaining.
File Status reports allow you to check the status of the principle Unicenter
CA-Scheduler files:
■ Master database
■ Tracking file
■ Staging file
■ Documentation file
Use these reports to determine when the files require reorganization (REORG
command).
The Mailbox report provides a common area to route Unicenter CA-Scheduler

messages so that any user can read them.
Successor Chain List reports provide a way of listing a job's or schedule's

successors either globally or up to a specified level. The reports can be
generated online for the current workload or forecasted for a future date.
Analysis reports can be used from batch or online to determine whether a

schedule or job has any missing or illogical records.
A variety of Advantage CA-Earl reports provide detailed information on the

principle Unicenter CA-Scheduler files:
■ Master database
■ History file
■ Tracking file
■ Staging file
■ Documentation file
A subset of Advantage CA-Earl is provided with Unicenter CA-Scheduler so

that you can create Advantage CA-Earl reports to suit your data center's needs.
In addition, many ready-to-use reports are provided for you to use as is or
modify to your liking.
The CAISERV facility allows you to produce diagnostic reports for checking the
current values of product options and assisting in troubleshooting problems.
To better monitor production, you can cause messages to be sent to different

users when schedules or jobs:
■ Start or end
■ Are late starting or ending

■ Abend, fail or are purged

■ Run too long
Routing of late messages can be defined globally as an installation option. You

can specify recipients for other messages using a schedule or job option.
Messages can also be logged to the CAICUI data set.
Unicenter CA-Scheduler can run two different ways in a multi-CPU

environment:
■ All jobs can automatically be scheduled and submitted to one master CPU
before they are routed by POWER to another CPU for execution.
■ Or each CPU can schedule and submit its own work. In either event,
Unicenter CA-Scheduler can cope with system failure by moving control to
another CPU.
You can implement Unicenter CA-Scheduler different ways within networks:

■ To centralize scheduling, design a network following the master/slave
principle: do job scheduling at one node of a centralized system and route
jobs to other nodes for execution.
■ Or let each node schedule its own work. Even if your network has
decentralized scheduling, jobs on one network can still be predecessors to
jobs scheduled on other networks.
Unicenter CA-Scheduler can handle the production traffic of the busiest data
centers.

1.4 Summing Up
1.4 Summing Up
The first step to implementing Unicenter CA-Scheduler is defining the
database. You will begin by defining jobs at station 40 (CPU processing).
Before you begin defining jobs, you need to devise an organized way of
grouping related jobs into schedules. While grouping jobs, keep in mind that
defining options for the entire schedule is the most efficient way to implement
Unicenter CA-Scheduler. Deal with exceptions by defining options for specific
jobs.
An important part of defining jobs is describing their selection criteria and

predecessors. The selection criteria determines which schedules and jobs
autoscan includes in the daily workload. Predecessors control the sequence in
which jobs are submitted to the CPU.
Since jobs are automatically submitted to the CPU, production staff can focus
more on other ways of improving service to their company. Management will
appreciate how Unicenter CA-Scheduler reports give an accurate picture of the
production workload so you can handle special requests more effectively and
plan for additional work during peak seasons.
Implementing Unicenter CA-Scheduler reflects a professional commitment to

efficient production and will maximize your data processing investment.
The chapter "Startup Tasks" shows new Unicenter CA-Scheduler users how to
begin implementing the product at their site. Its tutorial approach gives
step-by-step instructions in the left column with detailed explanations on the
right.
More experienced Unicenter CA-Scheduler users will find the troubleshooting

information in the chapters "Tips" and "Techniques" most useful.

Chapter 2. Startup Tasks
When Unicenter CA-Scheduler is first installed at your site, its database is

empty which means you need to perform some startup tasks before learning
about routine types of maintenance. This chapter is devoted to startup
instructions and introduces you to some of the basics of Unicenter
CA-Scheduler. Everyone should read the topic in this chapter called Getting
Started. The other topics in this chapter cover tasks that only concern people
with Manager authority level.
If Unicenter CA-Scheduler is new to your site, read this entire chapter.

Otherwise, just remember that you can look here to learn how to maintain:
■ Station records
■ Userids
Refer to these topics when you need to perform these tasks.
Chapter 2. Startup Tasks 2-1

2.1 Getting Started
2.1 Getting Started

To get the feel of Unicenter CA-Scheduler, the following tasks will be
described:
■ Logging on
■ Using the main menu
■ Getting help
■ Logging off
In this topic, logging on will be described first. Follow these instructions to

practice using Unicenter CA-Scheduler. Once you are comfortable doing these
tasks, you can start or stop these exercises at your convenience.
2.1.1 Logging On
Unicenter CA-Scheduler can run under CICS, CMS, or ICCF. Once you are
logged on to the appropriate system, how to start Unicenter CA-Scheduler will
be described.
How you start Unicenter CA-Scheduler depends on which system you are
using. Consult the chart following for the appropriate command.
To Start Unicenter CA-Scheduler Enter

From
CICS SCHD
CMS The name of the EXEC defined for
Unicenter CA-Scheduler. Write that
name here:
ICCF SCHDICCF
When you type that command and press ENTER, the Unicenter CA-Scheduler
Logon panel appears:
SCHD-LG LOGON CA-SCHEDULER

===> - RO
CONNECT : 4
USERID : master
READ PASSWORD : read
WRITE PASSWORD : write
CONNECT STATION : 4
PF1=HELP


2.1 Getting Started
Now you are ready to log on to Unicenter CA-Scheduler. What you type next
depends on how long Unicenter CA-Scheduler has been at your site:
■ If Unicenter CA-Scheduler was just installed at your site, type the values
shown on the preceding panel, tabbing from field to field. Do not press
Enter yet. These passwords are the values defined for the MASTER userid
when Unicenter CA-Scheduler is first installed.
■ If Unicenter CA-Scheduler has been around your site a while, those
passwords have probably been changed. Check with the person who
installed Unicenter CA-Scheduler to learn what values to use. Unicenter
CA-Scheduler userid and passwords do not have to match those you used
to signon to CICS, CMS, or ICCF.
Note: A write password is optional. However, logging on without it means

you can only display Unicenter CA-Scheduler data. To update data,
logon to Unicenter CA-Scheduler with your write password. Always
logon with your write password when you begin a practice session.
The last field links you to the workstation of your choice. However, not all
users can connect to all workstations; their choices are limited to those stations
included in their user record. When this field is left blank, Unicenter
CA-Scheduler automatically connects you to the first station listed in your user
record.
For now, type 40 as your connect station and press Enter. Unicenter
CA-Scheduler responds by displaying its main menu.
2.1.2 Using the Main Menu

When you have successfully logged on, Unicenter CA-Scheduler displays its
main menu:

2.1 Getting Started
SCHD-MM MAIN MENU CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
-------SELECT FUNCTION-------
==> ONLINE SCHEDULE STATUS

==> ONLINE MONITORING
==> REPORTING FACILITY
==> POWER INTERFACE
==> SCHEDULE MAINTENANCE
==> JOB MAINTENANCE
==> USER ID MAINTENANCE
==> STATION MAINTENANCE
==> RESOURCE MAINTENANCE
==> CALENDAR MAINTENANCE
==> DATETABLE MAINTENANCE
==> STAGED JCL MAINTENANCE
==> DOCUMENTATION MAINTENANCE
==> DRIVER PROC MAINTENANCE
==> AUTO-REPLY MAINTENANCE
==> GENERATION PARM DISPLAY
PF1=HELP

When you logon to Unicenter CA-Scheduler without a write password, this
message appears on the third line of the main menu:
CACO238I WRITE PASSWORD VERIFICATION FAILED-READ ONLY
Everything you will need to do with Unicenter CA-Scheduler starts here. To
select a function, tab the cursor to that line and press Enter. Try selecting any
function now.
Once you press Enter, Unicenter CA-Scheduler displays the appropriate panel.
To return to the Main Menu, press Clear.
No matter how deeply you have gone into Unicenter CA-Scheduler, you can
always return to this panel by pressing Clear repeatedly.
2.1.3 Getting Help

Next the HELP facility will be described. Notice that the bottom line of that
panel shows PF1=HELP. To display HELP for any panel in Unicenter
CA-Scheduler, press PF1 (or PF13). If your terminal does not have PF keys,
type HELP in the command area and press Enter.
When you request HELP, Unicenter CA-Scheduler usually shows a panel like
this (some HELP panels will vary depending on the complexity of the panel
that calls them):

2.1 Getting Started
To select the topic you need help with, type a number in the command area
and press Enter.
Some HELP panels contain more text than can be displayed on one physical
panel. A -- MORE -- prompt at the bottom of the panel tells you that more
text follows. Press PF8 or enter FORW1 to continue to the following text.
While you are exploring HELP, notice the function keys defined on the bottom
line. If your terminal does not have function keys, enter the equivalent
commands on the command line instead. The chart following describes what
these keys and commands do.
PF Key Command Causes Unicenter CA-Scheduler To

PF1/13 HELP Explain how to use the HELP facility
PF3/15 PREVLV Display the last HELP panel
PF4/16 INITIAL Display the initial HELP panel
PF7/19 BACK1 Display previous text in the same HELP
panel
PF8/20 FORW1 Display following text in the same HELP
panel
PF12/24 EXIT Exit from HELP (returns you to Unicenter
CA-Scheduler panel). The Clear key does
the same thing.

2.1 Getting Started
After you have explored HELP a bit, return to the main menu. Remember that
Clear always takes you back to the last menu you used.
While you are using Unicenter CA-Scheduler, you are sure to run into
messages that Unicenter CA-Scheduler displays on the third line of your panel.
Since that space is limited, you may want a longer explanation of what has
happened. Unicenter CA-Scheduler will give you more details if you type this
in the command area: HELP MSG followed by the message number. (Notice
that message codes start with four letters followed by three numbers and
sometimes an additional one-letter action code.)
Now that you know how HELP works, feel free to check what HELP has to
say about the panels you will be working with.
2.1.4 Logging Off

There are two ways to log off of Unicenter CA-Scheduler. Choose a method
depending on where you are in Unicenter CA-Scheduler.
■ From the Logon panel or main menu, press Clear. If you are at another
Unicenter CA-Scheduler panel, the other method is more convenient.
■ From any menu or directory panel, enter /LOGOFF in the command area.
Try logging off Unicenter CA-Scheduler now. Then you can log on again in
preparation for the next topic.

2.2 Maintaining Stations

This topic covers the tasks involved in maintaining workstation definitions:
■ Defining stations
■ Changing station definitions
■ Deleting stations
■ Displaying station records
Since station records rarely require maintenance, most Unicenter CA-Scheduler

users do not need to read this topic. In fact, Unicenter CA-Scheduler only
permits users with Manager authority to maintain station records. Other
Unicenter CA-Scheduler users can only display existing station records. If and
when you need to work on your database's station records, consult this topic
for detailed instructions.
Bring up the Unicenter CA-Scheduler main menu as a starting point and tab to
STATION MAINTENANCE.

===> MASTER - WR
CONNECT : 4

==> POWER INTERFACE
==> JOB MAINTENANCE
_ ==> STATION MAINTENANCE
PF1=HELP

Then tab down to the eighth menu choice, STATION MAINTENANCE, and
press Enter.
That selection brings you to the Station Maintenance menu, which lists the
tasks you can choose from:

SCHD-WM STATION MAINTENANCE CA-SCHEDULER

===> _ MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY............(PRESS ENTER)
SELECTIVELY DISPLAY DIRECTORY.... 1,SELECT CRITERIA
DISPLAY SPECIFIC STATION......... 2,STATION NUMBER
ALTER STATION RECORD............. 3,STATION NUMBER
DEFINE STATION RECORD............ 4(,STATION NUMBER)
DELETE STATION RECORD............ 5,STATION NUMBER
PF1=HELP

If you logged on without a write password, Unicenter CA-Scheduler only
shows this menu's first three choices, which allow you to display station
records.
The following topics explain how to proceed when:

■ Defining new workstations
■ Changing existing station definitions
■ Deleting station definitions
2.2.1 Defining Stations

If Unicenter CA-Scheduler is new to your site, you should start building its
database by defining workstations. New Unicenter CA-Scheduler sites begin
by defining:
■ Station 40 as CPU processing and possibly
■ Station 39 as JCL setup
First, define the CPU station. On the Station Maintenance menu, DEFINE
STATION RECORD appears as option 4. Select that option by typing 4 in the
command area (===>) and pressing Enter.
If you are not assigned Manager authority level, Unicenter CA-Scheduler

displays the message CACO141E CREATE NOT ALLOWED on the third line
of the Station Maintenance menu. That message indicates that you are not
authorized to work with station records.
If your authority level permits you to define stations, Unicenter CA-Scheduler

displays the Station Definition panel:

SCHD-WU STATION DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
STATION ID : 4 PROTOTYPE STATION:

STATION NAME : cpu
TIME ZONE :
STATION TITLE : cpu station
STATION DESCRIPTION : Where the jobs are run
PF1=HELP

The only required field in the station record is STATION ID; the station name
and station title only appear on reports. Press the TAB key to move the cursor
from field to field. To define station 40 as the CPU station, enter the data
displayed on the panel preceding.
When defining other workstations, substitute appropriate values for the data
shown preceding. Your choice of STATION ID is important: Unicenter
CA-Scheduler expects jobs to flow through workstations numbered in
ascending order. The order in which you number workstations is the basis for
sequence enforcement. Therefore, be sure that:
■ Pre-CPU stations range from 01 to 39
■ Post-CPU stations use numbers 41-99 and
■ Station number sequence shows how work flows through your data center
When you are finished typing values on the Station Definition panel, press
Enter. Unicenter CA-Scheduler then informs you whether that record was
successfully added to the database.
If Unicenter CA-Scheduler adds the record to the database, it displays this

panel:
SCHD-UTIL SCHDUTIL OUTPUT CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
DEFINE STATION ID=4,NAME=CPU,TITLE='CPU STATION',

DESC='WHERE THE JOBS ARE RUN'
CACU18I STATION 4 CPU HAS BEEN ADDED
PF1=HELP

If Unicenter CA-Scheduler rejects this record, it displays other messages on the
same panel. For example, if you try to add a station number that is already
defined in the database, Unicenter CA-Scheduler displays this message:


===> MASTER - WR
CONNECT : 4
DEFINE STATION ID=4,NAME=CPU,TITLE='CPU STATION',

DESC='WHERE THE JOBS ARE RUN'
CACU15E DEFINE STATION CPU DUPLICATE RECORD
PF1=HELP

Does this mean Unicenter CA-Scheduler created a duplicate record? Whenever
you are in doubt, display help for that message number. If you try that, you
will see that Unicenter CA-Scheduler detected the duplicate record and
rejected it.
If Unicenter CA-Scheduler finds any errors, you can correct them by typing
directly onto the SCHDUTIL Output panel. Then press Enter again to add the
corrected definition to the database.
Alternatively, you can press Clear to:

■ Exit from the definition panel without entering a record in the database
■ Return to the maintenance menu and try the whole definition again or
■ Get ready to define another station
Now try defining a station on your own. Pick a number at random and type
your userid for STATION NAME and STATION TITLE. The examples
following use station 27. Jot down the number you use here so you can
practice changing and deleting your station later.
2.2.2 Updating Station Records

Unicenter CA-Scheduler gives you two ways of updating records:
■ One requires that you know the station number you want to change.
■ The other does not.
The first method follows.
Begin by checking which option on the Station Maintenance menu allows you
to update existing records:


===> _ MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

The instructions on this panel tell you to use option 3 to change an existing
record. Notice, however, that Unicenter CA-Scheduler expects you to enter the
station number when you select option 3. Therefore, when you type 3 in the
command area, follow it with a comma and the number of the station you
want to update.
Change the name of the workstation you defined. If you defined station 27,
enter 3,27 in the command area to retrieve that record.
If you are not assigned Manager authority level, Unicenter CA-Scheduler

displays the message CACO122E ALTER IS NOT ALLOWED on the third line
of your panel. That message indicates that you are not authorized to work
with station records.
If your authority level permits you to alter station records, Unicenter

CA-Scheduler displays the STATION ALTER panel.
SCHD-WU STATION ALTER CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
STATION ID : 27
STATION NAME : userid
TIME ZONE :
STATION TITLE : your userid
STATION DESCRIPTION :
PF1=HELP

Now you can alter anything but STATION ID in this record by tabbing to it
and typing over the old value. Try changing STATION NAME to your initials.

To submit this change to the database, press Enter. Or if you change your
mind about altering the record, press Clear. When you submit a change to the
database, Unicenter CA-Scheduler confirms that the station record changed by
displaying the message following:

===> MASTER - WR
CONNECT : 4
ALTER STATION ID=27,NAME=INITIALS

CACU18I STATION 27 INITIALS HAS BEEN ALTERED
PF1=HELP

Compare this approach to the alternate method for making changes. Begin by
returning to the Station Maintenance menu using the Clear key.
The other method for altering station records does not expect you to know
which station ID to change. Begin by displaying all station records stored in
your database.

===> _ MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

The first entry on the menu preceding tells you to press Enter to display a
directory of station records.

SCHD-WD STATION DIRECTORY CA-SCHEDULER

===> _ MASTER - WR
CONNECT : 4
ID STNAME TIME-ZN D E S C R I P T I O N
2 KEYPUNCH WHERE INPUT DATA IS KEYPUNCHED
21 KEYPUNCH
27 INITIALS
39 STAGING WHERE JCL CHANGES BEFORE JOBS RUN
4 CPU WHERE THE JOBS ARE RUN
6 OUTPUT WHERE OUTPUT IS DISTRIBUTED FROM
END OF DIRECTORY LIST
PF1=HELP

The stations you see listed are different than those shown here. However, you
should be able to spot the station you defined.
Select that station so you can alter its values. Start by tabbing down to that
line. Then type A and press Enter.
If your authority level permits you to alter station records, Unicenter

CA-Scheduler displays your station record so you can type in new values. Try
adding a station description such as you see following:
SCHD-WU STATION ALTER CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
STATION ID : 27
STATION NAME : initials
TIME ZONE :
STATION TITLE : your userid
STATION DESCRIPTION : This is a test record
PF1=HELP

Press Enter to save your changes or press Clear to cancel them. When
Unicenter CA-Scheduler has changed your station record, it confirms the
correction by displaying the message:
CACU18I STATION 27 INITIALS HAS BEEN ALTERED
Then press Clear until you return to the Station Maintenance menu.
2.2.3 Deleting Workstations

Deleting records is similar to altering them: Unicenter CA-Scheduler gives you
two methods to choose from. Which method you use depends on whether you
know what station number to delete.
To delete a specific station number, begin by checking which option on the

Station Maintenance menu allows you to delete an existing record.


===> _ MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

The preceding panel tells you that option 5 deletes an existing record. Notice,
however, that Unicenter CA-Scheduler expects you to enter the station number
when you select option 5. Therefore, when you type 5 in the command area,
follow it with a comma and the number of the station you want to delete.
Delete the workstation you defined. For example, if you defined station 27,
enter 5,27 in the command area to delete that record.
If you are not assigned Manager authority, Unicenter CA-Scheduler displays

the message CACO148E DELETE IS NOT ALLOWED. But if you have
Manager authority, Unicenter CA-Scheduler confirms you deleted that station
record with the message shown following:

===> MASTER - WR
CONNECT : 4
DELETE STATION ID=27

CACU18I STATION 27 INITIALS HAS BEEN DELETED
PF1=HELP

That's how simple it is to delete a station record. Before the alternate method is
demonstrated, take a moment to recreate the station record you just deleted.
Then you will be ready to continue.
If you do not know which station number you want to delete, display a
directory of stations using the Station Maintenance menu. Pressing Enter at
that menu causes the following panel to appear:


===> MASTER - WR
CONNECT : 4
21 KEYPUNCH
27 INITIALS THIS IS A TEST RECORD
PF1=HELP

Your entries will differ from those shown preceding, but you should be able to
pick out your station record. To delete that record, first tab down to it.
Before you typed A to alter the record. Now type L to delete it. Once again, if
you have Manager authority, Unicenter CA-Scheduler confirms that it deleted
the record by displaying the message:
CACU18I STATION 27 INITIALS HAS BEEN DELETED
2.2.4 Displaying Workstations

All Unicenter CA-Scheduler users can display station records. If you have
Manager authority, you saw one way of listing station records while you
practiced maintaining workstations. In all, you have three alternatives for
displaying station records:
■ Display a specific station number
■ List a subset of stations and choose one
■ List all stations and pick one
First, the record for station 40 will be displayed. On the Station Maintenance
menu, choices 1 and 2 both display a station record, but in different formats.


===> _ MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

Try option 2 first because it is faster. When you use option 2, Unicenter
CA-Scheduler expects you to specify a station number. To display the record
for station 40, try typing 2,40 in the command area. Unicenter CA-Scheduler
responds by displaying that station record on this panel:
SCHD-WU STATION DISPLAY CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
STATION ID : 4
STATION NAME : CPU
TIME ZONE :
STATION TITLE : CPU STATION
STATION DESCRIPTION : WHERE THE JOBS ARE RUN
PF1=HELP

This panel resembles the panel you used when defining station records. Now
compare that approach to another one that requires two steps. Return to the
Station Maintenance menu to try that alternate approach.
Try option 1, which requires you to specify some selection criteria. That criteria
can be the station number. Try typing 1,40 in the command area and pressing
ENTER. Unicenter CA-Scheduler responds by displaying that station record in
another format:


===> _ MASTER - WR
CONNECT : 4
PF1=HELP

Option 1 displays that record on the Station Directory panel. You may recall
that this panel allowed you to alter or delete records by typing the appropriate
command next to a specific record.
This panel also recognizes a third command, D, which causes the Station
Display panel to appear. Branch to that panel now by tabbing to the station 40
record and entering a D.
Then return to the Station Directory panel.
Option 1 on the Station Maintenance menu can be useful if you want to list a
group of related station numbers. To list all defined stations between 20 and
29, you can use the asterisk (*) as part of the selection criteria.
For example, if you type 1,*2 in the command area of the Station Maintenance
menu, Unicenter CA-Scheduler displays records for all station numbers that
start with 2:

===> _ MASTER - WR
CONNECT : 4
21 KEYPUNCH
PF1=HELP

Now return to the Station Maintenance menu to try the last method for
displaying station records.
The last method causes Unicenter CA-Scheduler to display all station records.
The instructions following review how that is done.
The first entry on the Station Maintenance menu tells you to press Enter to
display a directory of station records. Pressing Enter to view that listing:


===> _ MASTER - WR
CONNECT : 4
21 KEYPUNCH
PF1=HELP

One panel might not hold all the stations defined at your site. If that is the
case, the END OF DIRECTORY LIST message will not appear on your panel.
Instead, the list will end with the message:
PRESS ENTER FOR NEXT PAGE
When this message appears, press that key to view the remainder of the list.
Remember that Unicenter CA-Scheduler recognizes the following commands
when they are entered next to a specific station:
To Enter
Alter records A
Display records D
Delete records L
Before you start the next topic, return to the main menu by pressing Clear.
2.2.5 Summary of Station Maintenance

Unicenter CA-Scheduler only permits users with Manager authority to define,
alter and delete station records. Any user can display station records. For
quick reference, the steps involved in maintaining station records from the
Station Maintenance menu are summarized following. Since there are so many
ways to display records, only the fastest ways are shown:
■ A specific station
■ An unknown station
■ A specific station
■ An unknown station
■ One station record
■ Some stations
■ All stations

To Enter This In Command Then

Area
Define records
a specific station 3,station number Enter changes
an unknown
number Press Enter Tab to a station; enter
an A; make changes
Delete records for
a specific station
5,station number
an unknown
station
Press Enter Tab to a station; then
enter an L
Display
one station record 2,station number
some stations 1,*x where x is the first Tab to a station; enter

character of some station aD
IDs
all stations
Press Enter
Press Enter to scroll
panels

2.3 Maintaining User Records

All Unicenter CA-Scheduler users can display userid directories. All users
logged on with write passwords can change their own passwords and userid
descriptions. But only users with Manager authority can maintain all user
records.
User records control who does what with Unicenter CA-Scheduler. Only users
who are defined in Unicenter CA-Scheduler database can logon to that
product. Unicenter CA-Scheduler security goes a step further: user records
limit what people can do with Unicenter CA-Scheduler.
This topic covers what has involved in maintaining user records in the
Unicenter CA-Scheduler database. The topics explored next include:
■ User authority levels
■ The role of passwords
■ Defining users
■ Altering, deleting, and displaying user records
If you have already become familiar with maintaining stations, you will notice
that Unicenter CA-Scheduler handles these tasks in similar ways.
2.3.1 User Authority Levels

Three levels of authority control what defined users can do with Unicenter
CA-Scheduler. The lists following describe the basic capabilities of each
authority level.
General Authority is intended for end users, restricting:
■ The stations they can connect to
■ The database records they can maintain
■ The schedules they are authorized to monitor and control
General users are also allowed to display and alter their own
passwords and define online documentation.
Supervisor
Authority allows its users to:
■ Define, maintain, display, and control
All schedules
Jobs defined at stations for which each user is authorized
■ Define online documentation
■ Display and alter
Their own passwords
All staged JCL while connected to station 39
■ Display all other database records
■ Connect to just those stations listed on its userid

Manager Authority allows its users to:

■ Connect to all stations
■ Maintain all database records
■ Control all schedules
People with General or Supervisor authority can display and alter their own
user records. Only users with Manager authority can define, alter or display
user records for others. Whether users at any authority level can display or
update other database records depends on what passwords they have defined.
For a comprehensive list of the specific tasks permitted by each authority level,
see the description of the Userid Definition panel in the Unicenter CA-Scheduler
Reference Guide Part 1.
2.3.2 The Role of Passwords

Authority levels define what data users can access; but passwords control
whether users can update or just display that data. People need read
passwords to log on to Unicenter CA-Scheduler. Write passwords control a
user's capabilities in two ways:
■ You can prevent users from changing data by not assigning them a write
password.
■ Users assigned write passwords decide when they want to use that update
capability. If they logon to Unicenter CA-Scheduler with their write
password, they can update the database during that logon session, but if
they signon without specifying their write password, they can only display
data during that session.
2.3.3 Getting Started

All the tasks involved with maintaining user records originate from the same
menus. To initiate this kind of maintenance, begin at the Unicenter
CA-Scheduler main menu by tabbing to USER ID MAINTENANCE:


===> MASTER - WR
CONNECT : 4

==> POWER INTERFACE
==> JOB MAINTENANCE
_ ==> USER ID MAINTENANCE
PF1=HELP

Then tab down to the seventh selection, USER ID MAINTENANCE, and press
Enter. That choice displays the UserID Maintenance menu, which lists
everything you can do with user records.
SCHD-UM USERID MAINTENANCE CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
DISPLAY SPECIFIC USERID.......... 2,USERID
ALTER USERID RECORD.............. 3,USERID
DEFINE USERID RECORD............. 4(,USERID)
DELETE USERID RECORD............. 5,USERID,WRITPASS
PF1=HELP

If you logon without a write password, only the first three menu choices
appear on your panel. They allow you to display userid directories.
The following topics explain how to:

■ Define new user records
■ Change existing user definitions
■ Delete user records
■ Display user records

2.3.4 Defining Users

Unicenter CA-Scheduler only allows people with Manager authority to create
user records. To define a new userid, type 4 in the command area of the
UserID Maintenance menu and press Enter.
If your authority level does not permit you to create user records, Unicenter
CA-Scheduler displays the message CACO147E DEFINE NOT ALLOWED on
the third line of your panel. But if you have Manager authority, Unicenter
CA-Scheduler responds by displaying the UserID Definition panel.
SCHD-UU USERID DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
USER IDENTIFICATION : acctg
USERID READ PASSWORD: receipts
USERID WRITE PASSWORD:
USER ID DESCRIPTION :
CONNECT USERID TO STATIONS: 4
USERID TYPE (M,S OR G) :
PF1=HELP

The panel preceding shows that Unicenter CA-Scheduler only requires data in
the first two fields. If you press Enter, leaving the remaining fields blank,
Unicenter CA-Scheduler creates a user record with the following
characteristics:
■ UserID is ACCTG
■ Read password is receipts
■ User can only display data
■ Connect to station 40
■ General authority level
ACCTG is limited to displaying data because no write password was assigned.

The General authority level limits ACCTG to:
■ Connecting to station 40 and any other stations specified
■ Monitoring the status of jobs and schedules for which it is authorized
■ Displaying
– Its own user record
– Definition records for authorized jobs and schedules
– Staged JCL for authorized jobs if authorized for station 39
You can expand upon those capabilities by specifying additional information

on the user record.

To Allow Specify
General users to
A write password of up to eight
■ Update schedules and jobs for
alphanumeric characters. Authorize that
which they are authorized
user on the appropriate schedule.
■ Issue commands to control
schedules and jobs for which Same as preceding.
they are authorized at stations
for which they are authorized
■ Maintain schedule and job
definitions without
authorizing their user IDs on
Change their authority
every schedule
level to S or M
Users with Supervisor authority to
■ Monitor other workstations
Other station IDs separated by commas
(list the workstation they will monitor
■ Maintain all station and user most first).
records
Change USERID TYPE to M
The rules following summarize that chart, clarifying the kinds of authority you
can assign to users:
Rule #1: Always assign users a read password.
Rule #2: Assign write passwords to give people update permission and
the ability to issue commands to control schedules and jobs.
Rule #3: Give users extra authority by making USERID TYPE be S or M:
■ Supervisor authority allows people to maintain all schedule
and job records, and issue commands to control all schedules
at just those stations for which they are authorized.
■ Manager authority allows people access all database records
and control all jobs and schedules at all stations.
Most Unicenter CA-Scheduler sites assign end users General authority with or
without a write password. To define ACCTG with the minimal permissions
enter the data shown on the preceding panel and press Enter.
If Unicenter CA-Scheduler successfully adds this unique new user record to its
database, the following message panel appears:


===> MASTER - WR
CONNECT : 4
DEFINE USERID NAME=ACCTG,READPASS=RECEIPTS

CACU18I USERID ACCTG HAS BEEN ADDED
PF1=HELP

However, Unicenter CA-Scheduler may not be able to create that user record
for some reason. In that case, other messages would appear:
■ If you do not have Manager authority, Unicenter CA-Scheduler responds
by displaying the message
CACO147E DEFINE NOT ALLOWED
on the third line of your panel.
■ The same message also appears if you did not logon using your write
password.
■ If that userid already exists, Unicenter CA-Scheduler displays the following
panel:

===> MASTER - WR
CONNECT : 4
DEFINE USERID NAME=ACCTG,READPASS=RECEIPTS

CACU15E DEFINE USERID ACCTG DUPLICATE RECORD
PF1=HELP

Next, create two other user records with different types of authority:
For Define This Record

Operators User ID: OPERATOR
Read password: CONSOLE
Write password: SYSTEM
Connect: 40,39
Authority: S
Production control staff User ID: PRODCTRL
Read password: INPUT
Write password: OUTPUT
Connect: 40,39
Authority: M
Define these records now before proceeding to the next topic.

Unicenter CA-Scheduler allows people who log on as OPERATOR to issue

online commands to control all schedules at stations 39 and 40. If, when
logging on, they do not specify which station to connect to, Unicenter
CA-Scheduler automatically connects them to station 40. That is because 40 is
the first entry in the list of stations that ID is authorized to connect to.
Users logged on as PRODCTRL can do everything OPERATOR can do as well

as:
■ Connect to all stations
■ Maintain all database records
■ Log other users off after a crash
2.3.5 Updating User Records

Users with Manager authority can update any user records. Others with write
passwords can follow these instructions to change their own passwords.
Unicenter CA-Scheduler gives you two ways of updating records. The first
way requires that you know the userid you want to change.
Begin by checking which option on the User Maintenance menu allows you to
update existing records.

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

This panel tells you to use option 3 to change an existing record. Notice,
however, that Unicenter CA-Scheduler expects you to enter a userid when you
select option 3. Therefore, when you type 3 in the command area, follow it
with a comma and the userid you want to update.
To change ACCTG's user record by adding a write password, enter 3,ACCTG

in the command area to retrieve that record. If your authority level permits
you to alter that user record, Unicenter CA-Scheduler displays the UserID
Alter panel:

SCHD-UU USERID ALTER CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
USERID WRITE PASSWORD:
USER ID DESCRIPTION :
CONNECT USERID TO STATIONS:
USERID TYPE (M,S OR G) : G
PF1=HELP

Now you can alter anything in this record but USER IDENTIFICATION by
tabbing to the field and typing in a new value. Try extending ACCTG's
authority by defining a write password of profit which will permit the ACCTG
userid to:
■ Define jobs and schedules
■ Define online documentation to display at the console
■ Alter
Its read and write passwords
Jobs and schedules that specifically authorize that userid
Staged JCL if authorized for that station and job
■ Issue commands to control schedules that authorize that userid
To submit this change to the database, press Enter. Or, if you change your
mind about altering the record, press Clear. When you submit a change to the
database, Unicenter CA-Scheduler confirms that it is altered that user record
by displaying the message following:

===> MASTER - WR
CONNECT : 4
ALTER USERID NAME=ACCTG,READPASS=RECEIPTS,WRITPASS=PROFIT

CACU18I USERID ACCTG HAS BEEN ALTERED
PF1=HELP

Unicenter CA-Scheduler allows people with different authority levels alter
different fields in user records:

Users With Can Change

General and Supervisor authority ■ Their own read password
■ Their write password (if one already
exists)
Manager authority Any field in any user's record
Compare this editing approach to the alternate method for making changes.
Begin by returning to the UserID Maintenance menu using the Clear key.
The other method for altering user records does not expect you to know which
userid to change. Begin by displaying all user records stored in your database.

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

The first entry on the menu preceding tells you to press Enter to display a
directory of user records. Press Enter to view that listing:
SCHD-UD USERID DIRECTORY CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
USERID TYPE STATUS CONNECT STATIONS D E S C R I P T I O N

_ ACCTG G LOGOFF 4
MASTER M LOGON
OPERATOR S LOGOFF 4,39
PRODCTRL M LOGOFF
PF1=HELP

The user records you created should appear in the directory list that is sorted
alphabetically by userid. The STATUS field on this panel tells you which of
these users are currently logged on.

Select the userid ACCTG so you can alter its values. Start by tabbing down to
that line. Then type A and press Enter. If you do not have Manager authority,
Unicenter CA-Scheduler displays the message ONLY YOUR OWN USERID
CAN BE ALTERED.
If your authority level permits you to alter the ACCTG record, Unicenter
CA-Scheduler displays it so you can type in new values. Add a userid
description such as you see following:
SCHD-UU USERID ALTER CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
USERID WRITE PASSWORD: profit
USER ID DESCRIPTION : Accounting Department
PF1=HELP

Press Enter to save your changes or press Clear to cancel them. When
Unicenter CA-Scheduler has changed that user record, it confirms the
correction by displaying the message:
CACU18I USERID ACCTG HAS BEEN ALTERED
Press Clear until you return to the UserID Maintenance menu.
2.3.6 Deleting User Records

Unicenter CA-Scheduler gives users with Manager authority just one way to
delete user records from the database. Begin by checking which option on the
UserID Maintenance menu allows you to delete an existing record:


===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

however, that Unicenter CA-Scheduler expects you to enter a userid and
password when you select option 5. The password needed is the write
password of the userid you are deleting. Therefore, to delete a user record,
type 5 in the command area and follow it with a comma, the userid you want
to delete, another comma, and the write password of that userid.
Delete the ACCTG userid you defined by entering 5,ACCTG,PROFIT. If you

are assigned Manager authority, Unicenter CA-Scheduler confirms you deleted
that user record with the message shown following:

===> MASTER - WR
CONNECT : 4
DELETE USERID NAME=ACCTG,WRITPASS=PROFIT

CACU18I USERID ACCTG HAS BEEN DELETED
PF1=HELP

Before you continue with the next topic, try recreating the userid ACCTG.
Return to the UserID Maintenance menu so you will be ready to start the last
topic in this chapter.
2.3.7 Displaying User Records

All Unicenter CA-Scheduler users can list userids and display their own user
record. If you have Manager authority, you already saw one way of listing
userids while you practiced maintaining user records.
Basically, Unicenter CA-Scheduler offers you three different ways to display

user records. You can:

■ Display a specific user record

■ List all userids and pick one record to display
■ List a subset of user records before picking one
■ List userids that are logged on or logged off
Display the user record for ACCTG. On the UserID Maintenance menu,
choices 1 and 2 both display a user record, but in different formats.

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

Try option 2 first because it is faster. When you use option 2, Unicenter
CA-Scheduler expects you to specify a userid. To display the record for
ACCTG, type 2,ACCTG in the command area. Unicenter CA-Scheduler
responds by displaying that user record on this panel:
SCHD-UU USERID DISPLAY CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
USERID WRITE PASSWORD: profit
USER ID DESCRIPTION : Accounting Department
PF1=HELP

The preceding panel resembles the one you used when defining userids
because all fields in the user record are displayed. Option 1 accomplishes the
same thing in two steps. Return to the UserID Maintenance menu to try the
alternate approach.

Option 1 requires you to specify some selection criteria that can be a userid.
Type 1,ACCTG in the command area and pressing Enter. Unicenter
CA-Scheduler responds by listing that userid in another format:

===> _ MASTER - WR
CONNECT : 4

ACCTG G LOGOFF 4 ACCOUNTING DEPT
PF1=HELP

Option 1 lists that userid on the UserID Directory panel but omits passwords.
If this panel looks familiar, you may recall that you can alter user records by
entering the A command next to a specific userid.
This panel also recognizes another command, D, which causes Unicenter

CA-Scheduler to display the entire user record on the UserID Display panel.
Branch to that panel by tabbing to the ACCTG record and entering a D.
After seeing both ways, you will probably use option 2 to display a user
record because it is more efficient. To try displaying records using other
methods, first return to the UserID Maintenance menu.
This method causes Unicenter CA-Scheduler to alphabetically list all userids.

The instructions following review how that is done.
The first entry on the UserID Maintenance menu tells you to press Enter to
display a directory of user records. Press Enter now to view that listing:

===> _ MASTER - WR
CONNECT : 4

ACCTG G LOGOFF 4
MASTER M LOGON
OPERATOR S LOGOFF 4,39
PRODCTRL M LOGOFF
PF1=HELP

One panel might not hold all the userids defined at your site. If that is the
case, the END OF DIRECTORY LIST message will not appear on your panel.
Instead, the list will end with the message:

To display a userid's complete record, you would tab to that userid and enter
a D.
Remember that Unicenter CA-Scheduler recognizes the following commands

when they are entered next to a specific userid:
To Enter
Alter records A
Display records D
Scrolling through several panels full of userids to locate the one that interests
you could be a bother. That is why Unicenter CA-Scheduler offers yet another
option. Before you try the third method, return to the UserID Maintenance
menu by pressing the Clear key.
Option 1 can be useful if your userid directory is long and you want to list
userids that start with the same characters. For example, what if you made
several userids for production control that all start with PROD and end with
the user's initials. You could list these several ways using option 1 and the
asterisk (*):
To List Userids Starting With Enter

The letter P 1,*P
The same PROD prefix 1,*PROD
For example, typing 1,*P causes Unicenter CA-Scheduler to display records for
all userids that start with the letter P:

===> _ MASTER - WR
CONNECT : 4

PRODCTRL M LOGOFF PRODUCTION CONTROL
PRODLJB M LOGOFF LYNN BROWN
PRODPAS M LOGOFF PAT SMITH
PRODTFA M LOGOFF TERRY ANDERSON
PF1=HELP

Now return to the UserID Maintenance menu to try the last method for
displaying user records.

If users are logged on to Unicenter CA-Scheduler when your system goes

down, the MASTER userid needs to force logoffs for those users. The MASTER
userid can force other users off by typing
3,L,userid on the UserID Maintenance menu.
Any user can force a logon by typing
F,userid in the command area of the Logon panel.
You can check to see the status of users individually using the methods shown
preceding, or you can list userids based on their current status. Submit these
commands to Unicenter CA-Scheduler by entering them in the command area
of the UserID Maintenance menu.
To List Users Who Are Currently Enter

Logged on to Unicenter CA-Scheduler 1,L=ON
Logged off 1,L=OFF
To see who is logged on to Unicenter CA-Scheduler now, type 1,L=ON in the

command area and press Enter. Unicenter CA-Scheduler responds by
displaying a directory listing just those users currently running Unicenter
CA-Scheduler:

===> _ MASTER - WR
CONNECT : 4

MASTER M LOGON
PF1=HELP

2.3.8 Summary of User Maintenance

This list summarizes who can do what with user records:
■ All users can display userid directories.
■ Users with write passwords can change their own passwords.
■ Only users with Manager authority can maintain all user records.
■ Only the MASTER userid can force other users off by typing 3,L,userid on
the UserID Maintenance menu.
■ All userids
The chart following sums up the steps involved in maintaining station records
from the UserID Maintenance menu. Since there are so many ways to display
records, only the fastest ways are shown:

To Enter This In Command Then

Area
Define records
a specific userid 3,userid Enter changes
an unknown userid Press Enter Tab to a userid;

enter an A; make
changes
Delete a specific userid 5,userid,writpass
Display
one user record 2,userid
some userids 1,*x where x is the first Tab to a userid;

character of some user IDs enter a D
Press Enter
all userids Press Enter to scroll
panels

Chapter 3. Maintaining the Database
The Unicenter CA-Scheduler database contains the information that automates

production. Therefore, the maintenance of that database is crucial to your data
center's operation.
Unicenter CA-Scheduler users find they spend most of their time maintaining
schedule and job records. This chapter focuses on how to work with these
types of records using the Unicenter CA-Scheduler interactive panels. When
you finish this chapter, you will be able to define, display and update:
■ Schedule records
■ Job records
If Unicenter CA-Scheduler is new to your site, perform the startup tasks

described in the chapter "Startup Tasks." Then, the next step is defining your
production workload to Unicenter CA-Scheduler.
Chapter 3. Maintaining the Database 3-1

3.1 Defining Schedules

A schedule contains one or more jobs that are grouped together because they
share similarities. Jobs in the same schedule might all:
■ Belong to the same application
■ Run on the same day
■ Have the same operational dependencies or, most importantly,
■ Belong together because that is how your site is organized
Grouping jobs in schedules is easier because jobs can be selected whenever

their schedules are selected, and many schedule options apply to all jobs
within a schedule. That means you can define jobs faster if you specify their
common characteristics on a schedule record.
In this chapter, the examples we use do not store much information in

schedule records. But as time goes on, you will find it is easy to implement
special features such as
■ Having Unicenter CA-Scheduler issue messages when work falls behind or
■ Defining when to submit jobs
by changing just schedule records instead of every job record.
All users with write passwords can define schedule records. This topic shows
you how by
■ Planning schedules
■ Defining a schedule base record
■ Checking which defaults apply to schedules
■ Learning the basics about a schedule record
■ Defining optional schedule records
3.1.1 Planning Schedules

As you start using Unicenter CA-Scheduler, do not try to automate everything
at once. If you do, you will be overwhelmed with details. Instead, start getting
comfortable with Unicenter CA-Scheduler by defining just a few simple
schedules first. You will start by outlining a schedule for your site's backup
runs. This example shows how easy defining a schedule can be. Later
examples will show optional features you can implement when defining
schedules.
When you are deciding what schedules to define for your site, keep these
guidelines in mind:
■ Group jobs into schedules by application first. If that gives you an
unmanageable number of jobs for one schedule, subdivide it based on
when jobs run.

■ Do not create a schedule for each day of the week. That approach is
difficult to implement and even harder to maintain. Instead, group jobs
belonging to the same application together in one or two schedules. That
makes it easier to verify predecessor relationships.
■ Likewise, put jobs that run upon request with the rest of those
applications' jobs. The goal here is to limit the number of cross-schedule
dependencies, keeping schedule maintenance and verification as simple as
possible.
■ Try to limit the number of jobs you put in schedules to under 50. Again,
the rationale is keeping things simple. Big schedules are more
cumbersome.
Now apply this advice to defining a schedule for backup jobs.
3.1.2 Defining a Schedule Base Record

Since schedules define the characteristics shared by groups of jobs, schedule
records primarily consist of optional fields. The simplest schedule definition is
stored on a base record. This topic explains how to define a simple schedule.
You begin defining schedules at Unicenter CA-Scheduler's main menu. Tab to

SCHEDULE MAINTENANCE.

===> MASTER - WR
CONNECT : 4

==> POWER INTERFACE
_ ==> SCHEDULE MAINTENANCE
==> JOB MAINTENANCE
PF1=HELP

Defining schedules is one form of schedule maintenance. Therefore, tab down
to the fifth selection and press Enter. That choice displays the Schedule
Maintenance menu, which lists everything you can do with schedule records.

SCHD-SM SCHEDULE MAINTENANCE CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
DISPLAY SPECIFIC SCHEDULE........ 2,SCHEDULE
ALTER SCHEDULE RECORD............ 3,SCHEDULE
DEFINE SCHEDULE RECORD........... 4(,SCHEDULE)
DELETE SCHEDULE RECORD........... 5,SCHEDULE
ANALYZE SCHEDULE................. 6,SCHEDULE
AUTO-REPLY PROCESSING............ 7,SCHEDULE
PF1=HELP

If you logon without a write password, the read-only functions appear on your
screen. They only allow you to display schedule directories, analyze a
schedule, or view auto-reply records. You need to logon with your write
password to practice defining schedules.
When the Schedule Maintenance menu appears, type 4 in the command area
and press Enter. Then the Schedule Definition panel appears.
SCHD-SU SCHEDULE DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
SCHEDULE NAME : _ PROTOTYPE SCHEDULE NAME :

SCHED PRIORITY:
AUTO SELECT : NO
DATETABLE NAME: SKIP :

RUN ON SYSID : BACKLOG : YES
NODE ID : STAGE JCL :
NODE SYSID : USE SIMTIME:
AVERAGE TIME:
USERS:
LIBRARY TYPE :
POWER CLASS :
POWER PRIORITY: POWER USER:
AUTO-REPLY MESSAGES: N
EARLIEST START TIME : MAXIMUM EXECUTION TIME :

MUST START BY TIME : COMPLETION DEADLINE TIME :
RECS= SBR: N SCR: N SRC: N SIR: N SMR: N PF1=HELP

This panel displays default values for three of its fields. Check what those
values do before deciding whether to change them.

AUTO SELECT controls whether Unicenter CA-Scheduler selects this schedule

automatically during autoscan. When AUTO SELECT = NO, this schedule is
skipped and its jobs are not included in the daily workload. That is exactly
what you want to happen while you are defining and testing a schedule and
its jobs, so do not change that field yet. Once you are satisfied with those
definitions, you will activate this schedule for automatic selection by changing
the value of AUTO SELECT to YES.
BACKLOG controls what happens if a schedule's jobs do not run on the day
they were selected. BACKLOG occurs on both schedule and job base records.
The value defined for a schedule applies to all jobs in that schedule unless you
specify a different value on a job base record. Since most sites usually want
jobs to carry over, leave BACKLOG = YES.
A complete explanation of how backlog works in Unicenter CA-Scheduler

appears later in this chapter.
AUTO-REPLY MESSAGES controls the automatic console replies for jobs. To

use this feature, auto-reply support must be selected in the Unicenter
CA-Scheduler generation options (see the CAIJGEN macro in the Unicenter
CA-Scheduler Systems Programmer Guide). This optional feature is discussed
later in the chapter. Leave AUTO-REPLY MESSAGES = N.
SCHEDULE NAME is the only field on a schedule record that requires input.
To name a schedule, type up to 8 characters (any combination of letters and
numbers). Name this schedule BACKUP. The cursor is already positioned at
the SCHEDULE NAME. Type BACKUP but do not press Enter yet.
The USERS field defines who can control and maintain this schedule. If you
leave this field blank, BACKUP becomes a public schedule that any user with a
write password can control or maintain. However, you may want to restrict
that capability to just a few users. With the USERS field, you define which
General users are authorized to control and maintain this schedule. Users with
Supervisor or Manager authority do not need to be authorized by the USERS
field because they can access all schedule definitions.
To be sure that you can work with this record later, tab down to the field
called USERS and type in your userid.
When you are defining schedule records, you will tab from field to field until
you have supplied all the values necessary. The other fields you see on this
panel do not require input. They are discussed later in the chapter. Finish
defining the backup schedule now.
The one distinctive thing about backup jobs is that they usually run at night.
Unicenter CA-Scheduler can continue that routine for you. Specify a value for
EARLIEST START TIME using 24-hour clock notation. For example, you can
hold the backup schedule until 11 p.m. by setting EARLIEST START TIME to
2300. Or, type 0100 to keep backup jobs from running before 1 a.m.

To save this schedule record, press Enter. Unicenter CA-Scheduler responds by

displaying the following panel:

===> MASTER - WR
CONNECT : 4
DEFINE SBR LASTUSER=userid,NAME=BACKUP,USERIDS=(userid),ERLYTIME=23

CACU18I SBR BACKUP HAS BEEN ADDED
PF1=HELP

If a schedule by that name already exists, Unicenter CA-Scheduler displays the
message:
CACU15E DEFINE SBR BACKUP DUPLICATE RECORD
If that message appears, try giving your schedule another name.
SBR in the messages preceding stands for Schedule Base Record, which is the
one required schedule record. Optional schedule records store other processing
information.
The Schedule Defines

Criteria record (SCR) ■ The days when this schedule is
selected
■ Predecessors for this schedule
Reason code record (SRC) Different times pertaining to the
schedule (early and late start times,
completion of deadlines, time limits)
depending on the reason why it was
selected that day (based upon its criteria
record)
Information record (SIR) Information that will be printed on
schedule reports
Message record (SMR) Messages to send users, informing them
of the schedule's progress
You will see how to define these other types of schedule records later in this
chapter. Press the Clear key to return to the Schedule Maintenance menu.

3.1.3 Checking Default Values for Schedule Base Records

Just as schedule options simplify the work of defining jobs, installation options
make defining schedules easier. Only one field in the schedule record requires
input: SCHEDULE NAME. All the other fields have defaults. To see which
schedule defaults were selected when Unicenter CA-Scheduler was installed at
your site:
■ Create a schedule record consisting of defaults.
■ Then display that record.
Most of the backup schedule you created consists of defaults, so just display
that schedule base record to see your site's default values.
The first three functions on the Schedule Maintenance menu allow you to
display a schedule base record:

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

Use option 2 because it is quicker. When you select option 2, Unicenter
CA-Scheduler also expects you to specify the name of an existing schedule in
the command area. To display the base record for your backup schedule, type
2 in the command area followed by a comma and the schedule's name,
BACKUP. For example, type 2,BACKUP and press Enter.
Unicenter CA-Scheduler responds by displaying that schedule base record:

SCHD-SU SCHEDULE DISPLAY CA-SCHEDULER

===> _ MASTER - WR
CONNECT : 4
SCHEDULE NAME : BACKUP

SCHED PRIORITY: 5
AUTO SELECT : NO

NODE ID: : STAGE JCL : NO
NODE SYSID : USE SIMTIME: NO
AVERAGE TIME:
USERS: userid
LIBRARY TYPE : CMS
POWER CLASS : A
POWER PRIORITY: POWER USER :
EARLIEST START TIME : 23 MAXIMUM EXECUTION TIME :

RECS= SBR: Y SCR: N SRC: N SIR: N SMR: N PF1=HELP

Notice that this panel displays more values than you specified for the backup
schedule. Many of the fields contain zeros, so skip those now. Instead,
concentrate on the fields that have nonzero values. Since your site's options
are probably different from Computer Associate's, the values you see
displayed are not the same as those shown preceding. Therefore, take a
moment to jot down your site's significant default values for schedules in the
alphabetical chart following.
Option Purpose Value

POWER CLASS Identifies the POWER CLASS
that is to appear on job
definitions for all jobs in this
schedule.
LIBRARY TYPE Identifies the library specified
as a generation option. It
contains the JCL for production
jobs.
RECS Shows which types of schedule
records have been defined. So
far, the schedule BACKUP only
consists of the schedule base
record you are looking at (SBR:
Y). The other types of schedule
records have not been defined
for that schedule yet.

Option Purpose Value

RUN ON SYSID In a multi-CPU environment,
identifies the SYSID of the CPU
that automatically selects and
submits the jobs in this
schedule. Leave this field
blank when you begin
implementing Unicenter
CA-Scheduler at your site.
RUN ON SYSID has no default
in a single CPU environment.
SCHED PRIORITY Determines the order in which
schedules are PRIORITY
evaluated when determining
which schedules can start. Most
sites ignore this field and use
other methods for sequencing
their workload.
STAGE JCL Controls whether the JCL for
these jobs is copied into the
staging library for editing prior
to submission. Since most jobs
do not require staging, STAGE
JCL is usually NO.
USE SIMTIME Can affect when this schedule
is started. Most sites ignore
this field and use other
methods for staggering their
workload. Set USE SIMTIME =
NO to ignore this field.
Check the values of these defaults to be sure they accurately represent your
site. Having the appropriate defaults will make defining schedules much
easier. To change installation options, speak with your systems programmer.
3.1.4 Learning the Basics About a Schedule Record

Unicenter CA-Scheduler provides many optional schedule fields so you can
define any characteristics common to the jobs in this schedule. Following is
what characteristics schedule records can define. Then how to analyze your
schedules to find out which characteristics the majority of jobs in each
schedule have in common is described.

3.1.4.1 When Will this Schedule Be Selected?
When Unicenter CA-Scheduler runs autoscan, it automatically selects that day's

workload. The selection process is a loop consisting of two steps:
■ First, Unicenter CA-Scheduler finds a schedule to select. Only schedules
with AUTO SELECT = YES are eligible for automatic selection. If AUTO
SELECT = YES, Unicenter CA-Scheduler checks the selection criteria
defined for that schedule to see whether that schedule should be selected
today.
■ Then it scans the selection criteria of every job in that schedule to select the
jobs belonging in that day's workload. When Unicenter CA-Scheduler
finishes with that schedule, it is ready to find another it can automatically
select today.
Jobs can only run on days when their schedules are selected. Jobs that run
daily must belong to schedules that are selected every day. That is why we
advise you to group an application's daily jobs into one schedule.
Initially, the default for AUTO SELECT prevents schedules from being
automatically selected. That gives you time to test schedule and job definitions
to be sure jobs run on the appropriate days. When you are satisfied with those
definitions, set AUTO SELECT = YES to have Unicenter CA-Scheduler include
that schedule among those it evaluates at autoscan time.
Three more fields control when schedules are selected: DATETABLE NAME,
SCR, and SKIP.
■ To select a schedule every day, leave DATETABLE NAME blank and do
not define a schedule criteria record (leave SCR: N).
■ To select a schedule only on certain days, you will need to define a
schedule criteria record (SCR). That criteria record may contain keywords
that refer to days defined in a datetable. If that datetable is the default, you
can leave the DATETABLE field blank. Otherwise, specify the appropriate
datetable name. See the chapter "Criteria Language" for detailed
instructions on how that is done.
■ Once you have set AUTO SELECT = YES, you may want to deactivate a
schedule for a while. You can use this advanced technique to handle such
exceptional situations, but normally you will not use the SKIP field.
Rather than setting AUTO SELECT = NO again, use the SKIP field to stop
selecting this schedule in autoscan for a while. Specify how many times you
want to skip this schedule when it ordinarily would be selected. For example,
suppose a schedule that normally runs on Friday instead ran on Tuesday this
week. Specify SKIP = 1 to prevent that schedule from running this Friday.
Every time Unicenter CA-Scheduler skips over a schedule it normally would
have selected, it decrements the value in the SKIP field by one until SKIP once
again is zero.

3.1.4.2 When Will a Schedule's Jobs Actually Run?
As Unicenter CA-Scheduler selects the day's workload, it organizes the work,

grouping each schedule's jobs together, but it does not line schedules up in the
order they are selected. Instead, Unicenter CA-Scheduler allows you to control
the work sequence with several schedule parameters:
■ SCR predecessors
■ USE SIMTIME
■ EARLIEST START TIME
■ SRC start times
■ COMPLETION DEADLINE TIME
■ SCHD PRIORITY
Defining predecessors forces Unicenter CA-Scheduler to witness a specific

event before starting any jobs in that schedule. Predecessors can be a variety of
events such as
■ The start or end of another schedule or job
■ The close of an output data set or generation data group
■ A user-defined event that you can control using a global parameter
■ An event that occurred sometime in the past
When schedules must run in a certain order, define schedules as predecessors

to one another using the schedule criteria record (SCR). See the chapter
"Criteria Language" for instructions on how that is done.
When Unicenter CA-Scheduler lines up the work to be processed during the

day, the first factor it considers is each schedule's predecessors. Then
Unicenter CA-Scheduler compares the start times for schedules, putting those
that can start earliest ahead of ones that start later. Schedules without
predecessors and start times go to the top of the list because nothing is
delaying them, so they start right after autoscan. SCHD PRIORITY is the last
factor Unicenter CA-Scheduler considers when organizing the workload and
only serves to sort schedules that have equivalent values for all the other
factors.
Unicenter CA-Scheduler gives you three ways of specifying when jobs start.
To see which method you chose, Unicenter CA-Scheduler checks the value of
USE SIMTIME. A value of YES causes Unicenter CA-Scheduler to start that
schedule at the time shown on the Simulated Execution Schedule.
If you set USE SIMTIME=YES, Unicenter CA-Scheduler ignores any other start
times you may have specified. Unicenter CA-Scheduler sites that have defined
their resources in great detail and run the vast majority of their production
load under Unicenter CA-Scheduler control could set USE SIMTIME=YES. The
accuracy of their history data and resource definitions would result in
simulations that project optimal start times for schedules. However, most
Unicenter CA-Scheduler sites leave USE SIMTIME=NO.

If USE SIMTIME = NO, Unicenter CA-Scheduler checks to see what start times
you have specified on the schedule record. You specify the earliest possible
time a schedule can start using a 24-hour clock. For example, an early time of
1400 allows a schedule to start no earlier than 2 p.m. in the afternoon. But
what if that schedule should not start until some day in the future? Unicenter
CA-Scheduler also allows you to specify start times with a prefix showing how
many days to delay the start of those jobs. For example, a start time of 031400
delays the start of that schedule until 2 p.m., three days after that schedule
was originally selected.
If USE SIMTIME=NO, Unicenter CA-Scheduler checks to see if a schedule's

reason code record contains start times. Since start time is an important factor
in sequencing your workload, Unicenter CA-Scheduler gives you flexibility.
For example, a schedule may need to start at different times on different days.
This is not a problem because Unicenter CA-Scheduler allows you to define
different reasons for selecting a schedule on its criteria record (SCR). Each
reason can cause that schedule to be selected on a different day. Once you
have defined reasons on the SCR, you can specify a different start time for
each reason. A schedule's alternate start times are stored on its reason code
record (SRC).
The last place Unicenter CA-Scheduler looks for a start time is EARLIEST
START TIME. If you do not specify a start time anywhere, Unicenter
CA-Scheduler only delays starting this schedule until its predecessor
conditions are satisfied.
When Unicenter CA-Scheduler organizes the work to be processed each day,

first it considers each schedule's predecessors. Then it checks start times. If
several schedules have the same predecessors and start times, Unicenter
CA-Scheduler puts those with earlier deadlines ahead of the others. Work that
has to be finished sooner goes first. You define deadlines in fields called
DEADLINE TIME on the reason code record or COMPLETION DEADLINE
TIME on the schedule base record.
Finally, Unicenter CA-Scheduler checks one last field when it's organizing the
workload. Schedules with the same predecessors, start times, and deadlines are
sorted by SCHED PRIORITY: schedules with the highest priority go first.
Priorities range from a high of 01 to a low of 99.
If, after checking all these fields, Unicenter CA-Scheduler finds a group of
schedules with equivalent values in all these fields, it lines up those schedules
in alphabetical order. The chart following summarizes how Unicenter
CA-Scheduler organizes its workload.
Sequence By Using On The

Predecessors Criteria language Criteria record

Sequence By Using On The

Start times USE SIMTIME = YES Base record
EARLY TIMEs Reason code record
EARLIEST START TIME Base record
Deadline DEADLINE TIMEs Reason code record
COMPLETION DEADLINE Base record
TIME
Priority SCHED PRIORITY Base record
Alphabetical order SCHEDULE NAME Base record
What if Unicenter CA-Scheduler does not complete some schedules in the

day's workload? Any jobs that are running when the next autoscan occurs are
always automatically backlogged, but what happens to jobs that have not
started yet?
BACKLOG fields control what happens if a schedule's jobs do not run on the
day they were selected. BACKLOG occurs on both schedule and job base
records. The value defined for a schedule applies to all jobs in that schedule
unless you override it by specifying a different value on a job base record.
Jobs that have BACKLOG=YES on their job base record (or default to
BACKLOG=YES on the schedule's base record) will always be backlogged if
they have not completed or been canceled by the next autoscan.
Jobs with BACKLOG=NO on their job base record (or default to

BACKLOG=NO on their schedule's base record) will be removed from the
workload if they are still waiting at the next autoscan.
If that schedule would also be selected tomorrow, the second set of jobs is
added to the workload after the backlogged schedule has completed and been
purged.

3.1.4.3 What JCL Does Unicenter CA-Scheduler Submit for These Jobs?
JCL for jobs under Unicenter CA-Scheduler control can be manually submitted
to the reader queue, but Unicenter CA-Scheduler can even automate that step
for you. Unicenter CA-Scheduler can retrieve JCL directly from
■ AllFusion CA-Panvalet,
■ User-defined libraries
■ A Unicenter CA-Driver procedure library
■ A CMS member
■ An ICCF member
■ An SLI source member
■ A PROC VSE procedure library
■ Allfusion CA-Vollie library member
■ CONDOR
However, sometimes production JCL requires editing before it can be

submitted. Two schedule fields tell Unicenter CA-Scheduler where to find the
JCL to submit for jobs in that schedule: STAGE JCL and LIBRARY TYPE.
Unicenter CA-Scheduler first determines which library contains the JCL for
these jobs by checking the LIBRARY TYPE. Then Unicenter CA-Scheduler
checks to see if this JCL requires editing. Since you can override a schedule's
value for STAGE JCL at the job level, Unicenter CA-Scheduler checks both
schedule and job base records. If STAGE JCL = NO, Unicenter CA-Scheduler
knows it can submit the production JCL directly to the CPU. However, if
STAGE JCL = YES, Unicenter CA-Scheduler copies the production JCL into the
staging library as soon as the job is selected. After that JCL has been edited
and staging is complete, Unicenter CA-Scheduler submits the edited JCL for
processing.
In the case where the JCL for a specific job is stored in a CA-Panvalet or OWL
library, Unicenter CA-Scheduler will submit a batch job that is a library access
job. This job will run in a partition and extract the actual job JCL from the
library and submit this JCL to POWER to be run.
3.1.4.4 Which CPU Should Control These Jobs?
The RUN ON SYSID field is used only in a multi-CPU environment. When

specified within a schedule definition, the RUN ON SYSID field value
designates a POWER SYSID that is then associated with the CPU that will
control and submit the jobs within that schedule.
Do not specify a RUN ON SYSID within a schedule definition if you have a

Unicenter CA-Scheduler Master/Slave, multi-CPU environment. This
environment determines the controlling CPU from the CAIJGEN installation
macro.

If your site has one CPU perform scheduling for all of them, it is called your
Master CPU. It is the first CPU listed on the SYSID= installation generation
macro parameter. Since that value is the default for a schedule's RUN ON
SYSID, you must leave that field blank on the schedule base record if your site
has a Master CPU.
NODE ID and NODE SYSID are only used at sites that are part of a network
that uses POWER/VSE at each node and Unicenter CA-Scheduler on each
CPU at every node. Only use NODE SYSIDs if there are multiple CPUs using
shared POWER spool at a NODE ID. Also notice that values for these fields
mean different things on schedule and job records.
NODE ID on the schedule record indicates the default NODE ID for the jobs in
that schedule. A job's NODE ID identifies which node the job's JCL is
submitted to. If a job runs on the node specified as the schedule's NODE ID,
you can leave NODE ID blank on the job record. To submit a job to another
node, specify its node ID on the job base record.
Suppose there are multiple CPUs at this node. Use NODE SYSID to specify a
particular CPU if the node has multiple CPUs that each run Unicenter
CA-Scheduler and share a POWER location. For NODE SYSID, enter the
POWER SYSID of the remote CPU where the job is to run. NODE SYSID is
only valid if NODE ID is also specified on the same record. When NODE ID
and NODE SYSID are given, that job base record's value for RUN ON SYSID is
ignored.
3.1.4.5 What Schedule Fields Are Used for Simulation?
Simulation is one of Unicenter CA-Scheduler's most powerful features. Without

actually running your workload, Unicenter CA-Scheduler can produce reports
showing
■ How heavily each device would be utilized
■ Which jobs would carry over to the next day
Such a planning tool gives Unicenter CA-Scheduler users an advantage when

dealing with the situations that confront a data center daily. Therefore, it is
worth your while to supply the values needed for simulation.
AVERAGE TIME allows you to specify the average processing time in days,
hours, and minutes. Leading zeros can be omitted. This optional field is only
used to prepare simulation reports. Use this field to have simulation reports
project the overall effect of a change in average processing time for this
schedule. If a time is not specified here, simulation uses the schedule's actual
average processing time based on historical $JOBACCT data.

Unicenter CA-Scheduler uses POWER CLASS to assign jobs to partitions on

the simulation reports.
3.1.4.6 What General Users Can Update this Schedule Record?
If anyone with General authority can update this schedule, leave the USERS
field blank so this becomes a public schedule. Otherwise, specify up to eight
userids separated by commas.
Example:
USERS: acctlbj,acctpas,accttfa,acctctrl
3.1.4.7 What Happens When Schedules Run Late?
Unicenter CA-Scheduler helps you manage your production workload by

alerting you to potential problems as quickly as possible. Therefore, when
Unicenter CA-Scheduler knows jobs are running late, it will warn you by
issuing messages. You can control when the messages are issued and who
receives them using fields on the schedule record.
If You Want When Schedules Specify A Value On The

Notification For
Start late MUST TIMEs or SRC
MUST START BY TIME SBR
Actually miss deadlines DEADLINE TIMEs or SRC
COMPLETION DEADLINE SBR
TIMER
Run too long MAXIMUM TIMEs or SRC
MAXIMUM EXECUTION TIMER SBR
SBR: schedule base record

SRC: schedule reason code record
You specify times for these fields in different ways:
MAXIMUM EXECUTION TIME tells Unicenter CA-Scheduler how long it

should take to process this schedule. The chart following illustrates the
different ways you can specify maximum execution time. Notice that leading
zeros can be omitted.
A Value Of Uses This And Means The Schedule Should

Notation Finish
30 mm Thirty minutes after it starts
200 hhmm Two hours after it starts

A Value Of Uses This And Means The Schedule Should

Notation Finish
10200 ddhhmm The next day two hours later than
it started (26 hours later)
Use a 24-hour clock to specify MUST START BY TIME and COMPLETION

DEADLINE TIME. The chart following shows that you can omit leading zeros
and you can extend the 24-hour clock by days.
A Value Of Uses This And Means Late Messages Will

Notation Be Issued
930 hhmm After 9:30 a.m. that day
1400 hhmm After 2 p.m. that day
11800 ddhhmm After 6 p.m. the next autoscan
day
Warning messages are sent to the operator if OPERATOR was specified on the
MSG installation option. If you want messages sent to other userids, specify
them in the schedule's optional message record (SMR).
3.1.4.8 Creating Optional Schedule Records?
The RECS fields at the bottom of schedule panels fulfill two functions:
■ The values displayed show whether each type record already exists for this
schedule. N means that type record has not been defined yet.
■ The fields allow you to input commands that will branch to these records.
The chart following shows what these commands can do.
If The Current Value Is Enter To

N C Create that record
Y A Alter that record
D Display that record
The chart following explains the purpose of each record type.

If You Want To Select This Record By Typing

C After
Define
-the days on which the schedule shedule SCR:
is selected
-predecessor conditions that must
be satisfied criteria
Assign different times to the schedule SRC:
schedule when it is selected for reason
different reasons code
Add information that will be schedule SIR:
printed on schedule report information
Send messages to users informing schedule SMR:
them of the schedule's progress message
The next topic covers the optional schedule records in detail.

3.2 Defining Optional Schedule Records

Now that you are familiar with the fields on the schedule base record, the
optional schedule records will be described. Do that by updating the schedule
base record. First check which option on the Schedule Maintenance menu
allows you to update existing schedule records.

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

The preceding panel informs you to use option 3 to change an existing record.
Notice, however, that Unicenter CA-Scheduler also expects you to state which
schedule you want to change. Therefore, when you type 3 in the command
area, follow it with a comma and the name of the schedule you want to
update.
Next, change the backup schedule you defined. If you defined a schedule
named BACKUP, enter 3,BACKUP in the command area to retrieve that
record.
If you are a user with General authority, Unicenter CA-Scheduler only permits
you to change that schedule record if:
■ This is a public schedule or
■ Your userid is listed as a value in that schedule's USERS field
If an unauthorized user tries to change an existing schedule definition,

Unicenter CA-Scheduler displays the message:
CACO229E USER NOT AUTHORIZED FOR THIS SCHEDULE
If your authority level permits you to alter that schedule record, Unicenter
CA-Scheduler displays the Schedule Alter panel.

SCHD-SU SCHEDULE ALTER CA-SCHEDULER

===> _ MASTER - WR
CONNECT : 4

SCHED PRIORITY: 5
AUTO SELECT : NO

NODE ID : STAGE JCL : NO
AVERAGE TIME:
USERS: userid
LIBRARY TYPE : CMS
POWER CLASS : A

RECS= SBR: Y SCR: N SRC: N SIR: N SMR: N PF1=HELP

To change any value displayed on this panel, tab to it, type in a new value,
and press Enter. If the new value does not completely overwrite the displayed
value, use the spacebar to blank out the rest of the field.
If desired, you can use this panel to eliminate any value in the SBR without
supplying a new one. Depending on the field type, either fill the field with
zeros or type NULL and blank out the rest of the field. If applicable, the value
will revert to the one defined in the CAIJGEN macro.
For example, what if you do not want an EARLIEST START TIME anymore?
Or you want to make this a public schedule?
■ To cancel a previously specified start time, fill in the field with six zeros.
■ To delete the value in the USERS field, type NULL and blank out the rest
of the field. This causes Unicenter CA-Scheduler to eliminate the value
previously defined for USERS and makes BACKUP a public schedule.
While you are altering the schedule base record, you can also create optional
schedule records by changing RECS values. Currently, the RECS values show
you which types of records already exist:
■ SBR: Y means the schedule base record has been defined.
■ Ns after the other abbreviations mean those record types do not exist.
You can tab to any RECS value and enter codes that allow you to create, alter
or display those schedule records.
Enter For Which Is This Type Of Record

C to create SCR Schedule criteria record

Enter For Which Is This Type Of Record

A to alter SRC Schedule reason code record
D to display SIR Schedule information record
SMR Schedule message record
The following text explores these optional schedule records by creating one of
each type. SBR: Y means a schedule base record already exists. To create
optional schedule records, type a C in place of the Ns following SCR, SRC, SIR
and SMR. Then press Enter.
When you change the values of RECS fields to A, C or D and press Enter,
Unicenter CA-Scheduler immediately branches to panels relating to those
records. The order in which they appear corresponds to the order they are
listed on schedule panels which means the Schedule Criteria Record (SCR) will
appear first if you have selected it.
3.2.1 Defining a Schedule Criteria Record

When you select SCR, Unicenter CA-Scheduler displays an editor panel where
you define the schedule criteria record. This record tells Unicenter
CA-Scheduler when to select this schedule for processing and what
predecessors must be satisfied before this schedule can start.
If you do not define a criteria record for a schedule, that schedule will be
selected every day and the schedule will have no predecessors.
To move the cursor into the area where you define criteria, press the TAB key
once.
SCHD-SCRE DEF C= S=BACKUP CA-SCHEDULER

===>
RANGE=1-72
1...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
1
2
3
d
7
8
9
17

There are two methods of defining when jobs are to be run:
■ One method uses calendars. If a datetable was not specified on the
schedule's base record, Unicenter CA-Scheduler allows you to enter the
name of a calendar after C= on the top line of this panel. Calendars
identify which days a job should run. If a calendar name appears on this

panel, that alone controls selection. When a calendar name is given, the
criteria statement only defines the schedule's predecessors.
■ The other method uses Unicenter CA-Scheduler's criteria language to
control selection and define predecessors. You define criteria statements by
entering data anywhere on lines 1 through 19 on this panel.
Most sites run backups daily, so you probably want this schedule to be
selected every day. However, on the days your databases are backed up, you
want to run backups after updating our site's databases. Therefore, the
DBUPDATE schedule should be a predecessor to the BACKUP schedule. How
the criteria language would handle this situation follows.
Start by typing SCD DBUPDATE OR on the first line and pressing RETURN.
Then type DAILY on the second line.
Although it really does not matter where on this panel you enter your criteria,
we recommend you type each reason for selecting a schedule on a separate
line because it is easier to see which reasons here correspond with fields on the
schedule's reason code record. If there is more than one reason for selecting a
schedule, each reason ends with OR (except the last one).
Note: Multiple ORs can be grouped into a single reason code by placing
parentheses around this reason. That means (MON OR FRI) is one
reason while MON OR FRI defines two reasons.
When you write criteria, you can embed comments anywhere by using /* as a
beginning delimiter and */ as an ending delimiter. These delimiters can appear
on different lines if the comment is longer than one line.
SCHD-SCRE DEF C= S=BACKUP CA-SCHEDULER

===>
RANGE=1-72
1...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
SCD DBUPDATE OR / END OF SCHEDULE DBUPDATE OR / 1
DAILY / EVERY DAY / 2
3
4
5
6
7
8
9
1
11
12
13
14
15
16
17
18
19
1...+....1....+....2....+....3....+....4....+....5....+....6....+....7...


A review of what the criteria statement SCD DBUPDATE OR DAILY does

follows. The OR without parentheses defines two reasons why this schedule
can be selected. Each reason will be examined independently:
■ This schedule is selected whenever the schedule named DBUPDATE is
selected, and on those days, the completion of DBUPDATE is a
predecessor to the backup schedule. All DBUPDATE jobs in the workload
must finish before any backup jobs can begin.
■ OR DAILY causes Unicenter CA-Scheduler to select the backup schedule
whenever DBUPDATE is not selected. On those days, this schedule has no
predecessors.
That means Unicenter CA-Scheduler selects the backup schedule every day.
And on days when DBUPDATE is selected, DBUPDATE is a predecessor to
BACKUP.
Does the order in that criteria statement matter? Would the statement
DAILY OR SCD DBUPDATE
yield the same result? Both statements cause the backup schedule to run on the
same days with the same predecessor. But there is a subtle difference
involving the reasons schedules are selected. Suppose DBUPDATE runs on
Mondays, Wednesdays and Fridays. Making DAILY the first reason in the
criteria statement means this schedule is always selected for that reason, but
putting DAILY last
(SCD DBUPDATE OR DAILY)
means that schedule sometimes is selected for the second reason.
Unicenter CA-Scheduler has an optional record that allows you to control

schedules differently depending on the reason why it was selected. Therefore,
make DAILY the second reason to implement different start times or
maximum durations for each reason. The next topic explains how to do that
using the schedule's optional reason code record.
For complete information on coding criteria statements, see the chapter

"Criteria Language."
To save this criteria record and leave this panel, type FILE in the command
input area. (Otherwise, you could leave the panel without saving this criteria
record by typing QUIT.)
All of the editor commands are inthe appendix "Editor Commands" in the
Unicenter CA-Scheduler Reference Guide, Part 2. The FILE command causes
Unicenter CA-Scheduler to immediately create that schedule's criteria record.
After you press ENTER, Unicenter CA-Scheduler displays the following panel,
which confirms that the record has been created:


===> MASTER - WR
CONNECT : 4
DEFINE SCR NAME=BACKUP,CRI='

SCD DBUPDATE OR
DAILY'
CACU18I SCR BACKUP HAS BEEN ADDED
PF1=HELP

To advance to the next panel, press Enter.
3.2.2 Defining a Schedule Reason Code Record

Unicenter CA-Scheduler enables you to modify reasons for selecting a schedule
using the schedule's reason code record. Unicenter CA-Scheduler can vary the
following fields based upon the reason a schedule is selected:
■ AVERAGE TIME
■ MUST START BY TIME
■ MAXIMUM EXECUTION TIME
The Reasons Definition panel allows you to specify up to 16 different values

for these five fields found on the schedule's base record. Unicenter
CA-Scheduler matches these values with reasons defined on the schedule's
criteria record: the first value here applies to the first reason for selection, and
so on. Enter the displayed values under EARLY TIME LIST and MAXIMUM
TIME LIST.
SCHD-SRC REASONS DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
SCHEDULE NAME : BACKUP PROTOTYPE SCHEDULE NAME :
AVG TIME LIST:

1 2 3 4 5 6 7 8
9 1 11 12 13 14 15 16
EARLY TIME LIST:
1 22 2 23 3 4 5 6 7 8
9 1 11 12 13 14 15 16
MUST TIME LIST:
1 2 3 4 5 6 7 8
9 1 11 12 13 14 15 16
DEADLINE TIME LIST:
1 2 3 4 5 6 7 8
9 1 11 12 13 14 15 16
MAXIMUM TIME LIST:
1 1 2 3 3 4 5 6 7 8
9 1 11 12 13 14 15 16
RECS= SBR: Y SCR: Y SRC: N SIR: N SMR: N PF1=HELP


The preceding panel shows different values defined for two fields. How does
this relate to the criteria statement SCD DBUPDATE OR DAILY?
■ On days when DBUPDATE runs, the backup schedule can begin any time
after 2200 (10 p.m.) and should take no more than one hour to run.
■ On other days, you might run fewer backup jobs, so the schedule can start
later (no earlier than 11 p.m.) and should only take 30 minutes.
Before you actually create this reason code record, examine all five fields on
this panel.
AVG TIME allows you to give simulation more precise average processing
times for this schedule. The fields here correspond to different reasons why the
schedule is selected. If you do not specify AVG TIME for the reason why the
schedule was selected, simulation uses AVERAGE TIME on the schedule base
record. If that field is also blank, simulation uses the actual average processing
time for this schedule derived from historical data.
EARLY TIME allows you to specify different start times for each reason a
schedule is selected. If you leave these fields blank, Unicenter CA-Scheduler
uses the value on the schedule base record every time the schedule is selected.
These values override EARLIEST START TIME on the schedule base record.
MUST TIMEs tell Unicenter CA-Scheduler to issue late messages at different

times for each reason schedules are selected. Suppose the backup schedule was
selected today for the second reason: DAILY. Then Unicenter CA-Scheduler
will issue a late message if the backup schedule has not started by the time
specified in the second MUST TIME field. These values override MUST
START BY TIME on the schedule base record.
DEADLINE TIMEs tell Unicenter CA-Scheduler to issue late messages if this

schedule is not finished by the deadline specified. Specify values here if you
want to define different deadlines for each reason the schedule was selected.
These values override the COMPLETION DEADLINE TIME you may have
specified on the schedule base record.
MAXIMUM TIMEs set limits on how long a schedule should run. If schedules
take longer, Unicenter CA-Scheduler will issue a late message. Specify values
here if you want to define different durations for each reason the schedule was
selected. These values override the MAXIMUM EXECUTION TIME specified
on the schedule base record.
Now that you are familiar with these fields, finish creating the reason code
record. After you have finished filling fields on the panel, press Enter.
Unicenter CA-Scheduler immediately sends this information to the database
and confirms this with the message:


===> MASTER - WR
CONNECT : 4
DEFINE SRC NAME=BACKUP,ERLY1=22,ERLY2=23,MAX1=1,

MAX2=3
CACU18I SRC BACKUP HAS BEEN ADDED
PF1=HELP

Use of reason codes provides you with tremendous scheduling flexibility. To
advance to the next panel, press Enter.
3.2.3 Defining a Schedule Information Record

All the schedule records you have defined so far contain information that
affects how Unicenter CA-Scheduler automates production at your site.
Usually, this record does not. A schedule's information record is purely for
your use. It stores descriptive information about this schedule that helps your
staff wrap up the work Unicenter CA-Scheduler began for you.
A schedule's information record only affects processing if your site has

implemented an optional simulation user exit. If so, the EXITPARM defined
here is passed to that user exit during simulation.
SCHD-SIR INFO DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
SCHEDULE NAME : backup PROTOTYPE SCHEDULE NAME :
DESCRIPTION : copies data sets to tape

COMMENT : rerun if this abends
EXITPARM
FORM : QUANTITY :
NOTIFY : j smith RESPONSIBILITY: j smith
VERIFY :
SPECIFICATION :
DESTINATIONS-1: tape 2:library 3: 4:

5: 6: 7: 8:
DELIVERABLES
1: backup tapes 2: 3: 4:
5: 6: 7: 8:
RECS= SBR: Y SCR: Y SRC: Y SIR: N SMR: N PF1=HELP

SCHEDULE NAME The only required value in an information record.
The other fields are optional and most allow you to
input anything you feel is appropriate. These field
names are intentionally general so you can record the
information you think will be most useful.

EXITPARM EXITPARM adjusts the default class or default

average processing time of all jobs in this schedule
during simulation. Unicenter CA-Scheduler passes
this value of up to 16 bytes to a user exit.
VERIFY Requires a specific response. Your choices are to
leave the field blank, or type in YES or NO. Use this
field for anything you want by setting up your own
standard for this field.
Next, create the information record shown preceding. As you tab from field to
field, type in the data displayed on the panel preceding. After you have input
that information, you are ready to create the information record.
After you have filled in the panel, press Enter to save the information record
for that schedule. Unicenter CA-Scheduler confirms that it stored that
information by displaying the following panel:

===> MASTER - WR
CONNECT : 4
DEFINE SIR NAME=BACKUP,DESC='COPIES DATA SETS TO TAPE',

COMMENT='RERUN IF THIS ABENDS',NOTIFY='J SMITH',
RESP='J SMITH',DEST1='TAPE',DEST2='LIBRARY',
DEL1='BACKUP TAPES'
CACU18I SIR BACKUP HAS BEEN ADDED
PF1=HELP

To view the next panel, press Enter. That displays the panel that defines the
last optional schedule record.
3.2.4 Defining a Schedule Message Record

The last optional schedule record helps implement Unicenter CA-Scheduler's
message capability by notifying users of a schedule's progress. Unicenter
CA-Scheduler is prepared to notify users of four events concerning schedules:
■ When schedules start
■ When they end
■ When they are late
■ When they run too long

SCHD-SMR MESSAGE DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
SCHEDULE NAME : backup PROTOTYPE SCHEDULE NAME :
SEND ALL MESSAGES TO : opctrl
SEND START MESSAGES TO :

SEND END MESSAGES TO :
SEND LATE MESSAGES TO : prodctrl,opctrl
RECS= SBR: Y SCR: Y SRC: Y SIR: Y SMR: N PF1=HELP

You can initiate those three kinds of progress reporting by filling in one field
on the schedule message record. Do this by typing the userid OPCTRL in the
field SEND ALL MESSAGES TO. If that is the only field you fill in on this
record, all three kinds of message go to that id.
If you fill in other fields on this record, it affects which messages go to

OPCTRL. OPCTRL will get only those messages not routed elsewhere. If you
really want OPCTRL to get all messages, be sure to include that ID in every
userid list you specify on this panel.
You can list up to four userids separated by commas in any of these fields. To
send any kind of message to the master console, specify OPERATOR as one of
the userids.
You can also specify MAILBOX as one of the userids, and the messages will be
sent to a common mailbox where they can be viewed using the Reporting
Facility panel. The following text describes sending late messages to the
userid PRODCTRL. If you only specify PRODCTRL as the recipient of late
messages, OPCTRL will not see the late messages. To guarantee that both
userids see late messages, list both of them in this field with a comma
separating them.
Then press Enter to save the last optional schedule record. Unicenter
CA-Scheduler responds by displaying the following message.

===> MASTER - WR
CONNECT : 4
DEFINE SMR NAME=BACKUP,MSG=OPCTRL,LATEMSG=(PRODCTRL,OPCTRL)

CACU18I SMR BACKUP HAS BEEN ADDED
PF1=HELP

To view the next panel, press Enter. Then press Clear to return to the Schedule
Maintenance menu.

3.3 Copying Schedules

Now that you have created one schedule, create another one just like it, only
much more quickly. You can do that by copying the new schedule from an
existing schedule.
Begin by using option 1 of the Schedule Maintenance menu. Notice that

Unicenter CA-Scheduler expects you to specify select criteria when you choose
option 1. We will use the schedule's name. Try typing 1,BACKUP in the
command area and pressing ENTER.
Unicenter CA-Scheduler responds by displaying the Schedule Directory panel:
SCHD-SD SCHEDULE DIRECTORY CA-SCHEDULER

===> _ MASTER - WR
CONNECT : 4
B C R I M
SCHEDULE PRTY JOBCT PCLASS PPRTY PSYS AUTOST R R C R R
BACKUP 5 A NO Y Y Y Y Y
PF1=HELP

The Ys in the five columns at the right indicate that the BACKUP schedule has
a:
■ Schedule base record (BR)
■ Schedule criteria record (CR)
■ Schedule reason code record (RC)
■ Schedule information record (IR)
■ Schedule message record (MR)
How to copy the BACKUP schedule's base record is explained next. To create
a base record for your new schedule, type C next to BACKUP and press
ENTER.
Unicenter CA-Scheduler responds by displaying the Schedule Definition panel

filled in as follows:

SCHD-SU SCHEDULE DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
SCHEDULE NAME : _ PROTOTYPE SCHEDULE NAME : BACKUP

SCHED PRIORITY: 5
AUTO SELECT : NO

AVERAGE TIME:
USERS:
LIBRARY TYPE : CMS
POWER CLASS : A
AUTO REPLY MESSAGES: N

RECS= SBR: Y SCR: Y SRC: Y SIR: Y SMR: Y PF1=HELP

The SCHEDULE DEFINITION panel shows all the information defined on
BACKUP's schedule base record and is waiting for you to specify the new
schedule's name. You can also tab to any fields on this panel and override
BACKUP's values by specifying others before you press ENTER. For now,
name this new schedule BACKUP1: type BACKUP1 as the SCHEDULE NAME
and press Enter. When you press Enter, Unicenter CA-Scheduler saves
BACKUP1's schedule base record.

===> MASTER - WR
CONNECT : 4
DEFINE SBR LASTUSER=userid,NAME=BACKUP1,ERLYTIME=23

CACU18I SBR BACKUP1 HAS BEEN ADDED
PF1=HELP

If you wanted to copy an optional record, you would enter something other
than C on the Schedule Directory panel. The table following explains what to
enter to copy different types of records:
To Copy A Schedule Type This Next To The Schedule Name

Base record C
Criteria record CCR
Reason code record CRC
Information record CIR

To Copy A Schedule Type This Next To The Schedule Name

Message record CMR
Now return to the Schedule Directory panel and try copying BACKUP's
message record and adding it to the BACKUP1 schedule. Enter CMR instead
of C and press Enter. Then identify which schedule the new message record
belongs to before pressing Enter again. Press Clear again to return.
Now that you know how to copy schedule records, press the Clear key before
beginning the next topic.

3.4 Displaying Schedules

Not all Unicenter CA-Scheduler users can display all schedule records. General
users are restricted to displaying only those records that specifically grant
them access. In all, you have three alternatives for displaying schedule
records:
■ Display a specific schedule record
■ List a subset of schedules and choose one record type
■ List all schedules and pick one record type
To display the record for your backup schedule, on the Schedule Maintenance
menu, option 2 displays a complete schedule base record.

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

When you use option 2, Unicenter CA-Scheduler expects you to specify a
schedule by name. To display the base record for your backup schedule, type
2,BACKUP in the command area. Then press Enter. Unicenter CA-Scheduler
responds by displaying that schedule's base record on this panel:

SCHD-SU SCHEDULE DISPLAY CA-SCHEDULER

===> _ MASTER - WR
CONNECT : 4

SCHED PRIORITY: 5
AUTO SELECT : NO

AVERAGE TIME:
USERS:
LIBRARY TYPE : CMS
POWER CLASS : A

RECS= SBR: Y SCR: Y SRC: Y SIR: Y SMR: Y PF1=HELP

This preceding panel resembles the panel you used when defining the
schedule base record. To view any optional schedule record, press the TAB
key. As you tab to different RECS fields, type Ds where Ys now appear to
display the optional records. After you press ENTER, the optional records you
requested will appear.
Unicenter CA-Scheduler allows you other RECS options besides D. You can
also type A to alter any schedule record. To move from panel to panel, keep
pressing ENTER. To exit from the Schedule Criteria Edit panel, press PF3, or
type FILE and press Enter.
Now you have seen the simplest method of displaying schedule records. The
other two methods for displaying records offer you even more flexibility. Let
us return to the Schedule Maintenance menu to try another approach.
Option 1 can be useful if you want to list a subset of schedules. To list all
schedules starting with B, you can use the mask character * as part of the
selection criteria.
For example, typing 1,*B causes Unicenter CA-Scheduler to display records for
all schedules with names that start with B:


===> _ MASTER - WR
CONNECT : 4
B C R I M
_BACKUP 5 A NO Y Y Y Y Y
BACKUP1 5 A NO Y Y
PF1=HELP

If you tabbed down to a particular schedule and typed D, Unicenter
CA-Scheduler would show you the Schedule Display panel; the same panel
that appeared when you used the first method.
Now return to the Schedule Maintenance menu to try the last method for
displaying schedule records.
The last method causes Unicenter CA-Scheduler to display all schedule

records. The instructions following review how that is done.
The first entry on the Schedule Maintenance menu tells you to press Enter to
display a directory of schedule records.

===> _ MASTER - WR
CONNECT : 4
B C R I M
APDAILY 5 12 A 9 NO Y Y
APMNTHLY 5 35 B 9 NO Y Y
ARDAILY 5 27 A 9 NO Y Y
ARMNTHLY 5 6 B 9 NO Y Y
_BACKUP 5 A NO Y Y Y Y Y
BACKUP1 5 A NO Y Y
DBUPDATE 5 3 A 9 YES Y Y Y
DISASTER 1 1 C 1 YES Y Y Y
INVDAILY 5 9 A 9 NO Y Y Y
INVWKLY 5 22 A 9 NO Y Y Y
PERDAILY 5 6 A 9 YES Y
PERWKLY 5 1 B 9 YES Y Y
PURDAILY 5 11 A 9 NO Y
PURWKLY 5 19 A 9 NO Y Y
RESTART 1 6 A 1 YES Y Y Y
RESTORE 5 1 A 9 YES Y Y Y
SALES 5 22 B 9 NO Y Y
PF1=HELP

Your entries will differ from those shown preceding. But you should be able
to find your schedule record. Tab down to your backup schedule. One panel
might not hold all the schedules defined at your site. If that is the case, the
END OF DIRECTORY LIST message will not appear on your panel. Instead,
the list will end with the message:


A summary of all the commands that the Schedule Directory panel supports is
shown in the following table.
To Type This Next To The Schedule Name

Display a record
base D
criteriaR DCR
information DIR
message DMR
reason code DRC
Alter a record
base A
criteria ACR
information AIR
message AMR
reason code ARC
Define a new record using this
record as the model
base C
criteria CCR
information CIR
message CMR
reason code CRC
Delete a record
all records for a schedule L
base LBR
criteria LCR
information LIR
message LMR
reason code LRC
Notice that C does more than just create new schedule records: it allows you
copy them. This method of building new records from existing ones is more
efficient than using the PROTOTYPE fields. Therefore they are not discussed
here. The copy feature is illustrated later in this chapter.
The next topic discusses deleting schedule records in more detail. Before you
start the next topic, return to the main menu by pressing Clear.

3.5 Deleting Schedules

Because there are different types of schedule records, Unicenter CA-Scheduler
gives you two methods for deleting them. Which method you use depends on
what schedule records you want to delete.
If you do not know which schedule you want to delete, or you only want to
delete an optional schedule record, begin by displaying a directory of
schedules using the Schedule Maintenance menu:

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

Pressing Enter at that menu causes the following panel to appear.


===> _ MASTER - WR
CONNECT : 4
B C R I M
BACKUP 5 A 9 NO Y Y Y Y Y
_BACKUP1 5 A NO Y Y
DBUPDATE 5 3 A YES Y Y Y
SHIPMENT 5 19 A 9 NO Y Y
PF1=HELP

Your entries will differ from those shown preceding. But you should be able
to find BACKUP1's schedule record. Tab down to your BACKUP1 schedule.
The following describes the various deletion options this directory panel
supports are examined.
To Delete Enter
All records for that schedule L
(except the history record)
Just the
-base record LBR
-criteria record LCR
-history record LHR
-information record LIR
-message record LMR
-reason code record LRC
Use LBR with caution. Optional records for that schedule will not be deleted
even though they do not appear on the directory or Analyze report. Optional
records will appear again if a base record with the same name is defined at a
later date.
The following describes deleting this schedule's message record. First, check
that the schedule actually has a message record. The value in the MR column
will be Y if a message record exists for this schedule. Explanations of the
other fields on this panel are provided in the topic called Copying Schedules.
Next, delete BACKUP1's schedule message record by typing LMR on that line
and press Enter.

If you have the authority to change this schedule, Unicenter CA-Scheduler

confirms that the message record is deleted by displaying the message:

===> MASTER - WR
CONNECT : 4
DELETE SMR NAME=BACKUP1

CACU18I SMR BACKUP1 HAS BEEN DELETED
PF1=HELP

To return to the Schedule Directory panel, press Enter. Then press Clear to
return to the Schedule Maintenance menu so it can be demonstrated the
second method for deleting schedule records.
To delete all of a schedule's records with a single command, begin by checking

which option on the Schedule Maintenance menu allows you to delete an
existing record:

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

This panel tells you that option 5 deletes an existing record. Notice, however,
that Unicenter CA-Scheduler expects you to enter a schedule name when you
select option 5. Therefore, when you type 5 in the command area, follow it
with a comma and the name of the schedule you want to delete.
The following text describes deleting the backup schedule you defined. For
example, if you named that schedule BACKUP1, enter 5,BACKUP1 in the
command area to delete that record.

If you are not authorized to delete this schedule, Unicenter CA-Scheduler

displays the message CACO229E USER NOT AUTHORIZED FOR THIS
SCHEDULE. But if you do have that authority, Unicenter CA-Scheduler
confirms it deleted that schedule record with the message shown following:

===> MASTER - WR
CONNECT : 4
DELETE S NAME=BACKUP1
CACU18I SBR BACKUP1 HAS BEEN DELETED
PF1=HELP

Since BACKUP1 only had a schedule base record, that is the only record that
was deleted. This panel will display a message for each type of record that
was deleted.

3.6 Analyzing Schedules

You should analyze all schedules that you add to the database before you put
them into production. This allows you to fix discrepancies and omissions
before you run the schedules. There are two ways to analyze a schedule
online:
■ Analyze a specific schedule
■ List all schedules and pick one to analyze
The first method is quicker, but the second is useful if you do not know the
exact spelling of the schedule to be analyzed. The analysis will produce
messages about the following:
■ If no jobs are defined for the schedule
■ If the schedule records specify an undefined calendar, datetable, userid, or
predecessor
■ If a predecessor or successor deadlock exists
To analyze a specific schedule, start at the Schedule Maintenance panel.

Suppose you recently defined a schedule (NEWSCHED), but you failed to
define any jobs for it and you defined a nonexistent datetable name in it.

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

To analyze the schedule, enter 6, followed by the schedule name.
Unicenter CA-Scheduler responds by displaying the SCHDUTIL Output panel:


===> MASTER - WR
CONNECT : 4
ANALYZE SCHEDULE LIST=ERR,NAME=NEWSCHD

CACU17E DATETABL ADATETB9 FOR YEAR 23 NOT FOUND
CACU41E SCHEDULE NEWSCHD NO JOBS DEFINED
CACU18I SCHEDULE NEWSCHD HAS BEEN ANALYZED
PF1=HELP

Notice that the analysis is performed with the LIST=ERR option so that only
error messages are displayed. If you need a full analysis report, use the JCL
described in the chapter "Reports" of the Unicenter CA-Scheduler Reference Guide
Part 2.
Before examining the second method of analyzing schedules, return to the

Schedule Maintenance panel by pressing Clear.
To analyze a schedule that has a name you do not know, start at the Schedule
Maintenance panel. You need to display a full directory of schedules so that
you can find the one you want.

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP


To display a full directory of schedules, press Enter.

===> MASTER - WR
CONNECT : 4
B C R I M
BACKUP 5 A NO Y Y Y Y Y
DBUPDATE 5 3 A 9 YES Y Y Y
NEWSCHD 5 A NO Y
NEWSCHD2 5 1 A NO Y
PRESS ENTER FOR NEXT PAGE PF1=HELP

Assume that the schedule that you want to analyze is called NEWSCHD2.
You recently defined it, but you defined a userid in the USERS field that is not
defined to Unicenter CA-Scheduler. Tab to it and enter ANA.


===> MASTER - WR
CONNECT : 4
ANALYZE SCHEDULE LIST=ERR,NAME=NEWSCHD2

CACU17E USERID AMBMA3 NOT FOUND
CACU18I SCHEDULE NEWSCHD2 HAS BEEN ANALYZED
PF1=HELP

Before beginning the next topic, return to the Unicenter CA-Scheduler Main
Menu by pressing Clear.

3.7 Automatic Console Replies for Schedules

Console messages issued by Unicenter CA-Scheduler VSE controlled jobs or
schedules typically require a response that either issues a command, supplies
data or requests some kind of operator intervention. These responses can be
automated by using the Unicenter CA-Scheduler Automatic Console Reply
feature. This feature is unavailable with the CMS online component.
You begin by tabbing to the Auto-Reply Maintenance line and pressing Enter.

===> MASTER - WR
CONNECT : 4

==> POWER INTERFACE
==> JOB MAINTENANCE
==> DOCUMENTATION MAINTENCE
PF1=HELP

This will display the Automatic Reply Maintenance panel. It may also be
reached by selecting 7,AUTO-REPLY PROCESSING on the Schedule
Maintenance Menu panel SCHD-SM, or the Job Maintenance Menu panel
SCHD-JM. Overwriting the auto-reply messages field on the SBR or JBR panel
with Y or C will also bring you to the Automatic Reply Maintenance panel.

SCHD-AR AUTOMATIC REPLY MAINTENANCE CA-SCHEDULER

====> MASTER - WR
CONNECT : 4
Schedule : ________ Job : ________ Jno : __ Msgid : ________
Scantxt :
Reply:
Schedule Job Job Message Scan Reply

Name Name Number Id Text Text
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit

3.7.1.1 To ADD a New Reply
Enter the schedule name in the schedule field and press Enter. If the schedule
has already been defined to the database, the panel will show the existing job
names, job numbers, message ids, scan text for each message (if any), and the
reply text.
Enter the job name in the job name field.
Enter the job number in the jno field.
Enter the message ID in the msgid field. The message ID is the first one to
eight characters of the message associated with the reply.
Each of the four key fields, Schedule Name, Job Name, JNO (job number) and
MSGID (message id), can also have a generic value. For example:
AA - any char string may follow
A??B ? - any char in this position

Scan text is a string of one to sixteen characters that occur in the message. The
string will be checked to verify the message id.
You may enter a reply to the message of up to 72 characters.


====> MASTER - WR
CONNECT : 4
Schedule : sched1__ Job : JOBD____ Jno : 14 Msgid : cacm27_
Scantxt : autoscan cannot
Reply: wait for monitor to terminate, then reactivate


To add the record to the database, either enter ADD on the command line or
press the function key.
The message CACO360I AUTO-REPLY RECORD ADDED will be displayed.

====> MASTER - WR
CACO36I AUTO-REPLY RECORD ADDED CONNECT : 4
Schedule : SCHED1 Job : JOBD___ Jno : 14 Msgid : CACM27
Scantxt : AUTOSCAN CANNOT
Reply: WAIT FOR MONITOR TO TERMINATE, THEN REACTIVATE



3.7.1.2 ALTer or REPlace an Auto-Reply Record
Begin with the Auto-Reply Maintenance panel SCHD-AR, described preceding.
To alter or replace an existing reply, enter the schedule name and press Enter
to search for the message to be changed. The ENTER-BROWSE function
displays the replies that currently exist in the database for that schedule.
Type A or R on the line of the record to be changed, and press Enter.

====> MASTER - WR
CONNECT : 4
Schedule : SCHED Job : ________ Jno : __ Msgid : ________
Scantxt :
Reply:

_ SCHED1 JOBA 11 CACM29 CANNOT RERUN USE RUN

_ SCHED1 JOBB 12 CACM62 ABENDED
_ SCHED1 JOBB 12 CACM7 NOT HELD RECHECK STAT
_ SCHED1 JOBC CACM97 SCHEDULER REINITIALIZE
a SCHED1 JOBD 14 CACM27 AUTOSCAN CAN WAIT FOR MON

The messages CACO372I UPDATE FIELDS AND PRESS ENTER and ALTER
will be displayed in the command area.


====> ALTER MASTER - WR
CACO372I UPDATE FIELDS AND PRESS ENTER CONNECT : 4
Schedule : SCHED1 Job : JOBD____ Jno : 14 Msgid : CACM27_


_ SCHED1 JOBB 12 CACM7 NOT HELD RECHECK STATUS
SCHED1 JOBD 14 CACM27 AUTOSCAN CAN WAIT FOR MON

Type the changes in the appropriate fields and press Enter.
The database is updated and the message CACO361I AUTO-REPLY RECORD

UPDATED is displayed:

====> MASTER - WR
CACO361I AUTO-REPLY RECORD UPDATED CONNECT : 4
Schedule : SCHED Job : JOBD____ Jno : _ Msgid : CACM27_


_ SCHED1 JOBB 12 CACM7 NOT HELD


3.7.1.3 To DELete an Auto-Reply Record
To delete an existing reply, enter the schedule name on panel SCHD-AR and
press Enter to search for the message to be deleted.
Type L on the line of the record to be deleted and press Enter.

====> MASTER - WR
CONNECT : 4
Scantxt :
Reply:


l SCHED1 JOBD 14 CACM27 AUTOSCAN CAN WAIT FOR MON

The message CACO369I PRESS ==> PF5 <== TO CONFIRM DELETE and
DELETE will be displayed in the command area.

====> DELETE MASTER - WR
CACO369I PRESS ==> PF5 <== TO CONFIRM DELETE CONNECT : 4
Schedule : SCHED1 Job : JOBD____ Jno : _ Msgid : CACM27_


SCHED1 JOBD CACM27 AUTOSCAN CAN WAIT FOR MON


The database is updated and message CACO362I AUTO-REPLY RECORD

DELETED is displayed.

====> MASTER - WR
CACO362I AUTO-REPLY RECORD DELETED CONNECT : 4
Schedule : SCHED1 Job : JOBD____ Jno : _ Msgid : CACM27


_ SCHED1 JOBD CACM27 AUTOSCAN CAN WAIT FOR MON


3.8 Summary of Schedule Maintenance

Anyone can create a schedule definition, but Unicenter CA-Scheduler only
allows authorized users to update or delete existing schedule definitions.
General users can change public schedules and schedules that specifically
grant them access in the USERS field.
The chart following sums up the steps involved in maintaining schedule

records from the Schedule Maintenance menu. Since there are so many ways
to display records, only the fastest ways are shown:
To Enter This In Then

Command Area
Define a schedule 4 Enter data
Copy a schedule 1,schedule name Tab to a schedule; enter C or
Cxx, where xx is the record
type. Enter new data
Alter
a specific schedule 3,schedule name Enter changes in SBR; enter A
in a RECS= field
an unknown schedule
(Press Enter) Tab to a schedule; enter A or
Axx, where xx is the record
type
Delete
a specific schedule Tab to the schedule; enter
a specific record 5,schedule name Lxx, where xx is the record
(Press Enter) type
Display
one schedule record 2,schedule name
some schedules 1,*x where x is Tab to a schedule; enter D

the first character
in some schedules
all schedules (Press Enter)

Press Enter to scroll panels
Analyze a schedule 6,schedule name
Display, alter or 7,schedule name
define auto-reply
messages

These same functions (except for AUTO-REPLY MAINTENANCE) can also be

performed using the Schedule Directory panel. The chart following lists the
appropriate commands.
The Schedule Directory panel supports the following commands:
To Type This Next To The Schedule Name

Display a record
base D
criteria DCR
information DIR
message DMR
reason code DRC
Alter a record
base A
criteria ACR
information AIR
message AMR
reason code ARC
record as the model
base C
criteria CCR
information CIR
message CMR
reason code CRC
Delete a record
all records for a schedule (except L
the history record)
base LBR (see Note following)
criteria LCR
history record LHR
information LIR
message LMR
reason code LRC
Analyze a schedule for missing or ANA
illogical records
Note: Deleting the base record will remove the schedule from the Directory
panel. Other schedule records associated with this record, however, will
not be deleted along with it. When you delete a base record, it is your
responsibility to either replace the base record or delete its associated
records using the batch utility.

3.9 Defining Jobs
3.9 Defining Jobs

Unicenter CA-Scheduler uses seven different types of records to store
information pertaining to a job, but only the job's base record is required. That
record assigns each job to a specific schedule to make your work easier.
Schedules group similar jobs together. If you define those similarities on
schedule records, almost all of that data automatically applies to all the jobs in
that schedule which means less work when defining these jobs. Therefore, it is
important to define schedules first.
All users with write passwords can define jobs for schedules they are
authorized to access. This topic shows you how by:
■ Defining a job base record
■ Checking what defaults apply to jobs
■ Learning the basics about the job base record
■ Defining optional job records
3.9.1 Defining a Job Base Record

Job records primarily consist of optional fields with defaults which means you
will not have to fill in all of the fields on job records. Since a job's base record
is the only one required, you begin by defining a simple job using just that
record. You begin defining jobs at Unicenter CA-Scheduler's main menu by
tabbing to JOB MAINTENANCE:

===> MASTER - WR
CONNECT : 4

==> POWER INTERFACE
_ ==> JOB MAINTENANCE
PF1=HELP

Then tab down to the sixth selection, JOB MAINTENANCE, and press Enter.

3.9 Defining Jobs
That choice displays the Job Maintenance menu, that lists everything you can
do with job records:
SCHD-JM JOB MAINTENANCE CA-SCHEDULER

===> 4 MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
DISPLAY SPECIFIC JOB............. 2,JOB(,JNO,STN,SCHEDULE)
ALTER JOB RECORD................. 3,JOB(,JNO,STN,SCHEDULE)
DEFINE JOB RECORD................ 4(,JOB,JNO,STN,SCHEDULE)
DELETE JOB RECORD................ 5,JOB,(JNO,STN,)SCHEDULE
ANALYZE JOB...................... 6,JOB(,JNO,STN,SCHEDULE)
AUTO-REPLY PROCESSING............ 7,JOB(,JNO,STN,SCHEDULE)
PF1=HELP

If you logon without a write password, the read-only functions appear on your
panel. They allow you to display job directories, analyze a job, or view
auto-reply records. You need to logon with your write password to practice
defining jobs.
Option 4 on the Job Maintenance menu allows you to define a job's base
record. The information following the 4 (,JOB,JNO,STN,SCHEDULE) identifies
options you can specify when selecting menu choice 4. Ignore that when
defining jobs; type 4 in the command area and press Enter. Then the Job
Definition panel appears. Tab to JOB NAME.

3.9 Defining Jobs
SCHD-JU JOB DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
JOB NAME : _ PROTOTYPE JOB: JNO: STN:

JOB NUMBER : PROTOTYPE JOB IN SCHEDULE :
STATION ID : CPU JOB : SKIP EXECUTION :
SCHEDULE NAME : JOB PRIORTY : USE SIM TIME : NO
STAGE JCL : AUTO START : NO AVERAGE TIME :
MEMO :
DISPLAY KEY : DISPLY TIME : INTERRUPT :
LIBRARY TYPE : MBR SUBID : MEMBER PASSWORD:
MEMBER NAME : SLI SUBLIB : ICCF LIB NUMBER:
POWER CLASS : NODE ID : RUN ON SYSID :
LDEST : PDEST : NODE SYSID :
RECOVERABLE : NO ABEND : ABORT FAIL CODE :
BACKLOG : YES TESTLIB PARM:
MUST START BY TIME : COMMANDS AT JOB START:
COMPLETION DEADLINE TIME : COMMANDS AT JOB END :
MAXIMUM EXECUTION TIME : AUTO-REPLY MESSAGES :
EARLIEST START TIME :
RECS= JBR: N JCR: N JRC: N JIR: N JMR: N JRR: N JNR: N PF1=HELP

Unicenter CA-Scheduler uniquely identifies every job it handles by four values:
■ Job name
■ Job number
■ Station ID
■ Schedule name
Since most work is done at the CPU, workstation ID defaults to station 40.
Most jobs are only scheduled once a day, so job number defaults to 01. That
leaves only two key fields on this panel that always require input.
JOB NAME consists of up to eight characters used to identify this job at your
site. Define a job called DEFAULTS. Type that value for JOB NAME and then
tab down to SCHEDULE.
SCHEDULE identifies which group definition pertains to this job. The values
in that schedule definition apply to all the jobs belonging to that schedule.
Enter the name of an existing schedule (up to eight characters). Assign this job
to your backup schedule.
Unicenter CA-Scheduler needs both job name and schedule name to specify a
particular task in its workload. This job will be known as DEFAULTS
BACKUP. If you try to create a job definition without these values, Unicenter
CA-Scheduler displays a message like this:

3.9 Defining Jobs

===> MASTER - WR
CONNECT : 4
DEFINE JBR LASTUSER=userid,NAME=DEFAULTS

CACU14E DEFINE JBR KEYWORD 'SCHEDULE' MUST BE SPECIFIED
PF1=HELP

The other fields on the Job Definition panel all have default values, some of
which appear on the panel. Most job fields default to values specified on
schedule records which means you do not have to type in values on the Job
Definition panel if you already entered that data on the schedule's record. But
defaults based on schedule values do not appear on your panel.
When you are defining job records, tab from field to field until you have
supplied all the values necessary. To further your understanding of Unicenter
CA-Scheduler, these fields will be described later in this chapter.
To save this job base record, press Enter. Unicenter CA-Scheduler responds by
displaying this message:
DEFINE JBR LASTUSER=userid,NAME=DEFAULTS,SCHEDULE=BACKUP
CACU18I JBR DEFAULTS HAS BEEN ADDED
If a job by that name already exists in that schedule, Unicenter CA-Scheduler

displays the message:
CACU15E DEFINE JBR BACKUP DEFAULTS DUPLICATE RECORD
If that message appears, try giving your job another name.
You will see how to define these other types of job records later in this
chapter. Now press the Clear key to return to the Job Maintenance menu.
3.9.2 Checking Default Values for Job Base Records

Just as some schedule options serve as defaults for jobs, installation options
supply defaults for schedules. It can get confusing because job defaults will
vary for different schedules. Clearly, you need a simple way of determining
what defaults apply to a job. Instead of worrying about what the install and
schedule defaults are, choose an easier way: create a dummy job called
DEFAULTS for every schedule and then glance at the values Unicenter
CA-Scheduler supplies. Eventually, you will want to delete these dummy
records because they take unnecessary space in your database.
The job that you just defined consists of defaults, so display that job's base
record. The first three functions on the Job Maintenance menu allow you to
display a job base record:

3.9 Defining Jobs
SCHD-JM JOB MAINTENANCE CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

Use option 2 because it is quicker. When you select option 2, Unicenter
CA-Scheduler also expects you to specify the name of an existing job. To
display the base record for the job defaults, type 2 in the command area
followed by a comma and the job's name, DEFAULTS. For example, type
2,DEFAULTS and press Enter.
Unicenter CA-Scheduler responds by displaying that job base record:
SCHD-JU JOB DISPLAY CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
JOB NAME : DEFAULTS

JOB NUMBER : 1
STATION ID : 4 CPU JOB : YES SKIP EXECUTION :
SCHEDULE NAME : BACKUP JOB PRIORTY : 5 USE SIM TIME : NO
STAGE JCL : NO AUTO START : NO AVERAGE TIME :
MEMO :
DISPLAY KEY : DISPLY TIME : INTERRUPT : NO
LIBRARY TYPE : CMS MBR SUBID : MEMBER PASSWORD:
MEMBER NAME : DEFAULTS SLI SUBLIB : ICCF LIB NUMBER:
POWER CLASS : A NODE ID : RUN ON SYSID :
MUST START BY TIME : COMMANDS AT JOB START: N
COMPLETION DEADLINE TIME : COMMANDS AT JOB END : N
MAXIMUM EXECUTION TIME : AUTO-REPLY MESSAGES : N
RECS= JBR: Y JCR: N JRC: N JIR: N JMR: N JRR: N JNR: N PF1=HELP

Notice that this panel displays more values than you specified for your default
job. Many of these fields obtain the defaults from the BACKUP schedule.

3.9 Defining Jobs
3.9.3 Learning the Basics About a Job Record

Unicenter CA-Scheduler provides even more job options than there were
schedule options. The following describes what characteristics job records can
define, and how Unicenter CA-Scheduler works with schedule and job options.
3.9.3.1 Which Users Can Work with Job Records?
Two factors determine who can work with a job record:

■ A user's authority level
■ The USERS defined on the corresponding schedule base record
Users with General authority can work with jobs associated with public
schedules and schedules that specifically define them as USERS. Supervisor
authority allows you to access jobs that run at stations your userid record
authorizes. People with Manager authority can access all jobs. Permission to
access a job means you can create a job for that schedule or workstation,
update records and delete records.
There is no field corresponding to USERS on a job record which means you

cannot override the value that appears on the schedule base record at the job
level.
3.9.3.2 When Will Jobs Be Selected?
When Unicenter CA-Scheduler runs autoscan, it selects that day's workload.

The selection process consists of two steps:
■ First, Unicenter CA-Scheduler sees which schedules to select.
■ Then it scans only the schedules selected for jobs that belong in the
workload.
That means jobs can only run on days when their schedules are selected. So
jobs that run daily must belong to schedules that are selected every day. For
details on the factors controlling when schedules are selected, see the topic
When Will This Schedule Be Selected?
When Unicenter CA-Scheduler is scanning jobs to select the day's workload, it

only examines two fields on the job base record: the RECS value for JCR and
the value of SKIP EXECUTION.
■ If JCR: N, that job becomes part of the workload whenever its schedule is
selected. If you want a job to run less frequently than its schedule, then
set JCR: Y and define a criteria record for that job. You will see how that
is done later in this chapter. Unicenter CA-Scheduler interprets your job's
criteria statement using either the datetable you specified on the schedule
base record, or the calendar shown on the job's criteria record.
■ Someday you may need to stop selecting a job for a while. If so, use the
SKIP EXECUTION field. Specify how many times you want to skip this job

3.9 Defining Jobs
when it ordinarily would be selected in autoscan. For example, suppose

that only once you want to omit a job that normally runs on Friday.
Specify SKIP = 1 and Unicenter CA-Scheduler will "forget" only that job
this Friday (not its successors). Each autoscan time when Unicenter
CA-Scheduler skips over a job it normally would have selected, it
decrements the value in the SKIP field by one until SKIP once again is
zero. Then selection for this job resumes normally. This advanced
technique is only used under exceptional conditions. Usually, SKIP = 0.
3.9.3.3 When Will Jobs Actually Run?
As Unicenter CA-Scheduler selects the day's workload, it organizes the work,

grouping each schedule's jobs together. This ordering reflects the sequence in
which Unicenter CA-Scheduler evaluates jobs for submission. It also
approximates the order in which jobs run.
It does not line schedules up in the order they are selected. Instead, Unicenter
CA-Scheduler allows you to control that order using schedule options. Those
options are described in the topic When Will A Schedule's Jobs Actually Run?
While Unicenter CA-Scheduler is organizing the workload, it also prioritizes
the jobs selected from each schedule. Unicenter CA-Scheduler allows you to
control the sequence of jobs within a schedule using the following job
parameters:
■ JCR predecessors
■ USE SIMTIME
■ JRC start times
■ JRC DEADLINE TIMEs
■ JOB PRIORITY

3.9 Defining Jobs
Defining predecessors forces Unicenter CA-Scheduler to witness a specific

event before starting AUTO-STARTed non-CPU jobs or submitting CPU jobs.
Predecessors can be a variety of events:
■ The start or end of another schedule or job
■ The close of an output data set or output generation data group
■ A user-defined event that you can control using a global parameter
■ The normal completion of a job that isn't controlled by Unicenter
CA-Scheduler
■ An event that occurred sometime in the past
Defining predecessors for schedules forces Unicenter CA-Scheduler to witness

a specific event before evaluating any jobs in that schedule. You can also
define predecessors for individual jobs. If both a schedule and its jobs have
predecessors:
■ None of the schedule's jobs will be evaluated until the schedule's
predecessors are satisfied and the schedule starts.
■ Once the schedule's predecessors are met, other factors such as start times
determine whether the job is ready to be submitted once its predecessors
are satisfied.
Note: Defining predecessors for jobs does not override a schedule's

predecessors: instead, predecessors are cumulative.
When jobs must run in a certain order, define predecessors for either schedules
or jobs. Be careful deciding what that predecessor should be: check what days
your predecessor is selected. For example, suppose your job's predecessor isn't
eligible to be selected on the same day your job is. If a predecessor is not in
the day's workload, Unicenter CA-Scheduler ignores it: your job runs without
waiting for the predecessor. This feature makes writing criteria statements
easier. See the chapter "Criteria Language" for instructions on how that is
done.
When Unicenter CA-Scheduler lines up work to be processed during the day,

the first factor it considers is predecessors. Then Unicenter CA-Scheduler
compares start times, putting schedules that can start earliest ahead of ones
that start later. Unicenter CA-Scheduler orders jobs within schedules in the
same way: jobs that can start earlier go ahead of jobs from the same schedule
that have later start times.
Schedules without predecessors and start times go to the top of the list because
nothing is delaying them from starting. Likewise, jobs without predecessors
and start times are the first jobs listed for each schedule.

3.9 Defining Jobs
The chart preceding illustrates how Unicenter CA-Scheduler sequences jobs.

Schedule A is first because A has no predecessors. Schedule B is ahead of C
because B has no start time. Now look at Schedule A's jobs to see why they are
sequenced in this order. Job A1 is first because it has no predecessors and no
start time. Since A3 has predecessors, A2 goes ahead of it.
Now look at job start times in Schedule B. B1 has no start time so it goes
ahead of B2. B2 is next because it can start earlier than B3. B4 is last because
only that job has predecessors in addition to the predecessors defined for the
schedule. Even though B4 has an earlier start time, its predecessors put it at
the end of Schedule B.
Now look at Schedule C to see how schedule and job start times interact.
Schedule C starts at 9 a.m. Job C1 does not have a start time, but its schedule
does. Therefore, C1 will not start until 9 a.m. What about C2? Its start time is
6 a.m., but this schedule does not start until three hours later. Therefore, C2
cannot start before 9 a.m. even if you give it an earlier start time.
Note: Job start times do not override specified schedule start times. Instead,
they let you postpone running jobs after a schedule has started.
Unicenter CA-Scheduler gives you three ways of specifying when jobs start.
To see which method you chose, Unicenter CA-Scheduler checks the values of
USE SIMTIME. SIMTIME is only used at sites with extensive Unicenter
CA-Scheduler experience. Such sites have defined their resources in great
detail and automated the vast majority of their workload using Unicenter
CA-Scheduler. As a result, they have refined simulation to such a degree that
it accurately reflects their daily operation. In fact, their simulation runs are so
accurate that those sites can rely on simulation data to determine when
schedules can start and jobs can be submitted. USE SIMTIME defaults to NO.
Only sites using Unicenter CA-Scheduler's most advanced features choose to
implement SIMTIME as their start time.

3.9 Defining Jobs
A value of YES on the schedule base record causes Unicenter CA-Scheduler to

start that schedule no earlier than the time shown on the Simulated Execution
Schedule. If USE SIM TIME = YES on the job base record, Unicenter
CA-Scheduler submits that job at the time indicated on the Simulated
Execution Schedule. Notice the subtle difference here. The SIMTIME fields on
schedule and job records do not override one another because they deal with
separate events: when schedules start and when jobs are submitted. Sites that
want to schedule jobs using SIMTIME get best results when SIMTIME values
on both the schedule and job records are YES.
If you set USE SIMTIME=YES on the schedule base record, Unicenter

CA-Scheduler ignores any other start times you may have specified for
schedules, either on the reason code record or the schedule's base record.
If USE SIMTIME = NO, Unicenter CA-Scheduler checks to see what start times
you have specified on the schedule's records. You specify the earliest possible
time a schedule can start using a 24-hour clock. For example, an early time of
1400 allows a schedule to start no earlier than 2 p.m., but what if that schedule
should not start until some day in the future? Unicenter CA-Scheduler also
allows you to specify start times with a prefix showing how many production
days to hold those jobs. For example, a start time of 031400 holds that schedule
until 2 p.m. three production days after that schedule was originally selected.
Notice that production days usually do not start at midnight. Instead, they run
from one autoscan to the next.
The first place Unicenter CA-Scheduler looks for a start time is on the
schedule's reason code record (SRC). If you do not specify a start time there
that corresponds with the reason the schedule was selected today, Unicenter
CA-Scheduler looks to see if you defined an EARLIEST START TIME on the
schedule base record. Start times defined on job records are not even looked
at until a job's schedule starts. Then Unicenter CA-Scheduler checks to see if
you have delayed any jobs by defining start times on job records.
Since start time is an important factor in sequencing your workload, Unicenter

CA-Scheduler gives you flexibility. For example, a schedule or job may need
to start at different times on different days. Unicenter CA-Scheduler allows
you to define different reasons for selecting a schedule or job on its criteria
record (SCR or JCR). Each reason can cause work to be selected on a different
day. Once you have defined reasons on a criteria record, you can specify a
different start time for each reason. A schedule's alternate start times are stored
on its reason code record (SRC). Likewise, a job's alternate start times are
stored on its reason code record (JRC).
If a job has no criteria record or it only needs one start time, specify that value
as EARLIEST START TIME on the job base record.
When Unicenter CA-Scheduler organizes the work to be processed each day,

first it considers predecessors. Then it checks start times. If schedules or jobs
have the same predecessors and start times, Unicenter CA-Scheduler puts

3.9 Defining Jobs
those with earlier deadlines ahead of the others. Work that has to be finished
sooner goes first. You define deadlines in the field called COMPLETION
DEADLINE TIME. Schedule deadlines affect how schedules are ordered in the
workload. Job deadlines have no impact on the sequencing of schedules and
only affect how jobs within a schedule are organized. For information on the
role deadlines play in progress notification, see the topics What Happens
When Schedules Run Late and What Happens When Jobs Run Late.
Finally, Unicenter CA-Scheduler checks one last field when it is organizing the
workload. Schedules with the same predecessors, start times, and deadlines are
sorted by SCHED PRIORITY: schedules with the highest priority go first.
Priorities range from a high of 01 to a low of 99. Likewise, jobs in the same
schedule with the same predecessors, start times, and deadlines are sorted by
JOB PRIORTY.
If, after checking all these fields, Unicenter CA-Scheduler finds a group of
schedules with equivalent values in all these fields, it lines up those schedules
in alphabetical order. Unicenter CA-Scheduler handles jobs within schedules in
the same way: jobs with the same values for all these fields are put into
alphabetical order in the work queue.
The factors determining the order of schedules in the workload are listed
following in decreasing order of importance.
Sequence By Using On The Schedule

EARLY TIMEs or Base code record
Deadline DEADLINE TIMEs or Reason code record
TIME
Priority SCHED PRIORITY Base record
Alphabetical SCHEDULE NAME Base record
order
Factors determining the order of jobs within schedules are listed following in
decreasing order of importance.

EARLY TIMEs or Base code record

3.9 Defining Jobs

Deadline DEADLINE TIMEs or Reason code record
TIME
Priority JOB PRIORITY Base record
Alphabetical JOB NAME Base record
order
What if there are so many jobs to run today that Unicenter CA-Scheduler
never gets to submit all of them? The values in the BACKLOG fields control
what happens. The term backlog identifies jobs that do not run on the
production day when they were selected and are carried over to the next
production day's workload.
If BACKLOG = NO on a schedule base record, that schedule's jobs will never

be backlogged unless you override this value on job records. If
BACKLOG=NO on the schedule's base record, jobs will only be backlogged if
BACKLOG = YES on their job base records or the job is submitted or started at
the time of the next autoscan.
Suppose a job is carried over into tomorrow's workload. What happens if that
job is selected again tomorrow? Tomorrow's job is added to the workload after
today's backlogged schedule has completed or been canceled.
3.9.3.4 Does This Job Record Describe a Job Performed on the CPU?
Job records describe every job defined to Unicenter CA-Scheduler. If a job is

performed at several workstations, a job base record exists for that job at every
workstation that processes it. So how does Unicenter CA-Scheduler identify
CPU jobs? STATION ID identifies the workstation this record refers to. Station
40 usually identifies work performed by your CPU, but what if you want to
automate scheduling of manual jobs your operators do? You can define a job
record at station 40 and set CPU JOB = NO. That tells Unicenter CA-Scheduler
that this job does not require CPU processing: no JCL exists for this job.
Can jobs that do not run on the CPU have EARLIEST START TIMEs? Yes,
however, the field called AUTO START controls what happens when that time
is reached. If AUTO START = NO, this job has to be started using Unicenter
CA-Scheduler's START command. (AUTO START's default is NO.) That means
that Unicenter CA-Scheduler's statistics for elapsed time are meaningful: they
show how long it takes for a job to complete once it has started.
If AUTO START = YES, the pre-CPU job automatically starts when its early
start time is reached and all predecessor conditions have been satisfied which
means the pre-CPU job is posted as started even though this work has not yet
begun.

3.9 Defining Jobs
3.9.3.5 What JCL Does Unicenter CA-Scheduler Submit for CPU Jobs?
Several fields on schedule and job base records determine what JCL Unicenter
CA-Scheduler submits for your job:
■ CPU JOB
■ LIBRARY TYPE
■ MEMBER NAME
■ MBR SUBID
■ MEMBER PASSWORD
First, Unicenter CA-Scheduler determines if this job executes on the CPU. If

STATION ID = 40, CPU JOB = YES and LIBTYPE is other than RDRQ, then
Unicenter CA-Scheduler knows this job has JCL it needs to submit.
Unicenter CA-Scheduler identifies the library where a job's JCL is stored using
an installation option or the job's schedule or job base record. If the installation
option is not the LIBTYPE appropriate to this job, override it at the schedule or
job level. If the schedule's value for LIBRARY TYPE is not appropriate to this
job, then override it using LIBRARY TYPE on the job base record.
Unicenter CA-Scheduler can retrieve JCL directly from:

■ A CMS member
■ A Unicenter CA-Driver procedure library
■ AllFusion CA-Panvalet
■ User-defined libraries
■ An ICCF member
■ An SLI source member
■ A PROC VSE procedure library
■ A Allfusion CA-Vollie library member
■ CONDOR
Depending on the LIBRARY TYPE you specify, Unicenter CA-Scheduler may

need additional information to identify where the JCL for your job is stored.
MEMBER NAME Identifies the library member that contains the JCL
for this job. Specify up to 8 characters for
MEMBER NAME. If no value is given, Unicenter
CA-Scheduler uses the job name as the default. If
a job's LIBRARY TYPE is RDRQ, do not specify a
member name.
MBR SUBID Specifies the prefix or qualifier required to find
the library member (up to 8 characters). For JCL
stored in VOLLIE libraries, specify OPERATOR
here.
MEMBER PASSWORD Supplies the member's password if one is required
to access that library member (up to 8 characters).

3.9 Defining Jobs
However, sometimes production JCL requires editing before it can be

submitted. STAGE JCL fields on the schedule and job base records identify
which jobs have JCL that requires editing before submission. Again, the value
of STAGE JCL on the job record overrides the one defined for the schedule. If
STAGE JCL = YES, Unicenter CA-Scheduler copies that job's production JCL
into the staging library when the job is selected. You can then define an
EARLIEST START TIME that allows plenty of time to edit the staged JCL
before this job is submitted. Or you can ensure that the JCL has been edited
before submission by defining another record for this job at station 39 (JCL
setup). Defining a job record for station 39 guarantees that Unicenter
CA-Scheduler will not submit this job for processing until that JCL has been
edited and staging is complete.
In the case where the JCL for a specific job is stored in a CA-Panvalet library,
Unicenter CA-Scheduler will submit a batch job that is a library access job.
This job will run in a partition and extract the actual job JCL from the library
and submit this JCL to POWER to be run so that this JCL may not be staged.
Once the JCL is staged, you can use a variety of editor commands to prepare it
for submission. In addition to usual text editing, you can perform some
special functions within the editor:
■ Expansion of Unicenter CA-Driver procedures embedded in the JCL
■ Display of current values of all Unicenter CA-Driver reserved-name
variable parameters in the JCL
■ Change of values of any Unicenter CA-Driver reserved-name variable
parameters in the JCL
For detailed explanations of the editor commands, see the appendix "Editor
Commands" of the Unicenter CA-Scheduler Reference Guide Part 2.
3.9.3.6 On Which CPU Should Jobs Be Run?
Unicenter CA-Scheduler uses three fields on both schedule and job base
records to record where jobs run:
■ NODE ID
■ NODE SYSID
■ RUN ON SYSID
Whether you need to define these fields depends on the CPU configuration at
your site:
If You Do This
Only have one CPU Leave all three fields blank on both schedule and
job records.

3.9 Defining Jobs
If You Do This
Have multiple CPUs at Define RUN ON SYSID. See the instructions
one site with shared following.
DASD
Have a network of Specify NODE ID and possibly NODE SYSID.
CPUs using the
POWER/VSE option
How you define these fields on schedule and job records is explained
following.
RUN ON SYSID is only used in a multi-CPU environment with a shared spool

complex. Notice that the value on a job record does not override what is
specified on the schedule record. Instead, the SYSID on the schedule record
selects and submits all jobs in that schedule. You specify which CPU the jobs
execute on using RUN ON SYSID on the job record. The schedule record
identifies which CPU scans this schedule while selecting the day's workload.
The same CPU also submits that schedule's jobs, but those jobs do not
necessarily have to execute on that CPU. You can cause a job to execute on
another CPU by specifying the POWER SYSID of that CPU in the RUN ON
SYSID field of the job's base record.
If your site has one CPU perform scheduling for all of them, it is called your
Master CPU. It is the first CPU listed on the SYSID= installation generation
macro parameter. Since that value is the default for a schedule's RUN ON
SYSID, you must leave that field blank on the schedule base record if your site
has a Master CPU.
NODE ID and NODE SYSID are only used at sites that are part of a network
that uses POWER/VSE at each node and Unicenter CA-Scheduler on each
CPU at every node. Only use NODE SYSIDs if there are multiple CPUs using
shared POWER spool at a NODE ID. Also notice that values for these fields
mean different things on schedule and job records.
NODE ID on the schedule record indicates the default NODE ID for the jobs in
that schedule. A job's NODE ID identifies which node the job's JCL is
submitted to. If a job runs on the node specified as the schedule's NODE ID,
you can leave NODE ID blank on the job record. To submit a job to another
node, specify its node ID on the job base record.
Suppose there are multiple CPUs at this node. Use NODE SYSID to specify a
particular CPU if the node has multiple CPUs that each run Unicenter
CA-Scheduler and share a POWER location. For NODE SYSID, enter the
POWER SYSID of the remote CPU where the job is to run. NODE SYSID is
only valid if NODE ID is also specified on the same record. When NODE ID
and NODE SYSID are given, that job base record's value for RUN ON SYSID is
ignored.

3.9 Defining Jobs
3.9.3.7 Once a Job Starts, How Can You Intervene?
Unicenter CA-Scheduler offers several commands that allow users to control a

job, but a job's definition also allows you to define control points during a job's
processing. Ordinarily, you do not want to intervene in job processing.
However, Unicenter CA-Scheduler gives you that ability should you need it.
MEMO defines text to display at the system console when this job starts at the
CPU. This happens every time that job runs. A MEMO of up to 60 characters
forces the operator to reply OK or TERM. If the reply is OK, the job runs, but
a reply of TERM causes Unicenter CA-Scheduler to cancel the job.
Although manual intervention is what Unicenter CA-Scheduler tries to

eliminate, there may be times when you need it. For example, Unicenter
CA-Scheduler may control a job that needs to have an online database closed
to users before it starts. Or another job may need onsite approval before it
starts. These instances show how the MEMO option can be used.
MEMO allows you to control a job when it starts, and INTERRUPT gives you
control when a job ends. INTERRUPT = YES prevents a job from automatically
being posted COMPLETED even though it ended successfully. Instead, it's
given a status of INTRPTD which prevents the job's successors from being
posted as satisfied. That gives you the chance to review the job's output. For
example, you can check a trial balance to see if it is correct. If so, you can
change the job's status to ENDED so its successors can be reevaluated to see if
they can run, but if you are not satisfied with the output, you can rerun an
interrupted job using the RERUN or SUBMIT command.
3.9.3.8 What Happens When Jobs Don't End Successfully?
Several fields on the job base record determine what happens when something
goes wrong or when unusual circumstances occur:
■ ABEND
■ BACKLOG
■ FAIL CODE
■ RECOVERABLE
What if the system crashes while a job is running? Will Unicenter

CA-Scheduler automatically restart the job? RECOVERABLE on the job record
tells Unicenter CA-Scheduler if a job can be restarted after the system is
re-IPLed. RECOVERABLE defaults to NO, which causes Unicenter
CA-Scheduler to put the job on hold. The job waits to be canceled or released,
but if RECOVERABLE = YES, Unicenter CA-Scheduler automatically releases
the job after you restart the system.
What if a job abends (cancels without going to normal completion)? A job's

ABEND field allows a variety of things to happen:

3.9 Defining Jobs
■ Ordinarily, Unicenter CA-Scheduler prevents successors to this job from

being satisfied. That is what happens when ABEND = ABORT, which is
the default.
■ Alternatively, Unicenter CA-Scheduler can ignore that this job abended. If
ABEND = CONT, successors continue to be satisfied as usual even if this
job abends.
■ If you specify ABEND=BACKOUT, Unicenter CA-Scheduler automatically
submits a backout job when the job abends. A value must be specified for
the BACKOUT installation option. Successors to the job will not be posted
as satisfied. Unicenter CA-Scheduler adds a new job tracking record for
the backout job. The backout job's name is constructed according to the
BACKOUT installation option by altering one character position of the
abended job's name. The backout job will be specified as ABEND=ABORT
to prevent resubmission if the backout job itself abends. All other job
attributes are copied from the abended job.
■ Unicenter CA-Scheduler's fourth alternative prevents successors from being
satisfied and begins processing another schedule instead. Specify that
schedule's name (up to eight characters) as the value for ABEND. This
alternative is a valuable rerun tool.
Suppose that a job runs to normal completion but returns a completion code
greater than zero. What happens then? It depends on the value you define for
FAIL CODE on the job base record. FAIL CODE specifies the threshold for
determining whether a job failed. If any job ends with a return code greater
than or equal to the value defined for FAIL CODE, Unicenter CA-Scheduler
gives that job a status of FAILED which means successors to this job will not
be satisfied. Values for FAIL CODE can range from 1 to 4095. If FAIL CODE
= 0 on the job base record, Unicenter CA-Scheduler does not check return
codes.
What will happen if a job never runs at all? If the production workload is too
great, what happens to the selected jobs that do not run? The term backlog
identifies jobs that do not run on the day they are scheduled and are carried
over to the next day's workload.
If BACKLOG=NO on a schedule base record, that schedule's jobs will never be

backlogged unless you override this value on job records. Jobs will only be
backlogged if: 1) BACKLOG = YES on their job base records, or 2) the job is
submitted or started at the time of the next autoscan.
Suppose a job is carried over into tomorrow's workload. What happens if that
job is selected again tomorrow? Tomorrow's job is added to the workload after
today's backlogged schedule has completed or been canceled.

3.9 Defining Jobs
3.9.3.9 How Do You Phase Unicenter CA-Scheduler into Production?
Fields on both the schedule and job base records allow you to implement
Unicenter CA-Scheduler in stages:
■ AUTO SELECT on the schedule base record
■ LIBRARY TYPE
AUTO SELECT on the schedule base record controls whether Unicenter

CA-Scheduler evaluates this schedule automatically during autoscan. When
AUTO SELECT = NO, this schedule is skipped and these jobs are not included
in the daily workload. That is exactly what you want to happen while you are
developing definitions for a schedule's jobs. Once you have verified those
definitions using the Analyze and simulation reports, set AUTO SELECT =
YES to include this schedule in the evaluation process that occurs at every
autoscan. Although this schedule may already include production work, you
can let Unicenter CA-Scheduler take control of the selection of this work by
specifying AUTO SELECT = YES.
The next implementation phase permits you to monitor Unicenter

CA-Scheduler's operation while it submits dummy JCL for each of your jobs.
This gives you three important capabilities:
■ When you are first implementing Unicenter CA-Scheduler, you can run the
product in parallel with your normal production. Without affecting your
regular operation, you can verify that Unicenter CA-Scheduler is
processing your workload as planned.
■ Even experienced Unicenter CA-Scheduler sites use this technique to
prepare for implementing new applications. TESTLIB enables you to define
and test definitions for applications that are not yet ready to go into
production. You can check your selection criteria and verify the order in
which jobs will run before they have even been handed over to
production.
■ You can also test the effect of abended and failed jobs by using TESTLIB to
cause those conditions for specific jobs.
To initiate this phase, change AUTO SELECT to YES on the schedule base
record and set LIBRARY TYPE to TESTLIB. Remember that if LIBRARY TYPE
is defined at the job level, it overrides the value you specify on that job's
schedule base record. You can quickly verify what library type applies to your
jobs by checking that value on the Job Directory panel.
When Unicenter CA-Scheduler sees that LIBRARY TYPE = TESTLIB, it

constructs the JCL to run a simple Computer Associates utility program:
CAJUTSTA.
You can use TESTPARM=testparm on individual jobs to cause the test

program to abend, to pass a nonzero completion code, and to have it wait for
a number of seconds. Thus, you can test the effect of abending and failing jobs
on the rest of the schedule.

3.9 Defining Jobs
When you are ready to automate the selection process, set AUTO SELECT =
YES and identify where the JCL for these jobs is stored using the fields
described in the topic What JCL Does Unicenter CA-Scheduler Submit For
CPU Jobs.
3.9.3.10 What Job Fields are Used for Simulation?
Without actually executing your jobs, simulation produces reports showing:

■ How heavily each device would be utilized
■ Which jobs would carryover to the next day
Because simulation is such an effective planning tool, take the time to supply
the data needed to run simulation. First, indicate which CPU these jobs run
on. See the topic Which CPU Should Jobs Run On for instructions showing
how that is done. Then specify the other data required to run simulations.
AVERAGE TIME allows you to override the computed average run times for
this job derived from historical data. If you specify a value here, Unicenter
CA-Scheduler uses that time for simulation. The value reflects how much time
elapsed between when the job starts and ends. If you do not specify a value
here, Unicenter CA-Scheduler averages the elapsed times for the last seven
days the job ran.
You can change the value for AVERAGE TIME to determine the impact of
production changes before they actually happen. First, run simulation with
Unicenter CA-Scheduler's computed value for AVERAGE TIME. Then key in a
different value and rerun simulation. By comparing the reports, you will be
able to see the impact of such a change on your production workload.
Unicenter CA-Scheduler uses POWER CLASS to assign jobs to partitions on

the simulation reports. POWER CLASS should correspond to the value of the
CLASS parameter on JOB statements submitted to POWER (a single character,
0-9 or A-Z). Since that field occurs on both the schedule and job base record,
you only need to specify POWER CLASS for a job if the value on its schedule
base record is not appropriate for this job.
To refine the accuracy of your simulation runs, define the resources each job
requires on the job resource record (JRR). This information is not required to
run simulation. However, unless resources have been defined, you will not be
able to USE SIMTIME to start schedules and jobs. Instruction on how that is
done are found in the topic Defining A Job's Resource Record.

3.9 Defining Jobs
3.9.3.11 How and When Can You Display Documentation Automatically?
User documentation can be built according to whatever standards you want. It

is done using full-panel editing facilities provided with Unicenter
CA-Scheduler. Each documentation member in this documentation file is given
an eight-character key and this along with the schedule name or job name (and
job number and station) comprise the name that is used to uniquely identify it.
You can at any time, view this information by using the Documentation
Maintenance panel.
If the job has a documentation key defined, the contents of that documentation
library member will be printed as part of the forecast and simulation
components, if requested.
When defining a job using the Job Definition panel, you can specify a DISPLY
KEY and a DISPLAY TIME. If the job is a CPU job (station 40), then the name
in the DISPLY KEY field will have its documentation displayed on the master
operator console at the time of day specified in the associated DISPLAY TIME
field. This will happen automatically. If you do not use the DISPLAY TIME
field, but a DISPLY KEY field is specified, the documentation members will
display at autoscan time.
If the job is a non-CPU job, the user starting the job will receive a message
saying that there is documentation associated with the job and the name of the
documentation member. The user can then display it. If the non-CPU job is
automatically started (AUTO START=YES), then the message is sent to the
users in the SEND START MESSAGES TO list defined on the job's Message
Definition panel.
3.9.3.12 What Happens When Jobs Run Late?
Unicenter CA-Scheduler helps you manage your production workload by

alerting you to potential problems as quickly as possible. Therefore, when
Unicenter CA-Scheduler knows jobs are running late, it will warn you by
issuing messages. You can control when the messages are issued and who
receives them using fields on both schedule and job records and the MSG
generation macro parameter.

3.9 Defining Jobs
If You Want Specify This Value On The

Notification
When schedules
start late MUST TIMEs or SRC
MUST START BY TIME SBR
miss their deadlines DEADLINE TIMEs or SRC

COMPLETION DEADLINE TIME SBR
run too long MAXIMUM TIMEs or SRC

MAXIMUM EXECUTION TIME SBR
When jobs
start late MUST TIMEs or JRC
MUST START BY TIME JBR
miss their deadlines DEADLINE TIMEs or JRC

COMPLETION DEADLINE TIME JBR
run too long
MAXIMUM TIMEes or JRC
MAXIMUM EXECUTION TIME JBR
abend
SEND ABEND MESSAGES TO JMR
are interrupted
INTERRUPT = YES and JBR
SEND INTERRUPT MESSAGE TO JMR
SBR: Schedule base record

SRC: Schedule reason code record
JBR: Job base record
JRC: Job reason code record
JMR: Job message record
You can specify times in different ways:
MAXIMUM EXECUTION TIME tells Unicenter CA-Scheduler how long it

should take to process this job. The chart following illustrates the different
ways you can specify maximum execution time. Notice that leading zeros can
be omitted.
A Value Of Uses This And Means The Schedule Or Job

Notation Should Finish
30 mm Thirty minutes after it starts
200 hhmm Two hours after it starts
10200 ddhhmm The next day two hours after it
started (26 hours later)

3.9 Defining Jobs
Use a 24-hour clock to specify MUST START BY TIME and COMPLETION

DEADLINE TIME. The chart following shows that you can omit leading zeros
and you can extend the 24-hour clock by days.
A Value Of Uses This And Means Late Messages Will Be

Notation Issued
930 hhmm After 9:30 a.m. that day
1400 hhmm After 2 p.m. that day
11800 ddhhmm After 6 p.m. the next autoscan day
Warning messages are sent to the operator if OPERATOR was specified on the
MSG installation option. However, you can route those messages to any other
userid by specifying that userid as the value for the MSG installation option. If
you want messages sent to other userids, you can specify them in the schedule
and job message records (SMR and JMR).
You can specify MAILBOX as one of the userids, and the messages will be sent
to a common mailbox where they can be viewed using the Reporting Facility
panel.
3.9.3.13 How Do You Create Optional Job Records?
The RECS fields at the bottom of job panels fulfill two functions:
■ The values displayed show whether each type of record already exists for
this job. N means that type of record hasn't been defined yet.
■ The fields allow you to input commands that will branch to these records.
The chart following shows what these commands can do.
If The Current Value Is Enter To

N C Create that record
Y A Alter that record
D Display that record
The chart following explains the purpose of each record type.
If You Want To Select This Record By Typing After

Define job criteria JCR:
■ The days on which the
job is selected
■ Predecessor conditions
that must be satisfied

3.9 Defining Jobs
If You Want To Select This Record By Typing After

Assign different times to the job reason code JRC:
job when it is selected for
different reasons.
Add information that will be job information JIR:
printed on reports
Send messages to users job message JMR:
informing them of the job's
progress
Define the resources a job job resource JRR:
requires
These types of records will be discussed in the topic called Defining Optional
Job Records.
3.9.3.14 Copying Jobs
The following text describes a much quicker method. You can do this by
copying an existing job.
SCHD-JM JOB MAINTENANCE Scheduler

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

Begin by using option 1 of the Job Maintenance menu. Notice that Scheduler
expects you to specify select criteria when you choose option 1. Use the job's
name. Type 1,DEFAULTS in the command area and pressing ENTER.
Scheduler responds by displaying the Job Directory panel:

3.9 Defining Jobs
SCHD-JD JOB DIRECTORY Scheduler

===> _ MASTER - WR
CONNECT : 4
B C I M R R N C C
JOBNAME ST JNO SCHEDULE LIBTYPE MEMBER SYS R R R R C R R S E
DEFAULTS 4 1 BACKUP CMS DEFAULTS Y
PF1=HELP

The preceding panel allows you to copy a job definition: to use one job
definition as the prototype for another. Type C on the line describing the
DEFAULTS job and press Enter. Unicenter CA-Scheduler responds by
SCHD-JU JOB DEFINITION Scheduler

===> MASTER - WR
CONNECT : 4
JOB NAME : _ PROTOTYPE JOB: DEFAULTS JNO: 1 STN: 4

JOB NUMBER : 1 PROTOTYPE JOB IN SCHEDULE : BACKUP
MEMO :
MEMBER NAME : DEFAULTS SLI SUBLIB : ICCF LIB NUMBER:
MUST START BY TIME : COMMANDS AT JOB START: N
RECS= JBR: Y JCR: N JRC: N JIR: N JMR: N JRR: N JNR: N PF1=HELP

Now you can define a job while seeing all the defaults that would apply to it.
Next, define a job called IH7D02. Type IH7D02 as the job name. Then tab
down to MEMBER.
MEMBER NAME identifies where the JCL for this job is stored. Most sites
name the members in their production libraries to correspond with job names,
so MEMBER NAME defaults to JOB NAME. Notice that DEFAULTS is the
current value of MEMBER NAME. Since the JCL for this job is stored in a
member named IH7D02, type in that value here.
Next, look at the optional job records Unicenter CA-Scheduler uses to

implement other features. Tab to the bottom of your panel and enter Cs for
every record type except JBR. C indicates that you want to create these
records.

3.9 Defining Jobs
The Job Defines

Criteria record (JCR) - when to select a job less frequently than its
schedule
- more or different predecessors for this job
Reason code record (JRC) Different times for running the job depending
on the reason why it was selected that day
Information record (JIR) More information that only applies to this job
Message record (JMR) Messages to send users, informing them of
the job's progress
Resource record (JRR) Resources required to process the job
Node Record (JNR) Nodes to inform when this job starts and
ends
The next topic discusses the optional job records in detail.
3.9.4 Defining Optional Job Records

After the base record is successfully added to the database, pressing Enter will
take you through all of the optional panels that you indicated you want to
define. Now that you are familiar with the fields on the job base record,
optional job records will be described.
3.9.4.1 Defining a Job Criteria Record
When you select JCR, Unicenter CA-Scheduler displays an editor panel where
you define the job criteria record. This record can tell Unicenter CA-Scheduler
a variety of things:
■ The predecessors you defined for this job.
■ That you do not want this job to run every time this schedule is selected
(because a calendar is specified or the criteria statement includes selection
keywords)
■ That you want to give different reasons for selecting this job so you can
define different start times or keep separate statistics for each reason.
If you do not define a criteria record for a job, that job will be selected every
time the schedule is selected and its only predecessors will be those defined
for its schedule.
The top line of the Criteria Definition panel identifies which job this record
applies to. If that schedule uses a calendar for selection instead of a datetable,
that calendar name appears following C=. To move the cursor into the area
where you define criteria, press the TAB key once.

3.9 Defining Jobs
SCHD-JCRE DEF C= J=IH7D2 JN=1 ST=4 S=BACKUP CA-Scheduler

===>
RANGE=1-72
1...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
MON OR /EVERY MONDAY OR / 1
TUE OR /EVERY TUESDAY OR / 2
WED OR /EVERY WEDNESDAY OR / 3
THU /EVERY THURSDAY / 4
5
6
7
8
9
1
11
12
13
14
15
16
17
18
19
1...+....1....+....2....+....3....+....4....+....5....+....6....+....7...

Next, define this job to run Monday through Thursday. Type in the criteria
statement shown preceding to define four reasons for selecting this job.
Although it really does not matter where on this panel you enter your criteria,
we recommend you type each reason for selecting a job on a separate line so
that it is easier to see which reasons here correspond with fields on the job's
reason code record. If there is more than one reason for selecting a job, each
reason ends with OR (except the last one, of course).
Note: Multiple ORs can be grouped into a single reason code by placing
parentheses around this reason. (See the chapter "Criteria Language" for
more details.)
When you write criteria, you can embed comments anywhere by using /* as a
beginning delimiter and */ as an ending delimiter. These delimiters can appear
on different lines if the comment is longer than one line.
The preceding criteria statement will cause Unicenter CA-Scheduler to select

this job less frequently than the rest of the schedule. That means Unicenter
CA-Scheduler selects the BACKUP schedule every day. On Monday through
Thursday, Unicenter CA-Scheduler puts this job in the daily workload.

3.9 Defining Jobs
The criteria statement you just defined contains no predecessors. Therefore,

this job will be submitted when:
■ The schedule's early start time is reached
■ The schedule's predecessor conditions have been met
■ The job's start time is reached and
■ The job's defined resources are available
Note: Predecessors in job records are not evaluated until its schedule has
started and the job's early start time has been reached.
For complete information on coding criteria statements, see the chapter
"Criteria Language."
To save this criteria record and leave this panel, type FILE in the command
input area. Otherwise, you could leave the panel without saving this criteria
record by typing QUIT. All of the editor commands are in the appendix
"Editor Commands" in the Unicenter CA-Scheduler Reference Guide.
The FILE command causes Unicenter CA-Scheduler to immediately create that

job's criteria record. After you press Enter, Unicenter CA-Scheduler displays
the following panel, which confirms that record has been created:
SCHD-UTIL SCHDUTIL OUTPUT Scheduler

===> MASTER - WR
CONNECT : 4
DEFINE JCR S=BACKUP,NAME=IH7D2,JNO=1,ST=4,CRI='

MON OR
TUE OR
WED OR
THU'
CACU18I JCR IH7D2 HAS BEEN ADDED
PF1=HELP

To advance to the next panel, press Enter.
3.9.4.2 Defining a Job's Reason Code Record
If you defined a criteria record for a job, you may also want to use the options
available on a job's reason code record. That record allows you to define
different values for the following fields:
■ AVERAGE TIME
■ MUST START BY TIME
■ MAXIMUM EXECUTION TIME
A job reason code record works just like a schedule's reason code record:

3.9 Defining Jobs
■ It is only valid if a criteria record exists for that job and selection is not
accomplished by a calendar.
■ It allows you to define up to 16 different values for certain fields, one for
each reason why this job could be selected.
■ Scheduler checks to see the reason why a job was selected, and then
applies the corresponding values when processing the job that day.
The only difference is that a job's reason code record applies to a specific job
while a schedule's reason code record applies to that schedule. A job's values
do not default to its schedule's values. Type the displayed values under MUST
TIME LIST and MAXIMUM TIME LIST.
SCHD-JRC REASONS DEFINITION Scheduler

===> MASTER - WR
CONNECT : 4
JOB NAME : IH7D2 PROTOTYPE JOB: JNO: STN:

JOB NUMBER : 1 PROTOTYPE JOB IN SCHEDULE :
STATION ID : 4
AVG TIME LIST:
1 2 3 4 5 6 7 8
9 1 11 12 13 14 15 16
EARLY TIME LIST:
1 2 3 4 5 6 7 8
9 1 11 12 13 14 15 16
MUST TIME LIST:
1 2215 2 2315 3 2315 4 2315 5 6 7 8
9 1 11 12 13 14 15 16
DEADLINE TIME LIST:
1 2 3 4 5 6 7 8
9 1 11 12 13 14 15 16
MAXIMUM TIME LIST:
1 15 2 1 3 1 4 1 5 6 7 8
9 1 11 12 13 14 15 16
RECS= JBR: Y JCR: Y JRC: N JIR: N JMR: N JRR: N JNR: N PF1=HELP

The Reasons Definition panel allows you to specify up to 16 different values
for these five fields, which have meanings similar to fields found on the job's
base record. Unicenter CA-Scheduler matches these values with the reasons
defined on the job's criteria record: the first values here apply to the first
reason the job was selected, and so on. Our example shows different values
defined for two fields. How does this relate to the job's criteria statement and
the schedule's reason code record?
■ On Mondays, Unicenter CA-Scheduler will issue warning messages if this
job does not start by 10:15 p.m. or runs longer than 15 minutes.
■ On other days, messages are issued if the job hasn't started by 11:15 p.m.
or it takes longer than 10 minutes to run.
■ The schedule's reason code record sets the default early start times for all
the jobs in this schedule based upon the reason why the schedule was
selected. None of a schedule's non-CPU jobs can be started and none of its
CPU jobs can be submitted until the schedule's start time has been
reached.

3.9 Defining Jobs
■ MAXIMUM TIMEs have been defined for the schedule as well as this job.
The job's record sets limits on how long this one job should run, but the
schedule's record limits how long the entire schedule can take.
Descriptions of all five fields on this panel follows.

AVG TIME Tracks how long the job takes for up to 16 reasons why
it might be selected. AVG TIME on the job's record does
not override the values for AVG TIME on the schedule's
record because these fields describe two different things:
how long an entire schedule or only one job usually
takes to run. Instead, the AVG TIMEs you specify
override the actual average run times derived from
historical data.
EARLY TIME Allows you to specify different EARLIEST START TIMEs
for each reason this job is selected. If you leave these
fields blank, Unicenter CA-Scheduler uses the value on
the job's base record every time the job is selected.
Notice that a schedule's EARLY TIME must be reached
before Unicenter CA-Scheduler considers submitting any
of its jobs.
MUST TIMEs Tell Unicenter CA-Scheduler to issue late messages if the
job hasn't started by the time specified for each reason
jobs can be selected. If you leave these fields blank,
Unicenter CA-Scheduler uses the value for MUST
START BY TIME on the job's base record instead.
DEADLINE TIMEs Tells Unicenter CA-Scheduler to issue late messages if
this job isn't finished by the time specified. Specify
values here if you want to define different deadlines for
each reason the job was selected. These values override
the COMPLETION DEADLINE TIME you may have
specified on the job base record. Notice that these
deadlines apply to a specific job while those on schedule
records define when all the jobs in that schedule must be
completed.
MAXIMUM TIMEs Sets limits on how long a job should run. If it takes
longer, Unicenter CA-Scheduler will issue a late
message. Specify values here if you want to define
different durations for each reason the job was selected.
These values override the MAXIMUM EXECUTION
TIME specified on the job's base record. MAXIMUM
TIME on job records define how long a job should take
to run, but on schedule records, MAXIMUM TIME
shows how long all the jobs in that schedule run.
What happens if you define more than 16 reasons in a criteria statement? The
times for any reasons beyond the 16th default to the values defined on the
job's base record.

3.9 Defining Jobs
Now that you are familiar with these fields, finish creating this reason code
record. After you have finished filling in fields on this panel, press Enter.
Unicenter CA-Scheduler immediately creates this record and confirms it with
this message.

===> MASTER - WR
CONNECT : 4
DEFINE JRC NAME=IH7D2,JNO=1,STATION=4,SCHEDULE=BACKUP,MUST1=2215,

MUST2=2315,MUST3=2315,MUST4=2315,MAX1=15,MAX2=1,MAX3=1,
MAX4=1
CACU18I JRC IH7D2 HAS BEEN ADDED
PF1=HELP

Use of reason codes provides you with scheduling flexibility. To advance to
the next panel, press Enter.
3.9.4.3 Defining a Job Information Record
All the job records you have defined so far contain information that affects
how Unicenter CA-Scheduler automates production at your site. However, a
job's information record is primarily for your use. It stores descriptive
information about this job that helps your staff wrap up the work Unicenter
CA-Scheduler began for you.
SCHD-JIR INFO DEFINITION Scheduler

===> MASTER - WR
CONNECT : 4

STATION ID : 4
DESCRIPTION : JUST WHAT IS CHANGED
COMMENT : MON-THU
EXITPARM:
FORM :
NOTIFY : VERIFY:
QUANTITY :
RESPONSIBILITY:
SPECIFICATION :
DESTINATIONS-1: rm112 2: 3: 4:
5: 6: 7: 8:
DELIVERABLES:
1: backup tapes 2: 3: 4:
5: 6: 7: 8:
RECS= JBR: Y JCR: Y JRC: N JIR: N JMR: N JRR: N JNR: N PF1=HELP

Unicenter CA-Scheduler only reacts to one field on the job information record:
EXITPARM. It adjusts the class or average processing time of this job during
simulation. Unicenter CA-Scheduler passes this optional value of up to 16
bytes to an optional user exit.

3.9 Defining Jobs
DESTINATIONS and DELIVERABLES allow you to record where to send the

output for this job. Notice that the panel preceding shows IH7D02 produces
backup tapes for delivery to room 112. These fields are only used in reports.
Next, create the information record shown preceding. As you tab from field to
field, type in the data displayed on the panel preceding. After you have input
that information, you are ready to create the information record.
After you have filled in the panel, press Enter to save the information record
for that job. Unicenter CA-Scheduler confirms that it stored that information by

===> MASTER - WR
CONNECT : 4
DEFINE JIR NAME=IH7D2,JNO-1,STATION=4,SCHEDULE=BACKUP,

DESC='JUST WHAT IS CHANGED',COMMENT='MON-THU',DEST1='RM112',
DEL1='BACKUP TAPES'
CACU18I JIR IH7D2 HAS BEEN ADDED
PF1=HELP

To view the next panel, press Enter. That displays the panel that defines the
job's message record.
3.9.4.4 Creating a Job Message Record
The job's message record extends Unicenter CA-Scheduler's progress

notification capability beyond schedules to jobs. By defining this record, you
can notify users of the progress made by an individual job:
■ When jobs start or end
■ Or only when they end unsuccessfully
■ When they are late starting or ending
■ When jobs require human intervention
■ When jobs run too long
So the schedule's message record identifies who needs to be notified about a

schedule's progress while a job's message record specifies who to tell about a
job's progress.

3.9 Defining Jobs
SCHD-JMR MESSAGE DEFINITION Scheduler

===> MASTER - WR
CONNECT : 4

STATION ID : 4
SEND ALL MESSAGES TO :
SEND START MESSAGES TO :

SEND END MESSAGES TO :
SEND LATE MESSAGES TO : operator
SEND ABEND MESSAGES TO : operator

SEND FAIL MESSAGES TO : operator
SEND INTERRUPT MESSAGE TO:
RECS= JBR: N JCR: N JRC: N JIR: N JMR: N JRR: N JNR: N PF1=HELP

You can initiate every kind of job progress reporting by filling in one field on
the job message record. If that is the only field you fill in on this record, all
job-related messages will go to that ID. Suppose you entered YOURID as a
value for SEND ALL MESSAGES. If you fill in other fields on this record, it
affects which messages go to YOURID. YOURID will get only those messages
not routed elsewhere. If you really want YOURID to get all messages, be sure
to include YOURID in every userid list you specify on this panel.
You can list up to four userids separated by commas in any of these fields. To
send any kind of message to the master console, specify OPERATOR as one of
the userids.
You can also specify MAILBOX as one of the userids, and the messages will be
sent to a common mailbox where they can be viewed using the Reporting
Facility panel.
The panel preceding creates a job message record that sends abend, fail, and
late messages to the master console. Try creating that record on your own by
tabbing to these fields and typing the value OPERATOR.
Unicenter CA-Scheduler needs to know more to produce some of these

messages. The chart following tells you what fields need to be completed to
activate each kind of message.
For These Messages Specify On The

Start messages SEND START MESSAGES JMR
End messages SEND END MESSAGES JMR

3.9 Defining Jobs
For These Messages Specify On The

Late messages -SEND LATE MESSAGES and JMR
-MUST START BY TIME JBR
MUST TIMEs JRC
-COMPLETION DEADLINE TIME or JBR
DEADLINE TIMEs JRC
-MAXIMUM EXECUTION TIME or JBR
MAXIMUM TIMEs JRC
Abend messages SEND ABEND MESSAGES JMR
Fail messages SEND FAIL MESSAGES JMR
Interrupt messages INTERRUPT and SEND INTERRUPT JBR
MESSAGE JMR
You can send a message when this job misses its deadline because you already
defined deadlines on the job's reason code record.
Then press Enter to save the job's message record. Unicenter CA-Scheduler
responds by displaying the following message:

===> MASTER - WR
CONNECT : 4
DEFINE JMR NAME=IH7D2,JNO=1,STATION=4,SCHEDULE=BACKUP,

LATEMSG=(OPERATOR),ABENDMSG=(OPERATOR),FAILMSG=(OPERATOR)
CACU18I JMR IH7D2 HAS BEEN ADDED
PF1=HELP

To view the next panel, press Enter.
3.9.4.5 Defining a Job Resource Record
The job resource record provides the information needed to run simulations.
Most of the fields show what types of devices your job requires. Unicenter
CA-Scheduler even maintains several key fields itself using data. To explore
this record in more detail, enter the displayed data in the appropriate fields:

3.9 Defining Jobs
SCHD-JRR RESOURCE DEFINITION Scheduler

===> MASTER - WR
CONNECT : 4

STATION ID : 4
MAX CPU TIME : ROUTE DELAY :
SEPARATE DSNAME:
SEPARATE JOBS
LIST:
DASD1 : 338,2 DASD2 :
DASD3 : DASD4 :
DASD VOLSERS :
DASD EXCPS :
TAPE1 : 348,1 TAPE2 :
TAPE3 : TAPE4 :
TAPE EXCPS:
UNIT1 : UNIT2 :
UNIT3 : UNIT4 :
UNIT EXCPS:
RECS= JBR: Y JCR: Y JRC: Y JIR: Y JMR: Y JRR: N JNR: N PF1=HELP

First, let us focus on three fields that affect when jobs are actually processed:
SEPARATE DSNAME Identifies a data set that can only be used by one
job at a time. That means while this job is
running, all other jobs are prevented from using
that data set. Unicenter CA-Scheduler accepts up
to 44 characters for a SEPARATE DSNAME. For
this option to be effective, you must also define
this data set as a SEPARATE DSNAME for every
job that uses this data set.
SEPARATE JOBS LIST Accepts up to eight entries that identify jobs that
are submitted or started or that cannot run on this
CPU while this job is running. If JOBA cannot
run with JOBB, then JOBB cannot run with JOBA
which means every job mentioned here also needs
a JRR of its own that names this job in its
SEPARATE JOBS LIST. When specifying more
than one job name, use commas between them, or
use mask characters. Mask characters identify a
group of jobs by defining the characters that these
job names have in common. The chart following
gives several examples of how to use mask
characters.
To Separate All Jobs That Specify

Start with PAY PAY*
End with 0100 0100

3.9 Defining Jobs
To Separate All Jobs That Specify

Somewhere contain the string QUEL *QUEL*
Start with PAY and end with 00 PAY*00
Start with P and the third character is Y P?Y*
For more information about mask characters, see

the definition in the Glossary.
DASD VOLSERS Specifies up to eight DASD volumes that must be
mounted before this job can be submitted.
Specifying them here does not get the devices
mounted. Instead, it causes Unicenter
CA-Scheduler to set job status to WAITING FOR
RESOURCES until all of the DASD VOLSERs
listed here are mounted. When Unicenter
CA-Scheduler sees that those resources are
available, it then submits the job. When specifying
more than one DASD VOLSER, use commas
between them. To refine the accuracy of your
simulations, define values where appropriate for
the fields described preceding as well as the
following:
■ Identify how many of each type of DASD,
tape and unit record devices this job uses. The
DASD types entered here must match
resources listed for the CPU's station record.
Unicenter CA-Scheduler has allocated room
for up to four different entries for each type of
device.
■ For example, if this job uses two 3380s, set
DASD01 = 3380,2. That tells Unicenter
CA-Scheduler that it should not simulate
processing until:
– Start time has been reached
– All predecessor conditions have been
satisfied
– Those defined resources are available
If this job is processed at several workstations, you may need to define a

ROUTE DELAY. Estimate how long it takes this job to get to this station from
the preceding one. This routing delay could take minutes or even days. The
chart following shows your options for specifying ROUTE DELAY:

3.9 Defining Jobs
A Value Of Uses This And Means The Job Is Delayed

Notation
30 mm Thirty minutes because of routing
200 hhmm Two hours
10200 ddhhmm 26 hours due to routing (1 day + 2 hours)
JOB NAME, JOB NUMBER, STATION ID and SCHEDULE NAME always

require the appropriate values. If you create a job's resource record by typing
C next to JRR in a RECS field, you do not have to fill in these values because
Unicenter CA-Scheduler does that for you. If you try copying another job's
resource record by issuing a CRR command on the Job Directory panel, you
will need to enter the appropriate values for these fields.
The remaining fields do not require input:

■ PROTOTYPE JOB, JNO, STN and PROTOTYPE JOB IN SCHEDULE are
only useful if you want to copy another job's resource record. Since there is
a more convenient method for copying records, leave these fields blank.
■ Scheduler maintains MAX CPU TIME, DASD EXCPS, TAPE EXCPS and
UNIT EXCPS using data. However, these fields also accept input. If you
enter values in these fields, they become the new values used in all future
simulations.
Next, define this job's resources. Enter the values shown on the panel
preceding. DASD01 = 3380,2 shows that this job uses two 3380s. And TAPE01
= 3480,1 means this job uses one 3480 tape drive. When Unicenter
CA-Scheduler simulates this job, it will know this job cannot run until those
resources are available.
Be very careful when defining resources: only specify device types that are also
defined as resources on station records. Unicenter CA-Scheduler does not
verify that your job's resources exist at the specified station when you define a
job's resource record. If you specify an undefined station resource, the
simulation report will always show this job as waiting for resources.
To save the job's resource record, press Enter. Unicenter CA-Scheduler


===> MASTER - WR
CONNECT : 4
DEFINE JRR NAME=IH7D2,JNO=1,STATION=4,SCHEDULE=BACKUP

DASD1=(338,2),TAPE1=(348,1)
CACU18I JRR IH7D2 HAS BEEN ADDED
PF1=HELP


3.9 Defining Jobs
To view the last optional job record, press Enter.
3.9.4.6 Defining Job Node Records
The last type of optional record is only used if you have a CPU network that
uses NJE and Unicenter CA-Scheduler with the NJE option activated at every
member of every node. Job node records contain the information necessary to
implement a specialized feature of the criteria language: NJE. The criteria
language allows you to define predecessors that reference jobs running at other
nodes. For example, suppose that JOBA is defined and runs on the node in
New York. JOBA is a predecessor of JOBB, but JOBB is in a schedule that is
defined at the Phoenix site.
How will the node in Phoenix know the status of JOBA in New York? That is
the purpose of the job node record: to inform other nodes of status of a
specific job. Define a job node record for jobs that are predecessors of jobs that
are defined at different nodes.
SCHD-JNR INFORM DEFINITION Scheduler

===> MASTER - WR
CONNECT : 4

STATION ID : 4
INFORM NODES: NEWYORK
RECS= JBR: Y JCR: Y JRC: Y JIR: Y JMR: Y JRR: Y JNR: N JNR: N PF1=HELP

INFORM NODES requires you to specify at least one node ID: the node where
this job's successor runs. Suppose that after IH7D02 backups up critical files in
Phoenix, the national TP network can be started in New York which means
that IH7D02 runs in Phoenix and has a successor in New York that is waiting
for IH7D02 to complete normally. By specifying NEWYORK in the INFORM
NODES field, you ensure that New York is notified when IH7D02 finishes
successfully.
Scheduler allows you to specify up to eight different node IDs separated by

commas:
INFORM NODES: node1,node2,node3,...,node8

3.9 Defining Jobs
The node IDs you specify here must also be listed in the CAIJNET installation
macro. To avoid undue overhead, only specify the node IDs that have
predecessor jobs waiting on this job's progress. It is not necessary, nor is it
advisable, to list the node ID where the job runs.
Then press Enter to save the job's node record. Unicenter CA-Scheduler

===> MASTER - WR
CONNECT : 4
DEFINE JNR NAME=IH7D2,JNO=1,STATION=4,SCHEDULE=BACKUP

INFORM=(NEWYORK)
CACU18I JNR IH7D2 HAS BEEN ADDED
PF1=HELP

Press Clear to return to the Job Maintenance panel before starting the next
topic.

3.10 Displaying and Updating a Job Definition

To correct errors detected by the ANALYZE command or to make any other
changes to job definitions, you can retrieve a record from the database, display
it and alter it. There are several ways to do this:
■ Go to the Job Maintenance menu and select the ALTER function by typing
3 in the input area. You must also give the name of the job you want to
alter. Then press Enter.
■ Display the Job Directory panel by going to the Job Maintenance menu and
pressing ENTER. When the directory appears, move the cursor to the job
you want to alter and type A next to it. This allows you to alter a number
of definitions quickly without having to return to the Job Maintenance
menu each time.
■ Another shortcut uses the RECS= line to edit related job records. If you
have displayed one job record and want to edit another record belonging
to the same job, enter A after the appropriate field on the REC= line.
■ The fastest method for editing allows you to go directly to any optional job
record from the Job Directory panel. Enter a three-letter code to indicate
what you want to do and which record to do it to. This method is
explained in detail later in this topic.
The first method parallels what you have learned about editing other types of
records, so that will not be repeated here. Other methods of editing are shown
following.
Two factors determine who can update a job record:

■ A user's authority level
■ The USERS defined on the corresponding schedule base record
Supervisor authority allows users to update all jobs that run at stations
specified on their userid records. People with Manager authority can update
all job records for every workstation, but users with General authority can only
update jobs belonging to public schedules and schedules that specifically
define them as USERS.
Begin by checking which option on the Job Maintenance menu allows you to
alter existing records:


===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

This panel tells you to press Enter to display a complete directory of jobs. That
panel appears following:

===> MASTER - WR
CONNECT : 4
B C I M R R N C C
IH7D2 4 1 BACKUP CMS IH7D2 Y Y Y Y Y Y Y
END OF DATA
PF1=HELP

From this panel you can display or alter any type of job record. Enter the
following commands next to the job name.
To Type This Next To The Job Name

Display a record
base D
criteria DCR
information DIR
message DMR
node DNR
reason code DRC
resource DRR


Alter a record
base A
criteria ACR
information AIR
message AMR
node ANR
reason code ARC
resource ARR
Next, change job IH7D02. Other fields occur on the right of this panel, but
ignore them for now. Instead, press the TAB key twice to move the cursor to
the line that describes the job IH7D02. Then type A and press Enter.
If an unauthorized user tries to change an existing job definition, Scheduler

displays the message:
CACO226E USER NOT AUTHORIZED FOR THIS JOB
If your authority level permits you to alter that job record, Scheduler displays
the Job Alter panel.
SCHD-JU JOB ALTER Scheduler

===> MASTER - WR
CONNECT : 4
JOB NAME : IH7D2

JOB NUMBER : 1
MEMO :
MEMBER NAME : IH7D2 SLI SUBLIB : ICCF LIB NUMBER:
MUST START BY TIME : COMMANDS AT JOB START : N
RECS= JBR: Y JCR: Y JRC: Y JIR: Y JMR: Y JRR: Y JNR: Y PF1=HELP

To change any value on this panel, you can tab to it and type in a new value,
but what if you do not want a value anymore? How do you eliminate a value?
■ To eliminate TIME values, type all zeros. For example, you can undo a
previously specified start time by filling in the field with six zeros and
pressing ENTER.
■ Values for fields like MEMO can be deleted by typing NULL in place of
the old value. Type NULL and blank out any other characters in the

MEMO field. That causes Unicenter CA-Scheduler to eliminate the value it

previously stored for MEMO.
While you are altering the job base record, you can also create or edit optional
job records by changing RECS values. Currently, the RECS values show you
which types of records already exist:
■ Y means the record has been defined.
■ N means those record types do not exist.
The RECS fields also accept input. You can tab to any RECS value and enter
codes that allow you to create, alter or display those job records. In the
following fields enter C to create, A to alter, or D to display.
Enter C, A, Or D Next To Which Is This Type Of Record

JBR Job base record
JCR Job criteria record
JRC Job reason code record
JIR Job information record
JMR Job message record
JRR Job resource record
JNR Job node record
To edit the job's criteria record, type A in the JCR field, and then press Enter.
Scheduler first changes the job base record and returns the following message:

===> MASTER - WR
CONNECT : 4
ALTER JBR LASTUSER=MASTER,NAME=IH7D2,JNO=1,STATION=4,SCHEDULE=BACKUP

CACU18I JBR IH7D2 HAS BEEN ALTERED
PF1=HELP

To move on to the job's criteria record, press Enter.
The Criteria Definition panel displays the record you defined for this job
earlier:

SCHD-JCRE DEF C= J=IH7D2 JN= 1 ST=4 S=BACKUP Scheduler

===>
RANGE=1-72
1...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
MON OR /EVERY MONDAY OR / 1
TUE OR /EVERY TUESDAY OR / 2
WED OR /EVERY WEDNESDAY OR / 3
THU /EVERY THURSDAY / 4
5
6
7
8
9
1
11
12
13
14
15
16
17
18
19
1...+....1....+....2....+....3....+....4....+....5....+....6....+....7...

To change the criteria statement, tab to the input area and type the correct
statement. To delete a line, tab to the numbered column at the right, type a D
and press Enter. Other editor commands are documented in the appendix
"Editor Commands" in the Unicenter CA-Scheduler Reference Guide, Part 2.
To leave this panel, type one of the following commands in the command area:
■ QUIT cancels the changes you have made to the criteria statement.
■ FILE stores this statement as the job's new criteria record.
To leave this panel without saving a new criteria record, type QUIT in the
command area and press Enter.
Unicenter CA-Scheduler responds by returning you to the Job Directory panel:

===> MASTER - WR
CONNECT : 4
B C I M R R N C C
END OF DATA
PF1=HELP

This panel focuses on the columns at the right. A Y in these columns shows
which types of job records have been created for each job listed in the
directory:

BR = job base record

CR = job criteria record
IR = job information record
MR = job message record
RC = job reason code record
RR = job resource record
NR = job node record
CS = commands at job start
CE = commands at job end
Next, alter IH7D02's criteria record directly from this panel. Start by tabbing to
that line on the panel. Then type ACR and press Enter. The A means you want
to alter a record and CR indicates which one: the criteria record. (If you only
wanted to display that record, you wouldd type DCR instead of ACR.)
Scheduler responds by displaying IH7D02's criteria record. To save the record

type FILE on the command line and press Enter. Whenever you alter a job
record, Unicenter CA-Scheduler will confirm that it is made that change in its
database by displaying the appropriate message on its utility panel.

===> MASTER - WR
CONNECT : 4
ALTER JCR NAME=BACKUP,NAME=IH7D2,JNO=1,ST=4,CRI='

MON OR
TUE OR
WED OR
THU'
CACU18I JCR IH7D2 HAS BEEN ALTERED
PF1=HELP

Press Enter to return to the Job Directory panel. Then you can continue editing
job definitions or press Clear to return to the Job Maintenance menu.

3.11 Deleting Job Records

Because there are different types of job records, Unicenter CA-Scheduler gives
you two methods for deleting them. Which method you use depends on what
job records you want to delete. However, be advised that deleting job records
from the database is a serious matter and isn't part of a normal day's activities.
If you do not know which job you want to delete, or you only want to delete
an optional job record, begin by displaying a directory of jobs using the Job
Maintenance menu.

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

Pressing Enter at that menu causes the following panel to appear.

===> MASTER - WR
CONNECT : 4
B C I M R R N C C
END OF DATA
PF1=HELP

Your entries will differ from those shown preceding, but you should be able to
find IH7D02's job record. Tab down to it.
The various deletion options this directory panel supports follow.

To Delete Enter
All records for that job (except the history L
record)
Just the
criteria record LCR
history record LHR
information record LIR
message record LMR
reason code record LRC
resource record LRR
base record LBR
commands at job start LCS
commands at job end LCE
Next, delete this job's message record. First, check that the job actually has a
message record. The value in the MR column will be Y if a message record
exists for this job. Next, delete the job's message record by typing LMR on
that line and pressing Enter.
If you have the authority to change this job, Scheduler confirms that it deleted
that record by displaying the message:

===> MASTER - WR
CONNECT : 4
DELETE JMR NAME=IH7D2,JNO=1,STATION=4,SCHEDULE=BACKUP

CACU18I JMR IH7D2 HAS BEEN DELETED
PF1=HELP

To return to the Job Directory panel, press Enter. Then press Clear to return to
the Job Maintenance menu so we can demonstrate the second method for
deleting job records.
The following describes how to delete all job records with a single command.
Begin by checking which option on the Job Maintenance menu allows you to
delete an existing record:


===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

however, that Unicenter CA-Scheduler expects you to enter a job name and
schedule name when you select option 5. Therefore, when you type 5 in the
command area, follow it with a comma, the name of the job you want to
delete, another 3 commas, and the name of the schedule that job belongs to.
Next, delete the job called DEFAULTS. To do that, enter

5,DEFAULTS,,,BACKUP in the command area to delete that record.
Scheduler then deletes the record for job number 01 at station 40. To delete a
record at another station or for another job number, specify all the optional
parameters with option 5. For example, entering
5,DEFAULTS,2,39,BACKUP
deletes the second job record called DEFAULTS belonging to the BACKUP
schedule at station 39 (if it was previously defined).

If you are not authorized to delete this job, Unicenter CA-Scheduler displays
the message DELETE NOT ALLOWED, but if you do have that authority,
Unicenter CA-Scheduler confirms it deleted all records (except the history
record) for that job with the message shown following:

===> MASTER - WR
CONNECT : 4
DELETE JOB NAME=DEFAULTS,JNO=1,STATION=4,SCHEDULE=BACKUP

CACU18I JBR DEFAULTS HAS BEEN DELETED
PF1=HELP


3.12 Analyzing Jobs
3.12 Analyzing Jobs

You should analyze all jobs that you add to the database before you put them
into production. This allows you to fix discrepancies and omissions before
you run the jobs. There are two ways to analyze a job online:
■ Analyze a specific job
■ List all jobs and pick one to analyze
The first method is quicker, but the second is useful if you do not know the
exact spelling of the job to be analyzed. The analysis will produce messages
about the following:
■ If the job records specify an undefined schedule, calendar, datetable,
userid, or predecessor
■ If a predecessor or successor deadlock exists
To analyze a specific job, start at the Job Maintenance panel. Suppose there is
a job (NEWJOB) you recently defined, but you defined a schedule name of
NEWSCHD7 that isn't defined to Scheduler.

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP

To analyze the schedule, enter 6, followed by the job name.

3.12 Analyzing Jobs

===> MASTER - WR
CONNECT : 4
ANALYZE JOB LIST=ERR,NAME=NEWJOB

CACU17E SCHEDULE NEWSCHD7 NOT FOUND
CACU18I JOB NEWJOB HAS BEEN ANALYZED
PF1=HELP

Notice that the analysis is performed with the LIST=ERR option so that only
error messages are displayed. If you need a full analysis report, use the JCL
described in the chapter "Reports" in the Unicenter CA-Scheduler Reference Guide
Part 2.
Before examining the second method of analyzing jobs, return to the Job
Maintenance panel by pressing CLEAR.
To analyze a job that has a name you do not know, start at the Job
Maintenance panel. You need to display a full directory of jobs so that you
can find the one you want.

===> MASTER - WR
CONNECT : 4
FUNCTION ENTER
-------- ------
PF1=HELP


3.12 Analyzing Jobs
To display a full directory of jobs, press Enter.

===> MASTER - WR
CONNECT : 4
B C I M R R N C C
IH7D2 4 1 BACKUP CMS IH7D2 Y Y Y Y Y Y
NEWJOB 4 1 NEWSCHD7 CMS NEWJOB Y
NEWJOB2 4 1 NEWSCHD8 CMS NEWJOB2 Y Y
END OF DATA
PF1=HELP

Assume that the job that you want to analyze is called NEWJOB2. You
recently defined it, but on the criteria record you named it as a predecessor of
itself. Thus, a predecessor deadlock exists. Tab to NEWJOB2 and enter ANA.

===> MASTER - WR
CONNECT : 4
ANALYZE JOB LIST=ERR,NAME=NEWJOB2,SCHEDULE=NEWSCHD8

CACU4E NEWJOB2 1 4 NEWSCHD8 DEADLOCK WITH PRED NEWJOB2 1 4 NEWSCHD8
CACU18I JOB NEWJOB2 HAS BEEN ANALYZED
PF1=HELP

Before beginning the next topic, return to the Main Menu by pressing Clear
repeatedly.

3.13 Automatic Console Replies for Jobs

Console messages issued by Unicenter CA-Scheduler VSE controlled jobs or
schedules typically require a response that either issues a command, supplies
data or requests some kind of operator intervention. These responses can be
automated by using Scheduler's Automatic Console Reply feature. This feature
is unavailable with the CMS online component.
You begin by tabbing to the Auto-Reply Maintenance line and pressing

ENTER.
SCHD-MM MAIN MENU Scheduler

===> E - WR
CONNECT : 4

==> POWER INTERFACE
==> JOB MAINTENANCE
==> DOCUMENTATION MAINTENCE
PF1=HELP

This displays the following Automatic Reply Maintenance panel. It may also
be reached by selecting 7,AUTO-REPLY PROCESSING on the Job Maintenance
Menu panel SCHD-JM, or the Schedule Maintenance Menu panel SCHD-SM.
Overwriting the auto-reply messages field on the JBR or SBR with the letter Y
or C will also bring you to the Automatic Reply Maintenance panel.

SCHD-AR AUTOMATIC REPLY MAINTENANCE Scheduler

====> MASTER - WR
CONNECT : 4
Schedule : ________ Job : ________ Jno : __ Msgid : ________
Scantxt :
Reply :


3.13.1.1 To ADD a New Reply
To enter a new reply associated with a job, type the job name in the job name
field and press Enter. If the job has already been defined to the database, the
panel will show the existing schedule name, job numbers, message IDs, scan
text for each message (if any), and the reply texts. If the job has not been
defined, proceed as follows.
Enter the schedule name in the schedule name field.
Enter the job number in the jno field.
Enter the message ID in the msgid field. The message ID is the first one to
eight characters of the message associated with the reply.
Each of the four key fields, Schedule Name, Job Name, JNO (job number) and
MSGID (message id), can also have a generic value. For example:
AA - any char string may follow
A??B ? - any char in this position

Scan text is a string of one to sixteen characters that occur in the message. The
string will be checked to verify the message id.
You may enter a reply to the message of up to 72 characters.


====> MASTER - WR
CONNECT : 4
Schedule : Sched1__ Job : JOBD____ Jno : 14 Msgid : cacm27_
Scantxt : autoscan cannot
Reply : wait for monitor to terminate, then reactivate


To add the record to the database, either enter ADD on the command line or
press the function key.
The message CACO360I AUTO-REPLY RECORD ADDED will be displayed.

====> MASTER - WR
CACO36I AUTO-REPLY RECORD ADDED CONNECT : 4
Schedule : SCHED1 Job : JOBD___ Jno : 14 Msgid : CACM27
Reply : WAIT FOR MONITOR TO TERMINATE, THEN REACTIVATE



3.13.1.2 ALTer or REPlace an Auto-Reply Record
Begin with the Auto-Reply Maintenance panel SCHD-AR, described preceding.
To alter or replace an existing reply, enter the job name or job number and
press Enter to search for the message to be changed. The ENTER-BROWSE
function displays the replies that currently exist in the database for that
jobname.
Type A or R on the line of the record to be changed, and press Enter.

====> MASTER - WR
CONNECT : 4
Scantxt :
Reply :


a SCHED1 JOBD 14 CACM27 AUTOSCAN CAN WAIT FOR MON

The messages CACO372I UPDATE FIELDS AND PRESS ENTER and ALTER
will be displayed in the command area.


====> ALTER MASTER - WR
CACO372I UPDATE FIELDS AND PRESS ENTER CONNECT : 4
Schedule : SCHED1 Job : JOBD____ Jno : 14 Msgid : CACM27_



Type the changes in the appropriate fields and press Enter.

UPDATED displayed.

====> MASTER - WR
CACO361I AUTO-REPLY RECORD UPDATED CONNECT : 4




3.13.1.3 To DELete an Auto-Reply Record
To delete an existing reply, enter the job name on panel SCHD-AR and press
Enter to search for the message to be deleted.
Type L on the line of the record to be deleted and press Enter.

====> MASTER - WR
CONNECT : 4
Scantxt :
Reply :


l SCHED1 JOBD 14 CACM27 AUTOSCAN CAN WAIT FOR MON

The message CACO369I PRESS ==> PF5 <== TO CONFIRM DELETE and
DELETE will be displayed in the command area.

====> DELETE MASTER - WR
CACO369I PRESS ==> PF5 <== TO CONFIRM DELETE CONNECT : 4


SCHED1 JOBD CACM27 AUTOSCAN CAN WAIT FOR MON



DELETED is displayed.

====> MASTER - WR
CACO362I AUTO-REPLY RECORD DELETED CONNECT : 4
Schedule : SCHED1 Job : JOBD____ Jno : _ Msgid : CACM27


_ SCHED1 JOBD CACM27 AUTOSCAN CAN WAIT FOR MON


3.14 Summary of Job Maintenance

Unicenter CA-Scheduler only allows authorized users to create, update or
delete job records. General users can work with jobs belonging to public
schedules or schedules that specifically grant them access in the USERS field.
The chart following sums up the steps involved in maintaining job records
from the Job Maintenance menu. Since there are several ways to do things,
only the fastest ways are shown:
To Enter This In Then

Command Area
Define a job 4 Enter job data
Copy a job 1,job being copied Tab to a job; enter C or Cxx,
where xx is the record type.
Enter new data
Alter
a specific job 3,job name Enter changes in JBR; enter A
in a RECS= field
an unknown job (Press Enter) Tab to a job; enter A or Axx,

where xx is the record type
Delete
a specific job 5,jobname,,,schedname Tab to the job; enter Lxx,
a specific record (Press Enter) where xx is the record type
Display
one job record 2,job name
some jobs 1,*x where x is the Tab to a job; enter D

first character in
some job names
all jobs (Press Enter) Press Enter to scroll panels

Analyze a job 6,job name
Display, alter or 7,job name
define auto-reply
messages
The Job Directory panel supports the following commands:


Display a record
base D
command at job start DCS
command at job end DCE
criteria DCR
information DIR
message DMR
node DNR
reason code DRC
resource DRR
Alter a record
base A
command at job start ACS
command at job end ACE
criteria ACR
information AIR
message AMR
node ANR
reason code ARC
resource ARR
record as the model
base C
command at job start CCS
command at job end CCE
criteria CCR
information CIR
message CMR
node CNR
reason code CRC
resource CRR
Delete a record
all records for a job L
except the history record)
base LBR (see following)
command at job start LCS
command at job end LCE
criteria LCR
history record LHR
information LIR
message LMR
node LNR
reason code LRC
resource LRR


Analyze a job for missing or ANA
illogical records
Notice that C does more than merely create new job records: it allows you
copy them. This method of building new records from existing ones is more
efficient than using the PROTOTYPE fields. The copy feature is illustrated in
the topic Copying Jobs.
Notice that deleting the base record will remove the job from the Directory
panel. Other job records associated with this record, however, will not be
deleted along with it. When you delete a base record, it is your responsibility
to either replace the base record or delete its associated records using the batch
utility.

Chapter 4. Online Monitoring
Once the Unicenter CA-Scheduler database is defined and Unicenter

CA-Scheduler is automatically selecting schedules and jobs through the
autoscan process, you then use the Online Monitoring component to control
the daily workload and monitor its progress by performing the following
functions:
■ Controlling schedules and jobs using control commands
■ Displaying status on Unicenter CA-Scheduler-controlled schedules and
jobs, listing jobs that have been submitted, jobs that are late, abended jobs,
and so forth.
■ Displaying other information such as
Date and autoscan information
Data set mask names defined in the CAIJ$DSN macros
Network information
■ Posting and unposting predecessors
■ Sending messages to other users and displaying messages sent by other
users
■ Displaying values of global parameters and resetting values
■ Setting predecessor conditions manually
This chapter focuses on how you use Unicenter CA-Scheduler to monitor the
status of the daily work flow and how to use control commands to control
daily production.
Chapter 4. Online Monitoring 4-1

4.1 Online Monitoring Panel

You start monitoring and controlling your production environment at the
Online Monitoring panel. To display that panel, start at Unicenter
CA-Scheduler's main menu and tab to ONLINE MONITORING:

===> MASTER - WR
CONNECT : 4

==> POWER INTERFACE
==> JOB MAINTENANCE
PF1=HELP

Online Monitoring is one of the functions listed on Unicenter CA-Scheduler's
main menu. To make that selection, tab to the second selection and press
Enter.
SCHD-OM ONLINE MONITORING CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
Enter no. of selected command, followed by comma and additional parameters.
MISCELLANEOUS COMMANDS
1 ONLINE STATUS 4 POST DEPENDENCY 7 DISPLAY
2 QUERY MESSAGES 5 UNPOST DEPENDENCY
3 SEND MESSAGE 6 SET/DISP GLOBALS
SCHEDULE COMMANDS JOB COMMANDS

2 RUN 3 CANCEL/POST 4 RUN 5 CANCEL/POST
21 REQUEST 31 TALTER 41 REQUEST 51 TALTER
22 RELEASE 32 SREQ 42 RELEASE 52 SREQ
23 HOLD 33 FORCE 43 HOLD 53 FORCE
24 CANCEL 34 PURGE 44 CANCEL 54 PURGE
45 SUBMIT 55 START
46 ADD 56 COMPLETE
47 RESTAGE 57 RERUN
PF1=HELP


The following table describes what you can do with the various fields on this
panel.
By Selecting You Can

ONLINE STATUS Display schedule status at the stations
you are authorized to connect to.
QUERY MESSAGES Display messages that have been sent to
your userid.
SEND MESSAGE Cause a message to be sent to other
userids.
POST DEPENDENCY Satisfy a predecessor condition so that a
waiting job or schedule can be
processed.
UNPOST DEPENDENCY Inhibit a predecessor condition so that a
waiting job or schedule cannot be
processed.
SET/DISP GLOBALS Display global parameters or cause
predecessor conditions to be satisfied by
supplying a value for GBLxnn.
DISPLAY Display a variety of information
including:
■ Date and autoscan information
■ Data set mask names (CAIJ$DSN
macros)
■ Network information
JOB COMMANDS Control jobs by issuing control
commands.
SCHEDULE COMMANDS Control schedules by issuing control
commands.
For example, you can send messages, post predecessors, and set global
parameters without leaving the Online Monitoring panel. All of these facilities
are described in detail later in this chapter.
To enter a command, you must enter the number that appears next to it on the
command line (===>). You may enter optional keywords by separating them
from the number and from each other with commas. This method of issuing
commands differs from what you have seen elsewhere in Unicenter
CA-Scheduler and is discussed in detail (including examples) in the topics that
follow.

This chapter does not cover control commands in detail. For more information,
refer to the chapter "Controlling Schedules and Jobs" in the Unicenter
CA-Scheduler Reference Guide Part 1.

4.2 Displaying Status

You will probably be performing this function many times. Throughout the
day, you will be reviewing the current status of schedules and jobs. The panel
that controls this process is entered from the Online Monitoring panel but can
also be entered directly from the Main Menu's first selection (ONLINE
SCHEDULE STATUS). To display the Online Status panel from the Online
Monitoring panel, enter 1 on the command line.
The following depicts the Online Status panel that is displayed.
SCHD-OS ONLINE STATUS CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
OPT PARM=> S=SNAME,J=JNAME,ST=NN,OR=P,D=S|T|H,SYS=SYSID,RO=NODE,FM=NODE

ACTIVE =>
INACTIVE =>
SUBMITTED =>
STARTED =>
COMPLETED =>
LATE =>
WAIT-ANY =>
WAIT, AND REASON =>
WAIT-PREDECESSOR =>
WAIT-RESOURCE =>
WAIT-START TIME =>
HELD =>
HELD, AND WHEN =>
ABENDED =>
CANCELLED =>
FAILED =>
INTERRUPTED =>
RUN IF REQUESTED =>
ALL => PF1-HELP

As soon as the database is scanned and jobs and schedules are selected
through the autoscan process, Unicenter CA-Scheduler starts schedules and
submits jobs that are available for processing. This starts a new daily process
that you can monitor. The day's workload consists of all the new jobs selected
that day as well as any backlogged work from prior days. Each schedule and
job is placed into a Unicenter CA-Scheduler queue.
4.2.1 Displaying a Specific Queue

Schedules and jobs are available for processing when:
■ Their early start time is reached, and
■ All predecessor conditions are satisfied, and
■ Resources defined on a job resource record are available, and
■ They are in the active queue

Schedules and jobs that are available as soon as autoscan is complete are
usually those without defined start times, predecessors, or resources. All
schedules and jobs go into one of these primary queues:
■ The active queue contains schedules and jobs waiting until they are
available for processing. They remain in the active queue during and after
processing.
■ The inactive queue contains schedules and jobs that were selected because
of REQUESTED or that are successors to jobs or schedules that were
selected for the reason REQUESTED, as well as jobs that have been held or
canceled. See the topic On-Request Schedules and Jobs in the chapter
"Techniques". REQUESTED schedules and jobs can be activated by the
REQUEST or SREQ commands.
All Unicenter CA-Scheduler's queues are listed on the Online Status panel. To
display all the schedules and jobs in a queue, place your cursor next to the
queue you want to display and press Enter.
Unicenter CA-Scheduler gives you several methods of tailoring status displays

to your specific needs. You can display:
■ Different kinds of data (full status descriptions, actual versus expected end
times, past histories of job execution)
■ For certain groups of schedules or jobs
■ Sequenced alphabetically or in order of execution priority
We recommend that you try limiting your displays to:

■ Specific schedules or jobs
■ A station
■ A SYSID
■ Schedules or jobs beginning or ending with a certain character string
■ A specific node in your network of data centers
or any combination of these. Limiting the display by specifying schedule name

or job name decreases response time in all cases except where a mask character
is used in the first character position.
The next topic explains how to tailor status displays to your specific needs.
Before proceeding to that topic, focus first on understanding the different types
of queues you can monitor. The diagram following shows how Unicenter
CA-Scheduler classifies jobs into queues.

Jobs in narrowly defined queues also belong to queues covering broader

categories. For example, all jobs in the INTERRUPTED queue are also in the
STARTED queue. The LATE queue isn't depicted on the diagram preceding
because its members can come from all but one of the other queues; every
category of job except RUN IF REQUESTED can also be late.

The table following briefly explains each queue type.
This Queue Displays Schedules And Jobs That Are

ABENDED CPU jobs that have abended and their abend
code.
ACTIVE Waiting for processing or were already
processed.
ALL All jobs (both active and inactive queues).
CANCELLED Cancelled by the CANCEL control command.
COMPLETED Completed normally.
FAILED CPU jobs that failed and their reason for
failure.
HELD Held and the reason why.
HELD, AND WHEN Held and the status as it existed before it was
held.
INACTIVE Waiting to possibly be activated by the
REQUEST or SREQ command at which point
they will be moved to the active queue. Also
includes held and canceled jobs.
INTERRUPTED Interrupted by the INTERRUPT=YES field.
LATE Late; they missed their deadline date and
time.
RECEIVED Received at remote nodes.
RUN IF REQUESTED Available to be requested.
STARTED Started. CPU jobs are those currently
executing; non-CPU jobs have been started
with the START command or started
automatically because AUTO START=YES.
SUBMIT FAILED Not started because submission failed. A
reason code is given.
SUBMIT IN PROGRESS Currently being submitted.

This Queue Displays Schedules And Jobs That Are

SUBMITTED ■ All CPU jobs that have been submitted to
POWER, but have not started yet as well
as
■ All non-CPU jobs waiting for the START
command.
■ CPU jobs currently being submitted
■ Jobs received at remote nodes
■ UNKNOWN status jobs (were submitted
or were executing when the system
crashed)
WAIT, AND REASON Waiting for any reason (the reason is
displayed).
WAIT-ANY Waiting for any reason such as predecessors
to be satisfied, an early start time to be
reached, or for resources to be available.
WAIT-PREDECESSOR Waiting for predecessors to be satisfied.
WAIT-RESOURCE Waiting for defined resources to be made
available.
WAIT-START TIME Waiting for its associated early start time to
be met.
4.2.2 Displaying Status for Specific Schedules and Jobs

Status displays automatically show the status of all schedules you are
authorized to monitor at all the stations you are authorized to connect to. You
can limit status displays to selected schedules, jobs, stations, and CPUs. The
optional parameters that limit the scope of status displays are shown
following. Use any combination of these parameters to display just those jobs
you are interested in. Type these parameters next to the name of the queue
you want to display and use commas to separate the parameters you have
selected.
To Restrict The Display To Specify Any Combination Of

These
A specific schedule or S=sname
Substitute * or ?s for > following:

all schedules whose names: S=characters-
-start with the same characters or S=-characters
-end with the same characters or S=-characters-
-contain the same characters

To Restrict The Display To Specify Any Combination Of

These
A specific job or J=jname
all jobs whose names: Substitue * or ?s for > following:

J=characters-
-start with the same characters or J=-characters
-end with the same characters or J=-characters-
-contain the same characters
One station you can connect to ST=id
One CPU SYS=sysid
Jobs received from another node FM=nodeid
Status at another node RO=nodeid
For example, you could display just those jobs in the ACCTG schedule that are
running late at station 39. To do that, you would tab down to LATE, enter
S=ACCTG,ST=39
and then press Enter. For more information about * and ?, see the term mask
character in the Glossary.
Note: Limiting the display by specifying schedule name or job name

decreases response time in all cases except where a mask character is
used in the first character position.
4.2.3 Displaying Status in Sequence

Unicenter CA-Scheduler shows queues in alphabetical order, but you can
request them in order of priority. Unicenter CA-Scheduler prioritizes work by
considering several factors, not just the value of the JOB PRIORITY field.
Unicenter CA-Scheduler allows you to determine the priority of schedules and
jobs within the workload using these factors:
■ Predecessors
■ Start times
■ Deadlines
■ Priority fields
Jobs with the same priority (the same values for all four factors) are sorted
alphabetically.
If you want the queue to appear in priority order, type

OR=P next to the queue you want to display. Remember that the priority of a
schedule or job is not based solely on the priority defined for it, but on other
factors.
Some special considerations apply to a multi-CPU environment: the

OR=P
parameter only displays jobs from the CPU at which you are logged on (not
from other CPUs). When running multi-CPUs, if you issue the STATUS
command with
OR=P and
SYS=sysid other than the SYSID of the CPU you are logged on to, the SYSID
will be ignored.
Notice that this display is NOT a completely accurate indication of the

sequence the jobs will run. Many events may delay or accelerate a given job's
start time (DSN close, SET GBLxnn, or FORCE, for example). Therefore, the
SIMEXEC report with the SIMULATE command is the best way to show a run
sequence of jobs.
The next topic contains an example using
OR=P.
4.2.4 Different Types of Displays

Unicenter CA-Scheduler gives you four different formats for displaying
queues. These formats all display jobs grouped by schedule. You request
different formats by specifying different values for the D parameter. Define the
appropriate value next to the queue you want displayed. The chart following
shows which D= values select each queue format. Choose just one of these
formats when displaying a queue.
To Display Specify
Jobs within schedules and their status condition Nothing
Actual start- and end-times versus expected D=T
A history of the execution of jobs within schedules that are D=H
currently being tracked
Statistics summarizing the schedules currently being tracked D=S

If you combine options by separating them with a comma, you can list the
jobs:
■ That are late
■ At station 39
■ Showing actual versus expected start- and end-times
■ In order of job priority
by tabbing down to LATE, typing
ST=39,D=T,OR=P and pressing ENTER. Looking at these different display

formats will clarify the differences in format.
Notice that using OR=P significantly improves response time for all queues
except ACTIVE, ALL, ABENDED, and FAILED.
4.2.4.1 Default Status Display
By not specifying a
D= parameter, you get the default status display. The panel following
illustrates output produced by tabbing to the ACTIVE field on the Online
Status panel and pressing Enter:
SCHD-CP SCHEDULER COMMAND PROCESSOR CA-SCHEDULER

===> MASTER - WR
CONNECT : 4

SCHEDULE JOB NAME JNO ST RC JCNT SYSID S T A T U S
DAILY 84 1 1 ENDED
JDAY1OF2 1 4 1 1 ENDED
JWEK1OF2 1 4 1 1 ENDED
JWEK4OF5 1 4 88 1 OS PURGED
DSNPRED 84 2 1 ENDED
DSNPRED1 1 4 84 1 SUBMITD
DSNPRED2 1 4 84 1 SUBMITD

This display groups jobs by schedule. Both schedules and jobs are listed
alphabetically. The status conditions and their meanings are described later in
this topic.
Although this is called a display panel, you can key in control commands to
control schedules and jobs by entering an abbreviation of the command to the
left of a schedule or job. The topics on Controlling Schedules and Controlling
Jobs fully explain this time-saving feature.

The RC field is unique to this display format; no other D= value displays it.
RC tells you why the schedule or job appears in today's workload. Some of the
numbers listed there relate back to reasons defined on criteria records. RC
codes have the following meanings:
If RC Is This Number
01 - 79 Corresponds to the position of the reason on the criteria
statement that was defined for this job or schedule.
80 Indicates that it was selected because today's date corresponds
to a workday on the calendar that was defined for this job or
schedule.
84 Indicates that it is selected by default every day because no
selection criteria were defined.
88 Indicates that it was added to today's schedule by the RUN
command.
92 Identifies a schedule that is being run because a job abended.
(This schedule was specified in a job's ABEND option as an
alternate schedule in case of abend.)
95 Indicates that this job was added to today's schedule using the
online ADD command.
96 Indicates that this job was a backout job that was submitted
for an abended job that specified ABEND=BACKOUT.
4.2.4.2 Sample Time Status Display
By specifying
D=T, you get the Time Status Display. The panel following illustrates output
that could result from typing just
D=T in the ACTIVE field on the Online Status panel.


===> MASTER - WR
CONNECT : 4

SCHEDULE JOB NAME JNO ST EARLY TIME MUST TIME DEADLINE
AVAIL TIME START TIME END TIME
JWEK3OF3 1 4 9/7 . 9/7 . 9/7 .
9/7 9.33 / . / .
JWEK3OF4 1 4 9/7 . 9/7 . 9/7 .
9/7 9.33 / . / .
JWEK3OF6 1 4 9/7 . 9/7 . 9/7 .
9/7 9.33 / . / .
JWEK4OF5 1 4 9/7 . 9/7 . 9/7 .
9/7 9.33 / . / .
DSNPRED 9/7 . 9/7 . 9/7 .
/ . / . / .
DSNPRED1 1 4 9/7 . 9/7 . 9/7 .
/ . / . / .
DSNPRED2 1 4 9/7 . 9/7 . 9/7 .

Notice that each schedule and job has two lines of data associated with it. The
first line of data (the one that contains the schedule or job name) includes the
date and time of its early start time (EARLY TIME), the time it must start by
(MUST TIME), and the latest time that it is due out (DEADLINE).
The second line of data contains the date and time when it actually became
available (AVAIL TIME), when it actually started (START TIME), and actually
ended (END TIME).
4.2.4.3 Sample History Status Display
By specifying
D=H, you get the History Status Display. The panel following shows output
D=H in the COMPLETED field on the Online Status panel. Average time is
shown in hh.mm format.


===> MASTER - WR
CONNECT : 4

SCHEDULE JOB SYS AVG START END COMP
NAME NAME JNO ST ID TIME TIME TIME S T A T U S CODE
ABCXY 1 .19 16.5 17.3
ABC 1 39 1 . 5 16.5 16.17 ENDED
1 39 1 .5 16.44 16.45 ENDED
1 39 1 .5 16.55 16.58 ENDED
ABC 1 4 1 .7 16.17 16.2 ABENDED 14
1 4 1 .7 16.46 16.5 ABENDED 18
1 4 1 .7 17. 17.2 ENDED
XYZ 1 4 1 .7 16.21 16.3 FAILED 8
1 4 1 .7 16.5 16.54 FAILED 16
1 4 1 .7 17.21 17.3 ENDED

This display also lists jobs within schedules.
The primary difference between this and the default display is that the History
display depicted preceding contains the average run time and the completion
code of the job. The average time of a job is based on its history and you can
use it to immediately determine if something is out of line. The status code
appears, but does not contain the same amount of information as the default
status display.
4.2.4.4 Sample Schedule Summary Status Display
By specifying
D=S, you get the Schedule Summary status display. This panel shows output
D=S in the ACTIVE field on the Online Status panel. Average time is shown
in DD/hh.mm format.

===> MASTER - WR
CONNECT : 4

SCHEDULE S T A R T E N D DEADLINE REMAINING AVERAGE RER
NAME DATE TIME DATE TIME DATE TIME TIME RUN TIME UN
CASCHD1 11/6 11.2 11/6 19.22 11/6 2. 8.12
CASHCD2 11/6 14.48 11/6 15.35 11/6 16.3 .44
CASCHD3 11/6 19.15 11/6 . 11/5 23.15 3.14 3.32 Y

This display just summarizes schedules. Along with the date and time at
which schedules started and finished, you can also see when they were due to
finish.

If the schedule is still waiting to start, the REMAINING TIME field shows the
average run time of the schedule in hours and minutes followed by a '+' to
indicate the amount of time the schedule will probably take to complete. If the
schedule has already started, however, this field is calculated by subtracting
the elapsed time from the average time. A '-' indicates that the schedule has
taken longer than average. The AVERAGE RUN TIME shows the schedule's
average execution time based on Unicenter CA-Scheduler's history data.
Another very important column in this panel is RERUN. It indicates that this
schedule has been carried over as backlog from a previous day and will run
again when this schedule ends.
The panel preceding shows CASCHD3 was supposed to run yesterday (11/5).
That schedule started 18 minutes ago (3.32 - 3.14) and still has over three hours
to run (3.14). The RERUN field indicates that when CASCHD3's jobs from
yesterday are done, CASCHD3 will run again with today's jobs.
4.2.5 Examples
These examples combine various parameters to illustrate some of the options
available with the Online Status panel.
To Display Move The Cursor To And

Type
PAYJ jobs in all WAIT-PREDECESSOR J=PAYJ*
schedules that are
waiting for
predecessors
Start and end times of COMPLETED D=T,ST=40
all jobs run on the
computer
Late jobs in order of LATE OR=P
priority
All jobs in the ALL S=PAYROLL,
PAYROLL schedule ST=40
that run on the
computer
All jobs scheduled at SUBMITTED ST=20,OR=P
the data entry station
that are waiting to be
started in order of
priority

4.2.6 The Meaning of Status

This list of status conditions explains the various stages that jobs and schedules
pass through. Reviewing this information will give you a good understanding
of what is going on within Unicenter CA-Scheduler.
ABENDED The job can be rerun using the RERUN or SUBMIT
command.
AUTO RECVRY HELD
The job or schedule was put on hold as part of automatic
recovery following a system crash. It must be released
using the RELEASE command. mix INTERRUPT field
AUTO STRTED Is a non-CPU job that was defined with the AUTO
START=YES option which means that the job was
automatically started when its early start time was reached,
all of its predecessor conditions were satisfied, and its
defined resources were met. Therefore, you can process
the job without posting START. After processing, use the
COMPLETE command to end the job.
userid CANCLD This job or schedule was canceled by a Unicenter
CA-Scheduler CANCEL command issued by a user whose
authority level allows them to control this schedule or job.
It can be purged from the status display via the PURGE
command or started again using the RUN, SUBMIT, or
RERUN command.
ENDED The job or schedule has ended with this completion code
and can be purged from the status display using the
PURGE command or started again via the RUN, SUBMIT,
or RERUN command. (Formerly COMPLETED status)
FAILED The job can be rerun using the RERUN or SUBMIT
command.
userid HELD The job or schedule was held by a HOLD command issued
by a user whose authority level allows them to control this
schedule or job. It will not be considered for processing
until it is released using the RELEASE command.
INTRPTD This identifies completed jobs defined with
INTERRUPT=YES. The job must be manually ended using
the COMPLETE command or rerun using the RERUN or
SUBMIT command.
NO BACKLOG CNCL
The job was canceled at the end of the day because it
hadn't been submitted or started yet and it was defined as
BACKLOG=NO. You will only see this if at least one
other job in the same schedule is still running or became
backlogged at autoscan. If at least one job is still running

or backlogged, the rest of the schedule cannot be purged.

Therefore, the rest of the jobs that have not started yet are
given this status to indicate that they are not really being
carried over to the next day in backlog; they will be
purged when the schedule ends.
NOT REQUESTED
This job or schedule has been selected and put in an
inactive queue in case it is REQUESTED. It will only be
processed if it is activated by the online REQUEST or
SREQ command.
SHUTDOWN HELD
The SHUTDOWN DELAY command has been issued and
shutdown will start as soon as the jobs currently running
at the CPU come to an end.
STARTED A schedule has been started, a CPU job is executing, or a
non-CPU job has been started using the START command.
For a CPU job, the status display shows the POWER job
number and the partition it is running in.
SUBMIT IN PROGRESS
Unicenter CA-Scheduler is retrieving a job's JCL from the
library where it is stored and submitting it to the operating
system. It cannot be held at this point.

SUBMIT FAILED Unicenter CA-Scheduler tried to submit a job and failed.

You can resubmit the job using the SUBMIT, RERUN, or
FORCE command when the cause of failure is corrected.
A four-character code tells you where the job was
submitted from or how the error was detected and why
the submission failed. The first two characters identify the
source of the error:
Code Source Of Error

04 VSE procedure library
08 ICCF library
0C Unicenter CA-Driver library
10 Unicenter CA-Driver expansion interface
14 SLI library
18 Allfusion CA-Vollie library
1C AllFusion CA-Panvalet library
20 AllFusion CA-Librarian library
24 CMS member
34 Non-standard library (requires user interface)
38 Dummy TESTLIB used during testing
3C Internal to Unicenter CA-Scheduler
40 During staging retrieval
44 During staging add
48 CMS Service Machine
50 CONDOR library
54 JCLMAN library

The last two characters tell you why the submission failed:
Code Reason For Error

04 The member could not be found
10 A file opening failed
18 Support was not generated for this library
1C A READ failed
20 Of an internal CATMAN I/O error
24 Internal to Unicenter CA-Scheduler
28 Job name is invalid
2C Internal to Unicenter CA-Scheduler
34 Class is invalid
3C PRI is invalid
40 SYSID is invalid
44 Unicenter CA-Scheduler ran out of storage
48 POWER communication error - IDENT
4C POWER communication error - CONNECT
50 POWER communication error - SENDR
54 POWER communication error - REQUEST
58 A logic error has occurred
5C Appendage error/CTLSPOOL error
60 An error from the CMS SUBMIT
64 The member is empty (no records)
68 Allfusion CA-Vollie SUBMIT no librarian support
6C Allfusion CA-Vollie INCLUDE not found
70 AllFusion CA-Librarian/CA-Panvalet INCLUDE not found
74 Too many nested INCLUDEs
78 Error on INCLUDE statement
7C LIB link error (bad VCON)
80 The CMS service machine is not logged on
84 The CMS service machine is not receiving

Code Reason For Error

88 Of a CMS service machine access error
8C Of a CMS service machine punch error
90 The CLOSE failed
94 PFIX failed
98 SCHEDULER/DRIVER variable resolution error
9C Of a CMS service machine invalid record length
A0 Of a CMS service machine error unpacking file
A4 JCLMAN member not found or syntax error
A8 Userid not defined to CA-TOP SECRET
SUBMITD The JCL for CPU jobs has been submitted to the operating
system for execution and has not started. The POWER job
number also displays with this status.
UNKNOWN This job was either STARTED or SUBMITD when the system
failed. It was not in a power reader queue when Unicenter
CA-Scheduler started up again; therefore it was assigned this
status. It can be resubmitted by issuing a SUBMIT, RERUN, or
FORCE command. It can also be canceled or posted as
complete.
WAITING FOR CPU JOB
This job will not start at a post-CPU station until it has ended
at the CPU station.
WAITING FOR PRED
The job or schedule has reached its early start time and is
waiting for one or more of its predecessor conditions to be
satisfied. These predecessor conditions include the start or end
of another job or schedule, the close of an output data set or
the satisfaction of a global variable. (You can use WAIT,
AND REASON on the Online Status panel to find out what
this job or schedule is waiting for.) This job or schedule will
not run until all of its predecessor conditions are satisfied
unless it is forced using the FORCE command.
WAITING FOR RESOURCES
The job has reached its early start time and all of its
predecessor conditions have been satisfied. Now it is waiting
for a DASD volume to be mounted, for a data set (SEPARATE
DSNAME), or for jobs from which it is separated to complete
(SEPARATE JOBS). (You can use WAIT, AND REASON on
the Online Status panel to find out what this job is waiting
for.) It will not run until these resources are available unless it
is forced using the FORCE command.

WAITING FOR START TIME

The job or schedule is waiting for its early start time. It will
not be available for processing until then unless it is forced
using the FORCE command.
WAITING NON-CPU START
This is a non-CPU job that was defined as AUTO START=NO.
It is now available and must be manually started using the
online START command.
WAITING PRE-CPU JOB
All of this job's predecessors have been satisfied except the
same job at a pre-CPU station. It will not be submitted at the
CPU station until it has ended at all of the pre-CPU stations in
its path.
WAITING USER SUBMIT
Unicenter CA-Scheduler tried to release the JCL for a job and
failed because the JCL has not yet been manually submitted to
the RDR queue. The job must be manually submitted with
DISP=H specified on the JECL job card. Unicenter
CA-Scheduler will try at regular intervals to release the job.
This status will only be seen for jobs defined with LIBTYPE =
RDRQ.

4.3 Handling Messages

The following subtopics explain how to display messages when they are sent
to you and how you go about sending messages to other users.
4.3.1 Displaying Messages

When MSG PENDING appears on the panel, go to the Online Monitoring
panel and enter 2. This will display system and user messages that have been
sent to your userid. After you display the messages, they are deleted.
Undisplayed messages are deleted at autoscan if they are more than two hours
old (unless the MSGHOLD generation option on the CAIJGEN macro was
changed).
This is a sample display:

===> MASTER - WR
CONNECT : 4

MESSAGE FOR JOB=JOB5 IN SCHEDULE=ARDAILY AT STATION=4
CACM4 JCL IS NOT IN READER QUEUE
PF1=HELP

Messages that have been sent to the Unicenter CA-Scheduler mailbox can be
viewed through the Reporting Facility panel.
Now that you know how to receive messages, you will learn how you can
send them to others.
4.3.2 Sending Messages

To send messages to another userid, go to the Online Monitoring panel and
enter 3, followed by the following two keywords:
User= Name the user who is to receive the message (1- to 8-character
defined userid). To send the message to all defined users, specify
USER=ALL. To send a message to the master console, specify
USER=OPERATOR.
Text= Give the text of the message (no more than 64 characters). Enclose
the message in single quotes if it contains blanks, commas, or other
delimiters.
For example, you could send the following valid message:
3,U=JOHN,T='PLEASE MOUNT THAT TAPE NOW'

If your message refers to a specific job, you can use these optional keywords to
identify it:
Job= Name the job (1-8 characters).
Schedule= Name the schedule (1-8 characters).
STation= Name the station (2-character station id).
JNO= Number of the job (1-2 digit number)
If your message refers to a specific schedule, you can use the SCHEDULE=
keyword to identify it.
If you want your message routed to another node, use this keyword:
ROute= Give the nodeid.
To assign a number to your message, specify MNO=nnn where nnn is a

number from 800 to 899.
If you need more room to type keywords, end the line with a comma. When
you press Enter, a blank panel will be displayed and you can continue the
command. We recommend that you type a comma after USER=userid and
then press Enter which brings up a continuation panel that leaves you more
room for specifying TEXT= and any optional keywords.

4.4 Handling Predecessor Conditions

This topic tells you how to post and unpost predecessors.
4.4.1 Posting Predecessors

The MASTER userid or a userid with Manager authority can post a
predecessor condition as satisfied so that a waiting schedule or job can be
processed. Notice that posting a predecessor satisfies all successors that are
waiting for it. If you only want to release one successor, use ONLYJOB,
ONLYST, ONLYJNO or ONLYSCD keywords.
To post a predecessor condition, go to the Online Monitoring panel and enter

one of the following:
Enter If The Predecessor You Are Satisfying Is The

4,DSN N=dsname Close of a data set
Start of a
4,SSCD N=sname -schedule
4,SJOB N=jname -job
End of a
4,SCD N=sname -schedule
4,JOB N=jname -job
4,VSE N=jname -nonscheduled DOS job
Type the name of a data set, schedule or job following the predecessor
keywords listed in the chart preceding. If the predecessor is a job, also give the
schedule name, job number, and station number. If you cannot fit all of the
information on the panel, end with a comma. This will give you a continuation
panel. Once you have satisfied a predecessor condition by posting it
manually, Unicenter CA-Scheduler reacts as if the event actually occurred.
This affects Unicenter CA-Scheduler totally, so the impact is not limited to just
today's workload or just this CPU. See the description of the POST command
in the Unicenter CA-Scheduler Reference Guide Part 1.
4.4.2 Unposting Predecessors

The MASTER userid or a userid with Manager authority can unpost a
predecessor condition so that a waiting schedule or job cannot be processed.
Notice that unposting a predecessor inhibits all successors that are waiting for
it. If you only want to inhibit one successor, use the ONLYJOB, ONLYST,
ONLYJNO, or ONLYSCD keywords.

To unpost a predecessor condition, go to the Online Monitoring panel and

enter one of the following:
Enter If The Predecessor You Are Unposting Is The

5,DSN N=dsname Close of a data set
Start of a
5,SSCD N=sname -schedule
5,SJOB N=jname -job
End of a
-5,SCD N=sname -schedule
-5,JOB N=jname -job
-5,VSE N=jname -nonscheduled DOS job
Type the name of a data set, schedule or job following the predecessor
keywords listed in the chart preceding. If the predecessor is a job, also give the
schedule name, job number, and station number. If you cannot fit all of the
information on the panel, end with a comma. This will give you a continuation
panel. Once you have unposted a predecessor condition manually, Unicenter
CA-Scheduler reacts as if the event never occurred. This affects Unicenter
CA-Scheduler totally, so the impact is not limited to just today's workload or
just this CPU. See the description of the UNPOST command in the Unicenter

4.5 Handling Global Parameters

This topic describes how you display and set global parameters.
4.5.1 Displaying Global Parameters

To display global parameters, go to the Online Monitoring panel and enter
6,D. The following panel is displayed:

===> MASTER - WR
CONNECT : 4

GBLA1
GBLA5
GBLA9
GBLA13
GBLB1 NO NO YES NO
GBLB5 NO NO NO NO
GBLB9 NO NO NO NO
GBLB13 NO NO NO NO
GBLC1
GBLC5
GBLC9
GBLC13

Each row on this panel defines the values of up to four global parameters. The
column on the left identifies the first global parameter defined in each row. To
check the value of GBLB03, look in the row that starts with GBLB01. The third
value in that row (YES) corresponds to GBLB03.
Any defined global parameter can be included on a criteria statement as a

predecessor condition that must be satisfied before the job or schedule can run.

4.5.2 Setting Global Parameters

Global parameters can be defined as predecessor conditions that must be
satisfied before a schedule or job can be processed. These predecessors are
specified on the Criteria Definition panels or by using the CRITERIA keyword
in this format:
GBLxnn=value
These predecessors are satisfied when a global parameter with the same values
for x and nn is set to the value defined preceding. To set the value of a global
parameter, go to the Online Monitoring panel and enter:
6,GBLxnn=value
Where Is
x A if the value is a number from 1 to 99999999
B if the value is Y or N
C if the value is up to 8 alphanumeric characters
nn A number from 1 to 16 that matches the number on the
criteria statement
Once GBLxnn is set to a value that satisfies the predecessor conditions of

schedules and jobs, Unicenter CA-Scheduler cannot be "dissatisfied." Resetting
GBLxnn will not change the fact that these predecessor conditions have
already been satisfied.
When the nature of your work flow requires manual control, use GBLxnn
variables in the criteria statements of the schedules and jobs that require that
type of manual control.

4.6 Displaying Date and Autoscan Information
4.6 Displaying Date and Autoscan Information

To display the current system date and time as well as autoscan information,
go to the Online Monitoring panel and enter 7,DATE. The following panel is
displayed:

===> MASTER - WR
CONNECT : 4

CACM54I LAST AUTOSCAN: JUL=9599 GREG=4/9/95 TIME=11.9.2 AUTOMATIC
CACM54I FOR DATE: JUL=9599 GREG=4/9/95 TIME=1..
CACM54I NEXT AUTOSCAN: JUL=951 GREG=4/1/95 TIME=1.. AUTOMATIC
CACM54I FOR DATE: JUL=951 GREG=4/1/95 TIME=1..
CACM54I TODAY'S DATE: JUL=9599 GREG=4/9/95 TIME=2.16.44
END OF DATA
PF1=HELP

It is a good idea to view this display after you temporarily change the next
autoscan time using the AUTOSCAN command with the TIME keyword to
ensure that the changed time is correct. The display shows whether last
autoscan was MANUAL, TEMPORARY, or AUTOMATIC and whether the
next autoscan will be TEMPORARY or AUTOMATIC.

4.7 Displaying Data Set Mask Names
4.7 Displaying Data Set Mask Names

To display the data set mask table and the node names that will be informed
when those data sets are closed, go to the Online Monitoring panel and enter
7,$DSN. The following panel is displayed:

===> MASTER - WR
CONNECT : 4
MILTON

CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I


4.8 Displaying Network Information
4.8 Displaying Network Information

To display the status of each node in a multi-node network, go to the Online
Monitoring panel and enter 7,NET. The following panel is displayed:

===> MASTER - WR
CONNECT : 4

CACM54I NAME SYSID TYPE APPLID ZONE S T A T U S STACK-USAGE
CACM54I USGDNCMD XAD1 JES2 A1SS1 UNCONNECTED K
CACM54I USG22ME 3 VSE A2SS1 UNCONNECTED K
CACM54I USG32ME 1 VSE A2SS1 UNCONNECTED K
CACM54I USG23ME 1 VSE A3SS1 1- LOCAL-NODE
CACM54I USG23ME 2 VSE A3SS2 1- UNCONNECTED K
CACM54I USG24ME XAE1 JES2 A4SS1 UNCONNECTED K
CACM54I USG312ME XAE3 JES3 A12SS1 ERROR
END OF DATA
PF1=HELP

You should keep an eye on the STACK-USAGE value for a connected node.
This is the number of requests (and the amount of private storage those
requests occupy) that the local node is attempting to send to this node. If those
numbers move up and do not move down, it could indicate a slow down in
VTAM communications between the local node and this node and possibly a
lost VTAM connection. Unicenter CA-Scheduler will send a warning message
to the operator console when the amount of storage used to hold the stacked
requests reaches the threshold defined in the VTAMLIM option of the
CAIJNET macro. In this case you should use the Unicenter CA-Scheduler or
VTAM VARY INACTIVE command to disconnect communication with this
node. Unicenter CA-Scheduler will then save any stacked requests for this
node on the tracking file. When the VTAM problem is resolved, use the
Unicenter CA-Scheduler VARY ACTIVE command to reestablish
communication with this node. Unicenter CA-Scheduler will then resend any
requests that were saved for this node.

4.9 Controlling Schedules

You can control schedules for which you are authorized. To control schedules
issue one of these online commands:
CANCEL FORCE HOLD PURGE RELEASE
REQUEST RUN SREQ TALTER CP
To enter a command, you must enter the number that appears next to it on the
command line (===>). You may enter keywords by separating them from the
number and from each other with commas. The chart following explains what
these commands do.
To Enter Which Stands For

Add a schedule to the active queue that has:
-not been selected today

20 RUN
-been INACTIVE along with all its
successors 21 REQUEST
-been INACTIVE and leave in the inactive

queue any successors that are also 32 SREQ
REQUESTED or that have other INACTIVE
predecessors that were also REQUESTED
Hold a schedule that is waiting or started 23 HOLD
Release the hold on a schedule 22 RELEASE
Cancel a schedule at any point before 24 CANCEL
completion
Cancel a schedule and post its successors as 30 CANCEL/POST
if the schedule completed successfully.
Rerun canceled or completed schedules. 20 RUN
Delete canceled or completed schedules 34 PURGE
Temporarily change values defined for an 31 TALTER
active schedule for this execution only
Force a schedule to start, even though it is 33 FORCE
waiting for its early start time to be reached
or for predecessor conditions to be satisfied
When issuing commands from the Online Monitoring panel, you can use any
of the keywords listed under the command name in the chapter "Controlling
Schedules and Jobs" in the Uniicenter CA-Scheduler Reference Guide Part 1. To
enter a keyword, enter the number of the command followed by a comma and

then the keyword. If you enter multiple keywords, separate them with
commas. For example, you could enter the following valid TALTER command:
31,NAME=TESTSCHD,DEADLINE=15
If you run out of room to enter keywords, follow a keyword=value
combination with a comma and press Enter . Another panel will be displayed
that allows you to continue the command.
You can issue certain control commands that pertain to schedules directly from
any of the status displays (SCHEDULER Command Processor panel). All you
have to do is position your cursor to the left of the schedule and type an
abbreviation of the command you want to issue. These abbreviations are
shown following:
Enter To Issue This Command

REQU REQUEST SCHEDULE
SREQ SREQ SCHEDULE
HOLD HOLD SCHEDULE
RELE RELEASE SCHEDULE
CANC CANCEL SCHEDULE
CP CANCEL/POST SCHEDULE
PURG PURGE SCHEDULE
FORC FORCE SCHEDULE
RUN RUN SCHEDULE
Optional keywords are not allowed if you use the preceding command
abbreviations. If you need to use optional keywords, issue the command
through the Online Monitoring panel.

4.10 Controlling Jobs

You can control jobs that are part of schedules at stations for which you are
authorized. To control jobs, issue one of these online commands:
ADD CANCEL COMPLETE FORCE HOLD PURGE
RELEASE REQUEST RERUN RESTAGE RUN SREQ
START SUBMIT TALTER CP
To enter a command, enter the number that appears next to it on the
number and from each other with commas. The chart following explains what
these commands do.

Add jobs to the active queue that:
-are not in the database 46 ADD
-are in the database but have not been 40 RUN

selected today
-have been INACTIVE, and add all their 41 REQUEST

successors
-have been INACTIVE, and add any 52 SREQ

successors that do not have REQUESTED in
their criteria and that do not have any other
INACTIVE predecessors that were also
REQUESTED
Submit jobs
-that are waiting or SUBMIT FAILED 53 FORCE
-regardless of their current status 45 SUBMIT
Rerun jobs that are
-canceled or completed 40 RUN
-abended, failed, or interrupted 57 RERUN
Post
Start to CPU and non-CPU jobs 55 START
End to INTRPTD jobs or complete non-CPU 56 COMPLETE
and CPU jobs
Hold a job 43 HOLD
Release the hold on a job 42 RELEASE
Cancel a job 44 CANCEL
Cancel a job and post its successors as if the 50 CANCEL/POST
job completed successfully


Delete canceled or completed jobs 54 PURGE
Temporarily change the values defined for an 51 TALTER
active job for this execution only
Write a fresh copy of the JCL to the staging 47 RESTAGE
library
When issuing commands from the Online Monitoring panel, you can specify
the schedule name (S=SNAME), the job number (JN=JNO), and the station number
(ST=NN), as well as any of the keywords listed under the command name in the
chapter "Controlling Schedules and Jobs" in the Unicenter CA-Scheduler
The following defaults are taken if you do not enter these keywords:
JN=jno Defaults to JN=01
ST=nn Defaults to the connect station (the connect station appears in

the upper right-hand corner of the panel)
To enter a keyword, enter the number of the command followed by a comma

and then the keyword. If you enter multiple keywords, separate them with
commas. For example, you could enter the following valid TALTER command:
51,TESTJOB,SCHEDULE=TESTSCHD,ABEND=BACKOUT
If you run out of room to enter keywords, follow a keyword=value
combination with a comma and press Enter . Another panel will be displayed
that allows you to continue the command.
You can issue certain control commands that pertain to jobs directly from any
of the status displays (SCHEDULER Command Processor panel). All you have
to do is position your cursor to the left of the job and type an abbreviation of
the command you want to issue. These abbreviations are shown following:

RER RERUN JOB
REQU REQUEST JOB
SREQ SREQ JOB
FORC FORCE JOB
STAR START JOB
COMP COMPLETE JOB
HOLD HOLD JOB


RELE RELEASE JOB
CANC CANCEL JOB
CP CANCEL/POST JOB
PURG PURGE JOB
REST RESTART JOB
RUN RUN JOB
SUB SUBMIT JOB
Optional keywords are not allowed if you use the preceding command
abbreviations. If you need to use optional keywords, issue the command
through the Online Monitoring panel.
4.10.1 Running Jobs With The ADD Command

ADD allows you to run a single execution of a job today whether it is defined
to the database. You can use this command to add a job to today's workload
if the job:
■ Is not in the database
■ Is in the database with different keyword values
and if you only want to run the job on a "one-time" basis.
An ADDed job will only exist on the tracking file for one day (unless it
becomes backlogged); the only trace or record of it in the database will be
history records.
If you are in doubt as to whether the job being added will ever need to be run
again, we recommend that you define the job to the database and define a
non-auto-selected schedule for it. Then you can issue a RUN command for the
schedule whenever you need this job.

To select this option from the Online Monitoring panel, enter 46. For example,
to add a job called JOBC, you would enter the following command in the
command area of the Online Monitoring panel:
46,NAME=JOBC
Unicenter CA-Scheduler responds by displaying the Dynamic ADD panel:
SCHD-DAD DYNAMIC ADD CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
JOB NAME : JOBC

JOB NUMBER : 1
STATION ID : 4
SCHEDULE NAME : JOB PRIORTY : 5
STAGE JCL : NO AUTO START : NO

LIBRARY TYPE : DRIVER MBR SUBID : MEMBER PASSWORD:
MEMBER NAME : SLI SUBLIB : ICCF LIB NUMBER:
POWER PRIORITY: 9 POWER USER :
RECOVERABLE : NO ABEND : FAIL CODE :
BACKLOG : YES
MUST START BY TIME :
COMPLETION DEADLINE TIME :
MAXIMUM EXECUTION TIME :
PF1=HELP

This panel closely resembles the Job Definition panel discussed in the chapter
"Maintaining the Database." Some fields are already filled in If you do not
specify a schedule name, that field defaults to $DYNxxxx where xxxx is the
POWER SYSID of this CPU. This schedule is dynamically created and added to
the workload for you.
After you key in values appropriate to this job, press Enter to display the next
Dynamic ADD panel. Enter any predecessors or successors that you want to
specify on this panel. Specify any predecessors (jobname, job number, station,
and schedule) in the PREDECESSOR JOBS fields. Specify any successors
(jobname, job number, station, and schedule) in the SUCCESSOR JOBS fields.
For example, if you are adding JOBC to today's schedule and want it to run
when JOBA completes successfully, specify JOBA's information in the
PREDECESSOR JOBS fields as shown following.
If you want to specify that JOB1 and JOB2 should run once JOBC has
completed successfully, specify JOB1 and JOB2 information in the SUCCESSOR
JOBS fields as shown following.

SCHD-DADP DYNAMIC ADD CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
PREDECESSOR JOBS:
JOBNAME LIST: JOBA

JOB NUMBER LIST: 3
JOB STATION LIST:
JOB SCHEDULE LIST: SCHD1
SUCCESSOR JOBS:
JOBNAME LIST: JOB1,JOB2

JOB NUMBER LIST: 4,5
JOB STATION LIST:
JOB SCHEDULE LIST: SCHD1,SCHD1
PF1=HELP

When you are done, press Enter to add the job to today's schedule.

4.11 Summing Up
4.11 Summing Up
The Online Monitoring panel is the starting point for monitoring and
controlling daily production.
To issue a command, you must enter the number that appears next to it on the
number and from each other with commas.
The Online Status panel allows you to monitor any queue, selecting just the
portion that interests you. Queues are explained in the topic Displaying Status.
Use the following parameters to tailor the queue display to your needs and
separate parameters with a comma.
To Specify
Select a specific
-schedule or job S=sname or J=jname
-station ST=id
-CPU SYS=sysid
Select a group of schedules or jobs Use * or ?s where > occurs following:
-starting with the same letters S=characters> or J=characters>
-ending with the same letters S=>characters or J=>characters
-containing the same letters S=>characters> or J=>characters>
Just display jobs received from FM=nodeid
another node
Display status at another node RO=nodeid
Display specific data
-history data or D=H
-actual vs. expected times or D=T
-schedule summary or D=S
-reason codes omit D parameter
In a certain order (jobs grouped by
schedule)
-alphabetical order or omit OR= parameter
-job priority order OR=P
For more information about * and ?, see the term mask character in the
Glossary.
Use the following keywords to send messages from the Online Monitoring
panel. Enter these keywords after entering 3, and separate them with commas.
(The U and T keywords are required.)

4.11 Summing Up
To Specify Abbreviation
Identify
-who the message goes to USER=ALL or U=
USER=OPERATOR or
USER=userid
-what your message refers to JOB=jname J=

SCHEDULE=sname S=
STATION=id ST=
JNO=jno JN
Define the text of the message TEXT='text' T
Route your message to ROUTE=nodeid RO=
another node
People with Manager authority can post and unpost predecessor conditions.
That is done by entering the following values in the Online Monitoring panel.
To Post, To Followed by If the Predecessor You Are

Enter Unpost, Satisfying Is The
Enter
4, 5, DSN N=dsname Close of a data set
Start of a
4, 5, SSCD N=sname -schedule
4, 5, SJOB N=jname -job
4, 5, End of a
4, 5, SCD N=sname -schedule
4, 5, JOB N=jname -job
VSE N=jname -nonscheduled DOS job
To display the current values of all global parameters, go to the Online

Monitoring panel and enter 6,D. To set a value, enter 6,GBLxnn=value. To set
a value, you must have Manager authority.
To display the following information, go to the Online Monitoring panel and

enter the values displayed following:
To Display Enter
The data set name masks defined in the CAIJ$DSN table 7,$DSN
The autoscan information, and the current system date and 7,DATE
time

4.11 Summing Up
To Display Enter
The network information from the CAIJNET table in an NJE 7,NET
environment
This Affects Jobs/ This way

Command Schedules
ADD J Adds jobs that are not in the database to
the workload.
CANCEL S,J Cancels a job or schedule at any point
before completion.
COMPLETE J Ends interrupted jobs and completes all
other jobs.
CP S,J Cancels a job or schedule and posts its
successors as if the job or schedule had
completed successfully.
FORCE S,J -Forces schedules that are waiting to
start.
-Submits JCL for jobs that are waiting or
SUBMIT FAILED.
HOLD S,J Holds work that is waiting or started.
PURGE S,J Deletes canceled or completed work from
the status display.
RELEASE S,J Releases held schedules and jobs.
REQUEST S,J Moves requested jobs or schedules and
their successors to the active queue.
RERUN J Reruns abended, failed or interrupted
jobs.
RESTAGE J Writes a fresh copy of a job's JCL to the
staging library.
RUN S,J -Adds work that was not selected to the
workload.
-Reruns canceled or completed work.
SREQ S,J Moves a schedule or job to the active
queue as well as any of its successors
that are not REQUESTED and that do
not have other INACTIVE predecessors
that were also REQUESTED.
START J Posts START status for non-CPU jobs.
SUBMIT J Submits a job's JCL for execution.

4.11 Summing Up
This Affects Jobs/ This way

Command Schedules
TALTER S,J Temporarily changes values defined in
the database for just this execution.
Before using any of these commands, refer to the chapter "Controlling

Schedules and Jobs" in the Unicenter CA-Scheduler Reference Guide Part 1 for
complete command descriptions.

Chapter 5. Criteria Language
The criteria language consists of a criteria vocabulary and a set of calendar

mechanisms used to construct a reason, or set of reasons, for selecting a
schedule or job for execution and for establishing its predecessors.
For example, if SCHEDA is to run every Monday and every Thursday, the
selection criteria associated with this schedule is MON OR THU.
This example uses criteria vocabulary that refers to a processing period when
selecting a schedule. Several different types of processing periods can be used:
■ Day of week (as preceding)
■ Week of month
■ Day in cycle
■ Week in cycle
■ Workday
■ Relative day
■ Accounting day of month
■ Holiday
■ Negative day of month (nn day from the end of a period)
Another condition that can cause selection of a schedule or job would be

another schedule or job being selected. For example, to select JOBB if JOBA
was selected, the criteria associated with JOBB is JOBA.
Previously, using the criteria vocabulary to select schedules or jobs was

discussed, but the criteria vocabulary is also used for defining predecessors.
Predecessors are conditions that have to be met before a schedule or job is
allowed to start. Other terms used for predecessor are prerequisite and
dependency.
Predecessors can be the starting or ending of other schedules or jobs, the

closing of an output data set, a nonscheduled VSE job, and other items like
these. Any predecessor can be defined as occurring on the day the schedule or
job is selected or as having occurred on a prior day. This will be discussed in
more detail later through the use of examples.
Chapter 5. Criteria Language 5-1

The criteria language uses three types of yearly calendar mechanisms:
Absolute Gregorian Calendar
Defines specific keywords that have absolute dates
associated with them. For example, the DAILY keyword
causes a job to be selected every day including weekends
and holidays; WEEK-DAY causes selection on Monday
through Friday including holidays; and so forth. This
mechanism is determined by the system and you do not
have to define anything; only use the keywords.
Datetables Defines workdays, holidays, accounting days, and
accounting periods. This is the most flexible calendar
mechanism to use and is the one recommended. It also
provides the easiest transition at year end.
Calendars Define daily, weekly, and monthly calendars to select
schedules and jobs. When using calendars, only the
calendar name determines selection. For example, you
cannot also select based on a criteria statement: with
calendars, criteria statements only define predecessors.
To use this mechanism, you must define several different
calendars.
The following topics explain the criteria vocabulary and calendar mechanisms.

5.1 Criteria Vocabulary

The criteria vocabulary consists of a set of reserved words broken into the
following categories:
■ Boolean expressions
■ Selection of schedules and jobs
■ Predecessor conditions on schedules and jobs
The following discusses these categories in more detail and contains some
examples.
5.1.1 Reserved Words for Use in Boolean Expressions

OR and AND expressions are used with selection and predecessor keywords.
The NOT expression is used with selection keywords only. Parentheses can be
used to logically group these expressions.
The examples following show how these reserved words can be used to handle
real scheduling situations.
5.1.2 Reserved Words Used for Selection

The following discusses reserved words that cause schedules and jobs to be
selected on a given day.
Gregorian Calendar keywords include such words as DAILY, WEEK-DAY,

WEEK-END, SUN, MON, JAN, DEC, 1ST, 31ST, and so forth.
Workday keywords include such words as WDAY, HDAY, WDOW1,

WDOW7, WDOW-1, WDOM1, HDAY1, HDAY31, HDAY-1, RD01=+nn,
RD31=-nn, and so forth.
Accounting period keywords include such words as xDAY, xDOM1, xDOM40,

xDOM-1, xMOY1, xWOF1, and so forth, where x is a one-character prefix that
you define when you set up a datetable. Datetables are discussed in more
detail later in this chapter.
A schedule or job can be used to determine selection. When it is used, it

automatically becomes a predecessor as well. Although the schedule or job
name itself causes selection to occur, there are a couple of reserved words that
can be used with them. One of these keywords is SCD, which identifies the
next name as being a schedule name. Otherwise, it is always assumed to be a
job name.
The other keyword is START. Although the schedule or job name causes
selection, START means that the predecessor is the starting of the schedule or

job. Normally, the predecessor is the completion. This subject is covered in

much more detail later in this chapter.
The following examples demonstrate the use of selection reserved words. Each
of these examples is called a condition.
Example Interpretation During Selection

DAILY Daily
MON Monday
WDAY Every workday
HDAY Every non-workday, meaning holidays
and possibly weekends. HDAY can also
be expressed as NOT WDAY.
JOB1 Every day JOB1 is selected.
MON AND JOB1 Every Monday as long as JOB1 is also
selected.
MON AND START JOB1 This is the same as the prior one. That
is, every Monday as long as JOB1 is also
selected.
MON AND NOT HDAY Every Monday as long as it is not a
holiday.
WDOW1 First workday of any week.
WED AND SCD SCHD1 Every Wednesday as long as the
schedule SCHD1 is also selected.
WDOM-1 OR JOB1 Last workday of the month or as long as
JOB1 is selected.
WDOW2 OR NOT JOB1 Second workday of the week whether
JOB1 is selected. Also selected anytime
JOB1 is not selected.
7TH The seventh day of every month.
RD15= +01 First workday following the fifteenth of
every month.
MAR AND RD14= -01 First workday preceding the fourteenth
of March.
Note: When using relative dating in the criteria record, the relative date must
be in parentheses or a syntax error will occur. For example,
(RDxx=+yy)

5.1.3 Reserved Words for Use in Predecessors

This topic discusses reserved words that are used to define predecessor
conditions. These reserved words ensure predecessor conditions are upheld,
but do not cause any form of selection.
PRED Or PRED SCD indicates the predecessor job or schedule must

complete, probably on a prior day. That is, the predecessor must
complete some time since the job or schedule last ran. If the PRED
schedule or job is also in today's workload, it will always wait for
today's PRED.
NJE Indicates the predecessor job runs on another node. NJE can be
prefixed with START indicating that this job will not start until the
NJE job that is the predecessor also starts. It can also be prefixed
with PRED indicating the predecessor was an NJE job that ran on a
prior day.
DOS Indicates the predecessor job is a nonscheduled VSE job. DOS can
be prefixed with PRED indicating it was run on a prior day.
DSN Indicates the predecessor is the close of an output data set. DSN can
be prefixed with PRED indicating the output data set was closed on
a prior day.
GDG Indicates the predecessor is the close of an output generation data
group. GDG can be prefixed with PRED indicating the output
generation data group was closed on a prior day.
GBLxnn Indicates a user-defined event must be satisfied. These
predecessors are called global parameters and are described in the
topic Commonly Asked Questions in the chapter "Tips."
When predecessors are defined this way, they are called explicit predecessors.
That is, the predecessor name is explicitly stated in the criteria. This particular
type can even be further qualified as a keyword-defined explicit predecessor.
The following examples illustrate the use of predecessor reserved words. Each
of these examples is called a condition.
Example Interpretation Of Predecessors

JOB1 Do not run until after JOB1 completes.
START JOB1 Do not run until after JOB1 starts.
PRED JOB1 Do not run unless JOB1 completed at least once
since the last time the job you are defining
predecessors for ran. If JOB1 happens to be in
today's workload, this job will not run until today's
JOB1 completes regardless of when JOB1 ran
previously.

Example Interpretation Of Predecessors

SCD SCHD1 Do not run until all of the jobs in the schedule
SCHD1 have completed.
DOS TSTJOB1 Do not run until after the nonscheduled VSE job
TSTJOB1 completes. (The job TSTJOB1 is not under
the control of Unicenter CA-Scheduler.)
PRED DSN Do not run until after the output data set
PROD.JOB1DSN PROD.JOB1DSN has been closed at least once since
this job was last run.
5.1.4 Combining Selection and Predecessor Criteria Vocabulary

Previously, selection and predecessor processing have been treated as separate
issues. They really are related, however.
For example, the selection criteria for JOBB is JOBA. That is, JOBB is selected
any time that JOBA is selected. In doing this, JOBA automatically becomes a
predecessor to JOBB. Thus, JOBA is an explicit predecessor to JOBB. That is,
the predecessor name is explicitly stated in the criteria. This particular type
can even be further qualified as a selection-defined explicit predecessor.
Selection-defined explicit predecessors are jobs or schedules used in the

selection criteria. The following is a list of these criteria:
Job name
SCD schedule name
START job name
START SCD schedule name
Some examples that define selection and predecessor criteria for JOBC follow.
Example Interpretation Of Criteria

JOBA Select every time JOBA is selected and
make the successful completion of JOBA
a predecessor of JOBC.
START JOBA Select every time JOBA is selected and
make the start of JOBA a predecessor of
JOBC.
MON AND JOBA Select every time JOBA is selected on a
Monday. JOBC will not start until JOBA
completes successfully.
WED AND START SCD SCHD1 Select every time schedule SCHD1 is
selected on a Wednesday. JOBC will not
start until schedule SCHD1 starts.

Two types of explicit predecessors have been described so far:

keyword-defined and selection-defined.
Implicit predecessors are predecessors that do not have to be defined in the

criteria. When the same schedule/job/job-number exists for more than one
station (01 - 99), the sequential order of the stations defines implicit
predecessors. For example, a CPU job on station 40 will always have an
implicit predecessor of its staging job on station 39, if both are in the day's
workload. Further, implicit predecessors are automatically selected on the
same day that the CPU job (station 40) is selected. You can, however, code
criteria for them to be selected less frequently than the CPU job. Note,
however, that you cannot cause implicit predecessors to be selected on a day
the CPU job is not selected.
Furthermore, implicit predecessors can only exist for CPU jobs and post-CPU
jobs. For example, a CPU job will not be submitted until all its pre-CPU jobs
complete. Likewise, post-CPU jobs will not be started until their CPU jobs have
ended.
5.1.5 Using Multiple Conditions with ANDs and ORs

The examples that have been used so far have contained only one reason. That
is, the condition or combination of conditions, individually caused the reason a
job or schedule was selected.
The way you separate reasons is with an OR outside of a set of parentheses or

with an OR if no parentheses are being used. For example,
MON AND JOB1 OR TUE AND JOB2
is the same as
(MON AND JOB1) OR (TUE AND JOB2)
Use parentheses as a normal convention since it more clearly depicts your

intention. All of our examples will appear with parentheses.
The reason a job is selected stays with the job for its life in the system. In the
example preceding, the value 01 would be the reason if it was selected because
it was (MON AND JOB1). The value 02 would be the reason if it was (TUE
AND JOB2). This value can be referred to as the reason code.
Understanding the relationships between reasons and predecessors is

important. Since the criteria language is used to define both selection and
predecessor conditions, there are rules for interpreting this mixture.
Rule #1 Every Unicenter CA-Scheduler-controlled job or schedule listed in a
criteria statement is a predecessor if it is also in the day's
production. Whether those jobs or schedules are part of the reason
for selection does not matter.

Given the example preceding, no matter what day it is, JOB1 and JOB2 will be
predecessors as long as they are in the day's workload. If it is Monday and
JOB2 happens to be in the workload for Monday, JOBC (the job being defined)
will have to wait for both JOB1 and JOB2 to complete.
Does this mean that Unicenter CA-Scheduler just makes one list of
predecessors for each job? Not at all. Rule #1 just applies to selection-defined
predecessors: jobs and schedules. Unicenter CA-Scheduler observes ORs used
with keyword-defined predecessors.
5.1.6 Affect of NOT Condition on Predecessors

The Boolean NOT expression affects selection just as you might expect:
selection only occurs when something else does not happen that day. For
example, if the criteria for JOBC is:
(MON AND NOT JOB1)
selection will occur only on Mondays when JOB1 is not selected.
How would predecessors be handled in the preceding example? If JOB1 for

some reason ends up in the workload (by a manual override), JOBC will wait
for it if JOB1 was added while JOBC was waiting for its start time to be
reached or other predecessors to be satisfied.
Another example will help reinforce this point. Consider this criteria statement
associated with JOBC:
(MON AND NOT (JOB1 AND JOB2))
This will cause selection to occur only on Mondays when both JOB1 and JOB2
are not selected. If either JOB1 or JOB2 is present, however, it will be a
predecessor of JOBC. This shows that Rule #1 applies even when using NOT
expressions.
The NOT expression is used only for selection purposes within the criteria
language.
5.1.7 Recommended Method for Defining Selection Criteria

Schedules are sets of related jobs grouped together in ways that are easily
understood by your production control area. So if production control thinks of
schedules as units of work, selection criteria would normally be defined at the
schedule level. If all jobs in a schedule run when the schedule is selected,
define when these jobs run once, on the schedule's criteria record which means
you only need to define predecessors at the job level. If a job does not run
every time its schedule runs, define its own individual selection criteria on the
job criteria record. Keep the following rule in mind when coding selection
criteria.

Rule #2 A job will only be evaluated for selection and eligible for today's
workload if its schedule is selected or eligible for today's workload.
For example, if the selection criteria for SCHED1 is MON, and JOB1A in
SCHED1 has a selection criteria of TUES, JOB1A will never get selected. JOB1A
is only looked at if its schedule is selected but SCHED1 is not selected on
Tuesdays, so JOB1A will never be selected.
Rule #3 When coding a job in the criteria language, always qualify it with
its schedule name.
Previously we have not followed the preceding rule for simplicity's sake
because schedule names technically are not required. However, if you omit a
schedule name when referring to a job, Unicenter CA-Scheduler looks in its
database and defaults to the first schedule it finds containing a job by that
name.
To specify a unique job, use this format:

jobname[-jobnumber] [station] [schedule]
Any or all of the three optional parameters (job number, station, and schedule)
may be omitted, but the order in which they are specified is significant. Notice
that the job number must be connected to the job name with a hyphen (-) and
no intervening blanks. For example, this is how to specify JOBA in SCHDA
with a job number of 02 at station 39:
JOBA-2 39 SCHDA
This format can be used with any of the reserved words that are valid for
defining predecessor jobs (PRED, VSE, or START).
If you run simulation, be careful how you use the REQUESTED keyword. To
ensure that simulation reports return reason codes that match those produced
by Unicenter CA-Scheduler on the online status displays (SCHEDULER
Command Processor panel), specify REQUESTED after job and schedule names
in selection criteria whenever possible.
A schedule is eligible for selection even if AUTO SELECT=NO is specified.

5.2 Calendar Mechanisms

Most of the examples presented so far have used explicit vocabulary such as
MON for Monday or WEEK-DAY for Monday through Friday, but this
oversimplifies what happens in real life. For example, we do have holidays.
Your accounting month may not begin on the first of every month. Some
months have four weeks, while others have five. There can be quite a variation
not only between different companies, but even different divisions within a
company.
Unicenter CA-Scheduler addresses all variations using three different calendar

mechanisms:
The Absolute Gregorian Calendar
Defines specific keywords that have absolute dates associated
with them. For example, the DAILY keyword causes a job to
be selected every day including weekends and holidays;
WEEK-DAY causes selection on Monday through Friday
including holidays; and so forth. This mechanism is
determined by the system and you do not have to define
anything; just use the keywords.
Datetables Define workdays, holidays, accounting days, and accounting
periods. This is the most flexible calendar mechanism and is
the one recommended. It also provides the easiest transition at
year end. Each schedule defines which datetable to use for
evaluating when to select that schedule and its associated jobs.
Calendars Define daily, weekly, and monthly calendars for selecting
schedules and jobs. When using calendars, only the calendar
name determines selection. For example, you cannot also
select based on another job being selected. To use this
mechanism, you must define individual calendars. This is the
mechanism to use if all else fails.
5.2.1 Gregorian Calendar

The Gregorian calendar mechanism is the simplest to understand and can be
used immediately. You do not have to define a calendar or datetable first. All
you do is use the reserved words (keywords) when defining your selection
criteria. Most of the preceding examples used keywords from the Gregorian
calendar mechanism.
This mechanism's reserved words that control selection are based on the
standard Gregorian calendar, not workdays or accounting days. Some
examples of these keywords follow:

Keyword When Selected

DAILY Every day including weekends and holidays
WEEK-DAY Monday through Friday
SUN Sunday
FRI Friday
MWF Monday or Wednesday or Friday
TT Tuesday or Thursday
JAN January
1ST First day of the month
SUN1 First Sunday of the month
WED-1 Last Wednesday of the month
2ND-WEEK Second week of the month (first Saturday starts the
first week of the month)
WOY3 Third week of the year
WOY-2 Second-to-the-last week of the year
There are many other keywords that can be found in the appendix "Criteria
Vocablulary" in the Unicenter CA-Scheduler Reference Guide Part 2.
Do not forget that you can also use the Boolean reserved words AND, OR, and
NOT:
Example Always Selected

JAN AND 15TH On January 15
(JAN AND 1ST) OR On the first day of each quarter
(APR AND 1ST) OR
(JUL AND 1ST) OR
(OCT AND 1ST)
DEC AND THU-1 On the last Thursday in December
5.2.2 Datetables
This calendar mechanism is the most flexible of them all and is the one we
recommend you use. It handles holidays (and weekends) as they pertain to
your own environment. When defining the selection for a job or schedule,
datetables are used to answer such questions as:
■ Is today a workday?
■ Is tomorrow a holiday?
■ Is this the fourth workday of the month?

In other words, Unicenter CA-Scheduler is smart enough to know today's date,

but is not smart enough to automatically know your unique workdays,
holidays, and accounting periods.
With datetables, you can use the reserved words described for Gregorian
calendars, but you must define your holidays. This is done with a full panel
that actually displays a calendar one month at a time. You can use two types
of keywords with datetables: workday keywords and accounting-period
keywords.
5.2.2.1 Workday Keywords
Workday keywords are just what they say: keywords that relate to workdays.
Workdays are days that are not defined as holidays. For our purposes,
weekends are considered holidays (unless you specify otherwise). The
following is a sampling of these keywords:

WDAY All workdays
HDAY All holidays
WDOW2 Second workday of the week
WDOW-1 Last workday of the week
WDOM-1 Last workday of the month
WDOM-3 Second-to-the-last workday of the month
WWOM2 Second work week of the month (any week with at least
one workday is counted as a work week)
RD01 = +1 First workday after the first day of any month
RD17 = -2 Two workdays prior to the 17th of any month
HDAY1 Current date plus one is a holiday
HDAY-3 Current date minus three days was a holiday
5.2.2.2 Accounting-Period Keywords
Later, when how to define a datetable is described, you will see how to define:
■ Accounting days
■ When an accounting period starts
■ When the accounting year ends
These accounting periods can be production cycles, sales cycles, or any other
unit of time. When you define a datetable, you have to define a prefix (any
letter, except E, H, N, P, or W, allowing for 21 different accounting periods)
while using the same datetable. Each accounting period has its own prefix. The

A prefix or the A version of the datetable is the default datetable. When you
use a B prefix, the accounting resolutions will be taken from the B version of
the datetable.
In the examples following, x is used instead of a prefix.

xDAY All accounting days for prefix x
xDOM1 First accounting day of the period (there can
be up to 40 accounting days in the period)
xDOM-1 Last accounting day of the period
xWOM2 Second accounting week of the period (there
can be up to 10 accounting weeks per period)
xWOM-1 Last accounting week of the period
The following describes what is involved in setting up a datetable.
You have to start with a rule. You have to consider accounting periods going
over a year-end date. Consequently, a rule for datetables:
Rule #4 Define three year's worth of datetables for each unique datetable
name. Each year being accessed must have a datetable for the year
before and after it.
The best way to describe the concept of datetables is to use an example.

Suppose that production jobs run Monday through Saturday. That is a six-day
work week (so type a 6 over the 5 for the WORK WEEK field). After you
press the ENTER key, the datetable display shows January, 2003:
SCHD-DTC DATETABLE DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
DATETABLE NAME: DATETAB
DATETAB PREFIX: A
DESCRIPTION : THIS IS AN EXAMPLE
DESIRED MONTH : JANUARY
DESIRED YEAR : 23
WORK WEEK : 6
SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY

1A 2A 3A 4A 5A 6A
7 8A 9A 1A 11A 12A 13A
14 15A 16A 17A 18A 19A 2A
21 22A 23A 24A 25A 26A 27A
28 29A 3A 31AP
PF1=HELP


Suppose you now want to indicate that January 1 is a holiday and a

nonaccounting day (by typing an H for holiday and an N for nonaccounting
day on top of the 01A field). You could also change the end of the accounting
period by removing the P from the 31st and putting it where ever you wanted
it, say on the 30th. If January was the end of the accounting year, youwould
put an E on the 30th. After typing this data on the panel, the following would
be displayed before pressing the Enter key.

===> MASTER - WR
CONNECT : 4
DATETAB PREFIX: A
DESIRED YEAR : 23
WORK WEEK : 6

HN 2A 3A 4A 5A 6A
7 8A 9A 1A 11A 12A 13A
14 15A 16A 17A 18A 19A 2A
21 22A 23A 24A 25A 26A 27A
28 29A 3APE 31A
PF1=HELP

Now, press the ENTER key.
The panel following shows what happens. Notice that 01 is now displayed in
low intensity and there is no A following it.

===> MASTER - WR
CONNECT : 4
DATETAB PREFIX: A
DESIRED YEAR : 23
WORK WEEK : 6

1 2A 3A 4A 5A 6A
7 8A 9A 1A 11A 12A 13A
14 15A 16A 17A 18A 19A 2A
21 22A 23A 24A 25A 26A 27A
28 29A 3APE 31A
PF1=HELP

Once January's definition is complete, press Enter to go to February. When all
12 months are defined, press Enter to store the datetable for this year on the

database. Also, define the corresponding datetables for the prior and next
years.
5.2.2.3 Summary of Datetables
Datetables are broken into two categories: workday processing and accounting
period processing. If you need more than one holiday definition, you will
need another datetable.
The reserved words (keywords) for the Gregorian Calendar mechanism and
the keywords for the Datetable calendar mechanism can be used together.
Here are some examples of Gregorian or Datetable calendar mechanisms:
Example Interpretation
(MON AND WDAY) OR Select on Monday when Monday is not a
(TUE AND HDAY-1) holiday, or select on Tuesday when Monday
is a holiday.
WDOW1 Select the first workday of every week. This
is the same as preceding except if Tuesday is
also a holiday, it will be selected on
Wednesday.
WDAY AND (MON OR Select every Monday through Thursday
WED OR TT) except on holidays.
WDAY AND NOT FRI This is the same as the preceding example,
only expressed more .
BDAY AND NOT BDOM-1 Select on every accounting day except for the
last accounting day of the period. This
references the datetable defined with prefix B.
WDAY AND WOY-1 Select every workday of the last week of the
year.
MON AND (WWOM2 OR Select every Monday of the second and fourth
WWOM4) weeks of the month regardless of whether
Monday is a holiday.
ADAY AND NOT HDAY Select on every accounting day that is not a
holiday. Notice that an accounting day may
be a holiday (this is not normally the case).
5.2.2.4 Date Translation Table Report
Previously discussed were the Gregorian calendar and datetables. A way is

needed to see what conditions are met on any given day. The Date Translation
Table report is obtained by running the Unicenter CA-Scheduler Utility with
the REPORT DATETRAN transaction. You can request a specific date or

datetable on this transaction if you desire. Reviewing this report will help you
understand the Gregorian calendar and datetables better.
COMPUTER ASSOCIATES DATE TRANSLATION TABLE

DATETRAN PAGE 1
Unicenter CA-Scheduler 7.3 965SHESA
4 APR 23 15.53.49
SIMULATION DATE 8 SEP 23
JULIAN DATE=95251
TABLE NAME=DATETAB
GREGORIAN DATE=9/8/95
DAY OF WEEK=FRI WEEK-DAY=YES WEEK-END=NO MWF=YES TT=NO NTH DAY OF MONTH=FRI2

FRI-4 NEGATIVE DAY OF MONTH=DOM-23
WEEK OF MONTH=2ND-WEEK WEEK OF YEAR=WOY36 WOY-18 DAYS IN MONTH=3 LEAP-YEAR=NO
DAY1OF2=NO DAY2OF2=YES
DAY1OF3=NO DAY2OF3=NO DAY3OF3=YES
DAY1OF4=NO DAY2OF4=YES DAY3OF4=NO DAY4OF4=NO
DAY1OF5=NO DAY2OF5=NO DAY3OF5=NO DAY4OF5=NO DAY5OF5=YES
DAY1OF6=NO DAY2OF6=NO DAY3OF6=NO DAY4OF6=NO DAY5OF6=NO DAY6OF6=YES
WEEK1OF2=YES WEEK2OF2=NO
WEEK1OF3=YES WEEK2OF3=NO WEEK3OF3=NO
WEEK1OF4=YES WEEK2OF4=NO WEEK3OF4=NO WEEK4OF4=NO
WEEK1OF5=NO WEEK2OF5=NO WEEK3OF5=YES WEEK4OF5=NO WEEK5OF5=NO
WEEK1OF6=YES WEEK2OF6=NO WEEK3OF6=NO WEEK4OF6=NO WEEK5OF6=NO WEEK6OF6=NO
WORK-DAY=YES WORK DAY OF WEEK=WDOW5 WDOW-1 WORK DAY OF MONTH=WDOM6 WDOM-16 WORK
DAY OF YEAR=18 -81
WORK WEEK OF MONTH=WWOM2 WWOM-4 WORK WEEK OF YEAR=WWOY36 WWOY-17
RD1=+5 -16 RD2=+5 -16 RD3=+5 -17 RD4=+4 -18 RD5=+3 -19
RD6=+2 -2 RD7=+1 -21 RD8=+ -
RD9=+22 -1 RD1=+21 -1 RD11=+2 -1 RD12=+2 -2 RD13=+2 -3
RD14=+19 -4 RD15=+18 -5 RD16=+17 -6
RD17=+16 -6 RD18=+15 -6 RD19=+15 -7 RD2=+15 -8 RD21=+14 -9
RD22=+13 -1 RD23=+12 -11 RD24=+11 -11
RD25=+1 -11 RD26=+1 -12 RD27=+1 -13 RD28=+9 -14 RD29=+8 -15
RD3=+7 -16 RD31=+6
HDAY=NO
HDAY-1=NO HDAY-2=NO HDAY-3=NO HDAY-4=NO HDAY-5=YES HDAY-6=YES HDAY-7=NO
HDAY1 =YES HDAY2 =YES HDAY3 =NO HDAY4 =NO HDAY5 =NO HDAY6 =NO HDAY7 =NO
HDAY8 =YES HDAY9 =YES HDAY1=NO
HDAY11=NO HDAY12=NO HDAY13=NO HDAY14=NO HDAY15=YES HDAY16=YES HDAY17=NO
HDAY18=NO HDAY19=NO HDAY2=NO
HDAY21=NO HDAY22=YES HDAY23=YES HDAY24=NO HDAY25=NO HDAY26=NO HDAY27=NO
HDAY28=NO HDAY29=YES HDAY3=YES
HDAY31=NO
A-ACCOUNTING DAY=YES DAY OF MONTH=ADOM6 ADOM-16 DAY OF YEAR=18 -81 WEEK OF

MONTH=AWOM2 AWOM-4 MONTH OF YEAR=AMOY9 AMOY-4
X-ACCOUNTING DAY=YES DAY OF MONTH=XDOM6 XDOM-16 DAY OF YEAR=18 -81 WEEK OF
MONTH=XWOM2 XWOM-4 MONTH OF YEAR=XMOY9 XMOY-4
The Date Translation Table Report is used to show you what selection
keywords are TRUE for a specific date and datetable combination. It first
displays the Julian and Gregorian dates with the datetable name that was used
to determine workdays, accounting days, and accounting periods. (The
datetable name is on the right side of the report).
Notice the next set of lines pertain to the Gregorian calendar and include DAY
OF WEEK, WEEK OF MONTH, DAYnOFm, and WEEKnOFm. These indicate
whether a condition is satisfied. For example, WEEK-DAY=YES means that

any time you specified WEEK-DAY as the criteria, the schedule or job will be
selected. The rest of the lines pertain to the datetable. They include the
workday, the workday of the week, the workday of the month, the workday of
the year, the work week, the relative days of the month, and the various
accounting days.
After reviewing this report carefully, you should understand how the criteria
vocabulary works with the Gregorian calendar and datetables.
5.2.3 Calendars
To use calendar processing, set aside everything you have learned so far about
the Gregorian calendar and datetables. Calendars use an entirely different
approach to selecting schedules and jobs. Do not try to relate any discussion of
calendars to the other calendar mechanisms.
We do not recommend that you use calendars. Instead, try to do all of your
definitions with datetables or the Gregorian calendar or a combination of the
two. Consequently, the description of calendars will be brief. If you do not
intend to use calendars, you can skip this subtopic.
You would use this mechanism if a set of schedules have to run on specific
dates during the year and there is no relationship between the dates. Then you
would use a calendar to define just the days of the year on which those
schedules run.
When using calendars, a schedule or job is selected on the days that the
calendar specifies as workdays. With calendars, the criteria language is not
used for selection, only for defining predecessors. Again, the only thing you
specify on a schedule for selection purposes is the calendar name. The same
calendar also applies to the jobs in that schedule.
The following steps describe how to use calendars.
5.2.3.1 Step 1: Define the prototype calendar
Before you define any calendars, first define a prototype calendar. This
calendar defines your holidays and what to do if jobs are selected on holidays.
In case of holidays, should jobs run on the prior workday, the next workday,
or not at all? The prototype calendar must have a name PROTOyy, where yy
is the year (for example, PROTO87).
You can only have one prototype calendar for each year which means that
there is only one set of holiday definitions. Once the prototype is defined, you
can define calendars specific to your needs. Defining a prototype calendar
follows.

The panel following defines the prototype calendar for 2003. It specifies a
five-day work week. If jobs are selected on holidays, Unicenter CA-Scheduler
handles rescheduling differently depending on the selection frequency:
■ With a WEEKLY frequency, jobs will be selected on the workday after the
holiday (nw: next workday).
■ MONTHLY selection reschedules jobs the workday before the holiday (pw:
prior workday).
■ Unicenter CA-Scheduler will not reschedule jobs selected from daily
calendars when holidays occur because we have not specified anything in
the DAILY field.
SCHD-CU CALENDAR DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
CALENDAR NAME : PROTO96

DESCRIPTION : 23 prototype calendar
DESIRED YEAR : 23
WORK WEEK : 5
DAILY (Y): WEEKLY (DOW): nw MONTHLY : pw
PF1=HELP

When you press Enter, January's dates are displayed in calendar format. Since
default work week value of 5 was accepted, the five weekdays are shown in
high intensity and the two weekend days are shown in low intensity. You can
change January 01 to a holiday by overtyping 01 with H and pressing Enter.
This changes the high intensity to low intensity.

SCHD-CU CALENDAR DEFINITION CA-SCHEDULER

===> MASTER - WR
CONNECT : 4
CALENDAR NAME : PROTO96

DESCRIPTION : 23 PROTOTYPE CALENDAR
DESIRED YEAR : 23
WORK WEEK : 5
DAILY (Y): Y WEEKLY (DOW): NW MONTHLY : PW

H1 2 3 4 5 6
7 8 9 1 11 12 13
14 15 16 17 18 19 2
21 22 23 24 25 26 27
28 29 3 31
PF1=HELP

Now pressing Enter causes FEBRUARY to be displayed. When all 12 months
are defined, press Enter and the prototype calendar is entered in the database.
You can now schedule jobs for selection according to the prototype calendar.
You can also use the prototype calendar as the basis for other calendars.
5.2.3.2 Step 2: Define daily, weekly and monthly calendars
Now that we have a prototype calendar, define other types of calendars.

When defining calendars, invent your own names for them such as DAILY,
TUESDAYS, PAYSEMI, ENDOFWK, or ENDOFMO.
To define a daily calendar, just specify a Y in the DAILY field.
To define a weekly calendar, specify a day of the week in the WEEKLY

(DOW) field. It can be SUN, MON, ..., SAT, or WE (Saturday and Sunday). If
this day corresponds with a holiday on the prototype calendar, the job
automatically moves to the next day (NW on the prototype) or the previous
day (PW on the prototype).
To define a monthly calendar, use the MONTHLY field to specify the day on
which schedules or jobs that reference this calendar are to be selected. It can
be FD (first day of month), LD (last day of month), or nn (nnth day of month)
to identify absolute days of the month. If any of these fall on a holiday, the
selection is based on the manner in which you defined the prototype. There is
a corresponding set of days used for workdays. These are FW, LW and nnW.
Since these are workdays, holidays are automatically considered.

5.3 Some Examples
5.3 Some Examples

Now that you are familiar with the criteria language and calendar
mechanisms, consider how to apply what you have learned to the following
scheduling problems.
Example 1
To run the Weekend Summary Report on the first workday of the week, which
criteria statement would you use?
Criteria:
WDOW1
Example 2
Now use another variation of WDOW to schedule the Weekly Summary

Report to run on the last workday of the week.
Criteria:
WDOW-1
Example 3
Which criteria statement would you use to run the Monthly Summary Report
on the first workday of the month?
Criteria:
WDOM1
Example 4
Which variation of WDOM will run the Monthly Summary Report on the last
workday of the month?
Criteria:
WDOM-1

5.3 Some Examples
Example 5
The weekly accounting report runs on Friday. If Friday is a holiday, the report
runs on the following Monday. If the following Monday is also a holiday, the
report runs on the following Tuesday. Which criteria statement conveys this
meaning?
Criteria:
(FRI AND WDAY) OR
(MON AND WDAY AND HDAY-3) OR
(TUE AND WDAY AND HDAY-4 AND
HDAY-1)
Example 6
An Accounting schedule (ACCPROD) consists of three jobs:

■ PROD001 - the daily summary that runs each workday
■ PROD002 - the summary that runs on Friday whether Friday is a holiday,
and is not dependent on PROD001
■ PROD003 - the weekly summary report that runs on Friday night and
must wait for the other two jobs to finish
Which criteria statements apply to this schedule and its jobs?
Criteria for schedule ACCPROD&COLON.

None: All jobs may be selected daily.
Criteria for job PROD001:

WDAY

FRI

FRI AND
(PROD1 ACCPROD OR PROD2
ACCPROD)
For selection purposes, the OR expression will be handled as expected.

However, predecessors that are jobs are handled as if there is always an AND
condition. Consequently, if Friday is a workday, PROD003 will wait for both
PROD001 and PROD002.

5.3 Some Examples
Example 7
A payroll schedule (PAY) consists of two jobs:

■ PAY001 - the summary that runs every weekday and needs an input data
set, PAY001.INPUT, that is transmitted every weekday from an RJE site. It
must also wait for job PAY002.
■ PAY002 - the summary that only runs on Friday.
Criteria for schedule PAY:

WEEK-DAY
Criteria for job PAY002:

FRI
Criteria for job PAY001:

DSN PAY1.INPUT AND
(PAY2 PAY OR NOT PAY2 PAY)
This tells Unicenter CA-Scheduler to schedule job PAY001 every week day,
whether job PAY002 is scheduled or not. Job PAY001 will wait for a data set to
be created every week day, and will also wait for job PAY002, when it is
scheduled on Friday.
Example 8
The Manufacturing Quarterly production schedule (MANQTR) contains three

jobs that run on the last day of the manufacturing quarter. MANQTR runs on
a 4-week, 4-week, 5-week cycle defined in a datetable specified in the schedule
definition using a prefix of M.
Criteria for schedule MANQTR:

MDOM-1 AND
(MMOY3 OR MMOY6 OR MMOY9 OR
MMOY12)
Criteria for job JOBA:

None - Defaults to whenever the schedule is selected.
Criteria for job JOBB:

JOBA MANQTR
Criteria for job JOBC:

JOBB MANQTR
The example preceding shows how you can define selection criteria at the
schedule level and predecessors at the job level. Separating selection criteria

5.3 Some Examples
and predecessor conditions this way makes it easier to evaluate these criteria
statements.
Example 9
In this example, something a little more practical will be shown to show some
of the logic behind determining criteria, which shows the type of thought
process you may go through.
The schedule named IH7BKUP backs up some disks and consists of three jobs:
a daily backup, a weekly backup and a monthly backup.
The daily job IH7D02 normally runs Monday through Thursday.

Consequently, its criteria would be something like:
MON OR TUE OR WED OR THU
What happens on holidays? On holidays, you do not want the job to run. To
omit holidays, revise the criteria as follows:
WDAY AND (MON OR TUE OR WED OR THU)
Now Monday through Thursday also have to be workdays. A more concise

way of writing this criteria statement is as follows:
WDAY AND NOT FRI
Another factor to consider is whether this job has predecessors. In this case, it
does not, so the daily job's selection criteria is now complete.
Next, work on the weekly job. You already know to be conscience of holidays.
If the weekly job runs on Monday through Thursday, the daily job must finish
first. The criteria statement that best describes this is shown following.
WDAY AND FRI

OR
(WDAY AND THU AND HDAY1 AND IH7D2 IH7BKUP)
OR
(WDAY AND WED AND HDAY1 AND HDAY2 AND IH7D2 IH7BKUP)
Since the weekly job will always run on the last workday of the week, you can
simplify the criteria statement preceding as follows:
WDOW-1 AND PRED IH7D2 IH7DBUP
The monthly job IH7M02 runs on the last workday of the month. Its
predecessors vary depending on what day of the week this job runs.
■ If the last workday falls on Monday through Thursday, the monthly job
should wait for the daily backup to complete.

5.3 Some Examples
■ If the last workday of the month is a Friday, the monthly job should wait
for the weekly backup to complete.
■ If the last workday of the month falls on a Saturday or Sunday, the
monthly backup job has no predecessors. However, the datetable was
defined for a five-day work week so Saturdays and Sundays are not
workdays.
The criteria would be:
WDOM-1 AND (IH7D2 IH7BKUP OR IH7W2 IH7BKUP)
Shown following is the finished product:
Criteria for schedule IH7BKUP:

None - Defaults to looking at all jobs each day.
Criteria for job IH7D02:

WDAY AND NOT FRI
Criteria for job IH7W02:

WDOW-1 AND PRED IH7D2 IH7BKUP
Criteria for job IH7M02:

WDOM-1 AND
(IH7D2 IH7BKUP OR IH7W2 IH7BKUP)

5.4 What Is Wrong with These Examples?

Now that you have a basic understanding of the criteria language, try testing
your knowledge by debugging errors in the following criteria statements.
Example 1
Criteria for schedule SCHD01:

MONDAY
Will this job run on Mondays? Not likely because MONDAY is not a
vocabulary word. Instead, Unicenter CA-Scheduler interprets MONDAY as a
job name. Therefore, this job will only be selected when the job MONDAY is
selected. Since you probably do not have a job named MONDAY, the schedule
SCHD01 would never be selected.
The correct criteria vocabulary word is MON.
Example 2

WDOW-1 OR DSN JOBA.DATASET
The intent is to select JOBB on the last workday of the week, but that is not
what happens. Evaluate this statement carefully to see what is wrong. It is
important to evaluate the selection criteria and the predecessor conditions
separately.
What is JOBB's predecessor? The data set JOBA.DATASET must be closed on

the day JOBB is selected before JOBB will be submitted.
When is JOBB selected? Not just on WDOM-1 (the last workday of the month).
Why? Because of the OR. The days on which JOBB is selected will be:
WDOW-1 OR 'keyword-defined parameter'
Unicenter CA-Scheduler cannot translate DSN JOBA.DATASET into a selection
condition, so the second condition defaults to DAILY. Because of the OR, this
job is selected WDOW-1 OR DAILY. How could you rewrite the statement to
run JOBB when intended? Code the criteria statement with an AND instead of
an OR:
WDOW-1 AND DSN JOBA.DATASET
This selects JOBB on the last workday of the month and waits for the data set
JOBA.DATASET to close before submitting JOBB.

Example 3

MON AND JOBB SCHED1 OR WED

MON OR WED AND JOBA SCHED1
Here is another problem. Why do not JOBA and JOBB in schedule SCHED01
run when expected? Both jobs are supposed to run Mondays and
Wednesdays. On Mondays, JOBB should be the predecessor to JOBA, but
conversely on Wednesdays.
The meaning of these criteria statements is confusing until you add some
parentheses to show how the system will interpret this:

(MON AND JOBB SCHED1) OR WED

MON OR (WED AND JOBA SCHED1)
Now it is a bit clearer. First, look at the selection criteria. Both jobs are always
selected on Mondays and Wednesdays:
■ JOBA is always selected on Wednesdays, so JOBB is, too.

■ JOBB is always selected on Mondays, so JOBA is also selected on
Mondays.
That seems in order, so look at the predecessor conditions, remembering the
rule for evaluating predecessors:
There are no OR relationships with selection-defined explicit predecessors. All

ORs become ANDs.
The preceding means the explicit predecessor of JOBA is JOBB, and the explicit
predecessor of JOBB is JOBA. When jobs require each other as predecessors,
that creates a predecessor loop, which is also called predecessor deadlock.
Although these deadlocked jobs are selected properly, neither job ever runs
because their predecessors are never satisfied. You can run the Analyze
Report at any time to detect deadlocks automatically.
Example 4

NOT MON OR NOT TUE

Suppose you want JOBA to run on any day but Monday or Tuesday. Why
does the criteria statement preceding not make that happen?
Instead, JOBA is always selected because on Mondays, JOBA is selected

because it is not Tuesday. And on Tuesdays (and every other day), JOBA is
selected because it is not Monday.
There are two valid ways to code this criteria:

NOT (MON OR TUE)
Another way to express this criteria:

NOT MON AND NOT TUE
Example 5

ADAY AND JOBA SCHED1 AND
GBLB1=YES
OR
ADAY AND GBLB1=YES
JOBB in SCHED01 will always be selected on ADAY. The confusion arises

when evaluating predecessors. JOBB is always supposed to wait for the global
GBLB01 to be set to YES. If JOBA is in the day's workload, it is supposed to be
a predecessor to JOBB.
That is not what happens. Instead, when JOBA is present, status shows that
JOBB waits for predecessors JOBA, GBLB01, and GBLB01. When GBLB01 is set
to YES, JOBB starts regardless of JOBA because of the second GBLB01. The
following is what happens.
After JOBB is selected, these predecessors are left for evaluation:
(JOBA SCHED01 AND GBLB01=YES) OR (GBLB01=YES)
JOBB will start as soon as GBLB01 is set to YES.
The correct way of coding this criteria statement is:

ADAY AND JOBA AND GBLB1=YES
OR
ADAY

After JOBB in SCHED01 is selected, only these predecessors are left for
evaluation:
(JOBA AND GBLB01=YES)
When JOBA is not in the day's workload, Unicenter CA-Scheduler knows that
it cannot be a predecessor.
Example 6

MON OR TUE OR WED OR THU OR FRI
OR
(SAT AND PRED JOBA)
The intent is that JOBB would run Monday through Saturday, but only on
Saturday if JOBA completed sometime since last Saturday (for example, it may
be that JOBA only runs on Fridays). The rule is that keyword-defined explicit
predecessors apply across all selection criteria. Consequently, JOBB will wait
for JOBA every time JOBB is selected (even on Monday, Tuesday, and so
forth).
To accomplish this, you have to set up JOBB as two separate jobs: JOBB-01 and
JOBB-02. Notice how the criteria for JOBB-01 has been simplified following.
The correct way of coding this criteria statement is:
Criteria for the first job JOBB-01:

WEEK-DAY
Criteria for the second job JOBB-02:
SAT AND PRED JOBA

5.5 Summing Up
5.5 Summing Up
Evaluate criteria statements twice: once to determine selection criteria and
again to identify predecessor conditions. When coding a job in the criteria
language, always qualify it with its schedule name. Use the SCD keyword
before a schedule name to identify it as such.
Selection A job will only be evaluated for selection and eligible for
today's workload if its schedule is selected or eligible for
today's workload. A schedule is considered eligible for
selection if the only reason it was not selected is because it
was defined with AUTO SELECT=NO.
The NOT keyword only applies to selection.
Predecessors Every job or schedule listed in a criteria statement is a
predecessor if it is also in or eligible to be in the day's
production. Whether those jobs or schedules are part of the
reason for selection does not matter.
Unicenter CA-Scheduler observes ORs used with all
keyword-defined predecessors except PRED, meaning
NJE,VSE, DSN, GDG, and GBLxnn.
A criteria statement like NOT JOBA defines JOBA as a
predecessor.
If jobs or schedules are predecessors, Unicenter CA-Scheduler
waits for them to complete unless you precede their names
with the keyword START.
Calendars Define daily, weekly, and monthly calendars for selecting
schedules and jobs. When using calendars, only the calendar
name determines selection.
Datetables Define three years' worth of datetables for each unique
datetable name. Each year being accessed must have a
datetable for the year before and after it.

Chapter 6. Tips
This topic of the manual is intended to provide you with some helpful hints
on using Scheduler. Some of the most commonly asked questions are followed
with a discussion of some pitfalls. The questions are grouped by topics that
parallel the structure of this manual:
■ Startup tasks
■ Maintaining the database
■ Analyzing the database
■ Daily processing
This organization allows each topic to stand on its own so you can jump from
topic to topic. Do not be concerned about reading this chapter in the order that
topics appear.
Chapter 6. Tips 6-1

6.1 Commonly Asked Questions

This topic consists of a series of questions that are commonly asked.
The following table lists the topic category with associated questions which are
answered following the table.
Topic Question
Startup Tasks When should autoscan be performed?
What is the general standard for numbering
stations?
Should I use datetables or calendars?
When should I define a new datetable versus a
new cycle in an existing datetable?
Maintaining The How should I organize my schedules?
Database Is there a fast way to add data to the database?
When should a job be staged?
When is a job submitted?
What are global parameters and when are they
used?
How can I run a job like an edit check repeatedly
until its output is correct?
How and when can I display documentation
automatically?
What are my options when a job abends?
Analyzing The How can I prevent predecessor loops?
Database When should I run forecasts?
When should I run simulation?
How do I plan when to run a new application?
How do I verify a new application?
Is there a way that I can create my own reports?
Daily Processing From where can I issue Unicenter CA-Scheduler
operator commands?
What is the difference between FORCE, SUBMIT,
RERUN, RUN, ADD, REQUEST, and SREQ?
When is the PRED flag reset?
What happens if there was a system crash?
6.1.1 Startup Tasks

Commonly asked questions concerning startup tasks follow.

6.1.1.1 When Should Autoscan Be Performed?
Autoscan is the daily process that purges completed jobs from the Scheduler
tracking file, backlogs schedules and jobs, if appropriate, and selects the day's
workload. Scheduler scans the database, analyzing the selection criteria and
placing the selected schedules and jobs onto the tracking file.
If your production normally starts at 16:00 and runs during the night with
everything completing by 07:00 or 08:00, then autoscan should be run at 08:00
or shortly after that. Run autoscan at a time when your machine load is at a
low point.
Notice the VSE jobs that are running will not go to the end of job until
autoscan completes. This ensures that the Unicenter CA-Scheduler monitor will
not miss events such as database close, VSE job ends, scheduler job ends, and
so forth.
Running autoscan this way gives the production control area a chance to get
everything ready for the day's workload, which includes JCL changes, control
statement changes, data entry work, last-minute changes, and the like.
6.1.1.2 What Is the General Standard for Numbering Stations?
Normally, stations are set up as follows:
20 Data entry
39 JCL staging
40 CPU processing
Station 20 Data entry
Jobs start at their early start time if you specify AUTO
START=YES (as long as their predecessors and resources are
satisfied). However, you always have to manually post these
data entry jobs when they have ended.
Station 39 JCL staging
Jobs must be manually posted as ENDED (using the
COMPLETE command) before a CPU job with the same name
will be submitted. If you specify that the station 39 job is to be
automatically started (AUTO START=YES), it will be started
at its early start time as long as its predecessors and resources
are satisfied.
Station 40 CPU processing
Jobs will be started when the early start times are met, all
predecessor conditions are fulfilled, and resources are
available. CPU job processing is automatic unless you override
it.
Chapter 6. Tips 6-3

6.1.1.3 Should I Use Datetables or Calendars?
Datetables and calendars are two different methods used to select schedules
and jobs for a specific day. Datetables provide significantly more flexibility
than calendars and should be used if at all possible. They are a bit more
complicated to understand, but entail less maintenance than calendars when
going from year to year. Datetables also allow multiple accounting periods as
well as different holidays.
One area where you will want to use Calendars is when the schedule has to
run according to a set of dates that follows no pattern. Define these individual
days once in a calendar. Then when any schedule runs on those dates, you
give it that calendar name for selection.
For most of your application needs, however, use datetables. A detailed

discussion on this matter appears in the chapter "Criteria Language."
6.1.1.4 When Should I Define a New Datetable Versus a New Cycle in an

Existing Datetable?
Keep in mind that a cycle can be an accounting, production, or sales period.

You can have up to twenty cycles defined with any one datetable, and any
number of datetables. The datetable prefixed by the letter A is your default
production datetable. The other prefixes are variations upon that datetable.
Any time you want to schedule a job based on a combination of two or more
cycles, you must use the datetable prefix; you cannot use different datetable
names.
6.1.2 Maintaining the Database

Commonly asked questions concerning maintaining the database follow.
6.1.2.1 How Should I Organize My Schedules?
A schedule should consist of a group of logically related jobs. This group of

jobs usually belongs to one application, but could also be run at the same
frequency. For example, you could define a Payroll schedule containing all the
payroll jobs and its selection criteria. If certain jobs in the schedule do not run
every time the schedule is selected, define the selection criteria for the
exceptional jobs. Or the daily Accounts Receivable jobs could be contained in
one schedule and the weekly Accounts Receivable jobs could be in another.
Possibly, the weekly schedule is dependent on the daily schedule to complete.
Do not organize schedules just by frequency. For example, do not have a

Monday schedule. There should not be one schedule just for requested jobs,
either, unless it is easily manageable. Instead, try to keep application-related
jobs together. This makes interdependencies within applications much clearer.

Keep in mind, most options defined for a schedule apply to all jobs in that
schedule. You can, however, override these options at the job level.
Try to keep schedules small (around 50 jobs) so they are easily managed. This
is particularly important when a schedule gets backlogged or when scrolling
through jobs displayed on Online Status panels.
6.1.2.2 Is There a Fast Way to Add Data to the Database?
If you have a lot of information to add, you should always analyze whether it
would be best to do it in a batch mode. You would use a full-panel editor to
format the data and then run it through the Unicenter CA-Scheduler batch
utility (CAJUTIL0).
You can take a shortcut when using the Online Database Maintenance facility.
Each time you enter a panel of data, Unicenter CA-Scheduler translates this
into a batch command with appropriate keywords, which invokes the batch
utility program and processes the command. Once the command is processed,
it is redisplayed in its batch format at the top of the panel in an input
command area. The panel on which this is displayed is called the SCHDUTIL
Output panel.
The SCHDUTIL Output panel will also contain any messages associated with
the command just processed and currently displayed. Messages can confirm
that the database has been updated or that a command contains specific errors.
The shortcut allows you to overtype any part of the batch command displayed
on the SCHUTIL Output panel. Once the batch command is displayed, you
can change part of the command, press Enter, and the new command will be
processed.
You can use this technique to:

■ Correct errors
■ Add a similar job or schedule to the database
To reduce the possibility of destructive errors, this feature does not permit you
to alter or delete multiple records.
6.1.2.3 When Should a Job Be Staged?
Staging a job means that at autoscan time or whenever the job is manually run
with the RUN command, the job's JCL is moved from the master JCL file
(LIBTYPE field) to the Unicenter CA-Scheduler staging library. This LIBTYPE
will default to the one that appears in the LIBTYPE installation option of the
CAIJGEN macro, but can be overridden at the schedule level and again at the
job level.
A job should only be staged if its JCL needs to be changed before it runs or if
it has control statements that need to be changed or added.
Chapter 6. Tips 6-5

To have a job's JCL staged, you must make the STAGE JCL field be YES on the
Job Definition panel for station 40 and either:
■ Define an EARLIEST START TIME that gives users enough time to change
the JCL or
■ Define the same job to station 39 (the staging station)
Using the first method does not guarantee that the staged JCL will be ready to
run before Unicenter CA-Scheduler submits it. A job's EARLIEST START
TIME may arrive before its JCL has been modified in preparation for
submission.
To ensure that a user at the JCL setup station has enough time to modify and
review the staged JCL, use the second alternative mentioned preceding. The
job defined at station 39 will be an implicit predecessor of the CPU job at
station 40 which means the CPU job cannot be submitted until the job at
station 39 has been manually marked as ENDED using the COMPLETE
command.
You could, for example, have a daily job that only needs to have its JCL or a
control statement changed on Fridays. Therefore, you only want to change the
JCL on Fridays. You can accomplish this by allowing the CPU job (the one
assigned to station 40) to be selected DAILY and the staging job (the same job
name within the same schedule defined to station 39) to be selected FRI.
Notice that the job's JCL will always be staged, even though you only change
it on Fridays. Remember, the station 39 job has to be manually started or
AUTO START=YES must be specified in its definition. When the JCL has been
changed, you mark the job on station 39 completed with the COMPLETE
command.
A job's JCL can be staged (taken from the master JCL file as specified in the
LIBTYPE field and placed in the Unicenter CA-Scheduler staging file) even if
staging is not automatic. That is, regardless of whether you had STAGE=YES
or not, a fresh copy of the job's JCL will be restaged. Furthermore, you may
want to restage JCL for a job with STAGE=NO. This would be for purposes of
changing it due to a rerun condition. You use the RESTAGE operator
command to accomplish this. Keep in mind that it will overlay any JCL that
may already be in the staging file for the respective job.
Once the JCL is staged, you can use a variety of editor commands to prepare it
for submission. In addition to usual text editing, you can perform some
special functions within the editor:
■ Expansion of Unicenter CA-Driver procedures embedded in the JCL
■ Display of current values of all Unicenter CA-Driver reserved-name
variable parameters in the JCL
■ Change of values of any Unicenter CA-Driver reserved-name variable
parameters in the JCL

Using these functions together is a convenient way to write and test Unicenter
CA-Driver procedures to automate JCL setup and minimize the need to stage
JCL. For detailed explanations of these functions and all of the editor
commands, see the appendix "Editor Commands" in the Unicenter CA-Scheduler
The JCL that is staged is purged from the staging library when its associated
job is purged from the tracking file. JCL that is stored in either a DOS source
statement library, a DOS procedure library, or Unicenter CA-Driver procedure
library is not fully expanded in the staging file. The staged version of these
jobs will contain the JECL and *$$SLI, // EXEC PROC, or // PROC,
respectively.
Do not use STAGE=YES for jobs that have their JCL stored in an AllFusion
CA-Panvalet library.
6.1.2.4 When Is a Job Submitted?
Once a job's EARLIEST START TIME is met, all of its predecessors have
completed normally, and its resources (volumes, SEPARATE DSNAMEs, and
SEPARATE JOBS) are available, then a job can be submitted.
6.1.2.5 What Are Global Parameters and When Are They Used?
Global parameters are user-defined conditions that are predecessors. You can
specify that a schedule or job must wait for a specific global parameter to be
set to a specific value before the respective schedule or job can be started or
submitted.
There are three types of global parameters: numeric, binary (yes or no), and
alphanumeric (up to eight characters). Global parameters follow the format:
GBLxnn=value
x= A if the value is a number from 1 to 99999999

B if the value is Y or N
C if the value is up to 8 alphanumeric characters
nn = a number from 1 through 16
An example follows. Suppose there is a set of jobs that cannot start without a
particular set of tapes arriving from an off-site location. Suppose this is some
accounting data and you give it a name of HERE-NOW. You have to pick a
global variable to be set aside for just this purpose. Suppose you choose
GBLC4 because you know no one else is using it. Any schedule or job that
needs the data before it can run will have as part of its criteria language the
following string of data:
GBLC4=HERE-NOW
Chapter 6. Tips 6-7

Once the tapes have arrived, an operator sets the value of the global parameter
GBLC4 to HERE-NOW. At that point, if any schedule or job is waiting for no
other reason but this variable, then the schedule will be started or the job will
be submitted.
It is very important to notice that global parameters are not reset

automatically. Someone must cause it to happen. Their values are saved on the
tracking file and always remain until they are reset to some other value or the
tracking file is reinitialized. Autoscan does not reset the global parameters.
A review of all the ways you can set, reset, and define global parameters
follows.
When you initialize the tracking file, all global parameters are set to zero (for
A-type), NO (for B-type), or null (for C-type).
If you want to see the current values of the global parameters, go into the
Online Monitoring panel and enter 6,D. The general Unicenter CA-Scheduler
Command Processor panel will be displayed with all of the global parameter
values. Another way to see the current values is to issue an operator command
GBL to display all defined global parameters, or GBLA for the numeric ones,
or GBLB or the YES/NO ones, or GBLC for the character ones.
To assign a value to a global parameter, you also go to the Online Monitoring

panel. Once there, enter 6,GBLxnn=value. You never really reset a value; you
type a new value each time. Another way to set global parameters is to use
the operator command SET GBLxnn=value. For example, SET GBLC1=SHIFT1
to mark the start of a specific shift. Another example, SET GBLC16=TP1HERE
to mark the arrival of a tape.
When you define the criteria for a schedule or job, you can specify which
global parameters and what values they are to contain for use as predecessor
conditions that have to be met before the schedule can be started or the job can
be submitted.
There is one rule you have to be sure to follow: a NOT reserved word
preceding a GBLxnn predecessor is NOT recognized. Therefore, NOT
GBLC01=CICS-UP will have the same affect as GBLC01=CICS-UP.
6.1.2.6 How Can I Run a Job Like an Edit Check Repeatedly until Its Output Is
Correct?
This is a situation where you want to keep running a job over and over again
until you get an indication that the rest of the application can run. You may
not know how many times it will take each day, since it depends on
everything being valid. There are two ways to achieve this type of processing:
■ Using the INTERRUPT field on the job base record
■ Using Auto-Reply processing.

To allow a job to be interrupted, you specify INTERRUPT=YES in its Job

Definition panel which means that when the job terminates normally, its status
will be set to INTRPTD instead of ENDED. You can then run the job by using
the RERUN command. Successors of this job will not run until the job is ended
manually using the COMPLETE command.
At any time during the day, you can go into the Online Status panel (either
from the Main Menu or from the Online Monitoring panel) and display all jobs
that are in an INTRPTD status so you can see any jobs that are interrupted.
When a job does get interrupted, you can have a message sent to up to four
users. These users can be any user name, the master console ('OPERATOR'),
or the Unicenter CA-Scheduler mailbox (MAILBOX). To do this, use the SEND
INTERRUPT MESSAGE TO field in the job's Message Definition panel.
Remember that when a job is to be interrupted, it must be manually posted to

do something next such as freeing successors to run. Either mark the job as
ENDED, or resubmit the job using the RERUN or SUBMIT command.
Successor jobs are then handled appropriately.
AUTO-REPLY processing takes a predefined action in reply to a console

message associated with a job or schedule.
6.1.2.7 How and When Can I Display Documentation Automatically?
User documentation can be built according to whichever standards you want.

It is done using full-panel editing facilities provided with Unicenter
CA-Scheduler. Each documentation member in this documentation file is
given an eight-character key and this along with the schedule name or job
name (and job number and station) comprise the name that is used to uniquely
identify it. You can at any time, view this information by using the
Documentation Maintenance panel.
If the job has a documentation key defined, the contents of that documentation
library member will be printed as part of the forecast and simulation
components, if requested.
When defining a job using the Job Definition panel, you can specify a DISPLY
KEY and a DISPLAY TIME. If the job is a CPU job (station 40), then the name
in the DISPLY KEY field will have its documentation displayed on the master
operator console at the time of day specified in the associated DISPLAY TIME
field. This will happen automatically. If you do not use the DISPLAY TIME
field, but a DISPLY KEY field is specified, the documentation members will
display at autoscan time.
If the job is a non-CPU job, the user starting the job will receive a message
telling him that there is documentation associated with the job and the name
of the documentation member. The user can then display it. If the non-CPU
job is automatically started (AUTO START=YES), the message is sent to the
Chapter 6. Tips 6-9

users in the SEND START MESSAGES TO list defined on the job's Message
Definition panel.
6.1.2.8 What Are My Options When a Job Abends?
In the next chapter, the separate topic Restart/Recovery Of Scheduled Jobs is

devoted to this topic.
6.1.3 Analyzing the Database

This topic presents several questions you may have regarding analyzing the
database and gives you difinitive answers.
6.1.3.1 How Can I Prevent Predecessor Loops?
Predecessor loops are also called predecessor deadlocks. A predecessor

deadlock exists when two jobs end up requiring that the other execute first.
For example:
JOBA requires JOBX to run first.
JOBB requires JOBA to run first.
JOBX requires JOBB to run first.
JOBX is a predecessor of JOBA, but cannot run until JOBB has ended. Since
JOBB will not run until after JOBA has ended, there is a deadlock.
Imagine how complicated this would be to resolve if there were a hundred

jobs, each with many predecessors. It is difficult to detect a deadlock unless
you use the Analyze Report.
To obtain the Analyze Report, run the Unicenter CA-Scheduler Utility program
(CAJUTIL0) with the batch command ANALYZE. You can check specific jobs
or schedules or you can give a range of jobs or schedules. For example, you
can analyze all schedules that begin with the first three characters PAY.
Anytime you make significant changes to jobs or schedules, run this report to
ensure that your changes have not introduced deadlocks. You should produce
it any time the criteria for a job or schedule is changed.
Instead of getting the comprehensive Analyze Report, you can use the
LIST=NO operand to request that just the errors be reported.
The ANALYZE command can also be issued online from any of these panels:
■ Job Maintenance (SCHD-JM)
■ Job Directory (SCHD-JD)
■ Schedule Maintenance (SCHD-SM)
■ Schedule Directory (SCHD-SD)

For details on how to issue ANALYZE online, see the topics Analyzing
Schedules and Analyzing Jobs in the chapter "Maintaining The Database."
Another way to detect deadlocks is to generate the Successor Chain List report
either from batch or online in the Reporting Facility panel. This is especially
useful for dynamically ADDed jobs to make sure that the added job did not
create a deadlock.
6.1.3.2 When Should I Run Forecasts?
The forecast function allows you to predict which schedules and jobs will be
selected on a future date as well as providing a comprehensive set of reports
detailing such.
When establishing a complex criteria for a schedule or job, run forecasting to

verify the selection. You can do this by only including the schedules or jobs
that you desire. This would be the primary reason for running forecasting.
Another reason for running forecasting would be to obtain a hard copy of run
books for a specific day, group of days, or schedules or jobs within a set of
days. These run books contain job information obtained from the database and
from documentation library members specified by the DISPLY KEY field.
6.1.3.3 When Should I Run Simulation?
The simulation function simulates the autoscan process and the manner in
which jobs would run on the real system. Such things as job concurrency,
resources, and predecessor constraints are taken into consideration. Simulation
produces a set of detailed reports showing when jobs will run and whether
they will complete on time.
Normally, simulation is run to determine the affect of a new application on the

rest of the workload. This helps you determine in advance whether the
requested frequency of running the application is viable. That is, if you find
that the new application cannot fit on Wednesdays without making a lot of
jobs late, you could try to run it on another day. It may turn out that it does
not absolutely have to run on Wednesdays. The requesting department may be
able to run it on Thursdays just as easily. You can make these decisions before
establishing policy and before finding that you do not have the resources to
handle it.
Simulation could also be run to determine the effect of adding new resources
such as tape drives or a faster CPU. By using the OVERRIDE RESOURCE
command, you can add the new tape drives. Or by using the FACTOR=factor
keyword on the same commands, you can cause the simulation to change the
current average time for jobs to reflect the faster CPU.
You may also want to run simulation as part of normal daily production to
determine what is going to happen that particular day. It provides you with a
Chapter 6. Tips 6-11

plan of what to expect and when to expect it. When you do this, you can
optionally use the simulated start times as the early time of the jobs for
submission. When you do, it ignores the early start time that you had on the
database.
6.1.3.4 How Do I Plan when To Run a New Application?
You first define your application completely. Temporarily set LIBTYPE =

TESTLIB in schedule base records. Now run simulation (see the discussion of
simulation preceding) with a ONLY command just for the schedules in the
new application. This will ensure that everything is the way you want it.
If you have backlogged jobs in the simulation, you may want to run the
Analyze Report to check for predecessor deadlocks.
Once everything looks correct, you can run the application in test mode with
the normal day's production and review its affect on the day's workload.
6.1.3.5 How Do I Verify a New Application?
There are four steps you should follow in verifying a new application.
Step #1 Analyze Report
The Analyze Report provides a detailed audit of all information
pertaining to the schedules being requested. From this report,
you have a complete list of everything that you keyed in for the
new application. You also get a set of error messages that
identify predecessor/successor deadlocks as well as any
references to jobs, predecessors, datetables, and stations that are
not on the database. Review this report carefully. Sometimes
you may prefer to print just the errors using the LIST=NO
option.
To obtain this report, use the JCL described in the the topic
Reports in the Unicenter CA-Scheduler Reference Guide Part 2.
You can also obtain it by issuing the ANALYZE command
online in the Job Maintenance (SCHD-JM) or Schedule
Maintenance (SCHD-SM) panel.
This example analyzes all schedules that begin with the
characters "APPLIS."
// JOB ANALYZE
// EXEC CAJUTIL,SIZE=48K
ANALYZE SCHEDULE NAME=APPLIS
/
/&
Step #2 Forecast
Run the forecast component for at least a month of dates and
obtain the Job Summary Report (SUMMARY). You do this for
the schedules that were built for the new application. Through

use of the ONLY command, only the new schedule names are
supplied causing just the new application to be analyzed.
Through use of the FORECAST command with the object of
SUMMARY, you will obtain just the Job Summary Report. The
following example contains three schedules to be selected over a
one month period with only the Job Summary Report being
produced.
// JOB FORCAST
// EXEC CAJUTIL,SIZE=48K
ONLY SCHEDULE N=APPL1S1
FORECAST SUMMARY MONTHOF=795
/
/&
Step #3 Simulation
Run the Simulation component for each unique day on which
the new application will run. During a month, this may only be
three days: a daily, a weekly, and a monthly.
You would use the ONLY and SIMULATE commands to
accomplish this.
You want to verify that the jobs were selected on the days on
which you intended them to be. Then you want to verify that
they were scheduled in the proper sequence: predecessor
relationships are properly followed. If you have jobs that are
backlogged, there is a good chance they may have a predecessor
deadlock. Also, if jobs are backlogged, check the accuracy of
early start times and run times.
Step #4 Test Run the schedule in test mode. Use the online tracking RUN S
command with the DATE=date keyword for each unique day on
which the new application will run.
Use the STATUS command to verify that jobs are scheduled
correctly, on those dates, and with the correct predecessors.
Keep in mind that since LIBTYPE=TESTLIB, Unicenter
CA-Scheduler will submit jobs that execute the CAJUTSTA test
program. You can use TESTPARM=testparm on individual jobs
to cause the test program to abend, to pass a nonzero return
code, and to have it wait for a number of seconds. By doing
that, you can test the effect of abending and failing jobs on the
rest of the schedule.
After the jobs in the schedule run to your satisfaction, you can
now alter LIBTYPE=TESTLIB, in the SBR, to your production
LIBTYPE. Also make sure that AUTO SELECT is set to YES.
Once you do that, the schedule and its jobs will be automatically
selected, starting at the next AUTOSCAN.

6.1.3.6 Is There a Way that I Can Create My Own Reports?
As part of Unicenter CA-Scheduler you have a component called Advantage

CA-Earl. Advantage CA-Earl is a generalized report writing facility for which
you are provided a set of sample reports. This sample set of reports includes
reporting on:
Database
History file
Tracking file
Documentation file
JCL Staging library
The source code for these Advantage CA-Earl reports is provided to you. The
following lists the reports and the names of the source members in which the
source is contained.
Database CAJINM01 Basic job information by schedule

CAJINM02 Basic job information by station
CAJINM03 Job criteria by schedule
History file CAJINH04 Abended job profile
CAJINH03 Completed job profile
CAJINH07 Forced and canceled jobs
CAJINH05 Late job profile
CAJINH06 Pending job profile
CAJINH01 Scheduled job status by schedule
CAJINH02 Scheduled job status by station
Tracking file CAJINT04 Abended job profile
CAJINT07 Cancelled jobs
CAJINT03 Completed job profile
CAJINT06 Pending job profile
CAJINS06 Pending schedules report
CAJINS01 Schedule status
CAJINT01 Scheduled job status by schedule
CAJINT02 Scheduled job status by station
Documentation CAJIND02 Documentation directory and list library
CAJIND01 Documentation directory list
CAJINTD1 Documentation with the tracking file
Staging library CAJING02 Staged JCL directory and list
CAJING01 Staged JCL library directory list
Although each of the preceding reports is written in Advantage CA-Earl and

provided for you, you have the ability to tailor any of them to your own
needs. The topic Reports in the Unicenter CA-Scheduler Reference Guide Part 2
describes each of these samples in detail. Also, the appendix "Advantage
CA-Earl Reports in the Unicenter CA-Scheduler Reference Guide Part 2 describes

other Advantage CA-Earl members that are used in producing the preceding
reports and that you may need for any reports that you build.
6.1.4 Daily Processing

Commonly asked questions concerning daily processing follow.
6.1.4.1 From Where Can I Issue Unicenter CA-Scheduler Operator Commands?
There are quite a few operator commands provided within Unicenter

CA-Scheduler. They do everything from displaying status to shutting down
Scheduler. For detailed information about using these commands, see the
chapter "Controlling Schedules and Jobs" in the Unicenter CA-Scheduler
There are, however, a number of different places where you can enter the
operator commands. This is done to make it practical for you.
Online Monitoring panel
When you are on the Online Monitoring panel, the operator
commands that can be used for schedules and jobs are listed
under the headings SCHEDULE COMMANDS and JOB
COMMANDS, respectively. If you want to issue one of the
commands you must enter the number that appears next to it
on the command line (===>). You may enter keywords by
separating them from the number and from each other with
commas. If you run out of room to enter keywords, follow a
keyword=value combination with a comma and press Enter.
Another panel will then be displayed to allow the entire
command to be entered.
Online Status panel
When you display status using the Online Status panel, a
subsequent panel is displayed with the data requested. It is
called the Schedule Command Processor panel. It is on this
panel that you can issue operator commands that pertain to
schedules and jobs.
Issue the commands by moving your cursor to the left of a
schedule or job and enter an abbreviation of the command.
For example, enter CANC for CANCEL. You can enter as
many commands on one panel as you need. See the chapter
"Online Monitoring" for a list of the command abbreviations.
When you use this method, you cannot use optional
keywords, only the command.
Be careful when you position your cursor. It is easy to put it
on the wrong line. You could end up cancelling a schedule
instead of a job, or cancelling the wrong job.

Operator Console
Any operator command can be issued from the operator
console by directing it to Scheduler. Prefix the command with
SC followed by a blank space.
Batch Program (CAJUCMD0)
Operator commands can be issued from a batch program
called CAJUCMD0 which means that you could embed a step
calling this program in your production JCL that could take
certain actions dependent on, for example, condition code
settings. Since you have the ability to cause any Scheduler
operator command to be issued, you could send messages to
specific users or the operator console, you could start another
job, or you could set global variables.
You can even issue these commands based on conditions
coded in an IF statement. You can test against the status of
other jobs, any schedule, user-defined globals, and many
others. The subtopic Issuing Online Operator Commands In
Batch Mode in the chapter "Techniques" describes this in
detail.
6.1.4.2 What Is the Difference Between FORCE, SUBMIT, RERUN, RUN, ADD,
REQUEST, and SREQ?
Each of these commands causes a job or schedule to be activated in some form.

The following describes how each command works.
FORCE Causes a schedule on the tracking file to be started regardless
of why it is currently waiting. It also can cause a job to be
submitted regardless of why it is currently waiting.
SUBMIT and RERUN
Cause a job to be resubmitted. It will not wait for an early
time or for predecessors: it is submitted immediately. If the
schedule that owns the job is not in START status, it will be
set to START status. Use RERUN or SUBMIT instead of
FORCE when a job has abended, failed, ended, canceled, or
been interrupted. FORCE is used to make a job start the first
time. RERUN substitutes Unicenter CA-Driver restart
parameters if LIBTYPE=DRIVER is defined and the JCL is not
staged or restaged. The only difference between SUBMIT and
RERUN is the Unicenter CA-Driver parameters they use:
SUBMIT uses the normal parameters while RERUN triggers
the restart parameters.
RUN Causes a schedule or job that exists on the database to be
added to the tracking file. These schedules and jobs are ones
that were not selected in today's workload or they may have
been canceled or completed. This is different than FORCE and
RERUN in that a fresh copy is obtained and all times,
predecessors, and resources are properly evaluated.

If the job or schedule is already on the tracking file (it would

be in a completed or canceled status), the older one is purged
from the tracking file. If the job is on the tracking file and not
completed or canceled, then the RUN command is in error.
With the RUN command, you can place the schedule or job in
a HELD status. This will give you a chance to take any other
manual actions you deem appropriate. Further, when you use
the RUN command to pull in a schedule, you can give it a
date so that only applicable jobs in the schedule are selected.
ADD Causes a job to be added to the tracking file. The job does not
have to be on the database. If it is on the database, you would
use this command instead of the RUN command if you
wanted to change any keyword values. Normally, you only
use ADD for one-time jobs.
You do not have to specify a schedule name. If you do, it will
be added to that schedule. If you do not specify a schedule
name, it will use a schedule name of $DYNx, where x is the
POWER SYSID of the system from which the command was
issued.
REQUEST and SREQ

Cause a REQUESTED schedule or job to be activated which
means it is moved from the inactive queue to the active
queue. Once in the active queue, it is handled normally.
The way that a schedule or job is made 'on-request' is by
giving it a selection criteria of REQUESTED. A REQUESTED
criteria causes the schedule or job to be selected every day
and placed on the tracking file.
The difference between REQUEST and SREQ is that, with
REQUEST, the REQUESTED schedule or job is moved to the
active queue along with all its successors. The SREQ
command handles successors differently: SREQ will not
activate a successor if it involves other requested jobs. A
successor of an SREQed schedule or job will not be moved to
the active queue if:
The successor's criteria statement contains the keyword
REQUESTED or
That successor is also the successor of some other
requested job in the inactive queue
There is a separate subtopic devoted to requested jobs in the
next chapter. If you plan to use this facility, you should
review the subtopic on REQUESTED work.

6.1.4.3 Summary
For jobs in the tracking file:

■ Use RERUN or SUBMIT for jobs that ended abnormally or were canceled.
■ Use FORCE to submit jobs if you are willing to violate their reasons for
waiting.
■ Use requested or SREQ for requested jobs.
For jobs not on the tracking file:

■ Use ADD to put a job on the tracking file if it does not exist on the
database or if it is on the database, but you need to change its keywords.
■ Use RUN to submit jobs in the database if you do not need to change their
keywords.
6.1.4.4 When Is the PRED Flag Reset?
When you use the PRED keyword in the criteria language, it indicates that the
schedule or job is to wait for a predecessor to complete. When you do not use
the keyword PRED, the predecessor is to complete within the autoscan day.
When you specify PRED in front of the predecessor, it means the predecessor
was to have completed since the last time this schedule or job was run. There
is an exception, however. If the PRED is a schedule or job that is in today's
workload, it will wait for that specific one to complete. For example, if a job
has a predecessor of PRED DSN JOBA.MASTER, the output data set
JOBA.MASTER must have been closed at least once between each running of
that job. If the job is run weekly, then it must have been closed at least once
during the last week.
Normally in the selection process (during autoscan), job names cause selection
if the predecessor job was selected. When PRED precedes a schedule name or
job name, it is not used in determining selection, but is a predecessor condition
only. All other criteria rules still apply.
6.1.4.5 What Happens If There Was a System Crash?
The following discussion is appropriate to a system crash or if Unicenter

CA-Scheduler does not complete normally.
Unicenter CA-Scheduler is able to recognize whether a clean shutdown

occurred. When a clean shutdown did not occur, upon starting back up,
Unicenter CA-Scheduler does the following based on the status of the job at
the point Unicenter CA-Scheduler was last active:
Status At Failure Sets New Status To

STARTED UNKNOWN - The job may have to be rerun, but
requires investigation by a troubleshooter.

Status At Failure Sets New Status To

SUBMITD Unicenter CA-Scheduler issues the POWER command to
determine if the job is in the POWER queue. If the job is
not in the POWER queue, it is placed in a status of
UNKNOWN. If the job is in the POWER queue,
Unicenter CA-Scheduler issues the POWER command to
place the job on POWER HOLD and then places the job
in a status of AUTO RECVRY HELD if
RECOVERABLE=NO on the Job Definition panel. If
RECOVERABLE=YES was specified and the job is in the
POWER RDR queue, the job is released and ready to
run.
WAITING As long as a job was waiting for any reason, it is placed
anything in a status of AUTO RECVRY HELD if the job was
defined with RECOVERABLE=NO. If it was defined
with RECOVERABLE=YES, it will take on the last
known status and be reevaluated (for example, it may
now meet its early start time). This ensures that you
have time to review it.
Once Unicenter CA-Scheduler has set all of the preceding status codes, it is up
to you to review the jobs and rerun appropriate jobs, mark current status on
others, and ensure the current status of each is correct. To see the status of the
job prior to the outage, use the HELD, AND WHEN option on the Online
Status panel. A lot of jobs will be left with a status of AUTO RECVRY HELD.
To restore their status to what it was at the time of the system crash, issue the
command:
RELEASE AUTO
These remaining jobs will be handled as if they had RECOVERABLE=YES

specified on their Job Definition panel.
Everything should now be back to normal.

6.2 Pitfalls
6.2 Pitfalls
This topic discusses some of the pitfalls you may encounter.
6.2.1 Using Operator Commands on the Status Display Panel

You are able to issue operator commands from a status display by just keying
in the command (first four characters) to the left of the schedule or job. You
can even issue more than one command at a time.
Pitfall: When keying in a command to the left of a schedule or job in the
Online Status Display, be sure you are on the correct line. It is easy
to cancel the wrong job.
While on the subject of operator commands in status displays, here is a
clarification, not a pitfall. Remember, when using the commands in this
manner, that they are processed sequentially and stop being processed upon
encountering an error. For example, there is no reason to cancel a schedule and
then the jobs in that schedule.
6.2.2 Cancelling and Purging a Job

Suppose you have a schedule that consists of four jobs: JOB1 through JOB4.
JOB2 requires JOB1; JOB3 requires JOB2; and so on. If you CANCEL JOB3,
whether you also PURGE it, JOB4 will always wait for JOB3. You can
manually override this with a POST or FORCE command.
Suppose that JOB3A has JOB3 as a predecessor. If JOB3 is canceled and not
purged, the predecessor JOB3 is ignored when you issue a RUN JOB3A
command because JOB3 has been canceled but is still on the tracking file. If
you purge JOB3 before issuing the RUN JOB3A command, JOB3A waits for
JOB3 to complete. You have to RUN JOB3 to put JOB3 back on the tracking
file.
Do not use the PURGE command unless you plan to put the job back on the
tracking file by issuing a RUN command.
Pitfall: Predecessors for jobs added to this day's production using the RUN
command are ignored if they have been canceled by the CANCEL
command but not deleted from the tracking file by the PURGE
command.
6.2.3 Changing Criteria on Selected Jobs

When a schedule or job has been selected, Unicenter CA-Scheduler reviews its
predecessor criteria as it exists on the database. What this means is that if you
have a schedule of four jobs: JOB1, JOB2, JOB3, and JOB5, where JOB2 requires
JOB1, JOB3 requires JOB2, and JOB5 requires JOB3. The schedule has been
selected and is on the tracking file. You then add JOB4 and change the

6.2 Pitfalls
predecessor criteria of JOB5 to now also require JOB4. If JOB5 had not yet
started, when it is evaluated to start, it will require JOB4, but JOB4 was never
selected. Therefore, JOB5 will never be submitted. It will always be awaiting
JOB4. If this happens, we recommend that you CANCEL and PURGE JOB4
and then issue an ADD command for JOB4.
Pitfall: When changing predecessor criteria on the database for jobs
that are selected and are already on the tracking file, be aware
that the jobs on the tracking file will be evaluated based on
the most current data on the database. Do not change the
criteria of active jobs.
6.2.4 Backlogging Over Two Autoscans

The subject of backlog is covered in the topic Backlogged Work in the chapter
"Techniques." When a schedule gets backlogged (autoscan occurred before the
schedule completed) due to the first autoscan occurring, it is handled as you
would expect. If, however, it does not finish before the next autoscan (meaning
it has been in the system for 48 hours), when it does finish, the new schedule
that is loaded is evaluated for the autoscan day on which it is loaded which
means that if a schedule that is selected on both Monday and Tuesday and has
its Monday's version backlogged until Wednesday; Tuesday's version will
never be run. That is because the evaluation takes place when Monday's
schedule completes, which is Wednesday, but it does not run on Wednesday.
Always watch backlogged work carefully.
Pitfall: Backlogged work that goes beyond a 48-hour period can be
lost if not monitored carefully.
6.2.5 Resetting Global Parameters

Global parameters are initialized only when the tracking file is initialized. They
are not reset at autoscan time. Once a value of a global parameter is set, it is
only reset when someone actually changes its value to something else. That is,
predecessor evaluation of schedules and jobs takes place based upon the
current value of the global parameter regardless of when that value is set.
If the preceding is not the way in which you desire to operate, you could have
a batch job that is submitted at a specific time (say immediately following
autoscan) that executes the Unicenter CA-Scheduler program CAJUCMD0 and
supplies transactions that set the global variables to the values you want.
Therefore, the pitfall:
Pitfall: A global parameter only gets set. If you want it reset, you
must set it to another value. There is no such thing as
resetting a global parameter.
Once a global parameter is set to a specific value, all unsatisfied predecessors

are reevaluated. If any schedules or jobs are waiting for that global parameter
to take on that value, those global predecessors are marked as satisfied.

6.2 Pitfalls
Satisfaction can only be reversed by changing the GBLxnn parameter and

cancelling the affected schedule or job and then issuing a RUN command to
reselect that schedule or job.

Chapter 7. Techniques
This chapter of the manual is intended to clarify various topics within

Unicenter CA-Scheduler. In some instances, techniques are discussed while in
other cases, the topic resembles a tutorial. Each topic stands on its own so you
can jump from topic to topic. Do not be concerned about reading these topics
in the order they are presented.
Chapter 7. Techniques 7-1

7.1 On-Request Schedules and Jobs

This topic discusses on-request schedules and jobs and gives you many
examples of criteria language.
7.1.1 Discussion
On-request schedules and jobs are ones that are selected every day, and placed
in an inactive queue, in case they are needed. They remain in an INACTIVE
status until they are activated by an operator command which means that you
cannot determine in advance whether the schedule or job will be needed on
any particular day.
You define an on-request schedule or job using REQUESTED, a Gregorian

calendar reserved word, in its selection criteria.
When the autoscan process runs, all REQUESTED schedules and jobs are
selected along with their successors and placed in Unicenter CA-Scheduler's
tracking file in an inactive queue. The only way they can be removed from the
inactive queue is using the operator command REQUEST or SREQ. When
removed from the inactive queue, they are placed in the active queue and will
then be handled as normally selected jobs.
An important difference between the REQUEST and SREQ commands is that

REQUEST also places the successor schedules and jobs in the active queue.
The SREQ command handles successors differently: SREQ will not activate a
successor if it involves other requested jobs. A successor of an SREQed
schedule or job will not be moved to the active queue if:
■ The successor's criteria statement contains the keyword REQUESTED or
■ That successor is also the successor of some other requested job in the
inactive queue
All schedules and jobs that have not been requested by the next autoscan are
purged from Unicenter CA-Scheduler's tracking file, regardless of which
BACKLOG values they had defined.
There is a guideline you should follow when using the REQUESTED keyword:
To ensure that simulation produces reason codes that match those produced
by Unicenter CA-Scheduler, specify REQUESTED after job and schedule names
in selection criteria whenever possible.

7.1.2 Criteria Language Subtleties

The best way to explain these subtleties is with examples. Each example
assumes that the jobs described are all contained in the same schedule.
Although you should always specify schedule names with job names in criteria
statements, they are omitted in the examples following to keep things simple.
7.1.2.1 Example 1
Job Criteria
JOBA REQUESTED
JOBB JOBA
JOBC JOBB
In the preceding example, all three jobs will be placed in the inactive queue
every day.
7.1.2.2 Example 2
Job Criteria
JOBA MON AND REQUESTED
JOBA will be placed in the inactive queue every Monday.
7.1.2.3 Example 3
Job Criteria
JOBA MON OR REQUESTED
The preceding example follows the same rules as MON when selected on
Monday and treated as a normal job (meaning that on Mondays, it is placed in
the active queue and it does not have to be requested). Any other day, it will
be treated as a requested job.
7.1.2.4 Example 4
Job Criteria
JOBA REQUESTED
JOBA1 None
JOBB JOBA OR JOBA1

In the preceding example, all jobs will be selected. JOBA and JOBB will be
placed in the inactive queue. JOBB is placed there because JOBA is the first
predecessor specified and it is a requested job. The ordering of these
predecessors is important as you will see with the next example.
JOBA1 will be run whenever its conditions allow (if there are none, it will start
immediately).
JOBB will always wait for JOBA1 (that is, you could request JOBB without
requesting JOBA). If JOBA is requested (with the REQUEST or SREQ
command), JOBB will automatically be requested and will wait for both JOBA
and JOBA1.
If no requests are made, JOBA and JOBB will be purged from the tracking file
at the next autoscan.
7.1.2.5 Example 5
Job Criteria
JOBA REQUESTED
JOBA1 None
JOBB JOBA1 OR JOBA
The preceding example is the same as the one previous except for the order of
the predecessors on JOBB. All three jobs will be selected, but only JOBA is
placed on the inactive queue. This is because JOBB got selected because of
JOBA1, which is selected whenever the schedule is selected.
JOBB will always wait for JOBA1, but will only wait for JOBA if JOBA is
requested (using the operator command REQUEST or SREQ) before JOBA1
completes.
If JOBA is not requested, it will be purged from the tracking file at the next
autoscan.
7.1.2.6 Example 6
Job Criteria
JOBA REQUESTED
JOBB JOBA AND REQUESTED
Both JOBA and JOBB will be placed in the inactive queue at autoscan time.

When the operator command REQ J N=JOBA is issued, both jobs (JOBA and
JOBB) will be moved to the active queue.
When the operator command SREQ J N=JOBA is issued, only job JOBA will be
moved to the active queue. JOBB will not be moved since it has the criteria
AND REQUESTED that must be satisfied. It is not satisfied using the SREQ
operator command with its predecessor JOBA. To move JOBB to the active
queue, in this case, use the REQUEST or SREQ command.
7.1.2.7 Example 7
Job Criteria
JOBA REQUESTED
JOBB MON OR JOBA
On Mondays, JOBB will be added to the active queue and will not wait for
JOBA unless it is also in the active queue. That is, JOBA will not be considered
a predecessor of JOBB unless JOBA is requested with the REQUEST or SREQ
command before JOBB is submitted. Once JOBA and JOBB are both in the
active queue, Unicenter CA-Scheduler will not submit JOBB until JOBA has
completed.
7.1.2.8 Example 8
Job Criteria
JOBA REQUESTED
JOBA1 REQUESTED
JOBB JOBA OR JOBA1
JOBC JOBA
All four jobs will be placed in the inactive queue at autoscan time.

When the operator command REQ J N=JOBA is issued, JOBA, JOBB and JOBC
will be moved to the active queue. This occurs with JOBB and JOBC since
neither of them are requested jobs, but rather each of them only require JOBA
to be selected. If JOBA1 were the requested job, then JOBA1 and JOBB would
be the ones moved to the active queue.
When the operator command SREQ J N=JOBA is issued, JOBA, JOBB, and
JOBC will be moved to the active queue having the same result, in this case, as
issuing the REQUEST command.
7.1.2.9 Example 9
Job Criteria
JOBA REQUESTED
JOBA1 REQUESTED
JOBB JOBA OR JOBA1
JOBC JOBA AND REQUESTED
JOBD JOBA AND JOBA1
All five jobs will be placed in the inactive queue at autoscan time.
This example closely resembles Example 8. Following is what happens when

the SREQ command is used with JOBA. In this case, JOBB will still be moved
to the active queue, but JOBC and JOBD will not. That is because JOBC's
criteria includes the REQUESTED keyword, and JOBA1 (JOBD's predecessor)
was REQUESTED. Issuing the command SREQ JOBC will move JOBC to the
active queue. To move JOBD to the active queue, SREQ both JOBA and
JOBA1.
7.1.2.10 Example 10
Job Criteria
JOBA NONE
JOBB REQUESTED
Both these jobs are in a schedule called SCHDA. SCHDA has a criteria of
REQUESTED. At autoscan time both JOBA and JOBB will be placed in the
inactive queue.

When the operator command REQ S N=SCHDA is issued, JOBA and JOBB will
be moved to the active queue.
When the operator command SREQ S N=SCHDA is issued, only JOBA will be
moved to the active queue.

7.2 Backlogged Work
7.2 Backlogged Work

There will be times when schedules or jobs will not complete the day on which
they were selected which means that they may be candidates for being
backlogged, but first, define what a day is.
In terms of your company, a day would be your normal daily business

computer cycle. For example, production work starts at 16:00 and is to be
completed by 08:00 the next morning. This is fairly typical which means you
run autoscan at, or shortly after, 08:00 (to select schedules and jobs for the next
16:00 to 08:00 time period). Thus, in terms of Unicenter CA-Scheduler, a day is
the 24-hour period that starts with the time that you run autoscan. This is
termed the production day or autoscan day.
Schedules and jobs that do not complete on the production day on which they
were selected can be carried over to the next production day. They are then
called backlogged schedules or jobs. When you define a schedule or job to the
database, specify whether that schedule or job is a candidate for backlog.
Normally it is.
What happens if the work for a production day is not complete is next
described.
Job Backlog The normal situation allows schedules to be backlogged.

When autoscan is initiated and it is determined that a
schedule is still active (it has not finished running yet),
the schedule will be backlogged. Any job in the schedule
that has completed, been canceled, or purged will retain
its status. If a job has been defined with
BACKLOG=YES, it will be backlogged if it had not
started. That is, it will be allowed to run. If a job in the
backlogged schedule has been defined with
BACKLOG=NO and still has a status of WAITING, it
will be canceled with a status called NO BACKLOG
CNCL.
Once all jobs in the backlogged schedule have been
completed or canceled, the schedule will be marked as
complete. If the same schedule was also selected on the
current production day, then it and its associated jobs
will be placed on the Unicenter CA-Scheduler tracking
file and processed as if it had been selected normally.
If a daily schedule gets backlogged for greater than 24
hours (that is, it is backlogged by two autoscans), then
when it completes, the schedule to execute on the
completed day is loaded to the tracking file. For
example, if Monday's schedule gets backlogged and

7.2 Backlogged Work
completes on Wednesday, Tuesday's schedule will never

be run.
Schedule Backlog When BACKLOG=YES or NO is specified on a schedule
definition, it acts only as a default for jobs in that
schedule when BACKLOG is not specified on a job.
Then it is handled as described in the previous
paragraph under the caption Job Backlog.
Requested Jobs
And Schedules Jobs and schedules that are ON-REQUEST and are still
in the inactive queue at autoscan time will be purged,
regardless of their BACKLOG value.
7.2.1.1 In Summary
NO BACKLOG CNCL is a status code that means the job was canceled at the
end of the day because it had not yet started and it was defined as, or
defaulted to, BACKLOG=NO. The jobs carrying this status have not yet started
and will not be run. As soon as the schedule ends, they will be purged.
When history is generated for these NO BACKLOG CNCL jobs, they will show
up on the Pending Job Profile Advantage CA-Earl report for the current
production day.
When a schedule is backlogged and it is also to be selected for the current

production day, the one being selected will not be placed onto the Unicenter
CA-Scheduler tracking file until the backlogged one completes. Only one copy
of a schedule at a time will be kept on the tracking file. Therefore, if for some
reason a schedule occurs daily and is backlogged twice, the schedule for the
middle day would never be brought in. Another example is that if a schedule
runs Monday and Tuesday only, and Monday's schedule gets backlogged until
Wednesday, Tuesday's schedule will never be run. This is because when
Monday's schedule finishes and Tuesday's is brought in, it is evaluated for
Wednesday. Since there is nothing in this schedule to run on Wednesday, it
will never get started.

7.3 Issuing Online Commands in Batch

A utility program (CAJUCMD0) is provided with Unicenter CA-Scheduler that
allows you to:
■ Send operator messages to system console
■ Issue Unicenter CA-Scheduler operator commands
■ Issue VM commands (if you are running under VM)
■ Issue POWER commands
■ Issue CICS CEMT commands or start user transactions
When you combine the facility with some language flexibility, you have
considerable power. For example, you could test the condition code of a step
in the middle of a job and based on its setting cause some other job or
schedule to be released to run. Or if a particular job was submitted before this
job, you could place some other job on hold. There are a whole set of status
conditions that you can check. These are described later.
A more detailed discussion on the format and use of this facility exists in the
chapter "Unicenter CA-Scheduler Commands in Batch Mode" in the Unicenter
7.3.1 Transaction Format

There are six types of transactions, you have to tell the CAJUCMD0 program
which type you are describing which you do by prefixing each transaction
with a two-digit code as follows:
Prefix Transaction Type

MO Send the following text to the operator console.
SC Issue the following Unicenter CA-Scheduler operator
command, which can include the conditional batch IF
statement.
CP Issue the following VM command.
PW Issue POWER commands.
CI Issue CICS Transactions.
DM Issue commands stored in the documentation library.

The preceding commands can be executed conditionally based upon the setting
of a global parameter or the status of a schedule or job. This introduces the SC
transaction that is used with the IF statement. The IF statement can even have
AND, OR, and NOT keywords. For example:
Transaction:
SC IF JOBA INTRPTD SC STATUS S=PAYSCHD
Read as:
The job that is executing CAJUCMD0 right now wants to determine if the job
JOBA is in an interrupted status. If it is, Unicenter CA-Scheduler will print the
status of the schedule PAYSCHD and all its jobs.
The following describes using the NOT keyword.
Transaction:
SC IF JOBA NOT COMPLETE SC HOLD J N=JOBB
Read as:
The job that is executing CAJUCMD0 right now wants to determine whether
or not JOBA completed. If it has not, Unicenter CA-Scheduler will place JOBB
in HELD status.
7.3.2 Status Checking

In the previous examples, the portion of the IF statement that reads JOBA
INTRPTD and JOBA NOT COMPLETE is called a condition. There can be
more than one condition in an IF statement. In this case, they would be
separated by an AND or an OR keyword. If the condition pertains to a
schedule or job, the right-hand part of the condition is the status to check
against. If you are looking at a global, the right-hand part is the value of the
global you want to check.
There are two levels of status codes. The major level is a code such as
INTRPTD or COMPLETE (as in the previous examples). This is termed the
major status code. There are some major status codes that can be optionally
qualified with a minor status code. An example of a major status code with a
minor status code would be WAIT PRED. WAIT is the major status code and
PRED is the minor status code. One example is asking if a schedule or job is in
a WAIT status for predecessors. Another example is WAIT START, which is
asking if a schedule or job is waiting for its early start time to be met.

To have an appreciation for the flexibility of this capability, all of the different
status codes are listed in the following tables.
Major Minor Description

ABENDED The job abended.
CC=dd The job abended with a completion code of

X'dd' (for example, X'FF').
ACTIVE The schedule or job is active in the system.
It is not necessarily running, but it is not
on HOLD.
CANCEL The schedule or job was canceled:
BACKLOG It carried over to the next production day

as backlog
OPER By an operator
COMPLETE The schedule or job ran to completion. This
includes abended, failed, and canceled jobs.
(The status display indicates ENDED.)
FAILED CC=nnnn The job failed with a FAILCODE of nnnn
HELD The schedule or job was held:
AUTO Due to automatic recovery
OPER By the Unicenter CA-Scheduler HOLD

command
LATE The schedule or job caused a late message
to be issued because it:
DEAD Did not finish by the COMPLETION

DEADLINE time
MAX Exceeded the MAXIMUM EXECUTION

time
MUST Did not start by the MUST START BY time.

INTRPTD The job was interrupted.
NOTREQ The schedule or job is in the inactive
queue.
STARTED The schedule or job is executing.
SUBMITD The job has been submitted.

Major Minor Description

SUBMFAIL The job was submitted, but failed.
WAIT The schedule or job is waiting for:
OPSUB Operator submission (jobs only)
PRED A predecessor to be satisfied
RESC Defined resources (jobs only)
START Its early start time.
7.3.3 Some Examples

The following examples show how you might issue some commands in batch.
7.3.3.1 Example 1
Suppose you have an online application called NETSCD and when it is shut
down, you want to set an indicator that allows a set of backup jobs to begin
processing. You can assign a global parameter to this function. Assume a
global parameter GLBC4 and assign it a value of NETSCDUP when the system
is running, and the value NETSCDWN when the system is not running and
backups can be taken.
You would use the following transaction in one of the first steps when starting
up the NETSCD task. This step would execute the CAJUCMD0 program.
SC SET GLBC4=NETSCDUP
This means that whenever the NETSCD task is running, the global parameter
GLBC4 is set to a value other than NETSCDWN.
Now, when the system is shut down, one of the last steps is to set GLBC4 to
the value NETSCDWN, which will allow the backup jobs to be started. The
transaction for the step that executes the CAJUCMD0 program will be:
SC SET GLBC4=NETSCDWN

7.3.3.2 Example 2
This example is a series of transactions and how they can be coded:
Transaction:
SC IF SCD PAYSCHD STARTED SC S S=NEXTSCHD
Read as:
The job that is executing CAJUCMD0 right now wants to determine if the
schedule PAYSCHD has started. If it has a status of STARTED, the status of
the schedule NEXTSCHD and all its jobs will be printed.
Transaction:
SC IF JOBA COMPLETE CC=10

SC TALT S N=NEXTSCHD ERLYTIME=0900
Read as:
The job that is executing CAJUCMD0 right now wants to determine if the job
JOBA completed normally. If it did, the early start time of the schedule
NEXTSCHD will be altered to 9:00 a.m. in the morning.
Transaction:
SC IF GBLA01 NOT 5 SC GBL
Read as:
numeric global parameter number 1 (GBLA01) contains a value other than five.
If it does, a list of all current global values will be printed.

Transaction:
SC IF GBLC02 NULL
MO REVIEW THE CURRENT GLOBAL
Read as:
alphanumeric global parameter number 2 (GBLC02) does not contain any
value. If there is no value, the console operator is notified to review the values
of all of the globals.
Transaction:
SC IF JOBA-2 40 PAYSCHD WAIT START AND

GBLB16 YES SC S
Read as:
The job that is executing CAJUCMD0 right now wants to determine if the CPU
job JOBA with job number 02 (JNO) contained in schedule PAYSCHD is
waiting for its early start time and the 16th binary global parameter is set to
YES. If so, a complete status of all schedules and jobs will be printed.

7.4 Restart/Recovery of Scheduled Jobs

This topic discusses methods of restarting and recovering scheduled jobs that
are defined in Unicenter CA-Scheduler's database and were selected as part of
the day's production during the most recent autoscan process.
Recovery of jobs after a system crash is discussed in the chapter "Tips" with
the question What happens if there was a system crash? This includes the
various Unicenter CA-Scheduler status settings.
Recovery of jobs as they pertain to a multi-CPU environment is discussed in

the topic Multi-CPU Considerations later in this chapter. That discussion
describes how jobs can be moved as a group from one CPU to another when
one CPU goes down.
In this topic, it will be discussed how you determine which jobs have abended,
what type of manual actions you can take, what type of automatic facilities are
available within the Unicenter CA-Scheduler database, and then discuss how
you could use Unicenter CA-Driver to automate the recovery process.
Unicenter CA-Driver is a component of Unicenter CA-Scheduler that provides
a JCL handling facility.
7.4.1 Inquiring About Jobs to Be Recovered

From the Online Status panel (which you can get to from the Main Menu or
the Online Monitoring panel), you have a set of status codes from which you
can display jobs that might need recovery if they are not set up to recover
automatically. The status codes that would indicate recovery may be necessary
include:
Status Code Description

ABENDED The job has abended with an abend code such as
X'1A'. It can be rerun by using the RERUN or
SUBMIT operator command.
OPERATOR CANCLD The job has been canceled by an operator using the
CANCEL operator command. This job can be run
again by using the RUN, RERUN, or SUBMIT
command.
FAILED The job has failed with a condition code that
exceeds the value specified in the FAIL CODE field
when defining the job or has failed on a JCL error.
It can be rerun by using the RERUN or SUBMIT
operator command.

To recover any job, its JCL is either in the staging library or can be placed
there by the RESTAGE operator command. Once it is in the staging library,
you can modify it and resubmit the job.
7.4.2 Automatic Recovery Options

When defining a job to the database, there is a field called ABEND, which can
be used to aid in automatic recovery of a job. There are four options you can
specify in this field. They include:
Option Description
ABORT Indicates that successors to this job will not have
this predecessor satisfied. This is the default value.
CONT Indicates that successors to this job are to be
handled as if the job terminated normally because
this predecessor has been satisfied.
BACKOUT Indicates that successors to this job will not be
posted as satisfied if this job abends. A backout job
will be submitted automatically if you specified a
value for the BACKOUT installation option.
Unicenter CA-Scheduler adds a new job tracking
record for the backout job.
Schedule name Indicates that the schedule name provided is to be
processed. This is a predefined recovery schedule
that will be automatically processed should the job
abend and the abended job will follow the same
process as ABORT.
If a recovery schedule is defined, it could contain a job that executes the

CAJUCMD0 program that allows you to interrogate various job's status
through batch commands. Based on the job status, other jobs could be brought
in with the RUN, REQUEST, or ADD operator commands for recovering the
abended job. This technique is described in the preceding topic of this chapter.
When you define a recovery schedule, you should attempt to use some sort of
naming convention so that any recovery schedule can be recognized quickly.
For example, begin all recovery schedule names with RR.
Another way to be sure that jobs that need recovery do not go unnoticed is to
use the message facility. That is, you can specify up to four users to send
messages to if the job abends or fails. Users are defined on the schedule and
job message records and can be operator consoles or the Unicenter
CA-Scheduler mailbox. (See the topics Defining A Schedule Message Record
and Creating A Job Message Record in the chapter "Maintaining the Database"
for more information.) Keep in mind that JCL errors for a job are treated as if
the job failed.

7.4.3 Unicenter CA-Driver Considerations

Implementing a job step restart process is inherently complex due to all of the
variations of abend conditions. As with the implementation of any automated
system, the 'cure' should not cause more disruption than the problem.
For example, in a multi-step job, Step 5 abends. The determination is made

through the automated process that exists today, that Step 5 relies on the
temporary data set that was created in Step 2. Therefore, the data sets that
were created in Steps 2, 3 and 4 must be removed from the VSAM USERCAT.
What cannot be determined through any automated process is that the data set
created by Step 1 and used for input by Step 2 was created using incorrect
input. Herein lies the problem of automating the restart/recovery process.
There are many options available to a data center to effect proper

restart/recovery. A more automated method can be achieved by using
Unicenter CA-Driver, an optional component of Unicenter CA-Scheduler/VSE.
Unicenter CA-Driver is a powerful JCL and runtime management facility that
can work hand-in-hand with Unicenter CA-Scheduler. You can define jobs to
Unicenter CA-Scheduler that store their JCL with Unicenter
CA-Driver-managed procedures. Unicenter CA-Driver controls the expansion
of these 'procs' based upon values that you supply.
When defining jobs to Unicenter CA-Scheduler that find their JCL in Driver
procs, Unicenter CA-Scheduler will also ask you to define normal runtime
parameters and rerun runtime parameters. The normal runtime parameters
will be passed from Unicenter CA-Scheduler to Unicenter CA-Driver when it is
time to submit the job. The panel (Unicenter CA-Driver restart parms)
parameters will be passed from Unicenter CA-Scheduler to Unicenter
CA-Driver whenever the job is being rerun using the Unicenter CA-Scheduler
RERUN command. Thus, this facility gives you the flexibility to have your
Unicenter CA-Driver procs expanded differently depending on the
circumstances at the time.
Unicenter CA-Driver also provides you with the ability to test VSE completion
codes and return codes between steps of a job. The results of these tests can be
used to execute steps of a job conditionally.
Unicenter CA-Driver is a very useful tool. To really get to know all of the
facilities of Unicenter CA-Driver and how they can be used, refer to your
Unicenter CA-Driver Reference Guide.

7.5 Multiple CPU Considerations

Unicenter CA-Scheduler, as you have seen throughout this manual, has a great
deal of flexibility. When it comes to scheduling and controlling production on
more than one CPU, this flexibility continues to exist. In this topic, however,
we are going to discuss the manner in which most shops use Unicenter
CA-Scheduler in a multi-CPU environment.
First, you must get some basic IBM terminology out of the way. The term
SYSID will be used throughout this chapter.
SYSID is the system identifier that uniquely identifies each of the VSE
operating systems that execute in your environment. This is established by the
systems programmer when generating each of the VSE operating systems. At
times, the SYSID is referred to as the POWER SYSID.
You can allow POWER with shared spool to determine which CPU jobs run
on. You do this through control of the CLASS designations. That is, if a job is
to run in CLASS T, and there is a CLASS T on each CPU, then POWER will
determine which CPU on which to run the job. There will be times, however,
where you want a job to execute on a specific CPU (maybe it is the only place
where a program can get to a specific database). In this case, you can direct
POWER to execute the job on a specific CPU by specifying a RUN ON SYSID
value in the job base record.
If Unicenter CA-Scheduler is submitting your JCL from LIBTYPE=CMS, it may

not be necessary to generate POWER with shared spool. In this case, the
Unicenter CA-Scheduler CMS service machine will do what non-shared power
spool cannot—route the JCL to the correct POWER SYSID. This can be
accomplished by creating a file that contains the POWER SYSID and the VSE
guest machine name. The file has a filename of SCDSYSID and a filetype of
USERID and must reside on a CMS disk that is accessible to the Unicenter
CA-Scheduler CMS service machine. The Unicenter CA-Scheduler CMS
service machine will match the SYSID in this file with the RUN ON SYSID
value (SYSID=) in the job base record and submit the job to the corresponding
VSE guest machine. There must be at least one blank between the POWER
SYSID and the VSE guest machine name as follows:
1 VSEPROD1 2 VSEPROD2 3 VSEPROD3
Unicenter CA-Scheduler will generate the appropriate POWER JECL JOB

statement with the SYSID= parameter whenever a RUN ON SYSID is specified
on the job base record.

7.5.1 Installation Considerations

When installing Unicenter CA-Scheduler, you have to indicate that it is going
to run in a multi-CPU environment which means that five things have to be
done.
1. You must code the parameter MCPU=YES in the CAIJGEN macro, which
indicates that you have a multi-CPU environment.
2. You must code the parameter SHARE=YES in the CAIJGEN macro. This
specifies that you are to share the Unicenter CA-Scheduler database and
associated files, which includes the database, the tracking file, the staging
library, and the documentation file and optionally the Unicenter CA-Driver
procedure library. This must always match the SHARE field on the
FORMAT and RESTORE commands (see number 4, following). By using
the SHARE database facility, you ensure the integrity of accessing the
databases and libraries from different CPUs at the same time, which is
done with software (spin) locks and not with IBM LOCKs.
3. You must code the parameter SYSID=(sysid1,sysid2,...) in the CAIJGEN
macro, which specifies the valid SYSIDs in your multi-CPU environment.
The first SYSID in the list is the default SYSID that governs which CPU
tracks schedules, which will be explained later. The list is also used to
validate any SYSID defined with a schedule or job.
4. You must specify INSRSYS=YES in the CAIJGEN macro to cause Unicenter
CA-Scheduler to insert the SYSID on the POWER job statement
automatically for designated jobs (jobs defined with a value for the SYSID
keyword on their job base records).
5. You must code the parameter SHARE=YES in the FORMAT statement
when initializing the Unicenter CA-Scheduler database (CAIJMST), the
tracking file (CAIJTRK), the staging library (CAIJSTG), and the
documentation file (CAIJDCM). It must also be performed when
formatting the the Unicenter CA-Driver procedure library. See the
Unicenter CA-Driver Systems Programmer Guide. This is done by executing
the program CAJUTIL0.
These steps are discussed further in the Unicenter CA-Scheduler Systems

Programmer Guide.
7.5.2 Control Of Jobs in a Multi-CPU Environment

Discussion in this topic pertains to multi-CPUs in a POWER shared spool
environment. This can be depicted as:

Normally you would not specify a specific CPU on which a job is to execute.
That is, you would let POWER determine which CPU is available to handle
the job and then let POWER start it on that CPU. This is called centralized
control. If you direct a schedule to a specific CPU by defining the SYSID from
which it will be controlled (by defining the SYSID on the schedule base
record), you will have a degree of decentralized control. The more schedules
you do this to, the more decentralized control you have.
In the case of decentralized control, be aware that the RUN ON SYSID fields
(and the equivalent SYSID batch keywords) on the schedule base record and
job base record perform different functions. RUN ON SYSID on the schedule
base record defines the CPU on which Unicenter CA-Scheduler controls the
schedule (that is, the CPU from which the schedule's jobs are submitted.) On
the other hand, RUN ON SYSID on the job base record specifies the CPU on
which the job actually executes.
The following steps through what happens in the control of a multi-CPU

environment on a daily basis.
Autoscan During the autoscan process, all schedules that have a SYSID
that matches the one for the CPU on which autoscan is being
run, will be selected for control on that CPU. That is, all jobs
will be submitted from the controlling CPU and internally

tracked there. Do not forget, the default SYSID is the first one
in your SYSID list specified when generating Unicenter
CA-Scheduler (CAIJGEN macro) and will be used for any
schedule defined without a SYSID.
If the job is actually executed on a CPU other than the
controlling one the other CPU will notify the controlling CPU
of any information it would have picked up itself, such as job
started and job completed, along with the termination code.
This is done by writing information on the tracking file to be
passed along as internal events. If any job is defined without
a SYSID, the default SYSID is the one specified (or defaulted)
at the schedule definition.
Operator Commands
When you issue operator commands, there are times that you
should be aware of which CPU is in control of the schedule or
job. That is, if you issue a CANCEL operator command for a
job that is not controlled on the CPU on which you are on, it
is written to the tracking file and within seconds (could be up
to 30 seconds), processed by the CPU controlling that job. If,
for some reason, the CPU is not able to handle it right away
(suppose it is down), as soon as it can, it will process the
command; even if it is hours later. The area on the tracking
file that passes these operator commands and status
information back and forth between CPUs is called the
Inter-Communication Records area (ICR).
The only operator command that cannot work in a multi-CPU
environment is the STATUS command using the priority
sequence. Since the priority order happens to be an in-core
mechanism, for performance reasons, each CPU has its own
list. Thus, when you request a display of jobs on another
CPU, the priority option cannot be used.
Do keep in mind that any operator commands that are issued
that have to execute on a CPU other than the one they were
issued from, will be sent across the ICR on the tracking file.
They will remain there until actually processed or purged.
When the down CPU becomes operational again and
Unicenter CA-Scheduler is subsequently started, Unicenter
CA-Scheduler determines if it missed an autoscan. If it missed
an autoscan, Unicenter CA-Scheduler immediately performs
an autoscan. If, during this autoscan, Unicenter CA-Scheduler
finds ICRs that are more than 24 hours old, it purges those
old ICRs without executing them.
Another consideration for multiple CPU environments is the
method for executing jobs at a CPU other than the controlling
CPU. To do this on a permanent basis, specify the SYSID of
the CPU at which the job will execute in the RUN ON SYSID
field of the job's base record. To alter the CPU for one

execution only, use the TALTER command with the SYSID

keyword.
Submission of Jobs
Jobs are always submitted from the CPU where their
schedules are controlled from. The proper POWER JECL JOB
parameters are generated if a RUN ON SYSID (SYSID
keyword) is specified on the job base record.
7.5.3 Recovery Of Jobs in a Multi-CPU Environment

The recovery process that is described here is when one of the CPUs in a
multi-CPU environment has an outage. Just because a CPU is down, it does
not mean the jobs set to execute there do not have to run; the work still has to
get done.
In the discussions that follow, there are two items that apply to practically all
recovery methods.
First, there is an operator command that is used to, essentially, move Unicenter
CA-Scheduler control of schedules from one CPU to another. You do this with
the operator command called MOVEOVER. This command should be used
only when there is a CPU outage.
Second, you are able to run the autoscan process for a down CPU with an
operator command called AUTOSCAN, on the CPU that is up. You do this by
specifying the CPU SYSID whose schedules and jobs you want to run on the
up CPU. This ensures that all work, even for the down CPU, is in the
production workload.
The following describes the various environments, as recovery is slightly

different if you are in a decentralized versus a centralized environment.
Decentralized In a decentralized environment, there are some schedules that
have a specific SYSID from which they are controlled. This
means that you have filled in the controlling SYSID in the
RUN ON SYSID field on the Schedule Definition panel.
Consequently, schedules will be controlled from their
respective SYSIDs which means that the environment contains
multiple Master CPUs.
Now, what happens if one of the Master CPUs goes down?
Move the schedules and jobs onto a Master CPU that is up.
You do this by issuing the MOVEOVER operator command on
the Master CPU that is to take control of the downed Master
CPU's jobs. Here is an example. If the downed Master CPU
has a SYSID of 1 and the new one has a SYSID of 2, then the
MOVEOVER operator command would look like:
SC MOVEOVER SYS=1,TARGET=2

If you knew the outage was going to be short, you could

MOVEOVER specific schedules by issuing this command for
each schedule you want moved over. The TARGET field is
optional and defaults to the CPU on which the MOVEOVER
command is being issued. It gives you the flexibility to issue
the command and cause it to be executed on another CPU.
At some point, the original Master CPU is available. It must
be given back control of Unicenter CA-Scheduler. Thus, you
use the operator command (from SYSID 1):
SC MOVEOVER RESTORE=Y
which will cause all schedules (even those currently executing)

that were controlled originally by the CPU that was down, to
be moved back.
Centralized In a centralized environment, there are no schedules that have

a user-specified SYSID from which they are controlled. This
means that you have never filled in the RUN ON SYSID field
when using the Schedule Definition panel. Consequently, all
jobs will be controlled on the first SYSID in the list of SYSIDs
defined in the CAIJGEN macro which is the the Master CPU.
All other CPUs in the list are Slave CPUs.
The simplest case is that if a Slave CPU is down, nothing has
to be done with Unicenter CA-Scheduler as POWER will have
been changed in a manner to handle this situation.
Now consider what must be done if the Master CPU goes
down. One of the Slave CPUs must be made the Master so
that Unicenter CA-Scheduler can continue controlling the
schedules and jobs. The workload from the Master CPU must
be moved over to the Slave CPU and the Slave CPU made to
simulate the Master CPU. You may do this by executing a
batch program, CAJMMOV0, but first you must use the
SHUTDOWN operator command to shutdown Unicenter
CA-Scheduler, then run the following job on the slave CPU.
// JOB CAJMMOV
// EXEC CAJMMOV
/
/&
After the job completes, bring up Unicenter CA-Scheduler on

that CPU again. It will now perform as the Master CPU.
Executing the CAJMMOV0 program on a CPU has a "permanent" effect, in that

the CPU will become the Master (control all schedules and jobs, and perform
AUTOSCAN) until the program is executed on a different CPU. If for any
reason a format of the tracking file becomes necessary, you must run

CAJMMOV0 again to designate the master CPU. Thus, when your "real"
Master CPU is back, execute the CAJMMOV0 program on the "real" Master,
before you bring up Unicenter CA-Scheduler, and things should be back to
normal.
7.5.4 Non-Shared POWER Considerations

This topic pertains to multi-CPUs in a POWER environment that is not shared.
This can be depicted as:
In this environment, you must specify a SYSID for each schedule you define
on the database, unless it is to be controlled from the first SYSID in the SYSID
list generated with the CAIJGEN macro.
Recovery in this environment is handled in the same way as the shared

POWER (multi-access) environment.
Do keep in mind that, in this environment, it is not possible to have a schedule

controlled at CPU1 and have that schedule's jobs be submitted to any other
CPU (CPU2 or CPU3) for execution.

7.6 NJE Processing
7.6 NJE Processing

NJE processing provides the ability to go beyond one data center complex.
That is, you can schedule and control production at different locations (even in
different cities). The different locations can have just one CPU or they may
have a multi-CPU environment, though each CPU must be a node on the
VTAM network.
In some cases, you may want to have just interdependencies across locations
properly handled. In other cases, you may want to go beyond this and have
jobs at one location submitted to execute at another location. These locations
are called nodes in the network of computer sites (or systems). The network
consists of two or more of these interconnected systems (nodes) that
participate in a VTAM communications network.
Using more common terminology, a job at one node can have a predecessor at
another node and Unicenter CA-Scheduler will know to wait for it. Each node
will be able to schedule its own work as if it were autonomous, but when it
has interrelationships with other nodes, they will be upheld properly. This is a
decentralized (Master/Master) environment. Each of these Master
environments (nodes) can have its own Master/Master or Master/Slave
environment and may be one or more CPUs themselves that utilize shared
spool.
Following are some samples that describe:
■ Cross-node job submission

■ Cross-node dependencies
■ Cross-node communications.
7.6.1 Cross-Node Job Submission

In a NJE environment, it is possible to have Unicenter CA-Scheduler cause
work to be submitted to run on other nodes. The appropriate VSE/POWER
JECL parameters (if omitted from the submitted JCL) are generated to handle
this, but what you want to accomplish here is to have you understand how
Unicenter CA-Sheduler operates in this environment.
The following depicts the general environment that the samples will reference.

7.6 NJE Processing
In the preceding diagram, the NODEA site is a single CPU using VSE\POWER
with NJE, and CA†SCHEDULER with the NJE option activated. Each CPU is a
node on a VTAM Network.
Sample 1 Schedule SCHDA is defined at node NODEA with no NODE

ID specified.
This is the normal case and it will always be controlled by
NODEA.
Sample 2 Schedule SCHDB is defined at node NODEB with no NODE
ID specified.
This is also the normal case and it will be controlled by
NODEB.
Sample 3 Schedule SCHDX is defined at node NODEA with a NODE ID
of NODEB. JOB1 is defined as part of schedule SCHDX and
has no NODE ID specified.
In this case, NODEA controls and submits JOB1. JOB1 will be
routed to NODEB where it will run and NODEB will know to
send its status back to NODEA for posting and control. Notice
that since the NODE ID for the job was not defined, it uses
the one defined for the schedule.
Sample 4 Schedule SCHDX is defined at node NODEA. JOB1 is defined

as part of schedule SCHDX and has a NODE ID of NODEB,
which means that JOB1 is to execute on the CPU defined as
NODEB.
In this case, NODEA controls the schedule SCHDX. JOB1
within SCHDX, however, has a NODE ID defined which
means that JOB1 will have its JCL routed to NODEB through
NJE.

7.6 NJE Processing
Sample 5 Schedule SCHDY is defined at NODEB with a NODE ID of

NODEA and RUN ON SYSID of 2. JOB1 is defined as part of
schedule SCHDY and does not have a NODE ID specified, but
does have RUN ON SYSID of 3.
In this case, NODEB controls the schedule SCHDY at the CPU
with SYSID 2. JOB1 within SCHDY will be routed to NODEA
to run since its NODE ID is not defined and it picks up the
one from its schedule which is NODEA. Since there is no
NODE SYSID on the job or its schedule, it will run according
to the definitions at NODEA that, in this sample, would be 1.
The RUN ON SYSID of 3 at the job level, in this case, will be
ignored.
Sample 6 Schedule SCHDY is defined at node NODEB with no NODE
ID or NODE SYSID. JOB1 is defined as part of schedule
SCHDY and has a NODE ID of NODEA and a RUN ON
SYSID of 3.
In this case, NODEB controls the schedule SCHDY at the CPU
that is defined as the controlling CPU with the Unicenter
CA-Scheduler SYSGEN definitions (described in the prior
topic on Multiple CPU Considerations). JOB1 within SCHDY
will be routed to NODEA to run since its NODE ID of
NODEA overrides anything defined at the schedule level.
Since there is no NODE SYSID on the job or its schedule, it
will run according to the definitions at NODEA that, in this
sample, would be 1. The RUN ON SYSID of 3 at the job level
will, again, be ignored.
In summary This gives you some insight into how jobs can be defined on
one node and submitted to run on another node.
7.6.2 Cross-Node Dependencies

The only predecessor events that can be fed back and forth between nodes are
NJE start or completion of job events.
In the case of job predecessors across nodes, you must define a job node record
if Unicenter CA-Scheduler is to inform another node or nodes (up to eight)
that this job started or completed. You do this with the INFORM Definition
panel.
The following discusses each of these types of predecessors and how to define
them.

7.6 NJE Processing
7.6.2.1 NJE Job Dependencies
When a predecessor of a schedule or job is a job controlled by another node,

then you use the NJE keyword. The NJE keyword only pertains to jobs, not
schedules. NJE can take any one of the following forms:
NJE Form Predecessor Type Is

NJE jobname The completion of a job at another node.
START NJE jobname The start of a job at another node.
PRED NJE jobname The completion of a job at another node on a
previous day.
To mark an NJE predecessor job as satisfied, its definition must include

instructions for Unicenter CA-Scheduler to notify the relevant node or nodes.
You do this using the INFORM Record Definition panel. That is, if a job
controlled from NODEA has NJE JOBA as a predecessor and you never
defined a job INFORM Definition panel for JOBA and JOBA runs at a node
other than NODEA, then NODEA will never be notified that JOBA completed.
Consequently, the job on NODEA will never be submitted.
Remember two things when dealing with predecessor jobs across nodes. First,
use the NJE keyword, and second, use the INFORM Definition panel. Thus,
you close the loop.
7.6.3 Cross-Node Command Processing

Control commands can be issued on one node and processed on another node.
You do this by using the RO (ROute=nodeid) keyword in the corresponding
control command. The node to which you are directing the command must be
active. Practically all of the commands offer this keyword. An example of
cross-node communications follows.
The environment used in the preceding example consists of three nodes

running NJE using the Unicenter CA-Scheduler NJE option. Each node
consists of a single CPU.

7.6 NJE Processing
The following jobs are defined at the Cherry Hill node:

SCD: SH1
JOB: SHJ1,NODE=blank
JOB: SHJ2,NODE=NEWYORK
JOB: SHJ3,NODE=PHOENIX
JOB: SHJ4,NODE=NEWYORK
All of the preceding jobs are within the schedule SH001. The schedule runs
every day and so does each job.
Shown below are different cases of cross-node communications given the

following situation with these nodes.
The operator at the Phoenix node can issue the CANCEL command with
different optional keywords with different results in each case.
CASE 1: CANCEL S NAME=SH1,FM=CHERRYHL
The preceding will cancel the part of SH001 submitted from Cherry Hill and
running at Phoenix. Thus, only job SHJ03 is canceled. The other jobs in the
schedule at Cherry Hill and New York remain intact.
CASE 2: CANCEL S NAME=SH1,FM=CHERRYHL,ROUTE=NEWYORK
This preceding will cancel the part of SH001 submitted from Cherry Hill and
running at New York. Thus, only jobs SHJ02 and SHJ04 are canceled (that is,
they are deleted from the POWER input queue since they have a status of
SUBMITD). The other jobs in the schedule at Cherry Hill and Phoenix remain
intact.
CASE 3: CANCEL S NAME=SH1,ROUTE=CHERRYHL
The preceding will cause all jobs in schedule SH001 to be canceled regardless
of where they are running. All of them are canceled because the ROUTE=
keyword directs the command to be issued at the Cherry Hill node. This is
the node where the schedule SH001 is defined and controlled.
A summary follows.

7.6 NJE Processing
1. When specifying the optional keyword FM= on commands, you are

identifying which node originally submitted the schedule or job to your
local node. This optional keyword allows you to distinguish between
remotely submitted schedules and jobs from locally defined and controlled
schedules and jobs of the same name (that is, schedule SH001 from Cherry
Hill as opposed to schedule SH001 originating in Phoenix).
2. When specifying the optional keyword ROUTE= on commands you are
identifying the remote node that will actually process the command you
are issuing.
3. When executing a command directed at a schedule at the node where that
schedule is defined, all jobs within that schedule are affected.
7.6.4 Installation Considerations

When installing Unicenter CA-Scheduler, you have to designate that you are
going to be in an NJE environment.
There are a set of steps you must take in establishing your communication
environment. First, you must code a certain set of operands in the CAIJGEN
macro for each of the data centers. Next, you must establish your VTAM
network. Each of these is described separately.
7.6.4.1 CAIJGEN Macro
There are a set of operands on the CAIJGEN macro that you must consider
when installing the cross-node communication facility in Unicenter
CA-Scheduler. They include the following.
1. You must establish each of the individual locations with their own
Unicenter CA-Scheduler system. Each of them must have Unicenter
CA-Scheduler installed and be defined to handle a Unicenter CA-Scheduler
NJE environment.
2. You must code the parameter NJE=YES in the CAIJGEN macro. This
specifies that you are going to have cross-node communications using
Unicenter CA-Scheduler.
3. You can override the VTAM retry interval, which means that if the VTAM
connection that is suppose to exist is, for some reason, not up, then
Unicenter CA-Scheduler will keep trying to make the connection every n
minutes. You define n in the operand VRETRY=N in the CAIJGEN macro.
7.6.4.2 VTAM Communications
You will be using VTAM as your mechanism for cross-node communications.

You are going to have to do two things to implement the VTAM mechanism.
1. You will have to code the CAIJNET macro as described in the Unicenter
CA-Scheduler Systems Programmer Guide. You must use this macro for each
of the nodes in the network. Its primary purpose is to list the nodes that

7.6 NJE Processing
Unicenter CA-Scheduler will communicate with. The node name

(NNAME) is related back to the NODE ID on the Schedule and Job
Definition panels.
2. You are going to have to define the VTAM application to your various
data centers. This is described in the Unicenter CA-Scheduler Installation
Guide. It relates your VTAM environment back to the VTAM application
name defined in the CAIJNET macro described preceding. You must
define a VTAM APPLID for each system in the network where Unicenter
CA-Scheduler is installed.
7.6.5 Control Commands for Checking The NJE Network

There are three commands that can be used to control and interrogate the
network under which Unicenter CA-Scheduler operates. These commands are
described in the chapter "Controlling Schedules and Jobs" in the Unicenter
CA-Scheduler Reference Guide Part 1. The commands are described briefly
following.
The network can be displayed with the Display Network control command (or
D NET). The status of each node in the network will be displayed. The display
includes the following information for each node:
NAME The node name.
SYSID This node's NJE/POWER SYSID.
TYPE This node's type.
APPLID This node's VTAM applid if VTAM is used for communication
between this node and the local node, or
ZONE Time adjustment factor between this node and the local node.
STATUS The current status of this node. The STATUS may be any of the
following:
Status Meaning
LOCAL-NODE This is the local node.
CONNECTED This node is currently connected to the local node.
UNCONNECTED This node is not connected to the local node at this
time. Either Unicenter CA-Scheduler is down on
this node, or VTAM communication is interrupted
for some reason.
CONCT-BND This node is in the process of establishing
connection to the local node.
ERROR This node was not defined to POWER. Make sure
NNAME in the CAIJNET macro correctly specifies
the name of the node as defined to POWER.

7.6 NJE Processing
Status Meaning
BUSY The local node is currently sending requests to this
node. This is a normal situation as long as the
number of stacked requests is moving up and
down. If the number of stacked requests only
moves up, it may indicate a slowdown in VTAM
communications between the local node and this
node and possibly a lost VTAM connection.
Unicenter CA-Scheduler will send a warning
message to the operator console when the amount
of storage used to hold the stacked requests
reaches the threshold defined in the VTAMLIM
option of the CAIJNET option. In this case you
should use the Unicenter CA-Scheduler or VTAM
VARY INACT command to disconnect
communication with this node.
Unicenter CA-Scheduler will then save any stacked
requests for this node on the tracking file. When
the VTAM problem is resolved, use the Unicenter
CA-Scheduler VARY ACT command to reestablish
communication with this node. Unicenter
CA-Scheduler will then resend any requests that
were saved for this node.
STACK USAGE The number of requests currently stacked to be sent to this

node from the local node, and the amount of private storage
that those requests occupy.
All Unicenter CA-Scheduler sessions can be activated or deactivated with the

VARY operator command. You can vary one VTAM session at a time or do
them all at once. VARY A activates VTAM sessions and VARY I deactivates
them.

7.7 Summing Up
7.7 Summing Up
The following is a review of the important principles outlined previously.
7.7.1 On-Request Schedules and Jobs

Remember these subtleties when defining a criteria statement containing the
keyword REQUESTED:
■ A criteria statement of REQUESTED causes Unicenter CA-Scheduler to put
that schedule or job and its successors in the inactive queue at autoscan.
■ When OR REQUESTED occurs in a criteria statement, Unicenter
CA-Scheduler will select that schedule or job daily. However, whether it is
put in the inactive queue depends on the reason for selection. If selection
occurs because of REQUESTED, that schedule or job is placed in the
inactive queue. Therefore, the order of reasons in a criteria statement really
matters a lot if one of the reasons is requested.
When a schedule or job is selected because of REQUESTED, all its successors

are put in the inactive queue. Issuing a REQUEST command moves a schedule
or job and all its successors to the active queue. The SREQ command handles
successors differently: SREQ will not activate a successor if it involves other
requested jobs. A successor of an SREQed schedule or job will not be moved
to the active queue if:
■ The successor's criteria statement contains the keyword REQUESTED or
■ That successor is also the successor of some other requested job in the
inactive queue
7.7.2 Backlogged Work

If work is backlogged for more than 48 hours, it is likely that the second day's
schedule will never run. Monitor your backlogged work carefully.
7.7.3 Online Commands in Batch

The CAJUCMD0 program can process six types of batch transactions:

CP Issue the following VM command.
MO Send the following text to the operator console.
SC Issue the following Unicenter CA-Scheduler operator
command, which can include the conditional batch IF
statement.
CI CICS Transactions

7.7 Summing Up

PW POWER commands
DM Commands stored in the documentation library
IF statements can include AND, OR and NOT keywords, test for major and
minor status codes test the value of a global parameter
7.7.4 Recovery
Jobs that may need recovery have a status of ABENDED, OPERATOR
CANCLD, or FAILED. The ABEND field on a job base record controls what
happens automatically if a job abends. If ABEND specifies a recovery schedule,
that schedule could include a job that executes the program CAJUCMD0.
Unicenter CA-Driver can automatically restart a job at different steps
depending on the type of abend that occurred.
7.7.5 Multi-CPU Considerations

Be sure to specify these values in the CAIJGEN macro when installing
Unicenter CA-Scheduler:
MCPU=YES SHARE=YES SYSID=(sysid1,2,...) INSRSYS=YES
Run the program CAJUTIL0 with the keyword SHARE=YES in the FORMAT
statements for the following files:
CAIJMST CAIJTRK CAIJSTG CAIJDCM
If Unicenter CA-Driver is installed at your site, run the program CARUINTA
or CAJUTIL0 with the keyword SHARE=YES in the FORMAT statement for
the Unicenter CA-Driver procedure library (CAIJDRV).
If you have multiple CPUs in a POWER environment that is not shared spool,
you must specify a SYSID for each schedule you define unless it is controlled
from first SYSID in the list generated with the CAIJGEN macro. In this
environment, it is not possible to have a schedule controlled by one CPU and
have its jobs executed on another CPU.

7.7 Summing Up
7.7.6 NJE Processing

The node where a schedule is defined is the node that controls that schedule
and submits its jobs.
A job's NODE ID identifies where that job will run. A schedule's NODE ID
identifies the CPU that will track and control that schedule and its jobs, and
will submit those jobs to the appropriate CPUs.
NODE SYSID identifies which CPU a job will run on at the specified NODE
ID.
Predecessor events can be fed between nodes if:

■ Jobs are preceded by the keyword NJE in the successors' criteria statements
and the predecessor's job node record is defined to notify every successor's
node of the predecessor's status
■ Output data set names are preceded by the keyword DSN in the
successors' criteria statements and have been specified to the CAIJ$DSN
macro with the successors' nodes that require notification and
DSNINFM=YES in the CAIJGEN macro

Glossary
This glossary defines terms used in all volumes of Supervisor or Manager authority level do not
Unicenter CA-Scheduler's documentation, but require specific authorization to maintain or control
sometimes one new term leads to another. To help schedules.)
you grasp these new ideas quickly, we have used
italics to highlight related terms worth autoscan. The automatic selection of a day's
cross-referencing. workload. Unicenter CA-Scheduler scans the
database at a set time every day to determine the
abend. Abnormal ending. An early termination of workload for the next 24 hours.
a program due to an error.
autoscan day. The 24-hour period starting with
accounting day. A day designated on a datetable as autoscan. Also called the production day.
part of a cyclic production, sales, or accounting
period. AUTOTIME. The time when Unicenter
CA-Scheduler automatically scans its database for
accounting period. One or more accounting days. workload selection. This defaults to midnight, but
may be modified with the AUTOTIM installation
accounting week. A week containing at least one option. Also called autoscan time.
accounting day.
available. Ready for processing by Unicenter
active. Schedules and jobs that are: CA-Scheduler. A schedule is available (ready to
start) when its early start time has been reached and
■ Waiting at any workstation for predecessors,
all of its predecessors have been satisfied. A job is
start time, or defined resources
available (ready to be submitted) when its schedule
■ Waiting at a non-CPU station to be started has started, the job's early start time has been
manually reached, all the job's predecessors have been
satisfied, and the resources defined for that job are
■ Submitted, held, or started
available (not in use).
■ Completed, interrupted, abended, or failed
backlog. Work that was not completed one day
The opposite of inactive.
and was carried over to the next. References to a
backlogged schedule or job pertain to a previous
array. A variable parameter with multiple values.
day's schedule or job which is included in today's
workload.
authority level. One of three different types of
access assigned to users using the TYPE field on a
backout job. A replacement job that is
user record. Each authority level places different
automatically submitted by Unicenter CA-Scheduler
restrictions on what those Unicenter CA-Scheduler
when a job abends provided that
users can do. See General, Supervisor, and Manager
ABEND=BACKOUT on the abended job's base
authority levels.
record.
authorized users. Users with General authority level
base record. The record which is required to define
who are allowed to maintain and control a schedule
a schedule or job. There is a schedule base record
and its jobs because they are listed in the USERS
(SBR) and a job base record (JBR).
field on that schedule's base record. (Users with
Glossary X-1
batch command. Any command that is issued by criteria statement. A statement defining:
executing a Unicenter CA-Scheduler program
■ The days schedules or jobs should be selected
through standard DOS JCL.
and
Unicenter CA-Driver. Computer Associates JCL ■ What predecessor conditions must be satisfied
manipulation product. before selected schedules can start or selected
jobs can be submitted
Advantage CA-Earl. Computer Associates Easy
See selection criteria, predecessor criteria, and selection.
Access Report Language. A subset of this product
that allows you to customize reports is provided
criteria vocabulary. Reserved words used in
with Unicenter CA-Scheduler.
Unicenter CA-Scheduler's criteria statements.
CAISERV. A Computer Associates diagnostic
cyclic scheduling. Scheduling a schedule or job at
facility that allows you to determine the current
regular intervals regardless of which day or month
values of installation options and to produce reports
it is (for example, every six weeks).
for use in troubleshooting problems.
database. The Unicenter CA-Scheduler master
calendar. An alternative method for identifying
database that stores records containing definitions of
when a schedule or job should be selected as part of
userids, stations, schedules, jobs, and resources. The
the day's workload. With this method, you define
default name of the database is CAIJMST.
several calendars, each designating different days
when schedules or jobs should be selected
datetable. Identifies workdays, holidays,
(Mondays, month-ends, pay days, and so forth).
accounting days, and accounting periods so you can
The database shows which calendar to consult when
use workday, holiday, and accounting keywords in
selecting a schedule or job.
criteria statements.
calendar mechanism. One of three date references
datetable prefix. A one letter prefix (excluding E,
Unicenter CA-Scheduler consults when selecting the
H, N, P and W) that allows you to define multiple
day's workload.
versions of a datetable by applying different
■ The Gregorian calendar tells Unicenter prefixes.
CA-Scheduler what day of the week it is so, for
example, jobs can be selected on Mondays. Date Translation Table. A report that shows when
workday, accounting, and Gregorian conditions are
■ Calendars explicitly define which days to select
true.
schedules and jobs so you can run jobs on
random dates.
deadlock. The stalemate that occurs when jobs are
■ Datetables define workdays, holidays, predecessors to each other. Deadlocked jobs never
accounting days and accounting periods so, for run because their predecessor conditions are never
instance, Unicenter CA-Scheduler can select jobs satisfied. Also called a predecessor loop.
on the last workday of the month.
default. A value or action that Unicenter
character string. One or more alphabetic, numeric, CA-Scheduler supplies automatically unless you
or special characters, usually enclosed in delimiters. specify some other alternative.
control command. A command used to monitor or delimiter. A special character that precedes and
control the workload. Also known as operator follows a character string. In 'this example', the
command. delimiter is a single quote (') identifying a character
string consisting of two words: this example.
criteria record. The record that determines when a
schedule or job is to be selected for processing and documentation. Members in the Unicenter
lists the predecessors for the schedule or job. There is CA-Scheduler documentation file (CAIJDCM) that
a schedule criteria record (SCR) and a job criteria provide information to users.
record (JCR).
X-2 Unicenter CA-Scheduler User Guide

documentation batch command. A command 2. The USERS field on a schedule's base record
issued through batch using the CARUTIL0 program defines which General users can access that
that is used to maintain members in the schedule and its jobs.
documentation file.
General users are prohibited from doing anything
involving stations or schedules for which they are
documentation file. The Unicenter CA-Scheduler
not authorized. See authorized users as well as
file that contains documentation members. The
Supervisor and Manager authority levels.
default name of the file is CAIJDCM.
generic list. A group of schedules or jobs whose
events. Occurrences that Unicenter CA-Scheduler
names begin with the same characters. To display,
monitors so it knows when predecessor conditions
list, or analyze a generic list, specify the common
have been satisfied. Some of the events that
characters followed by an mask character (*).
Unicenter CA-Scheduler monitors are schedules and
jobs starting and ending, the close of output data
global parameter. A user-controlled variable that
sets and generation data groups, and what time it is.
defines a predecessor condition in criteria statements
and can assume arithmetic, binary, or character
explicit predecessor. A predecessor that is
values. See keyword-defined explicit predecessors.
specifically defined in the criteria statement of a
schedule or job. Explicit predecessors can be either
Gregorian calendar. The standard 12-month
of two types:
calendar which Unicenter CA-Scheduler references
■ Selection-defined explicit predecessors are to interpret certain selection keywords (like
predecessors that also define selection criteria. WEEK-DAY) in criteria statements. You can use
They can be schedule or job names used with or Gregorian calendar keywords without defining a
without the keywords SCD and START. datetable or calendars.
■ Keyword-defined explicit predecessors are
Gregorian date. A date shown as mm/dd/yy
ignored in the selection process and always
(American format) or dd/mm/yy (European format).
include one of the following keywords:
DSN GDG GBLxnn DOS PRED history file. The Unicenter CA-Scheduler file that
contains history records for schedules and jobs.
When START or SCD are used with PRED or DOS,
the result is a keyword-defined predecessor that is
history record. The record that contains statistics of
ignored during the selection process.
past runs of schedules and jobs.
forecasting. .* previously FORECAST Producing
implicit predecessor. Predecessors that are not
reports that show which schedules and jobs will be
defined on a job's criteria statement. Because
selected for processing on any given days.
Unicenter CA-Scheduler enforces workstation
sequences, pre-CPU jobs (such as data entry and JCL
General authority level. The default authority level
staging) are implicit predecessors for CPU jobs.
assumed for all users unless Supervisor or Manager
Likewise, CPU jobs are implicit predecessors for
is specified. Allow users to:
post-CPU jobs (such as report distribution). See
■ Define and maintain certain schedule and job sequence enforcement.
records
inactive. Schedules and jobs that are:
■ Control and display the status of certain
schedules and jobs ■ Defined as REQUESTED but not activated by a
REQUEST or SREQ command, and
■ Potentially display and alter JCL for certain
staged jobs ■ The successors of REQUESTED schedules and
jobs
Two fields determine the scope of a General user's
authority: Schedules and jobs in the inactive queue at autoscan
time are purged regardless of what values have
1. The CONNECT field on each user record
been defined for BACKLOG. The opposite of active.
defines which stations that General user is
authorized to access.
Glossary X-3
information record. The record that provides Julian date. A five-digit number of the form
descriptive information of schedules and jobs. There yyddd, where yy is the year and ddd is the relative
is a schedule information record (SIR) and job day of the year (from 001 to 366). For example,
information record (JIR). 87305 is November 1, 1987.
installation option. A value specified on the keyword-defined explicit predecessors. Predecessors

CAIJGEN installation macro when Unicenter that are ignored in the selection process and always
CA-Scheduler is installed. This value controls include at least one of the following keywords:
scheduling operations throughout the data center
DSN GDG GBLxnn DOS PRED
unless it is overridden by values in Unicenter
CA-Scheduler's database. The keywords START or SCD can also be used with
DOS or PRED.
JBR. Job base record. This record is required to
define a job. levels of predecessors. In terms of a family tree,
the number of preceding "generations" (schedules or
JCR. Job criteria record. This record determines jobs) with defined predecessors. The number ending
when a job is to be selected for processing and lists each job name following identifies each job's level of
the predecessors for the job. predecessors.
JIR. Job information record. This record provides

descriptive information for a job.
JMR. Job message record. This record determines

who receives messages when a job begins, ends,
starts late, abends, is purged, or is interrupted.
JNR. Job node record. This record is used to

specify other nodes to be notified when a job starts
or ends.
job. Usually refers to work submitted to the CPU

for processing. However, Unicenter CA-Scheduler
expands the scope of that definition to encompass
all data processing tasks under Unicenter
CA-Scheduler's control. This can include pre-CPU
tasks such as data entry, jobs that run on the CPU,
and post-CPU tasks such as report distribution.
job number. One of four fields used to uniquely

identify each job definition. When a job needs to JOBA0 and JOBB0 have no predecessors.
run more than once during a production day, create (Their levels of predecessors = 0)
a job definition for each iteration by giving them JOBA0 is JOBA1's predecessor.
different job numbers. (JOBA1's level of predecessors = 1)
job path. All the stations where a job is processed JOBA1 is JOBA2's predecessor.
as it moves through the data center. (JOBA2's level of predecessors = 2)
JOBA2 and JOBB0 are JOBA3's predecessors.
JRC. Job reason code record. This record is used (JOBA3's level of predecessors = 3)
assign time specifications which vary according to
the reason a job is selected for processing. JOBA3 is JOBB4's predecessor.
(JOBB4's level of predecessors = 4)
JRR. Job resource record. This record allows you to The key word here is level. JOBA3 has four
define the resources necessary to run a job. different predecessors, but only three levels of
predecessors. Levels of predecessors is one factor

Unicenter CA-Scheduler uses when ordering the interrupted. There is a schedule message record
workload. Schedules and jobs with fewer levels of (SMR) and job message record (JMR).
predecessors are evaluated ahead of those with
more. nesting. One procedure calls (retrieves) another
procedure which can, in turn, call another
mailbox. The common area for sending Unicenter procedure.
CA-Scheduler messages so that they can be viewed
by many users without being deleted. node. Each location in a network having one CPU
or multiple CPUs with multi-access spooling facility.
Manager authority level. The highest authority
level which allows these users to access all stations, node record. The record that specifies other nodes
control all schedules and jobs, define and maintain to be notified when a job starts or ends.
any database records, and issue all commands. See
General and Supervisor authority levels. null value. A defined value of nothing which has
been added to the database using the keyword
MASTER userid. The userid reserved for the NULL.
Unicenter CA-Scheduler administrator.
on-request. Schedules or jobs having the keyword
mask character. An asterisk (*) or question mark (?) REQUESTED in their criteria statement. These
included anywhere in a search string. Used when schedules and jobs are selected every day in case
you want to display all records with names that they are needed, but they remain inactive until
share common characters. activated by the REQUEST or SREQ command.
? indicates that any character can be
operator command. A command used to monitor
substituted at this point in the search string,
or control the workload. Also known as control
but just one character can be substituted for
command.
each question mark. That makes ? a
positional mask character.
path. All the stations where a job is processed as it
* indicates that Unicenter CA-Scheduler will moves through the data center.
accept anything occurring at this point in the
search: an * can signify any number of periods. A year can be divided into accounting
characters. For example: periods, production periods, sales cycles, or any
other unit of time. The end of each period is
P? displays all record names of just 2
identified by a P on the datetable.
characters starting with P
P* displays all records that start with the post-CPU job. Work scheduled after CPU
letter P processing to wrap up a job. Examples include
output decollation, shipment of backup tapes offsite,
?ACC?
and report distribution. See station.
displays record names of just five
letters with ACC in the middle
pre-CPU job. Work scheduled to prepare a job for
*ACC* CPU processing. Examples include daily shipment of
displays just those records with ACC input forms, data entry, and JCL setup. See station.
anywhere in their name
predecessor. An event that must happen before the
See generic list.
next job can begin. Unicenter CA-Scheduler's
criteria statements allow you to define predecessors
master database. The Unicenter CA-Scheduler
for schedules and jobs which means schedules and
database that stores records containing definitions of
jobs in today's workload will not run until their
userids, stations, schedules, jobs, and resources. The
predecessors are satisfied. If JOBA is a predecessor
default name of the database is CAIJMST.
of JOBB, JOBB will not run until JOBA runs to
completion.
message record. The record that determines who
receives messages when a schedule or job begins, Predecessors fall into several different categories that
ends, or starts late or when a job abends, or is are defined in this glossary:
Glossary X-5
■ Explicit predecessors ■ The names of jobs or schedules also selected that
day or
■ Implicit predecessors
■ A combination of the two
■ Keyword-defined explicit predecessors
See selection.
■ Selection-defined explicit predecessors
reason code. A number that explains why a
predecessor criteria. All of the predecessors defined
schedule or job was selected. Numbers from 01 to 79
for a schedule or job in its criteria statement. These
correspond to the position of a reason in the criteria
predecessor conditions must be satisfied before a
statement. Numbers from 80 to 99 are special reason
schedule can start or a job can be submitted.
codes which indicate that selection was based on
default daily processing, calendars, or manual
predecessor loop. The stalemate that occurs when
additions.
jobs are predecessors to each other. These deadlocked
jobs never run because their predecessor conditions
reason code record. The record that assigns time
are never satisfied. Also called deadlock.
specifications which vary according to the reason a
schedule or job is selected for processing. There is a
procedure. One or more statements cataloged
schedule reason code record (SRC) and job reason
under a procedure name as a member of the
code record (JRC).
CA-Driver procedure library.
RECS line. The line on the bottom of the Schedule
procedure library. The library that stores Unicenter
Definition (SCHD-SU) panel and Job Definition
CA-Driver procedures.
(SCHD-JU) panel that provides access to panels for
optional schedule and job records.
production day. The 24-hour period starting with
autoscan. Also called the autoscan day.
reserved-name variable parameter. One of a set of
Unicenter CA-Driver variable parameters which are
prompt. A word on a screen that reminds you to
predefined by Computer Associates.
supply a value.
resource record. The record which specifies the
prototype calendar. A master calendar that defines
resources that are used to run a job.
all of the year's holidays and tells when to
reschedule jobs that would normally be selected on
route delay time. The delay between the time a job
holidays. These holidays and rescheduling
ends at one station and starts at the next station.
instructions are automatically applied to all
calendars defined for that year.
route station. A workstation defined for purposes of
receiving reports rather than performing data
prototype definition. An existing definition whose
processing tasks.
values are used as defaults for a new definition. Any
fields left blank while defining a new record are
run book. A report that contains detailed
assigned values from the prototype definition.
information on the current day's workload.
public schedule. A schedule that can be
SBR. Schedule base record. This record is required
maintained by all users because no value is specified
to define a schedule.
in the USERS field of the schedule base record.
schedule. A group of related jobs that:
queue. One of the various job categories that
depend on the status of the jobs. ■ Run on the same days or
■ Belong to the same application or
reason. Why a schedule or job is selected for the
day's workload. A reason can be: ■ Have the same operational dependencies or
■ One or more words from the criteria vocabulary ■ Belong together because your production jobs
or are organized that way

The payroll department's month-end jobs could the calendar and ignores the selection criteria. See
make up a schedule. The schedules and jobs selection.
selected each day comprise the workload.
sequence enforcement. Making sure schedules and
SCR. Schedule criteria record. This record jobs are processed in the right order. See implicit
determines when a schedule is to be selected for predecessor.
processing and lists the predecessors for the schedule.
shared DASD. A hardware configuration that
selection. How Unicenter CA-Scheduler determines allows two or more operating systems to use the
the day's workload at autoscan time. Unicenter same disk files. This situation allows several
CA-Scheduler reviews the criteria statements of operating systems to use the same set of Unicenter
every schedule to see which ones qualify for CA-Scheduler files at the same time. However,
inclusion in the day's workload. Every time when operating systems share Unicenter
Unicenter CA-Scheduler selects a schedule that CA-Scheduler files, it does not imply that they also
qualifies, it scans the criteria statements of every job share spool files.
in that schedule. Jobs are selected if:
simulation. Answers the question "what if." It
■ They specify a calendar which defines that day
shows how processing is affected by changes in
as a workday or
workload or hardware failure. Simulation also totals
■ A reason in the criteria statement is true that how long each job usually takes to project when the
day or workload is likely to finish.
■ No criteria record exists for that job or
SIR. Schedule information record. This record
■ One reason in the criteria statement is the provides descriptive information for a schedule.
keyword REQUESTED
SMR. Schedule message record. This record
Jobs can only be selected when the schedules they
determines who receives messages when a schedule
belong to are selected. All the important terms used
begins, ends, or starts late.
in this definition are also defined in this glossary.
spin locks. The method Unicenter CA-Scheduler
selection criteria. There are two distinct meanings:
uses to protect the integrity of its files when two or
1. All the reasons why a job or schedule can be more operating systems share them. See shared
selected as defined in its criteria statement. If a DASD.
calendar is also defined for a schedule or job,
Unicenter CA-Scheduler bases selection on the SRC. Schedule reason code record. This record is
calendar and ignores the selection criteria. See used assign time specifications which vary according
selection. to the reason a schedule is selected for processing.
2. The keywords that are used in the maintenance
staging. Unicenter CA-Scheduler's three-step
panels to limit the directory to be displayed.
process for tailoring production JCL:
selection-defined explicit predecessor. A 1. First, Unicenter CA-Scheduler automatically
predecessor that also defines selection criteria. They copies the production JCL for jobs that require
are schedule or job names used with or without the staging into its staging library.
keywords SCD and START. When START or SCD is
2. Then users modify that copy of the JCL as
used with PRED or DOS, the result is a
needed (the original production JCL is not
keyword-defined explicit predecessor that is ignored
changed).
during the selection process.
3. When the JCL has been modified and that
selection criteria. All the reasons why a job or pre-CPU job has been posted as ENDED,
schedule can be selected as defined in its criteria Unicenter CA-Scheduler automatically submits
statement. If a calendar is also defined for a schedule the modified JCL to the operating system when
or job, Unicenter CA-Scheduler bases selection on that job becomes available for processing.
Also called JCL setup.
Glossary X-7
staging file. The Unicenter CA-Scheduler file that events as they occur. As jobs move from station to
contains staged JCL members. The default name of station through the data center, Unicenter
the file is CAIJSTG. CA-Scheduler automatically updates their status in
its tracking file.
station. Any area where a job is processed as it
makes its way through the data center. Examples tracking file. The Unicenter CA-Scheduler file that
include production control, data entry, JCL setup, contains the copy of current production. The
CPU processing, and report distribution. Also called default name of the file is CAIJTRK.
a workstation.
variable parameter. A symbolic parameter that is
substring. Part of the value given to a variable defined when a procedure is cataloged and referenced
parameter. in the body of the procedure. During expansion, each
reference to the symbolic parameter is replaced with
status conditions. The various words (ABENDED, a default or override value.
ENDED, and so forth) that Unicenter CA-Scheduler
applies to jobs to indicate their current state within work flow. The movement of jobs from station to
production. station through the data center.
successor. Any job that cannot start until some workday. Any day that is not designated a
event triggers it. Unicenter CA-Scheduler's criteria weekend or a holiday on a calendar or datetable.
statements allow you to define conditions that must
be met before a job can start. If JOBA must finish workload. The work Unicenter CA-Scheduler
before JOBB can start, JOBB is a successor to JOBA. anticipates submitting each day. That includes:
Conversely, JOBA is a predecessor to JOBB.
1. The schedules and jobs automatically selected by
autoscan to run on that production day based on
Supervisor authority level. The intermediate
the information stored in Unicenter
authority level which allows users to control all
CA-Scheduler's database and
schedules and jobs at specified stations, even if they
are not authorized on the schedule base record. 2. The schedules and jobs manually added by
However, their scope of authority is limited to just users
those stations specified on their user record. See
See selection.
General and Manager authority levels.
workstation. Every area where a job is scheduled
SYSID. The 1-character POWER identifier that
for processing as it makes its way through the data
defines the CPU on which Unicenter CA-Scheduler
center. Examples include production control, data
is running.
entry, JCL setup, CPU processing, and report
distribution stations. Also called a station.
tracking. Unicenter CA-Scheduler monitors the
progress of jobs by collecting and analyzing data on

Index
ALL
Special Characters queue 4-8
"Who value for USER= parameter 4-23
is Alter Or Replace An Auto-Reply Record 3-47,
logged on" 2-34 3-107
$DYNx schedule 6-17 Altering
* 2-33 CPUs jobs run at 7-23
job optional records 3-94
A jobs 3-91
predecessors 6-20
ABEND
schedules 3-18, 3-20
field 3-68, 4-13, 7-17
station
ABENDED
records 2-10
queue 4-8
user records 2-26
status 4-17, 6-14, 6-16, 7-12, 7-16
Analysis reports 1-12
ABORT option 7-17
Analyze
Accounting periods
jobs 3-101
criteria keywords 5-3, 5-12
schedules 3-40
Date Translation Table report 5-17
ANALYZE command 1-12, 6-10, 6-12
using datetables 1-6, 5-2, 5-10, 6-3
Analyze report 6-10, 6-12
Activating VTAM sessions 7-33
AND keyword
ACTIVE
DSN keyword 5-25
field 4-12, 4-13, 4-15
examples 5-4, 5-6
queue 4-6, 4-8, 6-17, 7-2
IF statement 7-11
status 7-12
NOT keyword 5-4, 5-27
Add
OR keyword 5-7, 5-11, 5-15
Auto-Reply Record 3-105
purpose 5-3
command 4-36
REQUESTED 7-6
ADD command 4-13, 4-36, 6-17, 7-17
Applications 6-12
ADD command definition 4-34
APPLID parameter, CAIJNET macro 7-32
Adding
Authority levels 1-9, 2-20
applications 6-11, 6-12
AUTO
fast 6-5
option of RELEASE command 6-19
jobs 3-53, 3-74, 3-94, 6-5
RECVRY HELD status 4-17, 6-18
schedules 3-1, 3-3, 3-17, 3-20, 6-5
SELECT field 3-5, 3-10, 3-70, 6-12
stations 1-11, 2-8, 6-3, 6-5
START field
users 2-22, 6-5
NO value 3-64, 4-22
Adding an Auto-Reply Record 3-45
YES value 3-64, 3-72, 4-8, 4-17, 6-3, 6-6, 6-9
Advantage CA-Earl reports 1-12, 6-13, 7-9
status 7-12
Index X-9
AUTO (continued)
STRTED status 4-17 C
Auto-Reply CAIJ$DSN 4-3, 4-30
default values 3-5 CAIJGEN 7-31
processing 1-9 CAIJNET 3-90, 4-31, 7-31
Automatic CAISERV 1-12
job submission 4-17, 7-23 CAJUCMD0 program
recovery 4-17, 7-17 automatic recovery 7-17
AUTOMATIC CONSOLE REPLY 3-44, 3-45, 3-47, issuing online commands in batch 6-16, 7-10
3-49, 3-104, 3-105, 3-107, 3-109 resetting global parameters 6-21, 7-13
Maintenance Panel 3-44 CAJUTIL0 program 7-20
Autoscan Calendar
backlogged work 6-20, 7-8 Definition panel 5-18
definition 6-2 holidays 5-18
displaying information 4-3, 4-29 mechanisms 5-1
global parameters 6-8 method 3-21, 5-2, 5-10, 5-17, 6-3
multi-CPU environment 7-21 reason code 4-13
process 1-7, 3-5, 4-5 workdays 5-18
purges jobs 7-2, 7-4 CANCEL
REQUESTED schedules 7-2 command
time 3-72, 6-9, 7-8 abbreviation 6-15
AUTOSCAN command 4-29, 7-23 impacts dependencies 6-20
AVAIL TIME field 4-14 recovery 7-16
AVERAGE TIME on with UNKNOWN status 4-21
job panels 3-71, 3-79 status 6-14, 6-16, 7-12
schedule panels 3-15, 3-24 CANCEL command
summary status panel 4-16 definition 4-32
AVG TIME on CANCELLED queue 4-8
history status panel 4-15 CANCLD status 4-17
job panels 3-81 Carrying over backlog 1-7
schedule panels 3-25 CC=Uxxxx status 7-12
CC=x"00" status 7-12
CC=xxxx status 7-12
B Centralized control 7-20, 7-24
Backlog Changing
autoscan time 6-2, 6-20 jobs 3-91
definition 1-7, 7-8 predecessors 6-20
rerun schedule 4-16 schedules 3-18, 3-20
status 4-17, 7-12 station records 2-10
symptom of deadlock 6-12, 6-13 user records 2-26
BACKLOG field Checking
on schedule panels 3-5 job completion codes 7-12
BACKLOG field on status 7-11, 7-14
job panels 3-69, 7-7, 7-8 Commands
schedule panels 3-13, 3-64, 7-8, 7-9 abbreviations 6-15
Backout jobs 1-9, 3-69, 4-13, 7-17 adding to the workload 6-16
Batch mode 6-5 control online 4-3
Boolean expressions 5-3 cross-node processing 7-29, 7-32
operator
for recovery 7-16
issued in batch 7-10
multiple CPUs 7-22

Commands (continued) Creating
operator (continued) jobs 3-53, 3-74
online monitoring 4-1 schedules 3-1, 3-3, 3-17, 3-20
where they work 6-15 station records 1-11, 2-8, 6-3
options 6-15 user records 2-23
Processor panel 6-8 Criteria
VM 7-10 Definition panel 3-21, 3-22, 3-77, 3-94
COMPLETE language 1-5, 3-58, 5-1, 7-2
status 7-12, 7-14 CRITERIA keyword 4-28
COMPLETE command Cross-node
AUTO STRTED status 4-17 communications 7-29
definition 4-34 dependencies 7-28
INTERRUPTED status 6-9 job submission 7-26
INTRPTD status 4-17
non-CPU stations 6-3
UNKNOWN status 4-21 D
COMPLETED queue 4-6, 4-8, 4-14 D NET command 7-32
Completion codes 4-15, 4-17, 7-12 DAILY keyword 5-2, 5-3, 5-4, 5-10, 6-6
COMPLETION DEADLINE TIME on Daily processing 4-5
job panels 3-62, 3-73, 3-79 Data
schedule panels 3-12, 3-24, 3-73 Sets
CONCT-END status 7-32 mask names 4-30
Conditions Data entry 6-3
causing selection 5-1, 5-4, 5-6, 5-7 Database
in IF statements 7-11 maintenance 3-1, 6-5
CONNECT STATION field organization 1-3
logon panel 2-3 reports 6-13
CONNECTED status 7-32 Date Translation Table report 5-15
Console Date, displaying 4-3, 4-29
commands 6-15 Datetable
messages 6-16, 7-10, 7-15 cycles 6-4
CONT option 7-17 Definition panel 5-13
Control method 1-5, 5-2, 5-10, 5-11, 6-3
centralized 7-20, 7-24 prefix 6-4
commands DATETABLE field 3-10, 3-21
checking NJE network 7-32 DAY keyword 5-3, 5-13, 5-15
online 4-3 Days-of-the-
online monitoring 4-1 month keywords
daily production 4-1, 4-3, 7-25 abbreviations 5-3, 5-10
decentralized 7-20, 7-23, 7-26 accounting cycles 5-3, 5-13
NJE network 7-32 workdays 5-3, 5-22
schedules 4-31 week keywords
Copying schedule records 3-29 abbreviations 5-3, 5-4, 5-10, 5-15, 5-25
CP command 4-32 accounting cycles 5-3
CP transaction 7-10 workdays 5-3, 5-4
CPU Deactivating VTAM sessions 7-33
JOB field 3-64, 3-65 DEAD status 7-12
master/slave relationship 7-24, 7-26 DEADLINE TIME field 3-25, 3-81
outage 7-23 Deadlock 5-26, 6-10, 6-12, 6-13
selection 3-66, 7-18 Decentralized control 7-20, 7-23, 7-26
station 1-2, 6-3
Index X-11
Defaults for Displaying (continued)
job base records 3-56 database records (continued)
schedule base records 3-6 schedules 3-6, 3-20, 3-32
status displays 4-12 stations 2-15
Defining userids 2-30
database records date 4-3, 4-29
authority levels 2-20 documentation on operator console 1-8
jobs 3-53, 3-74, 6-5, 6-9 execution history 4-11
optional schedules 3-18 global parameters 4-3
passwords 2-21 HELP 2-4
predecessors 3-60, 5-1, 5-6, 6-18 job
schedules 3-1, 3-3, 3-17, 3-20, 6-3, 6-4, 6-5 optional records 3-94
scheduling criteria 1-5, 5-8 messages
stations 1-2, 1-11, 2-8, 6-3, 6-5 from other users 4-1
users 2-22, 6-5 sent to your userid 4-3, 4-23
global parameters 6-7 when jobs are late 3-72
job when schedules are late 3-16
node record 3-89 network information 4-31
options 1-3, 1-5, 3-18 status information
predecessors 3-89 global parameters 4-1, 4-27, 6-8
work schedules network nodes 7-32
accounting cycles 1-6 workload 1-10, 4-1, 4-4
calendars 5-17, 5-19 DISPLY KEY field 3-72, 6-9, 6-11
holidays 1-5, 5-12 Documentation
production cycles 1-6 library 1-8, 3-71, 6-9, 6-11
sales cycles 1-6 Maintenance panel 3-72, 6-9
Deleting reports 6-13
Auto-Reply Record 3-49, 3-109 DOM keyword 5-3, 5-13, 5-15, 5-22
job 3-97 DOS keyword 5-5
schedules 3-36 Down, CPU 7-23
stations 2-13 DSN keyword
user records 2-29 OR keyword 5-25
values 3-93 PRED keyword 5-5, 6-18
Dependencies 5-1, 7-28 Dynamic ADD panels 4-37
Directory of
jobs 3-75
schedules 3-29, 3-33, 3-34, 3-37 E
stations 2-12, 2-14, 2-16, 2-17 EARLIEST START TIME
users 2-28, 2-32 on
DISPLAY $DSN command 4-3, 4-30 job panels 3-62, 3-65, 3-79, 6-7
DISPLAY Alloc command 4-3 schedule panels 3-5, 3-20, 3-24
DISPLAY Date command 4-3, 4-29 EARLY TIME field 3-25, 3-81
DISPLAY Network command 4-3, 4-31, 7-32 END TIME field 4-14
DISPLAY TIME field 3-72, 6-9 End-times 4-11
Displaying ENDED status 4-17, 6-16
"status Ending Unicenter CA-Scheduler 2-6
information" "who is logged on" 2-34 Erasing values 3-93
autoscan information 4-3, 4-29 ERROR status 7-32
CAIJ$DSN table 4-3 EXITPARM field 3-27, 3-82
data set mask names 4-30 Explicit predecessors 5-5
database records
jobs 3-56, 3-91

F HOLD
command 4-17, 7-12
FAIL CODE field 7-16 JCL parameter 4-22
FAILED HOLD command 4-32
queue 4-8 Holidays 5-4, 5-12, 5-15, 5-18, 5-21, 5-23, 6-3
status 4-17, 6-16, 7-12, 7-16
False job completion 1-9
File Status report 1-12 I
FORCE command ICR 7-22
abbreviation 6-15 IF statement 7-10
definition 4-32, 4-34, 6-16 Ignoring predecessors 6-16
FAILED status 4-19 Implementation 1-1
UNKNOWN status 4-21 Implicit predecessors 5-7, 6-6
WAIT status 4-21, 4-25, 6-17 inactive queue
Forcing logons and logoffs 2-34 contents 4-6, 4-8, 7-2, 7-12
FORECAST command 6-12 operator commands 6-17
Forecasting 1-11, 3-72, 6-9, 6-11, 6-12 Inform Definition panel 3-89, 7-28, 7-29
FORMAT statement 7-20 INFORM NODES field, Inform Definition
Forms control 1-2 panel 3-89
Information Definition panel 3-26, 3-82
G INSRSYS installation option 7-20

Installation
GBL command 4-3, 6-8, 7-14 NJE considerations 7-31
GBLxnn keyword 4-3, 4-26, 5-5, 5-27, 6-7 Installation considerations 7-19
GDG keyword 5-5 Inter-Communication Records area 7-22
General authority level 2-20 INTERRUPT field 4-17, 6-9
Getting help 2-4 INTERRUPTED queue 4-8
Global parameters INTRPTD status 4-17, 6-16, 7-12
definition 6-7
displaying values 4-1, 4-3, 4-27, 6-8
in IF statements 7-11 J
setting values 4-1, 4-3, 4-28, 6-21 JBR 3-53
starting transactions 7-11 JCL
testing values 6-16 errors 7-17
when backups can run 7-13 libraries 1-8
Gregorian calendar 5-2, 5-3, 5-10 setup 1-2, 1-8, 6-5
Grouping jobs 1-2, 6-4 staging 6-3, 6-13
JCR 3-58, 3-60, 3-77, 4-13
H JES
CLASS field 3-71
Handling messages 4-22 shared 7-20, 7-27
HDAY keyword 5-3, 5-4, 5-12, 5-15, 5-21, 5-23 JIR 3-77, 3-82
HELD JMR 3-74, 3-77, 7-17
AND WHEN JNR 3-89
field 6-18 Job
queue 4-8 altering 3-94
queue 4-8 analyzing 3-101
status 4-17, 6-17, 7-12 Auto-Reply Maintenance 3-104
HELP 2-4 commands 6-15
History defaults 3-56
displays 4-11, 4-14 defining 3-94
reports 1-11, 6-13
Index X-13
Job (continued) JOB PRIORITY field 3-63
displaying 3-94 JRC 3-62, 3-77, 3-79
maintenance JRR 3-71, 3-77, 3-85
changes 3-91
defining 3-53, 3-74, 6-5, 6-9
deleting 3-97 L
displaying 3-56 Late
resources 6-7 messages 3-16, 3-72, 7-12
sequencing 1-2, 1-6 queue 4-6, 4-8
messages 3-83 status 6-14, 7-12
name 1-2, 3-55 LIBRARY TYPE
numbers 1-4, 7-15 on
panels job panels 3-65, 3-70
Alter panel 3-93 schedule panels 3-8
Definition panel 3-54, 3-76, 6-9 Limiting scope of status displays 4-9
Directory panel 3-70, 3-75, 3-92 LIST
Display panel 3-57 option 6-12
Maintenance menu 3-54, 3-91 Listing
path 1-2, 1-4 "who
processing is logged on" 2-34
abends 6-10, 6-16, 7-16 jobs 3-56, 3-91
cancelling 6-20 schedules 3-32
purging 6-20 stations 2-15
recovery 7-15 userids 2-30
reruns 6-8 LOCAL-NODE status 7-32
staging 1-8, 3-9, 3-65, 6-5 Logoff procedure 2-6, 2-34
submission 1-7, 6-7, 6-8, 6-16, 7-23 Logon
queues 4-8 panel 2-2, 2-34
records procedure 2-2, 2-34
base record 3-53 status 2-28
criteria record 3-58, 3-60, 3-77, 4-13
information 3-77
information record 3-82
M
Mailbox report 1-12, 3-74, 3-84
message 3-74, 3-77, 7-17
Main menu panel 2-3
node record 3-89
Maintaining
reason code 3-62, 3-77, 3-79
database records 3-1, 6-5
resource record
job records 3-52
defining 3-77, 3-85
schedule records 3-2
for simulation 3-71
stations 2-7
routing 7-27
user records 2-20
selection
Manager authority level 2-21
additions 6-16, 6-17
Mask character 2-33, 3-86, 4-9
criteria language 5-1, 5-3
Master CPU 7-24, 7-26
process 3-58
MAX status 7-12
rule 5-8
MAXIMUM EXECUTION TIME
with REQUESTED 6-17, 7-2
on
status 7-14
job panels 3-73, 3-79
submission 7-26
schedule panels 3-16, 3-24, 3-73
Summary report 6-12
MAXIMUM TIME field 3-16, 3-25, 3-81
JOB NUMBER field 3-55

MBR SUBID field 3-65 Network
MCPU installation option 7-20 displaying 4-3, 4-31
MEMBER implementation 1-13, 3-89, 7-25
NAME field 3-65 simulation 3-66
PASSWORD field 3-65 NJE
MEMO definition 7-31
field 3-68 installation option 7-31
Message job 5-5
Definition panel 3-27, 3-72, 3-83, 6-9 keyword 5-5, 7-28
displaying 4-3, 4-23 PRED keyword 5-5
HELP 2-6 START keyword 5-5
operator 7-10, 7-15 processing 7-25
record definition 3-27, 3-83 support 1-13
routing 6-16 NJE keyword 7-28
sending 4-3 NNAME parameter, CAIJNET macro 7-32
status 7-12 NO BACKLOG CNCL status 4-17, 7-9
to other users 1-12, 4-1, 4-23 Node
when definition 7-26
jobs are interrupted 6-9 displaying status 4-31, 7-32
jobs run late 3-72 notification 7-28
jobs start 3-72, 6-9 record 3-77, 3-89
schedules run late 3-16 status 7-32
MO transaction 7-10, 7-15 NODE ID field
Monitoring workflow 1-10 Job
Month keywords Definition panel 7-27, 7-32
abbreviations 5-3 Definition screen 3-15, 3-67
accounting cycles 5-3 Schedule
month names 5-10 Definition screen 3-15, 3-67
workdays 5-3, 5-20, 5-22, 5-24 NODE SYSID field
MONTHLY frequency 5-18, 5-19 Job
MOVEOVER command 7-23, 7-24 Definition panel 7-27, 7-32
MOY keyword 5-3, 5-22 Definition screen 3-15, 3-67
MSG installation option 3-17, 3-74 Schedule
MSGHOLD generation option 4-23 Definition screen 3-15, 3-67
Multiple Non-scheduled MVS job 4-13
CPUs 1-13, 3-66, 4-11, 7-18, 7-26 Non-shared POWER 7-25
reasons 5-7 NORMAL job completion 7-14
MUST NOT
START BY TIME on keyword
job panels 3-73, 3-79 AND keyword 5-4, 5-15, 5-23, 5-27
schedule panels 3-16, 3-24, 3-73 IF statement 7-11, 7-14
status 7-12 parentheses 5-27
TIME field 3-16, 3-25, 3-81 purpose 5-3
rule 6-8
selection 5-8, 5-11
N REQUSTED status 4-18
Naming Notifying nodes 7-28
conventions 7-17 NOTREQ status 7-12
jobs 1-2 NSYSID parameter, CAIJNET macro 7-32
schedules 1-3 NULL value 3-93, 7-15
workstations 1-2
Index X-15
Numbering Ordering queues 4-10
jobs 1-4 Organizing schedules 6-4
stations 1-2 Outage, CPU 7-23
Overriding
predecessors 6-16
O schedule options 1-3
Online start times 6-16
commands in batch 7-9 Overview
monitoring 4-1 system 1-7
Monitoring panel
displaying global parameters 6-8
getting there 4-1 P
issuing control commands 4-33 Parentheses in expressions
issuing operator commands 6-15 AND and OR keywords 5-7, 5-11, 5-15, 5-21,
Status panel 5-22, 5-23, 5-24, 5-26
displaying interrupted jobs 6-9 NOT keyword 5-27
issuing operator commands 6-15 purpose 5-3
recovering from system crash 6-18 Passwords 2-21
resubmitting jobs 7-16 Pending Job Profile report 7-9
transactions 7-10 Pitfalls 6-19
Online Monitoring panel 4-35 POST command 4-3
ONLY command 6-12, 6-13 POST DEPENDENCY field 4-25
OPER status 7-12 Post-CPU stations 1-2
Operator POWER
commands CLASS field 3-8, 3-16
displaying global parameters 6-8 HOLD status 6-18
for recovery 7-16 non-shared 7-25
issued in batch 7-10 Pre-CPU stations 1-2
multiple CPUs 7-22 PRED
on Status Display panel 6-20 flag 6-18
where they work 6-15 keyword 5-5, 6-18
messages 7-10, 7-15 status 7-12
OPERATOR CANCLD status 7-16 PRED keyword 7-29
OPERATOR on PREDECESSOR JOBS field 4-37
job panels 3-84, 6-9 Predecessors
schedule panels 3-28, 6-9 AND keyword 5-4
USER= parameter 4-23 deadlock 5-26, 6-10, 6-12, 6-13
OPSUB status 7-12 definition 1-6, 3-11, 3-60
Optional loop 5-26, 6-10, 6-12
job records 3-74 maintenance
schedule records 3-17 changing 6-20
Options 1-3, 3-18 defining 5-1, 5-6, 6-18
defining 3-18 overriding 6-16
OR keyword posting 4-38
DSN keyword 5-25 set manually 4-1
IF statement 7-11 multiple nodes 7-28
NOT keyword 5-27 NOT keyword 5-8
parentheses 5-7, 5-11, 5-15, 5-21, 5-23 OR keyword 5-7, 5-21, 5-25, 7-4
predecessors 5-8, 5-21 reserved words 5-4, 5-5
purpose 5-3 satisfying 4-3
REQUESTED 7-3 types
at different nodes 3-89

Predecessors (continued) RDnn keyword 5-3, 5-12
types (continued) Reasons
explicit 5-5 codes 4-13, 5-7, 7-4
from prior days 5-5, 6-18 Definition Panel 3-24, 3-80
generation data group 5-5 for selection 5-1
implicit 5-7, 6-6 multiple 5-7
non-scheduled DOS job 5-5 RECOVERABLE
other jobs or schedules 5-3, 5-4, 5-5, 5-6, 5-9, field 3-68, 6-18
5-21, 5-22, 5-23, 5-24, 5-25, 5-26, 5-27, 7-3, 7-4 Recovering scheduled jobs 7-15
output data set 5-5, 5-25 Recovery
tasks starting 5-3, 5-4, 5-5, 5-6 AUTO status 7-12
user-defined event 5-5, 5-27, 6-7 system crash 6-18
unposting 4-3, 4-25 RECS
waiting 4-21 field
Predicting the workload 6-11 job panels 3-74, 3-94
Prerequisites 5-1 schedule panels 3-8, 3-17, 3-20
Printing Relative days 5-3, 5-12, 5-17
jobs 4-17, 6-3 RELEASE command
run books 6-11 automatic recovery 4-17, 6-18
Priority-ordered queues 4-10 definition 4-32
Production HELD status 4-17
control 1-2 REMAINING TIME field 4-16
cycles 1-6, 5-12, 6-4 REORG command 1-12
day 4-5, 7-8 Reports
library 1-8 Advantage CA-Earl Database
tasks 1-1 user-defined 6-13
Progress notification 1-12 Analyze 6-10, 6-12
Prototype Date Translation Table 5-15
calendars 5-17 distribution 1-2
schedules 3-30 forecasts 6-11
Public schedules 3-5 Job Summary 6-12
PURGE command Pending Job Profile 7-9
definition 4-32 simulation 6-11
impacts dependencies 6-20 types 1-11
with CANCLD status 4-17 user-defined 6-13
with ENDED status 4-17 REQUEST
command
abbreviation 6-17
Q automatic recovery 7-17
QUERY MESSAGES field 4-23 definition 4-32, 4-34
Questions 6-2 inactive queue 4-6, 4-8, 4-18, 7-2
Queue predecessors 7-4
definitions 4-6 REQUESTED keyword
formats 4-11 daily processing 4-6, 6-17
sequence 4-10 impact on successors 7-3
Quick data entry 6-5 jobs purged by autoscan 7-2, 7-4
purpose 7-1
R RERUN
command
RC field 4-13
ABENDED status 7-16
CANCLD status 4-17, 6-17, 7-16
definition 4-34, 6-16
Index X-17
RERUN (continued) Satisfy predecessor conditions 4-3, 4-38
command (continued) SBR 3-6
edit checks 6-8 SC transaction 7-10, 7-13
ENDED status 4-17 SCD keyword 5-3, 5-4, 5-5, 5-6
FAILED status 4-17, 7-16 SCHD command 2-2
INTRPTD status 4-17, 6-9 SCHDUTIL Output Panel 2-9, 6-5
field 4-16 SCHED PRIORITY field, schedule display 3-8, 3-12
RESC status 7-12 Schedule
Reserved words 5-3, 5-4, 5-5 analyzing 3-40
Resetting Auto-Reply Maintenance 3-44
global parameters 6-21 maintenance
PRED flag 6-18 changing 3-18, 3-20
Resource copying 3-29
Definition panel 3-85 defaults 3-6
requirements 4-21, 6-7 defining 3-1, 3-3, 3-17, 3-20, 6-3, 6-4, 6-5
RESTAGE command 6-6, 7-17 deleting 3-36
Restart displaying 3-6, 3-20
instructions 1-8, 7-15 listing 3-32
job steps 7-18 messages 3-27
RESTORE option 7-24 priorities 3-12
Revising name 1-3, 3-55
jobs 3-91 panels
schedules 3-18, 3-20 Command Processor panel 6-15
ROUTE keyword 7-29, 7-32 Definition panel 3-4, 3-29
Routing Directory panel 3-29, 3-33, 3-34, 3-37
jobs 7-27 Display panel 3-7, 3-32
messages 1-12, 3-72, 6-9 Maintenance menu 3-4, 3-19
Rules governing Schedule Directory panel 3-35
criteria language 5-29 Summary Status Display 4-11, 4-15
datetables 5-13 processing
predecessors 5-7, 5-8, 5-9 backlog 4-16
selection 5-8, 5-9, 5-10 commands 6-15
RUN controlling 4-31
command recovery 7-15
automatic recovery 7-17 records
CANCLD status 4-17, 7-16 base 3-6
definition 4-32, 4-34, 6-16, 6-17 criteria record 3-6, 3-10, 3-11, 3-21, 4-13
ENDED status 4-17 information 3-6
reason code 4-13 message 3-6, 3-17, 3-74
staging jobs 6-5 reason code 3-6, 3-12, 3-62
IF REQUESTED queue 4-8 selection
ON SYSID field on additions 6-16
job panels 3-67, 7-21 criteria language 5-1, 5-3
schedule panels 3-8, 3-67, 7-21 rule 5-8
RUNBOOK 3-72, 6-9, 6-11 with REQUESTED 6-17, 7-2
Running backups 7-13 SCHEDULE NAME field 3-4
SCHEDULER Command Processor
panel 4-12
S panel, issuing control commands 4-33, 4-35
Sales cycles 1-6, 5-12, 6-4 Scheduling
CPU networks 1-13

Scheduling (continued) SID 7-19
jobs 1-5, 5-8, 5-18 SIMTIME 6-11
multiple CPUs 1-13 SIMULATE command 6-13
techniques 7-1 Simulation 1-11, 3-72, 6-9, 6-11, 6-12, 6-13
SCR 3-6, 3-10, 3-11, 3-21, 4-13 SIR 3-6
Security 1-9 SKIP field 3-10, 3-58
Selecting Slave CPU 7-24, 7-26
jobs SMR 3-6, 3-17, 3-74
ADD command 6-17 Sorting queues 4-10
criteria language 5-3 Specific dates 5-17, 6-4
process 1-7, 3-58 SRC 3-6, 3-12, 3-62
REQUESTED keyword 6-17, 7-2 SREQ
RUN command 6-16 command
with schedules 5-8 inactive queue 7-2
reports 1-11 SREQ command
schedules abbreviation 6-17
criteria language 5-3 definition 4-32, 4-34
instead of jobs 5-8 inactive queue 4-6, 4-8, 4-18
methods 6-3 predecessors 7-4
process 3-10 STAGE JCL field 3-9, 3-65, 6-6
REQUESTED keyword 6-17, 7-2 Staging
RUN command 6-16 file
SEND MESSAGE field 4-23 reports 6-13
Sending messages jobs 1-8, 3-9, 3-65, 6-3, 6-5
abended jobs 7-17 START
failed jobs 7-17 command 4-18, 4-22, 4-34, 7-14
interrupted jobs 6-9 keyword 5-3, 5-4, 5-5, 7-29
late jobs 3-16, 3-72 status 7-12
to TIME field 4-14
console 6-16, 7-10, 7-15 with WAIT status 7-15
other users 3-27, 3-83, 4-1, 4-3, 4-23, 6-16 STARTED
when non-CPU jobs start 3-72, 6-9 queue 4-6, 4-8
SENDMSG command 4-3 status 4-18, 6-18, 7-12, 7-14
SEPARATE Starting
DSNAME field 4-21, 6-7 jobs 6-16
JOBS field 4-21, 6-7 schedules 6-8, 6-16
Sequencing transactions 7-11
enforcement 1-2, 1-6 Unicenter CA-Scheduler 2-2
jobs 1-6 Station
queues 4-10 ID 2-9, 3-55, 3-64
workstations 1-2 maintenance
SET command 4-3, 6-8, 7-13 adding 1-11, 2-8, 6-3, 6-5
SET/DSPLY GLOBALS field 4-27 deleting 2-13
Setting global parameters 4-1, 4-3, 4-28 listing 2-15
SHARE installation option 7-20 numbers 1-2
Shared panels
JES 7-20, 7-27 Alter panel 2-11, 2-13
SHUTDOWN Definition panel 2-8
DELAY command 4-18 Directory panel 2-12, 2-14, 2-16, 2-17
HELD status 4-18 Display panel 2-16
Maintenance menu 2-7
Index X-19
Station (continued) Supervisor authority level 2-20
records 2-8 SYSID
standards 6-3 definition 7-19
Status installation option 7-20
checking 7-11, 7-14 status 7-32
codes 4-16, 6-18, 7-11 System
command 7-22 crash 3-68, 4-17, 6-18, 7-16
displays overview 1-7
content 4-1
default (D= omitted) 4-12
for specific schedules and jobs 4-9 T
getting there 4-4 TALTER command 4-32, 7-14
History (D=H) 4-14 TARGET option 7-24
issuing operator commands 6-20 Techniques 7-1
monitoring workload 1-10 TEXT= parameter 4-23
multiple CPUs 4-11 TIME
Time (D=T) 4-13 keyword, AUTOSCAN command 4-29
field 2-28, 2-34 status displays 4-13
nodes 7-32 Tips 6-1
values 7-11 Tracking file
status displaying, schedule status 4-3 additions 6-16, 6-17
Stopping Unicenter CA-Scheduler 2-6 backlogged work 7-8
SUBMFAIL status 7-12 during autoscan 1-7, 6-2
SUBMIT FORCE command 6-16
command global parameters 6-8
ABENDED status 4-17, 7-16 inactive queue 7-2
CANCLD status 4-17, 7-16 initialization 6-8
definition 4-34, 6-16 multiple CPUs 7-22
ENDED status 4-17 REQUESTED keyword 6-17
FAILED status 4-17, 4-19, 7-16 user-defined reports 6-13
INTRPTD status 4-17 Transactions 7-10, 7-13
UNKNOWN status 4-21
FAILED status 4-19, 4-34
IN PROGRESS status 4-18
U
UNCONNECTED status 7-32
SUBMITD status 4-21, 6-18, 7-12
Unicenter CA-Driver
SUBMITTED queue 4-6, 4-8
recovery 7-16, 7-18
Submitting jobs
restart parameters 6-16
across nodes 7-26
UNKNOWN status 4-21, 6-18
automatically 1-7, 6-7, 6-8
UNPOST command 4-3, 4-26
manually 4-22
Unposting predecessors 4-3, 4-25
multiple CPUs 7-23
Updating
RERUN command 6-16
database information 3-1
SUBMIT command 6-16
jobs 3-91, 3-94
Successor Chain List report 1-12, 6-11
schedules 3-20
SUCCESSOR JOBS field 4-37
station records 2-10
Successors 6-17, 7-2, 7-3, 7-17
status 1-9
Summary
user records 2-26
option for forecasts 6-12
USE SIMTIME field 3-9, 3-11, 3-61, 3-71
schedules 4-11
User
status display 4-15
-defined events 5-27

User (continued) WEEK-END keyword 5-3
authority levels 2-20 Weekends 5-12
defining 2-22, 6-5 WEEKLY frequency 5-18, 5-19
deleting 2-29 WOF keyword 5-3
documentation 3-71, 6-9 WOM keywords 5-13
listing 2-30 WORK WEEK field 5-13
logon status 2-28 Workdays 5-2, 5-3, 5-4, 5-10, 5-12, 5-15, 5-17
maintaining 2-20 Workstations 1-2
USER= parameter 4-23 WOY keyword 5-15
Userid WWOM keyword 5-12, 5-15
Alter panel 2-26, 2-29
CANCLD status 4-17
Definition panel 2-23 Z
Directory panel 2-28, 2-32, 2-33 ZONE parameter, CAIJNET macro 7-32
Display panel 2-31
HELD status 4-17
Maintenance menu 2-22, 2-34
USERS field
content 3-16
controls job records 3-58, 3-91
NULL value 3-20
purpose 3-5, 3-19
Using
HELP 2-4
menus 2-3
Utility program 6-5, 6-10, 6-12
V
VARY command 4-31, 7-33
VERIFY field 3-27
Verifying
applications 6-12
workload selection 6-11
VIA parameter, CAIJNET macro 7-32
VM commands 7-10
VRETRY installation option 7-31
VTAM communications 4-31, 7-26, 7-31
VTAMLIM option, CAIJNET macro 7-33
W
WAIT
queue 4-8, 4-21
status 4-21, 4-22, 4-34, 6-18, 7-12, 7-15
WDAY keyword 5-3, 5-4, 5-12, 5-15, 5-21, 5-23
WDOM keyword 5-3, 5-12, 5-20, 5-24
WDOW keyword 5-3, 5-12, 5-15, 5-20
Week keywords 5-3, 5-10, 5-12, 5-13, 5-15, 5-20
WEEK-DAY keyword 5-3, 5-10, 5-16
Index X-21

CA Scheduler

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CA Scheduler

Enviado por

Direitos autorais:

Formatos disponíveis

Unicenter CA-Scheduler

Job Management for VSE

 2005 Computer Associates International, Inc.

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Chapter 2. Startup Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Chapter 3. Maintaining the Database . . . . . . . . . . . . . . . . . . . . . 3-1

iv Unicenter CA-Scheduler User Guide

Chapter 4. Online Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Chapter 5. Criteria Language . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Chapter 6. Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Chapter 7. Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

vi Unicenter CA-Scheduler User Guide

Unicenter CA-Scheduler Job Management for VSE (Unicenter

Unicenter CA-Scheduler automates production control by scanning the

Because Unicenter CA-Scheduler is so versatile, it allows you to choose only

This chapter provides a high-level introduction to the terminology, key

Chapter 1. Introduction 1-1

1.1 Beginning with the Basics

Unicenter CA-Scheduler has you number workstations in ascending order for a

1-2 Unicenter CA-Scheduler User Guide

when you define jobs to Unicenter CA-Scheduler. Even if ARDAILY is a group

Think of a schedule as a timetable: it tells Unicenter CA-Scheduler when

Schedule Name When Jobs Run Job Names

Unicenter CA-Scheduler uniquely identifies a task by knowing four values:

Chapter 1. Introduction 1-3

That gives you a glimpse of how thoroughly Unicenter CA-Scheduler can

1-4 Unicenter CA-Scheduler User Guide

DAILY Every day

If you say that a schedule runs daily, Unicenter CA-Scheduler workload

Whether Unicenter CA-Scheduler includes a job in the daily workload depends

Chapter 1. Introduction 1-5

Schedule's Criteria Job's Criteria When A Job Can Run

The types of events that can be defined as predecessors include waiting:

Before Unicenter CA-Scheduler can begin automating your production

1-6 Unicenter CA-Scheduler User Guide

1.2 How Unicenter CA-Scheduler Works

Once a day, Unicenter CA-Scheduler scans the database to identify

Chapter 1. Introduction 1-7

Unicenter CA-Scheduler automatically submits jobs to the operating system

Jobs without early start times, without pre-CPU workstations, without

1-8 Unicenter CA-Scheduler User Guide

■ Display the current values of Unicenter CA-Driver reserved variable

Unicenter CA-Scheduler assists in managing production job rerun/restart in

False job completion frequently occurs. It is a case in which a job appears to

Users can communicate with Unicenter CA-Scheduler in online or batch mode.

Unicenter CA-Scheduler users can be assigned three levels of authority to

Security exits are also available for enhanced protection.

Chapter 1. Introduction 1-9

Using Unicenter CA-Scheduler menu-driven panels, users at different

1-10 Unicenter CA-Scheduler User Guide

1.3 Additional Features

Once Unicenter CA-Scheduler is automating production control for station 40

The Unicenter CA-Scheduler reporting facility provides a variety of reports

Production summaries report on various aspects of daily production that you

Chapter 1. Introduction 1-11

The Mailbox report provides a common area to route Unicenter CA-Scheduler

Successor Chain List reports provide a way of listing a job's or schedule's

Analysis reports can be used from batch or online to determine whether a

A variety of Advantage CA-Earl reports provide detailed information on the

A subset of Advantage CA-Earl is provided with Unicenter CA-Scheduler so

To better monitor production, you can cause messages to be sent to different

1-12 Unicenter CA-Scheduler User Guide

■ Abend, fail or are purged

Routing of late messages can be defined globally as an installation option. You

STATION ID : 4 PROTOTYPE STATION:

DEFINE STATION ID=4,NAME=CPU,TITLE='CPU STATION',

DEFINE STATION ID=4,NAME=CPU,TITLE='CPU STATION',