We're tracking a few incidents like this one. It seems constrained to HP laser-class devices, and occurs whether the Universal or device-discrete driver are in play. It may be due to the use of a print processor other than WinPrint (HP drivers always use their own print provider) and having differences between what is on the Pharos print server and the client.
Watch this space!
Pharos Systems Technical Support
Glad to hear that, Scott.
Jeff, thanks for posting about this.
Our organization has been seeing this same 'effect' as well, but I've struggled with making it happen consistently. I'll be watching this space for a resolution (or to contribute as possible).
- Paul L.
After updating to Service pack 1, we started using Raw 9100 over LPD printing and had similar issues, including a Syntax error, or offending command to be printed on the last page. We also use HP's UPD.
If your release mechanism is set to RAW, set it back to LPD.
1 of 1 people found this helpful
The issue stems from our introduction of the "RAW" transport protocol (TCP 9100) in Uniprint 9.0 and Blueprint 5.1. The streaming protocol, unlike LPR (TCP 515) has no flow control, and so what happened (more often than not) is that the server closed the port too soon after the job was sent to the printer. The packet containing the "End Of Job" sign-off was then reaching the printer before the job data was completely received. The result was that the printer basically threw away any data that made up that last page, and ignored any data that came in afterwards.
This has been completely resolved and is available now in the most current patch releases for Uniprint 9 and Blueprint 5.1. The default timer to close the port is 5 seconds. This can be changed to a different value in either product:
Blueprint and Uniprint:
On the Collector or Print Server, copy the following to a new text file and name it with a ".reg" extension:
Windows Registry Editor Version 5.00
Then, merge the new Registry setting and restart the Pharos Systems Secure Release Service. The lower limit for this setting is 1 (second). If the value specified is any integer less than 1, then the default value (5) will be used. There is no upper limit, but to ensure customer satisfaction, it should not be set too high. Note that the above assumes the operating system is 64-bit. If you are using a 32-bit operating system, remove the "\Wow6432Node" in the path.
I hope that this helps!
Would this work with Pharos 8.4?
Yup. Print Services patch 136 for UP 8.4 also accommodates. I'd forgotten that 8.4 was when this first came up. Same info applies.
Pardon my ignorance, but is there any advantage to using either RAW or LPR?
When Uniprint 9.0 came out, I noticed the option for RAW and I used it on all our printers when I built the 9.0 server. Everything seemed to work well from Summer until last quarter. We have not really had any real printing problems. Occasionally, we would have some weird things happen, so I decided to apply Print Services 94 hotfix. During Spring break, I applied the hotfix and when we came back from break, we started to have some problems with run-away print jobs that print a few random gibberish characters on each sheet of paper. I don't remember ever having the problem with Uniprint 9.0. The symptoms reminds me of people printing .EXE files to a printer. Seems the printer is expecting text but binary (graphical) information is being sent. We are mostly using the HP UPD as well.
Yesterday, I changed the transport protocol back to LPR on a certain model of printers and I have not gotten any reports of run-away gibberish printing today. I am probably going to change all the printers back to LPR over the course of the week.
I still have to apply Print Services 119 hotfix, but is there any advantage to using RAW or LPR?
Santa Clara University