RPG's "Move fields" logic, and its cousin EVAL-CORR

RPG's "Move fields" logic, and its cousin EVAL-CORR

One of the cool features of RPG is the "move fields" logic where data is moved from input buffers to program fields and from program fields to output buffers. Most RPG programmers don't consider this to be a special feature - it is so fundamental to RPG that RPG programmers take it for granted.

When the RPG programmer defines a file in the RPG source, the compiler implicitly generates an internal program field for each field in the file, and the compiler also implicity moves data from the I/O buffers to the program fields for read and write operations to the file. If a particular field name appears in more than one file used by the RPG program, the field can be read from one file and then written out to the other file without any effort on the part of the RPG programmer.

Example: Say files FILE1 and FILE2 files have fields NAME and ADDR. A READ operation reads both those fields from file1 and a WRITE operation writes both those fields out to file2. It's not necessary to mention the field names in the source unless the fields are needed for some calculation.

       read FILE1;
       write FILE2;

If a new field CITY is added to both files, and the program is recompiled, the CITY field is automatically handled by the READ and WRITE operations. No change is required to the program source.

If you look in your compiler listing, you can see the I and O specs that the compiler generates. These specs are not just descriptions of the I/O buffers. They are executable operations. The I specs are move operations from the Input buffer to the program fields, and the O specs are move operations from the program fields to the output buffer. It is because the I and O specs are executable operations to and from program fields that it's possible for a field to be defined as packed in a database file and zoned in a screen file. RPG automatically does any necessary conversions when it moves the data between the I/O buffers and the program fields.

You can see the I and O specs in action by stepping through the I and O specs in the debugger. You have to compile with OPTION(*DEBUGIO) and use the listing debug view.

The "move-fields" logic has always been part of RPG.

The EVAL-CORR opcode (added in v5r4) works in a similar way. If the READ and WRITE operations use data structures instead of using the I and O specs, you can assign all the same-name subfields from one data structure to another without specifying each subfield by name. Just like the example above, the following code automatically handles the new CITY subfields when the program is recompiled after the CITY fields are added to the files.

read FILE1 ds1;
       eval-corr ds2 = ds1;
       write FILE2 ds2;

Even though it is excellent the way RPG automatically handles the fields from files, it might be better for program maintenance in the long run to have the movement of field data from file to file be more explicit.