Highlighted
Super Contributor.
Super Contributor.
1738 views

Report Writer under managed COBOL?

Jump to solution
Does anyone know of any restrictions or issues with using Report Writer in managed COBOL? Does anyone have any experience with Report Writer in managed COBOL? We've converted a number of our "batch" COBOL programs to managed code with success, but this is the first one that uses Report Writer and an exception is being thrown at the C# call to COBOL class (within a rununit) that reminds me of Net Express errors I saw YEARS ago when a compiler bug created bad references that wouldn't link. The exception is "Method not found: 'Void COBOLPrograms.WYE39P._MF_IMPLICIT_1()'". We are running VC 2.3.1 for VS 2013 Update 5. COBOLPrograms is the COBOL class library targeting .NET Framework 4.5 with Debug/Any CPU configuration. WYE39P is the converted COBOL program (public) with only the Linkage Section and Procedure Division code residing in the single Method-ID named InstanceMethod. We aren't getting any compile errors. And we haven't run it from a server, just within the IDE. Questions? Comments? Ideas?
0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Report Writer under managed COBOL?

Jump to solution

Thanks Don.

I have been able to reproduce the problem using a simplified version of your example that invokes the COBOL method from a C# console app without using RunUnits.

I find that the error occurs whenever the INITIATE statement is present in the method. If I comment this out then the call is successful.

I also converted the class into a COBOL program with a single entry point and I can invoke this entry point from the same C# program without a problem.

I have created an RPI for this and have passed it onto development for review.

Thanks.

View solution in original post

0 Likes
6 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Report Writer under managed COBOL?

Jump to solution

I don't have any experience with Report Writer in managed or unmanaged COBOL, I'm afraid. However, my initial guess is that a generated method needs to be decorated with the MicroFocus.COBOL.Info.Callable attribute. You could try adding "attribute Callable" to the method-id in WYE39P, along these lines:

method-id InstanceMethod attribute MicroFocus.COBOL.Info.Callable.

You might need to add that attribute declaration to the class-id as well.

If that fixes it, then you should ask your support rep to raise an RPI against Report Writer, I think.

0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Report Writer under managed COBOL?

Jump to solution

The suggestion didn't fix the exception.  I tried modifying the method-id first and tested, then modified the class-id and tested again.  Same exception thrown at the C# call to the COBOL class.  Maybe for a better picture, here is the C# code from our program called COBOLRunUnit.cs:

bool bError = false;

string sLine = "";

string sOutput = "GOOD";

string param_control = "data to be passed to WYE39P";

MicroFocus.COBOL.RuntimeServices.RunUnit myRunUnit = new MicroFocus.COBOL.RuntimeServices.RunUnit();

try

{

   WYE39P myCobol = new WYE39P();

   myRunUnit.Add(myCobol);

   sOutput = myCobol.InstanceMethod(ref param_control);

   if (sOutput == "ERROR") { bError = true; }

}

catch (Exception ex)

{

   bError = true;

   sLine = "****      ERROR:" + ex.Message.ToString();

}

While single-stepping through this code, pressing F11 at "sOutput = myCobol..." causes the cursor to jump to the catch.  There is a breakpoint set on the first executable COBOL statement in WYE39P, but we never get there.

Also note:  As soon as I modified the method-id in WYE39P, the "WYE39P"s in the C# statement "WYE39P myCobol = new WYE39P();" underlined with a red squiggle.  In fact every statement making this type of assignment in this C# program "red underlined" and the Error List tab showed a first message:

"The type or namespace name 'COBOLPrograms' could not be found (are you missing a using directive or an assembly reference?)"

followed by one message for each call to a COBOL class:

"'COBOLRunUnit.COBOLRunUnit.[program name](string)' is a 'method' but is used like a 'type'".

Do I still open an RPI, or does this give someone another idea of where we have gone over the cliff?

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Report Writer under managed COBOL?

Jump to solution

I haven't had to use run units in managed COBOL myself, so I'm afraid I don't have anything else to suggest. I can only recommend you contact your support representative.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Report Writer under managed COBOL?

Jump to solution

Hi Don,

Please open up a support incident and attach a demo program and we will take a look.

Thanks.

0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Report Writer under managed COBOL?

Jump to solution

I've opened incident # 2872555 and uploaded a .zip of the entire solution folder.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Report Writer under managed COBOL?

Jump to solution

Thanks Don.

I have been able to reproduce the problem using a simplified version of your example that invokes the COBOL method from a C# console app without using RunUnits.

I find that the error occurs whenever the INITIATE statement is present in the method. If I comment this out then the call is successful.

I also converted the class into a COBOL program with a single entry point and I can invoke this entry point from the same C# program without a problem.

I have created an RPI for this and have passed it onto development for review.

Thanks.

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.