GNU COBOL vs. Micro Focus COBOL: A Detailed Comparison
Both GNU COBOL and Micro Focus COBOL are popular COBOL compilers, but they cater to different needs and offer distinct features. Here's a detailed comparison to help you choose the right one:
License and Cost:
GNU COBOL: Open-source and free to use.
Micro Focus COBOL: Proprietary software with various paid licensing options.
Supported Platforms:
GNU COBOL: Runs on various platforms like Linux, Windows, macOS, and Unix.
Micro Focus COBOL: Supports a wider range of platforms, including mainframes, cloud environments, and modern operating systems.
Compiling Standards:
GNU COBOL: Adheres to various COBOL standards, including ANSI/ISO COBOL 85, 2002, and 2014.
Micro Focus COBOL: Supports different COBOL standards, including IBM Enterprise COBOL and its own extensions.
Features:
GNU COBOL: Simpler compiler with basic COBOL features.
Micro Focus COBOL: Offers extensive features like debugging tools, IDE integration, performance optimization, and integration with other languages.
Performance:
GNU COBOL: May have slightly slower performance compared to Micro Focus COBOL.
Micro Focus COBOL: Generally optimized for performance and scalability.
Community and Support:
GNU COBOL: Large open-source community providing support through forums and mailing lists.
Micro Focus COBOL: Dedicated vendor support and professional services available.
Other Considerations:
GNU COBOL: Suitable for learning COBOL, hobby projects, and small-scale development.
Micro Focus COBOL: Preferred for enterprise-level applications, mission-critical systems, and COBOL modernization projects.
Choosing the Right Compiler:
Ultimately, the best COBOL compiler depends on your specific needs and priorities. Here's a quick guide:
Choose GNU COBOL if:
You need a free and open-source compiler.
You are learning COBOL or working on small projects.
You value community support.
Choose Micro Focus COBOL if:
You need extensive features and support for various platforms.
You are working on enterprise-level COBOL applications.
You require performance optimization and integration with other languages.
I hope this comprehensive comparison helps you make an informed decision - Thanks "Bard"
Last edit: Simon Sobisch 2024-03-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
supported platforms: GNU: nearly any in nearly any version since 199x, MF: most relevant ones (and if you want to switch, you likely need a new license)
standards: GNU many standards, including proprietary ones, including those supported by MF - but not all features implemented
features: GNU with much better integrations (but not to "Visual Studio" [vscode works fine though] and only partial Eclipse), not a "simple compiler with basic features" (apart from NIST85 it runs a bunch of newer IBM and newer COBOL standard features that only got included into most recent versions of MF), MF: a lot of mf-only (aka "lock-in" features [GNU works on providing a way out]), still better for integrating with Java (GNU is working on that ans should be at least a bit faster) and .NET
community and support: professional commercial support also available for GnuCOBOL (but don't be confused by the price tag which is much lower - as far as my experiences are the "service" is much better [most likely because you are not one of some million customers])
"other considerations" / choose: GNU preferred by banks and other large companies that do not have a mainframe-like environment (CICS, JCL, ...), because of "no recurring costs", better performance and debugging options, as well as the possibility for full code review
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ralph Says
Choose GNU COBOL if:
You need a free and open-source compiler.
You are learning COBOL or working on small projects.
You value community support.
Choose Micro Focus COBOL if:
You need extensive features and support for various platforms.
You are working on enterprise-level COBOL applications.
You require performance optimization and integration with other languages.
According to Ralph, if you want a "real" compiler, choose MF
I hope that GNUCOBOL can serve as a compiler for large-scale enterprise projects and I will work towards that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ralph just noted what commonly used "AI" models currently tell.
And as noted: there are banks and government environments where GnuCOBOL is used in production, as well as a bunch of others.
The models just weren't trained with this information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My post was that of Bard / Gemini (AI) comparing MF to GnuCOBOL.
"Ralph Says" is actually what Bard / Gemini stated.
A misinterpretation by Juan Carlos.
From 2018 on, I (Ralph) have sought to improve GnuCOBOL to embrace more zOS professional Cobol programmer usage.
zOS, the platform where 90% + of all COBOL usage is deployed.
Given that my focus is that of zOS COBOL professionals I can't really address the screen section idiosyncrasies of COBOL vendor "A" versus COBOL Vendor"B" as such relates to the implementation of screen section syntax / behavior.
Behavior / syntax is obviously vendor specific.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For Pottmi
These are comments that discourage focusing on solving problems and making the system more compatible. I think it's foolish to focus on the differences, it's not moving forward.
Anyway, Simon, as the leader of GNUCOBOL, is the one who should evaluate this and decide.
It has been said that Ralph transcribes what the AI says, in this discussion and in the SCREEN SECTION discussion Ralph seems to try to discourage moving towards the solution.
What interests me is that GNUCOBOL works and especially with full compatibility with MF and on Linux and I'm going to do everything in my power and possibilities for that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For Ralph
I think it's great that you have and continue to push for GNUCOBOL to work for Z/OS.
I've been working on Unix for about 38 years and on Linux for about 30 years and I'm interested in getting it to work on this system.
I think it may be of interest to many because Z/OS or Windows are not open systems when Linux is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For Simon
Before Monday I will prepare the list of errors that we have detected.
I will also document how we have solved the problem of compiling the programs in MF and GNUCOBOL simultaneously without errors.
These are simple scripts, simple ideas that can be useful for other conversions.
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I may be able to help with screen i/o not functioning as expected. I'll look your documentation when you post that. Any simple programs that exhibit the behavior issues along with screen shots of the expected results would be helpful.
Chuck Haatvedt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Last edit: Simon Sobisch 2024-03-12
So, what's your take on Bard's take?
My disagreements:
Ralph Says
Choose GNU COBOL if:
You need a free and open-source compiler.
You are learning COBOL or working on small projects.
You value community support.
Choose Micro Focus COBOL if:
You need extensive features and support for various platforms.
You are working on enterprise-level COBOL applications.
You require performance optimization and integration with other languages.
According to Ralph, if you want a "real" compiler, choose MF
I hope that GNUCOBOL can serve as a compiler for large-scale enterprise projects and I will work towards that.
Ralph just noted what commonly used "AI" models currently tell.
And as noted: there are banks and government environments where GnuCOBOL is used in production, as well as a bunch of others.
The models just weren't trained with this information.
I really believe that there are people on the forum whose real intention is to prevent this from moving forward.
“intention is to prevent this from moving forward.”
What are you observing that makes you say that?
What is “this”?
On Wed, Sep 4, 2024 at 12:20 Juan Carlos Escartí juanc@users.sourceforge.net wrote:
My post was that of Bard / Gemini (AI) comparing MF to GnuCOBOL.
"Ralph Says" is actually what Bard / Gemini stated.
A misinterpretation by Juan Carlos.
From 2018 on, I (Ralph) have sought to improve GnuCOBOL to embrace more zOS professional Cobol programmer usage.
zOS, the platform where 90% + of all COBOL usage is deployed.
Given that my focus is that of zOS COBOL professionals I can't really address the screen section idiosyncrasies of COBOL vendor "A" versus COBOL Vendor"B" as such relates to the implementation of screen section syntax / behavior.
Behavior / syntax is obviously vendor specific.
Ralph
For Pottmi
These are comments that discourage focusing on solving problems and making the system more compatible. I think it's foolish to focus on the differences, it's not moving forward.
Anyway, Simon, as the leader of GNUCOBOL, is the one who should evaluate this and decide.
It has been said that Ralph transcribes what the AI says, in this discussion and in the SCREEN SECTION discussion Ralph seems to try to discourage moving towards the solution.
What interests me is that GNUCOBOL works and especially with full compatibility with MF and on Linux and I'm going to do everything in my power and possibilities for that.
For Ralph
I think it's great that you have and continue to push for GNUCOBOL to work for Z/OS.
I've been working on Unix for about 38 years and on Linux for about 30 years and I'm interested in getting it to work on this system.
I think it may be of interest to many because Z/OS or Windows are not open systems when Linux is.
For Simon
Before Monday I will prepare the list of errors that we have detected.
I will also document how we have solved the problem of compiling the programs in MF and GNUCOBOL simultaneously without errors.
These are simple scripts, simple ideas that can be useful for other conversions.
Regards
Juan,
I may be able to help with screen i/o not functioning as expected. I'll look your documentation when you post that. Any simple programs that exhibit the behavior issues along with screen shots of the expected results would be helpful.