On Mon, 12 May 2025 14:05:50 +0200 Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
> Before going further, I'd first like to understand why you chose to > use syslog in a runtime lib. While logging to syslog is certainly > useful in daemons and such, a runtime lib is different IMO: while > regular users can log to syslog, access to the log files is usually > restricted to privileged users. Hi Rainer, Thank you for asking the question, and for providing the exact minimal fix I would have suggested. I support your effort to ensure the COBOL FE compiles on Solaris, and I'm sorry i ran afoul of it. I added syslog for error messages to libgcobol because it will be required in production. Daemon mode is normal for COBOL programs, and interactive mode is rare. There is no need for a daemonization process on a mainframe because running "headless" was its modus operandi before it had a name. Most COBOL systems are launched by something like JCL, and monitored via logs. They may be batch programs. Or they may be online in the form of e.g. CICS, which has as you might guess extensive logging. The use of LOG_PERROR is a convenience for the gcobol user during development and testing. It's my intention to make it an option, something that I'll address when I overhaul options Real Soon Now. I don't intend an option to defeat logging. If logging is defeated during testing and enabled in production, surprises will be unpleasant. If logging is defeated in production, support will be much more difficult. If log messages are overwhelming or inconvenient, that's what identification, facility, and level are for, in syslog configuration. As a matter of GCC policy for libgcobol messages, I would suggest: 1. Use LOG_PERROR if available, else #define LOG_PERROR 0. We can manage that in configure.ac. For systems that don't support it, document that it's not available. If that presents a problem to someone, the license lets them modify the code. (As can we, of course.) 2. If different syslog systems format their messages differently, that's ok. The messages produced by libgcobol will be in the format familiar to the sysadmin. 3. Simplest is best. As of now, there are 3 calls to syslog(3), with no workarounds and no conditional code. That serves all demonstrated need. By keeping it simple we make it reliable, which I'm sure we all agree is a key feature of logging. Finally, I want to clarify for those following along at home why libgcobol produces any message at all, ever, since the normal rule is that libraries should be quiet. ISO COBOL defines Exception Conditions that may be enabled by the program and Error Status on files. Some are defined as fatal, meaning if they aren't handled by the program they lead to process termination. In libgcobol, any fatal condition -- enabled explicitly or implicitly -- that is not handled by the program is logged and leads to a call to abort(3). In addition, any EC explicitly enabled and not explicitly handled (fatal or not) is logged. By default, no EC is enabled. The theory is that if the program enables an EC and doesn't handle it, that represents a logic error. The message can be quelled by disabling the EC or handling it, either way. I hope that answers your question. It's not the only way in which COBOL is different from C, believe me. Welcome to my world. --jkl
