WebSphere MQ for Solaris: Installation

WebSphere MQ 5.3 for Solaris
Installation

^Tips

Contents

Overview
Optional software
Pre-Install
Install
Verify the server installation
Verify the server installation using JMS Postcard
Install the client
Verify the client
Apply maintenance
Uninstall

Links

WebSphere MQ information
Download WebSphere MQ for Solaris V5.3
SupportPacs
Whitepapers and migration documents

Overview

Install WebSphere MQ on every box that is going to run WebSphere Application Server.

108827.12
111177.06

One can display installed patches by running:
showrev -p patchnumber
If you are going to use the SSL support provided by WebSphere MQ, verify the following patches:

108434.02
111327.02
108991
108528

Optional software

Compilers

Sun Workshop compiler C V5.0
Sun Workshop compiler C++ V5.0
Forte C 6 (Sun Workshop 6 C)
Forte C++ 6 (Sun Workshop 6 C++) including update 2
Micro Focus Server express V2.0.10
Java 2 Standard Edition, for the Solaris Operating Environment, SDK 1.3.1

Transaction monitors

BEA TUXEDO V6.4 and V6.5
WebSphere Application Server V4.0
TXSeries. for Solaris V4.3

WebSphere MQ for Solaris, V5.3 supports WebSphere Application Server as an XA coordinator.

Databases

DB2® Universal Database V7.1 or V7.2
Oracle 8iR3 (8.1.7) and Oracle 9i
Sybase V12 or V12.5:

DCE

IBM DCE V3.1 for Sun Solaris 7
IBM DCE V3.2 for Sun Solaris 8

To run the DCE send, receive, or message exits supplied by WebSphere MQ, use a DCE product that supports DES data encryption.
DCE names and security modules are provided with WebSphere MQ for Solaris, V5.3. Note that if you install the WebSphere MQ DCE extensions, you will not be able to use SSL channels.

Java

To use JMS, JRE V. 1.3 or later is required. This is generally provided by WAS.

Pre-Install

Create WebSphere MQ file systems

The installation directory for the WebSphere MQ product code is /opt/mqm.
Working data is stored in /var/mqm.
These directories are fixed.
Install WebSphere MQ for Solaris in /opt/mqm.
If you cannot install the product code in /opt/mqm, you can do one of the following...

Create a new file system and mount it as /opt/mqm.
Create a new directory anywhere on your machine, and create a symbolic link from /opt/mqm to this new directory. For example:
mkdir /bigdisk/mqm
ln -s /bigdisk/mqm /opt/mqm

Always remember the first rule of installing software: check permissions and pathing if you run into intractable problems. For example, to open up directory permissions:
chmod 777 directory_name

Create and mount a file system on a separate volume called /var/mqm. Having a separate volume protects other system activity if a large amount of WebSphere MQ work fills the file system fills to 100%. >To determine the size of the /var/mqm file system for a server installation, consider:

The maximum number of messages in the system at one time
Contingency for message buildups.
The average size of the message data, plus 500 bytes for the message header
The number of queues
The size of log files and error messages
The amount of SSL trace that is written to /var/mqm/trace.

Allow 50 MB as a minimum for a WebSphere MQ server. You need less space in /var/mqm for a WebSphere MQ client, typically 15 MB.

Create separate file systems for working data

One can also create separate file systems for your log data (/var/mqm/log) and error files (/var/mqm/errors). If possible, store log files on a different physical volume from the WebSphere MQ queues (/var/mqm). This ensures data integrity in the case of a hardware failure.
To use individual queues that hold more than 2 GB of data, mount the file system with the largefiles option.
The size of the log file depends on the log settings that you use. The size we recommend is for circular logging using the default settings. For further information on log sizes see the WebSphere MQ System Administration Guide.

Create the user ID and group
Create the following user and group IDs installing WebSphere MQ.
Both user ID and group ID must be set to mqm. For stand-alone machines, you can create the new user ID and group IDs locally; for machines administered in a network information services (NIS) domain, an administrator must create the IDs on the NIS master server machine.
useradd mqm
useradd mqbrkrs
groupadd mqm
groupadd mqbrkrs

Add the above users to the each other's groups in /etc/group. Also add the root user to the mqm and mqbrkrs groups.

