Cas Caswell wrote:

[snip]
>  If you run remsh and do not specify the -n option to disable STDIN, remsh
>  forks a child process to read STDIN. So you now have two processes active
>  and doing I/O to your terminal. It is my understanding that in Unix, you
>  can have a read on STDIN and do a write to STDOUT and have the write
>  go through. With MPE, once you get to the terminal driver, ie once the
>  file sys maps STDIN and STDOUT to the physical device to talk to, the
>  driver is written such that you do not write through a read. When the
>  read completes, then the write is sent to the physical device. So in MPE
>  land if the child process hangs a read on STDIN, it will block writes
>  from the parent prcess to STDOUT.(ignoring pre-emptive writes)
>
We had the same problem in our application. A child process was doing the
keyboard read and sending the keystrokes over a pipe to the parent. The
parent wanted to update the screen and could not do it until the child
received at least one character. We got around this problem by using an
XL supplied by CSY in Boeblingen,
which could do screen writes on sub-MPE level so that it would not have to wait
for a blocking keyboard read. This worked well enough, but only over a hardwired
or DTC terminal. It failed over a network connection.

I would have hoped that with the POSIX implemetation the keyboard and
screen would not lock each other out, but aparently this is still the case.
I suppose in a 'real' UN*X there are actually two device drivers, one for
screen and one for keyboard, whereas in MPE there's only one, for the thing
MPE calls 'terminal'. I don't think POSIX specifies anything on this level.
However it seems likely that other posix apps being ported in from UNIX will hit
this same problem. Is it likely to get changed in the future ? Are there any
hard reasons for having this blocking scheme (except for historical MPE
design features that might not apply to posix ) ?

[snip]

>  At this point my recomendation is to always specify the -n option when
>  running remsh from MPE iX space. It should not impact your ability to
>  pipe data into the remsh (ie I don't believe you can do that in MPE
>  space). Further I recommend that running remsh from the posix shell you
>  should specify the -n parm UNLESS you are doing some form of piping into
>  the remsh.
>
That should be working well enough. Unless of course the pipe is emptied
before the screen output is written, which will probably happen.
Or is the keyboard read posting deferred until nobody is writing to the screen ?
In that case it's no problem.


        Chris Breemer
        Compuware Europe B.V.