Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!caen!dali.cs.montana.edu!ogicse!qiclab!leonard
From: leonard@qiclab.scn.rain.com (Leonard Erickson)
Newsgroups: comp.sys.novell
Subject: Re: Print Queue Job Splits
Message-ID: <1991May24.033715.18556@qiclab.scn.rain.com>
Date: 24 May 91 03:37:15 GMT
References: <1991May15.170341.28938@qut.edu.au> <887@macuni.mqcc.mq.oz>
Organization: SCN Research/Qic Laboratories of Tigard, Oregon.
Lines: 48

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