Interfaces hang for READ TIMEOUT seconds before processing a message

[Jon Tai]

HLCSTCP1 does a READ with both a #intexpr argument and a :numexpr argument: X#HLDB:HLDREAD. HLDB is set from the BLOCK SIZE field in the HL LOGICAL LINK file; HLDREAD is set from the READ TIMEOUT.

If a small chunk of data (less than BLOCK SIZE) is received, the READ command waits until READ TIMEOUT has elapsed before retuning. This almost always happens, because READBLK^HLCSTCP1 is called to read in a loop until it receives an end-of-message delimiter. In the case that the message is smaller than the BLOCK SIZE, the READ times out. In the case that the message is larger than the BLOCK SIZE, most of it will be read instantly in BLOCK SIZE chunks, but READing the remainder will stall. (Unless of course, the message and its delimiter is perfectly aligned to BLOCK SIZE.)

The message is not processed (and thus ACKs are not generated) until the entire message has been received. Since the last READ of the message almost always waits READ TIMEOUT seconds, we effectively wait READ TIMEOUT seconds before processing any message.