Hello Managers:
I have decided to change the way in which the print queues are set up on the
DU side. No longer will I send jobs to the VMS queues, instead I am putting
the printers in the /etc/hosts file, and letting the printcap entries refer
to them explicitly.
I would like to thank all that took the time to respond, come of their
responses are listed below:
-------------------------------------------------------------------------------
Henry Flogel <hflogel_at_mailhub.wpl.com>
Dan -- I don't know if you can do what I am about to suggest but it worked
for us.We had the same problem for printers that had
the 'rp=' entry in uppercase, i.e. the printer send
no "CR"s. When we made the entry lower case the
problem went away!
----------------------------------------------------------------------------
-----
ccksb_at_trentu.ca (Ken Brown)
Does the HP have a JetDirect card? If so, here's what I use for an HP 4si;
cts_lj4_ps|lp0:\
:lf=/usr/adm/lperr:\
:lp=:\
:rm=cchp1:\
:rp=raw:\
:mx#0:\
:sd=/usr/spool/lpd:
cts_lj4|lp1|lp:\
:lf=/usr/adm/lp1err:\
:lp=:\
:rm=cchp1:\
:rp=text:\
:sd=/usr/spool/lpd1:
Note that the 1st one is for postscript and the second for text. The remote
printer (cchp1) is a node on our network and because it's not name-served
I've got it in /etc/hosts.
-----------------------------------------------------------------------------
"Uwe Schmidt" <SCHMIDT_at_bis.uni-oldenburg.de>
filter.c:
#include <stdio.h>
int c;
main()
{
while ((c = getchar()) != EOF) {
if (c == 10)
putchar(13);
putchar(c);
}
}
cc filter.c
mv a.out /somewhere/myfilter
in printcap: :if=/somewhere/myfilter:\
--------------------------------------------------------------------------------
Charles M. Richmond <cmr_at_iisc.com>
The reason that the print filters don't work is because, DU assumes
that remote printers do their own filtering and thus ignores all "of"
and "if" entries in a printcap that specifies a remote printer. You
should be able to solve your problem on the VMS side. Alternately
you could alias 'lpr' to be something like 'cat $* |filter|lpr -P xxx'
on your DU side.
----------------------------------------------------------------------------
------
Sheila Hollenbaugh <shollen_at_valhalla.cs.wright.edu>
If you absolutely must use VMS print queues, then you probably can't
use the rp=text. Otherwise, assuming that the printer is on the
network, you can spool directly to the printer using rp=text.
Those printers handle lpr traffic well on their own. The only
reason I can see for diverting the traffic through a VMS machine is
if you are using it to track who is printing what.
----------------------------------------------------------------------------
-----------
Sean Watson <swatson_at_tuolumne.lib.csubak.edu>
Let me preface this by saying that I haven't done much with
Dec-Unix's lpd nor have I used a JetDirect so please take what I say here
with a grain of salt. On the other hand, I have mucked around with the
BSD lpd quite a bit (both doing straight configuration and hacking the
source), so my input might be worth reading.
When you submit a job to lpd, (either via lpr or from a remote lpd),
it first checks if you have permission to use it (via the rg or the
/etc/hosts.lpd and /etc/hosts.equiv files) Next, it checks if the printer has
a rp/rm pair. If so, it ships the job off to that queue without further
processing. Otherwise, it queue's it and if the queue was previously empty
starts running the queue. To run the queue, it:
(1) opens the output device (the lp tag).
(2) forks an output filter (the of tag) with the lp tag as its stdout.
(3) while jobs are in the queue
(3a) generates and sends a banner page to the output filter
(3b) sends a special character sequence to get the output filter to stop
itself (with kill(SIGSTOP, getpid());) and waits for notification of
the SIGSTOP.
(3b) forks an input filter (the if tag) (or one of cf, df, gf, nf, rf,
tf, or vf if the job was sumitted with the appropriate flags) with
the lp tag as its stdout (it doesn't send it through of).
(3c) sends the job to the input filter
(3d) closes the input filter
(3e) sends a SIGCONT to the output filter.
(4) closes the output filter
(5) closes the output device
(6) marks the queue as inactive
This means that if it has a rm/rp pair of tags, the filter tags have no
effect. You can force the filters to take effect by setting
lp=/dev/null, setting the sh flag, not setting of, and setting if= a script
that looks something like this:
#/bin/sh
realinputfilter $* | lpr -Pprintername.raw
and making the printername.raw have the rm/rp pair.
You have some choices for rm. If your LaserJet has a jet direct card (or
can talk lpd protocol some other way), you can just set rm=LaserJet's IP addr
and rp=text (or rp=raw or whatever). Otherwise, you can send it to your
VMS queue and let your VMS machine worry about getting the job to the
printer.
Having only one machine talk directly to the printer has the advantage that
you can do centralized accounting, disable printing at a single point (but
still allow queueing of jobs), and work on filters at a single point.
Also the queue is more liable to be fifo since it is likely that one machine
will outcompete another in getting its jobs to the printer (which is
likely to have a limited queue size). The disadvantage is that a single
point of control is the same as a single point of failure.
----------------------------------------------------------------------------
--------
Long, Michael <MLONG_at_karmax.com>
Here's the printcap entry we use for our HP laserjet 4M. As you will see
it includes rp=TEXT. It's my understanding that this is nothing to do
with VMS (we also print to this printer from VMS), rather TEXT is the LAT
service name set on the network card of the printer. We use the standard
hp laser filter supplied with DEC UNIX.
systi:\
:af=/usr/adm/systi_act:\
:if=/usr/lbin/hplaserof:\
:lf=/usr/adm/systi_err:\
:lp=/dev/systi:\
:mx#0:\
:of=/usr/lbin/hplaserof:\
:pl#66:\
:pw#80:\
:rm=systi:\
:rp=TEXT:\
:rw:\
:sd=/usr/spool/syti:\
:xf=/usr/lbin/xf:
----------------------------------------------------------------------
I hope I didn't miss anyone, and thanks again.
--
Dan Peters
Systems Specialist
Novacor Chemicals
(519) 862-1445 x 5420
petersd_at_novachem.com
The opinions expressed above are my own, and not necessarily those of Novacor
Received on Wed May 29 1996 - 21:23:20 NZST