RPG IV has a little-known feature that allows you to sort an array by any given location. "How?" you may ask. The answer: data structures.
That's right; if you store an array inside of a data structure, RPG IV has an obscure syntax that allows you to specify a subfield that can be used to sort the array. The secret is to declare the array as a data structure subfield and use the OVERLAY keyword to build a mini data structure on top of the array.
The OVERLAY keyword allows you to force one data structure subfield to overlay another subfield. If the subfield being overlaid (specified as the first parameter of the OVERLAY keyword) is an array, the new subfield is also implicitly an array and overlays each element of the original array.
For example, assume an array named ARR appears in a data structure and has 50 elements, each being 30 characters in length. A second subfield named ITEM is declared as 10 positions in length and overlays the ARR subfield. In this situation, the ITEM subfield is implicitly declared as an array by the compiler with the same number of array elements as the ARR array (no DIM keyword is required, nor is one allowed). Each element of the ITEM array overlays the first 10 positions of each element of the ARR array.
The original array, ARR, does not require a length to be specified. A length may be specified, but if it is not, the compiler calculates the length by adding up the sizes of all the subfields that overlay ARR. Tricky? Yes! And certainly obscure too.
Let's take a look at an example of an array with overlapping subfields.
The requirement is to store 250 names and addresses for display in a subfile. A data structure is declared, and an array named THEARRAY is defined with 250 elements. No length is defined for THEARRAY as it will be calculated at compile time. Here is the declaration:
D TheArray Dim(250)
MYDS is the data structure name; although the name is irrelevant, I like to avoid unnamed data structures as a general practice. MYDS contains the subfield named THEARRAY. This subfield is an array with 250 elements.
The fields that will be displayed in a subfile are Customer Number (CUSTNO), Customer Name (CUSTNAME), City (CITY), State (STATE), and Zip Code (ZIPCODE). The end users require that they be able to sort the list by any of the given fields.
We add those subfields to the data structure and include the OVERLAY keyword to cause them to overlay the THEARRAY field, as follows:
D TheArray Dim(250)
D CustNo 7P 0 Overlay(TheArray)
D CustName 30A Overlay(TheArray:*NEXT)
D City 15A Overlay(TheArray:*NEXT)
D State 4A Overlay(TheArray:*NEXT)
D ZipCode 10A Overlay(TheArray:*NEXT)
This code causes the compiler to declare that each of the overlaying subfields also be declared as arrays. CUSTNO, CUSTNAME, CITY, STATE, and ZIPCODE all implicitly have the DIM(250) keyword on them. But since they overlay THEARRAY, they are actually both data structure subfields and arrays, arrays that overlay THEARRAY in memory.
Let's look at a simpler example:
D Item Dim(5)
D Code 1A Overlay(Item)
D Seq 2A Overlay(Item:*NEXT)
In this example, the ITEM subfield is also an array with five elements. Looking further into the data structure, we see two more subfields named CODE and SEQ. The length of these two fields is 1 and 2 bytes, respectively. This means that ITEM is now an array of five elements, each with 3 bytes. By multiplying the number of elements by the number of bytes per elements, we get 15.
If we map out a memory diagram of this data structure and array, we would see the following (note that this is only a portion of the table for the sake of example):
Bytes
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
Data
|
A
|
0
|
1
|
B
|
1
|
2
|
C
|
3
|
4
|
|
ITEM(1)
|
ITEM(2)
|
ITEM(3)
|
||||||
|
Code(1)
|
Seq(1)
|
Code(2)
|
Seq(2)
|
Code(3)
|
Seq(3)
|
Note that each element of CODE and SEQ overlays the corresponding element of ITEM. That is, CODE (1) overlays position 1 of ITEM(1), and SEQ(1) overlays positions 2 and 3 of ITEM(1). Likewise, CODE (2) overlays positions 1 of ITEM(2), and SEQ(2) overlays positions 2 and 3 of ITEM(2). And so on.
We can sort the data in the ITEM array by ITEM, CODE, or SEQ. Whichever part we sort by, the other parts are carried along with it. Thus, if we sort by SEQ, the array ITEM is sorted using positions 2 and 3 of each of its elements.
If we wanted to create an array that contained contact information and needed to sort that information by any of its subfields, we would use the above technique. For example:
In this example, the data structure named MYDS is a typical data structure. It contains the subfield named THEARRAY. This subfield is an array with 250 elements. Note the DIM(250) keyword. No length is specified for the THEARRAY subfield because it's implied, but the subsequent overlapping subfields--CUSTNO, CUSTNAME, CITY, STATE, ZIPCODE--are also part of the data structure, and they overlay the THEARRAY subfield.
This array may be sorted by any of the fields identified with an arrow or even by the THEARRAY field itself, however unlikely that would be.
Let's look at a working example. In the example the follows, the CUSTMAST file is read, and each record is stored in the CONTACT array. After all the records are loaded, the SORTA opcode is used to sort the contacts by the Balance Due. Here's the source code for this example:
FCUSTMAST IF E DISK Prefix(CM_)
D i S 10i 0
D Contact_T DS Inz
D Contact Dim(250)
D CstNbr 7P 0 Overlay(Contact)
D CompName 30A Overlay(Contact:*NEXT)
D FName 15A Overlay(Contact:*NEXT)
D LName 15A Overlay(Contact:*NEXT)
D Address 30A Overlay(Contact:*NEXT)
D City 25A Overlay(Contact:*NEXT)
D State 5A Overlay(Contact:*NEXT)
D ZipCode 10A Overlay(Contact:*NEXT)
D Country 20A Overlay(Contact:*NEXT)
D Balance 7P 2 Overlay(Contact:*NEXT)
C READ CustRec
C DOW NOT %EOF(CUSTMAST)
C eval i = i + 1
C eval CstNbr(i) = CM_CustNO
C eval CompName(i) = CM_CompName
C eval FName(i) = CM_FstName
C eval LName(i) = CM_LstName
C eval Address(i) = CM_Addr1
C eval City(i) = CM_City
C eval State(i) = CM_State
C eval ZipCode(i) = CM_ZIPCODE
C eval Country(i) = CM_Country
C eval Balance(i) = CM_BALDUE
C read CustRec
C Enddo
*** Sort the contact list by Balance Due
C SortA Balance
C eval *INLR = *ON
C return
Of course, all the normal array-sorting issues apply to this example; you have to be aware of unused array elements and also watch for too many records overrunning the array. Using dynamic arrays could help with this, particularly if you extract the number of records you're going to read from the File's INFDS and then allocate enough elements for the array dynamically. See my two previous articles on this topic: "Best of Cozzi: Dynamic Memory and Dynamic Arrays" and "Dynamic Arrays Revisited."
If you want to avoid sorting empty array elements, you will need to keep track of how many elements you've populated and use the new OS/400 V5R3 enhancement %SUBARR. For example:
See my article on "Sorting and Searching Arrays Becomes Manageable in V5R3" for more information.
Bob Cozzi is a programmer/consultant, writer/author, and software developer of the RPG xTools, a popular add-on subprocedure library for RPG IV. His book The Modern RPG Language has been the most widely used RPG programming book for nearly two decades. He, along with others, speaks at and runs the highly-popular RPG World conference for RPG programmers.
LATEST COMMENTS
MC Press Online