Data centers are huge, power-hungry and inefficient. They consume electricity and IT budgets at staggering rates. HP wants to change that. The company's enterprise server division is developing efficient, compact machinery that's set to shatter our views of the traditional data center.  Read Full Post

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

Are you encountering the situation where you wish that rather than adding references to other projects or DLL’s, in order to bring them into your bin directory, that you could simply specify that all your programs went into the same folder? The simplest way to run applications under .NET is to have them all in the same folder. This typically, while debugging is in the debug\bin folder. This may also mean that you are finding yourself placing other dependant DLL’s in the same folder. One easy solution is to change your Output Path in your project, and other projects that share DLL's. You get there by selecting “Project Properties”, then the “Build” tab, then setting the OutPut Path. Setting the output path to where you keep all your programs, will allow them to be found, as this is the path this Solution/project will run from and expect to find it’s program it needs.  Read Full Post

I recently recalled that I wrote the article below in 2003 for a technical publication but I don’t think it ever saw the light of day. It still contains a number of relevant points that those interested in developing quality code or owning a quality COBOL compiler may find useful, so I’m making the article available here. It is based on an interview with Mr. Masaaki Uchida, at that time General Manager of the compiler development group at Fujitsu in Japan, and adds points derived from other research available at the time. Read Full Post

Have you ever wanted to create a COBOL DLL under .NET that holds multiple COBOL programs, that are grouped functionally? For example, maybe you want to have one DLL that holds all of your file maintenace tasks that you can call, such as creating a file, deleting a file, renaming and copying a file (and yes, maybe even check if one exists). This Blog covers this task in a way that you can not only learn or brush up on, how to create such a multiple Entry Point DLL and use it, but also gives you some NetCOBOL for .NET experience with the SYSTEM.IO Namespace for files.  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

With the release of NetCOBOL for .NET V4.1, there have been a lot of questions about what versions of Microsoft products this will work with and how to use it conjunction with older versions. Read Full Post

This tutorial describes how you can develop NetCOBOL for .NET routines, and use the added functionality that .NET has to offer from your NetCOBOL for Windows COBOL code. In order to do this, Your NetCOBOL for Windows code relies on the same feature it did to call an ActiveX DLL (see video of NetCOBOL for Windows calling a VB6 ActiveX DLL for reference). This layer is called the Component Object Model or COM. COM works in conjunction with .NET by the use of two tools (TLBExp and RegAsm). Download the sample source code used in this tutorial. Read Full Post

There are a variety of indexed file (ISAM) technologies that can be used with NetCOBOL and the Alchemy Solutions legacy modernization products and folks sometimes get confused about which one to pick, primarily because the documentation doesn't do a great job of summarizing why you would use one over the other. Let me start by saying that we generally recommend that folks use NeoData, our newest product offering, when possible particularly for legacy modernization projects. Let me explain why by giving you the highlights of the 3 available technologies: Read Full Post

Over the years, we’ve developed and sold a number of different products, many of which had different licensing mechanisms. In most cases, in order to activate a license for our software, you had to download and install the software, then email us a license request. Only after receiving a response from us could you actually begin to use the software. What a pain! Read Full Post