HDTenEightyP/NetNews huggingface dataset:
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: BACKUP performance - can I expect any better?
Date: 22 Nov 1992 16:10:59 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 <1992Nov22.081354.21838@nntpd.lkg.dec.com>, francini@narfvx.enet.dec.com (John Francini) writes:
>
>In article <1992Nov18.195835.8983@ac.dal.ca>, ae@ac.dal.ca writes...
>[...]
>
>> 
>>	BACKUP /IGNORE=INTERLOCK disk tape_file /BLOCK_SIZE=32256
>> 
>
>For maximal tape usage, set /BLOCK_SIZE to the maximum allowed, 65535.

But if you're considering copying the saveset to disk at any time in the
future, restrict the blocksize to the largest value allowed for a BACKUP
saveset on disk: 32256.

>You also may want to experiment with various values of /GROUP=n. This sets
>the size of redundancy groups on the tape.   Redundancy groups allow for
>more bulletproof data recovery in the event of bad media, but at a cost in
>excess data being written onto the tape (thus lowering your effective
>throughput).

Though, oddly enough, decreasing the group size can, in some circumstances,
increase your throughput.  In particular, if the extra data the tape drive
needs to write allows BACKUP to have another block of data ready before the
drive stops streaming, you CAN get better performance with lower group sizes.
--------------------------------------------------------------------------------
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: viznyuk@ohstpy.mps.ohio-state.edu
Newsgroups: comp.os.vms
Subject: The problem with $CREMBX System_Service
Date: 17 Nov 92 17:10:01 EST

   Hello VMS community !

I have a little question about
$CREMBX System_Service.
Here is a piece of program
which is supposed to read data
from terminal and then write them
to mailbox, where they are supposed
to be picked up by parallel subprocess
(usually - DCL).

   [......]
char w;
static short tt,ch;
$DESCRIPTOR(TT,"SYS$INPUT");
$DESCRIPTOR(MB,"MAILBOX");
short iosb[4];
unsigned flag = CLI$M_NOWAIT;
   [......]
SYS$ASSIGN(&TT,&tt,0,0,0); 
SYS$CREMBX(0,&ch,0,0,0,0,&MB,0);
LIB$SPAWN(0,&MB,0,&flag,0,0,0,0,0,0,0,0,0);     /* starts parallel subprocess */
for (;;)
  {
  SYS$QIOW(0,tt,IO$_TTYREADALL+IO$M_NOECHO+IO$M_TRMNOECHO+
  IO$M_ESCAPE,iosb,0,0,&w,1,0,0,0,0);     /*    ----->  Reads single char w
                                                      from terminal  */
  SYS$QIO(0,ch,IO$_WRITELBLK+IO$M_NOW,iosb,0,0,
  &w,1,0,0,0,0);                          /* --->  writes char w to mailbox  */
  }


Now the problem is that DCL which is run in the subprocess
started by LIB$SPAWN  understands each write made by second
SYS$QIO above, as if it is followed by <RET> keystroke, that
is as if terminal is in "raw" mode.
Does anybody know how to make DCL in subprocess read
data from mailbox in its usual way - by strings, not by
single chars ?   May be I missed some flags ?

I would appreciate any suggestions.
S.Viznyuk
From: TARKA10@SNYBUFVA.BITNET (Mark Tarka)
Newsgroups: comp.os.vms
Subject: (none)
Date: 15 Nov 92 03:43:01 GMT
Distribution: world
Organization: from SUNY College at Buffalo, NY 14222

set info-vax nomail

Newsgroups: comp.os.vms
From: rubin@procon.jhuapl.edu (Don Rubin)
Subject: Wierd BACKUP change in VMS 5.5-2
Organization: Johns Hopkins Univ APL
Date: Tue, 17 Nov 92 20:33:45 GMT


We recently upgraded one of our clusters to 5.5-2, everything
went well and we had no complaints from the users until someone
ran one of my programs that is a front end to BACKUP. We have
a database of backups that allows the user find which tape has
the desired data. The restore program gets info from the user
and then mounts the tape (all of our programs do mounts and
dismounts so the users never have to worry about doing that)
if the label agrees with the one the user specified then a
subprocess is created (using smg$create_subprocess) and BACKUP
is spawned. UNTIL 5.5-2 this worked properly, since the drive
was mounted in the parent process, backup just went ahead and
did the restore. NOW backup aborts saying the tape drive is
allocated by another process (yes, the parent). After much
mail with DSNLINK the word is that the problem has been
refered to engineering. We worked around the problem by
mounting and dismounting the tape before going to the sub-
process. The problem with this is if the user control Cs
the program the exit handler can not dismount the tape (as it
did before when it was mounted by the main process) and the
drive can end up allocated to a non-existant process.

