Russell,

Feature #0 is not new to 31240.  I have observed this since version 1,
release 1.

Feature #1?  The feature is that it doesn't start at the beginning.
And that is a fine and welcome feature.  I don't see a problem here.
Let expire run until it gets over the big hump.  You still have
a lot more capability than before 31240.

Feature #2, i have no comment.  I don't actually use any of this stuff.

Feature #3 is a bug of course and should be reported.

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <199910070300.QAA25005 AT mailhost.auckland.ac DOT nz>, on 10/07/99
In <199910070300.QAA25005 AT mailhost.auckland.ac DOT nz>, on 10/07/99
   at 04:00 PM, Russell Street <russells AT AUCKLAND.AC DOT NZ> said:

>Hi... has anyone noticed these (err) features with the inventory
>expiry under 3.1.2.40?

>Feature #0:

>        Expire inventory works through the nodes in the order they were
>        registered;  first registered is expired first.


>If you cancel an EXPIRE INVENTORY process and restart it some time
>later it will pick up where it left off.  This is a good thing.  But
>leads to feature #1:

>        ADSM starts at the beginning of the file space it was last
>        examining.

>Therefore, if you have a regime in which expiry is run every day, is
>cancelled after 4 hours and have a file system that takes (say) 5
>hours to examine, then ADSM will stay stuck on that one file system.


>But wait, if you order now you can get feature #2 for no extra cost!


>If you use 'expire inventory duration=nnn' and expiration is cancelled
>because it has exceeded the duration, you get feature #2:

>        The next expiration starts from the beginning of the node list.

>So if you try to use duration=nnn to control expirations, you will
>just expire the same set of file systems over and over again.



>And feature #3 (at least on my system)

>        The server leaks memory if expire inventory and client
>        sessions run concurrently.

>... our ADSM server [process] has crashed three Saturdays in a row.
>Each time the server process has grown from a sedate 128MB-140MB
>footprint to 570MB+ and paging madly.

>If expire inv is not running, no Satuday crash.  (I don't have the
>courage to run expire inv during a weekday backup window ;)


>Before I try to raise this with IBM service, does anyone else see
>these sorts of effects?

>You probably need a large client base --- we have ~600 clients and a
>30GB database, so small sites and test systems won't show it up.


>Russell