I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

Historically, arrays have become an under utilized commodity in RPG. They are usually used to store small "lists" such as month or day names. This was understandable when the amount of space occupied by an array was a concern and when the means of defining and using arrays was restrictive. But this is no longer the case in RPG IV; we can now define very large arrays, and we are no longer preoccupied with the amount of storage reserved by a program (maybe concerned, but no longer preoccupied).

In this tip, I want to examine some of the features of defining and using arrays in RPG IV.

Figure one shows an alternative to defining compile time arrays. The compile data is placed in a named data structure and the array overlays the data. This method has the enormous benefit of having the array data alongside the definition of the array as opposed to having to page to the end of the program to view the data. There are two interesting points to note: you can define storage in a data structure without providing a DS sub-field name, and you can specify the name of the data structure on the Overlay keyword.

Figure two shows another feature of defining arrays in a data structure. The Address array is defined as having 100 elements, each element being 87 characters in length. The rest of the data structure appears to define subfields that overlay the first element of the array (i.e. the combined length of the subfields is 87 characters). But such is not the case; since the subfields overlay an array they are themselves arrays. That means operations (such as SortA) executed on a sub field actually affects the overlaid array. In the example shown in Figure 2, the SortA of City results in the Address array being sorted based on the 61 to 80 character of each element. Or the SortA of State results in the Address array being sorted based on the 81 and 82 character of each element. The %SubArr BIF is used to ensure that only the elements that have been loaded are sorted (you do not want blank elements being sorted to the start of the array).

We will look at a sample program that allows the user to sort a subfile by placing the cursor on a column and pressing F10. The program is a simple load all subfile with the added proviso that the required data is loaded to an array and that the subfile is, in turn, loaded from the array.

Figure three shows the DDS for the display file containing the load all subfile. The main points to note are (numbers correspond to the numbers in the figure):

1. CA10 is the function key used for sorting. The user positions the cursor on a column and presses F10 to sort based on that column.

2. The Return Cursor Location (RTNCSRLOC) keyword is used to determine which record (CSRREC) and field (CSRFLD) the cursor is positioned on when the screen is returned. For example, the names of the screen format and the field are returned in CSRREC and CSRFLD.

Figure four shows the source of the RPG IV subfile program. The main points to note are numbers correspond to the numbers in the figure:

1. The F10 key is mapped to the indicator F10Sort in the indicator data structure for the display file.

2. An externally defined data structure (SubRecData) is used to store an image of a subfile record. The field names used in the subfile correspond to those inputs from the database files (CCODE and ANAME).

3. AllSubRec is a 9999 (the maximum number of records in a subfile) element array where each element is an image of the SubRecData data structure.

4. Subfields that correspond to the fields in the subfile record overlay the AllSubRec array; so each of these is, in turn, an array. Note how there are no hard-coded lengths or data types in this data structure; all of the components of the data structure are defined using the Like keyword and the use of *Next in the Overlay keyword means you need only be concerned with the sequence of the fields in the subfile record.

5. The LoadDataArray routine reads all required records from the customer and address files and adds them to the AllSubRec array. When records are input the data is placed in the CCODE and ANAME fields in the SubRecData data structure; the data structure is then copied to the next array element. At the end of the routine, the field RecordsInSubfile indicates the number of elements loaded in the array.

6. The subfile is loaded directly from the AllSubRec array; an element is moved to the SubRecData data structure and the subfile record corresponding to the array element is written. The important point to note is that each element of the array is loaded to the corresponding subfile record.

7. F10 results in the execution of a sort routine.

8. Based on the value of the CSRFLD field set on the RTNCSRLOC keyword, the corresponding subfield is used to sort the AllSubRec array. The %SubArr BIF and the RecordsInSubfile field are used to ensure that only the loaded elements are sorted. Processing continues with the subfile being reloaded.

Although this technique is not suitable for volatile data, it does provide a very easy means to quickly re-sequence data for presentation purposes (a subfile in this case, but it could just as easily be for a Web page).xc

And finally

Given that the limits in RPG IV have been extended way beyond anything we could have imagined back in the RPG III days, it only makes sense to make use of all these new capabilities.

We have an historical tendency to refrain from loading a lot of information into memory. When we break the habit we discover there are a lot of neat things we can get our programs to do with little or no performance overhead.

-----------------------------------About the author: Paul Tuohy is CEO of ComCon, an iSeries consulting company. He is the author of Re-Engineering RPG Legacy Applications and is one of the quoted industry experts in the IBM Redbook "Who Knew You Could Do That With RPG IV?"

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy