upgrade to 3.1.2.20 did not fix this ... expiration still hanging

ijk

ilona.kersey AT swpc.siemens DOT com
Siemens Westinghouse Power Corporation

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Price, Robert R.
> Sent: Tuesday, March 30, 1999 10:10 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Expiration = FEAR
>
>
> 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
> >
>