Most IBM i shops run at least one batch job that takes longer than it should. The team has learned to work around it, and the overnight window gets padded. Nobody asks too many questions because the system has always worked this way, and the code is old enough that touching it feels risky. IBM i batch optimization is rarely on the roadmap until the issues become impossible to ignore.
Legacy RPG batch routines often carry decades of accumulated logic that has never been audited as a whole. Experienced IBM i programmers can identify and remove redundant processing without touching core application logic. One client recovered 900 hours of annual processing capacity from a single 20-hour engagement, with no new hardware and no migration project.
The Real Cost of a Neglected Batch Routine
When a batch routine runs long, and nobody can explain why, the business pays for it every night. Delayed reporting, constrained processing windows, and workarounds that have calcified into standard practice all carry a real cost.
The client at the center of this story had been running their enterprise software since the mid-1970s. The application grew through maintenance cycles and extensions that each made sense at the time but were never reviewed as a whole. By the time our senior programmers took a look, the day-end batch routine had expanded to 85 pages of RPG code. It took three and a half hours of processing time every single night. The client knew it ran long but did not know why.
Our team approached the problem the way a coach studies game film. Instead of searching for one obvious issue, we looked for patterns, redundancies, and moments when the system did work it didn't need to do. We measured performance in 15-minute increments and identified which routines were necessary. We traced where the code looped through logic that had accumulated over decades without ever being rationalized.
Then the team used augmented intelligence selectively to streamline the routine further. This was not AI applied broadly to a legacy codebase. Experienced programmers used a specific tool at the right moment, guided by 30 years of distribution and manufacturing software knowledge.
20 Hours of Work Produced 900 Hours of Return
Twenty hours of skilled programming work recovered 900 hours of annual processing capacity. There was no new hardware, no migration, and no ERP replacement project.
The routine went from 3.5 hours to 1 hour. That 2.5-hour nightly reduction gives the business approximately 900 additional hours of available processing capacity each year. Data that previously arrived in a daily batch report now reaches division users in real time.
The RPG programming language has been a core component of IBM i environments since the platform's earliest commercial deployments. Many mid-market shops still run on RPG variants written in the 1970s, 1980s, and 1990s. The IBM i operating system's broad compatibility means that old code can run reliably for decades without anyone examining whether it runs efficiently.
That ratio of 20 hours invested to 900 hours returned deserves a moment of attention. The application the client had already built and understood became dramatically faster and more useful without replacing or rebuilding anything.
Like in the earlier coaching analogy, great coaches see what athletes cannot see about their own performance. They recognize which adjustments produce marginal gains that compound into wins. Our senior programmers bring similar pattern recognition to IBM i code. It's not just technical knowledge, but the accumulated judgment that comes from writing and maintaining distribution and manufacturing software across decades.
The same principle applies to IBM i managed services more broadly, where consistent expert attention surfaces problems that in-house teams stop seeing.
The Expertise Behind Smarter Code Optimization
The senior programming team at Source Data carries a specialization that is genuinely rare in today's market. Our fluency extends not only to current RPG but to the older RPG variants written in the 1970s, 1980s, and early 1990s. Most of the IBM i installed base still runs on those variants, and newer technologists have no training to diagnose them.
That depth is what makes the diagnosis possible in the first place. Without it, the 85 pages of code in this client's routine would have remained opaque, and the routine would still be running at 3.5 hours.
We touched on related issues in our post about the legacy programmer trap in IBM i. It covers how so much institutional knowledge can rest with one person, and what may happen if that person becomes unavailable. The batch optimization problem is one of its most concrete and quantifiable expressions.
Bob Losey has spent more than four decades diagnosing IBM i performance problems that other teams had given up on. His perspective on this engagement reflects both the technical and organizational dynamics at play.
"They looked at the software and said, 'This day-end routine is 85 pages of RPG programming. This makes no sense.' They figured out how to determine what was happening in 15-minute increments, and then they figured out where they could cut out unneeded routines and see patterns. And then, as senior software developers, they made specific and intelligent use of augmented intelligence to streamline the day-end routine. They were able to reduce this legacy software day-end routine from three and a half hours a day to one hour. That 2.5-hour reduction is a gain of 900 extra hours a year of data processing that this company didn't have." – Bob Losey, Founder and President, Source Data Products
The Performance Gains Hiding in Your Existing Applications
The batch routine story is not an isolated result. A recent client was able to shift from daily batch reporting to real-time data visibility for division users. That shift changed operations in ways that contributed to a subsequent growth period. The underlying application didn't change, but team members were able to use it more effectively.
That kind of return does not require replacing what you have. You just need the right people looking at what you already built.
If your IBM i environment has batch routines that run long, the gap between current performance and what is possible may be significant. You may also find similar performance gaps in legacy RPG applications that haven't been examined in years. You just need the right programmers with enough depth in legacy RPG to read it accurately, diagnose it honestly, and know what can safely change.
The IBM i DR Test Failure article makes a related point about what happens when expert review surfaces problems that routine operations have masked. Batch performance issues follow the same pattern: they are invisible until someone qualified looks directly at them.
The Cost of Treating Batch Delays as Inevitable
Most IT teams treat long-running batch windows as a fixed constraint rather than a solvable problem. That assumption has real costs that add up over time. Nine hundred hours of processing capacity lost per year is not a rounding error. It is equivalent to roughly 22 additional 40-hour workweeks of compute time the business doesn't have access to.
The other common mistake is treating batch optimization as a risky proposition because the code is old. The risk is real if the wrong team does the work. It is manageable, and the outcomes are measurable, when experienced IBM i programmers make targeted changes.
Our article on IBM i AS400 skills collapse touches on similar issues. It covers how black box thinking develops in environments where the original programmers are gone.
Common Questions About IBM i Batch Optimization
How do I know if my IBM i batch routine is a candidate for optimization?
If your overnight batch window has grown over time and nobody can explain exactly why it takes so long, it is worth an assessment. Routines that have been extended across multiple decades without structural review often carry redundant logic that adds processing time without contributing useful output. A diagnostic review with an experienced IBM i programmer is usually the most efficient starting point.
Does optimizing legacy RPG code require rewriting the application?
No. The most effective IBM i batch optimization work is targeted and selective. Experienced programmers identify specific routines that are redundant or inefficient and address those without altering the core application logic.
Is it safe to modify RPG code that has been running for decades?
Safety depends entirely on the depth of expertise applied to the work. Programmers who are fluent in legacy RPG variants from the 1970s, 1980s, and 1990s can read and understand the code accurately before making changes. The risk increases when you entrust the work to technologists who lack that specific fluency.
What role does artificial intelligence play in IBM i batch optimization?
It is a tool, not a substitute for expertise. In the engagement described here, experienced programmers used augmented intelligence at a specific point in the process after they had already diagnosed the problem. The tool accelerated a task that human judgment had already defined and scoped. Without that foundation, AI applied to legacy RPG produces unpredictable results.
Can batch optimization improve real-time data availability for business users?
Yes. When batch processing runs more efficiently, data can be retrieved and processed faster. Instead of waiting for an overnight completion window, it could potentially be made available to users in real time or near real time. That shift in availability frequently has downstream business impact well beyond the IT department.
What should I expect from a first conversation about IBM i batch performance?
A qualified IBM i programming team will want to understand the age of the application and which RPG variants are in use. They also want to know the current batch window duration and whether any performance measurement has been done. They will not need to commit to a solution before reviewing the code. The diagnostic phase is where the real picture emerges, and where experienced teams earn credibility.
Does batch optimization require new hardware or a migration project?
No. The optimization work can produce measurable results on existing infrastructure without hardware changes, new software licenses, or a migration project. The return comes from improving how the existing codebase performs.
Your Batch Window Probably Has Room to Breathe
If your overnight window has grown year over year and the team has simply adapted around it, that adaptation has a cost. It shows up in delayed reporting and constrained processing capacity.
Source Data's senior programming team has the RPG depth to assess what is actually happening inside long-running batch routines. Reach out to our team to start the conversation about what your batch environment is actually capable of.
