I am new to Cics and MQ i am trying to get the message from one MQ and writing to a File,I know to get the record from the Mq need to give a Call statement to get the record.
Suppose if there is some 10 records in the Queue and i need to read the queue 10 times to get the 10 records.
So if 10 calls can i give the call in a loop some thing till end of Queue .
and how to check it is the end of queue what response code will i get if it reaches the end of queue.
Please let me know if more information needed
First, do NOT use queue-depth to determine the number of records on a queue. This is not reliable as messages may arrive or expire after you enquire on depth. Also, expired messages contribute to queue-depth for a time after expiry.
The appropriate way to process all messages is to MQGET in a loop until MQ returns MQCC_FAIL with MQRC_NO_MSG_AVAILABLE (REASON=2033). Of course, more messages can arrive on the queue after this, so how will your process those?
A lot depends on what you are trying to achieve in your application, whether messages are "grouped" in MQ terms, whether you are using triggering &c.
It seems a little unusual to use CICS to process multiple MQ messages just to move them to a file - this can easily be done in a batch program.
Thanks for your replay ,the initial req: was to write the java pgm which wil handle the MQ but now they want it to be run by a Cics transaction .
Once the MQ gets the data we need to trigger the pgm to get the msg and write to a file..So if we run a batch pgm how to start the pgm once the message hits the queue
if we run a batch pgm how to start the pgm once the message hits the queue
You would need a trigger-monitor program running. It's probably easier to use the CICS trigger monitor. Now, the code will depend on how you set up triggering. If you have TRIGGER=EVERY, each message runs a separate CICS transaction, so you don't want to loop until MQRC_NO_MESSAGE_AVAILABLE. In fact, MQRC_NO_MESSAGE_AVAILABLE shouldn't happen as the message that caused the trigger event is present on the queue.
If the messages are arriving in batches of (say) 10, you could have TRIGGER=DEPTH so that you process 10 messages at a time.
If you are using TRIGGER=FIRST to start a long-running process, can I suggest you have a long WaitInterval? In times of low volume this reduces the number of MQGETs issued where no message is available, which helps reduce cpu utilisation.
Joined: 17 Aug 2007 Posts: 562 Location: Iowa, USA
You need a "trigger monitor" program.
1. Your data queue can have an associated initiation queue.
2. Based on your trigger definition (first msg, 10 msgs, etc) the QMGR puts a message in the init.queue
3. The trigger monitor waits for something to hit the init.queue and then starts the processing program, usually by issuing an MVS command.
CICS has a trigger monitor already built in so it's easier to use that than write or buy another one for batch.
Joined: 20 Oct 2006 Posts: 6970 Location: porcelain throne
just because you don't know how to do something is not a reason to jimmy-rig or overuse a resource. - cics in this place.
mq triggers work, but they have to be monitored to insure that they continue to function.
writing a permenant running batch job is also a solution.
the job would be started as a Started Task.
the program does an MQ receive message with a time/wait interval of a minute or so. either the recieve provides a message - in which case you process the message - or you get a no message response.
whether you received a message or not, you would then check on operator messages like STOP, in which case you would STOP RUN (after processing the que item). Make it a distructive read. If you are updating/inserting into db2, you need rrsaf. Make periodic commits.
if you have a lot of messages (more than 1,000,000/hr) might want to have two or more of these started tasks hanging on the que.
You mentioned writing to a file - vsam hopefully (not qsam). With the correct share options, you could have many started tasks reading the que and writing messages to the 'file'. (Yet another reason to join the 21st century and use db2).
CICS is an extremely good, fast, reliable application. but it was designed to do online transaction processing, not to be a catch-all for batch projects that could not be developed due to lack of experience/fore-thought.
I know of a large bank in germany that communicates via MQS between an z/os mainframe and a unix box running SAP-3 AP, 4+ million trans/hour, all thru this started task. Fortunately the techies at the bank would not allow such a poor use of cics facilites for this process and the project was developed as batch.