From: adam@irvine.com (Adam Beneschan)
Newsgroups: comp.os.vms
Subject: Re: Fixing SYSTEM-W-HEADERFULL error
Date: 16 Nov 92 18:35:29 GMT
Organization: Irvine Compiler Corp., Irvine, California, USA


In <BxoMzw.Jx9@irvine.com> I wrote:

> Our situation:  We have a Vaxstation 4000 model 60, VMS version V5.5,
> 1 gigabyte SCSI drive.  There are 49112 files on our system, and our
> INDEXF.SYS file is 49190 blocks.  (Each header in INDEXF.SYS is 1
> block, so it's not surprising that these figures are close.)  If we
> say SHOW DEVICE/FULL, it says the maximum number of files is about
> 257000.  
> 
> Our problem is that we can't create any new files on the system.  If
> we try to use the CREATE command to create a new file, we get this
> error message:
> 
> %DCL-E-OPENOUT, error opening DKA200:[VM.INTEL.74.JUNK]X313.DAT; as output
> -RMS-E-CRE, ACP file create failed
> -SYSTEM-W-HEADERFULL, file header is full
> . . . .
> We think the problem is that the system is trying to enlarge the
> INDEXF.SYS file and can't.
> 

Thanks to Carl, Neil, Hans, Bob, Steve, and Aaron who took the trouble
to e-mail responses to me.  Thanks also to anyone else who sent me a
response after I started writing this post.

To summarize what I've received:

Basically, INDEXF.SYS is allowed only 53 extents (as I understand it,
each extent is one contiguous block of storage).  Unlike other files,
INDEXF.SYS and other *.SYS files cannot be given an extension header
to hold more extents.  Doing BACKUP/IMAGE to back up the disk, and
then BACKUP/IMAGE again to restore it, solved our problem.  Before
doing this, we did
    $ DUMP/HEADER/BLOCK=COUNT=0 [000000]INDEXF.SYS
and counted the Retrieval Pointers in the "Map area" part of the dump
to verify that there were 53 pointers.  After the backup and restore,
we did this again and found only 3 or 4 pointers.

Other suggestions I've received:

-- Get a disk defragmenter.

-- INIT the disk with a large value for /HEADERS, causing INDEXF.SYS
   to be pre-allocated with whatever number of headers we ask for.

-- Initialize another disk with a larger value for /MAXIMUM_FILES,
   then backup the entire disk onto that one.

Carl gave me these instructions:

> Immediately after you finish the BACKUP/RESTORE:
>     1)	Find out what the default extend quantity is for the disk by
> 	using the SHOW DEVICE/FULL command;
>     2)	Set the default extend quantity to some enormous number 
>       (can't be more
> 	than 65535; you don't want it to be any larger than approximately the
> 	difference between the maximum files allowed for the volume and the
> 	size of INDEXF.SYS) using the SET VOLUME/EXTENSION command;
>     3)	Create lots of empty files, until you've forced extension of 
>       INDEXF.SYS,
> 	then delete the empty files.  The following procedure should do it:
> 	$	SIZ = F$FILE("[000000]INDEXF.SYS", "ALQ")
> 	$	N = 0
> 	$ LOOP:	COPY NL: 'F$FAO("!8ZL", N)'.
> 	$	IF F$FILE("[000000]INDEXF.SYS", "ALQ") .GT. SIZ THEN GOTO DELE
> 	$	N = N + 1
> 	$	GOTO LOOP
> 	$ DELE:	DELETE 'N'.;
> 	$	IF N .EQ. 0 THEN EXIT
> 	$	N = N - 1
> 	$	GOTO DELE
>     4)	Set the default extend quantity back to what you found in 
>       step 1.
> The procedure in step 3 may take a fair amount of time to complete.  You
> probably want to execute the procedure from an empty directory.  The delete
> loop is there because if you've ended up creating a lot of files, repeated
> invocation of the DELETE command to delete the files in decreasing 
> alphabetical order will be faster than deleting them all with a single 
> DELETE command.  Hope this helps.
> 

Aaron also pointed out that this subject was discussed about three
months ago and there's more information in the archives.

                                -- Thanks, Adam
Xref: sparky comp.os.vms:18292 vmsnet.sources.d:693