Then don't use /tmp. Mount a bespoke TFS and manage it accordingly.
On 4/12/2017 10:29 PM, John McKown wrote:
On Sun, Dec 3, 2017 at 10:39 PM, David Crayford <[email protected]> wrote:
You don't need to be authorized to use z/OS UNIX shared memory segments.
You do need access to the file system and the memory segments are protected
using the normal UNIX permissions. Semaphores and pthread mutexes can also
reside in shared memory for inter-process locking.
The /tmp TFS is backed by memory so the easiest solution may be to us
files in the TFS.
The only problem that I have ever had with using /tmp is that, if it were
"released" (i.e. documented to & it's use encouraged) to programmers, then
I would run into complaints about "running out" of space on /tmp and file
name collisions. E.g. one job using up all the space in /tmp due to the JCL
writing believing it would just be a few records, but then a "bug" cause it
to try to write millions (this has happened here). Also, our programmers
at least, tend to be "lazy" and expect z/OS to "clean up" after them (some
of them don't even CLOSE their data sets). So I would need to manage the
files & directories in /tmp, most likely using skulker. And, of course,
that means that eventually somebody will whine that one of their files got
deleted.
I have addressed a _UNIX shell user_ using too much "temp" space by making
/tmp2 be an "automount controlled" mount point and forcing all the
"temporary file location" environment variables, such as TMP, TMPDIR, TEMP,
et al., to be /tmp2/&SYSUID. So when a shell user uses a properly coded
shell command, they go into their own zFS filesystem data set.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
