Amount prints in KB in a period

[Enrico Blanzola]

Hi everybody,
on my hp-ux 11i server there're configured a lot of printers (about 230). There's the need to know the amount of prints (size in KB or MB) for every printer in a certain period (for example weekly or monthly).
I noticed that size is shown in "lpstat -t" command or directly under the path /var/spool/lp/request/ but these are temporary information. It would be better to have a log file with history of print-job and relative size.
The spool log (/var/adm/lp/log) doesn't show sizes.
Any idea?
Thanks in advance

[Rita C Workman]

I can't think of a good way to do this because printers can be accessed by so many.
Most shops are similar, the big jobs go to big printers that are only used by servers. But those 230 (like this shop) can be accessed by printjobs from your servers, or printjob from the command line, or print job from any PC or Window server that decides to print something there.

So you really might only be able to gather stats from the printer itself, if it actually keeps them.

Sorry, there's alot of smart folks out there, so maybe one of them has an idea or knows of some third party software that will give you what you need.

Rgrds,
Rita

[Rita C Workman]

Here's a thought for the "bean counter" who came up with this request....

Put in "x" number of reams of paper and keep track how much paper your going through.

Bean counters like that kind of stuff....

Rgrds,
Rita

[Bill Hassell]

It will be a big scripting project. You'll have to monitor *ALL* the print queues in /var/spool/lp/request/ every second, looking for "d" files (d=data, c=control), then make a list of the current files with size, and finally, count the space used after the file disappears (it has been printed). This shouldn't take more than 3-4 days of scripting and testing.

HOWEVER: this space is totally, completely useless unless you are using green bar paper with impact printers (from 20 years ago). Modern printers require enormous amounts of non-printing data and a print job may contain downloaded fonts, bit-mapped pictures, macros, page layout directives, and some text. In other words, a sheet of paper may require 4 MB of data or perhaps 17 bytes for a one-liner. And of course, these printers are on the network so anyone can likely print to them without going through your HP-UX server.

So the question is: do the bean-counters want to monitor network traffic (in which case, the above script will work, but just for HP-UX printing), or printer usage (refer to Rita's 2nd answer above (count the reams of paper)?

[Dennis Handly]

>Bill: HOWEVER: this space is totally, completely useless

Right, besides the reams of paper, there are toner and other consumables that are more important than bytes.

Perhaps the bean-counters should look into HP Managed Print Services:
http://www.hp.com/go/mps

[Enrico Blanzola]

Thanks to everyone for your help.
Actually I give you more infos in order to understand better my request.
- All prints are generated by an application on ux server, so every print pass through unix machine.
- Printers are spread in european sites
Since there is a migration plan for change both unix server site and tool, there's the need to know the amount of data printer for every printer is to have an order of magnitude for network traffic. I thought that unix server had these information, instead of having recourse to networking filters.

[Tom Henning]

Okay, so the intent is short term information gathering. For a short term solution, a quick method might be to place a wrapper script around the lp command (assuming that the application uses this to print) that details the print request to a log file, with the destination and file size, and then execute the real lp command.

This is good only for the short term, since the next time the lp subsystem is patched it will likely break.

Remember to document what you have done, and just as important, how to undo it. So that in months time when you (or the other system admin, assuming you have a backup) try to remember why the lp command is now a script, you can remember why.

[Enrico Blanzola]

Thanks Tom, but I think there would need a deamon for this aim, because prints could come in any time and could be present in lpstat just for few second.
At the moment I would avoid to create a new process on this production server.
I'll continue to search for a solution.
Thanks

[Tom Henning]

No, a daemon is not required. I was trying to suggest something a lot simpler.

1. Write a shell script like:

#! /bin/sh
#
# Shell script to gather printer usage information
ll $* >> /var/tmp/printer_log_file
/usr/bin/lp.orig $*

2. Move the /usr/bin/lp command to /usr/bin/lp.orig.

3. Move your shell script to /usr/bin/lp. Modify ownership and permissions to match /usr/bin/lp.orig.

4. Document in your system logbook what you just did, or you'll regret it some day in the future.

The above script is to demonstrate the principal, and is not complete. It will not handle lp command lines that provide options to the lp system (-). It is also untested.
The file to log to can be named anything, and does not have to be in/var/tmp.

The ll line can be expanded to capture only the information you really want, also.

This solution should not cause harm to the system, and can be easily backed out of my simply changing lp.orig back to lp.

[Dennis Handly]

>Tom: /usr/bin/lp.orig $*

Typically for a wrapper where you don't have to do anything after the call, you should use exec. And also use "$@":
exec /usr/bin/lp.orig "$@"