In mission-critical system environment, back-end servers normally busy with huge amount of batch jobs. Their schedule is not as simple as cron on Linux or Unix system which is time-based scheduling only. Each job normally depends on the status of several other jobs and/or non-job events such as messages, file access/release, and/or even date/time and specific business calendar. All of jobs and their dependencies are described in the operation "run-book". Before a job is scheduled, operator must be very sure all required conditions have been complied. Such mechanism usually handled by a team of operators which able to work under high pressure. They stick their eyes to the console screen and run-book. Any mistakes in whatever can potentially bring the whole system into very expensive emergency situation.
With the automatic workloads scheduler, operators may ignore their detail work. The content of run-book are stored into the scheduler database and let scheduler takes over the work. The way scheduler evaluates all required conditions for each job is by collecting all related information upon occurrence of their appropriate events. Schedule of a job is actually triggered by the final occurrence of event showing complied condition when all previously collected conditions are complied.
zJOS/Puspa© is one of automatic workloads schedulers. It's a solution to establish automatic workloads scheduling system on z/OS operating environment. Workloads can be batch jobs, STCs and/or commands. Triggers to schedule can be a single or combination of multiple of any type of event, includes end-of-job (EOJ), end-of-job-step (EOS), commands, messages, dataset access, dataset release or date/time. For multiple triggers, users can freely define boolean type of triggering compliance logic as a list of 1 to 100 ANDs, and each AND can be either individual trigger or unlimited number triggers that's ORed each other. This means, the schedule is only carried out when all trigger entries in the list have complied, where the compliance of each trigger entry is represented by at least one that has complied. For example:
Users can also add an exception condition to execute one of provided actions or their own recovery procedure. Environment can be a single or multiple z/OS hosts. The above example shows system SYS2 and SYS3 are included in the integrated scheduling system. All of its main functions are:
When a scheduled job is executed manually, Puspa knows it and ignores all of its status yielded in either each step or final terminations. Schedule of that job is still ongoing and will be executed normally when all conditions are complied. In the other word, names of scheduled jobs do not restrict naming of non-scheduled jobs. Users are allowed to have and execute jobs with the same job names as scheduled jobs.
One of zJOS/Puspa strong point is its triggering method, pipelined at job-step levels with multiple boolean conditional tests to establish complex schedule flows. See illustration below.
The above figure gives an example of a schedule flow with inter jobs dependencies. JOB0 is an initial job which can be triggered by date/time or messages or commands. JOB1 is only triggered by end of step STEP01 of JOB1 with condition code (CC) 0. This means JOB1 won't be scheduled if STEP01 of JOB0 is not ended with CC 0. When STEP02 of JOB0 is ended with CC 0, JOB3 is triggered. But JOB3 is also depending on JOB1 step STEP12 to end with CC < 8. So JOB3 won't be scheduled until both conditions are complied. JOB2 is only waiting for step STEP11 of JOB1 to end with CC < 4. JOB4 is more interesting. It's depending on JOB1, JOB2 and JOB3. JOB4 won't be scheduled until JOB3 step STEP31 is ended with CC 0 and either one is coming first, step STEP13 of JOB1 is ended with CC < 4 or step STEP21 of JOB2 is ended with CC 0.
Below is more advanced example of pipelined scheduling flow which involves non job status types of triggers instead of just inter-jobs dependencies. In this example 2 messages are involved. It's presented using a series of slides to get better illustration. But you need to repeatedly click your mouse to have the slides rolling. It's actually driven automatically in every 2 seconds if accessed directly from Slideshare site. (thank you very much to Slideshare for providing excellent services).
In networked multiple z/OS hosts, triggering mechanism crosses inter-hosts as smooth as when it works on a single host. All triggering mechanisms are integrally controlled by a host which is running zJOS-XDI server. The other hosts are running zJOS Agent each.
The above figure shows an example of integrated scheduling for 2 z/OS hosts, SYS1 and SYS2. zJOS-XDI is running on SYS1 and SYS2 is integrated to SYS2 using zJOS Agent technology. Once zJOS Agent on SYS2 is logging into zJOS-XDI on SYS1, both hosts appear as a single system to zJOS/Puspa. Jobs or any other events on SYS1 can trigger schedule on SYS2 and vice versa. Schedule of JOB6 on SYS2 must be triggered by JOB3 on SYS1 and JOB2 on SYS2. JOB7 on SYS1 must be triggered by JOB6 on SYS2. zJOS Agent bridges inter-host events traffics to be recognized by zJOS/Puspa.