ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportMQ Channels Stay Asleep/Inactive Even With Msg In TX Queue?

Post new topicReply to topic
MQ Channels Stay Asleep/Inactive Even With Msg In TX Queue? View previous topic :: View next topic
Author Message
nickj
PostPosted: Thu Mar 02, 2017 2:05 pm Post subject: MQ Channels Stay Asleep/Inactive Even With Msg In TX Queue? Reply with quote

Newbie

Joined: 02 Mar 2017
Posts: 4

Hey there,

First just wanted to say what a great resource to find, really appreciate everyone's efforts here to help people out!

I've very much benefitted from the answers all of you have dedicated your time to providing, so thanks again!

A quick question, and more some guidance on what concept/part of the MQ Guide I should be looking at:

What settings are available on the channel to ensure that a channel automatically wakes up when there are messages sitting on it's transmission queue?

Right now, it stays asleep/inactive, and I need to login with the Explorer to switch to Start and then everything goes along nicely on the Sender, and receive the subsequent response...?

EDIT
Looks like I've done a bit more research, am I on the right path by just setting up the Transmission Queue Triggering like follows:

Trigger Data (TRIGDATA) = <Name of Channel I want to start>
Initiation Queue (INITQ) = SYSTEM.CHANNEL.INITQ

Am I right in assuming that the trigger type should be set to "Every" and not "First", as I intend on any new message arriving to trigger the channel sending?

Thanks again in advance,

Nick

Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Mar 02, 2017 3:07 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7830
Location: US: west coast, almost. Otherwise, enroute.

Trigtype(first) is sufficient). The other requirement is a started channel initiator.
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Thu Mar 02, 2017 3:49 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1719
Location: Melbourne, Australia

Check that transmission queue has
usage(xmitq)
trigtype(first)
trigger
initq('SYSTEM.CHANNEL.INITQ')
trigdata('yoursenderchannelname')

maxmsgl also needs to be large enough for your largest message + size of mqxqh header
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Mar 02, 2017 11:05 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7830
Location: US: west coast, almost. Otherwise, enroute.

Look in the error logs for the qmgr whose sender chl fails to start Post errors here.
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
exerk
PostPosted: Fri Mar 03, 2017 2:59 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5717

And you may have to reset the trigger, e.g. ALTER QL(BLAH) NOTRIGGER followed by ALTER QL(BLAH) TRIGGER, or do it through MQ Explorer as you intimate you're using that.
_________________
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
View user's profile Send private message
Vitor
PostPosted: Fri Mar 03, 2017 5:38 am Post subject: Re: MQ Channels Stay Asleep/Inactive Even With Msg In TX Que Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24511
Location: Ohio, USA

nickj wrote:
Am I right in assuming that the trigger type should be set to "Every" and not "First", as I intend on any new message arriving to trigger the channel sending?


To expand on the comment of my most worthy associate:

You should use "First" not "Every". As a well behaved MQ application, the channel MCA will, once started, continue to run until the transmission queue is empty. Because "First" was chosen as a shorter way of writing "when the queue depth goes from 0 to 1", the next message to arrive on an empty queue will cause the "First" trigger to fire (assuming the MCA has stopped at this point).

If you use "Every", a new instance of the MCA will be triggered for each message that arrives. This will cause pain, suffering, madness and lots of error messages as they fight it out for access to the queue, as well as a lot of error messages from the poor confused MCA at the other end which expects a well mannered conversation over the channel and is instead confronted with this yelling crowd.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Sun Mar 05, 2017 3:37 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1719
Location: Melbourne, Australia

Quote:
Am I right in assuming that the trigger type should be set to "Every" and not "First", as I intend on any new message arriving to trigger the channel sending?

Never use trigtype(every) on transmission queues, for reasons given above. If the channel is not starting when the first msg appears on the xmitq, you need to identify the reason and fix it.
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sun Mar 05, 2017 8:31 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7830
Location: US: west coast, almost. Otherwise, enroute.

Look for possible clues in errors logs.
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
nickj
PostPosted: Wed Mar 08, 2017 4:41 pm Post subject: Reply with quote

Newbie

Joined: 02 Mar 2017
Posts: 4

Thanks all for your replies, sorry for my tardiness, I had the week off work...back to it now (the joy!)

So I looked further into it, and I didn't have the channel initiator setup initially as suggested by bruce2359 thanks!

