IBM Websphere MQ interview Questions : 

IBM Websphere MQ interview Questions Part
===============================================================


What is MQ and what does it do?

Ans. MQ stands for MESSAGE QUEUEING. WebSphere MQ allows application programs to use message queuing to participate in message-driven processing. Application programs can communicate across different platforms by using the appropriate message queuing software products.

What is the Message-driven process?

Ans . When messages arrive on a queue, they can automatically start an application using triggering. If necessary, the applications can be stopped when the message (or messages) have been processed.

What are the advantages of the MQ?

Ans. 1. Integration.

2. Asynchrony

3. Assured Delivery

4. Scalability.

How does it support the Integration?

Ans. Because the MQ is independent of the Operating System you use i.e. it may be Windows, Solaris,AIX.It is independent of the protocol (i.e. TCP/IP, LU6.2, SNA, NetBIOS, UDP).It is not required that both the sender and receiver should be running on the same platform

What is Asynchrony?

Ans. With message queuing, the exchange of messages between the sending and receiving programs is independent of time. This means that the sending and receiving application programs are decoupled; the sender can continue processing without having to wait for the receiver to acknowledge receipt of the message. The target application does not even have to be running when the message is sent. It can retrieve the message after it is has been started.

What are the hardware and Software requirements for MQ Installation in AIX?

Ans. WebSphere MQ for AIX, V5.3 runs on any machine that supports the AIX V4.3.3 PowerPC® 32.bit, or AIX® V5.1 Power 32 bit only operating system.

Disk Storage: Typical storage requirements are as follows:

1 Server installation: 50 MB

2. Client installation: 15 MB

3 Data storage (server): 50 MB

4. Data storage (client): 5 MB.

Software Requirements:

Operating system: The operating systems supported by WebSphere MQ for AIX, V5.3 are:

1. AIX V4.3.3, with PTF U472177, running in a 32 bit environment, on 32 or 64 bit hardware.

2. AIX V5.1, with PTFs U476879, U477366, U477367 and U477368, and APAR fix IY29345 running 32 bit kernel running on 32 or 64 bit hardware.

3. AIX V5.1, with PTF U476879, U477366, U477367 and U477368, and APAR fix IY29345 running 64 bit kernel running on 64 bit hardware.

Connectivity The network protocols supported by WebSphere MQ for AIX, V5.3 are:

1. TCP/IP

2. SNA LU 6.2.

Databases: DB2 7.1, 7.2

Oracle 8i and 9i

Sybase v12 or v 12.5

Java: If you want to use the Java Messaging Support, you need the Java Runtime Environment Version 1.3 or later

What are the software and hardware requirements for installing MQ on Windows?

Ans: MQ v 5.3 supports Windows 2000, Windows 2000XP,Windows 2000NT,

Windows 2003 SE, Windows 2003EE.

Disk Storage: Typical storage requirements are as follows:

1 Server installation: 50 MB

2. Client installation: 15 MB

3 Data storage (server): 50 MB

4. Data storage (client): 5 MB.

Connectivity The network protocols supported by WebSphere MQ for AIX, V5.3 are:

1. TCP/IP

2. SNA LU 6.2.

3. LU 6.2

4. NetBIOS

Databases: DB2 7.1, 7.2

Oracle 8i and 9i

Sybase v12 or v 12.5

Java: If you want to use the Java Messaging Support, you need the Java Runtime Environment Version 1.3 or later

what is a Message and what does it contain?

Ans: A message is a string of bytes that is meaningful to the applications that use it. Messages are used to transfer information from one application program to another (or between different parts of the same application). The applications can be running on the same platform, or on different platforms.

WebSphere MQ messages have two parts:

1. The application data. The content and structure of the application data is defined by the application programs that use it.

2. A message descriptor. The message descriptor identifies the message and contains additional control information, such as the type of message and the priority assigned to the message by the sending application. WebSphere MQ defines the format of the message descriptor. For a complete description of the message descriptor,

What is the Max Length of the message does MQ support/

Ans: The default maximum message length is 4 MB, although you can increase this to a maximum length of 100 MB (where 1 MB equals 1 048 576 bytes).

What is the difference between Persistent and Non Persistent Messages?

Ans: In Web Sphere MQ, messages can be either persistent or non persistent. Persistent messages are logged and can be recovered in the event of a WebSphere MQ failure. Thus, persistent messages are guaranteed to be delivered once and only once. Nonpersistent messages are not logged. Web Sphere still guarantees to deliver them not more than once, but it does not promise to deliver them once.

What is the effect of using Persistant messages?

Ans: Persistent messages are usually logged. Logging messages reduces the performance of your application, so use persistent messages for essential data only. If the data in a message can be discarded if the queue manager stops or fails, use a nonpersistent message.

WebSphere MQ messages:

Messages are made up of Two parts: Message descriptor, Application data

Types of messages?

Datagram: A Message sent with no response expected.

Request: A Message sent for which a response is expected.

Reply: A Response Message for a requested message.

Report: A Message that describes the occurrence or event

Ex COA/COD
Sizes ?

Qmanagerà10000 Msgs Maxmsglengthà4 Mb

Queueà5000 Msgs Maxmsglengthà4 Mb

What is the attribute used to see the Message length?

Ans: MaxMsgLength

What is MQ Client?

Ans: A Web Sphere MQ client is a component that allows an application running on a system to issue MQI calls to a queue manager running on another system. The output from the call is sent back to the client, which passes it back to the application.

What is MQ Server?

Ans: A Web Sphere MQ server is a queue manager that provides queuing services to one or more clients. All the Web Sphere MQ objects, for example queues, exist only on the queue manager machine (the Web Sphere MQ server machine), and not on the client. A Web Sphere MQ server can also support local Web Sphere MQ

Applications

What are the Objects used in Web sphere MQ?

Ans: 1. Queue Manager 2. Queues

3. Channels 4. Processes 5. Name lists.

Mention the No of Characters required for creating names of the MQ objects?

Ans: For MQ Channels it is 20 Characters

For Remaining objects it is 48 characters.

What about is the Default port number for MQ Queue Manager?

Ans: 1414
Difference between MQSC commands and Control commands?

MQSC Commands – These commands are used to handle the admin related functions for the components that are present in the MQ Series. In general MQSC commands are used for creating and maintaining Message channels, Queue Managers, Clusters etc…

Control Commands – These commands are used to manage the processes and services that are helpful in the functioning of the MQ Series. In general these commands are used for Channel listener, Channel Initiator, Trigger monitor etc…

Is the MQSC attributes are Case sensitive?

Ans: MQSC commands, including their attributes, can be written in uppercase or lowercase. Object names in MQSC commands are folded to uppercase (that is, QUEUE and queue are not differentiated), unless the names are enclosed within single quotation marks. If quotation marks are not used, the object is processed with a name in uppercase.

SCRIPT COMMANDS:-

After entering in to queue manager we can find script commands.

Script commands are same for every queue manager.

(These Commands should be used in CAPITAL LETTERS)

· DEFINE :-To define/create MQ manager objects like queue,

Channels, process, and listener.

· ALTER :-to update or modify the existing objects

· DISPLAY :-to view all the properties of a particular object or to

Display all objects

· DELETE :-to delete created objects

· CLEAR :-to clear the message from the queue

· END :-to come out of the queue manager

· PING :-to check whether other side channel / queue manager is ready to accept our request.

· START :- to start the particular channel or listener

· STOP :-to stop particular channel or listener

· REFRESH :-used to refresh the security every time after giving or executing, set mgr or command for queue manager or object

· RESET :-used to reset channel,cluster,queue manager

· RESOLVE :-to resolve the channel which is in indoubt state