Just thought you'd like to know.

--
Don Rubin
Johns Hopkins Univ APL
rubin@procon.jhuapl.edu
Newsgroups: comp.os.vms
From: fairfield@slacvx.slac.stanford.edu
Subject: Re: Wierd BACKUP change in VMS 5.5-2
Organization: Stanford Linear Accelerator Center
Date: Tue, 17 Nov 1992 22:14:04 GMT

In article <1992Nov17.203345.23090@aplcen.apl.jhu.edu>, rubin@procon.jhuapl.edu (Don Rubin) writes:
> 
> We recently upgraded one of our clusters to 5.5-2, everything
> went well and we had no complaints from the users until someone
> ran one of my programs that is a front end to BACKUP. We have
> a database of backups that allows the user find which tape has
> the desired data. The restore program gets info from the user
> and then mounts the tape (all of our programs do mounts and
> dismounts so the users never have to worry about doing that)
> if the label agrees with the one the user specified then a
> subprocess is created (using smg$create_subprocess) and BACKUP
> is spawned. UNTIL 5.5-2 this worked properly, since the drive
> was mounted in the parent process, backup just went ahead and
> did the restore. NOW backup aborts saying the tape drive is
> allocated by another process (yes, the parent). After much

    Just curious, from which version of VMS did you upgrade to V5.5-2?
The reason I ask is that we are running V5.5-1 and I ran into essentially
the same problem: subprocess unable to access the drive allocated to the
parent (don't take me too literally, can't remember whether the drive
was mounted or just allocated...).   This had nothing to do with BACKUP.
I just gave up without thinking much more about it :-(

		-Ken
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
From: DWING@UH01.Colorado.EDU ("would rather be skiing ...")
Newsgroups: comp.os.vms
Subject: Re: TUNING - QUANTUM SYSGEM parameter
Date: 18 Nov 92 14:44:15 GMT
Distribution: world
Organization: The Internet

Don Stokes, (DS555), <don@zl2tnm.gen.nz>, writes:

>pihlab@hhcs.gov.au writes:
>> 2. What are some reasonable starting QUANTUM settings for the following
>>    machines:
[...]
>Also, the calculation was a bit off for V5.2(& 5.3?), because under these
>versions, a process would not preempt another unless it was 3 or more
>priority levels above the current process.  This has now been fixed, but
>with those versions, knocking QUANTUM right down would have helped a lot,
>effectively providing a form of preemption, although not nearly as good
>as real preemption as done in current and earlier versions.  Could this
>be why you got such an improvement by diddling QUANTUM before?

Don is referring to DEC's handling, within the scheduler, of the SYSGEN special 
parameter PRIORITY_OFFSET.  In "some" versions of VMS V5.x, a value of 0 for
PRIORITY_OFFSET actually means 4 (or 3).  DEC has reverted to 0 meaning 0, 
which means that a process with a (current) priority which is greater than
the currently executing process will preempt the currently executing process.

-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
 Systems Administrator, University Hospital, Denver
From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: Re: sys$hiber/sys$wake problems?
Date: 15 Nov 92 13:27:26 GMT
Distribution: world
Organization: The Internet


	|>    If one or more wakeup requests are issued for the process while
	|>    it is not hibernating, the next hibernate call returns
	|>    immediately; that is, the process does not hibernate.  ...
	|>
	|>This is, in fact, the correct behavior for a semaphore.  If it
	|>doesn't work this way, your process could block indefinately.
	|>
	Hi Rob,

	And all others that responded via e-mail. You are correct,  however we
	aren't the ones calling sys$wake. After leaving sys$hiber the
	next-to-last time, the bit pcb$v_wakepen bit is clear. The next time
	we start to enter sys$hiber it is set and we don't call sys$wake
	anywhere in between. (This is what  upsets us as we hope to set up
	things before calling sys$wake,  and when we don't we exit from hiber
	in an unknown state). I suspect (thanks Matt) the PPL$ runtime library
	as this scheme  has worked successfully for many years and PPL is the
	only new  variable in the scheme. My next task is to try to trap calls
	to sys$wake from the main and sharable images. Any ideas on  doing
	this? I may have a hard time convicing our system manager  to let me
	patch the system service vectors. Read that as slim to none. 

"Free wakes" are part of the design of the SYS$WAKE/SYS$HIBER mechanism.
Since there is only one "wake pending" bit per process, not one per access
level, there are tons of ways for the bit to get set.  If it was set at the
rundown of the last image in the process, it is probably STILL set - rundown
can't clear it, since it's not a user-mode (or any other mode) object.  If
you've done any SPAWN's or ATTACH's in the process, DCL itself may have done
hibernates and wakes.

Learn to live with it; that's just the way it is.  (There are good REASONS for
it being that way.)  The ONLY way to use $HIBER/$WAKE reliably is in code that
looks like the following:

