Printer Queue Page Counting

[David Jones_21]

The accounting file format is described in appendix C of the System Management Utilities Manual 1 (A-L). I believe later versions of VMS moved it somewhere else.

[Paul Anderson_7]

DCPS has a problem with the way many printers respond to the PostScript request for "pages printed". Many printers respond with how many pages have actually dropped into the output bin, which is not going to provide the correct information. This is because your job might start and end before any pages actually leave the printer because of other jobs printing, or the printer warming up from power-save mode, for example.

So what you really want is the number of pages _interpreted_ by the PostScript interpreter at both the beginning and end of the job. Subtracting those two numbers, as DCPS does, results in the correct answer.

The way many printers (including HP printers) do it is give you the number of pages physically printed during the interpretation of your job. That number is not interesting and not correct.

Standard OpenVMS symbionts such as PRTSMB or LATSYM, having no knowledge of PostScript, attempt a page count by counting form feeds or by counting lines. Since there are no form feeds in PostScript files, and the number of lines of PostScript code has nothing to do with how many pages print, this number is a big approximation.

I can't speak for the TCP/IP Services LPD or Telnet symbionts, but they have no knowledge of PostScript either, so the only accurate page counts they provide would be for text files.

Paul

[Jon Pinkley]

Paul Anderson>>"So what you really want is the number of pages _interpreted_ by the PostScript interpreter at both the beginning and end of the job. Subtracting those two numbers, as DCPS does, results in the correct answer."

From a "cost" point of view, printing an 8 page document with the following commands will use varying amounts of sides imaged "clicks" and sheets of paper.

$ print /que=dcps1 /param=(number_up=4,sides=2) doc.txt ! uses 2 imaging clicks and 1 sheet of paper

$ print /que=dcps1 /param=(number_up=4,sides=1) doc.txt ! uses 2 imaging clicks and 2 sheets of paper

$ print /que=dcps1 /param=(number_up=2,sides=2) doc.txt ! uses 4 imaging clicks and 2 sheets of paper

$ print /que=dcps1 /param=(number_up=1,sides=2) doc.txt ! uses 8 imaging clicks and 4 sheets of paper

$ print /que=dcps1 /param=(number_up=1,sizes=1) doc.txt ! uses 8 imaging clicks and 8 sheets of paper

Since accounting has only one field for "pages printed", your description implies that all the above print commands will report 8 pages printed.

DCPS could "compute" the sides imaged or sheets used based on the pages interpreted.

Does DCPS allow you to set a definition of pages printed to one of (pages,clicks,sheets)?

It would also be possible for the DCPS symbiont to use the GETs from source (ACR$L_GETCNT) and QIOs to printer (ACR$L_QIOCNT) fields for clicks and sheets based on DCPS settings. Some customers may find sides imaged and sheets used more valuable than the number of GETs and number of QIOs. This would be done using the accounting parameter to the SMB$SEND_TO_JOBCTL routine when sending the SMBMSG$K_TASK_COMPLETE message.

Jon