Thanks every one for there suggestions.  I bumped BUFPOOLSIZE from 4m to 16m and
it seems to be working better.  It still ran for 3 days and did not complete, so
I am thinking of bumping it up to 32m.  During the process I used omegamon to
view what ADSM was doing.  And saw that it was plowing through the database
cylinder at a time.  One time I watched it go through over 1,000 cylinders of
database to delete less then 500 enteries.  Is this how it is suppose to work?
Does anyone know how it determines to delete an entry and where to go to do it.
I was told by the support center that ADSM maintains a table with expired
entries. (Of course we cannot view this table or scan it)  I know it expires
based on NODEname but to me it would be better based on DATABASE name.  I wonder
how many times during expiration that ADSM reads through the same database?  I
just think there must be alot of unnecessary I/O happening during this process.
But I really appreciate this forum I have gotten many ideas just reading these
updates.  Thanks and you all have a good week....
___________________Reply Header_________________________
Author: To: adsm-l AT vm.marist DOT edu at IntPO
Subject: HELP!!!!
10-09-96 02:30 PM

Is anyone having/have had a problem getting the expiration process to run.  We
are running ADSM 2.1.09 on a MVS server.  We have a 16 gigabyte ADSM database
with 325 clients (os/2,Mac,SUN,AIX) I am not sure when the expiration process
last ran successfully.  According to IBM with our size of database it will take
between 75-125 HOURS to complete the expiration process!!!  Whenever expiration
runs it seems our ADSM performance suffers significantly.  (Migrations,
Backups), we also experience hangs that cause us to bounce ADSM on the server.
IBM has given us a TRACE to run but the degradation caused by that is more then
the expiration problem.  I hope I am not the only one with this problem?  Any
suggestions would be greatly appreciated!!  Thanks
Don.Ludwig AT ccmail.fingerhut DOT com