Report Writer under managed COBOL?

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?
  • 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.

  • 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();



       WYE39P myCobol = new WYE39P();


       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?

  • 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.

  • Hi Don,

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


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

  • Verified Answer

    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.