Just an information request. Is there anywhere a document that lists the extent to which Visual COBOL adheres to the ANSI/ISO COBOL standards? Obviously COBOL 85. But what about 2002, 2014 and 2023? I know that MF produced Object Oriented support (Object COBOL) but I've not been able to find the extent to which it differed from the standard.

I'm not interested in anything related to .NET - essentially Native (not Managed) coding.

Thanks

Just an information request. Is there anywhere a document that lists the extent to which Visual COBOL adheres to the ANSI/ISO COBOL standards? Obviously COBOL 85. But what about 2002, 2014 and 2023? I know that MF produced Object Oriented support (Object COBOL) but I've not been able to find the extent to which it differed from the standard.

I'm not interested in anything related to .NET - essentially Native (not Managed) coding.

Thanks

There really isn't any documentation that I know of that outlines the supported standards all in one place. 
The doc page that covers this briefly can be found here: It basically states that we are ANSI-85 compliant and we have implemented some of the features of ISO2002.

The ISO2002 syntax that we do support is shown with an ISO2002 bubble next to the syntax diagram itself.

There is also a DIALECT"ISO2002" directive that turns on a certain level of compatibility with this standard. It's documentation can be found here:

We support several different syntaxes when programming in OO COBOL in native code. There is the Micro Focus syntax which also uses an internal set of class libraries and then there is the ISO2002 syntax also.

We also maintain a degree of compatibility with many other COBOL dialects like IBM mainframe dialects and RM, ACU, etc. Look at the DIALECT directive for more information.

Just an information request. Is there anywhere a document that lists the extent to which Visual COBOL adheres to the ANSI/ISO COBOL standards? Obviously COBOL 85. But what about 2002, 2014 and 2023? I know that MF produced Object Oriented support (Object COBOL) but I've not been able to find the extent to which it differed from the standard.

I'm not interested in anything related to .NET - essentially Native (not Managed) coding.

Thanks

In addition to what Chris answered, it is very difficult these days to label a product like Visual COBOL as "supports 2014 or 2023 standard".

We are now on Version 9.0 of the product and the standards release in 2014 2023 included some new syntax as well as some syntax or features in COBOL that we've supported for years (e.g. Line Sequential files).

When the details are released for a standard, we may already have support for some features of it or over time we may gradually add support for that standard thru support for specific statements or new features of a statement. Our compiler technology supports many different dialects that were released over the years so there isn't just one dialect we support, and dialect doesn't necessarily equate to a standard.

It might be easier to identify what features of a standard that matter to you and then using our documentation determine if it is supported. e.g. SET DYNAMIC Length is supported, PERFORM until EXIT is supported, etc.

With regard to ISO2002, there is a compiler directive to turn on overall support for ISO2002 including reserved words. The setting is:

ISO2002 DIALECT setting

Using the DIALECT compiler directive

Just an information request. Is there anywhere a document that lists the extent to which Visual COBOL adheres to the ANSI/ISO COBOL standards? Obviously COBOL 85. But what about 2002, 2014 and 2023? I know that MF produced Object Oriented support (Object COBOL) but I've not been able to find the extent to which it differed from the standard.

I'm not interested in anything related to .NET - essentially Native (not Managed) coding.

Thanks

Paolo, there is a good book for this in german language.
Autor: Peter Roitzsch
Titel: Cobol 2014 Handbuch
Based on ISO/IEC-Standards 2014
ISBN: 978-3-7467-5638-7

Thank you. Unfortunately I don't speak/read German. However I have some 'classic' books about OO COBOL - by Raymond Obin, Edmund Arranga/Frank Coyle and Wilson Price. The problem I had was figuring out how representative MF OO COBOL was of the COBOL shown in these books. I now have a much clearer idea.

That OO COBOL book (based on that standard) was a good reference at the time.  The OO COBOL from that standard wasn't widely used I believe, because there wasn't an extensive framework of classes to use with it. The intention was that a framework would grow and be available for use. However, the .NET framework came along with its concept of common language specification. Many years later Visual COBOL has very strong support for a very modern OO COBOL syntax that allows COBOL to leverage both the .NET framework and the Java Framework...including 3rd pard libraries. With Visual COBOL, COBOL has effectively become both a .NET and Java language while still supporting traditional COBOL syntax.

