RPM 6.1 Release 2017

Wed, 01/03/2024 - 15:44 By Dave Brooks

Brooks Internet Software, Inc. releases RPM Remote Print Manager®(“RPM”) version effective August 18, 2017.

It’s been almost a year since the last product release on August 10, 2016. Since then we have introduced new features, made significant changes in some areas, and fixed a ton of bugs. As always, we do our very best to test in advance but with the myriad of configurations and applications, we depend on (and sincerely appreciate) our customers’ feedback and enthusiasm for moving forward. We understand that people rely on us for print workflow and we take the responsibility very seriously.

Faster job launching

We refactored the job launcher to act immediately on the following events:

  • Turning “suspend” off on a queue
  • Toggling “hold” on a job
  • Adding or modifying an action. This is particularly useful if you have created a new queue and sent jobs to it. If the queue is not suspended, then as soon as you add an action, the jobs will process. Of course, if you mean to add several actions then you should leave “suspend” turned on until you are finished.
  • If a device was in error, and that is resolved automatically by RPM through the device tester, then the jobs will process without user intervention
  • Jobs sent to another queue with the “copy queue” action will now be processed immediately
  • Jobs submitted using the user interface “drag & drop” are now processed immediately
  • The RPM service is now wired in with the user interface, so if you reprint in the UI, the service is immediately notified; and if the service reprints (which is also new) the UI is immediately notified
  • Each time a job is completed, we now check for new jobs

For more discussion on this please see Faster Launching for Your Print Jobs

Database stability and performance

When we separated the database processing from RPM into a separate process, we reviewed all the interprocess communication methods used in Windows and attempted to pick one that gave customers a good experience for speed and reliability.

Unfortunately, we had more than a few customers who found they could not start RPM because some system runtime failed, and so they would have to reboot their system.

Of course, that is a very long way from being acceptable.

Attempting to resolve this, we discovered another method that is intrinsic enough to Windows itself that it seems to have much better performance and reliability. And hopefully, it won’t be “back to the drawing board” on this one any time soon.

We actually engineered it so we could test several methods before selecting a winner.

For more discussion on this please see Major Improvements to database stability and performance

Addressed ‘Database connection error’

RPM includes a configuration file which is outside the database. One thing it includes is the location of the database, which is kind of important.

Unfortunately, we had too many processes which competed now and then to update this file. Fortunately, we were able to get all the programs on the same track! We have yet to receive a report of this problem happening with the update, which is hopeful since it was a common occurrence before.

For more discussion on this please see Eliminating the dreaded 'Database connection error'

Updates to Data Extraction transform

  1. Previously we were launching an external program to do the regular expression search; now we do it internal to RPM. Rather than take perhaps five seconds or more, it’s milliseconds.
  2. When we use the data extraction values to construct a filename, we are a lot more efficient with the use of the database (like, more sparing) which is another time saver

For more discussion on this please see big changes to the Data Extraction module

Handling partial print jobs

We’ve known for some time that some print systems will send empty jobs to RPM as a way to confirm that it’s running and accepting jobs. That's one reason we include the option to delete empty print files.

More recently we discovered that some print systems send partial job transfers and simply halt the transaction midway. This was causing some problems for customers with various error messages. However, in at least one case the print system itself took our response as an error. That has the potential to interrupt processing.

This post describes the problem in more detail and how we resolved it.

For more discussion please see Changes to handling partial print jobs

Device tester upgrades

RPM has included a device tester module for several years now. When we were working on the job launcher problem, we reviewed the device tester and found that it could do more than it was. For instance, there were certain kinds of problems that we were marking as a job error. Jobs with errors are automatically retried every so many minutes.

However, in some cases, it was a device that was the problem, not the job itself. Consequently, we empowered the device tester to do more than it was. Now, if we detect that a device has recovered, we restore the device within RPM and relaunch jobs associated with it.

For more discussion on this please see Device Testing Improves Job Recovery

Page range changes

  1. We removed the option for page range printing in the raw print action. There was never going to be a way we could reasonably accommodate partial job printing with anything but plain text. We can still separate out ranges of data if you wish to experiment on your own.
  2. We fixed page range printing in the text print action. We were running into situations where the first page printed, after page 1 of the document, was coming out somewhat reduced in size on the page. Obviously, that’s not good.

For more information on page range printing in RPM please see:

Updates to LPR and IP print actions

We discovered that the end events for LPR and IP printing were not properly synchronized, which resulted in the service taking quite a bit of time to end those actions. Once this was fixed, the throughput for those actions improved dramatically.

Telnet protocol update

We’ve continued to have intermittent problems with the timeout function in the telnet print protocol. This function was meant to implement “quiet print”. With quiet print, the client suspends sending data for a time period, rather than closing the connection and opening a new connection. RPM is supposed to submit the job for processing when this happens.

We ended up taking this a step further. RPM now receives the telnet job and does all the database processing in the background. This means that it is now possible to send telnet jobs much faster than RPM can put them in the database and display them in the user interface. The jobs are all retained, they are simply processed in the background.

On the sending side, it seems to speed up dramatically. Even with large batches on a not very powerful Windows system, we can easily get 10 to 14 jobs per second on the sending side.

Busy Windows fixes

Sometimes we’d encounter a situation where if Windows was very busy creating and writing files, we would not get the notification that our writes have completed until an extensive delay. Usually, when this happens, the job would take a very long time to be available to process (maybe 30 seconds or more), or there would be a timeout error message. Reprinting was always successful in these cases. This is fixed.

Sometimes when the system was very busy we’d get a notification that a job file was empty or missing, when that was not at all the case. It was at times a frequent reason for job error if you were watching the UI. This is fixed.

Super long file name in another code page

A customer sending a very long file from a Cyrillic system found that job progress halted. We discovered that the database issued an error but we were not able to trap this particular error and continue. We resolved that.

It turns out RPM was able to handle the Cyrillic filename fine, even though the receiving system was not using a compatible code page. If the receiving system had been using Cyrillic we would have attempted to translate the name to Unicode. Even so, that proved to be unnecessary.

Startup processing

RPM has long removed jobs which were being sent when RPM exited. These would have the job status “xfer”. What we didn’t do was to remove the data file. The theory was that for the user a partial job might be better than no job.

However, that has not proved to be the case, and what was actually happening is RPM would generate a message in the Event log stating “file found”. We have had a number of support emails over this as people are naturally concerned.

Now RPM simply removes those files without generating the message.


  1. Sending a crash report is now optional.
  2. Updated the URL for the RPM homepage in the UI
  3. Resolved an issue with expired licenses
  4. RPM Select now forces the “FIFO” option on the scheduler
  5. Added support for valid though undocumented two-character commands in the Remove PCL transform
  6. Fixed a bug in the Data Extraction transform which under certain circumstances would clobber the first byte of the extracted data
  7. Resolved an issue which prevented PDF creation if the system had a malformed font file
  8. Fixed an obscure registry import issue when the sequence number was used in a filter action
  9. Fixed a notable slowdown in processing which stems from resolving a hostname which is not in DNS, such as a recently added host or possibly one from a different domain which is unknown to the local DNS