Edgardo,

maybe I was not clear enough. You still can use second alternative:
1. Store somewhere an older DB backup together with all tapes for this
particular node and forget about them in production TSM server. Restores
for the node can be done from some other TSM server instance (test server,
second instance on production TSM, etc.)
1a. (optional) minimize tape usage - restore DB backup before
"version-upgrade" to test server, mark all volumes read-only, delete all
other nodes and perform reclamation
2. Mark tapes as "unavailable" in production server
3. restore volumes from copypool - other nodes' data is at your hands.

Zlatko Krastev
IT Consultant






Edgardo Moso <edgardo_moso AT KINDREDHEALTHCARE DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
13.10.2002 01:13
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Down Level Client Code


Zlatko,

Thanks for your suggestion.

By the way I can't do your  second  alternative because the Storage pool
is
not collocated. There are other data in the tape.  Although could be done
if we upgrade the TSM server from 4.2 to 5.1 because of move data command.
My only worry is we always have a restore as of now because we are moving
this application to a different apps in the w2k environment.  Your first
is
not applicable.

Yes, that's right.   I used that most of the time  instead of -node option
the -virtualnodename but this is a slip of my fingers.  I was been aware
in
the past but sometimes when there are lot of things going on we commit
error.   Tivoli should have considered human error in the design.

Again, this is greatly appreciated.

Ed




From: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET> on 10/12/2002 04:32 PM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:  Re: Down Level Client Code

Two choices:
- if you do not need many versions of the node's data - simply rename the
node and register new node with same name, perform full backup, delete
renamed node;
- if you need to keep all backup versions or have archives - identify
which tapes contain that node's data, mark them "unavailable" and keep
somewhere with a DB backup before dsmc-query. But when you need to restore
from that data you have to restore the DB in separate instance.
- use both - using second method preserve all data and afterwards using
first method have quick current data restores from main/production TSM
instance.

WARNING: next time use -virtualnodename=<other node> instead of
node=<node> and this would never happen (Mark, this is nearly a FAQ
candidate).

Zlatko Krastev
IT Consultant






Edgardo Moso <edgardo_moso AT KINDREDHEALTHCARE DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
12.10.2002 16:27
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Down Level Client Code


Does any body has a work around with the dwon level client code errror?

Here's what happened:  I have an old ADSM client version 3.1 runnning in
Solaris 2.5. We don't want to upgrade it to a higher level, say TSM
version
4.2.2, because if we upgrade we need to upgrade first the Solaris to a
higher level.   We dont want to do this beause the client box has nothing
on it except the old patience and nurisng data that we would like to
preserve for a period of time.   Basically this server's data are
stagnant,
it would be used for for restore.  Other than this TSM client,  ourTSM
clients had been upgraded to 4.2 and I know Tivoli corrected this bug.
Usually,  when I'd like to verify  query about the  the client nodespecs I
will just use the command in my desktop "dsmc -tcps=server1 -node=node1".
I used this in this node and not knowing with the query command my node
data was changed in the server, it has an error "Down level client code"
when I run any comand in the client box.  For me this is the worst
transition Tivoli had made to a higher TSM client, allowing this command
and not protecting the lower version.  The worst tof all is when I asked
Tivoli support, the Manager himself said, they have no technical solution
to the problem except to upgrade it to the supported level.   I know of
some solution but it's impractical to apply beause for example, I will
resotre the db back, I will sacrifice 99 % of the clients in this TSM
server.  If I used export/import this will take forever because this is
almost 600GB of data.  I consider updating the TSM database but I don't
know how to do it.

Any help will be greatly appreciated.

Thanks.