| Author |
Message
|
| sid008 |
 Posted: Tue Nov 20, 2012 3:09 am Post subject: How to clear transmission queue |
 |
|
Newbie
Joined: 13 Nov 2012
Posts: 6
|
Hi guys
I am trying to clear the transmission queue but can't seem to be able to
clear qlocal(REMOTE.LOCAL.XMITQ)
29 : clear qlocal(REMOTE.LOCAL.XMITQ)
AMQ8143: WebSphere MQ queue not empty.
I have stopped the channels, cleared down the DL queue
As you can see the CURDEPTH shows as (0). Someone suggested it might have something to do with OPPROCS but that is also (0)
| Code: |
AMQ8409: Display Queue details.
QUEUE(REMOTE.LOCAL.XMITQ) TYPE(QLOCAL)
ACCTQ(QMGR) ALTDATE(2012-11-20)
ALTTIME(10.37.41) BOQNAME( )
BOTHRESH(0) CLUSNL( )
CLUSTER( ) CLWLPRTY(0)
CLWLRANK(0) CLWLUSEQ(QMGR)
CRDATE(2011-04-08) CRTIME(14.40.56)
CURDEPTH(0) DEFBIND(OPEN)
DEFPRTY(0) DEFPSIST(NO)
DEFSOPT(SHARED) DEFTYPE(PREDEFINED)
DESCR(Transmition queue to REMOTE)
DISTL(YES) GET(DISABLED)
HARDENBO INITQ(SYSTEM.CHANNEL.INITQ)
IPPROCS(0) MAXDEPTH(5000)
MAXMSGL(4194304) MONQ(QMGR)
MSGDLVSQ(PRIORITY) NOTRIGGER
NPMCLASS(NORMAL) OPPROCS(0)
PROCESS( ) PUT(ENABLED)
QDEPTHHI(80) QDEPTHLO(20)
QDPHIEV(DISABLED) QDPLOEV(DISABLED)
QDPMAXEV(ENABLED) QSVCIEV(NONE)
QSVCINT(999999999) RETINTVL(999999999)
SCOPE(QMGR) SHARE
STATQ(QMGR) TRIGDATA(REMOTE.LOCAL.QMGR)
TRIGDPTH(1) TRIGMPRI(0)
TRIGTYPE(FIRST) USAGE(XMITQ)
|
Any suggestions.
Oh and the reason I am doing this is; I was trying to send messages from one LOCAL QMGR to a REMOTE QMGR, getting an error message
| Quote: |
AMQ9506: Message receipt confirmation failed.
EXPLANATION:
Channel 'REMOTE.LOCAL.QMGR' has ended because the remote queue manager did not
accept the last batch of messages.
ACTION:
The error log for the channel at the remote site will contain an explanation of
the failure. Contact the remote Systems Administrator to resolve the problem. |
Someone suggested I should clear XMITQ as there might be pending messages stuck on it.
Sorry for the rather long question I thought it might be beneficial if I provided as much info as possible.
Thanks for your help. |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Nov 20, 2012 3:25 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
And what does the log at the remote end state? And are you happy with the suggestion of just 'throwing away' messages containing data which does not belong to you? Before you make any decision about doing so I suggest you carry out proper end-to-end, full fault diagnosis. And even if you did clear out 'stuck' messages what would you do if the next lot got stuck too?
And what was on the DLQ, which should of course always be at zero depth in a properly running system?
_________________
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 |
|
|
| sid008 |
| Posted: Tue Nov 20, 2012 3:29 am Post subject: |
|
|
Newbie
Joined: 13 Nov 2012
Posts: 6
|
| exerk wrote: |
And what does the log at the remote end state? And are you happy with the suggestion of just 'throwing away' messages containing data which does not belong to you? Before you make any decision about doing so I suggest you carry out proper end-to-end, full fault diagnosis. And even if you did clear out 'stuck' messages what would you do if the next lot got stuck too?
And what was on the DLQ, which should of course always be at zero depth in a properly running system? |
Good point! problem is I don't have access to the remote queue or the logs. All I have to work from is my local logs - the remote end MQ setup (or personnel managing it) are almost impossible to get hold of.
As for the messages these are test and can be discarded (plus I can resend the same messages). If the messages do get stuck again I can at least get back to the remote site with some information (i.e. cleared xmit etc and still facing the same issue)
Thanks. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Nov 20, 2012 3:35 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sid008 wrote: |
| exerk wrote: |
And what does the log at the remote end state? And are you happy with the suggestion of just 'throwing away' messages containing data which does not belong to you? Before you make any decision about doing so I suggest you carry out proper end-to-end, full fault diagnosis. And even if you did clear out 'stuck' messages what would you do if the next lot got stuck too?
And what was on the DLQ, which should of course always be at zero depth in a properly running system? |
Good point! problem is I don't have access to the remote queue or the logs. All I have to work from is my local logs - the remote end MQ setup (or personnel managing it) are almost impossible to get hold of. |
Get your management involved - if you're having a point-of-contact problem in this environment what are you going to do when you get the same problem in a Production environment?
| sid008 wrote: |
| As for the messages these are test and can be discarded (plus I can resend the same messages). If the messages do get stuck again I can at least get back to the remote site with some information (i.e. cleared xmit etc and still facing the same issue) |
How will you know a future issue is the same as your current issue, and not the same symptom, if you do not identify the exact nature of your current issue?
_________________
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 |
|
|
| Esa |
| Posted: Tue Nov 20, 2012 5:58 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
So you need to teach yourself how to resolve a channel properly. This requires communication with the administrators of the QM receiving the messages. You need to compare your channel statuses to figure out if the receiving MCA has committed the in-doubt batch or not. When you understand how it goes, it will perhaps be a good idea to write yourself a document with step-by-step instructions.
But, now when I came to think of it, you should not need to resolve channels manually if you can restart the channel. Because the MCA:s should resolve it automatically. Maybe this is something else. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Nov 20, 2012 6:45 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
|
|
