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 <[EMAIL PROTECTED]> on 10/12/2002 04:32 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 12.10.2002 16:27 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] 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.