Você está na página 1de 11

Middleware News

FRIDAY, MARCH 13, 2009


Websphere MQ Commands / ibm websphere mq
commands
Websphere MQ Commands / ibm websphere mq commands
=================================================
MQ commands
Command name Purpose
amqccert Check certificate chains
amqoamd Output setmqaut commands
amqmdain Configure or control WebSphere MQ services (Windows systems only)
amqtcert Transfer certificates
crtmqcvx Convert data
crtmqm Create a local queue manager
dltmqm Delete a queue manager
dmpmqaut Dump authorizations to an object
dmpmqlog Dump a log [url]
dspmq Display queue managers
dspmqaut Display authorizations to an object
dspmqcsv Display the status of a command server
dspmqfls Display file names
dspmqrte Display route application
dspmqtrc Display formatted trace output (UNIX systems only)
dspmqtrn Display details of transactions [pareja de rsvmqtrn]
dspmqver Display version number
endmqcsv Stop the command server on a queue manager
endmqdnm Stop .NET monitor
endmqlsr Stop the listener process on a queue manager
endmqm Stop a local queue manager
endmqtrc Stop tracing for an entity
mqftapp Run the File Transfer Application
mqftrcv Receive file using the File Transfer Application (server)
mqftrcvc Receive file using the File Transfer Application (client)
mqftsnd Send file using the File Transfer Application (server)
mqftsndc Send file using the File Transfer Application (client)
rcdmqimg Write an image of an object to the log
rcrmqobj Recreate an object from their image in the log
rsvmqtrn Commit or back out a transaction [pareja de dspmqtrn]
runmqchi Start a channel initiator process
runmqchl Start a sender or requester channel
runmqdlq Start the dead-letter queue handler
runmqdnm Run .NET monitor
runmqlsr Start a listener process
runmqsc Issue MQSC commands to a queue manager
runmqtmc Invoke a trigger monitor for a client (AIX clients only)
runmqtrm Invoke a trigger monitor for a server
setmqaut Change authorizations to an object
setmqcrl Set certificate revocation list (CRL) LDAP server definitions (Windows systems only)
setmqprd Enroll production license
setmqscp Set service connection points (Windows systems only)
strmqcsv Start the command server for a queue manager
strmqm Start a local queue manager
strmqtrc Enable tracing


FRIDAY, MARCH 13, 2009
Websphere MQ Clustering
Clustering Up
Main purpose : workload balancing.
SC34-6061 : Queue Manager Clusters. [MQ-Clustering.pdf]
SC34-6061 : Queue Manager Clusters. Online url (v 5.3)
SC34-6589 : Queue Manager Clusters. url (v 6.0) [T42:\mq\books\]
Distributed queing is when you group queue managers in a cluster : the queue managers can make the
queues that they host available to every other queue manager in the cluster. Any queue manager can
send a message to any other queue manager in the same cluster without explicit channel definitions,
remote-queue definitions, or transmission queues for each destination. Every queue manager in a cluster
has a single transmission queue from which it can transmit messages to any other queue manager in the
cluster.
Each queue manager in a cluster needs to define only:
one cluster-receiver channel on which to receive messages
one cluster-sender channel with which it introduces itself and learns about the cluster
which own queues it wants to make available to the cluster
As with distributed queuing, an application uses the MQPUT() call to put a message on a cluster queue at
any queue manager. An application uses the MQGET() call to retrieve messages from a cluster queue on
the local queue manager.
You can only GET from a local cluster queue, but you can PUT to any queue in a cluster. If you open a
queue to use the MQGET command, the queue manager will only use the local queue.
Each queue manager has a definition for the receiving end of a channel called TO.qmgr on which it can
receive messages. This is a cluster-receiver channel. A cluster-receiver channel is similar to a receiver
channel used in distributed queuing, but in addition to carrying messages this channel can also carry
information about the cluster.
Each queue manager also has a definition for the sending end of a channel, which connects to the
cluster-receiver channel of one of the Full Repository (FR) queue managers. This is a cluster-sender
channel. A cluster-sender channel is similar to a sender channel used in distributed queuing, but in
addition to carrying messages this channel can also carry information about the cluster.
Once both the cluster-receiver end and the cluster-sender end of a channel have been defined, the
channel starts automatically.
In any cluster you need to nominate two queue managers to hold full repositories.
The clusters use the publish/subscribe model for internal messaging (and will Subscribe to only 2 FR)
Queue Manager Repository is kept in SYSTEM.CLUSTER.REPOSITORY.QUEUE queue
Cluster information is carried to repositories (whether full or partial) on a local queue called
SYSTEM.CLUSTER.COMMAND.QUEUE.
Few Q&A ;
how many FR ? 2
DISCINT=0 ? no
2 qmgrs just to be FR ? yes, on a separate server
Good intro : Getting started with queue manager clusters.
Interesting summary :
#1 Regardless of how many FRs you have, each FR should have a manual CLUSSNDR defined to every
other FR.
#2 If every FR has a CLUSSNDR to every other FR, each FR will know about every cluster attribute on
every QM in the cluster.
#3 A PR will only ever publish info to 2 FRs. A PR will only ever subscribe to 2 FRs. Period. It doesn't
matter how many manual CLUSSNDRs you define on that PR. A PR will only ever send its info (publish)
to 2 FRs and will only get updates (subscribe) from 2 FRs.
#4 You should only define one CLUSSNDR to one FR from a PR.
#5 If 2 FRs go down in your cluster, your cluster will be able to send messages just fine. But any changes
to cluster definitions become a problem. Any PRs that used both of these down FRs will still function for
messaging, but they will not be made aware of any changes in the cluster because both of it's FRs are
N/A.
#6 If two of your FRs are down, and you still have other FRs, you could go to your PRs and delete the
CLUSSNDR to the down FR, define a CLUSSNDR to an available FR and issue REFRESH CLUSTER(*)
REPOS(YES). This would cause your PR to register with an available FR and thus pick up cluster
changes.
#7 In a properly designed system the liklihood of 2 FRs being down is next to zero, so the need for more
than 2 FRs is next to zero. And even if both FRs are down it doesn't mean your cluster will come to a
screeching halt.
Just use 2 FRs.
Problem : stuck message(s) @ Xmit Q(s)!