· SUSPEND :-to suspend a queue manager from a cluster environment

· RESUME :-to remove a queue manager from a cluster environment

How can we write the MQSC commands that have too many parameters/

Ans: For commands that have too many parameters to fit on one line, use continuation characters to indicate that a command is continued on the following line:

1. A minus sign ( ) indicates that the command is to be continued from the start of _ the following line.

2. A plus sign (+) indicates that the command is to be continued from the first nonblank character on the following line.
What is programmable command format (PCF) commands?

These commands are issued from a programme for local or remote administration done by programmers.

What are commands used for creating the Queue manager from the Command prompt?

Ans: crtmqm -q -d MY.DEFAULT.XMIT.QUEUE -u DEAD.LETTER.QUEUE QM1

Here -q used to define the Queue manager QM1 as a Default Queue manager

-d is used to define the default transmission Queue -u is used to define the default dead letter queue.

How can U make the existing Queue Manager as an default Queue Manager?

Ans: On Windows systems, use the Web Sphere MQ Services snap-in to display the properties of the queue manager, and check the Make queue manager the default box. You need to stop and restart the queue manager for the change to take effect.

Where are the backup files are present after creating the Queue Manager?

Ans: Windows systems: If you use Web Sphere MQ for Windows NT and Windows 2000, configuration information is stored in the Windows Registry.

UNIX Systems: 1. When you install the product, the Web Sphere MQ configuration file (mqs.ini) is created. It contains a list of queue managers that is updated each time you create or delete a queue manager. There is one mqs.ini file per node.

2. When you create a new queue manager, a new queue manager configuration file (qm.ini) is automatically created. This contains configuration parameters for the queue manager.

What is the command used for starting the Queue Manager?

Ans: strmqm QMName

What is the command used for stopping the Queue manager?

Ans: endmqm -w QMName

The command waits until all applications have stopped and the queue manager has ended.

endmqm –i QMName

This type of shutdown does not wait for applications to disconnect from the queue manager.

What’s the message code for Stopping a Queue Manager?

AMQ4044 Queue manager stopping

What is the command used to delete the QueueManager?

Ans: dltmqm QMName

Display the attributes of the Queue Manager QM1?

Ans: runmqsc QM1 Display qmgr

 

 

 

 

IBM Websphere MQ: MAXHANDS queue manager parameter - 

What is the purpose of the MAXHANDS queue manager parameter?

MAXHANDS (Maximum Open Handles) is the queue manager parameter that limits the number of handles that any one process can have at the same time. The details relating to it are as follows:

Setting MAXHANDS:

• Alter the MAXHANDS queue manager parameter using the MQSC alter queue manager command. Example: alter qmgr maxhands (300)
• On Windows you can also use the WebSphere MQ Explorer to alter the queue manager's Max handles, extended property.

MAXHANDS(integer):
The maximum number of open handles that any one task can have at the same time. This is a value in the range zero through 999 999 999.

For clarification:
MAXHANDS refers to the maximum number of objects that a single connection can have open at the same time. So, if an application thread issues an MQOPEN for a queue, that counts as 1, and so on for each queue that is opened in that thread. A separate thread in the same or in a different process also has its own MAXHANDLES objects that it can open. The total number of handles for a queue, for example the number of applications that have a queue open, is not related to MAXHANDLES.

The open handles for a queue can be displayed using the display queue status command. In the example below, the qstatus for a queue named 3 shows that there are three open handles on the queue. The open handles are owned by PIDs 1928, 2572 and 2504.

IBM Websphere MQ Manager Stops Responding To JMS Requests -

MQ Manager stops responding to JMS requests.

Symptom

SystemOut.log:
FreePool E J2CA0046E: Method createManagedConnctionWithMCWrapper caught an exception during creation of the ManagedConnection for resource JMS$cftestcf$JMSManagedConnection@1373738090, throwing ResourceAllocationException. Original exception: javax.resource.spi.ResourceAdapterInternalException: Failed to create session
at com.ibm.ejs.jms.JMSCMUtils.mapToResourceException(JMSCMUtils.java:125)
at com.ibm.ejs.jms.JMSManagedSession.(JMSManagedSession.java:213)
. . .
javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for 'xldn0384abc:XYZ123'
at com.ibm.mq.jms.services.ConfigEnvironment.newException

(ConfigEnvironment.java:546)
at com.ibm.mq.jms.MQConnection.createQM
(MQConnection.java:1450)
at com.ibm.mq.jms.MQConnection.createQMNonXA
(MQConnection.java:960)
at
. . .
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2009
at com.ibm.mq.MQManagedConnectionJ11.
(MQManagedConnectionJ11.java:172)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection
(MQClientManagedConnectionFactoryJ11.java:270)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection
(MQClientManagedConnectionFactoryJ11.java:290)

AMQERRO1.log
AMQ9513: Maximum number of channels reached.

Cause

The maximum number of channels that can be in use simultaneously has been reached. The number of permitted channels is a configurable parameter in the queue manager configuration file.

When an application connects to MQ a channel is started on the MQ side. If the application, for any reason, is unexpectedly disconnected (no proper disconnection takes place) then the channel will not get cleaned up on the MQ side. It will become 'orphaned' from its original parent connection. When the application reconnects it will get a new instance of the channel, so now there will be 2 instances of the channel, the new one and the old, orphaned instance.

MQ only allows a certain number of channels. If you build up enough channels you will get the MaxChannels error AMQ9513.

Channels may also be getting orphaned due to TCP/IP interruptions rather than an application disconnecting improperly from MQ.

Resolving the problem

How should you manage these orphaned channels?

If you can get these orphaned channels to clean up you will go a long way towards avoiding this issue.

1. Set up the operating system TCP/IP KeepAlive parameter.
You must enable KeepAlive at operating system (TCP/IP) level. How this is done depends entirely on the operating system you are using. The TCP/IP keep alive setting is an operating system parameter. It determines how long to keep a TCP/IP connection alive.

KeepAlive has a timeout option that is usually set to 2 hours. Recommend setting this to a much shorter interval, such as 10 minutes. Once this change has been made the OS will need to be rebooted for this to take effect.

2. In addition to enabling KeepAlive at the OS level, MQ must also be configured to use KeepAlive. This is done by adding the following stanza to the QM.INI file for this queue manager, as follows:
TCP:
KeepAlive=yes

See MQ TCP Stanza

Once this stanza has been added the queue manager must be restarted for this to take effect.

3. It is also highly recommend to change the MaxChannels value (also in the QM.INI file) to 3 times what you think may be needed. For instance from 100 to 300 MaxChannel. See the MQ Channels stanza. This will ensure that you have some flexibility in the event a contingency occurs. To determine the number of channels WebSphere Application Server requires, see this technote, Explanation of connection pool and

IBM Websphere MQ : connection pool and session pool settings for JMS connection factories - 

In WebSphere Application Server, all JMS connection factories, including queue connection factories (QCFs) and topic connection factories (TCFs) have connection pool and session pool settings that can be configured.

This technote explains the following points:

• The difference between these pools and their relationship
• The maximum number of TCP/IP connections to a WebSphere MQ queue manager that is expected with a given set of connection pool and session pool settings
• The manner in which these settings are affected when message listener ports are configured to use the connection factory

Resolving the problem

In the JMS programming model, an application must get a JMS connection and a JMS session to send a message. A typical JMS application that sends messages looks like this:

QueueConnectionFactory qcf = (QueueConnectionFactory)ctx.lookup("jms/qcf");
Queue queue = (Queue)ctx.lookup("jms/q");
QueueConnection jmsconn = qcf.createQueueConnection();
QueueSession session = jmsconn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
QueueSender sender = session.createSender(queue);
TextMessage message = session.createTextMessage("Message Text");
sender.send(message);

