Alternatives to printing on paper

[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.  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.

[Steven Schweda]

> [...] virtualized onto VMware via AVT's vtAlpha emulator. [...]

> [...] 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. [...]

   How can "350KB" (less than an old floppy) be enough to crash
anything?  How does one run out of emulated disk space?  Can't you just
specify a larger emulated disk?  (How much could that cost?)

   I haven't printed anything from a UNIX system since before I can
remember, so I know nothing, but ...

      man printcap

> Can we change the printcap to print to a file or something else
> somewhere else?

   I'd try defining a printer with an output filter ("of"), which could
be a shell script, which I'd write to process the data-to-be-printed as
I wished.  If it could distinguish between useless and useful, then it
could ignore the useless parts.  The useful parts could be transmitted
(by "cat", e-mail, FTP, whatever) to some desired destination.  After
which, "lp=/dev/null" could work just fine.

> Can we set up some sort of filter that only prints the information we
> want and just ignores the rest?

   If you know how to distinguish between useless and useful, then sure.

   If you can capture some sample data files, then you should be able to
define a new printer (which uses your new "of" program/script), play
around with it until you're satisfied with whatever it does, and then
move your new printer into position where the mystery program expects to
see its (previously real) printer.


> [...] the spooler then stops once it gets to about 100 entries [...]

   "mj"?

[Ken-Snauffer]

Thank you Steven.

Disk space:
We have increased the disk space available to the VM and to the emulator. However, there seems to be a pretty involved set of steps to increasing the disk space to the root mount point which is where this file is written to (not usr or var). We do have a backup of the VM in case of a mess up,, but not the tru64 system itself, which makes restoring very complicated with severe amounts of downtime afterwards. This machine is currently in production and downtime is not accepted well at all.  I would love to take this suggestion, but some step by step guidence will be needed. I am very familiar with Linux, but this is actual Unix, tru64 to be precise, and has its own twists.

Printcap:
I have looked at the man pages for printcap as well as many other peices of documentation and forums. From everything I can tell, you either define a locally connected printer as /dev/lpx (which the system generates on its onw), LAT (which I got really confused on),. or TCP to print to an IP address (which is what we have right now). My understanding of creating a file as a device is also pretty complicated and I could not find a step by step process on how to do it. Also, even though the drive space is there, we cannot seem to implement it into the unix OS. I even tried to create a second virtual drive and give it to the system with no success on that either. Additional help would be necessary.

Filtering:
Yes, it would be very easy to filter the data needed from the "junk". I briefly looked at the (of) part of the printcap, but thought it would not pertain to my situation as it seemed to be something like printer drivers. I guess I will have to look more closely at this.

Thank you.

[Steven Schweda]

> [...] you either define a locally connected printer as /dev/lpx (which
> the system generates on its onw), LAT (which I got really confused on),.
> or TCP to print to an IP address (which is what we have right now).
> [...]

   LAT (Local Area Transport) is a non-IP network protocol, largely
DEC-specific, typically used with DECserver terminal servers (which can
be connected to serial-line printers).  Unless you have a DECserver (or
other LAT-capable terminal server), you should probably forget all about
it.

> [...] creating a file as a device [...]

   You're working too hard.

   In (BSD) UNIX printing, "lpd" can run your data-to-be-printed through
multiple "filters" (for various purposes).  A "filter" can be any
program/script which can do almost anything, and whose output (if any)
gets passed down the line to the next stage, eventually, perhaps,
getting passed to an actual printer ("lp=xxx").

   The important thing about this scheme is that a "filter" can do
anything you want with the data it gets, including tasks which have
little or nothing to do with actual printing.  For example:

      /etc/printcap entry:

lpx:\
        :of=/root/lpx_of.sh:\
        :lp=/dev/null:\
        :sd=/usr/spool:\
        :sh:

   Note that the printer device in this case is "/dev/null".

      Filter (far from optimal, but illustrative):

purt# cat /root/lpx_of.sh
#!/bin/sh

# Very simple printer output filter.

file_name_out="/var/tmp/lpx_$$.out"     # Temp file name.

cat > $file_name_out                    # Send filter input to temp file.

# E-mail temp file contents to a user on a different system.
# (Include the PID in the subject as an identifier.)

mailx -s "lpx test $$" sms@its < $file_name_out

rm $file_name_out                       # Delete the temp file.


   Note that there should be little if any output from this "filter",
and whatever does escape will be sent to "/dev/null" by "lpd".

      Test:

purt# cat ts.dat
Trivial sample data line 1
Trivial sample data line 2
Trivial sample data line 3

purt# lp -d lpx ts.dat
Print job request-ID is: lpx-11

      Received e-mail:

From:   SMTP%"daemon@purt.antinode.info"
To:     sms@its.antinode.info
CC:
Subj:   lpx test 1324

Return-Path: daemon@purt.antinode.info
Received: from purt.antinode.info (10.0.0.144)
         by its.antinode.info (V5.7-ECO5, OpenVMS V8.4 IA64);
        Wed, 9 May 2018 15:06:41 -0500 (CDT)
Received: by purt.antinode.info (8.13.6/1.1.29.3/26Feb18-0746PM)
        id w49K6cZX001327; Wed, 9 May 2018 15:06:38 -0500 (CDT)
Date: Wed, 9 May 2018 15:06:38 -0500 (CDT)
From: system background account <daemon@purt.antinode.info>
Message-Id: <201805092006.w49K6cZX001327@purt.antinode.info>
To: sms@its.antinode.info
Subject: lpx test 1324

Trivial sample data line 1
Trivial sample data line 2
Trivial sample data line 3


   So, generally, if you can figure out what you want to do with these
data, then it should be possible to get a "printer" to do it.


> [...] increasing the disk space to the root mount point [...]

   I haven't looked at this stuff for about as long as I haven't printed
anything, but, if "/" is getting full, then you might want to move some
stuff to "/usr" (or wherever).  "ln -s" is your friend.