[comp.unix.ultrix] LAT printer won't do big files

fnddr@acad3.fai.alaska.edu (Rice Don D) (10/05/90)

I have set up a couple of PostScript printers (one QMS, one Apple) on a
terminal server and I can access them from a couple of DS5000s/Ultrix 4.0
just fine for small files.  However, when I have a large (>100K roughly) file
trying to print, the serial data lights on the server flash for many seconds
as the file starts spooling to the printer, then they stop.  At that point,
lpq shows the queue is "waiting for 15 seconds before retrying."  I have a
terminal hooked to the printer's transmit data line to monitor PostScript
messages, but there are none when printing stops.  After the 15 seconds
elapses, it tries sending the file again, gets about to the same point,
and quits...goes to sleep for 30 seconds, retries, etc.
There is no indication of an error from the printer or in the lpd error log.
And, if I use the command
	cp bigfile.ps /dev/tty17
it prints just fine.  This indicates to me that lpd is the problem.  For the
record, the laserwriter line is set up in rc.local by
	lcp -s -h /dev/tty17:SCATTER:ISR_ALW
and its printcap is very simple:
	lsr|ISRnet LaserWriter II:\
		:lp=/dev/tty17:sd=/usr/spool/alw:\
		:br#9600:\
		:fc#0177777:fs#023:\
		:xc#0177777:xs#040:\
		:lf=/usr/adm/alw-errs:mx#0:
The QMS setup is basically identical, using /dev/tty16, and they both have
the same problem.
I'm tempted to just use a background copy to the device since that always
seems to work, but I would like to know what is going on.  Something
degradingly obvious no doubt.

Also, if anyone has a fancier printcap for the laserwriter, I would be happy
to know about it.  I'm using lwf from comp.sources.unix to filter ascii files.
[The files that cause the problems above are bitmap graphics, not that it
matters.]
Thanks,
Don Rice                                  Internet: fnddr@flux.fai.alaska.edu
Geophysical Institute                     E-mail:   fnddr@acad3.fai.alaska.edu
University of Alaska                      Phone:    (907) 474-7569
Fairbanks, AK 99775                       Loran:    64.86N 212.16E

grr@cbmvax.commodore.com (George Robbins) (10/05/90)

In article <1990Oct5.021738.939@hayes.fai.alaska.edu> fnddr@acad3.fai.alaska.edu writes:
> I have set up a couple of PostScript printers (one QMS, one Apple) on a
> terminal server and I can access them from a couple of DS5000s/Ultrix 4.0
> just fine for small files.  However, when I have a large (>100K roughly) file
> trying to print, the serial data lights on the server flash for many seconds
> as the file starts spooling to the printer, then they stop.

Sounds like it might be either a printcap determined file size limit or
a flow control problem.

You might try specifying mx=big number instead of 0 to see if the man
page is lying.  Beyond that, interpret the fs# and xs# bits, and also
the flow control options on the LAT port.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)

fnddr@acad3.fai.alaska.edu (Rice Don D) (10/07/90)

In article <14899@cbmvax.commodore.com>, grr@cbmvax.commodore.com (George Robbins) writes...
>In article <1990Oct5.021738.939@hayes.fai.alaska.edu> fnddr@acad3.fai.alaska.edu writes:
>> I have set up a couple of PostScript printers (one QMS, one Apple) on a
>> terminal server and I can access them from a couple of DS5000s/Ultrix 4.0
>> just fine for small files.  However, when I have a large (>100K roughly) file
>> trying to print, the serial data lights on the server flash for many seconds
>> as the file starts spooling to the printer, then they stop.
> 
>Sounds like it might be either a printcap determined file size limit or
>a flow control problem.
> 
>You might try specifying mx=big number instead of 0 to see if the man
>page is lying.  Beyond that, interpret the fs# and xs# bits, and also
>the flow control options on the LAT port.
I've tried mx#9999 with no effect.  Playing with the fs and xs bits is more
interesting.

My initial values, fs#023:xs#040, came from the example ln03 printcap in
the Ethernet Comm Servers manual (p 3-4).  However, the ln03 example in
printcap(5) shows fs#03:xs#044000, which is also what lprsetup produces for
the ln03.  Now according to tty(4), fs#023 is CRMOD|CBREAK|TANDEM, which
looks okay to me.  The xs#040 turns out to be LTOSTOP, which seems dumb,
but I can't figure out xs#044000.  The 04000 is LDECCTQ, but 040000 doesn't
make sense because the local mode is supposedly a 16-bit word.  Anyway, I
tried it and it doesn't fix the problem.

I even tried LAUTOFLOW, though since LAT is all software, I wasn't surprised
when it didn't work.  I don't see any other bits that look relevant.

