On Apr 18, 2007, at 10:26 AM, David Browne wrote:
Maximum Scratch Volumes Allowed: 250 Number of Scratch Volumes Used: 182
David - We lack the context of what was going on in the server when the error appeared, or whether the operation was reattempted and consistently failed each time. It may be that the conditions described in APAR IC52341 were in force. Also, while the numbers you cite above make it appear that there is a 68 tape margin, the MAXSCRatch value is usually an arbitrary number, and so the perceived margin may not actually exist in the library, relative to its libvolumes complement. Whereas you are using node collocation, the rules as listed under "How the Server Selects Volumes with Collocation Enabled" in the Admin Guide manual apply; and whereas you have lots of volumes in Filling state and low utilization, then TSM should have been able to continue writing without such an error condition. So something else is going on that needs investigation, where some answers may be found by poring over the Activity Log. One seemingly obvious thing you should verify is that BACKUPPOOL actually does point to TAPEPOOL1 as its next storage pool. (It sure would be nice if the TSM error message said what pool was in issue.) Richard Sims
