Should one also stop any expire inventory administrative schedules that are
set, or does this problem only apply to an expiration process that was
started via the expinterval option?

I'm assuming yes, the schedule should be stopped until the problem is
remedied...?

Paul

-----Original Message-----
From: Tom Brooks <tbrooks AT VNET.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU <ADSM-L AT VM.MARIST DOT EDU>
Date: Monday, July 19, 1999 3:52 PM
Subject: WARNING, READ THIS BEFORE INSTALLING the ADSM server 3.1.2.30


>The server level 3.1.2.30 introduced an error in expiration processing such
>that the wrong policy attribute may be used to expire data.
> To encounter this situation, the following would need to occur:
>
>1) A given file would need to have multiple inactive versions of a file.
>2) The file has no active versions (the file was deleted from the client
>filesystem and an incremental backup was run).
>3) When expiration is run, all versions of the file are eligible to be
>expired under the "RETAIN EXTRA" policy attribute.
>
>In this error, the last version of a backup file may be managed by the
> RETAIN EXTRA policy attribute instead of the "RETAIN ONLY" policy
attribute.
>
>This can only occur if:
>
>- multiple inactive versions of the file exist when expiration is run.
>- all the inactive versions are eligible to be expired under the RETAIN
EXTRA
>when expiration is run.
>
>In this situation, the last backup version of the file can be deleted
incorrect
>using the "RETAIN EXTRA" policy attribute when it should have been
> managed by the "RETAIN ONLY" value.  The description above describes
>how this can occur.
>
>IF YOU HAVE ALREADY APPLIED 3.1.2.30 and you are exposed
>
>1) Halt the server
>2) Set the server option EXPINTERVAL 0 (in the server options file).
>3) Re-Start the server
>
>We are working to correct this as soon as possible
>
>Tom Brooks
>ADSM Server APAR Coordinator
>ADSM Server Development
>