Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!bionet!hayes.fai.alaska.edu!acad3.fai.alaska.edu!fnddr
From: fnddr@acad3.fai.alaska.edu (Rice Don D)
Newsgroups: comp.unix.ultrix
Subject: Re: LAT printer won't do big files
Message-ID: <1990Oct7.004722.4918@hayes.fai.alaska.edu>
Date: 7 Oct 90 00:47:22 GMT
References: <1990Oct5.021738.939@hayes.fai.alaska.edu> <14899@cbmvax.commodore.com>
Sender: usenet@hayes.fai.alaska.edu (J Random USENET)
Reply-To: fnddr@acad3.fai.alaska.edu
Organization: University of Alaska Fairbanks
Lines: 62
News-Software: VAX/VMS VNEWS 1.3-4

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