Re: RPG Futures (was free form RPG reference)

Steve Richter wrote:

Barbara, my working assumption on this is that CEERTX is not used
within compiler generated code in order to do procedure exit cleanup.

CEERTX is not used; a different method of enabling a cancel handler is
used.  (A direct handler, like you get with C #pragma cancel_handler.)

It is probably used when the Monitor ... EndMon opcodes are used. 

No, that's an exception handler, also enabled without calling CEEHDLR,
but by using a direct handler.

My assumption is that when the compiler uses %alloc in a procedure it
has to call CEERTX in that procedure in order to make sure that
everything that is allocated from the heap is deallocated.

If you mean the compiler itself as a separate application, at compile
time, yes and no.  Storage allocations are handled at a higher level
than an individual procedure.

If you mean an RPG procedure that does a %alloc, no, it's up to the RPG
programmer to deallocate the storage.  The compiler has to assume that
the RPG programmer still wants the storage after the procedure ends.

The next assumption is that an unbounded array would be allocated on
the heap. Meaning that the use of an unbounded array in a procedure
would require the procedure call CEERTX on entry.   All guesswork.
Dont anyone jump out the window. Based on my timings, calling a shell
procedure that uses CEERTX takes 10x the CPU than without. So a
procedure that used an unbounded array would take longer to call than
one that uses a standard array.

Since a cancel handler is probably already enabled for your procedure
for other reasons, we are only concerned about the time to actually
deallocate the storage.

my guessing here is that procedure variables are allocated on the
stack in one swoop when the procedure is called. Heap allocations are
done one at a time as the procedure is running.  From my measurements
the alloc .. dealloc pair takes 6x the time of a procedure call.

That may be true.  So an unbounded array might have a higher cost than
an "ordinary" array.  Already it's the case that a large array has a
higher cost than a small array, due to initialization.  That's just a
fact of life that some things cost more than others, but that doesn't
mean they aren't still valuable.  The alternative is for RPG programmers
to code the unbounded array themselves, which would almost certainly
cost (a lot?) more than if the RPG compiler generated it for them.