MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2014

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



fixed

Charles,

That is not an option, those libraries already exist for a different environment.
IASP not a current option, maybe future.
3rd party support issues with IASP.

I'm working on code to find and identify the X-LF on the source LPAR, move the LF before the error occurs.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Wednesday, February 26, 2014 10:36 AM
To: Midrange Systems Technical Discussion
Subject: Re: X-LIB LF cause RSTLIBBRM to fail with CPI321E

The only alternative is to restore evening to the original libraries.

The system will be able to deal with the X_LIB dependency.

Charles


On Wed, Feb 26, 2014 at 10:30 AM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>wrote:

Rob, Charles,

I've seen this several times, not often, ugly when it occurs. it's
always accidental, programmer moves LF to incorrect library.. The only
fix I know of is to move the LF on the source LPAR back to the proper
library containing the PF, redo the save, then the restore, or simply
SAVRSTOBJ the single LF.

I'm looking for alternatives, if any.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, February 26, 2014 10:24 AM
To: Midrange Systems Technical Discussion
Subject: Re: X-LIB LF cause RSTLIBBRM to fail with CPI321E

Ok, now I see the issue from the OP
<snip>
and the libraries on target LPAR B have different names.
</snip>
Yeah, that's going to be tough. Probably will need to do the dual
restore and that even might have issues if the library names are different.

Let's see, saved these libraries:
DALLASAR
DALLASGL
And let's say there's a LF in .AR pointing to PF in .GL.

Now your restoring them to another lpar, AND, renaming them to
HOUSTONAR HOUSTONGL

I am not sure if even the dual restore can fix that.



Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Charles Wilt <charles.wilt@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 02/26/2014 10:01 AM
Subject: Re: X-LIB LF cause RSTLIBBRM to fail with CPI321E
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Rob,

I'll grant you that IBM has made it easier...(and faster) but
technically you are still doing running two RSTxxx commands :)

Regardless, the system won't be able to restore a X-LIB dependent
object when the object it depended on was restored to a new library.

In that scenario, you'd have to recreate the dependent object.

Charles


On Wed, Feb 26, 2014 at 9:22 AM, <rob@xxxxxxxxx> wrote:

I thought IBM eliminated the need to do the dual restore for cross
library
logicals with current levels of the OS.
6.1, Systems Management, Recovering your system, What's new for 6.1



http://pic.dhe.ibm.com/infocenter/iseries/v6r1m0/topic/rzarm/rzarmwhat
new.htm


<snip>
Deferred restores

You can restore physical and logical files in any order.

The Restore Library (RSTLIB) and Restore Object (RSTOBJ) commands
have
been enhanced with a new parameter to defer the restore of dependent
database files whose based-on files are missing. Deferred objects
can be logical files or SQL materialized query tables (MQTs).<<

You can use the new Restore Deferred Objects (RSTDFROBJ) command to
complete the restore of deferred objects, if the objects that they
depend
on are now available.

You can use the new Remove Defer ID (RMVDFRID) command to remove all
deferred object information that is associated with a deferred restore.

For more information about deferred restores, see the following topics:

Sequence for restoring related objects.
Deferring the restore of dependent objects.
Verifying whether objects are restored successfully.
Task 5: Restoring libraries to the system auxiliary storage pool.
Restoring logical files.
Restoring SQL materialized query tables.
</snip>

Methinks the OP was trying to use this deferred restore method and
was having issues with it.

Deferring the restore of dependent objects



http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzarm/rzarmseqr
estoredeferobject.htm


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Charles Wilt <charles.wilt@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 02/26/2014 08:57 AM
Subject: Re: X-LIB LF cause RSTLIBBRM to fail with CPI321E
Sent by: midrange-l-bounces@xxxxxxxxxxxx



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/rzalyhowi
aspswork.htm





http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzahf/rzahfwork
withmultipledb.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.


--
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.


--
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.


--
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.


--
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.

--
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.


--
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.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact