Hi Robin
I have exactly the same problems with NT4 (SP5+) and W2K (SP2) client from
3.7.2.17 to 4.2.1.15
We already have a dedicated backup network and check all communication
params.
Everything seems good to me. I opened a pmr and I'm still waiting IBM's
call..
rv
Robin v/d Vliet <R_van_der_Vliet AT DAS DOT NL>@VM.MARIST.EDU> on 2001-11-22
11:29:40
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: TSM kills IP address on NT4 clients
Hello everybody,
I thought maybe one of you could have experienced the following problems
with
TSM and NT4 clients, and maybe you can help us out with them, I sure hope
so.
We are trying to make archives of our NT4 clients and although some come
out
with a state of succes, others loose their connection with the TSM server.
I know, this ain´t all that bad since these sessions are re-established,
but
because of this some of these clients take too long to complete (eg. 12
hours to
complete a 5 Gb archive).
The DSMerror.log files all show a lot of entries like:
21-11-2001 21:51:19 sessRecvVerb: Error -50 from call to 'readRtn'.
All I could find on this problem was to update the drivers on the NIC´s and
to
adjust the settings like Duplex mode and the speed (100Mb) to match. Still,
this
problem persists.
We made a serperate network so TSM and the Clients would not be confronted
with
other requests, but without succes.
Other failing clients even loose their IP address during and after the
archive
session. Although the properties of the IP address shows up like it should
on NT
we can´t ping it anymore, leaving no other option then rebooting the
machine.
This is an example of what we see in the dsmerror.log on these clients
21-11-2001 21:22:44 ANS1810E TSM session has been reestablished.
22-11-2001 04:31:05 sessRecvVerb: Error -50 from call to 'readRtn'
22-11-2001 07:39:49 sessSendVerb: Error sending Verb, rc: -50
22-11-2001 07:39:49 ANS1809E Session is lost; initializing session
reopen
procedure.
22-11-2001 07:39:49 ANS1809E Session is lost; initializing session
reopen
procedure.
22-11-2001 07:40:14 TcpOpen: TCP/IP error connecting to server.
22-11-2001 07:40:14 sessOpen: Failure in communications open call. rc:
-50
22-11-2001 07:41:05 TcpOpen: TCP/IP error connecting to server.
22-11-2001 07:41:05 TcpOpen: TCP/IP error connecting to server.
22-11-2001 07:41:05 sessOpen: Failure in communications open call. rc:
-50
22-11-2001 07:41:56 TcpOpen: TCP/IP error connecting to server.
22-11-2001 07:41:56 TcpOpen: TCP/IP error connecting to server.
The catch in all of this is that we can schedule an archive for two clients
to
run and no problems seem to appear and the archive/backup sessions
completes in
a short amout of time, like it should. If we update the schedule to make an
archive for 4 or more clients all mentioned above seems to apply.
Some background information:
We are using the following components:
AIX (ver. 4.3) with TSM (ver. 4.2)
NT 4 with servicepack 4 and 6a clients
100 Mbit Ethernet connections (100mb/full duplex configured)
Avaya P333t switch (all ports are 100mb/full duplex configured)
The Maxsessions parameter is configured "40".
Our goal is to make archives of 18> clients on a weekly basis,
Can anyone please supply me with a hint on how I can reach my goal?
Thanks in advance,
Robin van der Vliet
=================================================================================
Dit bericht is uitsluitend bestemd voor de geadresseerde en kan
vertrouwelijke
informatie bevatten. Gebruik door derden of openbaarmaking van dit bericht
zonder toestemming van DAS Rechtsbijstand of de geadresseerde is niet
toegestaan
en kan onrechtmatig zijn. Aansprakelijkheid voortvloeiende uit
onvolledige of
niet tijdige ontvangst van dit bericht is uitgesloten. Indien dit bericht u
per
ongeluk bereikt, verzoeken wij u vriendelijk ons daarvan direct in kennis
te
stellen en het bericht te wissen.
Dit bericht en eventuele bijlagen zijn gescand op de ons bekende virussen.
Wij
adviseren u alle berichten en bijlagen op virussen te scannen voor ze te
openen.
=================================================================================
|
