Re: Failed GO SAVE 21

On 30-Sep-2015 12:55 -0600, rob wrote:

On 30-Sep-2015 12:39 -0600, rob wrote:

Well, Chuck, you do have a point there

Presumably meaning, that perhaps an OS had since changed to have /tmp defined with AlwSav=No, such that the issue for the OP is mitigated for installations that do not customize to allow save for that directory; if not also, there could have been code changes that implicitly omit those objects that might be referenced concurrent to the save, or perhaps otherwise resolved by some other magic.? For all I know, the exact same issue could persist even to the most current release, and the problem is simply very rare [or, though hopefully not, misdiagnosed by me as to the origin].

/tmp
Creation date/time . . . . . . . . . . : 07/29/14 12:12:28
Can be saved . . . . . . . . . . . . . : No
System restricts save . . . . . . . : No

once /tmp is flagged this way then the subdirectories simply do not
matter.

Supposing the run-time re-create of the object is the only way the /tmp gets created [although maybe, but I doubt, could also come from install media], I suppose one could [if the explicit request is not prevented] Remove Link (RMVLNK) the /tmp and review the directory attributes after the object is re-created. I suppose, if the subtle warning in the following doc reference is a concern, and allusion that possibly the object is only "created again during the next restart of the system", I suppose the delete could be performed during a manual IPL, or better\safer, in restricted-state just prior to the PwrDwnSys.

*ALWSAV attribute is not mentioned at
[https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/ifs/rzaaxtmpdir.htm]

There exists the option to submit feedback for the page; now in the form of the /comments/ section instead of a feedback-button. Anyone concerned, could request they add mention of any other non-default attributes [other than the already documented Restricted Rename And Unlink [i.e. ATR(*RSTDRNMUNL)]. I did not add such a comment.

However if someone reveals that the ATR(*ALWSAV) for /tmp has changed to have VALUE(*NO), then I may be motivated to find someone to whom I can report what I concluded was the problem for the OP; i.e. suggest to somethat that IBM might still have an issue that may not yet have been addressed, except tangentially and merely masked by chance, because anyone could choose to [re]include /tmp using CHGATR [unless again, though doubtful, that explicit change request is prevented].