In an alternative universe:
April 1, 2010
RPG, from its very inception, has been designed to be an easy to use programming language. Since business data is stored in files, RPG was designed to make reading and writing files easy. To that end, its creators made sure that the processing of files was made easy by its READ and READE and READP operation codes, using a Pascal-like DO loop. Doing subtotals has been accomplished by the programmer storing intermediate data in temporary user-defined fields, then comparing group identifiers with the new identifiers and outputting the results before proceeding. Proper cascading logic enables the user to track multiple group changes that may need to be done at the same time. CHAIN and READ make it possible to easily link related files.
Batch file processing used to be the way to process data; but eventually the report became less important and the screen more so. Now, as SQL is used more and more, with SELECTs and the use of a cursor, pseudo-batch processing has come more into vogue.
With that in mind, we felt it was time to take a radical step to make batch processing more elegant. We have implemented in the latest release of RPGIV a new facility we have chosen to call “the RPG cycle”.
With the RPG cycle, by declaring a file (using new file descriptors in the F specifications) as “primary” or “secondary”, you no longer need to issue explicit READ instructions. The compiler assumes you want to read the file or files from beginning to end. If only one file (primary) is used, you don’t even have to tell the system what file is being referred to. If a secondary file is also used, you use numbered Boolean variables or flags to identify a calculation as being associated with a particular file.
We have also made it possible for the programmer to designate up to nine subgroups for totaling and other calculations associated with the subgroup. If a field designated as a subgroup identifier changes in value, the input data is held in buffers until calculations affecting that subgroup and all lower level subgroups have been completed in ascending level order (from 1 to 9). There is NO need to save data in “hold fields”; the system handles all of that. These field changes are known as “level breaks”, and the calculations associated with them are called “level break calculations”. The changes are referenced or indicated by Boolean variables L1 through L9 (L standing for level). “LR”, now used to designate end of file (Last record) will activate all previous calculations and output for all levels in ascending numerical order.
You can process files one after the other, or you can emulate SQL joins by associating related fields in the files with another Boolean variable called “matching record”, or MR.
You can still use READ and CHAIN to process files, without reference to the cycle; using the new features of the cycle is entirely optional. You can also, within the cycle, read other files using CHAIN and READ operations.
The beauty of the new process is that you don’t have to save the “level break” fields to process group totals. The system takes care of all the details. We have thus created a powerful, flexible system for batch file processing.
Early reports from beta testers indicate a high level of appreciation for, and excitement about, the possibilities of the new process.
Another new feature that has had programmers excited was enhancement of the printing functions of RPG. Now that PDF support has been implemented, the fact that printing is still important has been given more emphasis.
We have been rethinking the whole print process, in an attempt to make it easier. In particular, it was felt that page overflow could be handled more elegantly. With this in mind, a new concept called “fetch overflow” has been implemented.
Suppose you have heading output that depends upon your overflow indicators, defined as Boolean variables OA through OG, plus OV. With an appropriate entry in your output specifications, you no longer have to test for overflow in your calculations and write code to generate the output. The system checks whether overflow has occurred when the detail output is about to print. If it detects the overflow flag on, it outputs the heading lines designated to print at page overflow, then prints the detail line that triggered the process.
If you set on the overflow flag in your *INZSR subroutine, your first page headings will print the very first time a detail line set for “fetch overflow” is encountered. Page control then becomes almost completely automatic. You no longer have to use EXCEPT output to print headings.
Of course, you can still generate headings by testing for overflow manually, or you can count lines on the page. RPGIV retains flexibility in this area.
We are extremely proud of the innovations in this release, and we are confident that the user community will also be happy with them.
The IBM RPGIV Compiler Team
Update: April 15, 2010
Reaction to the upgrades has been enthusiastic, even exuberant. A typical response has been “We love it! It’s great! RPG READ and SQL DECLARE CURSOR are so 20th century.”
Read the original at RPG and Programming.