topic Re: Anal/dis/rep/read in Operating System - OpenVMS

Anal/dis/rep/read

Wim Van den Wyngaert — Mon, 04 Oct 2004 01:55:56 GMT

I do anal/dis/rep/read on a station with 1 disk.
I get :

ANALDISK-W-READFILE (2126,1,0)
error reading VBN325
SYSTEM-F-PARITY, parity error

I thought this was a temporary file but after a reboot I get the same result (same fileid).

How is this possible ? How can I delete and recreate this file ?

Wim

Re: Anal/dis/rep/read

Bojan Nemec — Mon, 04 Oct 2004 02:20:07 GMT

Hi,

Can you find out which file is this? Have you try:

$ PIPE DIR/FILE/NOHEAD/COL=1 disc:[*...] | SEA SYS$PIPE "(2126,1,0)"

Or there is an LOSTHEADER for this file?

Bojan

Re: Anal/dis/rep/read

Uwe Zessin — Mon, 04 Oct 2004 02:22:27 GMT

You normally get prompted to recover lost files to [SYSLOST]. I would first try and find out a bit more about the file, perhaps it is entered in a directory anyway and you have discovered a bug:

$ dump/header/blocks=count=0/identifier=(11516,7,0) dsa0:

Re: Anal/dis/rep/read

Wim Van den Wyngaert — Mon, 04 Oct 2004 02:28:50 GMT

Bojan,

Did that with output to a file and searched the file (pipe doesn't allow /window and with your statement you don't see the name).

Result : debug.exe.

Why didn't anal/dis/rep/read report this name and dir did ?

Uwe : I specified /repair. So if it was lost : it should get repaired. No ?

Re: Anal/dis/rep/read

Uwe Zessin — Mon, 04 Oct 2004 02:38:40 GMT

Ah, I see that you did not specifiy /CONFIRM. In that case you don't get prompted and lost files usually get automatically entered in [SYSLOST], but as I already wrote: you might have discovered a bug in VMS.

Have you tried the command I gave you? Did you get any useful output?

Re: Anal/dis/rep/read

labadie_1 — Mon, 04 Oct 2004 02:43:48 GMT

Uwe answer is perfectly correct, but I like DFU
$ mc dfu
search disk/fid=(2126)

Re: Anal/dis/rep/read

labadie_1 — Mon, 04 Oct 2004 02:49:02 GMT

a little improvement

$ pipe dump/header/block=count=0/ident=(14633,1,0) dra1: | sea sys$pipe "File name:"

gives File name: XXX

:-)

Re: Anal/dis/rep/read

Wim Van den Wyngaert — Mon, 04 Oct 2004 03:01:33 GMT

All,

I recreated debug.exe. No more parity errors now.

So, why wasn't the name debug.exe given by anal ?

Re: Anal/dis/rep/read

labadie_1 — Mon, 04 Oct 2004 03:28:06 GMT

I find in the doc

ANALYZE/DISK_STRUCTURE Output

------------------------
By default, the Analyze/Disk_Structure utility directs all output to your terminal. If you prefer, you can use the /LIST qualifier to generate a file containing the following information for each file on the disk:

File identification (FID)
File name
Owner
Errors associated with the file

-----------------------

so you shoud add /list to get the file name

source:
http://www.pi-net.dyndns.org/docs/openvms0731/731final/6048/6048pro_005.html

Re: Anal/dis/rep/read

Wim Van den Wyngaert — Mon, 04 Oct 2004 03:42:25 GMT

Gerard,

I think this is not correct. /list will give you a list of all files.

Normally, anal will report the file name. For some unknown reason it didn't (corruption ?). The dir command is getting its info elsewere and did find the name.

So, why didn't anal report the file name ?

Wim

Re: Anal/dis/rep/read

labadie_1 — Mon, 04 Oct 2004 03:59:39 GMT

Well I do not know.

The example in the doc has files by file-id and file name, with the same lostheader message.

%VERIFY-W-LOSTHEADER, file (16,1,1) []X.X;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (17,1,1) []Y.Y;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (18,1,1) []Z.Z;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (19,1,1) []X.X;2
not found in a directory
%VERIFY-W-LOSTHEADER, file (20,1,1) []Y.Y;2
not found in a directory
%VERIFY-W-LOSTHEADER, file (21,1,1) []Z.;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (22,1,1) []Z.;2
not found in a directory
%VERIFY-W-LOSTHEADER, file (23,1,1) LOGIN.COM;163
not found in a directory
%VERIFY-W-LOSTHEADER, file (24,1,1) MANYACL.COM;1
not found in a directory

