|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.