CODEWITHSUNDEEP
odbcdb2ibm-midrangerpg
Bill Martin
Bill Martin

Reputation: 4943

How to define the calling program when using Iseries ODBC?

Is there a way to define the calling 'program name' when using the Iseries ODBC driver? When I run a command against our AS400 using the Iseries Access ODBC driver, the calling program in the call stack of the as400 shows the program name as blank. I'd like to define one because we have a trigger that needs to know who is the caller.

Upvotes: 1

Views: 1455

Answers (3)

user2338816
user2338816

Reputation: 2163

It's been possible for some time, exposed only since i 6.1. For an example usage, run this statement in i Nav 'Run SQL Scripts...':

select CURRENT CLIENT_APPLNAME, CURRENT CLIENT_PROGRAMID, CURRENT CLIENT_WRKSTNNAME from sysibm.sysdummy1

Support is available to application developers using a JDBC, OLE DB, CLI, or .NET data provider. They can also be set by calling a special stored procedure.

Using IBMDASQL for example, a connection string might include:

conn.Open "Provider=IBMDASQL; Data Source=MyAS400;" & _
"Client User ID=MYWINUSRID; Client WorkStation Name=MYWINPC; " & _
"Client Program ID=somepc.exe; Application Name=Sample for Audit"

The SQL Reference discusses new "special registers".

Upvotes: 0

Korinne Adler
Korinne Adler

Reputation: 676

As JamesA points out, all ODBC requests go through the QZDASOINIT job, so you can't change the call stack to determine the caller.

To get around this problem, DB2 for i includes client special registers that are automatically set by the ODBC driver (which you can override if you wish) and your trigger can then use. For more information see: http://ibmsystemsmag.blogs.com/i_can/2009/10/i-can-use-client-special-registers.html

Upvotes: 2

James Allman
James Allman

Reputation: 41158

The ODBC connection is proxied through a QZDASOINIT job. I don't believe there is a way to identify the specific connection (or program) that fired the trigger.

Upvotes: 3

Related Questions