Data structures can be used to solve many programming problems encountered in everyday work in RPG. Many operations used to rearrange data can be eliminated by effective use of data structures. Data structures can be externally defined, allowing programs to share the same view of information and eliminating the need to define the view more than once. In this article, I'll explain what data structures are and show you how to use them to simplify some common programming tasks. I'll provide samples in OPM (Original Program Model) RPG (RPG III) and ILE RPG (RPG IV).

What Is a Data Structure?

To help you visualize the concept of a data structure, think of a record format (or record structure); for example, a display file record format. A display file record format defines the fields that are read from or written to a display device. To display information, a programmer simply writes the record format, and every field defined for that format is written to the screen. Grouping the fields and referencing them as one unit reduces the amount of code required to handle information. Similarly, disk record formats define the fields that are read from or written to disk. Often, we think of record formats as defining an area on disk, but, when a record is read, that area on disk is copied into memory. The record format ultimately defines an area of memory.

Data structures, like record formats, also define an area of memory and the layout of variables (known as subfields in RPG) found within the area. In fact, the short definition of data structures is a definition for an area of memory.

Data structures allow you to organize and group variables into a single name, reducing the number of variables a programmer may need to handle. To operate on all variables of a group, the programmer needs only to reference a single data structure name.

Data structures also allow a programmer to view the same area of memory in different ways. For example, a single area of memory might contain both my first and last name. Through one data structure, a program can see my first name and last name as separate variables; through another data structure, the program can view my whole name as one variable. Another data structure could view my name as 14 separate variables. The same area can be viewed in many different ways. These different views of memory can make information more usable and can save you from having to handle data in your program with data manipulation operations. The examples I provide later will illustrate these benefits.

Defining Data Structures

In OPM RPG, the data structure definitions must follow any record definitions in the input specifications. They are made up of two input specification (I-spec) formats: the data structure statement and the data structure subfield statement. 1 contains the format for both OPM RPG data structure formats.

In OPM RPG, the data structure definitions must follow any record definitions in the input specifications. They are made up of two input specification (I-spec) formats: the data structure statement and the data structure subfield statement. Figure 1 contains the format for both OPM RPG data structure formats.

In ILE RPG, data structures are defined with the new data definition specification (D-spec). Two different D-spec formats are used to define a data structure: one for the data structure name and one for the subfields. 2 contains the format for both ILE RPG data structure formats.

In ILE RPG, data structures are defined with the new data definition specification (D-spec). Two different D-spec formats are used to define a data structure: one for the data structure name and one for the subfields. Figure 2 contains the format for both ILE RPG data structure formats.

Data structure definitions always start with one data structure statement. The maximum length of an OPM data structure is 9,999 and, in ILE RPG, the maximum length of a named data structure is 32,767. Most often, a data structure is given a name, though it is not required. In ILE RPG, if the data structure is unnamed, the maximum length increases to 9,999,999.

RPG treats the data structure name as character data, although its subfields can be of mixed data types. You can use a data structure name anywhere a character field is allowed.

Following the data structure statement, you specify the data structure subfield statements. Subfields in RPG describe the components or elements that make up a data structure. Although subfields can be of any RPG data type, the program treats the data structure name as a character field. In both OPM and ILE RPG, you can use starting and ending positions to define subfields, but in ILE RPG, you have the option of simply specifying the length of the subfield in positions 35-39. Although using the length notation can be easier than specifying starting and ending positions, it can require you to create filler fields when subfields aren't contiguous.

If the data structure is externally described, the subfield statements are brought in from the external definition. You define an external data structure just as you would define a record format for a database file. The main difference is that you would normally create the file with the member (MBR) parameter value set to *NONE, since the file is most often being used only to contain the format of the data structure. The MBR value of *NONE is not a requirement, however. You can use any external physical file's format to describe a data structure.

Define the record format using Data Description Specifications (DDS) and then create the file with the Create Physical File (CRTPF) command. 3 contains the OPM RPG I-spec and the ILE D-spec used to define an external data structure in your program. In this example, the data structure name is EXTDS and the file containing the data structure definition is EXTDSPF. In OPM RPG, the system always uses the first record format of the file, but in ILE RPG, you have the option of specifying a specific record format. For example, in the ILE definition in 3, I specified DSFMT as the record format for file EXTDSPF. The record format name is optional; if not specified, the system uses the first record format of the file.

