HFS file compression
Hi: Is there something that one needs to do to reclaim space in an HFS file in z/OS? I have deleted several files and subdirectories, yet when I attempt to add a new directory, I get error 85x, and a message that indicates there is no space left on the device. I would have thought an HFS file wouldn't behave like a PDS, but more like a UNIX device. Any ideas? Mike Myers Pitt County Memorial Hospital -- The contents of this e-mail (and any attachments) are confidential, may be privileged and may contain copyright material. You may only reproduce or distribute material if you are expressly authorized by us to do so. If you are not the intended recipient, any use, disclosure or copying of this email (and any attachments) is unauthorized. If you have received this e-mail in error, please notify the sender and immediately delete this e-mail and any copies of it from your system. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS file compression
There could be someone who has the file open even though you have deleted it. I have run into this in the past. We had a WebSphere region that filled up an HFS. I deleted the file that was consuming the space, but it didn't get released until the WebSphere region came down. This is a security 'feature' of UNIX. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mike Myers Sent: Friday, May 09, 2008 1:59 PM To: IBM-MAIN@BAMA.UA.EDU Subject: HFS file compression Hi: Is there something that one needs to do to reclaim space in an HFS file in z/OS? I have deleted several files and subdirectories, yet when I attempt to add a new directory, I get error 85x, and a message that indicates there is no space left on the device. I would have thought an HFS file wouldn't behave like a PDS, but more like a UNIX device. Any ideas? Mike Myers Pitt County Memorial Hospital -- The contents of this e-mail (and any attachments) are confidential, may be privileged and may contain copyright material. You may only reproduce or distribute material if you are expressly authorized by us to do so. If you are not the intended recipient, any use, disclosure or copying of this email (and any attachments) is unauthorized. If you have received this e-mail in error, please notify the sender and immediately delete this e-mail and any copies of it from your system. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS file compression
On Fri, 9 May 2008 14:09:24 -0400, Veilleux, Jon L wrote: There could be someone who has the file open even though you have deleted it. I have run into this in the past. We had a WebSphere region that filled up an HFS. I deleted the file that was consuming the space, but it didn't get released until the WebSphere region came down. This is a security 'feature' of UNIX. Call it security; call it integrity; call it convenience. I cherish the behavior and rely on it regularly. Because: o UNIX rename() is preemptive -- I needn't delete an existing file before I rename another to its name. o UNIX rename() is atomic -- when I perform a rename() no other process will observe an interval, however small, when the file appears not to exist. o UNIX unlink() (and rename()) have a sort of low-grade work unit isolation -- as you observe, when I unlink(), any other process (or my own) can continue to operate on that file without encountering an invalid mixture of versions until it closes it. In some cases when I wish to replace a file on a server, I write to a temporary filename; close() and rename() to the actual target name. This means that any other user is guaranteed to observe either the entire new version or the entire old version with integrity. On many UNIX systems the tmpfile() function creates the file by opening it, and immediately unlinks it. This leaves only the tiniest window during which abnormal termination of the process leaves the temporary file dangling. z/OS, OTOH, employs a contrary design. It's very easy to kill -KILL a z/OS process and leave a residual temporary file; very difficult on other UNIX systems. PDSEs exhibit much of the same behavior; perhaps even worse in some respects -- closing and deleting a single member may not reclaim the space until the directory is closed. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
