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.
Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at
MC Press books written by Joe Pluta available now on the MC Press Bookstore.
 |
||
 |
|
Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
|
|
||
 |
|
WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95
Now On Sale
|
|
||
 |
|
Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00
Now On Sale
|
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online