× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



the full system restore option 21 also makes use of DFRID’s.

wonderful option. got rid of the RSTLIB OPTION(*NEW) had done in the past.

Bryan



On Nov 2, 2018, at 6:48 AM, Rob Berendt <rob@xxxxxxxxx> wrote:

Found it.
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzarm/rzarmseqrestoredeferobject.htm
http://www-01.ibm.com/support/docview.wss?uid=nas8N1018811
http://www.redbooks.ibm.com/redbooks/pdfs/sg247713.pdf
Defer ID . . . . . . . . . . . . DFRID
It's an option on RSTLIB. New feature in 6.1.
BRMS automatically takes advantage of it.
<snip>
RSTOBJBRM and RSTLIBBRM do not include the DFRID parameter and do default
to use DFRID(Q1ARSTID) under the covers. As mentioned above BRMS creates
the deferred id under the covers and performs the RSTDFROBJ automatically.

</snip>

BTW, it stores this data on your system, like forever. And recommends you
manually clean this up.

<snip>
When your data recovery is complete and you no longer need the information
that is stored for deferred objects, use the Remove Defer ID (RMVDFRID)
command to remove the information. For example, use the RMVDFRID command
if you manually create the deferred objects or start journaling for the
deferred objects. Information that is no longer needed might cause future
restore operations to send messages that you do not expect.
</snip>

<snip>
Where is the deferred ID stored on the system?

Library QRECOVERY, files QADBRSDFR and QADBRSDFRI

It is quite possible for orphaned or abandoned records to accumulate in
the QADBRSDFR file over time. The purpose of the RMVDFRID command is to
allow user-initiated cleanup of a QADBRSDFR file for a particular DFRID.
System-initiated cleanup will be performed for all DFRIDs if the QADBRSDFR
file is deleted or if damage is detected. Cleanup has the effect of
throwing away the records.

It is important for users to clean up the QADBRSTDFR file, by restoring
deferred files and removing any unwanted deferral records, as a completion
step in their restore process. Users should beware that orphaned records
can cause interference and confusion for future restores of those files.
</snip>

<snip>
SELECT * FROM QRECOVERY/QADBRSDFR WHERE DBRDFRID = 'Q1ARSTID'
</snip>

Just to list the DFRID:
SELECT DBRDFRID FROM QRECOVERY.QADBRSDFR group BY DBRDFRID;

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: "Musselman, Paul" <pmusselman@xxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 11/01/2018 05:32 PM
Subject: RE: P7 V7R3 to P9 V7R3 migration recommendations /
suggestions
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



There's something from IBM (in the O/S) that handles cross-library LFs--
it keeps either the PF or the LF (whichever comes first) in a 'holding'
state until the 'other' library is restored. You get a message on the
screen during the restore. Then the system links them together. If that
doesn't work, you have to rebuild the indices.

Paul E Musselman

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Rob
Berendt
Sent: Thursday, November 01, 2018 5:05 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: P7 V7R3 to P9 V7R3 migration recommendations / suggestions

Cross library logicals are always a hoot.
LIBA/LF1 points to LIBB/PF1
LIBB/LF2 points to LIBA/PF2

...

Rob Berendt

--
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.