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. -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
