DN> The server process usually is an OS/2 app. Indeed, I cannot think of a
 DN> way of creating a named pipe from within a VDM. I was referring to the
 DN> client app when I wrote about VDM and VMB.

        That wasn't quite clear, but let's get this thing working under a
purely OS/2 environment before trying the OS/2-VDM mix, OK?

 LR>         I'm not using COMMAND.COM, even in a VDM.  4OS2.EXE
 LR> (and CMD.EXE, yes, of course I tried it) may be assigning
 LR> the pipe, but the strings are not passing through it.

 DN> Now you are saying that you are running the client app in an OS/2
 DN> session. If so, where does the DOS compiler fit in? [No lewd remarks
 DN> from Mr. Pollard!]

        Although I have of course tried the DOS code (the file access error
code changes when the pipe is created), if MORE and TYPE won't work in
OS/2, there is little point in trying to get the DOS code to work, is
there?

 DN> So, the scenario is that you are running an OS/2 server process and
 DN> trying to use TYPE and/or MORE at an OS/2 command prompt as a client
 DN> process.

        Yes.  This is step one of the test process.  Once that is working,
I can try the VDM as the client.

 DN> Since you are using file redirection to achieve this you will,
 DN> I think, need to have the pipe created with inheritance bit set, since
 DN> external commands are run as child processes of the shell process. This
 DN> is an option set by the server process in the DosCreateNPipe() API.

        I'll check on this, but since it works on the author's system, I
can't see how he could be not doing this.

 DN> You alluded to another person writing the server code. It should be
 DN> quite easy for him/her to check this, since only one DosCreateNPipe()
 DN> call need be made, even if multiple instances of the pipe are to be
 DN> active concurrently.

        No, just one instance.  I'll check with him, though.

 DN> Well, you were the one who said you were using a DOS compiler to
 DN> prepare the code. In what other environment could the code run?

        The code has little chance of working in a DOS environment if the
raw API isn't working under OS/2, no?

 DN> My experience has been that application code should be suspected
 DN> first, then a compiler's code gen. and run-time library, and lastly
 DN> the underlying OS's API.

        Yes, of course.  However, since it works on his system, and not on
mine, it is differences in the system which are suspect, no?  The
executable code is the same.  (It's a single, stand-alone .EXE, BTW.)

 DN> However, if I hadn't asked about your VDM configuration I would have
 DN> been _assuming_ that you had checked everything.

        Understood.

 DN> details are easy to overlook, even for experienced professionals. As a
 DN> professional myself, I would rather ask and be sure than assume

        Yes, I know.  The point is, I had expressed that the trouble
existed BEYOND the VDM interaction.

 DN> you posted, I _had_ to ask. No offence was intended.

        None was taken.  It's just that time is short, and the author is
talking about abandoning the project.  I need it working before that, as I
suspect it won't work in its current configuration.  Focusing on concerns
with the VDM aren't going to help until TYPE and MORE are working under
OS/2, yes?

                                                     Les

e-mail: lrhorer{at}fibrcom.com

--- EZPoint V2.2