Re: Trigger Processing Question

That is still not going to get you the current version. The OS stores the
virtual address of the program for the next time if gets called. If you move
the program it will go to where you moved it to or if you deleted it it will
error out.

Solutions:

1. If you store the name of the program and library in a character field it
will not store the virtual address.
2. Use the trigger mediator. When you reload, it reloads everything and it
get the correct version of the service program so you don't deal with all
these issues.


On Fri, Jun 17, 2011 at 10:58 AM, Morgan, Paul <Paul.Morgan@xxxxxxxxxxx>wrote:

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