> Sometimes this works and I'm assuming that the LPD running within that > printer is "lost" in those cases.
Yes. Another common cause is that the printer is servicing a request from another protocol and just not responding to LPR requests at all, which causes RSCS to time out and stop printing to the printer. Early generation HP exhibited (and many Canon and Xerox printers *still* exhibit) this problem often. It appears that writing working multitasking code for microcontrollers is no longer taught in schools. *grump* At least most vendors have fixed the bugs where the LPD implementation in the printer mixed data from different sources if two print requests occurred at the same time....*grumble* > Second question: Has this ever happened to you? > When it fails we assume there something physically wrong with the > printer. All the bloody time. It's less likely to be physical problems with the printer than poorly written LPD implementations in the printers. That's one reason why I tend to put a Linux instance in between RSCS and the printers. It does put another layer for the operators to monitor, but the CUPS LPR/LPD support is smarter about retrying and/or it can just use IPP whenever possible (which gives more status about what's happening with the printer and also doesn't require the printer to switch input mechanisms between the Windows boxen and the mainframe).
