I've seen the OE database server write events to the windows application log before. That is not a surprise.
But today I was very surprised to notice client-session messages too. For the first time I'm seeing that certain client-session errors and warnings are being written to the windows event log. Here are the two examples I've found so far. Note that these are being added to the event log on a PASOE server that has no database running on it:
This is a bit of a surprise. I have always relied on using the PASOE agent logs to find my errors ... but now it looks like some of them can be reported to the windows event log too. The PASOE instance is even going so far as to register a new event source ("LUMBERTRACK_PROGRESS") for these events. Screenshot.
The docs and KB have very little on this topic, but it appears there is at least a little bit of customization that can be done to adjust the behavior:
https://knowledgebase.progress.com/articles/Article/P26612
https://docs.progress.com/bundle/openedge-startup-reference/page/Event-Level-evtlevel.html
I'm wondering how far I can go with the event-log capabilities of PASOE ... maybe we can even use SCOM to extract errors out of these logs. It might give us more options for managing PASOE servers.
I just wish that the LOG-MANAGER had a mechanism to send messages to the windows event logs as well as the agent logs. I haven't found that functionality yet.
You can write a wrapper around LOG-MANAGER and then write to Windows Event Log.
&Global-define EventSource "TestProgress"
&Global-define EventLog "Application"
USING System.Diagnostics.*.
IF NOT EventLog:SourceExists({&EventSource}) THEN
EventLog:CreateEventSource({&EventSource}, {&EventLog}).
EventLog:WriteEntry({&EventSource}, "This is an event").
The problem is that you can't use EventLog:SourceExists and EventLog:CreateEventSource as non-administrator so first you'd have to create EventSource as an administrator and then you can use WriteEntry as a regular user.
Thanks for the tip.
I was thinking about this a little more and I'm pretty convinced now that this is vestigial behavior that is not an intentional part of the design of a remote instance of PASOE.
Notice that the messages claim to be from the database. The events explicitly say they are a "Message from PROGRESS database lumbertrack". I'm guessing that in a legacy "shared-memory" scenario, where client sessions are running on the **same** machine as the database, the client sessions themselves were responsible for logging some portion of the problems that are considered database-related .
The event-log entries coming from the database-server *and* from the client-sessions would be reported into the **same** event source on the same server, thereby giving a "complete" picture of all databases-related errors and warnings.
Again the value of this approach is somewhat lost when you are talking about a remote PASOE instance which is pretty far removed from the database server itself. It would be more challenging in that case to see the combined list of database-related errors and warnings. ... If you have a load-balanced PASOE deployment then things get even more peculiar - since you have to harvest all these database-related messages from a number of servers.
In general, most client-session errors in PASOE can be found in the msagent logs (including the "Lock wait timeout" one). It is odd to see these so-called "database" errors being treated differently insofar as they are sent to a custom event source in the application logs. I haven't found any examples of other types of error messages being sent to the windows event log on a PASOE server, so I think the messages are limited to errors that are considered to be "database" errors.
Hope this is clear. As tpavlovic showed above, it makes more sense if you log messages yourself, rather than relying on the the vestigial behavior from the days of "shared-memory" clients. You probably won't want the eventsource name to appear as if these messages are being written by the database server.