Displaying messages in your national language
Messages in U.S. English are always available. If you require messages in a different language, ensure that:

You install the appropriate message catalog.
Your NLSPATH environment variable includes the appropriate directory. For example, to select messages in German use the following:
export LANG=de
export NLSPATH=/usr/lib/locale/%L/LC_MESSAGES/%N

Install

Kernel configuration

To view current kernel settings:
sysdef -i

To change the values, add a set parameter = value line to the /etc/system file.

Do not change the value of shmmin from the system default value.
Semaphore and swap usage does not vary significantly with message rate or persistence.
set shmsys:shminfo_shmmax = 4294967295
set shmsys:shminfo_shmseg = 1024
set shmmin:shminfo_shmmin = 1
set shmsys:shminfo_shmmni = 1024
set semsys:seminfo_semmni = 1024
set semsys:seminfo_semaem = 16384
set semsys:seminfo_semvmx = 32767
set semsys:seminfo_semmap = 1026
set semsys:seminfo_semmns = 16384
set semsys:seminfo_semmsl = 100
set semsys:seminfo_semopm = 100
set semsys:seminfo_semmnu = 2048
set semsys:seminfo_semume = 256
set msgsys:msginfo_msgmni = 50
set msgsys:msginfo_msgmap = 1026
set msgsys:msginfo_msgmax = 4096
set msgsys:msginfo_msgmnb = 4096

WebSphere MQ queue managers are generally independent of each other. Therefore system kernel parameters, for example shmmni, semmni, semmns, and semmnu need to allow for the number of queue managers in the system.
You need to set the kernel parameters set msgsys:msginfo_msgmap and msgsys:msginfo_msgmax only if you are using circular logging.

File descriptors

Solaris has a low default system soft limit for the number of file descriptors. When running a multi-threaded process, you might reach the soft limit for file descriptors. This gives you the WebSphere MQ reason code MQRC_UNEXPECTED_ERROR (2195) and, if there are enough file descriptors, a WebSphere MQ FFST. file.
To avoid this problem you can increase the system soft limit for the number of file descriptors. To do this, edit the /etc/system file and change the value of the system soft limit to match the system hard limit (1024) by adding set rlim_fd_cur=1024.
Additionally, if you are running WebSphere MQ under the Lotus® Domino. server, you can reduce the number of active server threads in the Domino HTTP server process by opening the server Name and address book, and reducing the Number active threads value on the server document to between 50 and 60.

Installation procedure

Log in as root.
Run the mqlicense.sh script to accept the license:
mqlicense.sh

If you use the Solaris volume manager to mount the CD, the command to accept the license is:
mqlicense.sh

To view a text-only version of the license:
mqlicense.sh -text_only

The license is displayed.
Pay particular attention to the section that outlines the number of license units you need, because you will be asked later to confirm that you have purchased sufficient license units for the number of processors that you have in your computer. If you accept the license, the installation continues. If you do not accept the license, you cannot continue the installation process.
If you are installing from a downloaded distribution, install by running:

pkgadd -d /path/to/MQ/distribution

During the installation process select yes if you are prompted to choose whether to install certain WebSphere MQ files as setuid/setgid files.

Set the number number of processors. For example:

setmqcap 20

The first time that you start a queue manager on this machine, if you have not already run setmqcapcommand, you get a warning saying Purchased license units not set. If you have already run setmqcap but entered an incorrect value, you get the warning Insufficient license units. To correct, run setmqcap.

CCSID

The Coded Character Set Identifier (CCSID) is fixed when you create a queue manager, determined by the locale used to run crtmqm. command. For US english:
export LANG=en_US.ISO8859-1 ISO8859-1 819

To modify an existing queue manager CCSID, follow this procedure:

Enter an runmqsc session:
runmqsc

Display the existing queue manager CCSID, using the MQSC command:
display qmgr ccsid

Change the CCSID to the new CCSID with the MQSC command: alter qmgr ccsid (new.ccsid) where new.ccsid is the number of the new CCSID.
Stop MQSC:
end

Stop the queue manager, and then restart it and any channels that it uses.

User exits

Check that your user exits are linked with threaded libraries before using them on this version of the product.

