Beruflich Dokumente
Kultur Dokumente
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.
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
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
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-9
Contents vii
Chapter 1. Introduction
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 can also think about work the same way you do. If
your production jobs are called AR004 or ARDAILY, use those same names
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.
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.
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.
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:
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.
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:
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.
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
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.
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.
The Date Translation Table report shows when work day, accounting, and
Gregorian conditions (like MON) are true.
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
■ Unicenter CA-Driver procedure library
Use these reports to determine when the files require reorganization (REORG
command).
The CAISERV facility allows you to produce diagnostic reports for checking the
current values of product options and assisting in troubleshooting problems.
Unicenter CA-Scheduler can handle the production traffic of the busiest data
centers.
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.
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.
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.
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.
When you type that command and press ENTER, the Unicenter CA-Scheduler
Logon panel appears:
USERID : master
CONNECT STATION : 4
PF1=HELP
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.
For now, type 40 as your connect station and press Enter. Unicenter
CA-Scheduler responds by displaying its main menu.
-------SELECT FUNCTION-------
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.
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):
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.
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.
Try logging off Unicenter CA-Scheduler now. Then you can log on again in
preparation for the next topic.
Bring up the Unicenter CA-Scheduler main menu as a starting point and tab to
STATION MAINTENANCE.
-------SELECT FUNCTION-------
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:
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY............(PRESS ENTER)
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.
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.
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.
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:
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.
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.
Begin by checking which option on the Station Maintenance menu allows you
to update existing records:
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY............(PRESS 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.
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:
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY............(PRESS ENTER)
PF1=HELP
The first entry on the menu preceding tells you to press Enter to display a
directory of station records.
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.
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY............(PRESS 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.
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:
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 THIS IS A TEST RECORD
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
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
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY............(PRESS 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:
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:
ID STNAME TIME-ZN D E S C R I P T I O N
4 CPU WHERE THE JOBS ARE RUN
END OF DIRECTORY LIST
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.
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:
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 THIS IS A TEST RECORD
END OF DIRECTORY LIST
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:
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 THIS IS A TEST RECORD
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
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.
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
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.
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.
-------SELECT FUNCTION-------
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
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.
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.
USER ID DESCRIPTION :
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
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:
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:
PF1=HELP
Next, create two other user records with different types of authority:
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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.
USER ID DESCRIPTION :
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:
PF1=HELP
Unicenter CA-Scheduler allows people with different authority levels alter
different fields in user records:
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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:
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:
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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 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.
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.
Display the user record for ACCTG. On the UserID Maintenance menu,
choices 1 and 2 both display a user record, but in different formats.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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:
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:
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.
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.
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:
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:
PRESS ENTER FOR NEXT PAGE
When this message appears, press that key to view the remainder of the list.
To display a userid's complete record, you would tab to that userid and enter
a D.
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 (*):
For example, typing 1,*P causes Unicenter CA-Scheduler to display records for
all userids that start with the letter P:
PF1=HELP
Now return to the UserID Maintenance menu to try the last method for
displaying user records.
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.
PF1=HELP
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:
Press Enter
all userids Press Enter to scroll
panels
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
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
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.
-------SELECT FUNCTION-------
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
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.
USERS:
LIBRARY TYPE :
POWER CLASS :
POWER PRIORITY: POWER USER:
AUTO-REPLY MESSAGES: N
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.
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.
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.
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.
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:
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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.
USERS: userid
LIBRARY TYPE : CMS
POWER CLASS : A
POWER PRIORITY: POWER USER :
AUTO-REPLY MESSAGES: N
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.
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.
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.
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.
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.
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.
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,
■ AllFusion CA-Librarian
■ 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
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.
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.
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.
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
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).
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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
USERS: userid
LIBRARY TYPE : CMS
POWER CLASS : A
POWER PRIORITY: POWER USER :
AUTO-REPLY MESSAGES: N
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.
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.
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.
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.
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.
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:
PF1=HELP
To advance to the next panel, press Enter.
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.
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:
PF1=HELP
Use of reason codes provides you with tremendous scheduling flexibility. To
advance to the next panel, press Enter.
FORM : QUANTITY :
NOTIFY : j smith RESPONSIBILITY: j smith
VERIFY :
SPECIFICATION :
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:
PF1=HELP
To view the next panel, press Enter. That displays the panel that defines the
last optional schedule record.
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.
PF1=HELP
To view the next panel, press Enter. Then press Clear to return to the Schedule
Maintenance menu.
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.
USERS:
LIBRARY TYPE : CMS
POWER CLASS : A
POWER PRIORITY: POWER USER :
AUTO REPLY MESSAGES: N
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:
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.
To display the record for your backup schedule, on the Schedule Maintenance
menu, option 2 displays a complete schedule base record.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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:
USERS:
LIBRARY TYPE : CMS
POWER CLASS : A
POWER PRIORITY: POWER USER :
AUTO-REPLY MESSAGES: N
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:
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 first entry on the Schedule Maintenance menu tells you to press Enter to
display a directory of schedule records.
A summary of all the commands that the Schedule Directory panel supports is
shown in the following table.
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.
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:
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
PF1=HELP
Pressing Enter at that menu causes the following panel to appear.
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.
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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.
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.
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
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
PF1=HELP
To analyze the schedule, enter 6, followed by the schedule name.
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.
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
PF1=HELP
PF1=HELP
Before beginning the next topic, return to the Unicenter CA-Scheduler Main
Menu by pressing Clear.
You begin by tabbing to the Auto-Reply Maintenance line and pressing Enter.
-------SELECT FUNCTION-------
Scantxt :
Reply:
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 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
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
To add the record to the database, either enter ADD on the command line or
press the function key.
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
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.
Scantxt :
Reply:
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
The messages CACO372I UPDATE FIELDS AND PRESS ENTER and ALTER
will be displayed in the command area.
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
Type the changes in the appropriate fields and press Enter.
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
To delete an existing reply, enter the schedule name on panel SCHD-AR and
press Enter to search for the message to be deleted.
Scantxt :
Reply:
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
The message CACO369I PRESS ==> PF5 <== TO CONFIRM DELETE and
DELETE will be displayed in the command area.
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
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.
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
-------SELECT FUNCTION-------
PF1=HELP
Then tab down to the sixth selection, JOB MAINTENANCE, and press Enter.
That choice displays the Job Maintenance menu, that lists everything you can
do with job records:
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
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.
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:
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
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.
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:
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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.
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.
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?
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
■ EARLIEST START TIME
■ JRC DEADLINE TIMEs
■ COMPLETION DEADLINE TIME
■ JOB PRIORITY
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.
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.
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.
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.
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.
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.
Factors determining the order of jobs within schedules are listed following in
decreasing order of importance.
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.
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?
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.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
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.
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).
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.
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.
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.
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.
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.
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.
Several fields on the job base record determine what happens when something
goes wrong or when unusual circumstances occur:
■ ABEND
■ BACKLOG
■ FAIL CODE
■ RECOVERABLE
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.
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.
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
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 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.
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.
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.
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.
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.
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.
These types of records will be discussed in the topic called Defining Optional
Job Records.
The following text describes a much quicker method. You can do this by
copying an existing job.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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.
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
displaying the following panel:
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.
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.
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.
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.
PF1=HELP
To advance to the next panel, press Enter.
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
■ EARLIEST START TIME
■ MUST START BY TIME
■ COMPLETION DEADLINE TIME
■ MAXIMUM EXECUTION TIME
A job reason code record works just like a schedule's reason code record:
■ 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.
■ 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.
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.
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.
PF1=HELP
Use of reason codes provides you with scheduling flexibility. To advance to
the next panel, press Enter.
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.
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
displaying the following panel:
PF1=HELP
To view the next panel, press Enter. That displays the panel that defines the
job's message record.
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.
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:
PF1=HELP
To view the next panel, press Enter.
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:
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.
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.
PF1=HELP
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.
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.
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
responds by displaying the following message:
PF1=HELP
Press Clear to return to the Job Maintenance panel before starting the next
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.
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:
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
PF1=HELP
This panel tells you to press Enter to display a complete directory of jobs. That
panel appears following:
PF1=HELP
From this panel you can display or alter any type of job record. Enter the
following commands next to the job name.
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.
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.
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:
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:
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.
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:
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.
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
PF1=HELP
Pressing Enter at that menu causes the following panel to appear.
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.
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:
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:
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS 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 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.
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:
PF1=HELP
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
PF1=HELP
To analyze the schedule, enter 6, followed by the job name.
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.
FUNCTION ENTER
-------- ------
DISPLAY FULL DIRECTORY........... (PRESS ENTER)
PF1=HELP
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.
PF1=HELP
Before beginning the next topic, return to the Main Menu by pressing Clear
repeatedly.
-------SELECT FUNCTION-------
Scantxt :
Reply :
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
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 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
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
To add the record to the database, either enter ADD on the command line or
press the function key.
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
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.
Scantxt :
Reply :
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
The messages CACO372I UPDATE FIELDS AND PRESS ENTER and ALTER
will be displayed in the command area.
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
Type the changes in the appropriate fields and press Enter.
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
To delete an existing reply, enter the job name on panel SCHD-AR and press
Enter to search for the message to be deleted.
Scantxt :
Reply :
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
The message CACO369I PRESS ==> PF5 <== TO CONFIRM DELETE and
DELETE will be displayed in the command area.
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
Enter -Browse 2/14 -Add 7/19 -Backward 8/2 -Forward Clear -Quit
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:
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.
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.
-------SELECT FUNCTION-------
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.
MISCELLANEOUS COMMANDS
1 ONLINE STATUS 4 POST DEPENDENCY 7 DISPLAY
2 QUERY MESSAGES 5 UNPOST DEPENDENCY
3 SEND MESSAGE 6 SET/DISP GLOBALS
PF1=HELP
The following table describes what you can do with the various fields on this
panel.
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.
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.
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.
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.
Jobs with the same priority (the same values for all four factors) are sorted
alphabetically.
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.
OR=P and
SYS=sysid other than the SYSID of the CPU you are logged on to, the SYSID
will be ignored.
OR=P.
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
Notice that using OR=P significantly improves response time for all queues
except ACTIVE, ALL, ABENDED, and FAILED.
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:
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
JDAY1OF4 1 4 1 1 ENDED
JDAY3OF3 1 4 1 1 ENDED
JDAY3OF5 1 4 1 1 ENDED
JDAY3OF6 1 4 1 1 ENDED
JWEK1OF2 1 4 1 1 ENDED
JWEK3OF3 1 4 1 1 ENDED
JWEK3OF4 1 4 1 1 ENDED
JWEK3OF6 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
PRESS ENTER FOR NEXT PAGE PF1=HELP
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.
By specifying
D=T, you get the Time Status Display. The panel following illustrates output
that could result from typing just
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 .
PRESS ENTER FOR NEXT PAGE PF1=HELP
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).
By specifying
D=H, you get the History Status Display. The panel following shows output
that could result from typing just
D=H in the COMPLETED field on the Online Status panel. Average time is
shown in hh.mm format.
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
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.
By specifying
D=S, you get the Schedule Summary status display. This panel shows output
that could result from typing just
D=S in the ACTIVE field on the Online Status panel. Average time is shown
in DD/hh.mm format.
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
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.
The last two characters tell you why the submission failed:
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.
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.
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.
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.
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.
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
CA-Scheduler Reference Guide Part 1.
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
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
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.
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.
MILTON
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
CACM54I
PRESS ENTER FOR NEXT PAGE PF1=HELP
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 USG24ME XAE2 JES2 A4SS2 UNCONNECTED K
CACM54I USG212ME XAE3 JES2 A12SS1 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.
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:
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.
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
Reference Guide Part 1.
The following defaults are taken if you do not enter these keywords:
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:
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.
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
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.
PREDECESSOR JOBS:
SUCCESSOR JOBS:
PF1=HELP
When you are done, press Enter to add the job to today's schedule.
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
command line (===>). You may enter keywords by separating them from 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.)
To Specify Abbreviation
Identify
-who the message goes to USER=ALL or U=
USER=OPERATOR or
USER=userid
People with Manager authority can post and unpost predecessor conditions.
That is done by entering the following values in the Online Monitoring panel.
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 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
To Display Enter
The network information from the CAIJNET table in an NJE 7,NET
environment
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)
The following topics explain the criteria vocabulary and calendar mechanisms.
The following discusses these categories in more detail and contains some
examples.
The examples following show how these reserved words can be used to handle
real scheduling situations.
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
The following examples demonstrate the use of selection reserved words. Each
of these examples is called a condition.
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)
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.
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.
Some examples that define selection and predecessor criteria for JOBC follow.
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.
is the same as
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.
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.
Another example will help reinforce this point. Consider this criteria statement
associated with JOBC:
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.
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.
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.
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:
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:
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?
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.
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:
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.
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.
PF1=HELP
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.
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.
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).
datetable on this transaction if you desire. Reviewing this report will help you
understand the Gregorian calendar and datetables better.
JULIAN DATE=95251
TABLE NAME=DATETAB
GREGORIAN DATE=9/8/95
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
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
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.
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.
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.
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.
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.
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
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
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
Example 7
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 example preceding shows how you can define selection criteria at the
schedule level and predecessors at the job level. Separating selection criteria
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.
What happens on holidays? On holidays, you do not want the job to run. To
omit holidays, revise the criteria as follows:
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.
Since the weekly job will always run on the last workday of the week, you can
simplify the criteria statement preceding as follows:
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.
■ 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.
Example 1
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.
Example 2
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.
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:
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
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:
Now it is a bit clearer. First, look at the selection criteria. Both jobs are always
selected on Mondays and Wednesdays:
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
Suppose you want JOBA to run on any day but Monday or Tuesday. Why
does the criteria statement preceding not make that happen?
Example 5
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 in SCHED01 is selected, only these predecessors are left for
evaluation:
When JOBA is not in the day's workload, Unicenter CA-Scheduler knows that
it cannot be a predecessor.
Example 6
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
To reduce the possibility of destructive errors, this feature does not permit you
to alter or delete multiple records.
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.
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
Reference Guide Part 2.
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.
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
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
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.
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.
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.
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.
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
users in the SEND START MESSAGES TO list defined on the job's Message
Definition panel.
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.
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.
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.
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.
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.
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
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.
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.
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
ONLY SCHEDULE N=APPL1S2
ONLY SCHEDULE N=APPL1S3
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.
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.
other Advantage CA-Earl members that are used in producing the preceding
reports and that you may need for any reports that you build.
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?
6.1.4.3 Summary
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.
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
6.2 Pitfalls
This topic discusses some of the pitfalls you may encounter.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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 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
CA-Scheduler Reference Guide Part 1.
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:
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.
Transaction:
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.
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.
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:
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
Transaction:
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:
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:
Read as:
The job that is executing CAJUCMD0 right now wants to determine if the
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:
The job that is executing CAJUCMD0 right now wants to determine if the
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
The following depicts the general environment that the samples will reference.
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.
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.
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.
All of the preceding jobs are within the schedule SH001. The schedule runs
every day and so does each job.
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.
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.
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.
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.
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.
7.7 Summing Up
The following is a review of the important principles outlined previously.
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.
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.
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.
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).
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.
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
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
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
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
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
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
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
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
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
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