>From some previous postings:
> . > > Reading the PJL specification, I gathered that you could send the followi
> . >ng
> . > > sequence to achieve the same.
> . > >
> . > > <ESC>[EMAIL PROTECTED]
> . > > @PJL ECHO attempting PAGECOUNT
> . > > @PJL INFO PAGECOUNT
> . > > @PJL ENTER LANGUAGE = PCL
> . > > ...
> . > > @PJL EOJ
> . > > @PJL ECHO attempting PAGECOUNT
> . > > @PJL INFO PAGECOUNT
> . > > <ESC>%-12345X
> . > >
> . > > The ECHO command is suppose to synchronise the output given from the prin
> . >ter.
> . > > That way, you would only need to get the start and end pagecounts from th
> . >e
> . > > open connection and they would almost always be correct.
> . > > or am I being gullible in thinking that the printers follow PJL strictly?
> . > >
> . > > Just a thought...has anybody tried anything like this before?
> . > >
> . > > Christopher
> . >
> . > Yes. However, you must get the pagecount AFTER the job has
> . > finished. The way that you have it now you will get the
> . > CURRENT pagecount... which may be the same as the starting
> . > pagecount if the printer is warming up.
> . >
> . > I kid you not.
> . >
> . > Isn't this wonderful?
> .So does that mean that the ECHO doesn't synchronise as it is documented
> .that is should do?
> .
> .
.,...
>
> From the PJL Reference:
>
> Page 7-2
> To clear any possible unread status responses requested by the
> previous application, upon startup, an application should use
> the ECHO command...
>
> Page 7-14
> ... Since the status messages are buffered in the printer until they
> are received, the current application may receive status messages
> that were requested by a previous applciation. (This happends in
> situations where the application requests information or unsolicited
> status is enabled, and the application closes before receiving the
> status messages).
>
> Basically, what you get with this is a 'marker' in the output
> stream. It does not provide any indication that the previous
> job has completed. In fact, my observation is that if you:
>
> a) connect using TCP/IP
> b) send job
> c) disconnect
> d) send new job
> (with echo)
>
> Then:
> a) some printers refuse connection while previous job is in progress
> b) some printers accept new connection, but will not accept data
> (sigh...) while previous job is in progress
> c) some printers will accept 'no output jobs' and fake their acceptance
> d) some printers will do c), and only when there is a job with output
> will they then block all additional IO until the previous job is
> finished.
> e) some printers will do d), but also have the interesting behavior
> of reporting errors (out of paper, jam, etc) FOR THE PREVIOUS JOB
> that is in progress.
I am willing to take another crack at this if somebody has a printer
that I can play with for a while.
I need:
a) user logged on to the print spooler
b) somebody standing next to the printer to tell when job is finished
c) telephone call to me.
Patrick ("Remote Console? Hell... I need a remote user. Bring on the Droids!") Powell
Call me at the number below if you have time and want this fixed:
Patrick Powell Astart Technologies
[EMAIL PROTECTED] 6741 Convoy Court
Network and System San Diego, CA 92111
Consulting 858-874-6543 FAX 858-751-2435
LPRng - Print Spooler (http://www.lprng.com)
-----------------------------------------------------------------------------
YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST
The address you post from MUST be your subscription address
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
