Blue Theme Orange Theme Green Theme Red Theme
 
Home | Forums | ASP.NET 2.0 Tutorials | Web Services | How Do I...? | Class Browser | WPF Quick Starts | Advertise with Us
 | Consulting  
Submit an Article Submit a Blog 
 Jump to
Skip Navigation Links
TechnologyExpand Technology
WebsiteExpand Website
Nevron Gauge for SharePoint
Search :       Advanced Search »
Home » COBOL .NET » Calling Procedural COBOL from VB.NET

Calling Procedural COBOL from VB.NET

Many clients will have existing COBOL source code that they will want to use within the .NET Framework.

Author Rank :
Page Views : 7415
Downloads : 116
Rating :
 Rate it
Level : Intermediate
   Print Read/Post comments Post a comment  Similar Articles  
   Email to a friend  Bookmark  Author's other articles  
Download Files:
vb2cob.zip
 
 
6 Months Free & No Setup Fees ASP.NET Hosting!
Become a Sponsor
 Tag Cloud
 Latest Jobs
More ... 
 Latest Interview Questions
More ... 

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!

Comment Request!
Thank you for reading this post. Please post your feedback, question, or comments about this post Here.
Login to add your contents and source code to this article
 [Top] Rate this article
 
 About the author
 
Rick Malek
Rick Malek is a Systems Engineer with Fujitsu Software based in Minot, North Dakota. While his primary duties are pre-sales support, Rick also does Consulting and Training. He has worked with COBOL since 1984, originally working on an IBM mainframe with CICS, VSAM and DB2.
Looking for C# Consulting?
C# Consulting is founded in 2002 by the founders of C# Corner. Unlike a traditional consulting company, our consultants are well-known experts in .NET and many of them are MVPs, authors, and trainers. We specialize in Microsoft .NET development and utilize Agile Development and Extreme Programming practices to provide fast pace quick turnaround results. Our software development model is a mix of Agile Development, traditional SDLC, and Waterfall models.
Click here to learn more about C# Consulting.
 
Introducing MaxV - one click. infinite control. Hyper-V Hosting from MaximumASP.
Finally – a virtual platform that delivers next-generation Windows Server 2008 Hyper-V virtualization technology from a managed hosting partner you can truly depend on. Visit www.maximumasp.com/max for a FREE 30 day trial. Hurry offer ends soon. Climb aboard the MaxV platform and take advantage of High Availability, Intelligent Monitoring, Recurrent Backups, and Scalability – with no hassle or hidden fees. As a managed hosting partner focused solely on Microsoft technologies since 2000, MaximumASP is uniquely qualified to provide the superior support that our business is built on. Unparalleled expertise with Microsoft technologies lead to working directly with Microsoft as first to offer IIS 7 and SQL 2008 betas in a hosted environment; partnering in the Go Live Program for Hyper-V; and product co-launches built on WS 2008 with Hyper-V technology.
Dynamic PDF
ceTE software specializes in components for dynamic PDF generation and manipulation. The DynamicPDF™ product line allows you to dynamically generate PDF documents, merge PDF documents and new content to existing PDF documents from within your applications.
Nevron Chart for .NET 2010.1 Now Available
The leading .NET charting control now features PDF, Flash and Silverlight export, visualization of large datasets and more. Deliver true charting functionality to your BI, Scorecard, Presentation or Scientific apps. Download evaluation now.
ASP.NET 4 Hosting
Get 2 Months Free of ASP.NET Hosting for Only $4.95/month! Receive FREE MS SQL and MySQL Databases Including ASP.NET 4/3.5, MVC 3.0, Silverlight 4, Windows 2008/IIS 7.0 Plus FREE IIS 7 Modules. Host UNLIMITED ASP.NET Web Sites – Click Here!
 
 Post a Feedback, Comment, or Question about this article
Subject:
Comment:
Nevron Gauge for SharePoint
Become a Sponsor
 Comments
Calling 32bit unmanaged dll from dotnet by Imran On April 26, 2007
how do we do this.... make the adderprogram an unmanaged 32bit dll in procedural cobol and call that from cobol.net. Is it possible regards
Reply | Email | Modify 
Team Foundation Server Hosting
 © 2012  contents copyright of their authors. Rest everything copyright Mindcracker. All rights reserved.