It’s time to discuss a few more variable prefixes and a technique you can resort to when you’re forced by the circumstances to use indicators, namely when you manipulate display and printer files.

The last installment of this series covered parameter and work variable prefixes, which are arguably the most-used variables in a typical RPG program. However, I recommend taking a few more steps and using separate variables for key fields and constants as well. Keep reading to find out why.

More Naming Variables Guidelines: Key Field Variable and Constant Prefixes

Besides the parameter and work variables mentioned in the previous TechTip, there are others that are equally important and often neglected, leading to hours and hours of wasted time looking for an error. I’m talking about key fields.

This principle might not be clear, so let me show you an example:

/FREE

SETLL MYFIELD MYFILE;

READ MYFILE;

DOW NOT %EOF(MYFILE);

   // The cursor is positioned and the first record was read

   // do something with it...

   READ MYFILE;

ENDDO;

/END-FREE

If MYFIELD is a field from MYFILE, but with a value that I got from somewhere else or composed from other fields, I would lose that value when I read the file. That’s why I prefer to use K_ prefixed variables:

/FREE

SETLL K_MYFIELD MYFILE;

READ MYFILE;

DOW NOT %EOF(MYFILE);

   // The cursor is positioned and the first record was read

   // do something with it...

   READ MYFILE;

ENDDO;

/END-FREE

There’s another group of fields that are sometimes used as part of keys to files, among other things: the constants. They also require a prefix.

Here’s an example of a constant (in this case, it indicates the maximum size of an array):

DCL-C C_MaxArraySize CONST(999);

Constants are not only easier to identify, they also improve performance. Because of their definition, they’re not handled like regular variables. The system acknowledges them for what they are, constants, and doesn’t treat them as plain old variables.

Now let’s discuss that named indicator technique I mentioned previously. Naturally, I’ll start by assigning a prefix to all indicator-related variables.

Sound interesting? To do it, start by defining a pointer over the memory address assigned to the indicators, like this:

// **************************************************************

//   Redefinition of indicators

// **************************************************************

// Definition of Indicator Pointer

DCL-S IndicatorPtr POINTER Inz (%Addr(*In));

Then, build a data structure based on that pointer:

// Specification of Indicators

DCL-DS *N Based(IndicatorPtr);

      INDLST CHAR(99);

END-DS;

After this, you can create groups of indicators for error-handling purposes, like this:

DCL-S ErrIndicators IND Overlay (INDLST: 31) Dim (40);

Alternatively, you can assign individual, human-readable names to each of them:

// **************************************************************

// Description of screen indicators

// **************************************************************

// General indicators

DCL-S I_DspMsgSfl IND Overlay (INDLST: 02);

DCL-S I_Hardcopy IND Overlay (INDLST: 03);

DCL-S I_PageDown IND Overlay (INDLST: 04);

DCL-S I_PageUp IND Overlay (INDLST: 05);

DCL-S I_Help IND Overlay (INDLST: 06);

DCL-S I_Home IND Overlay (INDLST: 07);

DCL-S I_SflDsp IND Overlay (INDLST: 10);

DCL-S I_SflDspCtl IND Overlay (INDLST: 11);

DCL-S I_SflClr IND Overlay (INDLST: 12);

Note that these are all part of the data structure built over the pointer shown before. If you want to assign more meaningful names to the indicators related to the error messages (or if you have to, because you still use message file-based error messages in display files), you can. It would look something like this:

// Error Indicators (I_XXYYYYYYYA)

//                      | |     |)

//                     | |     Letter (For reused MSGs on same scr)

//                     | Message ID

//                      Screen ID

// Indicators screen INVINPC1

DCL-S I_C1DBO0038 IND Overlay (INDLST: 35);

I try to avoid indicators as much as I can and, for most things, that’s possible. With a little creativity and some study, you’ll find that you can use something called “program to display file” fields, or P-Fields, defined in the DDS source, to eliminate the usage of indicators for most of the attributes. The hexadecimal values needed to set them can be found in the SDA Programming Guide under the section for the DSPATR keyword. Unfortunately, as far as I know, P-Fields do not support the MDT, OID, PC, and SP attributes; of this group of attributes, only the Position Cursor (PC) can be eliminated by using the CSRLOC keyword. It’s possible to use a service program that calls the List Field API (QUSLFLD) over the display file and retrieves the row and column for the field in question.

I’m sure some of the readers don’t agree with the prefix scheme described here. Feel free to share your ideas about this topic in an open and constructive discussion in the comments section below or in one of the LinkedIn groups where RPG Academy’s TechTips usually pop up!

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale