RE: Reference files

Well, you just _had_ to do it, didn't you?  ;-)

You have just started a thread war on Reference files.  Or maybe _I_ will.
;-)

I will try (hah!) to be neutral by saying first off that there are pros and
cons to using File Reference Files (FRF).  There, that's the end of my
neutrality!

FRFs have no data.  When I create them, I specify MBR(*NONE).  They are used
strictly for defining fields used in your database files and, possibly,
printer & display files.  Most likely, you have done no harm by removing the
FRF function from your database files.  You'll run into trouble if you don't
match the definitions used in the FRF with those in the database files where
you've replaced the FRF reference.  The S/36 had no FRF concept; everything
was program-described on the S/36 (shudder, shudder).  Had you asked about
this before you replaced the FRF function, I would have recommended that you
leave it as is.  It must have been a LOT of work to do that.  After you
modified all the database file source to remove the FRF references, did you
recompile all of the files?  And verified that the field definitions in the
file object did not change?  If you changed all of the source, but did not
recompile the files, you or someone else might get an ugly surprise two
years down the road when they go to change a file's definition, recompile
it, and discover after programs bomb and data turns up missing that a field
that should have been 10 alpha is now 8 alpha, and everyone will scratch
their heads and say, "how the HECK did that happen?"  That would be a good
time to hide.  ;-)

Anyway... the PROs as I see them:  
Your field definitions are consistent across the "set" of files that you
define using a given FRF.  You have an 8-digit customer number?  In an FRF,
you'd define something like:
     A            CUSTOMER#      8S 0       TEXT('Customer Number')
     A                                      COLHDG('Customer' 'Number')
     A                                      EDTWRD('0   -    ')

In a given database file, such as Customer Master, Customer Ship-To, etc.,
you would define the customer number like:
     A            CMCUS#    R               REFFLD( CUSTOMER#  OEFRF )

The field CMCUS# assumes the attributes of CUSTOMER#.  And so does every
other field you define with the given REFFLD keyword.

Say you've got 30 files out there with this definition.  You're guaranteed
that the customer number will be 8.0 with the same text, column heading, and
edit word.  Also say that, two years down the road, you have to expand the
customer number to 10 digits, zero decimal.  You change the CUSTOMER#
definition in the OEFRF file, compile that, then compile every file that
uses the REFFLD for CUSTOMER#.  No need to edit 30 source file members.

You might think, given that explanation, that I'm PRO on FRFs.  I am all for
the concept of FRFs.  However, IMNSHO, the IBM-supplied AS/400
implementation of this concept is POOR, POOR, POOR.  Herewith are the CONs
as I see them.

1) You open a file's source member to see how it is defined.  All you see
are statements like:
     A            CMCUS#    R               REFFLD( CUSTOMER#  OEFRF )
     A            CMADL1    R               REFFLD( CUSTADDRLN OEFRF ) 
     A            CMADL2    R               REFFLD( CUSTADDRLN OEFRF ) 
     A            CMCITY    R               REFFLD( CUSTCITY   OEFRF ) 
     A            CMZIP     R               REFFLD( USZIP      OEFRF ) 
     A  .... etc. ....

Of course, you know how CUSTOMER# is defined, but what about all of the
hundreds or even thousands of other FRF fields?  O.K., so then you hit F15
and browse the FRF source and scan for the FRF field name.  After you've
done that ten times for file that's got 100 fields defined in it, it gets
old real quick.

2) The AS/400 has a limit on the length of a record format, about 32760
bytes.  I've seen various systems that have multiple FRFs because of this
limit.  JD Edwards uses 26 FRFs, one for each letter of the alphabet.  This
only multiplies the frustration generated by CON #1.

3) Say you're creating a new database file.  You are required to use an FRF.
You want to add a new field that is defined as, let's say, a "Customer
Code".  Does the FRF have a field already defined for this?  How do you find
out?  Have fun searching for it, especially if you have a large FRF or
multiple FRFs!  Do this as many times as you have new fields to add.

