BOLTHOUSE%MCOPN1@eg.ti.COM.UUCP (05/27/87)
VMS print accounting is somewhat unusual in that it doesn't actually count newlines or other 'magic' characters to make its decisions. Your problem with the number of pages printed is the exception to that rule. If your device handles pagination itself, then the symbiont only sends out one *very* large page (i.e., /NOFEED). The symbiont duly reports to the job controller that it printed one page. That's what the job controller then drops off into the accounting file. Note that it's not accounting that's messed up, but the symbiont! This is fixable if you know the ins and outs of symbiont alteration. Those I know who have mucked with the symbiont tell me it's not that tough, but I haven't done this myself. Mucking with the symbiont will also resolve the problem of having the number of lines incorrectly reported. You can count the number of lines yourself, and report that back to the job controller as the number of $GETs from source. Admittedly, this contradicts the intended spirit of the number, but the point is, you can make accounting be what you want it to be if you work at it hard enough. The reason the number of $GETs from source is different with the 2 devices is because (I think...) the DMF-32 based printer can grab/buffer more data at a time than the LP11 based printer. This, I believe, is also something the symbiont can recognize. The LP11 is the most inefficient way I know of to run a printer (no...I suppose you could run one serially off a DZ11. Yuck!). Again, if you want to know how many lines were printed, you should count newlines yourself in the symbiont. Has anyone any ideas how we're ever going to handle accounting for printers that understand page-description languages (i.e., PostScript)? Page by page seems easiest, but I don't know if that's possible. Just a random, passing thought... David L. Bolthouse Texas Instruments Defense Electronics Information Systems VAX System Support McKinney, Texas Ma Bell: 214-952-2059 Internet: bolthouse%mccore@ti-eg.com
LEICHTER-JERRY@YALE.ARPA (05/28/87)
At the end of an excellent discussion of printer accounting, David Bolthouse comments: Has anyone any ideas how we're ever going to handle accounting for printers that understand page-description languages (i.e., PostScript)? Page by page seems easiest, but I don't know if that's possible. Just a random, passing thought... To expand: It's exactly because it's been clear for several years now that this class of printer was the wave of the future that the default accounting stuff in the symbiont is so limited. If your model of a printer is that it's kind of a fast terminal, then counting line feeds or page feeds or even the total number of bytes makes sense. But modern printers are much more complicated than that, and trying to understand just what printer X is going to do with data stream Y can be very complex. There is no simple correlation between any of the obvious measures of the input file with the amount of output produced - a short Postscript program can produce an infinite amount of output. Ultimately, only the printer itself is able to judge what resources it has used - whether "resources" should include paper, lines, time, or whatever - and it will have to be the printer that calculates the charges. I've heard mention - perhaps on INFO-LASER - of Postscript programs to do just that. They would have to be used in conjunction with symbionts that knew how to ask the printer for this information and then add it to the accounting records. -- Jerry -------
CP.PAVER@MCC.COM (Bob Paver) (05/29/87)
I was skimming the technical ref. manual for a TI2108 printer that we have in on evaluation. It described a Postscript (tm) function to return the value of the page counter in the printer. This is the way to go for page counting. Of course the symbiont needs to be "educated." -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Bob Paver (512) 338-3316 Microelectronics and Computer Technology Corp. (MCC) 3500 West Balcones Center Drive Austin, TX 78759 ARPA: paver@mcc.com UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!im4u!milano!paver -------