S
sseney
Guest
Gus, not sure if I follow. Our environment is as follows: 1. Each printer is defined a printer queue on each Linux system where users might print to that printer. 2. Each linux system has their own print server (we don't have just one print server but many). 3. Our Progress APPS have printers defined (which use the defined printer queues) 4. Each user has a defined default printer - and then can select another printer if they need to print elsewhere in the company. Typically, they only print to a printer in their general work area. 5. we use the lp command from w/in 4GL code to send print jobs to specific printer queues. The problem we are seeing with CUPS and using the command cupsenable, after a printer has been down/broken. This that command doesn't appear to "resend" all jobs still in that printer queue to the printer. We noticed that on a different linux system (running a different os version/level) still has the old "enable" command and that does resend the print jobs hung on a queue to the now fixed printer. What we've been trying to figure out is what is the cause of the difference between "cupsenable" vs "enable" commands (as they are supposed to be essentially the same...and what other config files we might need to check on the one host that doesn't seem to work properly...as our SA has not yet found the cause. We've googled & searched many CUPS/Linux forums and the answers there have said to just re-enable the print queue and the print jobs should print...but they don't for one of our Linux systems. We have to go into the GUI software for CUPS and resend each print job still hung on the print queue. This is obviously not desired - as it's extremely time consuming when we have several days of hung jobs. Another point, is that sometimes printers break and we're not notified right away, and there are automated print jobs that print - so they get hung as they can't print. There are times we can resolve this by changing the user's ID to a different printer/queue defined for that system...but sometimes we can't as some are not based on user id but are "hard coded"...and yes, I know, hard-coding might not be good or best practice...but that's what has been done and we have to live with this limitation for now...until I can convince powers to be to enhance the script/processes so that we woudn't need to change a program to change the printer for the report(s). I've posted on several Linux & CUPS forums...to no avail...was hoping that maybe someone on the PEG or Progress community might've run across this issue before.
Continue reading...
Continue reading...