Re: Cycle Processing vs. Doing it my way

And not only maintained faster - but performs faster.  Like the
informational message 'RPG PROVIDES BLOCK OR UNBLOCK SUPPORT FOR FILE
ITHL01'.  I wonder how many people, who fight the cycle, use the BLOCK
(*YES) keyword on the F spec.

Rob Berendt

==================
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    Douglas Handy
                    <dhandy1@bellsout       To:     rpg400-l@midrange.com
                    h.net>                  cc:
                    Sent by:                Fax to:
                    rpg400-l-admin@mi       Subject:     Re: Cycle Processing 
vs. Doing it my way
                    drange.com


                    12/07/2001 04:17
                    PM
                    Please respond to
                    rpg400-l






Albert,

>The cycle is only useful for programs that read a file from top to bottom

Or have an OPNQRYF front-end selection.  My norm is to always use a *CMD
prompt
to allow multiple selection criteria.  This submits itself to batch, where
the
criteria is constrained by the OPNQRYF optimizer much more intelligently
than I
possibly could in RPG.  Then it reads the file "from top to bottom", with
suitable blocking for increased performance.

The simple fact is, the query optimizer is better at performing the
selection
than I am, based on the selection criteria for a given run.  And the follow
on
RPG program is *very* simple indeed.

>This narrows the number of programs down considerably. Usually it's report
>programs..

Or batch update programs.  Of course, that is a lower percentage of the
total
programs than it was on the S/3 (excluding the Model 15D).

But it is *not* limited to programs which have to process the entire file.
As
Charlie points out, that was true on the 34/36 but is *not* true on the
400.

>Finally, the only thing that using the cycle buys you is being able to
>create a program faster.

And maintain it faster.  And it performs better than me doing my own
selection
criteria processing.  To me, that is a win, win, win.

Embedded SQL may be a reasonable alternative here.

But I have yet to see a SQL statement that is the direct replacement for
matching records, with reporting for *both* an outer-join and inner-join at
the
same time with one simple, fast, blocked pass through the files.

>When you consider the actual number
>of programs where it could be used,

I'm sure I have hundreds of them.  Virtually every batch process (report or
otherwise) can read "top to bottom" -- with dynamic record selection -- in
an
optimized fashion.

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.