#1256 Ctrl+C not caught by CBL_EXIT_PROC

[Ralph Linkletter]

Use of CTRL+C returns to the operating system without notification when CBL_EXIT_PROC is enabled.
I depend upon CBL_EXIT_PROC to gracefully exit ZEDIT and gracefully exit components within the WINZOS ecosystem.
Thed ramification of not being able to "catch" the CTRL+C interrupt is leaving an edit sessions in an unknown state - also WINZOS has cleanup resposibilities - as an example processing JCL DISP= the 3rd parameter.

Attached are an MP4 depicting the return to zOS from ZEDIT AND a GNUCOBOL source program enabling the CBL_EXIT_PROC (as well as CBL_ERROR_PROC).

[Ralph Linkletter]

The MP4 was not attached for some reason - here it is

[Vincent (Bryan) Coen]

It would be some what useful to specify what version of the compiler you are referring to.
Change milestone to show the correct one.

[Ralph Linkletter]

I do not have the authorization needed to update the bug report.

[Vincent (Bryan) Coen]

You should be able to make an amendment but if not specify what version !

[Ralph Linkletter]

GnuCOBOL versions 3.2 and 3.3
32 bit Windows

C:\APANEL_TEST>cobcrun --info
libcob (branches/gnucobol-3.x r5627M) 3.3-dev.5627
Copyright (C) 2024 Free Software Foundation, Inc.
License LGPLv3+: GNU LGPL version 3 or later <https://gnu.org/licenses/lgpl.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 Sobisch, Edward Hart
Built Jan 02 2026 21:24:11
Packaged Dec 06 2025 01:59:21 UTC

build information
build environment : i686-w64-mingw32
CC : gcc
C version : (MinGW) "15.2.0"
CPPFLAGS : -I/mingw32/include -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2
CFLAGS : -O0 -std=c11 -Wdeclaration-after-statement -ggdb3
-fasynchronous-unwind-tables
-fstack-protector-strong -fstack-clash-protection
-pipe -fsigned-char -Wall -Wwrite-strings
-Wmissing-prototypes -Wno-format-y2k
LD : R:/msys64/mingw32/i686-w64-mingw32/bin/ld.exe
LDFLAGS :

GnuCOBOL information
COB_MODULE_EXT : dll
dynamic loading : system
64bit-mode : no
BINARY-C-LONG : 4 bytes
endianness : little-endian
native EBCDIC : no
variable file format : 0
sequential file handler : built-in
indexed file handler : BDB, version 18.1.40
mathematical library : GMP, version 6.3.0
XML library : libxml2, version 2.15.1
JSON library : json-c, version 0.18.0
extended screen I/O : pdcurses, version 4.5.3 (CHTYPE=64[64], WIDE=0[0],
UTF8=0[0])
mouse support : unknown

[Simon Sobisch]

rechecked in gnucobol3.x:

• COB_SIGNAL_REGIME=0 (Default) -> as defined GnuCOBOL sets a bunch of signal handlers to handle on its own, mostly for cleanup purposes (and in case of most signals also output the call-stack, dump, ...)
• COB_SIGNAL_REGIME=1 -> as defined, sets up all entries like "0" - but does not do this for signals that are setup to be ignored before the setup starts (= before cob_initis executed)
• COB_SIGNAL_REGIME=2 -> as defined "nothing is done by GnuCOBOL" -> whatever the system does, which is in case of a shell/terminal - if you don't disable that externally or up-front - an exit
• neither the error nor the exit handlers are called in case of a catched signal, so you can also not abort that or add additional error handling

For a note how these can be used to ignore SIGINT, see [feature-requests:#521] (patches welcome to implement that, btw - maybe of interest to @chaat) .

The last part of my test results above is what this issue is about.
The main question: Should (both, or possibly only the error handler?) be executed when a signal is catche? For all signals? Should they allow to ignore the signal?

What is also possible for "catching" it (as long as no other signal handler was executed afterwards, registering for SIGINT): you could register an error handler with cob_reg_sighnd - but this is called after the COBOL runtime is teared down.
Similar, if you use cob_call_with_exception_check you should always get back to that (with an error code) - with the environment being teared down again.

[Ralph Linkletter]

Close this please - it seems it is not a bug.
The Micro Focus and Fujitsu behavior is a matter of implementing the code Simon has provided.

[Simon Sobisch]

So you've tested and neither ERROR_PROC nor EXIT_PROC are executed with Fuji/MF if you press CTRL+C?

[Ralph Linkletter]

Close this please - it seems it is not a bug.
Micro Focus disables Ctrl+C terminating an application via runtime config
SET COBSW=+K

[Vincent (Bryan) Coen]

Closed as requested

[Vincent (Bryan) Coen]

Reopened as it should be able to be captured pre O/S dealing with the condition.

By the use of a pre condition value or setting in the source code, etc.