Could not talk to print service

[Krishna Rao Siddamsetti]

We have configured three IBM6400-010 printers on Sun Enterprise Server
E4500 running SunOS 5.8 using HP's JetAdmin/HPPI. These printers serve
the Unix server as well as AS/400. However, they behave strangely when
it comes to printing large reports from Unix. When the report is big,
these printers print some pages and then loop back to printing from
page 1. For example, if the report is 200 pages, they would print from
page 1 to, let us say, 47, and then start from page 1. This will go on
until some one stops the printer manually. At this time, it is not
easy to cancel the job also. One thing, the 'cancel' command will not
work and will respond with the above message ("Could not talk to
...."). And then pressing the 'cancel' button on the printer will not
do the job easily, because each push of the 'cancel' button clears
only so much of the buffer on the printer. So what we end up doing is
to keep pressing the 'cancel' button for a long time, more than
half-an-hour often, to clear all the buffer so that the printer does
not start printing when re-started. I have tried to find a solution to
this problem from HP, IBM technicians, and a couple of sys. admins
with no success. I will greatly appreciate it if any of you could help
me with any solution you may have for this problem. I tried the
following with no success:
lpshut
rm -r /var/spool/lp/tmp /var/spool/lp/temp /var/spool/lp/requests
/usr/lib/lpsched

Thanks a lot in advance,

Krishna Rao Siddamsetti
Mississippi Valley State University

[ML Starkey]

Krishna Rao Siddamsetti wrote:

> We have configured three IBM6400-010 printers on Sun Enterprise Server
> E4500 running SunOS 5.8 using HP's JetAdmin/HPPI. These printers serve
> the Unix server as well as AS/400. However, they behave strangely when
> it comes to printing large reports from Unix. When the report is big,
> these printers print some pages and then loop back to printing from
> page 1. For example, if the report is 200 pages, they would print from
> page 1 to, let us say, 47, and then start from page 1. This will go on
> until some one stops the printer manually. At this time, it is not
> easy to cancel the job also. One thing, the 'cancel' command will not
> work and will respond with the above message ("Could not talk to
> ..."). And then pressing the 'cancel' button on the printer will not
> do the job easily, because each push of the 'cancel' button clears
> only so much of the buffer on the printer. So what we end up doing is
> to keep pressing the 'cancel' button for a long time, more than
> half-an-hour often, to clear all the buffer so that the printer does
> not start printing when re-started. I have tried to find a solution to
> this problem from HP, IBM technicians, and a couple of sys. admins
> with no success. I will greatly appreciate it if any of you could help
> me with any solution you may have for this problem. I tried the
> following with no success:
> lpshut
> rm -r /var/spool/lp/tmp /var/spool/lp/temp /var/spool/lp/requests
> /usr/lib/lpsched
>
> Thanks a lot in advance,
>
> Krishna Rao Siddamsetti
> Mississippi Valley State University

You have a few problems here.

First question would be: is there a reason you are using an H-P utility
to setup IBM Network printers? While this is not unheard of, it assumes
you have your IBMs attached to the network with either H-P JetDirect
interfaces or an interface that mimics an HP jetdirect. The output of
the command: lpstat -lp <queuename> would be helpful. lpstat -v
<queuename> as well.

The re-printing behaviour you describe could be attributed to how you
have the printers setup. This is a common complaint with HP printers
that are connected via JetDirect interfaces and have the "job recovery"
and/or "true end of job" parameters set to "ON". It's also a common
problem with network printers that are configured as remote printers,
which is not recommended or supported.

The inability to cancel a job could be attributed to the contents of
your /etc/inetd.conf file, specifically the in.lpd line. It has to be
uncommented AND it MUST refer to "tcp6" and not tcp. You should also
run the command pmadm -l and make certain there are no references to tcp
services. zsmon services are OK; they are for serial ports. TCP
services in this context can cause problems and should be removed.

[Doug Freyburger]

Krishna Rao Siddamsetti wrote:

>
> We have configured three IBM6400-010 printers on Sun Enterprise Server
> E4500 running SunOS 5.8 using HP's JetAdmin/HPPI. These printers serve
> the Unix server as well as AS/400. However, they behave strangely when
> it comes to printing large reports from Unix. When the report is big,
> these printers print some pages and then loop back to printing from
> page 1. For example, if the report is 200 pages, they would print from
> page 1 to, let us say, 47, and then start from page 1. This will go on
> until some one stops the printer manually.

This is caused the a default setting in the print queue. It is
set to restart any failed print job. I've encountered it on
HPUX and used SAM to turn it off, so on Solaris I don't know if
the printer set-up can be done via GUI or a config file.

> At this time, it is not easy to cancel the job also.

That's because each time the printer end fails, the Unix end
submits the job again from scratch. You'll need to use
"cancel" on Unix to remove it from the queue as well as on
the printer to stop the current instance.

One thing you'll need to do is get the print jobs to stop
failing half way in. Maybe cut them up into smaller pieces.
Maybe look closely at the AS/400 config to make certain it
waits until the printer is available in case it is interupting
the print jobs to cause the failure.

[Greg Andrews]

Krishna, you report two problems. The second problem (can't
cancel print jobs) compounds the first (print jobs repeating
endlessly).

In most cases, the second problem is easier to fix than the
first, so it's a good place to start. Martha suggested the
correct entry in /etc/inetd.conf. The old-style TCP listener
daemons can also interfere with the operation of the cancel
command, and they are no longer used for printing. Run these
commands to disable the listeners to prevent them from causing
trouble:

pmadm -r -p tcp -s lpd
pmadm -r -p tcp -s lp
pmadm -r -p tcp -s 0 (that's the number zero)


See if that helps the problem with the cancel command.

The problem with the repeated print jobs is something I've
seen happen with the HP Jetdirect/HPPI software. If you
look in the file /opt/hpnpl/README.UNX, you'll find some
very interesting reading in Section III:


************************************
III. ISSUES/SOLUTIONS/WORKAROUNDS
************************************