Problem doing ALTER FRAGMENT...ATTACH

Ugh. Platform: DG/UX R3.1, ODS 7.12.UC1X7. Will be upgrading soon, don't worry :). Problem: I have a huge table that I am trying to attach a fragment back into. This table has 53 fragments based on expressions. I am using the ALTER FRAGMENT...ATTACH...AFTER syntax to do my ATTACH. The ALTER FRAGMENT statement fails with a -776/-131 error (no space left to do the ALTER). After letting this I've determined that space is being allocated in _every_ fragment and it looks as though every fragment has writes going against it (I suspect that every fragment gets rebuilt completely but I don't know that for sure). Anyhow, the first fragment in the fragmentation scheme runs out of space, and my suspicion is that at the very least the entire 1st extent is going to get rewritten. I'm hoping that the rest of the table doesn't have to be rewritten. I'm a little (lot) upset at this - I can understand having to read all the existing fragments to figure out whether or not their rows belong in the new fragment, but writing out at least the entire first fragment (and from what I've seen on smaller tables, it looks like the whole table will get rewritten) seems really lame. Can anyone answer these questions for me? 1) Will the ALTER FRAGMENT...ATTACH require that every complete fragment be rewritten, or not? 2) My understanding was that ALTER FRAGMENT...ATTACH wrote in units of a few next extent sizes (from a CDI post by Art Kagel back in September). Can you find out if it has to write the entire first extent as well - our first extent on this table is 550 MB and we definitely don't have that available right now. 3) Any chance that the ALTER FRAGMENT...ATTACH processing became parallelized as of IDS 7.24.UC5 and/or became slightly more efficient with regard to not rewriting stuff in the entire table when I'm only attaching one fragment? Please respond back to Wes.Gamble@chron.com as well. Thanks for any help on this one, WG