Optimizing an automatic storage error

["Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx>]

 >> 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.

Almost certainly, yes.  Although I would have expected the run-time to clear
up and re-use such allocations anyway.  Have you raised this as an APAR with
IBM?

Anyway - since you are passing varying length fields, one option would be to
add the keyword OPTIONS(*VARSIZE) which will allow a varying field of < 65K
to be passed as-is with no copying.  A copy will still be made of any
"ordinary" (i.e. non-varying) character field, but at least the varying
fields will not require it.

I have to wonder if you _really_ need to bring back this large a piece of
data.  The fact that you are using CONST implies that smaller fields will be
used.  %Len in the called procedure can be used to determine the current
size of the field, but that only helps if the original parm was non-varying
or the varying field had its length set to max (%Len(varfld) =
%Size(Varfield) - 2 ) before the call.  But because the compiler space fills
(sadly) fields under these circumstances, there might be significant
overhead in doing this.

Without knowing more about what you are doing it is difficult to suggest
alternatives.  For example I assume that you are returning a value in this
field since it appears to be replacing a return value, but are you ever
passing fixed length fields or only varying?

Jon Paris
Partner400
www.Partner400.com