Re: Logging NDB and SQL... endless loop issue? [PERSONAL REPLY[ -- MIDRANGE-L

NDB IBM refers to as "normal data base" operations I believe. These are
done using WRITE, UPDATE, READ, CHAIN, etc. They are a separate exit point
from the SQL.

So if I'm logging both, no matter how I write I see it looping endless just
from writing log entires to the file. :) Make sense? I'm sure I'll get a
couple replies...there must be a way to see that "oh, this is a log from
the exit point, so don't log it" or something similar, but it's still going
to cause a little slowdown in performance.

Yes, this cold/flu started out just a tight chest and cough.. then the
fever for 3 days and pins and needle skin and headache. ouch.. I think my
fever is finally broke, but now I have the runny nose. I have a physical
on Tuesday and I have a feeling my liver enzymes are going to be sky high
from all the advil and aleve and sudafed haha!

On Sun, Feb 18, 2018 at 10:46 AM, Mark S Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Hi, Brad,
* >>>---> private reply off-list **<---**<**<<*

Just recovered from a nasty chest cold myself, so I can relate ... drink
plenty of fluids (OJ, chicken soup or broth, etc.) to stay hydrated and get
plenty of rest ... (my cold was the typical duration -- 3 days coming
on, 3 days with, 3 days leaving ...)

Not sure exactly what you mean by "NDB logging"...

As far as SQL logging, I believe the exits you refer to will give you
access to the actual SQL statements being requested by various clients,
e.g. whether coming in from a PC (Client Access Operations Navigator SQL
window, etc., or some ODBC/JDBC type of application, or even from RPG
programs using embedded SQL or using the DB2 SQL CLI interface ...

But, if you turn around and write that data out to a table, using RLA, I
don't think that will go anywhere near that particular exit at all ...
this exit point is _not_ logging each and every "transaction" (that would
be more the job of Journaling ...) -- just the SQL statements.

Hope that "makes sense"...

My best suggestion is -- try it ... write a small simple version of one of
those exits, to write the data out to a "flat file" or table using RLA, and
see what happens ... plug the exit in, and watch ... then you can just
un-plug it ... :-)

Hope that helps somewhat ...

I hope you start to feel better soon ...

Mark S. Waterbury

On 2/18/2018 11:06 AM, Bradley Stone wrote:

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).

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD