Hi Miles,
My sympathies - this error can drive you around the bend, as it did me last
week.
The first thing to check is your tape drives - the whole problem that I was
encountering was related to TSM believing a tape drive was available when
in fact it wasn't. When TSM fails to mount a tape in the drive that it
thinks should be available it didn't quite know what to do, instead of
taking the drive offline, as it normally would. You'll probably have seen
the following in your server activity log:
ANR1410W Mount request denied for volume xxxxxx - mount failed.
ANR8447E No drives are currently available in library xxATL1.
ANR0525W Transaction failed for session x for node x - storage media
inaccessible.
In isolation this may not appear too bad, but if you have several sessions
queuing or in media wait, then all of the sessions fail with this error,
quitting along the lines of no drives being available in the ATL. Which is
most annoying and frustrating when you are sitting there and you can see
several of your drives available and idle.
As I said, the whole problem in our environment was related to a single
drive getting utterly confused as to whether it had a tape mounted or not -
this was then followed by TSM trying to mount the current 'Filling' tape,
one which our 3494 had dropped and had 'lost' somehow (I'm not sure the CE
put it back into the 'emergency slot'...) and TSM getting even more
confused when it couldn't mount it.
I would suggest resolving this situation by:
o) getting TSM to unmount all of the drives it thinks have a tape mounted,
and manually unloading any others (and as necessary, in a 3494 that is,
make sure you put the tape back in the emergency slot),
o) performing an audit of the library,
o) remove and re-introduce the tape drives at AIX level (i.e. lsdev -Cc
tape, rmdev -dl rmt0, rmt1 etc. then run cfgmgr to make sure they all come
back),
o) stop starting the /etc/lmcpd daemon,
o) remove and re-add the drives at TSM level, by which time your library
may have finished its audit.
o) Now try it, and keep an eye on the TSM server's activity log for any of
those messages above.
This worked for me, thankfully.
Can anyone perhaps add any more of an explanation to this?
Rgds,
David McClelland
---------------------------
Tivoli Storage Management Team
Tivoli Storage Management Team
IBM EMEA Technical Centre,
Internet: davidmcclelland AT uk.ibm DOT com
Miles Purdy <PURDYM AT FIPD.GC DOT CA>@VM.MARIST.EDU> on 05-11-2001 14:09:45
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: ANS1312E
Hi folks,
AIX Server 4.1.3
AIX client 4.1.3
Error: ANS1312E (on the client)
Yesterday morning I started getting client error ANS1312E. One of my
filesystems fails to backup with "Server media mount not possible". The
error manual was completely useless. What does this error mean?
This is my only filesystem that fails to backup. The MC is:
tsm: UNXR>q COPYGROUP NISA_DOM ACTIVE DATABASE_ONSITE STANDARD f=d
Policy Domain Name: NISA_DOM
Policy Set Name: ACTIVE
Mgmt Class Name: DATABASE_ONSITE
Copy Group Name: STANDARD
Copy Group Type: Backup
Versions Data Exists: No Limit
Versions Data Deleted: No Limit
Retain Extra Versions: 3
Retain Only Version: 3
Copy Mode: Modified
Copy Serialization: Shared Static
Copy Frequency: 0
Copy Destination: ONSITE_ONLY
Last Update by (administrator): PURDYM
Last Update Date/Time: 06/04/01 14:57:04
Managing profile:
This MC goes straight to tape, which I think is related to the problem.
tsm: UNXR>q STGPOOL ONSITE_ONLY f=d
Storage Pool Name: ONSITE_ONLY
Storage Pool Type: Primary
Device Class Name: 3570
Estimated Capacity (MB): 6 097 510.3
Pct Util: 3.5
Pct Migr: 4.2
Pct Logical: 100.0
High Mig Pct: 90
Low Mig Pct: 70
Migration Delay: 0
Migration Continue: Yes
Migration Processes:
Next Storage Pool:
Reclaim Storage Pool:
Maximum Size Threshold: No Limit
Access: Read/Write
Description: Stores data onsite only
Overflow Location:
Cache Migrated Files?:
Collocate?: Filespace
Reclamation Threshold: 99
Maximum Scratch Volumes Allowed: 500
Delay Period for Volume Reuse: 1 Day(s)
Migration in Progress?: No
Amount Migrated (MB): 0.00
Elapsed Migration Time (seconds): 0
Reclamation in Progress?: No
Volume Being Migrated/Reclaimed:
Last Update by (administrator): PURDYM
Last Update Date/Time: 11/04/01 14:00:28
Thanks Miles
-------------------------------------------------------------------------------------------
Miles Purdy
Miles Purdy
System Manager
Farm Income Programs Directorate
Winnipeg, MB, CA
purdym AT fipd.gc DOT ca
ph: (204) 984-1602 fax: (204) 983-7557
-------------------------------------------------------------------------------------------
=========================================================================
|
