Comparison of Deployment Scenarios for Enterprise Wide Scheduling

Abstract

In an environment with both mainframe and distributed scheduling requirements, in addition to end-to-end scheduling where Tivoli Workload Scheduler for z/OS is used to manage both the mainframe and the distributed schedules, there are two other alternatives: keeping Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS engines separate, or managing both mainframe and distributed environments from Tivoli Workload Scheduler (Distributed Scheduler) using the z/OS extended agent. This Technote discusses the pros and cons of these alternatives.

Contents


Keeping Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS separate

Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS can be used in conjunction with one another in an end-to-end environment, or they can be used separately. To keep them separate is up to you--there may be specific business reasons or perhaps separate people work directly with the UNIX or Windows systems from those who work on the mainframe. Whatever the case may be, the ability to keep Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS separate exists.

Figure-1 shows this type of environment.

Keeping Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS separate

Figure-1 Keeping Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS separate

The result of keeping Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS separate is that your separate business groups can create their own planning, production, security, and distribution models, and thus have their scheduling exist independently and continue to relate to the application requirements.

There are some operational and maintenance considerations for having two separate Tivoli Workload Scheduler planning engines:

  • The dependencies between Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS need to be handled by the user. This can be done by using the extended agent on Tivoli Workload Scheduler, and outside the current scheduling dialogues by using data set triggering or special resource flagging (both of which are available to Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS) to communicate between the two environments.
  • It is difficult to manage the planning cycles of independent scheduling engines, especially since they do not have the same feature set. This makes it sometimes troublesome to meet the all the dependency requirements between platforms.
  • Keeping both Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS engines means there are two pieces of scheduling software to maintain.


Note: This scenario can be used as a bridge to end-to-end scheduling (that is, after deploying Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS products separately, you can connect the distributed environment to the mainframe and migrate the definitions to see the end-to-end scheduling in action).

Managing both mainframe and distributed environments from Tivoli Workload Scheduler using the z/OS extended agent

It is also possible to manage both mainframe and distributed environments from Tivoli Workload Scheduler using the z/OS extended agent. Figure-2 shows this type of environment.

Managing both mainframe and distributed environments from Tivoli Workload Scheduler using the z/OS extended agent
Figure-2 Managing both mainframe and distributed environments from Tivoli Workload Scheduler using the z/OS extended agent

This scenario has the following benefits:

  • It is possible to do centralized monitoring and management. All scheduling status providing up-to-the-minute information on job and application states and current run-time statistics can be derived using the common user interface. Also, you can define inter-platform dependencies for both scheduling environments.
  • Each business unit can produce its own planning, production, security, and distribution model.
  • Mainframe production planning and execution is handled separately from distributed job planning and execution. One does not (necessarily) affect the other.

Some of the considerations of an end-to-end environment are:
  • The graphical interface shows distinct parts of the overall application flow, but not the overall picture. Also, there is no console (ISPF or Telnet) view that can show the entire plan end-to-end.
  • The z/OS agent is another component that must be installed and maintained. Since the parallel engines can run on different cycles and there is no “master” coordinator to manage parallel tasks cross-platform, coordination of the engines needs careful planning.

Mainframe-centric configuration (or end-to-end scheduling)

In this environment Tivoli Workload Scheduler for z/OS is used to manage both the mainframe and the distributed schedules.

This scenario has the following benefits:

  • All scheduling aspects from production planning, dependency resolution, and deadline management to job and script definition can be centrally managed.
  • It has robust productive planning capabilities such as the latest available job arrival times, critical job deadline times, and repeated applications.
  • Localized job execution allows distributed execution to continue even during planned or unplanned system downtime.
  • It allows console or GUI-based centralized monitoring. The z/OS scheduling engine provides scheduling status and up-to-the-minute information on job and application states and current run-time statistics directly from the planning engine. There is also an alternate “3270”-based single administrative console for enterprise scheduling.
  • You can have enterprise application integration with this solution. Integration into both OS/390 and distributed-based applications including TBSM, SA/390, TDE, WLM is possible.


Note: For more information about application integration in an end-to-end environment, you can refer to the IBM Redbook Integrating IBM Tivoli Workload Scheduler with Tivoli Products, SG24-6648.

There are also some considerations, such as:

  • Business units, e-business, and so on are no longer autonomous. All management is done from the mainframe. No option exists to segregate off components to be managed separately.
  • There are a lot of moving parts, and proper planning, knowledge, training, and so on is necessary.

Special Notices

This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.

Profile

Publish Date
09 May 2006


Rating: Not yet rated


Author(s)

IBM Form Number
TIPS0614