Yes, If you have some "Filling"/"Empty" volumes that are NOT "Read-Write", then TSM will attempt to get one that is read-write, or attempt to get a scratch volume if there are none. Then if your MAXSCR is less than or equal to the number of scratch volumes used, you'll get a server out of storage space.
...deon --- Have you looked at the A/NZ Tivoli User Group website? http://www.tuganz.org Deon George, IBM Tivoli Software Engineer, IBM Australia Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816, IVPN +70 66058 mailto:[EMAIL PROTECTED], http://www.ibm.com/tivoli "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> wrote on 15/04/2004 04:59:21 PM: > Thanks deon, > > Could this also happen if the status of the volume is not read/write? > > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > Deon George > Sent: donderdag 15 april 2004 1:43 > To: [EMAIL PROTECTED] > Subject: Re: even/uneven tape cycle / ANR1025W > > Klaas, > > The errors you are getting indicate that the storage pool (or > subordinate > - which is more likely the case). You'll get this because: > > * You dont have enough volumes defined - ie: the volumes defined are > already full, > * You dont have enough scratch volumes define: ie: check the MAXSCR > parameter on q STGP <name> f=d > > ...deon > --- > Have you looked at the A/NZ Tivoli User Group website? > http://www.tuganz.org > > Deon George, IBM Tivoli Software Engineer, IBM Australia > Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816, > IVPN +70 66058 > mailto:[EMAIL PROTECTED], http://www.ibm.com/tivoli > > "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> wrote on 14/04/2004 > 06:56:31 PM: > > > Hi list, > > > > I've got a client who is working with TSM the following way: > > > > They work with an autoloader. > > > > They wanted to have a 2 week tape cycle with even and uneven weeks and > a > > 2 week period for keeping the tapes. > > What I did was create 2 sets of tapes(4 tapes eacht) and 2 > > diskpools(even and uneven) so in week 13 they backup to diskpool > uneven > > and in week 14 they backup to diskpool even. > > During the week migrations to a normal tapepool take place. > > On Monday the tapes will be checked out and they can checkin the other > > set of tapes (depending on week). > > > > For my this is a very unusual way to work with TSM and as they are > > running into some problems I'm not quite sure how to handle this. > > They are getting the following errors: > > > > >ANR0522W Transaction failed for session 10440 for node > > >MERCURIUS (WinNT) - no space available in storagepool > > DISKPOOL_ONEVEN_WEEK >and all successor pools. (SESSION: 10440) > > > > Diskpools get flushed every night so there should be enough space. > > > > > ANR1025W Migration process 424 terminated for storage pool > > > DISKPOOL_ONEVEN_WEEK - insufficient space in subordinate storage > pool. > > > > > (PROCESS: 424) > > > > To me this is strange because the next storage pool is the tape pool > > > > If anyone has worked with an autoloader or worked with a tape cycle > this > > way I would like to hear from them. > > > > Thanks in advance > > > > Regards, > > > > Klaas Talsma > > > > > > > > -- > > Bell Microproducts Europe BV > > > > This message is intended only for the use of the person(s) (\"the > > intended recipient(s)\") to whom it is addressed. It may contain > > information which is privileged and confidential within the meaning > > of applicable law. If you are not the intended recipient, please > > contact the sender as soon as possible. The views expressed in this > > communication may not necessarily be the views held by Bell > > Microproducts Europe BV. > > > -- > Bell Microproducts Europe BV > > This message is intended only for the use of the person(s) (\"the > intended recipient(s)\") to whom it is addressed. It may contain > information which is privileged and confidential within the meaning > of applicable law. If you are not the intended recipient, please > contact the sender as soon as possible. The views expressed in this > communication may not necessarily be the views held by Bell > Microproducts Europe BV.