The call to createQueueConnection gets a connection from the connection pool. The call to createQueueSession gets a session from the session pool.

By default, the Max Connections property for the connection pool and session pool is 10. This means that there can be a maximum of 10 connections or sessions in each pool. Each connection in the connection pool has its own session pool. This means that there can be 10 session pools that can have a maximum of 10 sessions each.

Each session represents a TCP/IP connection to the queue manager. With the settings mentioned here, there can be a maximum of 100 TCP/IP connections. If you are using WebSphere MQ, it is important to tune the queue manager's MaxChannels setting, located in the qm.ini file, to a value greater than the sum of the maximum possible number of sessions from each JMS connection factory that connects to the queue manager.

In addition to sending messages, the connection pools and session pools are used by the WebSphere Application Server message listener ports to receive messages and pass them to the message driven bean (MDB) associated with the listener port. When a listener port is defined, it is configured with a JMS connection factory. Each listener port uses one connection from the connection factory's connection pool.

There is also a setting on the listener port called Maximum sessions. The value of this property is the number of sessions that are used in the session pool of the connection that is used by the listener port. This influences the number of messages that can be concurrently processed by the listener port. The number of listener ports configured to use a connection factory, as well as the Maximum sessions settings on the listener ports, should be taken into consideration when tuning the connection pool and session pool settings.

Note: If the Maximum sessions for a listener port is greater than the Max Connections setting for the session pool, the Maximum sessions is changed to the value of Max Connections when the listener port starts.

Tuesday, February 4, 2014

IBM Websphere MQ : Using "runmqras" to collect problem determination data and files (MQ 7.0.1.8 or later; MQ 7.1.0.1 or later; MQ 7.5 or later) - Middleware News

You are using WebSphere MQ 7.0.1.8 or later (MQ 7.1.0.1 or later; MQ 7.5 or later) and you have opened an IBM Service Request ticket (PMR) to report a problem and you need to provide the MQ error logs, FDC files, version/fix pack of MQ, etc.
Is there a tool that you could use to gather those files and optionally send them to IBM Support via ftp?

Yes, you can use the MQ "runmqras" tool. The utility "runmqras" is a Java based tool shipped with WebSphere MQ.

Note:
Although runmqras is available since 7.0.0.0 as a proof of concept, not until 7.0.1.8, 7.1.0.1 and 7.5 did the tool became fully functional.

a) If you are going to gather information from all the queue managers, issue the following, assuming that the PMR number is 01234,567,890 (for the flag "-pmrno").
The flag "-ftp IBM" indicates that the resulting zip file will be sent via ftp to the IBM ftp server used for receiving PMR data.

runmqras -ftp IBM -pmrno 01234,567,890

This level of diagnostics is ideal when a problem is first raised, as it gives a lot of background on the product version, machine information, etc and can speed up the initial investigation.

Using the 'ftp' flag to ftp the resulting zip file directly to IBM is optional. For example, to collect the information and leave it as a zip file for manual submission you can remove the -ftp and -pmrno options. The location of the collected file is written to the console at the end of processing. Thus, the command would be simply:

runmqras

b) Similar to (a), but you want to collect additional information for the MQ queue manager QM_TEST. To collect important definition information from "runmqsc" (section "defs"), cluster information (section "cluster") and the MQ trace files (section "trace"), you would issue:

runmqras -qmlist QM_TEST -section defs,cluster,trace -ftp IBM -pmrno 01234,567,890

Note: The list of sections to run for a particular problem would normally be provided by IBM support as they vary depending on the type of problem

c) You do not always need to specify all the sections. For example, if the PMR is not related to clusters, then you do not need to specify the section "clusters" and you can specify only the definitions in runmqsc (section "defs") and the traces (section "trace"):

runmqras -qmlist QM_TEST -section defs,trace -ftp IBM -pmrno 01234,567,890

+++ Reference link +++

The following link of the WebSphere MQ Information Center has more information on the options to be used with runmqras:

WebSphere MQ > Reference > Administration reference > WebSphere MQ control commands > The control commands
runmqras

+++ Additional information +++

This section shows examples on how to use the tool and typical messages that you see when using it. Also, it shows what type of files are collected.

1) Example of using runmqras in Linux Intel 32-bit to collect the data for all queue managers and send the resulting zip file to IBM via ftp, using PMR 01234,567,890.

$ runmqras -ftp IBM -pmrno 01234,567,890
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20111020 (SR13 ))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20111020 (JIT enabled)
J9VM - 20111017_92807_lHdSMr
JIT - 20110916_20782_r8
GC - 20110524_AA)
JCL - 20111019
/opt/mqm/java/jre/bin/java -cp /opt/mqm/java/lib/com.ibm.mq.commonservices.jar:/opt/mqm/java/lib/com.ibm.mq.tools.ras.jar -Djava.library.path=/opt/mqm/lib:/opt/mqm/java/lib -DdefaultRasInput=/opt/mqm/bin/isa.xml -DdefaultRasWork=/tmp/runmqras_120525_150110 crtmqras.Zipper -ftp IBM -pmrno 01234,567,890
crtmqras v1.15.1.19 starts...
Using default Input path:
/opt/mqm/bin/isa.xml
Using default Work path:
/tmp/runmqras_120525_150110
Using default output path:
/tmp/runmqras_120525_150110
Using Zip File path:
/tmp/runmqras_120525_150110/01234.567.890.runmqras_201205251401.zip
Running on Linux
Editor Note: ... you may see a slight delay at this time while the tool gathers the files
crtmqras has successfully finished
Editor Note: ... the following 2 lines provide the full path of the resulting zip file.
The zip file can be found at /tmp/runmqras_120525_150110/01234.567.890.runmqras_201205251401.zip
FTP HANDLER: Opening connection to the server.
FTP HANDLER: Connection established for user -anonymous.
FTP HANDLER: Starting file transfer.
Transferred: 10 %.
Transferred: 20 %.
Transferred: 30 %.
Transferred: 40 %.
Transferred: 50 %.
Transferred: 60 %.
Transferred: 70 %.
Transferred: 80 %.
Transferred: 90 %.
Transferred: 100 %.
FTP HANDLER: File transfer complete.


2) Excerpt from the listing of files included in the zip file obtained by the above runmqras invocation (item 1)
Notes:
- To keep the listing short in this technote, files with size of 0 were omitted.
- The queue manager QMGRMI is a multi-instance queue manager and the queue manager data is located in a different path: /var/mqm/data/
- The file names and number of files that you will see, might be different than the ones shown below.