sleep:
	while (not condition)
		SYS$HIBER()

wakeup:
	make condition true;
	SYS$WAKE(target)

Period.  End of discussion.  If you don't like it, don't use VMS.

Trapping calls to SYS$WAKE, patching system service vectors - all a load of
nonsense.  If you don't like the way VMS's system services work, design
another operating system; don't start mucking with VMS a bit at a time.

(Sorry to make such assertive statements, but writing reliable synchronized
code is HARD.  VMS has given you a mechanism that works.  You're kidding
yourself if you think it's trivial to do better.)

							-- Jerry

Newsgroups: comp.os.vms
From: gotwols@warper.jhuapl.edu (Bruce Gotwols)
Subject: UNCOMPRESS for VMS
Summary: Where can I obtain a UNIX compatible version of UNCOMPRESS for VMS?
Keywords: UNCOMPRESS
Organization: JHU/Applied Physics Laboratory
Date: Wed, 18 Nov 1992 03:02:03 GMT

	Can anyone tell me where I might obtain a copy of uncompress that is
compatible with the UNIX utility of the same name, but will run under VMS?

	(Sorry if this is a question that was recenntly discussed, but all of 
the messages with uncompress in the name had expired by the time I saw them.)

			Thanks, bruce
--
Bruce L. Gotwols
Johns Hopkins University, Applied Physics Lab., Laurel MD 20723
Internet:  gotwols@warper.jhuapl.edu   (128.244.27.2) 
SPAN:      APLSP::STR::GOTWOLS
From: Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms
Subject: Re: Failures in system security.
Date: Wed, 18 Nov 92 09:39:32 PST
Organization: The Portal System (TM)
  <1992Nov13.100241.254@rlgsc.com> <1e2e81INN9h4@gap.caltech.edu>
  <1992Nov16.154413.13758@ncsa.uiuc.edu> <1992Nov17.004401.256@rlgsc.com>

Robert "Bob" Gezelter (gezelter@rlgsc.com) writes:
 
> [...] Any validation scheme which starts out with 
>"Believe the credentials that the person who just walked in the 
>door is holding" is an incident waiting to happen. As I noted 
>earlier in this thread, the fact that an incomming request 
>appears to have come from a privileged user on another node is, 
>for most intents and purposes, a useless piece of information.

If we can't trust the "credentials that the person who just walked in the 
door is holding," then what credentials CAN we trust?  I submit that the
answer is "NONE!"  The Unix world, as I understand it, hands off the respon-
sibility to a "trusted" central authority -- is this what Kerberos is? --
but this just pushes the problem off on someone else: it becomes the "central
authority"'s responsibility to decide whether HE can trust the credentials
borne by those who come looking for his blessing.  And how do we, in turn,
KNOW that we can trust that central authority?  System failure, software bugs,
malicious hacking, or -- heck -- bribing a human central-authority-system-
manager could easily lead to falsified credentials even from the "trusted"
central authority.  Any security system invented by Man can be spoofed by Man. 
 

Either we reach a point, somewhere, in ANY security scheme, where we MUST
trust information given to us by some other party -- OR we trust NO one and 
the system is secure by means of being totally inaccessible -- in which case
it may as well not exist.  What use are computing resources that no one can
get to?  I guess there are standards committees in existence whose function, 
basically, is to define the arbitrary point at which we draw the line and 
commit ourselves to trusting second- (or third- or fourth- or...) hand cre-
dentials.
 
Chris Chiesa
  Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms
From: jsue@ncsa.uiuc.edu (Jeffrey L. Sue)
Subject: Re: Failures in system security.
Originator: jsue@troon.ncsa.uiuc.edu
Organization: The Dow Chemical Company
Date: Mon, 16 Nov 1992 15:44:13 GMT

In article <1e2e81INN9h4@gap.caltech.edu> carl@SOL1.GPS.CALTECH.EDU writes:
>In article <1992Nov13.100241.254@rlgsc.com>, gezelter@rlgsc.com writes:
>>> I understand that in version 5.5-2 DEC modified things so that to request an
>>> outgoing connection to object 27 one needs SYSPRV.
>
>Clarification:  They now allow the system manager to enable such a feature.
>
>>Sorry to be the bearer of bad news, but requiring SYSPRV on the 
>>outgoing connection merely makes it slightly more difficult to 
>>fake a connection, it is NOT a useful indication of authenticity. 
>
>If you use NCP to set access for all but trusted nodes (where a trusted node
> is
>one which you know has the new feature enabled) to OUTGOING only, then you 
>know
>(assuming that there are no security bugs in the MAIL image) that any one-hop
>mail message originates either:
>    1)	From the ostensible author; or
>    2)	From a privileged user or process on one of the trusted machines; or
>    3)	From someone with PHY_IO priv or equivalent on a machine that is
>	impersonating one of the trusted machines.
>While that's not 100% secure, it's a lot more secure than VMS mail has been in
>the past.

