Open lefessan opened 1 year ago
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.
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.
That was correct, sorry. You're now the speaker of this repo to the GC dev group :-)
Note: for module loading/unloading and environment and file there's even and old related FR: https://sourceforge.net/p/gnucobol/feature-requests/270/
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:
COB_SYSLOG
that can be set by the user/system@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 ?