Path: utzoo!attcan!uunet!tektronix!orca!pogo!richk
From: richk@pogo.WV.TEK.COM (Richard G. Knowles)
Newsgroups: comp.lang.postscript
Subject: Re: ^D embedded in PS files
Message-ID: <7279@pogo.WV.TEK.COM>
Date: 17 May 89 22:00:10 GMT
References: <8905051356.AA01321@decwrl.dec.com> <645@cbnewsh.ATT.COM>
Reply-To: richk@pogo.WV.TEK.COM (Richard G. Knowles)
Organization: Tektronix, Inc., Wilsonville,  OR.
Lines: 52

In article <645@cbnewsh.ATT.COM> wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) writes:
>
> But *why* should a spooler care about the end of a job?

The primary reason a spooler needs to know the actual end of a job (ie, when
the interpreter has finished parsing/executing all input tokens and is waiting
for more) is for proper resource accounting.  A secondary reason is to be
able to give the user some assurance that his job will not be effected by
someone else's (ever had someone invoke the image/colorimage command but not
supply enough data?).

I have no idea how many installations actually *use* accounting info, but
since the spoolers generally support the concept you need to be able to
detect when the job is complete so the amount of consumables can be
calculated and an appropriate charge be made to the user.  There is more
than one way to do that, such as:

  1)  adding a special message to the end of a job;
        cons: -- must wrap the job in a save/restore so as to protect the
	         message from redefinitions made by the job
                 *or* append an END-OF-JOB character/message (^D) to the job
		 followed by your special message;
              -- exitserver requests could not be allowed;
              -- user could duplicate the message and thereby avoiding
		 charges;
	      -- How long do you wait?;
	      -- Unreliable if communication channel has any chance of
                 overrunning (quite possible on busy CPU's);

  2)  send status requests and watching for the "waiting" or "idle" state;
        pros: -- probably should be doing status requests anyway to be able
	         to detect error conditions;
        cons: -- "waiting" is not a sufficient indicator (since waiting can
		 in the middle of jobs if your comm channel is slow).  Might
		 have to append a END-OF-JOB (^D) to force the idle state,
		 but imbedded ^D's could also confuse the issue.

I'm sure there are additional ways, but using a ^D echo is much simpler.
The spooler could be coded in such a way that ^D's are valid in jobs and
still use it itself by just detecting any embedded ^D's.  Once detected,
pass it on but hold back any data that follows until the printer echos it
back or the status goes idle, then continue on with the rest of the data.
This way, the spooler knows that only one ^D is outstanding at any one time
and can make a fairly safe assumption about the echo it gets back from the
^D it appended to the job.

-------- Whatever I say is my fault and no one elses! -----------

Richard G. Knowles                        richk@pogo.WV.TEK.COM
Graphics Printing and Imaging                (503) 685-3860
Tektronix, Inc; D/S 63-356
Wilsonville, Or 97070			or just yell "Hey, Rich!"