RPM Overview

Mon, 10/21/2019 - 10:57 By Dave Brooks
  Home • Print server • Virtual printer • Print spooler • Queues • Actions • Transforms • FAQ
RPM Remote Print Manager

RPM Remote Print Manager® ("RPM") is a unique product in the marketplace. Typically, when you print a document, it goes to a printer, and that's it. But, RPM gives you full access to your data, including many options beyond a one-time print.

Here are some of our output processing options:

And that's not a list. Those are merely ideas based on ways people currently use RPM. We are not limited to these.

Essential resources

Before we go too far in this conversation, let's list out some essential resources for RPM:

Print server because no one talks directly to printers

There are so many good reasons why print servers are standard, and printers are (usually) not.

  1. A print server can usually handle multiple incoming jobs at once. A printer usually cannot.
  2. A print server might keep a log so you would know after the fact which jobs it received and from where. Some printers log; many don't. RPM keeps several logs for different uses.
  3. Your printer should use all its resources to print rather than store print jobs and handle queries. RPM handles the heavy lifting of those tasks, so your printers don't have to.
  4. A printer might have one or two built-in queues for specialized print processing. Often a print server has several queues which perform the same role. RPM has unlimited queues, which you can configure as you like.

Virtual printer intercepts your third-party print jobs

Many applications in banking, health care, and agribusiness, to name a few, print to what they believe is a printer. Often the application stipulates a printer rather than software.

RPM does such a good imitation of a printer that some of our customers have come to call it a "virtual printer," and in fact, RPM meets the definition in Wikipedia.

You don't "create a virtual printer" with RPM. Instead, installing and setting it up in your environment is enough to bring a virtual printer onto your premises.

Print workflow to build the process you want

We designed RPM to accommodate a variety of printing scenarios.

On the most superficial level, you might archive a print job to a folder or send it directly to a printer.

A slightly more complicated task might be to run your print job through a text preprocessing filter and then convert it to PDF. You could then archive the PDF, email it or upload it to a server somewhere.

You might also print your preprocessed document to a Windows printer with full font and margin support.

You could also do all of the above:

  • preprocess the text document
  • configure the output to a Windows printer
  • copy the preprocessed file to another queue in RPM

In the second RPM queue, you would convert the preprocessed file to PDF and then send that result to email, disk, server, etc.

We designed the workflow to be able to process your file in stages, act on those stages, then where it makes sense to move those results down the pipeline to a later stage. This may sound complex, but it's far more straightforward than packing all the processing into one step and making conditional adjustments.

We are happy to consult with you about your data needs and give you the benefit of years of design and troubleshooting experience.

Inputs to RPM use network and folders

  1. RPM supports LPR and LPD, which are print protocols used worldwide since 1990
  2. Telnet, a plain and straightforward print methodology that used to be a staple in the airline industry, among others
  3. JetDirect or AppSocket, used by many millions of HP printers worldwide
  4. Folder watcher, which we call QueueFolder as we associate one folder with a queue in RPM
  5. We also have a home-grown RPC which we use with the user interface; you can add jobs using our RPC with some programming.

Print spooler, safely collecting jobs

Any print spooler has a typical set of roles, no matter the setting.

  1. Always be ready to receive a print job
  2. Don't act on the print job until it is entirely received
  3. Treat each print job as if it is the only print job in the system; for instance, never mix up the pages in two print jobs; always keep the banner page with the right print job; etc.

Some print spoolers have additional features which users have found advantageous, including

  • be able to reprint the job on error
  • be able to retain jobs optionally for discretionary reprint
  • change the processing setup for the print job and "try again" using the same original data file and metadata

RPM does all these things. RPM works alongside the Windows print spooler, but since RPM has many outputs beyond printing, we don't rely exclusively on the Windows print system.

Print queues, all the processing setup

RPM uses the named queue model made famous by the print system in BSD Unix. In this model, you send your print jobs to a queue with an alphanumeric name on a given host computer.

There are no default options in this model. For example, at the beginning of my Unix career in the eighties, there were no default printers; each computer had access to any number of printers from different vendors, each supporting one or more input formats. The idea of a "default" printer makes sense on Windows for a given user but not necessarily anywhere else in the world.

In RPM, this model embraces:

  • custom preprocessing, or none at all
  • a variety of output actions

Note that one of the outputs is to copy the print job to another named queue. The "copy queue" action gives you many opportunities to design a customized workflow. We provide several working examples.

Retain jobs and reprint

RPM offers job retention as a setting wired into each queue. Job retention lets you set the criteria on when to remove completed jobs.

One criterion is to retain a certain number of jobs. You might set this to 100 or ten thousand, any number that suits your needs. As each job completes processing, RPM checks whether the number of completed jobs exceeds this threshold and if so, it removes the oldest complete job.

The other criterion for job retention is to remove jobs after a given period. You can set this anywhere from minutes to days. With this setting in place, RPM creates a timestamp for when to remove each new job.

Any job not yet removed can be reprinted. Just select the job or jobs in the user interface. We provide a "reprint" button in the toolbar and a menu selection under "Jobs."

You can reprint any job in an error state the same way.

Transforms to your data

You know what your data needs. We don't. That's why RPM stores all print jobs as a binary copy.

And we can change the data if that's what you need.

Let's say you receive SCS files from an IBM computer system. We can convert those to PDF for you and render them on a Windows printer. In this instance, going from EBCDIC to Unicode requires some data conversion, not to mention the bold print and other features of SCS.

Over the years, we have created dozens of transformations for print data based on use cases.

Output actions for your data

Our output actions include:

  • text print, which leverages the Windows print system for fonts and margins, and such
  • raw print, which bypasses the print driver and renders directly on the printer; this assumes the data is 100% in the correct format for the printer
  • email, where we can send a print job as the message body or attached
  • archive to folder
  • filter, another name for running a program
  • copy to queue, which sends a print job to another named queue for further processing (printing from multiple input trays uses this)
  • LPR printing uses the same print protocol RPM uses to receive, to send a print job to another print server
  • IP printing uses the "raw socket" or Telnet approach to send print jobs to another compatible print server
  • FTP, which uploads to an FTP server