HDTenEightyP/NetNews huggingface dataset:
From: olin@vger.cheme.cornell.edu (Steve Thompson)
Subject: test
Reply-To: olin@vger.cheme.cornell.edu
Organization: Chemical Engineering, Cornell University, NY
Date: Sun, 27 Sep 1992 16:09:57 GMT

test - please ignore

---------------------------------------------------------------------------
Steve Thompson, System Mangler   Internet: thompson@cheme.tn.cornell.edu
School of Chemical Engineering   Bitnet:   thompson@crnlchme
Olin Hall, Cornell University    Phone:    (607) 255 5573
Ithaca NY 14853
---------------------------------------------------------------------------
Newsgroups: vmsnet.networks.management.decmcc
Subject: DECmcc for Ultrix, DECnet/OSI & DNS
From: brockie@golem.wcc.govt.nz (Roger Brockie)
Date: 30 Sep 1992 01:44:28 +1200
Organization: Wellington City Council, Wellington, NZ
NNTP-Posting-Host: golem.wcc.govt.nz

I've just installed the DECmcc BMS product ona RISC Ultrix  box running 
DECnet/OSI, so I can use DNS in case we want to share the data sometime, as
the manual recommends,  but I have a couple of problems.

First. I get nodename conflicts in DNS with the nodes added during the OSI
installation.  How do I get around this ?

Second.  MCC insists on putting the nodenames in the root name space, according
to the DNS manual this should be aviod.  The only way I can see to put them
in subtrees is to create the nodes with names such as decmcc.this_node or
decmcc.dna_phase4.this_node.  But then that name appears in all the windows
on the mcc management station, yuk!.

Has anyone else had these problems, and found acceptable solutions ?
I looking at not using DNS, or worse talking ot DEC ;-).

Thanks in advance,
Roger



-- 
brockie@golem.wcc.govt.nz
From: Dan Wing <DWING@UH01.Colorado.EDU>
Newsgroups: vmsnet.internals
Subject: INDEXF.SYS and BACKUP
Date: 29 Sep 1992 19:03:12 -0600 (MDT)
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

It wasn't a dream ....

I just pulled the VMS V5.5-2 release notes from DSNlink, and section 2.4.4
of the System Manager's chapter mentions that VMS V5.5-2 BACKUP will not
over-write the destination volume's size of INDEXF.SYS during a restore
operation.

-Dan Wing, DWING@UH01.Colorado.EDU or WING_D@UCOLMCC.BITNET (DGW11)
 Systems Programmer, University Hospital, Denver
From: jeh@cmkrnl.com
Newsgroups: vmsnet.internals
Subject: Re: Source CDs
Date: 5 Oct 92 02:09:22 PDT
Distribution: world,local
Organization: Kernel Mode Consulting, San Diego, CA

In article <1992Oct4.042754.4024@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:
>   I don't think the local offices will do any better or worse with listings
> than anything else, provided you give them the part number. Also, I doubt that
> thet could do the right thing for simple stuff, like VAX BASIC.

Ah, there's the rub -- finding the part number.  I've heard many reports from
folks who didn't have the number for the listings CDs, and couldn't convince
their Digital sales rep to look for it, as the rep was convinced that it didn't
exist.  Happens all the time, and is one reason for slow sales of listings
kits.  At one point the part number was quite difficult to find on the
Electronic Store... I could list several other ways in which some folks in DEC
seem to be trying to hide the listings offering under the rug... If *I* were
Digital, I would be making a big point of the fact that VMS listings are
available for only $2K; to my way of thinking this is a big advantage.  I know
of no other hardware-vendor-supported OS (proprietary or otherwise) for which
you can get listings for only $2K. 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: Arne Vajhxj <ARNE@ko.hhs.dk>
Newsgroups: vmsnet.internals
Subject: Re: Program code to SET UIC
Date: 01 Oct 1992 20:51:52 +0100
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

