The idle wait applies to session 2763, while the bytes received applies to
session 2764. These are two separate/independent sessions, so there is no
direct relationship between what happens on one session and what happens
on the other session. However, there is an *indirect* relationship. Based
on the information you have provided, I would say that session 2763 was
initiated by a client producer thread, and session 2764 was initiated by a
client consumer thread. (The TSM client uses the producer-consumer
multithreading model.)

When the producer thread gets a file specification to be processed, it
queries the TSM server for information about existing backups for that
file spec. The server sends the query results back to the client, which is
why you see a relatively large number of bytes sent for session 2763.

The producer thread uses the query results to determine which files have
changed since the last backup, then builds transactions (representing
files to be backed up) to be processed by the consumer thread. The
consumer thread then backs up the files in each transaction. Since it is
the consumer thread that does the actual backup work (i.e. the transfer of
the data to the server), you see its session (2764) with a large number of
bytes received.

In your case, the producer thread is not being given any more file
specifications to process, so it isn't querying the TSM server, and thus
its session is idle. Once the consumer thread is done with its work (and
there are no more file specifications to process), then the consumer and
producer threads will close out their server sessions.

If the producer session is timed out via the server's IDLETIMEOUT setting,
it will re-establish itself if necessary.

The client's main thread is responsible for giving the producer thread
file specs to process. The producer thread doesn't close out its session
after processing each file spec for performance reasons; if the file specs
are coming in fairly quickly, then the overhead of stopping/restarting
sessions could impact performance. In theory, I suppose the producer could
close its session after a certain period of inactivity, but for now, this
is how it works. What you are seeing is normal.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




"PINNI, BALANAND (SBCSI)" <bp3965 AT SBC DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/02/2002 10:33
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: WHy Idle wait keeps incrementing?(reply)



Hi

Happy new year to u all.

Can u pl help me with this question.
I have seen sometimes Idlewait time keeps incrementing in spite of
client
getting backed up.
Thanks in advance.
tsm: TSM>query session

  Sess Comm.  Sess     Wait   Bytes   Bytes Sess  Platform Client Name
Number Method State    Time    Sent   Recvd Type
------ ------ ------ ------ ------- ------- ----- --------
--------------------
--------------------
 2,763 Tcp/Ip IdleW  42.1 M  10.5 M   1.1 K Node  WinNT    Client1
 2,763 Tcp/Ip IdleW  42.1 M  10.5 M   1.1 K Node  WinNT    Client1
 2,764 Tcp/Ip RecvW    0 S    1.7 K 106.9 M Node  WinNT    Client1
Balanand