I’m developing an RPG program on IBM i. When there is a problem with an input, a message explains what is wrong. In this particular development setup, though, I needed an extra step to see those messages during my own tests.
The RPG program writes the error information to a work file. aXes, on the browser side, handles showing it to the user. Processing the input and presenting the message are separate responsibilities.
For my checks, I run the RPG program through a 5250 text screen. With the way I’m testing it, that job alone doesn’t put the written messages on my screen for inspection. I was building the error-handling logic, but I still needed a way to see what it produced.
So I made a small test application that displays the work file’s contents in real time from another job. I operate the RPG program in one job and watch the messages in the other. That is how I’m checking its behavior.
Writing another program to test a program: a slightly complicated approach for someone who dislikes extra chores. But with a tool that shows what I need to see, I can check things as I go.
I’m building a screen for the user. First, I need to make the behavior visible to the person building it. That was the purpose of this extra application. Preparing to produce an error message is one thing; preparing to see it takes a little work too.