RE: SQL vs. traditional I/O?

That took me a minute.  Basically one field for every 'element' of every
column.  And each row in this fref would be a column in another
table.  Sounds a lot like QSYS2/SYSCOLUMNS.

The biggest time I see FREF's getting full is when they do something like
R FREFR
  IPROD         15          TEXT('Item Number')
                            COLHDG('Item Number')
  SLPROD        15          TEXT('Item')
                            COLHDG('Item')
...
Not that this is any better
R FREFR
  IPROD         15          TEXT('Item Number')
                            COLHDG('Item Number')
  SLPROD           R        REFFLD(IPROD)
...
Instead of just having IPROD in there and having all files call it
IPROD.  And then your programs can either qualify, or prefix, the file if
they just have to.  (Like SL is just so much more meaningful than I.)

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com


|-----------------------------+-------------------------------------------|
|   "Dan Bale"                |                                           |
|   <dbale@xxxxxxxxxxxxx>     |                                           |
|   Sent by:                  |                                         To|
|   midrange-l-bounces@midrang|                                    "Midran|
|   e.com                     |                                    ge     |
|                             |                                    Systems|
|   07/23/2004 01:37 PM       |                                    Technic|
|                             |                                    al     |
|         Please respond to   |                                    Discuss|
|         Midrange Systems    |                                    ion"   |
|       Technical Discussion  |                                    <midran|
|      <midrange-l@xxxxxxxxxxx|                                    ge-l@mi|
|                m>           |                                    drange.|
|                             |                                    com>   |
|                             |                                         cc|
|                             |                                           |
|                             |                                    Subject|
|                             |                                    RE: SQL|
|                             |                                    vs.    |
|                             |                                    traditi|
|                             |                                    onal   |
|                             |                                    I/O?   |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|-----------------------------+-------------------------------------------|






> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx / Carel Teijgeler
> Sent: Friday, July 23, 2004 1:20 PM
>
> Jim,
>
> It depends on what Os release you are. With V5R2 SQL has been
> enhanced to refer to columns (fields) in other tables when
> creating tables (files). I still think that that enhancement is
> more cludgy and cumbersome than the traditional field reference file.
>
> I wish there was a repository of fields (columns) somewhere to
> use for reference, both in SQL and DDS (file SYSCOLUMNS (an LF
> IIRC) perhaps?). Was IDDU not developped for that purpose?
>
> Regards,
> Carel Teijgeler.

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.

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.

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!

db

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