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

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

Scott

This fits what happened to me. In my case, I had added calls to a new 
function to adjust some text. And the calls were inline.The overflow of 
auto storage was pretty clearly related to the number of distinct calls 
to the procedure. In other words, the number of locations in the source 
where the calls occurred. I was not able with time and other constraints 
to reorganize an otherwise sprawled-out source member, so the solution 
was to use a shorter length for the return value. According to Barbara's 
latest post, seems the better solution is to find ways to make more of 
the code into procedures that call other procedures.

Now a question arises - why don't the BIFs have this problem? Or do 
they? It does seem related to allocation at the point of the calls.

Vern

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
>
> Joe Pluta wrote:
>   
> > This seems like a pretty serious issue since it would most likely only 
> > occur during periods of heavy load, so I put together a little test, 
> > albeit pretty unscientific.  Basically I just created an ILE RPG program 
> > that invokes a subprocedure that returns a 65K varying field (after 
> > stuffing the current time into the field).  I ran it for an hour and a 
> > half, 14 million calls, and it seemed to run just fine.
> >     
>
>
>