Re: Recognising a particular job

When you update the record that fires the trigger, can you put a code in that record that identifies the source of the update. The trigger can then read that code and act accordingly.

Sent from my iPhone

On Feb 23, 2018, at 5:54 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

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].

--
Regards, Chuck

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD

[Rodda Paint Company]
Chuck Graves
Consulting Partner
Rodda Paint Co.<http://www.roddapaint.com>
6107 N. Marine Drive
Portland, Oregon 97203