How to send print jobs to RPM

I always like to install software and get productive with it right away. I’m normally 3-4 steps out, planning what to do with this, and how to extract that, and where the PDF goes. It’s just my nature.

I’ve set up RPM Remote Print Manager® (“RPM”) any number of times and so far I’ve only been stumped once. However, this question is one we hear more often than some:

How do I get my print jobs to show up in RPM?

It’s actually very simple. In this article, I’ll describe the few steps you need, and how to test whether it’s really working or not.

Step 1: Install RPM

I admit--that’s obvious! You don’t have to be an IT professional to know the software is not going to receive print jobs if it’s not on your system.

When you install RPM on your Windows PC, the installer launches the service automatically. The user interface is optional; that’s the question you were asked at the end, do you want to run RPM Remote Print Manager, etc.

When RPM first runs it creates a listening port for LPD print jobs. We describe this in the article How Network Ports and Protocols work in RPM

The main point here is that by the time you install RPM, it should be ready to receive LPD print jobs.

Step 1(a): if someone has gotten there first

There is one reason why this would not be true: another software is using port 515.

You can review the event log (click the "Events>>" button at the bottom of the user interface), or launch message log viewer (Log / Launch Log Viewer) and scroll through the log. If RPM fails to create its LPD port you should find it quickly this way. If another service is using port 515, stop that service and restart RPM.

Step 2: get your PC hostname or IP address

RPM has created port 515 for you. At this point, another program on your network should be able to send a print job to port 515 on your PC. The only thing we need now is your PC’s hostname or IP address.

How do you get the IP address?

The short answer is to do a web search on this phrase:

how to find my ip address on windows

I tried this search on both Google and DuckDuckGo.com; I got different first results but both results seemed to work.

If you are using Windows 10 for instance, like I am, you would select the search phrase:

how to find my ip address on windows 10

Step 3: set up your remote system to send print jobs to RPM

Here is another example where you can and should use your search skills. I did the following searches in Google just now:

  • How to print lpd from as/400
  • How to print lpd from CUPS
  • How to print lpd from AIX
  • How to print lpd from hp3000

Each of these searches produced what appear to be meaningful results. The AIX search, for me on this particular day, produced a text snippet with step by step instructions.

My point is that we have little to no hands-on experience for most user’s remote systems, except that we have an AS/400 in-house (and we are not experts).

Please note: RPM is a print server and we have a great deal of expertise with it. When we say “we don’t support your print client” we mean the software you print from, not the software you print to. RPM is the software you print to.

With all that said we have a page on our site with sample setup steps for a variety of remote systems.

Step 4: picking a queue name

As a general point of interest, when you set up the “print client” you are going to need one or more of the following:

  1. the hostname or IP address of the Windows PC RPM is installed on
  2. you may need to know it’s port 515
  3. you’ll probably want a queue name.

Typically your system administrator will assign a queue name for the outgoing prints destined for RPM. When RPM receives the LPD print request (which includes a queue name) it will create that queue if it doesn’t already exist. That’s the default behavior. If you want to change that, we have an article How to prevent queue names appearing in RPM

If you want to create a queue name, you can do that on the remote system by sending the job. If you prefer, you can create the queue name in RPM first. The article above shows how that is done.

Step 5: run the UI, it may show something

Let’s say you have done all that and have sent a bunch of jobs to RPM. You run the user interface but you don’t see anything:

Here I’ve sent 801 jobs to a queue I called “archive”. But, I don’t see anything.

Looking closer I see an empty printer symbol. When I click on the name “archive” I now see this:

Now I see plenty of jobs and if I were to count all the way to the bottom, there would be 801 jobs in that queue.

The reason they are sitting there (and the empty printer symbol) is that I haven’t configured the “archive” queue yet to do anything with those jobs. But, RPM received the jobs, and that’s what this article is about.

Step 6: If jobs don’t come through, use these tests to make sure jobs can get there

If you have access to a Linux based system, then follow these steps.

The telnet test

Just now I went to an Ubuntu server in our network and typed the following at the command line:

telnet 192.168.89.132 515

