hi, thanks for input, some answers ...

- no, no one changed the PASSWORDDIR client option, in fact i had it
only in four dsm.sys stanzas

- for HP-UX TSM.PWD location is /etc/adsm , unfortunately i generated
the passwords again as soon as possible since my arch logs backups
where failing so my time stamps are fresh

- about evidence, absolutely none whatsoever was found, i digged the
whole actlog in that period which is from 9:00 till 16:32 as noticed
in dsmsched logs

- there is no way to change the identity of the client, only i can do that :-)

- what i noticed is that unfortunately it happened on other server as
well, actually we are talking here about 4 node HP-UX cluster with
oracle databases, my scrips checks which DB is on what node and
starts,stops, kills appropriate dsmcad process

- so, it happened only on 2 servers, im 95% sure ... checking further

thanks again


On 5/17/07, Richard Sims <rbs AT bu DOT edu> wrote:

On May 17, 2007, at 3:45 AM, goc wrote:

> hi, now thats interesting ...
> last night all backups from one of our servers went MISSED
> because the GENERATED passwords got lost somewhere,
> the passwords were not changed, the password "retention" is
> set to 9999 days, PASSWORDACCESS 100% on GENERATE
> ... so i really don't know what happened ...

You don't say what investigation you've done to pursue this.

Did anyone introduce or change the PASSWORDDIR client option?
If no PASSWORDDIR option in effect, is there a TSM.PWD file
in directory /etc/security/adsm/, the default location for the
password file?  If not, the mtime timestamp on the directory
will show when the contents of the directory changed and thus
narrow down whatever event occurred.  (Did some ambitious
system administrator do file system housekeeping?)
Is there a TSM.PWD file there, but zero length?  That would
suggest that an attempt was made to change the password at a
time when the file system was full.
In poring over the client schedule and error logs, and TSM
server Activity Log, do you find any evidence of a problem?
Is there in any way a change to the identity of the client,
in OS or TSM terms, such that that identity is inconsistent
with the nodename in the TSM password file?

    Richard Sims