Pinned topic The role of XD Compute Grid and Enterprise Schedulers (TWS, Control-M, etc)
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Compute Grid is an execution runtime for enterprise grid and java batch applications; it is not an enterprise scheduler. Enterprise schedulers serve as an integration point where the entire batch infrastructure is managed centrally. Artifacts such as enterprise-wide batch schedulers, dependencies among jobs and external resources, the location for where the job should execute, and so on are defined and managed at this point. XD Compute Grid works alongside enterprise schedulers and is essentially one destination where enterprise schedulers can dispatch to. Compute Grid’s primary objectives are to execute batch jobs with: high performance, recoverability, and availability.
On the z/OS platform, Compute Grid integrates with JES and allows jobs to be submitted via JCL. Since enterprise schedulers are familiar with how to manage JES batch jobs, they by proxy are able to manage Compute Grid jobs. Note that on z/OS, a native MQ client is used to for job submission and monitoring, therefore the job submissions don’t require the initialization and termination of a Java Virtual Machine, ensuring high performance. On distributed platforms, a java-based adapter client bridges the gap, once again by proxy, between the enterprise scheduler and Compute Grid.
Enterprise schedulers will centrally manage operational plans and other such scheduler-specific artifacts. These schedulers then dispatch batch jobs to XD Compute Grid via JES, on Distributed platforms, the details differ but the concept remains the same. XD Compute Grid will then execute the job assuring the defined qualities of service are met, and will notify the enterprise scheduler of job state information and other such execution data.
Compute Grid compliments enterprise schedulers such as TWS, Control-M, Zeke, etc; it doesn't replace them.
A quick checklist (courtesy of Chris Vignola) of the differences between Compute Grid and Enterprise Schedulers (Tivoli Workload Scheduler for now):
Compute Grid provides
1. batch programming model
2. batch development tools
3. batch execution environment (called 'batch container')
4. checkpoint/restart + failover
5. job operations: submit/cancel/stop/pause/resume
6. classification/WLM for batch jobs (requires OO on Distributed)
7. job management console (plus command line console and APIs)
8. job logs (viewable/retrievable through JMC, command line console, APIs)
9. job classes (rules for how much CPU, threads, etc, batch jobs can consume)
10. HA/scalability for job scheduler and batch container
11. support for both WAS-hosted batch applications and native applications
12. integration with Enterprise Schedulers- so the enterprise scheduler can be "on top" - i.e. be the superior job scheduler that sub-dispatches jobs to Compute Grid's job scheduler (that's called meta-scheduling). This enables Compute Grid jobs to be part of a larger workload scheduled by the enterprise scheduler.
Note: enterprise scheduler's have more powerful scheduling rules - time/date/resource (file) and does job choreography. Compute Grid has only time/date scheduling and does not do job choreography. Compute Grid does do multi-step jobs with conditional execution among the job steps based on return codes from the batch applications.
Enterprise Schedulers Provide
1. ability to define workload schedule with dependencies
2. ability to execute (JES jobs on z/OS, Unix/bat commands on Unix/Windows)
3. ability to execute these things based on time/date (once or recurring) + triggered based on resource (i.e. file)
4. ability to conditionally execute next thing in schedule based result of previous thing in schedule
5. on z/OS provides basic operations console so you can "visualize" workload - ont sure if it has this on Distributed or not
Message was edited by: Snehal Antani
Updated on 2008-01-26T19:23:18Z at 2008-01-26T19:23:18Z by SystemAdmin