HDTenEightyP/NetNews huggingface dataset:
From: rj@cadre.com (Rob deFriesse)
Newsgroups: comp.os.vms
Subject: Re: retrofitting the old VMS queue manager
Date: 16 Nov 92 19:07:32 GMT
Article-I.D.: fripp.1992Nov16.190732.807
Reply-To: rj@cadre.com
Organization: Cadre Technologies Inc.

olin@vger.cheme.cornell.edu (Steve Thompson) writes:
: I need to return to using the old VMS queue manager (as used in VMS A5.5 and
: previous versions) on a cluster running 5.5-1, while retaining everything
: else the same (ie I don't want to reinstall A5.5). This is not related
: to any problems with the new queue manager - I have other reasons for
: doing this which I can't go into here. Anyone know how to retrofit the
: old queue manager? Thanks,
: 
: Steve

I did this once.  The problem is, I don't remember everything I did.
However, the important step was to patch "sys$common:[sys$ldr]sys.exe".

What DEC does is to ship this file with the version A5.5 coded in.  When
you run "sys$update:VMS$UPGRADE_A55_V55.COM", it changes A5.5 to V5.5.
The queue manager or something sees this and uses the old or new queues
accordingly.

To patch it back, look in the file "sys$update:VMS$UPGRADE_A55_V55.COM"
to see how the patch is done.  Take all the necessary precautions before
getting started (copy sys.exe, backup the system disk, etc.)  Clean up
any files that "sys$update:VMS$UPGRADE_A55_V55.COM" created.  You will
need to reboot to pick up your changes.  You will also need to either
have saved your old "jbcsysque.dat" file or rebuild it when you're done.

Some experimentation will be required.  I can't guarantee that you will be
successful.  Keep good backups and you should be ok.

--

  Rob deFriesse                                          Mail:    rj@cadre.com
  Cadre Technologies Inc.                                Phone: (401) 351-5950
  222 Richmond St.                                       Fax:   (401) 351-7380
  Providence, RI  02903

  My opinions are my own and do not represent the position of Cadre in any way.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Plans for mixed Alpha/VAX cluster with common system disk?
Date: 20 Nov 1992 03:15:41 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Nov19.125053.5849@ais.com>, bruce@ais.com (Bruce C. Wright) writes:
>On the other hand, I don't think this will be that big a problem in
>practice -- that's the way network file systems have worked in Unix
>for years without anyone complaining much about it.  Each architecture
>just gets its system binaries from different places, & the users have
>to fend for themselves.

On the other hand, you've NEVER been able to move executables from one unix
system to another.  Frequently you can't even move some of the source code
without putting in conditional code.  On the other hand, until Alpha, one of
DEC's slogans was
	VMS is VMS.
An image that runs on one VMS system runs on ANY VMS system at the same version
level, and non-privileged code almost always will continue to run after an
upgrade.  Not so any more.
--------------------------------------------------------------------------------
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.
Newsgroups: comp.os.vms
From: fisk@cvdv73.mayo.edu (Tom Fisk)
Subject: Re: ?UCX /NFS/ Question
Keywords: UCX,NFS
Reply-To: fisk@mayo.edu
Organization: Mayo Clinic, Rochester, MN
Date: Tue, 17 Nov 92 22:15:27 GMT


In article <mike.721982321@starburst.umd.edu>, mike@starburst.umd.edu (Michael F. Santangelo) writes:
|>From: mike@starburst.umd.edu (Michael F. Santangelo)
|>Newsgroups: comp.os.vms
|>Subject: ?UCX /NFS/ Question
|>Date: 17 Nov 92 06:38:41 GMT
|>
|>
|>Okay, I spent a few hours playing with UCX 1.3's NFS Server and
|>finally managed to get an NFS client to mount the user disk on
|>my VMS host (simple, non-CFS), config was something like this:
|>
|>  ADD PROXY TESTUSER/UID=-2/GID=-2/HOST="myclient"
|>  BIND DUA1: "/userdisk"
|>  ADD EXPORT "/userdisk"/HOST="myclient"
|>
|>myclient successfully mounts a subdirectory (testdir) of DUA1 as
|>"/userdisk/testdir" using the "nobody" user (uid=-2/gid=-2).  TESTUSER
|>has full access to this directory, it is its owner and permissions are
|>set O:RWED,S:RWED,W,G.  In DCL, I place a file in /userdisk/testdir
|>and the client sees it when I do a directory (ls).  HOWEVER, the
|>client CAN NOT write to this directory despite everything I have
|>tried!  It is somehow write protected.
|>
|>Any ideas?  There is a "SECURITY" logical in UCX$NFS_STARTUP set to 0,
|>does this have anything to do with it?  I am baffled.
|>

I have found that you need to add a proxy for each user that is trying to 
write a file to that disk.  The nobody proxy is good enough for the mount but
when you try to write a file then it needs the specific user access (who you
are logged in as on the Unix box).  This is what I found I need to do....any
other more appropriate answers??
--
-------------------------------------------------------------------------------
Thomas B. Fisk          +----------------------------+  Internet: fisk@mayo.edu
Mayo Clinic             |   If you don't know where  |  Voice: (507) 255-4341
200 First Street SW     |  you're going you'll never |  FAX: (507) 255-5484
Mail Stop 2D-337 STM    |         get there.         |
Rochester, MN  55905    +----------------------------+
-------------------------------------------------------------------------------
Newsgroups: comp.os.vms
From: rewise@musctn.monsanto.com (Richard Wiseman - VAX/VMS CraftsPerson)
Subject: Re: %system-F-REMRSRC, insufficient system resources at remote node
Organization: Monsanto - Ag.
Date: Mon, 23 Nov 1992 22:20:54 GMT

	In article <21NOV92.00260721@moleng.ucsc.edu>, wipke@moleng.ucsc.edu writes:
> When we do a
> SET HOST SECS
> we get
> %SYSTEM-F-REMRSRC, insufficient system resources at remote node
> 
> How can I know what specific resource is causing this msg?  LRP's are
> available on SECS according to "show mem"
> Node SECS does not have many people logged in or connected.
> 
> -Wipke@secs.ucsc.edu

	This is usally caused by the "executor Max links" parameter 
	for the remote node being exceded..
	go into NCP on the remote node and do a show executor count
	look for the line that says "Maximum logical links active" 
	then do a show executor characterics
	look for the line that says "maximum links"
	if the two numbers are the same then this might be the cause of 
	your problem.
	if you feel you need more links increase the number on the remote node
	with the NCP command 
	define exec max links xx  ( this puts it in the permanet data base
	set exec max links xx  ( this puts it in the volitle data base)
	be carefull not to make the number too large..


				...rew-- 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Richard Wiseman		 VAX-VMS Crafts Person
   MONSANTO	                Internet:  Rewise@musctn.monsanto.com
   RR #5 Wiggins Rd.             Yellnet:  +1 (319)262-7528 or 262-7339
   BOX 473                           FAX:  +1 (319)262-5626
   Muscatine, Ia 52761        Disclaimer:  All opinions are my own, I think
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Newsgroups: comp.os.vms
From: newark@befvax.uchicago.edu (Tom Newark)
Subject: vs 4060 to vs 4090 upgrade bombs....
Reply-To: newark@befvax.uchicago.edu
Organization: University of Chicago, Dept of Molecular Genetics and Cell Biology
Date: Thu, 19 Nov 1992 14:07:45 GMT

Over the last 2 days i've been trying to upgrade my vs 4000 model 60 to a 
model 90.  After installing the hardware upgrade (i have 128 meg of memory and
an spxgt graphics board) and loading the operating system (remastered 
vms 5.5-2) from scratch (they sent me an os kit that only allows installs 
no upgrades) the system loads fine, but crashes at the drop of a hat....

I can log in decwindows but if I try to end the session the machine crashes.
If I run a large program from the os (with or without decwindows loaded) the
system also crashes.

When I say crashes I mean the workstation screen goes black, and sometimes the
message 

?33 unxint

is displayed, sometimes not.   Then the machine goes into a cold boot (memory 
test and all).  This is very frustrating....I've sat through a 128 meg memory
test hundreds of times....

I've been able to boot the model 60 spxgt under 5.5-2 remastered, so I'm 
beginning to think I have a bad model 90 motherboard.  Has anyone else seen
this or have any ideas?  

Thanks for your help in advance 

Tom Newark


@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@
#@ Tom Newark    System Manager/Programmer                             @#
@# Department of Molecular Genetics and Cell Biology                   #@
#@ University of Chicago  --  newark@befvax.uchicago.edu               @#
@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@
From: helen@pulua.hcc.hawaii.edu (Helen Rapozo)
Subject: Re: ?Why does this backup go so slow?
Organization: Honolulu Community College
Date: Tue, 17 Nov 1992 09:58:55 GMT

In article <1992Nov12.124928.1@woods.ulowell.edu> welchb@woods.ulowell.edu writes:
>It took us 4.5 hours to do an image backup of an RA90 (80% full of user
>data) onto an RA92?  Why does it not go faster?   [I had prepared a much 
>longer version of the question, with so many particulars, that my boss 
>said to just ask the simple question.]
>-- 
>Brendan Welch, UMass/Lowell, W1LPG,  welchb@woods.ulowell.edu
***********
Depends on the command that you used.  Did you do a /VERIFY on the
backup command?  Was the system running when the backup was
being performed?  If so what was the priority of the backup
process?


Honolulu Community College            cs_rapozo@hccadb.hcc.hawaii.edu
874 Dillingham Blvd.                  helen@pulua.hcc.hawaii.edu
Honolulu, HI 96817                    rapozo@uhunix.uhcc.hawaii.edu
Ph#: (808) 845-9202
Newsgroups: comp.os.vms
From: Sten M. Drescher <smd@hrt216.brooks.af.mil>
Subject: Re: File transfers - slow Kermit, looking for Zmodem
Organization: AL/HRTI, Brooks AFB
Date: Fri, 20 Nov 1992 14:11:29 GMT

	I want to thank everyone who send me suggestions on how to
correct my problem.  I had Kermit-32 3.3.128 mailed to me, which kicked
my transfer rate up to the 500-600 cps range.  I then was told where to
find RZSZ for VMS,  and that gives me 800-900 cps (of course, I then
discovered that Crosstalk for Windows implemtation of ZModem is
incompatible, but that didn't suprise me).  I didn't try the C-Kermit,
because I only saw sources, and we don't have a C compiler on our
system.  As far as Kermit being in the VMS distribution, all I knew that
an instructor at a company I took a class at said that Kermit was on the
CD-ROM the OS was on - he could have been wrong, I could have
misunderstood him, or anything.  At any rate, thank you all.
		Sten Drescher
From: moeller@gwdgv1.dnet.gwdg.de ("GWDGV1::MOELLER")
Newsgroups: comp.os.vms
Subject: re: Turning VAX FORTRAN IOSTAT into VMS status code
Date: 16 Nov 92 13:27:31 GMT
Distribution: world
Organization: The Internet

"Phil" (no return address) asked:
> Hi. I wonder if anyone can tell me how to turn a VAX FORTRAN
> IOSTAT status return value into a VMS status for signalling
> by LIB$SIGNAL?  I cant in this application use ERRSNS because
> the error of interest may not be the last io transaction on
> the file at the time when I want to signal.

Multiply by 8, and add '00188004'x (hexadecimal) to it.

You may wish to select another "severity" by changing the last hex digit;
4 makes for a FATAL status (%FOR-F-...).

Wolfgang J. Moeller, GWDG, D-3400 Goettingen, F.R.Germany | Disclaimer ...
PSI%(0262)45050352008::MOELLER      Phone: +49 551 201516 | No claim intended!
Internet: moeller@gwdgv1.dnet.gwdg.de   | This space intentionally left blank.
From: simons/G=Colin/I=CB/S=Sewell/O=H.A.Simons.Ltd/OU=CORP@mhs.attmail.com
Newsgroups: comp.os.vms
Subject: re: Location of Login question
Date: 17 Nov 92 17:13:01 GMT
Distribution: world
Organization: The Internet

|	Is there a way to determine if a user is logged in from a hardwire, or
|	is dialing in from home?  If so how?  Does this depend if your system
|	is set up to allow this, or is it an natural part of the VMS os?


	The lexical function F$GETDVI(terminal-name,"TT_DIALUP")
	will tell you whether a specific terminal is a dialup terminal.

	The lexical function F$GETJPI(pid,"JOBTYPE") returns the value
	4 if the process is logged in over a dialup line. Other values
	for possible JOBTYPE returns can be found in the $JPIDEF
	macro in SYS$LIBRARY:STARLET.MLB.

	On a DECSERVER port attached to to a modem, you have to set the
	DIALUP flag on the port so incoming logins will be flagged
	as dialups.

						colin sewell
						h.a.simons ltd.
						vancouver, bc
From: system@NIUHEP.PHYS.NIU.EDU
Newsgroups: comp.os.vms
Subject: re:RE:User limit in VS4000 (under cslg)
Date: 16 Nov 92 15:09:32 GMT
Distribution: world
Organization: The Internet

>Check you CSLG agreement again... The one that Washington University (St. Louis)
>has limits the number of simultaneous logins on a VAXStation to 8 per the
>agreement.  While the (software) licenses provided by the CSLG are unlimited.
>The paper agreement says otherwise.  If you are running unlimited logins you
>may be in violation of the CSLG agreement.
	I guess I'll have to get a copy of the agreement ( the university 
administators haven't bothered to give me a copy.  Happily we have a D.O.E.
grant that over the years built us up to a vaxserver 4000 and 8 workstations,
so I already limit logins to 8.
Robert Morphis

P.S. I would normally just send this to the poster, but I have no idea if the
return address in the header will work.
system%niu.hepnet@lbl          BITNET
system@phys.niu.edu            INTERNET
NIU::SYSTEM                    HEPNET

Newsgroups: comp.os.vms
From: critz@star.enet.dec.com (Richard Critz)
Subject: Re: Plans for mixed Alpha/VAX cluster with common system disk?
Reply-To: critz@star.enet.dec.com (Richard Critz)
Organization: Digital Equipment Corporation, Nashua, NH
Date: Mon, 16 Nov 1992 21:40:16 GMT


In article <1992Nov16.180234.26912@sol.UVic.CA>, zapantis@uvphys.phys.uvic.ca (Nik Zapantis) writes:
|>-In article <1992Nov12.224853.23999@engage.pko.dec.com>, parris@star.enet.dec.com (Keith B. Parris) writes:
|>
|>|>
|>|>We don't presently plan to support a common system disk shared between VAX and
|>|>Alpha systems.  Cluster-common files (SYSUAF, RIGHTSLIST, etc.) can be shared. 
|>|>
|>
|>Will the Alpha support/mount a VAX/VMS system disk? In other words, will I be
|>able to have both an Alpha VMS disk and a VAX/VMS disk mounted on an Alpha 
|>system, and boot Alphas from the Alpha disk and VAXens from the VAX disk?

Yes.  There's no such thing as an Alhpa disk or a VAX disk.  They are all
ODS-2 meaning that each mounts on either system.  The only differences
you care about are whether the executables (and so on) are for the Alpha
platform or the VAX platform.

--
-----------------------------------------------------------------------------
Richard Critz					      critz@star.enet.dec.com
      -- I speak only for myself; I make no commitments for Digital. --
-----------------------------------------------------------------------------
From: mathog@seqvax.caltech.edu (David Mathog)
Newsgroups: comp.os.vms
Subject: Resolution: .tar.Z files that won't unpack under VMS
Date: 23 Nov 1992 17:16 PST
Organization: Division of Biolgy, CALTECH
Distribution: world
NNTP-Posting-Host: seqvax.bio.caltech.edu
News-Software: VAX/VMS VNEWS 1.41    

Thanks to all of you who e-mailed or posted replies.

Switching to VMSTAR (obtained from ftp.spc.edu) fixed the problem.

The buggy tar was version 1.2 of "VMS TAR", originating in Australia.
Let's hope that the program's authors fix it - it has a nice VMS command 
line.  Sorry folks, I don't remember which FTP site it came from.

Thanks again.

David Mathog
mathog@seqvax.caltech.edu
Manager, sequence analysis facility, biology division, Caltech
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: HUNG SYSTEM WHEN SUBMITTING THREE JOBS ON SYS$BATCH
Date: 22 Nov 1992 16:18:05 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <C014F5D13B5F00093D@EGFRCUVX>, SABRY@SHEBIN.EG writes:
=WE  WORK A MICROVAX 3400 ,12MB.
=HERE ON A DEVICE USERNAME CALLED SHEBIN AND HE MAKE THREE OR 3 JOBS BY
=SUBMITTING AND THIS A JOBS BY FORTRAIN ..OK.
=THIS A JOBS WROKED ONCE ON SYS$BATCH AND SYS$BATCH LIMIT_JOPB=3     OK.
=THEN AFTER SO SEEM THAT MICROVAX HUNG  AND CANNOT WORKINGD WITH US
=AND ALSO ANY USER CONNOT LOGIN TO ACCOUNT OWN IT AND DCL  VERY SLOWER AND
=NOT ANY ANSWER WITH US..OK
=THEN APPEARS TO US THIS A MESSAGES:-
=%SYSTEM-W-PAGEFRAD,PAGE  FILE BADLY FRAGMENTED,SYSTEM CONTINUING.
=ALSO,
=%SYSTEM-W-PAGECRIT,PAGE FILE SPACE CRITICAL,SYSTEM TRYING TO CONTINUE.
=I SORRY ON THIS A MESSAGE BUT I WANT FROM ANYONE SOLVE THIS PROBLEM AND
=GIVE ME A MAIL CONTIAN THE SOLVE  TO A ERRORS MESSAGES.
=THANKS A LOT FOR NAYONE ON HELP.
=E-MAIL OR  ENTERNET:SABRY@SHEBIN.EG

The problem is that your page file is too small.  Use the SYSGEN CREATE command
to increase the size of your page file (or, better still, use AUTOGEN to
calculate an appropriate size) and reboot your system.
--------------------------------------------------------------------------------
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.
Newsgroups: comp.os.vms
From: magoo@baloo (Tim Lentz x255)
Subject: Re: How to get remote node name from RSH process?
Organization: Precision Visuals, Inc.
X-Newsreader: Tin 1.1 PL4
Date: Thu, 19 Nov 1992 03:03:42 GMT

ALLEN@ECF.NCSL.NIST.GOV writes:
: 
: 	Hi guys,
: 
: 	I'm using Multinet to execute various DCL command files on our Vax
: 	from a Sun workstation using the rsh utility. From within the VAX
: 	command file I'd like to be able to determine the name (or IP address)
: 	of the workstation from which it was invoked.
: 
: 	I've played around a little and I see the VMS process seems to be
: 	running against a mailbox device but I havn't found any record of
: 	the remote node that created the process or mailbox.  Anybody able
: 	to offer any assistance?
: 
: 	Thanks,
: 
: 	Dan

Try: $ multinet show/connections

Granted you will see more than you probably want (all shells, logins, X11, etc.) but it might give a hint. This works with V3.1 anyway.

T
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
magoo@pvi.com					Just a fool waiting on the wrong
Manager Computer Networks			block. Putting a little ZEP in 
Precision Visuals, Inc. Boulder, Co		your step.
Newsgroups: comp.os.vms
From: marshall@nebula.ssd.lmsc.lockheed.com (Bob Marshall)
Subject: Re: SYSTEM-F-NOLINKS, maximum network logical links exceeded
Reply-To: marshall@nebula.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Sun, 22 Nov 92 19:38:06 GMT

In article <1992Nov22.174003.1130@nntpd.lkg.dec.com>, francini@narfvx.enet.dec.com (John Francini) writes:
>
>In article <22NOV92.01314219@moleng.ucsc.edu>, wipke@moleng.ucsc.edu writes...
>>NCP shows max links = 32, but SHOW NET shows zero links to the node
>>that gives this error upon SET HOST <anyothernode>.  Is max links
>>for the network or for the node?  Is there some other parameter tha
>>that causes this?
>
>The error is coming from the remote system, not the local one, if I
>understand your scenario correctly.  In other words:
>
>You're logged onto NODEA::.  You SET HOST to NODEB::.  You get the
>SYSTEM-F-NOLINKS.  NODEB::'s using the maximum number of links.
>
>NODEB's NCP max links parameter needs to be increased.

I don't think this is correct. If you are on NODEA and get the "NOLINKS"
message, then it is coming from NODEA. If NODEB did not have any slots
left in the link vector, then the message on NODEA will be "insufficient
resources at remote node". So it's NODEA that needs to increase the
number of links.

=============================================================================
Bob Marshall                     \\     "Women aren't as smart as they
Lockheed Missiles & Space Co.     \\     think they are; they think we
Sunnyvale, CA                      \\    men know a lot more than we
marshall@force.ssd.lmsc.lockheed.com\\   really do."
"I tell the truth 'cept when I lie"  \\     - Tim the Toolman
=============================================================================
From: kjb@calmasd.prime.com (Ken Brucker)
Newsgroups: comp.os.vms
Subject: Re: Fixing SYSTEM-W-HEADERFULL error
Date: 16 Nov 92 23:32:34 GMT
Article-I.D.: calmasd.1992Nov16.153235.958
Organization: Computervision, San Diego CA

In article <1992Nov16.122136.26119@fripp.ri.cadre.com>, rj@cadre.com (Rob deFriesse) writes:
> adam@irvine.com (Adam Beneschan) writes:
> 
> : We think the problem is that the system is trying to enlarge the
> : INDEXF.SYS file and can't.
> 
> That's it exacly.  Here's what you do:
> 
> 1. Back up the disk to tape or another disk.
> 
> 2. Determine the maximum number of files you will ever need on the disk.
> 
> 3. Inititalize the disk with _BOTH_ /maximum_files= _AND_ /headers= set to
>     the figure determined in step two.  If you don't use /headers=, it won't
>     work.
> 
> 4. Restore the contents of the disk.  Use /noinitialize if you're doing an
>     image restore.

Be careful on this last step.  There's a bug that I know existed back in VMS
5.4 and may still be present in Backup.  Essentially, it ignores the /noinit
when doing an image restore and re-creates the indexf.sys to be just large
enough to hold the files that are in the save set.

I mentioned this to one of the Backup developers at a DECUS a couple of years
ago and I think the patched version of Backup that is available via DSNlink
contains the fix, but I don't think VMS 5.5-1 does.  Although I haven't had
reason to test this lately so I don't know if this is still a real problem with
the current VMS release.

To get around the bug, do steps 1 to 3 and then do a selective restore to the
entire disk.

Ken

-- 
-------------------------------------------------------------------------------
**  Ken Brucker -- VMS/Ultrix Systems Programmer/Mangler -- Computervision
 **  kjb@calmasd.Prime.COM  
  **  Practice Random Kindness and Senseless Acts of Beauty