HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

File identification problem.

 
SOLVED
Go to solution

File identification problem.

When using a dir command to find a file, the file can be found if I don't include a semicolon & *, but if i do it says 'file not found'. Any reason for this please?
29 REPLIES
Steven Schweda
Honored Contributor

Re: File identification problem.

As usual, showing actual commands with their
actual output can be more helpful than vague
descriptions or interpretations.

> Any reason for this please?

Believe it or not, the answer may depend on
exactly what you're doing, which my psychic
powers are too weak to reveal to me.

While you're at it, some system
identification (hardware, OS, version, ...)
might also be interesting.

Re: File identification problem.

Yes, sorry.
vms version V8.3-1H1

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

Re: File identification problem.

apologies - that should read 'dir' not 'dil'.
Robert Gezelter
Honored Contributor

Re: File identification problem.

Dave,

Could you please try:

$ DIR SY0:[CUP.LIVE.DAT]ITLEXT_25083.NORMAL;0

and

$ DIR SY0:[CUP.LIVE.DAT]ITLEXT_25083.NORMAL;-1

Also, please do a SHOW PROCESS/ALL (for starters, I suggest SHOW PROCESS/CASE/PARSE; but the other information may be useful later, so it is worth doing it once).

- Bob Gezelter, http://www.rlgsc.com
Steven Schweda
Honored Contributor

Re: File identification problem.

> apologies - that should read 'dir' not 'dil'.

But if it did, then I'd expect different
(less) output. Around here, for example:

alp $ dir fred.lis

Directory ALP$DKA0:[SMS]

fred.LIS;2

Total of 1 file.


show symbol dil ! (Or "dir", ...)

> [...] exactly what you're doing [...]

Still a mystery.
tsgdavid
Frequent Advisor

Re: File identification problem.

Is it possible that the file is installed with the INSTALL utility? If a file is installed, VMS looks for the version that is installed. If you include a semi-colon in the file spec, it ignores the installed file information.

Dave Williams

Re: File identification problem.

;0 and ;-1 yields 'no files found'.

Show process/case/parse result:

7-JAN-2011 14:10:43.74 User: OPS2 Process ID: 0000058D
Node: VISLIV Process name: "_TNA13:"

Parse Style: Extended

Case Lookup: Blind
tsgdavid
Frequent Advisor
Solution

Re: File identification problem.

Have you tried copying the file to a new directory (using ;1)? I am wondering if your directory file is corrupted.

Have you tried ANALYZE/DISK/REPAIR on the disk volume?
tsgdavid
Frequent Advisor

Re: File identification problem.

Oops, I guess the COPY would be without the ";1".

I would also suggest doing a DIR/FULL on the file.
Hoff
Honored Contributor

Re: File identification problem.

It appears distinctly possible somebody has a DCL symbol for the DIRECTORY command, and have gotten that wrong somehow. Post the following:

$ 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

Re: File identification problem.

We have resolved this issue.
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.
Hoff
Honored Contributor

Re: File identification problem.

This reeks of a file system or directory cache or volume corruption.
John McL
Trusted Contributor

Re: File identification problem.

How did you identify that certain files were still corrupt after the reboot?

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.
John Gillings
Honored Contributor

Re: File identification problem.

Dave,

>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.
A crucible of informative mistakes

Re: File identification problem.

You are right, the reboot didn't fix anything.
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.
GuentherF
Trusted Contributor

Re: File identification problem.

Dave,

"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
GuentherF
Trusted Contributor

Re: File identification problem.

And btw. this is neither a problem with OpenVMS file identification nor are these corrupted files.

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
P Muralidhar Kini
Honored Contributor

Re: File identification problem.

Hi Dave,

>> 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 !to get a better formatted output

The above data would help in analysis from file system point of view.

Regards,
Murali
Let There Be Rock - AC/DC

Re: File identification problem.

'dil' is a symbol set up inhouse;
dil == "directory/size=all/date"

Hoff
Honored Contributor

Re: File identification problem.

Barring cases of operational errors...

This (still) reeks of a file system or directory cache or volume corruption, or of a nasty executive-mode file system or I/O caching bug, of a memory or processor error, or an un-shadowed disk block error, or of a controller- or clustering- or firmware-related issue within the storage.

And no, these sorts of cases variously won't end well.

While I disagree with John G's position on the need to reboot servers (IMO, striving for longer server uptimes can be a deceptively poor practice, and longer uptimes can be one of the better outward signs of lurking managerial, operational and application stability issues), I do agree with John here; that a reboot should not be expected to fix cases such as this one.
GuentherF
Trusted Contributor

Re: File identification problem.

Now that the "dil" mystery has been lifted I go with Murali on looking at an on-disk directory corruption. The right comand to folow this would have been:

$ DUMP/DIRECTORY SY0:[CUP.LIVE]DAT.DIR

Due to lack of information lemme guess. This is a directory where at high rate temporary files are created/deleted.

Which program/process/procedure (FTP, nfs, who-knows) is creating/deleting these files?

Is this a VMScluster node?

/Guenther
Robert Gezelter
Honored Contributor

Re: File identification problem.

Dave,

I will second Hoff's and Guenther's comments, with the added question of "What is the storage configuration? What disks? What Controllers?

- Bob Gezelter, http://www.rlgsc.com
John McL
Trusted Contributor

Re: File identification problem.

As 'tsgdavid' said earlier, an ANALYZE/DISK would be useful.

I wouldn't use /REPAIR immediately. Run it without first in order to understand the magnitude of the problem. It shouldn't take much more than 5 minutes to run unless things are very sick.

Also, are you running a defragger on the disk in question? I have seen instances where defraggers corrupted files, but admittedly not for several years.

Finally, how is the disk used and with what kind of IO rates? The symptoms you described could occur if there's a job that renames files and you happened to find the file just before the rename but when you looked again it couldn't be found under the old name.
P Muralidhar Kini
Honored Contributor

Re: File identification problem.

Dave,
I agree with John that ANALYZE/DISK without /REPAIR should be done first.
However if you plan to run ANALYZE/DISK without the /REPAIR qualifier
then I would recommend using /LOCK qualifier to avoid any false alarms.

John,
>> Also, are you running a defragger on the disk in question?
>> I have seen instances where defraggers corrupted files, but
>> admittedly not for several years.
This sounds interesting.
Can you give me some more details about which (DFO, DFU ...), how
(any scenarios) defraggers can cause a directory file to get corrupted.

Regards,
Murali
Let There Be Rock - AC/DC