Check the transaction logs and see if you were charged for the initial print that didn't complete. If that's the case, the second job isn't free, it's just been charged for already. In the system section in Pharos Admin, you can choose how you want the system to react when a print job fails.
At CU, OIT chose to use re-list vs. re-list free. We have a system in place that provides refunds for failed jobs. Any of the three choices works, just depends on which one is the best choice for your environment.
Sorry, missed the driver part of the question. Any chance the print group is referencing the wrong driver or charging model? What type of printer? Are you using a specific driver for the device or one of the "Universal\Global" drivers. I've seen that happen when we used a global driver and the job had color in it. The driver sees it as a color job and the B&W printer doesn't know how to interpret the job. Then the printer hangs or ignores the job. Any info in Pharos alerts? That might give a clue as to what the Pharos system saw.
Yes I'm using a specific driver and the model is "HP LaserJet P4010"..
And no info under pharos alerts..
Sorry for not clearing that part..
Yes I got charged for the first job and I have the option "relist as a free print" selected - which is what I wanted in case the print failed.
But even when I tried to release the "Free print" job, it also failed and it kept re-listing the job as a free print.. which tells me something else cause this to happen..
My concern is why does it treat the black and white job as a color print.. cause it says in the log:
- Based on the following check for associated color device Printer= PStation= PrintRelease-LRF3 PrintGroup=Black_White Print Group
- No Color Devices found
I have a pretty heavy interest in this subject. We have an external Blackboard gateway for charging and we do the free relist. The free relist is a pretty cool feature but I don't think people know about it. I'm trying to understands what happens when the print job poops out. My understanding is that a person releases a job, a call to the Blackboard gateway debits their Blackboard account. The job is released and starts to print. In the middle of the print job, the printer hangs for whatever reason; most likely a RIP error and the printer needs to be power cycled. Through the SNMP mechanism, Uniprint detects something messed up and relists the job for free. In a perfect world, the patron goes to another printer and tries to re-release it and is not charged again.
What really happens, is that the patron fiddles around and the job expires from the print system. They come back a few day later and are mad that their Blackboard account was debited $20.00 for their print job, but the print job did not come out and was deleted, and they cannot print anymore because they have insufficient funds. In the meantime they may have found another way to print their $20.00 document elsewhere. They come to me for a refund. When I go to look at the transactions for that person, I do not see any $20 transaction. When I ask the Blackboard office to query their transactions, they do see the $20 transaction. Of course, because Uniprint would not start sending the print job until they successfully debits the $20. The trend seems to be that completed jobs are logged in the Pharos transaction logs and these bunged up jobs are not.
Not to change the direction of the discussion, but since I have people interested in failed jobs and free relisting has anyone else seen this behavior of not logging incompete or errored or relisted print jobs? Maybe I have this color and B&W issues as well. I'll have to check. Or have you seen some other behavior? Or do I have some kind of setting wrong?
I'm having the same exact issue.. users dont know about this free re-listing feature.
Here is what i think happens.
- User sent the print job to Pharos server.
- Pharos communicate with Blackboard and sees the connection, so it gives the green light to blackboard to debit the money from that user account.
- Pharos then talks to the release station and tries to release the job.. boom there is a problem nothing was released and its too late cause the money already been debited from the account.
- Pharos cannot backward, so it re-list the same job and market as a free print.
*keep in mind that pharos only re-list the print job for a specific period of time, which is the "Reprint Holding Period", I changed mine to 240mins = 4 hours, which means if the user didnt try to release it within 4 hours.. it gets deleted and there is no record under Pharos Administrator, the only two places that has a record of that print job is Blackboard + Pharos print logs under "C:\ProgramData\Pharos\Logs\PrintServiceYYYY-MM-DD.log" <== Good luck finding that specific transaction when you have thousands of other transactions like my server.
So my approach of fixing this issue was to look at the logs and search for the keyword "free print" and locate which printers had this re-listing issue.. I was able to get a list of them and then I changed the printing protocol under those devices from RAW to LPR or from LPR to RAW.. right now i have about 30 devices devices, they are mixed; some are using RAW and some are using LPR.. and it seems to be working fine.. I hope this helps!
This article may be useful to those interested in the topic, as it describes the SNMP device check and how it operates.
Also, a minor correction...
The time that a Free Print job has to live in the queue is set by the secure Print Group's "Job Purge Time" and not the Device's "Reprint holding time".