>> I'm thinking of the LPD software that runs on some non-VM=20 >> system that controls the network PC printer. I haven't looked=20 >> at RSCS LPD support yet. >> Could that be a possibility? > >The LPD implementation that finally despools the output to the physical >printer is the one that matters. That's the one that has the last word >about how the incoming data stream is interpreted. That's usually either >the one that's embedded in the printer (like a JetDirect card) or in the >print server supporting the printer. It's possible that it is causing >the problem, but most ASCII-based LPD implementations don't really do >any translation on the input stream (they figure the client is the only >one that cares, mostly for exactly this reason) and just pass it through >to the printer.=20 > >In this case, you'd still need to get the output to the printer somehow, >so I don't think the RSCS LPD would really help you much -- you'd still >have to turn around and resend the output to the printer, so you really >haven't accomplished any simplification. The RSCS LPR support is likely >to be the place to fix this. That's where you'd specify 437 to whatever >translation (I'd suggest 8859-1, most everything handles that properly >these days). You might try printing a config page from the printer, >determining it's direct address, and bypassing whatever is in-between to >determine where the confusion lies (direct LPR from RSCS is usually a >good test).=20 > >(And FWIW, if you're not using the RSCS LPR and LPD, you should switch >ASAP. It's substantially better (thanks, Les!) and a lot easier to >manage. All we need now is IPP support...8-))
Well if there is a translation problem with the daemon, you can resolve the translation via RSCS LPD then have RSCS LPR retransmit to the daemon and tell the daemon to just pass the data along to the printer as is. Best Regards, Les Geer IBM z/VM and Linux Development
