| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Syncpoint control under CICS trans |
« View previous topic :: View next topic » |
| Author |
Message
|
| SONDAPISSA |
 Posted: Tue Aug 17, 2004 10:37 am Post subject: Syncpoint control under CICS trans |
 |
|
Novice
Joined: 27 Apr 2004
Posts: 14
Location: México
|
Hi all 
We have MQ 5.2 for Z/os on mainframe, also CICS TS 1.3, and use the MQSeries Adapter for CICS, but not use the trigger monitor.
We "duplicate" the logic of CKTI with other transaction(cics-cobol), this use a MQGet with browse option for validation propouse and start other transaction for process the message data.
The second appls(also cics-cobol) use a MQGET with NO_SYNCPOINT option and do CICS SYNC, but when an error occurs the appls backout the message to the income queue.
The questions is: Why the message is backed out to the income queue, if use the correct options
I know, the default for cics-cobol apps with MQ calls is SYNCPOINT on get's or put's.
The message's are not persistance, because we don't want recover the message-data, if an error occurs.
thanks all in advise
_________________
Julio Cuevas Rocha
MQSeries Installation and Configuration Certified
MQSeries Solution Expert Certified |
|
| Back to top |
|
 |
| EgilsJ.Rubenis |
| Posted: Tue Aug 17, 2004 11:42 pm Post subject: |
|
|
Acolyte
Joined: 18 Nov 2002
Posts: 63
Location: Germany, Alfeld
|
Hi Julio,
your problem you described is handeled propperly. If the CicsTxn dumps or is canceld the message is not processed propperly and moved back to the inQueue. Thats the way it should be. Is the message moved back if the CicsTxn processes the message and sets a CicsSync ?
What Do you mean by "an error occurs". Is it a logical error what you mean? If so you could take the message and put it to a specified trash Queue, so its burned (no persitance, timoeut minimum).
I'm working with CicsBridge. Every CicsTxn is sending a reply message that I'm processing. Then i'm deciding what to do.
cheers, Egils |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Wed Aug 18, 2004 12:30 am Post subject: Re: Syncpoint control under CICS trans |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| SONDAPISSA wrote: |
We "duplicate" the logic of CKTI with other transaction(cics-cobol), this use a MQGet with browse option for validation propouse and start other transaction for process the message data.
|
You are not duplicating CKTI logic. CKTI does destructive reads of trigger messages from the InitQ, it does not browse the queue.
| Quote: |
The second appls(also cics-cobol) use a MQGET with NO_SYNCPOINT option and do CICS SYNC, but when an error occurs the appls backout the message to the income queue. |
Double check your application logic - it sounds as if the the NO_SYNCPOINT options is not being passed correctly on your MQGET
| Quote: |
The message's are not persistance, because we don't want recover the message-data, if an error occurs.
|
Browse based dispatchers are difficult to get right because they can miss messages that appear on the queue 'behind' the browse cursor, this can occur from put of higher priority messages, slow put commit, get rollback.
If your message length is less then 32K you could do destructive gets in your dispatcher and pass the data to your second application on the CICS start. This would save the need for MQOPEN/GET/CLOSE in the application and improve performance.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| SONDAPISSA |
| Posted: Wed Aug 18, 2004 7:43 am Post subject: |
|
|
Novice
Joined: 27 Apr 2004
Posts: 14
Location: México
|
thanks Egils and Bob
I go to check my appls and NO_SINCPOINT options
_________________
Julio Cuevas Rocha
MQSeries Installation and Configuration Certified
MQSeries Solution Expert Certified |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