$ unzip -l /tmp/runmqras_120525_150110/01234.567.890.runmqras_201205251401.zip
Archive:  /tmp/runmqras_120525_150110/01234.567.890.runmqras_201205251401.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
    18634  04-30-12 12:14   var/mqm/errors/ffst.out
   265502  04-27-12 07:26   var/mqm/errors/AMQERR01.LOG
     2732  05-25-12 08:28   var/mqm/mqs.ini
     1296  11-22-11 09:28   var/mqm/qmgrs/QM_TEST/qm.ini
     1298  05-25-12 08:28   var/mqm/data/QMGRMI.000/qm.ini
      509  01-16-12 15:00   var/mqm/qmgrs/QM_TEST/qmstatus.ini
      556  05-25-12 08:28   var/mqm/data/QMGRMI.000/qmstatus.ini
       56  01-16-12 15:00   var/mqm/qmgrs/QM_TEST/amqalchk.fil
       56  05-25-12 08:28   var/mqm/data/QMGRMI.000/amqalchk.fil
    52904  01-16-12 15:00   var/mqm/qmgrs/QM_TEST/errors/AMQERR01.LOG
     7066  05-25-12 08:28   var/mqm/data/QMGRMI.000/errors/AMQERR01.LOG
     6256  01-16-12 15:00   var/mqm/log/QM_TEST/amqhlctl.lfh
     6256  05-25-12 08:28   var/mqm/log/QMGRMI.000/amqhlctl.lfh
     6286  01-25-12 11:38   home/userx/.mqdata/.metadata/.log
                            ... more files for MQ Explorer (if applicable)
      939  05-25-12 14:01   dspmqver_-a.stdout
       79  05-25-12 14:01   idmqm.stdout
    20176  05-25-12 14:01   ps_eo.stdout
     2388  05-25-12 14:01   amqicdir-a.stderr
      338  05-25-12 14:01   ipcs_u.stdout
      234  05-25-12 14:01   binrpm.stdout
       91  05-25-12 14:01   uname.stdout
      109  05-25-12 14:01   dspmqver.stdout
     4636  05-25-12 14:01   ipcs_t.stdout
     3305  05-25-12 14:01   netstat-s.stdout
     4684  05-25-12 14:01   javalibfiles_sum.stdout
     2291  05-25-12 14:01   javalibfiles.stdout
       65  05-25-12 14:01   lib64files.stderr
     7185  05-25-12 14:01   binfiles.stdout
      498  05-25-12 14:01   mount.stdout
        9  05-25-12 14:01   stamp_hostname.stdout
      498  05-25-12 14:01   ipcs_l.stdout
      125  05-25-12 14:01   netstat-anp.stderr
     3996  05-25-12 14:01   ipcs_a.stdout
       70  05-25-12 14:01   javalib64files.stderr
    81552  05-25-12 14:01   libfiles_sum.stdout
       58  05-25-12 14:01   stamp_dspmqver.stdout
       53  05-25-12 14:01   dmpmqaut.stderr
       59  05-25-12 14:01   lib64files_sum.stderr
       53  05-25-12 14:01   gsk8ver.stderr
    17877  05-25-12 14:01   ps_efl.stdout
      251  05-25-12 14:01   df.stdout
     3377  05-25-12 14:01   binfiles_sum.stdout
    47339  05-25-12 14:01   netstat-anp.stdout
      839  05-25-12 14:01   dspmq.stdout
       64  05-25-12 14:01   javalib64files_sum.stderr
      264  05-25-12 14:01   netstat-i.stdout
      376  05-25-12 14:01   explorerFiles.stdout
      399  05-25-12 14:01   errors.stdout
       54  05-25-12 14:01   gsk75ver.stderr
      831  05-25-12 14:01   dspmqver_-p_15.stdout
       53  05-25-12 14:01   gsk7ver.stderr
     6880  05-25-12 14:01   libfiles.stdout
       59  05-25-12 14:01   amqoamd.stdout
     3785  05-25-12 14:01   ipcs_c.stdout
     4048  05-25-12 14:01   usrlibsymlinks.stdout
      394  05-25-12 14:01 autopdzip/autopd/autopd-collection-environment-v2.xml
    41975  02-22-12 10:18   isa.xml
   139474  05-25-12 14:01   console.log
 --------                   -------
  2763148                   170 files

3) Example of running runmqras for only the QM_TEST queue manager, gathering runmqsc, clustering data and trace files.

$ runmqras -qmlist QM_TEST -section defs,cluster,trace -ftp IBM -pmrno 01234,567,890
... Similar to item (1) ... Notice the path for the zip file.
Using Zip File path:
/tmp/runmqras_120525_154125/01234.567.890.runmqras_201205251441.zip
Running on Linux
crtmqras has successfully finished
The zip file can be found at /tmp/runmqras_120525_154125/01234.567.890.runmqras_201205251441.zip
FTP HANDLER: Opening connection to the server.
FTP HANDLER: Connection established for user -anonymous.
FTP HANDLER: Starting file transfer.
...

4) Example of the contents for the zip file obtained in item 3:
Note: To keep the illustration short, only few representative files are shown in the output.

$ unzip -l /tmp/runmqras_120525_154125/01234.567.890.runmqras_201205251441.zip
Archive:  /tmp/runmqras_120525_154125/01234.567.890.runmqras_201205251441.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
    18634  04-30-12 12:14   var/mqm/errors/ffst.out
   265502  04-27-12 07:26   var/mqm/errors/AMQERR01.LOG
     2732  05-25-12 08:28   var/mqm/mqs.ini
     1296  11-22-11 09:28   var/mqm/qmgrs/QM_TEST/qm.ini
      500  05-25-12 14:39   var/mqm/qmgrs/QM_TEST/qmstatus.ini
       56  05-25-12 14:39   var/mqm/qmgrs/QM_TEST/amqalchk.fil
    63635  05-25-12 14:39   var/mqm/qmgrs/QM_TEST/errors/AMQERR01.LOG
     6256  05-25-12 14:39   var/mqm/log/QM_TEST/amqhlctl.lfh
     6286  01-25-12 11:38   home/rivera/.mqdata/.metadata/.log
    13857  01-27-12 15:29   home/userx/.mqdata/.metadata/.plugins/com.ibm.mq.explorer.ui/WMQ_Navigator.xml
     4284  05-25-12 14:40   var/mqm/trace/AMQ30089.0.TRC
    16060  05-25-12 14:40   var/mqm/trace/AMQ29730.0.TRC
      939  05-25-12 14:41   dspmqver_-a.stdout
      367  05-25-12 14:42   runmqsc_PUBSUB_QM_TEST.stdout
      132  05-25-12 14:41   amqsbcg_QM_TEST_SCTQ.stdout
      494  05-25-12 14:41   runmqsc_PROCESS_QM_TEST.stdout
    65815  05-25-12 14:41   runmqsc_QUEUE_QM_TEST.stdout
      614  05-25-12 14:41   runmqsc_SERVICE_QM_TEST.stdout
    62874  05-25-12 14:41   amqsbcg_QM_TEST_SCRQ.stdout
       79  05-25-12 14:41   idmqm.stdout
    21988  05-25-12 14:41   ps_eo.stdout
     2388  05-25-12 14:41   amqicdir-a.stderr
      833  05-25-12 14:41   runmqsc_QALIAS_QM_TEST.stdout
      340  05-25-12 14:41   ipcs_u.stdout
      234  05-25-12 14:41   binrpm.stdout
       91  05-25-12 14:41   uname.stdout
      603  05-25-12 14:42   runmqsc_LSSTATUS_QM_TEST.stdout
     2432  05-25-12 14:41   runmqsc_QMGR_QM_TEST.stdout
     4821  05-25-12 14:41   runmqsc_CONN_QM_TEST.stdout
      109  05-25-12 14:41   dspmqver.stdout
     1066  05-25-12 14:41   runmqsc_NAMELIST_QM_TEST.stdout
     5786  05-25-12 14:41   ipcs_t.stdout
     3305  05-25-12 14:41   netstat-s.stdout
     4684  05-25-12 14:41   javalibfiles_sum.stdout
     2291  05-25-12 14:41   javalibfiles.stdout
       65  05-25-12 14:41   lib64files.stderr
     7185  05-25-12 14:41   binfiles.stdout
     3716  05-25-12 14:42   runmqsc_TOPIC_QM_TEST.stdout
      283  05-25-12 14:41   runmqsc_CLUSQMGR_QM_TEST.stdout
      498  05-25-12 14:41   mount.stdout
      867  05-25-12 14:41   runmqsc_LISTENER_QM_TEST.stdout
      765  05-25-12 14:41   runmqsc_QREMOTE_QM_TEST.stdout
        9  05-25-12 14:41   stamp_hostname.stdout
      498  05-25-12 14:41   ipcs_l.stdout
       15  05-25-12 14:41   amqrfdm_QM_TEST.stderr
      284  05-25-12 14:42   runmqsc_SVSTATUS_QM_TEST.stdout
    15482  05-25-12 14:41   runmqsc_QSTATUS_QM_TEST.stdout
      125  05-25-12 14:41   netstat-anp.stderr
     6823  05-25-12 14:41   runmqsc_QMODEL_QM_TEST.stdout
     5016  05-25-12 14:41   ipcs_a.stdout
       70  05-25-12 14:41   javalib64files.stderr
    82095  05-25-12 14:41   libfiles_sum.stdout
       58  05-25-12 14:41   stamp_dspmqver.stdout
    11221  05-25-12 14:41   dmpmqaut.stderr
       59  05-25-12 14:41   lib64files_sum.stderr
       53  05-25-12 14:41   gsk8ver.stderr
    19479  05-25-12 14:41   ps_efl.stdout
      251  05-25-12 14:41   df.stdout
      798  05-25-12 14:41   runmqsc_AUTHINFO_QM_TEST.stdout
     3377  05-25-12 14:41   binfiles_sum.stdout
    50907  05-25-12 14:41   netstat-anp.stdout
      829  05-25-12 14:41   dspmq.stdout
      287  05-25-12 14:42   runmqsc_TPSTATUS_QM_TEST.stdout
      272  05-25-12 14:41   runmqsc_CHS_QM_TEST.stdout
       64  05-25-12 14:41   javalib64files_sum.stderr
      264  05-25-12 14:41   netstat-i.stdout
    58095  05-25-12 14:41   runmqsc_QLOCAL_QM_TEST.stdout
      131  05-25-12 14:41   amqsbcg_QM_TEST_SCCQ.stdout
    11341  05-25-12 14:41   runmqsc_CHANNEL_QM_TEST.stdout
      376  05-25-12 14:41   explorerFiles.stdout
     2440  05-25-12 14:42   runmqsc_SUB_QM_TEST.stdout
      561  05-25-12 14:42   runmqsc_QMSTATUS_QM_TEST.stdout
      399  05-25-12 14:41   errors.stdout
       54  05-25-12 14:41   gsk75ver.stderr
     1330  05-25-12 14:42   runmqsc_SBSTATUS_QM_TEST.stdout
     2842  05-25-12 14:41   amqrfdm_QM_TEST.stdout
      831  05-25-12 14:41   dspmqver_-p_15.stdout
      284  05-25-12 14:41   runmqsc_QCLUSTER_QM_TEST.stdout
       53  05-25-12 14:41   gsk7ver.stderr
     6880  05-25-12 14:41   libfiles.stdout
      284  05-25-12 14:42   runmqsc_TCLUSTER_QM_TEST.stdout
    15588  05-25-12 14:41   amqoamd.stdout
     4709  05-25-12 14:41   ipcs_c.stdout
     4048  05-25-12 14:41   usrlibsymlinks.stdout
      394  05-25-12 14:42   autopdzip/autopd/autopd-collection-environment-v2.xml
    41975  02-22-12 10:18   isa.xml
   134131  05-25-12 14:42   console.log
 --------                   -------
  1970140                   183 files

