Data base repository (Was: RE: SQL vs. traditional I/O?)

Dan,

comments in line.

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR  ***********

On 23-7-04 at 14:37 Dan Bale wrote:

>> -----Original Message-----

>I've never been a fan of the AS/400's implementation of FRFs.
>
> * You make a change to a field, or add one, in the FRF source, compile that, 
> then compile the database file.
>
> * Try finding an appropriate field to reference in an FRF. 
>
> * Limits on record length mean that FRF's usually take more than one file to 
> accomplish.
>
>It just seems real kludgy to use.

It depends. How many fields that should contain date or price values do you 
have in your database? I would only define one field each, DATE and PRICE, in 
the FRF and in the DDS source for each file I would reference to those fields 
in the FRF, not define derived fields in the FRF itself. I think it is more a 
design matter. (see for instance C. Massoglia, Database DDS, midrange Computing 
publication 1994).

>I would like to see FRFs utilized where a data file for storing FRF info is 
>defined, i.e.:
>   A          R FRF@
>   A            FRFFIELD      10
>   A            FRFLENGTH      5  0
>   A            FRFDTATYPE     1
>   A            FRFDECPOS      2  0
>   A            FRFTEXT       50
>   A            FRFCOLUMN1    20
>   A            FRFCOLUMN2    20
>   A            FRFCOLUMN3    20
>   A            FRFEDITCDE     1
>   A            FRFEDITWRD    50
>   A            FRFDATEFMT     5
>   A            FRFTIMEFMT     5
>   A            FRFDATACTG     2
>   A            FRFLONGDES  2000
>
>An application would be used to design data files and would use this "FRF"
>file (it would NOT be SEU!).  Probably WDSCi / Code/400 does something
>along these lines, although probably still is limited to the traditional FDF. 
>The "design" application would then generate the required DDS or DDL, as
>requested.  There's other stuff as well, I'm sure, that could be added to
>that format, but it gives the gist of what I'm talking about.

That is getting to a repository I was talking about. I would like to define 
things once (especially database fields), and reference them unlimetedly (to 
adapt a similar phrase). The RDBM system should supply this functionality. The 
AS/400 is a data base machine, so a lot of data is already available.

I base my view on a repository with a demo version of S-Designer (about 1995, 
running on Windows 3.1). It was a data base design tool (still is under a 
different name) with a conceptual model and an application model cnnot remember 
the propriate name). In this programme there was a repository, in which you can 
define base fields. When adding fields into a table you could select such a 
base field from the repository to refer to. ( I hope I put that clearly). (Then 
you could generate SQL scripts for many different and popular RDBMs, like DB2, 
Oracle, Sybase; it could even generate DDS source.)

>IDDU?  With all due respect Carel, if I wanted to torture myself, I'd rather
>listen to the Bee Gees.  It's been so long that I checked it out after your
>post, created three field defs, a record format def, and a file def, but
>darned if I can figger out how to create the file object!  IDDU is so
>obscure after all these years because, IMO, it was such a kludge to begin
>with.  And it never got better.  Might as well stick with SEU DDS specs!

I have not done anything in IDDU since my RPG training in 1990. I did not even 
know it was still on the machine (Why? Who is using it?). But what I can 
remember (vaguely), it was tedious, indeed. I was more referring to the assumed 
concept of IDDU, I thought it had (if it had any but torturing DB designers).