LAT printer won't do big files

[George Robbins]

In article <1990Oct7.234015.18782 at hayes.fai.alaska.edu> fnddr at acad3.fai.alaska.edu writes:
> In article <1990Oct7.004722.4918 at hayes.fai.alaska.edu>, fnddr at 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 at cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)