Highlighted
Absent Member.
Absent Member.
2032 views

Mixing NetExpress build gnts and Visual Cobol build native dlls

Jump to solution

[Migrated content. Thread originally posted on 13 April 2011]

If I build a native Visual Cobol dll and replace the previously built Netx5.1 gnt in a deployed env. would you expect the Netx code to be able to interact with the VC dll as it did with the gnt ? In essence can you build some of your code with Netx 5.1. and some with native Visual Cobol and get the two to interact ? This would allow a gradual transition to V.Cobol if it works ok.


e.g xyz.cbl prevoously generated xyz.gnt
rebuild xyz.cbl with VC to produce xyz.dll

remove xyz.gnt from the deployment area and replace with xyz.dll - would you expect this to work ?
0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Mixing NetExpress build gnts and Visual Cobol build native dlls

Jump to solution
No I would not expect this to work as Net Express and Visual COBOL use two different run-time systems and two different licensing techniques.

I just tried a test here where a NX 5.1 EXE calls a Visual COBOL .DLL and it failed to load properly.

View solution in original post

0 Likes
6 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Mixing NetExpress build gnts and Visual Cobol build native dlls

Jump to solution
No I would not expect this to work as Net Express and Visual COBOL use two different run-time systems and two different licensing techniques.

I just tried a test here where a NX 5.1 EXE calls a Visual COBOL .DLL and it failed to load properly.

View solution in original post

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Mixing NetExpress build gnts and Visual Cobol build native dlls

Jump to solution
ok well at least that fits in with my findings too - as I found that the dll didn't load properly too - shame as it would have allowed a piece meal transition.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Mixing NetExpress build gnts and Visual Cobol build native dlls

Jump to solution
if we deployed both runtimes and both license services would it work ?
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Mixing NetExpress build gnts and Visual Cobol build native dlls

Jump to solution
Providing your code does not use any pre-processors or ecm's, then you could try taking you .int's from Net Express and generate this to a .obj by hand.

For example if you had "a.int" from Net Express using Visual COBOL you could generate a .obj from it..
cobol a.int omf(obj);

Then you can use "lib" or "cbllink" to create a .dll or .exe.
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Mixing NetExpress build gnts and Visual Cobol build native dlls

Jump to solution

if we deployed both runtimes and both license services would it work ?


No, only one copy of the run-time system can be loaded per process.
The run-time system has the same name under Net Express and Visual COBOL, cblrtss.dll or cblrtsm.dll.

It's all or nothing I'm afraid...
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Mixing NetExpress build gnts and Visual Cobol build native dlls

Jump to solution
These sort of things always concern me when trying to move a product (being my own development)foward.

There are already enough problems when you have to separate companies suppling Net Express applications for 1 site, where 1 application can call into the other.

This isn't even supported well within the same product line for example NX 5.1 Wrappack 3 applications can break running under NX 5.1 Wrappack 5.

You try and ask a software house "Hey look guys, I want to Ship NX 5.1 Wrappack 5, can you go and recompile (and make changes to your app)so our applications can work in harmony on the customer site.

The same issue is going to arise moving forward to Visual COBOL, it's not trivial task moving from one development environment to another and often you might want a hybrid state (Part NX 5.1 part Visual COBOL).

It's so important that Micro Focus need to take great care in NOT breaking bakward/foward compatability otherwise this becomes too greater risk.

Regards

Neil
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.