Skip to main content

During mass data processing in the following constellation, the memory consumption increases continuously. When the 2GB limit is reached, the runtime crashes.

Prog1

    perform many times

                 read file

                 call "Prog2"

    end-perform

Prog2 (not with "is-initial" because the last state should stay in memory)

   "heavy I-O" , this means: open / read / rewrite / close many files and records

In the windows taskmanager we can see how the memory usage of the runtime-process is constantly increasing. In the debugger the memory consumption (u) "overhead" increases.

This is not the case in a local environment where the files are not addressed by AcuServe notation (@srv:).

Has anyone seen this before?

Runtime & AcuServe Version 10.2.0 as well as 10.2.1

During mass data processing in the following constellation, the memory consumption increases continuously. When the 2GB limit is reached, the runtime crashes.

Prog1

    perform many times

                 read file

                 call "Prog2"

    end-perform

Prog2 (not with "is-initial" because the last state should stay in memory)

   "heavy I-O" , this means: open / read / rewrite / close many files and records

In the windows taskmanager we can see how the memory usage of the runtime-process is constantly increasing. In the debugger the memory consumption (u) "overhead" increases.

This is not the case in a local environment where the files are not addressed by AcuServe notation (@srv:).

Has anyone seen this before?

Runtime & AcuServe Version 10.2.0 as well as 10.2.1

Update:

The cause is that each time prog2 is called, files are opened and closed again.
With the following method additional memory is not allocated with every call:


Prog2
01 call- flag pic 9 value 1.
88 first- call value 1, false zero.
….
if first- call
open i- o files
set first- call to false
end- if

* do not close files when exit !

Once the memory has been allocated by the "open i- o", it will never be released. (not even with cancel all)
You have to finish the runtime.

During mass data processing in the following constellation, the memory consumption increases continuously. When the 2GB limit is reached, the runtime crashes.

Prog1

    perform many times

                 read file

                 call "Prog2"

    end-perform

Prog2 (not with "is-initial" because the last state should stay in memory)

   "heavy I-O" , this means: open / read / rewrite / close many files and records

In the windows taskmanager we can see how the memory usage of the runtime-process is constantly increasing. In the debugger the memory consumption (u) "overhead" increases.

This is not the case in a local environment where the files are not addressed by AcuServe notation (@srv:).

Has anyone seen this before?

Runtime & AcuServe Version 10.2.0 as well as 10.2.1

I suspect this is due to how the runtime deals with files opened multiple times. When it can detect that the file is the same (usually using an inode or some other unique aspect of a file), it only has the file open once. But when the file is remote, it most likely can't detect that the file is the same as was previously opened.

I suspect your new logic is more correct in any case.

During mass data processing in the following constellation, the memory consumption increases continuously. When the 2GB limit is reached, the runtime crashes.

Prog1

    perform many times

                 read file

                 call "Prog2"

    end-perform

Prog2 (not with "is-initial" because the last state should stay in memory)

   "heavy I-O" , this means: open / read / rewrite / close many files and records

In the windows taskmanager we can see how the memory usage of the runtime-process is constantly increasing. In the debugger the memory consumption (u) "overhead" increases.

This is not the case in a local environment where the files are not addressed by AcuServe notation (@srv:).

Has anyone seen this before?

Runtime & AcuServe Version 10.2.0 as well as 10.2.1

In the original case, I changed the logic. That's okay now.
But I still have a special routine that works similarly. The files used there are the same, but the file path are constantly changing because the files are in different subdirectories. Here I could only help myself by dividing the processing into different blocks and starting a separate runtime session per block.
Perhaps it would be helpful to have a way to tell the runtime that it frees up the used memory for unused (opened) file handles.
Terms & ConditionsAccessibility statement