Re: DB2/400 Rerference file -- MIDRANGE-L

Hello Booth and Nina,

(Waiting for the yawns ...)

Your example situations usually result from a poorly designed FRF.  Most sites 
I have seen have no idea how to 
use one properly.  I will agree it gets difficult when mixing assorted packages 
but it is straight-forward for 
in-house applications and if more of the packaged software houses did things 
properly life would be much 
easier.

The FRF defines base types and business entities.  Base types are things that 
the DB doesn't provide direct 
suport for -- like dates before L data types.  Entities are things like 
customer number, address, balance, 
etc.  They should be defined in alphabetical order in two groups; base types 
first, then entities.

A single FRF should be used where possible until the DB 8000 column limit is 
reached.  If your application has 
more than 8000 discrete entities/types then you will need two or more FRFs.

Where people screw up is by allocating sections to applications or worse, 
individual files.  This almost 
always results in duplicate definitions and difficult maintenance.  The moment 
you see something like the 
following in a FRF you know the designer hasn't a clue:

A* CUSTOMER MASTER
A          CSTNBR        7 0
A          CSTNAM       30
A* PARTS MASTER
A          ITMNBR       11 0
A          ITMDSC       50
A* ORDER HEADER
A          ORDNBR        7 0  
A***       CSTNBR        7 0
A          ORDDAT        6 0
A          SHPDAT        6 0
A* ORDER DETAIL
A****      ORDNBR        7 0
A          ORDLIN        3 0
A****      ITMNBR       11 0

Notice the duplication of field names to allow each file to be described?  
Notice that the duplicates are 
commented out to satisfy the DDS compiler?  Notice the SHPDAT and ORDDAT fields 
are individually defined?  It 
is not necessary to group the fields by file in the FRF on an AS/400 because I 
can always ask the DB what 
fields a particular file contains.

This FRF should look more like the following:

A* Base data types
A          DATE          6 0
A          DESC         50
A          NAME         30
A* Business entities
A          CSTNBR        7 0
A          CSTNAM   R          REFFLD(NAME *SRC)
A          ITMDSC   R          REFFLD(DESC *SRC)
A          ITMNBR       11 0
A          ORDDAT   R          REFFLD(DATE *SRC)
A          ORDLIN        3 0
A          ORDNBR        7 0
A          SHPDAT   R          REFFLD(DATE *SRC)

Of course, additional keywords should be used to define COLHDG, TEXT, ALIAS, 
and validity checking (if you 
like DDS validity checking).

There is only one other concern and that is specific to RPG III.  While I 
subscribe to the theory that each DB 
entity should have only one identifier regardless of which file it appears in, 
RPG III provides no way to 
qualify the entity.  Due to RPG having only one reference to a particular name 
data isolation is lost.  RPG IV 
allows the PREFIX keyword to overcome this but RPG III needs to have it 
corrected in the DB by applying a file 
prefix to each of the entities.  So PF examples using the above FRF may look 
like:

A* Customer Master
A                                     REF(FRF)
A         R CSTMSTR
A           CMCNBR                    REFFLD(CSTNBR)

A* Order Header
A         R ORDHDRR
A                                     REF(FRF)
A           OHONBR                    REFFLD(ORDNBR)
A           OHCNBR                    REFFLD(CSTNBR)

A* Order Detail
A         R ORDDTLR
A                                     REF(FRF)
A           ODONBR                    REFFLD(ORDNBR)

It should be apparent from these examples that a properly designed FRF can be 
an asset but it requires 
discipline on the part of the designer and programmers to get it right and keep 
it right.

Regards,
Simon Coulter.

//----------------------------------------------------------
// FlyByNight Software         AS/400 Technical Specialists
// Phone: +61 3 9419 0175      Mobile: +61 0411 091 400
// Fax:   +61 3 9419 0175      E-mail: shc@flybynight.com.au
// 
// Windoze should not be open at Warp speed.
//--- forwarded letter -------------------------------------------------------
> X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.50 b48 
> Date: Sun, 27 Sep 98 11:46:01 -0400
> From: boothm@ibm.net
> To: MIDRANGE-L@midrange.com
> Reply-To: MIDRANGE-L@midrange.com
> Subject: Re: DB2/400 Rerference file

> 
> I agreed with this up until my first exposures to this on a fairly large site 
>with many applications, 
assorted third-party packages, and sites around two continents.  Their two 
field reference files had become a 
mish-mash of stuff, usually every new application had a new section with all of 
it's fields including date 
fields even though the fields were typical of other fields already defined.  At 
first I felt the site was 
unusual, with unusual solutions.  But since then, on other sites, it appears to 
me that the idea of reference 
file is good in theory, but just not scalable to large installations.  Of 
course I have seen very few 
installations, so perhaps other sites have other solutions; perhaps the scaling 
issue is normally resolved in 
ways not clear to me yet.
> 
> 
> In <199809280352.XAA000.69@unicorn.flybynight.com.au>, on 09/27/98 
>    at 11:49 PM, "Simon Coulter" <shc@flybynight.com.au> said:
> 
> >Hello Booth,
> 
> >RPG functions do not obviate the need for a field reference file but they
> >do augment one.  It is simply  better to have all the field definitions
> >in one place.  All files (PF, LF, DSPF, PRTF, etc) should reference  the
> >FRF and never directly reference the database.
> 
> >Regards,
> >Simon Coulter.
> 
> -- 
> -----------------------------------------------------------
> boothm@ibm.net
> Booth Martin
> -----------------------------------------------------------

//--- forwarded letter -------------------------------------------------------
>we started out using them too, until it became unmanagable.  so we quit using 
>them, except for the limited 
>ones we started with.
>
>i suppose it's ok if your applications are small, but if you have thousands of 
>fields, over several hundred 
>files,  it is a lot to keep up with.  at least for my simple brain...
>
>nj

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