composer@bucsf.bu.edu (Jeff Kellem) (03/24/90)
Has anyone else seen the following problem??
Scenario: a couple printers hanging of an annex box
print queues off a Multimax running UMAX4.2 (doubt this matters)
annexes are Annex-IIs, running v4.1
Problem: after some number of pages, a job will restart from the beginning
(same header page, job number, etc).
This usually occurs for large jobs and the position that it restarts at
varies.
Note: A "large" job in this case could be a 30 page print job, though 30
pages is not very large.
Thanks for any info or pointers on this...
-jeff
Jeff Kellem
INTERNET: composer@cs.bu.edu (or composer@bu.edu)
UUCP: ...!harvard!bu-cs!composerloverso@Xylogics.COM (John Robert LoVerso) (03/29/90)
In article <COMPOSER.90Mar23212703@bucsf.bu.edu> composer@cs.bu.edu writes: > Scenario: a couple printers hanging of an annex box > print queues off a Multimax running UMAX4.2 (doubt this matters) > annexes are Annex-IIs, running v4.1 > Problem: after some number of pages, a job will restart from the beginning > (same header page, job number, etc). It *is* important that you are using UMAX4.2. In particular, how are the printers feeding print data to the Annex? With UMAX4.2, you have several choices: 1. Using "ra=" in /etc/printcap This uses the Annex LPD protocol and should not be any different than any other host using a modified Berkeley spooler. There is no known problem with this that would cause only half a job to come out. 2. Using RDP (via an rnode) and "lp=" in /etc/printcap This should also work without a problem (I.e., even though there are several problems with RDP, this isn't one of them). If this is how you are attaching your printer, you should definitely call Encore customer service. 3. Using an rtelnet-created device and "lp=" in /etc/printcap You should not use rtelnet under UMAX4.2 because of several problems in the networking code, including problems with non-blocking I/O not working properly and interrupted system calls not being properly restarted. In particular, with rtelnet, a write is done but is interrupted, and so an EINTR results. However, there has usually already been a partial write, and there is no information on how many bytes of the buffer were actually written. I.e., the output datastream is hosed. For this reason, do not use rtelnet under UMAX4.2 (at least up to and including R3_3). Either way, if you are having problems with Encore-supplied programs, you should report the problem to Encore Customer Service. When they have eliminated any potenial UMAX problem as the cause, they will then forward the problem onto Xylogics. John -- John Robert LoVerso Xylogics, Inc. 617/272-8140 x284 loverso@Xylogics.COM Annex Terminal Server Development Group