Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!mahendo!wlbr!WLV.IMSD.CONTEL.COM!mcc
From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Newsgroups: comp.sys.novell
Subject: Re: Print Queue Job Splits
Message-ID: <1991May16.040502.3026@wlbr.imsd.contel.com>
Date: 16 May 91 04:05:02 GMT
References: <877@macuni.mqcc.mq.oz>
Sender: news@wlbr.imsd.contel.com (news)
Organization: Contel Federal Systems
Lines: 25
Nntp-Posting-Host: wlv.imsd.contel.com

In article <877@macuni.mqcc.mq.oz> dbielik@suna.mqcc.mq.oz.au (Danny Bielik) writes:

>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.

We had a similar problem with AutoCAD applications.  On complex print jobs
which required downsizing the output for HP LJIII, the HP LJIII set up data
was sent at the beginning of the job but prior to AutoCAD performing the
remapping of the image.

The solution for this specific case was to use the /TIme switch to the CAPTURE
command.  With CAPTURE /NT /TI=60 used to capture the output, the 60 timeout
intervals allowed the complete output to be captured as a single file.  The
impact of the delay was restricted to the user who needed to print the large
and complex plots.

You could also do this through changing print server parameters; however,
the problem with that approach is that it impacts all users.  Unless an EOF
condition is detected, the /TI=60 will force a 60 timeout period delay after
the last character is captured and placement of the file into the queue.

Merton Campbell Crockett