Monday, February 3, 2014

IBM WebSphere MQ for Linux V6.0 and V7 Explorer Trace

Follow the instructions listed below to run trace for the WebSphere MQ for Linux V6 and V7 Explorer using the MQ Java API:

1. Modify the files runmqcfg.cmd and runmqcfg_rcp.cmd in the directory:

/opt/mqm/bin

Modify the line:
AMQ_EXPLORER="./eclipse"
to the following, according to the version of MQ:
v6.0:
AMQ_EXPLORER="/opt/mqm/ies30/eclipse/eclipse"
v7.0:
AMQ_EXPLORER="/opt/mqm/eclipseSDK33/eclipse/eclipse"

And add the single line:
AMQ_EXPLORER="$AMQ_EXPLORER -Dcom.ibm.mq.commonservices=/tmp/internal.properties"
before the statement
cd $AMQECLIPSE

2. Both of these scripts are dependent on the environment variable AMQECLIPSE. If this environment variable does not exist then it should be created as the first line in the script. For example:

v6.0:
export AMQECLIPSE="/opt/mqm/ies30/eclipse"
v7.0:
export AMQECLIPSE="/opt/mqm/eclipseSDK33/eclipse"

Note: If you want, you can include the above line in the user's profile.

3. Create a file called "internal.properties" in the /tmp directory with the following text.

Diagnostics.MQ=enabled
Diagnostics.Java=explorer,wmqjavaclasses,all
#Diagnostics.Java=explorer
Diagnostics.Java.Trace.Detail=high
Diagnostics.Java.Trace.Destination.File=enabled
Diagnostics.Java.Trace.Destination.Console=disabled
Diagnostics.Java.Trace.Destination.Pathname=/tmp/trace
Diagnostics.Java.FFDC.Destination.Pathname=/tmp/FFDC
Diagnostics.Java.Errors.Destination.Filename=/tmp/errors/AMQJERR.LOG

4. Ensure that the file permissions for the above file allow it to be read by all processes:

chmod a+r /tmp/internal.properties

5. You may also need to create the following directories:
/tmp/FFDC
/tmp/trace
/tmp/errors

6. Ensure that the file permissions for these directories allow other users to write, such as:

chmod 777 /tmp/FFDC
chmod 777 /tmp/trace
chmod 777 /tmp/errors

7. From a command prompt, invoke the script:

runmqcfg

8. In the /tmp/trace directory you will find files with the format AMQyyyymmddhhmmsssss.*.TRC
which contain the MQ Java trace output.

IBM WebSphere MQ for Linux Trace -

Follow the instructions listed below to start, stop and format WebSphere MQ for Linux trace. Trace files are written to the directory /var/mqm/trace, so delete or relocate old trace files before beginning a new trace.

Start trace for every WebSphere MQ process:

strmqtrc -e

Or start trace only for one queue manager:

strmqtrc -m MY.QMGR

Or start a high detail trace for one queue manager:

strmqtrc -t all -t detail -m MY.QMGR

Or start a high detail wrapping trace and limit the file size to ~5MB:

strmqtrc -l 5 -t all -t detail -m MY.QMGR

End all tracing:

endmqtrc -a

Format the trace files:

dspmqtrc *.TRC

Or format wrapping trace files:

dspmqtrc *.TRC *.TRS

The trace formatter program converts binary files named AMQppppp.TRC (where ppppp is the process identifier or pid which created the file) into readable files named AMQppppp.FMT.

If you used a wrapping trace, then each time a .TRC reaches the size limit MQ renames it to a .TRS extension and starts a new .TRC file. The trace formatter can convert both files to a single formatted file, but only if you format the .TRC and .TRS files at the same time, as shown above.

Send formatted trace files to IBM support unless binary traces are specifically requested. To save space, compress the formatted trace files with compress, zip, gzip, or bzip2.

IBM WebSphere MQ for AIX Trace V5.3, V6 and V7 

WebSphere MQ V6 and V7 on AIX now supports the standard WebSphere MQ trace facility as well as the AIX system trace. It is recommended that V6 and V7 customers use the WebSphere MQ trace commands unless requested by the WebSphere MQ service team to use the AIX system trace hooks.

Follow the instructions listed below to start, stop and format WebSphere MQ for AIX trace. Trace files are written to the directory /var/mqm/trace, so delete or relocate old trace files before beginning a new trace.

• Start trace for every WebSphere MQ process:
  strmqtrc -e

Or start trace only for one queue manager:

strmqtrc -m MY.QMGR

Or start a high detail trace for one queue manager:

