Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.




The purpose of this article is to introduce Managed COBOL syntax. It's a big subject, so this is just the tip of the iceberg. We can add more detailed articles on specific areas in future - if you have any suggestions of areas you'd like to see, please let us know.

  • Overview
    • What is Managed COBOL?
    • What’s the difference between .NET COBOL & JVM COBOL?
  • Managed COBOL Syntax
    • OO Syntax
    • Accessing Class Libraries
  • Predefined Types


What is Managed COBOL?

Managed COBOL is COBOL with extensions to support the .NET & JVM frameworks. This includes OO syntax support and syntax to allow access to the available class libraries. You could view “Managed COBOL” as a new COBOL dialect.

What’s the difference between .NET COBOL & JVM COBOL?

Our aim is for .NET COBOL & JVM COBOL to be syntactically identical.

They’re not exactly the same yet, partly because .NET COBOL is more mature than JVM COBOL, so we’re playing catch-up.

This aim offers us some challenges. What if there are differences between the frameworks which mean our behaviour would differ from existing languages in that framework?

Should .NET COBOL behave like C# & JVM COBOL behave like Java? Or should .NET COBOL behave like JVM COBOL? This is a tricky one, but we’re going to stick with that aim of trying our best to make COBOL behave the same on both platforms.

But actually... although this might offer us some technical challenges, it could also offer great advantages to the Managed COBOL language because it could potentially get the best of both worlds (JVM world and .NET world) - if we implement .NET framework syntax in .NET COBOL we will also implement that syntax in JVM COBOL (unless there’s a good reason not to) even if it does not already exist in the JVM framework and vice versa.


SYNC keyword on methods*

This is a JVM syntax that does not exist in the .NET framework. We’ve added the SYNC keyword on methods for JVM COBOL and for consistency it is also supported in .NET COBOL. This does not exist in other C# or VB.


This is a new language feature in Visual COBOL R4.

Extension Methods**

This is a .NET feature that does not exist in the JVM. But because of our .NET COBOL & JVM COBOL parity aim, when extension method syntax was added to .NET COBOL it was also added to JVM COBOL. So extension method syntax is available in JVM COBOL, although not in other JVM languages.


This is a new language feature in Visual COBOL R4.

So .NET COBOL users get SYNC on method syntax and JVM COBOL users get extension method syntax - syntax that does not exist in other languages in that framework.

Managed COBOL Syntax

Managed COBOL includes OO syntax and also syntax that allows us to access the framework’s class library. Let’s have a brief look at those two areas.

OO Syntax

Managed COBOL provides support for classes, methods, inheritance, access levels (public, private) etc.

Sample code:


Accessing Class Libraries

Accessing the class library is fundamental to a managed language. The Managed COBOL syntax to allow you to do this are the invoke and set verbs.

set is used when you want to see the return type. For example:



In JVM :


And an invoke example :


In the set example, you can see that the COBOL syntax is the same in .NET COBOL & JVM COBOL. Where the program differs is the names of the namespaces/packages and classes available in your environment.

In .NET, string maps to the System.String class in the .NET class library. Length is a property of System.String which returns the length of the string.

In JVM, string maps to String class in the java.lang package. length() is a method of the java.lang.String which returns the length of the string.

Predefined Types

Predefined types have been used in the examples above, so worth a mention. These are new types that have been added to the COBOL syntax that map to managed framework types.

Predefined COBOL name

   .NET Class             

JVM equivalent       

Alternative COBOL





PIC S9(2) COMP-5




PIC S9(4) COMP-5




PIC S9(9) COMP-5




PIC S9(18) COMP-5





























Example - the recommended syntax for declaring a binary-long is :

 But the following 2 alternatives have the same effect:


Procedural COBOL

  • Procedural code can be compiled to native (unmanaged) or managed code (.NET or JVM)

Managed COBOL

  • Managed COBOL provides extensions to COBOL  to support the .NET or JVM frameworks
  • Compiled with the ilgen directive to run on .NET
  • Compiled with the jvmgen directive to run on JVM


  • Since “.NET COBOL” and “JVM COBOL” syntax are the same, we call the language “Managed COBOL” unless the syntax differs.  

* COBOL SYNC syntax

  • The SYNC keyword is the equivalent of LOCK in C#. It ensures that one thread does not enter a critical section of code while another thread is in the critical section. If another thread tries to enter SYNCed code, it will wait, block, until the object is released. You can a SYNC block around a block of code and from R4 you can also SYNC a method.




** COBOL Extension Method syntax

  • Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type. For Managed COBOL client code, there is no apparent difference between calling an extension method and the methods that are actually defined in a type.


Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.

Hi Paula,

Nice article, I would like to share some comments with you:

.Net does have method sync support, you just need to use an attribute,

for example: MethodImplAttribute(MethodImplOptions.Synchronized)]

Its a shame we do not allow the use of "length of" on the string object aka:

set my-binary-long to length of my-string

What happens if my class is a partial class or is said to be an "internal" class, is this something that is portable to the JVM world?

Finally the use of lock(self) is not recommend, have a look @ msdn.microsoft.com/.../c5kehkcz.aspx

Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2012-06-21 16:57
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.