In the last issue, I talked about qualified data structures in RPG IV. Qualified data structures give you the ability to create multiple data structures with identical subfield names, a capability previously unavailable to the RPG world.
Qualified data structures were introduced with OS/400 V5R1. When V5R2 was announced, IBM included several enhancements to RPG IV, including an enhancement to qualified data structures. Surprisingly, this slight variation to qualified data structures makes them even more useable than they are under V5R1.
Since qualified data structures can contain subfield names that are the same as the subfield names of other data structures, IBM instituted nested data structures. IBM calls this new feature "complex data structures." To me, the only thing complex about them is calling them "complex data structures," so I choose to call them "nested data structures."
In addition, RPG IV now allows data structures to be declared and used just like arrays. That is, you can use the DIM keyword instead of the OCCURS keyword when defining a multiple-occurrence data structure. The benefit of data structures as arrays is that the syntax is much less complicated when you refer to a data structure as an array vs. when you need to use the OCCURS keyword and operation code.
Nested Data Structures
Nested data structures are data structures within data structures. Strictly speaking, nested data structures are qualified data structures within qualified data structures. In other words, a subfield of a qualified data structure may also be another qualified data structure.
Nested data structures allow you to move beyond using the OVERLAY keyword in your definition specification by providing you with the ability to declare a data structure subfield as a data structure itself. How do you do this? Simply add the LIKEDS keyword to the subfield, and it becomes a nested, qualified data structure. Figure 1 shows an example:
|
Figure 1: Example of a nested data structure
When this code is compiled, it is expanded to include the QUALIFIED keyword for the ORDDATE subfield, and the four subfields of CLDate are inserted into the CUSTORDER data structure. See Figure 2.
|
Figure 2: Compiler-expanded nested data structure
The ORDDATE subfield actually becomes a nested data structure. It is a regular data structure that also happens to be a subfield of the CUSTORDER data structure. In Figure 2, the ORDDATE subfield contains the CENTURY, YEAR, MONTH, and DAY subfields. You'll recall from the last isue that the way you access qualified data structure subfields is by qualifying the subfields to the data structure name. For example, in the Calculation specifications, in order to retrieve the DAY subfield, the following code is required:
C eval nDay = CustOrder.OrdDate.Day
In this example, the DAY subfield is qualified to its parent data structure, ORDDATE. ORDDATE is qualified to its parent data structure, CUSTORDER. If the subfield DAY was not used (as shown below) then the value of ORDDATE would be returned by this statement. That is, all seven positions of the ORDDATE subfield would be returned instead of only the DAY subfield's value.
C eval CLDate = CustOrder.OrdDate
More Than LIKEDS: LIKEREC
With V5R2, in addition to the LIKEDS keyword, IBM introduced a new keyword that allows you to declare one data structure "like" another. This new keyword does not use an existing data structure as the format for the new data structure; rather, it inherits its data structure layout from input file format.
The LIKEREC (Like Record) keyword is used to declare a data structure or a subfield of a data structure (in the case of nested data structures) the same as the layout of record format declared elsewhere in the source member. This means that if you have a database file declared in the source member, its record format name may be used to declare a data structure. This is very similar to the LIKEDS keyword, except it uses a file format instead of a data structure.
The LIKEREC keyword has an additional parameter that LIKEDS does not. The second parameter is optional and allows you to specify which fields from the record format are going to be included in the data structure you're declaring. These are the special values:
- *INPUT--Only input-capable fields are included.
- *ALL--All fields of the externally defined record format are included.
- *OUTPUT--Only output-capable fields are included.
- *KEY--The key fields of the externally described database file are included. They are included in the same order that they appear in in the key.
If the second parameter of LIKEREC is not specified, then *INPUT is the default. Most of the options for LIKEREC are obvious: *INPUT includes only input fields, and *OUTPUT includes only output fields. The one that is interesting is the *KEY option, which causes the key fields to be included in the data structure.
Why do I care about *KEY? Another new feature of RPG IV is the ability to use a data structure as a key list. To do this, you declare a data structure with the key field as subfields. The LIKEREC keyword and its *KEY option make this incredibly easy! Then, in free-format RPG IV, you can use the new %KDS operation code function to identify that the data structure is a key list. For example, see Figure 3.
|
Figure 3: LIKEREC Keyword and Key Lists
Granted, my free-format RPG IV skills are not the best (I'm still being stubborn about the need for a semicolon after the IF, ELSE, ELSEIF, ENDIF, and ENDDO statements), so the code in Figure 3 may not be perfect. But Figure 3 declares an externally described file named CUSTMAST. That file's record format (CUSTREC) is being used on lines 2 and 3 to declare two different data structures. The first one is named UNDOBUFFER. It occurs 20 times and is probably being used in the program as a way to enable an "undo" function in the program.
The second data structure (line 3) is also based on the CUSTREC format, but the LIKEREC keyword includes the *KEY option. This causes the data structure to be declared using only the key fields from the CUSTMAST file.
Down in the free-format specifications, the first statement is a CHAIN operation that uses the new %KDS operation function. This tells the CHAIN opcode three things about CUSTKEYS:
1. It's a data structure.
2. It includes only key fields.
3. It is to be used as the key list to chain out to the file.
The %KDS function also accepts an optional second parameter that indicates the number of key fields to be used. For example, if the data structure contains five key fields, but you want to use only three of them, the following CHAIN operation and %KDS function would be used.
This tells the %KDS function to use the first three subfields of the CUSTKEYS data structure as the key list for the CHAIN operation.
You can use the LIKEREC keyword just as you'd use the LIKEDS keyword. The data structure is a qualified data structure and may also be a nested data structure or the parameter of a prototype or procedure interface. It may also be the return value of a procedure.
Next time, I'll review the new "Data Structures as Array" feature that makes multiple occurrence data structures obsolete.
LATEST COMMENTS
MC Press Online