165 Version number incompatibility

[Migrated content. Thread originally posted on 17 June 2011]

Hello,

I am getting run time error '165 Version number incompatibility' in a dll file of cobol code when a call statement is executed during animation. The calling code is a windows executable (formed by linking cobol and c objects)

I am developing a netexpress project that uses couple of c objects that are generated using visual studio express 2010.

many of the default windows libraries such as kernel32.lib user32.lib etc come installed with Nx5.1 and visual studio as well. Also both have a version of the linker (LINK.exe). Its very obvious that the linker versions are different (10 with VS and 6 with Nx51). There are 2 versions of the link.exe in the Nx5.1 installation one at /bin and the other at /bin/linker why is that ?
Will the cobol run time system be ok with code produced by visual studio using its set of files and some code from Nx5.1 library files. Which version of the linker should Nx5.1 invoke.

Could you please clarify what basic considerations do I need to take into account to avoid such errors. Whould it be ok to mix c objects produced from VS 2010 that use its version of lib files and cobol objects that use lib files from Nx5.1 installation ?

Thanks in Advance
PTeng

Just to further add that I have compiled all the code using below libs

Searching C:\\openUTM-Server\\sys\\libwork.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\kernel32.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\user32.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\gdi32.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\winspool.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\comdlg32.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\advapi32.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\shell32.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\ole32.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\oleaut32.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\uuid.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\odbc32.lib:
Searching C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\lib\\odbccp32.lib:
Searching C:\\Program Files\\Microsoft Visual Studio 10.0\\VC\\lib\\msvcrtd.lib:
Searching C:\\oracle\\product\\11.2.0\\dbhome_2\\RDBMS\\XA\\oraxa11.lib:
Searching C:\\Program Files\\Micro Focus\\Net Express 5.1\\Base\\Lib\\cblrtss.lib:

but when the cobol code is compiled into an exe or .dll using the same libs (unfortunately the verbose in Nx unlike VS does not give u the path of the libs its searching) and the invoked i get the 165 error

PTeng

[Migrated content. Thread originally posted on 17 June 2011]

Hello,

I am getting run time error '165 Version number incompatibility' in a dll file of cobol code when a call statement is executed during animation. The calling code is a windows executable (formed by linking cobol and c objects)

I am developing a netexpress project that uses couple of c objects that are generated using visual studio express 2010.

many of the default windows libraries such as kernel32.lib user32.lib etc come installed with Nx5.1 and visual studio as well. Also both have a version of the linker (LINK.exe). Its very obvious that the linker versions are different (10 with VS and 6 with Nx51). There are 2 versions of the link.exe in the Nx5.1 installation one at /bin and the other at /bin/linker why is that ?
Will the cobol run time system be ok with code produced by visual studio using its set of files and some code from Nx5.1 library files. Which version of the linker should Nx5.1 invoke.

Could you please clarify what basic considerations do I need to take into account to avoid such errors. Whould it be ok to mix c objects produced from VS 2010 that use its version of lib files and cobol objects that use lib files from Nx5.1 installation ?

Thanks in Advance
PTeng

PTEng,

We strongly recommend keeping built C and COBOL code in separate execution units (in Windows terms, .exe or .dll). In particular the COBOL runtime makes use of the native C runtime, NetExpress is not built with VS2010, and you are probably experiencing the results of trying to use two different C runtimes within the same execution unit.

We also recommend ensuring that any memory allocated within a given execution unit is (in the fulness of time) freed within that same execution unit. Freeing memory in COBOL that has been allocated in C, and vice versa, are not supported.

Regards,
Chris

[Migrated content. Thread originally posted on 17 June 2011]

Hello,

I am getting run time error '165 Version number incompatibility' in a dll file of cobol code when a call statement is executed during animation. The calling code is a windows executable (formed by linking cobol and c objects)

I am developing a netexpress project that uses couple of c objects that are generated using visual studio express 2010.

many of the default windows libraries such as kernel32.lib user32.lib etc come installed with Nx5.1 and visual studio as well. Also both have a version of the linker (LINK.exe). Its very obvious that the linker versions are different (10 with VS and 6 with Nx51). There are 2 versions of the link.exe in the Nx5.1 installation one at /bin and the other at /bin/linker why is that ?
Will the cobol run time system be ok with code produced by visual studio using its set of files and some code from Nx5.1 library files. Which version of the linker should Nx5.1 invoke.

Could you please clarify what basic considerations do I need to take into account to avoid such errors. Whould it be ok to mix c objects produced from VS 2010 that use its version of lib files and cobol objects that use lib files from Nx5.1 installation ?

Thanks in Advance
PTeng

One thing I see is that you are linking with the static run-time library (cblrtss.lib), which might be problematic if you are then linking with later C libraries than VC6.

Also, depending on what options you used when linking with the static run-time library, then you may not have support for doing dynamic calls built in into your executable. That is what the error 165 suggests. If you want to use static linking then using the litlink call convention (8) for calls from COBOL would make sure everything was fully resolved at build time. What happens if you link your code with the shared run-time library?

[Migrated content. Thread originally posted on 17 June 2011]

Hello,

I am getting run time error '165 Version number incompatibility' in a dll file of cobol code when a call statement is executed during animation. The calling code is a windows executable (formed by linking cobol and c objects)

I am developing a netexpress project that uses couple of c objects that are generated using visual studio express 2010.

many of the default windows libraries such as kernel32.lib user32.lib etc come installed with Nx5.1 and visual studio as well. Also both have a version of the linker (LINK.exe). Its very obvious that the linker versions are different (10 with VS and 6 with Nx51). There are 2 versions of the link.exe in the Nx5.1 installation one at /bin and the other at /bin/linker why is that ?
Will the cobol run time system be ok with code produced by visual studio using its set of files and some code from Nx5.1 library files. Which version of the linker should Nx5.1 invoke.

Could you please clarify what basic considerations do I need to take into account to avoid such errors. Whould it be ok to mix c objects produced from VS 2010 that use its version of lib files and cobol objects that use lib files from Nx5.1 installation ?

Thanks in Advance
PTeng

Hello Kelvin,

Thanks for your reply, It works now !! Removing cblrtss and linking to use dynamic / shared runtime seems to have done the trick.

Which version of visual studio do you recomend to use with Nx5.1 ? I can see that it has a VS-2008 shell.

I was already using litlink and call convention 8 in each thread of execution.

Having said that I am still using VS2010 libraries and the supplied linker (version 10) from microsoft and it seems to work.

Thanks
PTeng