Re: Cycle Processing vs. Doing it my way

["Charlie Massoglia" <cmassoglia@xxxxxxxxxxx>]

While I have the utmost respect for Jon, I absolutely disagree with him and
am forced to agree with Doug.  Most of the initial opposition to the cycle
came from the System/38.  There was a terrible performance penalty using
input primary files.  The quickest way to speed up a batch process at night
was to change the old converted S/3 and S/34 code to use input full
procedural instead of input primary.  On the AS/400, there is little
difference in processing time between the two.

The other area of opposition came from the System/36 where we could not
easily use level breaks in combination with user specified selection
criteria without having to sort the file even though an index was available.
That problem was easily overcome on the System/38 by using a front end
OPNQRYF followed by a simple RPG III program using the cycle with level
breaks.  An existing compatible access path was used without having to
create a new one.

Is anyone trying to say that an RPG IV programmer who knows the cycle well
can possibly write a report with sub-totals by employee and sub-totals by
department and sub-totals by day quicker WITHOUT using the cycle?  If so, I
would like to see the program.

And how about writing a single program to show customer master file records
with no matching transactions and transactions with no matching customer
master record sorted together by customer number.  I defy you to write that
program quickly without using matching record.  Properly used, matching
record provides similar performance to manual input full procedural files at
a fraction of the programming required.  However, using matching records
when not appropriate, as with any technique improperly used, can provide
TERRIBLE performance.

I learned to use procedures in RPG IV and teach them to other programmers
because they can substantially improve productivity.  In the same respect, I
use the cycle including level breaks and matching records, albeit sparingly,
in RPG IV and teach them to other programmers because they can substantially
improve productivity.

I have a session titled "Level Breaks, Matching Records, and Other Advanced
uses of the Cycle in RPG IV" which I present at COMMON.  I first gave the
session as a joke and was blown away by the number of people who attended.
One attendee told me she finally understood how her boss wrote programs -
not that she necessarily agreed with the technique presented, only that she
could now understand his code.

Anyone who would like a copy of the presentation emailed to them, please
contact me PRIVATELY at cmassoglia@common.org.

Thanks.


Charles L.Massoglia, President
Massoglia Technical Consulting, Inc.
cmassoglia@voyager.net
In MI 517-676-9700 or in NC 919-363-9395


----- Original Message -----
From: "Douglas Handy" <dhandy1@bellsouth.net>
To: <rpg400-l@midrange.com>
Sent: Friday, 07 December, 2001 12:53
Subject: Re: Cycle Processing vs. Doing it my way


> Jon,
>
> >To me the main problem with the cycle etc. is simple.  I want my programs
to
> >be understood by the maximum number of people possible.  ...
>
> >The minute I use the cycle I have automatically eliminate a large group
of
> >programmers from being able to simply grasp the intent and mechanics of
my
> >program.  End of story.
>
> Just to play Devil's Advocate here, the same argument can be alledged
against
> using pointers, or most APIs, or service programs with binding
directories, or
> ...  (name your favorite new RPG IV feature here).
>
> Yet you don't advocate coding to the least common denominator if they
don't
> understand these concepts.  You want them to get with the program, so to
speak,
> and learn how to make use of what the language offers.
>
> Is there irony in the disparity?
>
> 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.
>
>