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!