Portals
Transforms
Actions
PDF
Print to
Windows printing
Text markup
Queues
How to
Workflow
Archive
Email
Purpose
Queue support in RPM Remote Print Manager® (RPM) is designed to let you thoroughly and completely configure each queue you create, independent of every other queue. This follows the Unix model of print queues, rather than the typical print server or Windows product.
Print servers that support LPD traditionally have two ways of dealing with queues:
- ignore them (all print jobs go to one port, or the default Windows printer)
- assign a few unique features to the queues, for instance, the "TEXT" queue might fix the stair step problem by converting line feeds to carriage return + line feed, where "RAW" sends the data through to the printer unchanged
Queues
RPM has always taken the approach to enable as much setup to each queue as possible, and to let you create as many queues as you like, each with independent configuration.
For instance, you might have several queues that convert different data formats into text markup, using different settings. Then each of these queues copies the converted jobs into a queue that broadcast prints these jobs to several printers; or converts to PDF and emails the jobs to a group.
Named queues
RPM supports as many named queues as you want. Since queue names go into a database, the number you can have is essentially unlimited. We impose no hard limit on the number of queues.
Names include alphanumeric characters [and what characters?] Spaces are silently removed. Names are case insensitive, so "Group1" is the same as "group1" and "GROUP1".
Unlimited queues
You can have as many queues as you like; there is essentially no limit to the number of queues RPM can manage.
However, RPM keeps some queue information in memory, so if you have a machine with a small memory footprint, it might not serve a hundred thousand queues as well as you would hope. However, you are far more likely to run into processing limitations from other issues than the number of queues.
Auto-create queues
By default, if you send a print job to RPM, and use a queue that is not already defined, RPM will create the queue without transforms or actions and store the job. This way, if your sending system uses a queue that doesn't exist, you have the chance to configure the queue, and no jobs are lost. The user interface will show the queue with an empty printer icon, meaning there is no setup (yet).
Job flow: Enable / Disable
Queues are enabled by default. When a queue is disabled, RPM will not receive jobs sent to that queue remotely. It will signal an error that the queue doesn't exist.
Job flow: Suspend / Resume
When a queue is suspended, any jobs in that queue will wait until the queue is "un-suspended" or resumed. When a queue is resumed, all the jobs that aren't held or in error are scheduled to print.
One reason for suspending a queue would be to postpone processing all jobs in that queue until a certain time of day. Once the queue is resumed, all jobs already in the queue are scheduled, and all jobs arriving for that queue are scheduled as well.
Job flow: Hold / Release
Where suspend is a setting that applies to the queue and affects all the jobs in the queue equally, hold is a setting that affects individual jobs.
When a queue is set to "hold", then all the jobs that arrive for that queue are set to "hold" also. "Held" jobs are not scheduled until they are "released".
The chief benefit is that jobs can be released individually, and usually are.
Strategies
There are two ways to consider setting up your print workflow with RPM:
- Do everything you need to do, in each queue, start to finish
- Consider grouping like functions
The first approach certainly makes sense for many applications. After all, one of the benefits of using RPM is "set it and forget it".
The second approach might make sense, though, if your print setup is fairly complex, or if you are in the process of defining it and want to save yourself some work.
If this is of interest please continue the discussion at the Workflow Portal.