Re: /tmp on an unload/reload

[CRPence <CRPbottle@xxxxxxxxx>]

  Does the doc clarify that you would need to perform other system 
change management like CHGLIB QUSRSYS CRTAUT(Customized) for what 
would transpire in a DR scenario for a customized create authority 
for the QUSRSYS library?

  I would expect that any object "created" as part of the OS 
install portion of DR, versus coming into existence due to being 
"restored" as part of DR activity, would need to be updated as part 
of normal system change management.  IMO that is much clearer [to 
state those objects created by install vs restored] than "IBM 
supplied" since previously customized objects such as LPP libraries 
& directories that come from the full system save versus install 
media would remain customized after DR yet still be "IBM supplied" 
objects.

  Of course an alternative to CHGATR would be to RMVDIR '/tmp' 
prior to RST, similar to the alternative to CHGLIB would be DLTLIB 
QUSRSYS prior to RSTLIB.  But the latter is not so easy if the 
system value QLIBLCKLVL='1' on the latest IPL.

Regards, Chuck

rob@xxxxxxxxx wrote:
> If you modify /tmp and change the RSTDRNMUNL attribute in order 
> to get QMSF and QtmmSendMail working then you will have to change
> that if you do an unload/reload. Tried to get the "Recovering
> your system" documentation updated to show this. Best I could get
> from IBM was the following:
>
> <snip>
>   Rob, I did some more checking into this. There are some 
>   attributes which are not set if the object exists during
>   restore.  RSTDRNMUNL is one of them. I'll have the Recover
>   your system documentation updated to include something like:
>     If certain attributes were changed on IBM supplied
>     directories, those attributes may need to be changed
>     again after recovery.
> </snip>
>
> You're on your own to determine that one of the directories that
> they are talking about is /tmp.
>
> Rob Berendt