>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
>