- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- File deletion error on
Operating System - OpenVMS
1752007
Members
4380
Online
108784
Solutions
Forums
Categories
Company
Local Language
юдл
back
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
юдл
back
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
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- 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
тАО11-30-2008 10:03 AM
тАО11-30-2008 10:03 AM
File deletion error on
Dear all,
Customer have encountered a problem was that supposed the directory file is deleted successfully:
$ DEL/LOG/NOCONFIRM DIRS$TMP:ZIP_19053219_2081528C.DIR;*
%DELETE-I-FILDEL, DIRS$:[TMP]ZIP_19053219_2081528C.DIR;1 deleted (69 blocks)
but when they performed the backup (command no retrievable), the error message "no such file" is prompted. After that, customer performed the $direct "file", and they found that the file name is appeared again but the timestamp is indicated "no such file". They have to manually delete the directory file again.
What bring my interest that was they are running DFO V2.9; will that be possibly caused by the access conflict (i.e User delete the file while DFO was accessing too. But not sure if it could cause the inconsistency.
Thank you for any "possible reason" so that I could be able to explain to customer.
OpenVMS Alpha V8.2
DFO V2.9
Best regards,
William
Customer have encountered a problem was that supposed the directory file is deleted successfully:
$ DEL/LOG/NOCONFIRM DIRS$TMP:ZIP_19053219_2081528C.DIR;*
%DELETE-I-FILDEL, DIRS$:[TMP]ZIP_19053219_2081528C.DIR;1 deleted (69 blocks)
but when they performed the backup (command no retrievable), the error message "no such file" is prompted. After that, customer performed the $direct "file", and they found that the file name is appeared again but the timestamp is indicated "no such file". They have to manually delete the directory file again.
What bring my interest that was they are running DFO V2.9; will that be possibly caused by the access conflict (i.e User delete the file while DFO was accessing too. But not sure if it could cause the inconsistency.
Thank you for any "possible reason" so that I could be able to explain to customer.
OpenVMS Alpha V8.2
DFO V2.9
Best regards,
William
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-30-2008 01:00 PM
тАО11-30-2008 01:00 PM
Re: File deletion error on
What is the outcome that you expect from this research? Given a specific answer or the identification of the error, what will be the results of gleaning that knowledge? What will be the value? And would there be a better way to spend the time and effort that was involved in the research and in acquiring that knowledge?
If this crops up regularly, then investigate what is happening with the directory, and what operations are occurring in parallel with the deletion. And in "up-armoring" the DCL and related processing involved.
As for the possibilities (and emphasis on possibilities): back links can cause this. disk errors. User errors. Conflicts between the backup and the deletion operations and the defragger or some other application that was running. Bugs in the local DCL. OpenVMS bugs.
And the better response to these questions in general -- where you'll get more return for the investment of time and thought -- is to spend the time that would have been spent figuring this out on:
- a: if the backups are sufficient and complete and current and if the entire configuration can be restored and the environment restarted from the archives. To ensure your customer can recover from disk errors.
- b: if the systems are running current versions for OpenVMS and DFO and all layered products, and to establish more current ECOs and the associated policies and procedures to get to current releases and ECO kits, and to test same.
If this is an actual and unresolved problem (and thus fodder to report to HP), the first thing HP is going to ask is to ECO the box to current. And if you want a more specific response or problem identification here (than the guesses), that's going to be involving HP support directly, or a whole lot more detail here.
If this crops up regularly, then investigate what is happening with the directory, and what operations are occurring in parallel with the deletion. And in "up-armoring" the DCL and related processing involved.
As for the possibilities (and emphasis on possibilities): back links can cause this. disk errors. User errors. Conflicts between the backup and the deletion operations and the defragger or some other application that was running. Bugs in the local DCL. OpenVMS bugs.
And the better response to these questions in general -- where you'll get more return for the investment of time and thought -- is to spend the time that would have been spent figuring this out on:
- a: if the backups are sufficient and complete and current and if the entire configuration can be restored and the environment restarted from the archives. To ensure your customer can recover from disk errors.
- b: if the systems are running current versions for OpenVMS and DFO and all layered products, and to establish more current ECOs and the associated policies and procedures to get to current releases and ECO kits, and to test same.
If this is an actual and unresolved problem (and thus fodder to report to HP), the first thing HP is going to ask is to ECO the box to current. And if you want a more specific response or problem identification here (than the guesses), that's going to be involving HP support directly, or a whole lot more detail here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-30-2008 01:22 PM
тАО11-30-2008 01:22 PM
Re: File deletion error on
William,
"Files" are somewhat of an illusion. What you see in a directory is a name pointing to a file header, which in turn points to the data. If you see "no such file" it means there is a directory entry but no file header. For some reason the file data and header have been deleted, but not the directory entry.
Given the long filename, I'd be especially careful to cross check the file name of your deleted file against the problem file to ensure you're really looking at the same entity.
The most common reason for finding dangling directory entries is where there are multiple directory entries for the same file (see SET FILE/ENTER) and the file has been deleted via a different entry. The dangling entry can be removed with SET FILE/REMOVE (dangerous command, see the warning under HELP SET FILE/REMOVE)
It's very unlikely that this could be caused by DFO. Any access conflict would be resolved with by DFO backing off, or the DELETE failing.
"Files" are somewhat of an illusion. What you see in a directory is a name pointing to a file header, which in turn points to the data. If you see "no such file" it means there is a directory entry but no file header. For some reason the file data and header have been deleted, but not the directory entry.
Given the long filename, I'd be especially careful to cross check the file name of your deleted file against the problem file to ensure you're really looking at the same entity.
The most common reason for finding dangling directory entries is where there are multiple directory entries for the same file (see SET FILE/ENTER) and the file has been deleted via a different entry. The dangling entry can be removed with SET FILE/REMOVE (dangerous command, see the warning under HELP SET FILE/REMOVE)
It's very unlikely that this could be caused by DFO. Any access conflict would be resolved with by DFO backing off, or the DELETE failing.
A crucible of informative mistakes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-01-2008 03:26 AM
тАО12-01-2008 03:26 AM
Re: File deletion error on
It is possible the file was open, but you got it marked for delete. In which case,
when you run anal/disk/repair it will free it up. Have fun.
Bob
when you run anal/disk/repair it will free it up. Have fun.
Bob
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP