Wednesday, July 3, 2024

Constant keyword added to RPG definitions

As part of the latest Technology Refreshes, IBM i 7.5 TR4 and 7.4 TR10, comes an addition to the variable and data structure definitions. It is now possible to use the constant keyword as part of those definitions to protect them from being changed.

Why would I want to do that?

There are times I want to use a variable, rather than a constant. It might be to contain a date. I would not want this to be changed, either on purpose or by accident.

Below is an example:

01  **free
02  dcl-s StartDate date inz(*sys) const ;
03  dsply StartDate ;
04  StartDate = d'2024-07-04' ;

Line 1: I always program in modern, totally free format, RPG.

Line 2: Definition of a date variable, I have called StartDate. I initialized it with the current time at program initialization. The constant keyword, CONST, follows to define it as an unchangeable constant variable.

Line 3: Display the contents of StartDate.

Line 4: Here I (try to) change the value in StartDate.

As the variable is defined as constant and I am trying to change it, the program will not compile. I see the following in my compile listing:

      1 **free
      2 dcl-s StartDate date inz(*sys) const ;
      3 dsply StartDate ;
      4 StartDate = d'2024-07-04' ;
 *RNF5346 30 a      000400  The operation modifies the field, but the field
                            cannot be modified.

I can make a data structure a constant too:

01  **free
02  dcl-ds DefaultSettings qualified const ;
03    Currency char(3) inz('USD') ;
04    DateFormat char(4) inz('*USA') ;
05    TimeFormat char(4) inz('*HMS') ;
06  end-ds ;

07  dcl-ds Settings likeds(DefaultSettings) ;

08  eval-corr Settings = DefaultSettings ;
09  Settings.DateFormat = '*MDY' ;

Lines 2 – 6: This is the definition of a data structure, DafaultSettings, that is a constant. Notice the CONST keyword on line 2.

Lines 3 – 5: I can define subfields and initialize them with various values.

Line 7: I am defining another data structure, Settings, with the LIKEDS keyword to be a copy of DefaultSettings. This means that the two have the same layout, but Settings does not contain the values in DefaultSettings.

Line 8: I use the Eval Corresponding operation code, EVAL-CORR, to copy the values in DefaultSettings to Settings.

Line 9: As Settings was not defined with the constant keyword I can change one of its subfields.

If I place a debug breakpoint after line 9 I can check the values in both data structures.

EVAL DefaultSettings

EVAL Settings

It is not possible to use the constant on data structure subfields. I tried and received a compile error when I did.

      1 **free
      2 dcl-ds DefaultSettings qualified ;
      3   Currency char(3) inz('USD') const ;
 ======>                              aaaaa
 *RNF3701 20 a      000300  Keyword is not allowed for a subfield definition;
                            keyword is ignored.
      4   DateFormat char(4) inz('*USA') ;
      5   TimeFormat char(4) inz('*HMS') ;
      6 end-ds ;

The next thing I thought to try was could I change the value in a constant variable in debug?

This is the program I created to test if I could.

01  **free
02  dcl-s StartDate date inz(*sys) const ;
03  dsply StartDate ;

Line 2: StartDate is defined the same way as it was in the first program.

I placed a debug breakpoint at line 3. And when debug "broke" I tried to change the value in StartDate.

EVAL StartDate = '2023-12-31'

Line 3: When the value of StartDate was displayed the following was shown:

DSPLY  2023-12-31

In other words I was able to change the constant. I am not sure what I think of that. Part of me wanted this to error as a constant is, well, constant. And in my IMHO it should have caused an error. What do you think?


You can learn more about the Constant keyword when defining variables from the IBM website here.


This article was written for IBM i 7.5 TR4 and 7.4 TR10.


  1. First of all thanks for that info, Simon.
    On the first look I cannot find a difference between DCL-S const and the current DCL-C, which is there for decades. Altering a const in debug is, from what I tried, not possible. Besides that you cannot explicitly define a length for the const, it's defined by its content.
    The const on data-structures was long overdue, even though for reasons of completeness only. If it is really needed is questionable. As your example shows, working with a const instance of the original makes no sense at all, since it is empty and immutable. Non-const stuff we already have, so no need to comment further.
    Altogether nothing but another gimmick by the compiler team that didn't cost much and we RPG developers still have to do many things by foot that are long provided by frameworks on other platforms.

  2. Hey Simon, I was confused about this enhancement myself. I agree with you, in that it just doesn't make sense to me. Or maybe you (and I) have discovered a bug in the new enhancement? It sure seems like if you're going to be allowed to add the Const keyword to a variable, then you should get a runtime (or better yet, a compile time) error when you try to assign the variable a new value.

  3. I think it should be valid to change the constant while in debug. The new constant feature is to prevent the RPG program from changing the value.

  4. I agree in debug mode you should be able to change the constant (but not it any other circumstance).

  5. It sounds like the same behavior as a Const on a prototype parm. It's a compile time restriction. You can change the value in debug if you really want to.



To prevent "comment spam" all comments are moderated.
Learn about this website's comments policy here.

Some people have reported that they cannot post a comment using certain computers and browsers. If this is you feel free to use the Contact Form to send me the comment and I will post it for you, please include the title of the post so I know which one to post the comment to.