Websphere MQ admin guide

Prepared By RAM.
Please contact me @ 09632073251 (Online & Class room Trainings)
WebSpehere MQ Administration Training Notes
Middleware :
Software that facilitates exchange of data between two application programs within the same
environment, or across different hardware and network environments.
As shown in below diagram, conceptually, middleware resides between the application layer
and the platform layer (the operating system and underlying network services
Message-oriented middleware (MOM): It is software or hardware infrastructure supporting
sending and receiving messages between distributed systems. MOM allows application modules
to be distributed over heterogeneous platforms and reduces the complexity of developing
applications that span multiple operating systems and network protocols

Prepared By RAM.
Please contact me @ 09632073251 (Online & Class room Trainings)
MQ: Messaging and Queuing
Message queuing is a method of program-to-program communication. Programs within an
application communicate by writing and retrieving application-specific data (messages) to/from
queues, without having a private, dedicated, logical connection to link them.
Messaging means that programs communicate with each other by sending data in messages and
not by calling each other directly.
Queuing means that programs communicate through queues. Programs communicating through
queues need not be executed concurrently.
MQSeries is an IBM implementation of MOM , MQSeries applications (local or remote)
communicate by putting messages on queues and by taking messages out from queues by using
Message Queue Interface (MQI) and MQSeries API.
A message from a sending application is placed on a queue, where it then waits for a signal that
receiving queue is ready to accept it.
Maintaining the messages queues, the relationships between programs and queues, handling
network restarts and moving messages around the network is under responsibility of MQSeries

Prepared By RAM.
Please contact me @ 09632073251 (Online Class room Trainings)
Advantages of WebSpehere MQ:
Common application programming interface
Assured message delivery
Time-independent processing

Prepared By RAM.
Application parallelism.
Asynchronous / Synchronous messaging support.
Faster application development.
Independent Operating system.
Point-to-point messaging
Publish and subscribe messaging
Request and reply messaging
Persistent and non-persistent messages
Asynchronous Messaging - Eliminates time dependency between applications.
Loosely coupled Architecture - Applications can be developed independent of each other
Applications can communicate independent of platform and the technologies
Assured and one time message delivery
Communication can be secured using one-way or two-way SSL.
Message Driven processing.(Triggering)
Figure 1
Message: Everything (Any piece of business data) is called a message in middleware.
4 Types of messages:
1. Request: A message for which a reply is expected.
2. Reply: A reply to a request message.
3. Datagram: A message for which no reply is expected.
4. Report: Is an occurrence of an issue or an error.

Prepared By RAM.
MQ:
32+ platforms: AS/400, Z/OS, all UNIX flavors (LINUX, SOLARIS SPARC, SOLARIS
INTEL, IBM AIX and HP_UX), Windows and ISERIES.
Languages: COBOL, C, JAVA, ASSEMBLER, .NET, JMS
MQ has two types of software’s:
1. MQ Server: If you installed MQ Server s/w on a machine an MQ service will run on the
machine and you can define all the WebSphere MQ objects(for example, Queue Manager,
Queues etc.,). 15-20 min
2. MQ Client: If you intall MQ client S/W on a machine, there will be no service run that
machine, it is a set of libraries used to communicate with MQ Server running on the Server
machine). 2-3 min
MQ Objects;
Queue Manager:
It is the overall governor for the entire WebSphere MQ system and its providing queuing
services to one or more clients, It is also a WebSphere MQ object.

Prepared By RAM.
Queue: Queue is MQ object and it is the safe place to store the messages, queues are four types.
Local Queue: An actual queue for which storage is allocated.
Remote Queue definition : A definition of a queue on a different queue manager (it
contains address about the remote queue manager)
Model Queue: A template whose properties are copied when creating a new dynamic
local queue (“create queue xxx “like” queue yyy).
Alias Queue: Another name for a local or remote queue. Typically used to switch queue
destinations without modifying program code
Local Queues:
Queues are defined as objects belonging to a queue manager. MQSeries knows a number of
different queue types, each with a specific purpose. The queues you use are located either in your
machine and belong to the queue manager to which you are connected, or in your server (if you
are a client). Figure 10 lists different queue types and their purposes. More detailed information
is below
Some properties of local queues:
• Maximum Message Size
• Maximum Queue Depth

Prepared By RAM.
• High/Low Factors
• Enable/Disable Put or Get
• Persistent/Not Persistent
Channel: A channel is communication path between the two queue managers, channels are
again 2 types.
Messaging Channels : Messaging channels are one way piping channels, these will be
used for either sending or receiving the messages, these are 6 types.
Sender
Receiver
Server
Requester
Cluster Sender Channel
Cluster Receiver Chanel
MQI Channels. : MQI channels are two way piping channels, these will be used for
sending and receiving the messages, these are 2 types.
1. Server-connection Channel
2. Client-Connection Channel
Message Channels work only in pairs:
1) Sender-Receiver - Sender starts the channel (Sender initiates the connection and
requests the receiver to start).
2) Requester-Server - Requester starts the channel (Requester requests the server
at the other end to start). Server can also start the channel if it has connection name
of the requester end.
3) Requester-Sender - Requester starts the channel and Sender terminates the call.
4) Server-Receiver - Similar to Sender-Receiver but Server should have the
connection name for the other end.
5) Cluster-Sender - Used by queue managers in cluster to send cluster information to
full repository queue manager and to send messages to other queue managers.
6) Cluster-Receiver - It is used by queue managers in cluster to receive information
about cluster and to receive messages from other queue managers.

Prepared By RAM.
How Messages Move Across Channels:
Listener: A Listener is a MQ services it listens outside network request and it should be running
with unique port number; the default port number for MQ is 1414.
Process Definition: This is an MQ object and this will be used for triggering purpose and this
we be used for to give the path which we need to invoke the particular application while trigger
invoke.
Name List:
The Web Sphere MQ application accesses the namelist at run time and creates a distribution list that
contains all of the queue names from the namelist. The application opens the distribution list in the
same way that it opens a queue. When a message is sent to the distribution list, the message is sent to
each queue in that list.
MQ Administration can done using:
1. MQSC (MQ script commands).

Prepared By RAM.
2. Control commands.
3. MQ Explorer: It is a GUI tool built on top of the eclilipse platform and is available on
Windows Intel and Linux(X86) machines.
4. PCF(Programmable Format Commands).
Message: Message is logical in MQ, message consists of two parts:
1. Message Header or Control information: This contains the complete information about the
message. For example, the date and time the message was put, the user who put the message
the type of O.S that put the message etc., The length of the header will be around 324 bytes.
2. Message Data: This is the actaual business data.
Once message arrived to Queue, then queue manager will add to message with Queue header
details.
About Messages
A message consists of two parts:

