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