Define the record format using Data Description Specifications (DDS) and then create the file with the Create Physical File (CRTPF) command. Figure 3 contains the OPM RPG I-spec and the ILE D-spec used to define an external data structure in your program. In this example, the data structure name is EXTDS and the file containing the data structure definition is EXTDSPF. In OPM RPG, the system always uses the first record format of the file, but in ILE RPG, you have the option of specifying a specific record format. For example, in the ILE definition in Figure 3, I specified DSFMT as the record format for file EXTDSPF. The record format name is optional; if not specified, the system uses the first record format of the file.

Data Structure Initialization

If you have ever worked with data structures on the AS/400, you've probably encountered this problem during your testing phase: you receive a decimal data error message at the first statement that references a numeric subfield from a data structure. You are expecting zeros in this field since the subfield is defined as numeric. However, the field actually contains blanks, which of course are invalid decimal data. If you remember anything from this article, remember that data structures are initialized to blanks at program initialization time unless you explicitly code for the data structure to be initialized.

The easiest way to perform initialization in OPM RPG is to code I in Position 18 of the data structure statement; in ILE RPG, use the INZ keyword. This is what IBM calls a global initialization, which sets all subfields to their appropriate values (i.e., character to blanks, numeric to zeros, date to January 1, 0001, time to zeros, and hexadecimal to blanks) at program initialization time. Look at 4 for an example of a globally initialized data structure.

The easiest way to perform initialization in OPM RPG is to code I in Position 18 of the data structure statement; in ILE RPG, use the INZ keyword. This is what IBM calls a global initialization, which sets all subfields to their appropriate values (i.e., character to blanks, numeric to zeros, date to January 1, 0001, time to zeros, and hexadecimal to blanks) at program initialization time. Look at Figure 4 for an example of a globally initialized data structure.

You can also initialize individual subfields to their default values or a specific value. Just place an I in Position 8 of the subfield specification; in ILE RPG, use the INZ keyword on the subfield statement. To specify your own value in ILE RPG, place a literal or a named constant, left justified, in Positions 21-42 of the subfield definition. 5 illustrates subfield initialization where a literal ('INIT'), a numeric value of 256, and the default initialization value of 0 are used.

You can also initialize individual subfields to their default values or a specific value. Just place an I in Position 8 of the subfield specification; in ILE RPG, use the INZ keyword on the subfield statement. To specify your own value in ILE RPG, place a literal or a named constant, left justified, in Positions 21-42 of the subfield definition. Figure 5 illustrates subfield initialization where a literal ('INIT'), a numeric value of 256, and the default initialization value of 0 are used.

Be careful with subfield initialization. It takes place sequentially starting at the first subfield specification. This means that a subfield you initialized could end up with a different value from the one you expect. For example, if a subfield is defined for the same, or part of the same, memory area previously defined in the data structure, the last subfield specified will determine the value of that area of memory. 6 illustrates this situation.

Be careful with subfield initialization. It takes place sequentially starting at the first subfield specification. This means that a subfield you initialized could end up with a different value from the one you expect. For example, if a subfield is defined for the same, or part of the same, memory area previously defined in the data structure, the last subfield specified will determine the value of that area of memory. Figure 6 illustrates this situation.

Clearing and Resetting

Use the CLEAR operation with the data structure name in Factor 2 to clear all elements of a data structure at times other than program initialization. It sets all or individual subfields of a data structure to blank (character subfields) or zero (numeric subfields).

When you want to set a data structure or subfield back to its initialization value, use the RESET operation with the data structure name in Factor 2. RESET accomplishes the same thing as CLEAR if the data structure was initialized to the default values of blanks or zeros.

Multiple Occurrence Data Structures

A data structure usually stores one occurrence of the view of memory; however, you can define one to contain up to 9,999 occurrences for OPM RPG and 32,767 in ILE RPG. In RPG, this is referred to as a multiple occurrence data structure (MODS).

