Re: SQL enhancements -- MIDRANGE-L

Bruce,

At 07:46 AM 9/7/99 -0400, you wrote:

>> >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.

>And COBOL has long been the standard language for defining business
operations.

 Not on the IBM Midrange, which is what we're dealing with here.

>> 2)  We still have to define all other file types w/ DDS, so it's not going
>> away.
>
>No. You don't have to define any file type with DDS, except for the
>multiformat logicals (which do not comply with Relational rules) and
>even they can be done away with by using Match Record logic in RPG.
>(that's II, III or IV!)

 Do you mean *PRTFs, *DSPFs and *ICFFs will be replaced by SQL??  :-)
(Rehtorical - I realize it was already addressed.)

>> 3)  Small point, but does SEU perform basic syntax checking for SQL
>> definitions?  If not the compile / edit cycle is lengthened.

>No, but IBM is not going to enhance SEU either. CODE and it's associated
>editor, LPEX, maybe...

 That's part of my point.  Since IBM isn't enhancing SEU, ut's becoming
more and more difficult to use some of the new features.  As a consultant I
often don't have much control over what tools shops own.  This is a
reality.  Blocking access to a system feature because it hasn't been built
into another mainstream area (i.e. column security and DDS) is adding
insult to injury.


>> 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?
>
>NO. NO. NO. It is NOT the marketing people of IBM. I do not listen to
>the marketeers, I prefer to listen to the developers. While SQL is not
>completely standard across all platforms, IBM does (more so than other
>vendors) try to adhere to the standards. As for the non portability, I
>have found it to be MUCH more portable than DDS.

 Do the IBM developers set the policy of other vendor's SQL
implementations?  Of course not. The reality is that there are subtle
differences that often have large ramifications.  But putting that aside,
in full blown business applications, embedded SQL does little to promote
portability! The entire application would have to be rewritten anyway, and
the SQL often makes the code more difficult to read, so what was gained?

>> 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.

>Well now, if SQL cannot grow the same way native commands can, then
>where did common table expressions come from. Did I miss something? Is
>this available in command format? No.

 I don't currently have access to a R4 machine, so I'm not familiar w/
"common table expressions."  What is this?  How is this implemented?  If
it's what I think it is, then there's no technical reason that Rochester
couldn't implement this fairly easily in DDS.

 BTW, I assume that this a standard ANSI SQL feature, right?

>> 7)  The SQL pre-compilers are notoriously behind the rest of the language
>> features.

>Language features? Like what? Called procedures? That's what User
>Defined Functions are.

 Nested /COPY functions, for one.  /IF DEFINED compiler directives.  The
need to have the field definition placed in the code before encountering
that field as an SQL definition (even RPG II didn't have this limitation!!)
 Correct me if I'm wrong on any of these limitations.

>> 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.

>The word "poor" is the problem here. Is is faster than native reads and
>writes? No. That's a given. Complex processing? Depends on the release.
>I have found that at V4R2 and above, performance of complex processing
>(say common table expression join with distict selection for specific
>subsets) can easily perform better than program logic to access and
>process the same information.

 I'm not going to get into performance issues, because that's a moving
target between end user environments and OS releases.  I personally find
complex nested SQL statements unintuitive and difficult to debug.  Most
HLLs do record at a time processing, i.e. read a record, do some calcs, and
then some sort of output.  A set at a time language embedded in a record at
a time type program leads to some kludgy code.

>>  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.
 

>The initial buy is is also on the RPG compiler. You buy the compiler
>option, not the functionality option. Your SQL program can run on ANY AS/400.

 All I'm saying is that until the functionality is available across the
board IBM shouldn't be trying to push this on us by refusing to upgrade
certain areas.  I certainly can understand that they want the upgrade
revenue stream to keep coming, but I think that Rochester has been skating
by in a few areas by ignoring the customer.  Al can give you a list of
thing he and others have been speaking up about in Common that we've heard
nothing about for the longest time. (Hint: how many CL *language*
enhancements have we had in the last 5 years?  I can think of two: %BIN and
allowing CL to become an ILE participant.)

 The same goes for any of the native development tools.

 -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
+---