ARSUPERC exit for OnDemand V9.0 using malloc

[bwissink]

We are using ARSUPERC exit to modify the SQL restriction string.  The question I have is the use of 'malloc' to allocate space for the restriction string.  currently in the exit we use 'malloc' to allocate 1024 bytes each time we run the exit and modify the SQL restriction string.   Shouldn't there be a corresponding 'free' somewhere?

[ewirtz]

Hi bwissink,

I think you are right. 1024 Bytes are not much. So maybe you have no problems. We use static memory to create a thread specific table of memory. This works fine.

regards

Egon

[Alessandro Perucchi]

Yes you should.
Otherwise you will have some memory leak, and in the long run, ondemand might crash.
C as you know does not use garbage collector like Java, therefore, every time you allocate memory, you must free that memory allocation.

[ewirtz]

Hi Alessandro,

if you want to create a query restriction you cannot do a free, because ARSSOCKD needs the content of the restriction. The only correct way I know is to construct a thread specific memory pool which need not to be freed because it can be reused.

regards

Egon.

[Alessandro Perucchi]

Yes, you are right.
I was more thinking on all these helping variables, where you allocate memory and then you need to free the allocated memory.

And I didn't read carefully, my bad, the allocated memory was for the returned restriction string. Then yes, it must not be freed!
sorry for the confusion...

[bwissink]

we are using COBOL for our ARSUPERC exit so how do I create a 'thread specific memory pool'?

[ewirtz]

Hi
for our COBOL exit we use local storage for query restriction. This storage seem to survive after the end of the exit call. ARSSOCKD uses this restriction and it works fine. For the next call we get a fresh copy of this local storage. So in COBOL it's much easier than in C.
Our thread memory pool is created by a C program and is used for other purposes.

Regards

Egon

[ewirtz]

Sorry,
we get some memory with CEEGTST for the query restriction at the end. This address is provided for ARSSOCKD. So we have a possible memory problem in ARSSOCKD because no free is done. But up to now we have had no problems with this. ARSSOCKD is restarted once a week.

regards

Egon