Re: Checking object create dates

On 14-Feb-2014 14:08 -0800, Voris, John wrote:

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.

So I infer your take on the overall topic from the OP, was that the issue is about ensuring proper system change management.? Such that the /changed/ printer file originally discussed, was an issue whereby the 3rd party sfw apparently would have replaced their version of a shipped PRTF as part of an upgrade or patch\fix, such that the desire of the OP is to ensure all of their prior customizations [specifically, to that object] are still properly applied after that upgrade activity completes?

If that was the intention for the OP, then I totally agree that the solution is instituting a system change management plan. And stored as CL requests in a CL stream [or CLP source; though that requires a compile] allows a fairly simple means to re-invoke any customizations after any\every upgrade, be it a full upgrade or merely a patch\fix. The application of the changes was an automated action on my systems [as part of QSTRUPPGM], by comparing a stored sfw product and fix level with the currently extracted levels; the script was invoked when differences were noted, and the newly extracted levels were the used to reset the stored levels upon completion.

p.s. While I had just noted I would not follow-up with regard to ascertaining the wider meaning of the OP topic, I started responding to this as a new topic; i.e. there was no "Re:" in the subject, even though I noted some unattributed quoted text was included that was culled from other posts under the original topic. Thus... Nobody need call-out my having replied.