Hi George,
the trigger program is executed in the same process as the database request, so you can use APIs to retrieve the current user profile of the process and the call stack if you need that information. The program has a "trigger buffer" as input parameter, which contains information about the operation type, the relative record number (row number) and the row data before and after the change.
In both cases (journal and trigger), the user and program information is the operating system view of the application: You will always get the instance user profile (typically <sid>adm) and the database interface program (typically XDNINLSVR), but not the SAP user, SAP transaction or SAP ABAP program name. The SAP information can be retrieved through SQL "special registers" CLIENT APPLNAME, CLIENT PRGRAMID and CLIENT USERID, but only in a trigger program, not through the journal (see http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/db2/rbafzspecreg.htm).
Unfortunately the SAP dictionary is very strict on trigger programs: SAP Notes 1749824 and 1655725 document that tables changes through the data dictionary are not possible when triggers exist on the tables. You would have to remove the triggers before installing transports that change the tables in question and add the triggers afterwards manually.
Kind regards,
Christian Bartels.