Yep - 100+ scratch tapes in both tape libraries. As I mentioned, there is no sign of any attempt to mount a tape and all drives were available at that time.
On Tue, Jul 18, 2017 at 11:29 AM, Richard Cowen <rco...@cppassociates.com> wrote: > Do you have lib volumes available (scratch/empty)? > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Zoltan Forray > Sent: Tuesday, July 18, 2017 11:24 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] No space available in storage pool failure but there > is plenty of space > > I already considered that. The tape pool is defined at 1500-scratch and > only 920-are used: > > 11:22:33 AM PROCESSOR : show sspool > -> Pool ARCHIVEPOOL(2): Strategy=10, ClassId=0, ClassName=DISK, > Next=6, ReclaimPool=0, HighMig=90, LowMig=70, MigProcess=1, > Access=0, > MaxSize=0, Cache=0, Collocate=0, Reclaim=60, MaxScratch=0, > ReuseDelay=0, crcData=False, verifyData=True, > ReclaimProcess=1, OffsiteReclaimLimit=NoLimit, ReclamationType=0 > Index=0, OpenCount=0, CreatePending=False, DeletePending=False > CopyPoolCount=0, CopyPoolIdList=, CopyContinue=Yes > deduplicate=False, identifyProcess=1 > Shreddable=False, shredCount=0 > AutoCopy=Client, Encrypted=0, Compression=0 > DS Extension: VolListSize=16, VolCount=1, VolLast=0 > -> Pool BACKUPPOOL(1): Strategy=10, ClassId=0, ClassName=DISK, > Next=6, ReclaimPool=0, HighMig=95, LowMig=90, MigProcess=2, > Access=0, > MaxSize=0, Cache=0, Collocate=0, Reclaim=60, MaxScratch=0, > ReuseDelay=0, crcData=False, verifyData=True, > ReclaimProcess=1, OffsiteReclaimLimit=NoLimit, ReclamationType=0 > Index=1, OpenCount=0, CreatePending=False, DeletePending=False > CopyPoolCount=0, CopyPoolIdList=, CopyContinue=Yes > deduplicate=False, identifyProcess=1 > Shreddable=False, shredCount=0 > AutoCopy=Client, Encrypted=0, Compression=0 > DS Extension: VolListSize=24, VolCount=18, VolLast=2 > -> Pool COPYPOOL-OFFSITE(-2): Strategy=30, ClassId=4, > ClassName=IBM3494-SUN, > Next=0, ReclaimPool=0, HighMig=90, LowMig=70, MigProcess=1, > Access=0, > MaxSize=0, Cache=0, Collocate=0, Reclaim=66, MaxScratch=1500, > ReuseDelay=0, crcData=False, verifyData=True, > ReclaimProcess=1, OffsiteReclaimLimit=NoLimit, ReclamationType=0 > Index=2, OpenCount=0, CreatePending=False, DeletePending=False > CopyPoolCount=0, CopyPoolIdList=, CopyContinue=Yes > deduplicate=False, identifyProcess=0 > Shreddable=False, shredCount=0 > AutoCopy=Client, Encrypted=0, Compression=0 > AS Extension: NumDefVols=770, NumEmptyVols=0, > NumScratchVols=770, NumRsvdScratch=0 > -> Pool PRIMARY-ONSITE(6): Strategy=30, ClassId=3, ClassName=IBM3494, > Next=0, ReclaimPool=0, HighMig=90, LowMig=70, MigProcess=1, > Access=0, > MaxSize=0, Cache=0, Collocate=0, Reclaim=63, MaxScratch=1500, > ReuseDelay=0, crcData=False, verifyData=True, > ReclaimProcess=1, OffsiteReclaimLimit=NoLimit, ReclamationType=0 > Index=3, OpenCount=0, CreatePending=False, DeletePending=False > CopyPoolCount=0, CopyPoolIdList=, CopyContinue=Yes > deduplicate=False, identifyProcess=1 > Shreddable=False, shredCount=0 > AutoCopy=Client, Encrypted=0, Compression=0 > AS Extension: NumDefVols=920, NumEmptyVols=0, > NumScratchVols=920, NumRsvdScratch=0 > > > On Tue, Jul 18, 2017 at 11:11 AM, Loon, Eric van (ITOPT3) - KLM < > eric-van.l...@klm.com> wrote: > > > Hi Zoltan! > > Try this one: issue a "show sspool" command. If the sum of > > NumScratchVols and NumRsvdScratch equals your total amount of scratch > > tapes, you're probably hit by this APAR: > > http://www-01.ibm.com/support/ > > docview.wss?uid=swg1IC77685 > > I have bine there, either raise your maxscratch value or bounce the > > server to reset the NumRsvdScratch value. Although the APAR is old and > > states it's fixed in 6.2, I still get hit by it on my 6.3 servers. I > > raised the maxscratch to 100,000 to get rid of it. These reserved > > scratches are (in my > > case) mainly caused by failed storage agent scratch mounts. > > Kind regards, > > Eric van Loon > > Air France/KLM Storage Engineering > > > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > > Of Zoltan Forray > > Sent: dinsdag 18 juli 2017 14:49 > > To: ADSM-L@VM.MARIST.EDU > > Subject: No space available in storage pool failure but there is > > plenty of space > > > > TSM Linux server 7.1.6.3. Client is Linux 7.1.6.4. > > > > This morning at 6am is the second time I have had this "failure" when > > it isn't true. > > > > ANR0522W Transaction failed for session 19482 for node > > VCU-GS1.CHPC.VCU.EDU (Linux x86-64) - no space available in storage > > pool BACKUPPOOL and all successor pools. > > > > But it isn't true. The BACKUPPOOL pool is only 92% used (of 9TB) and > > the hi/low triggers are 95/90. I checked activity logs and there > > haven't been any recent migrations. > > > > The NEXTPOOL is tape and all 9-drives are free and the MAXSCRATCH > > count hasn't been hit. > > > > The backup only transferred 60GB (of 108TB examined) before dying due > > to this erroneous error. > > > > No other errors in the activity log. So, what gives? > > > > -- > > *Zoltan Forray* > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon > > Monitor Administrator VMware Administrator Virginia Commonwealth > > University UCC/Office of Technology Services www.ucc.vcu.edu > > zfor...@vcu.edu - > > 804-828-4807 Don't be a phishing victim - VCU and other reputable > > organizations will never use email to request that you reply with your > > password, social security number or confidential personal information. > > For more details visit http://infosecurity.vcu.edu/phishing.html > > ******************************************************** > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee only. > > If you are not the addressee, you are notified that no part of the > > e-mail or any attachment may be disclosed, copied or distributed, and > > that any other action related to this e-mail or attachment is strictly > > prohibited, and may be unlawful. If you have received this e-mail by > > error, please notify the sender immediately by return e-mail, and delete > this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > > its employees shall not be liable for the incorrect or incomplete > > transmission of this e-mail or any attachments, nor responsible for any > delay in receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > Dutch > > Airlines) is registered in Amstelveen, The Netherlands, with > > registered number 33014286 > > ******************************************************** > > > > > > -- > *Zoltan Forray* > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon > Monitor Administrator VMware Administrator Virginia Commonwealth University > UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - > 804-828-4807 Don't be a phishing victim - VCU and other reputable > organizations will never use email to request that you reply with your > password, social security number or confidential personal information. For > more details visit http://infosecurity.vcu.edu/phishing.html > > > This email has been scanned by BullGuard antivirus protection. > For more info visit www.bullguard.com > > -- *Zoltan Forray* Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor Administrator VMware Administrator Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html