On Sat, 16 Feb 2019 at 01:35, Booth Martin <booth@xxxxxxxxxxxx> wrote:
This exercise is not going well. Lets say I have 4 programs, 3 of which
have display screens, and each program has one to four specific
activities. There are two data files used.
1. Do I combine all 3 display files into one?
2. Do I compile the programs as modules?
3. Do I write a service program, turning every activity into a procedure?
1) Keep pushing, keep learning!
2) We all of us were there at first!
RPGers who are new to sub-procedures try to find an analogy that will
help them learn. That analogy is often the subroutine. So many times
I've seen someone take an EXSR and wrap a PI around it and call it a
sub-procedure, but in my opinion, this is a misapplication of the
sub-procedure. The best sub-procedures (again, my opinion) are
functions: they take some small number of parameters as input and
return ONE answer. Please please please note that this is the starting
point: it's not a recommendation for everyone to follow in every case.
The point of stating this concept is to help narrow your focus enough
to look into the code and find the FIRST sub-procedure, the easiest
one.
Ignore how many display files there are, ignore how many programs
there are. Ignore the idea that you are only looking for code that can
be reused: virtually every independent code block is better as a
function/sub-procedure than as mainline code. Find a bit of code that
seems like it returns one value from several inputs and make that into
a sub-procedure.
As far as the infrastructure goes, ignore modules, ignore service
programs, ignore binding. Set that all aside. You're going to make
your first sub-procedure part and parcel of an existing program. The
only thing you'll need to change aside from creating your
sub-procedure is to add a control specification DFTACTGRP(*NO)
ACTGRP('BOOTH'). Don't worry about the name of the activation group
for this exercise. Use the prototype wizard in RDi to create the PR/PI
for your new sub-procedure and compile as you normally would:
CRTBNDRPG or CRTSQLRPGI *PGM.
ILE has a lot of moving parts, but that's for much more advanced stuff
than I ever needed in 20+ years. That means that you and I can use a
limited palette and still be total ILE-heads. :-) For now, especially,
just focus on one sub-procedure. Put that one sub-procedure inside one
of the existing programs. Learn how they nestle into the existing code
and see how easy it is to call and get a result from. Instead of 6
lines of tax calculations, instead, you might have
taxRate =getTaxRate(totalSalesAmount: taxJurisdiction);
taxAmount = totalSalesAmount * taxRate;
and then you realise that it's a function, and you write
taxAmount = totalSalesAmount * getTaxRate(totalSalesAmount: taxJurisdiction);
My old RPG brain is always looking for those intermediate holding
variables, but they aren't necessary when I use functions!
Hope this helps,
--buck
midrange.com