I've done that now, and on queue manager restart/start/stop the ChannelInitiator service is starting:

Code:

mqm        175  0.0  1.1 360648 11452 ?        Sl   11:25   0:00 /opt/mqm/bin/runmqchi -m COOLQMGR1 -q SYSTEM.CHANNEL.INITQ -r



AND the channel initiator kicks and sends the messages from the TQ like it's meant to, but despite it all seeming to be working fine, I'm still getting some weird errors when restarting the QM (which restarts the CI service), implying it is trying to start the service twice again?

Code:

-------------------------------------------------------------------------------
03/09/17 11:00:24 - Process(175.1) User(root) Program(runmqchi)
                    Host(ramzihacker) Installation(Installation1)
                    VRMF(9.0.1.0) QMgr(COOLQMGR1)

AMQ8024: IBM MQ channel initiator started.

EXPLANATION:
The channel initiator for queue SYSTEM.CHANNEL.INITQ has been started.
ACTION:
None.
-------------------------------------------------------------------------------
03/09/17 11:00:24 - Process(180.1) User(root) Program(runmqchi)
                    Host(ramzihacker) Installation(Installation1)
                    VRMF(9.0.1.0) QMgr(COOLQMGR1)

AMQ9509: Program cannot open queue manager object.

EXPLANATION:
The attempt to open either the queue or queue manager object
'SYSTEM.CHANNEL.INITQ' on queue manager 'COOLQMGR1' failed with reason code
2042.
ACTION:
Ensure that the queue is available and retry the operation.



Some more info:

Sender Channel Config
Code:

DISPLAY CHL(COOLQMGR1.TO.ANOTHERQMGR)
     1 : DISPLAY CHL(COOLQMGR1.TO.ANOTHERQMGR)
AMQ8414: Display Channel details.
   CHANNEL(COOLQMGR1.TO.ANOTHERQMGR)       CHLTYPE(SDR)
   ALTDATE(2017-03-09)                     ALTTIME(10.26.17)
   BATCHHB(0)                              BATCHINT(0)
   BATCHLIM(5000)                          BATCHSZ(50)
   CERTLABL( )                             COMPHDR(NONE)
   COMPMSG(NONE)                           CONNAME(123.456.789.123(1414))
   CONVERT(NO)                             DESCR(TEST)
   DISCINT(5)                              HBINT(300)
   KAINT(AUTO)                             LOCLADDR( )
   LONGRTY(999999999)                      LONGTMR(1200)
   MAXMSGL(4194304)                        MCANAME( )
   MCATYPE(PROCESS)                        MCAUSER( )
   MODENAME( )                             MONCHL(QMGR)
   MSGDATA( )                              MSGEXIT( )
   NPMSPEED(FAST)                          PASSWORD( )
   PROPCTL(COMPAT)                         RCVDATA( )
   RCVEXIT( )                              RESETSEQ(NO)
   SCYDATA( )                              SCYEXIT( )
   SENDDATA( )                             SENDEXIT( )
   SEQWRAP(999999999)                      SHORTRTY(10)
   SHORTTMR(60)
   SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)
   SSLPEER( )                              STATCHL(QMGR)
   TPNAME( )                               TRPTYPE(TCP)
   USEDLQ(YES)                             USERID( )
   XMITQ(TRANS.OK.TEST)


Transmission Queue Config
Code:

DISPLAY QUEUE(TRANS.OK.TEST)
   31 : DISPLAY QUEUE(TRANS.OK.TEST)
