Solved: Debugging - Micro Focus Community

pavlli · ‎2017-01-13

Hi,

please I have troubles with debugging. I have this situation:

compiled .GNT and .IDY file (can't use .INT, because program is called from Infor SunSystems and there must be GNT)
- I have checked "compile for debugging" and "enable multiprocess debugging"
then I start my app (Infor SunSystems) and connect to it from Visual Studio via Debug -> Attach to process, here I choose Micro Focus: Native Debugger Code
then when my program run, it will stop on first line, but when I hit F11 key, it runs thru to the end
BUT, and this is interesting, when this program called another program, which is still compiled in Net Express 5.1 debugging is working, F11 key move line by line in code in Visual Studio!
please, there must by some solution, how to debug correctly, mostly if programs compiled in Net Express, can be debugged in Visual Studio 🙂

Thanks for any help

Chris Glazier · ‎2017-02-01

You are setting mem-flags to a 1 which indicates that you wish to allocate shared memory.

In the docs under CBL_ALLOC_MEM it says:

The maximum size of shared memory is restricted by the operating system and the run-time system. The run-time tunable, shared_memory_segment_size, can be used to set the maximum size. The default is 65536, and the minimum is 8192 bytes.

So you are limited to 65636 unless you change this setting.

You can change the max shared memory by setting the run-time tunable shared_memory_segment_size.

The easiest way to change this is to create a config file and set the environment variable COBCONFIG to point to its name.

The file would contain:

set shared_memory_segment_size=60000

If you saved the above in file c:\temp\cobconfig.cfg and set environment variable COBCONFIG=c:\temp\cobconfig.cfg

then this would allow you program to allocate shared memory blocks of 600000 bytes.

If you are creating an .exe from your project then you can also add an application.config file to your project by right-clicking on the project and selecting add-->New Item and then choose application.config file.

Click on the app.config file to open the editor and then click on the run-time tunable configuration. Look for the option for Shared Memory-->Initial size of the shared memory block and change the value there.

Try again.

View solution in original post

Chris Glazier · ‎2017-01-17

The executables compiled with Net Express are not compatible with executables compiled with Visual COBOL. You cannot mix them in this manner and you cannot debug Net Express programs using Visual COBOL.

You will need to recompile your Net Express programs using Visual COBOL.

pavlli · ‎2017-01-23

Ok, we complie our whole project with Visual Studio. But CBL_DEBUGBREAK still trying to start Net Express, even we have this setting on:

Navigate in the Visual Studio IDE to Debug-->Options-->Just-in-Time and ensure that the MF Native Debugger is checked

Isn't problem, that we have Net Express and Visual Studio on same machine?

Chris Glazier · ‎2017-01-23

No there should not be a conflict with having Net Express and Visual COBOL installed on the same system as long as your system environment variables aren't set so that an incorrect copy of run-time .dlls would be located.

When CBL_DEBUGBREAK is called it will look in the system registry for the product of the run-time system in use and will locate the entry under the key [product-name]-->Config-->dynamic_debug_cmd_ptrace and will launch this command.

For the NX entry it will launch the NX IDE MFNETX.EXE. For the VC entry it will launch mfjitvs.exe.

As long as your application is compiled using a single product and it is locating the correct version of the run-time system cblrtsm.dll for that product it should launch the correct debugger.

pavlli · ‎2017-01-23

Ok, thanks, I will check our settings. Please can you write me proper PATH variable settings for Net Express and Visual Cobol, so I can check it also, if there is everything ok?

Thanks

Chris Glazier · ‎2017-01-23

The default location for the compiler and run-time system files:

NX:

C:\program files (x86)\Micro Focus\Net Express 5.1\base\bin

and

C:\program files (x86)\Micro Focus\Net Express 5.1\base\bin\WIN64

VC:

C:\program files (x86)\Micro Focus\Visual COBOL\bin

and

C:\program files (x86)\Micro Focus\Visual COBOL\bin64

I would recommend that you do not include these folders within your PATH or COBDIR settings at the system level. On the development computer when these products are launched it will read the correct product locations from the Registry and so should be set appropriately.

If you are running your compiled executables outside of the IDE either from a shortcut or a command prompt then I would recommend that you set the appropriate locations from within a .bat file before launching each one instead of setting it at the system level.

If you start a Net Express command prompt or a Visual COBOL command prompt and launch your application from there things should be setup automatically for you.

Just make sure that you don't start copying run-time files like cblrtss.dll or cblrtsm.dll into your application directories or system directories as then they are prone to be picked up in error when the application starts. On the development system you should keep all of the COBOL components in their respective install folders only.

pavlli · ‎2017-01-25

Thanks for all your help, but I think, I didn't explain our problem properly. We are developing module for Infor SunSystems. And SunSystems is complied in Net Express 5.1. And of course we are unable to change SunSystems GNT files.

Is there any possibility to combine these worlds - so SunSystems will be still NE Cobol and our module will be in VS Cobol? And in final client SunSystems instalation, all Cobol DLLs are in SunSystems folder. And when NE Cobol DLLs have same names as VS Cobol DLLs, they can't coexist in same place?

Or is there any solution for that? Our main reason why we are trying VS Cobol, is that we want to use .NET functions in our module.

Thanks

NeilH1 · ‎2017-01-25

Whatever initiates the starting process (PID) is going to determine the runtime used. So the first COBOL element to be used will load that (whatever it was compiled with) runtime into memory.

So if I have an executable for example is compiled for NX 5.1 any programs (.INT\GNT\DLL) loaded within that process MUST be compiled under NX 5.1, you can't mix them.

The only way,and I stand to be corrected, would be to spawn a new process that could use VS COBOL compiled files and perhaps pass it a file name etc in order to pass data across from something compiled in NX.

Both NX 5.1 and VS COBOL runtimes can exist on the same machine without any problem.

Neil

pavlli · ‎2017-01-25

Ok, thanks for explanation. But in this solution:

starter NX 5.1 compiled program
VS Cobol program will be called via CBL_EXEC_RUN_UNIT for new process (I suppose?)
but how will be path defined for example for cblrtsm.dll (have same name in NX 5.1 and VS Cobol)?

NeilH1 · ‎2017-01-25

This is all how that exe was compiled.

When you compile a COM component or executable it can be set to dynamic binding. Therefore when this executable is started, then embedded code will look in the registry in order to locate the runtime.

So if Net Express 5.1 is installed under C:\Program Files (x86)\NX51 and Visual COBOL Server under C:\Program Files (x86)VC , both have unique registry settings.

HKEY_LOCAL_MACHINE\SOFTWARE\Micro Focus\NetExpress\5.1\COBOL\5.1\Environment

HKEY_LOCAL_MACHINE\SOFTWARE\Micro Focus\Visual COBOL\2.3\COBOL\Environment

So if it's compiled dynamically bound the registry is used.

If it's not dynamically bound then the normal Windows search PATH is used. This in your case would present a problem, as the very first cblrtsm.dll it find it will load.

Be very careful of making sure there are no runtime files sitting in Windows\system32, as these will get loaded before the location in the registry.

I often come across poor installations when vendors have deployed cblrtsm.dll and other runtime files in WIndows\system32 on customer sites. I end up moving those applicable files into the vendors own solution in order that both products work.

I can't vouch if CBL_EXEC_RUN_UNIT will work in your scenario but it's a really easy little demo for you to create to prove the point.

The thing to remember out of all of this......you cannot have 2 different runtimes loaded into the same process. I don't know if CBL_EXEC_RUN_UNIT will still have NX51 runtime as a parent process I've not tried.

Neil

pavlli · ‎2017-01-25

Ok, I am testing it now. Just to be sure, in Visual Studio setup for dynamic binding is:

Project properties -> COBOL Link -> Run-time Model - Dynamic

And if in application folder is DLL library from NE Cobol (it's by default from Infor SunSystems, and I can't remove it), it's ok for Dynamic Binding? Or it's same problem as if DLL it's in Windows\system32?

NeilH1 · ‎2017-01-25

Must your newly compiled program reside in the same folder? Rather have it in a sub folder, or better still totally different folder.

If there are runtime files in the same folder this might not work as it has potentially the same problem as residing in Windows\system32.