Tested Schedulers, well documented anyway

OK, you have your own MVS 3.8J system running now, and you want to automate your batch jobs. There are quite a few options available to you and these are the ones I have looked at

ZTIMER

I can't remember where I got this one from, pretty sure it was from the Xephon site but it is not in any of the later archived publications on cbttape.org. I still have the objects installed if anyone wished to request them.
It works by using JES2 timers to schedule itself, on each execution it will create a JES2 timer to run itself again when the next job is due to run. I actually used this for quite a few years without any problems.

• Benefits
  • as it is JES2 timer driven there is no started task permanently running chewing up your virtual mainframes memory
  • it re-reads the control file each time it is kicked off by the timer so changes can be picked up without needing to do anything other than update the parm file
• Drawbacks
  • It can only issue commands or display WTO's, that was never a problem for me as I already had a "S XX,J=YY" procedure setup to submit jobdecks from a job library, but it does involve running another task to submit a job

AUTO - in CBT Tape 249 file 39 (this has not been tested)

I have has mixed results from assembling files under Turnkey3 from CBT249.FILE039. They all assemble cleanly, some abend when run. That doesn't mean this won't assemble cleanly and run, I have just never tried this program as while it looks bells and whistles and is; like ZTIMER above it seems to only have commands issued by timer... it does support multiple JOBDECK files for manual triggering but the timer component seems to be only commands.
As this file is already on a standard turnkey3 distribution so you can review the documentation there to see if it meets your needs.

• Benefits
  • As well as scheduled commands being run it allows operators to use the "F" modify command to run command members or submit jobs on demand.
  • Really good automatic scheduling, commands can be scheduled down to the day of the month
  • Supports multiple jobdeck files for on-demand job submissions, ie: you could have a pre-change file to fall back on if changes go wrong, or seperate jobdecks for admin tasks; the JOBnn DD file to be used can be entered by the operator for on-demand jobs (according to the doco, remember I have not tried this).
• Drawbacks
  • It seems to be able to only issue commands, the examples in the source code show that commands are used to isue modify commands to submit jobs from the job dataset(s).
    So for me personally, I already have a started task proc that can submit jobs from my jobdecks library and don't require a started tsask running to do that same thing from a modify command.

Schedule - From Xephon MVS magazine 1999-02

This is the one I used to use. I had to make a few changes to get it back-ported to run on MVS3.8J as it was using timer functions that just don't exist on MVS3.8J, and I added a few extra auditing WTO's, but it is working to my satisfaction now. My updated version is available in the downloads section, or you can view it here as well.

• Benefits
  • The jobdeck file and command file are seperate functions. Unlike AUTO above if a job is to be run it will just be run from the job file when it is scheduled to run, no intermediate steps needed.
  • Has a job 'catchup' recovery option. If you shutdown the scheduler for a few hours for some reason when it is restarted it will run (if recover option was set for the job/command) actions that were scheduled during that downtime. Recovery/Catchup seems to work OK from the testing I have done
  • As part of my changes it will now WTO every command issued from a command member for auditing purposes (ok, really so I can see where I made a typo)
  • Supports periodic repeating jobs
• Drawbacks
  • Works using weekday names, does not have the flexibility of using MM/DD as AUTO above may do.
  • Wants to store the entire schedule in memory, so in the control file has a max-entry expected parm; repeating jobs require a memory slot per repeat interval so this needs to be managed carefully
  • Unlike AUTO there is no ability to submit jobs or commands on demand; but I already have a seprate proc to submit on demand jobs and use bsppilot (which is on TK3 already) to run batches of commands, so no loss there.

My own scheduler

Progress on my date utility library had reached the stage where the library functions could support a full scheduler, so I wrote a job scheduler as a demonstration of how the utility functions can be used. It is shipped as part of my date utility routine library and this is currently the job scheduler I use now

• Benefits to me
  • it is my code, I would rather bugfix my own code (although I think it is bug free)
  • I can implement additional functions I may need easily
  • for my use, having one PDS containing both jobs and commands makes more sense to me, so that is what I have chosen to use
  • it can both run jobs and issue commands on schedule
  • it has a wide range of scheduling formats, all I need for future dates anyway
• The only drawbacks
  • for users other than myself, this is not stable code, it is being enhanced/modified as my needs change, the documentation is unlikely to be kept up to date
  • holiday calendar functionality is on the todo list, not the done list; may never be done as I do not need it