Read every record, then read master data dozens of times for each one. Even under that workload, the AS/400 completed the job in about thirty minutes. Because the platform was fast and dependable, poor data access was hidden behind the assumption that “this is just how long it takes.”
01 / DISCOVERY
The first warning about those thirty minutes came from a casual conversation.
The program was a “condition addition” function. It applied complex business rules to roughly 400 million records and created new records whenever the conditions were met. The field team submitted a request through the head of laboratory operations, and I assigned the implementation to a member of my team.
The process took about thirty minutes. People in the workplace kept running it, assuming that such a complicated operation naturally took that long.
The issue did not surface through a formal incident report. It came up while I was chatting with Ichisaka, the leader of the specimen-receiving team. “This feels unusually slow for an application you built,” he said. That small sense of unease exposed the problem.
02 / RESPONSIBILITY
The responsibility was mine.
This was not simply the fault of the developer who implemented it. My code review was insufficient, and I had not verified the result all the way through to processing time. I had delegated the work, so the responsibility was mine.
We already had a process: development verified that the request had been implemented correctly, the release was made, and the field team checked it against production data. But processing time was not an explicit acceptance item, so “the function produces the correct result” was enough to pass.
Afterward, we added processing time to the field acceptance criteria. The important result was not only making the job faster. It was returning to the process, understanding why the delay had been accepted, and preventing the same oversight from happening again.
03 / TOO FORGIVING
The AS/400 was too forgiving.
The original program read roughly 400 million records sequentially and accessed master files dozens of times while judging each one. If we assume thirty lookups per record, that is 400 million × 30—or about 12 billion logical lookups. The “12 billion” in the title is an estimate meant to show the scale, not a measured audit count.
Frequently used master pages and indexes were probably already in memory buffers managed by Db2 for i, so not every lookup required physical disk I/O. Even so, completing that workload in thirty minutes is remarkable.
The AS/400 was not slow. The railway was built for a bullet train, but the data-access design was riding a bicycle on the tracks. And the AS/400 patiently carried that bicycle to the destination anyway. High stability and performance can sometimes conceal an unreasonable design.
04 / REPAIR
Keep the business logic. Repair the route to the data.
There was no need to throw away the complex business rules. The solution was to redesign the access path so the program could reach the necessary data in the necessary order.
After the redesign, a process that had taken about thirty minutes finished in twenty to thirty seconds. We did not introduce magical new technology. We simply let IBM i and Db2 for i work the way they were designed to work.
Read every record and repeatedly accessed master data for each decision.
Preserved the business logic and redesigned data access.
05 / FOR PEOPLE
A system exists for the people who use it.
Ichisaka had also helped with the speech-recognition specimen-verification system. He spoke frankly from the operator’s point of view: “It would be better if this worked this way,” or “I wish we had this feature.” Sometimes I released an improvement thirty minutes after hearing the request; on one occasion, we revised the application three times in a single day. I also quietly added a Kansai-dialect option to the menu, and the people who found it used it and laughed.
When people see that speaking up produces a real change, they feel free to say more. That relationship is why the comment “this is strangely slow” surfaced in an ordinary conversation. Trust uncovered a problem that technology alone had missed.
I do not love the AS/400 merely because it is old or familiar. I love it because I have repeatedly experienced its ability to turn the voice of the workplace into working software quickly—and to help people do their jobs with a smile.
The AS/400 was not slow.
It was almost too forgiving.