New Ranks & Badges For The Community!
Notice something different? The ranks and associated badges have gone "Star Fleet". See what they all mean HERE
Highlighted
Absent Member.
Absent Member.
4100 views

How to Change Existing Program to Make it COM

Jump to solution

Hi

In our current project we are using 7 modules of Micro focus COBOL. There are 4 modules which are COM modules and having Compiler directive set as OOCTRL. Rest 3 modules are using Entry Points with DynamicWinAPI. And they all are clubbed in to an DLL. Which is used by C++ to call COBOL Modules. 

Now we are removing C++ and Upgrading from C++ to .NET.  Because of this change the above DLL will be consumed by .NET.

When we try to Register that DLL with REGSVR32 , We are getting error "DLL was loaded , But the DLLregisteryServer entry point was not found".

Do we have to change the existing code? and what needs to be changed?

Please suggest what we should do to rectify this problem.

Thanks

Charan

Tags (2)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

I have posted a sample for this on the thread that you created on the Net Express forum as this is really the product that you are using.

Please post any further correspondence to that thread.

Thanks

View solution in original post

0 Likes
9 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Hi Charan,

Adding the OOCTRL directive to a program does not automatically make it a COM server module. OOCTRL(+P) is required in both a COM Server and COM client in order to control the parameter passing required by COM.  In Net Express there was a wizard available which would automate the process of creating a COM module application that contained required class entries, a trigger program to register the class, type libraries and .reg files. This would create a COM server for your native COBOL programs.

In Visual COBOL the process is different and actually simpler. If you create your application as a managed .NET Class library assembly and set the option for use with COM Interop, it will automatically create a COM interface for all public methods in your class so that the managed .dll can be called from a COM client. Of course if you move you modules into managed code then there probably is no need to create it as COM as it could then be called directly from any .NET language.

Can you please clarify, how these existing modules were being compiled for COM previously and how are they being used in your application? Were you previously using Net Express to create these modules?

What is the current requirement for these modules, to be called by C# or some other .NET language?

Thanks

0 Likes
Highlighted
Absent Member.
Absent Member.

Hi Chris

Please let me know which wizard we should use to automate the process of creating a COM Module.

Please find answers to your questions:-

"how these existing modules were being compiled for COM previously"

  Out of 7 modules

  1. 4 are compiled with OOCTRL(++P) and they are used by COBOL to call .NET DLL.

  2. The other 3 modules are native COBOL programs, They are having Entry Points with DynamicWinAPI

"how are they being used in your application?"

They are clubbed into an DLL and that DLL is consumed by VISUAL C++.

"Were you previously using Net Express to create these modules?"

They were created using Net Express.

"What is the current requirement for these modules, to be called by C# or some other .NET language?"

We are upgrading Visual C++ to C#.NET  and Rewriting the C++ code in C#. So now C# need to consume the DLL. Which has to be COM or COM+ DLL.

So we wanted to know how we can create a COM or COM+ DLL for those 3 Native COBOL programs and Club all 7 modules into one single DLL?

I have tried creating new COM service for the COBOL module using new Service Interface wizard in Net Express 5.1.

Also when i have used the Service Interface wizard for an Native COBOL module to create COM interface. it creates an Triger program and a Class, But when we deploy it it creates a DLL for one single module.

So if we do the same process for 3 Native COBOL modules. we have 3 separate DLL  for them, So we have club all this DLL and that is not an easy task and not possible in Net Express.

Hope I am able to make it clear now.

Thanks

Charan

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

So if I understand correctly, you previously had 4 COBOL modules that were used as COM clients and 3 that were linked together into a native dll that was then called by your C++ application using LoadLibrary, etc. is that correct?

So what you are looking for is a way to repackage those 3 programs into a .dll that can be consumed by C#. You are posting this question to the Visual COBOL forum so I am assuming that you are talking about deploying this as a Visual COBOL application and not Net Express is that correct?

There are a couple different ways that you can go here.

If you do not have the requirement that these have a COM interface then you could load and call the native .dll directly from C# using the .NET P/Invoke technology. This involves creating a wrapper class to define the .dll name and entry points and then calling this from C#. This is documented from Microsoft and can be found here.

If you do have the requirement to have a COM interface for this then the easiest method in Visual COBOL is to create a managed .NET COBOL Class Library project and check the Register for COM Interop checkbox. In this class you would define your entry points that would be called by C# and when you build the project it will automatically create a COM Interop assembly that will be registered on your system using the Class name. You could call your native COBOL .dlls from this COM wrapper. There is an example of this here.

The third option in Visual COBOL is to recompile your existing native modules in a managed code Class Library and then they can be called directly from C# without any COM layer.

