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):
|
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
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
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