Hello Les,

Maybe you can enlighten me on setting this up. I've read the "RSCS 3.2.0
Setting up an LPD-type Link"
(http://www.vm.ibm.com/related/rscs/lpdsetup.html)
but I am a bit confused.

This is in my config file

* IP PLAS PRINTER                                               
LINKDEFINE IPPLAS TYPE LPR FORM * AST                           
PARM IPPLAS  EXIT=LPRXONE ITO=0 TCP=TCPIP USER=Y PRINTER=RAW  # 
  SECURE=NO HOST=172.16.92.97 SYS=Y                           # 
  EP='S=N FF=N C=LPR CONV=Y SUFFIX=1B45'                        
* IP DELORMIER (CGI) PRINTER                                    
LINKDEFINE IPDELOR TYPE LPR FORM * AST                          
PARM IPDELOR EXIT=LPRXONE ITO=0 TCP=TCPIPC USER=Y PRINTER=RAW # 
  SECURE=NO HOST=10.161.58.231 SYS=Y                          # 
  EP='S=N FF=N C=LPR CONV=Y SUFFIX=1B45'                        

The LPD document talks about defining LPRLINK (and LPRPLINK) and then in
the LPRXFORM CONFIG file specifying

FORM=LPRFORM
HOSTNAME=host_name
PRINTER=printer_queue_name

I'm going to read further but how do I get the LPD of VM to print
directly to these 2 printers? What would be HOSTNAME and PRINTER ? 

Thanks

Mike 
 

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On
Behalf Of Les Geer (607-429-3580)
Sent: January 4, 2006 12:14 PM
To: [email protected]
Subject: Re: LPR & French Canadian characters

>> 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

Reply via email to