I have a strange problem; or perhaps it is a feature? I'm not sure, but it looks as a problem. This is the setup: An HP-UX server with several DB2 instances, all version 8.1. Users need to be able to switch between instances, which they do by setting DB2INSTANCE as well as the PATH and library path; but for some reason this doesn't seem to work quite as expected, especially for two instances, db2i81 and db2i81p. These are the symptoms:

set env for db2i81 and run:
$ db2 get dbm cfg | grep -i svce
TCP/IP Service name (SVCENAME) = db2i81

set env for db2i81p and run:
db2 get dbm cfg | grep -i svce
TCP/IP Service name (SVCENAME) = db2i81

- but if I first set the environment for db2i81p and then for db2i81, SVCENAME will come back as db2i81p. What is happening here?

In the user profile file (not sure what it is called in HP-UX but it is .profile in Linux) for instance owner, there are some commands added by DB2 to initialize the environment so that the user id points to the correct DB2 instance. It would probably be best to look at those commands and use them for any other users that want to point to another instance.

It is a bad idea to re-use the profile of another user. there can be settings in this profile that are not needed or specific for this user
always create a client instance and catalog the local instances/node and databases and use your own profile

What you are saying is true - and it is what I do, more or less; only I have wrapped it in a shell function with a menu interface that lets the user set the environment for Oracle, Informix and Sybase as well (we develop SW that talks to all of those).

The thing is - this problem doesn't seem to occur on the other platforms (AIX, SunOS, Linux). I have compared the whole environment in the situation described (first set the env for db2i81, then db2i81p, compared to just setting db2i81p) - and there is no difference at all. But the SVCENAME is different in the two situations.

Actually, I would source the sqllib/db2profile of the respective instance. Then you only pick up the DB2-related changes and not what any other user may do in his/her ~/.profile.

SVCENAME is only a mapping between a symbolic name and /etc/services
to define a port on which the instance is listening for external connections
each instance has his own entry in this file

Try issuing "db2 terminate" after you change the shell environment. Catalog and connection information may be cached and won't take effect immediately.

That's not quite correct. SVCENAME identifies the port already. The identifier may be a symbolic name or a numeric value. If it is a numeric value, then it is the port number (not a mapping). The symbolic name is mapped to a port number using /etc/services, however.