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.