Microfocus Cobol - Unix to Linux and using other compilers

[Ron Campbell]

I'd like some guidance on compilers both open source and proprietary and what is needed to move from Microfocus compilers to others.

What are the changed Compiler Directives and Functions?

Specifically - Netcobol, and also Opencobol.

[Vince Coen]

Hello Ron!

Post by Ron Campbell
I'd like some guidance on compilers both open source and proprietary
and what is needed to move from Microfocus compilers to others.
What are the changed Compiler Directives and Functions?
Specifically - Netcobol, and also Opencobol.

Open Cobol is now called Gnu Cobol and current versions are v2.0 and v2.1.

The 1.1 version is also still available.

The v2 series is v2.0 with the v2.1 having RWDS (report writer) added but
is not as up to date with bug fixes etc as v2.0.

The RWDS will hopefully be merged into v2.0 soon.

There is also a version where the code is converted from C to C++ again
hopefully to create a OO version at a later date but this is early days.

GNU Cobol is supplied in source form as well as binaries for Windows and
can be compiled using MS Visual Studio also support for other platforms
including Mac OSX, BSD, ARM (Ra-berry Pi etc) another at a basic level (so
still needs more work on migration is IBM MVS.

Product comes with two test scripts built in to the make file the first is
a sanity check of some 500 tests and the second runs the NIST compiler
tests for which it passes most (some are bypassed).

This is used in production around the world in Linux, Windows, BSD and OSX
platforms notably in the UK, USA, Japan and a fair number of other
countries within government departments as well as businesses.

I have been using it myself since the early 2000's in mid sized Accounting
and other applications as well as migrated other business applications on
behalf of customers as a Freelance Contractor over the past 5 -7 years
covering over 1,000+ programs each.




Vince

[c***@acceo.com]

I ported our application from "Micro Focus COBOL for Unix V3.1 revision 060" to "Fujitsu NetCOBOL for Linux Version 7". There are about 600 COBOL source programs, with several million lines of code.

Compiler Directives were the simplest part of the conversion.

We now maintain a single source base in SCO while providing releases in both SCO and Linux. The installed base is hundreds of servers and thousands of users.

The entire project, from concept to full implementation, took about 18 months with work done by two programmers each part time and one part time QA. Total time spent on project was about one man-year. I had loads of prior COBOL conversion experience.

---Charlie

[Pete Dashwood]

Post by c***@acceo.com
I ported our application from "Micro Focus COBOL for Unix V3.1
revision 060" to "Fujitsu NetCOBOL for Linux Version 7". There are
about 600 COBOL source programs, with several million lines of code.
Compiler Directives were the simplest part of the conversion.
We now maintain a single source base in SCO while providing releases
in both SCO and Linux. The installed base is hundreds of servers and
thousands of users.
The entire project, from concept to full implementation, took about
18 months with work done by two programmers each part time and one
part time QA. Total time spent on project was about one man-year. I
had loads of prior COBOL conversion experience.
---Charlie

Good stuff!

Both Micro Focus and Fujitsu native code COBOL compilers are excellent
products from excellent companies.

Did the cost of run time licensing have anything to do with that decision?
:-)

I also switched from Micro Focus to Fujitsu many years ago, but it was
driven mostly by poor COM support in Net Express, where Fujitsu made it
really easy.

Some years later I resolved to move off COBOL completely, largely driven by
some shabby sales treatment from the then Fujitsu vendor.

When I look back now (having moved on from COBOL altogether), I have to
smile at the stress and anguish it all caused me.

Your post does raise an interesting point though... I wonder what colours
the decision by most people who change compiler vendors? Is it just about
money, or (as in my case) are there other emotional factors that contribute?

Pete.

[Vince Coen]

Hello Ron!

Post by Ron Campbell
I'd like some guidance on compilers both open source and proprietary
and what is needed to move from Microfocus compilers to others.
What are the changed Compiler Directives and Functions?
Specifically - ... Opencobol.

As said in a prev. msg OpenCobol has been renamed GnuCobol and is available
via :

http://sourceforge.net/p/open-cobol/code/HEAD/tree/branches/

Where you can select the various variants based on v2.

Compiler directives are very simple on GC main one being
' source free' or
' source fixed'

The former is the default and the later can be ignored if you always
remember to compile a free format program with cobc -x(or-m for modules)
-free progname.cbl etc.

There are additional directives that are conditionals e.g., if .. then else
etc.

Functions far to many to list here go to the following and get the
progrmmaers manual:

http://opencobol.add1tocobol.com/guides/

and select the version and manual format (A4 or US Letter).

I have been migrating system from both IBM m/f and MF Cobol WB, NE, VC
etc) with no real problems just time consuming depending in the sources
usage of extended screen handling, RDBMS, CICS etc.

GC is in a constant program of improvements and bug fixes and very well
supported within the community see:

http://sourceforge.net/p/open-cobol/discussion/


. NetCobol.

