Possibly the most critical change in this version affects RPM running a program when you are limiting idle CPU—more details on that below.
However, we have several other changes of interest to some users.
Priority manager saves time.
One of RPM Elite's job scheduling algorithms uses priorities to select the next job to process. The priority settings include Action types, Devices, Queues, Remote Hosts, and Remote Users.
You can find this form under Configure / Scheduler Settings if you are using RPM Elite. RPM Select does not have this option.
With priority scheduling, you leverage settings from the LPR metadata using the priority settings. For instance, you could specify that whenever a specific remote user submits a job, it would get a higher priority (or lower). The same applies to the remote host (which is the host of origin) and the queue, which is originally part of the LPR print command.
The change to this version of RPM is that we no longer try to load all the priorities data into the service on startup. For some users with tens of thousands of entries, this took several minutes, which delayed RPM from receiving jobs during that time. The reason we don't need this information is that the scheduling algorithm is in the database schema.
If you are an RPM Elite user, see the article on prioritizing your print operations for examples on how to use the priority scheduling.
Crash handling update
We know crash handling is essential for this reason: if your operation relies on printing, you want your print servers to keep running. And if they don't, the next best thing is a quick diagnosis and remedy.
RPM calls several programs during regular operation, including either dbshm or dbpipe to talk with our database, and Queue Folders for RPM Elite users. We updated the way they do diagnostic logging as we noticed that they occasionally generate a crash dump.
On the topic of crash dumps, we also changed how these programs engage with crash dump handling. Now all three check the config.xml file in the RPM install folder to know whether or not to register for crash dumps. The directive for that handling is in the user interface, under Configure / General Settings.
MAC address changes
The MAC address is part of every computer standard network setup. Many commercial software products use the MAC address as part of the licensing since that is supposed to be unique.
When the RPM license software determines that the MAC address changed, it resets the license, which will disrupt your print operations. Now when this happens, RPM issues a Critical Event with the old and new MAC addresses so that you will know proactively.
We also include the MAC address in the file license.csv. You can look at this file in Excel or upload it to Google Sheets to see for yourself if the MAC address changes.
Please note that we don't cause the MAC address to change, and it's not likely to be a software error. A typical reason this may happen is running on a virtual machine where the MAC address is not static (it needs to be). We're merely advising you that it happened so you can correct the situation. Naturally, we're standing by to help you with licensing issues, if we can.
Important fix to running a program and limiting idle CPU time
When you run a program, whether it's an action or transform, RPM optionally uses logic to limit idle time. If your program stops running but doesn't exit independently, RPM can terminate the program after an idle period. You may want RPM to do this if your program waits for acknowledgment that it's complete. The Adobe Acrobat PDF reader program is said to work this way in some instances.
We discovered that we couldn't get the CPU data on some computer systems for the process you're running. Until we find a fix for that issue, which seems to be a Windows issue, we recommend updating to this version.