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


  1.  Home
  2. MIDRANGE-L
  3. December 2017

RE: ATR(*ALWSAV) Was: Migrating extant system to new hardware

Jack,

I found my V6R1 P5 9406-550 to P7 8205-E6C migration notes from 2012.
Approximately 2 tb was migrated.

R&D LPAR was migrated weeks earlier.

My main issues, which I avoided (found in testing the migration-3 times)

1) LIC on the P5 was down level, 1st test migration failed because of this.
2) Some IFS objects were be being omitted from the save, which in turn caused some IBM LPP to fail, and RSTUAT also failed.

Other migration issues below.

3) Outqs that have devd were not restored, they were created, and not with the authorities they originally had. Outqs had their *PUBLIC authority changed from *CHANGE to *USE. This affected multiple users and their ability to work with spooled files within the affected outqs. The fix to the problem is changing the *PUBLIC authority of the outqs back to *CHANGE.
4) System service program QPMLPMGT authority was changed from *PUBLIC *USE on the POWER5 to *PUBLIC *EXCLUDE on POWER7, users were not able to view and/or print archived reports, changed the *PUBLIC authority of QPMLPMGT back to *USE.
5) QSYS/CHKPRDOPT PRDID(*OPSYS)- *FILE QALZALPKEY in QSYS not found for product 5761SS1 option *BASE release V6R1M0. Required PTF 5761999-MF55161 V6R1M1 not in correct status for PTF 5761SS1-SI46163 V6R1M0. PTF requisite errors found for product 5761SS1. Product 5761SS1 release V6R1M0 option *BASE load 5050 not correctly installed.

To minimize downtime, a full save will be done late in the week. Static, seldom used data, 25% of the system (IFS migrated optical, JRNLIB, BRCAUDIT, etc), will be deleted. This saved hours during migration. This static data will be restored following the migration, after we are up and online, as needed. All spoolfiles will be saved, not migrated, can be restored if and when needed.

Following the migration, a full dedicated system save must be done within a week.

I use BRMS for all normal saves, but during my migration testing, found issues with the BRMS recovery process that was not easily and quickly resolvable.
IBM actually recommended using the Save 21, Restore 21, for the migration.

Save 21 Entire system - 5 hours (excluding spoolfiles) 3582 with 2 LTO3 drives, backup ran using parallel drives
Restore 21. System and user data - Est. was 6 hours - 3573 with 4 LTO5 drives (actual restore was only 2 hours-SSD drives!!!)
Verify Restore - 1 hour
UPDPTFINF - 15 min
INZBRM - 5 minutes
Install/Apply PTF - 10 min
IPL - 5 min
2nd IPL may be needed - 5 min
Install all license keys, 20-IBM and 20- 3rd party products - 1 hour

The joblog from migration/recovery was 15,000 + pages.
I actually wrote an RPGLE program to summarize and count the various joblog messages, to save time reviewing.

Hope this all helps.

Paul



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: Thursday, December 21, 2017 1:44 PM
To: Midrange Systems Technical Discussion
Subject: Re: ATR(*ALWSAV) Was: Migrating extant system to new hardware

That's a good idea; it depends on how time critical the migration is - plus I usually prefer to keep them simpler.

Testing the BRMS recovery is certainly good practise.

On Fri, Dec 22, 2017 at 7:40 AM, Rob Berendt <rob@xxxxxxxxx> wrote:

<snip>
I use BRMS for most saves but for migrations I much prefer to use the
GO SAVE option 21 save.
</snip>
I paid homage to that in a recent thread. However I just like to do
it with BRMS. Gives me familiarity with, and tests, their recovery process.


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: Evan Harris <auctionitis@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 12/21/2017 01:36 PM
Subject: Re: ATR(*ALWSAV) Was: Migrating extant system to new
hardware
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



THose are pretty much the same ones I set - image catalogs and storage
spaces and more or less the same reasons. I can recreate the image
catalogs easily enough and the guests need a specific save strategy.

But I also have clients that keep thousands of XML files and use
virtual tape (well technically I guess that is an image catalog) and I
exclude those too.

I use BRMS for most saves but for migrations I much prefer to use the
GO SAVE option 21 save.

On Fri, Dec 22, 2017 at 1:14 AM, Rob Berendt <rob@xxxxxxxxx> wrote:

In general I do not set
CHGATR OBJ('/mydir') ATR(*ALWSAV) VALUE(*NO) Instead I set this in
BRMS, using omits, for directories I wish to omit during backups.
And then in BRMS, if I want to save them, I simply add the
OMITS(*IGNORE) parameter to STRBKUBRM.

The two exceptions are:
- the directories containing image catalog entries (and even then
I've been know to change them for an unload/reload)
- QFPNWSSTG on my hosting lpars. I prefer to save the guests instead.
And
do not see the need to double save. In case of disaster I will
rebuild the storage spaces, and perhaps balance them out better. I
have changed this when doing a data center migration when I saved
only the hosting lpar.

IBM, starting with 7.2 I believe, has changed a whole bunch of
directories
with ATR(*ALWSAV) VALUE(*NO). Mainly certain logging directories.
You will see a bunch of these messages in your saves:
CPD37C3
Message . . . . : Cannot save /tmp.
Cause . . . . . : The ALWSAV attribute on /tmp was set to *NO
preventing
the object from being saved.

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: Evan Harris <auctionitis@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 12/20/2017 04:16 PM
Subject: Re: Migrating extant system to new hardware
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



You will potentially get bitten on this if you have anything marked
as
ALWSAV(*NO) as well.

I have a few directories I mark as ALWSAV(*NO) but I generally
review
this
before an unload/reload so I know what I have to recreate.

On Thu, Dec 21, 2017 at 9:12 AM, Rob Berendt <rob@xxxxxxxxx> wrote:

<snip>
items were being omitted from the system save (QLNKOMTS) </snip>

This is a BRMS term.
Basically the cure, when you know you are doing an unload/reload
(or a full system save where you want most everything) is when you
use the
BRMS
command STRBKUBRM you do not forget to change this from the default:
OMITS(*PROCESS) to OMITS(*IGNORE) We always do the *IGNORE on our
quarterly saves.


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

--
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: http://amzn.to/2dEadiD




--

Regards
Evan Harris
--
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: http://amzn.to/2dEadiD


--
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: http://amzn.to/2dEadiD




--

Regards
Evan Harris
--
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: http://amzn.to/2dEadiD


--
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: http://amzn.to/2dEadiD





As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
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.