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



We're in the process of scratching the 520 back to it's 'initial' state.

The restore will back-level some of the LLPs and system objects.  After we
do the restore, we are then going to upgrade the 520 back to 5r3 which
brings everything up to snuff.  We've managed to do this but in bits and
pieces.  There have been a couple of little problems with Ops Console and OS
stuff which we've managed to get straightened out.

We're fortunate in that we don't have a deadline to get this done.  Our 720
has more than enough capacity for our current application volumes.  We are
in the process of bringing three 'sister' divisions onto the iSeries (all
from UNIX by the way) but there is lots of application work to be done
before they can move over.  This gives us the opportunity to test this thing
until we get it right.

If we can do the 5r2 to 5r3 migration, it could probably be done over a
normal weekend.  We run 24x7 except for a weekly save on Saturday night.
Usage is low on Sunday so we can get away with keeping the system down on
Sunday under extreme circumstances.  We cannot upgrade the 720 to 5r3 in
advance since we have fax adapters which are not supported on 5r3 and we
don't want to take a chance.  If we have to upgrade the 720 and then do the
migration, it will need a long weekend.  The only long weekend left this
year is Thanksgiving in October.  

I'm using our disaster recovery procedure (which I wrote) to restore the
system.  We've done a few DR tests in the past but I've always been the one
doing the restore.  This time we had an operator do it.  I wanted a second
party to run it to pick up on anything confusing in the procedure.  I know
what I meant but someone else might not.


Thanks,


Gord


>On Mon, 26 Sep 2005 12:27:58 -0500, "Ingvaldson, Scott" 
><SIngvaldson@xxxxxxxxxxxx> wrote:

>If you are still testing I would try:
>
>RSTOBJ OBJ(QAOK*) SAVLIB(QUSRSYS) DEV(tapxx) MBROPT(*ALL)
>ALWOBJDIF(*ALL) and RST DEV('/QSYS.LIB/tapxx.devd') OBJ(('/QOpenSys/*'))
>ALWOBJDIF(*ALL) and see how it turns out.  You don't get many good
>opportunities to test fixing problems like this without a complete
>do-over.  Also, IIRC the only "supported" procedure for this type of
>migration is to upgrade your 720 to V5R3 first and then do the restore
>to the new machine.  Were you able to restore the V5R2 QUSRSYS to the
>V5R3 machine without back-leveling it or the O/S?
>
>Since you referred to this as the "first test" can I assume that you are
>going to test again?  
>
>As the SuSE (Linux) folks like to say, "Have a lot of fun..."
>
>Regards,
> 
>Scott Ingvaldson
>iSeries System Administrator
>GuideOne Insurance Group
>
>
>-----Original Message-----
>date: Mon, 26 Sep 2005 10:20:48 -0400
>from: Gord Hutchinson <gordm1@xxxxxxxxxxxxxxx>
>subject: Re: System Distribution Directory Entries - Save & Restore
>
>Thanks Scott.
>
>At the risk of opening another can of worms, we are testing a migration
>from
>a 5r2 720 to a 5r3 migration 520.  The directory entries did not get
>restored.  I found that the reason why was that while doing the restore
>*ALLUSR the job aborted because we forgot to change the job to *PRTWRAP
>when
>the message queue filled up.  We restarted the restore *ALLUSR with
>OPTION(*NEW) which of course didn't restore anything which was already
>there
>- including the directory entries in QUSRSYS.  Ain't hindsight terrific.
>
>BTW, the only other problem we had in the first test was the fact that
>none
>of the objects in QOpenSys were restored.  The directories were not the
>contents.  They all errored with CPFA0B0 - Request not allowed to
>operate
>from one file system to another.  I'm suspecting (hoping) that this is
>related to a keying error my the operator on the RST command.  She
>entered
>the library name as 'QSYS.LIB' instead of '/QSYS.LIB'.
>
>
>Gord
>
>
>>On Fri, 23 Sep 2005 15:15:32 -0500, "Ingvaldson, Scott"
><SIngvaldson@xxxxxxxxxxxx> wrote:
>
>>They are in the QAOK* files in QUSRSYS.  As such they get saved with
>>your SAVLIB *ALLUSR or an option 23 save (as well as the option 21
>>save.)
>>
>>You can restore them using RSTLIB QUSRSYS, or RSTOBJ QAOK*.  
>>
>>***DISCLAIMER*** Restoring IBM objects in QUSRSYS can be somewhat
>dicey,
>>especially if you are trying to migrate from another system.  Possible
>>side effects may include back-leveling your O/S or having to re-enter
>>your software license keys.  If you are not doing this as part of a
>full
>>system restore I would consider manually recreating them or writing a
>>program to do this.
>>
>>Regards,
>> 
>>Scott Ingvaldson
>>iSeries System Administrator
>>GuideOne Insurance Group
>>
>>-----Original Message-----
>>date: Fri, 23 Sep 2005 14:10:05 -0400
>>from: Gord Hutchinson <gordm1@xxxxxxxxxxxxxxx>
>>subject: System Distribution Directory Entries - Save & Restore
>>
>>What command saves the distribution directory entries (from WRKDIRE)?
>>Is it
>>part of SAVSYS?
>>
>>One step further, which command restores them?
>>
>>Thanks,
>>
>>
>>Gord


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.