Author |
Message
|
PeterPotkay |
Posted: Mon Aug 06, 2018 4:28 pm Post subject: |
|
|
![](images/avatars/c7de043e3ce24eaa279a5.gif) Poobah
Joined: 15 May 2001 Posts: 7716
|
ucbus1 wrote: |
few more updates on the application.
1.mainframe puts a request on a queue.
2. Datapower's front side handler takes the message and hands it over to a back end process via Multi protocol gateway (MPGW)
3. The response from back end process is received by the Datapower and the response is put on the mainframe response queue .The response queue is indexed on correlation id. Mainframe picks up the message using correlation id
4. The front side handlers of the datapower use "units of work"="1" on MQ queue manager object. I believe this setting should make messages put by datapower on COMMIT.
While getting the message from mainframe, datapower does not encounter any timeout issues. However when the response is sent by datapower, mainframe is timing out on Getting the message.
@belchman, I will try to get more info and provide the input |
Are you 1000% sure DataPower is setting the Correlation ID to the value the mainframe app expects for the reply message? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
PeterPotkay |
Posted: Mon Aug 06, 2018 4:31 pm Post subject: |
|
|
![](images/avatars/c7de043e3ce24eaa279a5.gif) Poobah
Joined: 15 May 2001 Posts: 7716
|
gbaddeley wrote: |
2 secs is quite a short WaitInterval, for any MQ interface. Try increasing it to 60 secs to make it easier to diagnose. |
For a mainframe IMS application a short get with wait is not odd in my experience. Otherwise you have IMS TCODEs blocking and waiting.....and waiting.....and waiting for the MQGET that will just 2033 eventually anyway. Oh do the MVS ancients get ornery when that happens. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Mon Aug 06, 2018 5:20 pm Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9405 Location: US: west coast, almost. Otherwise, enroute.
|
PeterPotkay wrote: |
ucbus1 wrote: |
On a different thought. could this be due to low batcsz parameter cluster receiver channel. It is currently set to 50 which I believe is default.
Could this Batchsize parm is the issue? What is criteria and ideal value to set this Batchsize parameter? |
Probably not the issue unless BATCHINT is also high and there is very little traffic on the channel, causing it to wait until BATCH INTERVAL or BATCH SIZE is met. |
What is batchinterval for the the cluster-receiver channel? It is the cluster-receiver channel def that is used to create a CLUSSDRA/B cluster sender channel. The default is zero. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
ucbus1 |
Posted: Wed Aug 08, 2018 5:16 am Post subject: |
|
|
Knight
Joined: 30 Jan 2002 Posts: 560
|
The batch interval on the channel is set to ZERO and the batch size is set to "50", I am thinking of suggesting to change to a lower value if it is going to help. How this needs to be tested. Does running dspmqtrn before making the change and after making the change help to identify lag in commits? Please let me know. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Aug 08, 2018 5:31 am Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9405 Location: US: west coast, almost. Otherwise, enroute.
|
ucbus1 wrote: |
The batch interval on the channel is set to ZERO and the batch size is set to "50", I am thinking of suggesting to change to a lower value if it is going to help. How this needs to be tested. Does running dspmqtrn before making the change and after making the change help to identify lag in commits? Please let me know. |
Please be precise. Which channel? What type of channel? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
ucbus1 |
Posted: Wed Aug 08, 2018 8:50 am Post subject: |
|
|
Knight
Joined: 30 Jan 2002 Posts: 560
|
Here are the details:
Code: |
CHLTYPE(CLUSRCVR) QSGDISP(QMGR) CLUSTER(xxx-xxx-xxx) CLUSNL() TRPTYPE(TCP) CONNAME(XXXX(4005))
DESCR() MODENAME() TPNAME() DISCINT(6000) SHORTRTY(10) SHORTTMR(60) LONGRTY( 999999999) LONGTMR(1200)
SCYEXIT() SCYDATA() MSGEXIT() MSGDATA() SENDEXIT() SENDDATA() RCVEXIT() RCVDATA()
MREXIT() MRRTY(0) MRTMR(1000) PROPCTL(COMPAT) PUTAUT(DEF) SEQWRAP( 999999999) CONVERT(NO) BATCHINT(0)
BATCHHB(0) KAINT(AUTO) NETPRTY(0) CLWLRANK(0) CLWLPRTY(0) CLWLWGHT(50) MCATYPE(THREAD) MONCHL(QMGR)
ALTDATE(xxxx-xx-xx) ALTTIME(xx.xx.xx) SSLCAUTH(REQUIRED ) SSLCIPH() SSLPEER()
CERTLABL() BATCHLIM(5000) USEDLQ(YES) STATCHL(QMGR) MCAUSER() LOCLADDR() BATCHSZ(50)
MAXMSGL( 20971520) COMPHDR(NONE) COMPMSG(NONE) HBINT(300) NPMSPEED(FAST) |
|
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Aug 08, 2018 12:37 pm Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9405 Location: US: west coast, almost. Otherwise, enroute.
|
ucbus1 wrote: |
The batch interval on the channel is set to ZERO and the batch size is set to "50" |
Good so far.
ucbus1 wrote: |
I am thinking of suggesting to change to a lower value if it is going to help. |
It won't. Batchinterval of zero tells the channel to transmit messages as they arrive committed into the transmission queue, and NOT to wait for other messages to complete a batch. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
ucbus1 |
Posted: Wed Aug 08, 2018 12:46 pm Post subject: |
|
|
Knight
Joined: 30 Jan 2002 Posts: 560
|
bruce2359 wrote: |
ucbus1 wrote: |
The batch interval on the channel is set to ZERO and the batch size is set to "50" |
Good so far.
ucbus1 wrote: |
I am thinking of suggesting to change to a lower value if it is going to help. |
It won't. Batchinterval of zero tells the channel to transmit messages as they arrive committed into the transmission queue, and NOT to wait for other messages to complete a batch. |
Hmm. This is different from what I have noted on the documentation. https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.ref.con.doc/q081700_.htm
Quote: |
You can specify any number of milliseconds, from zero through 999 999 999. The default value is zero.
If you do not specify a batch interval, the batch closes when the number of messages specified in BATCHSZ has been sent or when the transmission queue becomes empty. On lightly loaded channels, where the transmission queue frequently becomes empty the effective batch size might be much smaller than BATCHSZ.
|
Since BATCHINT is zero, doesn't the batch close when the number of messages specified in BATCHSZ has been sent, in this case "50"? I am confused. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Aug 08, 2018 1:01 pm Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9405 Location: US: west coast, almost. Otherwise, enroute.
|
ucbus1 wrote: |
Since BATCHINT is zero, doesn't the batch close when the number of messages specified in BATCHSZ has been sent, in this case "50"? I am confused. |
No.
You missed the big Note
Quote: |
BATCHINT specifies the total amount of time that is spent waiting for messages. It does not include the time spent retrieving messages that are already available on the transmission queue, or the time spent transferring messages. |
Quote: |
Batch interval (BATCHINT)
This attribute is a period, in milliseconds, during which the channel keeps a batch open even if there are no messages on the transmission queue. |
Thus, zero batchinterval effectively tells the sender end of the channel to wait zero milliseconds to close (and send) the batch. In short, send the batch now, don't wait for any other messages to arrive. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
ucbus1 |
Posted: Wed Aug 08, 2018 1:28 pm Post subject: |
|
|
Knight
Joined: 30 Jan 2002 Posts: 560
|
I think I am getting confused with BATCHINT and BATCHSZ parameters.
I have been reviewing the threads on this forum:
http://www.mqseries.net/phpBB/viewtopic.php?t=25986
Quote: |
Highest speed - batchint 0 batchsz 1 - but every message is committed.
High speed - batchint 0 batchsz xxx - which means if there is a (little) message queueing on the xmitq xxx messages are transfered (committed) in one go. this will save some commits and so some cpu. if there is no queueing on the xmit when using batchsz 0 then this setting has no effekt (except on errors where messages pile up and similiar). |
In my case, we find the response messages sent by sending app ( datapower) were not being available for the receiver app( mainframe) and wonder if Commits were not happening immediately after PUT and thought BATCHINt and BATCHSZ parameters were the issue. So BATCHINT=0 dictates the COMMITs to happen instantaneously and BATCHSZ parameter only helps in reducing how frequently the COMMITS are happening.
It appears like I am back to square one. ![](images/smiles/icon_frown.gif) |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
exerk |
Posted: Wed Aug 08, 2018 1:41 pm Post subject: |
|
|
![](images/avatars/148480827754327ad624e20.jpg) Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
ucbus1 wrote: |
...So BATCHINT=0 dictates the COMMITs to happen instantaneously and BATCHSZ parameter only helps in reducing how frequently the COMMITS are happening.
It appears like I am back to square one. ![](images/smiles/icon_frown.gif) |
Neither of those settings will affect whether or when the application commits messages, they only affect the transmission of messages on the XMITQ that are available to be transmitted, i.e. messages that an application has put on the XMITQ and committed. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Aug 08, 2018 4:20 pm Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9405 Location: US: west coast, almost. Otherwise, enroute.
|
To eliminate MQ channel as the source of the delay, use amqsput to put msgs to another cluster queue on the same qmgr. I’d expect sub-second across the channel. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Aug 08, 2018 4:52 pm Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9405 Location: US: west coast, almost. Otherwise, enroute.
|
When this odd behavior next occurs, DISPLAY CHATATUS for the affected channel. Display CURRENT and SAVED. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
PeterPotkay |
Posted: Wed Aug 08, 2018 7:40 pm Post subject: |
|
|
![](images/avatars/c7de043e3ce24eaa279a5.gif) Poobah
Joined: 15 May 2001 Posts: 7716
|
ucbus1 wrote: |
bruce2359 wrote: |
ucbus1 wrote: |
The batch interval on the channel is set to ZERO and the batch size is set to "50" |
Good so far.
ucbus1 wrote: |
I am thinking of suggesting to change to a lower value if it is going to help. |
It won't. Batchinterval of zero tells the channel to transmit messages as they arrive committed into the transmission queue, and NOT to wait for other messages to complete a batch. |
Hmm. This is different from what I have noted on the documentation. https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.ref.con.doc/q081700_.htm
Quote: |
You can specify any number of milliseconds, from zero through 999 999 999. The default value is zero.
If you do not specify a batch interval, the batch closes when the number of messages specified in BATCHSZ has been sent or when the transmission queue becomes empty. On lightly loaded channels, where the transmission queue frequently becomes empty the effective batch size might be much smaller than BATCHSZ.
|
Since BATCHINT is zero, doesn't the batch close when the number of messages specified in BATCHSZ has been sent, in this case "50"? I am confused. |
BATCHSZ is 50.
BATCHINT is 0.
10 message arrive and are sent, the transmit queue depth becomes zero, the batch is committed and th e10 messages are available right away. Its not going to wait to get to 50. Actually it does wait. It waits exactly BATCHINT seconds, and if that is set to zero seconds.... _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
PeterPotkay |
Posted: Wed Aug 08, 2018 7:42 pm Post subject: |
|
|
![](images/avatars/c7de043e3ce24eaa279a5.gif) Poobah
Joined: 15 May 2001 Posts: 7716
|
ucbus1 wrote: |
few more updates on the application.
1.mainframe puts a request on a queue.
2. Datapower's front side handler takes the message and hands it over to a back end process via Multi protocol gateway (MPGW)
3. The response from back end process is received by the Datapower and the response is put on the mainframe response queue .The response queue is indexed on correlation id. Mainframe picks up the message using correlation id
4. The front side handlers of the datapower use "units of work"="1" on MQ queue manager object. I believe this setting should make messages put by datapower on COMMIT.
While getting the message from mainframe, datapower does not encounter any timeout issues. However when the response is sent by datapower, mainframe is timing out on Getting the message.
@belchman, I will try to get more info and provide the input |
Are you 1000% sure DataPower is setting the Correlation ID to the value the mainframe app expects for the reply message?
How do you know? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
|