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