I agree with Dennis. One of the ways of doing what Dennis suggests is: If you use SL (service layer) model for instance, the CKTI would trigger SL ProgA which can check to see if the ProgB (that services the app. queue) is already running. If so, the ProgA will not start ProgB.
Ruzi --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote: > I agree with all that claimed subsequent triggers > SHOULD not occur. But no matter how you spin it, > it's still a slight possibiltiy. A good programmer > should anticipate that and design/program > accordingly. There are many ways to detect and/or > prevent multiple instances of a program from hanging > in suspense indefinately. Give one of them a shot. > > > -----Original Message----- > > From: Glen Shubert [SMTP:[EMAIL PROTECTED] > > Sent: Friday, April 04, 2003 5:48 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Triggering Z/OS DLQH > CSQUDLQH > > > > > > You may also be getting a 2nd trigger based on > TRIGINT if it is set too low. > > > > Glen Shubert > > Associate Director > > TSYS - MQSeries Technical Support > > > > > > > > [EMAIL PROTECTED] > > Sent by: MQSeries List <[EMAIL PROTECTED]> > > > > 04/03/2003 09:04 PM > > > > Please respond to MQSeries List > > > > > > To: [EMAIL PROTECTED] > > cc: > > Subject: Re: Triggering Z/OS DLQH > CSQUDLQH > > > > Hi Rick > > > > Thankyou for thoughts - I think that could be part > of the explanation. > > Though if the queue manager fires one Trigger > first then the arrival of > > another message on the queue will not trigger the > condition for trigger > > first (that the depth goes from 0 to 1) as the > depth is already > 0 and > > nothing has taken a message off. Unless it is the > fact that during the > > longer CICS start up time the first message has > expired and something has > > caused the queue manager to reset the queue depth > to zero, so it fires off > > another when the next message arrives as IPROCS on > the queue is still zero. > > > > My transaction has a get with WAIT for the next > message to arrive so it > > does not shut down immediately when there is no > message to process. > > Messages arrive every second or so for it to > process. > > > > Alan > > > > > > > > > > Alan Turnbull > > Senior Developer > > QBEMM > > > > Direct: (02) 8275 9880 > > > > > > [EMAIL PROTECTED] > > > > > > |--------+--------------------------------------> > > | | Rick Tsujimoto | > > | | <[EMAIL PROTECTED]| > > | | CANON.COM> | > > | | Sent by: MQSeries List | > > | | <[EMAIL PROTECTED]> | > > | | | > > | | | > > | | 04/04/2003 10:03 AM | > > | | Please respond to MQSeries | > > | | List | > > | | | > > |--------+--------------------------------------> > > > >----------------------------------------------------------------------------------------------------------| > > | > > | > > | To: [EMAIL PROTECTED] > > | > > | cc: > > | > > | Subject: Re: Triggering Z/OS DLQH > CSQUDLQH > | > > > >----------------------------------------------------------------------------------------------------------| > > > > > > > > > > One possibility could be a timing issue. During a > cold start, more > > processing could be occuring vs. a warm start. > Since CKTI is fired from > > the PLTPI, it could have started the first > instance of your triggered > > transaction. If, for some reason, that instance > got hung up, e.g. busy > > system, and didn't have a chance to open the > queue, another trigger message > > could be created if another message arrives in the > interim, causing the > > second instance to be created > > > > My question is, why doesn't your transaction > terminate if it finds nothing > > on the queue? > > > > > > > > > > [EMAIL PROTECTED]> > > EMM.COM.AU To: > > [EMAIL PROTECTED] > > Sent by: cc: > > MQSeries List > Subject: Re: Triggering Z/OS > > DLQH CSQUDLQH > > <[EMAIL PROTECTED] > > en.AC.AT> > > > > > > 04/03/2003 05:39 > > PM > > Please respond > > to MQSeries List > > > > > > > > > > > > Hi > > > > I have once seen this abberrant behaviour of two > trigger FIRST firing in > > CICS - i wonder if anyone can explain why? > > > > My CICS transaction is started by TRIGGER=FIRST on > one queue and once it is > > started it stays alive processing messages that > arrive on the queue. Often > > when CICS starts up there will messages on the > queue and only one instance > > of the transaction is started as expected. > > > > One day the development CICS region crashed > (cancelled by ops) and after a > > cold restart I later saw that I had two instances > of my trigger=first > > transaction running. Both started at virually the > same time when CICS came > > up - nearly consecutive transaction numbers. Both > were processing the same > > queue as the transaction reports what queue it is > started for, and nothing > > else is taking messages off the queue. There would > have been expired and > > expiring messages on the queue, so could this have > caused the queue manager > > to create a additional trigger message? > > > > This is CICS 4.1, MQ 5.2 on OS390 2.6 > > > > Thanks > > Alan > > > > > > > > Alan Turnbull > > Senior Developer > > QBEMM > > > > Direct: (02) 8275 9880 > > > > > > [EMAIL PROTECTED] > > > > > > > === message truncated === Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
