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