I am gradually beginning to realise the problems with respect to OO COBOL. It seems I have 3 possible options:

a) To adhere to the standard, use Visual COBOL with dialect ISO2002  and write my own classes

b) Use the .NET framework - a non-starter for me. Managed code, in my view, is so far removed from traditional COBOL that I hardly recognise it. When I need .NET classes I use C#

c)  Use OO COBOL based class libraries (but with MF's interpretation of OO) via MF Visual Object COBOL. Don't laugh 😆 -  I used this in the '90s and it was an excellent product. I never understood why MF dropped it (and left a lot of unhappy users in the process.) I still have VOC running in Windows 95 in a virtual machine. Yes, I know - I'm a dinosaur but it's a usable option

Michael, this has been a very interesting discussion. Thank you, and Chris, for your input and insights.

I am gradually beginning to realise the problems with respect to OO COBOL. It seems I have 3 possible options:

a) To adhere to the standard, use Visual COBOL with dialect ISO2002  and write my own classes

b) Use the .NET framework - a non-starter for me. Managed code, in my view, is so far removed from traditional COBOL that I hardly recognise it. When I need .NET classes I use C#

c)  Use OO COBOL based class libraries (but with MF's interpretation of OO) via MF Visual Object COBOL. Don't laugh 😆 -  I used this in the '90s and it was an excellent product. I never understood why MF dropped it (and left a lot of unhappy users in the process.) I still have VOC running in Windows 95 in a virtual machine. Yes, I know - I'm a dinosaur but it's a usable option

Michael, this has been a very interesting discussion. Thank you, and Chris, for your input and insights.

Hi PaoloR 

Just to let you know, the OO class libraries and the native OO run-time are still included in Visual COBOL so you can continue to use them if you need to. There hasn't been any new development on them in a long time but they are definitely still present. 

Gael

You may already be aware of this but thought I would add it for clarity, managed COBOL, either .NET or JVM does not require that you write your programs using OO-COBOL syntax. You can compile standard procedural COBOL programs to .NET or JVM code and then call them directly from a front end like WinForms, WPF written in OO-COBOL or C# or JVM thru various Java frameworks. Most customers who are migrating an existing code base use this method. In that way you do not have to change any existing sources in order to be able to operate in a .NET or JVM environment.

II wasn't aware of that, Gael. I've looked at the various VC menus and I can't find any referring to, say, a Class Browser (such as the one in Visual Object COBOL and, prior to that, In Personal COBOL for Windows.)

So presumably the VC OO class libraries - not having any new development - are these same ones and presumably they follow MF's implementation of OO COBOL syntax. If so, then presumably the DIALECT ISO2002 directive would not be appropriate. So it seems that using VC + OO would be the same as using Visual Object COBOL 🤔

Where, in VC, can I find these libraries?

Sorry, I should have given you a better explanation. The old development tools are not included, so no class browser, form designer etc as Visual Studio has tools for creating Winfoms and WPF and the expectation is that new development would be done using those. It is only the class libraries themselves that are included, primarily to support existing applications such as those using Dialog System for example.

The binaries are in the bin and bin64 folders and the sources are in subfolders of the cpylib folder of the product installation ie basecl, guicl and olecl. To answer your question, yes, they are the same ones as in older products.

Sorry, I should have given you a better explanation. The old development tools are not included, so no class browser, form designer etc as Visual Studio has tools for creating Winfoms and WPF and the expectation is that new development would be done using those. It is only the class libraries themselves that are included, primarily to support existing applications such as those using Dialog System for example.

The binaries are in the bin and bin64 folders and the sources are in subfolders of the cpylib folder of the product installation ie basecl, guicl and olecl. To answer your question, yes, they are the same ones as in older products.

The old class library documentation from Net Express  is provided with Visual COBOL in the following location:

C:\\Program Files (x86)\\Micro Focus\\Visual COBOL\\help\\nxrclr.chm

You can also find it on-line under Net Express documentation here: