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