Re: Recognising a particular job

On 22-Feb-2018 12:30 -0700, Craig Richards wrote:

I have a trigger program where updates to the table could come from:

1. The general application / support staff OR
2. An Application Server processing messages coming in from an
external system.


- If an update is caused by 1. then message needs to be sent out to
the external system.
- If an update is caused by 2. then the external system instigated
the update and therefore does not require a message.

A given trigger program can always determine the Application Server
program relevant to the file it's on and therefore one way to
determine if it is case 2 would be to check if that program was in
the call stack, by using an API ( quite expensive I think? ) or
trying to send a message to a Program Queue of that name ( will fail
if it's not in the call stack )

These seemed like OK solutions if they could be done once at
initialisation and remembered, but that's not a great idea in a
trigger program... And I fear that the call stack one is a bit
expensive to do every time and the program message one will fill up
the joblog....

So I'm wondering about other non-expensive ways to determine in the
trigger program if it needs to send out a message. Some simple but
not foolproof things that occur to me are:

- Job User or Name if this can be guaranteed to only be used
in case 2.
- Jobs in case 2 will have their own subsystem but I can't see
that attribute on the QWCRTVCA API.
- Accounting Code seems to be linked to User Profile or JOBD and
can't be changed on the fly.

Anyone know of a very inexpensive way to tag a job that
could be utilised in a trigger program.

IMO, asking "who called" is an indication of a probable design problem; as expressed elsewhere, the data should be all that the trigger program needs to make any decisions about what to perform, so as to avoid either a need for the program to /assume/ what to do, including possibly the program being designed to fail, in the event the "who" is undefined per use by/in a previously untested or since-changed environment. That said, a possibly apropos means:

[->Retrieving data using the SELECT statement->Special registers in SQL statements](https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/sqlp/rbafyspecreg.htm)

For example, the CURRENT CLIENT_APPLNAME [aka: CLIENT APPLNAME] could be referenced; obtain a value for the "application name for the client connection" that had been set by the application [via a application/connection method, the WLM_SET_CLIENT_INFO procedure, or the Set Client Information (SQLESETI) API].