[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Hi,
I'll have a hunt around to find someone who can help.
Please could you let me know which version of NE you are using.
Also, NE is quite a old product now. I would have thought you would be very much better off indeed using
Visual COBOL.
Kind Regards
Dr Alexander J Turner
Software Systems Developer Senior Principal
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Hi,
I'll have a hunt around to find someone who can help.
Please could you let me know which version of NE you are using.
Also, NE is quite a old product now. I would have thought you would be very much better off indeed using
Visual COBOL.
Kind Regards
Dr Alexander J Turner
Software Systems Developer Senior Principal
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Thank you, I appreciate it.
I am evaluating Net Express 5.1 and the idea is to recompile the existing COBOL modules and sub-programs as COM components and run them under .Net InterOP Services, in order to leverage the Legacy COBOL where it makes sense to do so. COM Scripts and called modules which will become COM components under .Net are fundamental to the current systems, and whichever PC COBOL system is decided on must support standard COM server/client. COM and DCOM are not essential, but IN Process server .DLLs are. The salvaged COBOL legacy must be used from both current desktops and proposed/exsting Web Pages (sometimes the same functionality in both environments) so COM is ideal for that.
Visual COBOL is not currently an option as it is more likely that C# will be used for new .NET development.
Regards,
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Thank you, I appreciate it.
I am evaluating Net Express 5.1 and the idea is to recompile the existing COBOL modules and sub-programs as COM components and run them under .Net InterOP Services, in order to leverage the Legacy COBOL where it makes sense to do so. COM Scripts and called modules which will become COM components under .Net are fundamental to the current systems, and whichever PC COBOL system is decided on must support standard COM server/client. COM and DCOM are not essential, but IN Process server .DLLs are. The salvaged COBOL legacy must be used from both current desktops and proposed/exsting Web Pages (sometimes the same functionality in both environments) so COM is ideal for that.
Visual COBOL is not currently an option as it is more likely that C# will be used for new .NET development.
Regards,
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Thank you, I appreciate it.
I am evaluating Net Express 5.1 and the idea is to recompile the existing COBOL modules and sub-programs as COM components and run them under .Net InterOP Services, in order to leverage the Legacy COBOL where it makes sense to do so. COM Scripts and called modules which will become COM components under .Net are fundamental to the current systems, and whichever PC COBOL system is decided on must support standard COM server/client. COM and DCOM are not essential, but IN Process server .DLLs are. The salvaged COBOL legacy must be used from both current desktops and proposed/exsting Web Pages (sometimes the same functionality in both environments) so COM is ideal for that.
Visual COBOL is not currently an option as it is more likely that C# will be used for new .NET development.
Regards,
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
If you give me your e-mail address I will send you a simple sample that does what you want.
When you are using the Class Wizard to generate the sources for a COM Server project you cannot just modify the source to add methods and properties without updating the associated type library.
To have Net Express automatically update the type library you need to use the Class Wizard to add the methods and data items that will be used in the call. (Edit->Class Wizard->Add Method.)
If you are simply looking for an easy way to wrap your COBOL procedural programs with a COM wrapper then you might want to look at the Interface Mapping Toolkit or IMTK as this allows you to do exactly that.
There is a tutorial in the help which takes you through various types of mapping including COM, called mapdemo.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
[quote]Chris Glazier originally wrote:
If you give me your e-mail address I will send you a simple sample that does what you want.
{pion}
Thank you Chris.
Could you please send it to: pion911@gmail.com
[quote]
When you are using the Class Wizard to generate the sources for a COM Server project you cannot just modify the source to add methods and properties without updating the associated type library.
To have Net Express automatically update the type library you need to use the Class Wizard to add the methods and data items that will be used in the call. (Edit->Class Wizard->Add Method.)\\
{pion}
Ah, I see. As there are a few dozen methods in the real COM components, adding them manually is not an attractive option. This is probably why my .dll builds OK but can't invoke a method... Thanks for the clarification.
I think this is the nub of my problem. It seems everything only works through the IDE. But there is no facility to batch compile in it as far as I can see. cbllink will allow me to link to a .DLL and it works fine as long as I have a Typelib (.RES) and include the necessary OLE support. (I understand now that my .DLL can't work because the methods were not added through the IDE and therefore haven't been built into the Typelib. This explains the fact that the Object Browser showed no methods too). Surely there is a flag somewhere that tells the compiler to generate .ODL? That would solve the whole problem. If I have 200 COM .DLL sources, I can't reasonably be expected to set up a project manually for each one. I would expect to be able to write a batch file (or have Micro Focus supply one) that addresses each stage (Compile and Generate ODL as a byproduct, MKTYPELIB using the generated ODL, Resource compile (if you really MUST... surely a MAKE file approach would be better?), Link as .DLL) Then I can edit the Source name (or provide a response list of sources) and away we go...
I am struggling with the IDE not because it is bad or doesn't work but because it caters for more things than I want, I am unfamiliar with it, and there is no simple explanation of the process, that I can find. For example, do I need a trigger file for an IN Process COM .DLL? (the documentation and the samples aren't clear and appear to contradict. If I build a COM Project it tells me it needs a trigger file and builds one, but the sample under SERVER\\DLL doesn't use one...) To be fair, I have never been able to get that server to work, even without modifying anything :-)
Hopefully your sample will clear this up once and for all. Thanks for that.
[quote]
If you are simply looking for an easy way to wrap your COBOL procedural programs with a COM wrapper then you might want to look at the Interface Mapping Toolkit or IMTK as this allows you to do exactly that.
{pion}
That was the first thing I did :-) It seemed like a lot of work for things that are already written as OO COBOL components and just need the right compile options.
[quote]
There is a tutorial in the help which takes you through various types of mapping including COM, called mapdemo.
{pion}
OK, I'll take another look. Thanks very much for your very helpful response.
Pion.
[/quote][/quote][/quote][/quote]
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
[quote]Chris Glazier originally wrote:
If you give me your e-mail address I will send you a simple sample that does what you want.
{pion}
Thank you Chris.
Could you please send it to: pion911@gmail.com
[quote]
When you are using the Class Wizard to generate the sources for a COM Server project you cannot just modify the source to add methods and properties without updating the associated type library.
To have Net Express automatically update the type library you need to use the Class Wizard to add the methods and data items that will be used in the call. (Edit->Class Wizard->Add Method.)\\
{pion}
Ah, I see. As there are a few dozen methods in the real COM components, adding them manually is not an attractive option. This is probably why my .dll builds OK but can't invoke a method... Thanks for the clarification.
I think this is the nub of my problem. It seems everything only works through the IDE. But there is no facility to batch compile in it as far as I can see. cbllink will allow me to link to a .DLL and it works fine as long as I have a Typelib (.RES) and include the necessary OLE support. (I understand now that my .DLL can't work because the methods were not added through the IDE and therefore haven't been built into the Typelib. This explains the fact that the Object Browser showed no methods too). Surely there is a flag somewhere that tells the compiler to generate .ODL? That would solve the whole problem. If I have 200 COM .DLL sources, I can't reasonably be expected to set up a project manually for each one. I would expect to be able to write a batch file (or have Micro Focus supply one) that addresses each stage (Compile and Generate ODL as a byproduct, MKTYPELIB using the generated ODL, Resource compile (if you really MUST... surely a MAKE file approach would be better?), Link as .DLL) Then I can edit the Source name (or provide a response list of sources) and away we go...
I am struggling with the IDE not because it is bad or doesn't work but because it caters for more things than I want, I am unfamiliar with it, and there is no simple explanation of the process, that I can find. For example, do I need a trigger file for an IN Process COM .DLL? (the documentation and the samples aren't clear and appear to contradict. If I build a COM Project it tells me it needs a trigger file and builds one, but the sample under SERVER\\DLL doesn't use one...) To be fair, I have never been able to get that server to work, even without modifying anything :-)
Hopefully your sample will clear this up once and for all. Thanks for that.
[quote]
If you are simply looking for an easy way to wrap your COBOL procedural programs with a COM wrapper then you might want to look at the Interface Mapping Toolkit or IMTK as this allows you to do exactly that.
{pion}
That was the first thing I did :-) It seemed like a lot of work for things that are already written as OO COBOL components and just need the right compile options.
[quote]
There is a tutorial in the help which takes you through various types of mapping including COM, called mapdemo.
{pion}
OK, I'll take another look. Thanks very much for your very helpful response.
Pion.
[/quote][/quote][/quote][/quote]
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Greetings,
(Sent example via e-mail)
The attached file is really a zip file.
I had to rename it to allow it to get past our e-mail server filter.
Please rename as zip and unzip it into your C: \\drive retaining the directory structure in the zip file.
Open c:\\testcomdll\\testcomdll.app in the IDE.
This was created using the Class wizard as an apartment threaded in-process COM Server.
The trigger program is necessary only for in-process servers as the trigger defines the OLE entry point required for COM.
All it does is load the main program when its entry point is called.
It looks like the following:
*> OLE server trigger (for in-process servers only)
*> WARNING: Do not add further entry points to this file
$set case
linkage section.
01 loadReason pic x(4) comp-5.
procedure division.
entry "DllOleLoadClasses" using by value loadReason.
*> OCWIZARD - start classes
*> Calling the class registers it as available to OLE clients
call "testcomdll"
*> OCWIZARD - end classes
exit program.
.
If you retained the directory structure of the zip file then you can register the testcomdll server by right clicking on the .reg file and selecting Register.
In this example I created the client program in the same project for ease of distribution.
After registering the server double-click on the callCOM.EXE in the build window to animate it.
It calls a single method in the COM server called testCALL using a single pic x(8192) parameter.
The method will move a value to this parameter and return.
When the client and server are in the same project like this, you can animate through the server code as well, otherwise you would have to place a call āCBL_DEBUGBREAKā in the server code in order to start animating.
I am unaware of any command line tools that we provide to generate the type libraries automatically.
The Class Wizard generates the .idl file automatically and this is built into the type library.
To see the commands that are executed in the IDE in order to build these files, select Build Settings from the Project menu and then highlight the desired file.
Example the Build settings for testcomdll.idl are as follows:
/cpp_cmd mfcpp.exe /cpp_opt "-r -u -I ." %FILENAME
Net Express has been around for over a decade and the COM support has not changed very much during that time.
I can tell you also that the COM support will not change in the future as this product is near the end of its life cycle.
Going forward, probably the best method of creating a COM interface to wrap around procedural native code .dlls today is to use Visual COBOL.
If you create a managed code class library and expose its methods as public and data as properties then you can create a COM wrapper by simply checking the Register for COM Interop option under properties.
You donāt have to deal with type libraries, everything is automated for you.
Visual COBOL supports the development of native unmanaged applications as well as managed applications so you can have both types available in the same solution.
Anyway, just food for thought :-)
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Great to see this has been answer.
To follow on from the Visual COBOL suggestions. Visual COBOL is being actively developed and the technology to interface procedural COBOL with classes and COM is being enhanced all the time.
Best wishes - AJ
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Great to see this has been answer.
To follow on from the Visual COBOL suggestions. Visual COBOL is being actively developed and the technology to interface procedural COBOL with classes and COM is being enhanced all the time.
Best wishes - AJ
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Thanks to both Alex and Chris for their responses. (I have added points to Micro Focus for friendly and useful help... :-)) Seriously, I really do appreciate the posts that have been made. Many thanks.
Chris, I'll load and test the Zip File and will comment back here when I've had a chance to see it. I understand your post and take your point that the NE 5.1 product is in its twilight. I considered your points about the legacy COBOL becoming managed classes under Visual COBOL but the the people I'm dealing with are not keen to make further serious investment into COBOL when their plan is to move off it. We haven't thought too much about cost yet but obviously C# is free and Visual COBOL is not... :-) Nevertheless, Visual COBOL has to be an option and I'll make sure it is on the table. The fact that managed and unmanaged code can both be developed or maintained from the same IDE is good, at least during transition. This avoids the need for a separate legacy IDE.
Will get back to you through this forum in a couple of days.
Thanks again,
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Thanks to both Alex and Chris for their responses. (I have added points to Micro Focus for friendly and useful help... :-)) Seriously, I really do appreciate the posts that have been made. Many thanks.
Chris, I'll load and test the Zip File and will comment back here when I've had a chance to see it. I understand your post and take your point that the NE 5.1 product is in its twilight. I considered your points about the legacy COBOL becoming managed classes under Visual COBOL but the the people I'm dealing with are not keen to make further serious investment into COBOL when their plan is to move off it. We haven't thought too much about cost yet but obviously C# is free and Visual COBOL is not... :-) Nevertheless, Visual COBOL has to be an option and I'll make sure it is on the table. The fact that managed and unmanaged code can both be developed or maintained from the same IDE is good, at least during transition. This avoids the need for a separate legacy IDE.
Will get back to you through this forum in a couple of days.
Thanks again,
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Thanks to both Alex and Chris for their responses. (I have added points to Micro Focus for friendly and useful help... :-)) Seriously, I really do appreciate the posts that have been made. Many thanks.
Chris, I'll load and test the Zip File and will comment back here when I've had a chance to see it. I understand your post and take your point that the NE 5.1 product is in its twilight. I considered your points about the legacy COBOL becoming managed classes under Visual COBOL but the the people I'm dealing with are not keen to make further serious investment into COBOL when their plan is to move off it. We haven't thought too much about cost yet but obviously C# is free and Visual COBOL is not... :-) Nevertheless, Visual COBOL has to be an option and I'll make sure it is on the table. The fact that managed and unmanaged code can both be developed or maintained from the same IDE is good, at least during transition. This avoids the need for a separate legacy IDE.
Will get back to you through this forum in a couple of days.
Thanks again,
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Hi Chris,
reporting back as promised :-)
I had no trouble in unpacking, installing, and running your test project, thanks.
My first impression was one of relief because the code was exactly what I expected to see :-)
After experimenting with it and checking various things I can draw the following conclusions:
1. My own attempts failed to work because I didn't build them through the IDE. (When I DID build a "cut down" version of one of the legacy components, it worked fine.)
2. The NE 5.1 provided example demo, probably DOES work. I didn't realise it needed to be double clicked to animate it. (I was using the step icon which I thought SHOULD work... anyway, you cleared it up by providing something that definitely did work as you described.)
I now have to consider the implications of what I have learned.
It is definitely not feasible for us to build a project and manually add methods/properties to it. We have hundreds of components and I believe there must be a batch solution.
1. Micro Focus OO COBOL COM components need to be built through the MF IDE (largely because there is no compiler switch to build the .ODL/.IDL and it apparently gets done when you add new properties and Methods through the IDE.) I have been looking for a utility which can generate .IDL from COBOL source and found a couple, but they are generally part of a larger package so I'll probably write one myself. Once it is possible to generate .IDL from source, it is possible to script a process that doesn't need the IDE. I see it as something along the following lines:
Create a MAKE file for each of the legacy components by generating it from a template. (It only needs to have the programID changed in it) We would need the COBOL source and the MAKE file for each component. Once that was available it is a single command to do the lot: NMAKE @BuildThese.txt
...where BuildThese is a generated text (response) file with some control parameters to NMAKE, and the names of all the components to be batch compiled.
The Make file template will do the following steps:
1. Create the .IDL file. (By analyzing the OO COBOL source, detecting properties and Methods. The necessary GUIDs for Typelib, Library, and Component can be assigned at the same time.)
2. Resource COMPILE the .IDL file to a .RES (OR MKTYPLIB it if you want/need a separate Typelib...)
3. Let cbllink do its stuff (something like...:
cbllink -d -rE -MMyComponent -OMyComponent.dll "MyComponent.cob" "MyComponent.res"
"dllserver.obj"
Notice there is no Trigger file. I don't believe it is necessary but if I'm wrong (and I'll find out when I test) it would be pretty easy to generate this from a template at the same time as the MAKE file is generated. The trigger file whould then be added in to step 3.
2. OTHER OBSERVATIONS:
1. The currently compiled .DLL is not loadable by other software. If you look at it with an Object Browser like OLEVIEW it fails. If you run Regsvr32 on it, it fails. It fails whether it is built for DEBUG or RELEASE, as soon as it is registered using the .REG file. In both cases it is because the library is not loadable, which looks like a problem connected with the use of the trigger file. I haven't been able to trace into the .DLL so I don't know at what point it calls the Trigger file entry point, or whether this is expected to be called by the calling application. (I didn't see you calling it in your code, so I guess it is internal.) Certainly, the method invoked worked fine.
2. Obviously, we will be invoking components from web pages and the desktop using COBOL, C#, and VB.Net. If these libraries can only be loaded by MF callers, that would be a show stopper. I haven't had time to try invoking the test method in the test .dll from another language but I seem to recall there being an example of a COM component being called from VB 4. I'll have another look at that. Calling it from C# would be through InterOP services and I'll check that out as well.
3. Once I have the MAKE process working, I'll try THAT .DLL as well and see if it is also "unloadable". (In theory, it shouldn't be, but the proof of the pudding...etc.)
OK, as you can see there is a fair bit going on and more to do.
If anyone else is trying to do what we are, I'll happily make the results of my efforts available, including the MAKE file template once I have it working.
The bottom line is to be sure that there is a viable solution if the clients choose Micro Focus.
Thanks again for your help.
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Hi Chris,
reporting back as promised :-)
I had no trouble in unpacking, installing, and running your test project, thanks.
My first impression was one of relief because the code was exactly what I expected to see :-)
After experimenting with it and checking various things I can draw the following conclusions:
1. My own attempts failed to work because I didn't build them through the IDE. (When I DID build a "cut down" version of one of the legacy components, it worked fine.)
2. The NE 5.1 provided example demo, probably DOES work. I didn't realise it needed to be double clicked to animate it. (I was using the step icon which I thought SHOULD work... anyway, you cleared it up by providing something that definitely did work as you described.)
I now have to consider the implications of what I have learned.
It is definitely not feasible for us to build a project and manually add methods/properties to it. We have hundreds of components and I believe there must be a batch solution.
1. Micro Focus OO COBOL COM components need to be built through the MF IDE (largely because there is no compiler switch to build the .ODL/.IDL and it apparently gets done when you add new properties and Methods through the IDE.) I have been looking for a utility which can generate .IDL from COBOL source and found a couple, but they are generally part of a larger package so I'll probably write one myself. Once it is possible to generate .IDL from source, it is possible to script a process that doesn't need the IDE. I see it as something along the following lines:
Create a MAKE file for each of the legacy components by generating it from a template. (It only needs to have the programID changed in it) We would need the COBOL source and the MAKE file for each component. Once that was available it is a single command to do the lot: NMAKE @BuildThese.txt
...where BuildThese is a generated text (response) file with some control parameters to NMAKE, and the names of all the components to be batch compiled.
The Make file template will do the following steps:
1. Create the .IDL file. (By analyzing the OO COBOL source, detecting properties and Methods. The necessary GUIDs for Typelib, Library, and Component can be assigned at the same time.)
2. Resource COMPILE the .IDL file to a .RES (OR MKTYPLIB it if you want/need a separate Typelib...)
3. Let cbllink do its stuff (something like...:
cbllink -d -rE -MMyComponent -OMyComponent.dll "MyComponent.cob" "MyComponent.res"
"dllserver.obj"
Notice there is no Trigger file. I don't believe it is necessary but if I'm wrong (and I'll find out when I test) it would be pretty easy to generate this from a template at the same time as the MAKE file is generated. The trigger file whould then be added in to step 3.
2. OTHER OBSERVATIONS:
1. The currently compiled .DLL is not loadable by other software. If you look at it with an Object Browser like OLEVIEW it fails. If you run Regsvr32 on it, it fails. It fails whether it is built for DEBUG or RELEASE, as soon as it is registered using the .REG file. In both cases it is because the library is not loadable, which looks like a problem connected with the use of the trigger file. I haven't been able to trace into the .DLL so I don't know at what point it calls the Trigger file entry point, or whether this is expected to be called by the calling application. (I didn't see you calling it in your code, so I guess it is internal.) Certainly, the method invoked worked fine.
2. Obviously, we will be invoking components from web pages and the desktop using COBOL, C#, and VB.Net. If these libraries can only be loaded by MF callers, that would be a show stopper. I haven't had time to try invoking the test method in the test .dll from another language but I seem to recall there being an example of a COM component being called from VB 4. I'll have another look at that. Calling it from C# would be through InterOP services and I'll check that out as well.
3. Once I have the MAKE process working, I'll try THAT .DLL as well and see if it is also "unloadable". (In theory, it shouldn't be, but the proof of the pudding...etc.)
OK, as you can see there is a fair bit going on and more to do.
If anyone else is trying to do what we are, I'll happily make the results of my efforts available, including the MAKE file template once I have it working.
The bottom line is to be sure that there is a viable solution if the clients choose Micro Focus.
Thanks again for your help.
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
I found a problem with the demo that I gave to you which is the reason you are having issues with REGSVR32 etc.
I originally created the demo under Windows 7 but I did not start the IDE with Administrator permissions.
This caused an error to occur when the Class Wizard was generating the resource file.
It did not add a reference to the type library so the .tlb was not being linked into the COM server.
The reason that it worked when the registry file was used is that the external .tlb file is specifically referenced.
Sorry about that.
I will e-mail a new version of the project with this problem fixed immediately...
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Chris Glazier originally wrote:
I found a problem with the demo that I gave to you which is the reason you are having issues with REGSVR32 etc.
I downloaded and ran the "new" version, thanks Chris. (It threw me for a moment when the string being returned from the server was blank, but it was easily fixed :-))
Using both the "old" and "new" versions of the project you posted I was able to investigate and put together the Batch Compilation Template I came here for originally.
In case anyone else may have a requirement to Batch Compile COM components, and as an appreciation for the help I have received, I'm making the template public. Here it is:
(NOTE: This is not definitive and may need adjustments for your particular environment/requirements. It has been tested with Chris's "testcomdll2" server and worked correctly, as well as several of my own components.)
################################################################################
# Control of Micro Focus NE 5.1 Build process
# for OO COBOL COM COMPONENTS.
#
# NOTE: The processes described here assume a Micro Focus NE 5.1 development
# environment is installed on the machine where the MAKES will be run.
#
# This MAKE file will make a COM Component, and each component
# should have one of these files generated for it.
#
# Process is as follows: (All of these actions are carried out by the Microsoft NMAKE Utility using
# the .MAK file for each component. The .MAK file is generated by editing
# this template.
# The edit consists of inserting the desired %progID% into it. (a "one line" change)
#
# For an IN Process COM Server running under Windows the "Trigger File" is NOT required, IF you
# are not using a GUI and you are working outside of the IDE, as we are here; (the IDE may have
# its own requirements.)
# The .DLL is loaded by the OS when it is instantiated. However, things may work differently in
# other environments, so if you think you need the Trigger File then it should be compiled to .OBJ
# as a pre-requisite. NOTE that all trigger files are the same so you could edit a template to do this.
# Include the trigger file .OBJ into step 5 if you are using a trigger file.
#
# 1. Edit the COBOL Trigger source template to the desired progName.
# 2. Compile the Trigger to .OBJ
# 3. Create the .IDL file for the target progID (This MAKE template uses an inhouse custom written
# utility which analyses the COBOL source and produces both .IDL and .REG files. (.REG is a spin-off
# and NOT required for further build steps.)
# There are a number of utilities available for generating .IDL/.ODL from COBOL, notably from OMG
# (CORBA), PRIMA Computing (NZ), and SOFTWARE AG.
# Because it is the Micro Focus Project IDE that builds this .IDL, rather than the compiler,
# it is not possible to build COM Components without a project, in the MF environment, UNLESS a
# different approach (like that shown here) is adopted.
# (As it states in the MF documentation, you MUST have a Project, to build a COM component.)
#
# 4. EITHER:
# (If you require a separate Typelib)
# Use MKTYPLIB on the IDL file (or MIDL compiler) to obtain a .TLB file
# OR:
# (The default, where the Typelib will be embedded in the target .DLL)
# Use the Microsoft Resource Compiler (RC) to compile the .IDL to a .RES file
# 5. Having provided the prerequisites, let cbllink do its job.
#
#
#
################################################################################
.SUFFIXES:
COBOL_PATH = C:\\Program Files\\Micro Focus\\Net Express 5.1\\base\\bin
#======================== ONE LINE to change here ================================
PROG_ID = %progID%
#=========================== That's it! ==========================================
ALL : "$(PROG_ID).DLL"
REBUILD : CLEAN ALL
CLEAN :
DEL "$(PROG_ID).DLL"
DEL "$(PROG_ID).LIB"
DEL "$(PROG_ID)_DLL.IDL"
DEL "$(PROG_ID)_DLL.TLB"
DEL "$(PROG_ID)_DLL.REG"
DEL "$(PROG_ID)_DLL.RC"
DEL "$(PROG_ID)_DLL.RES"
DEL "$(PROG_ID).OBJ"
# You can comment out lines by using the hash (US="number") symbol
#
# The first step is to produce an .IDL or .ODL file. I am using a utility I wrote to do this,
# but there are a number of commercial utilities which will parse COBOL and produce an .IDL
# Assuming you already have this available from some other source, comment out this step.
# STEP 1: PRODUCE .IDL and .REG (.REG should not be essential as Regsvr32 should do the same
# job, but tests showed that ClassID may not be registered so it is handy to have .REG)
# My utility produces both files.
#
# "$(PROG_ID).IDL" : "$(PROG_ID.CBL"
# COMIDLREG -i -r $(PROG_ID).CBL (You will need an equivalent, or an existing .IDL file which you
# can edit manually to include your properties and method signatures)
#
# STEP 2: CREATE A TYPELIB
"$(PROG_ID).TLB" : "$(PROG_ID).IDL"
MKTYPLIB.EXE /nocpp /win32 $(PROG_ID).IDL
# STEP 3: EMIT A TEXT FILE FOR THE RESOURCE COMPILER
"$(PROG_ID).RC" : "$(PROG_ID).TLB"
ECHO typelib $(PROG_ID).TLB > $(PROG_ID).RC
#
# If your component has a GUI you will need more in the .RC file. (See the .RC generated by the Project.)
# The above is the simplest possible .RC and contains no INCLUDES or C Header files. It works for
# IN Process COM servers with no GUI resources to load.
# STEP 4: CREATE THE .RES FILE SO THE TYPELIB CAN BE LINKED WITH THE .DLL
"$(PROG_ID).RES" : "$(PROG_ID).RC" "$(PROG_ID).TLB"
RC.EXE /r /i "$(COBOL_PATH)\\..\\INCLUDE" $(PROG_ID).RC
# STEP 5: CREATE THE COM SERVER .DLL using cbllnk from the command line.
"$(PROG_ID).DLL" : "$(PROG_ID).RES"
cbllink -d -rE -l -uCOBOL.DIR -M$(PROG_ID) -O$(PROG_ID).dll "$(PROG_ID).CBL" "$(PROG_ID).res" "dllserver.obj"
# Remember to make sure you have a COBOL.DIR file in the working directory. You only need ONE
# of these, but you will need a .MAK file (derived from this template) for each component you wish to
# batch compile. Typically, you would write a script or (COBOL?) program to process each of the
# components by generating a .MAK file for it from this template, and adding its name to a
# response (text) file for NMAKE. Use a working directory to generate the MAKE files into, add the
# COBOL source of each component, the COBOL.DIR file, and then it is just a single command to
# batch compile everything: NMAKE @response.txt (or: NMAKE progname.MAK to build a given component.)
# The NMAKE Utility will run through all of the steps above for each progID it encounters in the
# response file, and the .DLLs will be placed in the working directory, along with Typelibs, .IDL,
# and .RES/.RC files.
#
# It is pretty easy to tailor the above for your specific needs (for example, add a step to run .REG)
# and interested parties are referred to the documentation on the Microsoft MAKE and NMAKE utilities.
OBSERVATIONS:
1. As a newcomer to the Micro Focus IDE it was difficult to decipher what the background processes were.
To be fair, most users don't care, but if there is a batch compilation requirement where things must run from a command line, it needs to be understood. I have spent the last two and a half weeks trying to deduce what the background process for COM is in this environment, and the details of it. A simple document addressing batch compilation could avoid that.
It wasn't immediately apparent or clear what the Trigger File is for and whether it was essential or not.
I couldn't find references to it in code or examples and I still don't know quite why it is there :-).
(I suspect it is so that GUI resources can be loaded, but I don't "know".) For your test project, I ignored it
in the MAKE process (in fact, I tried building both with and without it and got the same correct results each time)
and the .DLL produced runs exactly as the one produced by the IDE, whether it has the trigger file compiled into it or not. (I registered the MAKE built .dll and then ran the TestCOM process from within the project. It worked fine, instantiating itself and returning a string from the test method. (I made sure the string returned from the Project built server and the string returned from the MAKE built server were different, so I could be sure which component was being accessed.)
2. I found a number of things that seemed "odd" to me but I won't elaborate here. I think some of it stems from the very visible C mind set that is behind this software. Never mind, programmers never agree on approaches and the only real criterion is whether it works or not :-). There is no question that the MF software works.
3. The help and support from a free forum is outstanding and a credit to Micro Focus as a company. It says a lot about attitude and that is very important when selecting a software vendor.
My own original problem (which was how to deal with several hundred COM components all with at least a dozen methods in them) is now solved and I can report to the clients that there is no reason why they can't go for Micro Focus, if that is their choice. I know there are some favoured approaches and vendors and one COBOL so far has had to be eliminated because of lack of OO and COM support.
The major mistake I made was not realizing that Methods must be added to server source through the IDE so they can be registered and generated into IDL. Chris pointed me at that and from then on things went better :-) Because this is not a viable approach for dealing with existing code it forced me to find another way.
I think this thread can be closed as "answered" and thanks again to Chris Glazier for his willing and capable support.
Regards,
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Chris Glazier originally wrote:
I found a problem with the demo that I gave to you which is the reason you are having issues with REGSVR32 etc.
I downloaded and ran the "new" version, thanks Chris. (It threw me for a moment when the string being returned from the server was blank, but it was easily fixed :-))
Using both the "old" and "new" versions of the project you posted I was able to investigate and put together the Batch Compilation Template I came here for originally.
In case anyone else may have a requirement to Batch Compile COM components, and as an appreciation for the help I have received, I'm making the template public. Here it is:
(NOTE: This is not definitive and may need adjustments for your particular environment/requirements. It has been tested with Chris's "testcomdll2" server and worked correctly, as well as several of my own components.)
################################################################################
# Control of Micro Focus NE 5.1 Build process
# for OO COBOL COM COMPONENTS.
#
# NOTE: The processes described here assume a Micro Focus NE 5.1 development
# environment is installed on the machine where the MAKES will be run.
#
# This MAKE file will make a COM Component, and each component
# should have one of these files generated for it.
#
# Process is as follows: (All of these actions are carried out by the Microsoft NMAKE Utility using
# the .MAK file for each component. The .MAK file is generated by editing
# this template.
# The edit consists of inserting the desired %progID% into it. (a "one line" change)
#
# For an IN Process COM Server running under Windows the "Trigger File" is NOT required, IF you
# are not using a GUI and you are working outside of the IDE, as we are here; (the IDE may have
# its own requirements.)
# The .DLL is loaded by the OS when it is instantiated. However, things may work differently in
# other environments, so if you think you need the Trigger File then it should be compiled to .OBJ
# as a pre-requisite. NOTE that all trigger files are the same so you could edit a template to do this.
# Include the trigger file .OBJ into step 5 if you are using a trigger file.
#
# 1. Edit the COBOL Trigger source template to the desired progName.
# 2. Compile the Trigger to .OBJ
# 3. Create the .IDL file for the target progID (This MAKE template uses an inhouse custom written
# utility which analyses the COBOL source and produces both .IDL and .REG files. (.REG is a spin-off
# and NOT required for further build steps.)
# There are a number of utilities available for generating .IDL/.ODL from COBOL, notably from OMG
# (CORBA), PRIMA Computing (NZ), and SOFTWARE AG.
# Because it is the Micro Focus Project IDE that builds this .IDL, rather than the compiler,
# it is not possible to build COM Components without a project, in the MF environment, UNLESS a
# different approach (like that shown here) is adopted.
# (As it states in the MF documentation, you MUST have a Project, to build a COM component.)
#
# 4. EITHER:
# (If you require a separate Typelib)
# Use MKTYPLIB on the IDL file (or MIDL compiler) to obtain a .TLB file
# OR:
# (The default, where the Typelib will be embedded in the target .DLL)
# Use the Microsoft Resource Compiler (RC) to compile the .IDL to a .RES file
# 5. Having provided the prerequisites, let cbllink do its job.
#
#
#
################################################################################
.SUFFIXES:
COBOL_PATH = C:\\Program Files\\Micro Focus\\Net Express 5.1\\base\\bin
#======================== ONE LINE to change here ================================
PROG_ID = %progID%
#=========================== That's it! ==========================================
ALL : "$(PROG_ID).DLL"
REBUILD : CLEAN ALL
CLEAN :
DEL "$(PROG_ID).DLL"
DEL "$(PROG_ID).LIB"
DEL "$(PROG_ID)_DLL.IDL"
DEL "$(PROG_ID)_DLL.TLB"
DEL "$(PROG_ID)_DLL.REG"
DEL "$(PROG_ID)_DLL.RC"
DEL "$(PROG_ID)_DLL.RES"
DEL "$(PROG_ID).OBJ"
# You can comment out lines by using the hash (US="number") symbol
#
# The first step is to produce an .IDL or .ODL file. I am using a utility I wrote to do this,
# but there are a number of commercial utilities which will parse COBOL and produce an .IDL
# Assuming you already have this available from some other source, comment out this step.
# STEP 1: PRODUCE .IDL and .REG (.REG should not be essential as Regsvr32 should do the same
# job, but tests showed that ClassID may not be registered so it is handy to have .REG)
# My utility produces both files.
#
# "$(PROG_ID).IDL" : "$(PROG_ID.CBL"
# COMIDLREG -i -r $(PROG_ID).CBL (You will need an equivalent, or an existing .IDL file which you
# can edit manually to include your properties and method signatures)
#
# STEP 2: CREATE A TYPELIB
"$(PROG_ID).TLB" : "$(PROG_ID).IDL"
MKTYPLIB.EXE /nocpp /win32 $(PROG_ID).IDL
# STEP 3: EMIT A TEXT FILE FOR THE RESOURCE COMPILER
"$(PROG_ID).RC" : "$(PROG_ID).TLB"
ECHO typelib $(PROG_ID).TLB > $(PROG_ID).RC
#
# If your component has a GUI you will need more in the .RC file. (See the .RC generated by the Project.)
# The above is the simplest possible .RC and contains no INCLUDES or C Header files. It works for
# IN Process COM servers with no GUI resources to load.
# STEP 4: CREATE THE .RES FILE SO THE TYPELIB CAN BE LINKED WITH THE .DLL
"$(PROG_ID).RES" : "$(PROG_ID).RC" "$(PROG_ID).TLB"
RC.EXE /r /i "$(COBOL_PATH)\\..\\INCLUDE" $(PROG_ID).RC
# STEP 5: CREATE THE COM SERVER .DLL using cbllnk from the command line.
"$(PROG_ID).DLL" : "$(PROG_ID).RES"
cbllink -d -rE -l -uCOBOL.DIR -M$(PROG_ID) -O$(PROG_ID).dll "$(PROG_ID).CBL" "$(PROG_ID).res" "dllserver.obj"
# Remember to make sure you have a COBOL.DIR file in the working directory. You only need ONE
# of these, but you will need a .MAK file (derived from this template) for each component you wish to
# batch compile. Typically, you would write a script or (COBOL?) program to process each of the
# components by generating a .MAK file for it from this template, and adding its name to a
# response (text) file for NMAKE. Use a working directory to generate the MAKE files into, add the
# COBOL source of each component, the COBOL.DIR file, and then it is just a single command to
# batch compile everything: NMAKE @response.txt (or: NMAKE progname.MAK to build a given component.)
# The NMAKE Utility will run through all of the steps above for each progID it encounters in the
# response file, and the .DLLs will be placed in the working directory, along with Typelibs, .IDL,
# and .RES/.RC files.
#
# It is pretty easy to tailor the above for your specific needs (for example, add a step to run .REG)
# and interested parties are referred to the documentation on the Microsoft MAKE and NMAKE utilities.
OBSERVATIONS:
1. As a newcomer to the Micro Focus IDE it was difficult to decipher what the background processes were.
To be fair, most users don't care, but if there is a batch compilation requirement where things must run from a command line, it needs to be understood. I have spent the last two and a half weeks trying to deduce what the background process for COM is in this environment, and the details of it. A simple document addressing batch compilation could avoid that.
It wasn't immediately apparent or clear what the Trigger File is for and whether it was essential or not.
I couldn't find references to it in code or examples and I still don't know quite why it is there :-).
(I suspect it is so that GUI resources can be loaded, but I don't "know".) For your test project, I ignored it
in the MAKE process (in fact, I tried building both with and without it and got the same correct results each time)
and the .DLL produced runs exactly as the one produced by the IDE, whether it has the trigger file compiled into it or not. (I registered the MAKE built .dll and then ran the TestCOM process from within the project. It worked fine, instantiating itself and returning a string from the test method. (I made sure the string returned from the Project built server and the string returned from the MAKE built server were different, so I could be sure which component was being accessed.)
2. I found a number of things that seemed "odd" to me but I won't elaborate here. I think some of it stems from the very visible C mind set that is behind this software. Never mind, programmers never agree on approaches and the only real criterion is whether it works or not :-). There is no question that the MF software works.
3. The help and support from a free forum is outstanding and a credit to Micro Focus as a company. It says a lot about attitude and that is very important when selecting a software vendor.
My own original problem (which was how to deal with several hundred COM components all with at least a dozen methods in them) is now solved and I can report to the clients that there is no reason why they can't go for Micro Focus, if that is their choice. I know there are some favoured approaches and vendors and one COBOL so far has had to be eliminated because of lack of OO and COM support.
The major mistake I made was not realizing that Methods must be added to server source through the IDE so they can be registered and generated into IDL. Chris pointed me at that and from then on things went better :-) Because this is not a viable approach for dealing with existing code it forced me to find another way.
I think this thread can be closed as "answered" and thanks again to Chris Glazier for his willing and capable support.
Regards,
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
There is a quick update to the MAKE file template.
I realised when I checked the produced .DLL with an object browser that the Typelib had not been assigned a resource number. It doesn't affect the working of the .DLL but it is annoying that the internal Typelib is not
presented on demand.
To remedy the situation replace STEP 3 with the following:
STEP 3: EMIT A TEXT FILE FOR THE RESOURCE COMPILER
"$(PROG_ID).RC" : "$(PROG_ID).TLB"
ECHO 1 TYPELIB $(PROG_ID).TLB > $(PROG_ID).RC
Step 4 uses the /i parameter to provide a path to INCLUDE files. This is only necessary if you are using the IDE provided .RC file instead of running step 3. If you use the .RC file provided by step 3 it has NO INCLUDES or C header files and none are required. If your component is using GUI you may need to have the includes provided in the .RC file from the IDE.
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
There is a quick update to the MAKE file template.
I realised when I checked the produced .DLL with an object browser that the Typelib had not been assigned a resource number. It doesn't affect the working of the .DLL but it is annoying that the internal Typelib is not
presented on demand.
To remedy the situation replace STEP 3 with the following:
STEP 3: EMIT A TEXT FILE FOR THE RESOURCE COMPILER
"$(PROG_ID).RC" : "$(PROG_ID).TLB"
ECHO 1 TYPELIB $(PROG_ID).TLB > $(PROG_ID).RC
Step 4 uses the /i parameter to provide a path to INCLUDE files. This is only necessary if you are using the IDE provided .RC file instead of running step 3. If you use the .RC file provided by step 3 it has NO INCLUDES or C header files and none are required. If your component is using GUI you may need to have the includes provided in the .RC file from the IDE.
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
There is a quick update to the MAKE file template.
I realised when I checked the produced .DLL with an object browser that the Typelib had not been assigned a resource number. It doesn't affect the working of the .DLL but it is annoying that the internal Typelib is not
presented on demand.
To remedy the situation replace STEP 3 with the following:
STEP 3: EMIT A TEXT FILE FOR THE RESOURCE COMPILER
"$(PROG_ID).RC" : "$(PROG_ID).TLB"
ECHO 1 TYPELIB $(PROG_ID).TLB > $(PROG_ID).RC
Step 4 uses the /i parameter to provide a path to INCLUDE files. This is only necessary if you are using the IDE provided .RC file instead of running step 3. If you use the .RC file provided by step 3 it has NO INCLUDES or C header files and none are required. If your component is using GUI you may need to have the includes provided in the .RC file from the IDE.
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
Another approach to building a Net Express from the command line is to use the projmake utility.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
spgennard originally wrote:
Another approach to building a Net Express from the command line is to use the projmake utility.
Yes, I had a good look at that and got quite excited when I found it :-)
I may have misunderstood here, but I think you have to have a project in order for it to work. (It builds existing projects, I think?)
As discussed previously, it is non-viable for me to build a COM project for every component we need to compile.
(Unless I am wrong about projmake and it will build such a project from scratch.)
For the MAKE solution, all you need is the source code (don't have to register every method and property through the IDE), your COBOL.DIR file and an IDL/ODL file that correctly indexes the properties and methods. (There are utilities that will generate this from OO COBOL source, but I wrote my own.)
Thanks for pointing out the projmake utility.
Pion.
[Migrated content. Thread originally posted on 28 March 2011]
After a couple of weeks of trying to make Net Express process COM correctly I am wondering if anyone is actually using this software from Micro Focus.
I have 2 clients who are considering MF NE and have asked me to evaluate it. So far it isn't looking good.
Imagine the simplest COM application possible. An In Process COM server with say, 1 Method, that takes 1 parameter, NO GUI interface or Presentation Layer, and NO public properties.
Under the "COMSERVER" Examples provided with the software is a DLL directory which gives a project file to build a very simple COM server which does a Loan Application. It builds and produces a COM server. The COM server registers with the system. (Interestingly for people who are familiar with COM servers, it doesn't build a Typelib but that isn't essential so we should be all right.)
Now go to the OC directory and build the Client app which calls our newly created server. It builds OK but when you run it, it fails saying it cannot bind to the server.
Set up a new OO CLASS project and specify it to be a COM server.
NE generates the base source code and some ancillaries like a Trigger (which is completely new to me and I've been dealing with COM for years - apparently it is needed to load the COM server .DLL; CreateObject does that for most people), a typelib and a registration file (which you don't need because regsvr32 does the job perfectly adequately...) Modify the source to include the single method with the single parameter, noted above.
Build it and register it. All good. (There is a single .DLL produced so I guess it has incorporated the "trigger" into that?) It is a bit of a worry that if you look at it with an Object Browser (OLEview) it appears to have no application Methods but we can find out whether this is problematic by testing it.
Of course, you CAN'T test it because it is a .DLL and the IDE doesn't generate a sample harness or testbed for you, but that's OK; it is a matter of minutes to knock one up.
Step through the harness. The "new" Method executes and the server is instantiated.
Now our single Method with the single parameter... It crashes saying the Parameter cannot be found (0x80020004).
I tried giving it a non-existent method name and it crashed correctly saying it couldn't find the method. (So the object returned is aware of the application methods, maybe just not aware of their signatures...) I tried every variation of USING and RETURNING (and both of them together, which I thought was illegal in COBOL, but it compiled successfully), returning the same HCODE every time. I most carefully checked the source code method signature in the server and the actual parameter being passed in the Client and they are correct. (It is a single COBOL string PIC X(8192) which should be easily converted to VT-BSTRING under the covers.)
So far MFNE is accumulating demerit points on the following:
1. Inadequate documentation and background. Why isn't there a simple document that explains the approach to COM? including:
Why trigger files are needed?
Why I can only use .CBL as a source extension for COM? (I might be able to address this with the OSEXT directive; been too busy to try...)
Why typelibs are compiled into separate resource files but there is no compiler directive to let me force ODL generation from a command line so I could do it later?
Why I can ONLY build a COM component from a PROJECT (One client has hundreds of these which we need to batch compile - a separate post here elicited NO response so I have to conclude either no one knows or no one cares, which makes me wonder if anyone is actually using OO COBOL and COM from MF...Hence this post.)
2. Why isn't there a simple example of a COM server running IN Process, that actually works?
I am striving to see that this software gets a fair evaluation and I accept that it is new to me, but I have spent many hours going through the documentation provided and I simply can't make this stuff work.
For standard procedural COBOL, the system has scored well (although runtimes and Licensing could still be a show stopper - we'll consider that separately after we are satisifed the software meets our needs, and will balance it against other options and products), but for COM (which is essential for the component based systems these clients have) it is currently batting zero.
I would really appreciate it if anyone can shed light on the problems described or can state they are doing this without problem.
I'll happily send a sample source for the In Process server to anyone who thinks they can make it work.
(Maybe they could return the .DLL and the settings they used...)
Cheers,
Pion.
spgennard originally wrote:
Another approach to building a Net Express from the command line is to use the projmake utility.
Yes, I had a good look at that and got quite excited when I found it :-)
I may have misunderstood here, but I think you have to have a project in order for it to work. (It builds existing projects, I think?)
As discussed previously, it is non-viable for me to build a COM project for every component we need to compile.
(Unless I am wrong about projmake and it will build such a project from scratch.)
For the MAKE solution, all you need is the source code (don't have to register every method and property through the IDE), your COBOL.DIR file and an IDL/ODL file that correctly indexes the properties and methods. (There are utilities that will generate this from OO COBOL source, but I wrote my own.)
Thanks for pointing out the projmake utility.
Pion.
