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: 

Anal/dis/rep/read

 
Wim Van den Wyngaert
Honored Contributor

Anal/dis/rep/read

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
Wim
30 REPLIES
Bojan Nemec
Honored Contributor

Re: Anal/dis/rep/read

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
Uwe Zessin
Honored Contributor

Re: Anal/dis/rep/read

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:
.
Wim Van den Wyngaert
Honored Contributor

Re: Anal/dis/rep/read

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 ?
Wim
Uwe Zessin
Honored Contributor

Re: Anal/dis/rep/read

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?
.
labadie_1
Honored Contributor

Re: Anal/dis/rep/read

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

Re: Anal/dis/rep/read

a little improvement

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

gives File name: XXX

:-)

Wim Van den Wyngaert
Honored Contributor

Re: Anal/dis/rep/read

All,

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

So, why wasn't the name debug.exe given by anal ?
Wim
labadie_1
Honored Contributor

Re: Anal/dis/rep/read

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
Wim Van den Wyngaert
Honored Contributor

Re: Anal/dis/rep/read

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
Wim
labadie_1
Honored Contributor

Re: Anal/dis/rep/read

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

Ian Miller.
Honored Contributor

Re: Anal/dis/rep/read

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?
____________________
Purely Personal Opinion
Wim Van den Wyngaert
Honored Contributor

Re: Anal/dis/rep/read

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
Wim
Hein van den Heuvel
Honored Contributor

Re: Anal/dis/rep/read

>>> 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.





Uwe Zessin
Honored Contributor

Re: Anal/dis/rep/read

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).
.
Bojan Nemec
Honored Contributor

Re: Anal/dis/rep/read

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
Wim Van den Wyngaert
Honored Contributor

Re: Anal/dis/rep/read

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

Wim
Wim
Uwe Zessin
Honored Contributor

Re: Anal/dis/rep/read

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.
.
faris_3
Valued Contributor

Re: Anal/dis/rep/read

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
Wim Van den Wyngaert
Honored Contributor

Re: Anal/dis/rep/read

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
Wim
Ian Miller.
Honored Contributor

Re: Anal/dis/rep/read

when the bad debug.exe was deleted then any bad blocks would have been transparently revectored so when the disk was filled with the temp file and all blocks read then no bad blocks where found.
____________________
Purely Personal Opinion
faris_3
Valued Contributor

Re: Anal/dis/rep/read

Or put in badblk.sys depending on the controller type :

See
[OpenVMS] How are Bad Block Handled on SCSI Disk Devices?

http://h18000.www1.hp.com/support/asktima/operating_systems/009370EE-0A09ACC0-1C009F.html
Wim Van den Wyngaert
Honored Contributor

Re: Anal/dis/rep/read

Rather strange findings.

VMS 7.3 on AStation 500.

Do type of file : parity error.
Defragmenter : aborts when it tries to defragment the file.
Dia reports "MEDIUM ERROR".

ana/dis/read : reports nothing !!!

If I do delete/erase of the file another file created after the delete gets corrupted.

So : bad blocks are not always handled correctly.

I renamed the last corrupted file to .badblocks and marked it with set file/nomov. Defragmenter is now happy. This seems the only working solution.

Wim
Wim
Uwe Zessin
Honored Contributor

Re: Anal/dis/rep/read

You could also set it to /NOBACKUP so that its contents are not read during backups.
.
Vladimir K. Vershinin
Frequent Advisor

Re: Anal/dis/rep/read

And BACKUP and RESTORE disk contents.

Vladimir Vershinin