4) (Number 3, continued...) Say you've determined, after searching for ten
minutes, that there is no "Customer Code" definition in the FRF.  Open up
the FRF source for edit (preferably in another display session), and add the
definition for "Customer Code".  Then go back to the database file's source
and add the REFFLD for that field.  Oh, don't forget to compile the FRF
before you compile the database file.

5) Even if you have gone through the trouble of mastering FRF concepts, you
still have to have a mechanism by which you can reliably identify all of the
files that are affected by any change made to an existing FRF definition.
Taking the CUSTOMER# example, we identified 30 files that use it in the
REFFLD keyword.  How did you determine that?  Are you _certain_ that you
identified all the database files that use it?  There is enough information
in the system to figure all this out, but you've got a lot of programming to
do to get at it in a useful way.  Or you can spend $$$$ on a third party
package to do this for you.

6) There is no good way to extend the FRF function to RPG program-described
fields.  If you take the concept of FRF to its full extent, you really
shouldn't be hard-coding the attributes of program-described fields.

7) As in all things worth doing well, there are infinite ways to complicate
FRFs.  I have seen them.  Usually when I do, I am heard to be "looking for
someone's head".  I have seen FRF fields with another reference.  It is
possible for a field reference to have multiple references.  I.e., the
following definition is in the Customer Master:
     A            CMSTAT    R               REFFLD( CMSTAT     OEFRF )

(BTW, sometimes you'll see this, where the field being defined has the same
name as the field being referenced; the FRF, most likely multiple FRFs,
define each and every field used in all the database files individually.
Another case for looking for someone's head.)

Anyway, the example continued, the FRF for the CMSTAT field:
     A            STATUS2        2A         TEXT('2-byte generic status
code')
        ....... (skip 100 source lines)
     A            REFSTATUS R               REFFLD( STATUS2    *SRC )
        ....... (skip 100 source lines)
     A            ABCSTATUS R               REFFLD( REFSTATUS  *SRC )
        ....... (skip 100 source lines) 
     A            CMSTAT    R               REFFLD( ABCSTATUS  *SRC )

Can you see what's going on here?  CMSTAT refers all the way back to STATUS2
to get its attributes.  And, yes, I'm not making this up, I have really seen
this.

Personally, I prefer to stay away from FRFs.  That said, the decision to do
so is rarely mine to make; either the shops I'm contracting in have them, or
they don't.  If I were starting development of a system from scratch, and
had the proper tools to effectively implement the FRF concept, I'd probably
do it.  Until pigs fly, though...

I see that there has been one post to your FRF question.  Maybe this isn't
as lively a subject as I thought...

- Dan Bale


-----Original Message-----
From: Sherry McMahon [mailto:smcm@frontiernet.net]
Sent: Monday, January 03, 2000 6:28 AM
To: RPG400-L@midrange.com
Subject: Reference files


Hello everyone,

Thank you for the help with the OMIT option in the SAVLIB command.  It
helped me greatly and prompted me to order the 'CL Programming for the IBM'
book.

I have another situation I've been wondering about and haven't felt
comfortable with the answers I've gotten when I've asked programmers I work
with.  I've rewritten Sys36 programs in RPGIV and converted flat files to
400 physical files.  (Once again Scott, thank you thank you thank you for
your help) As I was doing this I saw other files, already AS/400 PF, had
reference files.  Everything I could read about reference files told me they
were just PFs.  I didn't understand why there were reference files then
physical files then logical files.  In my conversions (Y2K) I did away with
the reference files and made the system consistent with just having the data
in the physical files.  Originally some of the data was in physical files
and some in the reference files.   All anyone could tell me was this was the
SYS36 way and the people before me stayed with what they knew.  The fact
that I don't understand why these files were necessary makes me afraid I may
have done some harm by doing away with the reference files, although
everything is working fine.  As usual the books and online references aren't
clear to me.  Could someone give me some insight into this?

Thank you,
Sherry McMahon
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---