Re[2]: CHGPF Question -Reply -- MIDRANGE-L

>>> Buck Calabro <mcalabro@commsoft.net>
09/19/97 09:12am >>>
        Why?  LVLCHK(*NO) is just another
attribute of a file, like SIZE or 
MAXMBRS...  If I create a file with 10
fields, write a hundred programs, then
add an eleventh field to the end, why
should I be forced to re-compile all 
one hundred programs, when I already KNOW
that none of them uses the
new field?  
I have never given this question much
thought before; seeing these
quite strong responses against the practise
gives me pause...

                ----------

Just to throw my $.02 in...

LVLCHK is a useful system safeguard warning
a programmer that "Hey, the file I knew
about when I was born is gone...some
imposter is in it's place!"  One can,
obviously, circumvent the built in
safeguards, but the very thought is too
similar to stuff that causes premature
baldness on other systems ("Gee, think of
the neat things I could do if I could
manipulate system pointers directly") and
other stuff.  Yeah it's a cool work around,
but I'll take the extra protection, thank
you and the cost is not that great.  A dumb
little CL w/DSPOBJD and a couple of IFs
conditioned on object type will recompile
all pgms in any library unattended whilst
you sleep, undisturbed by the thought of
dreaded CPF4131 errors.

Further, from a completely purist point of
view, if the field you're adding is so
completely unrelated to the original 10 in
the file that all 100 legacy pgms will
*NEVER look at it, why would you add it to
that file in the first place?  After all,
conceptually, a file is nothing more than a
series of *RELATED* fields.

Finally, since you touched off the recent
legacy code thread, I know you're really
concerned about other people supporting
your code at some time in the future.  The
next guy to come along may not be so
careful and stick a field any old place in
your file (for a perfectly good reason too
- I saw somebody post a note recently about
query tools & putting related fields
together for usability.)  Suddenly, all 100
of your LVLCHK(*NO) pgms are either A)
blowing up immediately on a lot of DecDta
errors (unless, of course, one didn't feel
like seeing those problems either and
compiled IGNDECERR(*YES), turning off yet
another system safeguard) or B) corrupting
your database by putting LAST-NAME in the
ZIP-CODE field. Neither situation is a very
pretty sight.

JMHO

Scott Cornell
Mercy Information Systems
+---
| 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
+---