P
Patrick Tingen
Guest
For our application we use a session-persistent procedure that listens to the event 'DEBUG-MESSAGE'. Whenever it receives such a message, it finds out which program sent it and which user started the program. It then uses the LOG-MANAGER to create or re-use a logfile, specific for that user, program and date.. A typical name for a logfile could be psspecmt1_20160419_nljrbkl.log Where psspecmt1 is the program and nljrbkl is the user. The mechanism can be controlled via a general setting in our database so we can turn it on or off as we like and set the folder the logfile needs to be written to. This mechanism also holds a maximum lifetime for the logfiles so they get cleaned up automatically after some days. So far, so good. The problem arises on the AppServer. We use the same mechanism for procedures that run there. But since we cannot set the name of the logfile in the LOG-MANAGER (see PKB 000037132 ), all of our debug messages end up in the Appserver logfile. That itself is not the biggest issue, but the AppServer logfiles grow rapidly, the developers have no access to these logfiles and the contents of the logfile is now mixed with both connect / disconnect info, which is not interesting for the developers, and application debug info, which is not interesting for our admins. In the past we have used a persisitent procedure that did a normal "OUTPUT TO" and closed itself, but it gave us too much headache; when procedures ended prematurely, the file remained locked or on consecutive runs, the log mechanism itself crashed because it tried to write to a locked file. So my question is: what would be a good alternative? (10.2B)
Continue reading...
Continue reading...