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

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