topic tcpip$telnetsym printers stalling intermittantly in Operating System - OpenVMS

tcpip$telnetsym printers stalling intermittantly

Tony Clayton_1 — Tue, 16 Oct 2007 12:00:27 GMT

We have 10 old serial prtiners (LA324, LA400, etc...) set up using the tcpip$telnetsym and 90% of the time they work fine, but occasionally their queues will go into a "stalled" state and we have to "stop/reset" and then "start" the queues to get them going again. Here's the command we used to set up the queues; "init/que/start/processor=tcpip$telnetsym/on="10.22.21.23:2001" printer1". All of these printers are connected to a DS90M+. Any suggestions or ideas?

Re: tcpip$telnetsym printers stalling intermittantly

Martin Hughes — Tue, 16 Oct 2007 20:33:55 GMT

I'd suggest you check your operator log for the accompanying error message. My guess is you will probably see something like "open_socket_ast invoked with bad IOSB 556: device timeout".

Given that all of the queues are going into a stalled state at the same time, the most likely scenario is that the VMS node loses connectivity with the terminal server.

Re: tcpip$telnetsym printers stalling intermittantly

Tony Clayton_1 — Tue, 16 Oct 2007 20:42:49 GMT

Sorry...I wasn't clear about the fact that the queues do not stall all at the same time...but rather they stall at different times. They all work most of the time (90% of the time), but ocassionally, they will stall at different times. There doesn't seem to be any pattern at all. We've looked at the size of the print job, the number of queued jobs, etc...there's just no decernable pattern. I will check the operator logs for the error.

Re: tcpip$telnetsym printers stalling intermittantly

Jon Pinkley — Tue, 16 Oct 2007 23:28:20 GMT

Tony,

How is the port on the DS90M+ configured? Are you using soft (xon-xoff) flowcontrol or hardware? I don't have either your printers or a DS90M+ so I can't tell you if hardware flow control is possible. If hardware flow control can be configured, doing so results in fewer problems.

Xon-Xoff is a less reliable method of signaling the readiness of the printer than a dedicated pin. For example, if a printer is turned off or the cable is disconnected when the terminal server thinks the printer is ready to accept data, new print jobs will be sent out the port and since there is nothing connected, no Xoff will ever be received by the port. Jobs will just be lost, although VMS will think they were successfully printed.

Your problem is not that. However, if the LA printers do not send an XON character when they are powered on, the following can lead to the situation you describe. A printer jams or paper runs out, and the printer sends an XOFF to the terminal server. Later a person reloads the paper, and turns the power off to allow the platen to move freely to adjust the paper, and then turns the printer back on. If the printer does not send an XON, the printer is ready, but the terminal server still thinks the printer is not ready to receive more characters, so it does not allow any new character to be sent out the port to the printer.

Most printers that support xon-xoff (soft) flow control will send a "gratuitous" xon when they are powered on, in case the port was previously in the "waiting for xon" condition.

The next time one of your queues goes into a stalled state, connect to the terminal server and issue the following command:

Local> show port xx status (for 10.22.21.23:2001 I would expect the printer to be connected to port 1 of the DS90M+, so substitute 1 for xx)

If you see output that shows "output XOFFed: Yes", then the terminal server is waiting for a "go ahead" xon to be received from the printer. Conversely, if you see something like the following, the problem is somewhere else, like the tcp connection.

Access: Remote Current Service:
Status: Idle Current Node:
Sessions: 0 Current Port:

Input XOFFed: No Output Signals: DTR RTS
Output XOFFed: No Input Signals: None

Good Luck,

Jon