Re: SQL enhancements

Mark Lazarus wrote:
> 
> 
>  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.
> 

See, I still believe that you are confusing fields (columns) with
UDFields. There may be thousands of fields, but distinct types?
Currently you only have several numeric, several character and three
date types. Maybe thousands of fields, but only a handful of distinct
types. Add money, customer, name, units of measure, etc. and you can
double the original number, but if you have thousands of distinct types,
then something else is wrong.

Me? I might name it rbh_money as the type.

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

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

> 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!)

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

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

Agreed. Ops Nav needs to do AT LEAST everything that you can do on the
400. For example, Ops Nav can not specify that the group profile be the
owner of objects created by the profile.

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

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

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

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

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

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

I would absolutely not take it personally. You see, I am an independant,
versed in DB2 C/S, DB2 UDB, DB2/400, Oracle and Informix. I am not IBM.

Now they might take it personally, but I doubt it.  <vbg>

-- 
===========================================================
R. Bruce Hoffman, Jr.
 -- IBM Certified AS/400 Professional System Administrator
 -- IBM Certified AS/400 Professional Network Administrator

"The sum of all human knowledge is a fixed constant.
    It's the population that keeps growing!"
+---
| 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
+---