Re: QWVRCSTK - CSTK0200 for 'what program fired the trigger'

On 28-Oct-2011 08:59 , Buck wrote:

I'm implementing QWVRCSTK in a trigger program for the usual reason:
to find the name of the program that performed the database update
that caused the trigger to run.

And my usual response... If a trigger needs to know the answer to the question of effectively "Who called?", then there might be a design issue that needs to be resolved. An answer to that question should not need to be asked generally; best if only asked in some rare security\auditing scenarios. Seriously question the reasoning which led to the conclusion for the need to know that detail within the trigger, and give careful consideration for why that information should not be used to make decisions to implement the business rule(s) for which the trigger exists.

I can understand why IBM includes CSTK0200 in a generic call stack
traverser; any given call stack may indeed have Java or PASE as the
originator. But for the purposes of finding the program that fired a
trigger, I don't see how Java or PASE could be in there.

A quick test of a Java class running on the i shows me that before
QDBUDR I get:
QSQRUN3 SQL_Update
QSQROUTX QSQROUTX
QZDASRV EXECUTE
QZDASRV QZDASQL
QZDASRV SQL_ECALL
QZDASRV SQL_EXTPGM
QZDASRV SQL_CODE
QZDASRV QZDACMDP
QZDASOINIT main

It appears to me that if I use CSTK0200, the only format returned
will be STKE0100 - for the purposes of finding the code that fired
the trigger. Empirical evidence is nice, but formal documentation
would be nicer.

My big 'problem' was that I was unable to get a Java stack frame to
test with :-)

What does the stack look like when an I\O is requested from a JAVA stored procedure? A JAVA toolbox I\O even without an SQL procedure?

create procedure ...
language JAVA parameter style JAVA
external name ...

Just as any native code can access a database file member via IFS naming, so too can a PASE process.? Something as simple as redirection could open and write.?

Regards, Chuck