Mixing NetExpress build gnts and Visual Cobol build native dlls

[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 ?

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.

[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 ?

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.

[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 ?

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

[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 ?

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

[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 ?

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.

[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 ?

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

[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 ?

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

[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 ?

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