Think of the MODS as an array of data structures or simply as a group of records stored in memory. You specify how many times you want the data structure to occur. A MODS is defined just like any other data structure, except you specify the number of occurrences in Positions 44-47 for OPM RPG, and with the OCCURS keyword in ILE RPG. See 7 for an illustration of a MODS definition. This data structure has 10 occurrences; below the definition you can see what the information in this MODS might look like.

Think of the MODS as an array of data structures or simply as a group of records stored in memory. You specify how many times you want the data structure to occur. A MODS is defined just like any other data structure, except you specify the number of occurrences in Positions 44-47 for OPM RPG, and with the OCCURS keyword in ILE RPG. See Figure 7 for an illustration of a MODS definition. This data structure has 10 occurrences; below the definition you can see what the information in this MODS might look like.

Notice that, in the ILE example, there is no From position value specified. Here, I simply specify the absolute length (similar to defining field lengths in DDS) of the subfield in Positions 33-39 to define the subfield length. Defining subfield lengths this way eliminates the need to calculate From and To positions.

To load or reference a particular occurrence of the data structure, use the calculation operation code OCUR (OCCUR in ILE RPG). This operation simply sets the current occurrence. Think of occurrence as an index that you don't have to define explicitly. Any reference to the data structure or its subfields will be to the occurrence set by the last OCUR operation. See 8 for an example of setting the current occurrence and retrieving the current occurrence using the OCUR operation. I use a literal in Factor 1 to set the occurrence, but you can also use a field name or named constant as long as it is numeric with zero decimal positions. Retrieving the current occurrence requires a numeric result field.

To load or reference a particular occurrence of the data structure, use the calculation operation code OCUR (OCCUR in ILE RPG). This operation simply sets the current occurrence. Think of occurrence as an index that you don't have to define explicitly. Any reference to the data structure or its subfields will be to the occurrence set by the last OCUR operation. See Figure 8 for an example of setting the current occurrence and retrieving the current occurrence using the OCUR operation. I use a literal in Factor 1 to set the occurrence, but you can also use a field name or named constant as long as it is numeric with zero decimal positions. Retrieving the current occurrence requires a numeric result field.

Unfortunately, RPG lacks the ability to reference more than one occurrence at a time. If you could reference the elements by subscripts (a function that exists in other languages), this restriction wouldn't exist. This would allow you to perform operations such as comparing the first and fifth occurrence. As it is, RPG forces you to set the occurrence, move the MODS data to temporary fields, set the occurrence again, and compare. It's clumsy.

A typical use of a MODS is the need to print a summary page on a report. You may have done this before, using several arrays, but that's usually more cumbersome than necessary. Using a MODS is easier since its elements can be of different types and lengths. This technique is illustrated by the partial RPG code in 9.

A typical use of a MODS is the need to print a summary page on a report. You may have done this before, using several arrays, but that's usually more cumbersome than necessary. Using a MODS is easier since its elements can be of different types and lengths. This technique is illustrated by the partial RPG code in Figure 9.

Grouping and Dividing Data

By defining the same area of memory in different ways, data structures allow a programmer to easily and automatically assemble data elements into a single referable unit and, conversely, to break up a single unit into parts.

You may have a database file with the date set up in three different fields like this: field YYYY (year), MM (month), and DD (day). With a data structure, you can assemble the three fields together into a new field. The code in 10 illustrates this. The program will dynamically keep field SHPYMD updated with the information from the components. If SHPY = '1991', SHPM = '07', and SHPD = '04', then SHPYMD will contain '19910704'. If SHPY is changed to '1992', SHPYMD will automatically become '19920704'. This relieves you from coding numerous operations, such as MOVE and MOVEL or CAT.

You may have a database file with the date set up in three different fields like this: field YYYY (year), MM (month), and DD (day). With a data structure, you can assemble the three fields together into a new field. The code in Figure 10 illustrates this. The program will dynamically keep field SHPYMD updated with the information from the components. If SHPY = '1991', SHPM = '07', and SHPD = '04', then SHPYMD will contain '19910704'. If SHPY is changed to '1992', SHPYMD will automatically become '19920704'. This relieves you from coding numerous operations, such as MOVE and MOVEL or CAT.

