Input or Update Primary files and (shudder) the RPG cycle …
First, I'd like to say that obviously there are some very knowledgeable midrange people here ... lots of good tips to pick up ...
I've been programming RPG since the early 80's ... and I notice that
very few people ever use or even refer to the RPG cycle any more ...
nor do I ever see IP or UP (input primary or update primary) files
used very often, even though they are extremely easy to use for
simple report, control break and daily processing/update files ...
Besides the obvious ... few people ever bother to try to understand the RPG cycle ... is there any reason for not using this extremely handy
means of file processing ? ...
Software/Hardware used:
ASKED:
November 11, 2009 9:47 PM
UPDATED:
November 17, 2009 4:33 PM
RELATED QUESTIONS
Answer Wiki:
Here are some reasons:
1. There are few of us left that understand it. This makes it hard for other people to debug or modify our code.
2. It is very difficult to do structured programming using the RPG cycle.
3. When all I wanted to do was read in a stack of 80 col cards, do some calcs and the do stacker select on my output, it was great. ;-)
To see all answers submitted to the Answer Wiki: View Answer History.
Note that the whole concept of “set-at-a-time” in SQL is little more than Cycle processing without ever mentioning the concept. Implicit open/close? Or apply logic to each processed record? That’s a basic Cycle.
As for why many don’t understand or relize the RPG Cycle even in concept…? I have no idea. Maybe it’s simply not taught.
Tom
Actually we use the cycle all the time, just not to process records from a primary or secondary file or automatically pop lines onto a report. Those just don’t seem to mesh well with the complexity that exists in our processing environments.
So this isn’t RPG anymore .. it’s RPG-COBOL-C-JAVA-RPG IV SQL.
Phil
When I (VERY RARELY) am writing a program that needs to just brute force sequentially process every record in a file, I will code an IP or UP, but as others have stated, this isn’t really the types of processes we need right now.
Anytime I need to process a complete file (usually a transaction file), I use IP file type. Its just so much cleaner that coding loops, esp if you need level breaks. I used to have a programmer sitting next to me who would code 30 lines or more to avoid using the cycle or level breaks. He was tausght NEVER to code IP or L1′s in any program. He spent more time debugging …
AUTOREPORT
Way cool!
I can create a roll-up summary report. AKA a balance Sheet report in less than 5 min.
What is even better is that at creation time, I can point the source code to a source file and tweak the code with my special programing requirements.
Phil
AUTOREPORT
Interesting… what is that?
AUTOREPORT was a print layout that was pre-processed much the way SQL is now. The output specs listed the fields and headings on the same line, and the auto-report processor created a print layout speced nicely, overflow and headings, and all the O-specs. If accum as requested, it also inserted the proper C specs to roll totals. It went away (afaik) when printer files in DDS were introduced with RPG-III.
If I’ve got most of a file to go through sequentially, I use the cycle – it’s fast and efficient.
I’ve never used AUTOREPORT and never played around with matching records enough to get the hang of it.
X
An additional design thought …
If you want to use Input/Update Primary processing on a transaction file to find
only new records … say with a program run daily by the IBM job scheduler … but you don’t like the idea of reading through the entire file every time, create a physical file with a processing flag field and then make a logical view that selects only records with the processing flag blank. Once the processing flag is set to ‘Y’ the daily program never reads it again.