Let me throw out a design strategy for discussion. (It's not an original
idea, by the way; it goes back to S/38 days.)

In the source of all logical files, do not simply define the record
format but explicitly code the fields required, even if all fields are
required. Disallow direct use of physical files by programs; some people
think this is good practice in any case.

Now, if you need to add a field to a physical file, and this field will
only be used in a few places, you can create a new logical containing
that field and use that logical in those places. The new field will not
appear in the existing logicals so the member format levels will not
change, so no need ever to use LVLCHK(*NO). The old programs will not
see the new field and it will not matter, even if the field is added
somewhere other than the end of the record.

The extra workload of having to specify the logical file fields is not
that great, and it supports the idea that logical files are working
views of the database while the physicals are it's implementation. It
also encourages designers to think carefully about what needs to be in
each logical and not include fields that are not required.

Comments? Objections? What do you think?

Dave Kahn - TCO, Tengiz, Kazakstan

e-mail:  kahn@tengizchevroil.com    (until September 30th)
         dkahn@cix.compulink.co.uk  (from  October 1st)

| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...


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

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