Re: Scheduled Service Password when using TSM and TDP/SQL

Jeff,

This should not be a problem.

If you are using a different NODENAME for DP for SQL
and the BA client (recommended), they will be maintained
and updated separately.

If you are using the same NODENAME for DP for SQL
and the TSM BA client, the password is stored (and retrieved)
from the same location in the registry, so they will
not get mixed up. The only possible way this could be causing
a problem is if you are running DP for SQL OR the BA client
as a clustered node (CLUSTERNODE YES in the DSM.OPT file)
AND you are using the same NODENAME for both.
If you are doing that, the passwords are encypted using
a different method and could be getting out of sync.
If you are running one of them in a clustered configuration,
you should use different NODENAMEs for them.

Thanks,

Del

----------------------------------------------------

Hi there,

This is something Del Hoobler can answer, i hope.

I have a TSM 5.1.5.0 client running on NT, which backs up daily to our TSM
server (v5.1.5.2, running on Z/os mainframe) via a scheduled service. When
i register the scheduled service, i supply the password as defined by the
server. In the DSM.OPT, i have PASSWORDACCESS GENERATE defined. The
password is then stored in the NT Registry. The password expiry is set at
30 days in the server.

I have TSM for SQL version 2.2.1installed on the same NT box. Again, i have
scheduled services defined for this, where again i supply a password when i
install the service via DSMCUTIL.

My question (or problem!); What should i do with the passwords? If i have
the TSM client as PASSWORD1 and the SQL client as PASSWORD2, does'nt that
get updated in the same NT registry? When the password changes after the 30
day period, will the TSM client find a password mismatch in the registry.
Alternatively, if the passwords are the same, what happens when the first
one changes the password. Will the second one stop working?

The reason i ask this is because somehow, the passwords between the TSM and
SQL clients appear to be getting out of step and i get 137 authentication
messages in the dsmerror.log. I know that this requires a password reset,
so i do just that. But i seem to get the problem again later in the month.

I also run Lotus Notes, Oracle  and UDB7 agents, but i don't get this
password problem.