Base calendars define the processing days (workdays) and nonprocessing days (weekends and holidays) in your data center. They can also be used to define the beginning and end of each month if you do not use the standard Gregorian months. They also tell CA Workload Automation SE how to count relative days: whether to count every day or just processing days.
At least one calendar is required for every year. It is defined by coding keyword values in a CA Workload Automation SE macro which must then be assembled and link edited into the CA Workload Automation SE calendar library or load library. For detailed information about calendars, see Calendar Definition and Structure in the chapter "Installation Requirements" in the Systems Programming Guide. Once a calendar is defined, it can be referenced by any number of jobs.
Free-form, card-image documentation about any part of the workload can be stored in the CA Workload Automation SE database and then either displayed online or printed (through the batch-terminal interface). Relevant documentation can also be routed to a terminal and displayed there when a job is scheduled. Documentation can be defined for a CPU job, an application system, a data set, a network, a DD statement, or any other user-defined item. It can be manually entered into the database using the documentation screens or transferred to the CA Workload Automation SE database from other online sources. Documentation members can be divided into segments for easier retrieval.
When a job is ready to be processed under CA Workload Automation SE control, CA Workload Automation SE automatically finds its JCL and submits a copy of it to the computer for execution. Therefore, the JCL for each job under CA Workload Automation SE control must be stored in a CA Librarian, CA Panvalet for z/OS, or partitioned data set which can be dynamically accessed by CA Workload Automation SE.
Each library you use to store JCL must have a unique ID number and must be defined to CA Workload Automation SE on a JCL statement in the initialization file. Each library can have an alternate library which can be used to store temporary JCL; this alternate library is automatically searched before the permanent JCL library. Onetime overrides can be stored in a special override library. Other overrides can be made by adding special statements to the JCL or by using the CA Workload Automation SE text editor to change the JCL before it is submitted for execution.
A job is a task or unit of work directed to a CPU. Although CA Workload Automation SE can bypass CPU execution, a job usually includes a set of JCL control statements with one JOB statement and one or more steps that are executed on the computer. Jobs are defined to CA Workload Automation SE on the CPU Job Definition screen, either online or in batch mode. Each job's individual scheduling criteria can also be defined to CA Workload Automation SE so that the job can be automatically selected for processing on the right day, at the right time, in the right order.
Jobs that are defined to CA Workload Automation SE but do not have defined scheduling criteria can be run on request by issuing online commands. Jobs that have not been defined to CA Workload Automation SE can also be run on request; they are added to the database with default values the first time they are run by request. The LOAD command can be used to add jobs to the database without running them.
A network is a group of non-computer tasks that must be performed either before a job runs on the computer (input network) or after a job runs on the computer (output network). Each network consists of from one to nine workstations, listed in the order in which their tasks are performed. Input networks can be scheduled just like CPU jobs and can trigger CPU jobs. Input networks can also be defined as predecessors of CPU jobs so that the CPU job cannot run until its input network is complete. Output networks can be defined as successors of CPU jobs so that the output network is placed in the postprocessing queue when its CPU job is placed in the request queue.
Five disk data sets hold records of CPU jobs during different phases of processing. A job starts in the request queue. It is put there because of one of the following: the schedule scan program reads the database and finds out the job is scheduled for processing; it is triggered by an event; or it is requested by the LOAD, DEMAND, or RUN command. At the same time, the job's JCL is found in the appropriate JCL library and a copy is written to the trailer queue.
When all of the job's requirements are satisfied, the job record is moved from the request queue to the ready queue. When resources are available, the JCL is submitted to JES. When the job goes active on the system, the job record is moved to the active queue. At job termination, CA Workload Automation SE returns the job record to the request queue. If the termination was not successful, the record is held for operator intervention, and the JCL remains in the trailer queue so the job can be restarted. If the termination was successful, the job record is moved to the prior-run queue and the JCL is deleted from the trailer queue.
Two additional disk data sets hold records of noncomputer tasks: the preprocessing queue lists all input networks that are scheduled for processing; the postprocessing queue lists all output networks that are waiting for their CPU jobs to end so they can be processed.
Requirements are things that must happen before a job can run. They are called predecessors because they must precede the job. They can be the completion of another job, the completion of an input network, the completion of a manual task, or the creation of a data set. They can be defined for each job, in addition to its scheduling criteria.
When the job is brought into the queues for processing, its requirements are attached to it, and it cannot be released for processing until all of its requirements are satisfied (either automatically or manually). The requirements screens can also be used to define mutually exclusive jobs or output networks that are successors to CPU jobs.
Schedule IDs are numbers from 1 to 255 that are used to identify scheduling variations. Scheduling variations allow you to schedule the same job in different ways: at different dates and times, with different triggers, with different requirements, with different due-out times, and with different JCL overrides.
The schedule scan program scans the database as often as you specify, selects jobs that are scheduled for processing in the next few hours, and brings them into the request queue.
Each job can have its own unique scheduling criteria. This scheduling criteria is defined to CA Workload Automation SE on the scheduling screens and stored in the database with the job's definition. The scheduling criteria can be based on either dates and times or events. Date-and-time scheduling tells CA Workload Automation SE when to run a job, for example, the last workday of every month. CA Workload Automation SE then uses the calendar referenced on the scheduling screen to determine the exact processing days. Triggering tells CA Workload Automation SE to process a job after an event, regardless of when that event takes place. The event can be the completion of another job, the completion of an input network, or the creation of a data set.
The first job in a job stream is usually scheduled by date and time, and the rest of the jobs are then triggered. This ensures that jobs run in the proper order, while reducing calendar maintenance, schedule-scan activity, requirement posting, and the amount of jobs in the queues at one time.
A workstation is the place where a non-computer task is performed. Workstations where pre-CPU tasks are performed are grouped together as input networks. Workstations where post-CPU tasks are performed are grouped together as output networks. CA Workload Automation SE monitors each workstation and sends messages prompting the workstation terminal operator if its task is not started or completed on time. When a task at one workstation is finished, it must be manually posted as complete before the task at the next workstation can be started.
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|