Prepared By RAM.
1. Data that is sent from one program to another
2. The message descriptor or message header
The message descriptor identifies the message (message ID) and contains control information,
also called attributes, such as message type, expiry time, correlation ID, priority, and the name
ofthe queue for the reply.
A message can be up to 4 MB or 100 MB long, depending on the MQSeries version you use.
MQSeries Version 5 (for distributed platforms) supports a maximum message length of 100 MB.
The Message Descriptor
The table below contains some interesting attributes of the message descriptor. We mention them
here because they explain some of the functions the queue manager provides for you
put: Writing a message into a queue. This is similar to inserting a record into a DB2 table.
get: Reading or getting a message from a queue. This is similar to selecting a record from a DB2
table.
MQI (Message Queuing Interface):
It is the interface between an MQ application program and MQ Queue Manager or Server. MQI
provides set of calls thru that application program can put and get messages to and from the
queue.
Note: The default message get in MQ is destructive, if you want a message to be get in browse
mode the application program has to set the options for the Browse get in the get message
options structure.

Prepared By RAM.
SQL: It is interface between an application program and the physical relational database (it can
be DB2 or Oracle).
Programming languages used for as Interface to connect MQ
Ex:
MQ COBOL (Mainframe or AS/400 MQ application development)
MQ C
MQI CALLS:

Prepared By RAM.
MQCONN : establishes a connection with a queue manager using the standard bindings.
MQCONNX: establishes a connection with a queue manager using fastpath bindings. Fastpath
puts and gets are faster, but the application must be well behaved, that is, well tested. Application
and queue manager run in the same process. When the application crashes it takes the queue
manager down with it. This API call is new in MQSeries Version 5.
A. To put message(s) to the queue.
1. MQCONN: This is the call to connect to the queue manager.
2. MQOPEN: This is to open the queue object.
3. MQPUT: Call to put the message(s) into a queue.
4. MQCLOSE: To close the opened queue.

Prepared By RAM.
5. MQDISC: To disconnect from the queue manager.
Note: #amqsput Queue-Name QMGR_NAME is the sample program to put a message into
the queue
B. To get message(s) from the queue.
2. MQOPEN: This is to open the queue object.
3. MQGET: Call to get the message(s) from the queue.
4. MQCLOSE: To close the opened queue.
Note: #amqsget Queue-Name QMGR_NAME is the sample program to get a message into
the queue
C. To put a single message into the queue.
2. MQPUT1: To put a single message into the queue.
D. To inquire and set the attributes of a queue
8. MQINQ: To inquire about the attributes of a queue.
9. MQSET: To set the attributes of a queue.
E. To commit and rollback the MQ server changes.
10. MQCMMIT: To commit the MQ changes.
11. MQRLBK: To roll back the MQ changes.
Communications:

Prepared By RAM.
1. Point to Point Communication
2. Pub/Subscription communication
Point to Point communication can be done in following ways.
Local Communication
Inter communication
Clustering
Client – Server Communication
Multi hopping
Alias Queue manager implementation
Multi-Instance Queue manager setup
Overlapping Cluster setup.
1. Local Communication:
Create A local queue and connect to the queue manager using the sample applications.
DEFINE QL (LOCAL Q NAME)
And try to put using test message:
AMQSGET QUEUENAME QMGRNAME to get the message .
2. Inter Communication (Distributed Queue management)

Prepared By RAM.
Inter communication means establishing the communication between the 2 or more queue
different queue managers which are running in heterogeneous or homogeneous systems. Or same
host or different hosts.
CLASS – 2 date:10-5- 11
MQ Control Commands:
#strmqcfg: Command to start the MQ explorer tool.
#crtmqm QMGR_NAME: Command to create the queue manager.
#strmqm QMGR_NAME: Command to start the queue manager.
#endmqm QMGR_NAME: Command to stop the queue manager.

Prepared By RAM.
#dltmqm QMGR_NAME: Command to delete the queue manager.
#dspmqver : Command to get the MQ version information.
#dspmq : Command to get information and status of the queue managers +in
the system+++
Note: All the sample programs are available in C:Program FilesIBMWebSphere MQtools
(/opt/mqm/tools on UNIX machines)..
Note: The queue data will physically be stored in C:Program FilesIBMWebSphere
MQQmgrsPRODqueuesQ1 (/var/mqm/qmgrs/QMGR_NAME/queues/QUEUE-NAME)
Note: The default MQ get is destructive(the messages will be deleted from the queue), to change
this to browse we have to set the get message options in the MQGET call.
Note: All the excutable MQ commands and programs all are available in C:Program
FilesIBMWebSphere MQbin (on UNIX machines /opt/mqm/bin)..
CLASS-3 date:11-05-11

Prepared By RAM.
Headers:
These header are available in the form of copybooks in COBOL, includer files in C language and
Classes in Java. The length of the message header will be around 320 bytes. The message data
depends on the type of the business transaction, it can be 1kb, 2kb etc.,
1. MQMD (Message Descriptor or message header or control information)
MQMD-MSGTYPE: This is the type of the message, this is application driven and the default
message type is datagram.
MQMD-ENCODING: This is machine dependent and queue manager driven and this will tell,
the numeric representation of data on a particular server.
MQMD-CODEDCHARSETID: this is machine dependent and queue manager driven and this
will tell, the character set identifier of the machine that put the message into the queue.
MQMD-FORMAT: this contains the format of the data that was put to the queue, this is queue
manager driven.
MQMD-PRIORITY: Any message we put to the queue can have priority of 0-9. 0 is the lowest
priority and 9 is the highest priority. The messages with hight priority will be processed first if
two messages placed at the same time into the queue and with different priorities. Priority value
has a meaning if the Message Delivery Sequence queue attribute is set to priority.
Simillar to the persistence, priority can also be set in the program or the message will take the
queue default priority.
MQMD-PERSISTENCE: Persistence messages will survive the restart of the queue manager.
Persistence messages will be written to the logs and MQ queue and non-persistent messages will
be written only to the queues and will get deleted in the queue manager re-start.
We can set the persistence to persistent or non-persistent in the program. If no t set in the
program MQ will take the queue default persistence.
MQMD-MSGID: This is the identifier for the message, generaly messages from a particular
client can be placed into the queue with unique message identifiers.
MQMD-CORRELID: Befor sending the reply back to the client, we can copy the message id to
the correlation identifier, so the client can correlate the request with the reply.

Prepared By RAM.
MQMD-BACKOUTCOUNT: This will tell the number of times the same message was put to
the queue and get from the queue, it is 0, if the message was put first time and 1 for the second
time, and 2 for the third time and etc., Its value is more than 1 or 2 if the application program
processing the message is in infinite loop, This field is queue manager driven.
MQMD-REPLYTOQ: For a request message, this is the queue where to send the reply.
MQMD-REPLYTOQMGR: For a request message, this is the queue manager where to send the
reply.
MQMD-USERIDENTIFIER: This contains the Id of the user who put the message. This will be
your windows login id or mainaframe RACF or TSO id or a UNIX user iD. Application also can
write some data into this field.
MQMD-APPLIDENTITYDATA: This can be filled by the application to give the identity of the
client that put the message into this queue.
MQMD-PUTAPPLTYPE: This is the type of the server that put the message into the queue, for
example: 32-bit windows, UNIX or a mainframe CICS transaction Server. This field is queue
manager driven.
MQMD-PUTAPPLNAME: This contains the application program which put the message into
queue. This is queue manager driven.
MQMD-PUTDATE: Date the message was put to the queue. This will written only by the queue
manager, we can not write some data into this field.
MQMD-PUTTIME. Time the message was put to the queue. This will written only by the queue
manager, we can not write some data into this field.
MQMD-APPLORIGINDATA: This can be filled by the application to give the details about the
origin of the client that put the message into the queue.
MQMD-OFFSET: This is the starting position of the message in the message data area. 0 means
first byte. This is other than zero, if your message is segemented.
MQMD-ORIGINALLENGTH: This is the length of the message that was put to the queue, this
is queue manager driven field.
Persistent messages survive the re-start of the queue manager.

