IBM i > DEVELOPER > WEBSPHERE

/Free Your I/O Operations



But the compiler writers didn't stop here. They gave us yet another-and in some ways even simpler-method of specifying key fields. As you know, we could always specify a field name in Factor 1 as the key for files with a single key. The V5R2 support allows for the use of multiple field names; it even supports the use of literals and expressions, with the compiler performing any required conversion. As you see in these examples, this is achieved through the simple expedient of enclosing the key list in parentheses.

 

     // Read using specified keys
  Chain (Division : PartNumber : Version) ProductRec;

     // Position file based on first 2 key fields
  SetLL (Division : PartNumber) ProductRec;

     // Position file to specified Part number in Division 99
  SetLL ( '99' : PartNumber) ProductRec;

Chain at has the same effect as it does in example -i.e. the whole key is used for the operation. Similarly, corresponds to in that it positions the file using only the first two key fields. is fundamentally the same as but illustrates the use of a literal as part of the key.

Frankly, we're torn as to which of these approaches we prefer. The %KDS option offers the benefit of being self-correcting in the event of a database change, and when a partial key is being used, it's far more obvious than the old KLIST method. On the other hand, the action of the parenthesized field list is immediately obvious. Simply by looking at the operation we immediately know which fields are supplying the key and how many key fields are being used. We suspect that both will find a niche in our arsenal of coding "tools."

There's one more V5R2 enhancement that we'd like to introduce: the new %FIELDS built-in. This one addresses another of our long-term beefs with RPG, namely that the UPDATE op-code updates all of the fields in the record-even those fields that are modified accidentally. To avoid this situation, it was necessary to use output specifications to specify the fields to be updated and then to initiate the update operation with the EXCEPT op-code. The problem with this, of course, is that we cannot determine which fields are being updated by simply studying the calc specs-we must dive down into the O-specs. The new BIF takes care of this deficiency in a very simple and obvious manner.

As you see in example , with the new BIF, we can specify a list of fields to be affected by the specific UPDATE operation. Only those fields specified are updated. Simple, huh?

     // Update only the Cost and UnitPrice fields
  Update Products %Fields( UnitCost : UnitPrice );

 

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

Advertisement

Advertisement

2019 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

IBM i > DEVELOPER > WEBSPHERE

Getting Started With RDP 8, Part 1

Obtaining and installing the new Rational Developer for Power

IBM i > DEVELOPER > WEBSPHERE

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