On Fri, 21 Mar 2025 11:50:19 +0100
"Jose E. Marchesi" <jose.march...@oracle.com> wrote:
>
> > Am 20.03.2025 um 21:50 schrieb James K. Lowden:
> >> On Mar 13, 2025, at 8:04 AM, Simon Sobisch <simonsobi...@gnu.org>
> >> wrote:
> >>>
> >>> exit() allows us to "pass to the operating system" directly; but
> >>> it doesn't directly say "success" or "fail".
> >>>
> >>>
> >>> Obviously the statements
> >>> STOP RUN WITH NORMAL STATUS 41
> >>> and
> >>> STOP RUN ERROR 41
> >>>
> >>> Should have a different result for the operating system.
> >> Or, obviously not.
> >> For OSes I'm familiar with, there is no *definition* of
> >> success/failure. There's just convention: 0 is success and nonzero
> >> failure. Even that is honored in the breach, see diff(1).
> >> IMO unless the OS defines success/failure outside the value of the
> >> exit status value (above, 41), the COBOL compiler cannot supply
> >> meaning to STOP RUN NORMAL or ERROR. It has no meaning in COBOL
> >> because it has no meaning outside COBOL.
> >> By that reasoning, the two statements above both return 41 because
> >> there is no way to say more. It is for the caller to decide what
> >> to do.
> >> I do not think -41 is an option; the compiler should not make
> >> arbitrary changes to the user's data.
> >> It is temping to raise(SIG_TERM) for error, but again the 41 is
> >> lost.
> >>
> >>> STOP RUN WITH ERROR "Don't do that, Jon!"
> >> When no numeric value is supplied, IMO:
> >> ? STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
> >> ? STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)
> >> That satisfies the Principle of Least Astonishment. BTW those
> >> values are defined by C, not POSIX.
> >> --jkl
> >
> >
> > I agree that this could be a reasonable approach:
> > * STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
> > * STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)
> > * Any text given goes to an internal DISPLAY (_possibly_ WITH ERROR
> > doing a DISPLAY UPON SYSERR)
> >
> > If I'd not now that "some heavy business applications" actually pass
> > the error using specific values (one for deadlock, another for
> > general db issues, one for logic issues, ...) I'd say "screw the
> > numbers - just DISPLAY them".
>
> So:
>
> STOP RUN
> EXIT PROGRAM
>
> should:
>
> exit (EXIT_SUCCESS).
>
> Then:
>
> STOP RUN WITH NORMAL STATUS <number>
>
> should:
>
> fprintf (stderr, "STOPPED WITH NORMAL STATUS %d", number);
> exit (EXIT_SUCCESS);
>
> Then:
>
> STOP RUN WITH ERROR STATUS <number>
>
> should:
>
> fprintf (stderr, "STOPPED WITH ERROR STATUS %d", number);
> exit (EXIT_FAILURE);
>
> ?
My executive summary would be:
* STOP RUN WITH <any> STATUS <number>
exit(<number>)
* STOP RUN WITH NORMAL STATUS <message>
display <message>
exit(EXIT_SUCCESS)
* STOP RUN WITH ERROR STATUS <message>
display <message>
exit(EXIT_FAILURE)
In 2025 we want to elaborate our trace functionality by writing to
syslog (where supported). For example, with LOG_NOTICE, enabled but
unhandled Exception Conditions should be logged when raised, whether or
not fatal, for the user's edification. Similarly,
STOP RUN WITH ERROR STATUS 42.
would record the fact of "error status" in the log, where the careful
user can respond accordingly (maybe by changing the program).
As a reminder, syslog messages can be copied to standard error with
LOG_PERROR. That feature could be turned on with a command-line option
or environment variable.
--jkl