strmqtrc -t all -t detail -m MY.QMGR

Or start a high detail wrapping trace and limit the file size to ~5MB:

strmqtrc -l 5 -t all -t detail -m MY.QMGR

• End all tracing:
  endmqtrc -a

• Format the trace files:
  dspmqtrc *.TRC

Or format wrapping trace files:

dspmqtrc *.TRC *.TRS

The trace formatter program converts binary files named AMQppppp.TRC (where ppppp is the process identifier or pid which created the file) into readable files named AMQppppp.FMT.

If you used a wrapping trace, then each time a .TRC reaches the size limit MQ renames it to a .TRS extension and starts a new .TRC file. The trace formatter can convert both files to a single formatted file, but only if you format the .TRC and .TRS files at the same time, as shown above.

Send formatted trace files to IBM support unless binary traces are specifically requested. To save space, compress the formatted trace files with compress, zip, gzip, or bzip2. 

WebSphere MQ for AIX Trace v5.3

Follow the instructions listed below to start, stop and format the AIX trace on v5.3.

Note: WebSphere MQ V6 and V7 customers should review the second part of this section. The additional trace function described in part two was added at WebSphere MQ v6.0.

• Start trace
  The following command starts a trace of WebSphere MQ data which will grow to approximately 50MB in size before wrapping. You can change the maximum size, but be aware that a small size may prevent useful information from being captured. The larger you make the file size the better chance of capturing the trace you need. You can choose any output file name you wish, but be sure there is ample storage for the trace:
  trace -a -j30D,30E -o /path/to/trace.out -L 50000000
• End trace:
  Because AIX traces wrap by default, it is important to stop tracing as soon as the problem occurs. If you delay in stopping the trace, or if your trace file size is too small, the information you hope to gather may be overwritten by new trace data:
  trcstop

• Format trace:
  
  trcrpt -t /usr/mqm/lib/amqtrc.fmt
  /path/to/trace.out > /path/to/trace.fmt

Send formatted trace files to IBM support unless binary traces are specifically requested. If the IBM support team asks you to gather additional trace hooks (not just 30D and 30E) then please send the binary trace file instead.

IBM Websphere MQ: MAXHANDS queue manager parameter - Middleware News

What is the purpose of the MAXHANDS queue manager parameter?

MAXHANDS (Maximum Open Handles) is the queue manager parameter that limits the number of handles that any one process can have at the same time. The details relating to it are as follows:

Setting MAXHANDS:

• Alter the MAXHANDS queue manager parameter using the MQSC alter queue manager command. Example: alter qmgr maxhands (300)
• On Windows you can also use the WebSphere MQ Explorer to alter the queue manager's Max handles, extended property.

MAXHANDS(integer):
The maximum number of open handles that any one task can have at the same time. This is a value in the range zero through 999 999 999.

For clarification:
MAXHANDS refers to the maximum number of objects that a single connection can have open at the same time. So, if an application thread issues an MQOPEN for a queue, that counts as 1, and so on for each queue that is opened in that thread. A separate thread in the same or in a different process also has its own MAXHANDLES objects that it can open. The total number of handles for a queue, for example the number of applications that have a queue open, is not related to MAXHANDLES.

The open handles for a queue can be displayed using the display queue status command. In the example below, the qstatus for a queue named 3 shows that there are three open handles on the queue. The open handles are owned by PIDs 1928, 2572 and 2504.




For further details refer to the online topics regarding the MAXHANDS queue manager parameter, and the 

Monday, January 27, 2014

IBM Websphere MQ - Automatic client reconnection 

Automatic client reconnection

You can make your client applications reconnect automatically, without writing any additional code, by configuring a number of components.

Automatic client reconnection is inline. The connection is automatically restored at any point in the client application program, and the handles to open objects are all restored.

In contrast, manual reconnection requires the client application to re-create a connection using MQCONN orMQCONNX, and to reopen objects. Automatic client reconnection is suitable for many, but not all client applications.

Table 1 lists the earliest release of WebSphere® MQ client support that must be installed on a client workstation. You must upgrade client workstations to one of these levels for an application to use automatic client reconnection. Table 2 lists other requirements to enable automatic client reconnection.

With program access to reconnection options, a client application can set reconnection options. Except for JMS and XMS clients, if a client application has access to reconnection options, it can also create an event handler to handle reconnection events.

An existing client application might be able to benefit from reconnection support, without recompilation and linking:

• For a non-JMS client, set the mqclient.ini environment variable DefRecon to set reconnection options. Use a CCDT to connect to a queue manager. If the client is to connect to a multi-instance queue manager, provide the network addresses of the active and standby queue manager instances in the CCDT.
• For a JMS client, set the reconnection options in the connection factory configuration. When you use the WebSphere MQ Resource adapter or a JMS Client that is integrated in a Java™ EE Environment, automatic client reconnection might not be available. There are restrictions in some of the managed environments, for more information see WebSphere MQ automatic client reconnection with WebSphere MQ classes for JMS.

Table 1. Supported clients

Client interface	Client	Program access to reconnection options	Reconnection support
Messaging APIs	C, C++, COBOL, Unmanaged Visual Basic, XMS (Unmanaged XMS on Windows)	7.0.1	7.0.1
	JMS (JSE, and Java EE client container and managed containers)	7.0.1.3	7.0.1.3
	WebSphere MQ classes for Java	Not supported	Not supported
	Managed XMS and managed .NET clients: C#, Visual Basic	7.1	7.1
Other APIs	Windows Communication Foundation (Unmanaged 1)	Not supported	7.0.1
	Windows Communication Foundation (Managed 1)	Not supported	Not supported
	Axis 1	Not supported	Not supported
	Axis 2	Not supported	7.0.1.3
	HTTP (web 2.0)	Not supported	7.0.1.3

1. Set managed or unmanaged mode in the WCF binding configuration.

Automatic reconnection has the following configuration requirements:

Table 2. Automatic reconnection configuration requirements

Component	Requirement	Effect of not meeting requirement
WebSphere MQ MQI client installation	See Table 1	MQRC_OPTIONS_ERROR
WebSphere MQ Server installation	Level 7.0.1	MQRC_OPTIONS_ERROR
Channel	SHARECNV > 0	MQRC_ENVIRONMENT_ERROR
Application environment	Must be threaded	MQRC_ENVIRONMENT_ERROR
MQI	One of: MQCONNX with MQCNO Options set toMQCNO_RECONNECT orMQCNO_RECONNECT_Q_MGR. Defrecon=YES|QMGR in mqclient.ini In JMS set the CLIENTRECONNECTOPTIONS property of the connection factory.	MQCC_FAILED when a connection is broken or queue manager ends or fails.

Figure 1 shows the main interactions between components that are involved in client reconnection.

Figure 1. Automatic client reconnection

Client application

The client application is a WebSphere MQ MQI client.

• By default clients are not automatically reconnected. Enable the automatic client reconnection by setting the MQCONNX MQCNO Option MQCNO_RECONNECT or MQCNO_RECONNECT_Q_MGR.
• Many applications are written in such a way that they are able to take advantage of auto-reconnection with no additional coding. Enable automatic reconnection for existing programs, without making any coding changes, by setting the DefRecon attribute in the channels stanza of the mqclient.ini configuration file.
• Use one of these three options:
  1. Modify the program so that the logic is unaffected by reconnection. For example, you might have to issue MQI calls within the sync point, and resubmit backed-out transactions.
  2. Add an event handler to detect reconnection, and restore the state of the client application when the connection is reestablished.
  3. Do not enable auto-reconnection: instead, disconnect the client and issue a newMQCONN or MQCONNX MQI call to find another queue manager instance that is running in the same queue manager group.
  For further details about these three options, see Application recovery.
