Highlighted
Absent Member.
Absent Member.
2129 views

Net Express to Visual Cobol migration.

Jump to solution

Hi

We have a set of 2 programs , Both the programs have Multiple Entry Points. We are trying to Migrate them to Visual COBOL and club them in to DLL. So that they can be consumed by .NET. 

While doing so we are following an approach of creating a wrapper class as mentioned below:-

1. We have created an Native Link Library project and added all 7 programs and compiled them. Compilation was successful and it created an Native Dll. 2. Now we have created a Managed Class library project and added a Wrapper Class program. Where we are making calls to Entry Point of both the programs.

3. Also created an Client Managed Program in one more project of the solution. To Create an instance of class and invoke the methods of the class.

The Startup project is Client Managed Program project.

While Executing it  we are getting error 173 - Program not found at the Line where we are making call to Entry Point of Native Program.

Following option we have tried to resolve this:

1. Setting an PP procedure pointer in the Class program to Native.DLL, But some how we are still getting the same error 173.

2. Using the APP.Config File in the Managed Project for setting the PATH variable of the NAtive DLL, Still the same error.

3. Setting the ENTRYNAMEMAP variable with the MFENTMAP file in the APp Config file,

But the error remains the same.

Please let us know where we are going wrong, Also if anyone can share an example of the same situation/problem.

Thanks 

Charan

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

The one other item that you might try is to create a dummy COBOL program with the program-id that is the same as the name of the .dll and contains just a goback statement and add this to your native .dll. Make this the main entry point and then instead of using the set pp to entry statement just do a call "dllname" which will load the .dll.

If that doesn't work then I would suggest that you open up a support incident with Customer Care so that we can investigate. If you put my name in the description then it should get routed to me. I will need an example of what you are trying to do.

Thanks.

View solution in original post

0 Likes
4 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Try setting the CASE directive on in the native project so that entry points will not be converted to uppercase. If you do not set this on then you will have to call the programs name as uppercase line call "SUBPROG".

The 173 error can occur if a dependency of the COBOL .dll is also not found so make sure that the native project is set to link dynamic on the link property tab so that it knows where to find the COBOL run-time system. If the native COBOL is dependant on other .dlls then they should also be located within the PATH.

Also make sure that the target CPU type of the managed programs is set to the bitness of the native .dll instead of anyCPU. If the native .dll is x86 then the managed projects should be x86 as well.

Thanks.

0 Likes
Highlighted
Absent Member.
Absent Member.

Chris

I have tried all the Options mentioned by you, Still getting the same error of not able to find the Entry point of the program. 173 error is coming for the same too.

I have Changed the Link option for Native from Shared to Dynamic.

Used the CASE directive for Native DLL project.

Also the native DLL is present in the Debug folder of Managed Project.

The Cpu type for all of them is set to x86.

From managed program i am creating an object of managed Wrapper class and than calling the NAtive Program's Entry point.

Still getting the same error.

Let me know if we need to setup something else too. Also if you have any solution for this.Please share.

Thanks

Charan

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

The one other item that you might try is to create a dummy COBOL program with the program-id that is the same as the name of the .dll and contains just a goback statement and add this to your native .dll. Make this the main entry point and then instead of using the set pp to entry statement just do a call "dllname" which will load the .dll.

If that doesn't work then I would suggest that you open up a support incident with Customer Care so that we can investigate. If you put my name in the description then it should get routed to me. I will need an example of what you are trying to do.

Thanks.

View solution in original post

0 Likes
Highlighted
Absent Member.
Absent Member.

Chris,

Creating a Dummy program solved my problem. Instead the Set PP entry to DLL is also working.

Thanks

Charan

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.