Dave,
        Checkout the following APAR.....


Tim Pittson
tpittson AT himail.hcc DOT com



  APAR Identifier ...... PN89379       Last Changed..96/10/07
  MAXIMUM REDUCTION VALUE OF ADSM DATABASE DOES NOT CHANGE AFTER
  ENTRIES ARE DELETED FROM THE DATABASE

  Symptom ...... IN INCORROUT         Status ........... CLOSED  SUG
  Severity ................... 2      Date Closed ......... 96/10/07
  Component .......... 565511901      Duplicate of ........
  Reported Release ......... 210      Fixed Release ............
  Component Name ADSM MVS SERVER      Special Notice
  Current Target Date ..96/11/30      Flags
  SCP ...................
  Platform ............

  Status Detail: ASSIGNMENT - APAR has been assigned to a
                              programmer.

  PE PTF List:

  PTF List:


  Parent APAR:
  Child APAR list:


  ERROR DESCRIPTION:
  After deleting a large number of entries from the ADSM database,
  the maximum reduction value for the db does not change. Q DB F=D
  shows the following statistics:

        Assigned Capacity (MB): 15,260
        Maximum Reduction (MB): 852
                         %UTIL: 51.3

  This means that the database consists of only 7,828 MB of data.
  Since the database is mirrored, the physical assigned capacity
  (between both copies) is 30,520 MB, with 15,656 MB being used.
  This effectively wastes 14,864 MB of space, which is roughly
  equal to 5.5 3390-3 DASD volumes.

  This represents a significant amount of wasted DASD space. Due
  to the size of the database, the dump and load process suggested
  in APAR IC08571 is not feasible.


  LOCAL FIX:


  PROBLEM SUMMARY:


  PROBLEM CONCLUSION:


  TEMPORARY FIX:


  COMMENTS:
  The ADSM Server database has a b-tree organization with
  internal refrences to index nodes and siblings.  The database
  grows sequentially from the bginning to end, and pages that
  are deleted internally are re-used later when new information
  is added.  The only utility that can compress the database
  so that "gaps" of deleted pages are not present is the database
  dump/load utility.

  After extensive database deletion occurrs, due to expiration
  processing or filespace/volume delete processing, pages in
  the "middle" of the space allocated for the database may become
  free, but pages closer to the beginning or end of the database
  still allocated.  To reduce the size of your database sufficient
  free pages must exist at the end of the linear database space
  that is allocated over your database volumes.  A database
  dump followed by a load will remove free pages from the
  beginning of the database space to minimize free space
  fragmentation and may allow the database size to be reduced.

  Request 961007122512 has been entered into our requirements
  database to request the development of a utility that would
  compress fragmented free space and allow your server database
  to be reduced without affecting server availability.  We will
  consider this requirement for a future ADSM release.


  MODULES/MACROS:


  SRLS:


  RTN CODES:


  CIRCUMVENTION:


  MESSAGE TO SUBMITTER:



>
>From:  David C Campbell[SMTP:eacdcc AT EXPEC DOT COM]
>Sent:  Tuesday, May 27, 1997 6:53 AM
>To:    ADSM-L AT VM.MARIST DOT EDU
>Subject:       clean up / reduce DATABASE
>
>I have and old database that was first allocated on MVS in 1994 and has
>grown to 20 gigabytes.
>
>since then we have been reducing the number of nodes by migrating them
>to other severs.
>
>the database is now only 47% used but there is no room for me to REDUCE
>the DB.
>
>is there any way to compress it so i can free up some space?
>
>regards
>Dave Campbell
>