Verify the server installation

One can verify a WebSphere MQ server installation at different levels:

local (stand-alone) installation that has no communication links with other WebSphere MQ installations.
includes communication links to other WebSphere MQ installations.

Install a queue manager and a queue

Log on as user "mqm".
Create a default queue manager called MY.QUEUE:
crtmqm -q MY.QUEUE

You will see messages telling you that the queue manager has been created, and that the default WebSphere MQ objects have been created.
Start the queue manager
strmqm

A message tells you when the queue manager has started. The first time that you start a queue manager on a machine, you might get one of the following warnings:
Purchased license units not set (use setmqcap) or Insufficient license units.

Enable MQSC commands:
runmqsc

A message tells you that an MQSC session has started. MQSC has no command prompt.
Define a local queue called MY.LOCAL.QUEUE:
define qlocal (MY.LOCAL.QUEUE)

A message tells you when the queue has been created.
Stop MQSC
end

Test the installation

To test the queue manager and queue, use the amqsput sample program to put a message on the queue, and the amqsget sample program to get the message back from the queue:

Change into the /opt/mqm/samp/bin directory, which contains the sample programs.
Put a message on the queue:
./amqsput MY.LOCAL.QUEUE

The following messages are displayed:
Sample amqsput0 start
target queue is MY.LOCAL.QUEUE

Some distributions of MQ have a crippled amqsput. To enable:

