I recently started a new consulting position, and the company I am working for now is using 20-year-old RPG code that has been modified over the years by developers with questionable skills. I suspect that I am not alone in having to maintain old and convoluted RPG II code. A long time ago, I worked for a guy who used to say, "Never use indicators...ever!" So I quit using indicators completely, and having to go back to using them again was unthinkable. Now, when I'm working on a display program using indicators to deal with the DDS display file, I get rid of the indicators in the program. Here's how you can do it.

Using the Indicator Data Structure (INDDS) and the File Information Date Structure (INFDS), you can separate the display file indicators from the actual RPG indicators and retrieve the Attention Indicator (AID) code for the AID-generating key pressed by the user. AID-generating keys include all the command keys, the Help key, the Page Up/Page Down keys, the Print key, and the Enter key. With the display file indicators set aside into a data structure, you can give them descriptive names. This will make the RPG code much more understandable to the next chump who has to modify it. The code snippet below is from a file maintenance program I recently re-wrote.

Of course, if you can't convert the RPG II code to ILE, then you’ll need to use the shorter field names when creating your data structure. The file spec defines the data structures to receive the INDDS and the INFDS data. For complete subfield definitions for the INFDS data structure, refer to the WebSphere Development Studio: ILE RPG Reference. The AID code (AidByte in the above code) is a hexadecimal field that corresponds to the key that the user pressed to return the control to the program. A list of the AID-generating keys and their codes can be found at in the 5250 Data Stream Details in the IBM Infocenter. The code for the constants that I use is shown below:

Once you have the code in place to receive the indicators and have your descriptive name defined, you need to do one last thing before writing your new code. You need to add the INDARA keyword to the display file DDS. Once that's done and you've recompiled the display, you can start removing the indicators from the code and replacing them with your new descriptive field names.

Another little trick I use to make my code more understandable is two constants called TRUE and FALSE. They are defined as show below:

Then, whenever I do comparisons or set the value of any of my "named indicators," I use the TRUE and FALSE constants. So the code might look something like this:

For those of you who are thinking that we're still using "indicators" and we've just given them names, you are correct. However, in my humble opinion, you are quibbling over semantics. I could make a case that a Boolean variable in C++ is simply another name for an "indicator," and I'd be right too. But I think we can all agree that the code shown above is more clear about what is actually happening than this code:

Or even this:

Good luck, and don't use indicators...ever!

Jeff Olen is the owner of Olen Business Consulting, Inc., an iSeries development services company based in Orange, California. When he's not busy writing code or writing articles, you can find him jumping out of perfectly good airplanes (a.k.a. skydiving). To find out more about Jeff or Olen Business Consulting, Inc. go to www.olen-inc.com or email Jeff at jmo@olen-inc.com.