David - The first thing to do is to follow your policy definitions as
        referenced by the client to see where they lead in storing
data.  It's all too easy to create a "dead end", as in pointing to
a storage pool to which no volumes have been assigned and where there
is no scratch pool.  Presumably you did a  'VALidate POlicyset'
before the 'ACTivate POlicyset', which should catch basic inconsistencies.
Beyond that, here are cumulative notes from my ADSM functional directory:

ANS1329S Server out of data storage space
        "Out of space": Typically, your server storage pools are full: you may
        need to lower your migration threshold.
        Or could be that your Stgpool MAXSCRatch value is insufficient.
        Has also been seen with a symlink which points to nothing.
        Might also be a Backup or Archive on a file system with complex
        directory entries (e.g., NTFS) such that they by default go to the
        storage pool with the longest retention, but that storage pool (probably
        different from where your data would go) cannot be written to. Look into
        ARCHMc and DIRMc.
        Further: At the start of the backup for the file, the server reserves
        enough space in the storage pool to hold the file based on the clients
        estimate. If storage pool caching is turned on then cached entries have
        to be released. If the system can not reserve enough space for the file
        in the storage pool then it is stored on the next storage pool that has
        room for the file. Normally  at least one storage pool is defined with
        no size limit, so this normally works.  Then the file is transmitted up
        to the server. If it is not compressed or reduces in size with
        compression it is stored in the reserved space and all is ok. If the
        file grows in size with compression and COMPRESSAlways=No then the
        client will stop sending the file and retransmit without compression and
        all is ok. But with COMPRESSAlways=Yes the file will be transmitted
        until the reserved space is used up. After that time the server out of
        message is issued if there is no free space in the storage pool. Without
        caching there is normally free space, but with caching the storage pool
        is full by design. It would be nice if the client could wait for the
        server to find more space in the storage pool or one of the next storage
        pools and then continue the backup.

 Richard Sims, BU