Thanks. I see that this was supposed to be corrected in 7.1.3 which is the version we are running. I hope IBM fixes this. Can't really say that setting all our copy volumes offsite for every restore is an acceptable workaround. Us who administer the servers have no control of who might initiate a restore.
Hans Chr. On Thu, Mar 17, 2016 at 9:23 PM, Gee, Norman <norman....@lc.ca.gov> wrote: > I ran into this many times, the only way I found that would speed it up > after the fact is to increase the mount retention time on the tape device > class. > To avoid this I had to keep my copy pools in offsite status. > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Hans Christian Riksheim > Sent: Thursday, March 17, 2016 1:04 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Restore using copypool volumes > > Just noticed that some restores are using copypool volumes. No primary > volumes are in disorder and there is nothing in the actlog indicating why a > tape from the copypool is chosen. > > I vaguely rememeber that this was a problem for early 7.1-versions of the > server. We are running 7.1.3.1. > > There is a queue of sessions requesting tapes from the primary pools but if > it is a "feature" to lessen the burden on our libraries I would like to be > in control. > > Is this a known problem for this version or should i PMR? > > Regards, > > Hans Chr. >
