/Free Your I/O Operations

Last month, we touched briefly on one of the new I/O-related functions available in V5R2, namely the ability for any I/O operation to specify a DS in the result field. Here, we take a look at some of the other V5R2 enhancements in this area.

Let's start with the new support for keyed I/O operations. As you may have noticed, the definition of KLISTs isn't supported in the new /Free format coding style introduced in V5R1. With V5R2, we now know why: The compiler folks had something much better in store for us! Of course the use of conventional fixed-form KLISTs is still supported, but we now have two new-and, we think, significantly better-options.

First comes the built-in-function, %KDS. KDS stands for key data structure. Instead of referencing a KLIST on a keyed operation, we can now reference a data structure that contains the relevant key fields. In addition, an optional second parameter allows us to identify how many of the key fields are to be used. In other words, we only need a single KDS, even if we sometimes want to perform the operation using a partial key. But wait, there's more. We don't even have to code the KDS ourselves. Using the new LIKEREC D-spec keyword, we can have the RPG compiler generate the DS for us. Take a look at these examples and you'll see what we mean:

     // The ProductKeys DS will contain the fields that make up the
     //   key for the Product File (Division, Part No & Version)
     D ProductKeys   DS                  LikeRec(ProductRec : *Key)

     // Read specified record using full key
  Chain %KDS(ProductKeys) ProductRec;

     // Position file using first 2 key fields
  SetLL %KDS(ProductKeys : 2 ) ProductRec;

At we define the KDS using LIKEREC together with the optional keyword, *KEY. This causes the compiler to generate a data structure consisting of fields whose definitions match the database file and, perhaps more important, will "automagically" adjust themselves if the database is modified in the future.

At , we demonstrate a CHAIN operation using the full key, and at we show how to specify a partial key. In this instance we're specifying that only the first two of three key fields be used. Notice how much simpler this is than the old KLIST method which would require us to code two KLISTs-one for the full key, and another for the partial key.


Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.

comments powered by Disqus



2018 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Getting Started With RDP 8, Part 2

Obtaining and installing the new Rational Developer for Power

Getting Started With RDP 8, Part 1

Obtaining and installing the new Rational Developer for Power

Less Talk, More Action

Rich UI enhancements put the B in RBD 8, Part 2

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters
not mf or hp