serial port on DS5000 not responding fast enough to CNTRL/S?

[Michael C. B. Ashley]

In article <900 at usage.csd.unsw.oz.au>, I wrote:

> I have a LaserJet III connected to one of the serial ports on a
> DECstation 5000. My problem is that when I send long files to the
> printer, it loses about 30 bytes every time the LaserJet's input buffer
> fills up. 

I have now examined this problem quite carefully using an RS-232
analyser, and have reached the following conclusions:

    (1) The DS5000 will output anything from 10 to 256 characters from
        its serial port (at 9600 baud) AFTER receiving a control-S. The
        number of characters sent depends on the :fs and :fc options in
        the /etc/printcap file (cooked mode gives you between 10 and 50 
        characters over-run, cbreak gives about 50, and raw (if you
        do the handshaking yourself) gives you up to 256 characters).

    (2) After receiving a control-S, and after the DS5000 eventually
        stops sending characters, it may then send a control-S to the
        printer (if the DS5000 input buffer is filled and if TANDEM mode
        is selected), and when it does so it SENDS A FEW ADDITIONAL
        CHARACTERS.  I only observed this once, but it is a serious bug.

    (3) The LaserJet III will only accept about 30 characters after it
        has sent a control-S to the DECstation. Any more than 30
        characters will result in an IO CONFIG ERR, and characters will
        be lost. This is hopeless. Incidentally, I am using the HP with
        the HP PostScript cartridge.

So, in summary, both devices are at fault: the DS5000 for not responding
to a control-S within a reasonable time, and the LaserJet for not being
able to buffer a reasonable number of characters after receiving a
control-S.

Is there some easy solution to this problem that I have missed? As I
mentioned in my earlier posting I have tried writing my own printer
filter and doing the I/O a byte at a time, but when I ask the kernel if
there are any characters for me to read from the printer (by using a
ioctl(1,FIONREAD,&bytes_to_read);) it replies "no there aren't" even if
some have been seen by the hardware and are filtering their way up 
through the operating system. Also, I'm not convinced that the call 
write(1,char,1) is returning after the character is physically emitted
from the serial port, rather than after the character has vanished far
enough into the kernel that it is guaranteed to be printed (note that I
am using fcntl(1,F_SETFL,FSYNCRON)). 
 
I would rather be doing astronomy than messing with this annoying 
problem :-)

Thanks for any advice.
Michael Ashley / Dept. Astrophysics / Uni. of NSW / Australia
mcba at usage.csd.unsw.oz.au