× 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[3]: CHGPF Question -Reply
  • From: Buck Calabro <mcalabro@xxxxxxxxxxxx>
  • Date: Fri, 19 Sep 1997 14:43:22 -0400

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

<snip>
Oh, I completely understand that, and have no quarrel
with it.  It's a great idea, and a wonderful addition to
our toolkit on the platform...


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

Recompiling will do the trick all right, but I
would take issue with the concept that
the cost of recompiling all the RPG 
programs in 6 libraries to be "not that great?"

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

<grin> This could be fun...  OK.  I can see that you're
thinking about, say, adding ZIP+4 to a customer master
file.  You need to change a bunch of your existing
programs to print/display the new ZIP+4.  But 
consider a change like adding a SIC (Standard 
Industrial Classification) code to your customer
master file.  This code is an industry standard that
describes the type of business your customer is.
(Restaurant, manufacturer, etc.)

If your change involves a new data mining application;
one that involves new programs, displays, etc.  then
the only changes to the existing programs are a few
listings/inquiries and maintenance.

The SIC code is *RELATED* to the customer master record
because each customer has ONE SIC code, so it really
belongs in the customer master record.

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

It's not the programs that are LVLCHK(*NO), it's the file.
If our intrepid programmer decides to put new fields in
the middle of the record layout, all she needs to do is
compile it *YES (or CHGPF it) and the programs will
4131 just like always...

For the record: I would rather that I didn't use LVLCHK(*NO)
but once people have found a shortcut, it's difficult to convince
them to take the long, quality road instead of the short, bumpy
one.

Buck Calabro
Commsoft

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.