2017-02-24 9:19 GMT-06:00 R.S. <[email protected]>:
> I'm trying to find a reason to use automount facility.
> Is it better than static mount of all needed filesystems?
>
​Personally, I use it for "ease of administration". I can make a single
control file, /etc/auto.master which "controls" a set of directories. In my
case, this is the UNIX "home" directories and UNIX "temporary" directories.
For the "home", I don't need to be bothered with creating a new zFS when I
create a new RACF id, everbody gets a OMVS segment with a autocreated UID.
Most people need an OMVS segment, such as for "ftp" processes, but most
won't use a UNIX shell or UNIX files directly. So creation of their "home"
directory is deferred until they actually _use_ it for the first time. This
saves me "bother" and saves disk space. Now, I personally don't like people
to use "/tmp" for UNIX "temporary" files. Why? Well, first off, I would
need to properly size it for _everybody_​'s accumulative use. So, in
/etc/profile, I "hard code" a number of environment variables like below:
luser=${LOGNAME} # user's RACF id
typeset -l luser # convert it to lower case
export TMPDIR=/tmp2/${luser} # POSIX variable pointing to user's temporary
UNIX files
export TMP=${TMPDIR} # old style usage for same
export TEMP=${TMP} # another old style usage
export TMP_VI=${TMP} # well, some versions of "vi" use this, z/OS does
Oh, you way that somebody might hard code the use of "/tmp" in their shell
scripts or programs? Well, they're idiots and deserve the pain that they
cause themselves. I don't have patience with, nor "molly coddle", people
who don't bother to learn how to do things the right way. Harsh? Perhaps,
but I am very willing to try to teach those who are interested and want to
learn "the right way" (OK, that's really "my way", but I base it on a lot
of reading by those in the UNIX community who are well thought of,
professionally: Linus Torvalds (UNIX), Richard Stallman (GNU, FSF), and
especially Eric S. Raymond.)
What the above does for me are: (1) I don't need to worry about BUBBA using
up all space in /tmp and so causing FRED a problem; (2) BUBBA doesn't need
to worry about space, usually, because his personal zFS temp space DSN will
expand as needed - see #5 for clean up of such; (3) I don't need to "clean
up" /tmp often, because no _users_ use it; (4) I don't need to have a bunch
of "user temp directory" zFS data sets setting around using up space; (5)
neither I, nor the user, needs to manage their temporary files because our
standard DASD management will _delete_ the container zFS data set if it is
unused for a week - this is strongly documented and anyone who complains
that they left an important file in their temporary files directory is
subject to BOFH style humiliation. Number 5 is my way of emulating z/OS
"work disk storage group" for UNIX files vs. z/OS DSN=&&TEMP data sets.
This last "autocleans" the UNIX temporary file space, so I don't need to
run some UNIX "file management" utility (like "skulker") to delete old UNIX
files in the "/tmp" directory. What can I say? I'm lazy!
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
--
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
