Hello,
     There has been concern about the expiration processing and the 3.1.2.1
level of the server.  The expiration processing in 3.1.2.1 was affected by
two items.

The first item was the fix for apar IX81990.  This apar FIXED expiration
to evaluate ALL possible files eligible for expiration.  There was an error
in the expiration algorithm that caused some files to be skipped by
expiration when they should have actually been expired.  This fix causes
these files to now be evaluated and if they are eligible, they will be
expired.

When 3.1.2.1 was applied, many customers would see expiration taking longer
to run.  The reason it takes longer to run once the 3.1.2.1. level is
applied is because more files had to be evaluated and because there MAY be
more files to expire as the files that were previously skipped are now
being handled.

The other item that affected the 3.1.2.1 server is documented in apar
IX85298.  This impacted the versioning of BACKUP files and how excess
versions of a file were not marked for deletion as they should have been.
This could cause the DB size to increase as files that would normally
expire were not being marked as eligible for expiration.  An emergency fix
for 3.1.2.1 was made available that incorporated this fix.  This fix is
also in the 3.1.2.20 level of the server.

It is recommended that customers apply the 3.1.2.20 level of the server as
it has the fix for IX85298 as well as other fixes.

ADSM Development