WebSphere MQ 5.3 for Solaris
Installation

 

Tips

 

Contents

  1. Overview
  2. Requirements
  3. Prepare to install
  4. Install
  5. Verify the server installation
  6. Verify the server installation using JMS Postcard
  7. Install the client
  8. Verify the client
  9. Apply maintenance
  10. Uninstall

 

Overview

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

WebSphere MQ information is available at:

http://www.ibm.com/software/mqseries

One can download WebSphere MQ for Solaris, V5.3 from:

www.developer.ibm.com/welcome/softmall.html

Review available SupportPacs:

http://www.ibm.com/software/mqseries/support

A list of MQ newsgroups can be found at:

http://www.ibm.com/software/mqseries/support/newsgroups

Whitepapers and migration documents can be found at:

http://www.ibm.com/software/mqseries/library

 

Hardware requirements

WebSphere MQ for Solaris, V5.3 runs on all Sun SPARC and Sun UltraSPARC desktop and server systems. Sun Solaris 8 (32 bit) is supported.

Verify the following patches are installed:

  1. 108827.12
  2. 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:
  1. 108434.02
  2. 111327.02
  3. 108991
  4. 108528

 

Optional software

 

Compilers

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

 

Transaction monitors

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

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

 

Databases

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

 

DCE

  1. IBM DCE V3.1 for Sun Solaris 7
  2. 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.

 

Prepare to install WebSphere MQ for Solaris

 

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:

or

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 a file system for the working data

Before installing WebSphere MQ for Solaris, 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:

  1. The maximum number of messages in the system at one time
  2. Contingency for message buildups.
  3. The average size of the message data, plus 500 bytes for the message header
  4. The number of queues
  5. The size of log files and error messages
  6. 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:

  1. You install the appropriate message catalog.

  2. 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 the WebSphere MQ for Solaris server

 

Kernel configuration

To view current kernel settings:

sysdef -i

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

  1. Do not change the value of shmmin from the system default value.

  2. 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

  3. 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.

  4. 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

  1. Log in as root.

  2. 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.

  3. 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.

  4. 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

See Code sets supported on WebSphere MQ for Solaris for more information on locales, languages, code sets, and CCSID.

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

  1. Enter an runmqsc session:

    runmqsc

  2. Display the existing queue manager CCSID, using the MQSC command:

    display qmgr ccsid

  3. 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.

  4. Stop MQSC:

    end

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

 

Change your locale on UNIX

You can use the executable locale to show your current locale.

In WAS the locale is inherited from the shell in which it is started.

syslog code page ccsid
iso8859-1 819
ibm-850 850
utf-8 1208

On Solaris, set the LANG and LC_ALL variables in /etc/default/init. On AIX and Linux, these variables are in /etc/environment. This task is not required on HP-UX.

 

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:

 

Install a queue manager and a queue

  1. Log on as user "mqm".

  2. 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.

  3. 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.

  4. Enable MQSC commands:

    runmqsc

    A message tells you that an MQSC session has started. MQSC has no command prompt.

  5. Define a local queue called MY.LOCAL.QUEUE:

    define qlocal (MY.LOCAL.QUEUE)

    A message tells you when the queue has been created.

  6. 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:

  1. Change into the /opt/mqm/samp/bin directory, which contains the sample programs.

  2. 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:

    1. cp -r /usr/localMQ/mqm/root/opt/mqm/samp/bin/* /opt/mqm/samp/bin
    2. cd /opt/mqm/samp/bin
    3. chmod 777 *
    4. cd /usr/local/bin
    5. 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....

  3. 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.

  4. 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

  1. 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.

  2. 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.

  3. Start MQSC commands:

    runmqsc

    A message tells you that an MQSC session has started. MQSC has no command prompt.

  4. 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.

  5. 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).

  6. 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.

  7. Stop MQSC:

    end

 

Set up the receiver workstation

  1. 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.

  2. 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.

  3. 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.

  4. Enable MQSC commands:

    runmqsc

    A message tells you that an MQSC session has started. MQSC has no command prompt.

  5. Define a local queue called MY.LOCAL.QUEUE:

    define qlocal (MY.LOCAL.QUEUE)

    A message tells you when the queue has been created.

  6. Define a receiver channel:

    define channel (first.channel) chltype (rcvr) trptype (tcp)

    A message tells you when the channel has been created.

  7. 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:

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

    strmqm

  2. 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.

  3. On the sender workstation, change into the /opt/mqm/samp/bin directory, which contains the sample programs.

  4. 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

  5. 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.

  6. On the receiver workstation, change into the /opt/mqm/samp/bin directory, which contains the sample programs.

  7. 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:

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:

 

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

  1. Change directory to /opt/mqm/java/bin

  2. 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.

  3. 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.

  4. 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.

  5. Run the Postcard shell script again. This opens a second postcard window.

  6. 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).

  7. 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.

  8. You now have two postcards, one with the nickname user1 and one with the nickname user2.

  9. 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.

  10. Click Send.

  11. 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.

  12. 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:

  1. Make sure that TCP/IP and WebSphere MQ are installed on both machines.

  2. 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:

  1. Change directory to /opt/mqm/java/bin

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. Click Send.

On the receiver machine:

  1. 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.

  2. 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.

  3. 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:

  1. Standard client This is the standard WebSphere MQ client. Use this client if you do not require Secure Sockets Layer (SSL) support.

  2. 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

  1. Log in as root.

  2. 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

  3. 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

  4. You are presented with a list of the packages that are available. Enter the number of the mqm package.

  5. 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.

  6. Answer y to the other questions.

  7. 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:

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

  1. 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.

  2. Start the queue manager:

    strmqm

    A message tells you when the queue manager has started.

  3. Enable MQSC commands:

    runmqsc

    A message tells you that an MQSC session has started. MQSC has no command prompt.

  4. Define a local queue called QUEUE1:

    define qlocal(queue1)

    A message tells you when the queue has been created.

  5. 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.

  6. Stop MQSC:

    end

  7. 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:

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 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:

  1. Change into the /opt/mqm/samp/bin directory, which contains the sample programs.

  2. Put a message on the queue:

    ./amqsputc QUEUE1 DEFAULT.QUEUE

    This displays the following messages:

    Sample amqsput0 start
    target queue is QUEUE1

  3. 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.

  4. 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:

  1. Log in as root.

  2. Use the endmqm command to stop all running queue managers.

  3. Stop any listeners associated with the queue managers, using this command:

    endmqlsr -m QMgrName

  4. 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:

  1. Log in as root.

  2. Mount the CD-ROM.

  3. Enter the following:

    pkgadd -d mq_solaris/mqm/patchname

 

Restoring the previous service level

To restore the previous service level:

  1. Log in as root.

  2. 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.

  3. 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

  1. Log in as root.

  2. Use the dspmq command to display the state of all the queue managers on the system.

  3. Use the endmqm command to stop all running queue managers.

  4. Stop any listeners associated with the queue managers, using the command:

    endmqlsr -m QMgrName

  5. 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).

 

Home

 

 

 

 

Posted By: Michael Pareene
Last Update: Michael Pareene

Confidential: Acme Corporation.
Copyright 2002. All Rights Reserved.