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