Re: Cycle Processing vs. Doing it my way

[Douglas Handy <dhandy1@xxxxxxxxxxxxx>]

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