AMQ8409: Display Queue details.
  QUEUE(TRANS.OK.TEST)                    TYPE(QLOCAL)
  ACCTQ(QMGR)                             ALTDATE(2017-03-08)
  ALTTIME(23.06.32)                       BOQNAME( )
  BOTHRESH(0)                             CLUSNL( )
  CLUSTER( )                              CLCHNAME( )
  CLWLPRTY(0)                             CLWLRANK(0)
  CLWLUSEQ(QMGR)                          CRDATE(2017-03-08)
  CRTIME(01.37.10)                        CURDEPTH(0)
  CUSTOM( )                               DEFBIND(OPEN)
  DEFPRTY(0)                              DEFPSIST(YES)
  DEFPRESP(SYNC)                          DEFREADA(NO)
  DEFSOPT(SHARED)                         DEFTYPE(PREDEFINED)
  DESCR(Transmission Queue for OK TEST)
  DISTL(YES)                              GET(ENABLED)
  HARDENBO                                INITQ(SYSTEM.CHANNEL.INITQ)
  IPPROCS(0)                              MAXDEPTH(5000)
  MAXMSGL(4194304)                        MONQ(QMGR)
  MSGDLVSQ(PRIORITY)                      TRIGGER
  NPMCLASS(NORMAL)                        OPPROCS(0)
  PROCESS( )                              PUT(ENABLED)
  PROPCTL(COMPAT)                         QDEPTHHI(80)
  QDEPTHLO(20)                            QDPHIEV(DISABLED)
  QDPLOEV(DISABLED)                       QDPMAXEV(ENABLED)
  QSVCIEV(NONE)                           QSVCINT(999999999)
  RETINTVL(999999999)                     SCOPE(QMGR)
  SHARE                                   STATQ(QMGR)
  TRIGDATA(COOLQMGR1.TO.ANOTHERQMGR)      TRIGDPTH(1)
  TRIGMPRI(0)                             TRIGTYPE(FIRST)
  USAGE(XMITQ)
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Wed Mar 08, 2017 6:09 pm Post subject: Reply with quote

Sentinel

Joined: 17 Nov 2005
Posts: 852
Location: New Zealand

If RUNMQCHI is getting 2042's when it tries to open the SYSTEM.CHANNEL.INITQ queue that's not good. This queue is used to accumulate the trigger messages as well as a variety of others. Channel triggering is not going to work if the initiator can't even open the initiation queue.

I can only imagine that you have some other program that has opened this queue erroneously. Issue a command like:
DIS QSTATUS(SYSTEM.CHANNEL.INITQ) TYPE(HANDLE) to see what application has opened the queue.

Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
nickj
PostPosted: Wed Mar 08, 2017 7:24 pm Post subject: Reply with quote

Newbie

Joined: 02 Mar 2017
Posts: 4

Thanks Paul, the channel triggering was working, but still getting those logs show up every now and then, despite everything "working".

I just restarted the server/QMGR a few times and now it's working properly, without having that error in the logs (which wasn't really, maybe a temporary acccess issue)

When I ran the DIS QSTATUS(SYSTEM.CHANNEL.INITQ) TYPE(HANDLE), it was only the runmqchi that was using it anyway:

Code:

DIS QSTATUS(SYSTEM.CHANNEL.INITQ) TYPE(HANDLE)
     1 : DIS QSTATUS(SYSTEM.CHANNEL.INITQ) TYPE(HANDLE)
AMQ8450: Display queue status details.
   QUEUE(SYSTEM.CHANNEL.INITQ)             TYPE(HANDLE)
   APPLDESC(IBM MQ Channel Initiator)      APPLTAG(runmqchi)
   APPLTYPE(CHINIT)                        BROWSE(NO)
   CHANNEL( )                              CONNAME( )
   ASTATE(NONE)                            HSTATE(ACTIVE)
   INPUT(EXCL)                             INQUIRE(NO)
   OUTPUT(NO)                              PID(175)
   QMURID(0.0)                             SET(YES)
   TID(1)
   URID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
   URTYPE(QMGR)                            USERID(root)
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Mar 08, 2017 7:43 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7830
Location: US: west coast, almost. Otherwise, enroute.

My diagnosis (from NZ) is that the other ci's we're the ones you started manually while trying to kick-start the channel. No harm, no foul.
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Thu Mar 09, 2017 3:37 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1719
Location: Melbourne, Australia

Quote:
03/09/17 11:00:24 - Process(175.1) User(root) Program(runmqchi)

All MQ qmgr processes should be running as mqm.

runmqchi is supposed to start when the qmgr starts. You shouldn't need to start it manually.
_________________
Glenn
Back to top
View user's profile Send private message
nickj
PostPosted: Thu Mar 09, 2017 4:09 pm Post subject: Reply with quote

Newbie

Joined: 02 Mar 2017
Posts: 4

gbaddeley wrote:
Quote:
03/09/17 11:00:24 - Process(175.1) User(root) Program(runmqchi)

All MQ qmgr processes should be running as mqm.

runmqchi is supposed to start when the qmgr starts. You shouldn't need to start it manually.


Yep, you're not wrong, that's exactly what triggers the weird logs, despite everything working.

Thanks again everyone for your help with this one!

Cheers,

Nick
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportMQ Channels Stay Asleep/Inactive Even With Msg In TX Queue?
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.