Here is what I have learned after upgrading to V3.1.2.41 two weeks ago.  If
I run expiration with any other processes it will hang the 'expire
inventory' process.  If I try to cancel it the 'expire inventory' process
will stay in a cancelling state until I recycle ADSM.  According to IBM
there is an APAR out there for my problem and it only occurs on Sun
servers. IC24611.

I like the idea of the expiration enhancements but it is causing more
problems than it is fixing.

Becky Buechler
Schneider National Inc.







                    ADSM-L AT VM DOT MAR
                    IST.EDU              To:     Becky 
Buechler/Schneider@Schneider,
                                         ADSM-L@ADSM-L AT VM.MARIST DOT 
EDU@SMTP@exchange
                    10/06/1999           cc:
                    09:00 PM             Subject:      Expire inventory 
"features"





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