Calling Procedural COBOL from VB.NET

Article Description  

Many clients will have existing COBOL source code that they will want to use within the .NET Framework. In most cases the COBOL code will be recompiled and the User Interface (UI) will be updated to either VB.NET or C#. One issue that many users will face is how to enable the interface between procedural based COBOL and VB.NET or C#? This article will show how you can create an interface program in NetCOBOL for .NET that will act as an interface between the .NET data types and the standard COBOL data types. The attached ZIP file has all of the code mentioned in this article and the user is free to update it as necessary.

Within the .NET Framework very specific data types have been designed to enable the many different languages to exchange information and interact with each other on a level playing field. An issue arises however when you have existing code that was not written to take advantage of the .NET data types, such as procedural based COBOL. COBOL data types have been defined since the language was first organized and have changed little. Yes there are OBJECT REFERENCES that the user could use, but by and large the standard practice has been to use the existing data types (i.e. PIC 9, PIC X) in a multitude of formats. How can one call from VB.NET to your existing COBOL code and still have the data map over correctly? By using a simple Object Oriented class that will act as a traffic cop controlling the data marshalling.

In our little example we ask the user to enter in two numbers then select a button to add them together. Another sample handles text input. Here is the VB.NET form as it should appear when you execute the project:

One of the buttons calls an OO COBOL class to add them together and then return the result. The other program is a standard procedural based COBOL program, much the same as many developers have been writing. The String example accepts input in the .NET data type and marshals it to the COBOL data type. There is no display for this sample, the user will have to debug the code to verify the results. We will concentrate our discussion on the call to the procedural COBOL program for this article and the issues with calling it. Let's start with the VB.NET program.

VB.NET coding

We will assume you are comfortable with the VB language. If you have any questions in this area please consult with one of your local VB experts.

Since the code we are calling is an Object Oriented COBOL module and the methods are static there is no additional coding that has to be added to the VB code to instantiate the COBOL class. Within the REFERENCEs for the VB project the user has to add  references to the COBOL interface program, the Fujitsu NetCOBOL environment and the modules the interface program will be calling.

To invoke the interface class that will in turn call the procedural COBOL program we use the "button_click" event. The code to enable this is:

The sub routine first declares three variables of integer data type and then converts the input the user has entered  to INT16 (a numeric .NET data type) and stores them in the newly declared variables. The event then calls the method "ADDER" in the interface program. The method name is the same as the program name the interface will be calling. By using the same name for both the METHOD-ID and the procedural COBOL the programmer will  find this to be very easy to remember and if maintenance is required will know immediately where to go in the interface program to make the necessary changes.

The Interface

The module we are calling the interface class is an Object Oriented COBOL program. It contains  static (or factory) methods or data and does not need to be instantiated in order to enable its methods. The methods contained within it are basic OO COBOL  that accepts input from the calling module and passes it along to a called procedural based program. Each of the methods are intended to call a specific procedural based COBOL program. (Once control has been passed to the procedural module it in turn may call other procedural modules as necessary).

In our example the procedural COBOL program we wish to call is named "ADDER". In the interface class a method called "ADDER" has been created and its coding is as follows:

Notice the PROCEDURE DIVISION header has the "USING..." phrase attached to it. When the method is invoked the calling module will be required to pass along the data for the variables listed in the LINKAGE SECTION. A big advantage in the .NET Framework is the presence of "conformance checking". Conformance checking verifies the calling routine has the proper variables in place prior to making the call to the module. This in turn reduces the chances for obtaining runtime errors due to improperly coded calls.

Within the PROCEDURE DIVISION of the method is a single line calling the procedural COBOL program and passing along the information it needs to perform its job. When the procedural code is done executing, control is returned to the interface program who then returns to the calling module, the VB.NET form, passing back to it the updated variable, INT03.

String Sample

The string sample follows the same basic steps detailed above but instead uses string data. One note to mention, when a string is defined in VB it has a default length of approximately 8,000 characters. When the string is 'marshalled' into the COBOL picture clause the length of the string is then determined by the picture clause. In our example we are using a PIC X(20) for the name. If you key in more than 20 characters the COBOL interface program will truncate the string to the desired length.

That's all there is to it! To help you along a template method has been created. The template has comments embedded within the source code to help you determine what updates to make and where.Also, there are numerous comments within the source code to help you along.

Wrap-Up

The ZIP file has all the necessary source code for you to follow along and see how the code is to be structured. One very important item to remind you of is the need to add in references to other projects when you are passing control between them. This is probably one of the most common errors when starting in the .NET environment. Once you get used to the environment though those issues will go away!

Happy Coding!