Hello Dwight,
AFAIK and have observed within the last months this is the normal behaviour
of the "new" multithreaded TSM client (>= v3.7.2.x). The default value for
the corresponding dsm.opt parameter RESOURCEUtilization is 2. So if you
haven't set a different value, everytime the client contacts the server he
opens two sessions: One for the control information, the other for the
data.
You can verify this by querying the client sessions on the server during a
scheduled or manual backup. Depending on the number and the size of the
changed files on the TSM client one session should have a relative small
number of bytes received or sent and won't change much after the backup
process itself has been initiated. The other session will transfer the data
from the client to the server and will the number of bytes received should
equal the size of the backed up files. This session will be closed before
the control session (the data transfer is already over but the client still
has to sent its results to the server).
So, if you want just one session for both tasks specify RESOURCEUtilization
1 in the dsm.opt. And if you want five data sessions you would have to
specify RESOURCEUtilization 6 in the client's option file.
And regarding your question about the error message:
Because every "new" client (v3.7 or 4.x) now uses two sessions maybe you
have to increase the maxsessions parameter in your dsmserv.opt so the
maximum number of scheduled sessions is also increased? And perhaps it is
just happening what the error log says: The server rejects the session
because there are no more sessions allowed to be opened?
Just my 2 cents. Please correct me when I'm wrong.
Mit freundlichen Grüßen,
Met vriendelijke groeten,
With best regards,
Bien amicalement,
CU/2,
Dirk Billerbeck
Dirk Billerbeck
GE CompuNet Kiel
Enterprise Computing Solutions
Am Jaegersberg 20, 24161 Altenholz (Kiel), Germany
Phone: +49 (0) 431 / 3609 - 117, Fax: +49 (0) 431 / 3609 - 190,
Internet: dirk.billerbeck @ gecits-eu.com
This email is confidential. If you are not the intended recipient,
you must not disclose or use the information contained in it.
If you have received this mail in error, please tell us
immediately by return email and delete the document.
cookde AT BP DOT [email protected] on 02.07.2001 19:58:02
Please respond to ADSM-L AT VM.MARIST DOT EDU
Sent by: ADSM-L AT VM.MARIST DOT EDU
To: mailbox.dekelnsm
cc:
Subject: cuSignOnResp: Server rejected session; result code: 53
--------------------------------------------------------------------------
Can't remember this one being mentioned and I didn't find anything on Can't
remember this one being mentioned and I didn't find anything on a
search of adsm.org so I though I'd toss this to the group...
anyone seen this in their client dsmerror.log ?
06/15/01 15:41:32 cuSignOnResp: Server rejected session; result code: 53
AIX 4.3.3 server running TSM 3.7.2 and the clients seem to mainly be sun
solaris 6 with tsm 3.7.2.0 client code
hugh amounts of zero activity sessions from client to server.... (they have
nothing to do with the scheduler)
3,0,ADSM,07/01/2001,00:50:33,SUNDEV1,oracle,SUN
SOLARIS,1,Tcp/Ip,1,0,0,0,0,0,0,0,0,3,7,7,0,0,4,0,0,0,0,7,2
3,0,ADSM,07/01/2001,11:31:32,TDCCDPD1,,SUN
SOLARIS,1,Tcp/Ip,1,0,0,0,0,0,0,0,0,1,0,0,0,0,4,0,0,0,0,7,2
Even if root simply initiates a "dsmc" session and then does anything to
contact the server (such as a "q sched") it opens a session that
terminates,
writes the record to the dsmerror.log and then performs the desired action
and gives the proper info back to the dsmc session
BUT each action initiates at least two sessions.
Is a little bit of a pain because after only being up for 45 days, this
specific tsm server is on client session 985,043
The accounting log is rather large.
I know... 4.1 or 4.2, I'll head there quick enough but this seems to have
started out of the blue a couple months ago and I haven't figured it out
yet...
any thoughts ?
Dwight
|
