I too have seen this behavior after migrating to 3.1.2.1.  The expiration,
which used to run successfully in about one hour, now takes days utilizing
as much cpu as it can get.  The object counts in the status message stop
incrementing after about an hour.  What is it doing between hour 1 and hour
100?  Is this a bug?  Can I safely cancel the process after the counts stop
incrementing and not lose anything from expiration?   IBM --- can you
comment please?



> ----------
> From:         Russell Street[SMTP:russells AT AUCKLAND.AC DOT NZ]
> Sent:         Monday, March 29, 1999 4:44 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Expiration = FEAR
>
> > I have a problem that seems to have effected a bunch of people here.
> > Expiration...
> >
> > I upgraded ADSM and fixed my management classes (I had them set to
> retain
> > omly=1 and retain extra=1 for an SQL management class).  I then started
> > expiration.  That was at 10:00am Friday.  It is now Monday and it is
> still
> > running.  It has examined over 2.5 million objects and deleted over 1.5
> > million!
> >
> > Anybody have this happen?
>
> Yes.  The first time from 3.1.1.3 to 3.1.2.1 the system did that.
>
> Now it expiration takes >24 hours, examines about 9 million objects
> and deletes a few hundred thousand.  This is on a system with 32
> million files in the inventory, plus copy pool references.
>
> Russell
>