TCP: "dead" BG devices?

[Lachnitt_1]

Hi,

While we analyze a communication problem in our environment, we recognized that (nearly) every TCPIP-process has "dead" BG devices.

Means that a e.g. "show proc TCPIP$INEATACP" shows all connected BG-Device and if I check all with "UCX SHOW DEV BGxxx", at least one reportd the following:

$ ucx sho dev bg4541
%TCPIP-W-NODEVSOCK, device_socket not found

This is on TCPIP 5.4 and 5.5 (on other versions i don't know!).

Is this normal? Perharps for process generation?

Further some devices have the state:

State: CANTSENDMORE CANTRECVMORE PRIV

I attached a OUT-File form a procedure which checked all process which have BG-Devices allocated.

bye Kuddel

[Ian Miller.]

Do you have the last ECO kit for TCPIP V5.4 and V5.5 ?

Are they leftover from TELNET connections that have gone?

[David Jones_21]

A pending 'accept' operation on a listen socket will have a device created (channel assigned) which binds to a new connect when it occurs. Until then, UCX show device can't 'find' it in it's socket list. It's normal.

[Ian McKerracher_1 · Accepted solution]

Hello Kuddel,

This has been raised before with an older version of TCP/IP and the Wizard has stated that it is normal and expected behaviour. It seems reasonable to assume that it is still normal behaviour. I agree with David.

http://h71000.www7.hp.com/wizard/wiz_6287.html


Regards,

Ian

[Wim Van den Wyngaert]

The process also has non-ucx devices open. So, it is normal.

I also have 1 CANTSENDMORE... device on my system. For DESTA Director.

Not sure what it means. Waiting for other side to come back because no keepalive was enabled ?

Wim

[Richard Whalen]

The idea of pending socket was posted as one possibility; another possible reason is that the program uses the select call. Select allocates a BG device to issue the QIO to with the other BG devices specified in the parameters. The BG device that is used as the channel is not expected to have an actual socket connected to it.