× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Chuck and CRPence,

Thanks for your replies and information.

I have to say that I think I agree with you that the trigger should ideally
only base it's decisions on the data.

However I have to work within the confines of project budgets / timelines
and I'm also thinking about what I can best control.

Currently the file has no proper audit fields to say who did what and when.
Obviously I could change that.

And it seems that the right thing to do would be to add a column to
identify whether an "external message is required" - as opposed to basing
the logic on ( for example ) the last update program name or possibly
accessing another table by program name to check the setting.

However that won't work either without revisiting all of the existing code
and making sure the new fields are all set correctly.
Otherwise, the only place ever updating the "external message required"
column would be the new server code, and once set it would retain that
value for all other updates.

So, now I'm up for not only recompiling the old code but changing it and
therefore retesting it.
My project manager won't love me.

And with regard to what I can control, I think - what would it take to
break the code and which seems more likely:

1. A careless developer sets the "external message required" field
inappropriately, either in production code or a fix program or even STRSQL
and so messages are not sent out to the external application when they
should be.
2. Someone decides to mess about with Work Management settings for the
message server subsystem or modifies the submission programs for the
servers.


- I would hope 1. wouldn't occur but I can easily see how it could.
- 2. Is extremely unlikely, but if done, is more likely to be done with
knowledge of how the systems interact.


I'll think more on this and I appreciate your points thank you.

Thanks as always and regards,
Craig

On 24 February 2018 at 06:15, Graves, Chuck <cgraves@xxxxxxxxxxxxxx> wrote:

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


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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.