Re: Best Practice Question

Shipped defaults are not necessarily "best practices". /tmp is the
pinnacle example.
You can delete /tmp and it will rebuild upon an IPL. IBM clearly documents
this at
https://www.ibm.com/docs/en/i/7.5.0?topic=directory-provided-directories
They do not say what the *ALWSAV attribute will be. What they do say is
that *RSTDRNMUNL will be set to yes. And they proceed to list what will
fail. What they don't tell you is that if you set *RSTDRNMUNL to yes then
IBM's email will cease to function. This is because a job running under
one IBM user creates the object in /tmp to queue it up and another job
running under a different IBM profile tries to delete it after sending and
cannot. IBM went so far as to reset this to yes upon every IPL until much
screaming, wailing and gnashing of teeth got them to stop doing that at IPL.

On Wed, Aug 20, 2025 at 1:40 PM Dan Bale <dan.bale@xxxxxxxxxxxxxxxxxxxxx>
wrote:

Can anyone provide context for why "Can be saved: No" for /tmp is
considered a best practice?

Is "Can be saved: Yes" the shipped default and, ergo, are most shops
oblivious to the potential impact of this setting?

- Dan Bale

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Rob
Berendt
Sent: Wednesday, August 20, 2025 12:15 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Best Practice Question

DSPATR OBJ('/tmp') should show
Can be saved . . . . . . . . . . . . . : No

If not then
CHGATR OBJ('/tmp') ATR(*ALWSAV) VALUE(*NO)

Definitely "best practices".


On Wed, Aug 20, 2025 at 11:47 AM Rich Loeber <rich@xxxxxxxxx> wrote:

Just wondering if it would be considered a best practice to always
exclude the /TMP folder in the IFS for a regular backup of the system.
This folder is used by items of the OS and we had a customer where
SNDSMTPEMM failed when our product tried to send an email during their

save.

Rich Loeber
Kisco Systems LLC

*** CONFIDENTIALITY NOTICE: The information contained in this
communication may be confidential, and is intended only for the use of the
recipients named above. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution, or
copying of this communication, or any of its contents, is strictly
prohibited. If you have received this communication in error, please return
it to the sender immediately and delete the original message and any copy
of it from your computer system. If you have any questions concerning this
message, please contact the sender. ***
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.