Optimizing an automatic storage error

Oh dear,
Back at Xmas we thought we'd licked the wretched "automatic storage limit 
exceeded" problem by not coding return values as 65K varying strings for a 
procedure that was coded in about 300 places in an application. 

Now we find that when we optimize *FULL, the application throws the automatic 
storage error again, so we can't optimize these programs.

Since one of the procedure parms if declared as a 65K const varying I'm 
wondering if this is what is causing the optimizer to generate code that gives 
us the runtime error again. I'm about to try any parameter declaration that 
might make the error go away ( short of doing things like splitting the app 
into 2 or more apps or attempting to recode all the calls as subroutine calls 
to a subroutine that isolates the procedure call to just one occurrence for the 
compiler to deal with.

Peter
  
This correspondence is for the named person's use only.  It may contain 
confidential or legally privileged information, or both. No confidentiality or 
privilege is waived or lost by any mistransmission. If you receive this 
correspondence in error, please immediately delete it from your system and 
notify the sender. You must not disclose, copy or rely on any part of this 
correspondence if you are not the intended recipient. Any views expressed in 
this message are those of the individual sender, except where the sender 
expressly, and with authority, states them to be the views of Baycorp 
Advantage.If you need assistance, please contact Baycorp Advantage on either :- 
        Australia 133124 or New Zealand +64 9 356 5800