Please be carefull installing this fix.
Read the readme files before installing!!!


---------------------
$$ FIX for APAR PQ26279
$$ FIX for APAR PQ26279
---------------------
ADSM V3 EXPIRATION PROCESSING PERFORMANCE IS SLOW. OTHER ADSM PROCESSES MAY
ADSM V3 EXPIRATION PROCESSING PERFORMANCE IS SLOW. OTHER ADSM PROCESSES MAY
STALL OR STALL EXPIRATION WAITING ON LOCKS.

There have been problems in ADSM V3 server expiration processing
which kept the server from expiring all of the data that it
should. With the 3.1.2.20 level all the fixes for these
expiration problems are officially available. Upon running at
this level (or a previous fixtest level with these fixes)
expiration processing will initially run quite a while longer
to do initial catching up. Once the initial expiration
processes has completely traversed the db at this level
subsequent expirations will still run a bit longer than they
in the past as it will now always be checking the areas it had
been missing in the past. Due to the long running nature of the
initial and in some cases subsequent expiration processes there
is the possibility of other server processing running into
lock contention with expiration. This can cause expiration or
the other process to stall for a while waiting on the needed
lock. ADSM development is investigating possible enhancements
to expiration processing in hopes of improving the current
performance and reducing the possibility of lock contention.
This APAR is intended to address this performance enhancement.

In addition to changes in the expiration algorithm,a new command
has been added.  The command is "CANCEL EXPIRATION".  This
will cancel an expiration process if there is one currently
running.  Please note that this does NOT require the process
id to be specified.  By not needing the process id, this
command can be scheduled using the server administrative
command scheduling utility to help manage expiration
processing and the time it consumes.

The expiration algorithm and server have been changed as follows:

1) The algorithm itself has been altered to allow it to use
multiple threads.  This will allow the process to spread the
work of searching for files to expire and the actual deletion
of files between these multiple threads.

2) The command "CANCEL EXPIRATION" has been added.  This allows
for the cancelling of an expiration process without knowing
what the process id for expiration is.

3) The expiration algorithm is now restartable.  If the
process is cancelled and subsequently restarted, it will
restart where it left off instead of always from the
beginning of the expiration management table in the server
database.

So as to better manage expiration, if expiration takes too
long to run in a given customer environment, this fix
should offer relief and better management of the expiration
process.  For example, if it is desired to ONLY have expiration
run for 2 hours each day from 8:00 at night to 10:00 at
night.  A server administrative scheduled command can be
set up to start expiration each night at 8:00.  And than
to manage having expiration ONLY run for 2 hours, another
scheduled command can be entered to issue the
"CANCEL EXPIRATION" command each night at 10:00.  By doing this
the customer can manage having expiration run just 2 hours
a night.  Also, since expiration is now restartable, the
expiration process over the course of these 2 hour nightly
runs, will be able to progress through the ENTIRE
expiration management database table instead of always
restarting from the beginning.

By providing this combination of new function in expiration
and the new CANCEL EXPIRATION command, the expiration
processing can be explicitly controlled by the needs of the
customer environment and offer relief to the change in
expiration performance.

> -----Original Message-----
> From: Lauer Edouard [mailto:Edouard.Lauer AT BIL-DEXIA DOT COM]
> Sent: Friday, June 11, 1999 11:07 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Expire Inventory too slow
>
>
> Hello everybody,
>
> since we've upgraded our ADSM server on AIX from 3.1.0.5
> to 3.1.2.20 the expiration process has taken from normally
> 30 minutes that it runs in the old version to about 4-5 hours
> now. When running the expiration process takes most of the
> server ressources for itself and doing queries in the db or
> doing backups/restores is greatly degradated. We've opened
> a call at IBM for this but now I've seen in the fixtest directory
> that there's an oxford version (???) that relates this problem.
> Can anybody tell me more?
>
> Regards,
> _________________ Lauer Edouard ____________________
> ______ Prod. informatique ____ Systhmes Ouverts ________
> __ * +352 4590 3889 __ * Edouard.Lauer AT bil-dexia DOT com __
>
>
> =============================================================
> An electronic message is not binding on its sender.
> Any message referring to a binding engagement must be
> confirmed in writing and duly signed.
>
> =============================================================
>
Frans Bijma
IBM certified Specialist-ADSM