G'day,

  I'm using Chris Breemer's message as a reply-template, but this is not
  totally a reply. Ross Scroggs has written a very nice summary of the
  quandry I'm in. If you've not looked at it yet, I'd recommend a
  perusal.

 RE: Remsh and using the -n option. I'm afraid we're in a bit of a bind.
The only answer I have for the near future, unless something really
drastic happens, is for the supported version of REMSH, I will need to
force the -n option on, disabling reads from STDIN. I realize this will
be a potential problem for Posix shell use and piping command output into
REMAH as data. However, I'm implementing this feature for the people who
need to fire off Unix commands from a MPE Jobstream. They've been waiting
for this for too long and so I'll be implementing to meet their needs now
(for support with 6.0 and possibly 5.5 PowerPatch 3). With the lead time
on MIT submittals and testing requirements, I need to lock the code down
now and can't continue looking at alternatives.

 For the remsh on Jazz, well I may add a 3rd version that contains my best
hack attempt to resolve the problems.  The orginal version (the Steve Elmer
version) has the source (different than mine but essentially the same) and
y'all should feel free to experiment.



Chris Bremmer wrote:
@
@ 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 ) ?

 Actually, there are folks internally who thought the same thing.  But, as
Posix sits on top of MPE it inherits MPE's IO (for better or worse).  Thus,
read block writes even on Posix.  I think Ross hit the nail on the head when
he pointed out that UNIX programs making use of the model of terminal
read/write being overlapped will be difficult to port.

*** Warning the following contains personal speculation. I am not *******
*** in a position to know for certain what others are really      *******
*** doing for next release.                                       *******

 Will this change in the future? Hard to say. CHanging this paradigm will
require rewrites to the TIO Driver, VT Drivers, and the Telnet Server.
Making chnages to VT will also require coordination with external vendors
such as WRQ and Minisoft (I'm sure there are others I just don't recall
them off the top of my head.) who have implemented the VT protocol as
well. It seems unlikely you'll see this change for the next release.

 A more likely scenario will be to get some form of select functionality
built in. There are  things we're trying to do that not having
SELECT work on TIO devices makes very difficult to impossible. I'm not
aware of an active project on this yet, but I do know that it's being
discussed in conjunction with the Posix Smoothing efforts and a few other
things. Unfortunately there's not an obvious means of implementing it,
so I think it unlikely to happen for next release as well.

******* End Specualtion **********************************************

 I tried a few work arounds for the supported project. Unfortunatley hard
preemptive writes, the same writes used by Tell, makes the output
unreadable. And there's no good way for me to be able to tell what's
in the data stream to make formatting decisions. I also investigated
changing the reads in the child process to doing a polling timed read
model. However, Timed reads can not be done over VT ( a large segment of
our customer base used PC-VT clients for primary access to the system
now), so this is unsupportable. It also leaves problems knowing when to
stop reading in a job environment. So I've written these alternatives
off as supportable options.

 Hope this helps put the REMSH client in perspective and let you know what
the final product should act like. As always, I'm intersted in comments or
concerns.

Thanks
cas caswell
HPCSY
--
=======================================================================
[log in to unmask] (Cas Caswell)   By the way: I said it, not my company.
 =======================================================================