Activity for Arnold Trembley
-
Arnold Trembley posted a comment on discussion GnuCOBOL
Eugenio, Back in 2017, I built a download for "Eliza", a game translated from BASIC. It was compiled with GnuCOBOL 2.2. You can still download it from here: https://www.arnoldtrembley.com/Eliza-setup-rename-7z-to-exe.7z If you rename the file extension to .exe and run it as a setup file, and install it into a folder named C:\eliza, you can then open a CMD window in that folder, type "eliza" and play with it. The folder contents look like this: Directory of C:\eliza 2026-01-12 07:54 PM <DIR> . 2026-01-12...
-
I know the OpenCobolIde for Windows uses GnuCOBOL 2.x with PDCurses, and my GC 3.2 build uses PCCursesMod (wincon rather than wingui). You WILL get different results in PDCurses using wingui versus wincon. I believe the SuperBOL GnuCOBOL uses NCurses, so I would not be surprised if there were some differences between GC with PDCurses and GC with NCurses.
-
To be clear, I never checked the generated C code, because I am not well versed in C. I don't believe I can determine if there is a defect in the generation of the intermediate C code. But I believe that the COBOL results are correct in all cases, using either c_main.cob or the similar bug1165v01.cbl (with extra display statements).
-
Thank you very much for the additional information. I think you may have a minor error in your sample program. The following statement: DISPLAY 1 " -> " SYAWDR-SIGMA-TXT (1) Should be replaced by one of these examples: DISPLAY 1 " -> " AUSGABE (or) DISPLAY 1 " -> " D312-SORT-TAB (or) DISPLAY 1 " -> " D312-SIGMA-KOPF (1) I do not have a very current version of GnuCOBOL 3.3 DEV. Mine comes from Chuck Haatvedt and has the following version: Microsoft Windows [Version 10.0.26200.7309] 2025-12-08 16:57:01...
-
Thank you very much for the additional information. I think you may have a minor error in your sample program. The following statement: DISPLAY 1 " -> " SYAWDR-SIGMA-TXT (1) Should be replaced by one of these examples: DISPLAY 1 " -> " AUSGABE (or) DISPLAY 1 " -> " D312-SORT-TAB (or) DISPLAY 1 " -> " D312-SIGMA-KOPF (1) I do not have a very current version of GnuCOBOL 3.3 DEV. Mine comes from Chuck Haatvedt and has the following version: Microsoft Windows [Version 10.0.26200.7309] 2025-12-08 16:57:01...
-
I don't understand this bug description. Could you please provide the complete data definitions with PICTURE clauses for SYAWDR-SIGMA-TXT, KLAMMER-AUF, and D312-SIGMA-KOPF, along with the initial contents or VALUE of KLAMMER-AUF? Then could you also please provide what results you actually received in D312-SIGMA-KOPF, versus what you expected to find in D312-SIGMA-KOPF? Kind regards,
-
I found this by accident, and thought it was interesting: James Lowden - The Once and Future COBOL https://www.youtube.com/watch?v=RM7Q7u0pZyQ
-
Do you still need to disable all optimizations with -O0? I finally found "freestanding" in the file generated by running "cobc -vvh > cobc-help.txt", and the definition only says "Do not assume that standard C libraries and "main" exist.' I don't see why that would affect the generation of COBOL working-storage section. I think that it should be a requirement for a compiler to include a diagnostic string in every program that specifies the exact name, version, build date & time of the compiler. I...
-
When you say "you may need to adjust the command line "in special cases", does that mean the command line for invoking the COBC compiler, or the command line for invoking the generated COBOL program? Personally, I am not hugely concerned with Microfocus COBOL compatibility (never having user MF), and my understanding was that Microfocus tried to have good compatibility with IBM Mainframe COBOL (which was perfectly okay with me). I'm not sure what you mean by "wrapper binaries" for translating environment...
-
Here's another resource: https://currencycalculate.com/list-of-currency-symbols/ Note that some currencies DO NOT have any single-character currency code or symbol. Given that a "character" in COBOL is pretty much limited to an 8-bit byte, it is never going to be possible to support a large number of special currency symbols in a single national code-set (ASCII or EBCDIC). The only reason that webpage can display so many currency code symbols is because it is encoded in UTF-8 (UniCode Translation...
-
There is another option to use ISO 4217 currency codes which are either three letters or three digits. You can use either the alphabetic or the numeric currency code. https://en.wikipedia.org/wiki/ISO_4217 https://www.iban.com/currency-codes For example: USD/840 is United States Dollars EUR/978 is Eurozone Euros (multiple countries) GBP/826 is United Kingdom Pounds Sterling CHF/756 is Swiss Francs (Confederation Helvetique) JPY/392 is Japanese Yen CNY/156 is Chinese RenMinBi (China New Yuan) This...
-
There is another option to use ISO 4217 currency codes which are either three letters or three digits. You can use either the alphabetic or the numeric currency code. https://en.wikipedia.org/wiki/ISO_4217 https://www.iban.com/currency-codes For example: USD/840 is United States Dollars EUR/978 is Eurozone Euros (multiple countries) GBP/826 is United Kingdom Pounds Stirling CHF/756 is Swiss Francs (Confederation Helvetique) JPY/392 is Japanese Yen CNY/156 is Chinese RenMinBi (China New Yuan) This...
-
There is another option to use ISO 4217 currency codes which are either three letters or three digits. You can use either the alphabetic or the numeric currency code. https://en.wikipedia.org/wiki/ISO_4217 For example: USD/840 is United States Dollars EUR/978 is Eurozone Euros (multiple countries) GBP/826 is United Kingdom Pounds Stirling CHF/756 is Swiss Francs (Confederation Helvetique) JPY/392 is Japanese Yen CNY/156 is Chinese RenMinBi (Yuan) This standard might be very helpful for any accounting...
-
Are you building VBISAM for MSYS2/MinGW64? If so, I would recommend this package: https://www.arnoldtrembley.com/vbisam-2.1.1.7z If you are building VBISAM for MinGW (32-bit), then I would recommend: https://www.arnoldtrembley.com/vbisam_install_guide_v5.1.zip Because it's the easiest to build for MinGW32. I don't have any binaries for GC 3.3, because it is still in development and we don't have a release candidate yet. Chuck Haatvedt has some GC 3.3 binaries available for download on his dropbox,...
-
Gregory, There are two versions of "MinGW", the old one (sometimes referred to as MinGW32), and the new one (sometimes referrred to as MinGW64). The old MinGW on Sourceforge is still on GCC 6.3.0. It hasn't been updated since May 30, 2017. It was moved to OSDN, but that website appears to be dead or non-responsive. It was last updated a few years ago to GCC 9.2.0 but I have been unable to download it for new machines. MinGW64 is actively maintained and supports both 32-bit and 64-bit Windows. It...
-
I also received the email and was able to detach the files. Thanks very much!
-
I tend to see this problem when using Word Processors. Looking at the code page for ISO Latin-1: https://www.charset.org/charsets/iso-8859-1 It appears that the single quote/apostrophe might be X'27', but the left single quote for word processors is x'60' and the closing right single quote is x'B4'. The compiler is probably expecting either x'27' for a single quote or x'22' for a double-quote. So the solution would be to somehow force the quote or apostrophe character expected by the compiler into...
-
Shouldn't the PERFORM statement also be corrected to include the THRU EXIT clause? I would think it needs to look something like: PERFORM 0000-READ-INPUT-FILE THRU 0000-EXIT UNTIL INPUT-FILE-EOF-SW EQUAL 'Y'.
-
I have created a bug report for this: https://sourceforge.net/p/gnucobol/bugs/1119/
-
Tables not correctly initialized by "VALUES ARE"
-
When looking at the TESTVALUE7.cbl program and the test results (created using MinGW GnuCOBOL 3.2 on Windows 11), it appears that the correct results occur when using PIC 9(2) as an elementary field, and the incorrect results appear when using PIC 99 as part of GROUP item being displayed.
-
Tables not correctly initialized by "VALUES ARE"
-
I am surprised. In the past (before retirement), the ONLY place I ever saw or used "VALUES ARE" was in 88 level condition-names. I never imaged this alternate use was allowed or even possible. The test program does suggest a bug in GnuCOBOL, but in some cases it works amazingly well. I compiled with a MinGW 32-bit GnuCOBOL 3.2 compiler. Microsoft Windows [Version 10.0.26100.4202] 2025-06-02 0:36:07 C:\cobol>testvalue7 Simple OCCURS with multi VALUES 01: jan has 031 days 02: feb has 028 days 03: mar...
-
I guess a "figurative constant" doesn't have a specific size, except in certain contexts. If it's any help at all (and it probably isn't), the program compiles and executes correctly with the following changes: ID DIVISION. PROGRAM-ID. TESTSET3. DATA DIVISION. WORKING-STORAGE SECTION. 01 wSIZE1 PIC 99. 01 my-hexff PIC x(01) VALUE X'FF'. PROCEDURE DIVISION. MAINLINE. * SET wSIZE1 TO SIZE OF HIGH-VALUES. SET wSIZE1 TO SIZE OF MY-HEXFF. DISPLAY wSIZE1. STOP RUN.
-
It looks like IBM COBOL for z/OS does not have any ON EXCEPTION/NOT ON EXCEPTION clauses for either ACCEPT or DISPLAY statements. So in that environment, there's not much need for END-ACCEPT or END-DISPLAY. Screen-handling is not something typically done by COBOL in the z/OS environment, for historical reasons.
-
This still looks like a bug to me. The most current IBM Enterprise COBOL V6.4.0 manual doesn't even show an "END-DISPLAY" reserved word as an option for the syntax of a DISPLAY statement. https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=statements-display-statement As far as I have ever understood, the only reason for using explicit scope terminators was to terminate a conditional statement when you could not use a period/full-stop to terminate a a statement inside a higher-level conditional statement....
-
I looked at the original dropbox link, but all the downloads are marked as last updated six days ago. Are the links correct?
-
Some of them can probably be found in one of these two locations: https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/samples/ https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/
-
Chuck Haatvedt has a possible code fix, but he and Simon are still debating the side effects. It turns out that some COBOL compilers handle division by zero very differently: https://www.microfocus.com/documentation/extend-acucobol/925/BKTRTRHPCBS083.html https://www.microfocus.com/documentation/extend-acucobol/925/BKUSUSCONFS009.html https://www.microfocus.com/documentation/visual-cobol/vc70/EclWin/HRCDRHCDIR1U.html
-
IBM seems to think that S0CB (division by zero) is a JCL error, rather than a COBOL error. https://ibmmainframes.com/references/a29.html There are a lot of other ABEND codes beginning with S0 in that list, You will have to scroll a long way to find S0CB.
-
IBM seems to think that S0CB is a JCL error, rather than a COBOL error. https://ibmmainframes.com/references/a29.html There are a lot of other ABEND codes beginning with S0 in that list, You will have to scroll a long way to find S0CB.
-
I agree that division by zero should result in program termination, especially for a batch COBOL program. But we should also consider what effect we want the ON SIZE ERROR/NOT ON SIZE ERROR clause to have. My recollection is that ON SIZE ERROR would prevent the MVS default ABEND for S0C7 data exception (invalid packed-decimal data, similar to NAN for some floating-point libraries ) or S0CB (division by zero exception), but would have not prevent an S0C4 ABEND (memory protection exception). In my...
-
I see now. The display is piecemeal, rather than line-oriented. But the thought occurs to me that if you COMPUTE the sum of zero minus one, and then store it in an unsigned binary short (presumably a 16 bit integer), the result should be one, since no negative numbers are allowed. Therefore SUBTRACT must take a different path.
-
When I compile that program, only the final display appears. Is there some magic required to display at row/column locations? This is the only result I get: DEFINE WS-NO AS USAGE BINARY-SHORT UNSIGNED. THEN SUBTRACT 1 FROM IT. 0000000100000000 00,001 COMPUTE WS-NO = 0 - 1 1111111111111111 65,535 SUBTRACT 1 FROM WS-NO WHEN WS-NO = ZERO 1111111011111111 65,534 SUBTRACT 1 FROM WS-NO AGAIN Press <enter> to END/QUIT. I expected to get four sets of displays like the above.
-
I would have to learn how to build a .MSI file, but I believe there are free software tools that can do this. It's been a long time since I last used Inno Setup, but creating a setup.exe file using inno was not too difficult. The 7-Zip self-extracting archive works, but its only install option is to specify the path where you want to install. It has no option to accept a license or view a readme file, or install registry entries, etc.
-
I tried a couple of experiments. If I rename the 01 AAA to be 01 BBB, then I can display either of them. But if I use EXHIBIT instead of DISPLAY, then I get a somewhat unexpected result: IDENTIFICATION DIVISION. PROGRAM-ID. TEST78LEV. DATA DIVISION. WORKING-STORAGE SECTION. 01 BBB PIC 999 VALUE 200. 78 AAA VALUE 100. PROCEDURE DIVISION. MAIN. EXHIBIT AAA EXHIBIT BBB STOP RUN. cobc.exe -x -Wall -fnotrunc -Xref -t C:\Users\Arnold\AppData\Local\Temp\test78-b.lst -o C:\Users\Arnold\AppData\Local\Temp\test78-b.exe...
-
It's possible that it is correct. In order for the rules for Qualification to work, COBOL must allow duplicate data names. I ran into a similar problem on IBM Mainframe COBOL many years ago: Here's a simplified example of the problem: ~~~ IDENTIFICATION DIVISION. PROGRAM-ID. HELLO6. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 01 100-PROGRAM-FLAGS. 05 100-CUST-ACCT-EOF-SW PIC X(01) VALUE 'N'. 88 88-100-CUST-ACCT-NOT-EOF VALUE 'N'. 88 88-100-CUST-ACCT-EOF VALUE 'Y'. 05 100-CUST-ACCT-EOF-SW...
-
I would think so. There are other Sourceforge projects that host .exe setup files for Windows. Winmerge is one example. https://sourceforge.net/projects/winmerge/files/latest/download
-
Thank you very much for your note. You do not need to install either MinGW or MSYS2 to install and use GnuCOBOL on Windows. Those tools are used to build GnuCOBOL, but are not needed to run the GnuCOBOL compiler or your compiled COBOL programs. Here are the most common download binaries that you might want to use on Windows 11: https://www.arnoldtrembley.com/GC32-BDB-SP1-rename-7z-to-exe.7z https://www.arnoldtrembley.com/GC32M-BDB-x64.7z Simply download one of these compilers and save to your hard...
-
It would also be useful if the mentioned GnuCOBOL binaries could be hosted on Sourceforge, similar to the out-of-date https://gnucobol.sourceforge.io/files/GC20rc1.zip I don't believe a casual visitor to GnuCOBOL on sourceforge would be able to find that link very easily. Kind regards,
-
SPFSE 365 is very good. I have and use it, and the binary is a free download. Unfortunately, the password for the source code died with the author, so it is not possible to update SPFSE 365. It works fine on Windows 10 and 11. SPFLite is another free text editor for Windows that emulates IBM ISPF. https://spflite.com/ https://spflite.freeforums.net/ https://spflite.com/Downloads.html Both SPFSE 365 and SPFLite have their own macro languages for user customization.
-
Did you read STARTHERE.txt from the installation? It has a lot of helpful tips. Also, you will need to run set_env.cmd to set GnuCOBOL environment variables. And it is a very good idea to keep your COBOL source code and compiled programs in a separate folder from the compiler itself.
-
Is it possible you overflowed column 72 in fixed format?
-
I missed my sign-in. The "usagelen.COB" program will show the lengths of various data types.
-
The name of the function is TEST-DAY-YYYYDDD and it works fine, but in the manual it is incorrectly spelled as TEST-DATE-YYYYDDD in the syntax example only. In the chapter title and header the function name is correctly spelled as TEST-DAY-YYYYDDD There is a separate function named TEST-DATE-YYYYMMDD which works fine and the manual appears to be correct where it is described. This is not an urgent problem, but if you're making a lot of changes to the manuals, it should be easy to include. Kind r...
-
There's another typo in the programmer's guide related to TEST-DAY-YYYYDDD: 8.1.95 TEST-DAY-YYYYDDD TEST-DAY-YYYYDDD Function Syntax TEST-DATE-YYYYDDD(date) << error, only TEST-DAY-YYYYDDD works... ~~~~~~~~~~~~~~~~~ ———————————————————————————————————————— This function determines if the supplied date (a numeric integer data item or literal) is a valid date. A valid date is one of the form yyyyddd in the range 1601001 to 9999365. Leap year is accounted for in determining the maximum number of days...
-
Relative files in GnuCOBOL are native to the local machine. They DO NOT require either BDB or VBISAM. I built a program to create and test a relative file, and compiled it with a Windows MinGW version of GnuCOBOL 3.2 that did not have ANY ISAM handler (neither BDB nor VBISAM) and it worked correctly. The source code is attached.
-
IBM manuals do allow "E" in the PIC clause: https://www.ibm.com/docs/en/cobol-zos/6.3?topic=clause-symbols-used-in-picture https://www.ibm.com/docs/en/cobol-zos/6.3?topic=clause-data-categories-picture-rules
-
You should try checking the GnuCOBOL Programmer's Guide and also the Programmer's Reference. https://sourceforge.net/p/gnucobol/code/HEAD/tree/external-doc/guide/PDFs/ (Look for gnucobpg and gnucobpr, and you can choose PDF's either in A4 or USA letter size.) E for exponent can only be used in numeric literals, such as in a VALUE clause or COMPUTE statement. I don't believe it is a valid character within a numeric-edited PICTURE clause. I have personally never used floating-point numbers in a COBOL...
-
Is a test case needed for: 01 P3 PIC $+9 . Or is that already handled correctly?
-
In Windows, you can use CTRL+ALT+E to create a Euro symbol, but if there is no 8-bit glyph for it in your CMD.EXE codepage, it probably won't show up COBOL data. What codepage do you use in Windows? Mine is 437 (OEM United States). As far as I know, it does NOT include the Euro symbol, or any characters other than 8-bit Windows ASCII. https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers You actually have two separate problems, first how to use the Euro symbol in you COBOL source...
-
Implementing Unix "fork" in windows is not trivial. Some people argue it's not even a good idea, for some very technical reasons. https://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork https://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork/985525#985525 Basically, you can run "fork" in Cygwin, but it's not fully integrated into Windows. You can run fork in WSL programs, but not very well in a GUI. https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf...
-
PDCursesMod can be built to support 3 different terminal types on windows. In my opinion wincon is the most useful, and TUI-Tools should work best with wincon. But you cannot do GUI style things in wincon (cmd.exe and Windows Terminal/cmd.exe), so Chuck Haatvedt is interested in building GUI style interfaces and likes wingui. VT terminal emulation is probably more similar to traditional unix or linux environments. The three different versions exist so that GnuCOBOL users can switch their pdcurses.dll...
-
Normally Chuck builds three different versions of pdcurses.dll with the following names: pdcurses-vt.dll pdcurses-wincon.dll pdcurses-wingui.dll And the "pdcurses-wincon.dll" is copied to "pdcurses.dll". The wincon version of pdcurses.dll should work correctly in either the CMD.EXE shell or the Windows Terminal shell for cmd.exe. Wingui uses a separate graphic window. The semigraphic characters should display as expected when using wincon or wingui versions of pdcurses.dll. I'm not sure what the...
-
Normally Chuck builds three different versions of pdcurses.dll with the following names: pdcurses-vt.dll pdcurses-wincon.dll pdcurses-wingui.dll And the "pdcurses-wincon.dll" is copied to "pdcurses.dll". The wincon version of pdcurses.dll should work correctly in either the CMD.EXE shell or the Windows Terminal shell for cmd.exe. Wingui uses a separate graphic window. The semigraphic characters should display as expected when using wincon or wingui versions of pdcurses.dll. I'm not sure what the...
-
There is no COMP-N in IBM Enterprise COBOL V6.2, unless COMP-N is "short" for COMP-1 thru COMP-5. Here's an interesting link that helps explain how IBM treats USAGE COMPUTATIONAL/COMP, BINARY, COMP-4, and COMP-5: https://www.ibm.com/docs/en/cobol-zos/6.2?topic=clause-computational-items
-
WS1A has picture 9(5) usage DISPLAY, but contains non-numeric data X'0000000000'. If you compare WS1A to zero, what result would you expect? A. WS1A equals zero B. WS1A is NOT equal to zero C. Program terminates abnormally for WS1A contains invalid non-numeric data D. Something else? Apparently Microfocus COBOL chooses B and GnuCOBOL chooses A. I believe certain older IBM mainframe COBOL compilers also chose A (due to S/360 instruction set). I no longer have access to an IBM Enterprise COBOL compiler...
-
when I compile and run "lovalues.cbl", I do not see any error. Microsoft Windows [Version 10.0.22631.3447] 2024-04-23 22:13:20 C:\cobol>cobc -V cobc (GnuCOBOL) 3.2.0 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Keisuke Nishida, Roger While, Ron Norman, Simon...
-
when I compile and run "lovalues.cbl", I do not see any error. Microsoft Windows [Version 10.0.22631.3447] 2024-04-23 22:13:20 C:\cobol>cobc -V cobc (GnuCOBOL) 3.2.0 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Keisuke Nishida, Roger While, Ron Norman, Simon...
-
Well, when I compile cs03ko it has no errors. I'm using GnuCOBOL 3.2 MinGW (32-bit, not an MSYS2 build), and my compile command looks like this: cobc -x -Wall -fnotrunc -t C:\Users\Arnold\AppData\Local\Temp\cs03ko.lst -o C:\Users\Arnold\AppData\Local\Temp\cs03ko.exe cs03ko.cbl I'm using the unmodified "default.conf" file, which could make a difference. Can you find out which .conf file the OP used? So I am NOT able to replicate this bug.
-
Data definition: Vt1to50 Pic X(30) Occurs 1 to 50 Should it not be PIC X(50) OCCURS 1 TO 50 TIMES ?
-
Your cx.bat file looks like this: rem @echo off rem Create EXE cobc -x -O2 %1 %2 %3 %4 I could be wrong, but I suspect cobc assumes when using -x that you want to compile four separate programs into a single load module. What happens if you change cx.bat to look like this? rem @echo off rem Create EXE cobc -x -O2 %1 cobc -x -O2 %2 cobc -x -O2 %3 cobc -x -O2 %4 I assume you want four separate .exe files created, yes?
-
Page 222 and 223 is the A4 version of the error. For USA letter size paper, the formatting goes off the rails around page 237 or 238. But the formatting looks bad for the next 14 pages in USA letter size.
-
COBOL Ninja offers a fairly expensive on-line COBOL class, but they also have some free instructions on how to install GnuCOBOL on Windows, and install Visual Studio with the Gnu Debugger. Using GnuCOBOL on Windows https://cobol.ninja/using-gnucobol-on-windows/
-
Here is a link to the updated build kit for generating GnuCOBOL using MSYS2 on Windows. https://www.arnoldtrembley.com/MSYS2-Build-Kit-v09.7z It's about 7.5 megabytes, and includes updates and corrections to the MSYS2 Build guide, plus updates to the GnuCOBOL and GCSORT manuals. The scripts will build GnuCOBOL with the most current versions of gmplib (6.3.0), PDCursesMod (4.4.0), cJSON, and xmllib. Special thanks again to Chuck Haatvedt.
-
I was able to get Eugenio's sample program to work, but with some minor code changes. I do not understand what the "T" character between the date and time is supposed to be (tab?) but you cannot use a blank space, underscore, comma or hyphen to separate the date and time. Also, you MUST use the "T" in the third example. I have no idea why or what it stands for. Normally, If I need formatted date and time I build it by editing the results of FUNCTION CURRENT-DATE.
-
I was able to get Eugenio's sample program to work, but with some minor code changes. I do not understand what the "T" character between the date and time is supposed to be (tab?) but you cannot use a blank space, underscore, comma or hyphen to separate the date and time. Also, you MUST use the "T" in the third example. I have no idea why. If I need formattted date and time I build it by editing the results of FUNCTION CURRENT-DATE.
-
I was able to get Eugenio's sample program to work, but with some minor code changes. I do not understand what the "T" character between the date and time is supposed to be (tab?) but you cannot use a blank space, underscore, comma or hyphen to separate the date and time. Also, you MUST use the "T" in the third example. I have no idea why. If I need formattted date and time I build it by editing the results of FUNCTION CURRENT-DATE.
-
The GnuCOBOL Programmer's guide says ANY LENGTH can only be used in the LINKAGE SECTION, and that must use only one X, A, or 9 character, so it looks like PIC 9 ANY LENGTH ought to be valid. Have you tried changing the definition of L-INPUT-DATE-DT to PIC X ANY LENGTH instead of PIC 9 ANY LENGTH? I'm not sure if this is a bug in GnuCOBOL or an error in the GnuCOBOL 3.2 Programmer's guide. Back in the 1980's we did not have ANY LENGTH in our COBOL compiler. We also didn't have a C$PARAMSIZE option...
-
You should probably try it this way (assuming there are no input arguments to compile.bat): compile.bat > see-02.txt Similarly, try this: cobcrun -vV > cobcrun.txt
-
If you truly are limited to 8.3 filenames in FREEDOS, I would think that the configuration files should have ".cfg" for their file extension. ".con" might be a console file in DOS.
-
Here is a link to the updated build kit for generating GnuCOBOL using MSYS2 on Windows. https://www.arnoldtrembley.com/MSYS2-Build-Kit-v08.7z It's only 4.6 megabytes. Many thanks to Chuck Haatvedt and Simon Sobisch for doing all the hard work on this. Chuck's menus allow building GnuCOBOL for compiler testing or for Production, either as 64-bit or 32-bit compilers, and with the following ISAM options: No ISAM support BDB 18.1.40 for ISAM VBISAM 2.1.1 BDB 6.0.19 for ISAM, with the less restrictive...
-
Make sure you have the name of the script typed correctly, and that you're starting in the right folder and starting in the right MSYS2 component (MSYS2 MINGW32 or MSYS2 MINGW64). Don't start in the MSYS2 task. I tend to set the cpu_count to 1, but that will make the build run longer. Be sure to include the full command, without the slash, for example: source build-x32.sh | tee build-x32.txt or source build-x64.sh | tee build-x64.txt And if you're still having problems we can contact Chuck Haatv...
-
Writing a GnuCOBOL debugger is no trivial task. There are User Interface and system control requirements that don't exist in normal business applications programming. I wish there was something similar to Compuware Xpediter, but for GnuCOBOL (either fixed format or free format) that would also work with GnuCOBOL on Linux or MacOS as well as Windows. GDB already exists, but it is built to debug the intermediate C code. COBOLWORX tries to solve that with its owl tools. It all "sort of" works, but it...
-
You can read about both MinGW toolsets in Wikipedia: https://en.wikipedia.org/wiki/MinGW https://en.wikipedia.org/wiki/Mingw-w64 Note that "MinGW w64" toolset uses the MSYS2 shell by default, and I will refer to it as MSYS2 to distinguish it from the older 32-bit MinGW toolset. MSYS2/MinGW64 is able to create 32-bit or 64-bit GnuCOBOL compilers. MinGW is only able to create 32-bit compilers. In general, GnuCOBOL 3.2 is the same whether it is built with older MinGW or MSYS2. But a 64-bit MSYS2 GnuCOBOL...
-
I apologize for being so late in updating this, but here is a link to the updated MSYS2 build kit: https://www.arnoldtrembley.com/MSYS2-Build-Kit-v07.7z This package includes Chuck Haatvedt's MSYS2 build scripts from August, for those of you who want to build your own Windows MSYS2 GnuCOBOL 3.2 compiler. The kit includes a build guide (.pdf and .docx), bash build scripts, GnuCOBOL manuals, and some additional files for packaging with a binary compiler. Chuck's updated scripts give you options for...
-
See Section 2.2.3 "Reference Modifiers" in the GnuCOBOL 3.2 Programmer's Reference Manual.
-
Testing with GC 3.2, in case it's not obvious. The segfault occurs in the sample program as provided, BUT if you remove the "IS INITIAL" option from the "prog2" PROGRAM-ID, then there is NO segfault. That may affect the scope of the defect or its fix. I don't see any advantage for using "IS INITIAL" on a statically bound subprogram, but it should only initialize its storage, never the caller's storage.
-
Here's a link to a late page in that thread: https://sourceforge.net/p/gnucobol/discussion/cobol/thread/a37c539dc5/?limit=25&page=4#d652
-
Here are direct download links for that binary version of the compiler (built by Chuck Haatvedt), and also a 32-bit version: https://www.arnoldtrembley.com/GC32M-BDB-x64.7z https://www.arnoldtrembley.com/GC32M-BDB-x32.7z These downloads are each about 96 megabytes. They both have the debugger support. If you don't already have 7-Zip for expanding them, that is also open-source software available from: https://7-zip.org/
-
I don't understand what you are trying to do. Normally, if you have data in a file, you would READ that record from the file. ACCEPT is used to get data typed by a human being into a COBOL elementary data item, on into a SCREEN section field (or fields). So if your input data is already in a data file, you would write a batch program to READ the file, convert each record (including changing numeric formats as needed), and WRITE each converted record to a new file. Conversion from one numeric representation...
-
It's also not possible to change the screen size (number of rows and columns) from the COBOL program using PDCursesMod and WinGui, nor to change the FONT. Chuck Haatvedt has done some of that but it requires calling a C program. If you use CMD.EXE instead of Windows Terminal, it's still possible to change font, font size, colors, number of rows & columns, using the menu you get by right clicking the icon in the upper lefthand corner. Changing "properties" is for the current session only, changing...
-
Here is an additional MinGW build of GnuCOBOL 3.2 using Berkeley DataBase 6.0.19, which was the last version that used the Sleepycat license. This is a much less restrictive license that should make it easier to distribute programs compiled with GnuCOBOL. GnuCOBOL 3.2 with BDB 6.0.19 (31May2013) passes all the same tests as GnuCOBOL 3.2 with the most current BDB 18.1.40. https://www.arnoldtrembley.com/GC32-BSL-rename-7z-to-exe.7z
-
The website has been updated with the new links. These are the basically the same MinGW 32-bit GnuCOBOL 3.2 Final Release binaries for Windows, but the PDF format GnuCOBOL manuals have been updated recently. https://www.arnoldtrembley.com/GC32-BDB-SP1-rename-7z-to-exe.7z https://www.arnoldtrembley.com/GC32-VBI-SP1-rename-7z-to-exe.7z https://www.arnoldtrembley.com/GC32-NODB-SP1-rename-7z-to-exe.7z Lots of older binaries are still available at: https://www.arnoldtrembley.com/GnuCOBOL.htm GnuCOBOL...
-
GnuCOBOL for Windows is now available using the Chocolatey package manager: https://community.chocolatey.org/packages/gnucobol
-
I don't really know much about Macs, but here are some links that might help: https://ports.macports.org/port/gnucobol/ https://riptutorial.com/cobol/example/19408/install-gnu-cobol-on-mac-os-x https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary
-
I have copied Chuck Haatvedt's MSYS2 GnuCOBOL 3.2 binaries for Windows, and added The GnuCOBOL manuals to the downloads, along with some minor helper files. These are plain 7-Zip archives. You will need the free 7-Zip software to decompress these archives while preserving the folder heirarchy. https://www.arnoldtrembley.com/GC32M-BDB-x64.7z 95.4 mb https://www.arnoldtrembley.com/GC32M-BDB-x32.7z 96.1 mb
-
On any Windows PC, you can simply delete the folder containing the MinGW GnuCOBOL compiler. But if you ever made permanent changes to your PATH or to default environment variables, then you need to use the following screen to remove those changes: (system properties / advanced / environment variables). It's safer than using RegEdit.exe.
-
On any Windows PC, you can simply delete the folder containing the MinGW GnuCOBOL compiler. But if you ever made permanent changes to your PATH or to default environment variables, then you need to use the following screen to remove those changes: (system properties / advanced / environment variables)
-
The website has been updated, and these links still work for MinGW GnuCOBOL 3.2 final release binaries: https://www.arnoldtrembley.com/GC32-BDB-rename-7z-to-exe.7z https://www.arnoldtrembley.com/GC32-VBI-rename-7z-to-exe.7z https://www.arnoldtrembley.com/GC32-NODB-rename-7z-to-exe.7z These are MinGW 32-bit binaries for GnuCOBOL 3.2. Here are some additional links: Lots of older binaries available: https://www.arnoldtrembley.com/GnuCOBOL.htm GnuCOBOL 3.2 Build Guide for MinGW 32-bit (in PDF or LibreOffice...
-
I don't have the website updated yet, but these direct links will work: https://www.arnoldtrembley.com/GC32-BDB-rename-7z-to-exe.7z https://www.arnoldtrembley.com/GC32-VBI-rename-7z-to-exe.7z https://www.arnoldtrembley.com/GC32-NODB-rename-7z-to-exe.7z These are MinGW 32-bit binaries for GnuCOBOL 3.2.
-
Yes, GnuCOBOL 3.2 Final has been released: https://sourceforge.net/projects/gnucobol/files/gnucobol/3.2/ That is the SOURCE code for the GnuCOBOL compiler itself (not including gmplib, pdcurses, BDB, VBISAM, GCSORT, etc.). It's the code you need if you are building the GnuCOBOL compiler from source. It is not the executable binary.
-
Yes, GnuCOBOL 3.2 Final has been released: https://sourceforge.net/projects/gnucobol/files/gnucobol/3.2/ That is the SOURCE code for the GnuCOBOL compiler itself (not including gmplib, pdcurses, BDB, VBISAM, GCSORT, etc.). It's the code you need if you are building the GnuCOBOL compiler from source.
-
Yes, GnuCOBOL 3.2 Final has been released: https://sourceforge.net/projects/gnucobol/files/gnucobol/3.2/
-
A new binary is available for GnuCOBOL 3.2 (24Jul2023, commit r5142) for Windows 7, 8, 10, 11: https://www.arnoldtrembley.com/GC32-BDB-r5142-rename-7z-to-exe.7z It's still possible that changes could be made before the FINAL release of GnuCOBOL 3.2. This build is for Windows users who want to try out a pre-Final release of GnuCOBOL 3.2 that is newer than Release Candidate 2 published last February. Simply download the .7z file, rename the file extension to .exe, and run the self-extracting archive....
-
You might try creating your own CLASS tests in COBOL, using SPECIAL-NAMES like this: SPECIAL-NAMES. CLASS EBCDIC-LETTERS IS X'81' THRU X'89, X'91 THRU X'99', X'A2' THRU X'A9', X'C1' THRU X'C9, X'D1 THRU X'D9', X'E2' THRU XE9, X'40' CLASS EBCDIC-DIGITS IS X'F0' THRU X'F9', X'C0' THRU X'D9', X'E0' THRU X'E9' CLASS EBCDIC-PUNCTUATION IS ...etc. Creating the rest of the class names is an exercise left to the reader. EBCDIC punctuation will be non-contiguous ranges. The ASCII class names will probably...
-
I question whether this is really a BUG, or an implementation issue. In most IBM COBOL environments that I'm aware of, the program name is NOT case-sensitive, and this is related to MVS JCL requiring uppercase only. But Unix/Linux environments are indeed case-sensitive, so this diagnostic seems to make sense for GnuCOBOL. Interestingly enough, Windows does not have anything as archaic as OS/360 JCL (even though the bat/cmd scripting language is pretty old now) it seems that Windows is not very case-sensitive....
-
Yes, I will want to add these notes to the README. Thanks very much!!
-
This also fails in GnuCOBOL 3.1.2, either MinGW 32-bit or MSYS2 64-bit. It fails the same way in GC 3.2 rc2, either MinGW 32-bit or MSYS2 64-bit So it probably needs to be fixed in GnuCOBOL 3.2, unless it's extremely difficult to make the change. Here is a revised version of the sample program, and another sample program, that can be used to demonstrate the problem:
1 >