Prepared By RAM.
These messages will written to the log and queue location, Whenever queue manager is re-started
all the messages will automatically deleted from the queue and only the persistent
messages will get copied from the logs into the queue.
Non-persistent messages cannot be written to the logs, we will lost this messages after the queue
mager re-start.
Priority: 0-9
Messages with high priority will be processed first when multiple messages with different
priority values were put to the queue.
CLASS-4
DATE:12-05-11
TYPES OF QUEUES:
1. Alias Queue: It is a local queue, it is a logical queue and will be resolved to a base queue.
Using the alias queues, we can set different attributes for persistence and priority on the same
base queue for different clients. We can also set different put and get authorities for different
clients using the alias queues on the same base queue.
We no need to change the base queue, we can set different put authority, get authority, priority
and persistence for diffenents client thru the alias queues.
MQRC 2016: Get inhibited on a queue.
MQRC 2051: put inhibited on a queue.
MQRC 2085: Object not found in the system.
MQRC 2058: Queue Manager name error (Queue Manager is not found in the system).
4. Model Queue: Model is just a template for defining dynamic queues at run time.
Dynamic queue are defined in the program at runtime taking the attributes from the model
queues.
There are two types of dynamic queues:
1. Temporary Dynamic Queue: This queue will be created in the program at runtime and will be
deleted after the program is completed.
2. Permanent Dynamic Queue: This queue will be created in the program at runtime and will stay
in the system permanently after the program is completed.
Dynamic queues will be created using the AMQ* prefix.

Prepared By RAM.
For defining the permanent model queues set the Definition Type as Permanent Dynamic.
For defining the temporary model queues set the Definition Type as temporary Dynamic.
Once a model is opened in the program automatically MQ will create Temporary or a Permanent
Dynamic queue based on the type of the model queue.
Runmqsc:
#runmqsc TEST
DISPLAY QLOCAL(*) ALL
DISPLAY QLOCAL(A*) ALL
LOGS:
Logs contains the persistent messages, uncommited unit work(uow), the record image of an
object.
MQ has two types of logs:
1. Circular logs (default logging in MQ)
2. Linear logs
Log path: C:Program FilesIBMWebSphere MQlog (Windows)
/var/mqm/Qmgrs/log (UNIX)
Default logging is circular logging, once all the logs are filled, MQ will start re-using from the
first log, So, we cannot the log out of space issues. We cannot have record of an object if we use
circular logging for the queue manager logs.
In Liner logging once all the primary and secondary logs allocated are filled, we will log out of
space issues.
Queue Manager Data Path: C:Program FilesIBMWebSphere MQqmgrs/QMGR_NAME
/var/mqm/qmgrs/QMGR_NAME
It contians all the queues, channels, process etc.,
Note: Major of the installations will have the circular logging. But there is a legal thing in some
financial projects we should use the linear logging to avoid the loss of log data.
How to increase the primary and secondary logs, once the queue manager is created:
Windows: Change the registry entries for the queue manager logs. Command is regedit.

Prepared By RAM.
UNIX: Updata the queue manager configuration file /var/mqm/Qmgrs/QMGR_NAME/qm.ini
file logs
entries.
Note: The increased primary log files can be treated as secondary and will be created on a need
basis simillar to how the seconday log file will be created.
Once the update is done re-start the queue manager.
Note: The Maximum size of a single log file is 65,535 (256MB)
Total log files size = 64GB(win)/128GB(unix)
The total number of primary and secondary log files should be 255.
How to calculate the best log file size:
1. Maximum number of persistent messages that can sit in the system at any point of time.
2. Consider the activity between two syncpoints in a business application.
3. Calcualte the down time (how much time required to shift the activity from a live system to a
back up system --- consider here the MQ activity for that time)
Note: Give all the required log space in the primary log files itself.
If I need 1GB of log space, create 4 primary log files with 256 MB of space, so you never get the
log file issues even the activity is more than calculated seconday will take care.
ERRORS:
Errors:
C:Program FilesIBMWebSphere MQerrors: This contains errors related to the system level.
/var/mqm/errors
C:Program FilesIBMWebSphere MQQmgrsQM2errors: Which contains the queue manager
specific errors. /var/mqm/Qmgrs/QM1/errors
LOG: This contains the uncommitted unit of work, persistene messages and record of an objects.
Log path: C:Program FilesIBMWebSphere MQlog
/var/mqm/Qmgrs/log
Default logging is circular logging, once all the logs are filled, MQ will start re-using from the
first log, So, we cannot the log out of space issues.

Prepared By RAM.
We cannot have record of an object if we use circular logging for the queue manager logs.
In Liner logging once all the primary and secondary logs allocated are filled, we will log out of
space issues.
Queue Manager Data Path: C:Program FilesIBMWebSphere MQqmgrs/QMGR_NAME
It contians all the queues, channels, process etc.,
FFST:
#amqldbgn -p 4028
System errors
Queue Manager error
trace files
generate FFST files
TYPES OF ERRORS:
Errors:
2 types of errors:
1. System level errors:
C:Program FilesIBMWebSphere MQerrors
/var/mqm/errors
2. Queue manager level errors:

Prepared By RAM.
C:Program FilesIBMWebSphere MQQmgrsFIDerrors
In the C:Program FilesIBMWebSphere MQerrors , /var/mqm/errors MQ MQ will
automatically create FFST (First Failure Support Technology) reports that contains the errors
information in the system. FFST contains the process Id that has the error.
#amqldbgn -i PID
We can also create trace files for different application process to help in resolving serious errors
with the application process:
#strmqtrc -i PID
Make sure to stop the tracing
#endmqtrc -i PID
Trace files wil be stored in C:Program FilesIBMWebSphere MQtrace
/var/mqm/trace
CLASS-5 DATE:16-05-11
TRIGGERING:
Automatically starting a program or transaction when trigger conditions are satisfied for a queue.
1 . Trigger Control: It must be on for a trigger queue
2. Trigger Type:
a.First: Trigger conditions will be satisfied whenever the first message arrives on queue.
b.Every: Trigger conditions will be satisfied for every message arrives on the queue.
c.Depth: Trigger conditions will be satisfied whenever depth number of messsages arrived on
the queue.

