For these kinds of tasks as part of an upgrade, whether for
application vendor or for OS upgrade - I suggest that you put these
standard changes in their own source member or members.
( for the vendor, you change Print-Files)
( for an OS-Upgrade, you change Command Defaults, etc. )
By creating source members of these changes - even if you never run
it as a long CL - you have the documentation that you need to know
what was changed, and to remind you to review your changes to see if
the vendor (or IBM) is going to affect you. These list of changed
objects become the first part of your System Acceptance Tests.
And besides storing these changes in its own place, you may find
this same documentation area also helpful for your annual DR test.
For example, after we restore at the DR Site, we run the program
called "DR_Site" that does some standard tasks on the DR Box, like
doing a mass change to every print file on the system . . .
CHGPRTF *ALL/*ALL PRTTXT('Report from DR Box')
This eliminates any confusion from the user community when they look
at what was printed or transfered to COLD Optical. The production
reports and DR reports may be interleaved on the same printer or COLD
Optical folder, but this helps identify which is which.
This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact