Re: X-LIB LF cause RSTLIBBRM to fail with CPI321E

On 25-Feb-2014 14:19 -0800, Steinmetz, Paul wrote:

When restoring multiple libraries (18) via an automated process from
LPAR A to LPAR B, RSTLIBBRM failed with a CPI321E, File SAVLF02C in
library TPAULT2 deferred because of reason code 1. Based-on file
SAVPF02 in library PAULT1 did not exist when SAVLF02C was being
created for the restore.

The reason for the failure is that the LF was not in the same library
as the PF on source LPAR A and the libraries on target LPAR B have
different names.

The automated process ends abnormally at this point with an
incomplete restore.

I added 2 changes to the automated process.
1) CPF0000 for the RSTLIBBRM with X-LIB LF (This allowed the
automated process to continue, even though there was a DFRID
was created.
2) Immediately following the RSTLIBBRM, I added QSYS/RMVDFRID
DFRID(*ALL). (This cleared the DFRID for all future RSTLIBBRM.

Rather than /clearing/ the Deferred restored condition, perhaps instead do whatever is required to make the RSTLIB via the BRMS not perform as a Defer ID (DFRID) restore; i.e. have the RSTLIBBRM use DFRID(*NONE) for this restore. The effect then, would be instead, that the object is not restored due to the missing dependent object(s); no need to effect the Remove Defer ID (RMVDFRID) action. An error nonetheless, but perhaps one for which the response and\or recovery is simpler.?

<<SNIP>>

A future check I intend is to identify any X-LIB LF on source LPAR
A, move the LF to the same library as the PF, thus eliminating any
DFRID due to X-LIB LF.

The proactive approach, prior to the save, is good; assuming no [effectively] concurrent create. But some LFs may reference more than one library, i.e. be spanning more than one library, whereby a MOVOBJ is of no assist. And besides, moving an object that someone created for an apparent purpose, may not be very helpful such that the likely effect will be that they repeat that same creation action, after they find their object has gone missing.... and the next time, the Move Object request is going to have a conflict to resolve. While effecting Delete File (DLTF) [or using the SQL to effect DROP with CASCADE to avoid other dependents leaves the same /missing object/ issue for the user who created the object initially, that does resolve any issue for conflicts with the Move request :-) Though, I suppose, sending an email to the creator and\or owner saying "do not create such an object" might be appropriate :-)