Bad IOSB 556

[Rafael Mendonça Braga]

Hello all!!

We are having troubles with our printer queues this week.
Well, I found at operator.log a lot of occurences of this messagee:

%%%%%%%%%%% OPCOM 9-NOV-2004 07:57:05.72 %%%%%%%%%%%

Message from user SYSTEM on SIRIUS

TCPIP$TELNETSYM - (P709) open_socket_ast invoked with bad IOSB 556: device timeout

It's occurring not only for the printer "P709", but for a lot of printer queues.
What this error means?!?!
A Network problem?!

I would like to thank everybody in advance!!!

Thanks guys!

Rafael M. Braga

[Ian Miller.]

Can you ping P709 using the address defined in the queue or the other printers?

[Uwe Zessin]

Hello Rafael,
I agree that it looks like an intermittent network problem. As this problem appears with lots of queues it sound like a problem with the server or equipment in the data path. I would first check the interface counters:

$ mcr lancp
LANCP> show device /counters

[Volker Halle]

Rafael,

556 = SS$_TIMEOUT = Device Timeout

This indicates some kind of network problem between your OpenVMS system, where TELNETSYM is running and your printers.

Start troubleshooting with:

$ TCPIP PING printername
or
$ TCPIP PING printer-ip-address

whichever is used as /ON= value on your queue ($ SHO QUE P709).

As a next step, you could use traceroute:

$ TR:==$TCPIP$TRACEROUTE
$ TR printername
or
$ TR pritner-ip-address

Volker.

[Rafael Mendonça Braga]

Hello All!!

Thanks a lot for the Replies!

Guys, I think it's a network problem, because I Found some printers in the operator.log that was with the error message, and look at the PING outputs:

SIRIUS> TCPIP PING p667
PING TS0034 (138.106.238.210): 56 data bytes


----TS0034 PING Statistics----
4 packets transmitted, 0 packets received, 100% packet loss
%SYSTEM-F-TIMEOUT, device timeout
SIRIUS> TCPIP PING p435
PING TS0062 (138.106.238.220): 56 data bytes


----TS0062 PING Statistics----
4 packets transmitted, 0 packets received, 100% packet loss
%SYSTEM-F-TIMEOUT, device timeout
SIRIUS> TCPIP PING p707
PING P707 (10.33.13.66): 56 data bytes


----P707 PING Statistics----
4 packets transmitted, 0 packets received, 100% packet loss
%SYSTEM-F-TIMEOUT, device timeout
SIRIUS> TCPIP PING p710
PING TS0034 (138.106.238.210): 56 data bytes


----TS0034 PING Statistics----
4 packets transmitted, 0 packets received, 100% packet loss
%SYSTEM-F-TIMEOUT, device timeout
SIRIUS> TCPIP PING p736
PING TS0039 (138.106.233.194): 56 data bytes


----TS0039 PING Statistics----
4 packets transmitted, 0 packets received, 100% packet loss
%SYSTEM-F-TIMEOUT, device timeout
SIRIUS>


So Do you think it's an network problem??

This printers was in the operator log with an error message (IOSB 556).

Thanks,

Rafael M. Braga

[Bojan Nemec]

Rafael,

This is a network problem. Other connection to or from the network (such as telnet or other) works?

When looking to yours PING outputs I see a strange thing:
SIRIUS> TCPIP PING p667
PING TS0034 (138.106.238.210): 56 data bytes
and
SIRIUS> TCPIP PING p710
PING TS0034 (138.106.238.210): 56 data bytes

Two different names and same IP address? If there are two nodes with the same IP, there can be very strange things on the network.

Bojan

[Uwe Zessin]

Bojan,
in both cases the name TS0034 is shown. That looks like an alias pointing to the same node.

Rafael,
from the output it sounds like you are dealing with multiple subnets, too. You might also have a routing problem. You can verify the paths like this:

TCPIP> traceroute p667

Of course you will not see a full path when the destination is unreachable.

I hope you have a documentation of your network topology. If not, this is the time to create it ;-)

[Bill Hall]

Rafael,

The IOSB 556 error seems to be a catch-all error as it also occurs when a print file can not be opened for printing. This is the most common situation when we get this error. A slow printer with large print files or low bandwidth somewhere along the network path combined with version limits and/or over-aggressive file cleanup... The problem continues to get worse if you are not pro-active in deleting the print jobs with deleted files. The queue stalls on the job with the deleted file. Additional jobs submitted are pending in the queue, more cleanup or version limits set on the print files remove more files before they can be printed.

[Volker Halle]

re: TS0034 - couldn't it be different ports on a terminal server ?! Check the queue /ON= parameter. If the queues contain the same IP name, but different port numbers, it IS a terminal server (of some kind).

re: IOSB 556 - this is definitely an error associated with creating an IP connection (note the routine name: open_socket_ast in the OPCOM message). It may cause the queue to stall and other cleanup-procedures to then delete the print-files, but it's NOT a catch-all when failing to open a print file.

Can you ping these IP addresses from some other IP nodes in your network ?

Volker.

[Rafael Mendonça Braga]

Hello guys!!

Thank you everybody!

Well,
I don't know much about our network here because I work at Technical Support department adn we have another department that cares only about network.
I will pass them all the information I got and all the responses you've posted to my question. When we got a solution, I will lwt you know!

I know that here we use "printservers" on the printers, and the "TS0034" is one of our printservers.
Yes, we have more than one printer alias configured to the same ip address... I don't know why, and now I have to ask the guys of network why it's happening and if it's correct.

Look:
SIRIUS> ucx sh host p710

LOCAL database

Host address Host name

138.106.238.210 TS0034, ts0034, LogPosVend_Main1, p667, P710


SIRIUS> ucx sh host p667

LOCAL database

Host address Host name

138.106.238.210 TS0034, ts0034, LogPosVend_Main1, p667, P710

Well, when we solve it I will post it here Ok?!

Thanks a lot Folks!!

Rafael M. Braga

[Uwe Zessin]

Yes, please. It is always nice to know if our answers have been helpful and what the problem was - we all can learn from it.

[Lokesh_2]

Hi Rafael,

Define the following logical and then stop/start the queue. Let us know if this rectify the problem:

Define/system/exec TCPIP$TELNETSYM_IDLE_TIMEOUT "0 00:00:30"

Increase the value a little bit it if the above also fails to work.

And if your printer is printing fine then to suppress the opcom you can define the following

DEFINE /SYSTEM TCPIP$TELNETSYM_NO_OPCOM 1


HTH,
Thanks & regards,
Lokesh

[Antoniov.]

Hi Rafael,
you cannot ping ts0034 (same as p667 and p710); you cannot ping TS0062 (alias p435), p707 and TS0039 (alias p736). Can you ping some other hosts?
Can you ping yourself 127.0.0.1?
can you ping direct addresses (example 138.106.238.210)?
Are theese addresses into your same network?

Antonio Vigliotti