Warning: Failed mail to VMS host
mail-support%cernvax.cern.ch at pucc.princeton.edu
mail-support%cernvax.cern.ch at pucc.princeton.edu
Wed Nov 21 12:57:20 AEST 1990
Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN at CERNVAX.BITNET> could
not be delivered.
The error message was:
Deferred: %MAIL-E-OPENOUT, error openning as output
This message is equivalent to the DECnet-VAX error message:
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded
The reason why your message could not be delivered is caused by the fact that
your correspondants account has ran out of diskquota. Please contact your
correspondant (by phone or otherwise) and tell him about this problem.
====== The start of Your original message ======
UNIX-WIZARDS Digest Thu, 15 Nov 1990 V11#032
Today's Topics:
Unmountable disk partitions
Re: asserts and unexpected returns (was: Re: Assert)
What is the kernel doing?
Re: What is the kernel doing?
BIND on Ultrix 4.0
Re: Killer Micro Question
Re: Killer Micro Question vs. mainframes
Re: Killer Micro Question
alarm () going off too soon
Re: alarm () going off too soon
alarm () expiring too soon
question on select() and sockets
Re: Alias to change path on the fly - ALTERNATIVE
-----------------------------------------------------------------
From: tanya katz <tanya at adds.newyork.ncr.com>
Subject: Unmountable disk partitions
Keywords: sysV.3.2 disk partition table
Date: 13 Nov 90 15:14:38 GMT
To: unix-wizards at sem.brl.mil
I'm sorry if this is redundant and you have already seen this, but
I have not seen any responses and am trying again. Someone out
there must have an idea about this? Please ;-)
I have a partitioned disk on which I want to mark one or more
partitions as unmountable.
I understand this is currently supported on Unix System V.3 Release 2.
We have Release 1.01 of the Tower 700. I am assuming that there is
some part of the bootblock or partition table that holds this information;
but where?
Can I do this on this version of the O/S? If so, how?
Thanks,
Tanya
tanya.katz at adds.newyork.ncr.com -OR- ...uunet!ncrlnk!adds!tanya
ADDS Inc, 100 Marcus Blvd, Hauppauge, NY 11788 - Tel: (516) 231-5400 x430
-----------------------------
From: "John F. Haugh II" <jfh at rpp386.cactus.org>
Subject: Re: asserts and unexpected returns (was: Re: Assert)
Date: 14 Nov 90 09:04:34 GMT
X-Clever-Slogan: Recycle or Die.
To: unix-wizards at sem.brl.mil
In article <4643 at segue.segue.com> jim at segue.segue.com (Jim Balter) writes:
>No one has claimed that assert cannot be made to return on some systems,
>yet this is at least the third time that you have responded to some *other*
>point as though that claim were being made. Can you say *strawman*?
The other objector to my claim that assert() may return has claimed
that implementations which have an assert() that can be made to return
should be ignored, despite the fact that AT&T UNIX 5.2.1 (and all releases
that I know of before it) has exactly this behavior. Dave has repeatedly
stated that for all "real" UNIX's assert() never returns, without
accepting that this criteria is only true for some flavors of AIX and
BSD. In any case, Dave is arguing against reality - the exception proves
the argument in this case, and the argument was that assert cannot be
relied on to always exit. Providing the single counterexample of SCO
Xenix 2.2.3 (and of course, AT&T UNIX 5.2.1) disproves his statement
that assert() always exits. [ And yes, he has made that claim, before
you state that this is a strawman. ]
Anyhow, this is getting old, and has long strayed away from the original
topic, which was to be careful of unexpected returns.
--
John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832 Domain: jfh at rpp386.cactus.org
"SCCS, the source motel! Programs check in and never check out!"
-- Ken Thompson
-----------------------------
From: Bob Palowoda <palowoda at fiver>
Subject: What is the kernel doing?
Date: 14 Nov 90 09:27:33 GMT
To: unix-wizards at sem.brl.mil
I'm curious, I was running umon386 and watching my system when there was
no activity. I notice that a rawch read causes a process switch. And in turn
it appears that the pwitch causes a iget, namei and dirblk. I assume the
latter are disk access. Why does it do this?
---Bob
--
Bob Palowoda palowoda at fiver | *Home of Fiver BBS*
Home {sun}!ys2!fiver!palowoda | 415-623-8809 1200/2400
More information about the Comp.unix.internals
mailing list