Thursday, March 3, 2011

server to server communication


SERVER TO SERVER COMMUNICATION
Setup of Sender Workstation 
  1. Create a default queue manager called QMSENDER. At a command prompt in a window, enter the following command:
crtmqm -q QMSENDER
The -q option specifies that this queue manager is the default queue manager.
Messages tell you that the queue manager is created, and that the default WebSphere® MQ objects are created.
  1. Start the default queue manager. Enter the following command:
strmqm QMSENDER
A message tells you when the queue manager starts.
  1. Enable MQSC commands. Enter the following command:
runmqsc
The message Starting WebSphere MQ Commands is displayed when MQSC has started. MQSC has no command prompt.
  1. In the MQSC command window, define a local queue to use as a transmission queue called QMA. Enter the following command:
define qlocal(TRANSMITQSENDER) usage(xmitq)
The message WebSphere MQ queue created is displayed when the queue is created.
  1. In the MQSC command window, create a local definition of the remote queue. Enter the following command: 
          define qremote(LOCAL.DEF.OF.REMOTE.QUEUE) rname(SAMPLE.QUEUE) rqmname('QMRECEIVER') xmitq(TRANSMITQSENDER)
The rname parameter specifies the name of the queue on the remote machine to which the message will be sent. Therefore, the name that the rname parameter specifies must be the name of the queue to which you want to send the message (that is, sample.queue on the receiver workstation). rqmname is the queue manager name on the remote machine.
  1. In the MQSC command window, define a sender channel. Enter the following command: 
         define channel(QMSENDER.QMRECEIVER) chltype(sdr) conname("con-name(port)") xmitq(TRANSMITQSENDER) trptype(tcp)
Where: 
  con-name is the TCP/IP address of the receiver workstation.
port  is the port on which the listener will be running on the receiver machine, the default value is 1414.
  1. In the MQSC command window, stop MQSC. Stop MQSC. Enter the Command: end
You have now defined the following objects:
  • A default queue manager called QMSENDER
  • A transmission queue called TRANSMITQSENDER
  • A remote queue called LOCAL.DEF.OF.REMOTE.QUEUE
  • A sender channel called QMSENDER.QMRECEIVER

Setup of Receiver Workstation 
  1. Create a default queue manager called QMRECEIVER. At the command prompt, enter the following command:
crtmqm -q QMRECEIVER
Messages tell you that the queue manager is created, and that the default WebSphere® MQ objects are created.
  1. Start the queue manager. Enter the following command:
strmqm
A message tells you when the queue manager starts.
  1. Open a new command prompt window and enable MQSC commands. Enter the following command:
runmqsc
The message Starting WebSphere MQ Commands is displayed when MQSC starts. MQSC has no command prompt.
  1. In the MQSC window, define a local queue called SAMPLE.QUEUE. Enter the following command:
define qlocal(SAMPLE.QUEUE)
The message WebSphere MQ queue created is displayed when the queue is created.
  1. In the MQSC window, create a receiver channel. Enter the following command:
define channel(QMSENDER.QMRECEIVER) chltype(rcvr) trptype(tcp)
  1. In the MQSC window, start the default WebSphere MQ listener by entering the following command:
start listener(SYSTEM.DEFAULT.LISTENER.TCP)
  1. In the MQSC window, verify the listener process has started by executing the command:
display lsstatus(SYSTEM.DEFAULT.LISTENER.TCP)
  1. In the MQSC window, stop MQSC. Enter the following command:
end

You have now defined the following objects:
·         A default queue manager called QMRECEIVER
·         A queue called SAMPLE.QUEUE
·         A receiver channel called QMSENDER.QMRECEIVER

Starting Channel 
  1. If the queue managers on the two workstations have stopped for any reason, restart them now using the strmqm command.
  2. On the sender workstation, enable MQSC commands. Enter the following:
runmqsc
  1. Using the MQSC window, start the sender channel. Enter the following command:
start channel(QMSENDER.QMRECEIVER)
The receiver channel on the receiver workstation is started automatically when the sender channel starts.
  1. Using the MQSC window, stop MQSC. Enter the following command:
end

Testing  Communication between the Workstations 
  1. On the sender workstation, in a new command window, put a message on the queue by entering the following command from  /opt/mqm/samp/bin directory
