Knowing how to use arrays is nice, but coming up with creative ways to use them is what its all about. This article gives you some examples of different things you can do with arrays.
In the June 1998 issue of Midrange Computing, I introduced arrays in Part 1 of this two-part series. I showed you how to define arrays and gave you some examples of how to manipulate them. I intended to publish Part 2 in July, but one of the nice things about being an editor is that I have discretion over what gets published and when. Weve had some exciting articles from outside authors lately, and I was eager to let them be published, so I yielded my place to them. However, I dont want to delay Part 2 any longer. I think its time we finished up this discussion.
This month, I concentrate on how to put arrays to work. I include some practical ways to use arrays in typical business applications; I also include some esoteric uses of arrays that you may never need. The point I want to make is that you can do more with arrays than you realize.
Simple Business Techniques Converting Normalized Data to Tabular Form
Database normalization is great for storing data in such a way that you can keep it clean and pull it back out when you need it. However, its not the way we look at information.
For instance, suppose a sales manager wants to see how certain items have been selling each month. Figure 1 shows an SQL statement I might use to answer that question. The output Id get from it is in Figure 2. The information is there, but its not pretty, and it wastes paper.
Instead, I prefer a columnar report, like that in Figure 3. But how do I transform Figure 2 into Figure 3? I know a few methods, but my favorite is to use an array. Columnar reports are well-suited to arrays.
A report like this is easy to generate with arrays, as you can see in Figure 4. The ItemTotal and GrandTotal arrays are accumulators, which are printed out when an item
number changes and at end of job, respectively. Using the RPG cycle and output specs makes this sort of program easy to develop. Notice that the arrays are referred to in several places without an index. This technique saves a lot of coding because one operation to an array replaces 13 operations to scalar variables. It may be ugly code (to some people), but Ill take ugly code and a pretty report over pretty code and an ugly report any day.
Equating Arrays to Scalar Variables in Data Structures
If you work in one of those shops where the cycle and output specs are considered taboo, dont fret; you can still use arrays. Since DDS doesnt support array variables (one of its glaring shortcomings, IMHO), youll have to equate the scalar variables you define in DDS to the arrays you want to work with.
Figure 5 provides an example. The fields beginning ItmTot are scalar fields defined in printer file DDS. Since ItmTot01 is the first subfield in data structure ItemArray, and array ItemTotal overlays ItemArray, ItmTot01 and ItemTotal (1) refer to the same place in memory. Likewise, ItmTot02 and ItemTotal (2) are two names for the same memory address. This means that modifying an array element is equivalent to modifying one of the ItmTot fields defined in the printer file.
Figure 6 shows the RPG III equivalent. Since RPG III variable names cant be longer than six characters, the printer file fields have been shortened to ITMxx. The principle is the same.
Simulating Multidimensional Arrays
RPG doesnt support multidimensional arrays. I can safely say that RPG II and RPG III never will. I have asked the good folks at IBM if I can expect multidimensional array support in RPG IV, and they tell me its on their list of possible enhancements.
I know a few methods of making 1-D arrays support arrays of two dimensions or more. Since I expect RPG IV to handle multidimensional arrays eventually, and since I know that RPG II and RPG III never will, Ill use RPG III to illustrate.
The RPG III program in Figure 7 contains a 2-D array called STTB (state table), which consists of 5-byte elements arranged in six rows of five columns. One way to handle this in RPG (and any language that allows only one array dimension) is to define each row as an element of one array and to move a row into another array in which the columns are defined. In Figure 7, STTB is defined as six rows of 25 bytes each. To access the columns, I used the MOVEA (move array) operation to copy one row into array STLN.
Another method I could have used is to convert the 2-D subscript into a 1-D subscript using the following formula:
(row - 1) * number-of-columns + column
Row 1 would contain elements 1 through 5, row 2 would contain elements 6 through 10, and so on. The element at row 4, column 2, would be calculated as (4 - 1) * 5 + 2, or 17.
I could have also defined an array within a multiple occurrence data structure. This method works, but I dont like it. I have to use one mechanism (the OCCUR op code) to manipulate one dimension, and another mechanism, indexes, to manipulate the other.
The Recondite Stuff
That should give you some idea of the ways in which arrays are typically used in AS/400 shops. As food for thought, Ill show you some alternative uses of arrays that you are less likely to need.
Table-driven programming means that program logic is stored in data rather than in calculations. Lets return to Figure 7 for an example.
If youve used Client Access, you know that to specify a certain file and member, you use the format lib/file(member). How would you go about writing a routine to extract the library name, file name, and member name from such a string? You could probably do it fairly easily with the SCAN op code (or %scan BIF) and substringing operations. But an easy way to do it is with a Finite State Machine (FSM). (An FSM is a computer program
that has a limited number of defined states, only one of which may be active. How the FSM processes a given input depends on which state is currently active.)
If youre interested, you can step through the code to see how this works. All Ill tell you is that the logic of the program is not in calculations but in the state table, STTB. As each character of the input string is processed, the program retrieves a table entry to determine what action to carry out and what the next state of the FSM should be. The same input character can cause different actions to take place (depending on the current state of the FSM), and different characters can force the same action in different circumstances.
If youre interested in FSMs, read my article, Extracting Problem Data from PC Files, in the February 1997 issue of Midrange Computing. Ive been writing FSMs for years, and Ive had a lot of fun with them.
A tree is a hierarchical collection of items. That is, an item can own other items, an item can be owned by only one item, and only one item (the root) has no owners. If an item can own at most two other items, the tree is called a binary tree.
An array makes a good way to store a binary tree. Any element n in the tree has nodes at elements 2n and 2n + 1.
For example, consider that a person has two parents, and each parent has two parents, and so on, as in Figure 8. Sallys parents are Fred and Mary, Marys parents are Bob and Sarah, and Freds parents are Bill and Betty. Figure 9 shows how this information would be stored in an array. If we make a rule that person ns father is to be stored in element 2n and ns mother is stored in element 2n + 1, we can deduce that Marys father and mother are in elements (2 * 3) and (2 * 3 + 1); that is, elements 6 and 7, respectively.
Use Your Imagination!
This is not an exhaustive list; you can do a lot more with arrays. But maybe this article will help you think of ways you can more effectively use arrays in your programs. Get those creative juices flowing, and put arrays to work solving problems in your shop.
ILE RPG for AS/400 Reference Version 4 (SC09-2508, CD-ROM QB3AGZ00) RPG/400 Reference (SC09-1817, CD-ROM QBKAQV00)
select item, xmonth, sum(qty*price)
group by item,xmonth
Figure 1: This SQL statement generates the report in Figure 2
ITEM XMONTH SUM ( QTY * PRICE )
A1 1 14.00 A1 2 6.00 A1 3 2.00 A2 2 6.00 A2 4 6.00
Figure 2: Relational tools typically yield reports that are accurate but ugly
Item Jan Feb Mar Apr May ... Dec Total
A1 14.00 6.00 2.00 ... 22.00 A2 6.00 6.00 ... 12.00 Total 14.00 12.00 2.00 6.00 .00 ... .00 34.00
Figure 3: This report is easier to read than the one in Figure 2
FSlsSumPF ip e k disk
FQSysPrt o f 132 printer oflind(*inOF)
D ItemTotal s +1 dim(13) like(Amt)
D GrandTotal s +1 dim(13) like(Amt)
D MonthNames s 9 dim(13) perrcd(7) ctdata
I Item L1
C L1 eval ItemTotal = *zero
C eval ItemTotal (Month) =
C ItemTotal (Month) + Amt
CL1 xfoot ItemTotal ItemTotal (13)
CL1 eval GrandTotal =
C GrandTotal + ItemTotal
OQSysPrt H 1P 2 04
O or OF
O MonthNames + 1
O T L1 1
O ItemTotal 4 + 1
O T LR 1
O GrandTotal 3 + 1
Jan Feb Mar Apr May Jun Jul
Aug Sep Oct Nov Dec Total
D ItemArray ds
D ItmTot01 6 2
D ItmTot02 like(ItmTot01)
... (ItmTot03 through ITM12 are defined similarly)
D ItmTot13 like(ItmTot01)
D ItemTotal dim(13) like(ItmTot01) inz(*zero)
E IT 13 6 2
I 1 62ITM01
I 7 122ITM02
... (ITM03 through ITM12 are defined similarly)
I 73 782ITM13
I 1 782IT
Figure 4: This short program is quickly developed and easily produces a columnar report
Figure 5: RPG IV code using a data structure to equate an array and printer file fields
Figure 6: The RPG III equivalent of Figure 5
* Break a string of the format lib/file(member) into components
E INP 34 1 Input from caller
E VAL 34 1 Work variable
E CH 5 5 1 Character types
E STTB 1 6 25 State table
E STLN 5 5 State table line
I 1 2 ACTION
I 3 40NEXTST
C *ENTRY PLIST
C PARM INPUT 34
C PARM LIB 10
C PARM FILE 10
C PARM MEMBER 10
C EXSR INIT Initialize
C ST DOUEQ*ZERO
C EXSR GETENT
C EXSR DOACT
C Z-ADDNEXTST ST
C GETENT BEGSR Get table entry
C ADD 1 IX
C Z-ADD1 CX 30
C INP,IX LOKUPCH,CX 33
C *IN33 IFEQ *OFF
C Z-ADD5 CX
C MOVEASTTB,ST STLN
C MOVEASTLN,CX TBLENT
C DOACT BEGSR
C ACTION WHEQ SC
C ADD 1 VX
C MOVE INP,IX VAL,VX
C ACTION WHEQ LI
C MOVEAVAL LIB
C EXSR CLRVAL
C ACTION WHEQ FI
C MOVEAVAL FILE
C EXSR CLRVAL
C ACTION WHEQ ME
C MOVEAVAL MEMBER
C EXSR CLRVAL
C INIT BEGSR
C MOVEAINPUT INP
C MOVE *ZERO IX 30
C Z-ADD1 ST 30
C EXSR CLRVAL
C MOVEL*LIBL LIB P Default value
C MOVEL*BLANKS FILE
C MOVEL*FIRST MEMBER P Default value
C CLRVAL BEGSR Clear VAL
C MOVE *BLANKS VAL
C MOVE *ZERO VX 30
Er00 Er00 Er00 Er00 SC02
FI00 FI05 Er00 LI03 SC02
Er00 Er00 Er00 Er00 SC04
FI00 FI05 Er00 Er00 SC04
Er00 Er00 Er00 Er00 SC06
Er00 Er00 ME00 Er00 SC06
Figure 7: Simulating a 2-D array
Bill Betty Bob Sarah
Figure 8: A binary tree of a persons lineage
Sally Fred Mary Bill Betty Bob Sarah
Figure 9: A binary tree stored as an array
MC Press Online