When new users approach NetCOBOL for .NET and are using embedded SQL in their COBOL code, one question we often get is whether to use ODBC or ADO.NET as the database access mechanism. NetCOBOL for .NET supports both and the good news is that choosing between the two can be as simple as changing configuration settings in your application’s configuration file (usually with the help of the NetCOBOL for .NET provided Runtime Environment Setup Utility). This is because the NetCOBOL compiler and runtime are responsible for handling all the work of translating your embedded SQL queries into calls that are made to the database that you specify.  Read Full Post

I was building a tool to generate some random data for testing with the goal that the data is readable. I wanted to get actual city/state/zip code information so I began looking at the census.gov website for the type of data that is available. I stumbled across several “names files” that contain first and last names and their frequency. The last name file was about 2MB in size – perfect for generating some random customer names. Read Full Post

Picture this: You are an active NeoBatch user, you are constantly running jobs working with your JCL batch operations, day in and day out. After making some changes to your JCL, you notice that it’s slowed down a bit. After some more changes, you think you have it going faster again, but you start to wonder: Is there a way to look at the history of the jobs that you’ve run, and present them in a graph or chart? The answer is yes, there is. You’re looking for NeoBatch SQL Reports. Read Full Post

We've just reached the end of a long road towards fulfilling a vision for what in many ways is a new product for us. While it is an extension of a number of things that we had products for, the goal was to consolidate functionality into a single, better tool and consequently provide a better tool for customers to manage their COBOL file data. Read Full Post

A number of users that are migrating their COBOL code from the mainframe to NetCOBOL and their data from DB2 to SQL Server stumble across some of the incompatibilities between DB2 and SQL Server. One such incompatibility arises when users write COBOL code with embedded SQL (ESQL) that relies upon getting a non-zero return code (SQLCODE) indicating that there were multiple matched rows for a SELECT query. Consider the following example:  Read Full Post