Tom,

When you say expiration has slowed down, what exactly do you mean?
If you are looking at the anr0812i message, are you talking about the
'examined' number  or the 'deleting' numbers?  Expiration can examine
a lot more files than it can delete.  If the prior events you are comparing to
did not do many deletes, and the current event did a lot of deletes, then
you probably don't have a problem.  Actually deleting a file takes the
server a lot, lot longer than just examining a set of backups to see if
a version is old enough to go.

I run on OS/390 too and expiration is a pig, but I have gotten use to it.
I am on 4.2.1.9 and I haven't noticed any slowdown over the past year
due to version upgrades.

Hope this helps,

Bill

At 03:59 AM 8/8/2002, you wrote:
>Hi all,
>
>Env: TSM server 4.2.0.0 on MVS 2.9
>Database 20GB, 66% utilized, 8 volumes on HP512 (4x ESCON connected)
>
>In last two months expiration process dramaticaly slowed down to approx
>500-1000 objects/minute. Expipration of 100.000 objects takes 3-4 hours (no
>other TSM processes runs at a time, TSM have about 800MB memory allocateed).
>Compared to our other TSM environments it is very slow. DB grows from 10GB
>to 20GB in last 2-3 months.
>
>Any idea? Tune some parameters? Increase memory allocation? Or any ather
>action like unload/load DB?
>
>
>Any help will be appreciated.
>
>Tom

----------
Bill Colwell
C. S. Draper Lab
Cambridge Ma.