Rob,
When you do your old SSD to newer SSD, did you ever consider using STRASPBAL TYPE(*MOVDTA).
This worked for me without a unload/reload, minimal down time, 2 hours.
If you have an HA/DR box, that's another story.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Tuesday, October 25, 2016 3:44 PM
To: Midrange Systems Technical Discussion
Subject: RE: BRMS system save strategy
The BRMS exits make perfect sense.
We tend to not save the network storage spaces anyway. Kind of figure a disaster would give me an excuse to rebuild the guested lpars with a better balancing. Maybe more NWSD's with fewer NWSSTG spaces on each of them or whatever I feel the performance balance might be. When an lpar creep grows you'll build it one way versus one you rebuild.
However, when I do my old ssd to newer ssd migration I will probably save the storage spaces to make the unload/reload of the system as a whole much faster.
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: "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 10/25/2016 03:35 PM
Subject: RE: BRMS system save strategy
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Part of that save is an exit that changes the allow save to *YES, then
puts
it back again. Sorry I did not clarify that enough.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Tuesday, October 25, 2016 2:29 PM
To: Midrange Systems Technical Discussion
Subject: RE: BRMS system save strategy
<snip>
IBM is notorious for marking files to not allow saves, (networks server
storage as an example) that's why we always do a restricted state save
with
*IBM in it, that has always worked for us in the past.
</snip>
If IBM stamps something this way, such as CHGATR OBJ('/QFPNWSSTG')
ATR(*ALWSAV) VALUE(*NO) then I don't believe doing a restricted state
save,
with any combination of parameters, will save that. One would have to
change it with CHGATR OBJ('/QFPNWSSTG') ATR(*ALWSAV) VALUE(*YES) prior to
running the save.
This is unrelated to
STRBKUBRM ... OMITS(*IGNORE)
And, yes, starting with 7.2 IBM went hog wild flagging a lot of
directories
with *ALWSAV - *NO. Mainly logging type information.
Now we get a lot of
Message ID . . . . . . . . : CPD37C3
Message . . . . : Cannot save /fixes.
Cause . . . . . : The ALWSAV attribute on /fixes was set to *NO
preventing
the object from being saved.
Recovery . . . : If the object is not needed for recovery purposes, no
recovery is necessary. If the object is needed for recovery purposes,
change the ALWSAV attribute to *YES and try the request again.
Before, if this was an unrestricted save, we would get:
Message ID . . . . . . . . : CPFA09E
Message . . . . : Object in use. Object is
/QIBM/UserData/OS/ADMININST/admin1/wlp/usr/servers/admin1/logs/console.
Cause . . . . . : An operation attempted to use object
/QIBM/UserData/OS/ADMININST/admin1/wlp/usr/servers/admin1/logs/console.log.
This object is currently in use.
Recovery . . . : Allow time for the current operation to complete and
then
retry. If no operation is being performed, determine if the object is
checked out. If it is, use the Check In Object (CHKIN) command to
check
in the object and then retry.
Then there are a few mysterious others. Like the 6 below.
Message ID . . . . . . . . : CPD37C4
Message . . . . : 47 objects not saved.
Cause . . . . . : 41 objects were not saved due to the ALWSAV attribute
set
to *NO. A CPD37C3 message was sent for each of those objects. 6
objects
were not saved because the system has indicated they should not be
saved.
Recovery . . . : See previously listed CPD37C3 messages. For objects
the
system has indicated should not be saved, no recovery is necessary. The
objects are either not needed for recovery purposes, or will be
recreated
by the system as needed.
Between all three:
- Objects the system decides you don't need to save
- Objects flagged *ALWSAV *NO
- Those in use (You do realized that save while active of IFS objects is a
sick joke, right?)
384316 objects saved. 301 not saved.
Save of list *LINK completed with errors.
You'd have to add these 301 objects to your BRMS omit list to get a clean
save without any "completed with errors" messages.
And that was just a backup completed on a lpar which was a mimix copy of a
*development* lpar. It had no interactive users and mimix data groups
were
ended prior to the save. Just think about a system which was really busy.
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:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
midrange.com
