We do our level best to support LPR print clients with RPM Remote Print Manager® (“RPM”). The fact that we have detailed logging available in RPM has saved our sanity more than once. Back in 1996 when we first encountered the IBM AS/400, our customer was having a problem receiving prints from the AS/400, and the log helped us track down the expectations of the IBM print system. I was able to make adjustments to RPM successfully from that data.
We recently heard from one of our partners, who was printing from an HP/UX system. He was having some trouble with the “title” argument. The title is one of the components of the LPD protocol. It’s something you are supposed to be able to include in the print setup from the client, then in RPM, we offer a variety of ways to use that setting (among others).
Unfortunately, for our partner, the title wasn’t coming through. We asked them to turn on diagnostic logging for “lpd2” so we could study the information his HP/UX print client was sending. It turns out that even when they added the title with a switch on the command line, their client was not adding the title to the metadata it sent us.
What it did send was three “name” fields, which struck us as odd. Multiple name fields make sense when you send multiple files in a single print request. We handle that already. However, we were unsure how to make sense of three name fields when you have one file.
Obviously, we could add a specific “one-off” behavior for our partner but the main reason to not do that is because we then need to maintain that non-standard logic for the rest of time.
What made more sense to us was to recommend a different print client.
Linux print clients
We know of two print clients on Linux systems which we are very comfortable recommending:
- CUPS
- rlpr
CUPS is the Common Unix Printing System. It is widely available on Linux systems. I always test RPM with CUPS but I don’t personally use CUPS for stress testing because it doesn’t want to queue up a large number of print jobs. I normally test RPM for functionality as well as volume (lots and lots of print jobs).
CUPS is probably on your Linux system already; if not then do a web search for instructions to install. On Ubuntu I normally type:
sudo apt-get install cups
You should confirm whether that is the right command for you.
rlpr is a great print system which seems to be widely available. I’ve been using it for testing for around 15 years. It is designed to replace the built-in LPR system and has a number of advantages.
One feature I like is that it does not require you to configure a remote printer on your Linux system, so no editing /etc/printcap. You can specify everything you need from the command line.
Another thing I like is that you can send multiple print jobs in a single connection; I made sure the latest RPM versions support that.
On Ubuntu I install rlpr with this command:
sudo apt-get install rlpr
It’s one of the first things I do when I set up a new Ubuntu VM.
Windows print clients
Microsoft has their own LPR client program. We use it at times to make sure RPM still supports its idiosyncrasies. I don’t know how many times we have supported a customer using the Microsoft LPR and have had to explain how to set a registry value to get that program to overcome one behavior or the other.
When you install RPM, we include a program in the install folder called pylpr. This is the program we most often use for sending test prints to RPM. It’s a command line program. You can get a summary of the switches and arguments by typing pylpr in a command prompt if you are in the RPM install folder.
The way I normally use it is to send a number of files to RPM:
pylpr -n -p archive@localhost d:\testing\data\samples\*
This will send all 758 files in my “samples” folder to the “archive” queue on my local computer and will list the name as it sends each one.