FRIDAY, MARCH 13, 2009
What is IBM Websphere MQ?
IBM WebSphere MQ is a family of network communication software products launched by IBM in March
1992. It was previously known as MQSeries, a trademark that IBM rebranded in 2002 to join the suite of
WebSphere products. WebSphere MQ is IBM's Message Oriented Middleware offering. It allows
independent and potentially non-concurrent applications on a distributed system to communicate with
each other. MQ is available on a large number of platforms (both IBM and non-IBM), including z/OS
(mainframe), OS/400 (IBM System i or AS/400), Transaction Processing Facility, UNIX (AIX, HP-UX,
Solaris), HP NonStop, OpenVMS, Linux, and Microsoft Windows.

Message-oriented middleware
Main article: Message-oriented middleware

A member of the WebSphere family from IBM, WebSphere MQ (formerly MQSeries) is the most
popular[1] system for messaging across multiple platforms, including Windows, Linux, IBM mainframe
and midrange, and Unix. WebSphere MQ is often referred to as "MQ" or "MQSeries".

There are two parts to message queuing:

* Messages are collections of binary or character (for instance ASCII or EBCDIC) data that have some
meaning to a participating program. As in other communications protocols, storage, routing, and delivery
information is added to the message before transmission and stripped from the message prior to delivery
to the receiving application.
* Message queues are objects that store messages in an application.

A queue Manager, although not strictly required for message-oriented middleware, is a Websphere MQ
prerequisite and system service that provides a logical container for the message queue and is
responsible for transferring data to other queue managers via message channels.

There are several advantages to this technology:

* Messages do not depend on pure packet-based transmissions, such as TCP/IP. This allows the sending
and receiving ends to be decoupled and potentially operate asynchronously.
* Messages will be delivered once and once only, irrespective of errors and network problems.

[edit] APIs

There are many ways to access WebSphere MQ's facilities. Some of the APIs supported by IBM are:

* IBM Message Queue Interface for C, COBOL, PL/I, and Java
* JMS for Java
* Perl interface (developed and contributed by Morgan Stanley), available from CPAN.[2]
* Windows PowerShell[3]
* XMS for C/C++ and .NET[4]

There are many other APIs (unsupported by IBM).

[edit] Awards

In 2004, WebSphere MQ won the British Royal Academy of Engineering's MacRobert Award for
technological and engineering innovation.[5]

[edit] Features

WebSphere MQ provides assured one-time delivery of messages across a wide variety of platforms. The
product emphasizes reliability and robustness of message traffic, and ensures that a message should
never be lost if MQ is appropriately configured.

It needs to be remembered that a message in the context of MQ has no implication other than a gathering
of data. MQ is very generalized and can be used as a robust substitute for many forms of
intercommunication. For example, it can be used to implement reliable delivery of large files as a
substitute for FTP.

