October 30, 2018 | IBM i

How Much Programming Does Your IBM i Job Scheduler Take?


For batch job scheduling, many shops use the native IBM i job scheduler that comes with the i operating system. After all, if your job scheduling solution already resides inside the OS then there’s no additional cost in using the native job scheduler to run IBM i jobs. Right?


While using the native IBM i job scheduler is usually thought of as a no-expense solution, there are several other expenses associated with using the IBM i native job scheduler, with the biggest expense being programming costs.


It’s true. Using the native IBM i job scheduler drives up your programming costs versus using third-party job scheduler software. And you can save programming resources by switching to a third-party product.


Programming costs for the native i job schedulers versus third-party schedulers

There are three areas where a third-party i job scheduling product saves programming time and expense versus using the native IBM i job scheduling software.


1. Multi-step scheduling in job scheduler entries
2. Running the same job scheduling entries with different parameters
3. Creating auditing and management reports for auditing and forensic analysis


Let’s compare how each job scheduling area consumes programming resources when using the native IBM i job scheduler and how programming resources are saved in each area by using a third-party job scheduler. For this comparison, we’ll look at each area using a general ledger reporting sequence where the same seven GL reports must be run for fifteen different departments.


Multi-step scheduling in job scheduler entries

The native job scheduler cannot run multiple steps within a single job scheduling entry.  Each job entry can only run one command. If you want to schedule a GL job that produces seven different GL reports for one department, a programmer needs to create a single program that sets up and runs all seven reports in sequence for that entity. Either that or you have to create seven job scheduling entries that each run a single report for the department.


When creating a job entry in a third-party job scheduler that runs the same seven GL reports for a single department, you can set up a scheduling entry that runs as many commands as needed to produce each report. No programmers need to get involved. Your operations personnel can set up the job entry with the desired programming commands. If you need to add an eighth, ninth, or tenth report to that scheduling entry, all the operations staff has to do is add the commands for running the additional reports to the GL job scheduling entry in your third-party software.


Running the same job scheduling entries with different parameters

Now, let’s look at what happens when you want to run those same seven reports for the other fourteen departments you need to run the reports for.


Using the native IBM i job scheduler, the programming staff needs to do one of two things: it either has to clone the original programming and job scheduling entry it created for the first department 14 times over (using the correct parameters for each department); or it has to create fourteen new programs and job scheduling entries, one for each department. And this fifteen-step process gets worse when performing maintenance. If there’s a change in the programs that need to be run, the programmers must make the change in all 15 sets of programs and job scheduling entries that produce the reports.


Most third-party schedulers have the ability to pass parameters into the jobs and programs called from a job entry. To create fifteen different jobs for running reports for fifteen different departments, all you’d need to do is create one job scheduler entry with a parameter specifying what department the reports will be run over. Once you create that first entry with a department parameter, you can then run that same entry fourteen other times with different parameters, to produce the reports for your other departments.


Creating auditing and management reports for auditing and forensic analysis

The native IBM i job scheduler offers almost nothing for reporting on job performance and maintenance, and it does nothing for forensic analysis (what happened with certain jobs). It takes programming skill to extract auditing, compliance, and performance information from jobs using the native IBM i job scheduler. For auditing and performance information about the run history of your GL job stream for all fifteen departments, your programming staff would have to program a system to gather, collate, and produce the necessary information and reports for all fifteen departments.


In contrast, third-party scheduling software collects comprehensive job history information, and it includes pre-written reports on scheduled job performance and maintenance history (job entry creation, modification, deletion, and run history). This information creates an historical record for your scheduler. Pre-written reports provide a forensic audit trail for auditors and other personnel needing to understand the history of a scheduled job. Because third-party schedulers provide pre-written historical reports, organizations can free up programming resources previously used for creating auditing and management reports.


Opportunities lost, opportunities gained

The biggest advantage in moving away from the native i job scheduler to a third-party package is the programming time organizations gain. Using the native job scheduler takes up valuable programming time that can be better used to work on applications that benefit the core business. Your programming staff becomes deeply involved in all aspects of job scheduling, from scheduled job creation to maintenance to reporting to forensic analysis. Your programming resources own your job scheduling solution.


Replacing the native job scheduler with a third-party IBM i job scheduler, your programmers can back away from owning the job scheduling function. Job scheduling stops being a programming exercise. It can be handed off to your operations staff, who can create and modify job scheduling entries. Writing reports no longer require creating and maintaining a job history database and custom-written reports. You operations staff, users, or even auditors can take over report generation using the tools and pre-written reports provided with the software.