Re: [Bulk] Save/restore of '/tmp'

Rob:

QSECOFR has *ALLOBJ so it should be able to delete anything in the "/tmp" directory. (Prompt CHGATR and place the cursor in the ATR field and press F1=Help ... then press F20 and page down to the section about *RSTDRNMUNL )

In Unix, by convention, "/tmp" is //a place to put "temporary" files, but does not work like QTEMP in that there is no "automatic" clean-up -- the system administrator must schedule a job to clear that directory periodically (usually done via CRON in Unix, AIX, etc.).

For OS/400 or IBM i, a shell script such as:

QSH CMD(;rm -r /tmp/*')

run by a user profile with *ALLOBJ should do the job. This can be set up as a batch job and scheduled, e.g. with WRKJOBSCDE.

QUESTION: why would you want to save and restore the contents of "/tmp" as part of normal "back-ups"?

Consider adding (' /tmp'' *OMIT) to the SAV that is done as part of your normal back-ups ...

To make "/tmp" behave more like QTEMP, with automatic clean-iup, do a (google search for "temporary user defined file systems" -- or find it in the Knowledge Center under "What's new for IBM i 7.1".

HTH,

Mark S. Waterbury


> On 8/1/2014 7:26 AM, 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. I am guessing it was
created with the restore of the OS. 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.
This is not covered in the "Recovering your system" manual.

For those of you unfamiliar with this history let's say you create an
object under '/tmp'. Even if QSECOFR signs on they are not going to
delete that object if the attribute of '/tmp' is not changed. So, you
create this object and some IBM utility, running underneath QTCP or some
such thing tries to process an email attachment in there, it may have
issues.

It's like a unix crappy way of trying to implement the QTEMP library
system. Well, maybe not quite. Let's just say it's an attempt to not get
people to always name stuff underneath '/tmp' the same and seeing that
they are getting stepped on by each other.

Rob Berendt