MQ provides application designers a mechanism to achieve non-time-dependent architecture. Messages
can be sent from one application to another, regardless of whether the applications are running at the
same time. If a message receiver application is not running when a sender sends it a message, the
queue manager will hold the message until the receiver asks for it. Ordering of all messages is preserved,
by default this is in FIFO order of receipt at the local queue within priority of the message.

It provides a means for transforming data between different architectures and protocols, such as Big
Endian to Little Endian, or EBCDIC to ASCII. This is accomplished through the use of message data
"exits". Exits are compiled applications which run on the queue manager host, and are executed by the
WebSphere MQ software at the time data transformation is needed.

WebSphere MQ allows receipt of messages to "trigger" other applications to run, and thus provides the
framework for a message driven architecture.

It implements the JMS standard API, and also has its own proprietary API, known as the Message
Queuing Interface.

Unlike email, MQ itself is responsible for determining the destination of messages by the definition of
queues, so processing of sent messages can be moved to a different application at a different
destination. MQ provides a robust routing architecture, allowing messages to be routed via alternative
paths around a network of MQ managers. MQ can be implemented as a cluster, where multiple MQ
implementations share the processing of messages to allow higher performance and load balancing.


FRIDAY, MARCH 13, 2009
What is DeadLetter Queue?
DLQ Up
If a message arrives at a queue manager but there is no queue there to receive it, the message is put on
the dead-letter queue as usual. If there is no dead-letter queue, the channel fails and retries, as
described in the MQ Intercommunication book.
"Clustering", v 5.3, SC34-6061-02, page 8.
Again : For example, if an application tries to put a message on a queue on another queue manager, but
gives the wrong queue name, the channel is stopped and the message remains on the transmission
queue. Other applications cannot then use this channel for their messages.
System Administration Guide, v 5.3, SC34-6068-02, page 26.
Again : If you do not, and the MCA is unable to put a message, it is left on the transmission queue and
the channel is stopped.
Intercommunication, v 5.3, SC34-6059-02, page 13.
Again : If all the retries are unsuccessful, the message is written to the dead-letter queue. If there is no
dead-letter queue available, the channel stops.
MQ v6 Intercommunication, SC34-6587, page 429 [451/573].
You can create it by using the DEADQ attribute on the ALTER QMGR command to specify one later.
DLQ monitor : MS71 !

How to WRITE into it
Define a cluster of 3 queue managers : TQM1, TQM2 and TQM3.
TQM1 and TQM2 share the queue WLMQ1 on the cluster. This is, TQM3 sees two "cluster" queues.
On TQM3, define an ALIAS for WLMQ1, named WLMAQ.
If an application writes - connecting to TQM3 - into WLMAQ, then the messages are split between
WLMQ1 on both TQM1 and TQM2.
Now, define a queue manager external to the cluster, named TQM4.
Define a REMOTE QUEUE on it, called RMQ99, pointing to WLMAQ on TQM3. And a CHANNEL also ...
and activate it !
If an application sends a message connecting to TQM4 and using this Remote Queue RMQ99, it is
placed in the TQM3's Dead Letter Queue (named TQM3DLQ) with Reason Code
d'2082 = MQRC_UNKNOWN_ALIAS_BASE_Q - see.
See "Dead-Letter Header" !
How to WRITE into it (2) :
put a message into a XMIT queue, and get RC = d'0271 = MQFB_XMIT_Q_MSG_ERROR Feedback
indicating that a message channel agent has found that a message on the transmission queue is not in
the correct format. The message channel agent puts the message on the dead-letter queue using this
feedback code.
Requires "Running" channel !

How to READ from it
DLQ handler {easy !}
RFHutil
RFHUtil + Read Queue + "DLQ" + uncheck "Include DLQH" on last Tab + Write Queue +
"Q1" + and msg is on Q1, without DLQH
MA0T ?
If you want to move one single message: MQMON (SupportPac MO71)


FRIDAY, MARCH 13, 2009
What is Channel?
Channel types
A channel is a communication link used by distributed queue managers. There are two categories of
channel in MQ:
Message channels, which are unidirectional, and transfer messages from one queue manager to
another.
MQI channels, which are bidirectional, and transfer MQI calls from a MQ client to a queue
manager, and responses from a queue manager to a MQ client.
There are two types of MQI channel : server-connection and client-connection.
MQ 6.0, "Application Programming Guide", SC34-6595-01, page 45 [65/601]
The definition of each end of a message channel can be one of the following types:
Sender
Receiver
Server
Requester
Cluster sender
Cluster receiver
Do not confuse message channels with MQI channels. There are two types of MQI channel : server-
connection and client-connection.
A message channel is defined using one of these types defined at one end, and a compatible type at the
other end. Possible combinations are:
Sender - Receiver
Requester - Server
Requester - Sender (callback)
Server - Receiver (server is used as a sender)
Client-connection with Server-connection
Cluster sender-cluster receiver
http://middlewarenews.blogspot.com/2009/03/what-is-channel.html