• Reconnecting to a queue manager of the same name does not guarantee that you have reconnected to the same instance of a queue manager.
  Use an MQCNO option MQCNO_RECONNECT_Q_MGR , to reconnect to an instance of the same queue manager.
• A client can register an event handler so that it can be informed the state of reconnection. TheMQHCONN passed in the event handler cannot be used. The following reason codes are provided:

  MQRC_RECONNECTING

  The connection failed, and the system is attempting to reconnect. You receive multipleMQRC_RECONNECTING events if multiple reconnect attempts are made.

  MQRC_RECONNECTED

  The reconnection made and all handles successfully reestablished.

  MQRC_RECONNECT_FAILED

  The reconnection was not successful.

  MQRC_RECONNECT_QMID_MISMATCH

  A reconnectable connection specified MQCNO_RECONNECT_Q_MGR and the connection attempted to reconnect to a different queue manager.

  MQRC_RECONNECT_Q_MGR_REQD

  An option, such MQMO_MATCH_MSG_TOKEN in an MQGET call, was specified in the client program that requires reconnection to the same queue manager.

• A reconnectable client is able to reconnect automatically only after connecting. That is, theMQCONNX call itself is not tried again if it fails. For example, if you receive the return code 2543 - MQRC_STANDBY_Q_MGR from MQCONNX, reissue the call after a short delay.

  MQRC_RECONNECT_INCOMPATIBLE

  This reason code is returned when the application tries to use MQPMO_LOGICAL_ORDER (with MQPUT and MQPUT1) or MQGMO_LOGICAL_ORDER (with MQGET) when reconnect options are set. The reason for returning the reason code is to make sure that applications never use reconnect in such cases.

  MQRC_CALL_INTERRUPTED

  This reason code is returned when the connection breaks during the execution of Commit call and the client reconnects. An MQPUT of a persistent message outside the sync point also results in the same reason code being returned to the application.

Multi-instance queue managers

Simplify restarting WebSphere MQ MQI client applications, after a multi-instance queue manager has activated its standby instance, by using automatic client reconnection.

The standby instance of a multi-instance queue manager is typically at a different network address to the active instance. Include the network addresses of both the instances in the client connection definition table (CCDT). Either provide a list of network addresses for the CONNAME parameter, or define multiple rows for the queue manager in the CCDT.

Commonly, WebSphere MQ MQI clients reconnect to any queue manager in a queue manager group. Sometimes you want a WebSphere MQ MQI client to reconnect only to the same queue manager. It might have an affinity to a queue manager. You can prevent a client from reconnecting to a different queue manager. Set the MQCNOoption, MQCNO_RECONNECT_Q_MGR. The WebSphere MQ MQI client fails if it reconnects to a different queue manager. If you set the MQCNO option, MQCNO_RECONNECT_Q_MGR, do not include other queue managers in the same queue manager group. The client returns an error if the queue manager it reconnects to is not the same queue manager as the one it connected to.

Queue manager groups

You can select whether the client application always connects and reconnects to a queue manager of the same name, to the same queue manager, or to any of a set of queue managers that are defined with the sameQMNAME value in the client connection table.

• The queue manager name attribute, QMNAME , in the client channel definition is the name of a queue manager group.
• In your client application, if you set the value of the MQCONN or MQCONNX QmgrName parameter to a queue manager name, the client connects only to queue managers with that name. If you prefix the queue manager name with an asterisk(*), the client connects to any queue manager in the queue manager group with the same QMNAME value. For a full explanation, see Queue manager groups in the CCDT.

Queue sharing groups

Automatic client reconnection to z/OS® queue sharing groups, uses the same mechanisms for reconnection as any other environment. The client will reconnect to the same selection of queue managers as is configured for the original connection. For example, when using the client channel definition table the administrator should ensure that all entries in the table, resolve to the same z/OS queue sharing group.

Client and server channel definitions

Client and server channel definitions define the groups of queue managers a client application can reconnect to. The definitions govern the selection and timing of reconnections, and other factors, such as security; see the related topics. The most relevant channel attributes to consider for reconnection are listed in two groups:

Client connection attributes

Connection affinity (AFFINITY)AFFINITY

Connection affinity.

Client channel weight (CLNTWGHT)CLNTWGHT

Client channel weight.

Connection name (CONNAME)CONNAME

Connection information.

Heartbeat interval (HBINT)HBINT

Heartbeat interval. Set the heartbeat interval on the server connection channel.

Keepalive Interval (KAINT)KAINT

Keepalive interval. Set the keepalive interval on the server connection channel.

Note that KAINT applies to z/OS only.

Queue manager name (QMNAME)QMNAME

Queue manager name.

Server connection attributes

Heartbeat interval (HBINT)HBINT

Heartbeat interval. Set the heartbeat interval on the client connection channel.

Keepalive Interval (KAINT)KAINT

Keepalive interval. Set the keepalive interval on the client connection channel.

Note that KAINT applies to z/OS only.

KAINT is a network layer heartbeat, and HBINT is a WebSphere MQ heartbeat between the client and the queue manager. Setting these heartbeats to a shorter time serves two purposes:

1. By simulating activity on the connection, network layer software that is responsible for closing inactive connections is less likely to shut down your connection.
2. If the connection is shut down, the delay before the broken connection is detected, is shortened.

The default TCP/IP keepalive interval is two hours. Consider setting the KAINT and HBINT attributes to a shorter time. Do not assume that the normal behavior of a network suits the needs of automatic reconnection. For example, some firewalls can shut down an inactive TCP/IP connection after as little as 10 minutes.

Network connectivity

Only network failures that are passed to the WebSphere MQ MQI client by the network, are handled by the automatic reconnection capability of the client.

• Reconnections performed automatically by the transport are invisible to WebSphere MQ.
• Setting HBINT helps to deal with network failures that are invisible to WebSphere MQ.

Queue managers and WebSphere MQ listeners

Client reconnection is triggered by server failure, queue manager failure, network connectivity failure, and by an administrator switching over to another queue manager instance.

• If you are using a multi-instance queue manager, an additional cause of client reconnection occurs when you switch control from the active queue manager instance to a standby instance.
• Ending a queue manager using the default endmqm command, does not trigger automatic client reconnection. Add the -r option on the endmqm command to request automatic client reconnection, or the -s option to transfer to a standby queue manager instance after shutting down.

WebSphere MQ MQI client automatic reconnection support

If you use the automatic client reconnection support in the WebSphere MQ MQI client, the client application automatically reconnects and continues processing without you issuing an MQCONN or MQCONNX MQI call to reconnect to the queue manager.

• Automatic client reconnection is triggered by one of the following occurrences:
  • queue manager failure
  • ending a queue manager and specifying the -r, reconnect, option on the endmqmcommand
• The MQCONNX MQCNO options control whether you have enabled the automatic client reconnection. The options are described in Reconnection options.
• Automatic client reconnection issues MQI calls on behalf of your application to restore the connection handle and the handles to other open objects, so that your program can resume normal processing after it has processed any MQI errors that resulted from the broken connection. SeeRecovery of an automatically reconnected client .
• If you have written a channel exit program for the connection, the exit receives these additional MQI calls.
• You can register a reconnection event handler, which is triggered when reconnection begins and when it finishes.

Although reconnection takes no more than a minute, reconnection can take longer because a queue manager might have numerous resources to manage. During this time, a client application might be holding locks that do not belong to WebSphere MQ resources. There is a timeout value you can configure to limit the time a client waits for reconnection. The value (in seconds) is set in the mqclient.ini file.

Channels:
    MQReconnectTimeout = 1800

No reconnection attempts are made after the timeout has expired. When the system detects that the timeout has expired it returns a MQRC_RECONNECT_FAILED error.

