Well, that's an issue, but not really a big one for me.

If you have collocation on, and a tape fills up, and there is not a scratch
tape available to the pool, ADSM will abandon collocation and put the data
on a tape in the pool that isn't already 100% full (and yes, I'm still
running V2).  So you have an escape hatch there.

Granted, you do still need to check on your pool occasionally, 'cause you do
need to increase your MAXSCRATCH parameter at whatever rate your total data
store is growing.  But I've found OCCASIONALLY only means about once a month
for me.  (Might be more often if you have smaller-capacity tapes).

Those of us with limited-capacity tape libraries have to live with this
issue, anyway.

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************








> -----Original Message-----
> From: Dusedau, Stefan [SMTP:Stefan.Dusedau AT VIACOM DOT COM]
> Sent: Thursday, March 18, 1999 8:10 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: restore times
>
> Bill,
>
> Thanks for the tip on the SQL. Using the distinct and the primary tape
> pool
> the node shows it is using only 109 tapes.
>
> My question to those who have suggested that collocation can be set up to
> not use one tape per node is: If you are limiting maxscratch for the pool
> how do you insure that a scratch tape will be available at 1am if a
> migration needs to take place? We found that limiting the number of tapes
> in
> the pool always bites you at the worst possible time and so we turned off
> collocation (this was at version 2 of ADSM).
>
> Thank You,
>
> Stefan Dusedau
> infoWorks
> A Viacom technology service
> (212)258-6739
> stefan.dusedau AT viacom DOT com <mailto:stefan.dusedau AT viacom DOT com>
>
>
>                 -----Original Message-----
>                 From:   Bill Colwell [mailto:bcolwell AT DRAPER DOT COM]
>                 Sent:   Wednesday, March 17, 1999 4:58 PM
>                 To:     ADSM-L AT VM.MARIST DOT EDU
>                 Subject:        Re: restore times
>
>                 A better select statement to list the volumes a node is on
> without
>                 getting duplicates for each filespace is --
>
>                 /*                                              */
>                 /* macro file to select the volumes that a node */
>                 /* is stored on.                                */
>                 /*                                              */
>                 set sqldatetimeformat i
>                 set sqldisplaymode w
>                 set sqlmathmode r
>                 commit
>                 select distinct volume_name -
>                    from adsm.volumeusage  -
>                    where stgpool_name = '9840APOOL' -
>                      and node_name = %1 -
>                   > e:\adsmcv3\sqllists\voluse3
>
>                 To run this, store it as a fill in the directory where
> dsmadmc is,
>                 and then enter "macro <filename> 'NODENAME_IN_CAPS' ".
>                 Then edit the output file \voluse3.  Adjust the
> redirection
> name
>                 as necessary.
>
>
>                 To comment on the thread in general, a Consolidate command
> would be
>                 a good thing to have.  I submitted a SHARE requirement for
> one 4 years ago when
>                 I wasn't doing collocation.  I have since switched to
> collocation so there are other
>                 thing I would like development to do first.
>
>                 I think there is a lot of misconceptions about collocation
> and how to implement it.
>                 It will always buy you something on the restore time, but
> you pay on the migration
>                 time.  You don't need 1 or more tapes for every node.
> ADSM
> will double up, triple up,
>                 etc.  as Wanda pointed out.
>
>                 --
>                 --------------------------
>                 Bill Colwell
>                 C. S. Draper Lab
>                 Cambridge, Ma.
>                 bcolwell AT draper DOT com
>                 --------------------------
>
>                 In <01BE707E.1928FF60.sorensen AT storsol DOT com>, on 
> 03/17/99
>                    at 01:57 PM, "John M. Sorensen" <sorensen AT STORSOL DOT 
> COM>
> said:
>
>                 >I do have a comment on the SQL query you used to
> determine
>                 >how many volumes contain data for any client node.  It
> turns
>                 >out that you may be in much better shape than you think!
>                 >The problem with the query is that the number returned
>                 >in count(*) will count every individual filespace
>                 >from a client node as a separate row.
>
>                 >Here is an example from my server.  Client node MELMARJO
> is
>                 >a Windows 95 client.  It backs up 3 filespaces; APPS,
> USER
>                 >and WINSYS (I have removed some whitespace from the
> output
>                 >but the text is untouched).  This query returns all
> columns
>                 >defined for the table, so that the upcoming query
> returning
>                 >the count(*) can be interpreted.
>
>                 >adsm> SELECT * FROM VOLUMEUSAGE WHERE
> NODE_NAME='MELMARJO'