home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18027 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  3.8 KB
  1. Path: sparky!uunet!ukma!wupost!usc!news!shrike.irvine.com!adam
  2. From: adam@irvine.com (Adam Beneschan)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Fixing SYSTEM-W-HEADERFULL error
  5. Message-ID: <Bxtnn5.E15@irvine.com>
  6. Date: 16 Nov 92 18:35:29 GMT
  7. Sender: usenet@irvine.com (News Administration)
  8. Organization: Irvine Compiler Corp., Irvine, California, USA
  9. Lines: 86
  10.  
  11.  
  12. In <BxoMzw.Jx9@irvine.com> I wrote:
  13.  
  14. > Our situation:  We have a Vaxstation 4000 model 60, VMS version V5.5,
  15. > 1 gigabyte SCSI drive.  There are 49112 files on our system, and our
  16. > INDEXF.SYS file is 49190 blocks.  (Each header in INDEXF.SYS is 1
  17. > block, so it's not surprising that these figures are close.)  If we
  18. > say SHOW DEVICE/FULL, it says the maximum number of files is about
  19. > 257000.  
  20. > 
  21. > Our problem is that we can't create any new files on the system.  If
  22. > we try to use the CREATE command to create a new file, we get this
  23. > error message:
  24. > 
  25. > %DCL-E-OPENOUT, error opening DKA200:[VM.INTEL.74.JUNK]X313.DAT; as output
  26. > -RMS-E-CRE, ACP file create failed
  27. > -SYSTEM-W-HEADERFULL, file header is full
  28. > . . . .
  29. > We think the problem is that the system is trying to enlarge the
  30. > INDEXF.SYS file and can't.
  31. > 
  32.  
  33. Thanks to Carl, Neil, Hans, Bob, Steve, and Aaron who took the trouble
  34. to e-mail responses to me.  Thanks also to anyone else who sent me a
  35. response after I started writing this post.
  36.  
  37. To summarize what I've received:
  38.  
  39. Basically, INDEXF.SYS is allowed only 53 extents (as I understand it,
  40. each extent is one contiguous block of storage).  Unlike other files,
  41. INDEXF.SYS and other *.SYS files cannot be given an extension header
  42. to hold more extents.  Doing BACKUP/IMAGE to back up the disk, and
  43. then BACKUP/IMAGE again to restore it, solved our problem.  Before
  44. doing this, we did
  45.     $ DUMP/HEADER/BLOCK=COUNT=0 [000000]INDEXF.SYS
  46. and counted the Retrieval Pointers in the "Map area" part of the dump
  47. to verify that there were 53 pointers.  After the backup and restore,
  48. we did this again and found only 3 or 4 pointers.
  49.  
  50. Other suggestions I've received:
  51.  
  52. -- Get a disk defragmenter.
  53.  
  54. -- INIT the disk with a large value for /HEADERS, causing INDEXF.SYS
  55.    to be pre-allocated with whatever number of headers we ask for.
  56.  
  57. -- Initialize another disk with a larger value for /MAXIMUM_FILES,
  58.    then backup the entire disk onto that one.
  59.  
  60. Carl gave me these instructions:
  61.  
  62. > Immediately after you finish the BACKUP/RESTORE:
  63. >     1)    Find out what the default extend quantity is for the disk by
  64. >     using the SHOW DEVICE/FULL command;
  65. >     2)    Set the default extend quantity to some enormous number 
  66. >       (can't be more
  67. >     than 65535; you don't want it to be any larger than approximately the
  68. >     difference between the maximum files allowed for the volume and the
  69. >     size of INDEXF.SYS) using the SET VOLUME/EXTENSION command;
  70. >     3)    Create lots of empty files, until you've forced extension of 
  71. >       INDEXF.SYS,
  72. >     then delete the empty files.  The following procedure should do it:
  73. >     $    SIZ = F$FILE("[000000]INDEXF.SYS", "ALQ")
  74. >     $    N = 0
  75. >     $ LOOP:    COPY NL: 'F$FAO("!8ZL", N)'.
  76. >     $    IF F$FILE("[000000]INDEXF.SYS", "ALQ") .GT. SIZ THEN GOTO DELE
  77. >     $    N = N + 1
  78. >     $    GOTO LOOP
  79. >     $ DELE:    DELETE 'N'.;
  80. >     $    IF N .EQ. 0 THEN EXIT
  81. >     $    N = N - 1
  82. >     $    GOTO DELE
  83. >     4)    Set the default extend quantity back to what you found in 
  84. >       step 1.
  85. > The procedure in step 3 may take a fair amount of time to complete.  You
  86. > probably want to execute the procedure from an empty directory.  The delete
  87. > loop is there because if you've ended up creating a lot of files, repeated
  88. > invocation of the DELETE command to delete the files in decreasing 
  89. > alphabetical order will be faster than deleting them all with a single 
  90. > DELETE command.  Hope this helps.
  91. > 
  92.  
  93. Aaron also pointed out that this subject was discussed about three
  94. months ago and there's more information in the archives.
  95.  
  96.                                 -- Thanks, Adam
  97.