Re: Best Practice Question

Hello Dan,

Am 20.08.2025 um 19:40 schrieb Dan Bale <dan.bale@xxxxxxxxxxxxxxxxxxxxx>:

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

/tmp is meant for files being created in a temporary manner. Ideally, they should be deleted by the generating application when no longer needed. Setting applications to debugging state, or (unexpected) application crashes happening might prevent cleanup.

See also: https://en.wikipedia.org/wiki/Unix_filesystem#Conventional_directory_layout (scroll to /tmp)

Due to their intended temporary nature, files in /tmp by themselves often have no value, because their content is often derived from data being in permanent storage anyway, and serves no other need than to conveniently tuck away intermediately processed data somewhere where it can be picked up by a subsequent program for further processing. This is to support of the Unix mantra of "Make each program do one thing well." and helps to chain many different such tools to perform complex operations on data. Not each scenario can be implemented by a linear chain of "pipes".

https://en.wikipedia.org/wiki/Unix_philosophy

https://en.wikipedia.org/wiki/Pipeline_(Unix)

All in all, /tmp is not unlike QTEMP, but global in nature and often gets erased when rebooting Unix-like OS.

Does that help in understanding?

Is "Can be saved: Yes" the shipped default

For 7.3: Yes.

and, ergo, are most shops oblivious to the potential impact of this setting?

Probably.

I feel the setting of "Can be saved: No" by IBM is somewhat excessive when considering the IFS in general, but for /tmp and even /var/tmp (same as /tmp but not erased at reboot time), it makes sense that the content isn't backed up.

:wq! PoC