dbielik@suna.mqcc.mq.oz.au (Danny Bielik) (05/15/91)
We are running Novell Netware 2.15 connected to one Panasonic KX-P4450 laser. 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. Is there a way of preventing this? ******************************************************************************* * Danny Bielik * * dbielik@suna.mqcc.mq.oz.au * * Macquarie University - Sydney Australia * * Phone (W) +61-2-212-6699 Fax +61-2-281-7394 * *******************************************************************************
dbielik@suna.mqcc.mq.oz.au (Danny Bielik) (05/16/91)
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! :-) I have seen the SERVERS, which I can set up, but are they servers for the Q, or Queues themselves? Confusing, isn't it? ******************************************************************************* * Danny Bielik * * dbielik@suna.mqcc.mq.oz.au * * Macquarie University - Sydney Australia * * Phone (W) +61-2-212-6699 Fax +61-2-281-7394 * *******************************************************************************
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (05/16/91)
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
dbielik@suna.mqcc.mq.oz.au (Danny Bielik) (05/16/91)
In article <1991May16.040502.3026@wlbr.imsd.contel.com> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >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. > This, I think is the perfect answer to my problems. In the batch file which runs the DTP software, I can capture with TI=60, and the other processes remain unaffected. Beats the hell out of making new queues or making all tasks wait 60 secs. ******************************************************************************* * Danny Bielik * * dbielik@suna.mqcc.mq.oz.au * * Macquarie University - Sydney Australia * * Phone (W) +61-2-212-6699 Fax +61-2-281-7394 * *******************************************************************************
kenh@techbook.com (Ken Haynes) (05/20/91)
In article <877@macuni.mqcc.mq.oz> dbielik@suna.mqcc.mq.oz.au (Danny Bielik) writes: >We are running Novell Netware 2.15 connected to one Panasonic KX-P4450 laser. > >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. > >Is there a way of preventing this? Increase the timeout value in you job definition to 60 seconds or more. This will allow the queue to remain open during the graphics generation/printing by your application. The job will not start printing until the job is complete and the queue is closed. It will slow your printing down on non graphics jobs, but if you are clever, you can switch between your print jobs using a third party program like PrintQueueAssist by Fresh Technology, or similar program. Ken -- Ken Haynes, CNE 900 Support.... Novell Technical Support 7 Days a week/24 Hours a day UUCP: {nosun, sequent, tessi} kenh@techbook
leonard@qiclab.scn.rain.com (Leonard Erickson) (05/24/91)
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
churchh@ut-emx.uucp (Henry Churchyard) (05/26/91)
In article <1991May20.131643.1535@techbook.com>, kenh@techbook.com (Ken Haynes) writes: > In article <877@macuni.mqcc.mq.oz> dbielik@suna.mqcc.mq.oz.au (Danny Bielik) writes: > >We are running Novell Netware 2.15 connected to one Panasonic KX-P4450 laser. > > > >When large, graphics intensive jobs, such as DTP documents are sent into the > >queue, the server may split them up into smaller jobs. 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. > > Increase the timeout value in you job definition to 60 seconds or more. [...] One solution I have seen in Novell 3.1 is to capture LPT1 with one timeout, then capture to the same queue as LPT3 with ti=60 or whatever. The user can then select the one they want within the application. Unfortunately I guess this won't work with 2.15. -- Martha Churchyard, 72030.1503@compuserve.com Please reply to 72030.1503@compuserve.com, not this account.
maimer@kuhub.cc.ukans.edu (06/12/91)
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 /_/| |/ |/ < )) _ < \ \ \| \ | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++