I sometimes get the problem described below. My server is an IBM SP Node,
AIX 4.3.1.
The ADSM server is at 3.1.2.41. Is there an APAR for this ?

Regards

Jasdayal S Dhanoa
MCI WorldCom

> -----Original Message-----
> From: Becky Buechler [SMTP:Buechlerb AT SCHNEIDER DOT COM]
> Sent: Thursday, October 07, 1999 3:39 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Expire inventory "features"
>
> 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

===================================================
This communication contains information which is confidential and
may also be privileged.  It is for the exclusive use of the
intended recipient(s).  If you are not the intended recipient(s),
please note that any distribution, copying or use of this
communication or the information in it is strictly prohibited.
If you have received this communication in error, please notify
the sender immediately and then destroy any copies of it.