stopping unwanted output to tty (interim summary)

[Michael C. B. Ashley]

A short while ago I posted this question:
:
:Picture this: you are logged into your trusty DECstation using a 1200
:              baud modem. You accidently enter a command which results
:              in a few megabytes of data being sent down the modem
:              (e.g., perhaps your program had a few more compilation
:              errors than you thought it would :-)).
:
:Question:     How do you avoid having to wait half an hour or so before
:              getting control of your DECstation back again?
:

I have received some 80 e-mail messages in reply, and they fall into the
the following groups (my responses in parentheses):

(1) Have you tried CONTROL-O?  (Yes. It works eventually, but I would
    prefer something that worked immediately.)
(2) You haven't given enough information in your question. (Sorry, I
    should have said that I was using a modem connected through a
    terminal switch using telnet via ethernet.)
(3) If you are using telnet, then there is nothing you can do about
    it.
(4) Get a faster modem.
(5) If you get some sort of credible answer to this question, please
    e-mail a response. The CONTROL-O behaviour *really* annoys me.

By far the majority of respondents were in the last category. In an
attempt to quantify the problem, I logged into the DECstation from a
modem (--> terminal switch --> telnet --> DECstation 5000/Ultrix 4.0)
and monitored the ethernet traffic using tcpdump on another
DECstation. From the modem I tried

cat /usr/man/manl/perl.l       (this is 188015 bytes long)

followed immediately by CONTROL-O. The file perl.l started coming
down the ethernet 256 bytes at a time, the CONTROL-O was received AND
acknowledged by the DECstation after the first packet of perl.l, the
DECstation then sent a further 17 packets of 256 bytes (which took 1
minute of real time) before stopping. I tried a number of experiments
using CONTROL-O and CONTROL-C typed one or more times in various
combinations, and the figure of 17 packets appeared quite stable.

So, to rephrase my original question: does anyone know how to force
the DECstation not to send the additional 17 or so packets?