amqsput LOCAL.DEF.OF.REMOTE.QUEUE
This puts the message to the local definition of the remote queue, which in turn specifies the name of the remote queue.
  1. Type the text message, then press Enter twice.
  2. On the receiver workstation, get the message from the queue by entering the following command from  /opt/mqm/samp/bin directory
amqsget SAMPLE.QUEUE
The sample program starts, and your message is displayed. After a short pause, the sample ends and the command prompt is displayed again.
Thus it proves the server to server communication by sending one message from the remote queue on the sender workstation to the local queue on the receiver workstation using XMITQ, Sender/Receiver Channels and Listener.

Command server


Using the command server

The command server is a WebSphere MQ component that works with the command processor component. Thecommand server reads request messages from the system-command input queue, verifies them, and passes the valid ones as commands to the command processor. The command processor processes the commands and puts any replies as reply messages on to the reply-to queue that you specify. The first reply message contains theuser message CSQN205I. See Interpreting the replies for more information. The command server also processes channel initiator and queue-sharing group commands, wherever they are issued from.

                                                                                       

Using the command server

The command server is a WebSphere MQ component that works with the command processor component. The command server reads request messages from the system-command input queue, verifies them, and passes the valid ones as commands to the command processor. The command processor processes the commands and puts any replies as reply messages on to the reply-to queue that you specify. The first reply message contains the user message CSQN205I. See Interpreting the replies for more information.

Identifying the queue manager that processes your commands

The queue manager that processes the commands you issue from an administration program is the queue manager that owns the system-command input queue that the message is put onto.

Starting the command server

Normally, the command server is started automatically when the queue manager is started. It becomes available as soon as the message CSQ9022I 'START QMGR' NORMAL COMPLETION is returned from the START QMGR command. The command server is stopped when all the connected tasks have been disconnected during the system termination phase.
You can control the command server yourself using the START CMDSERV and STOP CMDSERV commands. To prevent the command server starting automatically when WebSphere MQ is restarted, you can add a STOP CMDSERV command to your CSQINP1 or CSQINP2 initialization data sets.
The STOP CMDSERV command stops the command server as soon as it has finished processing the current message, or immediately if no messages are being processed.
If the command server has been stopped by a STOP CMDSERV command in the program, no other commands from the program can be processed. To restart the command server, you must issue a START CMDSERV command from the z/OS console.
If you stop and restart the command server while the queue manager is running, all the messages that are on the system-command input queue when the command server stops are processed when the command server is restarted. However, if you stop and restart the queue manager after the command server is stopped, only the persistent messages on the system-command input queue are processed when the command server is restarted. All nonpersistent messages on the system-command input queue are lost.

Sending commands to the command server

For each command, you build a message containing the command, then put it onto the system-command input queue.

Building a message that includes WebSphere MQ commands

You can incorporate WebSphere MQ commands in an application program by building request messages that include the required commands. For each such command you:
1.    Create a buffer containing a character string representing the command.
2.    Issue an MQPUT call specifying the buffer name in the buffer parameter of the call.
The simplest way to do this in C is to define a buffer using 'char'. For example:


 char message_buffer[ ] = "ALTER QLOCAL(SALES) PUT(ENABLED)";
When you build a command, use a null-terminated character string. Do not specify a command prefix string (CPF) at the start of a command defined in this way. This means that you do not have to alter your command scripts if you want to run them on another queue manager. However, you must take into account that a CPF is included in any response messages that are put onto the reply-to queue.
The command server folds all lowercase characters to uppercase unless they are inside single quotes.
Commands can be any length up to a maximum 32 762 characters.

Putting messages on the system-command input queue

Use the MQPUT call to put request messages containing commands on the system-command input queue. In this call you specify the name of the reply-to queue that you have already opened.
To use the MQPUT call:
1.    Set these MQPUT parameters:
Hconn
The connection handle returned by the MQCONN or MQCONNX call.
Hobj
The object handle returned by the MQOPEN call for the system-command input queue.
BufferLength
The length of the formatted command.
Buffer
The name of the buffer containing the command.
2.    Set these MQMD fields:
MsgType
MQMT_REQUEST
ReplyToQ
Name of your reply-to queue.
ReplyToQMgr
If you want replies sent to your local queue manager, leave this field blank. If you want your WebSphere MQ commands to be sent to a remote queue manager, put its name here. You must also have the correct queues and links set up, as described in the WebSphere MQ Intercommunication manual.
3.    Set any other MQMD fields, as required. If you are not using the same code page as the queue manager, set CodedCharSetId as appropriate, and set Format to MQFMT_STRING, so that the command server can convert the message. You should normally use nonpersistent messages for commands.
4.    Set any PutMsgOpts options, as required.
If you specify MQPMO_SYNCPOINT (the default), you must follow the MQPUT call with a syncpoint call.