You can use data structures to break up data elements into smaller, usable pieces. This is just the opposite of the previous example. Look at 10 again. If SHPYMD = '19911125', SHPY will contain '1991', SHPM will contain '11', and SHPD will contain '25'. Field SHPYMD is subdivided into fields SHPY, SHPM, and SHPD.

You can use data structures to break up data elements into smaller, usable pieces. This is just the opposite of the previous example. Look at Figure 10 again. If SHPYMD = '19911125', SHPY will contain '1991', SHPM will contain '11', and SHPD will contain '25'. Field SHPYMD is subdivided into fields SHPY, SHPM, and SHPD.

Overlaying Data in ILE RPG

With the above example, you can think of the subfields SHPY, SHPM, and SHPD as overlaying the SHPYMD field. The specific From/To positions of the subfields determine how the data from a field occupying the same area of memory overlays the subfield. Because SHPY is defined as occupying positions 1-4, and positions 1-4 of field SHPYMD contain 1991, the data overlays subfield SHPY.

This From/To position notation for overlaying data works in both OPM RPG and ILE RPG. However, in ILE RPG, if you use the length notation, you have another way to specify an overlay?the OVERLAY keyword. Examine the OVERLAY keyword technique in 11 for the same data structure that was defined in 10 using the From/To notation.

This From/To position notation for overlaying data works in both OPM RPG and ILE RPG. However, in ILE RPG, if you use the length notation, you have another way to specify an overlay?the OVERLAY keyword. Examine the OVERLAY keyword technique in Figure 11 for the same data structure that was defined in Figure 10 using the From/To notation.

In 11, you can see that SHPYMD overlays SHPY starting at position 1. (I could have eliminated the starting position for field SHPY because, if no start position is specified, the default is 1.) SHPYMD overlays SHPM starting at position 5 and SHPYMD overlays SHPD starting at position 7.

In Figure 11, you can see that SHPYMD overlays SHPY starting at position 1. (I could have eliminated the starting position for field SHPY because, if no start position is specified, the default is 1.) SHPYMD overlays SHPM starting at position 5 and SHPYMD overlays SHPD starting at position 7.

If you decide to use the length notation, you must use the OVERLAY keyword to define subfield overlays.

Some Things to Remember

You cannot use a data structure name or subfield name more than once within the same data structure or among any of the data structures used in your program. That's to say, data structures A and B cannot both contain subfield X.

Data structures by default are initialized to blanks, which means all subfields, no matter what their data type, will contain blanks. Unless you initialize numeric subfields with valid decimal data, you may end up receiving a decimal data error in your program.

Subfields are initialized sequentially, which can cause unexpected results when subfield definitions overlap. For the same reason, be care-ful when combining global initialization with subfield initialization.

If you don't assign a name to a data structure, you can work only with the subfields.

Use Data Structures

There are other more advanced topics concerning data structures that weren't covered here, such as three special data structures (the data area data structure, the file information data structure, and the program-status data structure) and how data structures can facilitate program interaction with the APIs. For more information about these more advanced topics, see the reference list included at the end of this article.

By now, however, you should know how to define data structures and, from some examples you've seen, you should have some idea of how you might use them in your programs. I encourage you to try to make use of data structures the next time you code a program. Through the proper use of data structures, your code will be simpler and more reliable.

Richard Shaler is a senior technical editor for Midrange Computing.

REFERENCES

ILE RPG/400 Programmer's Guide (SC09-1525, CD-ROM QBKAQD00).

ILE RPG/400 Reference (SC09-1526, CD-ROM QBKAQE00).

OS/400 System API Programming V3R1 (SC41-3800, CD-ROM QBKAVC00).

OS/400 System API Reference V3R1 (SC41-3801, CD-ROM QBKAVD00).

RPG/400 Reference (SC09-1817, CD-ROM QBKAQV00).

RPG/400 User's Guide (SC09-1816, CD-ROM QBKAQU00).

RPG Data Structures Primer

New ILE RPG Limits Affecting Data Structures

? Maximum field name length has increased from 6 to 10.

? Maximum number of numeric field decimal positions has increased from 1 to 2.

? Maximum length of named data structure has increased from 9,999 to 32,767.

? Maximum length of unnamed data structure has increased from 9,999 to 9,999,999.

? Number of occurrences in a multiple-occurring data structure has increased from 9,999 to 32,767.

