RE: SQL vs. traditional I/O?

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx / Bob Cagle
> Sent: Thursday, July 22, 2004 2:17 PM
>
> Maybe I'm opening a bucket of worms here, but for straight RPG
> programming on an AS400/iSeries/i5 machine, why should we use SQL
> instead of traditional RPG I/O (read, chain, etc.)?  I have seen
> multiple postings on these lists and several articles all saying we need
> to switch to SQL now!  But, traditional I/O works great on the platform
> it was intended for - the SQL implementations I have seen are 'clunky'
> at best.
>
> Note: I understand SQL has its place; web programming, etc.  I just
> don't see the need to switch over 100% to SQL.  What am I missing?  Why
> should I use an SQL select statement versus a simple chain to a logical
> file?
>
> Bob Cagle

A simple one-time CHAIN?  Maybe not.  At least I wouldn't.

I'll tell you how I'm starting to use it; you may have seen my earlier posts
this week.

It usually starts out with a WRKQRY query:  User says she needs such & such
a query and, as the request evolves, you see that it's becoming more than
just a simple query.  You start joining files, using calc fields, and (the
final straw which puts me over the "edge") data selection values subject to
change.

I converted the *QRYDFN using RTVQMQRY to get the SQL and "played" (or was
it "tortured myself"?) with it in interactive SQL.  Bonus #1: Get to see
results without having to run the traditional cycle: compile, run, & restart
SEU.  Once the SQL works as desired, it's not that much of a stretch to
embed it into an HLL program.

In my case, since I am on a deadline and I couldn't get past some of the
rookie niggles that were showstoppers for me, I wrote the program using
native I/O.  Inside the loop of reading the big history file, I had to SETLL
on the control file, READE in another loop, test the date to see if it was
in the acceptable range, and increment four different sums.  When I look at
that code compared to the SQL, I think the SQL is much easier to understand
(Bonus #2).

>From what I understand, IBM no longer enhances native I/O; all the
enhancements are done to the SQL "side".

I also think Rob's point about record format level checks is a big plus.

There is a LOT to like about SQL.

db