RE: Calling C from RPG: what am I doing wrong?

I did not mean to throw a cat amongst the pigeons by raising this old
issue again.
I'm happy that the problem has never recurred since V5R1 as the program
which exposed the problem has never been recompiled and now does not
fail.

Correct, the problem was exceedingly difficult to debug, as in our case,
it only occurred while the system was handling an unmonitored exception.
Once a senario in which it occurred could be replicated, the program had
to be whittled down until the problem vanished.

As I mentioned, it was indeed proven to be directly related to the
number of compiled sub-procedure calls, less than 130, OK, more than
130, failure.
The important thing is that the execution never got as far as running
even the first sub-procedure call since the unmonitored exception arose
on the first executable statement.
The return value on the call was of fixed length but the size did not
matter, in fact it was only 40 bytes. It was the size of the return
value in the prototype (65K) which caused the problem.
In fact, I have safely recompiled at V5R4, the same code that was errant
at V5R1, with the sub-procedure call explicitly repeated as an extra
statement 1000 times with no ill effect.

Peter




-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Sunday, 30 November 2008 4:02 a.m.
To: RPG programming on the IBM i / System i
Subject: Re: Calling C from RPG: what am I doing wrong?

Scott Klement wrote:

I don't see what this has to do with load? Why would a higher load
cause you to use more automatic storage? Seems to me that the amount
of automatic storage you use should be pretty much determined at
compile time, and be a fixed-number thereafter

That's what I thought as well, but I misunderstood Barbara's comment
about "zillions of calls". That combined with the fact that the problem
only manifested itself at runtime frightened me into thinking that
somehow automatic storage usage was growing during runtime, and so I
wrote a simple test.

I'm still a little concerned about the mechanics - is the 16MB limit per
module? Per bound program? If it's the former, the compiler I wonder
if the compiler can't catch it. If the latter, shouldn't it be detected
during the bind? If neither, if it's at the job or activation group
level, then it's a subtle and potentially very hard to debug problem.

Joe