Jerry,
     I also ran into some timeout issues a long time ago (1/94).  Per IBM
level 2, I raised the commtimeout parameter in the ADSM server options file
from the default of 60 seconds to 300 seconds.  This helped eliminate a lot
of the timeout problems we were having.

     I would definitely recommend bumping up the dispatching priority for
ADSM, at least during the periods when your incremental backups are running.
 We have our ADSM dispatching priority set to just below that of TCPIP.  In
my opinion, ESCON is not going to by you anything because bus & tag @ 4.5
MB/sec is still faster than Ethernet or Token Ring (would probably help with
FDDI, though). You used to be able to run into problems with the 3172's
(overruns, etc.) by running in  'promiscuous' mode but I don't think that's
supported anymore.  You might also want to check and see what ADSM
background processing is running at the time you're having these problems
(i.e. Expire processing, disk to tape migration, reclamation, etc.)  I try
to avoid running these processes while the incrementals are running - they
use a lot of CPU resources and can interfere wtith the backups.

Good luck !!!

Tim Pittson
pittson1 AT bwmail1.hcc DOT com

 ----------
From: owner-adsm-l
To: Multiple recipients of list ADSM-L
Subject: Performance problem help
Date: Tuesday, January 16, 1996 1:31PM

Date:     January 16, 1996            Time:    12:54
From:    Jerry Lawson
    ITT Hartford Insurance Group
    (203) 547-2960    jlawson AT itthartford DOT com
 -----------------------------------------------------------------------------
We seem to be having a performance problem that has us scratching our heads.
Has anyone else seen anything like this?

We are running the MVS server at V1 R1 L14.  A customer will initiate a
backup
(usually an initial backup, but could be a long restore), and the process is
initiated.   Throughput seems to be OK, based on what we see on the Kb/sec
indicators.  All of a sudden, we will get a message on the client indicating
a
TCP/IP failure.  On the server, we get an ANR0481 message, indicating that a
client session was terminated after 60 seconds of inactivity.  (Message
manual
indicates the client was holding a lock.  My concern here isn't what we were
holding, but rather "Why have we been sitting there for a minute."

We initially thought that the problem was in a 3172 that we were using for
connections to the mainframe.  It was an older model, and it was running at
99% + utilization most of the working day.  The network folks think the 3172
is flooded with broadcast messages - ADSM activity is generally low when
this
occurs.  We addressed this problem by upgrading the 3172 to the new model
that
was recently released (90hz Pentium based).  (BTW - we are not doing the
TCP/IP offload in this box).  However, the next morning after the upgrade
(yesterday) the problem reoccurred.  Utilization on the 3172 was in the low
30% range.  Diagnostic messages on the 3172 indicate the problem was between
ADSM and the 3172.

On MVS, ADSM runs with a low dispatching priority - underneath batch and
TSO.
Is this normal, or should it be above them?  Overall MVS utilization exceeds
95% most of the time.   TCP/IP's dispatching priority is set very high to
insure it gets what it needs.  The 3172 is on a high speed Bus and Tag
channel
(4.5 MB/Sec).  Does it need to be moved to an ESCON channel?

Can anyone else suggest anything?

*****************************************************************************
                        Jerry