LH/DH problem

[Art Berggreen]

>	The problem lies in the LH/DH-11 IMP interface.
>	Sometimes, most likely always, it will not set the <END OF MESSAGE>
>	flag in the control & status register if the input buffer is filled  
>	at the same time that <LAST BIT SIGNAL> from the 
>	IMP comes up.
>
>	This causes the LH/DH driver to append the next 
>	incoming message from the IMP to the the previous message.
>	This process (appending of messages) will continue until
>	a message SHORTER then the input buffer size is sent --
>	a RFNM response does nicely.
>
>	This results in the LOSS of the succeeding messages (e.g. RFNMs)
>	since the 1822 protocol handling code expects to get only
>	<ONE> message from the LH/DH at a time.

Being the original designer of the LH/DH (it's amazing how fast 10 yrs passes!)
this piqued my interest, so I decided to have a chat with the folks who
currently have responsibility for these beasts.  Unless the LH/DH is of VERY
early vintage, this problem should not occur.  I hope to find some time 
(I am probably dreaming about having time) and do some experimentation.

The described problem would appear to happen ONLY if a message from the IMP
is one word longer than the buffer being read into.  When the buffer fills,
leaving the data that contains the Last Bit in the LH/DH data buffer, the
Receive DMA terminates and the EOM flag is NOT ON (because the user has not
yet DMA'd the End-of-Message into memory).  What should happen when the
Receive DMA is restarted, is that the remaining word is read into memory
and the DMA should terminate with the EOM flag ON.  If when the DMA is
restarted, the internal EOM status is lost, the following message would
be concatenated with the end of previous message.

A better solution than reducing IMPMTU would be to use I/O buffers that are
slightly larger than IMPMTU (and of course setting the Receive Byte Counter
to be larger that any expected message). 

					"Art Berggreen"<Art at ACC.ARPA>

------