On 01-Aug-2014 06:26 -0500, rob@xxxxxxxxx wrote:
I've migrated several lpars from Power 6 to Power 8, with a few more
to go. One thing I've noticed is that even though BRMS says it was
saved it doesn't seem to get restored on the target system.
The creation date/time Creation date/time: 07/29/14 12:12:28 is way
before the restore of the stream files.
The logs would say what was restored.? In my experience the Restore
(RST) of a directory or file does transpire according to what is logged
by restore, even when the directory or file already exists; barring any
errors, for example due to disallowed object differences. A directory,
much like a file, is a container; the existence allows the /objects/
within to be restored, such that although the container was /restored/,
only the contents that were restored are notable.
I am guessing it was created with the restore of the OS.
Some objects are created during an IPL irrespective the IPL being
part of an install, many others only during an install; though often the
run-time would be designed to reactively create those same objects if
they are found to be missing when required. The Object Information
Record (OIR) of the /QSYS.LIB objects is much nicer from which to
determine origins; excepting of course, the anomaly with the "system
created on" information discussed recently:
<
http://archive.midrange.com/midrange-l/201407/msg00338.html>
So when you restore the stream file system you will get the
subdirectories underneath it but not the attributes of '/tmp' itself.
Which is a big thing if you have to run CHGATR OBJ('/tmp')
ATR(*RSTDRNMUNL) VALUE(*NO) in order to get email attachments to work
from IBM i email utilities. Just run that again after a restore.
I have little idea of what BRMS does with regard to saving the /tmp,
but I would expect the OS would by default [for DR B&R] treat the /tmp
much the same as various system libraries having a function, if not
analogous, at least somewhat similar; e.g. similar to how the *LIB
objects QRPLOBJ and QRECOVERY would and should not be saved and\or
restored as part of DR. And then, BRMS to do what the OS built-in
backups do. I actually would have guessed that the directory /tmp would
get created with [err... changed after creation to have] the Allow Save
(*ALWSAV) attribute set to *NO.
This is not covered in the "Recovering your system" manual.<<SNIP>>
I would expect there is at least some allusions, if not specific
mention of, implementing System Change Management; ensuring that
customizations made to the prior system should be re-applied to the new
system. That Change Attribute (CHGATR) request is really no different
than any other customization in that regard. Introduced as a change to
the default behavior spanning some release, however, possibly that
Restricted Renames And Unlink (*RSTDRNMUNL) attribute change was
eventually implemented by some sys admins, reactively rather than
proactively; a customization by any origin is best implemented as part
of proper System Change Management, and is not unique to a recovered system.
midrange.com
