NOTICE: Our Community is moving. Get more information. Updated information on a New Login Process
Speaking to a NetExpress user recently I sensed some fear at the idea of moving to Visual COBOL – a new IDE and a new language (.NET COBOL or JVM COBOL). Understandably daunting.
So I thought it might be worthwhile to give an overview of this “new language” and demonstrate that it is a force for good – not to be feared. So let’s take a look at .NET COBOL and JVM COBOL (or Managed COBOL**) and see how they fit in with procedural COBOL and the new frameworks. (We won’t discuss actual syntax in this document.)
There are 2 Visual COBOL products:
Visual COBOL for Visual Studio
Visual COBOL for Eclipse
With these IDEs come .NET COBOL & JVM COBOL* respectively, or Managed COBOL as we'd prefer to collectively call them. * *
Managed COBOL is COBOL with extensions to support the .NET & JVM frameworks. This offers OO syntax support and syntax to allow us to access the available class libraries. If you are familiar with COBOL dialects, you could envisage Managed COBOL as a new dialect.
NB Both Visual COBOL for Visual Studio and Visual COBOL for Eclipse provide support for native (unmanaged) and managed COBOL projects.
What code changes do I need to make to get started with Visual COBOL?
None - so long as your app does not use features that are not supported in Visual COBOL (for example Panels2, DS and ACU-GT.) Core COBOL is fully supported.
Assuming this to be the case :
You can take your existing app and compile it to native code – no code changes.
You can take your existing app and compile it to managed code – no code changes.
This is where the 2 IDEs differ. The COBOL language looks the same (nearly **) but the output from the compiler is different depending on your IDE.
Comparing Managed COBOL compiled for .NET & Managed COBOL compiled for JVM :
Now let's take a closer look at Visual Studio & .NET.
At compile time a .NET compiler converts the .NET source code into CIL code. At runtime, the CLR's just-in-time compiler converts the CIL code into code native to the operating system.
This means you can write mixed language applications, for example a COBOL app with a C# web front-end.
Now let's take a closer look at Eclipse & the JVM.
At compile time a JVM compiler converts the source code to Java bytecode. Don't be put off by the word "Java" - the JVM was initially designed to support only the Java programming language, the associated Java programs had been compiled to a format called Java bytecode. However, as time has passed, more and more languages have been designed to run on the Java platform – including COBOL. Their compilers compile to this common format – Java bytecode.
At runtime, the JVM's just-in-time compiler converts the Java bytecode into code native to the operating system.
This means that COBOL can take advantage of Java Platform's original objective of "write once, run anywhere" (WORA). So JVM COBOL can run on any device equipped with a Java virtual machine (JVM), be it Red Hat, AIX or an Android phone.
The ultimate aim is for .NET COBOL & JVM COBOL to be syntactically identical.
We're not quite there yet (partly because .NET COBOL is more mature than JVM COBOL), but we're working on it. **
Hence they are collectively called "Managed COBOL".
So are there now 3 COBOL compilers?
No. Just one.
The IDE takes care of this for you, but the compiler knows the format of code to generate depending on the compiler directive.
JVM COBOL is available with Visual COBOL R3 as an Early Access Program. It is GA in Visual COBOL for Eclipse R4 which was released June 2011.
** Aim to get .NET COBOL and JVM COBOL to look and behave the same
This is work in progress. It is ambitious. We are not expecting 100% success and will document any differences. Therefore our preference is to collectively call .NET COBOL & JVM COBOL – "Managed COBOL".
I very happy to read this good news. Thank You Paula Willis.