× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: DDS Support
  • From: John Bussert <jbussert@xxxxxxxxxxx>
  • Date: Fri, 30 Jun 2000 07:43:32 -0500

All,

You really start to see the differences in the support for the 400's DB2
and the rest when you start to hook it to other platforms in a "native
way".  The web has really forced this.  There are tricks that can be
done using ALIAS (but it has some real "gotchas!") and playing with the
system catalog tables SYSxxxxxxx in QSYS2 or in the catalog library.  It
took  us a long time to figure it out, but we are slowly getting the 400
database to be "other platform" friendly" with SQL et.al. from other
platforms.

john

-----Original Message-----
From: James W. Kilgore [mailto:eMail@James-W-Kilgore.com]
Sent: Friday, June 30, 2000 1:37 AM
To: MIDRANGE-L@midrange.com
Subject: Re: DDS Support


Mark,


"M. Lazarus" wrote:
> 
>  Then I assume you're running as fast as possible from RPG and CL
> coding!  :-)  RPG is non-standard outside of the IBM Midrange.

Well, actually, not running, I am sort of trotting, maybe briskly
walking, into SQL and JAVA. ;) It's the whole print thing and stuff like
level breaks that are holding me back. I still have a lot of RPG/CL/DDS
clients to support, but I am given liberty (without budget) to try out
different approaches.

I'm in total agreement with you about the merits of what IBM has given
us as tools on the AS/400, but, IMHO, the world isn't going to stay the
same for us dyed in the wool IBM midrangers much longer.

Maybe when I get up to speed on SQL I'll have a better appreciation for
the "missing" parts you mention.  But, again, I stand by the premise
that if you have your own tool for data definition, you can control the
creation of DDS or SQL (of any flavor or limitation) and not have to
worry or care about if IBM makes enhancements to DDS, which I think is
what started this discussion.

Sorry,  but I think that the energy would be better spent on having
IBM's SQL implementation enhanced so there are no "missing" parts and
while they are at it toss in REFFLD capability and raise the bar for all
implementations of SQL.

Within this thread, Eric N. Wilson posted what may be a workable
solution to the REFFLD issue.  My problem has not been with the use of
SQL as an alternative to CHAIN, but in the definition of the file
itself.  As I understand it, referential integrity can only be
implemented on those files that are created via SQL.  RI is my goal, but
I didn't want to trade one benefit (RI) at the cost of another (REFFLD).

Personally I could care less about -how- I must define a file, my issue
is whether I can automate the process.  With the proper tools, you can
become platform or implementation independent.  IMHO, DDS is just a
particular platform, and from what you tell me, IBM's SQL is just a
particular implementation.

To sum up my view point, I'm amazed at how a software community spends
more energy on protecting their methods or languages than they do on
creating the tools of the trade.  Maybe my view point was slanted by my
first mentor that made a simple, yet profound (to me anyway) statement:
"Programs -are- data."  For a compiler writer a source program is the
input, for a tool writer the program is the output.  The same can be
said for DDS or SQL or IDDU or whatever the world throws at us next.
+---
| 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
+---
+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.