> I need to write a little routine to change UIC for an arbitrary, captive
> user.  Fortunately, INFO-VAX has been following this for the last few days,
> and has produced the following CMKRNL routines:
>
> (1)     .ENTRY  KERNEL, ^M<R2,R3,R4>            ;Save our registers
>         JSB     SMP$GET_CURPCB                  ;Get ther current PCB
>         MOVL    NEWUIC,PCB$L_UIC(R4)            ;Tweak its little UIC
>         MOVZWL  #SS$_NORMAL,R0                  ;Return happy
>         RET                                     ; as a little bird
>
> (2)     .ENTRY  CMKRTN, ^M<>                    ;Registers, what registers
>         MOVL    G^CTL$GL_PCB,R0                 ;GET THE PCB ADDRESS
>         MOVL    UIC, PCB$L_UIC(R0)              ;GET THE NEW UIC
>         MOVL    #SS$_NORMAL,R0                  ;SET OK RETURN CODE
>         RET                                     ;BACK
>
> Personally, I like (2) best, since I cannot see what the hell happens
> when I JSB to SMP$GET_CURPCB (what with no listings or fiche).
>
> I throw this out to the MACRO32 list for ideas and comments.

Both contain unnecesarry code, because

        .ENTRY  XXXXXX,^M<>
        MOVL    UIC,PCB$L_UIC(R4)
        MOVL    #SS$_NORMAL,R0
        RET

is sufficient since R4 contains the PCB address (see the documentation of
SYS$CMKRNL !).

                                                          Arne

Arne Vajhxj                             local DECNET:  KO::ARNE
Computer Department                     PSI:           PSI%23831001304030::ARNE
Business School of Southern Denmark     Internet:      ARNE@KO.HHS.DK
From: lbmoore@tchden.org (Louis B. Moore)
Newsgroups: vmsnet.internals
Subject: Program code to SET UIC
Date: 30 Sep 92 17:29:02 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Greetings,

I need to write a little routine to change UIC for an arbitrary, captive
user.  Fortunately, INFO-VAX has been following this for the last few days,
and has produced the following CMKRNL routines:

(1)     .ENTRY  KERNEL, ^M<R2,R3,R4>            ;Save our registers
        JSB     SMP$GET_CURPCB                  ;Get ther current PCB
        MOVL    NEWUIC,PCB$L_UIC(R4)            ;Tweak its little UIC
        MOVZWL  #SS$_NORMAL,R0                  ;Return happy
        RET                                     ; as a little bird

(2)     .ENTRY  CMKRTN, ^M<>                    ;Registers, what registers
        MOVL    G^CTL$GL_PCB,R0                 ;GET THE PCB ADDRESS
        MOVL    UIC, PCB$L_UIC(R0)              ;GET THE NEW UIC
        MOVL    #SS$_NORMAL,R0                  ;SET OK RETURN CODE
        RET                                     ;BACK

Personally, I like (2) best, since I cannot see what the hell happens
when I JSB to SMP$GET_CURPCB (what with no listings or fiche).

I throw this out to the MACRO32 list for ideas and comments.

Thanks in advance,


 Louis B. Moore                      Internet: lbmoore@tchden.org
 Systems Programmer                  Phone:    +1 303 837 2513
 The Children's Hospital of Denver   Denver, Colorado USA 80218
From: SYSMGR@IPG.PH.KCL.AC.UK
Newsgroups: vmsnet.internals
Subject: re: VMS shareable images, what's wrong with them?
Date: 30 Sep 92 11:49:17 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

> DEC ought to redo their shareable-image technology. The current method
> was invented almost 15 years ago and has a variety of problems.
>
> Garry Wiegand --- garry@ithaca.com --- Ithaca Software, Alameda, California

Garry,
        I'm curious. I know that making a shareable image can be tedious,
but once put together they seem to work rather well. What improvements
do you have in mind, and has anyone done something like them already?

        Yours,
                Nigel Arnot

                NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
                NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)
From: DWING@UH01.Colorado.EDU (Dan Wing)
Newsgroups: vmsnet.internals
Subject: Re: SET WATCH
Date: 1 Oct 92 16:53:43 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Harry Flowers, FLOWERS@MEMSTVX1.MEMST.EDU, writes:

>In article <8435732@MVB.SAIC.COM>, "CCF::GPE%hermes.mod.uk"@relay.MOD.UK writes
   :
