Warning: Failed mail to VMS host

mail-support%cernvax.cern.ch at pucc.princeton.edu mail-support%cernvax.cern.ch at pucc.princeton.edu
Tue Nov 20 15:21:02 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          Sat, 17 Nov 1990              V11#034

Today's Topics:
                    Re: Unmountable disk partitions
                       Re: Killer Micro Question
                  Re: question on select() and sockets
                     Re: What is the kernel doing?
                    Re: Where the Hell is everyone?
                               Re: YA4.1B
                 Re: SETUID STRIPTS ARE A SECURITY HOLE
                   Grabbing tty (rather than console)

-----------------------------------------------------------------

From: Heiko Blume <src at scuzzy.in-berlin.de>
Subject: Re: Unmountable disk partitions
Keywords: sysV.3.2 disk partition table
Date: 15 Nov 90 20:45:56 GMT
To:       unix-wizards at sem.brl.mil

tanya at adds.newyork.NCR.COM ( tanya katz ) writes:
>I have a partitioned disk on which I want to mark one or more
>partitions as unmountable.

well, a 'perm=NOMOUNT' in the filesystem's stanza in /etc/partitions
sounds logical, but if you want to be *really* sure that you cannot
mount it even from a boot floppy, i'll be happy to send you a little
superblock editor (:-) so you can change the filesystem type magic number
or whatever you like to make mount fail.
--
      Heiko Blume <-+-> src at scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93
                    public source archive [HST V.42bis]:
        scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
                     uucp scuzzy!/src/README /your/home

-----------------------------

From: Heiko Blume <src at scuzzy.in-berlin.de>
Subject: Re: Killer Micro Question
Date: 15 Nov 90 20:59:21 GMT
To:       unix-wizards at sem.brl.mil


In article <16364 at s.ms.uky.edu> randy at ms.uky.edu (Randy Appleton) writes:

#I have been wondering how hard it would be to set up several
#of the new fast workstations as one big Mainframe.  For instance,
#imagine some SPARCstations/DECstations set up in a row, and called
#compute servers.  Each one could handle several users editing/compiling/
#debugging on glass TTY's, or maybe one user running X.
#

you might want to have a look at some backissue of BYTE (about distributed
processing). they had an article about a compute server with a damn lot of
processors. it had a Real Fast Bus and processors dedicated for network
handling etc.
--
      Heiko Blume <-+-> src at scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93
                    public source archive [HST V.42bis]:
        scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
                     uucp scuzzy!/src/README /your/home

-----------------------------

From: Moellers <josef at nixdorf.de>
Subject: Re: question on select() and sockets
Date: 16 Nov 90 07:16:39 GMT
Sender: news at nixpbe.nixdorf.de
To:       unix-wizards at sem.brl.mil

In <ABDIK.90Nov14162831 at lion.cat.syr.EDU> abdik at cat.syr.EDU (Ahmad Dik) writes:


>I would like to know if select() can be used to find out if there is
>a blocked read on a socket.

>In other words, will the second parameter of the select() function
>tell me if the socket's buffer is empty, and I can write to it, or
>does it tell me that there is someone blocked trying to read from the socket.

>If select can not be used to tell if anyone is blocked reading on a
>socket, is there any other way I can find out ??

The second parameter tells You if You can write to the socket.
That does not mean that the buffer has to be empty, just that there is
enough room to accomodate a write(). It doesn't tell You how much You'll
be able to write.
Needless to say: it's a vector with a bit for each fd.

To my knowledge there is no way of telling if anyone is blocked on the
other end of a connection as
1. the "other party" might be on a different machine far far away
2. the "other party" might not even be a UNIX box that knows what a
   "process" is or how one can "block".

--
=======
| Josef Moellers		| c/o Siemens Nixdorf Informatonssysteme AG |
|  USA: mollers.pad at nixdorf.com	| Abt. PXD-S14				    |
| !USA: mollers.pad at nixdorf.de	| Heinz-Nixdorf-Ring			    |



More information about the Comp.unix.internals mailing list