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 think of this as cool - 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 will automatically be handled by the READ and WRITE. 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 to have a field defined as packed in a database file and zoned in a screen file. RPG just does any necessary conversions when it move 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, or I should say it has been at least since RPG II. (I don't know much about the original RPG prior to RPG II.)
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 actually mentioning the subfields by name. Just like the example above, the following code will automatically handle 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 I do think it is very cool the way RPG automatically handles the fields from files, I sometimes wonder if it would be better in the long run for program maintenance to have the movement of field data from file to file be more explicit. But that's a topic for another blog post.
