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)