[SOLVED] Tru64 Printing to something other than a printer

I have been searching for a solution to a printing issue for several months now and have come up with no decently working solution. Please give input.

We have an old inventory control program running on TRU64 Unix V5.1B operating system. Around 2003 it was virtualized onto VMware via AVT's vtAlpha emulator. The program appears to have been written to print it's own internal events to two files (log_file and log_file1) which are then lpr'd to printers (control and logger) set up in the operating system via printcap and then the files are deleted. The printcap file showes these printers to be lp=@ip.address:9100 which are old HP print servers (lan to parrallel) with simple text only dot matrix printers attached.
These two printers print an average of about 3 single line entries per 1 minute, 98%+ of which is not needed. There is 1 print job (about 6 lines of text) submitted and printed every hour with an inventory update, which IS needed. Therefore, I cannot just redirect the printers to /dev/null.

We cannot just turn off the printers because the spooler then stops once it gets to about 100 entries and the program hults (but not the system). I say this because we can go in and purge the print queue (via lpc) and everything starts working again.

I did figure out that if we turn the spooler off, the log_file and log_file1 do not get deleted, but are instead appended to. The problem here is that 1 weeks worth of "held" printing ended up creating 1 log_file a little over 350KB and crashed the entire unix system because it filled up the minimal available disk space. We did have a backup of the VM, but this created about 8 hours of downtime till we cleaned up and updated the program's internal database.

A few things to mention...
1: There is a network obviously, but everything else is windows based.
2. There are no programmers that are willing to try to tackle re-writting the software (internal or external).
3. Everything that is "printed" is actually submitted to some sort of file and then that file is spooled to the printer (the log_file and log_file1 are just some of the files) then the files are deleted.
4. If these files exist, they are appened to and not over-written.

I am not sure what options I have, therefore I do not have specific quesitons on how to do something.
Can we change the printcap to print to a file or something else somewhere else?
Can we set up some sort of filter that only prints the information we want and just ignores the rest?
Are we just stuck and have to keep replacing print cartridges and paper regularly?
Is there anything else you would like to know to help you help me?

Thank you in advance.

Wow - Tru64!

When I saw your post I thought about using named pipes (FIFOs) where you send your prints to a script that extracts only what you want then that actually prints what it extracted. It has been a while since I played with named pipes but I found this link that is sort of on track to the idea that may help you get started:

https://unix.stackexchange.com/quest...ut-interfering

I'd previously used named pipes for MeasureWare/Perf data collection on HP-UX years ago so I'm assuming Tru64 has the same capabilities to use them though I've never worked on it (even after HP bought Compaq and got Tru64).

Basically you would like to take that print stream and instead of going to a printer, you want to take it to a file or parse it some way?

You might be able to take that jetdirect stream and use it in some manner I'd guess unless your ip example is in conflict with some subnet issue I'd think. https://unix.stackexchange.com/quest...-raw-port-9100 example but look for other ways in this stream capture.

As you say there is no one willing to mess with this code and down time is critical. Might be worth it to just let it print. Maybe set print font on printer to 6.

Jetpcl may be a solution but I didn't look at it too much.

I would think that some business printers could be set to monitor and save pages to internal but report as being printed back to software.

See if the answer in this thread is helpful. It does print to /dev/null (no nothing printed), but the required data is written to a file via an output filter

:of=:of=/var/output/capture:\

pointing to a very simple script (outlined in the answer).

I should check this forum out more frequently. I hope you're not still having this problem but in case you are...

Originally Posted by Ken_Snauffer I have been searching for a solution to a printing issue for several months now and have come up with no decently working solution. Please give input. We have an old inventory control program running on TRU64 Unix V5.1B operating system. Around 2003 it was virtualized onto VMware via AVT's vtAlpha emulator. ...

Nifty little emulator. Looks like a real Alpha from the console. I was involved on a project some time ago using this product to rehost a system off of sunsetted Alpha hardware. It would have been so-o-o easy to do if the client had actually been testing their backup tapes.

We cannot just turn off the printers because the spooler then stops once it gets to about 100 entries and the program hults (but not the system). I say this because we can go in and purge the print queue (via lpc) and everything starts working again. [snip]

If you know something about the contents of the files that are being queued, I'd take a look at doing something like:

• Keeping the queue stopped -- let jobs be queued but not print: "lpc down queuename"
• Examine the files in the queue for the content you are not interested in. When found, delete those entries: "lprm -Pqueuename queueid"
• When the queue contains only the files you need to have printed, re-enable printing until the queue is emptied. Then disable printing again: "lpc up queuename"

I'd look into running a script to do this in cron every few minutes.

This should be easily scripted (sh, ksh ,Perl, etc.) and run in cron every few minutes. I'd schedule it to run fairly frequently. Most of the time it'd probably find nothing to do and exit quietly. You could run it less frequently (lower "overhead") but users might have to wait several minutes to receive print jobs

I can envision that, occasionally, one of the unwanted print files may slip through if they get queued within the window where you've re-enabled printing but that should be minimal but I suspect you could prevent that by:

1. "lpc down queuename" to stop printing
2. Examine files and remove those you don't want printed with "lprm" as needed
3. "lpc disable queuename" to prevent further queueing
4. "lpc up queuename" to allow printing of the queue contents that should now contain only the reports you want.
5. Monitor the queue to test whether print jobs are still waiting to be printed.
6. When the queue is empty: "lpc down queuename" (disable further printing) followed by "lpc enable queuename" (allow queueing).

What I'm not sure about is whether disabling queueing in step 3 affects the printing of currently queued jobs. I'd test it but I haven't worked in a Tru64 environment for a number of years and the Alphaserver 400 I had at home went to the Great Datacenter In The Sky a few years ago.

Hope this helps some...