>> Ian Kitching    (systimk@uk.ac.anglia.va) wrote:
>>
>>>However... I know SET WATCH FILE worked under VMS V5.0 but it hasn't worked
>>>for me since V5.2. I've eliminated lack of CMEXEC privilege as the problem.
>>>SDA shows the cell as containing %Xfa00 - an appropriate value for process
>>>default protection. When I use SET WATCH FILE the cell doesn't change.
>>
>> I can confirm that SET WATCH FILE still works under VMS 5.4-3 and A5.5.
> Perhaps
>> they have changed the cell which is used?
>
>One thing I found out when trying to use it is that it requires CMKRNL as an
>AUTHORIZED privilege.  I used Ehud's PRCPRV to give an account CMKRNL to use
>SET WATCH, and it wouldn't work.  So, if you've got CMKRNL as a default priv,
>but not an authorized one, I don't believe that it will work.

I've installed SYS$SYSTEM:SETWATCH.EXE with CMEXEC, to allow non-priv'd users
to trace (vendor-supplied) images.  Haven't had a crash yet, but then again,
it isn't used very often.  I don't know if there are any back-doors to
installing this image with privs, though (like ANALIMDMP's problem).

You could install SETWATCH.EXE with CMEXEC, and put an ACL on the file
preventing non-priv'd users from running it.  Then, if someone needs to trace a
program's file accesses, you can SET RIGHTS/ENABLE/IDENTIFICATION=pid their PID
to grant them the ability to use SET WATCH for this interactive session.

SET WATCH has worked on VMS V5.4-x and V5.5 for me.

-Dan Wing, DWING@UH01.Colorado.EDU or WING_D@UCOLMCC.BITNET (DGW11)
 Systems Programmer, University Hospital, Denver
From: "CCF::GPE%hermes.mod.uk"@relay.MOD.UK
Newsgroups: vmsnet.internals
Subject: SET WATCH
Date: Thu, 1 Oct 92  12:57 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Ian Kitching    (systimk@uk.ac.anglia.va) wrote:

>However... I know SET WATCH FILE worked under VMS V5.0 but it hasn't worked
>for me since V5.2. I've eliminated lack of CMEXEC privilege as the problem.
>SDA shows the cell as containing %Xfa00 - an appropriate value for process
>default protection. When I use SET WATCH FILE the cell doesn't change.

I can confirm that SET WATCH FILE still works under VMS 5.4-3 and A5.5. Perhaps
they have changed the cell which is used?

Graham

Graham Evans
GPE%hermes.mod.uk@relay.mod.uk or GPE@hermes.mod.uk (INTERNET)
GPE@uk.mod.hermes (JANET)
From: "Ian Kitching, System Manager"
Newsgroups: vmsnet.internals
Subject: Re: SET WATCH
Date: Fri, 2 Oct 92  12:00 BST
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Problem solved! I used the Debugger to step through and found my problem is
due to a command parsing quirk.

The "SET WATCH" part invokes SETWATCH.EXE via a syntax clause, as one would
expect. SETWATCH then does CLI$GET_VALUE for the WATCH_OPTION and tests if
it is "FILE", no abbreviation allowed. It doesn't do anything if the test
fails.

Since I (almost) always abbreviate interactive commands, I've been
typing SET WAT FI(L)/CL=...

Ian Kitching    systimk@va.anglia.ac.uk
Newsgroups: vmsnet.internals
From: frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger)
Subject: RE: file header full on system disk
News-Software: VAX/VMS VNEWS 1.41    
Reply-To: frank@rover.uchicago.edu
Organization: Joint Center for Radiation Therapy
Date: Mon, 28 Sep 1992 15:43:00 GMT

In article <9209252307.AA28389@relay2.UU.NET>, "(Jon Pinkley, Westinghouse (216)486-8300 x1335)" writes...
>INIT /HEADERS=xxx preallocates up to /maximum_files headers.  I
>thought that the BACKUP truncation on restore was supposed to be
>fixed in V5.5-2 (From a talk at the Spring DECUS on BACKUP)
> 
>Jon Pinkley jon@clevax.wec.com  ...uunet!tron!clevax!jon
>(216)486-8300 x1335

	One thing they forgot going from RSX to VMS. BRU had a switch to
	specify number of file headers on restore.

	Alternate would be to do the restore by first initializing the disk
	to the size you need and then doing the Restore, instead of letting
	restore do the init for you. (cept for stand alone, of course.)

   Frank R. Borger - Physicist    __       Internet:  Frank@rover.uchicago.edu
