>We believe that a client node naming convention will be necessary in
>order to manage this environment.  Based on experience can anyone tell
>me if there are definite benefits to having this naming convention or if
>there were management problems encountered because one wasn't in place?
>We have had some resistance from our pilot clients in this area and want
>to make sure that there are good reasons for having one.

>The convention we are looking at denotes Business Unit, city, platform
>and target ADSM server.

I think that naming conventions are a good idea. But you might consider
using an attribute that is less likely to change for the node name, like
an employee ID number, for instance. The attributes that might be more
subject to change, like business unit names (these might change when you
go through a re-org), cities (if the department moves), etc., might be
better placed in the CONTACT field of the node definition. For example:

   REG N 208165 <password> CON="<unit>/<city>/<building>/<floor>/<phone>"

Note the use of the '/' to delimit the fields within the CONTACT info.
Any delimiter will do... it isn't necessary, but you might find it
helpful in the future if you ever want to write (for example) a Rexx
utility to extract information about your ADSM users.

Hope this helps give you some ideas.

Andy Raibeck
ADSM Level 2 Support