Othmar,
        I ran into this situation also... it's described in APAR IC0857I.  The
only way to reduce it is with a DUMPDB/LOADDB.  Even though I shut down
our ADSM system cleanly before doing this, I ended up having to do an
AUDITDB because I ran into a bad page on the DUMPDB. One thing to keep
in mind is that you can do the DUMPDB against your existing system and
the LOADDB against newly allocated database and recovery log volumes.
Either way, I'd use an external utility (DSS, FDR) to backup all things
related to your ADSM system before starting this process.

Good luck !!

Tim Pittson
tpittson AT himail.hcc DOT com

>----------
>From:  WEBO@MT0004 (O.Weber)[SMTP:othmar_weber AT E-MAIL DOT COM]
>Sent:  Wednesday, September 25, 1996 4:35 AM
>To:    Multiple recipients of list ADSM-L
>Subject:       Reduction of Database
>
>Hi there!
>
>We are running ADSM V2.1 on MVS. After deleting some filespaces I
>tried to reduce the size of the server database but encountered the
>following problem:
>
>The ADSM database can't be reduced athough more than half of the
>pages are not used. The command "Q DB F=D" revealed the following:
>
>          Available Space (MB): 2 728
>        Assigned Capacity (MB): 2 312
>        Maximum Extension (MB): 416
>        Maximum Reduction (MB): 0                   <-----
>             Page Size (bytes): 4 096
>            Total Usable Pages: 591 872             <-----
>                    Used Pages: 203 596             <-----
>                         %Util: 34,4
>                    Max. %Util: 47,7
>              Physical Volumes: 12
>             Buffer Pool Pages: 512
>         Total Buffer Requests: 45 124 233
>                Cache Hit Pct.: 72,88
>               Cache Wait Pct.: 0,00
>           Backup in Progress?: No
>    Type of Backup In Progress:
>  Incrementals Since Last Full: 0
>Changed Since Last Backup (MB): 0,05
>            Percentage Changed: 0,01
>Last Complete Backup Date/Time: 24.09.1996 14:22:44
>
>I told the problem to IBM but the guy there said that this can happen
>when the database pages are spread all over the database volumes. He
>told me to do a DBDUMP and DBLOAD. So I have worse experience with
>this commands (this is another story) I would only use them if this
>were the only way. One thing I tried: I defined a new database volume
>and deleted an old one. Then I defined the old one as new volume and
>deleted another old one and so on. Unfortunately this had no effect.
>
>Has anyone experiences with this problem? Any help would be
>appreciated.
>
>Othmar Weber
>BAYER AG Germany
>othmar_weber at e-mail.com
>