MVSFORUMS.com

[Jamylady]

I searched for this topic with out luck; blame me if there is already one like this.
Folks,
We are in a situation where we can't make program changes, but we need to capture the history on any database update. Using TRIGGER was an excellent idea till the point where we realized that when we do an update using CICS Screen, DB2 is actually reckoning the CICS as the user and returning the CICS process ID under the USER column. Is there any way we can get the current CICS -user using TRIGGER?
As you know, any history data should have USERID and Timestamp.

The TRIGGER is working fine, history is been written, but we are not able to capture the USER. What DB2 is able to capture is the process id of the CICS instead of the actual user id.

Any help would be greatly appreciated

Thanks
JA

[CZerfas]

Hello JA,

during the definition of your CICS - DB2 connection (I think it's DB2C, probably DB2T) you name the userid which will be used to create the thread to DB2. I think you have the following alternatives: the CICS start user (which is used in your installation), the ID used by the user to logon to your CICS or a string literal (which of course has to be known by your DB2 subsystem). In the DB2 installation guide you should find the complete story.

In our shop we have the userid of the one sitting in front of the screen available within DB2, so there have to be alternatives to your situation.

regards
Christian

[Jamylady]

User id can be made available to DB2 programatically by using host variable. but when we want to capture any add/update/delete by the application, DB2 doesnt know who the actual user is. All it knows is the process id of CICS
I am not sure how to get this right!
Thanks

[CZerfas]

This is not a problem you can solve during program execution.

When the connection between a transaction and DB2 is build (called a thread), a DB2 authorization exit gets control and fills the DB2 registers "primary authorization id" and the list of valid "secondary authorization ids". By default the CURRENT SQLID is set to the "primary authorization id" and can be manipulated with SQL.

Your problem is, that due to the parameters userd during thread creation, the "primary id" is set to the id of the CICS starter. This can be changed by your system programmer to the id of the transaction starting user.

Therefore, you have to talk to the system programmer responsible for defining the CICS/DB2 attatchment.

regards
Christian