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



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.