Info below is from observation and working with the stuff. A developers
input would be appreciated so we can work out a way to do this or whatever
the problem our colleague here has.

On UNIX platforms its some arbitrary machine dependant data which is used to
encrypt the password locally when using passwordaccess generate. There is
absolutely no problem in IP addresses changing as this is a technique used
in multihomed cluster nodes - its the fact its on a physically different box
from when the password was encrypted that causes the problem.

Neither the client nor the server code notices the IP address change as ADSM
is (mostly) independant of the underlying network protocol (exception is
schedmode prompted which only works on IP).

What actually happens is the client goes to use whatever the machine
dependant data is and tries to use the encrypted password it has with this
data. When it notices it can't use the password with this data the client
code deletes the file containing the (in its opinion) badly encrypted
password.

Because the developers still haven't given us the equivalent of
clusternode=yes on UNIX clients (yes its only available on NT) we have to
resort to using mailprog scripts to trap the plain text version of the
generated password and feding this into dsmc set password each time the
machine boots/HA software starts up. Please give us something a little more
usable and take this requirement into account if doing something special for
DHCP - its the same underlying issue.

Regards
Alan
[snip]
> > Is the client password really dependent on IP-address,
> > or is it the server noting a different IP-address and
> > saying "Hey, that's strange - better ask for a password" ?
>
> The server is noting that the node has changed IP-address
> and asks for the password. This is done so you can restore
> your backups to a different machine, when a client machine
> has broken down due to faulty hardware (for example).
>
> For DHCP, I think you have to think of something to work
> with this -- such as giving all users passwords.
> A more sophisticated solution would be writing an automated bot
> that contacts the clients by ipname (rather than numeric ipaddress)
> and then initiate a 'manual' backup. On Linux, you could
> 'enter' the node password using an `expect` script.
>