We have several printers setup to send the print file to a specific IP address and place in a specific folder based on printer selection (this is a Win2000 Server). The issue we are having is before sending the file, I do a lpstat for the printer and it shows ready and waiting. We send the job to the printer...the print job sit forever in the queue and shows that the destination is down and is waiting for it to come up.
We have in the past restarted the print service and sometimes the files will release, but that has not worked the last couple of times.
We are pretty much stumped any help/suggestions would be great
I assume the printer is in fact enabled as you say it is ready and waiting.
Is this a REMOTE printer?
If so I have seen these daisy chained in such a way that one queue is leading to another a queue which leads to a printer.
If this is your case.
This can cause many problems (other than not passing options) namely that the queue you are monitoring thinks it is up and available when in fact the next queue in the line is disabled (HPUX will disable printer queues based on connectivity loss) or perhaps the scheduler is in fact stopped on the next machine.
Find out the destination and trace it all the way to the physical IP of the printer. Note if the destination is an older Xerox it will be setup as remote queue no matter what.
Eronysis,
Thanks for your input.
This is setup as Remote printer with its destination as IP address with a queue name of uschecks. This queue is actually a folder on the machine.
Once the file arrives to the destination folder, we open up software which takes that file and sends it to an actual printer.
We have found that if we restart the print services on HPUX that sometimes the file will in-fact leave the queue and arrive in the folder. In some cases it will not. It doesn't seem to matter if the software is up or not.
We did some tracing today and our network folks continue monitor.
Any addl feedback you can provide may help us further troubleshoot.
TU again
Kurt
The print scheduler will most often restart(from the begining) a job stopped during such a restart. I have also seen remote queues such as yours hang when a printer is renabled without a lpshut and lpsched following it, although this was mostly on my legacy 10.10 and 10.20 environments. These things can be real bears but persistence pays off Good Luck!
Again, thanks for your input. As we have done a bit more investigation, the receiving server has a specific LPD service (Microsofts get disabled) to handle unix jobs provided by a 3rd party software. This service was not always running or in some instances it did not shut down properely and appeared to be running (or at least unix thought it was).