I have a requirement as below
1) MF appl.(uses IMS database) PUTS msg to a request Queue
2) JAVA appl. reads request Queue and PUTS a response to reply Queue.
3) MF appl has to GET the msg from reply Queue and do further processing.
As part of my testing, I would like to test option (3). Hence modified my program and then,
a) I am issuing a PUT call to store the test msg in the reply Queue with 'Datagram' message type.
b) After certain period of wait time, I am issuing a GET call to retreive the msg from the reply Queue.
At the step (b), I am receiving the 2033 (MQRC_NO_MSG_AVAILABLE) reason code, with COMP CODE=2. The reason code and COMP COde for step (a) are zeroes.
As mentioned, the MQGET call is returning 2033 (MQRC_NO_MSG_AVAILABLE).
When googled, I found that the NO-SYNCPOINT is used to operate outside the unit of work. So, I have tried MQCMIT and then issued PUT(with MQPMO-SYNCPOINT option) and GET(with MQGMO-SYNCPOINT option). This issued reason code 2012- MQRC_ENVIRONMENT_ERROR.
MQCMIT call:
Code:
CALL 'MQCMIT' USING WS-CONN-HDL
WS-COMPCODE
WS-REASON
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
not even going to try to debug your code.
but i will say:
you have an outbound queue (from MF to JAVA)
you have an inbound queue (from JAVA to MF)
from mf perspective:
i would not have the same program
writing to the outbound queue
waiting
reading the inbound queue
this should consist of 2 separate tasks:
one to write messages to outbound
one to read inbound and process the messages.
(that means a minimum of two modules.)
do not expect msg-1 to be returned before msg-2.
your second task (program) must be able to process a message
without anticipating - thinking you know what message is coming.
for testing
you can store messages in a qsam file,
and then using mqsutil, populate the queue - which in turn would initiate task 2.
regardless of cics or batch - this is a two thread process,
you have two separate processes (tasks)
1. access ims, formulate msg, write outbound message.
2. read inbound message, process message
both processes need to be independent of one another,
and never have task 2 thinking it knows what is going to be on the inbound queue.
again, test data should be generated and stored in qsam file
which can be used via mqsutil to populate the inbound queue to test process 2.
doing so, enables you to test at will, and repeatedly.
i would suggest reading the mqs documentation which explains how mqs works,
and how to design processes utilizing mqs to communicate with one another.