Concepts

In managing production workloads, IBM Z Workload Scheduler builds on several important concepts.

Plans. IBM Z Workload Scheduler constructs operating plans based on user-supplied descriptions of the DP operations department and its production workload. These plans provide the basis for your service level agreements and give you a picture of the status of the production workload at any point in time. You can simulate the effects of changes to your production workload, calendar, and installation by generating trial plans.

IBM Z Workload Scheduler schedules work based on the information you provide in your application (job stream) descriptions.

You can plan for maintenance windows in your hardware and software environments. IBM Z Workload Scheduler helps you perform a controlled and incident-free shut down of the environment, preventing last-minute cancellation of active tasks. You can choose to reroute the workload automatically during any outage, planned or unplanned.

IBM Z Workload Scheduler tracks jobs as they are processed at workstations and dynamically updates the plan with real-time information on the status of jobs. You can view or modify this status information online using the workstation ready lists in the dialog.

Virtual Workstations.Using virtual workstations improves workload balancing and the monitoring of system availability. This feature automatically directs the submission of workload to different destinations removing the need to associate a workstation to a specific destination. You can define a list of destinations for the submission of workload and the scheduler distributes the workload to automatically-selected active destinations, according to a round-robin scheduling approach.

You can activate this feature by specifying the new virtual option at workstation definition level. This option is allowed for computer workstations with the automatic reporting attribute, and is supported by all the interfaces available to define, modify, and monitor workstations.

Using virtual workstations the scheduler distributes the workload across your trackers evenly, thus avoiding bottlenecks when submitting or running jobs. In fact, the scheduler splits the workload among the available destinations, so that the Job Entry System (JES) and Workload Manager (WLM) do not find overloaded input queues when selecting jobs for their action.

Dependencies. In general, every DP-related activity must occur in a specific order. Activities performed out of order might create invalid output and possibly even corrupt your corporate data. This might cause costly reruns, missed deadlines, and unsatisfied customers.

You can define dependencies for operations (jobs) when a specific processing order is required. When IBM Z Workload Scheduler manages the dependent relationships for you, the jobs are always started in the correct order every time they are scheduled. A dependency is called internal when it is between two jobs in the same job stream, and external when it is between two jobs in different job streams. A dependency takes place between a predecessor operation and a successor operation, whereby the successor can start after its predecessor has completed.

The resolution of a dependency is resolved based on the input arrival times - theoretical start times that help define a specific application occurrence - of the applications of which the predecessors and successors are part. A dependency is resolved when a best matching predecessor is found according to the criteria defined for that dependency. The criteria can be that the best matching predecessor can be found within the closest preceding occurrence with respect to the successor, or in one that runs in the same day or within a specific interval of days or hours. Also, a dependency can be defined as mandatory to various degrees.

In addition, you can specify conditional dependencies, where you use the return code and status of an operation to determine the start of another operation. Standard logical operators are supported to define the check on status or return code values, to implement the definition of dependencies with a conditional logic. If the predecessor operation is associated to a job with different steps, you can specify a conditional step-level dependency on individual step return codes.

IBM Z Workload Scheduler lets you serialize work based on the status of any DP resource. A typical example is a job that uses a data set as input, but must not start until the data set is successfully created and loaded with valid data. You can use resource serialization support to send availability information about a DP resource to IBM Z Workload Scheduler.

Special resources. Special resources are typically defined to represent physical or logical objects used by jobs. A special resource can be used to serialize access to a data set or to limit the number of file transfers on a particular network link. The resource does not have to represent a physical object in your configuration, although it often does.

IBM Z Workload Scheduler keeps a record of the state of each resource and its current allocation status. You can choose to hold resources if a job allocating the resources ends abnormally. You can also use the IBM Z Workload Scheduler interface with the Resource Object Data Manager (RODM) to schedule jobs according to real resource availability. You can subscribe to RODM updates in both local and remote domains.

IBM Z Workload Scheduler lets you subscribe to data set activity on z/OS® systems. The data set triggering function of IBM Z Workload Scheduler automatically updates special resource availability when a data set is closed. You can use this notification to coordinate planned activities or to add unplanned work to the schedule.

Calendars. IBM Z Workload Scheduler uses information about when the job departments work, so that job streams are not scheduled to run on days when processing resources are not available (for example, Sundays and holidays). This information is stored in a calendar. IBM Z Workload Scheduler supports multiple calendars for enterprises where different departments have different work days and non-working days. Different groups within a business operate according to different calendars.

The multiple calendar function is critical if your enterprise has installations in more than one geographical location (for example, with different local or national holidays).

Business processing cycles. IBM Z Workload Scheduler uses business processing cycles, or periods, to calculate when your job streams run, for example, weekly, or every 10th working day. Periods are based on the business cycles of your customers. IBM Z Workload Scheduler supports a range of periods for processing the different job streams in your production workload.

Run cycle groups. One of the elements that make up the definition of an application is the run cycle, where you specify the temporal details of when the application should run in terms of time, days, weeks, months, or periods (and several other details). An application can have several definitions of run cycles, which become part of the definition of that application. There are several types of run cycles, such as regular, exclusive, rule-based, or period.

Going one step further, you can define run cycle groups. These are database objects in their own right, and are not part of the definition of an application, but the same run cycle group can be used by more than one application. A run cycle group is a list of run cycles that, combined together, produce a set of run dates.

You can structure a run cycle group into subsets. Within a subset you can match an exclusive run cycle against a positive one to generate negative occurrences, which identify the days when an application is normally scheduled to run but is bypassed.

You can make use of the logical AND between two run cycles in a group. This enables you to easily define rules that schedule work on complex run dates.