Announcement: gcobol

Announcement: gcobol

[James K. Lowden]

https://git.symas.net:443/cobolworx/gcc-cobol/
https://github.com/Apress/beg-cobol-for-programmers

Greetings, gcc!  We come bearing gifts! 

When you set your clock ahead an hour yesterday, you might not have
realized you set your calendar back to 1985.  There's a new gcc COBOL
compiler. We call it: gcobol.

On the books, we have 1 man-year invested: two full-time
programmers since October 2021.

We have so far compiled just over 100 programs from the examples in
"Beginning COBOL for Programmers", by Michael Coughlin. We are near the
end of that phase of the project, and expect to have ISAM and
Object-Oriented Cobol features implemented in the next few weeks.  We
are working on compiling the NIST COBOL test suite, which we expect
will take a few months to complete.  We have begun work on  gdb, too,
and hope to have it working by year end. 

Our project should not be confused with GnuCOBOL
(https://savannah.gnu.org/projects/gnucobol).  That project is a Cobol
translator: it compiles Cobol to C, and invokes gcc to produce
executable code.  Our gcobol compiler is (currently) a fork of gcc.  It
implements a gcc frontend for Cobol and (obviously) invokes the gcc
backend to produce executables.  (We have a friendly relationship with
GnuCOBOL, and its maintainer supports our undertaking.)

Ours should also not be confused with prior efforts to create a gcc
Cobol compiler.  Others have tried and failed.  Failure wasn't an
option for us.  I won't say it was easy, but here we are. 

Eventually, if the gcc maintainers are interested, we would like to
pursue full integration with gcc.  For the moment, we have questions
we're hoping can be answered here by those who ran the gauntlet
before us.  Given the state of the internals documentation, that seems
like our best option. We've been rummaging around in the odd sock
drawer for too long.  

If you're like me (like I was), your visceral response to this
announcement can be summed up in one word: Why?

The answer is as easy as it is trite: the right tool for the job.

I wouldn't write an operating system in Cobol.  But I wouldn't write
one in Python or Java, either.  Cobol has a niche no other language
occupies: a compiled language for record-oriented I/O.  

That might sound strangely specialized, but it's not.  Record-oriented
I/O describes, I would argue, nearly *all* applications.  Yet, since the
advent of C, nearly all applications have relegated I/O to an external
library, and adopted the Unix byte-stream definition of a "file".

If you've written a CGI web application, you know what I'm talking
about.  Cobol eliminates a lot of gobbledygook by reducing free-form
run-time variables to compile-time constants.

That's the rationale, and it's not just a theory.  Cobol is alive and
kicking.  Estimates vary, but they all say north of 100 billion lines
of Cobol are still in use, with millions more written every year, even
now, in the 21st century.  Odds are your last ATM transaction or credit
card purchase went through a Cobol application.

There's another answer to Why: because a free Cobol compiler is an
essential component to any effort to migrate mainframe applications to
what mainframe folks still call "distributed systems".  Our goal is a
Cobol compiler that will compile mainframe applications on Linux.  Not
a toy: a full-blooded replacement that solves problems.  One that runs
fast and whose output runs fast, and has native gdb support.

I am happy to debate the lunacy of this project and the viability of
Cobol, either here or off-list.  Today, we want to make the project
known to those in the technical community who might most want to know
what we're up to, and explain why we'll be asking the questions we're
asking.  

Also, if you want to give it a whirl, please don't hesitate.  We're
happy to help, and expect to learn something in the process. 

Thank you for you kind attention.

--jkl

Re: Announcement: gcobol

[David Edelsohn]

On Mon, Mar 14, 2022 at 4:35 PM James K. Lowden
<jklowden@schemamania.org> wrote:
>
> https://git.symas.net:443/cobolworx/gcc-cobol/
> https://github.com/Apress/beg-cobol-for-programmers
>
> Greetings, gcc!  We come bearing gifts!
>
> When you set your clock ahead an hour yesterday, you might not have
> realized you set your calendar back to 1985.  There's a new gcc COBOL
> compiler. We call it: gcobol.
>
> On the books, we have 1 man-year invested: two full-time
> programmers since October 2021.
>
> We have so far compiled just over 100 programs from the examples in
> "Beginning COBOL for Programmers", by Michael Coughlin. We are near the
> end of that phase of the project, and expect to have ISAM and
> Object-Oriented Cobol features implemented in the next few weeks.  We
> are working on compiling the NIST COBOL test suite, which we expect
> will take a few months to complete.  We have begun work on  gdb, too,
> and hope to have it working by year end.
>
> Our project should not be confused with GnuCOBOL
> (https://savannah.gnu.org/projects/gnucobol).  That project is a Cobol
> translator: it compiles Cobol to C, and invokes gcc to produce
> executable code.  Our gcobol compiler is (currently) a fork of gcc.  It
> implements a gcc frontend for Cobol and (obviously) invokes the gcc
> backend to produce executables.  (We have a friendly relationship with
> GnuCOBOL, and its maintainer supports our undertaking.)
>
> Ours should also not be confused with prior efforts to create a gcc
> Cobol compiler.  Others have tried and failed.  Failure wasn't an
> option for us.  I won't say it was easy, but here we are.
>
> Eventually, if the gcc maintainers are interested, we would like to
> pursue full integration with gcc.  For the moment, we have questions
> we're hoping can be answered here by those who ran the gauntlet
> before us.  Given the state of the internals documentation, that seems
> like our best option. We've been rummaging around in the odd sock
> drawer for too long.
>
> If you're like me (like I was), your visceral response to this
> announcement can be summed up in one word: Why?
>
> The answer is as easy as it is trite: the right tool for the job.
>
> I wouldn't write an operating system in Cobol.  But I wouldn't write
> one in Python or Java, either.  Cobol has a niche no other language
> occupies: a compiled language for record-oriented I/O.
>
> That might sound strangely specialized, but it's not.  Record-oriented
> I/O describes, I would argue, nearly *all* applications.  Yet, since the
> advent of C, nearly all applications have relegated I/O to an external
> library, and adopted the Unix byte-stream definition of a "file".
>
> If you've written a CGI web application, you know what I'm talking
> about.  Cobol eliminates a lot of gobbledygook by reducing free-form
> run-time variables to compile-time constants.
>
> That's the rationale, and it's not just a theory.  Cobol is alive and
> kicking.  Estimates vary, but they all say north of 100 billion lines
> of Cobol are still in use, with millions more written every year, even
> now, in the 21st century.  Odds are your last ATM transaction or credit
> card purchase went through a Cobol application.
>
> There's another answer to Why: because a free Cobol compiler is an
> essential component to any effort to migrate mainframe applications to
> what mainframe folks still call "distributed systems".  Our goal is a
> Cobol compiler that will compile mainframe applications on Linux.  Not
> a toy: a full-blooded replacement that solves problems.  One that runs
> fast and whose output runs fast, and has native gdb support.
>
> I am happy to debate the lunacy of this project and the viability of
> Cobol, either here or off-list.  Today, we want to make the project
> known to those in the technical community who might most want to know
> what we're up to, and explain why we'll be asking the questions we're
> asking.
>
> Also, if you want to give it a whirl, please don't hesitate.  We're
> happy to help, and expect to learn something in the process.
>
> Thank you for you kind attention.
>
> --jkl

Hi, James

Great work!  Looking forward to having the GCobol front-end contributed to GCC.

Thanks, David

Re: Announcement: gcobol

[Jose E. Marchesi]

> https://git.symas.net:443/cobolworx/gcc-cobol/
> https://github.com/Apress/beg-cobol-for-programmers
>
> Greetings, gcc!  We come bearing gifts!
>
> When you set your clock ahead an hour yesterday, you might not have
> realized you set your calendar back to 1985.  There's a new gcc COBOL
> compiler. We call it: gcobol.

Awesome :)

Re: Announcement: gcobol

[Aldy Hernandez]

I paid for high school and university writing Cobol, so I'm strangely
interested in the project.  Seems like life has come full circle for
me :).