If you are still using Net Express then the wizard I am referring to is the Class Wizard and not the service interface one. This can be accessed from New-->File-->Class and then select COM Component. This will generate the required files for a COM interface and then you can call your native modules from within this.

Thanks.

0 Likes
Highlighted
Absent Member.
Absent Member.

Hi Chris

In our project earlier we were using a unmanaged DLL that was consumed by C++. Now we are migrating from C++ to .NET. So the same DLL can not be consumed by .NET.

The problem statement:-

The COBOL program "Prog1" inside the DLL is having 4 Entry points.

As read from some of the threads we are trying to create a COBOL COM wrapper Class from File -> New->CLASS->COM Component.

This will create a new class in a new Net Express project. then We tried to create 4 method using Class wizard in this Class for all entry points.

1. Like Method1 for Entry1

2. Method2 for Entry2.

Now we are not able to understand how to make a call to existing (Prog1) COBOL program for an entry points in the Method.

We also tried the below option:

Method 1()

          :declare in local storage of method 1

                   77 default-entry-point  procedure-pointer.

:Code in Mehtod

       set Default-Entry-point to entry "Prog1".  (in an method1)

                 and then call the Entry point.

                Call "Entry1" using

After this we compiled and build the Code and an DLL is created.

That DLL is registered using REGSVR32 and TILBIMP is doen for the same at .NET side.

Now when .NET tried to call MEthod1 after creating object of the Net Express Class.

We are getting an error 173 Called program not found in drive/directory.

Let us know where we are making mistake.

Thanks

Charan

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

I have posted a sample for this on the thread that you created on the Net Express forum as this is really the product that you are using.

Please post any further correspondence to that thread.

Thanks

View solution in original post

0 Likes
Highlighted
Absent Member.
Absent Member.

Hi Chris

We are trying to migrate the above 7 programs into Visual COBOL.

5 Modules out of the 7 modules are  Having Entry points defined and are called by .NET.

Rest 2 are calling an Web service by creating object of the .NET class and calling .NET methods.

You have mentioned above a solution in VIsual COBOL:-

"The third option in Visual COBOL is to recompile your existing native modules in a managed code Class Library and then they can be called directly from C# without any COM layer."

Let us know how we can do that.

Thanks & Regards

Charan

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

You can take existing procedural COBOL programs and add them to a managed code Class Library project. When you build the project they will be compiled to .NET assemblies containing classes and methods that can be accessed directly from other .NET assemblies written in COBOL, C# or VB.NET, etc.

If you compile these COBOL programs using the ilsmartlinkage directive the compiler will generate a class for each of the parameters in the linkage section which make it easier to call the program from a different language like C#.

Open up the Samples Browser from the Visual COBOL group on the Start menu. Select COBOL Book from the list on the left and then select C# Winbook on the right and open up this project. This demonstrates a C# WinForm application that calls a Legacy COBOL program using ilsmartlinkage to pass in parameters.

Thanks.

0 Likes
Highlighted
Absent Member.
Absent Member.

Hi Chris,

We have tried the methods mentioned by you. Following are some issues we are facing in doing so.

1. Create the Managed Code Class Library project.

   - We have Added all the programs in an managed code class library project and try to compile them.

   - While doing this we are getting error of MFOLE.CPY error. Because couple of programs are calling .NET     web service and trying to parse the XML response received from .NET.  How to resolve it, we are not sure.

2. Compile the program using Ilsmartlinkage directives.

  - We have added couple of programs and compiled them, we are getting COBOL.DIR directive not found error while building the Project/Solution.

 - Tried to find out how to set COBOL.DIR, But not able to extract much information.

Please let us know what are possible steps we should use to migrate Net Express Code to Visual Cobol.

Thanks

Charan

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Hi Charan,

Not all native COBOL programs can be moved to managed code as is. Most programs that use standard procedural COBOL language constructs can be moved without a problem.

Programs that use features such as the native OO syntax or class library support of Net Express, i.e.OLE class library, are not supported directly in managed code and would require some coding changes.

Calling a .NET Web Service from a managed client is much easier than doing this from a native client. You do not use the COM layer but simply add a Web Reference of the web service directly to your client project and instantiate the class.

I would suggest that you look in the Samples Browser under category Web Applications and Windows Communication Foundation for examples of this.

I am not sure what is causing the COBOL.DIR not found error. Are you setting the COBDIR environment variable within your project? Does this only happen when you are turning on ilsmartlinkage? How are you turning on ilsmartlinkage, project properties, program level, etc?

What other directives are you setting?

Thanks.

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.