So the subprogram is a procedural COBOL program that resides in a different project is that correct?

Is the project containing the called program a managed code Class Library project or is it a native project?
Is FPACTGN the name of the Class Library project?
If not then you might have to load the projects .dll prior to calling the entry point.

Please take a look at the tutorial here which covers using the CALL statement within in managed code projects in Visual COBOL for Visual Studio.

Thanks.

The programs are in different projects in a single solution. FPACTGN is the class library project.  It's not that I am getting a not found or error, it just executes the call with nothing and goes to the next line.

How are you executing the call?

Are you stepping through the call in the debugger using F11?

Is any part of the call statement highlighted with an underline in the editor that displays the message about a dynamic call being generated for the method?

If your solution is self-contained and you can zip it up and e-mail it to me at chris.glazier@microfocus.com I will take a quick look.

Yes the calling parameter are underlined and the popup says 'Can not find method  'FPACTGN' with this signature -  will generate dynamic call'.  This is the large solution I have had issues with in the old release.  IT's 101mg zipped.

That error message means that the compiler cannot resolve the call as the parameters do not match or the program name cannot be found.

Are you adding a reference to the Class Library project within the references folder of the calling project?

If you are adding a reference and you still get this compiler message then something else is not matching up.

Can you show me what the program-id, linkage section and procedure division header look like for the subprogram?

I have a reference to the called program in the calling program project.  I checked the dll is in the bin\\debug folder of the calling program.  I remove the calling parameter and still get the same message so I think it's the called program that is not being identified.  Here is the Program-ID, linkage section, and procedure header of the subprogram, I also add the call from the calling program.

      program-id. FPACTGN AS "FPACTGN".

      LOCAL-STORAGE SECTION.

      LINKAGE SECTION.

      01  DPMCall.

          05 DPMCLength                   pic 9(4) comp-5.

          05 DPMCType                     pic 9(4) comp-5.

          05 DPMCReturn                   pic 9(4) comp-5.

          05 DPMCReturnFlag               pic x.

          05 DPMCFileName                 pic x(8).

          05 DPMCDefaultPath              pic x(30).

          05 DPMCLoginRecord              pic x(120).

          05 DPMCSharedData.

             10 DPMC-PROGRAM              pic X(8).

             10 DPMC-ACTION               pic X(1).

             10 FILLER                    pic x(3825).

             10 DPMC-VEIWRPT              PIC X(256).

          05 DPMTABLENUM                  PIC X(02).

          05 DPMPASS-RECORD                  PIC X(60).

      PROCEDURE DIVISION USING BY REFERENCE DPMCALL.

Call from main program

          Call "FPACTGN" using PMCALL

PMCALL and DPMCALL are exactly the same except for naming and we use in all programs to move data from program to program

Thanks

I have a reference to the called program in the calling program project.  I checked the dll is in the bin\\debug folder of the calling program.  I remove the calling parameter and still get the same message so I think it's the called program that is not being identified.  Here is the Program-ID, linkage section, and procedure header of the subprogram, I also add the call from the calling program.

      program-id. FPACTGN AS "FPACTGN".

      LOCAL-STORAGE SECTION.

      LINKAGE SECTION.

      01  DPMCall.

          05 DPMCLength                   pic 9(4) comp-5.

          05 DPMCType                     pic 9(4) comp-5.

          05 DPMCReturn                   pic 9(4) comp-5.

          05 DPMCReturnFlag               pic x.

          05 DPMCFileName                 pic x(8).

          05 DPMCDefaultPath              pic x(30).

          05 DPMCLoginRecord              pic x(120).

          05 DPMCSharedData.

             10 DPMC-PROGRAM              pic X(8).

             10 DPMC-ACTION               pic X(1).

             10 FILLER                    pic x(3825).

             10 DPMC-VEIWRPT              PIC X(256).

          05 DPMTABLENUM                  PIC X(02).

          05 DPMPASS-RECORD                  PIC X(60).

      PROCEDURE DIVISION USING BY REFERENCE DPMCALL.

Call from main program

          Call "FPACTGN" using PMCALL

PMCALL and DPMCALL are exactly the same except for naming and we use in all programs to move data from program to program

Thanks

I tested this here and it works fine for me.
I am using VC 2.2 for VS2012.

I am attaching my simple demo which has two projects, the main windows form app and then the class library project containing the subprogram.
When I step through these it calls the subprogram fine and returns.

Perhaps you can check and see if my demo works for you and to see what the differences might be between your project setup and mine?

What additional compiler directives are you using and are they the same for both projects?

Your example worked on my system too.  We are using this copybook cblproto.cpy that was provided by you guys, could that cause a problem?  I have check properties and everything I can think of.

Using cblproto.cpy should not cause a problem as that only ensures that parameters are correct for the system run-time routines. In fact I just added it to the top of each of the projects in my example and it still runs just fine.

Your project containing the subprogram is a managed code project correct?

If you look at the properties page for the project it should have no COBOL Link tab.

If it were a native project and you were trying to do a P/Invoke then you might see the behavior that you are experiencing.

Try adding exception handling around the call to see which exception is occurring:

          try

             Call "FPACTGN" using PMCALL

           catch ex as type Exception

              display ex::Message

          end-try

It was managed code.  If I put the sub program in the same project as the calling program ,it works fine.  I will use that for now until I have more time to explore.

