| Author |
Message
|
| mq_series |
 Posted: Mon Nov 04, 2002 8:53 pm Post subject: MQSeries VS IMS |
 |
|
Apprentice
Joined: 29 Oct 2001
Posts: 30
|
Hi,
I am good in MQSeries but new to mainframe,COBOL and IMS.I am working on a problem a brief description is as follows.
Inbound messages from a mqseries on win NT are coming on a MQSI hub , The hub routes these messages to mainframe mqseries where these messages are to be processed and replied back to hub with the results obtained from IMS database.This is going to be an online web application.
Please correct me where I am wrong.In my cobol program I am going like this
1) GU call to read the trigger message
2) From trigger msg I will come to know of QMgr and Queue name.
3) MQConn to connect to QMGR
4) MQOPEN in syncpoint + inquire+fail if quiescing option
5) MQGet
6) Process the message(By calling another IMS application)
7) MQPUT (syncpoint )
 MQCLOSE
9) MQDISC
10) GO TO STEP 1 above till there are more trigger message
Now in this case after looking at a sample code based on which I have written above program.It seems that for each incoming message there will be one trigger message. Am I correct in thinking so ?
If any mQCall fails then I am using CHNG and ISRT (Trigger Msg).
Since MQGET and MQPUT are in syncpoint mode how these will be committed or rolled back.Do I need to do anything extra to make the changes committed/rollback.
Please give ur comments and suggest any other better alternative.
Regards
RKV |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Nov 07, 2002 6:06 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
With this code, yes, you will get one trigger message for every MQ message llanding on the queue, because you are closing the queue after only getting one message. If there are any other message on the queue at this point, asuuming Trigger OnFirst, the QM will generate one more trigger message. This behaviour will continue until the queue is empty at MQCLOSE. Message are commited on the MQDISC with this code. Kinda of ineffecient, because of the constant retriggering.
Your code would be better like this:
1) GU call to read the trigger message
2) From trigger msg I will come to know of QMgr and Queue name.
3) MQConn to connect to QMGR
4) MQOPEN fail if quiescing, input options only (syncpoint is a GET/PUT option; inquire is not needed)
5) MQGet (syncpoint yes option) (check MQMD_Backout Count after each GET to make sure you don't have a poisened message loop)
6) Process the message(By calling another IMS application)
7) MQPUT (syncpoint )
Everything good? The Commit, else Rollback.
9) Go to Step 5 until no more messages.
10) MQCLOSE
11) MQDISC
12) end program and wait to be retriggered
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mq_series |
| Posted: Fri Nov 08, 2002 12:24 am Post subject: |
|
|
Apprentice
Joined: 29 Oct 2001
Posts: 30
|
Thank You very much for your kindness Boss.
Regards
Rajeev |
|
| Back to top |
|
|
| gwlfng |
| Posted: Tue Nov 19, 2002 5:57 pm Post subject: |
|
|
Newbie
Joined: 13 Nov 2002
Posts: 8
Location: Boston
|
| In IMS (an MPP program), the MQ connection handle drops (an implicit disconnect) at each IMS commit point. The natural IMS commit point is at each GU to the IO-PCB. You can't use MQCommit here, IMS has got to drive. I don't know if an explicit commit via IMS CKPT will drop the connection handle as well (probaly does). If it's ok to do multiple messages in a single unit of work, then 1 connect - 1 open - many gets works ok, but you don't want a long-running MPP, especially if you have a single message region. IMS/DC doesn't really bring out the most for MQ efficiency. These issues are reasons to consider the OTMA Bridge. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 20, 2002 6:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
gwlfng is correct. Issuing the IMS calls to commit or backout would kill your QM and Q handles. Forgot about that.
If you want to do the GETs and PUTs under syncpoint, they will not get committed until your app ends and IMS then commits. If this is the case, you probably want to do one GET/PUT per instance of being triggered. Each GET/PT will be its own unit of work. If there are more messages on the queue when you go to close, you will get retriggered over and over until you flush the queue. Inefficient, but it will allow you to accomplish what you want.
You could do more than one GET/PUT under syncpoint, but now you are holding back messages based on whether subsequent messages work, which may not make business sense.
The other option of course is to remove the syncpoints and then you can loop on the queue all you want.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mktgurutsm |
| Posted: Fri Dec 03, 2004 9:13 am Post subject: How does OTMA alleviate this? |
|
|
Novice
Joined: 08 Jan 2004
Posts: 21
Location: New York
|
Peter - how does using the OTMA IMS bridge alleviate these IMS MQ connect/disconnect issues?
Our processing is very much as described earlier in this post:
1) GU call to read the trigger message
2) From trigger msg I will come to know of QMgr and Queue name.
3) MQConn to connect to QMGR
4) MQOPEN in syncpoint + inquire+fail if quiescing option
5) MQGet
6) Process the message(By calling another IMS application)
7) MQPUT (syncpoint )
MQCLOSE
9) MQDISC
10) GO TO STEP 1 above till there are more trigger message
The MQPUT (under syncpoint control) apparently forces an MQ Close and Disconnect. My question is (I hope you or someone can answer it), how does using the OTMA IMS bridge alleviate this? If we use the OTMA IMS bridge instead of the BMP IMS MQ trigger monitor which triggers the IMS transaction that does the MQ GET and PUT processing, how would OTMA alleviate the excessive MQ Close and Disconnect calls when under syncpoint control. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 03, 2004 12:39 pm Post subject: Re: How does OTMA alleviate this? |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mktgurutsm wrote: |
| The MQPUT (under syncpoint control) apparently forces an MQ Close and Disconnect. |
Not true. An MQPUT does not force a close or disconnect, whether it has syncpoint coded or not. Your app closes and disconnects. Change the logic in your code if you don't want to close and disconnect after the MQPUT.
OK, I suppose if the MQPUT abends, you would get disconnected as your program bombed.
The OTMA bridge connects to the QM and opens up the queue exclusivly for as long as it is up. As messages land in the MQ queue, it picks them up, passes them off to IMS, and then goes back to waiting on the queue. It is not closing and disconnecting constantly.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mktgurutsm |
| Posted: Fri Dec 03, 2004 1:27 pm Post subject: Does MQPUT to GU force syncpoint |
|
|
Novice
Joined: 08 Jan 2004
Posts: 21
Location: New York
|
| Peter - Our application programmer states they are not issuing a commit or close or disconnect. They go from an MQPUT back to an IMS GU. When this happens, does it force a syncpoint, commit, MQ Close, and disconnect? - or any combination of? Thank You |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 03, 2004 1:51 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Check out the details in the App Programming guide for MQ (doc button top right) on how an IMS program behaves in regards to closes, disconnects, commits, etc depending on whether it ends cleanly or abnormally.
The app should explicitly close the queue and disconnect if it is done using the MQ queue. If it is going to go back to issue an IMS GU call, I am not sure what will happen to open MQ queues and connected QMs. Here, we always clean up after ourselves in regards to MQ before going back to the IMS queue for the next IMS message.
Obviously in batch this is not the way we do it, we keep the queue open and drain it, just like the OTMA does it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mktgurutsm |
| Posted: Wed Jan 26, 2005 6:02 am Post subject: Question on Batch IMS MQ |
|
|
Novice
Joined: 08 Jan 2004
Posts: 21
Location: New York
|
Peter - You wrote
"Obviously in batch this is not the way we do it, we keep the queue open and drain it, just like the OTMA does it."
Are you referring to a BMP? If so, how is this avoided by using a BMP. I'm trying to find information on this because we recommended the app use a BMP and it is still forcing the MQ Close / Disconnect each time it goes to the IMS Queue and does a GU. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 26, 2005 6:43 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Our batch jobs are not BMPs. As such, they are not under control of the IMS control region, and thus are not restricted by those rules. If you batch job is a BMP, then I assume it is more like a regular IMS online app when it comes to keeping an MQ queue open across transactions, i.e. it ain't happenin'.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
