RPGIV @ Work

A unique site for RPG and System i Lovers


Hi, this site will provide all what you need in System i and RPG developments.

My Name is Chamara Withanachchi, System i Expert and RPG Developer. And in the field for last 11 years.

I hope you will find lot of valuable information from this site

Expressions in Keylists Print E-mail
User Rating: / 0
Written by Chamara Withanachchi   
Expressions in Keylists

Thanks to Skott Klement

RPG's native I/O operations support keylists in three different formats: the traditional KLIST, the key data structure (%KDS), and a list of values. One of the big advantages of the list of values format is that it lets you use expressions inside the keylist. Just as an expression can assign the value of a 5,0 numeric variable to a 6,0 numeric value, it can also use keys where the size doesn't match the external definition. There are situations in which this is very useful.

p>The ILE RPG Reference manual explains that there are four ways to specify a search argument for native I/O operations such as CHAIN or SETLL. Three of these ways are the three different methods of specifying a keylist that I mentioned earlier. You'll find this documentation in the section titled Keys for File Operations.

One of the options it lists is called a "list of values." Here's what it says on the preceding manual page:

3. A list of values, such as "(a:b:c+2)". Each part of the composite key may be any expression. Data types must match the corresponding key field, but lengths and data format do not have to match.

For example, a CHAIN operation that uses this list of values syntax might look like this:

  chain (custno: shipDate) SALESTOT;

In this example, there are two keys in the key list. The first is "custno," and the second is "shipDate." The documentation states that the data types must match, but lengths and format don't have to match. I find that behavior very helpful.

We have files in which the field lengths aren't consistent. For example, the GL number is 5,0 in one file and 6,0 in another file. Thanks to the way IBM implemented the "list of values" keylists, I don't have to move the number to a temp field. I can just chain with it.

  chain (inputGL) GLMAST;

In this example, inputGL is 5,0, but the key to GLMAST is 6,0. No need to copy to a temp variable (as you would have done with KLIST). RPG will take care of adjusting the field length for me.

You can use any expression for these key fields—so it works just like EVAL works, which I find very intuitive. When you assign one variable to another with EVAL, the data types of the variables don't have to match. (You can assign a 6,0 field to a 5,0 field, as long as the number would fit in a 5,0 field.)

Expressions also mean you can do some manipulation. For example, I can convert a date field from one format to another right on the keylist.

  setll (%dec(%date(inputField:*USA):*ISO)) Calendar;

The above code converts a field from MMDDYYYY format to YYYYMMDD right on the keylist, and this saves me having to code a temporary field.

Furthermore, we have some inventory files in which a "location" is represented by a warehouse number (1A) and a location (7A). And we have some in which it's one 8A field. No problem! I can do this:

  chain (WHSE + LOCATION) MyFile;

In this case, the two fields (WHSE and LOCATION) get concatenated, and then the output is used as the first key to MyFile. Again, it saves me the effort of coding a temp field.

If you want to guarantee that your field sizes match, you can use %KDS or KLIST to get that behavior. Indeed, with %KDS, you can tell RPG to build the key list for you from the external definition of the file, so there's no chance of a mismatch.

      D keys            ds                  likerec(GLMASTR: *KEY)
         keys.glno = inputGL;
         chain %kds(keys) GLMAST;

If you want RPG to guarantee that they're the same length, this method works very nicely. So you have that option if you need it. But personally, I prefer the "list of values" method with its support for expressions to %KDS and its rigid values. It saves me a few lines of code and simplifies my program a bit.

<Previous   Next>