Every computer language above the level of assembly language has the concept of an array. The original RPG, though, took the array to an extreme level, with concepts such as alternating tables, concepts that hung around the language even after their initial RPG II syntax was long out of date. One of the last vestiges of that heritage is the compile-time array, in which a line with asterisks in positions one and two is placed at the end of the source, and then every line after that one defines an entry in an array. This article shows the modern version of that programming technique, as well as a much more powerful variant of the alternating table.
Hearken Back to Those Days of Yore
It's sometimes best to begin at the beginning, which in this case is the old RPG III days. I briefly considered going all the way back to RPG II, but I didn't think I could revive enough of those brain cells to make a coherent example. But RPG III I can do:
E ID 1 6 3 DTA 27
I 1 20 CITY
I 21 22 STATE
I 23 27 ZIPCOD
C Z-ADD1 X 30
C '002' LOKUPID,X 90
C 90 MOVE DTA,X STRDTA
C MOVE *ON *INLR
004Manhattan Beach CA90266
What you see in the first listing is the code required to handle an alternating array as well as the compile-time definition of the data. The compile-time data is the green stuff after the double-asterisk. If you're as old as I am, you may recognize the concept of putting data after the source code using the ** technique. The first two characters of the card deck were often used to control how the data was used, so it's no great surprise for RPG to use two asterisks to tell the compiler that this is no longer RPG source code but instead should be treated as data. For us old-timers /* does not mean beginning of comment; it means end of file, but as usual I digress....
Anyway, what the code does is simple enough. It creates two arrays of six elements each (one named ID and one named DTA), with each source line containing one element from each array (hence the term "alternating arrays"). In this case, the left element is the three-character ID, while the right element is a 27-character composite field. The composite field is further defined by the STRDTA (SToRe DaTA) data structure. The code does a lookup for the hardcoded ID "002" in the ID array and then moves the corresponding data from the DTA array into the STRDTA data structure. When this code is executed, the program ends with (among other things) the CITY subfield containing the value Palatine. This was pretty much the state of the art of the basic RPG III opcodes. Let's fast forward, shall we?
Arrays in the World of RPG IV
RPG IV gets a lot more creative. First, you can specify all the data and all the structures in one nice, contiguous set of source code. Next, you can specify more than two subfields; you can specify many array subfields, each looking like its own individual array but also inextricably linked to the others.
More importantly, an interesting consequence of the language allows you to not only search against but even to sort by any of the subfields of the data. And because the data subfields are also considered part of the larger data structure, all of the other subfields are sorted right along with the subfield specified on the SORTA opcode.
* Store Lookup
A d cStores ds
B d 1 30 inz('001Charleston WV25286')
B d 31 60 inz('002Palatine IL60074')
B d 61 90 inz('003Poughkeepsie NY12601')
B d 91 120 inz('004Manhattan Beach CA90266')
B d 121 150 inz('005Houston TX77053')
B d 151 180 inz('006Phoenix AZ85048')
C d aStores 30 dim(6) overlay(cStores)
D d aStoreID 3 overlay(aStores)
D d aStoreCity 20 overlay(aStores:*NEXT)
D d aStor