Newsgroups: comp.sys.novell
Subject: Re: Utility To Close Spool For Just One Job?
From: Aengus Lawlor <RBYAML@rohvm1.rohmhaas.com>
Date: Sun, 4 Oct 1992 21:58:24 EDT
Organization: Rohm and Haas Company

In article <BvKypF.J4q@sti.com>, westes@sti.com (Will Estes) says:
>
>In article <92276.173954RBYAML@rohvm1.rohmhaas.com> Aengus Lawlor
><RBYAML@rohvm1.rohmhaas.com> writes:
>>In article <BvHEGp.26u@sti.com>, westes@sti.com (Will Estes) says:
>>>
>>>Does anyone know of a netware utility that will close the print spool
>>>but leave the capture command on the printer port intact for future
>>>printing?  It is an incredible defect in the architecture of the current
>>>capture command that I can issue multiple print commands within the
>>>timeout period for the spool and have these jobs all concatenate
>>>together.  This sounds more like a mainframe computer printing system
>>>than a PC print spooler that was designed with naive end users in mind.
>>
>>The NetWare print spooler will send a job to the printer when either it has
>>received no data in the last X seconds, where X is the preassigned timeout
>>value, OR when the application informs it that the print job is complete.
>>An application informs the spooler that the job is complete by closing the
>>file it is printing to (LPTx). If an application assumes that it owns the
>>printer, and therefore it decides to keep the file open, the spooler has
>>to assume that the application is still thinking about the next bit of the
>>job it wants to print, so it considers the job incomplete.
>>
>>The only defect in this architecture is that is impossible to account for
>>programmers who are too ignorant or lazy to close the LPTx file when they
>>are finished with it.
>
>I think what we have here is a difference in philosophy, not a
>difference over facts.
>
>In my opinion, a program should serve the needs of the customers who use
>it.  Saying that most DOS application programmers are lazy is only a
>technical defense.  In fact, the failure to be able to close a spool on
>demand causes customers problems precisely because so many DOS
>applications are not written to close the spool.  Given that this is the
>state of the world, what I need from Novell is not a set of excuses
>about how application programmers are lazy.  What I need is a utility
>that compensates for their laziness.  You should also remember that in
>my example I am using some command-line utility to quickly print off a
>large number of files.  So it is a perfectly reasonable thing to want to
>be able to close that spool if the application didn't do it for me!
DOS is supposed to do it for you! DOS is supposed to automatically close
all open files when an application ends. Now, maybe MS changed it so that
it doesn't do that any more, or maybe your application, for reasons of
it's own manages to quit without actually telling DOS about it, or maybe
it's a TSR, but flaming Novell for this is not particularly reasonable.
(Unless you don't consider the words "incredible defect" to be a flame).

Novells CAPTURE program is written to work quite effectively with the
documented behaviour of DOS.
>
>Incidentally, I got three pieces of mail from users who told me that
>this problem with CAPTURE also drives them crazy, and one of them even
>sent me a utility that closes the spool.  So I am apparently not the
>first person to have this sentiment about CAPTURE.  If you want Novell
>to hear you, you should post those replies for Novell people to read.
I don't quite understand what the last sentence is supposed to mean,
but perhaps you could tell us what verions of DOS, NETx and Capture you're
using and what parameters you are giving it, and what verion of NetWare
is running on your server. And what utility you're using to do the printing?

For the record, I tried to deliberately concatenate two printouts, and I
couldn't.
>Please note: I am just asking for some extra capability above what is
>already there to make my life easier.  It doesn't require that the
>current architecture for print spooling under Novell be abandoned, and
Even if they are  "incredibly defective"?

>since it's about three days of programming and testing for a
>knowledgeable programmer, it should really be a non-decision for
>Novell...do it because it will benefit customers without any downside.
>
>--
>Will Estes              Internet: westes@netcom.com
--
RBYAML@ROHMHAAS.COM                    Aengus Lawlor
RBYAML@ROHVM1.BITNET                   (who used to be ALAWLOR@DIT.IE)
"How about some of that famous Dublin wit, Barman?"
"Certainly, sir. Would that be Dry or Sparkling?"