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.ibm DOT com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.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.MARIST DOT EDU> wrote 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
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Andrew Raibeck
> Sent: woensdag 3 januari 2007 19:10
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Resetting Passwords on Clients
>
> Some things that can cause the encrypted password to "break":
>
> - Switching between CLUSTERNODE NO and CLUSTERNODE YES (password
> encryption based on host or cluster name, depending on CLUSTERNODE
> value).
>
> - If the host or cluster name changes (password encryption based on host
> or cluster name, depending on CLUSTERNODE value).
>
> - If the password is changed by means external to PASSWORDACCESS
> GENERATE functionality. For example, if you use UPDATE NODE 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 NODENAME 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.ibm DOT com
>
> IBM Tivoli Storage Manager support web page:
> http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageMan
> 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.MARIST DOT EDU> wrote 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
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> > Of Dennis, Melburn IT7
> > Sent: woensdag 3 januari 2007 17:55
> > To: ADSM-L AT VM.MARIST DOT 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
> > Orlando, 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]