I hope it works for you. We recently upgraded to 5.5.1 server on a z/OS
platform, after which most of our scheduled backups failed, apparently because
of some perceived discrepancy found by reverse lookup.
We added the DNSLOOKUP NO parameter as suggested by IBM support (it is
undocumented for z/OS) and by itself, it did not solve our problems.
We also had to restart the client acceptors on all the clients. In a few cases
we had to perform manual backups before the new server software was satisfied.
- Margaret Clark
Systems Programmer, San Diego Data Proc4essing Corporation
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Conway, Timothy
Sent: Thursday, September 18, 2008 4:20 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM scheduler can't reach TSM client even though it seems
to know it's IP address.
TSM will populate field TCP_ADDRESS in table NODES with the numeric address of
the client when it connects, so not having name lookups performed is really no
loss in functionality... And now that I know about that option, it's going in
next restart, because it will cut latency, which will matter for things like
when an RMAN client deletes its old backups in a flurry of hundreds of separate
sessions in sequence.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, John
Sent: Thursday, September 18, 2008 1:35 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM scheduler can't reach TSM client even though it seems
to know it's IP address.
Bill,
Never heard of this option. Won't this make us unable to reach ANY
clients then, unless we put them in the local /etc/hosts file? That would be
impractical, with 1600 clients in our environment.
Or will TSM use the cached copy it saved when the client first
connected in? Do you use that in your environment? Does it work seamlessly,
or are there gotchas?
Best Regards,
John D. Schneider
Phone: 314-364-3150
Cell: 314-750-8721
Email: John.Schneider AT Mercy DOT net
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Bill Boyer
Sent: Thursday, September 18, 2008 1:31 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM scheduler can't reach TSM client even though it seems
to know it's IP address.
Try DSNLOOKUP NO in the dsmserv.opt file. The default is YES.
Bill Boyer
"Hang in there, retirement is only thirty years away!" - ??
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, John
Sent: Thursday, September 18, 2008 1:49 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM scheduler can't reach TSM client even though it seems to know
it's IP address.
Tim,
We have tried this, but it doesn't help. When you issue a 'q node
stlo-mpvadm f=d' the TSM scheduler clearly has the correct address cached for
it:
...
TCP/IP Name: STLO-MPVADM
TCP/IP Address: 10.52.27.204 ..
So the TSM scheduler seems to still know what the IP address is, but for some
reason still does a DNS resolve I guess.
Best Regards,
John D. Schneider
Phone: 314-364-3150
Cell: 314-750-8721
Email: John.Schneider AT Mercy DOT net
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Conway, Timothy
Sent: Thursday, September 18, 2008 11:09 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM scheduler can't reach TSM client even though it seems
to know it's IP address.
The simplest solution is
upd node STLO-MPVADM HLA=10.52.27.204
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, John
Sent: Thursday, September 18, 2008 9:29 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM scheduler can't reach TSM client even though it seems to
know it's IP address.
Greetings,
We are running TSM 5.4.3.0 on AIX 5.3ML5. Most of our TSM clients
are 5.4.x or 5.5.x. Most of our clients run "schedmode prompted" so
the TSM server launches the schedule.
We see an occasional problem where a Windows client is set up wrong in
Active Directory (which feeds DNS), and the TSM scheduler won't be able to
start the client scheduler. It will get errors such as:
09/18/08 05:51:12 ANR8213W Session open with stlo-mpvadm.company.com
timed
out. (SESSION: 243)
09/18/08 05:52:58 ANR8213W Session open with stlo-mpvadm.company.com
timed
out. (SESSION: 243)
09/18/08 05:54:44 ANR8213W Session open with stlo-mpvadm.company.com
timed
out. (SESSION: 243)
09/18/08 05:56:30 ANR8213W Session open with stlo-mpvadm.company.com
timed
out. (SESSION: 243)
09/18/08 05:58:16 ANR8213W Session open with stlo-mpvadm.company.com
timed
out. (SESSION: 243)
09/18/08 06:00:01 ANR2578W Schedule WIN_PROD_0300 in domain WIN_PROD
for
node STLO-MPVADM has missed its scheduled start up
window.
In looking into it, what seems to be happening is that it's forward resolve in
DNS doesn't match it's reverse resolve. Here is an example:
W:\>nslookup stlo-mpvadm
Server: stl-pdcp001.smrcy.com
Address: 10.2.215.158
Name: stlo-mpvadm.smrcy.com
Address: 10.52.27.204
W:\>nslookup 10.52.27.204
Server: stl-pdcp001.smrcy.com
Address: 10.2.215.158
Name: stlo-mpvadm.company.com
Address: 10.52.27.204
W:\>
Notice that the domain name of the host is different on the forward and the
reverse resolve. That is a mistake.
When you issue a 'q node stlo-mpvadm f=d' the TSM scheduler clearly has the
correct address cached for it:
...
TCP/IP Name: STLO-MPVADM
TCP/IP Address: 10.52.27.204 ..
So what is TSM's problem here? It knows the correct IP address. What
difference does it make that the reverse resolve doesn't match? Or is the
problem with the client? Is it not responding? The client's dsmwebcl.log and
dsmerror.log show no evidence that it is getting contacted at all.
The right way to fix this is to fix the Active Directory root cause, but
sometimes that requires a reboot of the client which can taken a week or more
to schedule.
Is the schedmode setting at fault? Would changing it to "polling" get around
this until a reboot can be scheduled? If I don't hear anything better I will
try that tonight.
Best Regards,
John D. Schneider
Lead Systems Administrator - Storage
Sisters of Mercy Health Systems
3637 South Geyer Road
St. Louis, MO 63127
Phone: 314-364-3150
Cell: 314-750-8721
Email: John.Schneider AT Mercy DOT net
This e-mail contains information which (a) may be PROPRIETARY IN NATURE OR
OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the
use of the addressee(s) named above. If you are not the addressee, or the
person responsible for delivering this to the addressee(s), you are notified
that reading, copying or distributing this e-mail is prohibited. If you have
received this e-mail in error, please contact the sender immediately.
This e-mail contains information which (a) may be PROPRIETARY IN NATURE OR
OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the
use of the addressee(s) named above. If you are not the addressee, or the
person responsible for delivering this to the addressee(s), you are notified
that reading, copying or distributing this e-mail is prohibited. If you have
received this e-mail in error, please contact the sender immediately.
This e-mail contains information which (a) may be PROPRIETARY IN NATURE OR
OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the
use of the addressee(s) named above. If you are not the addressee, or the
person responsible for delivering this to the addressee(s), you are notified
that reading, copying or distributing this e-mail is prohibited. If you have
received this e-mail in error, please contact the sender immediately.
|
