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