1. try "q actlog begind=-2 s=recla" (or maybe s=100 or some other search
string) to see when the reclamation threshold got reset.  If you find that
it happened at 15:00, then say "q actlog begind=-2 begint=14:55" to see who
issued what command.  That ought to shed some light.

2. I suggest you not set the disk pool's low migration threshold to 0. Set
it to 5% or something.  If it's zero, the first packet that lands in the
disk pool kicks off migration, which completes immediately - then the next
packet does the same thing, so migration thrashes crazily.

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Stephen Pole
> Sent: Wednesday, May 30, 2001 11:44 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: adsm 3.1 and stgpool reclaim threshold
>
>
> Hi Steve,
>
> I have not seen this behaviour unless you have an entry in adminstrative
> command schedules like the ones below:-
>
> To check this out do the following:-
>
> Log into the ADSM Web GUI
>
> Select > Object View > Automation > Adminstrative Command Schedules
>
> This will bring up the Automated command schedules that run by themselves
>
> They will more than likely look like this:-
>
> Update storage pool <STGPOOL_NAME> low=30 high=70
>
> This is timed to start at say 19:00 hours every day of the week.
>
> During the day you can raise/lower the high water mark, but at 19:00 hours
> the 70% mark will be reset by this schedule.
>
> For example, we like to have our data running to disk during the
> day, so we
> have a high water mark set as above.
>
> Now during the night (when there is less activity) another schedule lowers
> the high water mark and low water mark to 0, then another
> schedule at 06:00
> resets this to low=30 and high=70.
>
> It looks like this:-
>
> update storage pool <STGPOOL_NAME> low=0 high=0
>
> This is timed for 19:00 every day of the week.
>
> BTW, we also do this before shutdown of the server, that is, we flush all
> our pools to disk before a shutdown.
>
> Hope this helps.... Give us a call as I assume you are in Perth Western
> Australia.
>
>
> Stephen Pole
> Operations Manager - PetroBank Asia Pacific
> Level 4 IBM Centre
> 1060 Hay Street
> West Perth WA 6005
> Phone +61 9 9320 9000
> Mobile 040 247 9133
>
>
> email: stephenp AT prth.geobank.pgs DOT com
> web : http://www.petrobankonline.com
>
>
>
>
>
> What happens is that
> ----- Original Message -----
> From: "Steve de Souza" <DeSouzaS AT BUNNINGS.COM DOT AU>
> To: <ADSM-L AT VM.MARIST DOT EDU>
> Sent: Thursday, May 31, 2001 10:27 AM
> Subject: adsm 3.1 and stgpool reclaim threshold
>
>
> > Hi,
> >         Can anyone tell me if there are any conditions which will
> >         cause a copystorage stgpool to have it's reclaim threshold
> >         percentage to change to 100% ??? We have no scripts which
> >         explicitly change it, and yet we find that it changes from 70 to
> 100
> >         every day !!
> >
> >         we have run into a problem in that this gets done every morning
> >         after bkserver finishes.
> >
> >         Any cluses/answers would be much appreciated.
> >
> >         cheers
> >                 steve
> >
> > ------------------------------------------------
> > Steve de Souza
> > Senior System Administrator
> > Bunnings Building Supplies
> > Perth, WA
> > Phone : (08) 9365 1527 /  0409 383 943
> > Email : desouzas AT bunnings.com DOT au
> >
> >
> >
> **************************************************************************
> > Bunnings Legal Disclaimer:
> >
> > 1)      This document is confidential and may contain legally privileged
> >         information. If you are not the intended recipient you must not
> >         read, copy, distribute or act in reliance on it.
> >         If you have received this document in error, please telephone
> >         us immediately on (08) 9365-1555.
> >
> > 2)      All e-mails sent to and sent from Bunnings Building Supplies are
> >         scanned for content. Any material deemed to contain
> inappropriate
> >         subject matter will be reported to the e-mail administrator of
> >         all parties concerned.
> >
> >
> **************************************************************************
>