| Author |
Message
|
| hwv |
 Posted: Wed Jul 18, 2012 12:57 am Post subject: z/OS QSG reset qstats not showing correct results |
 |
|
Novice
Joined: 03 Jun 2005
Posts: 19
|
We just migrated from V6.0 to V7.1 on z/Os. We are using QSGs.
When using reset Qstats for a shared Q (for each QM of the QSG) I got the Deq and Enq figures, but when using a ReqRep scenario with putting a message from IMS and getting the message by a listener at the same time, no messages are shown in the Enq or Deq figures. This problem occurs on V7.1 but not on V6.0.
I hope, somebody can help.
Greetings
hwv |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Jul 18, 2012 9:20 pm Post subject: Re: reset qstats not showing correct results |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hwv wrote: |
We just migrated from V6.0 to V7.1 on z/Os. We are using QSGs.
When using reset Qstats for a shared Q (for each QM of the QSG) I got the Deq and Enq figures, but when using a ReqRep scenario with putting a message from IMS and getting the message by a listener at the same time, no messages are shown in the Enq or Deq figures. This problem occurs on V7.1 but not on V6.0.
I hope, somebody can help.
Greetings
hwv |
Be more specific as to your version (including fix pacs).
I suspect the message is being passed in MEMORY and never "hits" the queue. You need to make sure you read the right stats... at the right software level! 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hwv |
| Posted: Thu Jul 19, 2012 12:44 am Post subject: Re: reset qstats not showing correct results |
|
|
Novice
Joined: 03 Jun 2005
Posts: 19
|
Thank you for your reply.
| Quote: |
| Be more specific as to your version (including fix pacs). |
CSQYSCMD - EARLY PROCESSING PROGRAM IS V7.1.0 LEVEL 222
OPMODE=(COMPAT ,710)
| Quote: |
| I suspect the message is being passed in MEMORY and never "hits" the queue. You need to make sure you read the right stats... at the right software level! |
The first application puts a message to a request queue and the second application gets it off the request queue, processes the message and puts the reply onto the reply queue where the first application gets it from the reply queue.
Both queues are shared queues in a queue sharing group. Message length is < 63k, so the messages are held in coupling facility. I have tested one time with persistent queues and another time with non persistent queues, but the results are the same.
What do you mean with "read the right stats... at the right software level!"
Are there different levels of the
RESET QSTATS ? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jul 19, 2012 4:21 am Post subject: Re: reset qstats not showing correct results |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| hwv wrote: |
Both queues are shared queues in a queue sharing group. Message length is < 63k, so the messages are held in coupling facility. |
Are message producer and consumer apps on the same z/OS instance? Are both in the same STGCLASS?
_________________
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 |
|
|
| hwv |
| Posted: Thu Jul 19, 2012 5:19 am Post subject: Re: reset qstats not showing correct results |
|
|
Novice
Joined: 03 Jun 2005
Posts: 19
|
| bruce2359 wrote: |
| Are message producer and consumer apps on the same z/OS instance? Are both in the same STGCLASS? |
For the request message, the message producer is an IMS transaction on z/Os. The consumer is a java application on my pc. For the reply, it's vice versa.
The Queues are on the same Queue Sharing Group.
The storage class isn't relevant, because the CFStruct parameter determines where the message is held.
Here is the DISPLAY QUEUE of the request queue:
| Code: |
DISPLAY Q(TEST.QUEUE.HWV.REQUEST)
CSQN205I COUNT= 3, RETURN=00000000, REASON=00000000
CSQM401I MQBT QUEUE(TEST.QUEUE.HWV.REQUEST) TYPE(QLOCAL) QSGDISP(SHARED) STGCLASS(DEFAULT)
CFSTRUCT(STR001) CLUSTER( ) CLUSNL( ) DESCR(Shared Queue Persistent) PUT(ENABLED) DEFPRTY(0)
DEFPSIST(NO) OPPROCS(0) IPPROCS(0) CURDEPTH(0) MAXDEPTH(999999999) PROCESS( ) NOTRIGGER
MAXMSGL(4194304) BOTHRESH(0) BOQNAME( ) INITQ( ) USAGE(NORMAL) SHARE DEFSOPT(SHARED)
MSGDLVSQ(PRIORITY) RETINTVL(999999999) TRIGTYPE(FIRST) TRIGDPTH(1) TRIGMPRI(0) TRIGDATA( )
DEFTYPE(PREDEFINED) NOHARDENBO CRDATE(2012-07-17) CRTIME(17.45.18) GET(ENABLED) DEFREADA(NO)
DEFPRESP(SYNC) PROPCTL(V6COMPAT) QDEPTHHI(80) QDEPTHLO(40) QDPMAXEV(ENABLED) QDPHIEV(DISABLED)
QDPLOEV(DISABLED) QSVCINT(999999999) QSVCIEV(NONE) INDXTYPE(NONE) ACCTQ(QMGR) MONQ(QMGR)
NPMCLASS(HIGH) DEFBIND(OPEN) CLWLRANK(0) CLWLPRTY(0) CLWLUSEQ(QMGR) TPIPE(TB001093,TB801093)
CUSTOM( ) ALTDATE(2012-07-17) ALTTIME(17.45.18)
|
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jul 19, 2012 6:31 am Post subject: Re: reset qstats not showing correct results |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| hwv wrote: |
The Queues are on the same Queue Sharing Group.
The storage class isn't relevant, because the CFStruct parameter determines where the message is held. |
Yes and no.
Are the IMS instance and WMQ instance in the same z/OS instance? I ask because it is possible that the message never gets propagated to the CF, as fjb_saper suggests. It would make no sense for WMQ to force inbound/outbound message to the CF if the producer and consumer apps can be satisfied with messages from in-memory buffers.
_________________
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 |
|
|
| bruce2359 |
| Posted: Thu Jul 19, 2012 6:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to Mainframe forum.
_________________
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 |
|
|
| hwv |
| Posted: Thu Jul 19, 2012 7:16 am Post subject: Re: reset qstats not showing correct results |
|
|
Novice
Joined: 03 Jun 2005
Posts: 19
|
| bruce2359 wrote: |
Yes and no.
Are the IMS instance and WMQ instance in the same z/OS instance? I ask because it is possible that the message never gets propagated to the CF, as fjb_saper suggests. It would make no sense for WMQ to force inbound/outbound message to the CF if the producer and consumer apps can be satisfied with messages from in-memory buffers. |
Yes, the IMS instance and the WMQ instance are on the same z/OS instance. I didn't know that messages could be dealt solely by in-memory buffers.
I had defined the queues with persistance and hadn't realised that the application puts the messages with non persistance  .
Now I changed the application:
| Code: |
// mp.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
mp.setDeliveryMode(DeliveryMode.PERSISTENT);
|
And guess what, the message count works. 
So I think, I can't rely on "RESET QSTATS" for non persistant messages on WMQ V7.1 when instantely consuming the messages.
Thanx a lot for helping.
Heinz-Willi |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jul 19, 2012 7:27 am Post subject: Re: reset qstats not showing correct results |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| hwv wrote: |
I had defined the queues with persistance and hadn't realised that the application puts the messages with non persistance . |
Queues are neither persistent nor non-persistent.
There is a queue attribute that will set persistence of this message IF the application specifies _PERSISTENCE_AS_Q_DEF (persistence as defined at the queue).
_________________
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 |
|
|
| hwv |
| Posted: Thu Jul 19, 2012 7:40 am Post subject: Re: reset qstats not showing correct results |
|
|
Novice
Joined: 03 Jun 2005
Posts: 19
|
| bruce2359 wrote: |
Queues are neither persistent nor non-persistent.
There is a queue attribute that will set persistence of this message IF the application specifies _PERSISTENCE_AS_Q_DEF (persistence as defined at the queue). |
o.k, more precisely, the queue can be defined on a non recoverable CFStruct.
When I try to put a persistent message on this queue I get a 
| Code: |
| 2048 (0800) (RC2048): MQRC_PERSISTENT_NOT_ALLOWED |
When I try to put a non persistant message on a queue which is defined on a recoverable CFStruct , this is o.k. So, this was what I had done. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jul 19, 2012 8:04 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
WMQ for z/OS shared queues are artifacts of real local queues, and have the same kinds of restrictions. Messages destined for shared queues are propagated (if necessary) to the shared instance in the CF.
A non-recoverable structure behaves pretty much the same thing as a temporary dynamic queue, in that an attempt to put a persistent message would fail with an RC 2048. So, non-persistent messages only.
A recoverable structure allows for both persistent and non-persistent messages - just like permanent dynamic or other real local queues.
_________________
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 |
|
|
|
|
