ADSM-L

Re: [ADSM-L] ANR1025W Migration process 3433 terminated for storage pool BACKUPPOOL - insufficient space in subordinate storage pool.(PROCESS: 3433)

2007-04-18 10:58:20
Subject: Re: [ADSM-L] ANR1025W Migration process 3433 terminated for storage pool BACKUPPOOL - insufficient space in subordinate storage pool.(PROCESS: 3433)
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 18 Apr 2007 10:57:49 -0400
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