TCP/IP Limitation?

[Arch_Muthiah]

Jorge,

As I said earlier, the number of connection is depend on your VMS system available resources.

But you can limit the number of connections if you don't have enough system resources using CHANNELCNT SYSGEN parameter.

TCPIP> SHOW SERVICE TELNET /FULL shows the current setting/limit details, the default I thing it is 256. Changing this values requires enough system resource especially (nonpaged pool size)

If you want you try change using
TCPIP> SET SERVICE TELNET /LIMIT=n
make sure the value of "n" would not exceed the channelcnt SYSGEN param.

Because "too many sessions" error will come whenever we don't have enough non-paged mem.

I would suggest better contact Hp on this.


Archunan

[Arch_Muthiah]

J,

I just saw this from the ask the wizard, it says something about your window side client lic limit and WINdows sometime misinterpreting the client connections lic limit (pthwork client), try go thru this...

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

Archunan

[Jorge Cocomess]

Here's the result after I ran "SHOW SERVICE TELNET /FULL"

Service: TELNET
State: Enabled
Port: 23 Protocol: TCP Address: 0.0.0.0
Inactivity: 1 User_name: not defined Process: not defined
Limit: 50 Active: 22 Peak: 35

File: not defined
Flags: Listen Rtty IPv6

Socket Opts: Keepalive Rcheck Scheck
Receive: 3000 Send: 3000

Log Opts: Actv Dactv Conn Error Logi Logo Mdfy Rjct
File: not defined

Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0


Please let me know your feedback.

Thanks,
J

[Robert Gezelter]

Jorge,

You noted that the telnet connections are limited to 50, and the maximum reached is 35, so that is unlikely to be the issue.

With that number of clients, you are not lilely to be hitting the 9999 units limitation on a daily basis.

I would, however, question one premis of this entire thread: That the OpenVMS system is the source of the problem.

If this is indeed happening several times a day, out of hundreds of connections, it is a rare enough event to be caused by other problems. To track this by science, rather than by guesswork, I would use a LAN monitor (e.g., Ethereal or Etherpeek) to capture and log the traffic that is having the problem. I would then locate the sessions that are being dropped and see exactly what DID HAPPEN not what MAY HAVE HAPPENED.

The logs will show the facts, not guesswork as to what could have happened. It is more grind, and more tedious than just adjusting parameters, but it is guaranteed to produce an accurate result that can be taken to management.

- Bob Gezelter, http://www.rlgsc.com

[Hans Blom_2]

Hi,
we had more or less the same problem, but with ftp. We found out a lot of server processes were in RWMBX and then connections timed out.
Raising the TQElm for account TCPIP$FTP solved the problem.

Regards
Hans