The IP address is that of my laptop. Note that I added “515” so that telnet would use my LPD port instead of its default telnet port.

This is what telnet displayed for me:

Trying 192.168.89.132...
Connected to 192.168.89.132.
Escape character is '^]'.

I hit the “enter” key and then a couple of other keys until I remembered which one I needed to exit. It turns out that Ctrl+Z did the job for me.

In the RPM user interface I clicked the “Events>>” button near the bottom, and saw the following:

Queue - 2018-10-16 13:39:14.533
enabled queue not found: -1

LPD command - 2018-10-16 13:39:12.861
unknown command -1

LPD command - 2018-10-16 13:38:35.341
unknown command 13

While this looks like a lot of complaining it’s really a good sign because it shows that print jobs can flow directly from that Ubuntu host to RPM on my Windows PC.

In general, if you can find a Unix emulation or a telnet utility, try to connect to your PC using port 515 after your IP address (or hostname). The fact that RPM registers an error is good because it means it was listening and heard your request (however ill-formed).

We have a page on doing telnet from a mainframe although we have not tried this (because we don't have a mainframe).

If you only have access to Windows systems:

The testlpr script

Using the RPM UI, add a queue named "brookstest". Now in a command window, go to the install folder and run the script "testlpr.bat"  This uses the pylpr program we include with the RPM install. This does not demonstrate sending print jobs across the network but it does show whether RPM is ready to receive prints or not.

Step 7: firewall

If your telnet utility says something along the lines of not being able to connect, then you either have the wrong IP address, or your route is blocked. You need to talk with your IT staff about the firewall.

When RPM installs it attempts to create an exception for port 515 in the firewall on that PC. There is no guarantee this will work, and certainly, there’s no way for RPM to know about firewalls between that machine and the one you are sending print jobs from.

You could always call us and ask for help but are you sure you want to talk with someone who can see the inside of your network from the outside? Right, I wouldn’t, either.

Step 8: How to tell if RPM is receiving

If you are not sure you are receiving jobs then the easiest way to tell is by running the user interface.

Remember the user interface snapshots above? In the first one it “appeared” that there were no jobs. But, there were 801 jobs; the queue “archive” had a couple of numbers next to it. One is current jobs, that is the number of jobs currently in the queue. The other is the total number of jobs the queue has received.

When I clicked on the queue, as the second image showed, then I could see all the jobs for that queue.

So:

  • If new queues appear, then you are receiving jobs
  • If the job count for one or more of your queues increases, then you are receiving jobs
  • If the job count goes up, then goes back down, but the job total keeps going up over time, then you are receiving AND processing jobs

Remember that if you are running the user interface watching for something to happen, you also have to make sure that someone is sending you print jobs. It would be great if RPM could go to your other systems and grab a print job, and pull it down, but that’s not the way these things work.

Step 9: do I need to turn on host access or any other permissions?

Here is the short answer. No, you don’t.

To get to the Host Access form, go to Configure / Security Settings:

Host Access is intended to control which machines on your network have permission to print to RPM. That’s all it is about. By default, every address is enabled. Some customers wanted to prevent RPM from being wide open to their network (it was probably a university). We made a way, and that’s the entire story.

Host access does NOT enable anything. It doesn’t get you print jobs where you couldn’t before.

Many customers have told us “we tried host access and that didn’t help”. That makes sense because host access is for restricting, not enabling.

Step 10: I still can’t print--what are the likely culprits?

First, if you have really done all the above, then there’s a chance that you installed RPM more than 21 days in the past and never licensed. If the trial period is done, then RPM will not receive.

Second, it’s relatively common that you may have an LPD already on your system, either Windows’ optional "LPD Services" or a third party one installed with another piece of software. You can check if you have another program listening on port 515 like this:

From an elevated command prompt use the command “netstat -abn | more” then page through the results. If you see a line identifying 0.0.0.0:515 and the next line doesn’t say [rpmsrv.exe], another program already had the port and is blocking RPM from listening. Stop that other service and then restart the RPM service to try again. You should have better luck the next time.