From: am815@cleveland.Freenet.Edu (Joel Peter Anderson)
Subject: Re: STREAMS M_ERROR Message problem
Reply-To: am815@cleveland.Freenet.Edu (Joel Peter Anderson)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Mon, 31 Aug 92 14:41:54 GMT


In a previous article, bad@flatlin.ka.sub.org (Christoph Badura) says:

>In <1992Aug26.130739.19300@usenet.ins.cwru.edu> am815@cleveland.Freenet.Edu (Joel Peter Anderson) writes:
>>The result is the next read or write returns with a -1 and errno is
>>set to 256 - status_code.  The PROBLEM is that the only way to
>>clear the error condition is to close the device.  Typically, the
>>error does not warrent a close.
>
>The *ONLY* way to clear the error condition caused by a M_ERROR
>message is to close the stream. It's documented that way.
>-- 

Well, yes, I found that document in the Vr3 Unix doco, however, this is 
what I found in our manuals for Vr4:


From the UHC supplied Unix Sys Vr4 documentation: [Streams manual,
Appendix B, page 13; copyright 1990]

"Sent upstream by modules or drivers to report some downstream error
condition.  When the message reaches the Stream head, the Stream is
marked so that all subsequent system calls issued to the Stream,
excluding close(2) and poll(2), will fail with errno set to the first
data byte of the messge.  POLLERR is set if the Stream is being
polled [see poll(2)].  All processes sleeping on a system call to the
Stream are awakened.  An M_FLUSH message with FLUSHRW is sent downstream.

-------
ok - that part sounds like what we see, M_ERROR sets an error on your
Stream - close it to get rid of it.  But read on::
-------


The Stream head maintains two error fields, one for the read-side and
one for the write-side.  The one byte format M_ERROR message sets
both of these fields to the error specified by the first byte in the
message. 

The second style of the M_ERROR message is two bytes long.  The first
byte is the read error and second byte is the write error.  This
allows modules to set a different error on the read-side and
write-side. If one of the bytes is set to NOERROR, the the field for
the corresponding side of the stream is unchanged.  This allows a
module  to just [sic] an error on one side of the Stream.  For
example,  if the Stream head was not in an error state and a module
sent an M_ERROR message upstream with the first byte set to EPROTO
and the second byte set to NOERROR, all subsequent read-like system
calls (for example read, getmsg) will fail with EPROTO, but all
write-like system calls (for example, write, putmsg)  will still
succeed.  If a byte is set to 0, the error state is cleared for the
corresponding side of theStream.  The values NOERROR and 0 are not
valid for the one-byte form of the M_ERROR message."

------

This is what we cannot get to work on our system.  I would be happy to
be told we are wrong, that this was changed and the doco is outdated,
or whatever... we just wanna know why the documentation says
this is the case....
-- 
-------------------------------------------------------------------------
  joela@apertus.mn.org           |Freenet: am815@cleveland.freenet.edu
    Joel Peter Anderson          |PNET: jpa@pnet51.orbit.mn.org
    Apertus Technologies         |GEnie:J.ANDERSON71
Newsgroups: comp.unix.wizards