I am probably over simplifying the issue or I am sure the smart folks at IBM would have done this already but it seems to be that if the DSN ENQ included a VOLSER, then the system would be able to distinguish between a truly ENQ Dataset and one that has the same name of an ENQ Dataset that resides on another volume. If the file is really in use, I would want to have the protection of jumping through hoops to make sure this is done by someone who truly understands what they are doing and its possible impact.
David Evans From: Paul Gilmartin <[email protected]> To: [email protected] Date: 07/22/2015 08:56 PM Subject: Re: Deleting data sets in use Sent by: IBM Mainframe Discussion List <[email protected]> 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