Prepared By RAM.
3. Trigger depth: This has the meaning when the trigger type is Depth. When Depth number of
messages arrived on the queue, trigger conditions will be satisfied for the queue.
4. Trigger Message Priority: All the messages with priority = this proiority of the message
value will be taken into consideration for triggering.
5. Initiation Queue: It is local queue, queue manager will write the trigger messages into
this initiation queue whenever trigger conditions are satisfied for the queue.
6. Process Object: Contains the application program or the transaction to be started.
There is a continously running trigger monitor program which will always look into this
initiation queue for trigger messages and whenever a trigger message arrives, the trigger monitor
program will read destructive that message and start the application program or the transaction.
Start the trigger monitor program:
#runmqtrm -q INITQ-Name -m Queue-Manager-Name
Notee: First will useful when ever you have to process some number of messages as a unit of
work or batch. Only one trigger message will be enough to process all the messages in the queue.
Scenario1: Trigger queue is getting one message every 5 min from a client, In this case there is
no diff b/w trigger type first and every.
Scenario2: Trigger queue is getting 100 messages in one shot every one hours. In this case if I
give trigger type as EVERY, 100 trigger messsages will generated and system will be heavy
loaded. If we give trigger TYPE as First in this case, only one Trigger msg will get generated
that will be enough to process all the 100 messages in the queue. The application program once
started has to make sure to get all the messages from queue(check for MQ return code 2033 --
enf of the queue) to process all the message with a single trigger message.
CLASS-6 17-05-2011
INTERCOMMUNICATION:
Sending a message from one queue manager(local machine) to another manager(remote
machine).
Sender(FID):

