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


  1.  Home
  2. MIDRANGE-L
  3. June 2011

Re: Trigger Processing Question

Charles,
I did not make myself clear on my prior posts.
The data / program flow that I am going to be using is:
1. Trigger fires on change to file
 a. program tests if desired fields have changed.
 b. if desired fields changed, send message to data queue and submit job to
start processing program if needed.
 2. Batch job retreives list of jobs from NEP subsystem and if desired job not
running, submits to batch.  This will be a NEP program that waits on a data
queue.
3. In NEP program, when data queue message is received, process data and wait
for next message.

What I was concerned about was step 2 - The batch job that tested if the NEP
(data queue processing) program was active.
I want to be able to change that program if needed and was not sure what the
best way to run it was.
I have settled on submitting it so that I will always get the latest version.

Thanks again to all who responded.

 
Jeff Young
Sr. Programmer Analyst






________________________________
From: Charles Wilt <charles.wilt@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Mon, June 20, 2011 9:03:32 AM
Subject: Re: Trigger Processing Question

If you do it this way, expect poor performance when the trigger is
fired multiple times in a single job...

ie. a batch update on the triggered file.

Particularly if the program is in RPG IV (RPG IV dynamic call is more
costly than an RPG III dynamic call)

Alan's trigger mediator would be a better choice IMHO...it includes
functionality to let you tell the trigger to reload a newer version.

Charles

On Fri, Jun 17, 2011 at 1:11 PM, Jeff Young <cooljeff913@xxxxxxxxx> wrote:
Thanks Paul,
I was not sure if that would work.

Since the batch job is library list dependent, I could have multiple copies
running with different job names that are identified by the environment.
If I setup a new enviornment, I would have to create a new prestart job entry
for it.

I appreciate all of the suggestions that I have received and will use Paul's
suggestion to make it a dynamic call.

Quick question:
The trigger program is Free Form RPGLE and I had been using a prototype with
EXTPGM.
How can I make this into a dynamic call instead of static?

Thanks,


Jeff Young
Sr. Programmer Analyst






________________________________
From: "Morgan, Paul" <Paul.Morgan@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Fri, June 17, 2011 12:58:14 PM
Subject: RE: Trigger Processing Question

Jeff,

To answer your question:

1) Make sure you are making a dynamic call to the program
2) Make sure the program shuts down after every call so it's no longer in the
call stack of the process

Then when you call the program again in the same process you will call the
current version.

Have you looked at a prestart job entry in that subsystem for your process or
processes that receives the data queue entry?  Those can get automatically
restarted by the subsystem if they ever end.

Paul Morgan

Principal Programmer Analyst
IT Supply Chain/Replenishment


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jeff Young
Sent: Friday, June 17, 2011 12:30 PM
To: Midrange Systems Technical Discussion
Subject: Re: Trigger Processing Question

Paul,
I still need to know if the program that receives the data queue entry is
active.
This will be a program running in a NOMAX jobs subsystem, but needs to be
library list sensitive.
My current logic is to call a program with the data needed for the data queue
and test if the processing job for the environment is active.
I do this using the List Active Jobs API and if the job is not active, I
submit
it.

My question is what is the best way to call this program from the trigger to
ensure that I will always get the current version?

Thanks,,

Jeff Young
Sr. Programmer Analyst






________________________________
From: "Morgan, Paul" <Paul.Morgan@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Fri, June 17, 2011 11:49:05 AM
Subject: RE: Trigger Processing Question

Jeff,

Why must the trigger program check if the processing program is active?  That
shouldn't be done in the process that fires the trigger.  Do that with some
sort

of scheduled job to occasionally check if the process monitoring the data
queue
is active.

Why must the trigger determine if the data queue exists?  I'd just have the
trigger program push an entry into the data queue.  Monitor or trap that push
into the data queue for an error. If you trap a 'data queue doesn't exist'
error

then do something about it.

Paul Morgan

Principal Programmer Analyst
IT Supply Chain/Replenishment


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jeff Young
Sent: Friday, June 17, 2011 11:34 AM
To: Midrange Systems Technical Discussion
Subject: Re: Trigger Processing Question

Hi Paul,
That is basicaly what I am doing, but I need to determine if the data queue
exists and if the processing program is active.
I have a program that will do that, but what is the best way for the trigger
to
call it so that if needed I can make adjustments to it without having to
worry about what version the trigger is actually calling.

Thanks,

Jeff Young
Sr. Programmer Analyst






________________________________
From: "Morgan, Paul" <Paul.Morgan@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Fri, June 17, 2011 10:43:08 AM
Subject: RE: Trigger Processing Question

Jeff,

Fire off an entry into a data queue from the trigger program.  Have another
process already running which is monitoring the queue and processes the entry
to


call the other program to do some other processing.  It's possible for you to
shut down the process and restart it to make changes to the other program.  As
long as the data queue is available the trigger program can continue to fire
entries into the queue.

I wouldn't do any checking for a data queue or process in the trigger program.
Neither would I submit a job or call the program from the trigger program. 
You
want to reduce as much as possible any possibility of an error or delay with
the


trigger program.

If you want to make changes to the trigger program you should use the Trigger
Mediator pattern.

Paul Morgan

Principal Programmer Analyst
IT Supply Chain/Replenishment


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jeff Young
Sent: Friday, June 17, 2011 10:27 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Trigger Processing Question

V6R1
I have a trigger program that is going to be called thousands of times during
the day.
This program will test some fields in the old and new record and then fire off
a



program to do some other processing if they are changed.
At this time this is the only trigger being used, so the Trigger Mediator
program is overkill.
I want to be able to make changes to the program doing the proessing if
needed.
I will initialy call a program to test if  a data queue exits and if the
processing job is already active and waiting for a message.
If not, the program will create the data queue and then submit the processing.

What is the best method to call this program?
 Dynamic call from the Trigger?
Submit job to batch ?
Some other method?

All suggestions will be appreciated.

Thanks,

Jeff Young
Sr. Programmer Analyst
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
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.