RPG and Programming

Still another example of the human factor being one of the greatest hindrances in solving computer problems - the willingness to see what one expects to see and to make assumptions.

I was writing a report that required me to accumulate data into arrays in the program, which, associated together in a data structure, could then be sorted appropriately with a SORTA statement. Below this, I had defined a separate, somewhat unrelated data structure.

In the array data structure, properly defined by the way, was an account number, followed by a short name. When I printed the report, to my surprise I found the account number slopping over into the short name and practically missing in the account number field

I have WDSC, the PC program that color codes fields and opcodes and creates outlines of the code, including a cross-reference of the fields in the program. The cross references indicated only one spot where the account number and name fields would be updated. The update was airtight, as far as I could see, when I ran the program in debug. But at the point just before the second element of the arrays were to be updated, the first elements of the arrays were already changed!

I then looked a little more carefully at the “watch” facility of the debugger, which allows you to tell the debugger to tell you when the value of a specific field changes. After the first element of the array was filled, I told it to watch for when the first element of the account number changed. I then told the program to continue. Then the cursor stopped- at my input file definition!

“Now, what’s going on?” I said to myself. The file was externally defined, but one field from the file was used in the data structure below the data structure defining the arrays. I looked at that data structure, and everything seemed to be in order. I checked other things, and I came back to that data structure and puzzled over it. And then I saw. The line (with the DS in it) that forms the initial definition of the description had an asterisk in column 7 - for some reason along the way, I had commented the line out and neglected to remove the asterisk when I was done.

With that asterisk in the definition line, its data structure fields that followed became associated with the array data structure above. The field thus overlaid the first 11 bytes of the data structure array, which included the account number and name. The field was read in, and the arrays changed.

Even with the color coding of the editor, I completely missed the asterisk. I had seen what I expected to see - the DS in the appropriate column. I missed the asterisk. Now, one could say that this is an argument for using the // freeform notation for comments and devising a new, freeform, keyword style form for field and data structure definition. But there is more to it.

I would submit that, no matter what precautions we take, the human factor will come into play. At some point, no matter what notation we use, the problem being handled will become sufficiently complex that the human writing the program will start making assumptions so he can handle the volume of concepts and data coming in, and he will see the concepts in his program that he expects to see- even if they are not there.

Sometimes it’s best just to take a break.