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

Paul,

Part of your problem is the fact that you're restoring into a different
library. As describe in detail by Chuck Pence on this list in the past,
the RSTxxx code only supports X-LIB logicals when they are restored into
libraries of the same name as the original.

When restoring into the same name, you simply run the RSTxxx twice. The
second time picks up the deferred objects.

Unless you very carefully control and monitor the source, I suspect you'll
be continuously fighting this battle.

I assume the target LPAR already has a set of the libraries you are trying
to restore which is why you're trying to restore to another name.
That being the case, have you considered an independent disk pool (iASP)?
This would allow you to have multiple DBs on the system; meaning you could
have a library of the same name on each DB.
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzaly/rzalyhowiaspswork.htm
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzahf/rzahfworkwithmultipledb.htm

Charles

--


CHarles


On Tue, Feb 25, 2014 at 5:19 PM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>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.

My questions are how do most handle or code for the DFRID issue?
Depending on the scenario, sometimes the issue can be resolved by moving
the LF to the correct library and then SAVRSTOBJ only the LF that failed.
Other times, the entire process may be restarted from scratch.

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.

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx
http://www.pencor.com/

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.