Eric,

Just for the record, here is the official documentation from tsm 3.7
chapter 7 (check the manual yourself to see the figures) --

- - begin IBM doc - - -

How the Server Selects Volumes with Collocation Enabled

When collocation at the client node level is enabled for a storage pool
(COLLOCATION=YES) and a client node backs up, archives, or migrates files
to the storage pool, the server attempts to select a volume using the
following selection order:

  1.A volume that already contains files from the same client node
  2.An empty predefined volume
  3.An empty scratch volume
  4.A volume with the most available free space among volumes that already
contain data

When collocation at the file space level is enabled for a storage pool
(COLLOCATION=FILESPACE) and a client node backs up, archives, or migrates
files to the storage pool, the server attempts to select a volume using
the following selection order:

  1.A volume that already contains files from the same file space of that
client node
  2.An empty predefined volume
  3.An empty scratch volume
  4.A volume containing data from the same client node
  5.A volume with the most available free space among volumes that already
contain data

When the server needs to continue to store data on a second volume, it
uses the following selection order to acquire additional space:

  1.An empty predefined volume
  2.An empty scratch volume
  3.A volume with the most available free space among volumes that already
contain data
  4.Any available volume in the storage pool

Through this selection process, the server attempts to provide the best
use of individual volumes while minimizing the mixing of files from
different clients or file spaces on volumes. For example, Figure 19 shows
that volume selection is horizontal, where all available volumes are used
before all available space on each volume is used. A, B, C, and D
represent files from four different client nodes.  - - - end IBM doc - - -

(in the last bullet 4 above, I don't know what volumes are left to fall
into this category;  this may be a documentation error.)
(Oh - I just thought of a category -- pending volumes, but I hope the
server won't take a pending volume before its time is up, that would be a
bug!)

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <59C645F3B051D311A4680000832FE2D401AF14A8@X0F0000>, on 02/17/00
In <59C645F3B051D311A4680000832FE2D401AF14A8@X0F0000>, on 02/17/00
   at 04:08 PM, "Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT NL> said:

>Hi Bill!
>I didn't know that! I thought that ADSM would stop backups when you run
>out of scratches.
>Well, this sure changes things... I was always thinking that counting the
>amount of available scratches was a good way of predicting your ADSM
>library capacity.
>I have to look for another way of calculating ADSM's storage capacity. I
>am using a 3575 with (at this moment) 18 scratches left. So, I thought I
>had 18/320*100=5.6% left. However, I now know that ADSM starts using
>partially filled tapes from other nodes when there are no scratches left.
>I directed the output from the command q volume stgpool=tapepool to a
>text file and I imported that file into Excel. I calculated the average
>tape usage for this storage pool and the answer was 43.3%. So, instead of
>having 5% left I have 43 % left! Right?
>Wow! Guess my boss will be happy to hear this!
>Kindest regards,
>Eric van Loon