Since RPG IV was first released and particularly since the release of free-format RPG IV, standardization has become a popular issue. However, standardizing indicator usage with external files has not been a heavily covered topic. Start with Standards As with any attempt to standardize, name selection is important. In the past, I used the indicator range *IN70 through *IN79 for CHAINs. This is not necessary with RPG IV. I now leave these available for TEST operations and other opcodes. The code in Figure 1 shows one way to represent indicators and demonstrates how they are passed to external files (in this case, a subfile and a printer file):
0015.00 Fmyfile if e k disk UsrOpn 0016.00 Fprtfile o e Printer IndDs(Indicators) OflInd(*in99) 0017.00 Fsubfile cf e WorkStn IndDs(Indicators) 0018.00 F sfile(Sfl1:Sfl1Rrn) 0019.00 F sfile(Sfl2:Sfl2Rrn) ... ... ... ... ... ... 0036.00 * Define the indicator data structure 0037.00 D Indicators ds 0038.00 D Exit 3 3N 0039.00 D Prompt 4 4N 0040.00 D SubmitJob 6 6N 0041.00 D ToggleFold 10 10N 0042.00 D Cancel 12 12N 0043.00 D ClearSfl1 31 31N 0044.00 D DisplaySfl1 32 32N 0045.00 D ClearSfl2 41 41N 0046.00 D DisplaySfl2 42 42N 0047.00 D AvoidF10 88 88N inz(*off) 0048.00 D MoreRecords 90 90N 0049.00 D Overflow 99 99N |
|
Figure 1: This example shows how to use the indicator data structure INDICATORS.
The data structure, called Indicators, renames *IN03 to the variable Exit, indicative of the exit or F3 key. When standardizing indicators, it is natural to reserve *IN01 through *IN24 for CUA-compliant function keys F1 through F24.
Other indicators are used for functions such as clear subfile and overflow. When choosing names, choose wisely.
The Indicators data structure is passed to external display and printer files via the Indicator Data Structure (INDDS) keyword. The keyword INDARA needs to be coded in the source code for these files to allow the data structure to be "communicated" to the external files.
Note that "INDDS(Indicators)" can be passed to multiple files. Hence, the one data structure can be used in many files. And if standard indicators are used within the program itself, they can be defined in indicators as well! Defining indicators this way removes the need for comment sections explaining indicator usage. Caveats When standardizing the indicator data structure, it is important to remember that any variation from the norm requires that you create a new indicator data structure. Notice that the Indicators structure in Figure 1 uses two sets of indicators for SFLCLR and SFLDSP operations because there are two subfiles. In that case, a standard SFLCLR would not work. Trying to standardize multiple clears by creating a named range such as SFLCLR1, SFLCLR2, etc. is not recommended. Such a method removes the ability to easily associate a field name with a particular subfile. It would be better to copy the copy member directly into the code and modify as necessary.
Another item worth noting is that passing the Indicators data structure to a printer file does not seem to work with printer overflow indicators. It would be nice if the named indicator could be used on the OFLIND parameter for the printer file on the F-spec. Unfortunately, it does not work that way now. Perhaps it will in a future release. Until then, you need to set the numbered indicator by program logic. Still, you will note that I name the indicator in the Indicators data structure. I do this for clarity and for reference. My intent is that the Indicators data structure is the "one-stop shop" for indicator representation unless other oddities occur in the code. Maybe someday we'll be able to use the named indicator in the OFLIND parameter, and when that happens, the only changes to this code will be replacing every *IN99 reference with the name of the indicator.
The final consideration when generalizing the Indicators data structure is whether it will be used as a /COPY member or not. On the one hand, a /COPY member could be the most optimal use of a standardized structure in much the same way prototype /COPY members are. On the other hand, if multiple subfiles are the norm in your IT shop or if you commonly use multiple printer files, give some thought to whether such common situations can be incorporated into the standard indicator data structure. It may be deemed that a new data structure definition is required within the program. Or multiple indicator data structures could be used. There is nothing preventing either of these situations from occurring. The Bottom Line Ultimately, the advantage of an indicator data structure is that you can create one home for all indicators in most situations. The INDDS can be a very useful tool in coding RPG IV programs if you keep it simple, handy, useful, and efficient. Take the time to think through the standards and the methods intended for implementation, and RPG IV programs may become a little easier to maneuver and understand.
Vincent B. Goldsby has been an IBM midrange systems professional since 1987. Presently, he is a senior programmer analyst in Memphis, Tennessee. Vincent can be reached for comments and questions at Vincent_Goldsby@msn.com.
|
[size="1">Code[/size>