IDMS vs. DB2
Alan Fields
I know this is a very broad, open-ended question, and your mileage
will vary greatly, but we've got some folks here who have made an
isolated comparison, and they are about to generalize a single result
into the conversion of an entire system (this one is a biggie; if
they're wrong, we, the company, could be in deep sneakers).
Anybody got any hard numbers, advice on where to look, or general
observations?? I really am looking for objective opionions, but I'll
take what I can get (and I am well aware of the audience I'm asking).
Alan Fields
VF Jeanswear
Greensboro, NC
(336) 332-5631
Alan_...@vfc.com
Lorenzen, David C
I would match IDMS up against DB2 any day. Several companies I can think of
right away,
"IT" San Antonio, "Bexar Appraisal" in San Antonio, just to name a few
regret having DB2
and would have wished staying on IDMS. Our testing indicated that DB2 was
very (and
still is) I/O intensive and is nothing more than a means to sell IBM DASD.
Just my 1.5 cents worth.
Dave
----------
From: Alan Fields
Sent: Tuesday, November 24, 1998 1:27 PM
To: IDM...@UGA.CC.UGA.EDU
Subject: IDMS vs. DB2
Jerry Fica
Jerry Fica DBA
Holland America Lines - Westours
300 Elliott Ave. W.
Seattle, WA 98119
Phone 206-281-0601
Email jf...@worldnet.att.net
JB Moore
>
> Has anyone out there done solid benchmarks of IDMS vs. DB2??
>
> I know this is a very broad, open-ended question, and your mileage
> will vary greatly, but we've got some folks here who have made an
> isolated comparison, and they are about to generalize a single result
> into the conversion of an entire system (this one is a biggie; if
> they're wrong, we, the company, could be in deep sneakers).
>
> Anybody got any hard numbers, advice on where to look, or general
> observations?? I really am looking for objective opionions, but I'll
> take what I can get (and I am well aware of the audience I'm asking).
>
> Alan Fields
> VF Jeanswear
> Greensboro, NC
> (336) 332-5631
> Alan_...@vfc.com
Alan,
Let me begin by clearly stating that I have never, ever been a fan of
"relational theory", or is it "model"? It reminds me of communism:
Sounds great in theory, but doesn't work in the real world. Oh, I guess
it would work for small, lightly accessed databases. It also seems to be
a good platform for after-the-fact data warehousing. But as a front line
transactional processor....I don't think so unless you are willing to
pony up buckets of ducats for hardware.
Databases are like mirrors: They reflect reality. They are NOT reality.
Does everything in the world fit into a 2-dimensional row and column
world? Sounds like a fun-house mirror or a whirling disco ball to me.
I also have a theory that if you really want to know the mindset of the
originators of something, look to how they named it: Personal Computer
(read as non-shared or personal), SQL - A QUERY language (what about
updates?).
IDMS is simply too complicated for most people. If you have talented
programmers and DBAs IDMS will kick the snot out anything on the planet.
I see so many companies that are what I call "reluctantly committed"
(read as "stuck with") IDMS only because there is nothing, repeat
NOTHING on the large scale enterprise server platform (read as
mainframe) that can touch it for throughput, recoverability and
Indy-class speed.
You may want to ask your DB/2 cohorts why they are even considering a
re-write this late in the 20th century. They have about 400 days to beat
the Y2K deadline. DB/2 is no picnic either: Lots of procedural code to
go along with the SQL. Good idea? I don't sink-so.
To paraphrase a good freind: A single valued fact in a row should be
dependent upon the key, the whole key and nothing but the key, so help
me Codd.
Jim Moore
Concentrated Logic Corporation
P.S. If there are any Forecross lurkers on the list, please stop sending
my company your IDMS-to-DB/2 junk. Not wanted, not appreciated.
P.S.S. If anyone would like to hear some good anecdotes about "isolated
comparisons" between DB/2 and IDMS, drop me a line. Here's a clue: When
you see a state lottery system, a stock exchange or any other highly
real-time business using an SQL-based, warehouse-oriented relational DB,
then you can believe that the "theory" has been proven.
Linda Campbell
My opinion, for what it's worth...........
Until DB2 Version 5 appeared, DB2 was NOT a transaction processing
DBMS. Under V5, if designed properly and managed by a very good DB2
DBA (probably several), it can compete with IDMS in general. However,
it is a VERY resource intensive DBMS and getting more so all the time.
On the subject of benchmarks, I worked in the Amdahl benchmark center
as a performance analyst for MVS subsystems several years ago. I am
also an experienced IDMS DBA and have some background in DB2 as a DBA
and what I can tell you is that benchmarks in general are useless. I
am sure that vendors (IBM, Hitachi, Amdahl, etc.) will tell you
otherwise, since they really have no other way to measure processor
performance, but you can make a benchmark tell you anything you want
it to. I know because I have.
Since IDMS and DB2 are inherently different, you would need to have a
very large application, OPTIMALLY designed to run in both, execute it
on a level playing field in both environments with the same
transaction mix and volume, with NO AGENDA in mind and compare the
results objectively. I have NEVER seen this done. You can't
extrapolate results from either to measure the other, period. There
are always thresholds after which the numbers fall apart, you don't
know what these are up front and can't know until you run the tests.
Small benchmarks are worse than useless because they can be incredibly
misleading. Also, performance does vary by vendor and generation of
processor because the instruction path lengths change and vary. It
also can change with each release of the DBMS software.
If your clients have an agenda, beware. It is extraordinarily
difficult to convert large, high volume applications from IDMS to DB2
and there aren't many success stories out there. You need solid
experience in both DBMSs and a huge commitment from management that is
sustained over a long period of time, to have a prayer of making it
happen successfully. My experience has been that you can find the
experience (if you're willing to pay for it), but the other two are a
rare commodity, given the very short attention span of upper
management today.
This one is tough and objectivity is hard to find. I like IDMS from a
performance perspective. In DB2, database maintenance is easier to
manage, but performance can be a nightmare if your application folks
don't know their stuff because 1 SQL statement can blow you completely
out of the water, performance wise. In IDMS, the DBA is in control
more so than in DB2. I could go on and on with this, but enough said.
Good luck. Feel free to call.
Linda Campbell
Campbell Consulting, Inc.
(520)282-8489
currently consulting at APL
______________________________ Reply Separator _________________________________
Subject: IDMS vs. DB2
Author: <fie...@VFC.COM> at INTERNET-GATEWAY
Date: 11/24/98 2:26 PM
Leo Gerritsen
A big IDMS site in Holland considered the conversion from IDMS to DB2
several years ago. They were offered a one-to-one conversion. They did a
testconversion of one application. Results were very poor, not only
performance wise. The new application was unmaintainable ! So they decided
for a broader approach. They selected HPS and are now in the process of
doing a total redesign of their applications to be able to implement them
in a environment of their choice.
Regards,
Leo Gerritsen.
JB Moore <conl...@IX.NETCOM.COM> wrote in article
<365B85...@ix.netcom.com>...
> Alan Fields wrote:
> >
> > Has anyone out there done solid benchmarks of IDMS vs. DB2??
> >
> > I know this is a very broad, open-ended question, and your mileage
> > will vary greatly, but we've got some folks here who have made an
> > isolated comparison, and they are about to generalize a single
result
> > into the conversion of an entire system (this one is a biggie; if
> > they're wrong, we, the company, could be in deep sneakers).
> >
> > Anybody got any hard numbers, advice on where to look, or general
> > observations?? I really am looking for objective opionions, but
I'll
> > take what I can get (and I am well aware of the audience I'm
asking).
> >
> > Alan Fields
> > VF Jeanswear
> > Greensboro, NC
> > (336) 332-5631
> > Alan_...@vfc.com
>
KenParis
Univac based equivalent for 4 years). I've also used DB2 for close to 12
years.
I feel comfortable making this statement: "if someone is building a new
application using the most current release of either IDMS or DB2, the DB2
system will perform significantly better." In addition, if size is a
consideration, the DB2 totally overwhelms IDMS - an associate of mine
worked on implementing a DB2 system where one table had 5.3 BILLION rows -
and this is a production system - not a query only database. And, from
what I understand, this is not the largest table in existence.
As far as SQL - it has always supported updating, if you didn't know that
you shouldn't be criticizing the language - if you did, then why make the
point? I have written over a thousand IDMS programs and I believe that
every one is a simpler program in the SQL world. In fact, alot of them
would not even be required as they can be replaced by a single SQL
statement. And if your application doesn't fit into a "two-dimensional"
model, then you have a much better chance to deal with it in DB2, which is
beginning to support more than tabular data, and this support is being
significantly enhanced in version 6 (which allows user defined data
types, user defined functions, extenders to the language to deal with
these, etc.)
I've always liked IDMS - I was on both the board and TAC (Technical
Advisory Committee) of the IDMS Users Association. I still enjoy writing
IDMS programs when there is a need to do so. Regardless, I've seen DB2
pass IDMS by and the distance between the two systems will only grow as
time goes by.
Archcons
I totally disagree with your speed statement, and your 1 line SQL statement!
How many I/O is it going to take to get one record out of that 5 Bil table,
versus an IDMS CALC or INDEXED record?
As far as writing a program for a 1 line SQL statement, I have not seen a 1
line SQL statement in years, unless of course you are just talking about
"SELECT * FROM TABLE" and what about OLQ for producing reports with no actual
code written?
Some SQL statement can be quite complicated, with inner joins, outer joins,
reflexive joins and nested subqueries.
The point is there are many people who work on IDMS and DB2. In defense of Jim,
of course he knew SQL had update capabilities. He was just making a Joke about
Structured QUERY language.
I also worked with IDS on the Univac, converted a few customers to IDMS from
IDS, then I worked on IDMS, Oracle, SYBASE, and DB2. I am of the opinion that
IDMS kills DB2 for flat out transaction processing. In my experience it always
has and probably always will.
IDMS has not had much enhancements since CA has taken over so sure DB2 is
gaining ground on IDMS, but where was DB2 20 years ago when any database in
IDMS could of been defined as stand alone tables with foreign keys to relate
records, IDMS was born with this feature, the only thing missing back then was
the SQL language.
A lot of the 'NEW' technology today such as single schema architecture and data
warehousing techniques have always been available to users of IDMS they just
never knew it was a big deal, it was standard equipment.
I agree the distance between the two systems will grow as time goes by and IDMS
users will go to some other platform, but I also know a company that went to
DB2 and came back to IDMS. I just don't think that DB2 or IDMS is the database
of the future, like IDMS DB2's time will come as well.
William M. Allen, Jr.
ARCH Consulting Associates, LTD.
4539 Hedgemore Drive Suite 160
Charlotte, NC 28210
(704) 676-0175 Office
(704) 676-0176 Fax
ARCH...@AOL.COM E-Mail
HTTP://WWW.ARCHCONS.COM Web Site