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.
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.
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.
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.
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.
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 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.
Managed COBOL provides support for classes, methods, inheritance, access levels (public, private) etc.
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 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
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:
* COBOL SYNC syntax
** COBOL Extension Method syntax
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