Prepared By RAM.
1. Local definition of remote queue (QREMOTE): This is a logical queue.contains the target
queue name (JPMC.QLOCAL) , remote queue manager name(JPMC) and transmission queue
namer(XMITQ).
The name of the transmission queue must be the same as the remote queue manager.
2. Trasmission queue (JPMC): This is a local trigger queue with the Usage set XMITQ or
transmission. The name of this queue must be the same as the target queue manager name.
3. Initiation Queue (FID.INITQ): This the local queue where the queue manager will write the
trigger messages when channel trigger happend or trigger conditions are satisfied for the
transmision queue. This should be defined based on the System queue
SYSTEM.CHANNEL.INITQ.
4. Process(FID.PROCESS): This contains the sender channel (FID.TO.JPMC) to be started (in
user data field) when trigger conditions are satisfied for the local transmission queue.
5. Sender channel(QM1.TO.QM2): This contains the machine name or address of the receiver
queue manager (including the port number) and the transmission queue(QM2) and the transport
protcol(TCP.
6. Start the channel initiator program against the initiation queue.
#runmqchi -q INITQ-NAME -m QMGR-NAME
#runmqchi -q QM1.INITQ -m QM1
Once trigger conditions are satisfied for the transission queue, queue manager will write a trigger
message into the initiation queue, the channel initiator program will look for trigger messages in
the initiation queue continously, once a trigger message is arrived, it will get that message which
contains the sender channel to be started and will start the sender Chanel.
Note: Application programmers will only have acces to the QREMOTE. Once the message was
put to the QREMOTE it will be moved to the transmission queue.
Note: Once the message was put to the QREMOTE, Queue manager will add a Transmision
header to the message which contains the remote destinaltion address and route it to the
transmission queue, this header contains the remote machine queue name, queue manager. This
will be removed once the message reaches the destination, before placing the message on the
target.

Prepared By RAM.
Receiver(JPMC):
1. JPMC.QLOCAL : this is the target for the messages.
2. Receiver channel(FID.TO.JPMC): the name must be same as the sender channel.
3. Listener: Listener is a WMQ object, the Listener looks for incoming MQ network requests on
a particular port number. WMQ queue manager default port number is 1414.
CLASS-7
Clustering:
Logical grouping of queue managers.
Ad:
1. Reduced administration and monitoring in a network
2. Work Load balancing
3. High Avaliability.
Full Repository Queue Manager: This contains the complete information about the cluster.
Repository information will be stored in SYSTEM.CLUSTER.REPOSITORY.QUEUE and the
repository information will be shared on SYSTEM.CLUSTER.COMMAND.QUEUE.
Partial Repository Queue Manager: This contains the information aboue the object in the remote
queue manager with which it is communicating now. Repository information will be stored in
SYSTEM.CLUSTER.REPOSITORY.QUEUE and the repository information will be shared on
SYSTEM.CLUSTER.COMMAND.QUEUE.
In any cluster we should have atleast two queue managers as act the full repository queue
managers, even if one full repository queue manager is down, the other full repository queue
manager will share the information with the Partial repository queue managers.

Prepared By RAM.
At any point of time the information in the full and partial repositories will be in sync.
QM1:
1. Alter the queue manager definition and select the full repository, if it is a full repository
queue managers.
2. Cluster sender channel --- will point to any other full repository queue manager, the
repository informtion will be shared with the other full repository on this channel.
3. Cluster Receiver channel --- For receiving messages from any other queue manager manager
in the cluster. This will point to itself.
4. MQ listener: For listening for MQ requests on a particular port number. 1414(default)
5. SYSTEM.CLUSTER.TRANSMIT.QUEUE -- This will act as the transmission queue for
transmitting the messages to any queue manager in the cluster.
QM2
1. Alter the queue manager definition and select the full repository, if it is a full repository
queue managers.
QM3

Prepared By RAM.
QM4
Cluster Queue: Cluster queue is a local queue, which is advertised in the cluster as the cluster
queue.
CLUS:
With 4 Queue managers Q1, Q2, Q3 and Q4.
Work Load Balancing: Sharing the workload in the cluster.
1. Create a cluster queue with the same name on all the queue managers (Creating the same
instance of the queue).
2. Alter the queue managers to which the applications (Local or Remote) are connecting set the
Cluster Work Load Use Queue to 'ANY'.
3. Alter the cluster queues the applications (Local or Remote) are opening, make the Default
Bind Type 'Not Fixed' and Cluster Work Load Use Queue to 'ANY'.
Alter the cluster receiver channel:
set Cluster work load channel weight:
Q1 - 50
Q2 - 20
Q3 - 15
Q4 - 15

Prepared By RAM.
1. Add/Remove a queue manager to the existing Cluster CLUS:
Adding:
1. Listener running.
2. Alter the queue manager and set Repository attribute to the cluster name, if it is a full
repository queue manager.
3. C.S.C
4. C.R.C
5. Cluster Queues.
Stop all the new connections to the to be removed queue managers. Also allow the existing
applications to be completed.
1. Suspend the queue manager frm cluster
2. stop the cluster sender and receiver channels
3. Delete the cluster sender and receiver channels.
CLASS-8
Channel States:
1. Initialization state: In this state channel will initialize itself.
2. Binding state: This is the state the sender channel will bind with the receiver system, it will
do a internal ping to receiver channel to check for any issues with the receiver system. Once the
channel completed states 1 and 2 successfully, the sender channel will get started and it drives
also the receiver channel to be started.
3. Running: This is the channel running state, if the sender channel is running, the corresponding
receiver channel will also be in the running state and messages will be moved from the sender to
the receiver side.
4. Inactive: If the sender channel is idle for more than the disconnect interval mentioned in the
sender channel's disconnect interval attribute, the sender channal and also the receiver channel

Prepared By RAM.
will be moved to the inactive state. This state is not an issue, this is to save the resources on the
system. Whenever a new message was placed on the XMIT queue, automatically the sender
channel will again go to the running state.
If the Sender is getting a message every one hour, in this case it is good to give less disconnect
interval to save the system resources.
Sender is getting a message 5 min, in this case it is good to give a high disconnect interval to
save the system resources.
5. Paused: We will see this channel state only for the receiver channel. This occurs if the
receiver target queue is full. This is an issue. The moment the receiver channel went to a paused
state an alert will be issues to resolve the issue. If the target queue is full the messages will be
lost if we have not defined dead letter queue for the queue manager.
6. Retry: This is an issue state. That should be resolved immediately, this indicates some issue
with the remote system queue manager, for example, the remote sever or the queue manager is
down or the Listener object is not running on the remote queue manager or there is some other
network issue (For example, the port number and machine address in the sender channel is
wrong).
If the channel is in re-try state MQ queue manager will trigger off the trasmission queue, so
mesages will stay in the transmission queue. Once the issue is resolved(starting the queue
manager or the Listener), mq will autocorrect the system by using the sender channel re-connect
intervals. Sender channel will come to running and the trasmission will be triggered on
automatically and the messages sitting in the transmission queue will be sent to the remote
Queue Manager's target queue.
7. Stopped: This can a manual stop of the channel or the channel went to the stopped state from
the retry state. If the channel is in retry, queue manager will wait for the short and the long retry
count intervals in the sender channel definition for the issue to get resolved, if the issue is not
resolved within this period the channel will go to the stopped state.
Note: If the channel is in the Sttopped STate, we have to start that channel manually.
Dead Letter Queue:
(Undelivered Message Queue):
This is local queue and will be attached to the MQ queue manager.

Prepared By RAM.
If the Queue manager is not able to put the messages to the target queue, the messages will be
routed to the dead letter queue. So, there will no messages loss in the network.
All the messages moved to the dead letter queue, will have a dead letter header attached, which
will contain the reason why the message was moved to the dead letter queue.
Default Queue Manager:
If an application program has not connected to any queue manager in the program, the program
will automatically get connected to the default queue manager if available. If default queue
manager is not available in the system we will get return code of queue manager not found.
MQCONN : Not required
MQOPEN
MQPUT/GET/
MQCLOSE
MQDISC : Not required
To create a defualt queueu manager: #crtmqm -q QMGR_NAME...
To Change the default queue manager to a different queue manager:
1. Win: Update the win registry default queue manager entry.
2. UNIX Systems: update the default queue manager entry in /var/mqm/qms.ini configuration
file
Dead Letter Queue:
(Undelivered Message Queue): It is a local queue attached to a queue manager. Messages will be
automaticalled by the queue manager moved to the dead letter queue if there are any issues
putting the messages to the target queue.
All the messages moved to a dead letter queue contains a dead letter header. Dead letter header
the reason why the message was moved to the DLQ.

Prepared By RAM.
Message in DLQ has : MQDLQ(Dead Letter Header) + MQMD (Message Header) + Message
date
Some times application programs also move the messages to the dead letter queues, if there are
some fatal issues occurred while processing the messages
What to do if a message was moved to the dead letter queue:
1. We have to check for the reason why the message was moved to the dead letter queue in the
dead letter header of the message.
2. Resolve the issue (For the example, if the reason in the dead letter headert tells that a
QUEUE_FULL condition occurs, increase the maximum queue depth and resolve the issue.
3. Copy the message from the dead letter queue, remove the dead letter header and put the
message manually back to the target queue. So, the message will get processed.
1. MQ Monitoring Tools: QPASA, NASTEL, MQMON. We have to set the monitoring
conditions for the dead letter queue. If a message was moved to the dead letter queue, issue an
alery thru sending a mail with the issue information to the MQ admin team memebers.
Automating the processing of messages in dead letter queue:
Dead Letter Handler: #runmqdlq is a system program that will do the the auto processing of
messages placed in the dead letter queue taking the input conditions given in the rules table.
When messages can not be delivered to the intended queue, the messages will be delivered to a
Dead Letter Queue (DLQ).
DLQ Handler
Once a message arrives on the DLQ you can automate the handling of that message using the
DLQ handler program. You can have the handler running and waiting for messages to arrive on
the DLQ or you can set up the DLQ to trigger the start of the handler program
runmqdlq DLQ QMGR rules.tb

Prepared By RAM.
where DLQ = name of your dead letter q
QMGR = queue manager name and
rules.tb is a file with the rules table
#runmqdlq QM2.DLQ QM2 C;rules.rul.txt
C:rules.rul.txt
WAIT(YES) RETRYINT(20)
REASON(MQRC_Q_FULL) ACTION(RETRY) RETRY(5)
REASON(MQRC_PUT_INHIBITED) ACTION(RETRY) RETRY(5)
REASON(*) ACTION(FWD) FWDQ('LOCALQ')
CLASS-9
Message context:
information allows the application that retrieves the message to find out about the originator of
the message.
The type of information falls into two categories: identity and origin context information.
Identity context: Identity context information identifies the user of the application that first put
the message on a queue:
UserIdentifier field
AccountingToken field
ApplIdentityData
Origin context

Prepared By RAM.
Origin context information describes the application that put the message on the queue on which
the message is currently stored. The message descriptor contains the following fields for origin
context information
PutApplType The type of application that put the message (for example, a CICS transaction).
PutApplName The name of the application that put the message (for example, the name of a job
or transaction).
PutDate The date on which the message was put on the queue.
PutTime The time at which the message was put on the queue.
ApplOriginData Any extra information that an application wants to include about the origin of
the message.
Errors:
2 types of errors:
/var/mqm/errors
#amqldbgn -i PID

Prepared By RAM.
#strmqtrc -i PID
#endmqtrc -i PID
/var/mqm/trace
MQ Security:
MQ Object Authority Manager (OAM): amqzfuma -- OAM process
The authorization service component supplied with the WebSphere® MQ products is called the
Object Authority Manager (OAM). By default, the OAM is active and works with the control
commands dspmqaut (display authority),dmpmqaut (dump authority), and setmqaut (set or reset
authority).
When an MQI request is made or a command is issued, the OAM checks the authorization of the
entity associated with the operation to see whether it can:
* Perform the requested operation.
* Access the specified queue manager resources.
dspmqaut or dmpmqaut
#dspmqaut -m QMGR1 -t queue -n QMGR1.QLOCAL -p user1
#dmpmqaut -m QMGR1 -t queue -n QMGR1.QLOCAL -p user1
#setmqaut -m QMGR1 -t queue -n QMGR1.QLOCAL -p user1 +allmqi
C:Documents and Settingskumardspmqaut -m TEST -t queue -n TEST.QLOCAL -p kumar

Prepared By RAM.
Entity kumar has the following authorizations for object TEST.QLOCAL:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr
C:Documents and Settingskumardspmqaut -m TEST -t queue -n TEST.QLOCAL -p Guest
Entity Guest has the following authorizations for object TEST.QLOCAL:
C:Documents and Settingskumarsetmqaut -m TEST -t queue -n TEST.QLOCAL -p Guest
+get +browse
The setmqaut command completed successfully.
get

Prepared By RAM.
browse
C:Documents and Settingskumarsetmqaut -m TEST -t queue -n TEST.QLOCAL -p Guest -
browse
get
To give the all the MQI access on a queue for a particular user:
C:Documents and Settingskumarsetmqaut -m TEST -t queue -n TEST.QLOCAL -p Guest
+allmqi
get
browse
put
inq
set
passid
passall
setid
setall

Prepared By RAM.
C:Documents and Settingskumardmpmqaut -m TEST -t queue -n TEST.QLOCAL -p Guest
profile: TEST.QLOCAL
object type: queue
entity: Guest@FRANKLIN-59KIIL
entity type: principal
authority: allmqi
To check the access authorities on a queue manager:
C:Documents and Settingskumardspmqaut -m TEST -t qmgr -p kumar
Entity kumar has the following authorizations for object TEST:
inq
set
connect
altusr
crt
dlt
chg
dsp
setid
setall
system
C:Documents and Settingskumardspmqaut -m TEST -t qmgr -p guest
Entity guest has the following authorizations for object TEST:

Prepared By RAM.
C:Documents and Settingskumarsetmqaut -m TEST -t qmgr -p guest +connect
C:Documents and Settingskumardspmqaut -m TEST -t qmgr -p guest
Entity guest has the following authorizations for object TEST:
connect
UNIX:
In unix operating system, the user must be added to the mqm group to get the administration
access on the MQ system. Root user also has no admin access on the MQ system. He also need
to be added to the mqm group to give him the administration access on the MQ system.
MQ –LINUX
Installation(Windows/Unix)
1. Createa a runtime path directory: /var/mqm (full access, chmod 777).
/var/mqm is the runtime path.
2.Create the product path directory /opt/mqm (full access, chmod 777)
/opt/mqm is the product path
3.copy the product tar file into a directory. /home/user-id/mq/mqv6.1.tar

Prepared By RAM.
4.unzip the tar file tar -zxvf mqc7.01.tar
5. accept the licence #licence.sh -accept
6. install the individual rpm pachages (MQ runtime and MQ server rpm packages are mandatory
to work with MQ).
#rpm -ivh package-name.rpm...
7. mqm admin group id will automatically created after the installation.
8. add the admins to this mqm group. Individual admin users will get the complete admin access
on MQ once they will get added to the mqm group.
9. product will be copied to /opt/mqm
/opt/mqm/tools - fixed
/opt/mqm/bin - fixed
/opt/mqm/eclipseSDK33
/opt/mqm/eclipse
/opt/mqm/java
/opt/mqm/licenses
10. run data will be in /var/mqm
/var/mqm/errors
/var/mqm/qmgrs
/var/mqm/logs

Prepared By RAM.
/var/mqm/trace
11. System configuration file /var/mqm/qm.ini. this contains the default queue manager, product
path, run path and mq connections (max).
12. Queue manager level configuration file /var/mqm/qmgrs/QMGR_NAME/qms.ini. This
contains the primary log files, secondary log files, logfile size etc.,
all control and mqsc commands are the same as in Windows.
If you do any changes to the configuration, we have to re-start the queue manager to apply the
changes to the MQ system.
MQ Quick Beginnings for Linux v7.01
After the installation, test the installation.
1. Create a queue manager.
2. Start a queue manager.
3. create a local queue.
4. put/get a message.
1. create the sender and receiver channels for communicating with the remote queue manager.
2. LDR, TQ, S.C, INITQ, PROCESS, CHIT program.
3. put a message on the logical Local Definition Of The Remote Queue and check for the
Message on the target system local queue.

Prepared By RAM.
#runmqsc
1. Status of the queues (Open Input Count, Open OutPut Count, Queue Depth).
#runmqsc Qmgr_Name
DISPLAY QSTATUS(B3.QLOCAL)
AMQ8450: Display queue status details.
QUEUE(B3.QLOCAL) TYPE(QUEUE)
CURDEPTH(4) IPPROCS(0)
LGETDATE( ) LGETTIME( )
LPUTDATE( ) LPUTTIME( )
MEDIALOG( ) MONQ(OFF)
MSGAGE( ) OPPROCS(1)
QTIME( , ) UNCOM(NO)
IPPROCS(0): This indicated the number of application programs opened the queue for getting
the messages.
OPPROCS(1): The number of applications opened the queue for putting the messages.
CURDEPTH(4): This indicates the number of messages currently sitting in the queue.
UNCOM(NO): This indicated any uncommitted activity against the queue.
2. Check the local queue attributes. runmqsc
DISPLAY QLOCAL (B3.QLOCAL) ALL
QUEUE(B3.QLOCAL) TYPE(QLOCAL)
ACCTQ(QMGR) ALTDATE(2011-04-28)
ALTTIME(22.13.53) BOQNAME( )

Prepared By RAM.
BOTHRESH(0) CLUSNL( )
CLUSTER(CLUSB) CLWLPRTY(0)
CLWLRANK(0) CLWLUSEQ(QMGR)
CRDATE(2011-04-26) CRTIME(22.10.36)
CURDEPTH(0) DEFBIND(OPEN)
DEFPRTY(0) DEFPSIST(NO)
DEFPRESP(SYNC) DEFREADA(NO)
DEFSOPT(SHARED) DEFTYPE(PREDEFINED)
DESCR( ) DISTL(NO)
GET(ENABLED) HARDENBO
INITQ( ) IPPROCS(0)
MAXDEPTH(5000) MAXMSGL(4194304)
MONQ(QMGR) MSGDLVSQ(PRIORITY)
TRIGGER NPMCLASS(NORMAL)
OPPROCS(0) PROCESS( )
PUT(ENABLED) PROPCTL(COMPAT)
QDEPTHHI(80) QDEPTHLO(20)
QDPHIEV(DISABLED) QDPLOEV(DISABLED)
QDPMAXEV(ENABLED) QSVCIEV(NONE)
QSVCINT(999999999) RETINTVL(999999999)
SCOPE(QMGR) SHARE
STATQ(QMGR) TRIGDATA( )
TRIGDPTH(1) TRIGMPRI(0)
TRIGTYPE(FIRST) USAGE(NORMAL)

Prepared By RAM.
3. Alter the queues(Increase the max queue depth, trigger on and off the queue,
increase/dec the maximum length of the message in the queue)
ALTER QLOCAL(B3.QLOCAL) MAXDEPTH(20000) MAXMSGL(4096) NOTRIGGER
12 : ALTER QLOCAL(B3.QLOCAL) MAXDEPTH(20000) MAXMSGL(4096)
NOTRIGGER
AMQ8008: WebSphere MQ queue changed.
4. Status of the channels(Running, stopped, inactive, retry).
17 : DISPLAY CHSTATUS(TO.B1) ALL.
CHANNEL(TO.B1) CHLTYPE(CLUSSDR)
BATCHES(0) BATCHSZ(50)
BUFSRCVD(0) BUFSSENT(0)
BYTSRCVD(0) BYTSSENT(0)
CHSTADA(2011-04-28) CHSTATI(22.23.53)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(192.168.1.2(3001)) CURLUWID(0000000000000000)
CURMSGS(0) CURRENT
CURSEQNO(0) EXITTIME(0,0)

Prepared By RAM.
HBINT(300) INDOUBT(NO)
JOBNAME(00000E5000001220) LOCLADDR( )
LONGRTS(999999999) LSTLUWID(0000000000000000)
LSTMSGDA( ) LSTMSGTI( )
LSTSEQNO(0) MCASTAT(NOT RUNNING)
MONCHL(OFF) MSGS(0)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME( ) SHORTRTS(0)
SSLCERTI( ) SSLKEYDA( )
SSLKEYTI( ) SSLPEER( )
SSLRKEYS(0) STATUS(RETRYING)
STOPREQ(NO) SUBSTATE( )
XBATCHSZ(0,0) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
XQMSGSA(2) XQTIME(0,0)
If the channel is in running or inactive status, then there will be no issue and if the channel is in
re-try or stopped state, that will be an issue.
5. Check the number of active connection against the queue managers?
19 : DIS CONN(*) ALL
AMQ8276: Display Connection details.
CONN(4D97B94D20000001)
EXTCONN(414D5143423320202020202020202020)

Prepared By RAM.
TYPE(CONN)
PID(4836) TID(1)
APPLDESC(WebSphere MQ Object Authority Manager)
APPLTAG(ebSphere MQbinamqzfuma.exe) APPLTYPE(SYSTEM)
ASTATE(NONE) CHANNEL( )
CONNAME( ) CONNOPTS(MQCNO_FASTPATH_BINDING)
USERID(MUSR_MQADMIN) UOWLOG( )
UOWSTDA( ) UOWSTTI( )
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)
CONN(4D97B94D20006801)
EXTCONN(414D5143423320202020202020202020)
TYPE(CONN)
PID(1972) TID(1)
APPLDESC( )
APPLTAG(WebSphere MQbinamqsput.exe)
APPLTYPE(USER) ASTATE(NONE)
CHANNEL( ) CONNAME( )
CONNOPTS(MQCNO_SHARED_BINDING) USERID(kumar)
UOWLOG( ) UOWSTDA( )
UOWSTTI( ) UOWLOGDA( )

Prepared By RAM.
UOWLOGTI( ) URTYPE(QMGR)
6. Status of the queue managers.
C:Documents and Settingskumardspmq
QMNAME(B3) STATUS(Running)
QMNAME(C1) STATUS(Ended normally)
QMNAME(C2) STATUS(Ended normally)
7. Check for the MQ return codes.
C:Documents and Settingskumarmqrc 2059
2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE
8. IBM program to check the message with the the message header or control information of the
message.
C:Documents and Settingskumaramqsbcg B3.QLOCAL B3
AMQSBCG0 - starts here
**********************

Prepared By RAM.
MQOPEN - 'B3.QLOCAL'
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 1208
Format : 'MQSTR '
Priority : 0 Persistence : 0
MsgId : X'414D51204233202020202020202020204D97B94D20007202'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'B3 '
** Identity Context
UserIdentifier : 'kumar '
AccountingToken :
X'16010515000000828BA628358A021A43170A32EB03000000000000000000000B'
ApplIdentityData : ' '
** Origin Context

Prepared By RAM.
PutApplType : '11'
PutApplName : 're MQjavajrebinjavaw.exe'
PutDate : '20110428' PutTime : '17010431'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 24 bytes
00000000: 4D65 7373 6167 6520 496E 6469 6120 5553 'Message India US'
00000010: 4120 4341 4E41 4461 'A CANADa '
No more messages
MQCLOSE
MQDISC

Prepared By RAM.
C:Documents and Settingskumarrunmqsc B3
1. Create a local queue based on some model queue and set the maximum queue depth for the
queue as 20000.
DEFINE QLOCAL(Q1) LIKE(SYSTEM.DEFAULT.LOCAL.QUEUE) MAXDEPTH(20000)
4 : DEFINE QLOCAL(Q1) LIKE(SYSTEM.DEFAULT.LOCAL.QUEUE)
MAXDEPTH(20000)
AMQ8006: WebSphere MQ queue created.
2. To delete a queue:
DELETE QLOCAL(Q2)
4 : DELETE QLOCAL(Q2)
AMQ8007: WebSphere MQ queue deleted.
3. To clear all the messages from the queue:
CLEAR QLOCAL(Q3)
7 : CLEAR QLOCAL(Q3)
AMQ8022: WebSphere MQ queue cleared.
4. To check the status of the queue:
DIS QSTATUS(Q3)
9 : DIS QSTATUS(Q3)
AMQ8450: Display queue status details.

Prepared By RAM.
QUEUE(Q3) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(1)
LGETDATE( ) LGETTIME( )
LPUTDATE( ) LPUTTIME( )
MEDIALOG( ) MONQ(OFF)
MSGAGE( ) OPPROCS(0)
QTIME( , ) UNCOM(NO)
IPPROCS(1): This indicated the number of application programs opened the queue for
getting the messages.
OPPROCS(0): The number of applications opened the queue for putting the messages.
CURDEPTH(4): This indicates the number of messages currently sitting in the queue.
UNCOM(NO): This indicated any uncommitted activity against the queue.
5. Defining the process:
DEFINE PROCESS ('Q1.PROCESS') +
DESCR('Process for ABCDEF CLIENT ') +
APPLTYPE(WINDOWS) +
APPLICID('C:prog.txt ') +
USERDATA(' ') +
ENVRDATA(' ') +
REPLACE
6. Alter the process:

Prepared By RAM.
ALTER PROCESS(Q1.PROCESS) APPLICID('C:prog2.txt ')
7. Delete the process
DELETE PROCESS(Q1.PROCESS)
8. DEFINE/ALTER/DELETE QLIAS, REMOTE QUEUE DEFINITIONS, MODEL QUEUES.
9. Checking the queue manager status?
DIS QMSTATUS ALL
2 : DIS QMSTATUS ALL
AMQ8705: Display Queue Manager Status Details.
QMNAME(B3) STATUS(RUNNING)
CONNS(7) CMDSERV(RUNNING)
CHINIT(RUNNING) STANDBY(NOPERMIT)
10. To get all the active connections against the queue managers?
dis CONN(*) ALL
CONN(E19FB94D20003201)
EXTCONN(414D5143423320202020202020202020)
TYPE(CONN)
PID(7092) TID(9)
APPLDESC( )

Prepared By RAM.
APPLTAG(re MQjavajrebinjavaw.exe)
CONNOPTS(MQCNO_HANDLE_SHARE_BLOCK,MQCNO_ISOLATED_BINDING)
USERID(kumar) UOWLOG( )
UOWSTDA( ) UOWSTTI( )
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
CONN(E19FB94D2000A601)
EXTCONN(414D5143423320202020202020202020)
TYPE(CONN)
PID(7620) TID(1)
APPLDESC( )
APPLTAG(WebSphere MQbinamqsput.exe)
CONNOPTS(MQCNO_SHARED_BINDING) USERID(kumar)
UOWLOG( ) UOWSTDA( )
UOWSTTI( ) UOWLOGDA( )
UOWLOGTI( ) URTYPE(QMGR)

Prepared By RAM.
11. To display the queue manager information?
3 : DISPLAY QMGR ALL
AMQ8408: Display Queue Manager details.
QMNAME(B3) ACCTCONO(DISABLED)
ACCTINT(1800) ACCTMQI(OFF)
ACCTQ(OFF) ACTIVREC(MSG)
ALTDATE(2011-04-29) ALTTIME(00.03.26)
AUTHOREV(DISABLED) CCSID(437)
CHAD(DISABLED) CHADEV(DISABLED)
CHADEXIT( ) CHLEV(DISABLED)
CLWLDATA( ) CLWLEXIT( )
CLWLLEN(100) CLWLMRUC(999999999)
CLWLUSEQ(LOCAL) CMDEV(DISABLED)
CMDLEVEL(701) COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE)
CONFIGEV(DISABLED) CRDATE(2011-04-26)
CRTIME(22.00.17) DEADQ(B3.DEADQ)
DEFXMITQ( ) DESCR( )
DISTL(YES) INHIBTEV(DISABLED)
IPADDRV(IPV4) LOCALEV(DISABLED)
LOGGEREV(DISABLED) MARKINT(5000)
MAXHANDS(256) MAXMSGL(4194304)

