Skip to main content

Websphere MQ

Create File Systems:

/usr/mqm -> MQ installation base

/var/mqm -> Queue Manager Data (log, qmgrs)

/home/mqm -> MQM user base (scripts, admin files etc)

/home/mqm/mqrouter - > MQ Router application files (scripts, config etc)

/home/mqm/saveqmgr -> Queue Manager backup location

Optional (for large installations in place of /var/mqm/):

/var/mqm/log –> Queue manager log

/var/mqm/qmgrs -> Queue manager data


 

Install – MQ Filesets:

mqm.base.runtime 7.0.1.3 WebSphere MQ Runtime for

mqm.base.samples 7.0.1.3 WebSphere MQ Samples

mqm.base.sdk 7.0.1.3 WebSphere MQ Base Kit for

mqm.client.rte 7.0.1.3 WebSphere MQ Client for AIX

mqm.java.rte 7.0.1.3 WebSphere MQ Java Client, JMS

mqm.jre.rte 7.0.1.3 WebSphere MQ Java Runtime

mqm.keyman.rte 7.0.1.3 WebSphere MQ Support for GSKit

mqm.msg.en_US 7.0.1.3 WebSphere MQ Messages - U.S.

mqm.server.rte 7.0.1.3 WebSphere MQ Server

mqm.txclient.rte 7.0.1.3 WebSphere MQ Extended

mqm.man.en_US.data 7.0.1.3 WebSphere MQ Man Pages - U.S.


 

Collect information from current server (for migrations):

On the current server, save the Queue Manager information using the saveqmgr MQ utility

#saveqmgr –m <Queue Manager Name> -s –f <File Name to save>

#saveqmgr –m <Queue Manager Name> -z -f <File Name to save>

This should create 2 files – one for the queue manager definitions and one for queue manager authorization definitions.

This utility is available from IBM WebSphere site: https://www-304.ibm.com/support/docview.wss?uid=swg24000673

Do this for all the desired Queue Managers.

Importing saved queue managers on the new server:

Create the desired empty queue mangaers on the new server:

#crtmqm – c "QM for ….env" –ll –ld /var/mqm/primary/log –md /var/mqm/primary/qmgrs –lp 3 –ls 2 <Queue Manager Name>

Start the new Queue Manager

#strmqm <Queue Manager Name>

Create the new Queue Manager definitions from the previously saved file (using saveqmgr)

#cat <QM definition file> | runmqsc <QM name>

Apply the authorization for the objects

Make the authorization file executable and execute it from the command line.

#./Authorization File

Labels:

Popular posts from this blog

Commands to restart RMC connection (t...

Commands to restart RMC connection (to HMC from LPAR) It has become very common with the IBM HMC to LPAR (logical/micro partition) communication to drop for unknown reasons.  Most of the time this is not a problem unless there is a need to do a dynamic logical partition operation (or DLAPR operation to add/remove resources on the fly).  This will become evident during the DLPAR operation when HMC complains about having no RMC connection to LPAR in operation.  When this happens run the following commands on the LPAR in question before reattemping the operation.  The DLPAR operation will still work with out this connection, but the LPAR needs a restart to see the change in the resources.  Restart the RMC connection on the LPAR: # /usr/sbin/rsct/install/bin/recfgct # /usr/sbin/rsct/bin/rmcctrl -p Verify the connection by running: lsrsrc IBM.ManagementServer This will show the HMC IP/hostname and the LPAR information.
Read more

Converting SEA on VIO from access to trunk mode

Shared Ethernet Adapters on VIO server can be configured in two different modes while accessing the external network. 1.  Simple mode 2. Trunk mode or 802.1Q mode In a Simple mode, the SEA is not aware of any VLAN information and bridges all the network packets to the external switch.  the external switch then determines the target and routes/discards it accordingly.  This is very useful when there is only one VLAN that needs to be serviced through the SEA to the LPARs using these VIO servers.  The configuration on the switch as well as the VIO (SEA) is simple and straight forward.  In a Trunk mode (802.1Q complaint), the SEA is aware of the VLANs and bridges only the packets that is part of the ‘Additional VLANs’ list.  The external switch then determines the target and routes/discards it accordingly.  This is very useful when there is a need to service multiple VLANs through the same SEA adapter.  This will provide the ability to create LPAR...
Read more

Shared Ethernet Adapter failover

Shared Ethernet Adapter (SEA): Shared Ethernet Adapter (SEA) provides the ability to share a physical adapter between multiple client partitions. It provides the connection between the virtual and physical network. The SEA acts like a layer-2 bridge between internal and external network SEA failover: SEA failover can be achieved by having SEA configured on two VIO servers which with the bridging functionality enabled ('Access External network'). They use a control channel to determine who is currently providing the Ethernet service to the client partitions. The client partition gets one virtual Ethernet adapter bridged by two VIO servers. From the client partition it looks like it has one virtual Ethernet adapter bridged by one VIO server - any given point of time. The SEA also support 802.1Q VLAN tagging like a regular SEA. Requirements for implementing SEA failover: VIO servers (on the same physical m...
Read more