We are announcing RPM Remote Print Manager® (RPM) update 6.2.0.503 for April 22, 2019. The following highlights what is new and different in this update.
What happens when you send your print job to the wrong printer port
We helped a client recently with a unique situation. Someone among their hundreds of users was sending a PCL print job directly to an LPD printer port. The result was that RPM crashed without leaving useful error messages.
We did two things to address this situation. First, we added a "client-ip" field to the capture file for new connections. We should mention that one of our support technicians had already turned on "capture" to help track the problem down.
Second, we updated the LPD protocol handler. In the 'get command" phase of the protocol, we made it so that an illegal command would not merely get an error message to the sender, which the sending program ignored. It would also generate a critical event in RPM and close the connection. This way, RPM would show you what happened, and not fault later.
Queue Folders update for empty file handling
Queue Folders 2.0 is our watch folder module, integrated with RPM. We received a request for help from a partner company. It seems they sent a few hundred files to a watch folder in RPM but, at the end of processing, half a dozen remained. Furthermore, the RPM log noted that the files were empty and removed them.
It turns out that the Queue Folders module only removed the files from consideration, not the actual file itself. We changed the logic so that Queue Folders would not stop monitoring the file just because it is empty.
Secondly, we added logic to track the file size over time. So long as the file continued to grow, Queue Folders would continue to monitor. Once the file size remained the same, Queue Folders would refer the file to RPM.
Text printing
We helped a user who was using two text print actions to print the same job using two printer trays. They were accomplishing this by setting the printing preferences in each of two text print actions.
The problem they ran into is that sometimes the jobs stopped printing partway or didn't print at all. We tracked this to an unnecessary API call. The user reports that the problem has not recurred.
This bug did not affect many other setups, and we are guessing why this was a problem here. It may be two simultaneous jobs with the same document name, but we are not sure.