Previous Topic: Deleting DocumentationNext Topic: Schedule ID Examples


Concepts

Calendar

Base calendars define the processing days (workdays) and nonprocessing days (weekends and holidays) in your data center. They can also define the beginning and end of each month when you do not use the standard Gregorian months. They also tell CA WA CA 7 Edition how to count relative days: whether to count every day or only processing days.

At least one calendar is required for every year. Coding keyword values in a CA WA CA 7 Edition macro defines a calendar. Next, assemble and link edit the macro into the CA WA CA 7 Edition calendar library or load library. Once a calendar is defined, any number of jobs can reference it. For more information about calendars, see the Systems Programming Guide.

Documentation

Free-form, card-image documentation about any part of the workload can be stored in the CA WA CA 7 Edition 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 database from other online sources. Documentation members can be divided into segments for easier retrieval.

JCL

When a job is ready to be processed under CA WA CA 7 Edition control, CA WA CA 7 Edition automatically finds its JCL and submits a copy of it to the computer for execution. Therefore, the JCL for each job under CA WA CA 7 Edition control must be stored in a CA Librarian, CA Panvalet for z/OS, or partitioned data set that CA WA CA 7 Edition can dynamically access.

Each library that you use to store JCL must have a unique ID number and must be defined to CA WA CA 7 Edition 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. One-time 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 WA CA 7 Edition text editor to change the JCL before it is submitted for execution.

Job

A job is a task or unit of work directed to a CPU. Although CA WA CA 7 Edition 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 WA CA 7 Edition on the CPU Job Definition screen, either online or in batch mode. Each job's individual scheduling criteria can also be defined to CA WA CA 7 Edition 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 WA CA 7 Edition but do not have defined scheduling criteria can be run on request by issuing online commands. Jobs that have not been defined to CA WA CA 7 Edition 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.

Network

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

Queue

The active workload, also known as the queues, holds records of the CPU jobs during different phases of processing. A job starts in the request queue. The job is put there because of one of the following reasons:

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 WA CA 7 Edition 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 more areas in the active workload hold records of noncomputer tasks:

Requirement

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 ID

Schedule IDs are numbers from 1 to 999 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.

Schedule Scan

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.

Scheduling

Each job can have its own unique scheduling criteria. This scheduling criteria is defined to CA WA CA 7 Edition 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 WA CA 7 Edition when to run a job. For example, the last workday of every month. CA WA CA 7 Edition then uses the calendar that is referenced on the scheduling screen to determine the exact processing days. Triggering tells CA WA CA 7 Edition 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 scheduled by date and time, and the rest of the jobs are then triggered. This method ensures that jobs run in the proper order, while reducing calendar maintenance, schedule-scan activity, requirement posting, and the number of jobs in the queues at one time.

Workstation

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 WA CA 7 Edition 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.