You are currently on IBM Systems Media’s archival website. Click here to view our new website.


Major Changes in RPG File Handling

Major Changes in RPG File Handling

In March 2009, we wrote about the increased size limits and other new D-spec features added to RPG in V6.1. At that time, we promised to cover more of the 6.1 RPG features later. Now that many shops have 6.1 (or even 7.1) installed, this seems like a good time to come fulfill that promise.

V6 introduced two major changes in the area of file usage in subprocedures. First, it became possible to define a file within a subprocedure. Files defined in this way are local to the subprocedure and therefore fully recursive. For those of you who’ve ever had to code parts explosions for Bill of Materials processing, this offers some interesting possibilities. Second, you can now pass files as parameters—yes, really! It’s this second feature that we find the most interesting in many ways as it opens the door (at least a little) to being able to write generic routines to handle files while still allowing the calling program to maintain “ownership” of the file and therefore the current cursor position. In other words, it has the benefits of a shared Open Data Path without the accompanying problems.

Defining Local Files

Let’s start our exploration with the definition and usage of local files. By default, local files are opened each time the subprocedure is called and closed when the subprocedure returns to its caller. Since opening and closing files is a resource-intensive process, you can force the file to remain open by coding the STATIC keyword as shown at (A) below. If you choose this option, you’re responsible for closing the file yourself. One common approach to handling this requirement is to call the subprocedure with no parameters and have the subprocedure logic treat this as a file close request. The other effect of the STATIC keyword is that you lose the recursive ability of the file. In other words, the same instance of the file will be used at all invocation levels of the subprocedure—in other words, the same basic rules that apply to a variable defined with the STATIC keyword. As you can see the F-spec follows the P-Spec and, as you would expect, must precede any D-specs.

    P GetCustData     B
(A) FCustMast  IF   E           K Disk    STATIC                                                             
    D GetCustData     PI              N
(B) D  custData                           LikeRec(CustMast: *Input)
(C)   Chain custData.CustKey CustMast custData;

One important thing you need to be aware of when defining files in subprocedures is that no I or O specs are generated. As a result all I/O operations must use the DS result field approach. You can see this at (C) where the DS custData is being used to receive the record retrieved by the Chain operation. In this particular instance, the actual record area was passed in as a parameter and is defined in the procedure interface (PI) with the use of the LikeRec keyword. You can see this at (B). Note that since we’re reading the file, we also need to specify the *Input keyword to keep the compiler happy. You might also note that the key we used for the Chain was passed to us in this LikeRec DS. We did this just to point out that by definition anything created with the LikeRec keyword is implicitly qualified. That’s all there is to it.

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.



2019 Solutions Edition

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

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

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