Legacy code (formerly, A revolutionary OS/Programming Idea)

Tom Novelli tom@tunes.org
Sat Oct 11 11:46:02 2003


Lynn Maxson writes:
> I don't know why your IBMer chose to emulate an ascii
> terminal or why he executed on a host system running under
> VM.  He probably even used a BOM based on a relational
> database using SQL instead of the original hierarchical one
> using DL/I.  I will tell you that there is an order of magnitude
> difference or more in terms of performance.
>
> I don't even know why he allocated file space the way he did
> or how he could possibly have run out of space.  The
> underlying file system is VSAM and it just doesn't happen...or
> rather it doesn't need to happen.

So which was faster, relational or hierarchical?

This system was written in COBOL.. I thought they were kidding about it's
1950's origins, but maybe not.  In any case, it was insane!  Everyone
involved clearly thought so!  It wasn't even 100% consistent.  Most likely
it was still in use because higher-up bureaucrats were afraid (justifiably?)
that a replacement would cost even more to use and maintain.

I guess that's the sad state of all manufacturing in the information age..
They spend more money collecting and analyzing *bogus* information than they
spend on actual manufacturing.  Why do they always insist on entering
everything, even work-in-progress, into an inflexible central database?
It's slow, tedious, often inadequate, and it's a single point of failure!
What happens when an enterprise database goes down, or becomes inconsistent?
And don't tell me that doesn't happen, because I've seen it happen!  They'd
be better off handling each project individually, on an ad-hoc basis.  If
they absolutely must have a central database, then for the sake of
consistency they should keep it to the bare minimum and avoid relying upon
it.

You have to weigh costs and benefits.  The perfectionist approach just isn't
worth it.

I know you're working on a big project :)  I just wanted to make a point.
These mailing lists are a big waste of time, so let's wrap this up...