RPG Data Structures Primer

Figure 1: OPM RPG Data Structure I-spec Formats

 Data Structure Statement Position .Entry 6 'I' (required) 7-12 .Data structure name. Required for externally .described data structures, data area data structures, and file information data structures. 17 'E': If externally described. 18 'I': Globally initialize the structure. 'U': Data area data structure. 'S': Program-status data structure. 19-20 'DS' (required). 21-30 .External file name that contains structure definition. 44-47 .Number of occurrences. 48-51 Length of data structure. Data Structure Subfile Statement Position Entry 6 'I 8 'I': Indicates this subfield is to be initialized. 21-30 External field name. 21-42 Initialization value. If character, enclose with apostrophes. 43 .Blank: character or zoned-decimal format. 'P': Packed-decimal format. 'B': Binary format. 44-47 Start location of field. 48-51 End location of field. 52 Subfield name. 
 
RPG Data Structures Primer
 
Figure 2: ILE RPG Data Structure D-spec Formats
 
 Data Structure Statement Position Entry 6 'D' (required) 7-21 Data structure name. Required for externally described data structures, data area data structures, and file information data structures. 22 'E': If externally described (EXTNAME keyword required if 'E'). 23 Blank: Data structure is not a program status or data area data structure. 'S': Program status data structure. 'U': Data area data structure. 24-25 'DS' (required). 33-39 Data structure length. 44-80 Keywords (External definitions are linked through the EXTNAME keyword.) (Initialization values are defined through the INZ keyword.) (Number of multiple occurrences is defined through the OCCURS keyword.) Data Structure Subfile Statement Position Entry 6 'D' 7-21 Subfield name. 26-32 Start location of subfield or reserved word. 33-39 End location of subfield. 40 Internal data type. Blank: character or zoned-decimal format unless the LIKE keyword is used. 'A' Character 'G' Graphic 'T' Time 'D' Date 'Z' Timestamp 'P' Packed 'B' Binary 'S' Zoned '*' Pointer 41-42 Decimal positions. 44-80 Keywords (Initialization values are defined through the INZ keyword.) 
 
RPG Data Structures Primer
 
Figure 3: External Data Structure Definition
 
 OPM RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 IDsname....NODsExt-file++.............OccrLen+................... IEXTDS E DSEXTDSPF ILE RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++++++ DExtDS e ds EXTNAME(EXTDSPF:DSFMT) 
 
RPG Data Structures Primer
 
Figure 4: Globally Initializing a Data Structure
 
 OPM RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 IDsname....NODsExt-file++.............OccrLen+................... ICTLFMT IDS I 1 10 LSTPGM I 11 130ERRCDE I 14 180RECCNT ILE RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++++++ DCTLFMT ds INZ D LSTPGM 1 10 D ERRCDE 11 13 0 D RECCNT 14 18 0 
 
RPG Data Structures Primer
 
Figure 5: Initializing Data Structure Subfields
 
 OPM RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 IDsname....NODsExt-file++.............OccrLen+.................. ICTLFMT DS I I 'INIT' 1 10 LSTPGM I I 256 11 130ERRCDE I I 14 180RECCNT ILE RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++++++ DCTLFMT ds INZ D LSTPGM 1 10 INZ('INIT') D ERRCDE 11 13 0 INZ(256) D RECCNT 14 18 0 INZ 
 
RPG Data Structures Primer
 
Figure 6: Improper Initialization of Data Structure Subfields
 
 OPM RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 IDsname....NODsExt-file++.............OccrLen+................... I IDS I I 19921114 1 80SHPYMD I 1 40SHPY I 5 60SHPM I 7 80SHPD ILE RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++++++ D ds INZ D SHPYMD 1 8 0 INZ(19941225) D SHPY 1 4 0 D SHPM 5 6 0 D SHPD 7 8 0 In this example, although it appears that SHPYMD will be initialized to 19921114, all fields will end up with a value of zero because subfield initialization is performed sequentially. First, subfield SHPYMD is initialized to 19921114. Then, because of the global initialization specified ('I' in position 18 for OPM RPG and the INZ keyword on the data structure statement for ILE RPG), the remaining fields, SHPY, SHPM, and SHPD, are initialized to zero. Since SHPYMD shares the same area of memory as the three subfields, it ends up with a value of zero instead of the 19921114 you might expect. To correct the above problem, remove the global initialization or move the SHPYMD field to the bottom of the data structure. 
 
