Swapnil,

Your first steps should be to gather more data, and use the data to guide eliminating single suspected points of failure.

The symptoms described might be caused by a memory leak.  Does the amount of memory used by the process continue to increase over time?  If so, then take steps to identify the possible source of the leak.  Is the CALLed program allocating memory that is not being released?  Possible sources of such leaks would be calls to C$MemoryAllocate, or use of some of the XML Extensions functions that allocate memory (e.g. XML GET TEXT) without using XML FREE TEXT to return the memory.  If your COBOL code has any COBOL pointers (i. el. data items described with USAGE POINTER) carefully determine the use of these pointers to determine if they are storing pointers to memory somehow allocated directly or indirectly.

Another approach to isolating a cause would be an otherwise identical test program to replace the curl command with (to use a Linux example) a sleep command, and let that run for some hours.  Observe its behavior, and memory use.  If the problem goes away, then the problem lies with curl and you should direct your efforts there.  

Although I doubt that this would make any difference, you could try CANCELing the CALLed program each time.

So, gather data and experiment with test programs, and tell us what you learn.

Thanks Tom.. I will perform test and will let you know... I am using CANCEL command as of now. I have couple of more question:

situation is PGM1 --> PGM2 --> CALL SYSTEM and CALL PGM3 and CALL PGM4.

1. Do I need to CANCEL PGM2 alone ?

2. Or PGM2, PGM3 and PGM4. Also, can I use CANCEL "SYSTEM" ?

You must cancel PGM3 and PGM4 as well as PGM2.  You may cancel SYSTEM, but it will have no effect.

Tom gives good advice. You can use the task manager or (better) the free Process Explorer to see how much memory your process is using at the start and at the end of the run.

Also, are you using XML Extensions?  What version of RM/COBOL are you using on what platform (operating system)?

Yes, I am using XML Extension in process. RM/COBOL is 12.18 [64 Bit]

Hi Tom - Please find my reply underneath.

<<The symptoms described might be caused by a memory leak. Does the amount of memory used by the process continue to increase over time?>>

Yes.. it is increasing with time.

<<Is the CALLed program allocating memory that is not being released?>>

I am using XML EXTENSION function in program [XML INITIALIZE, XML IMPORT FILE and XML GET UUNIQUEID].Not using XML GET TEXT. 

<<Another approach to isolating a cause would be an otherwise identical test program to replace the curl command with (to use a Linux example) a sleep command, and let that run for some hours. Observe its behavior, and memory use. If the problem goes away, then the problem lies with curl and you should direct your efforts there.>>

Writing the output of curl to temproary file. Later, reading the file and  deleting temporary file using CALL SYSTEM "rm -f <<filename>> command in program. Also, Logging time before and after each SYSTEM call. This time keep on increasing with time until processing is kill and started again [then again time started building with memory]

<<Although I doubt that this would make any difference, you could try CANCELing the CALLed program each time.>>

Tried but no impact.

There are a couple things you can try.

XML Extensions caches documents to improve performance in most standard usage situations.  However if documents are cached that will never be reused, caching can over time (such as your 24-7 application) work against you.

You can control caching by using three XML functions:

• XML FLUSH CACHE
• XML DISABLE CACHE
• XML ENABLE CACHE

As mentioned in a previous post, using the various XML ... TEXT functions can cause XML Extensions to allocate memory which must be freed by using XML FREE TEXT when the allocated memory is no longer needed.  Failure to do so will cause a memory leak. There is no automated garbage collection.

<<You can control caching by using three XML functions:>>
<<TEXT functions can cause XML Extensions to allocate memory>>

Tried but no impact.

Further, Steve advises there is known problem of Memory leak with XML Extension 12.18 for long running process [24-7]. Problem will be resolved with 12.19 release. Tested with beta version of 12.19.
Created a small test where my program issues 100,000 API call sequentially. Test took 12 hours to complete with 12.18 with nearly 25% of MEM. Whereas test completed in 2 hours with 12.19 with no memory leakage.

Swapnil,

Thank you for coming back and reporting this.  Much appreciated!