Highlighted
Contributor.
Contributor.
1611 views

Cobol calling C#

Jump to solution

We are replacing our legacy Cobol security programs with a new Security System which runs as a Web Service. Working with legacy code, I have an unmanaged cobol subroutine (SUBR01) that is compiled as a GNT. This, in turn, calls a DLL (DLL01), registered as a COM object, written in C#, which calls another DLL (DLL02) which acts as a Web Interface to the Security System service. This way I have a nicely encapsulated way to call the Security System from any legacy Cobol program.

The problem I’m running into is this: When I call SUBR01 from an unmanaged Cobol console app, it works fine. However, when I run it from a web program, also written in unmanaged Cobol, it hits DLL01 fine but when DLL02 tries to access it’s config file, it throws an error “System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize ---> System.ArgumentException: Illegal characters in path.” It seems like the messaging between DLL01 and DLL02 is somehow getting garbled or corrupted.

I’ve also tried calling DLL01 directly from the web program, removing the GNT from the picture, and still received the same error.

I would give you a list of things that we’ve tried and failed, but we’ve been fighting this for the better part of two weeks with no success, and the list would probably run for 10 pages. Suffice to say, we’ve tried changing both the cobol and C# modules and nothing has worked.

So I guess the first question is … is what I’m trying to do even possible? What’s so different between a console app and a web app that would garble the messaging? Is there something that we need to set in IIS 7.0 for either the web site or the app pool so that this will work? If is there a compile option that I’m missing (I have the “OOCTRL(+P)option in both the web program and SUBR01)? Has anyone even tried a set-up like I outlined above? Do I need to write DLL01 in cobol rather than C#? I’m desperate for any ideas that I can try?

Thanks!

0 Likes
1 Solution

Accepted Solutions
Highlighted
Contributor.
Contributor.

RE: Cobol calling C#

Jump to solution

The program in question is actually a GNT being called by a CGI.EXE program.  We're using that rather than a newer technology because the system was converted from NetExpress 5.0 and has over 100 CGIs, so converting them to something like ASP.NET is a large undertaking.  It's on the radar, just down the road a tad.

I'm convinced that the problem is NOT the location of the config file.  We tried moving it to multiple locations with no success.  The problem appears to be something in the web client is probably using a technology that native cobol web program didn't like, causing the message from the site to the service to get garbled.  In any  case, we discovered that we could use winHttp, and that works just fine.

Mike

View solution in original post

0 Likes
2 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Cobol calling C#

Jump to solution

Have you debugged the C# DLL01 program and checked the parameters being passed in both when being called from a console app and being called from a web site?

You state that the web site is an unmanaged COBOL program so I am assuming this is compiled as a CGI .EXE program is that correct? Or is it a multi-threaded ISAPI program? Is there a reason you are using such outdated web technology when VC supports ASP.NET, etc?

I am not sure what you mean by the .dll accessing its configuration file as normally config files such as app.config an web.config are only processed by a main program and not by a .dll. Where is the config file located and how is it accessed.

I don't believe it is the interface between COBOL and C# that is different but more likely how the application is run such as current working directory etc. This could have something to do with the fact that the current working directly that is in play when run as a web app may not be the same as when running as a console app.

0 Likes
Highlighted
Contributor.
Contributor.

RE: Cobol calling C#

Jump to solution

The program in question is actually a GNT being called by a CGI.EXE program.  We're using that rather than a newer technology because the system was converted from NetExpress 5.0 and has over 100 CGIs, so converting them to something like ASP.NET is a large undertaking.  It's on the radar, just down the road a tad.

I'm convinced that the problem is NOT the location of the config file.  We tried moving it to multiple locations with no success.  The problem appears to be something in the web client is probably using a technology that native cobol web program didn't like, causing the message from the site to the service to get garbled.  In any  case, we discovered that we could use winHttp, and that works just fine.

Mike

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.