This may be a server bug that is fixed in 3.1.2.30 & 40.
We needed to do a full point in time restore of a filesystem on a digital unix
box.
The user wanted to use the gui and got the dreaded 'preparing' also.
The session eventually timed out after 60 minutes of inactivity.
I knew about this bug already and had been waiting eagerly for the fix in 2.30.
But 2.30 arrived with a serious expiration bug. Anyway, I put 2.30 on
despite the expiration bug, restarted the server and the restore. It
immediately said 'waiting for files' and started sending files within a minute.
The bug was in the no query restore code. you can either move up to 3.1.2.40
or disable NQR by doing an ordinary restore with 'show active and inactive'.
I don't remember the apar number, but you can see it in the anr3310 readme
if you receive the 3.1.2.40 ptfs.
--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <H000132102efebf5@MHS>, on 09/27/99
In <H000132102efebf5@MHS>, on 09/27/99
at 04:40 PM, Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU> said:
>My site has a 3.1.2.20 server running under MVS. Recently the system
>administrator for a Solaris client system needed to restore some files. He
>started up the GUI, requested a point in time restore of a single file,
>selected a restore location different from the original location, and told the
>GUI to proceed with the restore. The GUI status indicator showed the dreaded
>"Preparing..." status for minutes on end before we gave up and used the
>command line interface. As noted above, he was only trying to restore one
>file. There were eight versions of the file stored on the ADSM server. A
>'query node' command reports a Solaris level of 5.6 and an ADSM client level
>of 3.1.0.6. Does anyone have any ideas for getting acceptable performance from
>the GUI client in this environment?
>I am well aware that the GUI client has crippling performance problems when
>asked to restore large numbers of files, but I thought it worked reasonably
>well with small numbers of files. It now appears that even that is doubtful.
>More and more, the GUI client looks like a toy that has no place in any
>serious data protection plan.
|
