Sorry this is a bit long, my life history.
When every thing was on cards, or tape I never used RPG . Program code,
data, everything, on punch cards.
Drop a stack of cards and if you dont have a sort column you are in big
trouble.
But if all you had was punch cards for data, opcodes like CHAIN
SETLL/READ are meaningless.
The RPG cycle automated the code you would otherwise have to constantly
reinvent when processing sorted stacks of punch cards.
I started on S/3 RPG II. Report Program Generator, when you got to
truly understand the cycle it made writing Reports really really easy
and quick.
Without firstly using SORT in CL I hardly ever used the RPG cycle
(memory fades) S/3 had no LGL files. But it did have ADDROUT sort, a
primitive LGL file.
It was not really possible to use the cycle without the data being
sorted in the proper order.
RPG II and RPGIII had EXCPT and CHAIN and ways to code to out of the cycle.
There was no interactive programing. Until later when S/3 got an add-on
CCP and monitors, oooohhh so very mysterious.
SO because all was batch programming almost every program had a Primary
file and every program used the RPG cycle.
Interactive CCP programs did not need a primary file (from memory I
could be wrong).
This was also a time when if you tried to access a locked record you got
an instant program crash.
One became very very careful to code for record lock control and always
always always minimise record lock time,
S/38 spoilt us with automatic record lock waits.
SQL is so powerful that with a single SQL statement I could do what an
entire batch program did.
The thing SQL doesnt have is report headings and footings and totals
and page breaks.
So to a cycle addict with MR and L1 on their mind you need to show them
a way to get Headings and footings and totals and page breaks, using SQL.
I agree with Don Brown. Excel is a powerful way to transition away from
reports.
I used Excel VB script to access DB2 via odbc and SQL in the script and
drop the SQL data directly into Excel,
It is a quick modification to drop report data into a file, you dont
need to put in headings footings etc. This makes the SQL to retrieve the
data trivial.
You can put code in the scripts to control when the SQL was, and was
not, allowed to run (month-end etc)
You can even put in the Excel script, code to create Headings and pivot
tables so the client can access the data as they need.
Train the client in the power of Excel , you can still produce the paper
reports, dont scrap the paper yet.
Eventually ask the client if they still want the paper report and why.
Invariably they will say for archive purposes.
Now its time to introduce electronic archiving, you will never print
paper again.
So for data processing, SQL with Excel, can extinct RPG even for data
archiving.
ps
Auditors dont like Excel and they say it is prone to manipulation,
so I gave the auditors ways to run the SQL scripts they could cross
check with their own DB access tools.
That kept them happy.
fwiw
Frank
On 18/06/2021 4:37 am, Niels Liisberg wrote:
The funny thing is that SQL nowadays have a feature similar to the L1 L2
etc. take a look at ROLLUP and CUBE
tor. 17. jun. 2021 kl. 20.19 skrev Reeve <rfritchman@xxxxxxxxx>:
I don't think the RPG Logic cycle was ever mandatory. But the lack of
iteration opcodes (DO, FOR, ITER, LEAVE) and the necessary reliance on
GOTO's made bypassing it painful.
Using the logic cycle and control breaks saved untold hours of programming
(and debugging) time. I have many customers unwilling to go to SQL solely
because they fear giving up L1; that's an education process on top with
thoughtful change management hidden underneath.
\reeve
On Thu, Jun 17, 2021 at 11:00 AM Justin Taylor <jtaylor.0ab@xxxxxxxxx>
wrote:
" why use RPGLE with cycle logic"
Beats me. My best guess is that it dates back to when the cycle was
mandatory.
date: Wed, 16 Jun 2021 14:56:56 -0500
from: Ignacio Garcia <cascada3405@xxxxxxxxx>
subject: Re: Commit & Logic cycle
Is a good idea....and why use RPGLE with cycle logic ?
As an Amazon Associate we earn from qualifying purchases.