From:	SMTP%"MACRO32%WKUVX1.BITNET@uu7.psi.com"  3-JUN-1993 09:29:51.49
To:	EVERHART
CC:	
Subj:	Re: What is the overhead for the /HIGHWATER volume qualifier ?

X-Listname: "VMS Internals, MACRO, & BLISS Discussions" <MACRO32@WKUVX1.BITNET>
Warnings-To: <>
Errors-To: MacroMan%WKUVX1.BITNET@uu7.psi.com
Sender: MacroMan%WKUVX1.BITNET@uu7.psi.com
Date: 03 Jun 1993 09:37:40 +0000 (GMT)
From: "Jess C. Goodman" <GOODMAN%ACCUWX.COM@ULKYVM.LOUISVILLE.EDU>
Reply-To: MACRO32%WKUVX1.BITNET@uu7.psi.com
Subject: Re: What is the overhead for the /HIGHWATER volume qualifier ?
To: MACRO32@WKUVX1.BITNET
Message-Id: <01GYXJ445KYU9VURR3@accuwx.com>
X-Vms-To: IN%"MACRO32%WKUVX1.BITNET@ULKYVM.LOUISVILLE.EDU"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Peter Lauterbach (peterl%progress.COM@ULKYVM.LOUISVILLE.EDU)  writes:
>        What's the real deal, and are you paying a performance hit for
>        having high-water marking enabled ? If so, in what cases ?

You are almost always paying a performance hit with high-water marking;
whenever you allocate blocks to a file the file system first erases them.

The only exception is when a sequential-organization file is opened unshared
with sequential-only access; only then does the file system use "true" high-
water marking.  Instead of pre-erasing blocks it prevents you from reading past
the last block that you have written.  But it does not return an error if
you do this - the bytes of the input buffer that correspond to the blocks
read past the high-water mark will be zeroed out.

After the file is closed if its high-water mark is before the last allocated
block then all read-only accessers of the file will "read" zeroes if they
read past the high-water mark.

If the next open for write-access to the file is not for unshared, sequential-
only access as before then the file system erases these previously allocated
blocks that were past the high-water mark as part of the open.

But the "gotcha" with "true" high-water marking is what is meant by
"sequential-only" access.  A high-level language OPEN such as a Fortran
"OPEN( UNIT=n, ACCESS='SEQUENTIAL', ...) does *not* qualify!!!

To be considered sequential-only the undocumented bit FIB$V_SEQONLY must be
set in the FIB$L_ACCTL field of the File Information Block.  This is easily
done with RMS by setting the FAB$V_SQO bit in the FAB$L_FOP field of the
File Information Block.

Very few applications set this bit even if they are accessing the file only
sequentially.  This is too bad because, besides enabling true high-water
marking, it also optimizes DECnet access to the file.

To check if a application has a file opened sequential-only check the
WCB$V_SEQONLY bit in the WCB$W_ACON field of the Window Control Block
or use Edward A. Heinrich's FILES_INFO program.