I'm working on a utility to find objects that exist in a
custom/emergency fix library that would have a create date *LT the
create date of the object in the standard library, thus sign of an
issue. Utility done, working.
However, I found a scenario where we received a new object (*prtf) for
If the objects could be assigned an Object Control Level, an APAR or PTF identifier, or some other value
that defines what is the specific object [beyond its name], would that assist to know that the duplicated object was a copy of the original . . .
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 it's 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.
- John Voris