The AS/400 Operations Evolution
August 26, 2019 Tom Huntington
According to a 2018 ITIC survey, 59 percent of respondents cited human error as the number one cause of unplanned downtime. In that story, the president of an IT operations and cybersecurity company observed that “the root causes of downtime are the same as they were 20 or 30 years ago. But there are more of them.”
That got us thinking. Businesses and technologies have changed over the past few decades, but why haven’t our IT processes kept pace? Why are we still suffering from downtime as the result of human error? Sure, human error can cover all manner of sins, but our business-critical processing should not be part of it.
Let’s take a look at how we were running IT processes 20 or 30 years ago to see how these legacy methods are still leading to downtime today – and what we can do to stop it.
Manual Operations
We are not going back quite as far as floppy diskettes, but we know many of you are still running processes manually. You have documented runbooks or spreadsheets that tell the operator what to do when and then check the item off the list. These runbook activities started as a way to document what the nighttime or off-shift operations team members were doing, so the business could understand what was happening after hours. Unfortunately, this manual documentation process became a way of life in the data center. The difference today is that your processes have grown in number and complexity.
The downtime danger of manual operations is that it’s not scalable. As the demand for technology workers continues to outweigh the supply, organizations that rely heavily on manual processing will fall even further behind – you won’t be able to complete the volume of activity in the desired time period and/or you will begin to make mistakes like missing jobs, running jobs out of order, or failing to recognize the file that arrived as the wrong one. The business suffers downtime while your IT team falls farther behind trying to back out the damages caused by AS/400-era processes that you still run today on IBM i.
Clever Coders And Homegrown CL Programs
Recognizing that manual processes are inefficient at best and unsustainable at worse, some organizations evolved thanks to clever coders. Clever coders are software developers that decided to fix night processing by writing their own scheduling script.
There are two downtime dangers with this way of handling your processes: talent and testing.
The thing with clever coders is that they are here one day and gone the next. Most likely the developer who created your code has either changed positions, left the company, or is soon to be (or may already be) retired. Sure, coding might have saved your company money back then, but today your IT team can’t commit time to code for application dependencies without creating unresponsiveness somewhere else.
They also can’t take the risk of changing that old code. That’s right. What started out as a grand idea of coding in dependencies, parameter passing, and night queue processing has turned into a tangled mess of spaghetti-ware so complex that today’s IT team is scared to change it.
Which leads us to the second danger: testing. How do you test your changes? Do you have to run the entire night processing? How do you re-run only one part of the night processing? If this is what your IT team spends its time on, they probably aren’t being very responsive to the user community for things like adding a new report.
Homegrown scripts were a good idea 20 years ago, but modern-day developers need to work on solving business problems instead of spending time reinventing the wheel by writing utilities.
Rudimentary Tools
IBM’s Work Job Schedule Entry (WRKJOBSCDE)
The next evolutionary step came in 1992 when IBM added WRKJOBSCDE into the IBM i operating system. WRKJOBSCDE is free with the operating system, so why not use it? Well, many organizations do. They say it’s because they don’t really have that many batch processes on IBM i. If this is true, why do they have developers or operators modifying jobs manually – or writing code that can reach out from IBM i to Windows, UNIX, or Linux servers – just to offset the many limitations of WRKJOBSCDE?
WRKJOBSCDE does not allow for dependency processing based on jobs and files, unless you count having your operator force jobs to run after another one finishes or write code to augment the schedule. Instead, it sounds more like these organizations have regressed back to relying on those clever coders, doesn’t it? Eventually the program won’t work, the operator will miss or force the wrong job, or job time limits will run out and staff will need to manually reschedule them. When this happens, your so-called free scheduler will cost you real money in the form of downtime.
The fact that operators spend any time looking for processes to end and then forcing jobs to run doesn’t really make this process all that much better than the old runbook approach.
Enterprise Resource Planning (ERP) Schedulers
IBM i isn’t the only technology that comes with a built-in scheduler. Many business applications – including SAP, JD Edwards, JDA, and others – have built-in schedulers that come with their product. These ERP schedulers have many of the same limitations as WRKJOBSCDE. Additionally, they tend to only take their own schedule into consideration. But the reality is that you have more than just ERP batch processing to worry about.
Most ERP vendors underestimate the complexity of job scheduling. Consequently, features for dependencies, diagramming, forecasting, auditing, cross-platform scheduling, and file monitoring don’t exist. Here again, IT teams start to write their own scripts to get around these limitations, spending time manually building complex visual diagrams and coding scripts to build dynamic parameters for things like dates.
Underdeveloped features aside, the biggest downtime danger we see with these ERP schedulers is they are not reliable. They just stop scheduling suddenly and then your IT team has to restart the scheduler to get it rolling again. In the meantime, what was supposed to run did not, which means you’re in the middle of a business outages or your start of business day is late.
IBM’s Advanced Job Schedule (AJS)
After WRKJOBSCDE, IBM delivered Advance Job Scheduler (AJS) to provide a more robust offering for IBM i users that didn’t invest in Robot Schedule. AJS is the evolutionary superior of WRKJOBSCDE and offers many advanced features, including dependencies and functionality to handle end-of-day, end-of-week, end-of-month, and end-of-quarter processes. Not a bad option for an organization that only runs IBM i and doesn’t have to worry about advance reporting or regulations.
But the world has changed since AJS first came on the scene. For one thing, IBM i isn’t alone in the data center anymore, and it hasn’t been for years. Yet many IBM i professionals aren’t working on solving the scheduling problem across the enterprise. Organizations today need a scheduling solution that can control IT and business processes across IBM i, Windows Server, Unix, and Linux without slowing down processing or introducing downtime while waiting for a file or process to arrive. That’s not AJS.
Similarly, regulations drive many IT spending initiatives today, and AJS just doesn’t cut it for IT audits. Developers end up spending time augmenting the lack of reporting in AJS just to pass these audits. IT teams need tools that work from a browser, audit their every change, and offer jobflow diagrams to help with development projects.
Robot Schedule
If you really want to stop downtime in its tracks, you need sophisticated job scheduling software—no manual errors, no coding accidents, no processing delays. Robot Schedule from HelpSystems is well-known and well-respected in the IBM i community. We’ve even heard stories where administrators won’t take the job unless the company gets Robot Schedule, too.
Robot Schedule runs millions of jobs every day and every night without getting sick, taking a vacation, or making a programming mistake. It is IBM i-centric, which means it can centralize and control cross-platform processes from IBM i and it keep a pulse on the process until it completes, delivering a fully integrated and reliable solution.
It can even launch bots – if you follow the robotic process automation (RPA) craze going on in the Windows world right now. Robot Schedule is the original ‘bot, highly evolved to ship with a modern, browser-based interface, along with a GUI and a traditional interface to meet your IT team’s needs.
Perhaps best of all, Robot Schedule can import IBM scheduling rules from WRKJOBSCDE or Advance Job Scheduler (AJS). It can also capture your submitted processes from menu systems, saving you time when getting started.
It’s time to move away from older IBM tools toward a modern, integrated solution. Robot Schedule is ready to go! Are you? Join our free webinar with COMMON on September 5 and learn how to convert from AJS or WRKJOBSCDE to Robot Schedule with ease.
This content is sponsored by HelpSystems.
Tom Huntington is executive vice president of Technical Solutions at HelpSystems and is author of the annual IBM i Marketplace Survey Results report. He was named an IBM Champion in 2016, 2017, 2018, and 2019 for over three decades of advocation and thought leadership on the IBM i platform.
