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