Michael Reese - Univ. of Chicago |___      Phone : 312-791-8075 fax : 567-7455
  Center for Radiation Therapy   | |_) _   America is a large, friendly dog in
                                   | \|_)  a very small room. Every time it wags
    "Birthplace of Softball"          |_)  its tail, it knocs over a chair.
					   Arnold Toynbee
From: "CCF::GPE%hermes.mod.uk"@relay.MOD.UK
Newsgroups: vmsnet.internals
Subject: SET WATCH
Date: Thu, 1 Oct 92   9:28 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Does anyone know how SET WATCH FILE works? By that I mean specifically the DCL
command - what have I actually changed if I type SET WATCH FILE/CLASS=blah ? Is
it as simple as setting a few flag bits in the process space?

The reason I'm asking is to see if it is possible to do the equivalent of SET
WATCH FILE to another process. If I know what to change, it can be attacked
directly (if in S0 space) or indirectly (via ASTs etc) if in P1 space.

Seem reasonable?

If anything comes of this I will post any code I write.

Thanks

Graham

Graham Evans
GPE%hermes.mod.uk@relay.mod.uk or GPE@hermes.mod.uk (INTERNET)
GPE@uk.mod.hermes (JANET)
From: osymh%trex.oscs.montana.edu@MTSUNIX1.BITNET (Michael L. Hitch)
Newsgroups: vmsnet.internals
Subject: RE: Bug in LIB$FIND_IMAGE_SYMBOL ?
Date: 5 Oct 92 20:37:27 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List


 system@idiws1.idi.battelle.org writes:
=> The docs say that if the "image" parameter is not given, SYS$SHARE: will
=> be searched for "filename.EXE".  Otherwise, a logical may be used for
=> "filename" to point to the proper file.
=>
=> I interpreted this to mean that if "image" was given, then that's what
=> you got.  However, it seems that if "filename" is a logical, then that
=> translation is used before even looking at the "image" parameter.
=>
=> Can anyone confirm or explain this?  Is it a bug in the RTL or am I
=> mis-interpreting the description?  Thanks for your input.

  The documentation I have for LIB$FIND_IMAGE_SYMBOL states that "image" is
the default file specification applied to the image name.  I would interpret
this as meaning "image" is specified as the default file specification to
the file specified in "filename".  If "filename" is a logical, then that
logical would be translated before the default file specifications are used.
---
Michael L. Hitch                        osymh@msu.oscs.montana.edu
Computer Consultant                     OSYMH@MTSUNIX1.BITNET
Office of Systems and Computing Services
Montana State University
Bozeman, MT     USA
From: SCHENKENBERG@Monmouth-ETDL1.Army.MIL
Newsgroups: vmsnet.internals
Subject: Re: Current directory in prompt
Date: Mon, 5 Oct 1992 08:33 EDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

>Fine, thinks I, but the timer isn't the best way to do things -- it burns
>cycles when not needed, and doesn't when it is (ie you can say SET
>DEFAULT [BLAH] and not see the new prompt until the next time you hit
>Return).

I too was a bit concerned about the timer and kludgy results of setting default
early in the timer interval.  (ie. the default may be changed but the prompt
may not reflect it. Ref:. the comment preample in the published code)

>What I do is re-vector SYS$SETDDIR to point to the code in P1 pool, so
>that after each call to $SETDDIR, the prompt is updated.

>The only snag at the moment is that the routine runs in the access mode
>of the caller, which means it may or may not be able to fiddle the
>prompt.  Usually, it will run in supervisor mode (ie when called from
>DCL as a result of a SET DEFAULT command), but if a user mode program
>decides to change the default directory, the prompt won't be updated.

>Anyone have a good solution to this problem?  (It's 5am and I'm off to
>bed!)

YES-

Make your thread of code into an executive mode (user defined) system service.
Then 're-vector' SYS$SETDDIR to point to the new service instead of code in P1
pool.  The code under the new service can then run in EXEC mode.

