- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Deleting a File that is Open
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-22-2009 10:14 AM
тАО05-22-2009 10:14 AM
On OpenVMS V8.3 on Files-11 ODS-2 Disks.
I have one process that, using a Fortran executable, OPENs an indexed file as SHARED, ACCESS=READ. No CLOSE is performed [yet] and one record has been read as RRL/NLK, Query-Locking is DISABLED. Write-Through caching is enabled on that file.
Another process comes along (actually a subprocess of that parent who opened the file) and using DCL $DELETE, successfully deletes that file. This deletion occurs explicitly for the purpose of sort'a "restoring" a series of files by re-loading a bunch of RMS files from a backup area. We understand and accept that that file originally OPENed has been replaced, even though it may not be aware of it [yet].
We know and understand that this behavior works, albeit...it is somewhat curious. (I will get to a question about that momentarily.)
Now, instead of that subprocess using DCL to $DELETE those files, we use hardware based data replication to perform a SNAP RESTORE (EMC Technology). Forgoing a detailed description of that process, I will simply state that in order to do that, that target device needs to be dismounted.
However, with that file OPENed, although its DELETEion is possible, the housing device cannot be dismounted. The error, as one would expect is:
%DISM-W-CANNOTDMT, DISKX1 cannot be dismounted
%DISM-W-USERFILES, 1 user file open on volume
If it is any help, this behavior can be reproduced by simply having two sessions...
- On #1, DCL $OPEN/READ a file.
- On #2, DCL $DELETE that file
- On #1, read record(s).
Now, for my questions:
1) Using the DCL $DELETE to delete that file from under that process that has it open, I can still see the FCB, and can see the F11 arbitration lock. I can even see the file using a $SHOW DEVICE/FILES (without BYPASS, the file name is displayed as blank, with BYPASS, the filename is shown). If there is a way to easily explain how this "temporary file" and/or "file marked for deletion" behavior allows for that file name to be seen and that FCB to still exist with that lock, I would very much be appreciative to hear it. Is it just that the directory entry is deleted but the file itself remains until the CLOSE? (I see that using a OPEN WRITE, the file cannot be deleted.)
2) [My real question] ... Is there a way other than having that process that performed the OPEN actually CLOSE the file and/or have its image terminated or process deleted...is there another way where I could $DISMOUNT that device...say by pulling the rug out from under that now temporary file? In opther words, having that executing subprocess sense the file (maybe via $SHOW DEViCE/FILES and telling that process to let go?)
A tough one to explain. I am hoping that I did a good enough job at it to make sense.
Note that I am experimenting with simply adding a CLOSE of that LUN prior to that launching of that executing subprocess. This would be a simple solution, but may open the proverbial "can-of-worms" as this code is very old and very much in use throughout our application. SUch changes, no matetr how simple, are sometimes frowned upon.
Many thanks in advance.
-Howard-
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-22-2009 11:27 AM
тАО05-22-2009 11:27 AM
Re: Deleting a File that is Open
At this time I can not experiment enough to be definitive, but is
$ DISMOUNT/ABORT
any help?
Worth a try?
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-22-2009 11:39 AM
тАО05-22-2009 11:39 AM
Re: Deleting a File that is Open
Yes...that was very much worth a try. I had not even thought of that one.
Unfortunately, no luck.
$ dismount/cluster diskx1
%DISM-W-CANNOTDMT, DISKX1 cannot be dismounted
%DISM-W-USERFILES, 1 user file open on volume
$ dismount/cluster/abort diskx1
%DISM-W-CANNOTDMT, DISKX1 cannot be dismounted
%DISM-W-USERFILES, 1 user file open on volume
Thank you, though. I wish that would have worked; it would have made my task rather simple.
-H-
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-22-2009 11:42 AM
тАО05-22-2009 11:42 AM
Re: Deleting a File that is Open
As for your earlier question, the request to delete the (open) file is completed upon the close or (upon system crash) upon a subsequent disk analysis and repair. Not before.
And with the latter question, is this your own local Fortran code running? If it is your code and as we have been discussing with regularity here recently, the "best" approach is to modify your Fortran code to assist with or to perform a consistent backup.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-22-2009 11:52 AM
тАО05-22-2009 11:52 AM
Re: Deleting a File that is Open
Yes. It is our home-grown code. And, yes...I completely agree that it would be certainly best to just modify that code...and I do agree that such is a best practice...but...
Maybe I am just looking for solutions that really either do not exist or just simply should never be done as a general practice. I admit that this is very possible, but I figured that it would never hurt to ask.
I had mentioned that I would/could just add a CLOSE of that file to the offending routine; unfortunately, sometimes making even the simplest of changes to pre-existing often-used modules causes issues that would never have been considered during a testing effort. I suppose that I would have liked to identify some "neat trick" or something that would allow me to forgo making changes that may have adverse affects elsewhere.
Oh well...
I do appreciate your information.
Thank you.
-H-
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-22-2009 06:15 PM
тАО05-22-2009 06:15 PM
Re: Deleting a File that is Open
The file appears to be deleted already because the directory entry for it is removed, but in fact the file still exists, as SHOW DEVICE/FILES will show. DFU UNDELETE /MARKED can be used to restore the directory and "unmark" it.
Otherwise when the file is closed by the read-only process then it is actually deleted. If the system crashes before the file is closed then the file becomes a "lost" file, along with still being marked-for-delete. ANALYZE/DISK/REPAIR or DFU VERIFY /FIX can be used to delete these lost files.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-23-2009 02:23 AM
тАО05-23-2009 02:23 AM
Re: Deleting a File that is Open
I concur with Hoff and the others, modifying the code to close the file is the definitive option. In fact, the reason it is the "best practice" is that it is the only solution that reliably works as intended without side effects.
I have seen many situations where programs "deleted" files out from under running programs, and have untangled more than a few undesired side effects (e.g., lost database updates). An emergency measure? Perhaps, but so is just doing a STOP/ID=.
Additionally, if I were modifying the code to close the file, I would also verify that the code has a check that the file is actually opened. If that trap is missing, I would add it at the same time, and verify that it actually works as intended with a test jacket. The most likely problem from closing the file is an attempt to read a now-closed file, which would be dealt with by that trap.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-23-2009 03:00 AM
тАО05-23-2009 03:00 AM
SolutionWhat do you expect to happen to the application that has the file open if you somehow force a dismount? It isn't going to be able continue without error.
There are several approaches, the simplest, but most obtrusive to the application, being to kill the process and restart it after you have taken your snapshot.
If you must dismount the disk, that's the only choice I can think of without modifications to the application. Note that if the application only has the file open for read, that shouldn't cause a consistency problem with the file in question, but if you are trying to achieve a clean dismount to "flush", then you will need to have all files on the volume closed, cluster wide.
A cleaner approach would be to have a mechanism to notify the application that it needs to close the file. One method is a "doorbell" lock, essentially the application opening the file for read access would take a PR lock on an agreed upon resource name and have it specify a blocking AST to be delivered if an incompatible lock is requested for the resource. The application would then be responsible to save RMS context (so it can restore when the snapshot is complete), close the file, release the PR lock or convert it to NL, and then requeue another lock and wait for it before reopening the file.
Synchronizing AST level and non-AST level code isn't trivial in the general case. Robert Gezelter has several presentations that describe a method where everything is done at AST level and thus avoids synchronization problems, a type of event driven cooperative multitasking, with ASTs starting processing and the done processing event is $hiber.
Easier, but with more overhead is to have the application open/read/close the file every time it reads a record, with error handling to wait and try again if it gets a device unavailable error on open. It really depends on what the indexed file is used for, and how often it is read, that will determine if that is an acceptable solution.
The opens and repositioning can be optimized somewhat by opening by FID, and using RFA, but it is still expensive compared to just reading a record.
There isn't a magic bullet that will cause all applications to close their files, wait for a "go ahead", then re-open the files, restore the previous RMS state, and continue.
Application checkpointing was planned for VAX/VMS V4, but the problem was much more difficult than was originally envisioned, and it never happened. There probably is no way to do it in a backward compatible way. There have been many things that were planned but never released. Some examples: QIO server, VMS snapshot services.
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-23-2009 12:27 PM
тАО05-23-2009 12:27 PM
Re: Deleting a File that is Open
--
The world should be glad that the QIO Server was never released.
It was a classic example of a project that collapsed under its own weight, even after it was trimmed back to about 25% of the original plan.
-- Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-24-2009 02:34 AM
тАО05-24-2009 02:34 AM
Re: Deleting a File that is Open
The introductory session that Jon referenced is "Introduction to AST Programming". It was last presented at the 2000 Compaq Enterprise Technology Symposium in Los Angeles. The slides from that presentation are available at http://www.rlgsc.com/cets/2000/435.html
- Bob Gezelter, http://www.rlgsc.com