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.