SQL enhancements -- MIDRANGE-L

Bruce,

At 09:56 AM 9/3/99 -0400, you wrote:

>>  If it's completely global, then that's a large potential problem, since
>> software vendors couldn't really take advantage of it.  Plus, from a
>> definition standpoint it doesn't really make much sense either.
>> LARGE_AMOUNT may mean one thing to one application and something totally
>> different to another.

>True. But software vendors are already naming libraries that don't
>conflict. Remember also that the name is not limited to 10 characters.

 If it has to be unique within a library, then that's OK.  But within the
entire system, would make it of limited usefulness, IMHO, as there are
often many thousands of fields in a system, but only a few libraries.

>Native? No. If you have been paying attention to what IBM says about the
>new features (column level security, etc.) in DB2 on the 400, then you
>know that they are not planning on enhancing DDS to support these
>functions. Commands may appear here and there, but DDS... no.

   <Rant mode *ON>

 I've been paying a lot of attention and I don't like a lot of what I'm
hearing.

>Why build for a single environment? Java is not a single environment.
>DB2 CS and UDB were not for single environments. If the interface is
>defined and built as SQL statements, why add the expense on the 400
>platform of trying to retrofit the features into DDS?

1)  DDS has long been the standard for defining native data on the /400.
2)  We still have to define all other file types w/ DDS, so it's not going
away.
3)  Small point, but does SEU perform basic syntax checking for SQL
definitions?  If not the compile / edit cycle is lengthened.
4)  When it comes to security (the new features), it's not a good idea to
prevent access to certain methods only.  This includes (but is not limited
to) SQL only and Ops Nav only features.
5)  Despite what the marketing people @ IBM would like you to believe, SQL
is not universal.  No language is, even Java (although that is probably the
closest.)  From a practical standpoint, most code written on one platform
is not portable to another w/o a lot of work.  We all need OS services to
get the job done and no 2 OSs are the same.  Now add the (seemingly)
preferred method of embedded SQL in RPG and the solution makes even less
sense.  By and large RPG is not a portable language at all, since other
platforms don't support it.  What does kludging in a different I/O access
method buy you?
6)  SQL cannot grow the same way native commands can, since IBM claims to
follow ANSI standards, which means approval by committee, not a short
process. If they put in extensions that are not ANSI compliant, then the
claim of portability just went out the window.
7)  The SQL pre-compilers are notoriously behind the rest of the language
features.
8)  I personally find SQL great for simple ad hoc queries, updates and
deletes, i.e. set-at-a-time processing.  It's poor for record-at-a-time and
complex processing.

 I can elaborate on (and probably add some to) this list if you like...

>Would you like to pay more or less for the Database? IBM has listened to
>people claiming that the 400 is just more expensive. More expensive
>DASD, more expensive operating system. Granted these are initial costs
>and not ongoing, but still more expensive to get into. 

 It is more expensive, but we pay that because of the reliability and the
integrated features we have come to expect that come w/ the DB.
Interactive / embedded SQL is a separate product, which makes no sense if
that's the direction we're expected to take. 

>The database is part of that cost. DDS is part of that cost. 

 We pay good money for OS/400, compilers and tools.  Is IBM pushing SQL
because they've structured it as an additional fee product?  There is an
initial buy in cost and an ongoing maintenance cost.  It's up to the bean
counters to make sure the money gets distributed properly. As an aside,
we're long overdue for CL (and DDS) enhancements that several hundred
thousand customers have been paying maintenance on for years.


   <Rant mode *OFF>

 Please don't take this personally, I just wanted to get it off my chest,
this issue has been bugging me for a while.

 -mark

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---