Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!caen!kuhub.cc.ukans.edu!maimer
From: maimer@kuhub.cc.ukans.edu
Newsgroups: comp.sys.novell
Subject: Re: Print Queue Job Splits
Message-ID: <1991Jun12.034014.31386@kuhub.cc.ukans.edu>
Date: 12 Jun 91 03:40:14 CDT
References: <1991May15.170341.28938@qut.edu.au> <887@macuni.mqcc.mq.oz> <1991May24.033715.18556@qiclab.scn.rain.com>
Organization: University of Kansas Academic Computing Services
Lines: 58

In article <1991May24.033715.18556@qiclab.scn.rain.com>, leonard@qiclab.scn.rain.com (Leonard Erickson) writes:
> dbielik@suna.mqcc.mq.oz.au (Danny Bielik) writes:
> 
> <In article <1991May15.170341.28938@qut.edu.au> owenc@qut.edu.au (Chris Owen) writes:
> <>From: dbielik@suna.mqcc.mq.oz.au (Danny Bielik)
> <>>When large, graphics intensive jobs, such as DTP documents are sent into the
> <>>queue, the server may split them up into smaller jobs.  THis does not pose
> <>>a problem, as the printer puts them together and prints OK.  The problem is
> <>>when another user places a job in the queue while a DTP document is being
> <>>queued, so that the other user's job gets stuck in the middle.
> <>
> <>If you're using capture with timeouts, it's possible that the shell is timing
> <>out while the workstation thinks about the next part of the graphic.  Increasing
> <>the timeout here should fix this (we use TI=10 sec, but its PC and application 
> <>dependent).  Alternately you could setup capture with no timeout, the job 
> <>finishing when the application is exited, or via ENDCAP.
> <>
> <Thanks, Chris.  I may just try this.  We have been using TI=1, but 10 sounds
> <fine.  The other thing I might try, when I get time, is to set up two queues,
> <one with higher priority, and feed the DTP docs in there, so nothing will
> <interrupt them on the way to the printer, i.e. jobs from the lower priority
> <Q.  The only problem is I don't know how!  :-)
> 
> Whoa! Your problem isn't that jobs are getting interrupted. It's that 
> because your timeout is too short, the graphic is getting split into
> multiple jobs.
> 
> /ti=1 means that a pause in the data stream of more than 1 second 
> signifies the end of the print job. On an original IBM PC, running
> Freelance, I've seen cases where a timeout of *120* wasn't long
> enough!
> 
> Sending the jobs to a higher priority queue won't help. I suggest
> that you use PCONSOLE to watch the job being sent to the printer.
> You'll see that it is being sent as a whole slew of little jobs, 
> rather than one big one.
> 
> You might also consider changing the application program. Some
> programs (for instance, Word Perfect) can send *directly* to the
> network printer queues. This avoids all kinds of problems. 
> 
> Another possible (though kludgy) solution is to print to a file,
> then NPRINT the file. In some cases this turns out to be *faster*
> than using CAPTURE!!
> 
> -- 
> Leonard Erickson			leonard@qiclab.uucp
> personal:	CIS: [70465,203]	70465.203@compuserve.com
> business:	CIS: [76376,1107]	76376.1107@compuserve.com
-- 
           |\   \\\\__       Tony Maimer                __
           | \_/    o \                                /  |
            > _   (( <_                               /   |
           | / \__+___/  maimer@kuhub.cc.ukans.edu   /o   /_/|
           |/     |/                                <  ))  _ <
                                                    \     \ \|
                                                     \    |
       +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++