> how many files/objects did it move from that tape? Every move implies a
> database update, so lots of objs or a busy Db can slow down the process.
> Perhaps ...

Also, check your actlog when the tape was mounted to see if it's VCR was
invalid, and if rebuilding it failed.  If so, this would slow down access
to the data.  A "q vol nnnnnn f=d" should also show if the tape had
previous read or write errors.


> > Hello,
> >
> > our 3590 tape units were upgraded from 3590B1A to 3590E1A.
> > Before using the 3590E Units, all tapes written by 3590Bs
> > got access mode readonly.
> > Now we try to get rid of our "old" taoes by move data
> > from storage pool on tape to storage pool on disk.
> > Normally, a move date (for a tape in an archive storage pool,
> > est. capacity = 14000MByte, pct. util = 100.0%) takes about 20 minutes.
> > Now we have one tape (same storage pool,
> > est. capacity = 13500 MByte, pct. util = 67.9%) that took more then 11
> hours
> > for move data.
> > I cannot see any reason for this strange behaviour;
> > other move datas from the same 3590 Unit take "normal" times.
> >
> > Any ideas?
> >
> > With kind regards / Mit freundlichen Gruessen
> > Eckhard Trinkaus
> >
> > ************************************************
> > Eckhard Trinkaus
> > Hochschulrechenzentrum der Philipps-Universitaet
> > Hans-Meerwein-Strasse D35032 Marburg/Lahn
> > Bundesrepublik Deutschland
> > Tel.:  +49 6421 2821554 / Fax: +49 6421 2826994
> > Email: trinkaus AT hrz.uni-marburg DOT de
> > ************************************************
>
>


Steve Roder, University at Buffalo
VM Systems Programmer
UNIX Systems Administrator (Solaris and AIX)
ADSM Administrator
(tkssteve AT buffalo DOT edu | (716)645-3564 | 
http://ubvm.cc.buffalo.edu/~tkssteve)