From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 23-JUN-1994 12:07:48.66 To: EVERHART CC: Subj: Re: PROBLEM: File Size Is Too Small!!! From: vandenheuvel@eps.enet.dec.com (Hein RMS van den Heuvel) X-Newsgroups: comp.os.vms Subject: Re: PROBLEM: File Size Is Too Small!!! Date: 9 JUN 94 13:22:02 Organization: Digital Equipment Corporation Lines: 32 Message-Id: <2t7k3b$j4g@jac.zko.dec.com> Nntp-Posting-Host: EPSYS To: Info-VAX@CRVAX.SRI.COM X-Gateway-Source-Info: USENET In article , dyson@sunfish.physics.uiowa.edu (Richard L. Dyson) writes... >VMS/RMS Experts, > > I have a perplexing problem that I would like to see if someone >can help me solve. It involves files that seem to have "used" sizes >significantly smaller than the "allocated" size. BUT wait! The data is >actually present in the disk file's allocated space. > For open, shared sequential files, the true end-of-file is maintained in the lock value block for the file lock. A stale EOF is recorded in the file header and is updated on every CLOSE or $FLUSH. A shared reader can of course 'see' all data up to the true EOF. However, a DIR/FULL only displays the information from the file header as you observed. Should for some reason the system fail to properly close the file, then the EOF value on disk may remain stale. The 'missing' data can in that case be found back by issuing the SET FILE/END command or similar. [PIP /EF:vbn:byte or on VMS V6.0 SET FILE/ATTR=(EBK:nnn, FFB:mmm) ] To prevent such problems and/or control the extend of the damage, please consider adding a time and/or data_volume based SYS$FLUSH call to the application. The RAB needed for this call can be obtained through FOR$RAB(). To monitor the EOF maintenance on a live system, check out ANAL/SYSTEM; SET PROCESS "your writer"; SHOW PROC/RMS=SFSB Hope this helps, +--------------------------------------+ | All opinions expressed are mine, and | Hein van den Heuvel | may not reflect those of my employer | vandenheuvel@eps.enet.dec.com +--------------------------------------+