Friday, January 3, 2014

What's new in IBM WebSphere MQ version 7.5 

WebSphere MQ V7.5 delivers a single Universal Messaging solution. It enables the simple, rapid, reliable, and secure transport of data and messages between applications, systems, and services.
WebSphere MQ is the market-leading, message-oriented middleware product that delivers a reliable, proven universal messaging backbone for almost 10,000 organizations of different sizes, spanning many industries around the world
Customers gain access to previously separately installable capabilities, enabling more complete solutions for data and message movement along with reduced complexity. Get the advantage of a smaller install footprint, simpler maintenance and eliminate the need for separate packages. Add as you need .
Enhancements include:

• No fee for Extended Transactional Client for all supported versions of WebSphere MQ - The Extended Transactional Client is available for use in all client deployments without additional entitlement for all supported versions of WebSphere MQ queue manager. Realize this benefit through the download and acceptance of this new License Information.
• Licensing changes for WebSphere MQ Telemetry Client - Use of the WebSphere MQ Telemetry Client requires purchasing an entitlement for WebSphere MQ Telemetry Clients for each WebSphere MQ Server installed that will have WebSphere MQ Telemetry clients connected to it, with no limit to the number of clients connected; applicable to WebSphere MQ v7.5, WebSphere MQ v7.0.1 and WebSphere MQ v7.1.
• Managed File Transfer and Advanced Message Security capabilities available within WebSphere MQ as additional licensing option
• Managed File Transfer and Advanced Message Security capabilities available within WebSphere MQ as additional licensing option
• Common tooling interface via the MQ Explorer
• Managed File Transfer-specific functional enhancements
• Security enhancements including the integration of the WebSphere MQ Advanced Message Security function into the MQ Server
• Multiple transmission queues defined for use in a clustered queue manager

You can obtain the new enhanced functions offered in WebSphere MQ V7.5 by migrating directly to V7.5 from WebSphere MQ V6.0, V7.0.1, or V.7.1 -- without migrating to an interim version or release.

Performance Points of MQ v7.5 vs. MQ v7.1

• Integration of WebSphere MQ with WebSphere Managed File Transfer and WebSphere AMS, together with Telemetry
• Unified Management & Monitoring across all messaging & files using a single dashboard
• Message throughput increase
  • 40% on AIX, 80% on Linux, 100% on Windows for persistent messages
  • 30% on AIX, and between 40-100% on Linux for non-persistent messages (2KB)
• 500% performance improvement for multi-subscriber message delivery
• MQTT protocol extends communication to 240,000+ mobile & other sensor endpoints (At a price of $100 per MQ Server)
• Simplified security wizard with automated “checking” to identify potential security exposures
• Extensions to support .NET APIs
• Multi-version and re-locatable installation for easier install, testing, and migration
• MQ v7.5 on Unix and Windows can support multiple installations on a single OS image

Why IBM WebSphere MQ v7.5 - Middleware News

Why WebSphere MQ v7.5

WebSphere MQ v7.5 provides additional enhancements to IBM ® Universal Messaging to deliver a single, integrated offering for all core messaging functions. Get the advantage of a smaller install footprint, simpler maintenance and eliminate the need for separate packages. Add as you need.

WebSphere MQ Advanced 7.5 – for developers

With this release, developers can install and use the entire WebSphere MQ Advanced stack (MFT, AMS, Telemetry) on their personal development machines without needing to pay a PVU based license. This new licensing option is priced per ‘Authorised User Single Install’ which effectively means a fixed price per developer exclusively for their development use.

Enhancements include

– A new JavaScript™ messaging API for use with MQTT, to allow JavaScript users to code mobile messaging applications with less programming
– Support for native iOS and Android applications to use mobile messaging (ships as part of the WebSphere MQ Client Pack for Mobile and M2M Messaging)
Integrated Managed File Transfer – WebSphere MQ File Transfer Edition, previously available separately, is now integrated as an optional feature of WebSphere MQ server component as WebSphere Managed File Transfer Service. Additional separately installable endpoints, WebSphere MQ Managed File Transfer Agents, are part of the package, installable subject to entitlement.
Integrated Advanced Message Security – Protect the security of your message contents without the need to change the application code itself. WebSphere MQ Advanced Message Security, previously separately available is now tightly integrated as an optional installable component as part of the WebSphere MQ v7.5 package. As previously, entitlement should be purchased prior to use..
Improved application isolation – With the ability to configure multiple transmission queues in WebSphere MQ clustered environment, WebSphere MQ v7.5 enables applications with different workloads and performance requirements to operate at their own rate without impacting other applications,
Enhancements for the Managed File Transfer capabilities – File transfer audit information can now be written directly to the file system for logging providing an additional configuration choice.
Enhancements for WebSphere MQ Advanced Message Security – Enhanced protection for configuration information used by WebSphere MQ Managed File Transfer
Wider access to the Extended Transactional (XA) client for all customers – The XA client is available for use in all client deployments without additional entitlement for connecting to WebSphere MQ queue managers WMQ V7.0.1, WMQ V7.1 and WMQ V7.5 . Realize this benefit through the download and acceptance of the updated License Information Documents for each WMQ Server.
Using WebSphere MQ Telemetry Standard Client – Use of the WebSphere MQ Telemetry Client requires purchasing an entitlement for WebSphere MQ Telemetry Clients for each WebSphere MQ Server installed that will have WebSphere MQ Telemetry clients connected to it, with no limit to the number of clients connected; applicable to WebSphere MQ v7.5, WebSphere MQ v7.0.1 and WebSphere MQ v7.1.

Version Comparison Table

Feature	WebSphere MQ V6.0	WebSphere MQ V7.0	WebSphere MQ V7.0.1	WebSphere MQ V7. 1	WebSphere MQ V7. 5
Special Licensing for developers
JavaScript™ messaging API for use with MQTT
Support for native iOS and Android applications
Integrated Managed File Transfer
Integrated Advanced Message Security
Integrated Telemetry
Multiversion install capability on distributed platforms
Enhanced security
Cloud support
Enhanced clustering
Multicast capability
Improved performance on distributed platforms
Extension to support for .NET APIs
Multiple instance queue managers for higher availability
Automatic client reconnect for higher availability
Increased visibility and auditability of configuration changes
Enhanced SSL security support
Service Definition wizard
IBM Message Service Client for .NET developers
Windows® Communication Framework support for .NET developers
Simple File Transfer, Quick Tour
New cross-platform configuration tooling
Find out what the system is doing, and influence it
Easier problem determination and problem avoidance
Exploiting z/OS services
Exploiting 64-bit address space
Runs on Linux and Windows
Connections can be local or direct client or via intermediate queue manager
Supports SSL for secure communication
Vendors and users can develop new function and integrate seamlessly
New options to be put on the “right mouse button” menus for objects
New top-level entities (like “queue managers” and “QSGs”)
Plug-ins do not need to duplicate configuration work like getting list of queue manager
NO charge for XA Client

Why is WMQ V7.5 not supported on z/OS or System i?
A key goal of WMQ V7.5 is to improve the overall Installation process for the WMQ, WMQ FTE and WMQ AMS functions. On Distributed platforms, the installation of the WMQ FTE and WMQ AMS products differed from that for MQ itself and it was felt that improving this was a key priority. This has never been seen as an issue for our z/OS customers, where products had always conformed to a common install process, and thus this key aspect of the release is not meaningful for z/OS customers. Additionally adding a separate release of WMQ on z/OS without any substantial major function would have been highly disruptive to customers who have long migration planning cycles between each release – especially since we have just released MQ V7.1 which contains significant function of particular value to z/OS customers.