"As IBM continues to enhance RPG to allow reducing the use of indicators, we as RPG developers should also be looking for ways to decrease our use of indicators."
So began a TechTip I wrote about attribute fields in October 2004. This is a sentiment espoused by many an RPG guru.
Attribute fields are one way to eliminate indicators, but are there any other ways? There are screen functions that require indicator usage, but can we at least reduce their usage? We can by doing what I like to think of as overloading indicator functionality.
Now, follow this scenario (I've seen this coded, and I have always questioned it): You are coding a subfile. To do so, you need a SFLDSPCTL keyword, with an indicator, of course, to display the subfile control record. You also need SFLCLR (or SFLINZ) to clear the subfile. So you put indicator 92 on SFLDSPCTL and indicator 93 on SFLCLR.
In the program, in order to clear the subfile, you need to set 92 off and 93 on. You write the control record to clear. After loading the subfile, you need to display the control record. You set 92 on and 93 off. That's two indicators to keep track of.
Two of a control record's functions are displaying itself and clearing the subfile. These are mutually exclusive functions. So why use two indicators? This is a case where one indicator can serve both functions: It can be overloaded. Indicator 92 can be used to display the subfile, and N92 can be used to clear it.
So now, in order to clear the subfile, you set 92 off. To display the control record, you set 92 on. That's only one indicator to keep track of.
So, you can overload an indicator on mutually exclusive functions; the indicator is on for one function and off for the other.
Another use for overloading indicators is on related functions. For example, consider the SFLDSP keyword on your expanding subfile. This keyword displays the subfile, of course. You turn it on only if there are records in the subfile to display. If there are no records to display, why bother turning on PAGEDOWN? You can use the same indicator, with the same setting, to condition SFLDSP and PAGEDOWN.
Not only that, PAGEDOWN is mutually exclusive to SFLEND (why allow PAGEDOWN when the last page of the subfile is displayed?), so you can also condition PAGEDOWN with the opposite setting of SFLEND.
Here is my standard, basic coding for expanding subfiles:
A N91 ERASE(SCRN1F)
A 92 SFLDSPCTL
A N92 SFLCLR
A 93 SFLEND(*MORE)
A N93 91 PAGEDOWN
Only three indicators are in use. Indicator 91 is used this way: If there are records in the subfile to display, then PAGEDOWN is active; otherwise, the area of the screen occupied by the subfile is cleared, and PAGEDOWN is inactive. Indicator 92: Either display the control record or clear the subfile. Indicator 93: If the last page of the subfile is displayed, show "Bottom" and deactivate PAGEDOWN; otherwise, show "More..." and turn on PAGEDOWN.
There are other times to overload indicators too. For example, if you are restricting certain functions of a program to certain users, you can use one indicator to protect screen fields, deactivate function keys, and hide the text for those function keys for unauthorized users. Those are related security functions. Likewise, you can use the opposite setting of that indicator to open the fields, activate the function keys, and display the text for authorized users.
In our quest to rid ourselves of indicators, we can use overloading to reduce the number of required screen indicators. We do this by using the same indicator for related functions and using opposite settings of one indicator for mutually exclusive functions. The fewer indicators we have, the better off the program can be.
Doug Eckersley is the chief iSeries developer at Dominion Homes in Dublin, Ohio. Doug has over 16 years of application development experience and is the co-author of Brainbench’s RPG/IV certification test. He wishes all readers a Happy New Year: Don’t get overloaded, and drive carefully.
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online