🚀 go-pugleaf

Thanks guys - the latest postings on this thread have confirmed that using
$EXTEND on INDEXF.SYS is *UNSAFE*, and has thrown up some interesting tidbits.
By way of summary:

(a) INIT/HEADER=nnnnn pre-allocates nnnnn headers in INDEXF.SYS. Apparently,
    from VMS 5.5-2 up, BACKUP no longer truncates INDEXF.SYS on IMAGE restore.
    At last!!

(b) The following looks to me like a real neat trick for drastically enlarging
     your INDEXF.SYS, up to the point where it runs out of headers or your
     disk is irredeemably fragmented:

> A quick and dirty fix if you spot this in advance is to
> $ SET VOLUME/EXTENSION=20000 disk$whatever then create some files
> to cause an extension of indexf.sys by 20000 blocks..
>
> Alan Greig                            Janet: Alan@UK.AC.DUNDEE-TECH

   Alan - you're too modest. I wish I'd thought of this one!

(c) I was lucky when I used $EXTEND on INDEXF.SYS, it WAS immediately after
    a BACKUP so that there weren't lots of small extents to cause INDEXF.SYS
    extents to overflow. (b) looks much  preferable, in all circumstances.
    I intuited that it was dangerous, but never thought through to why. I
    certainly wouldn't have tried if I hadn't still had the original disk that
    I'd BACKUP'ed from!

(d) I repeat my plea to DEC, despite the fix to BACKUP (which itself is
    most welcome. Reasoning:

> >I do wish DEC would fix the INDEXF.SYS extension algorithm. Wouldn't setting
> >the extend quantity to the maximum of 1000 or 20% of the INITIALIZE size of
> >INDEXF.SYS be a lot more sane?
>
> Heck, why not give us an INITIALIZE switch that lets us preallocate the
> whole darn thing and be done with it!  (And fix BACKUP to not truncate INDEXF
> on restore!)

Not good enough. A naive sysmgr is likely to INIT a new disk with all
defaults and feed it to his users. The INDEXF extend trouble strikes a lot
later and causes much downtime while the problem is diagnosed, the disk
backed up and restored, and the consequential foul-ups repaired. This sort
of thing gets VAX/VMS a bad name.

                Nigel Arnot

                NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
                NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)