Re: Why isn't go restore opt 21 used with previous-to-current

On 12-Dec-2014 10:14 -0600, Ted Breedon wrote:

<<SNIP>> IBM told me that the instructions are "probably" based off
of old documents so a 21 restore should work but the OS hasn't
fundamentally changed so I'm a little perplexed.

Sounds like whomever is being attributed the moniker of IBM is giving someone an effective brushoff; oddly at an expense to them, of having to initiate corrections, where presumably no corrects are necessary.

The instructions are documented as they are, because they are what was determined to be the most likely to be _generically successful_ in effecting the task; i.e. with very few exceptions, given the instructions are followed, the documented processes should effect the intended, for as close to every scenario as is possible.

As I had alluded in my prior reply, doing the GO RESTORE option-21 restore is quite probably capable of effecting the intended, without error, for some installations. However some number of previous-release installations may have been customized in such a manner that one or more of the _disallowed object differences_ may cause a failed restore of some object(s) to a system installed with the LIC and OS of a more current [up to N+2] release, for which the recovery might require reloading the GO SAVE option-21 media and then re-requesting a restore either with an Allow Object Differences (ALWOBJDIF) specification of other than *NONE or instead first perform correction(s) to the object on disk such that the next ALWOBJDIF(*NONE) restore will not fail again. Thus the instructions are formulated to accommodate those scenarios which would otherwise fail, even if the vast majority of scenarios do not require the steps to be followed exactly as shown; in this case, so as to save them the effort of re-attempting a failed restore, simply by specifying an option that would allow them to avoid such a failure.