| TechTip: Move Your Compile-Time Arrays to the D-Specs |
 |
 |
 |
| Tips & Techniques - RPG | ||||||||||||||||||||||||
| Written by Joe Pluta | ||||||||||||||||||||||||
| Tuesday, 18 December 2007 18:00 | ||||||||||||||||||||||||
|
A couple of odd little keywords allow you to use the old-fashioned compile time array, but this tip will show you a different take on it. Ah, another TechTip! Quick update: My last TechTip on getting PTFs on CD worked just fine. I'll follow up shortly with a TechTip on installing those PTFs from an image catalog. And now back to your regularly scheduled tip. In this tip, I'm going to show you some clever D-spec tricks that will allow you to remove one of those remnants of old-fashioned RPG programming. A D-spec, or definition specification, is the specification we use to define variables in our modern RPG programs. Prior to this, variables were either found in input/output specifications or defined as work fields right in the C-specs (calculation specifications). One particularly annoying issue was the specification of text strings, such as program messages. Even though i5/OS message files provide an excellent mechanism for internationalized message strings, sometimes you want a simple set of lines in your program to convert an index to a text string. In RPG III, we accomplished this via the compile-time array. Take a look at Figure 1.
Figure 1: A compile time array in standard RPG III is tedious and error-prone. In Figure 1, the first non-comment is the definition for the array MSG. It says not only that there are five entries of 20 characters apiece, but also that the first numeric entry, 1, indicates that one entry is defined in each source line. Which source line is it? Well, in keeping with the old card-driven days of yesteryear, the definitions are at the end of the source code, after the first line with asterisks in the first two positions. This is fine if you're reading from an 80-column card reader, because it means you can just change the last few cards in the card deck to change the literals. But the problem is that any time you need to add an entry, you have to make changes in two completely separate parts of the code: the very top and the very bottom. That is a tedious and error-prone procedure, and it only gets worse as you add more arrays. Now, as many of you know, CVTRPGSRC is a very simple converter, and it doesn't do anything it doesn't have to do. It works fine, but the result isn't exactly going to rocket you forward syntactically.
Basically, the E-spec has been replaced with a matching D-spec that specifies an array and indicates that the data is in the source code (CTDATA) and that each record contains one entry (PERRCD(1)). The issues of double maintenance still apply, 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. But there is another way!
This is the way we do things in the new millennium! I won't argue the issue of message files versus hard-coded literals; this example assumes that you have already decided you want to use literals, and we'll acquiesce to your better judgment. Since you want literals, I've given you literals. Let's take a look at the code. The first D-spec defines a data structure named dsMSG. Note that all fields are based on the original array name; in fact, the array itself keeps its old name. This new style of definition needs two more fields: the data structure and the number of entries, and those are dsMSG and #MSG, respectively. The dsMSG name simply provides an anchor point for the MSG array; it will be used at the very end of the data structure. Following it are each of the original strings, stored in unnamed fields of the original length of the array. What this does is store the literals contiguously in memory. The fields are initialized using the INZ keyword. I'm showing screen shots of WDSC because I want you to see the syntax coloring; the comments on the right (MSG001, etc.) show up in turquoise and stand out from the message text itself. This is a good way to visually relate the array index to a specific message. After the messages have been defined, the last entry in the data structure is the definition of the array itself. You specify the length and entries of the array and tell it to overlay the data structure. This will cause it to aggregate all of the literals in the data structure into a single array. There are a couple of variations on this theme, depending on what you want to hard-code. This is my personal choice: I hard-code the size of the array element but put the number of elements in a constant. Now, to add a new entry, I add a new line in the array and then update the #MSG constant (which I can use later in the program if I need to in order to process the array). I'm hoping that someday IBM will let me specify the length constant using an expression (something like %SIZE(dsMSG) / %SIZE(MSG001), where MSG001 would be the name of the first string) so that I could simply add a new line to the array and everything would be done. But for now, adding a line and updating the count variable right after the array is good enough for me; I usually remember to do both. And even without the expression in the constant, with this tip you have a way to define an array of literal strings so that everything—the array, the size of the array, and the contents of the array—is defined at the same time. | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
| Last Updated on Wednesday, 19 December 2007 03:50 | ||||||||||||||||||||||||
