Chris Breemer wrote:

@ Sorry if you felt my irony was aimed at you ... it wasn't ! I was just
@ enjoying some civilized (I hope) HP bashing... We all recognize the
@ great services some of the HP engineers are doing, probably even in their
@ spare time.

 No insult taken. I was just trying to point out that while we're all
 operating in a friendly collaboration in this forum, I still need to make
 money for my employer.

@ Anyway, I've followed your advice and filed a enhancement request for remshd
@ on the 3k. Hope it helps some. There _must_ be others wanting this, or ... ?

 I'll look up the SR number in a day or so, when it has a chance to
 percolate through the internal network.

 <snip inetd servicing remsh discussion and my hang whine deleted>

@ Yes, the bloody hangs, they're the worst ;-) Good luck and let us know !
@

 Well, I think I have a handle on the hang. Haven't decided on a fix yet.
 and yes, it it looks like a difference between MPE I/O "models" and Unix
 I/O "models". What makes it entertaining is it appears to be timing
 related....

 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)

 Since we're involved in a fork situation, we don't know who will run
 first, the parent or the child. If the work to be done on the remote side
 is short, the parent could conceivably complete and tear down before the
 child read gets posted. If not, once the child read is posted, the parent
 or any other process will not be able to write to the terminal until the
 read is satisfied (I'm ignoring pre-emptive writes at the moment).

 This explains why something like:
 remsh;info="host -l user pwd"  generally works and
 remsh;info="host -l user ls -a" doesn't. I've found that
 remsh;info="host -l user ls filename" works just fine. So it's not
 related to ls behavior.

 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.

 I'll go away now and and look at my options for getting around this. I'm
 going to try and avoid hard pre-emptive writes as they can have other
 side effects on your display.

 Hope this helps and I'll keep y'all posted on where things stand in the
 resolution process.

 cas

--
=======================================================================
[log in to unmask] (Cas Caswell)   By the way: I said it, not my company.
stuperans miaow!     - translated from George Carlin at Carnegie Hall
 =======================================================================