Prepared By RAM.
MAXPROPL(NOLIMIT) MAXPRTY(9)
MAXUMSGS(10000) MONACLS(QMGR)
MONCHL(OFF) MONQ(OFF)
PARENT( ) PERFMEV(DISABLED)
PLATFORM(WINDOWSNT) PSRTYCNT(5)
PSNPMSG(DISCARD) PSNPRES(NORMAL)
PSSYNCPT(IFPER) QMID(B3_2011-04-26_22.00.17)
PSMODE(ENABLED) REMOTEEV(DISABLED)
REPOS( ) REPOSNL( )
ROUTEREC(MSG) SCHINIT(QMGR)
SCMDSERV(QMGR) SSLCRLNL( )
SSLCRYP( ) SSLEV(DISABLED)
SSLFIPS(NO)
SSLKEYR(C:Program FilesIBMWebSphere MQqmgrsB3sslkey)
SSLRKEYC(0) STATACLS(QMGR)
STATCHL(OFF) STATINT(1800)
STATMQI(OFF) STATQ(OFF)
STRSTPEV(ENABLED) SYNCPT
TREELIFE(1800) TRIGINT(999999999)
12. Alter the queue manager.
ALTER QMGR DEADQ(B3.DEADQ)
2 : ALTER QMGR DEADQ(B3.DEADQ)

