ADSM-L

Re: DB Restore Using Server To Server Virtual Volume Failing

2003-07-01 13:55:04
Subject: Re: DB Restore Using Server To Server Virtual Volume Failing
From: Allen Barth <allen.barth AT DB DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 1 Jul 2003 12:51:59 -0500
FWIW, Another important bit is server versions.  I've experienced the same
sort of thing when server versions where different, especially when the
target server was at a lower release.  An upgrade of the target server
removed my errors.

Al Barth




Richard Sims <rbs AT BU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/29/03 07:24 AM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: DB Restore Using Server To Server Virtual Volume 
Failing


...
>ANR9999D pvrserv.c(661): ThreadId<43> Error positioning SERVER volume
>         TSM_DCA.DBB.056841428 to 1:0.
>ANR9999D icrest.c(2076): ThreadId<0> Rc=30 reading header record.
...

Robin - It sounds like your test system dsmserv is trying to find its way
        in the virtual volume, but can't quite recognize header records.
I would double-check that the timestamps and size of the test system
dsmserv module show it to actually be at least the same level as the one
on the system which created the virtual volume, reasoning that a lower
level might not be able to deal with what was written by a higher level.
As an experiment you might try copying over the dsmserv from the
originating system and trying that.  If still nadda, you might wonder
about the integrity of the virtual volumes.

  Just some ideas,  Richard Sims, BU

<Prev in Thread] Current Thread [Next in Thread>