[IMAGE]
[IMAGE][IMAGE]
Ron Turull
[IMAGE]
[IMAGE]
In case you haven't yet heard the news, the ILE RPG compiler now supports -- as of V5R2 -- data structure arrays. That is, you can now specify the Dim keyword on the definition of a data structure to dimension that data structure. Just as you can dimension a stand-alone field to create an array of that type of field, you can now dimension a data structure to create an array of that kind of data structure.
Data structure array basics
It's all pretty straightforward. If MyDS is a data structure array of 10 elements, then MyDS(5) will access the fifth element of that data structure array. But how do you access the subfields? That requires a bit more discussion.
When you define a data structure array, you not only use the Dim keyword, but you must also specify the Qualified keyword. The Qualified keyword was introduced in V5R1, and it allows you to specify the name of a data structure subfield qualified by the name of the data structure. For example, if data structure MyDS is defined with the Qualified keyword and it contains a subfield named Subfield1, then you would use the following notation to access the subfield:
If data structure MyDS is also defined with the Dim keyword, then something like the following notation is used to access subfields in a specific element:
In this example, you would be accessing the subfield named Subfield1 in the fifth element in the data structure array MyDS.
Clear up the confusion over multiple-occurrence data structures
Over the past few months I have detected a hint of confusion about multiple-occurrence data structures with regard to data structure arrays. While the two have some dissimilarities, data structure arrays are essentially and technically the same as multiple-occurrence data struc...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
tures.
More precisely, multiple-occurrence data structures are, and have always been, data structure arrays; they were just implemented poorly and given a goofy IBM name. Of course, this was the result of the six-character limit on fields names and on the Result Field column. Under the covers, data structure arrays and multiple-occurrence data structures are implemented almost identically. You see, a data structure is a high-level language (HLL) construct; there is no such thing as a data structure down at the machine interface (MI) level. That means all data structures must be implemented in a simulated fashion, regardless if they are simple data structures, multiple-occurrence data structures or data structure arrays. Interestingly, the MI language does contain arrays -- and fairly sophisticated ones at that. So, once a data structure is defined at the MI level, making it into an array is fairly straightforward.
Thankfully, we (i.e., the RPG language) have evolved to where we can actually call data structure arrays "arrays" instead of "multiple-occurrences." Unfortunately, most, if not all, of the documentation has not. I have yet to find one definitive statement that explains, for example, that multiple-occurrence data structures are often interchangeable with data structure arrays, such as when passed as parameters.
Arrays (this includes multiple-occurrence data structures because remember, they are arrays) are stored in one chunk of contiguous storage. There are no extra spaces in between the individual elements of the array unless you specify alignment; that is, the compiler will not add any extra space that you don't ask for. Therefore, in storage, a multiple-occurrence data structure looks exactly like a data structure array.
Another good example of the documentation being out of date is the SQL Reference. In the "ILE RPG," it discusses using multiple-occurrence data structures for multiple-record fetches. However, it makes no mention of using data structure arrays as an alternative, never mind that using data structure arrays is actually a better alternative.
Always use data structure arrays
If you are in charge of setting programming practices and standards in your shop, you should insist that data structure arrays are used instead of multiple-occurrence data structures whenever possible. They are much simpler to code, and they are much less prone to bugs.
-----------------------------------
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years experience programming for and managing AS/400-iSeries systems.
==================================
MORE INFORMATION
==================================
- Don't proliferate old, bad code
In an effort to hasten the completion of projects, most programmers "steal" code from other sources within their libraries. The problem is that many times, the code originated years ago and is cumbersome, lengthy and not easy to maintain. Even most ILE code resulted from old code that was passed through a conversion utility. Using the functionality of RPGIV's Keywords and Built-In-Functions usually can make the code much smaller and manageable. Search400.com memb er Joe Szymanski provides a couple of examples, including one involving data structure arrays.
- Referencing a subfile of an array
"JFuchs" is using a data structure as an array and want sto use one of the subfiles of the data structure in an Eval statement. The problem is he doesn't know how to reference this. Not to worry -- Nick Hobson was on hand with some advice.
- "CLEAR" advantage over resetting work fields
Site expert John Kohan illustrates how to use the "CLEAR" operation code to clear the fields in a a single-occurrence data structure or multiple-occurrence data structures.
- Pass larger amounts of data between programs
When using separate programs to retrieve and display data, Search400.com member Tim Cervenec says to use use arrays or multiple-occurrence data structures to pass back larger amounts of data strings.
