Faster job startup and more / RPM

update available

RPM Remote Print ManagerĀ® ("RPM") version, dated November 19, 2019.

The most vexing problem reported to us in recent months is when you restart the RPM service, and jobs don't print as they should.

We have worked on that problem in this release and offer quite a bit more pain relief.

Topics covered in this release:

  1. enhancements to the RPM startup, which ensure eligible jobs print right away
  2. introducing a new scheme for database access to mitigate problems with security software
  3. changed the way we report the number of days remaining for support if you use an internationalized date format
  4. message log updates, event log cleanup
  5. we've extended the "discard small jobs" setting to AppSocket, Telnet, and Queue Folders (the folder watcher)
  6. you can now update the RPM temp folder and have it take effect immediately
  7. we now recognize the local IP interface address for job naming purposes (your PC usually supports several)
  8. if you are getting queue-create requests, we now show you where they came from so you can block if needed
  9. we now let you know that Firebird is an RPM dependency, so it's harder to uninstall without meaning to

Startup enhancements

There were certain things RPM does immediately after startup, which, if one failed, the rest would not run at all. We discovered this is one reason the job launching loop would not start.

Also, on startup, the job launcher now automatically marks devices as "ready" that may be used by jobs ready to process.

We have been able to reproduce the problem where jobs don't seem to print on startup as they should, and this enhancement fixes that.

Shared memory option for database access

RPM now offers an alternative program for communicating with the database.  The current program, dbpipe.exe, use named pipes for interprocess communication between itself and the database utility.  While there are no known operational issues with named pipes, a few users reported problems with it that may be caused by antivirus or other security-based applications.  The new dbshm.exe program uses shared memory which provides those users who encounter issues with named pipes an alternative

Of course, we added support in the user interface to switch between the two database interface approaches. Note that you must restart the service for this to take effect.

alternatives for database access

Alternatives for database access

To clarify: Firebird does not use shared memory. RPM uses either named pipes or shared memory to communicate with a program that works with Firebird. We do this so that potential database access issues don't disable your printing.

Support expiration reporting

The license manager provides the support expiration date to RPM using American date format; in other countries, this led to a wrong estimate of the time remaining for support. We had assumed incorrectly that the date format is international, but it is not.

Message log updates

When RPM purges the message log of expired messages periodically, we now keep those messages related to jobs that still exist, for instance, through job retention. You'll notice this in the log viewer if you activate the Job column.

We occasionally hear reports of jobs with fragments of the correct size. To this end, we added a message log entry for each of the four incoming protocols, or job input methods. This posts with the name of the protocol and the total size of the data file. The protocols are LPD, Telnet, AppSocket, and file watcher.

"Discard small jobs" limits enforced

The Telnet, AppSocket, RPC handler, and folder watchers now honor the "Discard jobs xx bytes or smaller" option available in General Settings. It's optional. However, they now log when this happens. Check the event log.

Please notice this is a limit you, the user, activates. RPM doesn't arbitrarily decide on its own that a job is too small, except zero byte jobs, of course.

Temp folder update

The spool manager starts using the temp folder path as soon as you update it in the user interface. You no longer need to restart the service. We continue to recommend not doing this while RPM is actively processing jobs that use the temp folder path.

User interface updates

  • no longer allows multiple Critical Events dialogs to open
  • shuffled columns in the Critical Events dialog, moving the timestamp to the left to make it more visible as the message text can get long
  • added icons in the status bar to show when Telnet and AppSocket are operational
  • prevents the temp folder from being the same as the Windows temp folder, as RPM cleans this folder on startup potentially removing something another program had written
  • limits log retention to 31 days. There is no good reason to keep years of logs. One suggestion if you like to keep log records is to export your log weekly, from the Log menu, and save to a date-stamped file
  • the spin control in the log retention dialog spins by ones rather than tenths
  • added an explanatory note on the Critical Events dialog, clarifying how messages appear
  • dependent services option cannot be enabled if there are none
  • fixed default sizes for critical events and diagnostic logging dialogs
  • allow space bar to toggle diagnostic logging and log options

Here is the updated Critical Events dialog. The Encountered time has been moved to the left of the Message making it more visible. The explanatory note explains how the message display works.

Critical Events dialog

Critical Events dialog

Event log cleanup

The first time we used the PCL to PDF module after a service restart, we were producing four event log messages, which we now merge into one.

Using the Local IP address

The network manager in RPM now logs the IP addresses used by the computer on startup. We already record the DNS servers and the MAC addresses discovered. You can find this in the file "report.txt" in the RPM install folder.

We discovered in the naming template that the local IP address was not working in the way we expected; it was picking the first interface that was not The intent is to show which local IP interface the job came in on. For instance, if your computer (like mine) supports plus an additional two local addresses in the 192.168 range, RPM now provides this local information in the naming template.

You can experiment with the "Local IP" address by directing your print jobs to one of the addresses on that list. 

RPM also applies this logic to the job naming feature in the Telnet protocol. The AppSocket contract derives the job name from the print jobs itself, using PJL commands.

Documenting where queue creation comes from

We added a critical event notification when an LPD print refers to a queue that does not already exist. In the past, RPM has interpreted this as a request to create a new queue. After a time, we added the option to block that feature. Now we are merely letting you know that a request came from the network regarding a new queue and whether we allowed it.

This example of the Critical Events dialog shows jobs sent to two different queues. In the first example, the LPD protocol created the queue since "auto-create" was true. RPM merely notifies the user. In the second case, I turned auto-create off before sending the job. RPM here warns the user that someone attempted to create a queue by submitting a print request.

queue creation warnings in critical events

Queue creation warnings in Critical Events

Adding Firebird to RPM dependencies

We also made a change to the uninstall menu in Windows to show that RPM depends on Firebird

Firebird dependency

Firebird dependency
Firebird dependency

Firebird dependency


Download the latest RPM installer

Download the latest RPM installer today!