We are upgrading an application written in Net Express using Dialog screensets to Visual Cobol using Windows forms.
In Net Express:
we have one project and the main .exe calls sub programs generated as .int's using the CALL statement. Some of the sub programs use screensets, some don't - they just run reports or process data. After each call statement we have a CANCEL statement. There is always only one entry point in each program.
In Visual Cobol:
we now have one solution containing several Windows Forms projects.
We also have numerous projects, one for each report or utility program from the Net Express project. All these projects have been set up as managed and contain one .cbl file which is a COBOL program (not a class), generated as a .dll, so each .dll contains just one program. All we did for each report or utility program from the Net Express was to set up a new managed class library project, delete out the code auto generated by Visual Studio and copy and paste the .cbl from Net Express.
These .dlls are called from the Windows Forms projects. To call these .dlls we have the switch loadFromRemoteSources enabled="true" srt in the APP.config file for the form projects.
The problem is: when we call one of these .dll's with, say, CALL "REPORT1"... and then use CANCEL "REPORT1" the CANCEL statement does not release the .dll from memory, which leads to numerous issues because the next time the program is called it is not in its initial state. These .dlls are not released until the appication is exited.
Am I correct in thinking that CANCEL does not work on managed COBOL programs generated as .dll's and to get arounf this we have to use the IS INITIAL clause in the PROGRAM-ID paragraph?
I did search the forum for similar problems but the posts all seemed to relate to slightly different scenarios.
I also notice that some .dll's loaded using CALL seem to be loaded more than once, ie the .dll file is opened more than once. Why would this be.
We are using Visual COBOL 2.1 for VIsual Studio 2010. We have not yet updated to a later version, we are still using Windows XP until later this year.