This thread discusses the Content article: TechTip: Move Your Compile-Time Arrays to the D-Specs

Joe, you _can_ code the length constant using an expression, %DIV(%SIZE(dsMSG):%SIZE(MSG001)). But you can't use that constant in the DIM keyword of the array that is part of dsMSG because the size of the data structure depends on the dimension of the array.

You can get what you want if you separate the array from the data structure and make it based on a pointer to the data structure.

Code:

D dsMsg ds D msg1 30 inz('one') D 30 inz('two') D 30 inz('three') D 30 inz('four') D msg s 30 dim(nMsg) based(pDsMsg) D pDsMsg s * inz(%addr(dsMsg)) D nMsg c %div(%size(dsMsg):%size(msg1))

Barbara, I tried a number of different methods to get this, but kept running into the issue of the array being inside the data structure. I never thought to remove it; thank you very much for the key. I will absolutely be using this in the future.

Joe

Joe wrote: "and you can't change the order of D-spec definitions for arrays without also changing the order of the data in the compile-time array specifications at the end of the program."

Haven't you used the **CTDATA ARRNAME syntax for compile-time data? It's been in RPG IV ever since about V3R1.

Perhaps it's just personal taste, but I find initializing an array using CTDATA more readable than going through the hoops and handstands you describe. Barbara's suggestion, while technically correct, just seems even goofier, IMO.

Cheers, and Happy Holidays!
Hans

Joe: On further reflection, another issue with your suggestion comes into view. While there may or may not be a maintenance issue with the original code (that can be corrected by using the **CTDATA ARRNAME syntax), your new code definitely has problems. Consider the maintenance nightmare of having to change the length of an array element. You've got the length hardcoded in each line now! While you could define each element initializer using LIKE, the size of your array initialization is now even more voluminous than before. You've taken some nice compact array initialization code and converted it into something huge and ungainly. Is that really an improvement?

Cheers! Hans

RPG doesn't have great support for initializing arrays; I'm not sure which I dislike more between **CTDATA ARRAYNAME or the data structure approach. **CTDATA is a bit easier to maintain, but keeping the DIM value the same as the number of **CTDATA initializations is annoying.

Another approach to this problem is to handle the initialization with ordinary assignments. I think this would be easiest by far to maintain.

Code:

D msgs s 100a varying dim(100) D nMsgs s 10i 0 inz(-1) begsr inzMsgs; msgs(1) = 'One'; msgs(2) = 'Two'; msgs(3) = 'Three'; msgs(4) = 'Four'; nMsgs = 4; endsr;

RPG doesn't have great support for initializing arrays; I'm not sure which I dislike more between **CTDATA ARRAYNAME or the data structure approach. **CTDATA is a bit easier to maintain, but keeping the DIM value the same as the number of **CTDATA initializations is annoying.

Another approach to this problem is to handle the initialization with ordinary assignments. I think this would be easiest by far to maintain.

Code:

D msgs s 100a varying dim(100) D nMsgs s 10i 0 inz(-1) begsr inzMsgs; msgs(1) = 'One'; msgs(2) = 'Two'; msgs(3) = 'Three'; msgs(4) = 'Four'; nMsgs = 4; endsr;

I never got around to learning the ** CTDATA ARRNAME syntax because, thankfully, I don't have a lot of places where I use compile time data at all. I use initialization routine as Barbara suggests, and frankly I prefer to load my tables from a database. Thanks for the update on the syntax, but it still doesn't remove the problem of having the definition of the array in two places, where a change at one end of the program requires a change at the other end. When I had to use compile-time arrays, this is something that I often forgot to do, so I wanted to give a new technique.

I agree that the hardcoded size is not pretty, but I really didn't have space to go into the LIKE define which is a better technique. LIKE has a ton of great uses and I hope to point that out in other tips.

But as to whether CTDATA is better or not, that's just an opinion and everyone's got one. Personally, I hate the idea of legacy keywords like CTDATA and PERRCD that you have to learn for one specific task, but that's just me. In this tip, I made no moral or even esthetic judgment, I simply presented another option and it's up to the individual programmer to decide which way they prefer.

In the end, neither your opinion nor mine really matters, does it? And that's as it should be.

Joe

Barbara: So how about improving the support for initializing arrays in RPG? It can't be too difficult to implement something like:

Code:

INZ('first': 'second': 'third')

Heck, to fix the other maintenance issue, take it one step further:

Code:

DIM(*INZ) INZ('first': 'second': 'third')

Cheers! Hans

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." George Bernard Shaw