BJS-
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: vmsnet.internals
Subject: re: file header full on system disk
Date: 26 Sep 1992 19:02:19 GMT
Organization: HST Wide Field/Planetary Camera
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Sep25.104629.16194@infocomm.com>, mark@infocomm.com writes:
>Be VERY careful of trying to do the $EXTEND on INDEXF.SYS.   The ONLY time 
>this method has a prayer of working is immediately after a backup/restore when
>there is a good probability that the extension will be done with a single
>extent.  Using this method when there are fragmented pieces of free space
>around might end up getting your $EXTEND to use multiple of those pieces.  If
>this happens, an you end up running out of room for extension descriptors in 
>the header of INDEXF.SYS, the file system will gladly allocate an extension 
>header and put the extra extent descriptors there.

Are you sure about that?  I'd've thought that the code that prevents allocation
of extension file headers for INDEXF.SYS would've been coded pretty deeply into
the XQP.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
From: Hunter Goatley <goathunter@WKUVX1.BITNET>
Newsgroups: vmsnet.internals
Subject: RE: SET WATCH
Date: Thu, 01 Oct 1992 07:14:32 EDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Graham Evans <"CCF::GPE%hermes.mod.uk"@relay.MOD.UK> writes:
>
>Ian Kitching    (systimk@uk.ac.anglia.va) wrote:
>
>>However... I know SET WATCH FILE worked under VMS V5.0 but it hasn't worked
>>for me since V5.2. I've eliminated lack of CMEXEC privilege as the problem.
>>SDA shows the cell as containing %Xfa00 - an appropriate value for process
>>default protection. When I use SET WATCH FILE the cell doesn't change.
>
>I can confirm that SET WATCH FILE still works under VMS 5.4-3 and A5.5. Perhaps
>they have changed the cell which is used?
>
No, it's still PIO$GW_DFPROT.  The following comments were taken from
one of the programs in Lee Gleason's KEYS utility.  (KEYS lets you
define "process-permanent" control keys to do things like toggle
VERIFY, toggle SET WATCH FILE settings, etc.  I just tried it under
VMS v5.5-1 and it worked fine.

;+
;  data displayed on use of this routine depends on the bits
;  set in pio$gw_dfprot. The value I used (^X2B) turns on
;  just a few displays.  If this is more or less than you want,
;  change every following occurrence of ^X2B with a bit
;  mask more to your liking.
;
;       Bit 0   Major functions
;       Bit 1   Control functions
;       Bit 2   Read or Write file attributes
;       Bit 3   Directory operations
;       Bit 4   Display entire FIB on every operation
;       Bit 5   Disk Quota functions
;       Bit 6   ...No apparent effect...
;       Bit 7   ...Likewise...
;-

You can get KEYS via anonymous ftp from ftp.spc.edu ([192.107.46.27]).
You'll need:

        [.MACRO32]LZDCMP.EXE
        [.MACRO32.SAVESETS]KEYS.BCK_Z

To get KEYS via e-mail, send the following command in the body of a
mail message to FILESERV@WKUVX1.BITNET:

SEND KEYS

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET, 502-745-5251
From: "Ian Kitching, System Manager"
Newsgroups: vmsnet.internals
Subject: re: SET WATCH
Date: Thu, 1 Oct 92  12:02 BST
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

>Does anyone know how SET WATCH FILE works? By that I mean specifically the DCL
>command - what have I actually changed if I type SET WATCH FILE/CLASS=blah ?
>Is it as simple as setting a few flag bits in the process space?

(This applies to VMS V5.0 - V5.4-2.)

SET WATCH FILE modifies flags in the P1 cell PIO$GW_DFPROT via a $CMEXEC call.

*Supposedly* this cell used to hold the process default protection but is
now obsolete (spare).

Flag bits:      0 - major
                1 - control
                2 - attribute
                3 - dir ops
                4 - dump (misc things)
                5 - quota

The messages are written via supervisor-mode ASTs to SYS$OUTPUT.

However... I know SET WATCH FILE worked under VMS V5.0 but it hasn't worked
for me since V5.2. I've eliminated lack of CMEXEC privilege as the problem.
SDA shows the cell as containing %Xfa00 - an appropriate value for process
default protection. When I use SET WATCH FILE the cell doesn't change.

Any ideas?

Ian Kitching    systimk@uk.ac.anglia.va
From: SYSMGR@IPG.PH.KCL.AC.UK
Newsgroups: vmsnet.internals
Subject: re**2: file header full on system disk
Date: Mon, 28 SEP 92 13:09:49 BST
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

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)