How to do Cold Restart of Queue Manager ?

How to do Cold Restart of Queue Manager ? (or) How to replace the Corrupted Queue Manager logs ?
on June 09, 2014

The following steps are required to cold start MQ on Linux:
 
Replacing Corrupted logs of a QMGR:


1. Delete all current queue manager logs:                                                                                             

mqm@mqm:~> cd /                                                                                                         
mqm@mqm:~> cd /var/mqm/log/OLDQMGR                                                                 
mqm@mqm:~> rm -r *                                                                                                     
                 
2. Create a DUMMY queue manager: 

(Note:  LOG PROPERTIES MUST MATCH OLDQMGR!!!)

If the corrupted QMGR logs looks like below:

   LogPrimaryFiles=55           -lp
   LogSecondaryFiles=2         -ls
   LogFilePages=16384          -lf
   LogType=LINEAR             -ll

Command to duplicate it:

mqm@mqm:~> crtmqm –lp 55 –ls 2 –lf 16384 -ll DUMMY

This might take little time.                                                           

Note: DON'T START the dummy qmgr once it is done.
                                                                                                                                   
3. Move file (amqhlctl.lfh) and directory (active) under:

/var/mqm/log/DUMMY into /var/mqm/log/OLDQMGR                                                                                                                                                                                                                 
mqm@mqm:~> mv /var/mqm/log/DUMMY/*
       
/var/mqm/log/OLDQMGR                                                 
                                                                                                                                   
4. Restart your QMGR:

Note: make sure all qmgr related processes are down:

ps –ef | grep  <qmgrname >

If you see some process still running Kill it with process id just like below:

kill –9 pid                                                                                                     

mqm@mqm:~> strmqm OLDQMGR

                                                                                                                                   
5. Delete the dummy QMGR:
                                                                                                                                   
       mqm@mqm:~> dltmqm DUMMY

Since the logs been replaced, We lost all information to commit or backout messages but all persistent messages are still in the queues (you don't lose persistent messages).


ref:

https://webspheremqadministrator.blogspot.com/2014/06/how-to-do-cold-restart-of-queue-manager.html

Removing a qmgr from a cluster

Procedure

Perform the following tasks at the TORONTO queue manager:

1. Modify the full repository queue manager REPOS and
REPOSNL attributes
If your queue manager is a full repository queue manager, before you can remove
it from a cluster, perform the additional step of altering the queue manager
definition to set the REPOS and REPOSNL attributes to blank. This sends a
notification to other queue managers advising them that they must stop sending
cluster information to this queue manager.

2. Check that the REPOS and REPOSNL changes have been
propagated
Check that the changes you made in the previous step have been propagated
around the cluster by issuing the following command on a remaining full
repository:

DIS  CLUSQMGR(TORONTO)  QMTYPE

and check that it shows that the queue manager is no longer a full repository. The
output should match the following:
AMQ8441:  Display  Cluster  Queue  Manager  details.
CLUSQMGR(TORONTO)
CLUSTER(INVENTORY)
CHANNEL(TO.TORONTO)
QMTYPE(NORMAL)

3. Suspend queue manager TORONTO
Issue the SUSPEND QMGR command to suspend availability of the queue
manager to the INVENTORY cluster:
SUSPEND  QMGR  CLUSTER(INVENTORY)
When you issue this command, other queue managers are advised that they
should refrain from sending messages to TORONTO.


4. Check that queue manager TORONTO has been suspended
Check that TORONTO has been suspended before moving on to the next step by
issuing the following command on a full repository:
DIS  CLUSQMGR(TORONTO)  SUSPEND
and check that it shows that the queue manager is suspended. The output should
match the following:
Removing a queue manager
114    Queue Manager ClustersAMQ8441:  Display  Cluster  Queue  Manager  details.
CLUSQMGR(TORONTO)
CLUSTER(INVENTORY)
CHANNEL(TO.TORONTO)
SUSPEND(YES)

5. Remove the CLUSRCVR channel definition
Remove the CLUSRCVR definition from the cluster:
ALTER  CHANNEL(TO.TORONTO)  CHLTYPE(CLUSRCVR)  CLUSTER(’  ’)
This command causes the full repository queue managers to remove all
information about that channel from their full repositories, so that queue managers
will no longer try to send messages to it. You can verify that this command has
been successfully propagated by issuing the following command on the full
repository:
DIS  CLUSQMGR(TORONTO)
You should receive a message like that below:
AMQ8147:  WebSphere  MQ  object  TORONTO  not  found

6. Stop the CLUSRCVR channel at TORONTO
Note:  Before performing this step, ensure that any bound messages have arrived
on TORONTO, otherwise these messages will become stuck on the sending
queue manager’s cluster transmit queue.
Issue the STOP CHANNEL command to stop the cluster-receiver channel:
STOP  CHANNEL(TO.TORONTO)
Once the channel is stopped, no more messages can be sent to TORONTO.
Later, to tidy up, you will probably want to delete the channel:
DELETE  CHANNEL(TO.TORONTO)
Note:  At this point the TORONTO queue manager is no longer a valid destination
in the cluster, but there may be messages bound to TORONTO (messages
put using BIND_ON_OPEN) still being sent from other queue managers in
the cluster.

7. Delete the CLUSSDR channel definition
Note:  Do not attempt this step before completing all previous steps in this task.
The CLUSSDR channel definition points to the full repository at queue manager
NEWYORK. Stop this channel as follows:
STOP  CHANNEL(TO.NEWYORK)
and then delete it:
DELETE  CHANNEL(TO.NEWYORK)

8. Issue the REFRESH CLUSTER command
Issue the REFRESH CLUSTER command to remove any auto-defined cluster
channels:
REFRESH  CLUSTER(INVENTORY)  REPOS(YES)

The queue manager TORONTO is no longer part of the cluster. However, it can
still function as an independent queue manager.


Ref:
Queue Manager Clusters

sample tool to test connection with MQ qmgr

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.dev.doc/q024090_.htm

http://www-01.ibm.com/support/docview.wss?uid=swg21615875

There is an additional MQ test you can run, The amqscnxc sample connect program included with the MQ samples. You need to have the MQ samples module installed to get this. Source code for the utility is also provided with the samples.

The following test will connect to the queue manager and respond that you are connected/or fail:

amqscnxc -x ConnName -c SvrconnChannelName QMgrName

UNIX: (need the ' ' for the -x option)
amqscnxc -x '192.168.1.131(1415)' -c EXCONN MIKE

Windows: (doesn't need the ' ' for the -x option)
amqscnxc -x 192.168.1.131(1415) -c EXCONN MIKE


*** for the MQ v8, you need to inpurt the user name for the connection, you can set the user id in the MQSAMP_USER_ID environment variable.

MQ V8 - Samples can use user ID and password
https://www.ibm.com/developerworks/community/blogs/messaging/entry/bitesize_blogging_mq_v8_samples_can_use_user_id_and_password?lang=en_us

MQ QMGR on Windows does not start after system reboot even if it is configured to automatically start in the MQ explorer?

https://developer.ibm.com/answers/questions/216225/mq-qmgr-on-windows-does-not-start-after-system-reb.html

Q:
A WebSphere MQ queue manager on Windows is configured to automatically start in the MQ explorer, however, after system reboot, the queue manager does not start. No errors can be found in the Windows event log or MQ error log. The queue manager can be manually started successfully using command line or MQ explorer (V7.1 or later version).

Ans:

One possible scenario could be that the Startup value in the qm.ini file has been set to "2". If the Startup value is 2, the MQ queue manager will not start automatically. If this is the case, please follow these steps to solve the problem.

1) Change "Startup" value to "1" in /qmgrs//qm.ini For example, InstanceData:    InstanceID=1381394841    Startup=1 .
2) Stop IBM MQ Service ( endmqsvc)
3) Start IBM MQServices ( strmqsvc)

https://developer.ibm.com/answers/questions/216225/mq-qmgr-on-windows-does-not-start-after-system-reb.html