I recently ran into a problem caused by having some clients at the V1 level
and others at the V2 level.

As most of you probably know, once you start using the V2 client code for
a node, that node can no longer use the V1 client. In other words, it's a
one-way trip.

The danger is in what constitutes "using the V2 client code". In this case,
"using the V2 client code" means even *attempting* to log on to the
server.

Example: suppose you have two nodes, NODE6 and NODE7. NODE6 is running the
V1 code and NODE7 is running the V2 code. Now suppose that the person who
owns NODE7 tries to establish a session with the ADSM server as follows:

     DSMC -NODENAME=NODE6

The server prompts him for the password, and he gets an authentication
error.

Oooooops!!!!!!! He *meant* to type this:

     DSMC -NODENAME=NODE7

Okay, now the server prompts him for the password, and he logs in success-
fully.

Now the user who owns NODE6 tries to log on to the ADSM server. Instead
of getting on, he gets a message telling him he can't establish a session
because he's at a down-level version of the client code!

Bottom line: even if you never successfully establish a session with ADSM,
you're upgraded!

Oh, this goes for applications that use the API, too (like SQL-Backtrack).
The first time you connect to the server with the new API, even if you
don't back anything up, you can't go back to V1.

I've opened a PMR on this and hopefully IBM will see they need to change
how this works. In my opinion, the point of no return should be the first
time you store data on the server (backup or archive), not the first time
you connect (or even *try* to connect!).

This hasn't caused us any major headaches, as the solution is simply to
upgrade the client code, which works great!

(I wonder.....I might be able to use this technique to force people to
upgrade who've otherwise not made the time to do so !!!!!)      :)

Andy Raibeck
Connecticut Mutual
203-987-3521