| Author | Message | 
		
		  | ucbus1 | 
			  
				|  Posted: Fri Aug 03, 2018 1:22 pm    Post subject: |   |  | 
		
		  | Knight
 
 
 Joined: 30 Jan 2002Posts: 560
 
 
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | bruce2359 | 
			  
				|  Posted: Fri Aug 03, 2018 3:05 pm    Post subject: |   |  | 
		
		  |  Poobah
 
 
 Joined: 05 Jan 2008Posts: 9486
 Location: US: west coast, almost. Otherwise, enroute.
 
 | 
			  
				| Is this a new app? 
 Has it worked before?  If it worked before, what has changed?
 
 Does every transaction cause this message delay?  Or just some messages?
 _________________
 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 |  | 
		
		  |  | 
		
		  | ucbus1 | 
			  
				|  Posted: Mon Aug 06, 2018 8:03 am    Post subject: |   |  | 
		
		  | Knight
 
 
 Joined: 30 Jan 2002Posts: 560
 
 
 | 
			  
				| On further investigation noticed we were getting message not found error 2033 even when the put time on the message was  bit old ,showing  that the message was put 10 sec before. This could be a COMMIT issue by the datapower as some of you have suggeted. But the datapower documentation and settings suggest that the COMMIT should have happened immediately after a successful PUT. May open a ticket and see where it leads. if anyone has any further input on the issue please share. |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | bruce2359 | 
			  
				|  Posted: Mon Aug 06, 2018 8:20 am    Post subject: |   |  | 
		
		  |  Poobah
 
 
 Joined: 05 Jan 2008Posts: 9486
 Location: US: west coast, almost. Otherwise, enroute.
 
 | 
			  
				| Run a trace on the affected qmgr to confirm whether an MQCMIT took place or not. _________________
 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 |  | 
		
		  |  | 
		
		  | ucbus1 | 
			  
				|  Posted: Mon Aug 06, 2018 8:44 am    Post subject: |   |  | 
		
		  | Knight
 
 
 Joined: 30 Jan 2002Posts: 560
 
 
 | 
			  
				| 
   
	| bruce2359 wrote: |  
	| Run a trace on the affected qmgr to confirm whether an MQCMIT took place or not. |  
 Thanks. Since this is production queue, will running trace cause any issue?
 How about running dspmqtrn?
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | rammer | 
			  
				|  Posted: Mon Aug 06, 2018 8:55 am    Post subject: |   |  | 
		
		  | Partisan
 
 
 Joined: 02 May 2002Posts: 359
 Location: England
 
 | 
			  
				| 
   
	| ucbus1 wrote: |  
	| 
   
	| bruce2359 wrote: |  
	| Run a trace on the affected qmgr to confirm whether an MQCMIT took place or not. |  
 Thanks. Since this is production queue, will running trace cause any issue?
 How about running dspmqtrn?
 |  
 IBM quote running trace can cause system to slow down but only by milliseconds.   You will only want to put trace on for a minute or so as well due to so much data gathered.  ensure you have plenty of space for storage!  also review the trace options to ensure you pick the right options for your criteria.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | ucbus1 | 
			  
				|  Posted: Mon Aug 06, 2018 9:10 am    Post subject: |   |  | 
		
		  | Knight
 
 
 Joined: 30 Jan 2002Posts: 560
 
 
 | 
			  
				| 
   
	| rammer wrote: |  
	| 
 IBM quote running trace can cause system to slow down but only by milliseconds.   You will only want to put trace on for a minute or so as well due to so much data gathered.  ensure you have plenty of space for storage!  also review the trace options to ensure you pick the right options for your criteria.
 |  
 Thanks
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | bruce2359 | 
			  
				|  Posted: Mon Aug 06, 2018 9:30 am    Post subject: |   |  | 
		
		  |  Poobah
 
 
 Joined: 05 Jan 2008Posts: 9486
 Location: US: west coast, almost. Otherwise, enroute.
 
 | 
			  
				| Tim Zielke should be along any time now. He’s our resident trace guy. _________________
 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 |  | 
		
		  |  | 
		
		  | ucbus1 | 
			  
				|  Posted: Mon Aug 06, 2018 11:26 am    Post subject: |   |  | 
		
		  | Knight
 
 
 Joined: 30 Jan 2002Posts: 560
 
 
 | 
			  
				| 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. 
 From IBM documentation
 "Messages arriving at the receiving MCA are placed on the target application queues under syncpoint control. This means that they are not visible to any receiving applications until the commit is performed. If the batch size is large, messages may not be made available to receiving applications for some time which may have a severe impact on the message throughput of the overall system. Because the batch size is so greatly influenced by the message arrival rate on the transmission queue, it is generally recommended to set the Batchsize quite high"
 
 Could this Batchsize parm is the issue? What is criteria and ideal value to set this Batchsize parameter?
 
 Last edited by ucbus1 on Mon Aug 06, 2018 11:29 am; edited 2 times in total
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | tczielke | 
			  
				|  Posted: Mon Aug 06, 2018 11:27 am    Post subject: |   |  | 
		
		  | Guardian
 
 
 Joined: 08 Jul 2010Posts: 941
 Location: Illinois, USA
 
 | 
			  
				| What platform is this trace being run on? _________________
 Working with MQ since 2010.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | ucbus1 | 
			  
				|  Posted: Mon Aug 06, 2018 11:28 am    Post subject: |   |  | 
		
		  | Knight
 
 
 Joined: 30 Jan 2002Posts: 560
 
 
 | 
			  
				| 
  Z/OS 
	| tczielke wrote: |  
	| What platform is this trace being run on? |  |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | bruce2359 | 
			  
				|  Posted: Mon Aug 06, 2018 12:32 pm    Post subject: |   |  | 
		
		  |  Poobah
 
 
 Joined: 05 Jan 2008Posts: 9486
 Location: US: west coast, almost. Otherwise, enroute.
 
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | tczielke | 
			  
				|  Posted: Mon Aug 06, 2018 12:42 pm    Post subject: |   |  | 
		
		  | Guardian
 
 
 Joined: 08 Jul 2010Posts: 941
 Location: Illinois, USA
 
 | 
			  
				| On z/OS, some of the monitoring tools (e.g. BMC Mainview) have their own API tracing that you can do, as well. _________________
 Working with MQ since 2010.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | ucbus1 | 
			  
				|  Posted: Mon Aug 06, 2018 2:56 pm    Post subject: |   |  | 
		
		  | Knight
 
 
 Joined: 30 Jan 2002Posts: 560
 
 
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | PeterPotkay | 
			  
				|  Posted: Mon Aug 06, 2018 4:25 pm    Post subject: |   |  | 
		
		  |  Poobah
 
 
 Joined: 15 May 2001Posts: 7723
 
 
 | 
			  
				| 
   
	| 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.
 _________________
 Peter Potkay
 Keep Calm and MQ On
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  |  |