Thanks a ton David!!! This was the answer. While every string being written to the memo field was indeed never larger than the original, I didn't think to pad every one of the replacements to the exact length of the original. After doing that the application worked without a hitch. There are several things we are accounting for now:

1. QA is now testing to make sure that all of the extra CHR(0)s at the end of the recursive records does not adversely affect the program.
2. This logic works find for fields less than 16 MB, but we'll have to put in an IF to handle larger fields.
3. I'll be having several Margaritas tonight and toasting to your help. Remind me to buy you a drink at the next conference.

As a side note, the problem not only caused memo bloat, but a huge slow-down in the system due to memory consumption. Even on "smaller" instances, it was internally eating up 50-60 MB of memory and creating a lot more .TMP files. As soon as this change was put into place, the number of .TMP files never exceeded 5 during all processing.

Thanks again!