pgm that triggered the trigger pgm?

Frank,

I opened a DCR (Design Change Request) number MR082903246 in August 2003
as follows:

---------

1. Request Title:
 
Addition of Application Program/Library name to Trigger Buffer
 
2. Provide a detailed description of request (including unique usage):
 
When an application program updates a database file which has a trigger
attached, the trigger program is called by the database itself and is
passed a trigger buffer parameter, containing information about the type
of database update that is being attempted and also 'before' and 'after'
database record images.
 
One piece of important information missing from the trigger buffer is
the name of the application program/library which is attempting to
update the database. For the trigger program to manually retrieve this
information requires at least one API call and some additional
processing, which affects the performance of database processing. Since
triggers are described as having excellent performance (because they are
called directly by the database rather than by the application program
itself), it's annoying that we need to offset this by adding additional
API calls, especially as the information we need (application program
name) is available to the database when it calls the trigger program.

3. Do you have a suggested solution?
 
Include the application program name and library within the trigger
buffer. The trigger buffer structure includes data based on offsets
rather than at fixed positions within the structure, so there should be
no problem in adding extra information.

---------

IBM replied 8 MONTHS LATER with this: "If this were done, it could only
work for native triggers (not sql triggers), would this be acceptable?".
So I responded with:

---------

I would think so - for SQL triggers, perhaps simply filling the (new)
AppPgm field with "*SQL" and leaving the (new) AppLib field blank would
be acceptable. After all, it is currently possible to discover this
information within the trigger program by going back up the call stack -
it's simply a hassle and can hit performance, which is a problem if the
trigger is potentially being called thousands of times. Therefore users
of SQL triggers aren't completely lost - they simply won't get the
benefit of this new feature.
 
My more immediate concern is where within the trigger buffer this new
information could be placed - would it be placed within the variable
section and if so, how would it be located?

Is the 16-byte reserved section at offset 80 currently used, or is it
simply a spacer? If it's only a spacer, could it be changed to be a
pointer to a fixed-format control section which could contain the AppPgm
and AppLib fields (as well, possibly as other control information)? If
not, I don't see how this information could be added...

---------

I never heard anything back from them after that...

Rory