Many RPG IV programmers are starting to code in free-format but are still wondering how to handle the factor-1 search argument used in CHAIN, READE, SETxx, and a few other operations that require a key list. Granted, a key list can be specified in fixed-format C specifications before the free-format lines, but they can be replaced also. The assumption made in this article is that externally described data files are being used and that keys have been defined in them. That said, I'd like to describe two methods that became available in OS/400 V5R2.
One method to use is the inline composite argument list provided on the calculation operation line. This method is very similar in theory to the KLIST scheme. Fields are specified in a parameter-style list, and together, these fields comprise the look-up key argument. No KLIST or KFLD operations are needed. An example would be as follows:
D Fld1 s 7 0
D Fld2 s 5 0
/free
. . .
Chain (Fld1:Fld2) Filex;
If not %found(Filex);
. . . In this example, the two fields named Fld1 and Fld2 are the key fields used to find a record in the file Filex. The data type and length of the fields specified must match the file key(s). This scheme is easy to implement, and it follows all the same rules as key fields that are coded in fixed-format KFLD operations. The only difference is that, in free-format, these fields must be predefined, and no temporary values can be specified, as Factor 2 provides on KFLD statements. Literals can be specified instead of variables in the composite key list. (Note: CHAIN offers many other options that I will not explore here.)
The other method to use, instead of KLIST and KFLD, uses the following elements:
First, define a named data structure in the D-specs that uses keyword LIKEREC with a value of the data file record name and *KEY as the second parameter. Another alternative is the same data structure with keyword EXTNAME with the data file record name and *KEY as the second parameter. The record name specified should match the record name of the file that will be used in CHAIN (and other) operations later in calculations. This data structure then becomes a qualified data structure, with subfields referenced using a recordname.fieldname format. The subfields of this data structure that are related to the keys of the file will be used as the argument key fields in the CHAIN, READE, or SETxx operations that come later in calculations.
Second, use the %kds built-in function (Search Arguments in a Data Structure) with parameters as the argument on the CHAIN (etc.) operations. The %kds built-in function has two parameters. The first parameter is the named data structure explained above, and the optional second parameter is a constant representing the number of key fields to use on the operation. Any number from 1 to n can be specified, where n is the number of key fields specified in the data file. Any number less than n would be considered a partial key list. A "highest order to lowest order" key scheme is used when this parameter is specified. If no second parameter is specified, then all key field values are used.
An example of this method follows:
Assume a keyed data file ARTRANSACT, record name ARRECORD, has key fields ARcompany, ARcustomer, and ARinvoice, and many other non-key fields.
FARTRANSACT IF E K DISK
*
D KeyStruct DS LikeRec(ARRECORD:*KEY)
*
/free
. . .
KeyStruct.ARcompany = ScreenComp;
KeyStruct.ARcustomer = ScreenCust;
Setll %kds(KeyStruct:2) ARTRANSACT; // Set file-ptr
Dou %eof(ARTRANSACT); // Loop through invoices
ReadE %kds(KeyStruct:2) ARTRANSACT;
If not %eof(ARTRANSACT);
// Process an invoice for this Company/Cust group
Endif;
Enddo;
. . . The above example picks up company and customer number values from another file, possibly a display device file, and puts them in the appropriate qualified data structure subfields. Now, the key data structure can be used on the SETLL, READE, or other operations. A partial key is used in this example to access all invoices for a specified company and customer.
Try one of these two alternatives when coding free-format RPG IV!
Jim Martin is 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 becoming 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 was a speaker at various local midrange user group meetings and conferences. He can be reached by email at jmartin@truevine.net.
|
