feature request: syslog logging in libcob

[lefessan]

Some of our customers are used to having COBOL programs being automatically monitored by their mainframe (usually issuing stop/start events, I-O stats and unexpected errors).

So, I am thinking about adding something like that into libcob. The idea would be:

• To have an env variable like COB_SYSLOG that can be set by the user/system
• The content of this variable would be used as some kind of bitmap to decide which events should be sent to syslog, and as which facility (for example, 'j' would be start/stop events, 'f' for file input-output, 'e' for errors, etc.)

@GitMensch Do you have an opinion on that ? Would it be ok as a contribution to GnuCOBOL ? Do you have requirements or nice-to-have features that could fit such a proposal ?

[GitMensch]

This is a useful discussion - and it belongs to the gnucobol dev list, please send it there.
If we add syslogging (which should be an optional feature, otherwise it should go to a logging file) then this may be better a configurable target than a single one, and this would also apply to current output (like runtime warnings/errors), but I'm not sure if this should be additional or "only".
Maybe something like COB_LOGGING=warnings(stderr,syslog[libcob_warn]),errors(stderr,syslog[libcob_err],file[/opt/log/$$.err]),iotrace(stderr)?

Even with syslogd allowing to also send output to a file a "direct" write will always be faster.

In GixSQL spdlog is used, but that is C11++, so out of scope.
With syslog the question is always what to do on Win32, I guess there are C syslog wrappers that would write to the event list, but I don't know.

Or "just add" syslog as a target, maybe with optional [name] for all configurable output files from runtime.cfg, which would only be available if configure finds the necessary header/function + additional output files for things like start/stop (if set, then output is done, otherwise it isn't)?

As noted: in general that should be sent to the dev mailing list, please put some additional thoughts (not a full design) and maybe outline 2 possible approaches in your mail.

[lefessan]

I don't think I have access to a dev-only mailing list on GnuCOBOL. I just registered to a few mailing lists, but they seem to be for users.

[GitMensch]

That was correct, sorry. You're now the speaker of this repo to the GC dev group :-)

[GitMensch]

Note: for module loading/unloading and environment and file there's even and old related FR: https://sourceforge.net/p/gnucobol/feature-requests/270/