Connection Log

Mainframe Product

Connection Log

More Information

You may want to also see our Problem Finders or z/OS monitoring products. Use the site navigation bar above or click on the product name below.

The Connection Log provides a simple way to view TCP connections for the mainframe TCP stack. You do not have to run programs against the live SMF datasets.

Why would someone want a Connection Log? You may want to see who is using the TCP/IP network. A user may be having problems connecting to an application or you may want to make sure that activity is indeed happening for a particular application. You may also be having problems with connection failures. Some applications if they are running out of capacity will send a reset to terminate the connection. You may want to know if all connections for an application for the last 10 minutes have terminated with a reset.

You may not want to use certain versions of the SSL/TLS protocol, because it has known security flaws. You may want to use only certain cipher suites, because the others are no longer considered secure.  Connection Log will let you see whenever someone starts a secure connection which is not approved.

The Connection Log shows you all TCP activity as it happens.

Connection Log is a pure mainframe application.


Here is a Case Study of how Connection Log can help you find and SOLVE problems on your network.  All the reports in the Case Study are from the Connection Log product.

How can Connection Log help you?

  • Warn you of failing connections.
  • Warn you of retransmissions on network hardware or circuits.
  • Alert you to connections which are transmitting excessive data.
  • Warn you of response time problems.
  • Alert you to an application which is reaching its capacity limits.
  • See which users have used your TCP applications (MQSeries, FTP, TN3270, etc.).
  • Alert you to AT-TLS problems.

Connection Log provides a simple way to view TCP connections for the mainframe TCP stack.  If you need to know about all of your TCP activity as it happens, you need Connection Log


We welcome your questions and queries. Please see our Contact Us page for complete contact information.

More Sayings to Live By

A small mistake done a million times a day becomes a big mistake!


• This was coming from load balancers ‘just checking” to see if they should balance.

• Why TCP connection? ICMP probably blocked.

• Some of this is OK. Have to decide the interval.

• Probably not a great idea to do it for apps which have no usage!

Waste of Resources?

• z/OS Communications Server will use resources.

• DB2 will use resources.

• Remote host will use resources.

• The traffic to and from the remote host will require bandwidth.

• Communications Server will use resources to record the activities.

• TCP monitoring tools will require resources to record the activities.

Traced the Addresses

What we saw was constant sequences of




Who is connecting to DBDist5?

Remote IP Count BytesIn BytesOut 37,282 0 0 37,280 0 0 37,280 0 0 37,281 0 0

DB2 Connection Analysis

Application Port Connections Percent
DBDIST1 5027 6,316 3.48%
DBDIST2 5029 25,295 13.94%
DBDIST3 5041 1 0.00%
DBDIST4 5045 39 0.02%
DBDIST5 5047 149,747 82.55%

Reset Analysis

Total Reset 149,420 Percent of total
FTP 121 0.08%
DB2 149,123 99.80%
TN3270 132 0.15%
IBM HTTP Server 43 0.03%
Other 1 0.00%

Connection Termination Analysis

Total Reset 193,066 Percent of total
Application Close 42,255 21.88%
Reset Received 149,420 77.39%
Keep Alive 296 0.15%
No FIN Received 18 0.00%
PASCAL Close 1,066 0.55%
Other 11 0.00%

DB2 Analysis

• As can be seen, DB2 has the most connections.

• There were 792.4 Million inbound bytes and 41.69 Billion outbound bytes for DB2.

• We next looked at how connections were terminated.

Case Study

DB2 Connections 193,066
Telnet Connections 42,255
FTP Client Connections 149,420
FTP Server Connections 296
Other Connections 18
Total Connections 193,066
Inbound Bytes 18.47 Billion
Outbound Bytes 43.82 Billion