× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Well, y'all, here goes an attempt at NOT starting a religious war!

FWIW, the cycle is still a part of "modern" RPG - it's always going to be run, unless the developer specifies NOMAIN for a service program module, AFAIK.

And embedded SQL has been possible in RPG III, as well, IIRC.

SQL is great for some things, but not everything. It often is "easier" to embed an SQL statement than to work out the niceties of native I/O. But there may be a trade-off involving performance. Anything that gets somewhat complex may result in temporary indexes being built, even when an index exists that seems it ought to apply. This is most often when there are what I call nested views. This happens when a view is defined over another view, and also when the "with ladida as (select...)" construct is used - this is basically a view. The problem with views is, they are always going to trigger an optimization stage, because basically nothing is stored in a view logical except the select statement. A view is always an ad hoc SQL statement.

This is where the cycle can shine - matching record processing uses exactly the index you specify - no guessing by the optimizer - and it is assumed you, the developer, know what you're doing.

Also, if SQL is used to retrieve a few records based on a key value in a loop, the SQL might execute multiple times - native could do a single CHAIN or equivalent. This could be true even with embedded SQL.

I have a rule - I call it an inverse effort rule - "if it is easier for the developer, it is usually harder or slower for the end user". Fewer lines of code and easier debugging are not our first priority, I believe - the best performing, easy-to-use app for the end user is - they are our customers after all.

Just some thoughts while on vacation. Back to work next week and reality strikes again!

Vern

At 05:20 PM 12/31/2003 -0500, you wrote:
I'm not going to argue against the cycle, but this is the sort of thing
that SQL is good at, too. (In fact, using SQL you _might_ be able to cut
down considerably on the number of separate programs, reducing both lines
of code and debugging issues.)

IMHO, "modern" RPG (meaning RPG IV) does have some real advantages, and
embedded SQL is definitely one of them. But for those who are so inclined,
by all means cycle on! :-)

And to all a Happy New Year!

Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> writes:
>We have a large number of sales
>analysis reports that combine these three files, using the RPG cycle with
>level breaks and matching records. I can imagine writing those reports in
>some other language -- no, thank you very much. The cycle is great for
>that.
>
>However, RPG didn't save that many lines of code (just many hours of
>debugging). The reason is that all of the reports look very similar, they
>just have different selection and sorting before they are produced.


Mike Naughton



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.