Prepared By RAM.
AMQ8005: WebSphere MQ queue manager changed.
13. Define/alter/diplay/delete an MQ service?
14. To check the listener information?
9 : display listener(LISTENER.TCP) all
AMQ8630: Display listener information details.
LISTENER(LISTENER.TCP) CONTROL(QMGR)
TRPTYPE(TCP) PORT(3003)
IPADDR( ) BACKLOG(0)
DESCR( ) ALTDATE(2011-04-26)
ALTTIME(22.00.49)
15. To check the status of the listener?
display lsstatus(LISTENER.TCP) all
10 : display lsstatus(LISTENER.TCP) all
AMQ8631: Display listener status details.
LISTENER(LISTENER.TCP) STATUS(RUNNING)
PID(3580) STARTDA(2011-04-28)
STARTTI(22.42.06) DESCR( )
TRPTYPE(TCP) CONTROL(QMGR)
IPADDR(*) PORT(3003)
BACKLOG(100)

Prepared By RAM.
16. To alter the listener?
Alter listener(LISTENER.TCP) TRPTYPE(TCP) PORT(4003)
14 : alter listener(LISTENER.TCP) TRPTYPE(TCP) PORT(4003)
AMQ8623: WebSphere MQ listener changed.
17. Stopping the listener?
STOP LISTENER(LISTENER.TCP)
16 : STOP LISTENER(LISTENER.TCP)
AMQ8706: Request to stop WebSphere MQ Listener accepted.
18. Delete the listener?
DELETE LISTENER(LISTENER.TCP)
17 : DELETE LISTENER(LISTENER.TCP)
AMQ8628: WebSphere MQ listener object deleted.
19. Define all the objects from runmqsc for triggering and intercommunication?
MS03: SAVEQMGR
This supportpac is used to take the backup of the MQ system configuration.
#saveqmgr -m QMGR_NAME -f file1
file1 contains the queue manager configuration data, we can make use of this data to create the
same objects on a different queue manager of on the same queue manager manager, if the queue
manager file system is corrupted.
#runmqsc QMGR_NAME C:filein.txt C:fileout.txt

