Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Printing issue

 
SOLVED
Go to solution
Yyrkoon_
Advisor

Printing issue

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)

 

9 REPLIES 9
abrsvc
Respected Contributor

Re: Printing issue

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
Honored Contributor

Re: Printing issue

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_
Advisor

Re: Printing issue

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
Valued Contributor

Re: Printing issue

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
Honored Contributor

Re: Printing issue

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.