I’ve been working my way through a version of COBOL in 21 days. I’ve got to the bonus days talking about debuggers.
Is there an ‘easy’ way to debug a COBOL program?
Compiling with the -g or -d flag results in multiple 'ld: warning: -undefined suppress is deprecated’ errors.
Trying to run the compiled program with gdb reports 'No debugging symbols found in ProgramA’ [as expected].
Any suggestions? Thanks.
David
PS, Thanks for cobc and gnuCOBOL. It has been interesting.
PPS, to sorry about sending this question in another thread. I thought changing the Subjetc line would create a new thread.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Welcome David ! I know very little about macOS but someone will probably help you. If you are debugging a problem , then there are other things you can do. Put display statements through out the program until you get near the statement that is causing a problem. Display fields and variables...
If you just want to learn gdb then hang around...
(oh don't worry about the other post, deleted)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mickey, Thanks for the suggestions. I've got most of the way through the book with some small changes. I've been using the display verb to insert debugging output. I need to add some accept dummy lines to be able to see the cascade of output one by one. ;-)
This approach is also complicated by the use of 'Full-screen I/O' Simple Display doesn't seem to be as useful. I need to re-read that chapter some more.
Thanks, David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2025-05-01
Oh, did not know using full screen.
Do you do a command line to execute ? If so maybe? you can point the display to a file.
pgm.exe 1>sysout.file 2>syserr.file
display (defaults to sysout) display to syserr goes to the command line error file..
Maybe ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A little different with macOS (and probably UNIX).
Using ./MyProgram 1>sysout.txt 2>syserr.txt
I created both files but no display of the menu on the screen
sysout.txt contained the screen display
syserr.txt was empty but may not have caused an error. The program didn't hang as before ;-) ./MyProgram 2>syserr.txt
gave the menu display on the screen but again an empty syserr.txt file. Again, I may not be generating an erro/crash. Might need to try a divide by zero :-)
Thanks, David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using this debugging technique you'd want to use ACCEPT/DISPLAY "as normal" and use DISPLAY "my debugging output" UPON SYSERR, then redirect syserr only.
To ensure that you only do this for debugging purposes use the debugging indicator and potentially an environment variable, see https://gnucobol.sourceforge.io/faq/index.html#some-debugging-tricks (just ignoring the "normal" display and add UPON SYSERR for debugging output).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the Mac it might differ slightly but more than likely will be the same and you will have to create this file and content using a TEXT editor
Having done so now do and assuming you have set up sudo :
sudo ldconfig
This will clear the LD error as the Cobol executables cannot find the extra libraries needed for the runtime systems.
Now for standard debugging which will provide a code trace and a dump if needed, include in the program compiles :
cobc -x progname.cbl -d -g -ftraceall -fdump=ALL (may use -m/drop -x as needed)
Now set for environment using your .bashrc file that sits in your user home folder the following
# .bashrc# User specific aliases and functions# Source global definitionsif[-f/etc/bashrc];then./etc/bashrc
fiexportCOB_SCREEN_ESC=YES
exportCOB_SCREEN_EXCEPTIONS=YES
exportCOB_LIBRARY_PATH=~/bin
# next if neededexportCOB_EXIT_WAIT=on
exportTMPDIR=~/tmp
exportDB_HOME=.
# last one for any ISAM filesexportCOB_SET_TRACE=1exportCOB_TRACE_FILE=${HOME}/trace.log
#next if needed or similar#export COBCPY=~/cobolsrc/ACAS/copybooks# Next as neededexportPATH=~/bin:.:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/lib64/qt5/bin:/home/vince/bin:/home/vince/.local/bin:/home/vince/mvs380/hercules/linux/64/bin
You will need to exit and then re enter the terminal program for settings to take effect.
Now when running program you will find in your home folder file trace.log containing the trace information and a data dump if your program fails with a non recoverable etc, exception.
Last edit: Simon Sobisch 2025-05-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
Thanks for the detailed explanation. I'm not sure how I installed gnuCOBOL :-(. It looks like I downloaded gnucobol-3.2 (as the tar.xz file) in Mar 2024 probably from this Source Forge site. While working through the book I had to install a database, i.e. db-berkley. At the time, last month I use homebrew as brew install gnucobol to add db-berkley and jws-jso as dependencies. Before and after the db-berkley install I had v3.2 of gnuCOBOL installed.
Today after downloading and unpacking gnucobol-3.2.tar.gz I cd to the expanded folder and used ./configure. This time I got an error at the end(?).
checking for curses mousemask function and mmask_t... yes
configure: Checks for Berkeley DB ...
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
configure: error: unable to extract Berkeley DB version information from db.h
BTW my /etc folder doesn't have any ld.* files.
Sorry, its a bit of a mess but I have been able to compile and run COBOL code with this set-up. Just curious about a debugger.
Thanks, David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So you can confirm this with 'cobc --info' , but the brew build of gnucobol is compiled with clang/llvm on mac os.. You should use lldb instead of gdb.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So you can confirm this with 'cobc --info' , but the brew build of gnucobol is compiled with clang/llvm on mac os.. You should use lldb instead of gdb.
gnuCobol debugger for macOS
👍
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure. You possibly would want to go with cobgdb for the command line option similar to what other COBOL environments provide, or SuperBOL's debugging support if you want to use that within an IDE (vscode based editors, possibly works on Theia as well).
If you want to go with the full GDB experience (especially if you already know about it or want to write own commands for the debugger / write analysis scripts / use it for automated runs) then cbl-gdb[website is currently restructured, you possibly have to scroll down and get some broken links] is the way to go. This also works well with GDB's TUI mode (always viewing all the COBOL code instead of listing as needed and "in general" with GDB frontends like the VIM or Emacs one). cbl-gdb is what I've worked on as well and rolled out to the COBOL devs for my employer (used daily for development and sometimes for the necessary debugging on the customer side of issues you cannot reproduce locally).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi David, just to follow-up: how is your COBOL route going and did you got to use one (or more) of the mentioned debugging options?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2025-06-06
Hi Simon
Thanks for the follow-up. I'd worked my way through one COBOL back and got distracted with other things. I couldn't get any of the debugging apps wokring. Seemed there were some dependencies that I wasn't able to resolve. The print debugging approach worked for me. My problem was/is with screen writing which complicaged the print/debugging. I was trying to get one of the book examples to work. I probably need to go back to some earlier chapters and/or try a smaller example. Thanks for your previous suggestions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I’ve been working my way through a version of COBOL in 21 days. I’ve got to the bonus days talking about debuggers.
Is there an ‘easy’ way to debug a COBOL program?
Compiling with the -g or -d flag results in multiple 'ld: warning: -undefined suppress is deprecated’ errors.
Trying to run the compiled program with gdb reports 'No debugging symbols found in ProgramA’ [as expected].
Any suggestions? Thanks.
David
PS, Thanks for cobc and gnuCOBOL. It has been interesting.
PPS, to sorry about sending this question in another thread. I thought changing the Subjetc line would create a new thread.
Welcome David ! I know very little about macOS but someone will probably help you. If you are debugging a problem , then there are other things you can do. Put display statements through out the program until you get near the statement that is causing a problem. Display fields and variables...
If you just want to learn gdb then hang around...
(oh don't worry about the other post, deleted)
Mickey, Thanks for the suggestions. I've got most of the way through the book with some small changes. I've been using the display verb to insert debugging output. I need to add some accept dummy lines to be able to see the cascade of output one by one. ;-)
This approach is also complicated by the use of 'Full-screen I/O' Simple Display doesn't seem to be as useful. I need to re-read that chapter some more.
Thanks, David
Oh, did not know using full screen.
Do you do a command line to execute ? If so maybe? you can point the display to a file.
pgm.exe 1>sysout.file 2>syserr.file
display (defaults to sysout) display to syserr goes to the command line error file..
Maybe ?
A little different with macOS (and probably UNIX).
Using
./MyProgram 1>sysout.txt 2>syserr.txtI created both files but no display of the menu on the screen
sysout.txt contained the screen display
syserr.txt was empty but may not have caused an error. The program didn't hang as before ;-)
./MyProgram 2>syserr.txtgave the menu display on the screen but again an empty syserr.txt file. Again, I may not be generating an erro/crash. Might need to try a divide by zero :-)
Thanks, David
Using this debugging technique you'd want to use ACCEPT/DISPLAY "as normal" and use
DISPLAY "my debugging output" UPON SYSERR, then redirect syserr only.To ensure that you only do this for debugging purposes use the debugging indicator and potentially an environment variable, see https://gnucobol.sourceforge.io/faq/index.html#some-debugging-tricks (just ignoring the "normal" display and add
UPON SYSERRfor debugging output).The LD errors relate to a build / install compiler step you have missed :
In /etc there should be the following folder and files :
In this last file should be something like -
For the Mac it might differ slightly but more than likely will be the same and you will have to create this file and content using a TEXT editor
Having done so now do and assuming you have set up sudo :
sudo ldconfigThis will clear the LD error as the Cobol executables cannot find the extra libraries needed for the runtime systems.
Now for standard debugging which will provide a code trace and a dump if needed, include in the program compiles :
cobc -x progname.cbl -d -g -ftraceall -fdump=ALL(may use-m/drop-xas needed)Now set for environment using your .bashrc file that sits in your user home folder the following
You will need to exit and then re enter the terminal program for settings to take effect.
Now when running program you will find in your home folder file trace.log containing the trace information and a data dump if your program fails with a non recoverable etc, exception.
Last edit: Simon Sobisch 2025-05-02
Hi
Thanks for the detailed explanation. I'm not sure how I installed gnuCOBOL :-(. It looks like I downloaded gnucobol-3.2 (as the tar.xz file) in Mar 2024 probably from this Source Forge site. While working through the book I had to install a database, i.e. db-berkley. At the time, last month I use homebrew as brew install gnucobol to add db-berkley and jws-jso as dependencies. Before and after the db-berkley install I had v3.2 of gnuCOBOL installed.
Today after downloading and unpacking gnucobol-3.2.tar.gz I cd to the expanded folder and used ./configure. This time I got an error at the end(?).
BTW my /etc folder doesn't have any ld.* files.
Sorry, its a bit of a mess but I have been able to compile and run COBOL code with this set-up. Just curious about a debugger.
Thanks, David
So you can confirm this with 'cobc --info' , but the brew build of gnucobol is compiled with clang/llvm on mac os.. You should use lldb instead of gdb.
I’m not sure what it is doing but lldb seems to ‘work’ on my Mac M1. I only tried it with hello.cob.;-)
Benjamin, Thanks. David
Sure. You possibly would want to go with cobgdb for the command line option similar to what other COBOL environments provide, or SuperBOL's debugging support if you want to use that within an IDE (vscode based editors, possibly works on Theia as well).
If you want to go with the full GDB experience (especially if you already know about it or want to write own commands for the debugger / write analysis scripts / use it for automated runs) then cbl-gdb [website is currently restructured, you possibly have to scroll down and get some broken links] is the way to go. This also works well with GDB's TUI mode (always viewing all the COBOL code instead of
listing as needed and "in general" with GDB frontends like the VIM or Emacs one). cbl-gdb is what I've worked on as well and rolled out to the COBOL devs for my employer (used daily for development and sometimes for the necessary debugging on the customer side of issues you cannot reproduce locally).Hi David, just to follow-up: how is your COBOL route going and did you got to use one (or more) of the mentioned debugging options?
Hi Simon
Thanks for the follow-up. I'd worked my way through one COBOL back and got distracted with other things. I couldn't get any of the debugging apps wokring. Seemed there were some dependencies that I wasn't able to resolve. The print debugging approach worked for me. My problem was/is with screen writing which complicaged the print/debugging. I was trying to get one of the book examples to work. I probably need to go back to some earlier chapters and/or try a smaller example. Thanks for your previous suggestions.