When a puzzling error appeared, memory was not enough. I logged each 5250 screen image so the exact sequence could be replayed later.

01 / THE SCREEN ITSELF BECAME THE LOG

The screen itself became the log

Instead of recording only a few selected events, the program wrote the DDS screen-record contents to a log file in essentially the same image used on the 5250 display.

To investigate later, the log viewer simply rendered those records back onto a 5250 screen. It felt much like testing a display file in SDA mode 3—except the sequence was real work that had already happened.

02 / MICROSECONDS MATTERED

Microseconds mattered

Some experienced operators could scan three specimen QR codes within 0.3 seconds. A timestamp precise only to the second—or even the millisecond in the wrong place—could make the event order ambiguous.

The log therefore recorded time down to the microsecond. When the sequence was replayed, the chronology could not quietly swap two rapid scans.

03 / THE LOG WAS EVIDENCE, NOT A WEAPON

The log was evidence, not a weapon

The purpose was not to prove that an operator had made a mistake. It was to establish what the screen showed, what was scanned, and how the application responded, so the system and the operation could be improved.

A person may not remember. The replay does.

Traceability without guesswork
WRITTEN BYYoshio Taki

A systems engineer who loves IBM i / AS/400

CHAPTER 02 · EPISODE 7 / 9 + EXTRA

Chapter 2 index: 9 stories + extra