Has anyone connected Visual Cobol running on AIX to SQL Server

We have a large number of  Cobol jobs running on AIX that connect to a Sybase database.  Our company is migrating that database over to SQL Server so we'd like to pick the best migration path for these Cobol jobs.  So far, we're looing at two options:

1. Use an 3rd-party ODBC driver.  Is anyone doing this?  If so, what driver are you using and what advice do you have?  We're not sure which driver to use (Microsoft does not provide an ODBC driver for AIX).  We're an enterprise company so we need driver software which is supported (e.g. - by a vendor).

2. Compile all of our Cobol jobs as Java and then use a JDBC driver (which Microsoft does provide).  In this case, we're worried about the impact this would have on our AIX server.  If we convert all of these jobs to java, will that result in higher memory or CPU demands on the box?  Are there any other things to watch out for?

  • Verified Answer

    Hi ,

    Micro Focus Support does not provide recommendations for 3rd party software. However, I have read of an ODBC driver vendor that claims support for connecting to SQL Server from Unix and Linux variants, including AIX - Easysoft http://www.easysoft.com/  I’ve mentioned this to a couple of customers, but don’t have any feedback that confirms whether they were successful.

    Regarding a move to JVM COBOL, the docs have a section that suggests there will be some impact on performance by moving from Native to JVM, but says this will vary by application:

    Compiling COBOL application directly to Java byte code This scenario is suitable for applications that do not require Enterprise Server or any transaction support and when the best possible integration with Java is required. JVM COBOL compiles to Java byte code which runs directly inside the JVM, providing full integration of COBOL with Java. With this method, Java classes can call existing COBOL applications using a variety of techniques and COBOL applications can also call Java classes or routines provided by the Java SDK. You must build the JVM COBOL applications on the platform they are deployed to. Due to the nature of the JVM, COBOL applications are likely to see some reduction in performance in comparison to COBOL applications running outside of the JVM in a regular native environment. The reduction in performance varies from application to application. Heavily intensive batch applications may experience lower performance whereas an interactive application may have no appreciable difference in responsiveness. It is recommended you conduct some performance testing against your existing application to determine if performance levels will be satisfactory. For more information, see JVM COBOL Interoperability and the JVM COBOL Tutorials available in the product help of Visual COBOL for Eclipse.

     You can find the above at this link.    


  • Thanks, Blair. We are looking at EasySoft so we'll see how that goes. I found this Community article that talks about improving the JVM performance: Understanding JVM COBOL Performance - It is Fast - Very Fast! . If you get time, can you take a look and see if you've considered/used any of this?

  • Hi  


    Noting that the post you referenced is very old (from 2012) I'd be interested to hear if anyone has tried the steps mentioned.


    I have not been involved in any bench-marking of JVM vs Native code. Perhaps someone else who has this background can chime in with some suggestions?

  • with a odbc Driver you can connect to SQL database, i have this connect string in a ASCII file, read this file and connect. The database can be on all os Systems, connect via ip address!

    i hope this help you!

  • SUCCESS!  We used Easysoft, which comes with an  ODBC manager (unixOdbc).  We installed it onto our test AIX box and configured the odbci.ini file (I think that's the name of the file!) to point to our SQL Server instance.  Once that was done, we built a Visual Cobol compile script (using Korn shell) and referenced the odbc instance that we just configured in the odbc file.  Note that newer versions of Easysoft support TLS 1.2 as well.