> So I guess the workaround is to remark out the
> PASSWORDACCESS line during the restoration
> process.

Yes, or else simply use VIRTUALNODENAME instead of NODENAME. You can
either put it in the options file or invoke it from the command line:

dsmc -virtualnodename=sourcenode
dsm -virtualnodename=sourcenode

Then you don't have to mess around with the options file at all.

Best regards,

Andy

Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
e-mail: araibeck AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.





Mark Stapleton <stapleto AT BERBEE DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08/11/2001 23:10
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: restore/retrieve in different server ** HELP **



>Mark Stapleton <stapleto AT BERBEE DOT COM> wrote:
>>The simplest way to do this is to do it from the command line:
>>
>>1. Edit the dsm.opt file on the target server. Comment out the
>>NODENAME line with an asterisk. Add the line
>>        nodename <name_of_source_client_box>
>>
>>2. Run DSMC. Enter the command:
>>        tsm> restore <drive>:\<desired_directory_tree>\<desired_file>
>>
>>Easy as can be. The most important thing to remember is not to have
>>the machines using the same nodename contacting the TSM server at the
>>same time.

On Sat, 11 Aug 2001 10:17:35 -0700, Andy Raibeck wrote:
>There is a "gotcha" with using NODENAME, in that if the target machine
has
>PASSWORDACCESS GENERATE in the options file (which is very likely), then
>when you enter your source node's password, it will be encrypted and
>stored on the target machine. Thus anyone else can subsequently access
>your node's data, presenting a potential security issue. Unless that is
>your intent, use VIRTUALNODENAME instead of NODENAME. The difference is
>that when you enter your password, it won't be stored on the target
>machine, regardless of whether PASSWORDACCESS GENERATE is in effect.

So I guess the workaround is to remark out the PASSWORDACCESS line
during the restoration process.

--
Mark Stapleton (stapleton AT berbee DOT com)
Mark Stapleton (stapleton AT berbee DOT com)