We are having a random print issue - we use UNIX printing. Some reports get stuck in a premature status. Yet if I go look at the temp file for the report it is there. If I take the ttaad320 record change the status, then I can reprint the report. I have not be able to duplicate the problem, but all users have reported that they have to use ctrl-alt-delete to kill the session. So it looks like everything runs okay until you get to the part where you take the temp file and execute the the lp command - sample from one device "/usr/bin/lp -dlouir01 -c -s -n%d %s". What exactly executes the lp command? I do not see anything on the process list. Is there an object I could run manually or at least look at? Just issuing the lp command on the temp file does not work so there is more to it than that. Looking to see if I need to go to Baan or our UNIX support group.

Any clues or anything at all would be appreciated. By the way the UNIX spooling takes place on a cluster of servers. I might move this to the administration forum, but thought I would check here first.

More information - this is not limited to just a few users or to any specific site. We have only few users who have reported the problem. Plus if they wait a little bit and try again it will work without problems. It does seem to occur more often in print purchase orders(tdpur4401m000) or in my home grown version which allow users to only print finalized purchase orders(uses AFS). I have also found that saving a printer in ttstpsplopen may cause a problem and have verified that the users that had the problem recently did not have a printer saved in this method. All I can think of for now.

Has anybody got any solution to this problem? I am also facing the same problem...

What about creating a wrapper script that calls lp and try to log as much info as possible thru it? Also keep an eye in your lpdaemon and its log, maybe this one is the one that has problems.

Well I never did find a solution for this and I do not know if the users just stopped complaining about(or if a tools update) solved the problem. I do know this - anytime anybody calls about a print problem I first look to see if they have done "save defaults" in ttstpsplopen. If they have I deleted, get them to log out and back in - this solves some weird problems.

I have users that experience very long delay times. The print job goes into 'premature' status and eventually gets set to 'Done' but, the job is still a long time showing up at the printer. It's a lot like what Mark_h describes.
Mark, what kind of printer are your using. Is it a HP4250?
Today, the printer decided to print the print control file instead of the actual tmp file that contained the job. The Unix admin and myself could not recreate the issue, and the printer is printing correctly now. We suspect something is happening at the physical printer that we can not detect.
It is surely a puzzle.
bb

I have users that experience very long delay times. The print job goes into 'premature' status and eventually gets set to 'Done' but, the job is still a long time showing up at the printer. It's a lot like what Mark_h describes.
Mark, what kind of printer are your using. Is it a HP4250?
Today, the printer decided to print the print control file instead of the actual tmp file that contained the job. The Unix admin and myself could not recreate the issue, and the printer is printing correctly now. We suspect something is happening at the physical printer that we can not detect.
It is surely a puzzle.
bb
We do use nothing but HP printers - as far as I know we do no have any HP4250's. When I was having this problem it was different types of printers. I do know that at times the printers configuration gets reset somehow and things like barcodes stop printing. The only option is to turn off & on the printer. We still use UNIX print queues that connect to Unix print cluster of machines - at least that is what I was told today. One problem we had yesterday was with a zebra - one set of 73 tags was sent to a printer, the user ended up with like 8 copies of these tags. The only reason they did not get more was because the job was cancelled. The problems we run into appear to be random.

Mark- It sounds exactly the same as ours. he he he. Random printing issues on random printers (all HP #### using the UNIX print queue). If you can call it 'exactly'! :D We use the 'on & off' to clear the printer and get printing to resume as normal also. I wonder if HP has any other clients experiencing the same behavior.

Good - point. I wonder how many others have this problem printing this way. Do your printers also do windows printing? I have to find out more about this - I think when I print from my PC it goes to a windows print server. Not sure about this yet. We did have HP2150's that would not work from a UNIX print queue - we solved it by installing some UNIX print services for the printer(not sure were). Then pointed the UNIX print queue straight to this windows queue. All baan printing now works to the hp2150. I am just not sure how this works.

Mark-
Yes, our printers are able to do windows printing if what you mean is: are they set up and available using network print services as well as set up in Baan on unix. :o Do you think it could be some kind of conflict between the two print services randomly confusing the printer?
thanks,
bb

Mark-
Do you think it could be some kind of conflict between the two print services randomly confusing the printer?
thanks,
bb
Thats exactly what I think is causing some of the print issues. Especially for things like barcodes quit printing. I can't prove it, but more windows or network printing is done to our printers than Baan printing.