Re: Trigger Question

my 2 cents - like everything else we do, it depends.

if the trigger's not going to do very much, a chain here, an update
there, leave it in-line.

if the action done by the trigger is integral to the application's
requirements that it be done immediately, leave the processing
in-line.

If the trigger just does a bit of housekeeping, and might require more
than a half second or so of processing, and depending on how often the
trigger will be fired, moving the process outside of the trigger might
be a valid alternative.

another solution might be to have the trigger write the buffer to a
dataqueue and have a monitoring never-ending-program read the queue
and perform the processing.

pros - no overhead of starting up a job in batch for every change to
the trigger file.
cons - dataqueues are a bit volatile - the chance of losing a data
queue entry due to unforceen errors is a bit greater than other
methods, but not unsurmountable.

ymmv.

Rick

On 12/17/05, Jack Derham <derhamj@xxxxxxxxxxxxx> wrote:
> To All,
>
>
>
> A discussion of Triggers the other day got a little heated when one member
> of the discussion said that IBM recommends that Trigger programs should not
> be designed to SBMJOB jobs but rather should do all of the processing within
> the bounds of the trigger program itself. Of coarse, as is almost always the
> case in these types of discussions, references were very scares, and the
> group of people quickly became polarized into pro and con camps. My search
> of the literature did not provide me with any concrete evidence one way or
> the other so I am turning to an excellent source of technical information to
> get either literature references or personal experience stories to settle
> this question in a friendly and logical fashion. The basic question: Should
> Trigger programs when necessary be designed to Submit Jobs to complete
> required processing.
>
>
>
> By the way, A very Merry Christmas holiday to all members.
>
>
>
> Jack Derham
>
> Direct Systems, Inc.
>
> --
> 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.
>
>