Advanced Job Scheduler
One of IBM's Best Kept Secrets
Author: Jeff Waldbillig
For years, the IBM Advanced Job Scheduler (AJS) has been biding its time one of IBM's best kept secrets. It will soon be obvious why this clandestine tool is no longer a secret. With V5R3, AJS has burst forth with new innovations designed to take it out of the shadows and into the light!
Several job schedulers on the market these days allow a certain level of flexibility in terms of deciding when and how often a job can be managed or run. Even the base OS/400 scheduler gives you some of that functionality. AJS gives you several orders of magnitude beyond that, and it's cleanly integrated with iSeries Navigator. For versatility, customers can use traditional green-screen commands, a sophisticated graphical user interface, or even their own cell phone to manage their scheduled jobs.
Let's examine a few of the scheduling options available with V5R3 of AJS. When you define a new job, the AJS scheduling tab gives you the option to select individual dates to run the job. You can also define particular days of the week, the first or last days of the month, every other Tuesday, even every seven weeks if that's what's required. You can specify the time of day to start the job, or you can have the job run at intervals, such as every three hours. You can even have your job run every eight minutes between 9:18 am and 11:42 pm if that's what you need in your environment. That level of flexibility is likely beyond your everyday needs, but that's why this is the advanced job scheduler! You can schedule your jobs to run precisely when and how often you want them to.
But what if your job must not run until some other job completes successfully? When you define your job, you can specify any jobs that must complete before your job can start. You can even indicate if the dependent job must complete normally before your job can begin (as opposed to a dependent job running to an abnormal completion). The concept of dependencies is not limited to jobs only. You can define other dependencies, as well. For example, you could require a particular status on a hardware device before your job runs. Or you could require that a file exists on your iSeries before your job runs. You also have the ability to specify a job to run if your job ends abnormally, so you can clean up any mess, and sound the appropriate alarms. With all of these attributes, you can see the power you have to control when and if your job runs.
But what if your scheduled job fails to run? For example, if you have a biweekly payroll job that fails to start at 10:00 pm, you need to know about it right away. With V5R3 of AJS, you can easily insulate yourself from such a critical situation. With the notification function that is integrated into AJS, you can explicitly identify who is notified when a job ends normally, abnormally, or if it fails to start. You have the power to send notification to a particular user, or to whomever is on-call at the time the notification is sent out. For critical job notifications, you can even define escalation lists, so that if a notification is not being addressed as quickly as you need, the next person on the list is contacted.
Perhaps the functions already described sounds useful to you. But what if you make AJS a significant player in your systems operations? What if you come to depend on that scheduling function being there, and performing its chores on your mission-critical system, and then that system goes down? Sure you can fire up your backup system, but what about all those critical jobs that AJS is supposed to be starting and monitoring? AJS can mesh easily in an environment where system availability is important.
When AJS jobs are scheduled, information about those jobs is saved into an OS/400 library (by default, QUSRIJS). A library where ASJ scheduling information is saved is considered an AJS scheduling environment. You can copy that library (that scheduling environment) to your backup machine, where doesn't do anything unless you indicate to AJS that you need to begin using that particular environment. In an emergency, you can have AJS on the backup machine begin monitoring for scheduled jobs from that backed up scheduling environment.
This approach to scheduling availability is novel because you can have any number of scheduling environments either waiting or active on a system. Perhaps you would have an active production scheduling environment that everyone uses, an active test scheduling environment that a select few use to develop future schedules, and then a few backup scheduling environments that would only be activated during an emergency. As you can see, AJS is a job scheduler your company can depend on.
These features are pretty cool, but with V5R3, AJS really becomes advanced. Could you ever imagine a time when you'd need to manage your AJS-scheduled jobs wirelessly? Perhaps you've finally set things up for that day of vacation, but while you're at the lake with a line in the water, you get a call from work that one of your scheduled jobs needs attention. Instead of turning the boat around and heading back in to work, you take out your cell phone, and quickly diagnose the problem.
With V5R3, this seemingly far-fetched scenario becomes a reality. AJS for Wireless is included with V5R3 of the Advanced Job Scheduler. With a wireless PDA, or Internet-capable cell phone, you can start and stop your scheduled jobs, examine job logs, view the history for a scheduled job, look at Management Central scheduled jobs, and even send a quick e-mail using AJS.
The power and flexibility described here is what AJS is able to deliver today with V5R3. If you'd like more information about IBM's Advanced Job Scheduler, you can check out the AJS web site at:
You can also see why this unknown little tool won't be a secret anymore.
Jeff Waldbillig is a staff software engineer at IBM in Rochester, Minnesota. He has held positions as a technical writer, host programmer, and is currently writing GUI software for iSeries Navigator. He can be reached at email@example.com.