Ed forwards:
> I don't have a definitive answer but one possible explanation is that with
> hptypeahead set to false it is masking a problem.  Here is an example. The
> host sends Reflection an escape sequence that requires Reflection to
> respond back, such as a status request.  Say the response is 10 bytes long
> plus a carriage return.  The host app posts a read of 10 bytes.
>
> With hptypeahead=false (or before it was implemented) when Reflection sees
> the escape sequence it knows to respond, but will wait for the DC1 from the
> host (under default handshaking conditions).  When the DC1 arrives
> Reflection sends the 10 byte response plus the carriage return.  Remember
> the host has posted a 10 byte read so after the first 10 bytes the read is
> satisfied, the DTC port or NSVT  goes into a "no read pending" state and
> when the carriage return arrives it is discarded.
>
> With hptypeahead=true, the same kind of thing happens except that the
> carriage return is not discarded.  So the next time a DC1 is posted it will
> be immediately satisfied by the carriage return in the typeahead buffer.
> This is where things start to go south and eventually will cause problems
> since the host and Reflection are out of sync.

Sounds like there's a bug here somewhere.

A couple more trivia points that might be related to this problem one way
or another:

I don't suppose you have HPTYPEAHEAD *and* Reflection's own client
typeahead turned on at the same time?

FDEVICECONTROL mode 192 includes a number of options for interacting
with an HPTYPEAHEAD enabled user, and VPLUS should be smart enough to
make use of these functions.  For example, you can use FDEVICECONTROL
to request that the next read bypass the typeahead buffer.  This was
designed specifically for the terminal inquiry type of function.  The
user types :RUN PROGRAM and then immediately starts filling up the
typeahead buffer with input for PROGRAM.  If PROGRAM tries to do a
status inquiry from the terminal, it would normally see the first part
of the user's input, since that would end up in the typeahead buffer
before the response to the escape sequence.  With the FDEVICECONTROL
option, PROGRAM can write the escape sequence and then bypass any
data in the typeahead buffer to read the status response directly.

Now if only we had a function to inquire as to whether or not there
are any characters in the typeahead buffer for DTC/VT/telnet sessions
with HPTYPEAHEAD=TRUE.  This would be useful in a number of places,
such as a workaround to the fact that select() on terminals always
returns true.

G.