Add a special register in SQL triggers to get the schema of the underlying table, at any point, not just in error handlers

Offset Dec	Offset Hex	Type	Field
0	0	CHAR(10)	Physical file name
10	A	CHAR(10)	Physical file library name
20	14	CHAR(10)	Physical file member name
30	1E	CHAR(1)	Trigger event
31	1F	CHAR(1)	Trigger time

In a RPLE trigger, we have the folowing information. It will be nice to have something similar un SQL.

D TRGBUF DS 2024 Received parameters
D TRHEAD 1 96 Header
D TRPF 1 10 Physical file
D TRPFL 11 20 Physical file libr
D TRPFM 21 30 Physical file mbr
D TRTYPE 31 31 Type 1=Ad,2=Dl,3=Ch
D TRTIME 32 32 Time 1=Aft,2=Bef
D TRRRN 41 44B 0 Relative Record #
D TROSBF 49 52B 0 Offset image before
D TRRLBF 53 56B 0 Rcd lenght before
D TROSAF 65 68B 0 Offset image after
D TRRLAF 69 72B 0 Rcd lenght after
D TRBUF 1 2024 DIM(2024) Buffer & Images

Hi,

In Db2 SQL triggers, there are cases where we need to populate an audit or diagnostic log with the execution context of the trigger, specifically the library (schema) in which the trigger is running. This requirement becomes critical on systems hosting multiple Db2 databases or multiple library lists, where the same trigger logic may be deployed across different libraries. In such environments, a trigger does not have native access to its effective execution library, and therefore cannot reliably determine or report this information at runtime. A possible workaround is to query the Db2 system view STACK_INFO to infer the execution context. However, this approach is computationally expensive, introduces non-negligible overhead, and can degrade trigger performance, especially in high‑throughput transactional workloads. Consequently, there is a need for a dedicated special register or built‑in mechanism that would expose the trigger’s current execution library directly, without requiring stack inspection, and independently of any error or exception condition. Such a feature would allow reliable and performant logging and auditing in multi‑database DB2 environments.

The CAAC has reviewed this IBM Idea. More information is needed.
Can you describe a programmatic use case?

Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual IBM Ideas on the broader IBM i community and has therefore reviewed your Idea.

For more information about CAAC, see www.common.org/caac

Carmelita Ruvalcaba - CAAC Program Manager

IBM will use this Idea as input to planning, but no commitment is made or implied. This Idea will be updated in the future if IBM implements it.

Db2 for i development team
IBM Power Systems Development

We have this information in a RPGLE trigger, but not under SQL