You may wonder why I bothered writing a "tip" about sorting arrays when SORTA has been around for quite some time. And, in fact, some programmers have found other techniques for sorting that are even faster than the SORTA operation.
But the topic I wish to discuss is more complex than just sorting. Sometimes, we need to load information into "related" arrays, similar to fields in a multi-occurrence data structure or fields in a subfile. But the ultimate need is to order (sort) the randomly occurring data that has been loaded dynamically into the arrays and then send the sorted output to print or some other output. The SORTA operation sorts one array, and if the array has index correspondence to some other array, it is lost as a result of the sort process. We need to not lose that correspondence.
In RPG/400, we do this by creating a new work array with a new element size that is the sum of two arrays where we want correspondence. A short routine puts the desired sort array element on the left side of the new array element and the "tag along" array element on the right side. By sorting the new array, we succeed in keeping correspondence. Next, we use another short routine to split the elements apart and put them back in the original arrays. If more arrays are involved, then the work array loading routine gets messier, as well as the unloading routine.
But RPG IV has the ability to sort an array while maintaining correspondence between one array and others very simply. Let's look at an example.
In a selected incoming data record, the name, city, account number, and dollar amount are placed in separate runtime arrays, using the same element index for each array. After loading many items (in no specific order), the array data is desired in subfile output or printed output in some order--for example, ascending by city. Sorting the city array solves one issue, but the correspondence between a city array element and the other arrays is lost. The RPG IV solution is to specify the arrays as part of a larger array within a data structure:
D DS
D Record 63 Dim(50) Ascend
D Name 25 Overlay(Record)
D City 20 Overlay(Record:*Next)
D Account 9 0 Overlay(Record:*Next)
D Amount 9 2 Overlay(Record:*Next)
Record is an array. Name, City, Account, and Amount are also arrays, since they redefine Record. By specifying "SortA City" on calculations, the corresponding array elements in Name, Account, and Amount are moved with the City elements during the sort because, in effect, the whole record is being sorted.
Of course, if the arrays are not filled during the load process, blank elements will "pop" to the top as a result of the sort. The routine to extract the information must bypass these empty "records." Also, if the arrays are used repeatedly, they may need to be cleared to avoid "old" data from being mixed with new information.
While the need to sort randomly occurring data doesn't come up very often, the technique described here may save you some time and reduce the complexity of your program.
Jim Martin is a corporate technical instructor at Jack Henry & Associates, in Monett, Missouri. He is a veteran of RPG programming, beginning in 1967 with a position at IBM as a systems engineer, and later was a staff programmer at the Rochester systems programming lab. For eight years, he was at Lakeview Technology as an AS/400 and RPG instructor and a speaker at various local midrange user group meetings and conferences. He can be reached by email at jmartin@truevine.net.
|