Can't say the same for NetCobol (Fujitsu) as all, Work (?) has been passed
to a company based in the USA but not to the benefit of users.
Updates and bug fixes as well as new versions/products are hardly on a
regular basis.


Vince

[c***@gmail.com]

Post by Vince Coen
Hello Ron!

Post by Ron Campbell
I'd like some guidance on compilers both open source and proprietary
and what is needed to move from Microfocus compilers to others.
What are the changed Compiler Directives and Functions?
Specifically - ... Opencobol.

As said in a prev. msg OpenCobol has been renamed GnuCobol and is available
http://sourceforge.net/p/open-cobol/code/HEAD/tree/branches/
Where you can select the various variants based on v2.
Compiler directives are very simple on GC main one being
' source free' or
' source fixed'
The former is the default and the later can be ignored if you always
remember to compile a free format program with cobc -x(or-m for modules)
-free progname.cbl etc.
There are additional directives that are conditionals e.g., if .. then else
etc.
Functions far to many to list here go to the following and get the
http://opencobol.add1tocobol.com/guides/
and select the version and manual format (A4 or US Letter).
I have been migrating system from both IBM m/f and MF Cobol WB, NE, VC
etc) with no real problems just time consuming depending in the sources
usage of extended screen handling, RDBMS, CICS etc.
GC is in a constant program of improvements and bug fixes and very well
http://sourceforge.net/p/open-cobol/discussion/
. NetCobol.
Can't say the same for NetCobol (Fujitsu) as all, Work (?) has been passed
to a company based in the USA but not to the benefit of users.
Updates and bug fixes as well as new versions/products are hardly on a
regular basis.
Vince

Has not been my experience with using NetCOBOL. The product is still supported and developed by Fujitsu Japan and the company GT Software sales and support the product outside of Japan. Many companies have successfully migrated from Micro Focus to NetCOBOL.

I think they have a webinar series addressing the conversions:

https://www.gtsoftware.com/resources/events/#Webinars

[Pete Dashwood]

Post by c***@gmail.com

Post by Vince Coen
Hello Ron!

Post by Ron Campbell
I'd like some guidance on compilers both open source and

proprietary > and what is needed to move from Microfocus compilers
to others.

Post by Ron Campbell
What are the changed Compiler Directives and Functions?
Specifically - ... Opencobol.

As said in a prev. msg OpenCobol has been renamed GnuCobol and is
http://sourceforge.net/p/open-cobol/code/HEAD/tree/branches/
Where you can select the various variants based on v2.
Compiler directives are very simple on GC main one being
' source free' or
' source fixed'
The former is the default and the later can be ignored if you always
remember to compile a free format program with cobc -x(or-m for
modules) -free progname.cbl etc.
There are additional directives that are conditionals e.g., if ..
then else etc.
Functions far to many to list here go to the following and get the
http://opencobol.add1tocobol.com/guides/
and select the version and manual format (A4 or US Letter).
I have been migrating system from both IBM m/f and MF Cobol WB, NE,
VC etc) with no real problems just time consuming depending in the
sources usage of extended screen handling, RDBMS, CICS etc.
GC is in a constant program of improvements and bug fixes and very
http://sourceforge.net/p/open-cobol/discussion/
. NetCobol.
Can't say the same for NetCobol (Fujitsu) as all, Work (?) has been
passed to a company based in the USA but not to the benefit of users.
Updates and bug fixes as well as new versions/products are hardly on
a regular basis.
Vince

Has not been my experience with using NetCOBOL. The product is still
supported and developed by Fujitsu Japan and the company GT Software
sales and support the product outside of Japan. Many companies have
successfully migrated from Micro Focus to NetCOBOL.
https://www.gtsoftware.com/resources/events/#Webinars

I have to agree. NetCOBOL would be my preference over Micro Focus, but I
would certainly recommend and use GNUCOBOL if it supported OO and COM.

Main objection to using COBOL is the lack of power compared to other more
modern languages (see post on XML elsewhere in this forum) and the COST!

C# is a free download. And the support is also free from a community of
millions of users...

Pete.

[Gary Crook]

Ron, if you want a full IDE you might want to consider Elastic COBOL as well.

You can get it for free at elasticcobol.com

Very strong support for the Micro Focus COBOL dialect.

Available on Windows, Linux, Mac OS X & Raspberry Pi.

[c***@acceo.com]

Pete,
--lots of snip--
Did the cost of run time licensing have anything to do with that decision?
Your post does raise an interesting point though... I wonder what colours
the decision by most people who change compiler vendors? Is it just about
money, or (as in my case) are there other emotional factors that contribute?
--

There were many considerations and we looked at all compilers available seven years ago.
- cost of runtime, AND cost of administering the licenses
- need to migrate from SCO to Linux
- ability to support relatively large programs (100K lines)
- simplicity of our code: I-O via our own C code (screen and files and ISAM)
- lack of need for tech support for compiler
- does the compiler make quality executables

Although I have worked with MF since the beginning, I have no emotional attachment. O/S and compilers come and go.

Cheers, Charlie