I am trying to build GnuCOBOL for mingw64, versions 3.1.2 and 3.2. I want to use vbisam; however, I have had no success. I have spent the last three days looking thru the forum for help. I have downloaded a number versions of vbisam.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps you could explain what the actual difficulties have been for you - error messages etc:
and I'm sure someone will have already been thru a similar situation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I forgot to login before posting a question last night. My goal was to build the compiler to match Linux and Windows. I have tried to use Visual Studio to no avail. Simon convinced me to try mingw, which I did. I have also used Arnold Trembley links in the past. A very useful website.
I wanted to create a 64bit version for Windows 10. So I followed the document that Arnold published on his website. However, it uses BDB and I want to use VBISAM. I was able to get a copy of vbisam to compile using Visual Studio; however, how do I then build the GnuCOBOL compiler? The main issue is compiling vbisam and then GnuCOBOL.
After I get this task working, I want to then move onto MySQL database programming using GnuCOBOL. I will most likely need help with that.
David, I have downloaded a version of 3.2. Is the build the same as previous versions?
Thanks for responding...
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The build guide for Mingw 3.1.2 has both BDB & VBI instructions - I believe however that the Mingw64 guide only uses a file created by Simon S which only contains BDB.
I build the Mingw version 3.1.2, 3.2 & 4.0x quite happily under Windows 10 64bit and I believe they are all 32 bit so what advantage having a 64bit version is - I don't know.
IF you want to try one of those let me know - send an email to my SF address & I can send you one of those via dropbox.
I don't run linux so I don't know if a build run under Win10 would work there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"...so what advantage having a 64 bit version is - I don't know."
Neither do I - perhaps someone has a COBOL application that exceeds 2,147,483,648 bytes of address space. To put it in perspective that is a COBOL program requiring more than 2 billion bytes of address space.
I can't imagine the paging demand if such an application were run on zOS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not know either. My understanding was since I was using a 64 bit Windows OS, I should have a compiler that is 64 bits. I have been a COBOL programmer all my life. I understand enough C to get in trouble. Basically, to do minor things.
When it comes to hardware architecture I am lost. For the last 25 plus years, I have been as I said a COBOL programmer running on SCO OpenServer 5. Before that, using COBOL on various VAX systems.
So I ask you all, does it really mater 32 or 64 bits?
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 32 bit GnuCOBOL works great on a 64 bit Windows deployment.
Unless your are building HUGE applications 32 bit GnuCOBOL for Windows should be your choice.
I would download the 32 bit version from www.arnoldtrembley.com
I think this is the download site for the above (with VBISAM) https://www.arnoldtrembley.com/GC312-VBI-rename-7z-to-exe.7z
Why is it you need the unreleased 3.2 version ?
3.1.x seems very worth of application development - sans callfh and extfh support.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course the older MVS address spaces (regions) are limited to 2 gigabytes of memory due to the use of 31-bit addresses, even on 64-bit System Z processors with over 4 gigabytes of main memory. Prior to that, MVS used a 24-bit address limiting you to a 16 megabyte address space.
Windows 10 still comes in 32-bit or 64-bit versions (the maximum address size), but most Windows systems since Vista/Win7 are 64-bit systems. Windows 11 only comes in 64-bit versions.
IBM DB2 for Windows is a 64-bit product, and probably requires a 64-bit compiler.
There may be some cases where a 64-bit version of GnuCOBOL would be useful, but most business applications can be implemented with a 32-bit GnuCOBOL compiler.
And 32-bit GnuCOBOL versions run well on 64-bit Windows.
Kind regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe IBM DB2 for Windows is now referred to as DB2 Community Edition.
The current version is IBM Db2 v11.5.7
Community edition is functional with GnuCOBOL 32 bit.
Community Edition must be deployed on 64 bit windows
However, as stated previously, Community Edition is functional with 32 bit GnuCOBOL.
In order for DB2 Prep to generate compliant GnuCOBOL requires the magic of the -Q GnuCOBOL compiler / linker option.
Chuck H. has the particulars. I gleaned the proper link convention with Chuck H assistance.
This is the download site for IBM Db2 v11.5.7 : https://epwt-www.mybluemix.net/software/support/trial/cst/programwebsite.wss?siteId=1120&tabId=2932&p=null&h=null
Of course the older MVS address spaces (regions) are limited to 2
gigabytes of memory due to the use of 31-bit addresses, even on 64-bit
System Z processors with over 4 gigabytes of main memory. Prior to
that, MVS used a 24-bit address limiting you to a 16 megabyte address
space.
Windows 10 still comes in 32-bit or 64-bit versions (the maximum
address size), but most Windows systems since Vista/Win7 are 64-bit
systems. Windows 11 only comes in 64-bit versions.
IBM DB2 for Windows is a 64-bit product, and probably requires a
64-bit compiler.
There may be some cases where a 64-bit version of GnuCOBOL would be
useful, but most business applications can be implemented with a
32-bit GnuCOBOL compiler.
And 32-bit GnuCOBOL versions run well on 64-bit Windows.
Kind regards,
Not out of the box as if user wishes to run 32 bit on a x64 you have to
install all the supporting packages to do so.
The extra packages to do this will increase disk usage to store them and
more CPU cycles to run any thing using them.
Therefore running only 32 bit apps can slow the system down compared to
running full 64 bit code if only regarding the scheduler but usually
every thing else. This is noticeable when running multi applications at
the same time.
Vince
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And 32-bit GnuCOBOL versions run well on 64-bit Windows.
Not out of the box as if user wishes to run 32 bit on a x64 you have to
install all the supporting packages to do so.
The extra packages to do this will increase disk usage to store them and
more CPU cycles to run any thing using them.
What 'extra' packages do I have to install - since it seems to be working fine on my Win10 64bit system ?????????.
I have a number of 32bit programs running fine - most of the commercial programs have both versions available - in fact I'm still running software produced back in 2002.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2022-02-22
researchresearchYour windoz system will install any needed packages to support 32bit operations if researchthey are not installed when first building a system.
There is an overhead for doing so as previously stated, my laptop which is a 64bit system ONLY cannot run 32bit without a load up of extra windoz libraries.
The same applies to the "*nix" platforms such as Linux.
As all my applications running on both platform use only 64bit I have no need for these extra libraries to support 32 operations.
What libraries window s loads for win10/11 I am not familiar with as I have zero interest in them so I suggest you do a bit of research on the requirement.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well I think you would find this interesting - it will add to your research. Perhaps even increase the accuracy of your "research" and resultant posts.
The 'System32' folder is for 64-bit files and the 'SysWOW64' folder is for 32-bit files (I have always thought the inverse)
This can be somewhat confusing, but the System32 folder is intended for 64-bit files and the SysWOW64 folder is intended for 32-bit files. This may seem a bit illogical if you look at the folder names, but there is an explanation to this. It has to do with compatibility. Many developers have hard coded the path to the system folder in their applications source code. They have included "System32" in the folder path. And to preserve compatibility, if the application is converted to 64-bit code, the 64-bit system folder is still named System32.
But what about 32-bit applications that have the system path hard coded and is running in a 64-bit Windows? How can they find the new SysWOW64 folder without changes in the program code, you might think. The answer is that the emulator redirects calls to System32 folder to the SysWOW64 folder transparently so even if the folder is hard coded to the System32 folder (like C:\Windows\System32), the emulator will make sure that the SysWOW64 folder is used instead. So same source code, that contains a path with the System32 folder included, can be compiled to both 32-bit and 64-bit program code without any changes.
So remember:
• the SysWOW64 folder is intended for 32-bit files only
• the System32 folder is intended for 64-bit files only
It is very important that a binary file compiled to a specific bitness (32 or 64) is installed to the correct system folder. Otherwise the program that needs the file will not be able to load the file and will probably not work as expected.
'WOW64' and 'x86', what do they mean?
SysWOW64 and Program Files (x86) are special folders that only exists on 64-bit Windows and they are intended to store 32-bit binary files. In the folder names there are the "strange" character combinations WOW64 and x86 included. These character combinations have a meaning and we will explain it below:
• WOW64 is a shortening for ”Windows on Windows 64-bit” (can be read as "Windows 32-bit on Windows 64-bit"). It's a emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows. A compatibility layer is used as an interface between the 32-bit program and the 64-bit operating system.
• x86 is the name of a processor architecture from Intel that handles 32 bit instruction sets. The x86 term have been used for a very long time and in the beginning it was used as a general term to refer to Intel 16/32 bit processors with names such 8086, 80186, 80286, 80386 etc. But since the release of the 80386 processor, the first real 32 bit processor, the term x86 have been used to refer to 32-bit processors that have an instruction set that is compatible with the old 80386 processor.
Ralph
Last edit: Ralph Linkletter 2022-02-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rich, there is a 32 bit version of GNUCOBOL which includes VBISAM on Arnolds website. It can use embedded SQL with the DB2 precompiler and it executes successfully. Be aware that multi-row operations in DB2 were not supported in the 11.5.6 version that I tested with. From Ralph's comment above, there appears to be a newer version which I've not tested.
please don't hesitate to contact me if you want to do some coding / testing with DB2 as there are a couple of issues which have not been resolved in GNUCOBOL using DYNAMIC calls to the DB2 runtime modules. Using STATIC calls, it works fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was just looking for help to build GnuCOBOL in 64 bit. I did not expect such a spirited discussion on 32 vs 64. It has been very interesting. Thanks to all who participated in this discussion.
my plan is to use Arnold Tremblay's latest version 3.12 with VBISAM, which is 32 bit. Then I am going to try getting esql working with MySQL. I have also had help in getting 3.2 and 4.0 installed on my PC. Someone had asked why, I just want to play with and see if my application will work.
I will post my work on esql.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, was able to build esqlOC (from Simon's pointer) by using VS2019. Then I copied the information in the FAQ and created the program esqlOCGetStart1.SQB. I compilied the program and ran it. However, I got the following error.
264010296 OCSQL: DB connecting using SQLDriverConnect
264010312 OCSQL: SQL code 0 : IM002 : [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
SQLSTATE=IM002, SQLCODE=-0000009999
SQL Error message:[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
*-----------------------------------------------------------------
STRING 'DRIVER={MySQL ODBC 8.0 Driver};'
'SERVER=localhost;'
'PORT=4554;'
'DATABASE=test;'
'USER=rdiiulio;'
'PASSWORD=password#;'
* example for DB specific ODBC parameter:
* no compressed MySQL connection (would be the DEFAULT anyway)
'COMRESSED_PROTO=0;'
INTO BUFFER.
As I said earlier, I am using MySQL.
Rich Di Iulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All!
I am trying to build GnuCOBOL for mingw64, versions 3.1.2 and 3.2. I want to use vbisam; however, I have had no success. I have spent the last three days looking thru the forum for help. I have downloaded a number versions of vbisam.
Rich Di Iulio
I was never able to do it either. I'm a COBOL programmer, not a Linux guru so most of the error messages were incomprehensible to me.
3.2 hasn't been released yet but you can download a version of 3.1.2 with vbisam from the following: https://www.arnoldtrembley.com/GC312-VBI-rename-7z-to-exe.7z
Perhaps you could explain what the actual difficulties have been for you - error messages etc:
and I'm sure someone will have already been thru a similar situation.
Hi Again,
I forgot to login before posting a question last night. My goal was to build the compiler to match Linux and Windows. I have tried to use Visual Studio to no avail. Simon convinced me to try mingw, which I did. I have also used Arnold Trembley links in the past. A very useful website.
I wanted to create a 64bit version for Windows 10. So I followed the document that Arnold published on his website. However, it uses BDB and I want to use VBISAM. I was able to get a copy of vbisam to compile using Visual Studio; however, how do I then build the GnuCOBOL compiler? The main issue is compiling vbisam and then GnuCOBOL.
After I get this task working, I want to then move onto MySQL database programming using GnuCOBOL. I will most likely need help with that.
David, I have downloaded a version of 3.2. Is the build the same as previous versions?
Thanks for responding...
Rich Di Iulio
The build guide for Mingw 3.1.2 has both BDB & VBI instructions - I believe however that the Mingw64 guide only uses a file created by Simon S which only contains BDB.
I build the Mingw version 3.1.2, 3.2 & 4.0x quite happily under Windows 10 64bit and I believe they are all 32 bit so what advantage having a 64bit version is - I don't know.
IF you want to try one of those let me know - send an email to my SF address & I can send you one of those via dropbox.
I don't run linux so I don't know if a build run under Win10 would work there.
"...so what advantage having a 64 bit version is - I don't know."
Neither do I - perhaps someone has a COBOL application that exceeds 2,147,483,648 bytes of address space. To put it in perspective that is a COBOL program requiring more than 2 billion bytes of address space.
I can't imagine the paging demand if such an application were run on zOS.
Ralph,
I do not know either. My understanding was since I was using a 64 bit Windows OS, I should have a compiler that is 64 bits. I have been a COBOL programmer all my life. I understand enough C to get in trouble. Basically, to do minor things.
When it comes to hardware architecture I am lost. For the last 25 plus years, I have been as I said a COBOL programmer running on SCO OpenServer 5. Before that, using COBOL on various VAX systems.
So I ask you all, does it really mater 32 or 64 bits?
Rich Di Iulio
The 32 bit GnuCOBOL works great on a 64 bit Windows deployment.
Unless your are building HUGE applications 32 bit GnuCOBOL for Windows should be your choice.
I would download the 32 bit version from www.arnoldtrembley.com
I think this is the download site for the above (with VBISAM)
https://www.arnoldtrembley.com/GC312-VBI-rename-7z-to-exe.7z
Why is it you need the unreleased 3.2 version ?
3.1.x seems very worth of application development - sans callfh and extfh support.
Ralph
According to Wikipedia, IBM z/OS is a 64-bit operating system.
https://en.wikipedia.org/wiki/Z/OS
Of course the older MVS address spaces (regions) are limited to 2 gigabytes of memory due to the use of 31-bit addresses, even on 64-bit System Z processors with over 4 gigabytes of main memory. Prior to that, MVS used a 24-bit address limiting you to a 16 megabyte address space.
Windows 10 still comes in 32-bit or 64-bit versions (the maximum address size), but most Windows systems since Vista/Win7 are 64-bit systems. Windows 11 only comes in 64-bit versions.
IBM DB2 for Windows is a 64-bit product, and probably requires a 64-bit compiler.
There may be some cases where a 64-bit version of GnuCOBOL would be useful, but most business applications can be implemented with a 32-bit GnuCOBOL compiler.
And 32-bit GnuCOBOL versions run well on 64-bit Windows.
Kind regards,
I believe IBM DB2 for Windows is now referred to as DB2 Community Edition.
The current version is IBM Db2 v11.5.7
Community edition is functional with GnuCOBOL 32 bit.
Community Edition must be deployed on 64 bit windows
However, as stated previously, Community Edition is functional with 32 bit GnuCOBOL.
In order for DB2 Prep to generate compliant GnuCOBOL requires the magic of the -Q GnuCOBOL compiler / linker option.
Chuck H. has the particulars. I gleaned the proper link convention with Chuck H assistance.
This is the download site for IBM Db2 v11.5.7 :
https://epwt-www.mybluemix.net/software/support/trial/cst/programwebsite.wss?siteId=1120&tabId=2932&p=null&h=null
However you must have an IBM account:
The sign up URL is:
https://www.ibm.com/account/reg/us-en/signup?formid=urx-33669
Ralph
On 21/02/2022 02:32, Arnold Trembley wrote:
Not out of the box as if user wishes to run 32 bit on a x64 you have to
install all the supporting packages to do so.
The extra packages to do this will increase disk usage to store them and
more CPU cycles to run any thing using them.
Therefore running only 32 bit apps can slow the system down compared to
running full 64 bit code if only regarding the scheduler but usually
every thing else. This is noticeable when running multi applications at
the same time.
Vince
Not out of the box as if user wishes to run 32 bit on a x64 you have to
install all the supporting packages to do so.
The extra packages to do this will increase disk usage to store them and
more CPU cycles to run any thing using them.
What 'extra' packages do I have to install - since it seems to be working fine on my Win10 64bit system ?????????.
I have a number of 32bit programs running fine - most of the commercial programs have both versions available - in fact I'm still running software produced back in 2002.
researchresearchYour windoz system will install any needed packages to support 32bit operations if researchthey are not installed when first building a system.
There is an overhead for doing so as previously stated, my laptop which is a 64bit system ONLY cannot run 32bit without a load up of extra windoz libraries.
The same applies to the "*nix" platforms such as Linux.
As all my applications running on both platform use only 64bit I have no need for these extra libraries to support 32 operations.
What libraries window s loads for win10/11 I am not familiar with as I have zero interest in them so I suggest you do a bit of research on the requirement.
Well I think you would find this interesting - it will add to your research. Perhaps even increase the accuracy of your "research" and resultant posts.
This is a comprehensive explanation of 32 bit windows components supported by a 64 bit Windows.
https://www.samlogic.net/articles/32-64-bit-windows-folder-x86-syswow64.htm
The 'System32' folder is for 64-bit files and the 'SysWOW64' folder is for 32-bit files (I have always thought the inverse)
This can be somewhat confusing, but the System32 folder is intended for 64-bit files and the SysWOW64 folder is intended for 32-bit files. This may seem a bit illogical if you look at the folder names, but there is an explanation to this. It has to do with compatibility. Many developers have hard coded the path to the system folder in their applications source code. They have included "System32" in the folder path. And to preserve compatibility, if the application is converted to 64-bit code, the 64-bit system folder is still named System32.
But what about 32-bit applications that have the system path hard coded and is running in a 64-bit Windows? How can they find the new SysWOW64 folder without changes in the program code, you might think. The answer is that the emulator redirects calls to System32 folder to the SysWOW64 folder transparently so even if the folder is hard coded to the System32 folder (like C:\Windows\System32), the emulator will make sure that the SysWOW64 folder is used instead. So same source code, that contains a path with the System32 folder included, can be compiled to both 32-bit and 64-bit program code without any changes.
So remember:
• the SysWOW64 folder is intended for 32-bit files only
• the System32 folder is intended for 64-bit files only
It is very important that a binary file compiled to a specific bitness (32 or 64) is installed to the correct system folder. Otherwise the program that needs the file will not be able to load the file and will probably not work as expected.
'WOW64' and 'x86', what do they mean?
SysWOW64 and Program Files (x86) are special folders that only exists on 64-bit Windows and they are intended to store 32-bit binary files. In the folder names there are the "strange" character combinations WOW64 and x86 included. These character combinations have a meaning and we will explain it below:
• WOW64 is a shortening for ”Windows on Windows 64-bit” (can be read as "Windows 32-bit on Windows 64-bit"). It's a emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows. A compatibility layer is used as an interface between the 32-bit program and the 64-bit operating system.
• x86 is the name of a processor architecture from Intel that handles 32 bit instruction sets. The x86 term have been used for a very long time and in the beginning it was used as a general term to refer to Intel 16/32 bit processors with names such 8086, 80186, 80286, 80386 etc. But since the release of the 80386 processor, the first real 32 bit processor, the term x86 have been used to refer to 32-bit processors that have an instruction set that is compatible with the old 80386 processor.
Ralph
Last edit: Ralph Linkletter 2022-02-22
David,
Thank you for your help.
Rich Di Iulio
Rich, there is a 32 bit version of GNUCOBOL which includes VBISAM on Arnolds website. It can use embedded SQL with the DB2 precompiler and it executes successfully. Be aware that multi-row operations in DB2 were not supported in the 11.5.6 version that I tested with. From Ralph's comment above, there appears to be a newer version which I've not tested.
please don't hesitate to contact me if you want to do some coding / testing with DB2 as there are a couple of issues which have not been resolved in GNUCOBOL using DYNAMIC calls to the DB2 runtime modules. Using STATIC calls, it works fine.
Okay,
I was just looking for help to build GnuCOBOL in 64 bit. I did not expect such a spirited discussion on 32 vs 64. It has been very interesting. Thanks to all who participated in this discussion.
my plan is to use Arnold Tremblay's latest version 3.12 with VBISAM, which is 32 bit. Then I am going to try getting esql working with MySQL. I have also had help in getting 3.2 and 4.0 installed on my PC. Someone had asked why, I just want to play with and see if my application will work.
I will post my work on esql.
Rich Di Iulio
Okay, was able to build esqlOC (from Simon's pointer) by using VS2019. Then I copied the information in the FAQ and created the program esqlOCGetStart1.SQB. I compilied the program and ran it. However, I got the following error.
264010296 OCSQL: DB connecting using SQLDriverConnect
264010312 OCSQL: SQL code 0 : IM002 : [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
SQLSTATE=IM002, SQLCODE=-0000009999
SQL Error message:[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
*-----------------------------------------------------------------
STRING 'DRIVER={MySQL ODBC 8.0 Driver};'
'SERVER=localhost;'
'PORT=4554;'
'DATABASE=test;'
'USER=rdiiulio;'
'PASSWORD=password#;'
* example for DB specific ODBC parameter:
* no compressed MySQL connection (would be the DEFAULT anyway)
'COMRESSED_PROTO=0;'
INTO BUFFER.
As I said earlier, I am using MySQL.
Rich Di Iulio