On a transfer to the OBSOLETE Environment, is anyone moving (copying) anything other than the source module? I'm unaware of any need, or best practice requiring copying all the additional output to OBSOLETE datasets. e.g. Load, Obj, etc.
Some folks like to move the element's processor outputs - executable, listing, to corresponding "obsolete" libraries when they transfer the obsolete element to the Obsolete Environment. This is "just in case" it really isn't obsolete. This gives them an immediate recovery option.
Makes sense. Just wanted to see if there were any other reasons.
It depends on the site really and everyone has the flexibility to decide what is best. It could even differ by system if you should prefer.
We do not allow any load, listings, etc to be copied into the obsolete Env. This forces our developers to run an element through the life cycle again if it is deemed it is actually still needed. Get a fresh compile/link and what not as well as get it back on their Auditor teams radar. If a system doesn't have Auditors, then it's not as big a deal, so we could be more flexible for those applications, but we apply the same rule site wide.
I agree with Joe.
While on the surface retaining all the output components seems like a good idea, if you needed to return that program from OBSOLETE to live PROD after, say, 5 years, are you REALLY going to copy in those old LOADs, DBRMs, and other pieces? I highly doubt that....
So maybe a hybrid would make the most sense; save the source but only save the output components for a year...
we dont ahve an obsolete env. The delete processor in production performs and archive step and copies the outputs to a corresponding .SAVE library.