Qmanagerà10000 Msgs Maxmsglengthà4 Mb
Queueà5000 Msgs Maxmsglengthà4 Mb
* Datagram: A Message sent with no response expected.
* Request: A Message sent for which a response is expected.
* Reply Response Message for a requested message.
* Report: A Message that describes the occurrence or event
* Ex COA/COD
Persistent messages are usually logged. Logging messages reduces the performance of your application, so use persistent messages for essential data only. If the data in a message can be discarded if the queue manager stops or fails, use a nonpersistent message.
WebSphere MQ messages:
Messages are made up of two parts: Message descriptor, Application data
In Web Sphere MQ, messages can be either persistent or nonpersistent. Persistent messages are logged and can be recovered in the event of a WebSphere MQ failure. Thus, persistent messages are guaranteed to be delivered once and only once. Nonpersistent messages are not logged. Web Sphere still guarantees to deliver them not more than once, but it does not promise to deliver them once.
The default maximum message length is 4 MB, although you can increase this to a maximum length of 100 MB (where 1 MB equals 1 048 576 bytes).
A message is a string of bytes that is meaningful to the applications that use it. Messages are used to transfer information from one application program to another (or between different parts of the same application). The applications can be running on the same platform, or on different platforms.
WebSphere MQ messages have two parts:
1. The application data. The content and structure of the application data are defined by the application programs that use it.
2. A message descriptor. The message descriptor identifies the message and contains additional control information, such as the type of message and the priority assigned to the message by the sending application. WebSphere MQ defines the format of the message descriptor. For a complete description of the message descriptor.
MQ v 5.3 supports Windows 2000, Windows 2000XP,Windows 2000NT,
Windows 2003 SE, Windows 2003EE.
Disk Storage: Typical storage requirements are as follows:
* Server installation: 50 MB
* Client installation: 15 MB
* Data storage (server): 50 MB
* Data storage (client): 5 MB.
Connectivity The network protocols supported by WebSphere MQ for AIX, V5.3 are:
* SNA LU 6.2.
* LU 6.2
* Databases: DB2 7.1, 7.2
* Oracle 8i and 9i
* Sybase v12 or v 12.5
Java: If you want to use the Java Messaging Support, you need the Java Runtime Environment Version 1.3 or later
With message queuing, the exchange of messages between the sending and receiving programs is independent of time. This means that the sending and receiving application programs are decoupled; the sender can continue processing without having to wait for the receiver to acknowledge receipt of the message. The target application does not even have to be running when the message is sent. It can retrieve the message after it is has been started.
Because the MQ is independent of the Operating System you use i.e. it may be Windows, Solaris, AIX.It is independent of the protocol (i.e. TCP/IP, LU6.2, SNA, NetBIOS, UDP). It is not required that both the sender and receiver should be running on the same platform.
3. Assured Delivery
When messages arrive on a queue, they can automatically start an application using triggering. If necessary, the applications can be stopped when the message (or messages) have been processed.
MQ stands for MESSAGE QUEUEING. WebSphere MQ allows application programs to use message queuing to participate in message-driven processing. Application programs can communicate across different platforms by using the appropriate message queuing software products.
It can hold messages in multiple formats
Maintaining the objects like channels and Queues is their responsibility
It is possible to define the queues in the JEE container simply with the help of this series
Telemetry allows the remote sensors to be connected with a node. When it comes to optimizing the sensor networks, its telemetry provides an optimization technique. In satellite networks, it can help to save a lot of costs simply.
The same is present in a folder which is named Windows Registry and is present in the Window’s Program Files. Yes, it is possible to change its location and users can store the backup data anywhere they want.
Well, they are Assured Delivery, Integration, Scalability, and Asynchrony
Although in few cases it consumes time depending on the exact message in the queue, the delivery is always assured. Users can check the status of all the messages simply anytime they want.
It is necessary that they are used in capital letters otherwise there will be no response.
Control commands are used when it comes to managing the services, as well as different processes related to messaging. Most of the time, these commands are deployed for the channel listener, triggering or for the integration of the same. On the other side, the MQS commands are useful when it comes to functions that are related to the tasks performed by an administrator. It is also possible to create Queue Managers and channels through these commands.
Ina network, there can be a very large number of nodes. Practically it is not possible to establish a direct physical connection between them all. Of course, this can enhance the cost up to a great extent and can make the network very complex. Thus, the concept of switching is considered. It basically acts as a temporary path that is established between a sender and a receiver for message transfer. The connection is terminated after the message is sent. Because not all the nodes need channels all the time, this concept can be applied. It is having a lot of advantages. All the data that seems to be sent on priority can be assigned sent immediately by stopping other operations.
These are Channels, Processes, Queue Manager, Name Lists, and Processes.
All these objects can have a similar nature or a different one depending on the operation they are engaged in.
Many times there is a need to issue MQI calls to a queue manager. IT is not always necessary that it runs on the same system. MQ client is responsible for issuing the same for an application. The output can be modified up to some extent. On the other side, the MQ server is basically a manager for the queue which is responsible for offering the queuing service to the clients. All the objects which are classified in the MQ appear only on the server and not on the client’s machine.
Well, the fact is sometimes there are so many messages on a network. The channel has its own limit of processing the data and when the same exceeds, the situation is considered as congestion. It is similar to a traffic jam on a road. The clearance needs time and so do the messages get a bit delayed for delivery.
The default number is 1414 and the same cannot be changed.
They are known as packets and packets in most of the cases are having the same size. Because they all belong to the same message, the information format is similar. They can choose any path that exists between the sender and the receiver and this is exactly what can sometimes result in packet loss. Although its priority is very low, in case it happens, the receiver can send the acknowledgment to the sender that it has not received a specific packet. The sender then has to resend the same to it.
All MQ channels should be within the 20 characters maximum and all other objects can have up to 48 characters. They need to be created into parts if this limit exceeds due to any reason.
A massage doesn’t just contain information that needs to be transferred but it contains other information too. For example, the type of message and what exactly its priority is. The same is described in the message descriptor which is defined by WebSphere MQ. It contains all other relevant information about the message and among all of the same, its priority that largely matters.
It is necessary to define the structure of an application data that needs to be used in a message. Applications programs make sure of this and this practice is followed in all the messages. This data is generally considered as application data.
In WebSphere MQ two types of messages exist. They are basically classified based on priority. The messages which are urgent and should be recovered in all the circumstances are called persistent messages. Others are non-persistent messages. This clearly indicates that persistent messages are always delivered to the destination. Users can define any message as persistent. It should be kept in mind that there is a limit on the number of attempts that the sender makes for the delivery in case anything goes wrong.
Yes, all the requirements are the same except for a few basic ones. For older versions of Windows such as 2000 and XP, it needs some customized settings in the application. It is actually free from the network protocols and thus users have no reasons to worry about this.
The installation of IBM Websphere MQ needs to have some basic storage requirements which are as under.
It needs 50 MB for data storage on the server. The server installation needs around 40 MB. While the data storage for the client and the installation of the file at the client end have 5 MB and 15 MB needs.
In the queue process, the process of sending or exchange of any message doesn’t depend on the time. This is exactly what makes both the sender, as well as the receiver be decoupled if the need for the same is there. There is actually no need for the sender to wait for getting the acknowledgment regarding the delivery of the message from the receiver. IT can continue with this next task. This process is basically considered as Asynchrony in IBM Websphere MQ.
Packets are the sub-parts of a message that needs to be sent from a sender to a receiver. Sometimes a situation arrives when a packet doesn’t reach its destination. Because all the packets have a well-defined address on them, the receiver can understand and acknowledge which message has been lost.
Well, the fact is IBM Websphere MQ is totally independent of the OS one is using. The same factor makes it totally independent of the TCP/IP protocol as well. There are many instances when the messages don’t get delivered or get delayed just because of a sender and a receiver having an OS mismatch. This is actually not at all a big deal with the IBM Websphere MQ and users need not worry about anything related to this.
This is “MaxMsgLength”
This MQ interview question is more to know that which version of MQ have you worked upon, do you are familiar with any issue with that particular version or many major changes to previous or next version, etc. Based upon your answer, you may expect some follow-up questions. By the way current version of WMQ is WebSphere MQ 7.5 but it is always good to check IBM's MQ website for the latest version.
A message is basically considered as a string of bytes that contains something useful for the machine or for the user. Generally, messages are deployed when it comes to sharing information among different nodes. It doesn’t matter whether the application runs on platforms that are different from each other.
Generally, the default length of a message is 4MB. However, it is not always necessary that all the messages should be of this size. In some special cases, it can be up to 100 MB. In case a message is too large in terms of size, the same can be divided into different parts and then these parts are sent in sequence order. This approach is generally regarded as message switching.
Rather simple and fact-based MQ Series interview question. This is asked to see whether candidate is familiar with MQ Series terminology or not. In WebSphere MQ, local queues are queue on same QueueManager while remote queue refers to queues on different QueueManager.
This MQ Interview question is not common or frequently asked, but good to know. If MQ clients sits on same physical server where QueueManager is located than it can create binding connection which is relatively faster than client connection, which is usually created by MQ clients residing on same network but not same host. Most of application uses MQ client connection to connect QueueMangaer, which is easy and flexible.
Yes, it can be possible.
This is a follow question of previous MQ interview question "What is dead letter queue in MQ Series". As we have seen that dead letter queue is used to store messages which is receives for non existent queue. On the other hand backout queue are application specific queue.If MQ client is not able to process message and ask for redelivery, message is redelivered to client with incremented delivery count. Once this deliveryCount crossed a configured threshold message is moved to back-out queue for later processing or error handling. In short if MQ Series not able to deliver message to client after a preconfigured attempt, WMQ moves message to backout queue.
A lot of messages arrive at the queue and especially when there is a lot of traffic. When such a thing happens, an automatic process that relates to the triggering starts. It is possible to stop the application with a simple instruction after it has done its work.
The one and the only prime requirement is the machine should be of 32-bit OS. Although it works on 64-bit OS, it needs some customized settings. The Aix should be installed on it and there will be no corrupt files related to programming.
Organizations and corporations can simply send bulk messages over complex networks. There are no strict protocols that need to be followed. Even if they are, the same can be managed very easily. Enterprises can make sure of quick information delivery to the destinations and can always have the things done in the best possible manner .
Another interesting and frequently asked WebSphere MQ Interview Question. You can easily answer this MQ question if you connected MQ via SSL. SSLPEER is a String usually DN (Distinguished Name) of MQ Client which connects to QueueManager securely using QueueManager. This is a mechanism WMQ uses to identify clients. In the case of Java or JMS clients, SSLPEER is DN of client certificate stored in its keyStore and sent to the server during SSL handshake.
CCDT file or Client Channel Definition table is a binary file that contains connection details required by MQ clients e.g. Java application using JMS to connect to MQ Server. In order to connect to MQ Server, MQ clients need MQ Server hostname, MQ Server port name, and server channel name. All these details are encapsulated in the CCDT file named AMQCLCHL.TAB. In order to create MQ Connection, MQ clients need the location of this file, which is provided as a configuration. most MQ errors come either with incorrect CCDT files.
Dead letter Queue in WebSphere MQ is a queue which is used by QueueManager to archive messages for a non existent queue. For example of QueueManager QMGR, receives a messages for queue ABC and if it didn't exist on that QueueMangaer then message will be routed to dead letter queue.
In WebSphere MQ or WMQ, Queue Manager use the channel to transmit messages to other QueueManager. Channel carries one way traffic in MQ Series (i.e. channels are uni directional). You can have either sending channel or receiving channel in MQ.
QueueManager is a primary component of WebSphere MQ or WMQ. QueueManager is responsible for storing and routing messages to other Queue Manager within MQ and it also communicate with outside world e.g. Java program or any other MQ client.