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
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.
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 Q
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.
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
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.
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:
Or start trace only for one queue manager:
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:
Format the trace files:
Or format wrapping trace files:
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 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:
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:
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:
- 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.
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
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 |
- 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.
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
same
QMNAME 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:
- By
simulating activity on the connection, network layer software that is
responsible for closing inactive connections is less likely to shut down
your connection.
- 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.
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 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.
