home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18283 < prev    next >
Encoding:
Text File  |  1992-11-20  |  2.6 KB  |  60 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!Sirius.dfn.de!gwdu03.gwdg.de!gwdgv1.gwdg.de!MOELLER
  3. From: moeller@gwdgv1.gwdg.de
  4. Subject: Re: re^2: extending INDEXF.SYS (new idea!)
  5. Message-ID: <AA48Q3E@gwdu03.gwdg.de>
  6. Sender: news@gwdu03.gwdg.de (USENET News System)
  7. Nntp-Posting-Host: gwdgv1.gwdg.de
  8. Reply-To: moeller@gwdgv1.gwdg.de
  9. Organization: GWDG Goettingen, F.R.Germany
  10. References: <9211170506.AA25540@ucbvax.Berkeley.EDU>
  11. Date: Sat, 21 Nov 1992 00:45:32 GMT
  12. Lines: 46
  13.  
  14. In article <9211170506.AA25540@ucbvax.Berkeley.EDU>, I wrote:
  15. >Some time ago, there was some discussion re: pre-extending INDEXF.SYS,
  16. >and the consensus was, that one has to be very careful,
  17. >so that INDEXF.SYS won't become a multi-header file by any chance.
  18. >
  19. >It occurred to me that there is a VMS utility for extending files,
  20. >which *has* that important check built-in:
  21. >
  22. >  $ MCR SYSGEN CREATE disk:[000000]INDEXF.SYS/size=<newsize>
  23. >[...]
  24.  
  25. Sorry, it wasn't a good idea - please forget it!
  26.  
  27. Basically SYSGEN CREATE does the right thing by extending a file with
  28. FIB$M_NOEXTHDR, which avoids getting a multi-header file.
  29.  
  30. But there several problems:
  31.  
  32. A minor one was noted by D.Jones, in that any extend operation 
  33. probably won't update the alternate index file header
  34. (which allows recovery from a damaged primary header);
  35. ANALYZE/DISK/REPAIR should fix that - often that's a good idea anyway.
  36.  
  37. Unfortunately, SYSGEN does two more things:
  38.  
  39. (a) the equivalent of SET FILE/NOBACKUP (noted by simons/G=Colin/...)
  40.     I doubt that this would be a problem, because BACKUP saves INDEXF.SYS
  41.     "file header only" anyway (look at your BACKUP Journal!).
  42.  
  43. (b) the equivalent of SET FILE/END_OF_FILE, i.e. it explicitly sets
  44.     the logical end-of-file mark to the highest block allocated 
  45.     This isn't desirable anyway (makes INDEXF scans slow);
  46.     unless the disk is being used for the first time, 
  47.     there's also a good chance for some of the blocks 
  48.     formerly beyond e-o-f in fact to look like valid file headers
  49.     (from a previous copy of INDEXF.SYS, which usually occupies
  50.     the same disk blocks after a re-INITialization).
  51.     Run ANALYZE/DISK/REPAIR, and you suddenly have lots of 
  52.     "multiply allocated blocks" (due to re-appearing "lost" files)!
  53.  
  54. Just yesterday I received VMS 5.5-2; if BACKUP/NOINIT now finally does
  55. the Right Thing, exteding INDEXF.SYS may become a topic of the past.
  56.  
  57. Wolfgang J. Moeller, GWDG, D-3400 Goettingen, F.R.Germany | Disclaimer ...
  58. PSI%(0262)45050352008::MOELLER      Phone: +49 551 201516 | No claim intended!
  59. Internet: moeller@gwdgv1.dnet.gwdg.de   | This space intentionally left blank.
  60.