Aldy

On Mon, Mar 14, 2022 at 9:35 PM James K. Lowden
<jklowden@schemamania.org> wrote:
>
> https://git.symas.net:443/cobolworx/gcc-cobol/
> https://github.com/Apress/beg-cobol-for-programmers
>
> Greetings, gcc!  We come bearing gifts!
>
> When you set your clock ahead an hour yesterday, you might not have
> realized you set your calendar back to 1985.  There's a new gcc COBOL
> compiler. We call it: gcobol.
>
> On the books, we have 1 man-year invested: two full-time
> programmers since October 2021.
>
> We have so far compiled just over 100 programs from the examples in
> "Beginning COBOL for Programmers", by Michael Coughlin. We are near the
> end of that phase of the project, and expect to have ISAM and
> Object-Oriented Cobol features implemented in the next few weeks.  We
> are working on compiling the NIST COBOL test suite, which we expect
> will take a few months to complete.  We have begun work on  gdb, too,
> and hope to have it working by year end.
>
> Our project should not be confused with GnuCOBOL
> (https://savannah.gnu.org/projects/gnucobol).  That project is a Cobol
> translator: it compiles Cobol to C, and invokes gcc to produce
> executable code.  Our gcobol compiler is (currently) a fork of gcc.  It
> implements a gcc frontend for Cobol and (obviously) invokes the gcc
> backend to produce executables.  (We have a friendly relationship with
> GnuCOBOL, and its maintainer supports our undertaking.)
>
> Ours should also not be confused with prior efforts to create a gcc
> Cobol compiler.  Others have tried and failed.  Failure wasn't an
> option for us.  I won't say it was easy, but here we are.
>
> Eventually, if the gcc maintainers are interested, we would like to
> pursue full integration with gcc.  For the moment, we have questions
> we're hoping can be answered here by those who ran the gauntlet
> before us.  Given the state of the internals documentation, that seems
> like our best option. We've been rummaging around in the odd sock
> drawer for too long.
>
> If you're like me (like I was), your visceral response to this
> announcement can be summed up in one word: Why?
>
> The answer is as easy as it is trite: the right tool for the job.
>
> I wouldn't write an operating system in Cobol.  But I wouldn't write
> one in Python or Java, either.  Cobol has a niche no other language
> occupies: a compiled language for record-oriented I/O.
>
> That might sound strangely specialized, but it's not.  Record-oriented
> I/O describes, I would argue, nearly *all* applications.  Yet, since the
> advent of C, nearly all applications have relegated I/O to an external
> library, and adopted the Unix byte-stream definition of a "file".
>
> If you've written a CGI web application, you know what I'm talking
> about.  Cobol eliminates a lot of gobbledygook by reducing free-form
> run-time variables to compile-time constants.
>
> That's the rationale, and it's not just a theory.  Cobol is alive and
> kicking.  Estimates vary, but they all say north of 100 billion lines
> of Cobol are still in use, with millions more written every year, even
> now, in the 21st century.  Odds are your last ATM transaction or credit
> card purchase went through a Cobol application.
>
> There's another answer to Why: because a free Cobol compiler is an
> essential component to any effort to migrate mainframe applications to
> what mainframe folks still call "distributed systems".  Our goal is a
> Cobol compiler that will compile mainframe applications on Linux.  Not
> a toy: a full-blooded replacement that solves problems.  One that runs
> fast and whose output runs fast, and has native gdb support.
>
> I am happy to debate the lunacy of this project and the viability of
> Cobol, either here or off-list.  Today, we want to make the project
> known to those in the technical community who might most want to know
> what we're up to, and explain why we'll be asking the questions we're
> asking.
>
> Also, if you want to give it a whirl, please don't hesitate.  We're
> happy to help, and expect to learn something in the process.
>
> Thank you for you kind attention.
>
> --jkl
>
>