Tweet
What are the definitions of these two concepts when referring to primary file processing and level control indicators? The IBM docs refer to both but never define them and I couldn't undestand what little I could find on Google about these concepts. Thanks.
-
-
These are related to the RPG cycle - something that is not commonly used these days and even less frequently taught. While the cycle has utility in some circumstances, it restricts your ability to use the latest free-form version of the language.
It is basically a legacy from the old punch card days.
The simplest way to look at it is that you have a heap of punch cards that represent sales items. You sort these cards into (say) product number order. You then tell RPG to read this heap fo cards and to watch the product number for any change. If the product code is the same as the previous record, then it is simply reported and any totals required accumulated. This is *detail time*. If the product code changes then we enter *total time*and you would output the totals to the printer or whatever.
Typically the only part of the cycle used these days is *INLR = *ON; being used to terminate the program. "LR" is a legacy of the old card input and means "Last Record". In the example above it would be used to trigger the output of the final set of product totals and the grand totals of the run.
If you want to understand it either find a really old book on RPG (any "flavor" such as RPG II would do). You can get some idea from studying the section on "RPG Cycle and other implicit Logic" which for me starts on page 3-28 of the 7.4 RPG reference manual. The chart on page 3-29 shows the basic flow and there is a more detailed diagram on 3-31. -
RPG is a powerful language. The cylce is straightforward and can be used with more recent developments such as REST interfaces, for example.
Code:File YOURFILE: A R YOURFMT A K STATE A K CITY A K DEPT
Code:FYOURFILE IP E K DISK IYOURFILE I STATE L3 I CITY L2 I DEPT L1 C L3 CALLP L3DETAIL first record for this state C L2 CALLP L2DETAIL first record for this city C L1 CALLP L1DETAIL first record for this department C CALLP DETAIL every record CL1 CALLP L1TOTAL last record for this department CL2 CALLP L2TOTAL last record for this city CL3 CALLP L3TOTAL last record for this state CLR CALLP LRTOTAL last record
For example:- L3DETAIL - Set state totals to zero. Retreive tax info for that state, info is retreived via a REST webservice. The webservice is accessed via a service program.
- L2DETAIL - Set city totals to zero. Retreive tax info for that city, info is retreived from an IBM/i file.
- L1DETAIL - Set dept totals to zero.
- DETAIL - For each record calculate the applicable taxes for the item on the record and add the tax amounts to department totals (L1 totals)
- L1TOTAL - Add the L1 totals to the L2 totals. Output the department totals, perhaps some departments have a PDF emailed to them and others have a CSV file delivered to an FTP site. Each delivery method contained in a subproc in a service pgm (for example).
- L2TOTAL - Add the L2 totals to the L3 totals. Report the tax figures to the city, using that city's delivery method (email, ftp, whatever).
- L3TOTAL - Add the L3 totals to the LR totals. Report the tax figures to the state, using that state's delivery method.
- LRTOTAL - Print grand totals for the CFO
Those subprocs can be free form, call service programs, etc. Only those few lines of the mainline need be fixed format. Those few lines clearly show the programmers intent. I think this is preferable to an obscured mainline of home-made level break logic.
I don't think any SQL understandable by mortals can match this. RPG is very powerful. While opinions differ I think understanding the cylce is to your advantage.
Comment
-
Sorry but I have to disagree. The things that makes the "programmers intent" obvious in this code are twofold.Originally posted by UserName10 View Post
1) Your well written comments
2) The fact that you already know the cycle
I know the cycle too - in fact it was all there was when I started. But I would no more use it for new code than fly in the air because for me the most important thing is that my code be readily comprehensible to those who follow me. Requiring that someone know the cycle before they have a clue what I'm doing is just not good practice in my opinion.
You can argue that people _should_ be taught the RPG cycle but that is not reality and these days we need to be able to take a Java/Python/C++/whatever programmer and point them at an RPG program and at least have them able to understand basically what is going on without haveing to do extensive study.Comment
-
Thanks for the replies. I had trouble understanding the difference between putting the level control indicator in pos 7-8 versus putting it in pos 10-11, but I was able to find a site that explained the main steps of the cycle. It was necessary for me to understand this cycle to understand how to construct detail time calculation vs total time calculation lines and what the difference is.
Just one question though, do total time lines have to be grouped together? I tried putting a total time calculation line between some code and kept getting compile errors. Is there a reason why total time calculation lines need to be grouped together? And it seems they must be the last lines of my program? Is it correct to say this?
Thanks.Last edited by JustPassing; February 8, 2020, 04:14 AM.Comment
-
If you are not forced to use the RPG cycle -- then don't !
Very few programmers today know about it. This even though they have been programming RPG for many years.
If you study the example given by UserName10 and the diagram that JonBoy refers to, you can see that the total
calculations are executed BEFORE the detail calculations. But in the source you will find that total calculations
are specified AFTER detail calculations. This can be very confusing for programmers not used to the cycle.
On the other hand are we using some elements of the cycle on a dayly basis.
For example the initialisation of variables. The opening of files. And closing of them when *INLR is on. And many other things.
This is the cycle that handles these things for us automatically.
If you insist in using the cycle then when testing one of the most important things is to check the first and last records read and processed.
This was one of the thing I was taught 34 years ago. Here you will find most errors in programs using the cycle.
And then a lot of comments for the poor programmers that have to modify the program after you. :-)
But still it is 25 years since I last have seen a program using the cycle. Nobody uses it today.
Comment
-
Thanks for the reply. I assure you, if I am trying to understand this, it's not because I "insist" on anything. It's because we still have a lot of old programs written in RPG/400 or RPGLE programs converted from RPG/400 and that still have RPG/400 logic in them. And I sometimes am tasked with modifying these programs.
Yes, I understood that total calculations are done before detail. The examples I found explaining the cycle helped a lot. My issues were more of a practical nature having to do with the coding of it (the rules and restrictions). But with examples, I've pretty much understood the main points.Comment
-
Looks like you are living in interesting times......
Well if you read chapter 3 in the RPG reference manual ( Procedures and the Program Logic Cycle )
you will find most of what is needed about the cycle.
When you are getting in touch with the philosophy of the cycle you will find that it is rather simple.
You have a primary file and perhaps secondary files and they are read first the primary and the the secondary.
Most of the time at least
Because there is something called matching records. I don't know if you have had a program using this ?
Read about it in the manual. It is fairly good described in the manual.
Good luck.
Comment
Comment