Re: Logging NDB and SQL... endless loop issue?

Don't log your log.

I know that sounds over-simplistic, but it really is the answer. The log is a separate entity whose activity shouldn't be logged in the log, anymore than sending a message to QSYSOPR should cause a message to be sent to QSYSOPR.

I know that second one.  I did it once.  Didn't end well.

I am looking into putting together some simple NDB and SQL logging for a
customer using the appropriate exit points.

The issue I can see is, if both exit points are working, and the logging
goes to normal table, this seems like it would cause an infinite loop of
logging, no matter if RLA or SQL is used to write the information. Unless
I'm overthinking it. :)

Ie... an SQL statement comes in
Exit program gets it, and writes a log of it to a table (using SQL)
..... this causes the exit program be called again...for each record
itself writes

If we use RLA to write the SQL log, and have NDB logging, same thing.
SQL statement comes in
SQL exit point logs using RLA, NDB exit is called
NDB exit writes to log and any way it does causes either NDB or SQL pme pf
tje exit points will be called again.

I suggested if this is the case that we log to the IFS as CSV or some other
format. But I just want to know if I'm overthinking this and there's some
magic that says "if the table action comes from an exit point, don't call
the exit point" or something else.

So far I have come up with nothing. But having a fever and a cold isn't
help much for clarity of thought lol..


Bradley V. Stone
www.bvstools.com
MAILTOOL Benefit #18 <https://www.bvstools.com/mailtool.html>: Ability to
use SSL, TLS or OAuth 2.0 authentication. (OAuth 2.0 only available with
Google or Microsoft Office 365).