× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Use of Reference Files (Was Re: Reference files)
  • From: Paul Tuohy <tuohyp@xxxxxxxxxxxxx>
  • Date: Fri, 04 Feb 2000 10:18:19 +0000

Hi Dan,

Not wanting to join in a thread war, but.......... ;-).

For the most part, I agree completely with what you say about FRFs. The main
problem is that they are maintained through DDS/SEU and are just a source 
member.
(And don't get me started on source being kept im members!). Since a FRF is a
Data Dictionary for a DB2/400, the problem is with the implementation of the 
data
dictionary, not with the data dictionary itself.

IMHO, the benefit of a data dictionary far outweighs the poor implementation.

I have seen Home Written applications to "maintain" a field reference file (not
all that difficult to write). If I am not mistaken, one is included with ADMS 
and
I am sure many other Change Management Systems (the $$$ you refered to).

I have snipped and commented on just a few of your points.

"Bale, Dan" wrote:

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

Makes you want to scream!

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

Actually makes you scream!

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

Unless you use some form of an externally described data structure and use LIKE
to refer to the fields. But, like you say - no GOOD way.

> 7) As in all things worth doing well, .............<SNIP>

Actually, there is a place for REFFLD(*SRC). Think how easy something like the 6
to 8 data change would have been if you had something like

      A           DATE                 6 0         TEXT('Generic Date')

        ....... (skip 100 source lines)
     A            ORDDAT       R               REFFLD( DATE  *SRC )
     A                                                     TEXT('Order Date')
        ....... (skip 100 source lines)
     A            SHPDAT        R               REFFLD( DATE  *SRC )
     A                                                     TEXT('Shipment Date')

Regards

Paul Tuohy


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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.