> We are getting the following error from time to time:
>
>       *******************************************************
>        ANS4017E Session rejected: TCP/IP connection failure
>       *******************************************************
>
>Any ideas what the problem is and how to fix it.

Here is a repost of something I posted earlier on this topic.

Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com

========================================

It is almost always impossible to diagnose "ANS4017E TCP/IP connection failure"
problems with just the ANS4017E message. When you get this, the first thing you
need to do is check the ADSM server activity log for corresponding error
messages, i.e. ANR0480W, ANR0481W, ANR0482W, or whatever. If you don't see any
message on the server indicating that the session failed, then issue QUERY
SESSION and check the state of the session. Also, on the client side, check the
dsierror.log file (for API applications like SQL BackTrack) or dsmerror.log
(for the regular ADSM backup-archive client). Typically a message will be there
with a TCP error number (errno).

While this could conceivably be an ADSM problem, the vast majority of the time
these turn out to be related to something external to ADSM. If your server is
MVS and you are using IBM's TCP/IP version 3.2, then make sure you have the
latest & greatest TCP/IP maintenance installed, as there have been several
APARs for TCP/IP 3.2 that impact ADSM. Also, check your DSM.OPT file for the
TCPWINDOWSIZE value. If you've got it set very high, try lowering it to a more
modest value like 32, and see if that makes any difference. These are only a
couple of things to check.

If you need assistance from IBM to diagnose this problem, then you should open
a problem record with IBM support (1-800-237-5511 if you have voice support, or
ETR if you have IBMLINK electronic support). If you want to gather some doc
before you call in, here is what you can do:

1) Obtain ADSM client and server traces that show the problem:

     a) From an ADSM administrative client, issue these commands:

          TRACE DISABLE *
          TRACE ENABLE SYSTIME TCP SESSION
          TRACE BEGIN some.file.name

     Note: "some.file.name" is a path/file name where the server
     trace file will be written. If the problem takes a while to
     occur, make sure you send it to a file system with lots of
     space. If this is an MVS server, enclose the file (data set)
     name in double and single quotes, like this:

     "'some.file.name'"

     On MVS, you should also pre-allocate the trace data set with
     these attributes: LRECL=1028, BLKSIZE=6144, RECFM=VB,
     DSORG=PS. Be sure that MVS security allows ADSM to open and
     write to this data set. Also, you should make the data set
     very large (on the order of hundreds of MB) to reduce the
     possibility of space-related abends. The size of the data
     set ultimately depends on how long it takes to recreate the
     failure, and how much other ADSM client traffic is going on
     while you are tracing the problem client.

     b) Edit the client API options file and add these lines:

          TRACEMAX 4096
          TRACEFLAGS TXN COMM SESSVERB SESSION VERBINFO
          TRACEFILE some.file.name

     Note: "some.file.name" is the path/file name where the
     client trace file will be written.

     c) Recreate the problem.

     d) After the problem occurs, from an ADSM administrative
     client issue these commands:

          TRACE FLUSH
          TRACE END
          TRACE DISABLE *

2) Collect the following items:

     a) The server trace file (or data set)

     b) The client trace file

     c) Client "dsm.opt" file (and "dsm.sys" if this is a
        UNIX client)

     d) The output from this ADSM administrative command:

        Q OPT

     e) The ADSM server activity log from the time the
        client session started through the time it
        failed

   Since the trace files may get large, you should probably
   PKZip them (or tar/compress, etc.).

3) Also be prepared to provide this information:

     a) The operating system, including version and
        release that your ADSM server runs on.

     b) The operating system, including version and
        release that your ADSM client runs on.

     c) If the server is MVS, the version of TCP/IP
        you are using.

     d) The version, release, and level of your ADSM
        server, as reported by the output from the
        administrative command:

        QUERY STATUS

     e) The version, release, and level of your ADSM
        client. You can obtain this by starting the
        ADSM command line client (dsmc). The first
        thing the client displays is the version,
        release, and level information.

Good luck!