Gerard, puzzled

Re: Anal/dis/rep/read

Ian Miller. — Mon, 04 Oct 2004 06:23:00 GMT

Re /LIST - according to the manual - lists all files. "If you specify /LIST, the utility produces a file that contains a listing of ALL file identifications (FIDs), file names, and file owners.". Not a particularly useful feature generally.

The original problem is fixed but what you are commenting on now is why the utility did not give the filename as well as the fileid in the original message - is that correct?

Re: Anal/dis/rep/read

Wim Van den Wyngaert — Mon, 04 Oct 2004 06:25:34 GMT

Yes Ian. Normally the name is not given if the file is temporary (t.i. already deleted but still open) or spooled (don't know how that works in detail).

Wim

Re: Anal/dis/rep/read

Hein van den Heuvel — Mon, 04 Oct 2004 06:27:09 GMT

>>> The example in the doc has files by file-id and file name, with the same lostheader message.

But this topic was not about a 'lostheader'.
It was triggered by the /read telling analyze to read all allocated blocks on the disk.
One of those was bad reporting an IO problem

Wim, I would not expect a bad block to clear over a reboot. If it was in a temp file, and that file was deleted, then analyze would not need to re-read and that could hide the problem.
If after reboot the block is re-used (for an other, or for 'the same' file), then the write operation may actually trigger clearing the problem (relocating the disk block).

>> I recreated debug.exe. No more parity errors now.

As per above... deleting the old file would have been needed to hide it, rewrite to clear it.

>> So, why wasn't the name debug.exe given by anal ?

Good question! Sorry, no answer.

Btw 1... DUMP/HEAD is the only command that does not need file-number + file-id. Just a file number will do.

Btw 2... other then the file name, you may want to use the mapping table in the header to determine whcih physical block was mapped by vbn 325.

Hein.

Re: Anal/dis/rep/read

Uwe Zessin — Mon, 04 Oct 2004 06:36:45 GMT

A file that was created through the spooling mechanism is never entered into a directory. It can have a name recorded in the file header anyway - that is why you can see []BLA.DAT;1

When you delete an open file, sometimes just the directory entry is removed - the file header is maked unused when the file is really closed. A 'temporary' file is one that never was entered into a directory - there is an option that can be specified on file CREATE. I am sure the spooling mechanism uses the same feature.

Again, the behaviour of ANALDISK looks like a bug to me. It is very likely that nobody of us can answer your persistent 'why'. You have to talk with the maintainer (HP).

Re: Anal/dis/rep/read

Bojan Nemec — Mon, 04 Oct 2004 10:40:09 GMT

Wim,

Sorry for the wrong pipe, I should test it.

My opinion is, that anal reads the indexfile and dir reads the directory. Both files contains the file name and the file id.

So, as Uwe suggested, try to look to the dump/head (this is the dump of the index file). Examine the file name and the back link file (it should point to the directory).

Was that the current sys$share:debug.exe or maybe it was a remaining of some VMS upgrade?

Bojan

Re: Anal/dis/rep/read

Wim Van den Wyngaert — Mon, 04 Oct 2004 13:04:20 GMT

Yes it was sys$share. Maybe the name wasn't given because the file was corrupt ?
I will keep an eye on it.

Wim

Re: Anal/dis/rep/read

Uwe Zessin — Mon, 04 Oct 2004 13:13:43 GMT

Hm...
Sorry, but that does not sound plausible to me. We're talking about corruption _inside_ a file, not in the file system's structure. If the file is properly linked from a directory I think the full path should be displayed to make the whole handling easy for the user.

Re: Anal/dis/rep/read

faris_3 — Tue, 05 Oct 2004 04:27:50 GMT

Hi,

You may try to check if you have a problem
on the free blocks now.

Fill the disk

$ copy nl: tempfile /alloc=free_blocks_on_disk

$ set file /end tempfile

$analyze /disk/read ...

hth,
HF

Re: Anal/dis/rep/read

Wim Van den Wyngaert — Tue, 05 Oct 2004 05:06:05 GMT

Uwe,

I don't know how the program is written but may be it doesn't always do the effort for looking for the file name after a parity error.

Farris,

Did somethink like that. No extra bad blocks.

All,

Maybe the disk should have been filled in the farris way before the OS was installed. Or maybe we should have used some kind of read check option during install.

Wim