On 2015-07-22 19:10, John McKown wrote: > On Wed, Jul 22, 2015 at 4:25 PM, Pommier, Rex <[email protected]> > wrote: >> >> I don't know about anybody else here but I much prefer z/OS making me jump >> through a hoop or two before deleting a dataset that has an enqueue on it >> than UNIX which allows (or at least it did somewhat recently) me to delete >> a file that is open/in use/actively being updated by somebody else. >> > > What is worse is the total lack of a _system level_ interlock on an inode > (which is a subtle difference from a "file"). This means that I can run > multiple "update" jobs concurrently and totally hose up the contents. This > is _somewhat_ mitigated by the fact that all local references (a file > descriptor) to an inode are actually, in effect, "pointers" to a global > "open inode" table in the kernel. Which means that the system I/O buffer is > shared. There is a type of "locking" for inodes, but it is discretionary > and not mandatory. IMO, not sufficient. > the z/OS locking by ENQ is to a large extent also discretionary. Two or more users can allocate a DSN SHR, and any or all of them can update it unbeknownst to the others. Integrity is ensured only by established conventions.
> The ability to "delete a file" (actually unlink a directory entry) while it > is open does have one nice effect (FSVO "nice"). A program which needs a > temporary disk work area (there are no &&TEMP type file names in UNIX) can > do an open() with OCREAT+OEXCL to atomically create and open a new file. If > the file exists, the open() fails. If it succeeds, the code can then > immediately unlink() the entry. This removes the name from the directory, > "&&TEMP" is one of the few z/OS files that I miss in UNIX. POSIX requires that tmpfile() create a file in such fashion that "The file shall be automatically deleted when all references to the file are closed." This practically requires that tmpfile() unlink the file before returning. z/OS violates this requirement. IBM doesn't care. > but the inode on disk still exists and can be used just like any normal > file, including normal expansion. The need for this, in UNIX, is that there > is nothing like OS/360's DISP parameter to automatically delete a file name > when the program ends. And, unlike OS/360 et al., if the entire system > crashes, the inode will be automatically removed when the system is > rebooted, and an fsck is done when the filesystem is mounted. I will grant > that z/OS very rarely fails and leave temporary data sets on the work > volumes. I have _no_ idea why the creators of UNIX never came up with the > equivalent of an ENQ. And I don't think that other types of locks are as > good (e.g. have a directory called /enq and try to atomically create and > open a "resource name" as a file name, failing if the open() fails.) > "&&TEMP" is one of the few z/OS facilities that I miss in UNIX. OTOH, it's priceless to me that rename() is preemptive and atomic, providing a rudimentary LUW isolation. For example, I have a process in which I need occasionally to update a file via FTP. I FTP to an "incoming" temp name and rename on success to the permanent name. Consumers will never encounter: o An incomplete file in transition o Absence of the file during a RENAME timing window. (I have gotten "WTF" queries from a consumer who happened to notice the "incoming" file in transition.) If I needed to do this for a collection of related files, I could do so by preemptively replacing a symbolic link to a directory. I dearly wish I had similar facilities for z/OS Legacy data sets. Imagine renaming a data set nondisruptively while the target DSN is in use. I could do some of this with DSN aliases and/or JCLLIB members with SET commands for prefixes. It's a poor approximation since JCLLIB only governs batch processes. The marvel of UNIX lies in its first three letters, "UNI"; that all processes, foreground and background, can use the same command set -- no JCL vs. CLIST vs. ISPF LM* vs. IDCAMS ... -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
