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