Using MQPUT1 and the system-command input queue

If you want to put just one message on the system-command input queue, you can use the MQPUT1 call. This call combines the functions of an MQOPEN, followed by an MQPUT of one message, followed by anMQCLOSE, all in one call. If you use this call, modify the parameters accordingly. 

Listeners


                                               
How to create a listener for a Message Queue

Sample: Queue Manager = QM_ORANGE

Run the message queue manager script command tool

[mqm@websphere2 ~]$ runmqsc
5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM_ORANGE.

Create the listener

DEFINE LISTENER(qm_orange.listener) TRPTYPE (TCP) PORT(60000)
1 : DEFINE LISTENER(qm_orange.listener) TRPTYPE (TCP) PORT(60000)
AMQ8626: WebSphere MQ listener created.
start listener(qm_orange.listener)
2 : start listener(qm_orange.listener)
AMQ8021: Request to start WebSphere MQ Listener accepted.
end
3 : end
2 MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.

Check to see if the listener is running as a process

[mqm@websphere2 ~]$ ps -ef | grep qm_orange.listener
mqm 12809 12709 0 22:18 pts/2 00:00:00 grep qm_orange.listener

Check to ensure port is an open (any adapter i.e not bound to any specific adapter) listener

[mqm@websphere2 ~]$ netstat -an | grep 60000
tcp 0 0 :::60000 :::* LISTEN

Create Channel

The server-connection channel, called SYSTEM.ADMIN.SVRCONN, exists on every remote queue manager. This channel is mandatory for every remote queue manager being administered. Without it, remote administration is not possible. 

You can create the channel using the following MQSC command: 
DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN) 
This command creates a basic channel definition. If you want a more sophisticated definition (to set up security, for example), you need additional parameters.

[mqm@websphere2 ~]$ runmqsc
5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM_ORANGE.

DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
1 : DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
AMQ8014: WebSphere MQ channel created.
end
2 : end
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

Sunday, January 2, 2011

How to uninstall and remove your WebSphere MQ on Linux

Today I wanted to un-install WebSphere MQ on Fedora 6. I had installed MQ yesterday and I wanted to remove it. This article is a log of the process I followed.

I logged into my Fedora 6 box as root

Remove install RPMs

I used root@websphere mwinstall]# rpm -ivh IBMJava2-SDK-1.4.2-0.0.i386.rpm to install, so I queried to find out what the software name of the rpm was as you cannot use the rpm filename that you used to install the rpm.

[root@websphere mq]# rpm -qa | grep IBM
IBMJava2-SDK-1.4.2-0.0

rpm -e IBMJava2-SDK-1.4.2-0.0

This worked however for the other rpm;s I had to remove the fix-packs first

Remove fix pack rpm's

I used rpm -ivh IBMJava2-142-ia32-SDK-1.4.2-6.0.i386.rpm to apply fix pack
So I used rpm -e IBMJava2-142-ia32-SDK-1.4.2-6.0

install: rpm -ivh MQSeriesRuntime-U809950-6.0.2-2.i386.rpm
remove: rpm -e MQSeriesRuntime-U809950-6.0.2-2

install: rpm -ivh MQSeriesServer-U809950-6.0.2-2.i386.rpm
remove: rpm -e MQSeriesServer-U809950-6.0.2-2

install: rpm -ivh MQSeriesJava-U809950-6.0.2-2.i386.rpm
remove: rpm -e MQSeriesJava-U809950-6.0.2-2

Remove base rpm's

I had to do in this order

rpm -e MQSeriesJava-6.0.0-0

rpm -e MQSeriesServer-6.0.0-0

rpm -e MQSeriesRuntime-6.0.0-0

Query to make sure they have all been removed

rpm -qa | grep MQSeries

Remove MQ directories

/opt/mqm

/var/mqm