WEDNESDAY, DECEMBER 29, 2010
MQRC and MQCC Understanding MQ reason codes and
completion codes 2110, 2092,2080,2030 - Middleware News
2110 0x0000083e MQRC_FORMAT_ERROR

Problem(Abstract)

You attempt to get a message from your queue. The getting application fails with a data conversion
format error.
Symptom

2110 0x0000083e MQRC_FORMAT_ERROR
Cause

The most common reason for 2110 is an incorrect message format in the message descriptor.
Resolving the problem

Specify the correct MQMD Format for your message. The format 'MQSTR ' is what most applications use
to convert string data (non numeric data).





2092 MQRC XMIT Q USAGE ERROR


Problem(Abstract)
You put a message to your queue remote and you expect that it will go to the transmission queue and
flow across your sender channel. The putting application fails with the following symptom.


Symptom
2092 0x0000082c MQRC_XMIT_Q_USAGE_ERROR

Cause
2092 is returned because the transmission queue definition did not specify the xmitq parameter.

Resolving the problem
Alter the transmission queue and specify usage(xmitq) parameter.

Example:
alter ql(my_queue) usage(xmitq)

Additional information
USAGE
This parameter is supported only on local and model queues.

NORMAL
The queue is not a transmission queue

XMITQ
The queue is a transmission queue, which is used to hold messages that are destined for a remote queue
manager. When an application puts a message to a remote queue, the message is stored on the
appropriate transmission queue while awaiting transmission to the remote queue manager.






2080 MQRC TRUNCATED MSG FAILED

Problem(Abstract)
Your first MQGET fails with MQRC_TRUNCATED_MSG_FAILED. This happens because your message
buffer is too small. You increased the buffer, and did another MQGET. When you process the message,
you find the data is not converted.

Symptom
2080 0x00000820 MQRC_TRUNCATED_MSG_FAILED

Cause
This is working as designed. See the additional information listed below.

Resolving the problem

* Make your message buffer of sufficient size, to handle your largest message.
* Your application must handle MQRC_TRUNCATED_MSG_FAILED. Make sure that your program
resets the MQMD FORMAT, ENCODING, and CCSID to the original value, else the message will not be
converted by WebSphere MQ.





2030 MQRC MSG TOO BIG FOR Q


Problem(Abstract)
MQPUT fails and you receive the following:

2030 X07EE MQRC_MSG_TOO_BIG_FOR_Q

Cause
The message length exceeds the maxmsgl specified in the WebSphere MQ queue manager, queue and
channel definitions.

Resolving the problem
The queue manager, queue and channel must have maxmsgl set to be large enough to hold your
messages.

1. Alter the queue manager maxmsgl.
2. Alter the queue maxmsgl.
3. Alter the channel maxmsgl.
4. Restart the queue manager.


Maxmsgl can be changed in runmqsc using the following commands:

C:\>runmqsc FRED
5724-B41 (C) Copyright IBM Corp. 1994, 2002. ALL RIGHTS RESERVED.
Starting MQSC for queue manager FRED.

alter qmgr maxmsgl(10000000)
1 : alter qmgr maxmsgl(10000000)
AMQ8005: WebSphere MQ queue manager changed.

alter ql(client.queue.local) maxmsgl(10000000)
2 : alter ql(client.queue.local) maxmsgl(10000000)
AMQ8008: WebSphere MQ queue changed.

alter chl(client.sdr) maxmsgl(10000000)
3 : alter chl(client.sdr) chltype(sdr) maxmsgl(10000000)
AMQ8016: WebSphere MQ channel changed.


Maxmsgl (Maximum Message Length) can also be changed using the MQSeries Explorer panels:


1. Alteration of the queue manager maxmsgl (Maximum Message Length) property:


2. Alteration of the queue maxmsgl (Maximum message Length) property:


3. Alteration of the channel maxmsgl (Maximum message Length) property:
Posted by Karthick at 5:13 PM 0 comments
Labels: IBM Websphere MQ, Middleware news
SATURDAY, DECEMBER 4, 2010
Channel SSL Error - Middleware News
Channel SSL Error


Channel SSL Error

Você também pode gostar