I think you hit on a great point. Of course, Rob is one who likes living on the bleeding edge and might just be able to justify what you are saying. (Chortle!)

I was curious about when SQL Server, e.g., came into existence, compared to the AS/400. Looked it up on WIKI - Microsoft took over Sybase' SQL Server around 1989 and I think official release of SQL Server around 1992. If I read the charts and text right - it WAS early.

There was already an established base of S38 apps using non-SQL techniques - but SQL was already out in some form on the 38 and certainly on the 400, which came out in 1988 or so. But we have suffered from the "no-name-database" problem.

Having said that, I'll probably repeat - the fact that an RDBMS is used other than with relational best practices does NOT make it other than an RDBMS, IMNSHO. I can use SQL Server or Oracle in just as "bad" a way as is being claimed for us dinosaurs on the 400. But I know I was thinking in relational terms in 1995 on the AS/400 when putting an app together, even to 3rd normal form, even though I was not cognizant of all the details of that. It just made sense. But I COULD put dates into SQL Server in 6 or 8 digit numbers. Easy to do.

I've come to the conclusion that this is a perception and marketing issue again, not a technical one. I'm convinced that we do have an RDBMS on the iSeries, but IBM has again done a woeful job of getting this fortressed information out to the general database public.


-------------- Original message --------------
From: Mike Cunningham <mcunning@xxxxxxx>

Don't you think some of these issues are also due to how long databases on
DB2/400 have been inexistence and have not been forced to unload/reload into a
new structure either due to a major change in the database engine or a major
change in hardware. To go back to a large database that was designed using tools
available in the 80's and has hundreds of applications using it and bring it up
to date using current tools and functionality is a very time consuming process
and sometimes adds nothing to the businesses bottom line. If it does make some
process faster or more efficient then it should be done. Yes, dates should be
stored in date type fields but 8.0 numeric fields also work and spending your
organizations money just to change from one to the other can't be justified on
that alone. I do think any new tables (files), columns (fields) should be
created using the newest tools available and I do not see any reason not to
journal just about every table, old or new.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]
On Behalf Of rob@xxxxxxxxx
Sent: Monday, March 10, 2008 8:12 AM
To: Midrange Systems Technical Discussion
Subject: Re: Which of the SYSIBM tables/views show the row count for

I have to agree that many of these features are in there and yet, it takes
a severe beating to get people to actually use them.

This thread ...


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

This mailing list archive is Copyright 1997-2020 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].