Highlighted
Absent Member.
Absent Member.
3017 views

OutOfMemoryException

Jump to solution

I am get this error after 15 minutes.  

Can I control the loading process?

Is there a document that describes the loading process?

ProcessRun: tmp = C:\ACCOUNTS\DEV10\IO\MGR01.io

ProcessRun: runProg = C:\MF-SYSTEM\WORKBENCH\BIN\ORDERMGT.EXE

ProcessRun: runProg = C:\MF-SYSTEM\WORKBENCH\BIN\ORDERMGT.EXE /P:C:\ACCOUNTS\DEV

10\IO\MGR01.io /D:C:\LISTENER\DEV10\DEV10.CONFIG

Unhandled Exception: OutOfMemoryException

Exception of type 'System.OutOfMemoryException' was thrown.

at Void  ORDERMGT.Main._MF_PERFORM_4_642(Int32 start_end)

at Int32  ORDERMGT.Main.Main()

at Int32  ORDERMGT.Main._MF_ENTRY()

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: OutOfMemoryException

Jump to solution

Customer opened up a support incident for this problem of running out of memory when loading a large managed code program in a .dll.

I will post the solution to the reported issue here for sake of completeness.

The problem really had nothing to do with the actual size of the program but it was caused by some overlapping perform ranges and errant go to statements that referenced paragraph labels which were outside of the current perform range.

This can cause the compiler to generate incorrect code as it tries to place the referenced paragraph or section into the same method as the paragraph or section where the go to statement resides.

program structure looked something like this. (only program > 150K lines)

100-start.

      perform 200-process thru 200-exit

      perform 300-process thru 300-exit

      stop run.

200-process.

      perform whatever

      perform whatever2

      if something

         go to 300-exit

      end-if

200-exit.

     exit.

300-process.

      perform whatever3

      perform whatever4

      go to 300-exit

300-exit.

     exit.

-----------------

The problem was go to 300-exit instead of 200-exit in the 200-process paragraph.

There is a directive called RESTRICT-GOTO which will flag these kind of errors when sections are being used but it does not work when only paragraph ranges are being used.

Development is currently looking at providing some type of automated analysis of this type of problem.

View solution in original post

0 Likes
7 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: OutOfMemoryException

Jump to solution

What product and version number are you using?

It looks like managed code so I am assuming Visual COBOL or Enterprise Developer?

How are you starting the program?

Can you run it under control of the debugger?

Thanks.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: OutOfMemoryException

Jump to solution

Visual Cobol for visual studio 2012.

No I can not run with the debugger.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: OutOfMemoryException

Jump to solution

So the application was compiled with Visual COBOL for Visual Studio 2012.

Are you running the application on this same development system or are you running it under COBOL Server 2012 on a different computer?

I am unsure of the question that you are asking about program loading.

What is it that this program is doing?

If the program has been running for 15 minutes before the out of memory error occurs then most likely the application is continuing to grow up until this point either because of recursive processing or it is calling additional modules.

Can you please clarify what the program is doing up until the point of error?

It is likely that you will have to open up a support incident with MF Customer Care for this problem as we will most likely need to set up tracing and/or get a recreate of the problem to run in-house.

Thanks.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: OutOfMemoryException

Jump to solution

I am running on the same machine as the program was compiled on.

Loading a large program.

Are subroutines added to the program as they are called?

Are there tips to breaking up large programs?  Will the use of SECTIONS in the PROCEDURE DIVISION help?

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: OutOfMemoryException

Jump to solution

It is hard to give suggestions without seeing the program in question.

If you are dynamically calling subprograms that are in other assemblies, then those assemblies will be loaded into the same process space as the calling program at the time they are called.

If you are statically calling subprograms that are in other assemblies and the reference to the assemblies can be made at compile time then these assemblies will be loaded when the application starts.

If you open up the Windows Task Manager while the program is running you will be able to monitor the process size as it grows.

Splitting up the procedure division into sections and paragraphs can change how the compiler generates the code but it is unlikely to help in this situation as all of the code will be loaded when the program is run.

Do you have any large data areas in the program like tables that may have large data records with many occurrences, etc.

What is the size of the .EXE file that is produced for this application?

What is the program doing when the Out of Memory error occurs?

Is it calling a specific module or does this error occur in different locations of the application.

If you would like us to look at the application, please open up a support incident with Customer Care.

Thanks.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: OutOfMemoryException

Jump to solution

The program is loading a large subroutine when this problem occurs.

Is there a limit to "process space"?   If so how big.

when compiling with native mode data 10,845, 704  lits 43,312 code 3,621,417 

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: OutOfMemoryException

Jump to solution

Customer opened up a support incident for this problem of running out of memory when loading a large managed code program in a .dll.

I will post the solution to the reported issue here for sake of completeness.

The problem really had nothing to do with the actual size of the program but it was caused by some overlapping perform ranges and errant go to statements that referenced paragraph labels which were outside of the current perform range.

This can cause the compiler to generate incorrect code as it tries to place the referenced paragraph or section into the same method as the paragraph or section where the go to statement resides.

program structure looked something like this. (only program > 150K lines)

100-start.

      perform 200-process thru 200-exit

      perform 300-process thru 300-exit

      stop run.

200-process.

      perform whatever

      perform whatever2

      if something

         go to 300-exit

      end-if

200-exit.

     exit.

300-process.

      perform whatever3

      perform whatever4

      go to 300-exit

300-exit.

     exit.

-----------------

The problem was go to 300-exit instead of 200-exit in the 200-process paragraph.

There is a directive called RESTRICT-GOTO which will flag these kind of errors when sections are being used but it does not work when only paragraph ranges are being used.

Development is currently looking at providing some type of automated analysis of this type of problem.

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.