At 12:54 AM 9/22/97 -0400, wrote:
>In a message dated 97-09-20 10:24:39 EDT, you write:
>> Users needed a field added to the item master to track an atrribute of that
>> item. They needed it ASAP (At least they thought so). I knew which programs
>> updated (add/change) and which ones just used it. I did exactly what Art
>> Recompiling all of the programs, moving to another system and installing
>> would have been a huge drain on resources. Although I did recompile and
>> install all of them on the following weekend.
>But what about the person that DOESN'T know "which programs updated
>(add/change) and which ones just used it"? For the "N"th time, what is the
>BIG DEAL about re-compiling all programs that use a given file? I seem to be
>getting the greatest resistance from the smaller accounts, which SHOULD have
>an EASIER time compiling all programs than the larger ones -- especially
>those with a CMS installed...

Hi, Dean

Here's my Nth response, albeit a little late. We're a fairly good-sized shop (megalomania arising here?), with 400's of various sizes at 13 sites around the country. We've begun using ALDON's CMS only in the last year and a half, as well as Hawkeye's Pathfinder cross-reference tool. They both save our lives on a regular basis.

We've long had the standard of not using LVLCHK(*NO). AFAIC, LVLCHK(*YES) gives protection we ignore at some peril. Also, I think it's more work than it's worth to keep track of what uses *NO and what uses *YES. Exceptions just make our work harder.

Recompiling all programs that use a file can be a big deal. We have a file on which, it seems, 100's of objects depend. It's our title order master. All our business revolves around this file. Changes to this file would result in days of effort to get all the correlative stuff done. Nonetheless, we'd do it—it's just part of the job, right?—but not without painstaking justification first. And we'd use the CMS tool and all the dependency skills it has. In fact, we are doing this with our Year 2000 effort.

The only time we use LVLCHK(*NO) is in very limited situations, to facilitate testing only, and with full knowledge that there's more work to do. IMHO, this attribute is too easily abused (no accusations here :-))

With you

Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN 55401
(612) 371-1111 x480 +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "". | To unsubscribe from this list send email to | and specify 'unsubscribe MIDRANGE-L' in the body of your message. | Questions should be directed to the list owner/operator: +---

This thread ...


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

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