Hi Karel,
Are you saying that the password expires DURING a scheduled operation, and
the operation subsequently fails? If so, and assuming that you are running
a supported TSM configuration, you should open a ticket with IBM support,
as this does not seem right to me (be sure to provide detailed recreate
scenario in order to facilitate a complete understanding of the problem).
Best 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 (DOT) ibm.com
IBM Tivoli Storage Manager support web page:
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L (AT) VM (DOT) MARIST.EDUwrote on 01/03/2007
11:19:19 AM:
Hi Andy,
And what if the password gets expired by passexp parm? This during the
scheduled back-up caused many of my scheduler services to stop on both
windows and Unix and failing the running back-up.
Regards,
Karel
Message
From: ADSM: Dist Stor Manager [mailto:ADSM-L (AT) VM (DOT) MARIST.EDU] Behalf
Andrew Raibeck
Sent: woensdag 3 januari 2007 19:10
To: ADSM-L (AT) VM (DOT) MARIST.EDU
Subject: Re: Resetting Passwords on Clients
Some things that can cause the encrypted password to "break":
- Switching between CLUSTERNDE N and CLUSTERNDE YES (password
encryption based on host or cluster name, depending on CLUSTERNDE
value).
- If the host or cluster name changes (password encryption based on host
or cluster name, depending on CLUSTERNDE value).
- If the password is changed by means external to PASSWRDACCESS
GENERATE functionality. For example, if you use UPDATE NDE to change
the password, or you connect with that node name from a different
machine, and subsequently change the password.
- Using the same node name to connecting to two different TSM servers
that have the same TSM server name but different node passwords.
There are other trivial cases, too, such as changing NDENAME in dsm.opt
file to a node whose password has not already been encrypted.
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 (DOT) ibm.com
IBM Tivoli Storage Manager support web page:
ager.html
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L (AT) VM (DOT) MARIST.EDUwrote on 01/03/2007
10:29:53 AM:
Hi,
I don't know the reason why (it is at least a bit annoying) this
happens, but changing to using the CAD to manage the scheduler service
help me to reduce the number of failed schedules because of this
problem.
Regards,
Karel
Message
From: ADSM: Dist Stor Manager [mailto:ADSM-L (AT) VM (DOT) MARIST.EDU] Behalf
Dennis, Melburn IT7
Sent: woensdag 3 januari 2007 17:55
To: ADSM-L (AT) VM (DOT) MARIST.EDU
Subject: Resetting Passwords on Clients
It seems that the biggest reason that I get reports of nodes missing
their schedules is because the scheduling services have stopped due to
passwords no longer syncing up. To remedy this I usually have to
reset the password, and this corrects this issue. Is there any rhyme
or reason as to why this occurs. This happens on both UNIX and
Windows clients.
--
Mel Dennis
Backup Systems Engineer
Siemens Business Services
4400 Alafaya Trail
, FL 32826
MC Q1-108
Tel: (407) 736-2360
Win: 439-2360
Fax: (407) 243-0260
Email: melburn.dennis (AT) siemens (DOT) com
[attachment "disclaimer.txt" deleted by Andrew Raibeck/Tucson/IBM]
[attachment "disclaimer.txt" deleted by Andrew Raibeck/Tucson/IBM]

Jan 3, 2007, at 3:11 PM, Andrew Raibeck wrote:

Hi Karel,

Are you saying that the password expires DURING a scheduled
operation, and
the operation subsequently fails? If so, and assuming that you are
running
a supported TSM configuration, you should open a ticket with IBM
support,
as this does not seem right to me (be sure to provide detailed
recreate
scenario in order to facilitate a complete understanding of the
problem).

Just to add a bit: Whereas this problem is said to manifest itself
on Unix, it would be trivial to construct a small monitor to examine
the TSM password file attributes every second or so during TSM
operations and then log and alarm when there is any change to that
file. The timestamp on the event could then be correlated with a
position in the scheduler log, and possibly dsmerror.log; and I would
also look at the Unix process accounting records to see if any rogue
action was afoot at that time.

Richard Sims