cp -r /usr/localMQ/mqm/root/opt/mqm/samp/bin/* /opt/mqm/samp/bin
cd /opt/mqm/samp/bin
chmod 777 *
cd /usr/local/bin
Run the following in a script:
for i in `echo amqsaxe amqsbcg amqsbcgc amqsblst amqscic0 amqscnxc amqsdlq amqsech amqsechc amqsgbr amqsgbrc amqsget amqsgetc_ d amqsgetc_nd amqsgrm amqsgrmc amqsinq amqsinqc amqsprm amqsprmc amqsptl amqsptlc amqsput amqsputc_d amqsputc_nd amqsqrm amqsr eq amqsreqc amqsset amqssetc amqstrg amqstrgc amqswlm amqsxae0 amqsxrm as`
do
echo $i
ln -s /opt/mqm/samp/bin/$i /usr/bin/$i
done

Also note that there appears to be a bug where the verification will not work unless the queue name is in uppercase. However, websphere appserver does not care. It can have any name....
Type some message text, on one or more lines, followed by a blank line. The following message is displayed:
Sample amqsput0 end

Your message is now on the queue and the command prompt is displayed again.
Get the message from the queue:
./amqsget MY.LOCAL.QUEUE

The sample program starts, and your message is displayed. After a pause, the sample ends and the command prompt is displayed again.
You have now successfully verified the local installation.

Verify a server-to-server installation

Test communications between sender and receiver using the sample programs, which must installed on both workstations.
MQ object definitions are case-sensitive. Any text entered as an MQSC command in lowercase is converted automatically to uppercase unless you enclose it in single quotation marks.
Set up the sender workstation

Create a default queue manager called DEFAULT.QUEUE:
crtmqm -q DEFAULT.QUEUE

Messages tell you that the queue manager has been created, and that the default WebSphere MQ objects have been created.
Start the queue manager
strmqm

A message tells you when the queue manager has started.
The first time that you start a queue manager on a machine, you might get one of the following warnings:
Purchased license units not set (use setmqcap) or Insufficient license units.

Start MQSC commands:
runmqsc

A message tells you that an MQSC session has started. MQSC has no command prompt.
Define a local queue, called TRANSMIT1.QUEUE, to be used as a transmission queue:
define qlocal (transmit1.queue) usage (xmitq)

A message tells you when the queue has been created.
Define a local definition of the remote queue:
define qremote (local.def.of.remote.queue) rname (MY.LOCAL.QUEUE) +
rqmname (.MY.QUEUE.) xmitq (transmit1.queue)

The name specified by the RNAME parameter must be the same as the name of the queue to which you are sending the message (MY.LOCAL.QUEUE on the receiver workstation).
Define a sender channel:
define channel (first.channel) chltype (sdr) +
conname (.con-name(port).) xmitq (transmit1.queue) trptype (tcp)

The value con-name is the TCP address of the receiver workstation, and port is the port name, with 1414 as default.
Stop MQSC:
end

Set up the receiver workstation

Create a default queue manager called MY.QUEUE:
crtmqm -q MY.QUEUE

Messages tell you that the queue manager has been created, and that the default WebSphere MQ objects have been created.
Start the queue manager:
strmqm

A message tells you when the queue manager has started. The first time that you start a queue manager on a machine, you might get one of the following warnings:
Purchased license units not set (use setmqcap) or Insufficient license units.

Start a WebSphere MQ listener as a background task:
runmqlsr -t tcp &

One can use the -p parameter to specify the number of a port that the listener should listen on. If you do not specify it, the default of 1414 is used. The port number must be the same as the one that you specify when setting up the sender.
Enable MQSC commands:
runmqsc

A message tells you that an MQSC session has started. MQSC has no command prompt.
Define a local queue called MY.LOCAL.QUEUE:
define qlocal (MY.LOCAL.QUEUE)

A message tells you when the queue has been created.
Define a receiver channel:
define channel (first.channel) chltype (rcvr) trptype (tcp)

A message tells you when the channel has been created.
Stop MQSC:
end

Use the amqsput sample program to put a message from the sender workstation to a queue at the receiver, and the amqsget sample program on the receiver workstation to get the message from the queue:

If the queue managers on the two workstations have stopped, restart them now:
strmqm

On the sender workstation, start the sender channel as a background task by entering:
runmqchl -c FIRST.CHANNEL -m DEFAULT.QUEUE &

The receiver channel on the receiver workstation starts automatically when the sender channel starts.
On the sender workstation, change into the /opt/mqm/samp/bin directory, which contains the sample programs.
To put a message on the local definition of the remote queue (which in turn specifies the name of the remote queue), use:
./amqsput LOCAL.DEF.OF.REMOTE.QUEUE

You will see the following:
Sample amqsput0 start
target queue is LOCAL.DEF.OF.REMOTE.QUEUE

Type some message text on one or more lines, followed by a blank line. You will see the following:
Sample amqsput0 end

Your message is now on the queue and the command prompt is displayed again.
On the receiver workstation, change into the /opt/mqm/samp/bin directory, which contains the sample programs.
To get the message from the queue at the receiver:
./amqsget MY.LOCAL.QUEUE

The sample program starts, and your message is displayed. After a pause, the sample ends and the command prompt is displayed again. You have now successfully verified the server-to-server installation.

Verify the server installation using JMS Postcard

To use JMS Postcard, install the optional Java Messaging feature of WebSphere MQ, and have a working JRE (Java Runtime Environment).
To use font and color settings different from the JVM defaults, change the Postcard.ini file.
Use JMS Postcard application to verify that WebSphere MQ is successfully installed, the associated communication links are working properly, and that WebSphere MQ Java Messaging support is successfully installed.
One can use JMS Postcard to verify a local installation (which does not have any communication links with other WebSphere MQ installations).
One can also use JMS Postcard to verify communication between your machine and the machine of another named user, where that machine is running WebSphere MQ and using TCP/IP. Therefore, you can use JMS Postcard to verify that you can communicate with another server. To use JMS Postcard for this type of verification, either both machines must be in the same cluster (the simplest method), or configure channels to communicate between the two machines
To ensure that both machines are part of the same cluster, do one of the following:

Run the JMS Postcard for the first time on each machine. The JMS Postcard detects that there are no local queue managers defined for that machine, and displays the Default Configuration wizard so that you can create the default queue managers and link them to the default cluster.
Create your own queue managers on both machines, create a cluster, and ensure that the queue managers that you create on each machine belong to the same cluster.

One can use the JMS Postcard with existing queue managers, as long as both queue managers belong to the same cluster, or communication channels have been configured between the queue managers. Alternatively, you can exchange postcards between two queues that are using the same queue manager as their mailbox.

Set up the system to run the JMS Postcard

Before you can run the JMS Postcard , ensure that:

You are a member of the WebSphere MQ administrators group (mqm).
A supported Java Virtual Machine is installed on your system and suitably configured in the system path so that the java command can be executed.
The required environment variables are defined. Define the environment variables as follows:

Log on as user mqm.
Add the required environment variables to the .profile file using a text editor.
CLASSPATH=/opt/mqm/java/lib/com.ibm.mq.jar:$CLASSPATH
CLASSPATH=/opt/mqm/java/lib/com.ibm.mqjms.jar:$CLASSPATH
CLASSPATH=/opt/mqm/java/lib/connector.jar:$CLASSPATH
CLASSPATH=/opt/mqm/java/lib/jms.jar:$CLASSPATH
CLASSPATH=/opt/mqm/java/lib/jndi.jar:$CLASSPATH
CLASSPATH=/opt/mqm/java/lib/jta.jar:$CLASSPATH
CLASSPATH=/opt/mqm/java:$CLASSPATH
MQ_JAVA_INSTALL_PATH=/opt/mqm/java
MQ_JAVA_DATA_PATH=/var/mqm
LD_LIBRARY_PATH=/opt/mqm/java/lib
PATH=$PATH:/opt/java1.3/bin >

Using the JMS Postcard to verify a local installation

A queue manager that can be used as a mailbox must be already set up.
This queue manager can be either the default queue manager, which is set up automatically when you run the Default Configuration wizard, or another queue manager that you have set up yourself.
To verify that the local installation is working, you can use the JMS Postcard. This application allows you to create two postcards on the same machine and send messages between them, verifying that WebSphere MQ messaging is working correctly on the machine, and that WebSphere MQ Java
Messaging support is successfully installed.
To use font and color settings different from the JVM defaults, change Postcard.ini

Change directory to /opt/mqm/java/bin
Run the Postcard shell script. If there are no queue managers on your machine, the Incomplete Default Configuration window is displayed. From here you can either run the Default Configuration wizard to create a queue manager to use with JMS Postcard, or you can close the application.
The JMS Postcard - Sign On window is displayed. Type in a nickname to use to send messages within the postcard application (for example, user1).
If the only queue manager on your machine is the default queue manager that you created by running the Default Configuration wizard, this queue manager is used as your mailbox for postcards. Click OK to display your first postcard.
Select the queue manager to use as the mailbox:

you have created one or more of your own queue managers, but you have not run the Default Configuration wizard, select the appropriate queue manager from the list displayed.
you have run the Default Configuration wizard and you want to use the default queue manager, but there is more than one queue manager on your machine, select the Advanced checkbox, then select Use Default Configuration as mailbox.
you have run the Default Configuration wizard and also created one or more of your own queue managers, and you do not want to use the default queue manager, select the Advanced checkbox, select Choose queue manager as mailbox, then select the appropriate queue manager from the list displayed.

When your selection is complete, click OK to display your first postcard window.
Run the Postcard shell script again. This opens a second postcard window.
The JMS Postcard - Sign On panel is displayed again. Type in a second nickname to use to send messages within the Postcard application (for example, user2).
Repeat the selection of the queue manager that you want to use as the mailbox. The queue manager you select for this second postcard must either be in the same cluster as the queue manager for the first postcard, or communication links must have been set up between them.
You now have two postcards, one with the nickname user1 and one with the nickname user2.
In one of the postcards (for example, user1), type some message text in the Message: field and the nickname of the other postcard (for example, user2) in the To: field.
Because the sender and receiver are on the same machine, you do not need to type anything in the On: field.
If the receiver is on a different machine, and is using the default queue manager as the mailbox, you need to type the recipient.s machine in the On: field.
If the receiver is on a different machine, and is not using the default queue manager as the mailbox, you need to type the recipient.s queue manager in the On: field.
Click Send.
The Postcards sent and received area of the postcard shows details of the message. In the sending postcard, the message is displayed as sent. In the receiving postcard, the message is displayed as received.
From the receiving postcard, double-click the message in the Postcards sent and received area to view it.

If you complete this procedure successfully, it verifies that WebSphere MQ is working correctly, and that the WebSphere MQ Java messaging support is successfully installed.

Postcard application

One can use the JMS Postcard application to verify communication between machines. Before starting:

Make sure that TCP/IP and WebSphere MQ are installed on both machines.
Check that either of the following apply:

Both machines are in the same cluster (this is the simplest method)
You have configured channels to communicate between the two machines

To verify that the communication between two machines, the sender of the message and the receiver, are working correctly, and that the WebSphere MQ Java messaging support is successfully installed, you can use the JMS Postcard application.
On the sender machine:

Change directory to /opt/mqm/java/bin
Run the Postcard shell script. If there are no queue managers on your machine, the Incomplete Default Configuration window is displayed. From here you can either run the Default Configuration wizard to create a queue manager to use with the JMS Postcard application, or you can close the application.
The JMS Postcard - Sign On window is displayed. Type in a nickname to use to send messages within the Postcard application (for example, user1). If the only queue manager on your machine is the default queue manager that you created by running the Default Configuration wizard, this queue manager is used as your mailbox for postcards. Click OK to display your postcard.
Select the queue manager to use as the mailbox:

If you have created one or more of your own queue managers, but you have not run the Default Configuration wizard, select the appropriate queue manager from the list displayed.
If you have run the Default Configuration wizard and you want to use the default queue manager, but there is more than one queue manager on your machine, select the Advanced checkbox, then select Use Default Configuration as mailbox.
If you have run the Default Configuration wizard and also created one or more of your own queue managers, and you do not want to use the default queue manager, select the Advanced checkbox, select Choose queue manager as mailbox, then select the appropriate queue manager from the list displayed.
When your selection is complete, click OK to display your postcard.

Type in the following:

Some message text in the Message: field.
The nickname of the recipient in the To: field.
If the receiver is using the default queue manager as the mailbox, the machine name of the recipient in the On: field. If the receiver is not using the default queue manager, type the queue manager name in the On: field.

Click Send.

On the receiver machine:

To receive the message, run the Postcard shell script.
If there are no queue managers on your machine, the Incomplete Default Configuration window is displayed. From here you can either run the Default Configuration wizard to create a queue manager to use with the JMS Postcard application, or you can close the application.
Type in the nickname of the recipient, select the queue manager to use as the mailbox, then click OK to display the JMS Postcard window.
In the Postcards sent and received area of the postcard, details of the new message are displayed. The message is displayed as received. When this message arrives, this verifies that WebSphere MQ and the Java messaging support are correctly installed and that your communication link between the two machines is working correctly.

When all installation and verification is complete, you are ready to start using WebSphere MQ

Install the WebSphere MQ for Solaris client

There are two types of clients in WebSphere MQ for Solaris, V5.3:

Standard client This is the standard WebSphere MQ client. Use this client if you do not require Secure Sockets Layer (SSL) support.
Client with SSL
This is the standard WebSphere MQ client with additional code to allow you to use SSL support. One can install the client with SSL from either the client or the server CD.

Installation procedure

Log in as root.
Run the mqlicense.sh script to accept the license:

For the WebSphere MQ client without the WebSphere MQ SSL support:
MQ53Client1/solarisMQClient/mqlicense.sh

For the WebSphere MQ client with the WebSphere MQ SSL support:
MQ53Client1/solarisMQClientwithSSL/mqlicense.sh

The license is displayed. If you accept the license, the installation continues. If you do not accept the license, you cannot continue the installation process.
After running mqlicense.sh as user root, run "setmqcap 20" as user mqm
To start the installation process:

For the WebSphere MQ client without the WebSphere MQ SSL support:
pkgadd -d MQ53Client1/solarisMQClient/mqs530.img

For the WebSphere MQ client with the WebSphere MQ SSL support:
pkgadd -d MQ53Client1/solarisMQClientwithSSL/mqs530.img

You are presented with a list of the packages that are available. Enter the number of the mqm package.
You receive a number of messages, after which a list of components is displayed. Enter the numbers of the components that you require separated by spaces or commas.
Answer y to the other questions.
A message tells you when installation is complete. Enter q to exit the pkgadd program.

Migrating to and from the WebSphere MQ SSL support

To upgrade a WebSphere MQ client without the SSL support to one with the SSL support, install the image from the directory on WebSphere MQ Client CD-ROM 1 that contains the set of client components with the WebSphere MQ SSL support. When you are asked whether you really want to install the image, answer .yes.. To downgrade a WebSphere MQ client with the SSL support to one without the SSL support, remove all the components of the client and install the client again, this time using the set of client components without the WebSphere MQ SSL support.

Installing the client on the same machine as a server

To install a WebSphere MQ for Solaris client on a server machine, use the WebSphere MQ Server CD-ROM. Choose the Client component on the Server CD-ROM to install the client code on the server machine. Do not use the WebSphere MQ Clients CD-ROM.
You might install components from the WebSphere MQ Clients CD-ROM onto a machine, and subsequently want to install the WebSphere MQ Server component on the same machine. If so, first remove from the machine any components that you installed from the WebSphere MQ Clients CD-ROM. Then use the WebSphere MQ Server CD-ROM to install the server, client, and any other components that you need.
If you install a WebSphere MQ client on the same machine as a WebSphere MQ server, the client is not connected to the server automatically. Configure the communication channel (an MQI channel) between the client and the server.

Verify the client installation

This chapter describes how to verify that you have correctly installed and configured the WebSphere MQ for Solaris client. To do this you use a client/server installation that includes communication links between a WebSphere MQ server machine and the WebSphere MQ client.

Verify the installation

To verify your WebSphere MQ client installation, you need a workstation set up as a WebSphere MQ server, in addition to your client workstation. One can then use sample programs (which must be installed on the client) to test communications between the client and server.
The verification procedure assumes that:

TCP/IP is configured and initialized on both the server and the client machines.
The WebSphere MQ server product is installed on a UNIX machine; if this is not the case, some of the commands will be different (for details, refer to the WebSphere MQ Clients book).

WebSphere MQ object definitions are case-sensitive. Any text entered as an MQSC command in lowercase is converted automatically to uppercase unless you enclose it in single quotation marks. Make sure that you type the examples exactly as shown.

Set up the server workstation

Create a default queue manager called DEFAULT.QUEUE:
crtmqm -q DEFAULT.QUEUE

Messages tell you that the queue manager has been created, and that the default WebSphere MQ objects have been created.
Start the queue manager:
strmqm

A message tells you when the queue manager has started.
Enable MQSC commands:
runmqsc

A message tells you that an MQSC session has started. MQSC has no command prompt.
Define a local queue called QUEUE1:
define qlocal(queue1)

A message tells you when the queue has been created.
Define a server-connection channel: line:
define channel(channel1) chltype(svrconn) \
trptype(tcp) mcauser(.mqm.)

A message tells you when the channel has been created.
Stop MQSC:
end

Start a WebSphere MQ listener:
runmqlsr -t tcp &

One can use the -p parameter to specify the number of a port that the listener should listen on. If you do not specify it, the default of 1414 is used. The port number must be the same as the one that you specify when setting up the client.

Set up the client workstation

When a WebSphere MQ application is run on the WebSphere MQ client, the following information is required:

The name of the MQI channel that connects the client to the server
The communications protocol
The address of the server

You provide this information by defining a client-connection channel with the name used for the server-connection channel defined on the server. This example uses the MQSERVER environment variable to define the client-connection channel. Before starting, use the ping command to check that your TCP/IP software is correctly configured, and that your WebSphere MQ client and server TCP/IP sessions have been initialized. From the client, enter:
ping server-address

or
ping IP_address

To create a client-connection channel, set the MQSERVER environment variable as follows...
export MQSERVER=CHANNEL1/TCP/'server-address(port)'

...where CHANNEL1 is the name of the server-connection channel already defined on the server.
port is optional and is the TCP/IP port number that the server is listening on. If you do not give a port number, WebSphere MQ uses:

The one specified in the QM.INI file.
If no value is specified in the QM.INI file, WebSphere MQ uses the port number identified in the TCP/IP services file for the service name WebSphere MQ. If this entry in the services file does not exist, a default value of 1414 is used.

The client and server listener program must use the same port number.

Test communication between the workstations

On the WebSphere MQ client workstation, use the amqsputc sample program to put a message on the queue at the server workstation, and the amqsgetc sample program to get the message from the queue back to the client:

Change into the /opt/mqm/samp/bin directory, which contains the sample programs.
Put a message on the queue:
./amqsputc QUEUE1 DEFAULT.QUEUE

This displays the following messages:
Sample amqsput0 start
target queue is QUEUE1

Type some message text on one or more lines, followed by a blank line. This displays the following message: Sample amqsput0 end Your message is now on the queue and the command prompt is displayed again.
Get the message:
./amqsgetc QUEUE1 DEFAULT.QUEUE

The sample program starts and your message is displayed. After a pause, the sample ends and the command prompt is displayed again.

Applying maintenance to WebSphere MQ

A maintenance update in the form of a Program Temporary Fix (PTF), also known as a CSD (Corrective Service Diskette), is supplied on CD-ROM. PTFs can also be downloaded from:
www-306.ibm.com/software/integration/mqfamily/support/summary/

You must stop all WebSphere MQ activity, before installation of maintenance on WebSphere MQ for Solaris, by carrying out the following procedure:

Log in as root.
Use the endmqm command to stop all running queue managers.
Stop any listeners associated with the queue managers, using this command:
endmqlsr -m QMgrName

To check that you have stopped all of them, enter the following:
ps -ef | grep mq

Check that there are no processes listed that are running command lines beginning amq or runmq. Ignore any that start with amqi.

Install a PTF

A PTF requires hard disk space for installation. In addition, the installation process requires an identical amount of disk space to save the previous level. For example, a 16 MB PTF requires 32 MB of space. This allows a PTF to be removed, and the previous level to be restored automatically.
If disk space is limited, the backup can be suppressed by creating an empty flag file called MQPTF_NOSAVE in the directory /var/sadm/pkg. If this option is used, the previous level is not restored if a PTF is removed. To restore a previous level in this instance, reinstall the product and reapply a previous PTF image. To apply the PTF named patchname:

Log in as root.
Mount the CD-ROM.
Enter the following:
pkgadd -d mq_solaris/mqm/patchname

Restoring the previous service level

To restore the previous service level:

Log in as root.
Use the pkgrm command to remove the latest PTF from the system. For example, to remove PTF U469913:
pkgrm mqm-upd0x

where x is the service level number that you want to revert to.
Ignore any error messages of the form shared pathname not removed.
If you have installed a WebSphere MQ client, and the client was updated after installing the PTF that is being removed, specifically update your WebSphere MQ client installation again, after the PTF has been removed.

Uninstalling WebSphere MQ for Solaris

Log in as root.
Use the dspmq command to display the state of all the queue managers on the system.
Use the endmqm command to stop all running queue managers.
Stop any listeners associated with the queue managers, using the command:
endmqlsr -m QMgrName

To check that you have stopped all of them, enter the following:
ps -ef | grep mq

Check that there are no processes listed that are running command lines beginning amq or runmq. Ignore any that start with amqi.

Uninstallation procedure

To uninstall WebSphere MQ, log in as root and run:
pkgrm mqm

If any updates have been applied, remove them first. If for any reason the product was not properly installed, delete the files and directories contained in/opt/mqm.
After uninstalling WebSphere MQ, delete the /var/mqm directory tree (unless you are migrating to a later version of WebSphere MQ).

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

WebSphere MQ 5.3 for Solaris Installation

Contents

Links

Overview

Optional software

Compilers

Transaction monitors

Databases

DCE

Java

Pre-Install

Create WebSphere MQ file systems

Create separate file systems for working data

Create the user ID and group

Displaying messages in your national language

Install

Kernel configuration

File descriptors

Installation procedure

CCSID

User exits

Verify the server installation

Install a queue manager and a queue

Test the installation

Verify a server-to-server installation

Set up the sender workstation

Set up the receiver workstation

Verify the server installation using JMS Postcard

Set up the system to run the JMS Postcard

Using the JMS Postcard to verify a local installation

Postcard application

Install the WebSphere MQ for Solaris client

Installation procedure

Migrating to and from the WebSphere MQ SSL support

Installing the client on the same machine as a server

Verify the client installation

Verify the installation

Set up the server workstation

Set up the client workstation

Test communication between the workstations

Applying maintenance to WebSphere MQ

Install a PTF

Restoring the previous service level

Uninstalling WebSphere MQ for Solaris

Uninstallation procedure

WebSphere MQ 5.3 for Solaris
Installation