× 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: Re: DB2/400 Rerference file
  • From: Bob Larkin <blarkin@xxxxxx>
  • Date: Mon, 28 Sep 1998 17:43:35 -0700

Nina,
Gee, If keeping track of ONE file with a bunch of fields is unmanageable, how 
do you keep track of THOUSANDS of fields in HUNDREDS of files.

I am sure every one of those thousands of fields has TEXT and COLHDG fields 
associated with them,,, right <vbg>

A Field Reference File works best when used as a "Data Dictionary". Most 
successful applications of this use a base field (ie CST# for Customer Number) 
In the file definition for the data file, the files prefix is comcatenated to 
the field name. For example, If the A/R master file's prefix is AR, the Field 
name would be ARCST#, and would reference CST# in the FRF.

Comments could/should also be placed in the FRF detailing the use of the field. 
If there is any question about a fields use, the FRF should answer the 
question, what is it for? Scanning the QDDSSRC members for CST# would show 
where it is used.

The FRF is not there to make work, but to make life easier, and mor consistent.

Bob Larkin


nina jones wrote:

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


begin:          vcard
fn:             Bob Larkin
n:              Larkin;Bob
org:            <A HREF="HTTP://web.wt.net/~blarkin/">Larkin Computer Consulting</A>
adr:            <A HREF="http://web.wt.net/~blarkin/">Bob and Diana's Page</A>;;;Houston;TX;<A HREF="http://web.wt.net/~blarkin/">;United States
email;internet: blarkin@wt.net
title:          Systems Consultant
x-mozilla-cpt:  ;4104
x-mozilla-html: FALSE
version:        2.1
end:            vcard


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.