Prepared By RAM.
QLOAD
Copy the Mo03 service pack from IBM site:
Service PacK: Mo03(Mo03: WebSphere MQ Queue Load / Unload Utility)
Download: google: mq mo03
1. Copy messages from queue to file
qload –m QM1 –i Q1 –f c:myfile
DIRECTORY STRUCTER
Windows:
Product path and run time path: C:Program FilesIBMWebSphere MQ
Sample Programs: C:Program FilesIBMWebSphere MQtools
Queue Manager data path:C:Program FilesIBMWebSphere MQQmgrsQMGR_NAME
System level errors: C:Program FilesIBMWebSphere MQerrors

Prepared By RAM.
Queue Manager level errors: C:Program FilesIBMWebSphere MQQmgrsQMGR-NAMe
errors
Queue storage location: C:Program FilesIBMWebSphere
MQqmgrsQMGR_NAMEqueuesQUEUE_NAME
Channel location: C:Program FilesIBMWebSphere
MQqmgrsQMGR_NAMEchannelCHANNEL_NAME
Log path: C:Program FilesIBMWebSphere MQlogQMGR_NAME/active
UNIX:
This is the product path: /opt/mqm
Sample Programs: /opt/mqm/tools, /opt/mqm/bin
Run time path: /var/mqm
Queue Manage data path: /var/mqm

Prepared By RAM.
System level errors: /var/mqm/errors
Queue Manager level errors: /var/mqm/qmgrs/QMGR_NAME/errors
Queue storage location: /var/mqm/qmgrs/QMGR_NAME/QUEUE_NAME
Channel location: /var/mqm/qmgrs/QMGR_NAME/CHANNEL_NAME
Log path: /var/mqm/log/QMGR_NAME/active/log-name(S000001*)
/(Root)
/var /etc /home /opt /
2. Copy messages from file to queue
qload –m QM1 –o Q1 –f c:myfile
3. Copy messages from queue to queue
qload –m QM1 –i Q1 –o Q2
Errors:
2 types of errors:
/var/mqm/errors

Prepared By RAM.
#amqldbgn -i PID
#strmqtrc -i PID
#endmqtrc -i PID
/var/mqm/trace

Websphere MQ admin guide

Recommended

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to Websphere MQ admin guide (20)

Recently uploaded (20)

Websphere MQ admin guide