I turned on debugging (db#9).  The debugging output wasn't very helpful.  This
is what I got for lpr -Ptest small.ps big.ps  (small.ps prints okay, big.ps
doesn't):

/usr/lib/lpd: test: Fri Oct  5 11:30:26 1990: daemon 1072 started
/usr/lib/lpd: test: Ultrix version for daemon enhancements: 3.0
/usr/lib/lpd: test: process_the_queue: while
/usr/lib/lpd: test: process_the_queue: for nitems 0
/usr/lib/lpd: test: process_the_queue: q_enabled
/usr/lib/lpd: test: process_the_job: command file cfA015flux.fai.alaska.edu
/usr/lib/lpd: test: Opening output connection for dev
/usr/lib/lpd: test: fc_run: straight copy
/usr/lib/lpd: test: fc_run: straight copy
/usr/lib/lpd: test: Closing output connection for dev
/usr/lib/lpd: test: Fri Oct  5 11:31:29 1990: Job 15, Retry #1 in 15 secs
/usr/lib/lpd: test: process_the_job: command file cfA015flux.fai.alaska.edu
/usr/lib/lpd: test: Opening output connection for dev
/usr/lib/lpd: test: fc_run: straight copy
/usr/lib/lpd: test: fc_run: straight copy
/usr/lib/lpd: test: Closing output connection for dev
/usr/lib/lpd: test: Fri Oct  5 11:32:47 1990: Job 15, Retry #2 in 30 secs
/usr/lib/lpd: test: Fri Oct  5 11:32:49 1990: daemon 1072 killed by signal 2

It would be nice to know _why_ it decided to close the output connection.
Oh well, guess I'll alias cp as the print command...it knows how to get big
files out to the LAT printers without giving me static.

I'd still appreciate suggestions though...

Don Rice                                  Internet: fnddr@acad3.fai.alaska.edu
Geophysical Institute                     E-mail:   fnddr@alaska.bitnet
University of Alaska                      Phone:    (907) 474-7569
Fairbanks, AK 99775                       Loran:    64.86N 212.16E

fnddr@acad3.fai.alaska.edu (Rice Don D) (10/08/90)

In article <1990Oct7.004722.4918@hayes.fai.alaska.edu>, fnddr@acad3.fai.alaska.edu (Rice Don D) writes...
> ... blah blah blah
>My initial values, fs#023:xs#040, came from the example ln03 printcap in
>the Ethernet Comm Servers manual (p 3-4).  However, the ln03 example in
>printcap(5) shows fs#03:xs#044000, which is also what lprsetup produces for
>the ln03.  Now according to tty(4), fs#023 is CRMOD|CBREAK|TANDEM, which
>looks okay to me.  The xs#040 turns out to be LTOSTOP, which seems dumb,
>but I can't figure out xs#044000.  The 04000 is LDECCTQ, but 040000 doesn't
>make sense because the local mode is supposedly a 16-bit word.  Anyway, I
>tried it and it doesn't fix the problem.
Then there are idiots who know that these printcap args are octal and the flag
definitions are hex, but don't do the base conversion before interpreting them.
The correct interpretations are fs#023 = 0x13 = ECHO|CBREAK|TANDEM, xs#040 =
0x20 = LLITOUT (now that makes more sense than LTOSTOP), xs#044000 = 0x4800 =
LDECCTQ|LPASS8.  But it still doesn't fix the problem.

Don Rice                                  Internet: fnddr@acad3.fai.alaska.edu
Geophysical Institute                     E-mail:   fnddr@alaska.bitnet
University of Alaska                      Phone:    (907) 474-7569
Fairbanks, AK 99775                       Loran:    64.86N 212.16E

grr@cbmvax.commodore.com (George Robbins) (10/08/90)

In article <1990Oct7.234015.18782@hayes.fai.alaska.edu> fnddr@acad3.fai.alaska.edu writes:
> In article <1990Oct7.004722.4918@hayes.fai.alaska.edu>, fnddr@acad3.fai.alaska.edu (Rice Don D) writes...

> Then there are idiots who know that these printcap args are octal and the flag
> definitions are hex, but don't do the base conversion before interpreting them.
> The correct interpretations are fs#023 = 0x13 = ECHO|CBREAK|TANDEM, xs#040 =
> 0x20 = LLITOUT (now that makes more sense than LTOSTOP), xs#044000 = 0x4800 =
> LDECCTQ|LPASS8.  But it still doesn't fix the problem.

You aren't the first one screwed over by the hex vs. octal confusion in prntcap...

Try hooking up your trusty vt100 clone as a "printer" and watch what seems to
go down.  Does flow control work?  Does the file end in mid-file or does it get
down to the bitter end, but miss a few lines or the terminator character?

Try turning on :rw: in the termcap entry and see if this yields more fun.

Is the "big" file from the same origin as the "little" files that work?

I had real problems with files generated by software than put in "paper sizes"
that DEC didn't believe in.  The thing would just swallow them, think for
a long time and do nothing.  Printing the same file with the VMS print spooler
extracted the postscript error message and put it out on a header page, dunno
why the ultrix spooler can't at least suck out the error message and write
it the the error log file...

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)