ENDDATA in RETRIEVE in the transaction started by CKTI

[Irina Yagudayeva]

Hello,
We have a CICS transaction which is being triggered from several Queues (zOS
environment).
From time to time we are getting ENDDATA condition in RETRIEVE command
issued in this transaction to get the Queue Name which triggers this
transaction. I browsed all possible causes of this condition in CICS manual and
don't see any of them fit our case. Did anybody else run into the same issue?
Any thoughts why and in what circumstances this could happen?
Thanks a lot.
Irina

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Wittenborn, Jack (DES)]

I have had this same issue, It has to do with the speed at which MQ triggers and CICS process messages.
I have a trigger event with several messages, The CICS program is removing the messages when another message comes in and triggers the process, but the CICS program has removed the message already and there is no data available. So it looks like an end of data condition because you can't figure out what triggered the queue.




Jack Wittenborn
Department of Enterprise Services (DES)
Enterprise Integration Services
1500 Jefferson Street
PO Box 41433
Olympia, WA 98504-1433
[phone]
Jack.Wittenborn-***@public.gmane.org



-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Irina Yagudayeva
Sent: Friday, April 04, 2014 12:08 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: ENDDATA in RETRIEVE in the transaction started by CKTI

Hello,
We have a CICS transaction which is being triggered from several Queues (zOS environment).
From time to time we are getting ENDDATA condition in RETRIEVE command issued in this transaction to get the Queue Name which triggers this transaction. I browsed all possible causes of this condition in CICS manual and don't see any of them fit our case. Did anybody else run into the same issue?
Any thoughts why and in what circumstances this could happen?
Thanks a lot.
Irina

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Misichko, Pamela]

If you have trigger set to every then there is one trigger for every message. Now if the CICS application program is coded to read another message from the queue when it finishes processing the first message and it finds another message, then you will have extra trigger messages.

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Wittenborn, Jack (DES)
Sent: Friday, April 04, 2014 3:49 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: ENDDATA in RETRIEVE in the transaction started by CKTI

I have had this same issue, It has to do with the speed at which MQ triggers and CICS process messages.
I have a trigger event with several messages, The CICS program is removing the messages when another message comes in and triggers the process, but the CICS program has removed the message already and there is no data available. So it looks like an end of data condition because you can't figure out what triggered the queue.




Jack Wittenborn
Department of Enterprise Services (DES)
Enterprise Integration Services
1500 Jefferson Street
PO Box 41433
Olympia, WA 98504-1433
[phone]
Jack.Wittenborn-***@public.gmane.org



-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Irina Yagudayeva
Sent: Friday, April 04, 2014 12:08 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: ENDDATA in RETRIEVE in the transaction started by CKTI

Hello,
We have a CICS transaction which is being triggered from several Queues (zOS environment).
From time to time we are getting ENDDATA condition in RETRIEVE command issued in this transaction to get the Queue Name which triggers this transaction. I browsed all possible causes of this condition in CICS manual and don't see any of them fit our case. Did anybody else run into the same issue?
Any thoughts why and in what circumstances this could happen?
Thanks a lot.
Irina

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Jantje .]

On Fri, 4 Apr 2014 21:07:38 +0200, Irina Yagudayeva

Post by Irina Yagudayeva
Hello,
We have a CICS transaction which is being triggered from several Queues

(zOS

Post by Irina Yagudayeva
environment).
From time to time we are getting ENDDATA condition in RETRIEVE command
issued in this transaction to get the Queue Name which triggers this
transaction.

Are you saying that the E C RETRIEVE (which should give you the name of te
queue that caused the trigger, amongs other info) is giving a CICS condition of
ENDDATA ? I have never seen that...

Like others have indicated, there are many possibilities for the MQ message
that caused the trigger to not be there when the programs come to run, but in
any case, you really ought to get a decent result on the E C RETRIEVE. If the
latter is not so, then I suggest you call IBM.

Cheers,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES