Goofy Named Constants

Using named constants can be problematic. Name collision is a medium to large problem when it comes to named constants. Take the CONVERT subprocedure example, the named constants UPPER and LOWER are pretty common. The odds of name collision with these names and those used in your own programs are pretty likely. So how do you avoid this type of collision?

Qualified Named Constants?

Unfortunately, we don't have the Qualified Named Constants feature in RPG IV. We do, however, have Qualified Data Structures. And if we're willing to compromise slightly, we can sort of simulate Qualified Named Constants.

For example, if you normally use named constants to identify colors used in web applications, you might have a line of code that looks like this:

     D  blue           C                   Const(X'0000FF')
     D  myColor        S             10I 0 
      /free
           myColor = blue;
      /end-free

Assuming you define BLUE as a named constant and /COPY it into programs that use it, you end up reserving the field named BLUE in those applications. The reserved field BLUE can cause name collision. If you use a Qualified Data Structure and named subfields, you can avoid this issue. Here's a simple example:

     D color           DS                  Qualified
     D  red                          10I 0 Inz(X'FF0000')
     D  green                        10I 0 Inz(X'00FF00')
     D  blue                         10I 0 Inz(X'0000FF')
     D  black                        10I 0 Inz(0)
     D  white                        10I 0 Inz(X'FFFFFF')

Now when you need to specify the color BLUE, you could code something like this:

     D  myColor        S             10I 0 
      /free
           myColor = color.blue;
      /end-free

This frees up the field named BLUE (as well as RED, GREEN, BLACK, and WHITE). In the /COPY member, instead of defining several named constants as RED, ORANGE, YELLOW, GREEN, BLUE, PURPLE and so on, you would define a Qualified Data Structure with a name you enjoy, and then name its subfields accordingly--making sure to initialize them to the value you want them to represent.

In my RPG xTools, there is a CGILIB service program that is included free with the package. It includes several web-based application development subprocedures for use by RPG IV. This allows RPG IV applications to be used as web applications. The basic idea of this type of CGI service program is to load up some HTML from the IFS and then insert customization and data into the HTML and send it to the web browser. Sort of like an "Externally Described HTML" model. There are a couple other products out there that contain similar functions.

So when an RPG web application is being created with xTools CGILIB, the user may want to set, for example, the style of a word to a specific color. By utilizing a Qualified Data Structure with subfields that contain named constant-like values, well let's just call this Qualified Named Constants, I can easily let my users /COPY in the CGI source member, including the COLORS data structure, and not worry about their own code containing fields that are similar to my own named constants. In fact, I tend to name my production code in the /COPY members with a "_T" suffix when the Data Structure is a template, so why not do something like that for Qualified Named Constants? How about suffixing it with "_C"?

     D color_C         DS                  Qualified
     D  red                          10I 0 Inz(X'FF0000')
     D  green                        10I 0 Inz(X'00FF00')
     D  blue                         10I 0 Inz(X'0000FF')
     D  black                        10I 0 Inz(0)
     D  white                        10I 0 Inz(X'FFFFFF')

The likelihood of anyone using COLOR_T in their own production code, while not zero, is very unlikely. Why? Because RPG programmers did not have the underscore symbol available for use in field names when their legacy code was written, hence it's unlikely that a name collision will occur. That doesn't mean it won't, just that it's less likely.

One thing I would consider is using just the underscore instead of "_C", as follows:

     D color_          DS                  Qualified
     D  red                          10I 0 Inz(X'FF0000')
     D  green                        10I 0 Inz(X'00FF00')
     D  blue                         10I 0 Inz(X'0000F')
     D  black                        10I 0 Inz(0)
     D  white                        10I 0 Inz(X'FFFFFF')

This is even more unlikely to have been used previously. In addition, look at how the code to access those subfields would appear:

     D  myColor        S             10I 0 
      /free
           myColor = color_.blue;
      /end-free

The color_.blue; variable is certainly distinct, although as I look at it, it's just slightly more palatable than using an "at sign" or "pound sign" in the variable name (We all know I hate that!).

So consider using some distinct Qualified Data Structure to store often used named constants as subfields with initial values. Granted, you can't really make a field "read only" (I wish we could) but you can help avoid name collision, and that's a good thing.

Bob Cozzi lectures on RPG IV and System i development to corporate customers and user groups all year long. He is author of RPG TnT: 101 Dynamic Tips 'n Techniques with RPG IV and hosts iWeekly, a weekly video podcast for RPG developers and Managers aired live on RPGWorld.com at noon Eastern time every Friday (16:00 GMT). Bob also produces RPG World, the most popular RPG IV Developer conference of the year. The next RPG World conference is planned for May 2009 in Las Vegas. Start planning now for your 2009 trip to RPG World and join Bob Cozzi, Bruce Hoffman, Greg Veal, Aaron Bartell, and more for the best RPG and System i developer training you can find. Details are posted at RPGWorld.com.