There was a recent update to MO71 that allowed multiple SERVICE objects to be edited at once.
MQGem Software (@MQGem) December 19, 2016
The example used in the screenshot was of the trigger monitor being run as a service, and is straight out of Knowledge Center (with the exception of a more meaningful object name).
It uses the provided amqsstop program as recommended too. The parameters that amqsstop expects are provided in the STOPARG which include the +MQ_SERVER_PID+ which is a token representing the process id of the process started by the STARTCMD and STARTARG arguments.
I was playing around with this SERVICE object a little more today and discovered that the STOP SERVICE command doesn’t work. This post covers what I discovered and how to fix it.
You’ll note from the screen shot that I’m running a 64-bit Windows queue manager – you can tell that from the path of the amqsstop program which is in the bin64 directory. However, I used the runmqtrm program from the bin directory. This is no doubt a migratory aid for those users that had scripts etc starting the trigger monitor from that location prior to the Windows queue manager becoming a 64-bit entity.
Having started my trigger monitor with the above definition, I can see it’s status using the DISPLAY SVSTATUS command.
AMQ8632: Display service status details. SERVICE(TRIGGER.MONITOR) STATUS(RUNNING)SERVTYPE(SERVER) STARTDA(2017-06-17) STARTTI(11.40.55) CONTROL(QMGR) STARTCMD(C:\mqm8004\bin/runmqtrm) STARTARG(-m MQG1 -q ACCOUNTS.INITQ) STOPCMD(C:\mqm8004\bin64/amqsstop) STOPARG(-m MQG1 ) DESCR(Trigger Monitor Service Auto Started with QMgr) STDOUT( ) STDERR( )
Part of this display is the process ID of the trigger monitor, and you can also see that the replaceable insert +MQ_PROCESS_ID+ in the STOPARG attribute has been replaced with the same PID.
When you issue the MQ command STOP SERVICE(TRIGGER.MONITOR) it issues a PCF Inquire Connections command with a WHERE clause asking for all those connections where the PID is 3384. You can see in the MQ trace that the answer which comes back is MQRCCF_NONE_FOUND.
Now I know the trigger monitor is running so I find it myself in a DISPLAY CONN command and I see this:-
AMQ8276: Display Connection details. CONN(876C445920002201) EXTCONN(414D51434D5147312020202020202020) TYPE(*)TID(1) APPLDESC(WebSphere MQ Trigger Monitor) APPLTYPE(SYSTEM) ASTATE(NONE) CHANNEL( ) CLIENTID( ) CONNAME( ) CONNOPTS(MQCNO_SHARED_BINDING) USERID(MUSR_MQADMIN) UOWLOG( ) UOWSTDA(2017-06-17) UOWSTTI(11.40.55) UOWLOGDA( ) UOWLOGTI( ) URTYPE(QMGR) EXTURID(XA_FORMATID XA_GTRID XA_BQUAL) QMURID(0.20482) UOWSTATE(ACTIVE)
So there are two interesting things in this output. Firstly the PID is different. Secondly, it’s the bin64 version of runmqtrm. There’s no sign of the bin version of runmqtrm with PID(3384) anywhere in DISPLAY CONN. So I guess it didn’t make a connection to the queue manager.
Next thing to check out is the processes that the Windows OS thinks are running. I look for and find both PID(3384) and PID(4604).
So it seems that the runmqtrm in the bin directory is not a copy of the one in the bin64 directory, but something else that starts the bin64 version of runmqtrm. This means that amqsstop doesn’t work because it is trying to find the first process which never connected to the queue manager.
The fix to get your Trigger Monitor Service definition to work again with a STOP SERVICE command is to use the bin64 version of runmqtrm directly in the STARTCMD and avoid this double hop which leaves you with two processes running unnecessarily.
DEFINE SERVICE(TRIGGER.MONITOR) + SERVTYPE(SERVER) CONTROL(QMGR) + DESCR('Trigger Monitor Service Auto Started with QMgr') + STARTCMD('+MQ_INSTALL_PATH+bin64\runmqtrm') + STARTARG('-m +QMNAME+ -q ACCOUNTS.INITQ') + STOPCMD('+MQ_INSTALL_PATH+bin64\amqsstop') + STOPARG('-m +QMNAME+ -p +MQ_SERVER_PID+')
You don’t have the same problem on Unixes, because there aren’t the two bin directories on those platforms. So this is very specific to Windows.
Really it’s a shame that there isn’t a replaceable insert something like +MQ_BIN_DIR_PATH+ so that these platform differences would be completely removed from the SERVICE object definition. But I suppose you could make one yourself and put it into the service.env file.