105 Memory allocation error 2

[chirpyform]

I have the above problem. I am not able to use CANCEL or RELEASE because of mico focus issues. Is there another way of freeing up memory?

Chris

 

[fredericofonseca]

Here we go again.

What OS
What machine configuration (memory related items only)
What COBOL version

Are you using .int, .gnt, .exe or a mix of all of the above.
do you use external routines (e.g. call third party programs)


and why not use cancel?




Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[Dimandja]

Also, is this a coding strategy problem? What exactly do you do to get this error? Why does your memory need "freeing up"?

Dimandja

 

[chirpyform]

What OS - UNIX
What machine configuration (memory related items only)
What COBOL version - 4.1

Are you using .int, .gnt, .exe or a mix of all of the above.
do you use external routines (e.g. call third party programs)
- We use .gnt programs and the programs do call subprograms

and why not use cancel?
- we are using micro focus which means that the CANCEL routine causes a runtime error (same for RELEASE)

The problem in its totality is :
We have a server written in Java that creates threads to listen to many clients simultaneously.
When the server is run we run a COBOL program that connects to a database (Oracle). After, each time the client makes a call to the server a COBOL program is run (using cobcall from mfcobol). The program runs fine for the first 110 times. But as the memory is not freed we get a memory allocation error.

Chris
Thanks for any help

 

[Dimandja]

Hi Chris,

According to some Java/MF COBOL documentation, "the COBOL run-time system always ensures that the COBOL program is removed from memory when the run unit is finished"; in other words, when STOP RUN is encountered.

Does your COBOL code execute STOP RUN before a new run unit is launched? If not, to free up memory, you'll need to find a way to stop unused COBOL run units.

Dimandja

 

[chirpyform]

The STOP RUN command kills my server and so in fact it is the method to stop unused COBOL run units that I want.

Thanks Chris

 

[WMK]

What error are you getting when you try to do a CANCEL subprogram-name statement? This SHOULD work with Micro Focus in all environments. RELEASE has nothing to do with "freeing memory" - it is a SORT statement.

Bill Klein

 

[fredericofonseca]

Chris

Correct me if I am wrong.

You have a Java program acting as a server (A).

Program A calls a COBOL program (B) just to do the Oracle connection. Once this connection is done this program exits an returns control to A.

A then starts listening and whenever need launchs a new thread program(C) (Java??)

Program C in turn calls COBOL program (D) using RuntimeSystem.cobcall...

Program C calls other COBOL programs. These you should be able to cancel using the normal COBOL cancel command. IF you are having problems with these then you need to compile the programs with other options, or to use Thread-Local-Storage in your COBOL programs instead of Working-Storage.

In order to cancel program C you need to use com.microfocus.cobol.RuntimeSystem.cobcancel().

Now the above may be very tricky, as you can NOT cancel a program that is being used by another thread, so you need to know whether there is still any thread using a particular program before cancelling it. Use of semaphores/shared memory on this situation is common.

Apart from this I don't know what else you can do.







Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[WMK]

Not certain that it will work, but you say,

"...a COBOL program is run (using cobcall from mfcobol). The program runs fine for the first 110 times."

If you use the IS INITIAL phrase in the program that is called 110 times, it MIGHT free storage after each instance of that program is exited.

Bill Klein

 

[Dimandja]

Bill & Frederico,

We may have lost Chris temporarily. But, let's see what is happening here.

Chris is right about Microfocus issues with CANCEL (runtime error thrown) and RELEASE <connection-name> (precompiler error): it's a long (Microfocus) story which has to do with &quot;backward compatibility&quot;. I choose to trust Chris on this one.

About running and cancelling COBOL programs from Java (or any other language) threads, this has been solved many times over. Let me explain.

The problem in Chris' system seems to be that the &quot;110th&quot; run unit uses up the last memory available, while orphan COBOL run units are standing around &quot;hogging memory&quot;, after the threads that started them are long gone. The solution would have been to &quot;cancel&quot; the COBOL program during the thread &quot;destruction&quot;. Unfortunately, the latest Java Virtual Machine implementations do not guaranty the execution of the destructor; which leaves these COBOL run units stranded. In this scenario, a judiciously placed STOP RUN would tidy things up.

Which leads to this (better) solution. Suppose you could &quot;park&quot; a COBOL run unit: start a run unit which any thread of Java could use (in turn, of course). For example, whenever a thread (of Java) requests COBOL assistance, the thread would find the run unit and send it the request. You may well endup with one run unit servicing any number of Java threads. For faster throughput, one could &quot;park&quot; any (comfortable) number of COBOL run units to be used (by any thread, in any language) when needed.

