Some of our developers here have been asking if anyone has developed a logging facility for Natural. (These programmers also work in Java; they’re thinking of something like log4j.) One suggestion was to use SYSRDC, but that looks at more of a systems level; we’d want to trace application-defined events with variable control over the level of logging. Has anyone done anything like this?
If you have Construct or Natural Business Services you can use the Trace and Debug Utilities to perform something similar to log4j. The utilities even automatically add tracing statements to exiting natural code if you want. You can also control when and where the output is written (screen, source area, work files, print files, etc…).
For more information, see the section “Supplied Generation Utilities” in the Generation Users Guide of the official documentation.
what you offer is, in my opinion, not a utility but a crutch. You can’t do this in normal production environment (can you change source code in production environments?). I would like a logging implemented into the natural runtime system. If necessary, it could be switched on even in production environments. This functionality could then also be used for a good debugger (as the current debugger only offers very very basic functions).
Just my opinion
You make some very valid points, but I was comparing this to log4j which also does something very similar in that you are required to add the logging statements to source code. At runtime you decide if logging is enabled or not, and if it’s disabled there is little to no performance hit. This is very similar to the way the Construct utilities work.
What is wrong with the original propopsal of using RDC from within the Natural nucleus? Using the “U” (user) type requests you can start, stop, and log, anything you want.
The “U” type RDC call can be for any application-defined event you like. It can always be written to the RDC wrap-around buffer. When you want to see them, send a special “U” record (and this can be from any natural session, even a remote one). The purpose of the special “U” request migh to log those events to a specific destination such as a file, or system log, or a CICS TDQ or even a SYSVIEW history log. Whatever destination you choose.
Such a facility would be relatively easy to code.
we published tha Logging-Framework on Sourceforge:
Feel free to download and using it.
We liked if you are helping use to improve the Logging-Framework.