I was able to install a 2.0 version of GNUcobol using a simple "opencobolide.exe" file but I can't seem to figure out how to get the latest 3.2 version installed over it. There are some limitations in the 2.0 version where important COBOL functions have not been implemented (multiple alternate keys - split keys etc.). I have downloaded gnucobol-3.2_win.7z, extracted it and it creates pretty much the same directories but it does not have a cobc.exe file in it. I have seen articles about having to "make" or "configure" the compiler, but it is pretty involved and not completely clear exactly how this all will update my current version in Windows 10,or what steps I am required to do (not simple). I have also gone down a rabbit hole with a "mingw" set of instructions that was pretty involved with not much success either. Is there a simple opencobolide.exe for windows with all of components ready to go, or a simpler set of instructions to use for the installation of the gnucobol-3.2_win.7z for windows that I downloaded. Thanks for any help you can offer.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Need help installing GNUCOBOL 3.2 2
- Thread starter RichL32
- Start date
-
1
- #2
Hi RichL32,
As you already found out, the archive gnucobol-3.2_win.7z you downloaded, does not contain binaries, but only sources which you have to compile (e.g. using MinGW).
I searched in Google for binaries and found this Arnold Trembley’s website.
There are lots of packages there. I only downloaded these two archives
GC32M-BDB-x64.7z
GC32-BDB-SP1-rename-7z-to-exe.7z
and looked inside, to see that both contain the windows executable cobc.exe
Try one of them out, or both, or other package from the site above.
Unfortunatelly I couldn't try it myself now, as I'm momentary on Linux PC.
If any problems, post them here and I will look at it, as soon as I will have Windows PC by my hands.
As you already found out, the archive gnucobol-3.2_win.7z you downloaded, does not contain binaries, but only sources which you have to compile (e.g. using MinGW).
I searched in Google for binaries and found this Arnold Trembley’s website.
There are lots of packages there. I only downloaded these two archives
GC32M-BDB-x64.7z
GC32-BDB-SP1-rename-7z-to-exe.7z
and looked inside, to see that both contain the windows executable cobc.exe
Try one of them out, or both, or other package from the site above.
Unfortunatelly I couldn't try it myself now, as I'm momentary on Linux PC.
If any problems, post them here and I will look at it, as soon as I will have Windows PC by my hands.
- Thread starter
- #3
WOW! Thank you for the quick and perfect response to my issue. I installed (copied) the 64bit unzipped files over my existing files and it worked beautifully! I got rid of the "not Implemented" errors, so I can continue to work on converting my programs with the 3.2 version. Thank you so much Microm! You saved the day.
-
1
- Thread starter
- #5
- Thread starter
- #7
I'm having trouble getting the cursor-up key to be recognized in my programs. I found a sample program that helped me to get the escape key to work using ENVIRONMENT variables (COB_SCREEN_ESC etc.), and the 78 level constant COB-SCR-ESC in the screenio copybook, but the COB-SCR-KEY-UP does not work. The sample program works for cursor-up, but only if you do the accept with a direct line/col reference in the command line. Do you happen to know the secret to this problem by chance? I can recode the source for direct reference but I am hoping for a simpler solution if there is one (another environment variable?). I can send you my code if it helps. I am using the special names field of "CRT STATUS IS WS-KEY-STATUS" which is defined in WS as Pic 9(4). I could not find anything useful on the web nor any potential environment variables.
Thanks in advance.
Thanks in advance.
Hi RichL32,
Momentary I cannot help you with this, as I doesn't have many experience with GNU COBOL either on Windows or Linux. I have it installed mainly to answer question in this forum. Natively I'm developer on IBM i aka iSeries aka AS/400 (e.g. see: and have some experience of designing screens on this platform.
Despite of this your question is interesting for me and as I will have time I will look at it.
But IMO you should post this question in new thread, as it has less to do with the original topic of this thread.
Momentary I cannot help you with this, as I doesn't have many experience with GNU COBOL either on Windows or Linux. I have it installed mainly to answer question in this forum. Natively I'm developer on IBM i aka iSeries aka AS/400 (e.g. see: and have some experience of designing screens on this platform.
Despite of this your question is interesting for me and as I will have time I will look at it.
But IMO you should post this question in new thread, as it has less to do with the original topic of this thread.
- Thread starter
- #9
- Thread starter
- #10
Sorry to bother you, but my latest post is about: libcob: error: module ‘9DOWN.dll’ not found
I have looked at a very similar post about the problem, but it was finally resolved with the discovery of a typo in his environment variable setting.
I am wondering if my problem has something to do with the install of the newer version of GNUcobol?
As you know, I just copied the files over the previous install, but I had never gotten to the called program step in the prior version to know if it would have worked for a called program either. All this environment setup is very new to me and I also do not know what the MING32 and MING64 directories are for. The IDE has a ming32 directory underneath it and maybe it is supposed to be ming64? I did have an error pop up about not finding the default.conf file, which was in mingw64. I had to move the ming64 directories to my D:\ drive and it seemed to eliminate the error. I have a 64 bit machine. Is there possibly some other functions I needed to run to make 3.2 version work for called modules issue and libcob?
I have looked at a very similar post about the problem, but it was finally resolved with the discovery of a typo in his environment variable setting.
I am wondering if my problem has something to do with the install of the newer version of GNUcobol?
As you know, I just copied the files over the previous install, but I had never gotten to the called program step in the prior version to know if it would have worked for a called program either. All this environment setup is very new to me and I also do not know what the MING32 and MING64 directories are for. The IDE has a ming32 directory underneath it and maybe it is supposed to be ming64? I did have an error pop up about not finding the default.conf file, which was in mingw64. I had to move the ming64 directories to my D:\ drive and it seemed to eliminate the error. I have a 64 bit machine. Is there possibly some other functions I needed to run to make 3.2 version work for called modules issue and libcob?
As you wrote above, you downloaded the package GC32M-BDB-x64.7z from which is 64-bit, so the directory should be mingw64. On the same website the 32-bit package is available too: GC32M-BDB-x32.7zRichL32 said:
- Thread starter
- #12
OK, I have it working properly now. I went back to square 1 and deleted the 2.0 files, while retaining the OpenCobol IDE folder and then reinstalled the GNU V3.2 version under the IDE folder. I also reconfigured some of the settings in the IDE for compile and runtime preferences. Also, the format of the call program name seems to work with a 77 level variable that has the just the program name without the .dll in the variable.
77 CALL-9DOWN-NAME PIC X(12) VALUE '9DOWN'.
01 CALL-RETURN-CODE PIC 9(05) VALUE ZEROES.
01 CALL-CONTROL-ID PIC X(80) VALUE SPACES.
01 CALL-PARMS REDEFINES CALL-CONTROL-ID.
03 CALL-PROGRAM-NAME PIC X(12).
03 CALL-NBR-OF-PLAYERS PIC 9(01).
CALL CALL-9DOWN-NAME USING CALL-RETURN-CODE
CALL-CONTROL-ID.
In the call parms the name is fully defined:
MOVE '9DOWN.dll' TO CALL-PROGRAM-NAME.
Not sure if that mattered, but it works.
MAYBE THIS WILL BE HELPFULTO SOME FUTURE PROGRAMMER.
77 CALL-9DOWN-NAME PIC X(12) VALUE '9DOWN'.
01 CALL-RETURN-CODE PIC 9(05) VALUE ZEROES.
01 CALL-CONTROL-ID PIC X(80) VALUE SPACES.
01 CALL-PARMS REDEFINES CALL-CONTROL-ID.
03 CALL-PROGRAM-NAME PIC X(12).
03 CALL-NBR-OF-PLAYERS PIC 9(01).
CALL CALL-9DOWN-NAME USING CALL-RETURN-CODE
CALL-CONTROL-ID.
In the call parms the name is fully defined:
MOVE '9DOWN.dll' TO CALL-PROGRAM-NAME.
Not sure if that mattered, but it works.
MAYBE THIS WILL BE HELPFULTO SOME FUTURE PROGRAMMER.
- Status
Similar threads
- Locked
- Question
- Locked
- Question