Might want to check resourceutil settings as that limits the number of
sessions clients try to setup. It should match maxnummp or be lower.

Op 31 aug. 2016 22:21 schreef "Zoltan Forray" <zforray AT vcu DOT edu>:

> AHA - so I am not loosing my mind (at least in this situation).  I too have
> been seeing clients getting >3-sessions eventhough the NODE maxnumpoints is
> 1!  I was always under the impression that maxnumpoints trumps
> resourceutilization.
>
> On Wed, Aug 31, 2016 at 3:40 PM, Thomas Denier <
> Thomas.Denier AT jefferson DOT edu>
> wrote:
>
> > We are occasionally seeing some odd behavior in our TSM environment.
> >
> > We write incoming client files to sequential disk storage pools. Almost
> > all of our client nodes use the default maxnummp value of 1.
> >
> > When the odd behavior occurs, a number of clients will go through the
> > following sequence of events:
> > 1.The TSM server will send a request to start a backup.
> > 2.The client will almost immediately open a TCP connection to be used as
> a
> > producer session (a session used to obtain information from the TSM
> > database).
> > 3.Somewhere between tens of seconds and a few minutes later the client
> > will open a TCP connection to be used as a consumer session (a session
> used
> > to send copies of new and changed files).
> > 4.Sometime later the client will open a third TCP connection and start
> > using it as a consumer session.
> > 5.The TSM server will report large numbers of transaction failures
> because
> > it considers the original consumer session to be tying up the one mount
> > point allowed for the node and hence has no way of storing files arriving
> > on the new consumer session.
> >
> > In most cases, all of the affected clients will hit step four within an
> > interval of a couple of minutes.
> >
> > My current theory is that step four occurs when the client system detects
> > a condition that is viewed as a fatal error in the original consumer
> > session, triggering the opening of a replacement consumer session. In
> most
> > cases the TSM server never detects a problem with the original consumer
> > session, and eventually terminates the session after five hours of
> > inactivity (we have database backups that can legitimately go through
> long
> > periods with no data transfer). More rarely the TSM server eventually
> > reports that the original consumer session was severed.
> >
> > We occasionally see cases where the replacement consumer session is in
> > turn replaced by another new session, and even cases where the latter
> > session is replaced by yet another session.
> >
> > Our client population is a bit over half Windows, but almost all
> instances
> > of the odd behavior involve only Windows client systems.
> >
> > The affected systems are frequently split between two data centers, each
> > with its own TSM server.
> >
> > We have usually not found any correlation between the odd TSM behavior
> and
> > issues with other applications. The most recent case was an exception.
> > There were some e-mail delivery failures at about the same time as step
> > four of the odd TSM behavior. The failures occurred when e-mail servers
> > were unable to perform LDAP queries.
> >
> > When we have asked our Network Operations group to check on previous
> > occurrences of the odd behavior they have consistently reported that they
> > found no evidence of a network problem.
> >
> > Each of our TSM servers runs under zSeries Linux on a z10 BC. Each server
> > has a VIPA address with two associated network interfaces on different
> > subnets.
> >
> > I would welcome any suggestions for finding the underlying cause of the
> > odd behavior.
> >
> > Thomas Denier,
> > Thomas Jefferson University
> > The information contained in this transmission contains privileged and
> > confidential information. It is intended only for the use of the person
> > named above. If you are not the intended recipient, you are hereby
> notified
> > that any review, dissemination, distribution or duplication of this
> > communication is strictly prohibited. If you are not the intended
> > recipient, please contact the sender by reply email and destroy all
> copies
> > of the original message.
> >
> > CAUTION: Intended recipients should NOT use email communication for
> > emergent or urgent health care matters.
> >
>
>
>
> --
> *Zoltan Forray*
> TSM Software & Hardware Administrator
> Xymon Monitor Administrator
> VMware Administrator (in training)
> Virginia Commonwealth University
> UCC/Office of Technology Services
> www.ucc.vcu.edu
> zforray AT vcu DOT edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit http://infosecurity.vcu.edu/phishing.html
>