Xref: utzoo comp.os.os2.misc:596 comp.os.os2.programmer:413
Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!elroy.jpl.nasa.gov!ames!amdahl!rtech!ingres!seg
From: seg@ingres.com (scott e garfinkle)
Newsgroups: comp.os.os2.misc,comp.os.os2.programmer
Subject: Re: Help with Named Pipes error messages
Message-ID: <1991Jan23.172128.26448@ingres.Ingres.COM>
Date: 23 Jan 91 17:21:27 GMT
References: <1991Jan22.110653.3328@eecs.wsu.edu>
Organization: Ask Computer Systems, Ingres Products Div.
Lines: 38

Newsgroups: comp.os.os2.programmer
Subject: Re: Help with Named Pipes error messages
Summary: 
Expires: 
References: <1991Jan22.110653.3328@eecs.wsu.edu>
Sender: 
Followup-To: 
Distribution: 
Organization: Ask Computer Systems, Ingres Products Div.
Keywords: 

In article <1991Jan22.110653.3328@eecs.wsu.edu> wbonner@eecs.wsu.edu (Wim Bonner) writes:
>
>I am trying to program using  Presentation Manager and Named pipes.   My
>server program creates a pipe, then waits till the client opens it, then
>sends some messages which  the client reads and  replies to.  They  then
>agree on  the name  for a  permanent pipe  between them,  and the client
>opens the second pipe (which  the server had already created)  This does
>not get a  return value of  0, but does  get the same  return value that
>opening the first pipe  got, and it passed  the correct messages, so  it
>seemed that it should be  ok.  The problem appears  to be when I try  to
>set the named pipe state in the  second named pipe.  The call is  almost
>exactly the same, but I get a 1 for a return value, which does not  seem
>to correspond with anything useful in BSEERR.H.

1 is ERROR_INVALID_FUNCTION -- "the pmode argument tried to change
a pipe-mode parameter other than the blocking state or the read mode, or
there was an attempt to put a byte-stream pipe into message-read mode".

Are you sure that the server .exe corresponds to the source?  At first
blow, it sounds to me like the second pipe doesn't have NP_TYPE_MESSAGE
set, though it dows seem so from your source.

Anyway, why bother to open a second pipe at all?  Why not just keep the
connection you started with, spawn off a thread to deal with that connection,
and go make another instance of the named pipe? 

	-scott garfinkle