Ah yes, the Royal "we" - blue of course - however, IBM have also been known to charge the odd fee; indeed, for my time when I was on staff analysing perfpmr data    It came to mind because I am working on such a report at the moment, in my now private capacity, and it's a nice way to get all the various stats and configs together around a problem.

The PTY settings are just one example limitation at the application level,
e.g. affecting concurrent telnet connections.

The server may refuse TCP connections for lower level reasons - e.g. not enough queues and buffers
in the tuning of the adapter, interface and kernel.  There's quite a bit to it.

The netstat statistics and/or entstat outputs might reveal queue/buffer config problems.

By the way, a good way to capture all the stats in a consistent manner,
around a problem like this, is to run a "perfpmr" - downloaded from here:

ftp://ftp.software.ibm.com/aix/tools/perftools/perfpmr/ (http://ftp://ftp.software.ibm.com/aix/tools/perftools/perfpmr/)

If you are having performance problems of any sort, this is something
we can analyse and report on for you - for a fee.  Otherwise, this is the tool
to gather data needed by the IBM support centre if you are raising it as a
problem possibly in need of a fix.

Take a look at the first section of
netstat -an
- for TCP sessions ESTABLISHED, etc.

If your reason for asking was that you are hitting a limit,
depending on what the TCP using application is, perhaps that's the PTY settings:
smit chgpty