I have created a queue manager (IBM WebSphere MQ->QueueManagers->new->QueueManager)
I have created a initiation Queue (QueueManager->Queues->New->Local Queue):
Queue name: INITQUEUE
Put Message & Get Message:Allowed
Scope:Queue manager
I have created a process (Process Definitions->New->Process Definition):
Process name:Paint
Application Type:DOS
Application ID:C:\Users\Desktop\paint.bat
I have created an application queue (QueueManager->Queues->New->Local Queue):
Trigger type: First
Trigger control: On
Initiation queue: INITQUEUE
Process name: sample
I have created a service to start the trigger monitor (Services->New->Service):
service type: server
service control : Queue Manager
Start command: C:\Program Files (x86)\IBM\WebSphere MQ\bin\runmqtrm
Start args: -q INITQUEUE
When a messages put to the application Queue, no trigger message is inserted into the initiation Queue.
When I start the trigger monitor, it automatically stops after few seconds.
How do I correct these issues.
This is the output got when I start the runmqtrm:
C:\Program Files (x86)\IBM\WebSphere MQ\bin>runmqtrm -m QMGR -q INITQUEUE
5724-H72 (C) Copyright IBM Corp. 1994, 2011. ALL RIGHTS RESERVED.
11/3/2017 01:54:43: WebSphere MQ trigger monitor started.
__________________________________________________
11/3/2017 01:55:04: Waiting for a trigger message
There is no error in AMQERR01.LOG. But the process is not working.
Also when a data is inserted into Application queue, it is does not enable the initiation queue.
And in CMD it says as WebSphere MQ trigger monitor started,initiation queue's open input count increases to 1 but in my UI it still remains as stopped.
Version of MQ server:
Name: WebSphere MQ
Version: 7.5.0.2
Level: p750-002-130627
BuildType: IKAP - (Production)
Platform: WebSphere MQ for Windows
Mode: 32-bit
O/S: Windows 7 Professional x64 Edition, Build 7601: SP1
InstName: Installation1
InstDesc:
Primary: Yes
InstPath: C:\Program Files (x86)\IBM\WebSphere MQ
DataPath: C:\Program Files (x86)\IBM\WebSphere MQ
MaxCmdLevel: 750
AMQ8351: WebSphere MQ Java environment has not been configured correctly.
AMQ8351: WebSphere MQ Java environment has not been configured correctly.
Name: IBM WebSphere MQ custom channel for Windows Communication Foundatio
n
Version: 7.5.0.2
Level: wn750-002-130611_P
Build Type: Production
Name: IBM Message Service Client for .NET (XMS .NET)
Version: 2.5.0.2
Level: nn250-002-130627
Build Type: Production
Name: IBM Global Security Kit for WebSphere MQ
Version: 8.0.14.28
Build Type: Production
Mode: 32-bit
Name: IBM Global Security Kit for WebSphere MQ
Version: 8.0.14.28
Build Type: Production
Mode: 64-bit
The issue with the configuration is that you created a Process called Paint, but on the application queue you set the Process name to sample. The name of the process the queue points to needs to match the name of the process that you created..
Paul Clarke of MQGem Software presented a presentation at Capitalware's MQ Technical Conference v2.0.1.4 called MQ Triggering which is a comprehensive presentation on IBM MQ Triggering with details on how to troubleshoot issues that I have found very useful.
Process name: Paint
Silly rabbit, tricks are for kids!!
MQ is running under a service account. You are trying launch a GUI application in the background. I'm sure if you opened the Task Manager there will be many 'mspaint.exe' running but not visible.
Use a program that can run in the background or create your own. Create a batch file called: hello.bat and put the following in it:
echo "Hello World. " %time% > C:\temp\hello.txt
Update the MQ Process definition with 'hello.bat' and do a test. Note: Make sure the C:\temp directory exist.
Related
I am going to answer this myself as a FAQ.
This has been seen on MacOS, but applies to all MQ Client only installations. When running dmpmqcfg in a terminal you see the error:
AMQ8670E: Loading of server module 'libmqds_r.dylib' failed.
The command dmpmqcfg is used to dump the configuration of IBM MQ queue managers. It needs to connect to a queue manager to do this. dmpmqcfg can run both in bindings and client mode. The error is thrown when dmpmqcfg is run in bindings mode on a client only install, and is thrown when it can't find the .dylib file being requested. libmqds_r.dylib is used to make a bindings connection, which only works when its co-located on the MQ server.
If you see this error on a client machine, then you need to run dmpmqcfg in client mode:
dmpmqcfg -c
and provide queue manager information on the command line, or through a CCDT, or mqclient.ini
We need to configure MQ QUEUE PLUG-IN connecting a RHEL Linux server. Below is version details.
Name: WebSphere MQ
Version: 8.0.0.5
Level: p800-005-160516.2
BuildType: IKAP - (Production)
Platform: WebSphere MQ for Linux (x86-64 platform)
Mode: 64-bit
O/S: Linux 2.6.32-754.2.1.el6.x86_64
http://resources.itrsgroup.com/docs/geneos/4.4.0/Netprobe/middleware/mq-queue.html
As per ITRS support we need libmqic.so - which is part of MQ Client Package. But since the server has MQ server installed we are not keen to install MQ Client.
So question is.
Can MQ Server and Client co-exist in same server ?
Its not logical that MQ server do not have equivalent of libmqic.so package. What is the equivalent of this in server installation ?
Can we just copy libmqic.so from a client installation and use ?
Any input on this would be great. Thank you.
Regards,
Dwija
The MQServer bundle from IBM includes RPMs for both client and server libraries.
You can check what is installed with this command (sort/paste/column just format it nice):
rpm -qa | grep MQSeries | sort | paste -s -d' \n' | column -t
You should see something like the following:
MQSeriesClient-8.0.0-4.x86_64 MQSeriesClient-U8005-8.0.0-5.x86_64
MQSeriesGSKit-8.0.0-4.x86_64 MQSeriesGSKit-U8005-8.0.0-5.x86_64
MQSeriesJava-8.0.0-4.x86_64 MQSeriesJava-U8005-8.0.0-5.x86_64
MQSeriesJRE-8.0.0-4.x86_64 MQSeriesJRE-U8005-8.0.0-5.x86_64
MQSeriesMan-8.0.0-4.x86_64 MQSeriesMan-U8005-8.0.0-5.x86_64
MQSeriesRuntime-8.0.0-4.x86_64 MQSeriesRuntime-U8005-8.0.0-5.x86_64
MQSeriesSamples-8.0.0-4.x86_64 MQSeriesSamples-U8005-8.0.0-5.x86_64
MQSeriesSDK-8.0.0-4.x86_64 MQSeriesSDK-U8005-8.0.0-5.x86_64
MQSeriesServer-8.0.0-4.x86_64 MQSeriesServer-U8005-8.0.0-5.x86_64
The 8.0.0-4 packages are the base install and the U8005 packages are the update to fixpack 8.0.0.5.
As long as you have the MQSeriesClient* packages installed you will have access to the libraries required by ITRS NetProbe MQ QUEUE PLUG-IN.
I do not know of any reason why a MQ Admin would have an issue with installing those packages that come as part of the MQ Server bundle.
If there is some reason they do not want to install those packages then another work around is to download the redistributable client (google MQC8 for the download link). You can just extract the tar into any location on the server and then make sure the LD_LIBRARY_PATH points to the locate you extracted the files to either the lib (32bit) or lib64 (64bit) sub directory. You can run file netprobe to check if it is 32bit or 64bit to see which is appropriate. If you need more details on this option let me know and I can add more.
I want to get the Queue details created for 7.0.1.6.
I am running “dmpmqcfg” command
But the command is not found in my bin directory in IBM MQ 7.0.1.6.
dmpmqcfg was added in V7.1 (previously, people used the MS03 saveqmgr SupportPac).
The MS03 SupportPac can be downloaded from the following page:
WITHDRAWN: MS03: WebSphere MQ - Save Queue Manager object definitions using PCFs (saveqmgr)
The page also confirms the dmpmqcfg was added in v7.1
Note: From MQ V7.1 onwards, the command dmpmqcfg is available in the
product. This is recommended instead of the use of MS03.
Could you please help on how to roll back the MQ patch applied on windows.
I have patched the system from MQ7.1.0.0 to MQ7.1.0.8. It is a MQ client.
Plz suggest how to rollback to 7.1.0.0.
dspmqver -i
Name: WebSphere MQ
Version: 7.1.0.8
Level: p710-008-161121
BuildType: IKAP - (Production)
Platform: WebSphere MQ for Windows
Mode: 32-bit
O/S: Windows Server 2008 R2 Server Enterprise Edition, Build 7601: SP1
InstName: Installation1
InstDesc:
InstPath: C:\Program Files (x86)\IBM\WebSphere MQ
DataPath: C:\Program Files (x86)\IBM\WebSphere MQ
Primary: Yes
MaxCmdLevel: 711
Name: WebSphere MQ
Version: 7.1.0.0
InstName: Installation2
InstDesc:
InstPath: C:\Program Files (x86)\IBM\WebSphere MQ_1
Primary: No
After executing the below command
C:\Program Files (x86)\IBM\WebSphere MQ\bin>dspmqver -i
Name: WebSphere MQ
Version: 7.1.0.8
Level: p710-008-161121
BuildType: IKAP - (Production)
Platform: WebSphere MQ for Windows
Mode: 32-bit
O/S: Windows Server 2008 R2 Server Enterprise Edition, Build 7601: SP1
InstName: Installation1
InstDesc: InstPath: C:\Program Files (x86)\IBM\WebSphere MQ
DataPath: C:\Program Files (x86)\IBM\WebSphere MQ
Primary: No
MaxCmdLevel: 711
Name: WebSphere MQ
Version: 7.1.0.0
InstName: Installation2
InstDesc:
InstPath: C:\Program Files (x86)\IBM\WebSphere MQ_1
Primary: Yes
The client software is distributed as a full install not a patch. In your case the roll back would consist of a uninstall of the 7.1.0.8 client package and a reinstall of 7.1.0.0 client package.
Download links for each v7.1.0.x client package are located on the IBM page "MQC71: WebSphere MQ V7.1 Clients".
NOTE that v7.1 of IBM MQ went out of support on April 30th 2017. Newer versions of IBM MQ client can connect to IBM MQ Queue Managers that are at a older version.
You have two installations on the same server, Installation1 is 7.1.0.8 and Installation2 is 7.1.0.0. Because of the order of the installations, you probably upgraded Installation1 from 7.1.0.0 to 7.1.0.8 and the later installed 7.1.0.0 as Installation2.
This is possible because MQ v7.1 and higher supports multiple versions being installed in parallel. On Windows one installation will always be primary, in the original output you provided your Installation1 at 7.1.0.8 was primary.
You can run the command below to switch the primary install to Installation2 (your 7.1.0.0 installation).
setmqinst -i -n Installation2
The updated output you provided shows that Installation2 at 7.1.0.0 is primary now.
You can consider this as rolled back to 7.1.0.0 since the installation with that version is now the Primary installation. You could take it a step further and actually uninstall the 7.1.0.8 installation if you like or you could keep it in place to "roll forward" to in the future.
I have installed WAS 8.5 Trial version on Windows 7. I would like to deploy and run Java 7 application. Is it possible to do it?
I can not see "IBM WebSphere SDK for Java Technology Edition 7" in the IBM Installation Manager's feature list and there is no SDK 7 installed, yet.
>managesdk.bat -listAvailable
CWSDK1003I: Available SDKs :
CWSDK1005I: SDK name: 1.6_64
CWSDK1001I: Successfully performed the requested managesdk task.
>
Has somebody managed to make WAS 8.5 Trial and Java 7 work together on Windows 7?
Thanks in advance!
I've just found one of the possible solutions...
Select the method "Download Director or HTTP" instead of "Installation Manager (Recommended)" at the download page of Evaluate: IBM WebSphere Application Server. Then you get a list of products to download which contains "IBM WebSphere SDK Java 7, Installation Manager repository".
Select and Download all parts of the product and extract the three part to the same directory.
Start your previously installed Installation Manager and add the directory as a new repository under File > Preferences > Repositories, then press OK.
Now you can choose Install and you can select IBM WebSphere SDK Java Technology Edition (Optional) from the list of available packages.
After the installation is completed you can check if everything went well.
>managesdk.bat -listAvailable
CWSDK1003I: Available SDKs :
CWSDK1005I: SDK name: 1.6_64
CWSDK1005I: SDK name: 1.7_64
CWSDK1001I: Successfully performed the requested managesdk task.
>
The Java SDK 1.7 is installed and you can set it as the default SDK in the Administrative Console of your server.
Server > WebSphere application servers > server > Server Infrastructure > Java SDKs
Sorry for the stupid question, I wasn't careful enough...
Firstly install the JDK 1.7 or any required version supported.(find the available using the command - managesdk.bat -listAvailable)
Then Go to the Installed WAS Server DIR and then navigate to bin folder
C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\AppSrv02\bin
For ALL Profiles
managesdk -enableProfileAll -sdkname SDK_Name -enableServers
From there execute this command(In Windows)
C:\Program Files (x86)\IBM\WebSphere\AppServer_2\profiles\AppSrv02\bin>managesdk
.bat -enableProfile -profileName AppSrv02 -sdkname 1.7_64
It gives this message to confirm.
CWSDK1017I: Profile AppSrv02 now enabled to use SDK 1.7_64.
CWSDK1001I: Successfully performed the requested managesdk task.
(In Linux)
/opt/IBM/WebSphere/WSRR/v8.5/bin/managesdk.sh -enableProfile -profileName AppSrv02 -sdkname 1.7_64
Note: AppSrv02 is the server name used in my local. Replace the name with your actual thing.