RE: How to tell if an object is in use?

Paul,

Mark's posted some good info.  But let me answer your question directly...

Assuming your files are externally defined with DDS or SQL, then the 400 file 
is as relational as any other.

The key idea to me is that the definition of the data format in the file is 
external to the programs that use it.  In contrast to a "flat-file" where the 
format is know only to the programs who use the file.  

So if you're still using internally defined files, created with CRTPF  
FILE(FLATFILE) RCDLEN(80), that's as close as the 400 comes to a "flat-file".  
However, as Paul mentioned, all files on the 400 are database files.  The 
FLATFILE above, is actually created as an externally described relation table 
with a single 80 character field.  Since the RDBMS doesn't know what exactly 
will be put into the file, it creates it with a CCSID of 65535.  This is where 
people run into problems when they try to transfer such files to a PC.  The 
65535 CCSID doesn't get translated by default.


HTH,

Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Mark S. Waterbury
> Sent: Sunday, February 13, 2005 1:03 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: How to tell if an object is in use?
> 
> 
> Hi, Paul:
> 
> A major innovation of System./38 and OS/400 was that all 
> "flat files" were
> actually implemented as database files (later called 
> DB2/400). Whether you
> create a file using DDS (PF, LFs) or via SQL, this is still true.
> 
> The big innovation was that a relational database could be 
> viewed as if it
> is a "flat file" so that existing programming languages 
> (COBOL, RPG, etc.)
> could access these database files using "traditional" record 
> I/O techniques,
> thus allowing programmers to be productive right away, 
> without having to
> learn the then-new "relational database" techniques and/or 
> using embedded
> SQL.
> 
> Here is the fundamental difference between a "true" flat-file and a
> "relational" database:
> 
> In a flat file, you have fields in a record where each field 
> is "bound" to a
> starting position and a length within the record; this 
> "binding" occurs at
> "compile-time" (e.g. when the file is created, and when your 
> RPG or COBOL
> program is "compiled" it contains a "mapping" -a data 
> structure that maps
> the fields in the record in the program's record buffer.
> 
> In a true relational database, there is no concept of records 
> with fields in
> any given starting position or ordering of fields in a 
> record. In SQL, you
> have only columns and rows in a table (or view). Thus, the 
> only "binding" is
> between the name of the column (fieldname) and the name of 
> the table (file
> name).  In other words, you never have any hard-coded offsets 
> to positions
> in a record with SQL;  you ask for columns by name, and the 
> SQL database
> takes care of getting them for you and returning them into your host
> variables.
> 
> This also means that you no longer have the concept of 
> "level-checks" at the
> record level; instead, SQL tries to coerce or implicitly 
> convert the data
> type of the column in the table to the data type of the 
> corresponding host
> variable, on a column-by-column basis, so in this way, SQL tables are
> "softer" than "flat files"... if you change the size of a 
> field in a record,
> you have to recompile every program that uses it because each 
> program has
> that hard-coded data structure to map the offsets of each field in the
> record; with relational databases, the only "binding" between 
> a program and
> a database is via the table name (or view name) and column 
> name(s) used by
> the program.
> 
> So, in practice, you can often change the type or length of 
> columns without
> necessarily having to recompile every program that uses that table. Of
> course, you could get an error on a given column if the 
> actual data in that
> column will no longer "fit" into a host variable.  So, the 
> errors that are
> conceptually equivalent to a "level check" are at the column 
> (field) level.
> 
> Here is my quick reference to map traditional data processing 
> (flat-file)
> terminology to relational database terminology:
> 
>     traditional            relational
>     =======           ======
>     field                    column
>     record                 row
>     file                      table
>         PF                      table
>         LF                      view (with index)
>     records in a file    rows in a table
>     fields in a record  columns in a row of a table
> 
> Also, here is a similar table mapping "relational" to 
> "object-oriented"
> terminology:
> 
>     relational                        object-oriented
>     ======                        ==========
>     table                              class (or object type)
>     column of a table            attribute of an object
>     row in a table                 instance of an object class
>     rows in a table                multiple instances of a class
> 
> The "big idea" here is that you can use the same principles 
> and techniques
> that lead to good database design (normalization, E/R 
> modeling, etc.) to
> design good object class librariees and hierarchies.
> 
> Hope that helps... ;-)
> 
> Mark S. Waterbury
> 
> ----- Original Message -----
> > From: "PaulMmn" <PaulMmn@xxxxxxxxxxxxx>
> > To: "Dave Odom" <Dave.Odom@xxxxxxxxxxxx>
> > Cc: <midrange-l@xxxxxxxxxxxx>
> > Sent: Saturday, February 12, 2005 8:33 PM
> > Subject: RE: How to tell if an object is in use?
> >
> 
> > Dave--
> >
> > What's the difference betwen the 'relational' data base I've always
> > assumed we got as part of OS/400 and 'real relational?'  Is 
> there any
> > difference between a table in DB2 and a 'flat file?'
> >
> > --Paul E Musselman
> > PaulMmn@xxxxxxxxxxxxxxxxxxxx
> >
> >
> > >Dave wrote (in part):
> > >
> > >I was going to suggest the person re-architect their apps such that
> > >they use DB2 tables and SQL
> > >and get away from flat files as that's the way things are 
> going anyway.
> > --
> > This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> >
> 
> -- 
> This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>