RE: Difference bet. Primary and Full procedural file.

Thanks Doug..
I guess many of us are on the same page that is use the cycle where it is
appropriate. Does not mean that cycle programming is "ALWAYS THE BEST".
What are the deficiencies of the SQL pre-compiler that bug you the most? Not
that I am going to make them go away, :=), but just curious.


-----Original Message-----
From: Douglas Handy [mailto:dhandy1@bellsouth.net]
Sent: Wednesday, May 22, 2002 10:13 PM
To: rpg400-l@midrange.com
Subject: Re: Difference bet. Primary and Full procedural file.

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
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.