Integration of an external workload scheduler to manage batch workloads
Many customers already use an external workload scheduler to manage batch workloads on the z/OS operating system. While Java batch running inside a WebSphere Application Server environment is attractive, a way to control batch jobs through an external workload scheduler is important.
External scheduler integration
Since an external scheduler does not know how to directly manage batch jobs, a proxy model is used. The proxy model uses a regular JCL job to submit, monitor, or submit and monitor the batch job. The JCL job step invokes a special program provided by batch, named WSGRID. The WSGRID application submits and monitors a specified batch job. WSGRID writes intermediary results of the job into the JCL job log. WSGRID does not return until the underlying job is complete, consequently providing a synchronous execution model. Since the external scheduler can manage JCL jobs, it can manage a JCL job that invokes WSGRID. Using this pattern, the external scheduler can indirectly manage a job. An optional plug-in interface in the job scheduler enables a user to add code that updates the external scheduler operation plan to reflect the unique state of the underlying job, such as job started, step started, step ended, job ended. The WSGRID program is written with special recovery processing so that if the JCL job is canceled, the underlying job is canceled also, thus ensuring synchronized life cycle of the two jobs.
The following diagram shows the job control by an external workload scheduler, but without JES being required.
(ZOS) The following diagram shows the job control by an external workload scheduler for the z/OS platform environment. In this diagram, the Tivoli Workload Scheduler is shown as an example workload scheduler.
Related: