With many thanks to Chuck Haatvedt and Simon Sobisch, you can now build GnuCOBOL Release Candidate 2 for Windows in 32-bit and 64-bit versions using MSYS2. These builds include gmplib 6.2.1, PDCursesMod 4.3.5, Berkeley DataBase 18.1.40 (for ISAM), and GCSORT.exe. MSYS2 uses GCC 12.2.0 as the embedded C Compiler. These binaries also include XML parsing, cJSON, code coverage testing, and debugging support. You can download a binary compressed with 7-Zip and rename the file extension from "7z" to "exe". Then you can run it as a self-installing archive. See the STARTHERE.txt file, or open a cmd.exe window in the install folder, and run "set_env.cmd" to set the environment variables. You can also download the MSYS2-Build-Kit.7z archive which contains the Build Guide in LibreOffice DOCX format and in PDF format.
Hi Arnold,
thanks once again for this very useful service to so many people.
A simple question to eliminate basic doubts .
What do you suggest on a WINDOWS 10 system, should we download and use the 64-bit version or the 32-bit one ?
Given that the 64-bit version is certainly more powerful, why is the 32-bit version still available ?
Once the 64-bit version is available, what reason does the 32-bit version have to still exist?
PS. One more question. Why are the Phyton libraries present in these files that you have prepared?
Last edit: Eugenio Di Lorenzo 2023-02-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Reason to use 31 bit /32 bit COBOL:
. COBOL professionals that write COBOL programs using preprocessors
CICS, IMS (EXEC DLI), EXEC SQL (some 3rd party vendors only support 31 bit)
. COBOL professionals that interface COBOL programs to operating system API(s)
. COBOL professionals that interface COBOL programs to 3rd party product API(s)
Reason to use 64 bit COBOL:
. There is need for a COBOL load module exceeding 2,000,000,000 bytes (2 BILLION) bytes of addressability
. You are enthralled with solutions in search of a problem :-)
Last edit: Ralph Linkletter 2023-02-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
More reasons for 64 bit: the instruction set is much newer so the underlying runtime / compiler can optimize more, it is also quite likely that you benefit of more available registers.
And: a bunch of software professional COBOL developers want/need to use start to be available in only 64 bit environments...
And: some professionals want to go 'totally cloud' and in some environments you can get much more cpu when using ARM64...
Have y'all considered that GnuCOBOL should have an AMODE compiler option ?
Certainly billions of lines of existing COBOL are not going to be rewritten and recompiled to support an unnecessary and needless 8 byte register / address.
Think AMODE(31) as a GnuCOBOL compiler directive, an option enabling compilation with the 64 bit GnuCOBOL but executes with 99.9999 % of the existing COBOL ecosystem.
From IBM documentation.
Addressing mode (AMODE)
Last Updated: 2021-06-25
A program can run in addressing mode (AMODE) 24, 31, or 64. A program that executes in AMODE 24 or 31 can invoke most of the services described in this information. A program that executes in AMODE 64 has a smaller group of services that it can invoke.
In general:
A program running in AMODE 24 cannot pass parameters or parameter addresses that are higher than 16 megabytes. However, there are exceptions. For example, a program running in AMODE 24 can:
Free storage above 16 megabytes using the FREEMAIN macro
Allocate storage above 16 megabytes using the GETMAIN macro
Use cell pool services for cell pools located in storage above 16 megabytes using the CPOOL macro
Use page services for storage locations above 16 megabytes using the PGSER macro
A program is allowed to call a service from AMODE 64 only if the documentation for the service indicates that it supports AMODE 64.
A program is allowed to call a service from RMODE 64 only if the documentation for the service indicates that it supports RMODE 64.
A program running in AMODE 64 should not call a service with data, parameters, or parameter addresses that are higher than 2 gigabytes, unless the individual service description indicates that it is allowed.
If a program running in AMODE 31 or 64 issues a service, parameters and parameter addresses can be above or below 16 megabytes, unless otherwise stated in the individual service description. Unless explicitly stated otherwise, assume that a given service cannot be invoked in AMODE 64 and cannot accept data, parameters, or parameter addresses above 2 gigabytes
Last edit: Ralph Linkletter 2023-02-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suspect that this may be related to whether or not a Win32 program can execute in the same processid as a Win64.... I suspect that within a PID all programs must be the same architecture.
where as on Z/OS 24 bit and 31 bit programs can both execute in an address space.
See this link for more information...
However, 64-bit Windows supports remote procedure calls (RPC) between 64-bit and 32-bit processes (both on the same computer and across computers).
Chuck I was speaking to the comments as to why a 64 bit COBOL compiler is a vogue requirement.
I think it a disservice to promote a 64 bit COBOL compiler when there is zero need for such. The hobbyists are an obvious exception.
A professional COBOL programmer needs to adhere to the logic of the current state of the COBOL ecosystem - it is a 31 bit world.
I was not contemplating SYSWOW64, Program Files (x86), Program Files.
Clearly SYSWOW64 and program files (x86) exist such that Windows 64 bit can execute 32 bit applications. SYSWOW64, despite its name, contains the 32-bit components on a 64-bit operating system.
It is my contention that a 64 bit COBOL compiler is a solution in search of a problem where no problem exists. Regardless the operating system.
There are significant, logical reasons to stay with 31 bit than there are reasons to play in the sand box with 64 bit.
From my z/OS bias the IBM comment below seems logical.
**Unless explicitly stated otherwise, assume that a given service cannot be invoked in AMODE 64 and cannot accept data, parameters, or parameter addresses above 2 gigabytes
**
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With many thanks to Chuck Haatvedt and Simon Sobisch, you can now build GnuCOBOL Release Candidate 2 for Windows in 32-bit and 64-bit versions using MSYS2. These builds include gmplib 6.2.1, PDCursesMod 4.3.5, Berkeley DataBase 18.1.40 (for ISAM), and GCSORT.exe. MSYS2 uses GCC 12.2.0 as the embedded C Compiler. These binaries also include XML parsing, cJSON, code coverage testing, and debugging support. You can download a binary compressed with 7-Zip and rename the file extension from "7z" to "exe". Then you can run it as a self-installing archive. See the STARTHERE.txt file, or open a cmd.exe window in the install folder, and run "set_env.cmd" to set the environment variables. You can also download the MSYS2-Build-Kit.7z archive which contains the Build Guide in LibreOffice DOCX format and in PDF format.
https://www.arnoldtrembley.com/GC32M-BDB-x64-rc2-rename-7z-to-exe.7z
https://www.arnoldtrembley.com/GC32M-BDB-x32-rc2-rename-7z-to-exe.7z
https://www.arnoldtrembley.com/MSYS2-Build-Kit-v05.7z
Kind regards,
Hi Arnold,
thanks once again for this very useful service to so many people.
A simple question to eliminate basic doubts .
What do you suggest on a WINDOWS 10 system, should we download and use the 64-bit version or the 32-bit one ?
Given that the 64-bit version is certainly more powerful, why is the 32-bit version still available ?
Once the 64-bit version is available, what reason does the 32-bit version have to still exist?
PS. One more question. Why are the Phyton libraries present in these files that you have prepared?
Last edit: Eugenio Di Lorenzo 2023-02-11
The only reasons to use 32 bit executables:
The Python libraries are included to support Gnu Debugger and/or code coverage debugging. PERL may also be required for that as well.
I still plan on doing MinGW 32 bit builds, but building them is less automated than building with the MSYS2/MinGW64 toolchain.
Kind regards,
Reason to use 31 bit /32 bit COBOL:
. COBOL professionals that write COBOL programs using preprocessors
CICS, IMS (EXEC DLI), EXEC SQL (some 3rd party vendors only support 31 bit)
. COBOL professionals that interface COBOL programs to operating system API(s)
. COBOL professionals that interface COBOL programs to 3rd party product API(s)
Reason to use 64 bit COBOL:
. There is need for a COBOL load module exceeding 2,000,000,000 bytes (2 BILLION) bytes of addressability
. You are enthralled with solutions in search of a problem :-)
Last edit: Ralph Linkletter 2023-02-11
More reasons for 64 bit: the instruction set is much newer so the underlying runtime / compiler can optimize more, it is also quite likely that you benefit of more available registers.
And: a bunch of software professional COBOL developers want/need to use start to be available in only 64 bit environments...
And: some professionals want to go 'totally cloud' and in some environments you can get much more cpu when using ARM64...
Have y'all considered that GnuCOBOL should have an AMODE compiler option ?
Certainly billions of lines of existing COBOL are not going to be rewritten and recompiled to support an unnecessary and needless 8 byte register / address.
Think AMODE(31) as a GnuCOBOL compiler directive, an option enabling compilation with the 64 bit GnuCOBOL but executes with 99.9999 % of the existing COBOL ecosystem.
From IBM documentation.
Addressing mode (AMODE)
Last Updated: 2021-06-25
A program can run in addressing mode (AMODE) 24, 31, or 64. A program that executes in AMODE 24 or 31 can invoke most of the services described in this information. A program that executes in AMODE 64 has a smaller group of services that it can invoke.
In general:
A program running in AMODE 24 cannot pass parameters or parameter addresses that are higher than 16 megabytes. However, there are exceptions. For example, a program running in AMODE 24 can:
Free storage above 16 megabytes using the FREEMAIN macro
Allocate storage above 16 megabytes using the GETMAIN macro
Use cell pool services for cell pools located in storage above 16 megabytes using the CPOOL macro
Use page services for storage locations above 16 megabytes using the PGSER macro
A program is allowed to call a service from AMODE 64 only if the documentation for the service indicates that it supports AMODE 64.
A program is allowed to call a service from RMODE 64 only if the documentation for the service indicates that it supports RMODE 64.
A program running in AMODE 64 should not call a service with data, parameters, or parameter addresses that are higher than 2 gigabytes, unless the individual service description indicates that it is allowed.
If a program running in AMODE 31 or 64 issues a service, parameters and parameter addresses can be above or below 16 megabytes, unless otherwise stated in the individual service description.
Unless explicitly stated otherwise, assume that a given service cannot be invoked in AMODE 64 and cannot accept data, parameters, or parameter addresses above 2 gigabytes
Last edit: Ralph Linkletter 2023-02-11
Ralph,
I suspect that this may be related to whether or not a Win32 program can execute in the same processid as a Win64.... I suspect that within a PID all programs must be the same architecture.
where as on Z/OS 24 bit and 31 bit programs can both execute in an address space.
See this link for more information...
However, 64-bit Windows supports remote procedure calls (RPC) between 64-bit and 32-bit processes (both on the same computer and across computers).
https://learn.microsoft.com/en-us/windows/win32/winprog64/process-interoperability
Chuck I was speaking to the comments as to why a 64 bit COBOL compiler is a vogue requirement.
I think it a disservice to promote a 64 bit COBOL compiler when there is zero need for such. The hobbyists are an obvious exception.
A professional COBOL programmer needs to adhere to the logic of the current state of the COBOL ecosystem - it is a 31 bit world.
I was not contemplating SYSWOW64, Program Files (x86), Program Files.
Clearly SYSWOW64 and program files (x86) exist such that Windows 64 bit can execute 32 bit applications. SYSWOW64, despite its name, contains the 32-bit components on a 64-bit operating system.
It is my contention that a 64 bit COBOL compiler is a solution in search of a problem where no problem exists. Regardless the operating system.
There are significant, logical reasons to stay with 31 bit than there are reasons to play in the sand box with 64 bit.
From my z/OS bias the IBM comment below seems logical.
**Unless explicitly stated otherwise, assume that a given service cannot be invoked in AMODE 64 and cannot accept data, parameters, or parameter addresses above 2 gigabytes
**