That is how this problem was successfully solved on many computer systems (most notoriously on Tandem systems) in the last 25 years.

Dimandja

 

[chirpyform]

Thanks for all the replies. Dimandja was right in the last response although I'm not sure I followed the logic of the solution. If you could explain further I would be extremely grateful.

Chris
We have tried IS INITIAL and CANCEL and THREAD-LOCAL STORAGE. We have tried compiling the programs with reentrant(2) aswell.

 

[fredericofonseca]

Chris,

I am sure Dimandja will give you some pointers about his solution.


I have the following questions any way.
How long takes each thread to process. 1 sec, 1 min or longer?
And how many requests do you have per second/minute/hour?

And what are you trying to achieve with the whole setup?





Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[Dimandja]

Chris,

Let me start by saying that I have not ran COBOL programs from Java as you described. The only thing I can do as point you to some solutions that should work.


The premise (correct me if I'm wrong):

You have Java code that calls upon COBOL services, as needed by each thread. The problem is that there is no way to tell that a thread has been abandonned (and thus kill COBOL). This is because the client can &quot;leave&quot; the
application without notifiyng the Java code that the thread is no longer needed.


The results (an assumption):

Java waits for the client that started a thread to keep using it. In the meantime, another thread is requested, and the number of running COBOL units balloons until the bubble bursts.


Solution 1:

Bind the COBOL and Java code as a single run unit.


Solution 2:

Use COBOL DLLs.


Solution 3:

Create a known and controlled number of COBOL run units when the application is started or during the application run. Put some smarts in Java to &quot;know&quot; when and which run unit to use (which one is ready) to service the next
request (from any thread). The COBOL code will have to be context free in order to correctly process each request. The client will have to maintain the context and pass it to Java/COBOL in each transaction.


All these solutions will make you redesign the COBOL code: the new code must not &quot;remember&quot; any previous transactions.

Dimandja

 

[chirpyform]

Sorry I haven't replied, difficult at the weekend. Thanks for all the replies and the effort. To be extremely exact on what is happening:

We have an intra-net (Struts, Tomcat), with to keep things simple, 1 function, search. On the intra-net there can be up to say 100 users at the same time. The search from the intra-net (Windows) calls a server (Java, Unix). The server obviously should be able to be called infinitely.
The server:
With each call to the server, the server always calls the same COBOL program (cob.gnt) using cobcall. After the program has finished its task the server does a cobcancel.
Unfortunately the memry required to run cob.gnt is not freed at the end and so it accumulates with each call.

Chris

 

[WMK]

Are you aware of the run-time switch that determines whether COBOL does a &quot;physical&quot; or &quot;logical&quot; freeing of memory on a cancel? From one of the manuals,

&quot;l - Memory
Enables you to set the maximum amount of memory to be made available to the run-time system, or to cause the run-time system to perform physical cancels instead of logical cancels.

Properties:
Default: The maximum number of bytes available to the run-time system.

Comments:
This switch is lower-case &quot;L&quot;, not upper-case &quot;I&quot;.

The format of this switch is lnnnnnn, where nnnnnn is the amount of memory in bytes to be made available to the run-time system.

You can use this switch to limit the amount of memory the run-time system will use. This might be useful to enable you to tune your system.

By default the run-time system performs logical cancels unless all available memory has been used up. As far as your programs are concerned, the behavior of logical and physical cancels is identical, but logical cancels are faster. A logical cancel flushes all file buffers but does not release any memory. To force all cancels to be physical, you must specify this switch with parameter zero; for example:

+l0
By default, when the run-time system requires memory space it checks that the new request does not exceed the available memory. If it does, the memory that should have been freed by any cancels is freed and the run-time system repeats its request for memory. The run-time system loads programs that have been logically canceled in preference to reloading from disk.

Statically linked COBOL programs cannot be physically canceled because they cannot be removed from memory.

Duplicate entry point names are not allowed in statically linked programs; you must ensure that all such programs have unique entry point names.

Logical cancels behave in the same way as these physical cancels under statically linked programs. Therefore, an application developed using .int and .gnt files with logical cancels should exhibit the same behavior when generated as object code files and statically linked. However, if you used physical cancels and duplicated entry point names while developing the application, the application might fail to static link.

See Also:
default_cancel_mode run-time tunable &quot;

***

I don't know if this will help you at all, but it MIGHT.



Bill Klein