Tell you what.  You give me a PC on your network with Ethernet & DECnet,
and we'll just see who your VAX thinks I am.  Remember, *I* am the system
manager for my PC/MAC/VAXstation.  Thus I can look like anyone I want.
And if I know that your system is down, or if I can interrupt the network
connection between systems (place myself in the middle), I can even do
it without anyone knowing.

Also, I don't think it takes PHY_IO privilege to open a network object.
If you know what VMS Mail expects as input from the network connection I
believe it's very easy in DCL to fake it out.

-- 
-----
Jeff Sue   
 - All opinions are mine -       (and you can't have any, nya nya nya)
From: mcmahon@TGV.COM (At the end of the long, dark tunnel)
Newsgroups: comp.os.vms
Subject: RE: DECwindows Motif 1.1 and creation of DECterms with RSHELL
Date: 17 Nov 92 01:02:53 GMT
Organization: The Internet

> Under DECwindows Motif 1.0 there was a problem if windows were created from 
> another node by doing an RSHELL, along the lines of:
> 
> $ set disp/create/tran=tcpip/node='p1'
> $ create/terminal/detach
>
> If this was used several times, only the *first* window would be created.

Well, the original problem was that the SET DISPLAY/CREATE command would create 
a new WS device (DECW$DISPLAY) for each invocation of the command procedure.  
The problem was that only the first WS device would stick around to be used by 
the created DECterm.  The reason the first hung around was that the DECterm 
controller held a channel open to it.  What the REUSE-DISPLAY command procedure 
did was find that original WS device and use that, instead of creating a new 
one.

And then Motif 1.1 came along...

The DECterm Controller process no longer assigns a channel to the WS device.  
The result is that every WS device created by the invocation of this command 
procedure disappears.  So when you do a SHOW DISPLAY in your DECterm windows, it 
comes back with DECW$DISPLAY being defined to a non-existant WS device.

I worked out a quick and dirty solution, which can be found below.  This 
requires that the newly created DECterm assign a channel to the DECW$DISPLAY 
device (e.g. OPEN $SAVE_THE_WS_DEVICE$ DECW$DISPLAY: in the LOGIN.COM file or 
somesuch).  It's a crude hack, but it will work.

Cheers!
John McMahon

$! P1 is the /NODE qualifier (default MULTINET_RSHELL_ADDRESS or 0)
$ if p1 .eqs. "" then p1 = f$trnlnm("MULTINET_RSHELL_ADDRESS")
$ if p1 .eqs. "" then p1 = "0"
$! P2 is the /TRANSPORT qualifier (default TCPIP)
$ if p2 .eqs. "" then p2 = "TCPIP"
$! P3 is the /SERVER qualifier (default 0)
$ if p3 .eqs. "" then p3 = "0"
$! P4 is the /SCREEN qualifier (default 0)
$ if p4 .eqs. "" then p4 = "0"
$ write sys$output "Node=",p1," Transport=",p2," Server=",p3," Screen=",p4
$ DeviceLoop:
$	next = F$DEVICE("_WS*")
$	if next .eqs. "" then goto endloop
$	define/user sys$output nl:
$	show display/symbol 'next'
$	if ( (p1 .eqs. DECW$DISPLAY_NODE)      .and. -
             (p2 .eqs. DECW$DISPLAY_TRANSPORT) .and. -
             (p3 .eqs. DECW$DISPLAY_SERVER) .and. -
             (p4 .eqs. DECW$DISPLAY_SCREEN) )
$	Then
$		Write Sys$Output "Using Device ''next'"
$		Define Decw$Display 'Next'
$		Goto The_Big_Exit
$	EndIf
$	goto deviceloop
$ endloop:
$ SET DISPLAY /CREATE /NODE='P1' /TRANSPORT='P2' /SERVER='P3' /SCREEN='P4'
$ Write Sys$Output "Creating New Device ",F$TRNLNM("DECW$DISPLAY")
$ The_Big_Exit:
$ Create/Terminal/Detach
$ Open $SAVE_THE_WS_DEVICE$ DECW$DISPLAY:
$ BaseRefCnt = f$getdvi("DECW$DISPLAY","REFCNT")
$ WaitLoop:
$	RefCnt = f$getdvi("DECW$DISPLAY","REFCNT") 
$	If RefCnt .Gt. BaseRefCnt Then Exit
$	Write Sys$Output "Open a channel to DECW$DISPLAY in the new DECterm."
$	Wait 00:00:15
$	Goto WaitLoop
From: gezelter@rlgsc.com
Newsgroups: comp.os.vms
Subject: Re: Novice with elementary question
Date: 22 Nov 92 16:22:49 GMT
Organization: Robert Gezelter Software Consultant, Flushing, NY

In article <1992Nov21.080357.23638@news.uiowa.edu>, rajar@herky.cs.uiowa.edu (Chandrashekar Rajaraman) writes:
> Hi,
> 
> How do you change the pagefilesize ?
> 
> Please email me.
> 
> Thank you.
> 
> Chandra
-- 
Chandra,
 
The easiest way for a novice to change the size of the PAGE, 
SWAP, and/or DUMP files is to use the DIGITAL-supplied procedure 
SYS$UPDATE:SWAPFILES.COM. The command procedure will prompt you 
for the sizes for new files. 
 
This procedure must be run from SYSTEM or some other 
appropriately privileged account.
 
I hope that the above is helpful. If I have been unclear, please 
feel free to contact me via Email.
 
- Bob
 
P.S. So I don't get flamed. I suspect that there are a lot of 
     novices out there who will appreciate seeing this 
     information.
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
| Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                                                 |
+--------------------------------------------------------------------------+
From: SABRY@SHEBIN.EG
Newsgroups: comp.os.vms
Subject: FAILURES IN SYSTEM OR HUNG TO SYSTEM WHEN SUBMIT
Date: 22 Nov 92 12:59:00 GMT
Distribution: world
Organization: The Internet


HI...
WE  WORK A MICROVAX 3400 ,12MB AND ALSO, VAX/VMS V5.2
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
FROM EGYPT.
SABRY
BYE.
From: ncuster@nyx.cs.du.edu (Nate Custer)
Subject: deleteing an rms block
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Tue, 17 Nov 92 23:19:32 GMT


If i create a random access file with rms in my account (i'm the owner)
and someone wants to delete one of the records in that file, can they
do that?  assuming w:rw protection is set?  when you delete the block,
aren't you just telling rms it isn't there anymore?  you're not actually
cleaning up the file right?  anyway, if someone could help would they
email me at 0224465@northwest.missouri.edu

Xref: sparky comp.os.vms:18209 comp.sys.dec:6058
Newsgroups: comp.os.vms,comp.sys.dec
Subject: mv2000 external disk
From: lucas@fallout.lonestar.org
Date: 18 Nov 92 14:21:48 CST
Organization: DECUS DFWLUG BBS *Dallas*TX*


Recently I decided to add an external disk drive (RD5x) to my microvax 2000.
However, the price of a used DEC enclosure for such a drive is a bit
expensive (like more than the mv2000!)  Does anybody have any suggestions or
extra parts that I could use to accomplish a 'home brew' enclosure?

thanks

Marty Lucas
Allied Electronics, Inc.
Fort Worth, TX

lucas@fallout.lonestar.org
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: RE: ?Why does this backup go so slow?  From the original poster.
Date: 20 Nov 1992 20:58:57 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 <1992Nov20.103537.1@woods.ulowell.edu>, welchb@woods.ulowell.edu writes:
>3) When you $MONITOR/DISK, what are the units of I/O measurement?  They seem
>to be blocks per 6 seconds (using the default of 3 seconds of sampling
>and 3 seconds of display).  I was getting approx. 20 on the original
>transfer.

Operations.  I.e., QIOs.  I think.
--------------------------------------------------------------------------------
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.