info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Announcing the development of Otterkit COBOL.
99 views
Skip to first unread message
KTSnowy (The Web Dev Fox)
Nov 26, 2022, 9:20:13 PM11/26/22
to
Today I'm announcing the development of Otterkit COBOL, a new free and open-source COBOL compiler that targets the dotnet runtime (more specifically, C#) and runs on macOS, Linux and Windows. We've been developing it for the past 3 months and I'm more confident in announcing its existence now, and I'm also really confident that with a little bit of work we could get a modern production-ready COBOL compiler that is free and open for everyone.
Currently the architecture for this compiler is split into the compiler itself and the runtime library. The runtime library being separate from the compiler also allows to more easily add more languages to the it, only requiring porting the runtime library and reuse some of the codegen methods (and a polyglot COBOL compiler would be pretty funny in my opinion and could be a fun thing to work on in the future. Finally fulfilling COBOL's purpose of being a truly portable "common business language").
Right now, it can't compile a full COBOL program yet, it's still missing the codegen which is something that I'm actively working on. BUT the foundation is already there, and the runtime library already implements some intrinsic functions and statements, and also correctly implements the COBOL datatypes and their PICTURE behavior, which in my opinion is one of the hardest things to implement correctly.
If you'd like to follow the development of Otterkit COBOL or if you'd like to help us develop an open-source and free modern COBOL compiler FASTER, check our GitHub organization:
https://github.com/otterkit
There's a discussions tab on the GitHub organization, feel free to ask anything there or suggest any changes and fixes if you find anything broken. My GitHub handle is @KTSnowy if you'd like to tag me in a discussion so that I can read it and reply earlier.
The compiler itself lives in the Otterkit repo:
https://github.com/otterkit/otterkit
And the runtime library lives in the Libotterkit repo:
https://github.com/otterkit/libotterkit
Both are licensed under the Apache-2.0 license.
Currently the architecture for this compiler is split into the compiler itself and the runtime library. The runtime library being separate from the compiler also allows to more easily add more languages to the it, only requiring porting the runtime library and reuse some of the codegen methods (and a polyglot COBOL compiler would be pretty funny in my opinion and could be a fun thing to work on in the future. Finally fulfilling COBOL's purpose of being a truly portable "common business language").
Right now, it can't compile a full COBOL program yet, it's still missing the codegen which is something that I'm actively working on. BUT the foundation is already there, and the runtime library already implements some intrinsic functions and statements, and also correctly implements the COBOL datatypes and their PICTURE behavior, which in my opinion is one of the hardest things to implement correctly.
If you'd like to follow the development of Otterkit COBOL or if you'd like to help us develop an open-source and free modern COBOL compiler FASTER, check our GitHub organization:
https://github.com/otterkit
There's a discussions tab on the GitHub organization, feel free to ask anything there or suggest any changes and fixes if you find anything broken. My GitHub handle is @KTSnowy if you'd like to tag me in a discussion so that I can read it and reply earlier.
The compiler itself lives in the Otterkit repo:
https://github.com/otterkit/otterkit
And the runtime library lives in the Libotterkit repo:
https://github.com/otterkit/libotterkit
Both are licensed under the Apache-2.0 license.
JM
Nov 28, 2022, 5:22:42 AM11/28/22
to
Regards,
KTSnowy (The Web Dev Fox)
Nov 28, 2022, 1:45:16 PM11/28/22
to
On Monday, November 28, 2022 at 7:22:42 AM UTC-3, JM wrote:
> Interesting. Good job. Waiting for the final version.
> Regards,
I'll make another announcement here when we get things working and ready to test with COBOL source code.
> Interesting. Good job. Waiting for the final version.
> Regards,
In the meantime let me know if there's something that you'd like to see implemented in the Otterkit compiler.
JM
Nov 29, 2022, 10:13:50 AM11/29/22
to
In .NET environment, WinForms integrated with Cobol it would be the way.
JM
Nov 29, 2022, 10:14:58 AM11/29/22
to
KTSnowy (The Web Dev Fox)
Dec 10, 2022, 12:32:46 AM12/10/22
to
Adding new statements to Otterkit is quite easy with the current architecture, so we could definitely support it in the future when the compiler gets to a more stable state.
Vincent Coen
Dec 10, 2022, 10:42:25 AM12/10/22
to
Hello KTSnowy!
Saturday December 10 2022 05:32, KTSnowy (The Web Dev Fox) wrote to All:
> On Tuesday, November 29, 2022 at 12:14:58 PM UTC-3, JM wrote:
>> A terça-feira, 29 de novembro de 2022 à(s) 15:13:50 UTC, JM
>> escreveu:
>> the way.. + SQL access!
> By SQL access so you mean IBM's EXEC SQL statement?
IBM did not design it and the EXEC SQL in supported by most if not all
RDBMS products including Mysql / mariadb, Postgres, Oracle, DB/2, MF SQL
server, and many others.
All are serviced by a pre-compiler that you feed the .scb sources to and
out comes a .cbl to pass to the Cobol compiler.
IT is a pity that there is no universal pre-compiler available that
supports more than one of these different RDB products but I was going to
upgrade the JC pre-compiler (written in Cobol) but other programming
requirements have gotten in the way..
> Adding new statements to Otterkit is quite easy with the current
> architecture, so we could definitely support it in the future when the
> compiler gets to a more stable state.
As some one has said a major requirement for a new compiler is full support
for a gui interface for all supported platform and where possible a link
into the SCREEN SECTION and accept, display accordingly.
This may be a bit of an ask i.e., supporting say Linux / *Nix and Windows
with the same product.
Vincent
Saturday December 10 2022 05:32, KTSnowy (The Web Dev Fox) wrote to All:
> On Tuesday, November 29, 2022 at 12:14:58 PM UTC-3, JM wrote:
>> A terça-feira, 29 de novembro de 2022 à(s) 15:13:50 UTC, JM
>> escreveu:
> By SQL access so you mean IBM's EXEC SQL statement?
RDBMS products including Mysql / mariadb, Postgres, Oracle, DB/2, MF SQL
server, and many others.
All are serviced by a pre-compiler that you feed the .scb sources to and
out comes a .cbl to pass to the Cobol compiler.
IT is a pity that there is no universal pre-compiler available that
supports more than one of these different RDB products but I was going to
upgrade the JC pre-compiler (written in Cobol) but other programming
requirements have gotten in the way..
> Adding new statements to Otterkit is quite easy with the current
> architecture, so we could definitely support it in the future when the
> compiler gets to a more stable state.
for a gui interface for all supported platform and where possible a link
into the SCREEN SECTION and accept, display accordingly.
This may be a bit of an ask i.e., supporting say Linux / *Nix and Windows
with the same product.
Vincent
Bill Gunshannon
Dec 10, 2022, 11:33:15 AM12/10/22
to
On 12/10/22 10:34, Vincent Coen wrote:
>
>
> IT is a pity that there is no universal pre-compiler available that
> supports more than one of these different RDB products but I was going to
> upgrade the JC pre-compiler (written in Cobol) but other programming
> requirements have gotten in the way..
>
Just out of curiosity, what is "the JC pre-complier"? A quick trip thru
>
>
> IT is a pity that there is no universal pre-compiler available that
> supports more than one of these different RDB products but I was going to
> upgrade the JC pre-compiler (written in Cobol) but other programming
> requirements have gotten in the way..
>
Google turned up nothing.
bill
KTSnowy (The Web Dev Fox)
Dec 10, 2022, 1:02:03 PM12/10/22
to
>As some one has said a major requirement for a new compiler is full support
>for a gui interface for all supported platform and where possible a link
>into the SCREEN SECTION and accept, display accordingly.
>This may be a bit of an ask i.e., supporting say Linux / *Nix and Windows
>with the same product.
One thing that we strongly disagree with in some current COBOL compilers is the apparent
>for a gui interface for all supported platform and where possible a link
>into the SCREEN SECTION and accept, display accordingly.
>This may be a bit of an ask i.e., supporting say Linux / *Nix and Windows
>with the same product.
need to embed additional functionality directly as compiler or COBOL language extensions.
We're trying a different approach and we're trying to make it easier to add and create external
libraries, COBOL 2022 has enough features and functionality to be able to write libraries and
frameworks, specially with it's OOP features. Having to embed extra functionality into the
language can easily make the compiler bloated and not cross OS, specially with GUI related stuff.
Yes, we're going to fully support the screen section and it's features from the 2022 standard,
but embedding any GUI framework into it would be a REALLY BAD idea. GUI is most of the time
not a cross OS thing, and most cross OS frameworks usually don't feel "native" to any OS.
Embedding any WinForms related functionality into the screen section itself would instantly
also make the compiler not compatible with Linux and macOS, and that would be quite bad.
Which is why we strongly believe that for Otterkit to work properly and have a place in a modern
ecosystem we need to make it easier to use and create COBOL libraries. It is a much better option
to support COBOL bindings for each OS's native GUI framework and let the user choose which one
to use and work with it as an added library or framework (Like every other ecosystem is doing it) than
directly embedding it into the language. It's also much easier to keep the compiler cross OS like this,
since each library and framework can be added as needed for each OS.
I was also thinking about including the EXEC SQL statement's functionality as a library function instead
of directly into the language as an actual statement. This seems much more reasonable today in 2022
and wouldn't be that much of a change. It will be much easier maintaining an SQL library for COBOL than
adding a specific RDBMS into the runtime itself to be able to run SQL statements. Supporting multiple
RDBMS systems would also be easier with an external library and not having to touch the compiler.
Something like: FUNCTION EXEC-SQL( "PostgreSQL" alphanumeric-literal ).
The first argument is the RDBMS to use, and the alphanumeric-literal would
contain the SQL statements passed to the RDBMS.
The same idea could be applied to any GUI framework, just provide COBOL bindings and expose any
GUI framework specific functions, classes, methods, etc as COBOL functions, classes and methods.
Now suddenly the work on the compiler will be much simpler and won't have to deviate much if at all
from the standard. Any added functionality or complexity is contained in external libraries.
Arne Vajhøj
Dec 11, 2022, 8:18:29 PM12/11/22
to
On 12/10/2022 1:02 PM, KTSnowy (The Web Dev Fox) wrote:
> I was also thinking about including the EXEC SQL statement's functionality as a library function instead
> of directly into the language as an actual statement. This seems much more reasonable today in 2022
> and wouldn't be that much of a change. It will be much easier maintaining an SQL library for COBOL than
> adding a specific RDBMS into the runtime itself to be able to run SQL statements. Supporting multiple
> RDBMS systems would also be easier with an external library and not having to touch the compiler.
Traditional each database comes with a pre-compiler for that specific
> I was also thinking about including the EXEC SQL statement's functionality as a library function instead
> of directly into the language as an actual statement. This seems much more reasonable today in 2022
> and wouldn't be that much of a change. It will be much easier maintaining an SQL library for COBOL than
> adding a specific RDBMS into the runtime itself to be able to run SQL statements. Supporting multiple
> RDBMS systems would also be easier with an external library and not having to touch the compiler.
database.
But that is not necessary when running in .NET environment. If the
pre-compiler generate ADO.NET calls using IDb types, then a single
pre-compiler would work with practically any RDBMS.
It would obviously just enable communication and allow standard
SQL (SQL-92 or whatever) to work - database specific SQL would
by definition not be portable. But that is an application
problem not a pre-compiler/runtime-library problem.
> Something like: FUNCTION EXEC-SQL( "PostgreSQL" alphanumeric-literal ).
> The first argument is the RDBMS to use, and the alphanumeric-literal would
> contain the SQL statements passed to the RDBMS.
is how it could work for embedded SQL with no reference to
host variables. But with host variables it becomes more
complicated - the pre-compiler generates code that
use those host variables in a manner that often
depends on the type of those.
Could a library call do something if the call included
SQL with placeholders and the actual host variables
by using reflection to detect the types of the host
variables and do something smart at runtime? Sure!
But work needed.
Arne
Vincent Coen
Dec 16, 2022, 10:39:20 AM12/16/22
to
Hello Bill!
Saturday December 10 2022 16:33, Bill Gunshannon wrote to All:
> On 12/10/22 10:34, Vincent Coen wrote:
>>
>>
http://www.applewood.linkpc.net/files/MySQL-Pre-Compilers/
as Presql-Nightly.rar
Description taken from top of the included presql2.pdf
A program to process SQL type syntax to be used with MySQL and
Mariadb (or others via ODBC) for input to the GnuCOBOL compiler
along with other support programs and files.
The following tools originating from Currey Adkins (Jim Currey) but some
what modified by myself, will allow preprocessing of MySQL type commands
into the source of a Cobol program prior to running the GnuCOBOL compiler,
in addition other tools that act as support to this function are also
included.
All references to MySQL also include Mariadb, a drop in replacement (usage
wise).
By standard convention the input file name should have extension name of
scb and the output file name should be .cbl. Note that scb stands for s =
SQL source, cb = cobol.
This package does NOT use EXEC statements but a variation of the theme as
extra commands are injected in to the source pack. At some point in the
future and if others request, I will add in direct support for EXEC SQL
syntax that will support both fixed and free source formats.
As supplied, the tools will accept a source file in free or fixed format.
The primary benefit of using this sub system is that the pre processor
accepts both free and fixed format program sources and provides additional
tools for creating copy books (see bldcopy2) used within a SQL based
program along with prtschema2 that will print out the entire table
structure of a given database.
Sample commands accepted are :
Syntax for MySQL Pre Processor Commands
Processes for Working-Storage
DEFINE
VAR
Processes for Procedure
Division
CLOSE
DELETE
FETCH
FREE
INIT
INSERT
LOCK
PRO
SELECT
SWITCHDB
UNLOCK
UPDATE
See the supplied manual for more information.
I use it within my SF available ACAS Business Accounting system written in
Cobol for the GnuCobol compiler also available on SF.
Vincent
Saturday December 10 2022 16:33, Bill Gunshannon wrote to All:
> On 12/10/22 10:34, Vincent Coen wrote:
>>
>>
>> IT is a pity that there is no universal pre-compiler available that
>> supports more than one of these different RDB products but I was
>> going to upgrade the JC pre-compiler (written in Cobol) but other
>> programming requirements have gotten in the way..
>>
>> supports more than one of these different RDB products but I was
>> going to upgrade the JC pre-compiler (written in Cobol) but other
>> programming requirements have gotten in the way..
>>
> Just out of curiosity, what is "the JC pre-complier"? A quick trip
> thru Google turned up nothing.
Obtainable from my nightly build area at :
> thru Google turned up nothing.
http://www.applewood.linkpc.net/files/MySQL-Pre-Compilers/
as Presql-Nightly.rar
Description taken from top of the included presql2.pdf
A program to process SQL type syntax to be used with MySQL and
Mariadb (or others via ODBC) for input to the GnuCOBOL compiler
along with other support programs and files.
The following tools originating from Currey Adkins (Jim Currey) but some
what modified by myself, will allow preprocessing of MySQL type commands
into the source of a Cobol program prior to running the GnuCOBOL compiler,
in addition other tools that act as support to this function are also
included.
All references to MySQL also include Mariadb, a drop in replacement (usage
wise).
By standard convention the input file name should have extension name of
scb and the output file name should be .cbl. Note that scb stands for s =
SQL source, cb = cobol.
This package does NOT use EXEC statements but a variation of the theme as
extra commands are injected in to the source pack. At some point in the
future and if others request, I will add in direct support for EXEC SQL
syntax that will support both fixed and free source formats.
As supplied, the tools will accept a source file in free or fixed format.
The primary benefit of using this sub system is that the pre processor
accepts both free and fixed format program sources and provides additional
tools for creating copy books (see bldcopy2) used within a SQL based
program along with prtschema2 that will print out the entire table
structure of a given database.
Sample commands accepted are :
Syntax for MySQL Pre Processor Commands
Processes for Working-Storage
DEFINE
VAR
Processes for Procedure
Division
CLOSE
DELETE
FETCH
FREE
INIT
INSERT
LOCK
PRO
SELECT
SWITCHDB
UNLOCK
UPDATE
See the supplied manual for more information.
I use it within my SF available ACAS Business Accounting system written in
Cobol for the GnuCobol compiler also available on SF.
Vincent
0 new messages