• Subject: Re: CHGPF Question
  • From: "James W. Kilgore" <qappdsn@xxxxxxx>
  • Date: Wed, 24 Sep 1997 10:52:06 +0100
  • Organization: Progressive Data Systems, Inc.

PaulMmn wrote:
> Dean wrote, in part:
> >
> >NOBODY has answered the question -- "What is the BIG DEAL about re-compiling
> >all programs affected by a file change?"
> The big deal is the application with 2000 (no, I'm not making this up)
> programs in the application, most of which use master file FRED (I made up
> the name).  Finding and recompiling all of those programs is a -=<BIG>=-
> deal.

The QUSRTOOLS has (had) a command for scanning all source members in a
file for a particular string. 
Without any change management tools available, this could be modified to
output the member/file/library name to a file or data queue which could
be piped into a batch CRTxxxPGM process.  I suppose it could be made
smart enough so that if it found a file name in an OVRDBF statement it
would log every called program until a DLTOVR was found.  Just an idea
to make it a little easier.  Still might not get them all though.

> However, I agree that LVLCHK(*YES) is next to Godliness; we wouldn't live
> without it.

Fully agree...lifes exciting enough <g>

> File changes to master files is a carefully thought out and implemented
> thing around here.  It's not a spur of the moment decision.  Which, I
> suppose, is why we have 2000 (no, I'm not making this up) objects in our
> file library (as the programmers would rather create a new 'mini-file'
> instead of re-creating a master file).
For 24/7 shops this may be the only way to get anything done in a timely
fashion.  Otherwise things would occur around those few days (holidays)
that the number of users disrupted by a shut down are at a minimum.

You may have to bite the bullet and consolidate those 'mini-files' if
performance ever rears it's ugly head. Sharing a single access path and
having 2000 field specific logicals may be hard enough to manage but it
may not only help performance but may save you some DASD.  Just a
| 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-2020 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].