Re: Save/restore of '/tmp'

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.