We do multiple sessions. Back when we started, ADSM (or the API code - never
tracked it down) considered each network interface as having a seperate
password, even though the host name was the same and the ADSM node name was
the same.

So I went to a never-expire password on ADSM and used backint -f password to
store it in the .bki. We actually use the same password for multiple nodes -
in our environment we don't need to worry about someone getting to things
they shouldn't this way. The other way of handling this would be have
different server-name clauses for the different environments; the passwords
in the .bki tie to server-name.

We starrted doing the copies before SAP, Oracle, or backint supported the
process, so our technique is slightly different from the install guide. In
essence, when we do a PRD (production) to TST (q/a) copy, we set the TST
system up with PRD mount points (unmount/remount the file systems), plug in
the proper nodename in the dsm.sys file, and change /etc/passwd so the
oracle user is oraprd and not oratst. Then SAP, Oracle, and TSM all think
we're restoring the PRD backup onto the PRD system.

We do this about 8 times per year with no real problems so far.

Tom Kauffman
NIBCO, Inc

> -----Original Message-----
> From: Seay, Paul [mailto:seay_pd AT NAPTHEON DOT COM]
> Sent: Tuesday, November 27, 2001 11:47 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: TDP for SAP R/3 Restores to Different System/SID
>
>
> I have read the documentation on this in the Installation
> Guide and still
> have some issues.  Most notably, changing the password on the
> source server
> is not a good thing when it is a production server TDP SAP
> R/3 node name.
> That can interrupt the production operation (redo logs, etc).
>  The case is
> the restore is going to run for 4 hours because it is a 1.5TB
> database to
> restore.
>
> We like the password generate option for security reasons,
> but recognize
> there are limitations when doing cross system restores of any
> type.  TSM
> backint goes through all these gyrations to provide a feature
> "-f password"
> to store the node password encrypted in the .bki file, yet
> does not have a
> way to handle the problem.
>
> A feature is really needed to be able to not interfere with
> the production
> operation.  We do a lot of restores of production to test.
>
> What is everyone else doing?
>
> Paul D. Seay, Jr.
> Technical Specialist
> Naptheon Inc.
> 757-688-8180
>