|
Using the output option on the restore allows you to scan for the "not restored" portion of message in the job log and note the tape sequence number. Using the sequence number to hop along the tape was much quicker than using OPTION(*NEW) to look for objects that hadn't been restored in a system build scenario I worked on not all that long ago.
I can say that waiting for an LTO 1 to find the objects was much slower than directing the restore to a particular part of the tape using a sequence number, however LTO 2/3 is so much quicker that I can't say this is still true, especially since I haven't has the luxury to test it in this situation. Also, I have to agree with Rob - these tapes are much faster, so it is possible that the time taken to identify the sequence numbers by scanning the job log would be greater than the additional time consumed by just issuing the second restore command specifying OPTION(*NEW).
Nevertheless, I like to know what has been excluded and why. Restore operations are not the place to be creating surprises for later on.
Regards Evan Harris At 04:10 p.m. 17/12/2005, you wrote:
midrange.com
But this is a blind restore, and you do NOT know if you have restored
everything. WHat happens if you had QVFYOBJECT set to 3 or 5, and the
*PGM wasnt signed. It wouldnt restore using the RSTLIB NONSYS *NEW, but
how would you know you missed it?
You would be better to do the following;
DSPJOBLOG - to find out the librarues that had objects that did not
restore. Get the number of objects and from the Help on the message
you will get the sequence number.
Then using your list of libraries do a
RSTOBJ OBJECT(*ALL) Library(library name from above) SEQ(sequence
number from above) ALWOBJDIF(*ALL) MATCH(*ALL)
OPTION(*NEW)REWIND(*LEAVE)
Now you repeat the RSTOBJ for each library you wrote down in your list
and after each restore, it will tell you the number of objects you
restored, so that you know if you have everything.
I don't have the Syntax exact on the commands as I am doing them from
memory, but I do this all the time and it is a great way of verifying
everything restores. Sure, there are other ways, but this has always
worked for me.
JMHO
Pete
---------------------------- Original Message ----------------------------
Subject: Re: Disaster Recovery test scenario
From: rob@xxxxxxxxx
Date: Fri, December 16, 2005 3:31 pm
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
--------------------------------------------------------------------------
> I've found that doing the second RSTLIB *NONSYS OPTION(*NEW) as outlined
> in the Backup and Recovery guide does a dandy job.
>
> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> ChadB@xxxxxxxxxxxxxxxxxxxx
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 12/16/2005 02:03 PM
> Please respond to
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
>
>
> To
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> cc
>
> Fax to
>
> Subject
> Re: Disaster Recovery test scenario
>
>
>
>
>
>
>
> I've found that it's well worth it to figure out which PF/LF combinations
> fit that problem for a given box and list them with recovery procedures so
> that on a recovery they can be kept track of and doublechecked before
> firing up the app. I've seen the situation even with some large, well
> written (in general) apps from big vendors. You'd think that wouldn't
> pass
> their QA when released...
>
>
>
> Al Barsa
> <barsa@barsaconsu
> lting.com> To
>
> Sent by: Midrange Systems Technical
> midrange-l-bounce Discussion
> s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx>
> cc
>
> Midrange Systems Technical
> 12/16/2005 11:28 Discussion
> AM <midrange-l@xxxxxxxxxxxx>,
> midrange-l-bounces@xxxxxxxxxxxx
> Subject
>
> Please respond to Re: Disaster Recovery test scenario
>
> Midrange Systems
> Technical
> Discussion
> <midrange-l@midra
> nge.com>
>
>
>
>
>
>
>
> Very bad to have PF's and LF's in different libraries. Go SAVE/RESTORE 21
> does not handle this properly unless the PF's are saved ahead of the LF's.
> Regardless, the save of the access path (which is the default as of V5R3)
> is wasted, and the LF has to be rebuilt regardless.
>
> Al
>
> Al Barsa, Jr.
> Barsa Consulting Group, LLC
>
> 400>390
>
> "i" comes before "p", "x" and "z"
> e gads
>
> Our system's had more names than Elizabeth Taylor!
>
> 914-251-1234
> 914-251-9406 fax
>
> http://www.barsaconsulting.com
> http://www.taatool.com
> http://www.as400connection.com
>
>
>
>
> Jerry Adams
> <jerry@bwwholesal
> e.com> To
> Sent by: Midrange Systems Technical
> midrange-l-bounce Discussion
> s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx>
> cc
>
> 12/16/2005 10:13 Subject
> AM Re: Disaster Recovery test scenario
>
>
> Please respond to
> Midrange Systems
> Technical
> Discussion
> <midrange-l@midra
> nge.com>
>
>
>
>
>
>
> A complicating factor that I encountered once was a client that insisted
> upon putting the PF's in one library (say, LIBPF) and the logicals in
> another library (LIBLF). Obviously, LIBPF would have to be restored
> before LIBLF. Restore 21 may handle this, or not.
>
>
> My client actually complicated it further. A had to be restore prior to
> B; B had to be restored prior to C; C had to be restored prior to A!
> For the life of me right now I can't remember what we did. But to this
> day, except for fly-by-night LF's in QTEMP, I insist that logicals be in
> the same library as the physicals. Joins could complicate that, but so
> far I haven't had physicals in multiple libraries for a join - yet.
>
>
>
> * Jerry C. Adams
> *iSeries Programmer/Analyst
> B&W Wholesale Distributors, Inc.* *
> voice
> 615.893.8633x152
> fax
> 615.995.1201
> email
> jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>
>
>
>
> Rick Aguiar wrote:
>
>>The only impact I've seen is where objects are not named with the library
> so
>>you may need to restore some libraries again based on the name of the lib
>>versus object.
>>
>>You can also just do the 21 restore process which takes all the single
> steps
>>out of the process.
>>Rick
>>
As an Amazon Associate we earn from qualifying purchases.
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.
