stanonik@NPRDC.ARPA (Ron Stanonik) (08/25/86)
Hello, We're having a problem with postscript printers hanging several times a day while printing (usually trivial one page) troff output. We're running Transcript 2.0 on a Vax 780 running 4.2bsd. The problem was observed on a Qms800, but we recently substituted a LaserWriter with the same results. From the log we observe the following psif: done sending waiting e0 i0 0 0 >>%%[ Error: undefined; OffendingCommand: BP ]%% >>%%[ Flushing: rest of job (to end-of-file) will be ignored ]%% psif: listener saw eof, signaling psif: FA 0 2 0 psif: FA 0 2 0 ad infinitum Taking a look at the current processes, the receiver pscomm has exited, but psrv has NOT! The sender pscomm is looping waiting for its children (normally only the receiver) to die! Two questions come to mind. Why is BP sometimes undefined? It's defined in pscat.pro and the same job restarted runs fine. How could psrv still be running after the sender is "done sending"? The sender stays in its sending loop until seeing eof on the pipe from psrv, the latter only happens when psrv exits. And only on seeing eof from psrv does the sender send the PS_EOF, which on return to the receiver causes it (the receiver) to exit. We blamed the problems for a long time on bad communications with the printer (which is in another building). We were confused by a third problem. Apparently the burst of error messages (OffendingCommand and Flushing) from the printer were occasionally too fast for the Vax which sent a control-s and (presumably) then a control-q. The Transcript software as delivered puts the Vax into tandem mode, presumably just for this purpose. We now suspect the printer is "missing" the control-q. Maybe flushing it along with the rest of the job (to end-of-file)? Nah! At any rate, we turned tandem mode off, and now find the sender hanging. We've looked at pscomm.c and psrv.c, carefully, many times, to no avail. Any ideas? Thanks, Ron Stanonik stanonik@nprdc.arpa ps. To be fair, we swapped in the laserwriter after tandem mode was off, and so can't say that the laserwriter exhibits the xon/xoff problem.