Printing issue

[Yyrkoon_]

Hi all,

I am having some problems printing. I have a printer queue "properly" configured. I sent jobs to this queue with a delay of 30 seconds during a whole day and it prints them all without any problem. Nevertheless, when I sent a batch file with around 160 print jobs, all them gets queued, but most (not all) of the times the printer gets stalled and I have to reset the queue.

Do you have any idea of what could be happening?

Thanks in advance

XXCDM1$ sh queue /full dongle
Printer queue DONGLE, stopped, autostart, on XXCDM1::"19.555.555.146:9100", mounted form DEFAULT
  <Dongle>
  /AUTOSTART_ON=(XXCDM1::"19.555.555.146:9100") /BASE_PRIORITY=4 /DEFAULT=(FORM=DEFAULT) /OWNER=[SYSTEM] /PROCESSOR=TCPIP$TELNETSYM
  /PROTECTION=(S:M,O:D,G:R,W:S) /SCHEDULE=(NOSIZE)

[abrsvc]

A queue "stalls" when the communication link failes or the printer "runs out of paper".  In this case, I would suspect that there is a communications problem which is being detected and rather than sending the print job to the proverbial bit bucket, the particular job is stalled.  I have seen this in the past at client sites where the printer itself is restarted or the cable is removed for some reason.    Since this is connected via IP, there is no mechanism for a "reconnect" that  I have found that will trigger the queue to restart on its own.

In my specific case, the printer was in an operating room that required cleaning after each procedure.  This meant that the printer was disconnected.  Quite often, the printer was not connected prior to an attempt to print to it.  Since the printer cannot initiate communications with the VMS system (doesn't really know or care about it), the printer would remain stalled until an operator would "restart" the queue.  I think the same thing is occurring here.  The communications link must be initiated from the VMS system TO the printer.  Had the printer just run out of paper, the link would still exist and be able to restart without intervention.

Hope this helps,

Dan

[Hoff]

In addition to abcsrv, check the duplex settings.  It's fairly common for duplex settings mismatches on the host or possibly also on the printer to sort-of work, and sort-of fail.

As for TCP/IP Services, please post the version and patch level.  What sort of printer is this?

And as there have been more than a few buggy implmentations around, if telnet printing doesn't work reliably, see if lpr works better here.  If the particular printer supports Postscript, then using the DECprint Services (DCPS) symbiont would be another potential alternative path.

Also confirm with the printer documentation that telnet uses TCP port 9100 here — that's an HP raw port — and not the more typical TCP 23.

[Yyrkoon_]

Thanks both, I have tried to follow your advices, regretfully nothing is solved. It is still getting stucked.

I have checked duplex settings, they seem to be right. about the port, 9100 is also correct, I can print without any problem but when I send a lot of jobs to the queue in a row. About the TCPIP version...

TCPIP> sh ver /all

  HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 2
  on an AlphaServer DS10 617 MHz running OpenVMS V8.3

All services inside are all of them "V5.7-ECO2        23-NOV-2010  SYS$COMMON:[..." but these:

TCPIP$NTPTRACE;1                 V5.7                         30-MAR-2004

TCPIP$TELNET_SERVER;1      V5.7-13ECO2       4-FEB-2005  SYS$COMMON:[SYSEXE]

all SSH related is                        V5.7-ECO2            19-JAN-2011

[MarkOfAus]

AFAIK, Port 9100 printing is RAW printing. There is no queueing performed by this raw port.

It would therefore correlate that VMS spewing multiple jobs to that port will cause problems. The jobs will either merge or more likely overwhelm the printer port and cause a stall to be reported back to VMS.

My solution would be to, as Hoff said, use lpd on the printer (assuming it's available as you omitted to mention the printer you are sending to). Use sys$system:tcpip$lprsetup to create the printer queue.

PS. Port 9100 is available on most enterprise printers, not just HP.

[Hoff]

Which manufacturer and model printer?

Telnet is usually on port 23.  Try that.

If telnet fails, try the LPD path. 

(Some printers have automatic printer format recognition, and which can sometimes get confused.   This is part of why I'd try the TCP 23 telnet path, and the LPD path.)

I'd also confirm that the duplex settings are correct on the DS10 and on the switch port.   Mismatched duplex settings cause weirdness, where some stuff works but increased activity might not.

Might also want to see if there are other IP-lreated or network or system-related errors being logged, too.  The command ANALYZE/ERROR/ELV will get you to the prompt that can translate the errors for the core system components.

See if there are firmware upgrades for the particular printer, too.

Then apply the current TCP/IP Services and current OpenVMS patches, and — failing that — ring up HP support, or whoever provides your escalation services.  (V5.7 ECO 2 and V8.3 are very old versions, unfortunately.)

ssh is not involved here, though the version in use looks to be as ancient as the rest of the software here.

[Yyrkoon_]

Sorry for that. Printer is:

hp laserjet 600 M603

[Hoff]

Per the manual and the printer specs, that printer does support "IPv4/IPv6: Apple Bonjour Compatible (Mac OS v10.2.4 or higher), SNMPv1/v2c/v3, HTTP, HTTPS, FTP, TFTP, Port 9100, LPD, WS Discovery, IPP, Secure-IPP, IPsec/Firewall; IPv6: DHCPv6, MLDv1, ICMPv6; IPv4: Auto-IP, SLP, Telnet, IGMPv2, BOOTP/DHCP, WINS, IP Direct Mode, WS Print; Other: NetWare NDS, Bindery, NDPS, ePrint"

Most of which are not supported by the available and add-on OpenVMS printing, unfortunately.

But telnet via IPv4 (though not IPv6) is supported, and that's via TCP port 23.  Try switching to that.

lpd is also supported via IPv4 and IPv6, and that's TCP port 515.   If telnet fails, try that.

Again: I'd move off the TCP 9100 raw port here, as you're not sending raw data, and it's distinctly possible sending a whole wad of files is getting tangled.   If that printer had integrated supported Postscript, then DCPS and TCP 9100 would be typical.  And DCPS uses TCP 9100.   But not here. as this printer appears to require host-based Postscript interpretation (akin to host-based rendering, but for processing Postscript), and a host-based Postscript interpreter is not available with OpenVMS itself nor with DCPS.

[Yyrkoon_]

Actually I am sending raw data. :)

[Yyrkoon_ · Accepted solution]

Well, the problem is solved.

Finally it was, as it is usually, a stupid thing. The quota in the queue was not enough, it has been solved just creating the queue with the proper parameter:

$ init/queue dongle2/proc=tcpip$telnetsym/start -

/AUTOSTART_ON=(xxcdm1::"19.555.555.146:9100") -

/default=(nofeed,form=default)/SCHEDULE=NOSIZE/WSQUOTA=16384

Many thanks for your help!