Context

Tool mentors explain how a tool can perform tasks, which are part of ITUP processes and activities. The tasks are listed as Related Elements in the Relationships section.

You can see the details of how processes and activities are supported by this tool mentor, by clicking the links next to the icons:

•   Service Execution
  •   Schedule and Adjust Workload

Details

IBM® Tivoli® Workload Scheduler management of workload is based on a database that contains the definitions of the scheduling objects. There are two versions of the scheduling objects database depending on the placement of the main workload controller; it can be based on a mainframe computer (in this case, z/OS) or based on a distributed platform.

Some of the scheduling objects can exist in both of the databases, some apply only to the distributed platform, and others might apply only to the mainframe platform.

The same kind of scheduling objects might require different attributes depending on the platform.

The list of scheduling objects used by IBM Tivoli Workload Scheduler contains:

• Workstations
• Parameters
• Prompts
• Calendars and Periods
• Domains
• Workstation Classes
• Jobs
• Job Streams
• Resources
• Users

The entire Part 4 of the book I IBM Tivoli Workload Scheduler Job Scheduling Console User's Guide Version 8.3 , describes how to use the graphical interface (briefly called JSC) to build the definitions of the scheduling objects for both the mainframe-based objects and the distributed ones.

Descriptions of the specific definition activities that are related to the z/OS platform only, and that are not available from the Job Scheduling Console interface, can be found in the book IBM Tivoli Workload Scheduler for z/OS - Managing the Workload Version 8.2 . This book also describes how to define the other scheduling objects with the use of the traditional interfaces of the mainframe platform (ISPF panels), rather than using the JSC.

The description of the activities to define the scheduling objects in the distributed platform database without using the JSC interface are located in the book IBM Tivoli Workload Scheduler Reference Guide Version 8.3 in Chapter 3.

Refer to the previous guides for complete details on the scheduling objects and their attributes.

The minimum set of object definitions that are required to produce a workload with Tivoli Workload Scheduler is made of a workstation, a job, and a job stream. Other required scheduling objects might be predefined and exist by default.

Workstations are definitions that represent computer systems or other entities that are capable of the execution of specific tasks, and have the ability to report the status of task execution to the workload scheduler. With IBM Tivoli Workload Scheduler interfaces, the user can identify the physical resources associated with workstations. Chapter 10 of the IBM Tivoli Workload Scheduler Job Scheduling Console User's Guide Version 8.3 contains detailed information on this activity.

A job is the representation of a task (an executable file, program, or command) that is scheduled and launched by IBM Tivoli Workload Scheduler. The job is executed by a workstation and, after execution, has a status that indicates if the execution was successful or not. A job definition can specify information on what to do whenever its execution was not successful. Jobs not included in a job stream do not have any attribute for execution, and are only the description of a task with a definition on how to perform it in a form that is known to the specified workstation.

A job stream represents a container for related jobs and gives organization among them, in terms of time of execution, sequencing, concurrency limitations, repetitions, assigning priority or resources, and so on. Job streams are the macro elements of the workload that you need to manage.

The IBM Tivoli Workload Scheduler plan is the to-do list that tells IBM Tivoli Workload Scheduler what jobs to run, and what dependencies must be satisfied before each job is launched.

The plan is built by the IBM Tivoli Workload Scheduler using the elements that are stored in the scheduling database.

On the z/OS platform there are two plans, the long-term plan (LTP) and the current plan. The long-term plan (LTP) contains a high-level description of the work that is scheduled for the coming weeks or months. The current plan (CP) is the Tivoli Workload Scheduler for z/OS schedule, providing the detail that is required to control the processing. The current plan is derived from a section of the long-term plan and contains the work that Tivoli Workload Scheduler for z/OS will run. As your batch processing is submitted and run, the current plan is updated to reflect the actual status of the work. The long-term plan does not contain all the information that Tivoli Workload Scheduler for z/OS needs to submit work to your system. Before Tivoli Workload Scheduler for z/OS can schedule work, you must produce a detailed plan, called the current plan. The process of producing the current plan is called daily planning.

For the distributed platform, the LTP of IBM Tivoli Workload Scheduler for z/OS corresponds to the preproduction plan. The preproduction plan contains the job stream instances to be run during the covered time interval together with the external dependencies. The distributed plan can cover any period of time, not just 24 hours. The period covered by the plan is referred to as the production day. The plan starts at the time that is defined by the start global option, which is set by default to 6:00 a.m. A new plan is created at the start of the production day and is placed in a production control file named Symphony. After the plan has been created, a copy of this file is sent to all subordinate workstations. The subordinate domain managers distribute their copy to all the FTAs in their domain and to all the domain managers that are subordinate to them, and so on down the line. This process enables fault tolerant agents throughout the network to continue processing even if the network connection to their domain manager is down. At each destination FTA, the IBM Tivoli Workload Scheduler processes access the copy of the Symphony file, read the instructions about which job is to be run, and makes calls to the operating system to launch jobs as required. The operating system runs the job, and in return informs IBM Tivoli Workload Scheduler whether the job has completed successfully or not. This information is entered into the Symphony file to indicate the status of the job. In this way the Symphony file is continuously updated with the status of the jobs, that is, the work that needs to be done, the work in progress, and the work that has been completed. If the FTA is not full-status, it monitors only what concerns its own job processing. If it is full-status, it also monitors what happens in its domain and in child domains of its domain. Every FTA receives the same Symphony file and every FTA updates the parts of the Symphony file to which it is related, while the master domain manager (and its backup) contains a copy of the Symphony file that contains all of these updates. To turn over a new day, pre-production setup is performed for the upcoming day, and post-production logging and reporting is performed for the day just ended.

The execution of a plan requires tracking to identify possible problems that can impact the effective delivery of the work products.

It is possible to perform the tracking from the JSC on either one of the platforms (z/OS and distributed). As an alternate interface to JSC on the z/OS platform you can also use native ISPF panel interface, and on the distributed platforms you can use the command line interface.

Part 6 of the book IBM Tivoli Workload Scheduler Job Scheduling Console User's Guide Version 8.3 , describes how to use the JSC to manage the plan execution, for example, by releasing jobs or holding execution of a schedule, and it describes both the z/OS and distributed operational modes.

Part 2 of the book IBM Tivoli Workload Scheduler for z/OS - Managing the Workload Version 8.2 describes the use of ISPF panels to monitor and control workload plan execution, handling operations in error and so on.

The same kind of activity for the distributed environment is covered by Chapter 5 of the book IBM Tivoli Workload Scheduler Reference Guide Version 8.3 that describes the command line interface command called conman to monitor and control execution flow.

For More Information

For more information about this tool, click on the link for this tool at the top of this page.