Re: Should I replace all CHAIN, SETLL, and READs to SQL -- RPG400-L

A couple thoughts -

1. it is not necessary to write a select/fetch routine - a SET is adequate - yes, it usually includes a SELECT statement - but there's no FETCH needed. I've wondered, never verified - whether a WHERE clause predicate can be used - like EXISTS - that'd be cool - bring the result right into an indicator.

2. I am probably being dumb here, but I really can't see all this problem with VSAM - why even bring it up? It's a red herring, so far as I can see. Here is a statement in a wiki about VSAM on the mainframe - Both IMS/DB <http://en.wikipedia.org/wiki/IMS/DB> and DB2 <http://en.wikipedia.org/wiki/IBM_DB2> are implemented on top of VSAM and use its underlying data structures <http://en.wikipedia.org/wiki/Data_structure>. SQL and native RLA in RPG use the very same underlying MI functions - it really doesn't matter one whit how the data is organized under the covers, at least to me - and VSAM might be what is going on there - but we use SQL on top of that without knowing at all what is in the cellar.

OK - enough - I really am interested in the distinction, if it exists - I think it's a comparison of things at different levels, and that is just not the place to make the comparison - there are better ways to see a valid difference.

I did say enough, right? Now I have to go to a rehearsal - Return to the Forbidden Planet - very fun, cool musical play.

Vern

On 11/5/2012 4:34 PM, WAJE0822 wrote:

I guess I'm a lazy programmer, you see I've adopted SQL for data access because it seems simpler and, for the most part, cleaner then RLA. I've been in the business since the System 360 days and can't tell you how many times I've had to debug a program because it failed to select a give record because it happened to be the second Tuesday of a 30 day month of an odd year. Or better yet, you write a program that reports a subset of total sales and the user says its wrong because the number you're reporting doesn't match sub total value from the total sales report. If you build data views and verify the results, then you can always produce consistent results.
Now don't take this wrong, SQL and RLA are tools and both have their uses. For example, If I need to verify existence I'll use the SETLL op code, rather then construct and SQL select and fetch routine. Why, in the last few months, I've actually written a program that has an Input Primary file.

It is my belief that SQL has become such a popular tool because
1) Machines have become so fast that forcing the database engine to look through thousands of records to find the one you're looking for takes no more noticeable time than a CHAIN, or SETLL and READ.
2) The "IN" languages, and "IN" database engines of the day do not support what used to be called VSAM. The only method they have to process data randomly is through SQL.

A long time ago I read an Intro to Data Processing book (circa 1958). he book is ancient history now but the author said one thing that really stuck. He was raising a warning about trying to do everything with the computer and it went something like this - When all you have is a hammer, everything looks like a nail.
On Nov 5, 2012, at 4:27 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Alan Campin
Every AS/400 shop. Absolute agony about making a change to a table.

You might gain more traction if you were not so predisposed to absolutes and hyperbole. In the SQL vs. RLA debate there are no real absolutes either way. Both have appropriate use cases. You're raising artificial barriers against RLA by ridiculing it and urging all DB I/O to be handled by SQL alone.

We use both SQL and RLA and don't agonize over changing table layouts. We're pretty agile with respect to changes to table layouts. We use a utility to scan RPG source members that would be affected by table layouts, and optionally compile them automatically. There typically aren't a lot. We encapsulate DB I/O appropriately. We use SQL in modules that generate filtered lists and reports, so none of those source members are affected. We don't recompile "the world".

-Nathan

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.