%TCPIP-E-LPD_REQREJECT after restarting LPD server

[Willem Grooters]

(VMS 7.1, TCPIP 5.0A. PRODUCTION - so urgent..)

I had to change information on one printer in TCPIP$LPD_PRINTCAP and restarted the LPD server using:

$ @SYS$STARTUP:TCPIP$LPD_SHUTDOWN
$ @SYS$STARTUP:TCPIP$LPD_STARTUP

since that moment, every job sent to printers using the LPD-SYMBIONT runs into this error:

%TCPIP-E-LPD_REQREJECT, print request rejected by !AS (queue !AS)

Just like this. No substitution of (who? What?) of queue.
I already checked the logfiles and all I find there is this message.

I have stoppped the queues and started them, with, and without restarting the LPD server; I also stepped back to the original TCPIP$LPD_PRINTCAP.DAT file, but nothing changed.
I also enabled debug (according the manuals defining TCPIP$LPD_DEBUG and TCPIP$LPD_RCV both to 15, but no additional output...

Accounting just states the job is stopped before executution and will be restarted.

LPD has been restarted under the SYSTEM account but that didn't help either.

Most important (due to the urgency of the issue): How to get things working again, as soon as possible? Preferrably after obtaining information on what nmay have caused the problem.

[labadie_1]

Have you tried using another symbiont, like

1) Dcps with the Ip_LPD
2) Telnetsym

[labadie_1]

By the way, a basic

$ ucx sh dev /port=515

gives
%TCPIP-W-NODEVSOCK, device_socket not found

or something better ?

And a
$ telnet ip_address_of_the printer 515
works/connects ?
or gives something similar to
%TELNET-E-CONNFAIL, Failed to connect to remote host
-SYSTEM-F-REJECT, connect to network object rejected

[Willem Grooters]

Alas, DCPS is no option: unsupported printer (Kyocera is not on the list)
The printers have previously been accessed using the TELNET symbiont but due to problems with that, we moved to LPD that solved these problems. All printers have worked since that moment, until this afternoon.

Extra: These problem printers are 'remote' - served by the same Windows-based printer server. Could that have caused a problem? Another queue, served by another server, has no problem at all.

[labadie_1]

>>>These problem printers are 'remote'

a firewall blocking the port 515 ?

Can you ask the networks guys to check ?

[Willem Grooters]

Ask the Wizard gave the right direction: the printer(server) rejects the request. (http://h71000.www7.hp.com/wizard/wiz_7596.html?jumpid=reg_R1002_USEN). As it turned out, a queue serviced by another Windows box did work correctly so that was, for us, enough to point the (Windows) printserver as a culprit. So the queues on that mnachine were restarted, and I could successfully output all reports..

[Willem Grooters]

Printing using LPD over a remote, non-VMS printserver, just restart the queues (or equivalent). It might help.

[Ian Miller.]

Personally when printing via a windows system has problems I always start with blaming the window system. Generally the support people for the windows system restart something and everything works again.

[Jan van den Ende]

@Ian

>>>
Generally the support people for the windows system restart something
<<<

As is their standard, so it would come naturally to them :-)

Proost.

Have one on me.

jpe