- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: File identification problem.
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
тАО01-07-2011 06:59 AM
тАО01-07-2011 06:59 AM
Re: File identification problem.
$ SHOW SYMBOL DIR
And with the Q and all, issue and post the output from the following commands:
$ DIRECTORYQ SY0:[CUP.LIVE.DAT]ITLEXT_25083.NORMAL
$ DIRECTORYQ SY0:[CUP.LIVE.DAT]ITLEXT_25083.NORMAL;1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2011 07:52 AM
тАО01-07-2011 07:52 AM
Re: File identification problem.
A system reboot untwisted it's knickers, so all post-reboot files were behaving as normal.
To fix the 'corrupted' files, I copied them to the same area with a generation of ;10, and purged them, which fixed it.
Many thanks for your time and suggestions guys, much appreciated as always.
Dave.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2011 09:13 AM
тАО01-07-2011 09:13 AM
Re: File identification problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2011 01:18 PM
тАО01-09-2011 01:18 PM
Re: File identification problem.
What exactly was the problem?
I have two reasons for asking
(a) As Hoff says, you may still have problems that will continue to play havoc with your file systems
(b) An important use of this forum is a resource to search when looking for answers to one's own problems. Recording what the problem was, no matter if it was self-inflicted, might help others avoid or rapidly resolve a similar problem in future.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2011 01:24 PM
тАО01-09-2011 01:24 PM
Re: File identification problem.
>A system reboot untwisted it's knickers, so
>all post-reboot files were behaving as
>normal.
Unlike some operating systems, OpenVMS tends to be completely deterministic, so reboots typically DO NOT change behaviour.
The 3R "solutions" (Restart, Reboot, Reinstall) don't have a place in the OpenVMS world, which is one reason that some of us inhabit it.
If you DO find a significant change in behaviour after a reboot (such as you describe), I'd strongly suspect something else is going on, and probably has NOT been fixed, just covered up. Now that you've rebooted, any diagnostic information has been lost.
For the future, if you see similar symptoms, particularly the same file or disk, I'd suggest you call in an expert to do some proper diagnosis. Alternatively, rather than just reboot, force a crash so the dump can be analysed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2011 06:46 AM
тАО01-10-2011 06:46 AM
Re: File identification problem.
The entire data area had to be rebuilt in order to receive uncorrupted files.
Still haven't got around to what broke them in the first place.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2011 03:20 PM
тАО01-10-2011 03:20 PM
Re: File identification problem.
"The entire data area had to be rebuilt" tells nothing to those who want to help you.
If you can explain a bit what that means in VMS commands/environment.
Is this node in a VMScluster?
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2011 03:24 PM
тАО01-10-2011 03:24 PM
Re: File identification problem.
It seems to be a problem with your "dil" command (I doubt you made a typo). There could be a command procedure activated for "dil" who knows. That is all I could figure out from the information you provided.
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2011 08:05 PM
тАО01-10-2011 08:05 PM
Re: File identification problem.
>> OPS2-VISLIV $ dil SY0:[CUP.LIVE.DAT]ITLEXT_25083.NORMAL
>>
>> Directory SY0:[CUP.LIVE.DAT]
>>
>> ITLEXT_25083.NORMAL;1 2/48 6-JAN-2011 13:39:49.54
>>
>> Total of 1 file, 2/48 blocks.
>>
>> OPS2-VISLIV $ dil SY0:[CUP.LIVE.DAT]ITLEXT_25083.NORMAL;1
>> %DIRECT-W-NOFILES, no files found
This is very strange indeed.
For any file, there would be entry in two places.
One in the INDEXF.SYS file and another in the directory file in which the file
resides. If you only issue a DIR command, the filename would be read from the
directory itself. In case you also issue qualifiers such as /DATE or /SIZE and
so on... the data corresponding to this would have to be read from the
INDEXF.SYS file. As you are able to get these details above, means that the
file has entries in both the INDEXF.SYS file and directory.
From the data available, its hard to say what the root cause of the problem is.
If problem reoccurs, the data to collect for analysis would be -
* What "dil" points to ?
* In memory Data
- System crash Dump
* On disk data
- DIR/FILE
- DUMP/HEADER/ALLOC
- DUMP/DIR
The above data would help in analysis from file system point of view.
Regards,
Murali
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-11-2011 07:07 AM
тАО01-11-2011 07:07 AM
Re: File identification problem.
dil == "directory/size=all/date"