RE: new as400.ibm.com site -- MIDRANGE-L

David:

I have avoided posting on this topic but, what the heck.

Thompson's original Unix used a byte-oriented file system.  You could read a
byte at a time - forward or backward.  For example, one of my old OS
textbooks says, "A file in UNIX is a sequence of bytes.  Different programs
expect various levels of structure, but the kernel does not impose a
structure on files."  It goes on to explain that a text file is a string of
bytes where the lines are separated by newline characters and that a
directory is a particular kind of file but that these are conventions.  The
kernel knows getc and putc.

Database products such as Oracle support either the native file system or
"raw" mode - that moniker is probably wrong but it is roughly correct.  If
the native file system is used, a mount point is created containing a
directory structure.  Then one or more large files are created in the
directory.  The database creates the structures that it wants within the big
file(s) then exposes programs and APIs that can modify the inside of the big
file as documented in their manuals.  If "raw" is used, the database is
given a set of physical drives and controllers.  The database application
provides all management for those drives including surface formatting,
operation scheduling, backup, and restore.  The programs and APIs operate on
the contents of those disk drives using database resources.

In my professional opinion, if a person objects to flat files then I can
legitimately object to byte files and we are even.  Even the raw version is
limited by the sector formats allowed by the drive manufacturer - usually
between 512 bytes and 750 bytes.  Arguments that a database product should
be owned and operated by the hardware vendor have the same credibility as
arguments that the database product should NOT be owned and operated by the
hardware vendor.  These arguments are religious, created by marketers, not
substantive.

Yesterday, Eric said that sizzle matters more than steak unless the techies
make purchasing decisions.  It might be true but I don't want to live like
that.  I want to use a superior product.  Oracle, DB2/400, IMS, and DB2 for
MVS are superior products.  Like most people, I happen to understand one of
those better than the others but that has not made me a bigot or a zealot.

Properly set up, Oracle is just as reliable and fast as DB2.  If we consider
the UDB version of DB2 that runs on MVS, AIX, NT, and other operating
systems, both products arose from the same heritage - the System R project
that IBM was running at the Santa Teresa Lab in the San Francisco area
during the 70s and 80s.  I was told that Oracle was created by some
disgruntled ex-IBM people - does anyone know if this is true?  The AS/400
version arose from different roots and shares only the external interface
with the UDB version.  We can thank the leadership of Bill Davidson and
Larry Youngren for that implementation - there may have been other
more-senior guidance but, aside from Dick Bains and Glen Henry, I don't know
those names.

If the AS/400 database product is superior to another one on my list (and I
do not say that it is or is not), it is because DB2/400 runs on only one
platform and is therefore easier to test.  As far as I can tell, that is the
most important objective difference between them.  Other differences exist
but, in my opinion, they are less important or subject to change with
funding or time.

This reply got out of hand, sorry.

Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-|-----Original Message-----
-|From: owner-midrange-l@midrange.com
-|[mailto:owner-midrange-l@midrange.com]On Behalf Of Shaw, David
-|Sent: Wednesday, October 04, 2000 7:38 AM
-|To: 'MIDRANGE-L@midrange.com'
-|Subject: RE: new as400.ibm.com site
-|
-|
-|Al,
-|
-|Those EDI files were also flat files, NOT relational database
-|tables.  What
-|they're talking about is the way that the data base is
-|implemented.  On the
-|AS/400, a database table is implemented as a physical file object.  A
-|physical file object is made up of several pieces, one of which is a data
-|space which is nothing more than a fixed record length flat file.  Modern
-|Unix and Windows server RDB's tend to implement an entire database as a
-|single big file, or in some cases a fixed number of files, in the
-|particular
-|operating system's file system.  Remember that these OS's have no
-|concept of
-|"objects", everything is a file, whether it's an executable
-|program, a data
-|base, a driver, or the OS kernel itself.  Database software is a separate
-|product that runs over the top of the OS - the OS doesn't understand the
-|concepts involved.  Database tables are internal constructs within these
-|database files, and the implementation is usually hidden and often more
-|subject to major change than what we're used to.  Consequently, the Unix
-|weenies have a tendency to sneer at what they see as an old-fashioned
-|implementation ("It's cruder than dBase II!"), when in fact it's a very
-|logical and powerful implementation for an object-based operating system
-|with a fully integrated database.
-|
-|Dave Shaw
-|Spartan International, Inc.
-|Spartanburg, SC
-|
-|-----Original Message-----
-|From: MacWheel99@aol.com [mailto:MacWheel99@aol.com]
-|
-|<snip>
-|
-|>  I think another reason that they want to "rebrand" it is
-|because a lot of
-|>  non-400 gurus know of the AS/400, and don't think very highly of it.
-|Only
-|>  because of a lack of understanding.  But, I can just see it on the
-|>  comp.sys.unix/hp/nt newsgroups now..
-|>
-|>  Post: "Hey!  did you see the new iSeries from IBM!  Looks killer!"
-|>  Reply: "Man, that's just the old AS/400.
-|>  Why would I want a machine that uses flat files for a DB?"
-|
-|What are the popular alternatives to flat files & can the AS/400
-|DB handle
-|them?
-|
-|I like flat files, but I have also worked with some EDI files ...
-|variable
-|length in which various delimiters define breaks between fields & there is
-|an
-|infinity of both record types and field types, in which the codes in the
-|front of a record tell us which family of rules applies to this
-|record, and
-|codes in the front of a field tell us the functionality of the
-|field - data
-|type, etc. and we do not know until we read a record what kind of
-|record it
-|is going to be.  I had EDI software that converted this to IBM
-|flat files so
-|
-|I could deal with it using my experience, but still, programs processing
-|this
-|stuff had to use humongous case statements based on the
-|definitional codes
-|"What was that record / field we just read?"  Forget about accessing the
-|records in anything other than sequential order.
-|
-|I had always thought that this EDI design was totally alien to Relational
-|Data Base theory ... is RDB passe' & some new theory replaced it?
-| Or is my
-|exposure to these EDI files, not what people referring to by
-|non-flat files?
-|
-|<snip>
-|+---
-|| 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
+---