Print entries in Accounting - From the do I really know what I thought I did department

[EWL]

I've searched manuals and the internet for an exact meaning of what is meant in accounting for pages printed. Is it based on the number of form feeds the symbiont anticipates will actually be done when the paper passes thru a printer or is it the actual number of pieces of paper that passes thru a printer? Either way would be 'close' enough for horseshoes, but I started questioning this when I started looking into using the accounting entries for resource chargebacks. If a print job is queued but the printer isn't started, does accounting record an entry when the job is queued or when the job actually starts on the printer?

This is one of those things I always thought I understood, but now I'm not so sure. This has almost been a great re-learning experience after 20+ years in OpenVMS.

Thanks for anykind of feedback.

[Jim_McKinney · Accepted solution]

The accounting records are written when the print symbiont calls the SMB$SEND_TO_JOBCTL routine with an accounting argument. The symbiont specifies the number or pages, reads, and writes performed on behalf of the job - after the job completes. The symbiont only knows what it sends to the printer - it can not know if the pages were actually printed - thoug it believes they were. The accuracy of the number of pages is often questionable as they can be influenced by many forces.

[EWL]

Thanks Jim....exactly what I was looking for.

[Wim Van den Wyngaert]

9100 queues pointing to an LPD queue also consider the pages printed while actually the LPD prints them. And the LPD queue says that it didn't print pages.

On VMS 7.3 with TCP 5.3 eco 2 pages printed by LPD is always zero ! Even if printed directly into the LPD queue. I guess accounting is not that important on open systems.

Wim

[David Jones_21]

The lpr/lpd protocol doesn't provide a mechanism for the print server to return pages printed to the client. DCPS, when printing to the RAW (9100) port on postscript devices, will attempt to query the printer to get actual pages printed. On some printers, this gave inaccurate results because the printer was queried before the print job's pages images were still in the printer's internal pipeline (up to 6 pages short on old HP 8100).

We wrote our own printer gateways that stall after each job to get accurate result, but that adds a latency if you have a bunch of small jobs.

For our newer printers, the gateway queries the printer's web interface for the printer statistics.