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.


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.


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 Files\IBM\WebSphere MQ\tools (/opt/mqm/tools on UNIX machines)..

Note: The queue data will physically be stored in C:\Program Files\IBM\WebSphere MQ\Qmgrs\PROD\queues\Q1 (/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 Files\IBM\WebSphere MQ\bin (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 Files\IBM\WebSphere MQ\log (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 Files\IBM\WebSphere MQ\qmgrs/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 Files\IBM\WebSphere MQ\errors: This contains errors related to the system level. /var/mqm/errors

C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM2\errors: 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 Files\IBM\WebSphere MQ\log

/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 Files\IBM\WebSphere MQ\qmgrs/QMGR_NAME

/var/mqm/qmgrs/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 Files\IBM\WebSphere MQ\errors

/var/mqm/errors

2. Queue manager level errors:

Prepared By RAM.


C:\Program Files\IBM\WebSphere MQ\Qmgrs\FID\errors


In the C:\Program Files\IBM\WebSphere MQ\errors , /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 Files\IBM\WebSphere MQ\trace

/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 Settings\kumar>dspmqaut -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 Settings\kumar>dspmqaut -m TEST -t queue -n TEST.QLOCAL -p Guest

Entity Guest has the following authorizations for object TEST.QLOCAL:

C:\Documents and Settings\kumar>setmqaut -m TEST -t queue -n TEST.QLOCAL -p Guest +get +browse

The setmqaut command completed successfully.



get

Prepared By RAM.


browse

C:\Documents and Settings\kumar>setmqaut -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 Settings\kumar>setmqaut -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 Settings\kumar>dmpmqaut -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 Settings\kumar>dspmqaut -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 Settings\kumar>dspmqaut -m TEST -t qmgr -p guest

Entity guest has the following authorizations for object TEST:

Prepared By RAM.


C:\Documents and Settings\kumar>setmqaut -m TEST -t qmgr -p guest +connect


C:\Documents and Settings\kumar>dspmqaut -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 MQ\bin\amqzfuma.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 MQ\bin\amqsput.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 Settings\kumar>dspmq

QMNAME(B3) STATUS(Running)

QMNAME(C1) STATUS(Ended normally)

QMNAME(C2) STATUS(Ended normally)

7. Check for the MQ return codes.

C:\Documents and Settings\kumar>mqrc 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 Settings\kumar>amqsbcg 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 MQ\java\jre\bin\javaw.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 Settings\kumar>runmqsc 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 MQ\java\jre\bin\javaw.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 MQ\bin\amqsput.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 Files\IBM\WebSphere MQ\qmgrs\B3\ssl\key)

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 Files\IBM\WebSphere MQ

Sample Programs: C:\Program Files\IBM\WebSphere MQ\tools

Queue Manager data path:C:\Program Files\IBM\WebSphere MQ\Qmgrs\QMGR_NAME

System level errors: C:\Program Files\IBM\WebSphere MQ\errors

Prepared By RAM.


Queue Manager level errors: C:\Program Files\IBM\WebSphere MQ\Qmgrs\QMGR-NAMe\errors

Queue storage location: C:\Program Files\IBM\WebSphere MQ\qmgrs\QMGR_NAME\queues\QUEUE_NAME

Channel location: C:\Program Files\IBM\WebSphere MQ\qmgrs\QMGR_NAME\channel\CHANNEL_NAME

Log path: C:\Program Files\IBM\WebSphere MQ\log\QMGR_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

Date post:	14-Jun-2015
Category:	Education
Upload:	ram-babu
View:	2,016 times
Download:	18 times

Websphere MQ admin guide

Education