Operating System - OpenVMS
1748109 Members
4146 Online
108758 Solutions
New Discussion юеВ

Re: inconsistent highwater mark and EFBLK

 
SOLVED
Go to solution
John Abbott_2
Esteemed Contributor

Re: inconsistent highwater mark and EFBLK

Here you go Volker...

J.

Don't do what Donny Dont does
John Abbott_2
Esteemed Contributor

Re: inconsistent highwater mark and EFBLK

One thing wrong... the file entry link count is zero.
Don't do what Donny Dont does
Jim_McKinney
Honored Contributor

Re: inconsistent highwater mark and EFBLK

And the "Highest block written" (value 0) does not match the "Highest block" (value 488664) - presumably a side effect of BACKUP restoration on a file that was marked "no backup".
John Abbott_2
Esteemed Contributor
Solution

Re: inconsistent highwater mark and EFBLK

Well spotted Jim !

... and when you do a $ set file/own=[x] foo.bar it writes binary zeros - the highest block written becomes 488664 and the anal/disk msg goes away.

This answers Andreas 2nd post question.

J.
Don't do what Donny Dont does
Andrea Arthur
Occasional Advisor

Re: inconsistent highwater mark and EFBLK

Thank you all for your contributions.
Volker Halle
Honored Contributor

Re: inconsistent highwater mark and EFBLK

Andrea,

this error is absolutley reproducable. Any WRITE access to such a file (a BACKUP of a file marked /NOBACKUP ending up with FH2$L_HIGHWATER=0), even a OPEN/READ/WRITE - although it may fail with an error %DCL-E-INVRFM - causes the file to be overwritten with zeroes and the HIGHWATER field in the file header to be updated.

The VERIFY_INDEX source code explicitly tries to skip reporting BADHIGHWATER for file headers with HIGHWATER=0 (IF ... .header[FH2$L_HIGHWATER] NEQ 0), but this logic somehow does not seem to work too well.

As we've now documented the reason for %ANALDISK-I-BADHIGHWATER and the explanation and workaround, it's time to close this thread.

Volker.
Cass Witkowski
Trusted Contributor

Re: inconsistent highwater mark and EFBLK

before we close this thread...

John said that doing the set file writes zeros on the file and then the highwater mark is not the last block in the file.

Do I really want to write zeros on a in use page or swap file?
Stanley F Quayle
Valued Contributor

Re: inconsistent highwater mark and EFBLK

How about fixing ANALYZE/DISK/REPAIR so it repairs the error?
http://www.stanq.com/charon-vax.html
Volker Halle
Honored Contributor

Re: inconsistent highwater mark and EFBLK

Cass,

only the first and exclusive write accessor would cause the file to be overwritten with zeroes. SET FILE/OWN=xxx PAGEFILE.SYS will return SYSTEM-W-ACCONFLICT, if the pagefile is in use - so no risk here !

Stanley,

making ANAL/DISK/REPAIR 'repair' this error may need it to overwrite the file with zeroes, not sure whether you would want that to happen, as it may severely increase the amount of time for ANAL/DISK/REPAIR to finish and release the volume lock.

The same would apply to the possible idea of 'fixing' BACKUP, this would require BACKUP to overwrite the file with zeroes when restoring a file marked /NOBACKUP - not a good idea.

I would vote for including the message and an explanation and workaround in HELP/MESS BADHIGHWATER

Volker.
Jan van den Ende
Honored Contributor

Re: inconsistent highwater mark and EFBLK

Volker wrote


I would vote for including the message and an explanation and workaround in HELP/MESS BADHIGHWATER


How about making ANAL/DISK smart enough to recognise the mark /NOBACKUP, and just NOT report BADHIGHWATER those files?
After all, it IS just the intended behavior...

just my EUR 0.02

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.