WINCOBOL WINZOS WINIDE
Simon I'd like to thank you for NOT mentioning WINCOBOL.COM in your recent LinkedIn post. WINCOBOL as you know is free to use software.
There are about 3 people in the whole wide world that can understand the HUGE source code repository of GnuCOBOL.
Effective use of Open Source source code as it relates to GnuCOBOL is confined to the "principals". Wherein the "principals" are versed not only in COBOL but are experts at vanilla "C".
Furthermore, GnuCOBOL as advocated by the GnuCOBOL "principals" is primarily a Linux tool. Since Linux is free Open Source software. Windows is tolerated but the Windows distribution is provided gratis by a 3rd party person (Arnold Trembley).
Lacking a complex of understanding of "C" (and for that matter COBOL) limits the Open Source modifications to an extremely small subset of developers.
So you are correct - it is Open Source. BUT the "source" means nada / nothing to the vast majority of current or prospective GnuCOBOL users.
The Linux bias / Stallman bias STILL prevails - it should not.
It is not useful Open Source beyond the experts.
GnuCOBOL can do so much more that what Bard (Genesis) thinks of it - hobbyist focused , non commercial software.
Deaf ears I would suspect :-(
Last edit: Ralph Linkletter 2024-02-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also feel that way. I mostly lurk here but the constant Linux and Open Source centered bias is disturbing. Without Arnolds effort I would not be able to enjoy GNUCobol, thanks to him I can.
Sure 'real' developers use Linux, sadly in my whole live as a developer over 30+ years I never found even ONE company using Linux besides as Web or File Server.
NONE company is using it in Office/Backoffice or whatever you might call it.
Sadly (or not) Linux is still not existing in the world of Users. You can go into ANY company and they are running Windows. Period.
The common answer here is - use WSL, MinGW, Msys2 and press some Linux environment onto my customers, heck and also install the complete development system onto the client machine to even RUN a application you wrote.
And this is is very sad because Cobol just runs circles around - say C# and Access.
But - 'real' developers do not care about Windows User.
So - yes - I am still lurking here in hope that at some time I might be able to write software for my customers again in a language I love, without having to rewrite all of it again because of Net Framework xx gets replaced by Framework YY every 2 or 3 years.
A solid COBOL could get me out of that dilemma, but convincing Windows Domain Admins to install any GNUCobol written Software on say 30 to 50 Office PCs is simply a nightmare.
So sadly it seems to be impossible.
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, I'm possibly "in a bubble" here, but I really don't see a disturbing "constant Linux and Open Source centered bias" here. Most discussions go around COBOL itself or the use of GnuCOBOL (that even doesn't focus on the operating system), as well as work on GnuCOBOL and related tools. Additional to Arnold also Chuck and Eugenio do quite some Windows related work, too. Maybe you can show me what you see as disturbing, while rechecking if these parts just stand out because you may not read those in other places.
In any case you are welcome to post more about COBOL here in general, as well as about GnuCOBOL on Windows.
sadly in my whole live as a developer over 30+ years I never found even ONE company using Linux besides as Web or File Server.
NONE company is using it in Office/Backoffice or whatever you might call it.
My experience is different. In that MOST companies that use COBOL do quite heavy batch computing and as this is much faster on GNU/Linux than on Windows this is nearly always done on those systems (or older UNIX environments like AIX or Solaris), if it doesn't run on a mainframe (where GnuCOBOL would also run - with ease on their Linux environments, more hard on their "native" parts).
The installations I've seen (or helped with) which do use Windows were "small systems" or environments from Windows users starting to do some validation of their COBOL.
All the fancy "cloud systems" (you know, there is no cloud, just other peoples' computers) and containers are based on GNU/Linux.
To make that more explicit: ALL banks and insurance companies I've had contact with (no matter if they use GnuCOBOL or MicroFocus) that used COBOL on distributed systems used it on GNU/Linux (mostly Red Hat based).
Would you really want to handle millions of transactions on Windows?
You can go into ANY company and they are running Windows. Period.
That's possibly true for > 98%. You see it on their screens. But the important thing is: at least the bigger companies will do their actual work on servers (database and applications) and those will mostly run on GNU/Linux.
The common answer here is - use WSL, MinGW, Msys2 and press some Linux environment onto my customers, heck and also install the complete development system onto the client machine to even RUN a application you wrote.
Hm. For your develop environment you can just unpack (or run it as self-installing archive) this "MinGW based" environment. Then you may use something like a cobc.cmd to compile and a cobcrun.cmd to run COBOL. How is this worse than "install possibly more MB with a setup.exe that hooks into your registry and possibly download and install hundreds of MB for a Microsoft runtime, then use cob.exe and cobrun.exe"?
I do see the "what do I need to distribute to the customer part", but as you can just unpack the same package there it is not really a problem is it? And with the existing package one could easily create a "runtime only" package, too.
It is just a tedious task with no benefit other than providing a smaller one-time distributed dependency package...
without having to rewrite all of it again because of Net Framework xx gets replaced by Framework YY every 2 or 3 years
That's the nice thing with GnuCOBOL if you have portable COBOL code (no special .NET calls) - just take the code, compile it using Arnold's package with the matching -std, no need to replace anything but calls to routines specific to operating system changed or vendor extensions not (yet) in GnuCOBOL. If you want to: compile them later using a newer version of GnuCOBOL (and for all 2.2 -> 3.x; just swap the runtime if you don't need the newer features).
convincing Windows Domain Admins to install any GNUCobol written Software on say 30 to 50 Office PCs is simply a nightmare
OK, so we speak about distributed applications. Many AD admins will use remote desktops/applications in which case you only install it on the running servers (down to 1-4 for your example). No matter if there or on 50+ Desktop PCs, it should even work fine from a network share (which they will have), so no need for an installation either (the my-application.cmd can also setup a local COB_FILE_PATH or more reasonable DD_ vars for local files, if those aren't setup within the application) - as long as you don't use some GUI framework that needs a local install [if you need a DB client that will be a separate install in any case].
The Windows admins I spoke to like "put this folder on a read-only share and distribute this shortcut via their profile" much more than "install this on all your desktops. Did you tried that route?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Windows is tolerated but the Windows distribution is provided gratis by a 3rd party person (Arnold Trembley).
The GnuCOBOL project distributes the GnuCOBOL source, as well as source for related community projects and directly supports "3rd party" binary distributors.
Primarily for testing we have some CI running creating binary packages as well (currently GNU/Linux 64bit, MinGW package similar to Arnold's, MSVC based ones).
For Windows this is MSYS2; Arnold's MinGW builds (also used by choco and other windows package managers) and people distributing the MSYS2 builds (binary packages 32+64bit based on this are available from Chuck/Arnold, if you don't want to use MSYS2 for anything else and use its package manager), for example at https://cobolworx.com/pages/windows.html.
https://github.com/mridoni/gnucobol-binaries/releases (used as option to be installed directly when installing Gix IDE and https://get-superbol.com/software/gnucobol-windows-installer/ provide MSYS2 based and MSVC based downloads; the first may be extracted silently (if 7z is installed on the machine), the second provides .msi-files and a working silent installation (you know, the kind of thing that is used in Windows Active Directory environments) and also includes GCSORT and GixSQL.
The same is true "outside of Windows", binary packages are primarily distributed by 3rd parties as well. On GNU/Linux GnuCOBOL is commonly distributed with the system package manager (or additional packagers like HomeBrew), the bigger part of those also allow a "runtime only" installation.
Some people also provide binary packages as tarball (for example Ron distributed those to his customers) or as .deb/.rpm (COBOLWorx has those available, for example).
Last edit: Simon Sobisch 2024-02-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, in the users's desk but in the data center mostly runs linux and all those Windows machines serving as terminals.
COBOL in the modern world is mostly for the backend doing stuff that is too costly to rewrite, applications needs massive power because need to handle enormous traffic so can only run on mainframe or both.
I earn a live interfacing new applications to those backends running CICS, DB2 and sometimes IMS - and other not so fancy platforms like IBM-i.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
WINCOBOL WINZOS WINIDE
Simon I'd like to thank you for NOT mentioning WINCOBOL.COM in your recent LinkedIn post. WINCOBOL as you know is free to use software.
There are about 3 people in the whole wide world that can understand the HUGE source code repository of GnuCOBOL.
Effective use of Open Source source code as it relates to GnuCOBOL is confined to the "principals". Wherein the "principals" are versed not only in COBOL but are experts at vanilla "C".
Furthermore, GnuCOBOL as advocated by the GnuCOBOL "principals" is primarily a Linux tool. Since Linux is free Open Source software. Windows is tolerated but the Windows distribution is provided gratis by a 3rd party person (Arnold Trembley).
Lacking a complex of understanding of "C" (and for that matter COBOL) limits the Open Source modifications to an extremely small subset of developers.
So you are correct - it is Open Source. BUT the "source" means nada / nothing to the vast majority of current or prospective GnuCOBOL users.
The Linux bias / Stallman bias STILL prevails - it should not.
It is not useful Open Source beyond the experts.
GnuCOBOL can do so much more that what Bard (Genesis) thinks of it - hobbyist focused , non commercial software.
Deaf ears I would suspect :-(
Last edit: Ralph Linkletter 2024-02-28
yes, Ralph.
I also feel that way. I mostly lurk here but the constant Linux and Open Source centered bias is disturbing. Without Arnolds effort I would not be able to enjoy GNUCobol, thanks to him I can.
Sure 'real' developers use Linux, sadly in my whole live as a developer over 30+ years I never found even ONE company using Linux besides as Web or File Server.
NONE company is using it in Office/Backoffice or whatever you might call it.
Sadly (or not) Linux is still not existing in the world of Users. You can go into ANY company and they are running Windows. Period.
The common answer here is - use WSL, MinGW, Msys2 and press some Linux environment onto my customers, heck and also install the complete development system onto the client machine to even RUN a application you wrote.
And this is is very sad because Cobol just runs circles around - say C# and Access.
But - 'real' developers do not care about Windows User.
So - yes - I am still lurking here in hope that at some time I might be able to write software for my customers again in a language I love, without having to rewrite all of it again because of Net Framework xx gets replaced by Framework YY every 2 or 3 years.
A solid COBOL could get me out of that dilemma, but convincing Windows Domain Admins to install any GNUCobol written Software on say 30 to 50 Office PCs is simply a nightmare.
So sadly it seems to be impossible.
Mike
Hm, I'm possibly "in a bubble" here, but I really don't see a disturbing "constant Linux and Open Source centered bias" here. Most discussions go around COBOL itself or the use of GnuCOBOL (that even doesn't focus on the operating system), as well as work on GnuCOBOL and related tools. Additional to Arnold also Chuck and Eugenio do quite some Windows related work, too. Maybe you can show me what you see as disturbing, while rechecking if these parts just stand out because you may not read those in other places.
In any case you are welcome to post more about COBOL here in general, as well as about GnuCOBOL on Windows.
My experience is different. In that MOST companies that use COBOL do quite heavy batch computing and as this is much faster on GNU/Linux than on Windows this is nearly always done on those systems (or older UNIX environments like AIX or Solaris), if it doesn't run on a mainframe (where GnuCOBOL would also run - with ease on their Linux environments, more hard on their "native" parts).
The installations I've seen (or helped with) which do use Windows were "small systems" or environments from Windows users starting to do some validation of their COBOL.
All the fancy "cloud systems" (you know, there is no cloud, just other peoples' computers) and containers are based on GNU/Linux.
To make that more explicit: ALL banks and insurance companies I've had contact with (no matter if they use GnuCOBOL or MicroFocus) that used COBOL on distributed systems used it on GNU/Linux (mostly Red Hat based).
Would you really want to handle millions of transactions on Windows?
That's possibly true for > 98%. You see it on their screens. But the important thing is: at least the bigger companies will do their actual work on servers (database and applications) and those will mostly run on GNU/Linux.
Hm. For your develop environment you can just unpack (or run it as self-installing archive) this "MinGW based" environment. Then you may use something like a cobc.cmd to compile and a cobcrun.cmd to run COBOL. How is this worse than "install possibly more MB with a setup.exe that hooks into your registry and possibly download and install hundreds of MB for a Microsoft runtime, then use cob.exe and cobrun.exe"?
I do see the "what do I need to distribute to the customer part", but as you can just unpack the same package there it is not really a problem is it? And with the existing package one could easily create a "runtime only" package, too.
It is just a tedious task with no benefit other than providing a smaller one-time distributed dependency package...
That's the nice thing with GnuCOBOL if you have portable COBOL code (no special .NET calls) - just take the code, compile it using Arnold's package with the matching -std, no need to replace anything but calls to routines specific to operating system changed or vendor extensions not (yet) in GnuCOBOL. If you want to: compile them later using a newer version of GnuCOBOL (and for all 2.2 -> 3.x; just swap the runtime if you don't need the newer features).
OK, so we speak about distributed applications. Many AD admins will use remote desktops/applications in which case you only install it on the running servers (down to 1-4 for your example). No matter if there or on 50+ Desktop PCs, it should even work fine from a network share (which they will have), so no need for an installation either (the my-application.cmd can also setup a local
COB_FILE_PATHor more reasonableDD_vars for local files, if those aren't setup within the application) - as long as you don't use some GUI framework that needs a local install [if you need a DB client that will be a separate install in any case].The Windows admins I spoke to like "put this folder on a read-only share and distribute this shortcut via their profile" much more than "install this on all your desktops. Did you tried that route?
The GnuCOBOL project distributes the GnuCOBOL source, as well as source for related community projects and directly supports "3rd party" binary distributors.
Primarily for testing we have some CI running creating binary packages as well (currently GNU/Linux 64bit, MinGW package similar to Arnold's, MSVC based ones).
For Windows this is MSYS2; Arnold's MinGW builds (also used by choco and other windows package managers) and people distributing the MSYS2 builds (binary packages 32+64bit based on this are available from Chuck/Arnold, if you don't want to use MSYS2 for anything else and use its package manager), for example at https://cobolworx.com/pages/windows.html.
https://github.com/mridoni/gnucobol-binaries/releases (used as option to be installed directly when installing Gix IDE and https://get-superbol.com/software/gnucobol-windows-installer/ provide MSYS2 based and MSVC based downloads; the first may be extracted silently (if 7z is installed on the machine), the second provides .msi-files and a working silent installation (you know, the kind of thing that is used in Windows Active Directory environments) and also includes GCSORT and GixSQL.
The same is true "outside of Windows", binary packages are primarily distributed by 3rd parties as well. On GNU/Linux GnuCOBOL is commonly distributed with the system package manager (or additional packagers like HomeBrew), the bigger part of those also allow a "runtime only" installation.
Some people also provide binary packages as tarball (for example Ron distributed those to his customers) or as .deb/.rpm (COBOLWorx has those available, for example).
Last edit: Simon Sobisch 2024-02-29
Windows everywhere?
Yes, in the users's desk but in the data center mostly runs linux and all those Windows machines serving as terminals.
COBOL in the modern world is mostly for the backend doing stuff that is too costly to rewrite, applications needs massive power because need to handle enormous traffic so can only run on mainframe or both.
I earn a live interfacing new applications to those backends running CICS, DB2 and sometimes IMS - and other not so fancy platforms like IBM-i.