RPG Data Structures Primer
 
Figure 7: A Multiple Occurrence Data Structure
 
 OPM RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 IDsname....NODsExt-file++.............OccrLen+................... ISUMDS DS 10 I 1 50CONBR I 6 35 CONAME I 36 462TOTSLS ILE RPG (Specified with length notation) *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++++++ DSUMDS DS OCCURS(10) D Conbr 5 0 D Coname 25 D Totsls 11 2 Up to 10 occurrences of the above data structure can be loaded with data. You can visualize the information as shown below. ....+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 00010ABC Company 00000010000 <- (1st Occurrence) 00020BBC Company 00000020000 <- (2nd Occurrence) 00030CBC Company 00000030000 <- (3rd Occurrence) 00040DBC Company 00000040000 <- (4th Occurrence) 00050EBC Company 00000050000 <- (5th Occurrence) 00060FBC Company 00000060000 <- (6th Occurrence) 00070GBC Company 00000070000 <- (7th Occurrence) 00080HBC Company 00000080000 <- (8th Occurrence) 00090IBC Company 00000090000 <- (9th Occurrence) 00100JBC Company 00000100000 <- (10th Occurrence) ....+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 
 
RPG Data Structures Primer
 
Figure 8: Setting and Retrieving the Current Occurrence
 
 OPM RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 * SET THE CURRENT OCCURRENCE OF DATA STRUCTURE SUMDS TO 5 C 5 OCUR SUMDS * RETRIEVE THE CURRENT OCCURRENCE C OCUR SUMDS CUROC 40 ILE RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq.... * SET THE CURRENT OCCURRENCE OF DATA STRUCTURE SUMDS TO 5 C 5 occur sumds * RETRIEVE THE CURRENT OCCURRENCE C occur sumds curoc 4 0 Using the data in Figure 7, SUMDS would now contain the following: ....+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 00050EBC Company 00000050000 The value of CUROC would contain a value of 5. 
 
RPG Data Structures Primer
 
Figure 9: Partial RPG Code Using MODS to Print a Summary Page
 
 OPM RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 FINFILE IP F 128 DISK IINFILE NS I 1 50CUSTNOL1 I 6 35 CUSTNM I 36 442SLSAMT * Multiple occurrence data structure IMODS DS 100 I 1 50CONBR I 6 35 CONAME I 36 462TOTSLS * C ADD SLSAMT L1SLSA 112 * CL1 EXSR L1TOT CLR EXSR LASTR * * Load data structure record from input file C L1TOT BEGSR C ADD 1 N 30 C N OCUR MODS C Z-ADDCUSTNO CONBR C MOVELCUSTNM CONAME C Z-ADDL1SLSA TOTSLS C Z-ADD*ZERO L1SLSA C ENDSR * * Print each occurrence of the data structure C LASTR BEGSR C EXCPTHEADR C Z-ADDN OSAV 30 C Z-ADD*ZERO N * C N DOWLEOSAV C ADD 1 N * Make the nth occurrence of data structure MODS available C N OCUR MODS C EXCPTDETAIL C ENDDO C ENDSR *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 
 
RPG Data Structures Primer
 
Figure 10: Grouping and Dividing Data
 
 OPM RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 IDsname....NODsExt-file++.............OccrLen+................... ISHPYMD DS I 1 4 SHPY I 5 6 SHPM I 7 8 SHPD ILE RPG *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++++++ DSHPYMD DS D SHPY 1 4 D SHPM 5 6 D SHPD 7 8 
 
RPG Data Structures Primer
 
Figure 11: Overlaying Data with ILE RPG 
 
 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++++++ D DS DSHPYMD 8 D SHPY 4 OVERLAY(SHPYMD:1) D SHPM 2 OVERLAY(SHPYMD:5) D SHPD 2 OVERLAY(SHPYMD:7) 

Also Read

Programming in ILE RPG - Defining Data Structures, Part I

H and F Position-less Specs

Practical RPG: AI and IBM i