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

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.