Re: CHGPF Question

[DAsmussen@xxxxxxx]

Dave,

In a message dated 97-09-20 04:36:01 EDT, you write:

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

Not sure why, but I'll bite.

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

This is how IBM defines field-level security, although other platforms
provide more economical means to do so.  How would you disallow physical file
access by a program using embedded SQL?

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

Fine, but why create a new logical (and it's inherent overhead) when you
already have one in place to perform the desired function?  NOBODY has
answered the question -- "What is the BIG DEAL about re-compiling all
programs affected by a file change?"

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

True.

Regards,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@AOL.COM

"We are what we repeatedly do.  Excellence, then, is not an act, but a
habit." -- Aristotle
+---
| 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
+---