print files from z/VM (rscs) to linux cups printer

[David Boyes]

> We managed to set up a CUPS printer (HP) on a Linux guest and
> are able to print to it (from within Linux). We would like
> to be able to print z/VM files to this printer using RSCS.

You also need the cups-lpr package installed on the Linux guest. LPR
support is not enabled in CUPS by default.

[Dave Jones]

Hi, Susan.

Welcome to the wonderful world of z/VM and Linux as a guest.

From the error message that appears. it seems that the Linux CUPS
machine is rejecting the attempt by RSCS to open a connection. You might
want to check the Linux configuration files to make sure that the
necessary ports are available and listening for a connection.....

However, since you're using a network attached printer, why not just
have RSCS print directly to it, instead of routing the print through the
Linux guest? RSCS has very robust print queue management, imho, and this
will save you cycles on the host. It's easy to configure RSCS for
network attached printers, see the RSCS doc for details and examples.

Good luck.

DJ

Susan Zimmerman wrote:
> Hello VMers.
>
> We are new to both z/VM and Linux so are struggling newbies.
>
> We managed to set up a CUPS printer (HP) on a Linux guest and are able to
> print to it (from within Linux). We would like to be able to print z/VM
> files to this printer using RSCS.
>
> To our knowledge, we configured an lprp link and an lpd link (RSCS). We
> used YaST to 'allow' from the z/VM IP addr on EOSprinter
>
> lpr command (on z/VM) and results:
>
> lpr test test a (asyn PRINTER EOSprinter HOST linuxipaddr
> RDR FILE 0025 SENT FROM TCPMAINT PRT WAS 0025 RECS 0003 CPY 001 A NOHOLD
> NOKEEP
>
> nothing prints.
>
> lpq command (on z/VM) and results:
>
> lpq (All PRINTER EOSprinter HOST linuxipaddr
> Connection to linuxipaddr failed (Foreign host rejected the open attempt)
>
>
>
> lpq command (on Linux) and results:
>
> lpq EOSprinter
> EOSprinter is ready
> no entries
>
> We're mssing something...but don't know enough to even ask the right
> questions.
>
> TIA for any and all help.
>
> Susan

[David Boyes]

> However, since you're using a network attached printer, why
> not just have RSCS print directly to it, instead of routing
> the print through the Linux guest? RSCS has very robust print
> queue management, imho, and this will save you cycles on the
> host. It's easy to configure RSCS for network attached
> printers, see the RSCS doc for details and examples.

Not uncommon situation: the LPD implementation in the printer gets
confused if multiple jobs come in at the same time from different
sources (remember, there's no disk space to spool jobs, and memory is
extremely limited on most embedded print servers). This causes jobs to
be lost or corrupted. Also, if you have multiple protocols enabled (eg,
SMB and LPD), the embedded print servers tend to lose output. HP
JetDirect cards are particularly bad about this.

Funneling the jobs through one source (especially one that can spool and
queue jobs) is generally a good idea.

Another thing that you should check: did you set the NJE nodeid of your
VM system in SYSTEM NETID when you saved CMS? You'll have weird
unexplainable problems with LPR links very similar to what you're seeing
if you didn't.

-- db

[Dave Jones]

David Boyes wrote:
[snip of some very useful information....]

>
> Funneling the jobs through one source (especially one that can spool and
> queue jobs) is generally a good idea.
>
I would agree that having one print driver/server is a good idea. It's
easier to manage the print queue, for one thing. I would suggest that
perhaps letting all of the Linux guest print via RSCS might be a
reasonable approach here, as I think, imho, that it has better queue
management and spooling "smarts". YMMY, of course.

DJ

[David Boyes]

> I would suggest that
> perhaps letting all of the Linux guest print via RSCS might be a
> reasonable approach here, as I think, imho, that it has better queue
> management and spooling "smarts". YMMY, of course.

Depends a lot on who actually is interacting with the physical printer and what they're trying to do with it. If it's your normal mainframe ops people managing the queue, then I'd tend to agree. If it's someone else, the WWW interface for CUPS beats RSCS's interface hands down for "general user" friendly queue management (check out http://your.linux.instance:631 on your nearest CUPS install to see what I mean).

CUPS' IPP support also allows much more sophisticated utilization of printer features, and mapping of LPR options and queue names to IPP option strings (check out use of CUPS instances as preconfigured option packages for LPR printers). The ability to trivially specify output as 2 up, duplexed, stapled on the long side, and first and last page drawn from different paper bins w/o coding a zillion escape sequences in RSCS -- that's easy in CUPS, and you just map a CUPS instance name to a RSCS printer name to get it for free.

CUPS is good stuff. And it's got a real Messages and Codes manual.

-- db

[Thomas Kern]

Just a minor side-track as to why involve CUPS.

I am interested in finding out how to get this done via CUPS because then from
my Disaster Recovery site, I can configure my CUPS/Linux svm to communicate
with a remote CUPS server via an encrypted link. This would allow us to print
our z/OS reports securely to printers at Business Recovery centers. The current
procedure involves an often faulty 3900 and couriers.

Using Linux/CUPS as a communications appliance seems a good fit. I just wish
that RSCS was not a necessary stop in the pipeline. I will be looking at the
Linux NJE product when we return from our March DR exercise.

/Tom Kern

--- Dave Jones <***@vsoft-software.com> wrote:
> ...snipped...
> However, since you're using a network attached printer, why not just
> have RSCS print directly to it, instead of routing the print through the
> Linux guest? RSCS has very robust print queue management, imho, and this
> will save you cycles on the host. It's easy to configure RSCS for
> network attached printers, see the RSCS doc for details and examples.


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[David Boyes]

> I am interested in finding out how to get this done via CUPS
> because then from my Disaster Recovery site, I can configure
> my CUPS/Linux svm to communicate with a remote CUPS server
> via an encrypted link.

(BTW, this topic will be in my advanced CUPS talk at WAVV and the next
zSeries Expos, and probably at Hillgang or NEUVM if they'll allow me a
slot to talk about it.)

[David Boyes]

> I am interested in finding out how to get this done via CUPS
> because then from my Disaster Recovery site, I can configure
> my CUPS/Linux svm to communicate with a remote CUPS server
> via an encrypted link. This would allow us to print our z/OS
> reports securely to printers at Business Recovery centers.
> The current procedure involves an often faulty 3900 and couriers.

See the CUPS Administrator's Guide, pg 38. The short version is to add
"Encryption Required" to /etc/cups/cupsd.conf, configure the appropriate
keys, and ensure that your cupsd is built with SSL support. You can
then supply any supported OpenSSL authentication/encryption method, and
it "just works". The SuSE one probably is (it's got every other option
turned on, so I doubt they missed this one). Dunno about RH or Debian
off the top of my head.

On the RSCS side, you use TYPE LPR links. Use lpoptions on the CUPS side
to create a CUPS instance that specifies an option string of
"Orientation=Landscape,Font=Courier,FontSize=9pt,PageLines=66", and use
that instance name as the remote printer name in the RSCS LPR PRINTER=
parm. CUPS will take it from there, assuming you have the correct PPD
file for your printer.

> Using Linux/CUPS as a communications appliance seems a good
> fit. I just wish that RSCS was not a necessary stop in the
> pipeline. I will be looking at the Linux NJE product when we
> return from our March DR exercise.

If a few paying customers asked for it, we'd add direct spool file
support to the NJE/IP Bridge. We didn't set out to create a RSCS
replacement, although it's starting to look like an interesting project.


-- db

[David Boyes]

> but if we can get z/OS and z/VM output into a linux appliance for
> distribution, it might be nice to allow conversion of the output to a properly
> encrypted email or transformed into a PDF and attached to an email to
> designated recipient.

All the support for that is already present in the NJE Bridge code, which runs fine on IFLs.

AFAIK, the BSI folks have the code available and have for a while...8-)

-- db

[Thomas Kern]

I know it is a bit impolite to suggest enhancements to an as-yet unannounced
product, but if we can get z/OS and z/VM output into a linux appliance for
distribution, it might be nice to allow conversion of the output to a properly
encrypted email or transformed into a PDF and attached to an email to
designated recipient.

I currently have an SVM running on the legacy side of our z890. It would be
nice to move this function to the IFL side if an NJE connection could be made
between z/OS and the IFL side. Putting the email and PDF functions into the NJE
appliance on the IFL and I don't need my SVM at all.

/Tom Kern

--- David Boyes <***@sinenomine.net> wrote:
> ... snipped ...
> If a few paying customers asked for it, we'd add direct spool file
> support to the NJE/IP Bridge. We didn't set out to create a RSCS
> replacement, although it's starting to look like an interesting project.


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com