Re: Difference bet. Primary and Full procedural file. -- RPG400-L

Ramanujam,

>Doug, how do you let the user choose level breaks?

When that is an issue I don't use cycle level breaks, because I don't believe in
shoehorning a solution when the shoe doesn't fit.  The right tool for the right
job and all that.

Does a progrm which started life as a cycle program with level breaks ever
become full procedure during maintenance?  Sometimes.  But I don't feel I've
lost anything in the process.  Until / if such time as that becomes an issue, I
have *negliglble* time invested in the cycle and use of Lx indicators.  If I
jerk it out of the code I've lost all of perhaps two minutes time when the
program was originally created.  And I still have the subroutines which handle
the actual processing associated with a change in a given field.

When the cycle fits, it works very, very well.  If it doesn't fit the needs,
don't make it try to.  Actually it is more common for me to remove Lx indicators
but leave the program using the cycle as I'll explain below.

In my experience it is extremely common to provide user record selection
criteria, fairly common to provide user sort preferences with only LR totals,
and less common to provide user control over multiple level breaks.

In each of these my typical approach is still to use OPNQRYF to perform the
record selection and/or sorting.  (I have a utility which builds the QRYSLT()
clauses for me.)  This allows the RPG to process the file as if it reading every
record, which makes the cycle a perfect fit with an input primary file.

If there are static level breaks, they get added to the program in the manner I
previously described.  If they are no level breaks, or they are dynamically
determined at run-time, they get passed in as *Entry parameters and the code
deals with them as necessary.

There is no big viture to making these input primary over full-procedural and
just doing a read loop.  But neither is than any real harm in doing so, and
performance is arguably at least as good.  By using ALWCPYDTA(*OPTIMIZE) and
letting the query optimizer decide how to select and process the records, the
RPG program is streamlined into a *very* straightforward process.

Ironically, moving the record selection outside of the program means I find more
cases where the cycle fits now than I did even in RPG II on the S/34 and S/36.

Should I use embedded SQL instead of OPNQRYF?  I'd be more inclined to if the
precompiler wasn't so far behind the feature set of the regular compiler.  The
combination of OPNQRYF and simple RPG programs has served me very well on the
AS/400 (er, iSeries).  I may sound like a heretic, but OPNQRYF isn't that
complicated either, and it performs very well with ALWCPYDTA(*OPTIMIZE).

My general strategy is to create commands for *everything* which may be called
from a menu (or command line if the user is authorized).  I *never* perform a
CALL to a first-level program.

I keep a source file with tons of boilerplates for common command keywords.
Each has just one keyword and associated ELEM or QUAL statements etc.  To build
a new command I just include the keywords I want in the sequence I want, and add
any specific to the new command.  For example, for record selection I might
include a keyword which asks for a specific customer or product number, or a
variation which includes a list with a starting and ending range for the field.
I have boilerplates for all the common files.  Each includes a choice selector
program which allows the user to press F4 on the field and have a windowed
selection program appear to find the desired values.

In literally a couple of minutes time I can create the CMD source for a new
command by just including various pre-built keyword templates.  Send it off to
compile and viola! -- I have a command to ask for all the sort / selection
criteria, including cursor senstive prompting.  And by using selective prompting
characters on keywords in the menu's command text, the same command can act
differently for various users or scenarios.

No need to build a DSPF in SDA.  No need to use SNDRCVF.  Trivial to change in
the future when additional keywords are needed.  And absolutely no problems with
passing numeric values in SBMJOB statements, etc.

Once the command is built by just including prebuilt keywords, I use another
utility which takes as arguments the command name and various features I want
included such as whether or not the command should submit itself to batch,
whether OPNQRYF should be used, etc.  Then it creates for me the CLLE source to
act as the command processing program, validity checking programing, and / or
prompt override program.

In literally a few minutes time I have a new command with all the regular
command prompt features, a CLLE driver program which acts as the CPP and
performs an automagic submit self to batch if requested.  And sets up all the CL
for OPNQRYF processing, including building the QRYSLT clause, doubling up
embedded quote characters (etc) and finally calling the RPG program I specified,
complete with the command parameters, before it cleans up the overrides and
exits.

All that leaves is the RPG program itself, which is now a very straight forward
program which just reads every record passed to it via OPNQRYF, making the cycle
a natural fit.  Level breaks may or may not be, depending on the scenario.

The entire process is quick and painless, and produces *very* standardized code
which makes future maintenance easier too.

Just my .02,
Doug