One of the changes we added recently in RPM Remote Print Manager® (RPM) was to make your print jobs launch faster.
Whenever you receive a print job from the network, of course, the aim is to process that job as soon as possible, and I believe we have been doing that all along. However, there are many other situations that result in jobs needing printing right away. We did it before, but now we do it more proactively, I believe to good result.
Working with a suspended queue
Let's take a look at the RPM user interface (or UI). The queue named "archive" at the top of the list has an orange icon, rather than the green icon most of the other queues have. The orange icon means the queue is suspended.
If you've been using RPM for a while, you probably already know this. Just in case, we'll walk through the process of resuming a queue or toggling the "suspend" status.
Note that the queues "archive" and "hp4200lpr" are suspended. Most of the other queues are green. The two empty icons for "ilya" and "lp" mean this queue has no actions, so no jobs sent to it will process until actions are added.
When a queue is suspended it means that RPM adds jobs to the queue, but they will not process until the "suspend" status is toggled off.
In this longer queue list I've selected the "archive" queue. Note the 3 checkboxes near the bottom which show the queue status. "Suspended" is checked. If you selected a queue with a green icon, say "filterx", the "Suspended" checkbox would not be selected.
In the next image, we see the jobs for the "archive" queue. These are files I sent to the queue while it was suspended. Nothing more will happen with these jobs until I "resume" the queue. That only means I turn off the "suspended" status. Some people call it "unsuspend" which is the same thing; we are just reversing the "suspend" status by toggling it off.
Here I reversed "suspend" by selecting the checkbox. Most of the jobs shown have the green checkmark, and the status shows "active". Several processed already before I could capture a screenshot.
The point is that as soon as you toggle the "suspend" status, the jobs start processing right away. That is the point of this update; jobs were taking up to ten seconds to start processing. Now, they will go as soon as they are eligible.
What does "as soon as they are eligible" mean? Basically: RPM has a concept of "next eligible job" to print. Several criteria go into this, and we have a configuration feature called "Scheduler options" which lets you choose which criteria you want to use. If RPM was already printing 15,000 jobs, then the jobs in our example here in the "archive" queue would print after those other jobs. In this instance, we had no jobs processing so the "archive" jobs ran right away.
Working with a held queue
Again, if you've been using RPM for a while you are probably familiar with "hold" and "release". Here we have turned on the "holding" attribute for our "archive" queue. Note the checkbox at the bottom left. The jobs here have an icon that resembles a lock. We used to use a stop sign but that suggested to some users that the job would never print, or that it had been stopped for an error, so we adopted a different icon.
If a job is held, it won't be eligible to print even if everything else says the job is ready. With job hold you can release individual jobs (or a group of jobs) manually in any order you wish. With suspend, you process all the eligible jobs in the queue. It's just a matter of which control works for you.
Note that in this image I've selected roughly half the visible jobs in the "archive" queue. When I hover over the "hold" button, the second button from the right, the help bubble says "Toggle Hold for Selected Job(s)". Since hold is already on for these jobs, the button will release the jobs.
This functionality has always been in RPM. What the update accomplished was to coordinate the UI and RPM better so that the jobs process immediately.
Again I wasn't quick enough to get a screenshot before most of the jobs processed. There are only a few active jobs left in this image. The UI left the same number of jobs selected, although below the active jobs are jobs that were not selected in the previous image.
Working with actions
There are two times I know of when you would want RPM to automatically start processing after an action change.
- Let's say you have a queue with no actions. One reason we see often for this is because someone sent jobs to a queue that didn't exist, and RPM created it. The customer thought the incoming queue name was going to be one thing, but the actual queue name was different.
If you created and configured the queue you want to use already, then add a "copy queue" action to the newly discovered queue and set the destination to the queue you really wanted.
When you add the action, RPM starts printing immediately. RPM now follows up an "action add" with a check for possibly eligible jobs.
- The second reason related to actions is if you update an action. Let's say RPM was printing to a printer which was removed from your network. Jobs sent there would be waiting for a new destination to be assigned. When you update the action to use a new printer, in this instance, RPM will automatically start processing jobs waiting on that action.
Action add and action change are new conditions we added to RPM to have it look for eligible jobs right away.
Working with devices
In these recent updates we also invested a lot of time upgrading the device handling, particularly the device tester. Now, if a device had not been working, but RPM finds it back online, RPM will automatically look for jobs which could have been waiting on this device, and schedule them.
For instance, let's say you were archiving jobs to a folder. For some reason this destination folder was not available. Naturally jobs that would be sent there are going to have to wait. Maybe it was a networked folder, and that network node went off line. For whatever reason, if RPM's device tester finds the device is now working again, it will automatically schedule jobs for that device--without any user interaction whatsoever.
Working with the copy queue action
In the past, when you run the copy queue action, the new job in the new queue wouldn't necessarily process right away. We fixed that.
Working with drag and drop
RPM now processes jobs immediately when you drag jobs from Windows Explorer onto an RPM queue in the UI, or when you drag jobs from one RPM queue to another.
Working with reprint
We have synchronized the UI and RPM so that when you reprint one or more jobs in the UI, it notifies the service immediately and RPM will start them processing.
Also, if RPM reprints a job for any of the reasons mentioned above (device online, for one) it will not only reprint but it will also notify the UI so you have visual confirmation.
Any time we have a new job or complete a job
Any time we receive a new job, or any time a job finishes processing, we check for new eligible jobs to print. This way, once the processing is up and running, it keeps running until there are no more eligible jobs.
Availability
We began to phase these changes in starting with the 6.1.0.448 version dated 2017-03-08. The majority of the changes were in place by the 6.1.0.450 version dated 2017-04-26.
We added the reprint integration in version 6.1.0.451 dated 2017-06-22.
Please see the RPM Roadmap for a full list of changes over the past several months. We will roll these into a general release when we've completed a few more items on our list.
Conclusion
RPM and the user interface are now synchronized much better, and RPM watches for more reasons to check for eligible jobs. These would be events, things that change, rather than continually polling and thereby slowing everything down. The end result is that job flow is much smoother and more responsive. With the UI wired in to RPM more closely, you can see the progress for yourself.