RE: system integrity

thanx for your answer. real world experience is always helpfull and is 
something i currently don't have, so thanx alot. 

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Al Mac
> Sent: Monday, October 03, 2005 7:39 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: system integrity
> 
> Lots of IBM commands can send stuff to *OUTFILE which can 
> then be analysed 
> by Query/400 or the HLL of your choice.
> 
> DSPDBR is a great command.
> 
> Watch out for stuff that is only used during end-month, 
> end-year, physical 
> inventory, etc. special operations that are rarely done, but mission 
> critical.  Also the risk of other like that but not 
> neccessarily used every 
> year ... like some report for the auditors that they not 
> always ask for.
> 
> Watch out for assumptions.  We periodically open a new 
> facility to handle a 
> particular line of our business, and close some facility when 
> its work gets 
> combined into another one.  So I am cleaning up the software that is 
> facility specific, and for 95% of it, no problem, but there 
> are periodic 
> screams from users who are dependent on software designed for 
> a facility 
> that was closed 3 years ago, because it can also be run where 
> they key in 
> which facility at run time, and they have grown accustomed to 
> having things 
> that way.  Thus, that which I consider to be dead, I move into a DEAD 
> library, but do not actually delete it until a year later, 
> when we have 
> gone thru all the once a year stuff, and apparently no one needed it.
> 
> Watch out for application naming conventions where the base 
> software from 
> the vendor goes in one library, while that which is added by 
> you in-house, 
> and by 3rd party vendors goes in a different library.
> 
> Case in point ... we purchased license to product X
> we purchased upgrades to that from vendor Y and Z
> we integrated what came from vendors X Y Z in our modifications
> This was all derivative software which the licenses let us use.
> 
> Years later, management decided that the annual $ we were 
> paying vendor Y 
> was not worth the value we getting from that, so they pulled 
> the plug, 
> which meant IT had to scramble to find all places Y software had been 
> integrated into other programs, and pull that stuff out.
> 
> It would have been so much simpler if we had one library for 
> that which was 
> uniquely Y stuff, and keep modifications that used Y stuff out of the 
> libraries supposed to be exclusively from other vendors.
> 
> Also, while we had placed a statement in derivative code 
> giving copyright 
> notice to X Y Z, it might have also been helpful to have a 
> directory of 
> what software we had that contained derivative code from 
> which vendors.
> 
> -
> Al Macintyre  http://www.ryze.com/go/Al9Mac
> BPCS/400 Computer Janitor ... see
> http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSou
> rces.html
> -- 
> This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>