Thanks for all of the help.

Hi Chris,

I am a little confused with this. We have one Winform project for a Menu that should call different Winform projects for every Menu option, and I can not make the call work, I allways receive an error. I really do not want to have a hole solution with all the projects inside. Is that needed or is there a way to call a managed winform solution from another managed winform solution in Visual COBOL? And I need to pass some parameters too. If you have a sample of this situation passing some parameters would be very welcome.

Regards

Hi Juan,

You can call programs within other projects by adding a reference to those other projects within the calling project.

A single Winform application should only have one main project that is created using the Winform application template as this will compile as an .EXE. The other projects that it calls should be created using the Class Library template which will compile as a .DLL.

You can then issue a call prog-name from the main .EXE to a COBOL program that exists in the .DLL as long as you have a reference to that .DLL. You can add a project reference by right clicking on the references folder under the main project name in solution explorer and selecting the .DLL project.

If you have other ..DLL projects that contain programs that you need to call and they are not within the same solution then you can add a reference to them in the same manner but instead of adding a project reference you would browser to the actual .DLL location.

Note that the CALL statement is only used to call COBOL procedural programs. If you wish to run another winform you would create a new instance of it and then invoke its methods. These forms can exist in other class library projects as long as you have a reference to them.

In short, you do not actually call projects or solutions but you call the programs that exist within them. You can call a COBOL program just like you normally would passing parameters through CALL USING and then using a linkage section in the subprogram.

If you can provide more detail as to what exactly it is that you are trying to do then perhaps I can provide a small demo to get you started in the right direction.

Thanks.

Thanks Chris,

In a traditional Cobol app (character or gui based) you normally have a main menu with all the options available, ie Customers, Proposals, Sales, Statistics, ..... and all the modules/programs are done separately and when the user selects one option, the control is transfered via a CALL from the main menu to the selected program.

In your opinion, what is the best strategy to do this with Visual COBOL?

Regards,

The strategy would be the same if you wish to keep it that way.

Your main application can present the main menu and then you can have separate Class Library projects for Customers, Proposals, Sales, etc.

Each of these could have their own set of winforms for presentation to the user but it is normally best to separate the UI portion of the application from the business logic so you may wish to handle all of your presentation logic within the main application and then just call into these other modules as required.

I will try to put together a simple demo and then attach it to this post.

If others out there could share their own experiences with packaging of a WinForm application, that would be great.

Thanks.

Great Chris,

I am not able to call or invoke the other class projects from the main exe. I will wait for the sample.

Thank you!

Here is a real simple demo of one way to possibly do this.

This is a solution that contains a main Winform application project named mainapp.
It also has two class library projects named customer and accounting.

Mainapp displays a main menu form allowing you to either run customer, accounting or quit.
Depending on the option selected it will invoke a class in either the customer project or the accounting project.

These classes in turn will display their own forms with a pushbutton which will call a COBOL subprogram passing parameters and will then return the parameters to the class where the parameter will be displayed on the form.

When you click Quit it will exist back a level.

Again, this is only one way to set this up.

The best method really depends on your particular application.

Thanks.

Thank you Chris!

You allways need all the projects in the same solution? Is not possible to have ie customers in another solution and invoke it from the mainapp?

In this particular case, the original Cobol app used to build a dynamic main menu based on a configuration file (COBOL indexed file) and then call each module taking the name from that file. This does not seem to be easy to do with Visual COBOL.

Regards

You can add a reference to an assembly that is not within the same solution by right-clicking the references folder and selecting browse to navigate to the assembly name, i.e. customer .dll on disk.

You can dynamically call COBOL programs by using call data-name just like you always have.

In the example that I provided instead of creating an instance of a class for customer or accounting you could make these into programs instead of classes and then you could just call them using call data-name.

If you need an example of this let me know and I will try to put one together this week some time.

Thanks.

I am attaching a new example which shows how to dynamically call COBOL programs which are not within the current solution based on a dynamically created menu.

Unzip testdynamicall.zip onto your C drive retaining the folder structure in the zip file.

Open up solution file c:\\testdynamic\\customer\\customer.sln and do a rebuild.

This solution contains 3 projects, customer, accounting and inventory. Each project contains a main COBOL program which will display a Windows Form allowing you to enter data in a textbox and then return.

Open solution c:\\testdynamic\\testdynamic\\testdynamic.sln and do a rebuild.

This solution contains the single project testdynamic.

If you run this project it will call a subprogram which will read a file containing a list of menu items and their associated program names and then pass back this data in a COBOL table.

This data will then be used to populate a list box on the main form and then it will present this form to the user. The user can select a menu item and click the Run program button and it will dynamically call the selected COBOL program which happens to be one of the programs within the customer solution. When you enter data into the forms of these programs it will be returned back to the main program and displayed.

You can use any control for a menu including an actual menu or menu strip. I selected a listbox for the sake of simplicity.

The testdynamic project contains references to the 3 output files, ACCTPROG.DLL, CUSTPROG.dll, and INVPROG.dll with the Copt Local property set to true. This will cause those .dlls to be copied into the output folder along with testdynamic.exe so that they can be found when the dynamic call is done.

Let me know if you have any questions.

Thanks.

Fantastic Chris!

Thank you so much.