From 83 Hours to 25: A QTEMP Case That Looked Like a Hardware Problem

Another case involved a monthly batch job at a large insurance company. Its total runtime exceeded 83 hours. IBM had already analyzed the case and concluded that, given the extremely high number of read operations, the system was performing quite well.

But once detailed open file information was available during execution, the true cause became visible very quickly. All records in a small QTEMP file were being read repeatedly by key inside a main processing loop. That was not a hardware problem. It was an application design problem.

Why the case looked misleading at first

From a distance, the workload seemed to confirm the original conclusion. There were many reads, and the system itself did not appear to be malfunctioning. If you only looked at the total amount of activity, it was easy to assume that the volume of work simply explained the long runtime.

That is what makes cases like this so instructive. The numbers were large, but the explanation was not “the system is slow.” The explanation was that a very specific access pattern was being repeated far too often.

The critical detail was inside QTEMP

The decisive clue came from seeing what files were actually being used while the job was running. Once that information was available, it became clear that the main loop repeatedly performed keyed reads against a small QTEMP file.

That detail changed the whole interpretation of the case. The issue was not the general amount of reading across the job. The issue was where the reads happened, how often they were repeated, and how they were embedded in the application logic.

Without open file data, this kind of inefficiency can remain invisible for a very long time. A job may look busy and expensive without revealing that much of the cost comes from one avoidable design choice.

The result was a dramatic reduction in runtime

By moving the read operation outside the inner processing loop, the runtime was reduced from 83 hours to 25 hours.

That is an extraordinary improvement, but the important lesson is not only the size of the gain. The deeper lesson is that the correction itself was straightforward once the problem had been made visible. The hard part was not inventing a solution. The hard part was getting the right evidence.

Why this matters

This is exactly why detailed job-level data matters so much in performance work. If you only know that a job performs many reads, you may still not know whether the design is reasonable or wasteful. If you can also see which files are being accessed and when, the explanation becomes much more concrete.

That kind of visibility changes the conversation. Instead of debating whether the system is underpowered, whether the workload is simply large, or whether nothing can realistically be improved, you can point directly to the inefficient pattern.

The broader lesson

Many performance problems look larger and more mysterious than they really are. They appear to involve hardware limits, system complexity, or unavoidable workload volume. In reality, they may come from a very small technical choice repeated at large scale.

That is why application performance analysis should not begin only with totals. It should also show where the work happens. In this case, once the right data was available, the inefficiency became visible and the correction was straightforward.

This article is part of GiAPA’s guide: Why IBM i Application Performance Analysis Feels Hard.

If you want the broader context — why IBM i performance problems often seem difficult, what data makes them easier to explain, and how real cases point to practical improvements — the full guide brings the pieces together.