|
View previous topic :: View next topic
|
| Author |
Message |
frozenblood
Warnings : 1
New User
Joined: 16 Oct 2012
Posts: 37
Location: INDIA
|
|
|
|
Hi,
We are developing an architecture where we have a static Q.
If a message arrives on the static Q (message is put through a batch job) it triggers a CICS transaction to pickup the message from the same Q call a webservice and put the response from the webservice in a dynamic Q.
In the backgroung the batch program is waiting for a message to arrive on the dynamic q, it abends after waiting for 2mins.
While testing my program what is happening is the CICS transaction is not getting trigerred as soon as the message is put on the Q, it is getting trigerred just after the timeout is reached and the batch program abends.
Is it something that is holding the transaction to get triggered as the batch program isnt closing the Q after the put, it is only doing a MQ commit ?
Any ideas/suggestions would be appreciated
Thanks |
|
| Back to top |
|
 |
sureshpathi10
Active User
Joined: 03 May 2010
Posts: 154
Location: Kuala Lumpur
|
|
|
|
Hi...
is it the same Batch program putting the message and expecting response?
Issue COMMIT/SYNCPOINT right after PUT message and try again. |
|
| Back to top |
|
|
Pandora-Box
Global Moderator
.jpg)
Joined: 07 Sep 2006
Posts: 1592
Location: Andromeda Galaxy
|
|
|
|
Could you show the queue definition?
What kind of trigger have you set?
Also curious what are you trying to do in the batch job?
Handling realtime data in batch is a bad idea |
|
| Back to top |
|
|
frozenblood
Warnings : 1
New User
Joined: 16 Oct 2012
Posts: 37
Location: INDIA
|
|
|
|
| sureshpathi10 wrote: |
Hi...
is it the same Batch program putting the message and expecting response?
Issue COMMIT/SYNCPOINT right after PUT message and try again. |
Yes its the same batch program which is putting the message and expecting the response. After the MQ PUT we issue a COMMIT and then wait for an MQ get. |
|
| Back to top |
|
|
charanmsrit
New User
Joined: 25 Oct 2007
Posts: 81
Location: Australia
|
|
| Back to top |
|
|
frozenblood
Warnings : 1
New User
Joined: 16 Oct 2012
Posts: 37
Location: INDIA
|
|
|
|
Hi Charan,
Below are the options for the mq open (put operation):
MQOO-INPUT-SHARED +
MQOO-OUTPUT +
MQOO-FAIL-IF-QUIESCING +
MQOO-SAVE-ALL-CONTEXT. |
|
| Back to top |
|
|
charanmsrit
New User
Joined: 25 Oct 2007
Posts: 81
Location: Australia
|
|
|
|
| frozenblood wrote: |
Hi Charan,
Below are the options for the mq open (put operation):
MQOO-INPUT-SHARED +
MQOO-OUTPUT +
MQOO-FAIL-IF-QUIESCING +
MQOO-SAVE-ALL-CONTEXT. |
Hi, they are not put message options but open object option used for MQOPEN. What are the MQPMO that you are using? refer to the link i have given which contains detailed information for PMO syncpoint option.
| Quote: |
Syncpoint options. The following options relate to the participation of the MQPUT or MQPUT1 call within a unit of work:
MQPMO_SYNCPOINT
The request is to operate within the normal unit-of-work protocols. The message is not visible outside the unit of work until the unit of work is committed. If the unit of work is backed out, the message is deleted.
If neither this option nor MQPMO_NO_SYNCPOINT is specified, the inclusion of the put request in unit-of-work protocols is determined by the environment running the queue manager and not the environment running the application. On z/OS®, the put request is within a unit of work. In all other environments, the put request is not within a unit of work.
Because of these differences, an application that you want to port must not allow this option to default; specify either MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT explicitly.
Do not specify MQPMO_SYNCPOINT with MQPMO_NO_SYNCPOINT.
MQPMO_NO_SYNCPOINT
The request is to operate outside the normal unit-of-work protocols. The message is available immediately, and it cannot be deleted by backing out a unit of work.
If neither this option nor MQPMO_SYNCPOINT is specified, the inclusion of the put request in unit-of-work protocols is determined by the environment running the queue manager and not the environment running the application. On z/OS, the put request is within a unit of work. In all other environments, the put request is not within a unit of work.
Because of these differences, an application that you want to port must not allow this option to default; specify either MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT explicitly.
Do not specify MQPMO_NO_SYNCPOINT with MQPMO_SYNCPOINT.
|
|
|
| Back to top |
|
|
frozenblood
Warnings : 1
New User
Joined: 16 Oct 2012
Posts: 37
Location: INDIA
|
|
|
|
| charanmsrit wrote: |
| frozenblood wrote: |
Hi Charan,
Below are the options for the mq open (put operation):
MQOO-INPUT-SHARED +
MQOO-OUTPUT +
MQOO-FAIL-IF-QUIESCING +
MQOO-SAVE-ALL-CONTEXT. |
Hi, they are not put message options but open object option used for MQOPEN. What are the MQPMO that you are using? refer to the link i have given which contains detailed information for PMO syncpoint option.
| Quote: |
Syncpoint options. The following options relate to the participation of the MQPUT or MQPUT1 call within a unit of work:
MQPMO_SYNCPOINT
The request is to operate within the normal unit-of-work protocols. The message is not visible outside the unit of work until the unit of work is committed. If the unit of work is backed out, the message is deleted.
If neither this option nor MQPMO_NO_SYNCPOINT is specified, the inclusion of the put request in unit-of-work protocols is determined by the environment running the queue manager and not the environment running the application. On z/OS®, the put request is within a unit of work. In all other environments, the put request is not within a unit of work.
Because of these differences, an application that you want to port must not allow this option to default; specify either MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT explicitly.
Do not specify MQPMO_SYNCPOINT with MQPMO_NO_SYNCPOINT.
MQPMO_NO_SYNCPOINT
The request is to operate outside the normal unit-of-work protocols. The message is available immediately, and it cannot be deleted by backing out a unit of work.
If neither this option nor MQPMO_SYNCPOINT is specified, the inclusion of the put request in unit-of-work protocols is determined by the environment running the queue manager and not the environment running the application. On z/OS, the put request is within a unit of work. In all other environments, the put request is not within a unit of work.
Because of these differences, an application that you want to port must not allow this option to default; specify either MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT explicitly.
Do not specify MQPMO_NO_SYNCPOINT with MQPMO_SYNCPOINT.
|
|
Thanks for the reply charan. But i am a bit confused here currently the MQPMO option being used by me is MQPMO-SYNCPOINT. Do i need to use that ?
On the CICS transaction end i am using the following.
MOVE MQWI-UNLIMITED TO MQGMO-WAITINTERVAL.
COMPUTE MQGMO-OPTIONS = MQGMO-CONVERT
+ MQGMO-SYNCPOINT
+ MQGMO-WAIT +
MQGMO-ACCEPT-TRUNCATED-MSG. |
|
| Back to top |
|
|
|
|
