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