WebSphere MQ
MQ: Messaging and Queueing. It is used for the transport of data from one server to another and the data will be transferred in the form of messages and messages will be placed(stored) on queues one after the other, that is the reason it is called messaging and queuing.
Message: Everything(Any piece of business data) is called a message in middleware.
4 Types of messages:
- Request: A message for which a reply is expected.
- Reply: A reply to a request message.
- Datagram: A message for which no reply is expected.
- Report: Is an occurrance of an issue or an error.
- ·
MQ: Supporting OS
32+ platforms: AS/400, Z/OS, all UNIX flavors (LINUX, SOLARIS SPARC, SOLARIS INTEL, IBM AIX and HP_UX), Windows and ISERIES.
Mq supported Languages: COBOL, C, JAVA, ASSEMBLER, .NET, JMS
MQ has two types of softwares:
- 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
- ·
- MQ Client: If you install 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
- ·
Queue Manager: It is the overall govern for the entire WebSphere MQ system. It is also a WebSphere MQ object. This is logical object. There are separate queue managers for Production, TEST and USER region environment.
Queue: It is the named destination for messages. It is a WebSphere MQ object.
MQ Administration can done using:
- MQSC (MQ script commands).
- Control commands.
- MQ Explorer: It is a GUI tool built on top of the eclilipse platform and is available on Windows Intel and Linux(X86) machines only.
- PCF(Programmable Format Commands).
- ·
Message: Message is logical in MQ, message consists of two parts:
- 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.
- Message Data: This is the actual business data.
2.
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.
SQL: It is interface between an application program and the physical relational database (it can be DB2 or Oracle).
MQI (Message Queueing Interface): It is the interface between an MQ application program and MQ Queue Manager or Server. MQI provides a set calls thru that an 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.
Steps: To install Websphere MQ in windows
1. Copy the S/w: .zip
2. Extract the s/w.
3. Launch
4. Select Software requirements — > Ecilipse (3.3) — Install
5. Server installation —> Select Custom —
Select — MQ Server, File transfer, JMS, Development Kit and MQ explorer.
First Steps:
#strmqcfg — > Control commands to start the MQ explorer.
#dspmqver — > To display the MQ version and product information.
#dspmq — > The environment infomtation, the queue managers created and the status of the queue managers
#crtmqm QMGR_NAME —-> To create the queue manager.
#strmqm QMGR_NAME —-> To start the created queue manager.
#endmqm QMGR_NAME —-> To stop the running queue manager.
#dltmqm QMGR_NAME —-> To delete the queue manager.
Queue Manager: Queue manager is the overall governer for the entire WMQ system.
Creating a Queue Manager ( In Windows CLI)
C:\Documents and Settings\USER1>crtmqm TEST
WebSphere MQ queue manager created.
Directory ‘C:\Program Files\IBM\WebSphere MQ\qmgrs\TEST’ created.
Creating or replacing default objects for TEST.
Default objects statistics : 68 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.
C:\Program Files\IBM\WebSphere MQ\qmgrs\TEST: This is the path where the queue manager data will be stored.
C:\Program Files\IBM\WebSphere MQ\ —-> This is the default MQ path.
Note: The install path and the run time data path on Windows machines is the same.
Default objects statistics : 68 created. 0 replaced. 0 failed: 68 system default objects are created. This objects can be used be used as a model for creating new MQ user objects. All the system MQ objects startes wil SYSTEM.*.
C:\Documents and Settings\USER1>endmqm TEST
Quiesce request accepted. The queue manager will stop when all outstanding work is complete.
Quiesce State: In this state MQ will wait for the all the current running activity to be completed, then it will go for shutting dowm itself. In this state MQ cannot accept new MQ connections.
Message in MQ: Message is logical in MQ. Message consists of two parts:
- Message header: This is also called as the control information or the MQMD header. It contains the complete information about the message. For example, the date and time the message was put to the queue, the id of the user who put the message, the priorty of the message , the type of the message etc.,
- Message data: This is the actual business data.
2.
Queue: Queue is the named destination for MQ messages.
Types of queues: (Basic Important )
- Local Queue: It is local or under the control of the queue manager.
1.
- Remote Queue: It is under the control of some remote queue manager.
2.
Note: We can put and get messages from a local queue.
We can only put messages to the remote queues.
SQL: SELECT, UPDATE, INSERT, DELETE, CREATE
MQI: (Message queueing interface): It is an interface between the application program and the MQ server. MQI contains calls for communicating with MQ server.
MQI Calls
A. Put a message into a queue:
- MQCONN: Is the call to connect to queue manager.
- MQOPEN: Open the queue.
- MQPUT: To put a message(s) into the queue.
- MQCLOSE: To closed the opened queue.
- MQDISC: To disconnect from the queue manager.
- ·
B. Get a message into a queue:
- MQCONN: Is the call to connect to queue manager.
- MQOPEN: Open the queue.
- MQGET: To get a message(s) into the queue.
- MQCLOSE: To closed the opened queue.
- MQDISC: To disconnect from the queue manager.
- ·
C. put a single message into a queue.
- MQCONN: Is the call to connect to queue manager.
- MQPUT1: To put a single message into the queue.
- MQDISC: To disconnect from the queue manager.
- ·
D.
- MQINQ: To inquire about the attributes of MQ object.
- MQSET: To set the attributes of an MQ object.
- ·
E.
- MQCOMMIT: To commit the MQ changes.
- MQRLBK: To rollbak the MQ changes.
Sample Programs:
Source:
C:\PF\IBM\WebSphere MQ\Tools\ — Windows
/opt/mqm/Tools — UNIX
All the executable control commands and IBM supplied programs will be available in
C:\PF\IBM\WebSphere MQ\bin —— Windows
/opt/mqm/bin —– UNIX
To Put a message on the queue:
Run the amqsput program:
#amqsput Queue_Name Queue_Manager_Name
C:\Documents and Settings\kumar>mqrc 2058
2058 0x0000080a MQRC_Q_MGR_NAME_ERROR
C:\Documents and Settings\kumar>mqrc 2085
2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME
To get a message from a queue:
To run the amqsget program:
#amqsget Queue_Name Queue_Manager_Name
The default message get is destructive. If we want to get the message in the browse mode, we have to set the MQ getoptions to MQGMO_BROWSE to get the message in the browse mode.
MQ- Message
- Message Header : contains 25-30 fields, giving the complete information about the message. The length
of the header is around 320 bytes.
- Message data: Depends on type of business transaction. The maximum length allowed for a single
message is 100 MB. 1kb, 2kb, 3kb.
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.,
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.
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.
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
3.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:
- Temporary Dynamic Queue: This queue will be created in the program at runtime and will be deleted
after the program is completed.
- 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.
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
Windows: MQ will run as a service.
amqmsrvn MUSR_MQADMIN — Process related to the MQ service. MUSR_MQADMIN is a user-id created by MQ at the time of installation. All the queue manager process and MQ service process amqmsrvn run under this user-id.
UNIX: Once the queue manager is started the MQ process related to the queue manager will start and runnning. The process will be run under user mqm, mqm user group will created at the time of the MQ server installation.
Queue Manager type of start-up:
- Automatic: Configures the queue manager to start automatically when the machine starts up.
- Service Manual: Configures the queue manager to start only when manually requested, once started it
will continue to run even after the user who started it has logged off
- Interactive Manual: Configures the queue manager to start only when manually requested, it will end
when the user who started it logs off
Start Queue manager:
1. Start a queue manager as created.
#strmqm QMGR_NAME
2. Start a queue manager as a service:
#strmqm -ss QMGR_NAME
3. Start a queue manager in interactive mode:
#strmqm -si QMGR_NAME
Stop Queue manager:
- Stop the queue manager in controlled mode:
#endmqm -w QMGR_NAME or #endmqm QMGR_NAME
In this mode, the queue manager will first go to Quiscing mode, in this state queue manager will allow the
existing MQ connections to be completed and does not any new MQ connections. Once all the
connections are closed the queue manager will shutdown.
- Stop the queue manager in immediate mode:
#endmqm -i QMGR_NAME
In this mode, queue manager doesn’t care about running MQ connections and will stop the queue
manager immediately, in this mode, we may loose some business data. Use this mode, if you are not
able to stop the queue manager in a controlled mode one.
- Stop the queue manager in pre-emptive:
#endmqm -p QMGR_NAME
Stop the queue manager in this mode, if you are not able to stop the queue manager in the above two
modes.
What if you are not able to stop the queue managers in any of the above modes: Stop the indivudual processes of the queue manager:
#tasklist
#ps -ef | grep QMGR_NAME
#runmqsc QMGR_NAME
DIS CONN(*)
To get the process Ids of all the running connections against the queue manager.
C:\Documents and Settings\kumar>runmqsc C1
5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED.
Starting MQSC for queue manager C1.
dis conn(*) all
1 : dis conn(*) all
AMQ8276: Display Connection details.
CONN(3613BE4D20000001)
EXTCONN(414D5143433120202020202020202020)
TYPE(CONN)
PID(4844) 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(kumar) UOWLOG( )
UOWSTDA( ) UOWSTTI( )
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)
AMQ8276: Display Connection details.
CONN(3613BE4D20000601)
EXTCONN(414D5143433120202020202020202020)
TYPE(CONN)
PID(5044) TID(1)
APPLDESC(WebSphere MQ Cluster Repository)
APPLTAG(ebSphere MQ\bin\amqrrmfa.exe) APPLTYPE(SYSTEM)
ASTATE(NONE) CHANNEL( )
CONNAME( ) CONNOPTS(MQCNO_SHARED_BINDING)
USERID(kumar) UOWLOG( )
UOWSTDA(2011-05-02) UOWSTTI(07.45.14)
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
QMURID(0.20) UOWSTATE(ACTIVE)
AMQ8276: Display Connection details.
CONN(3613BE4D20000701)
EXTCONN(414D5143433120202020202020202020)
TYPE(CONN)
PID(5180) TID(1)
APPLDESC(WebSphere MQ Deferred Message Processor)
APPLTAG(ebSphere MQ\bin\amqzdmaa.exe) APPLTYPE(SYSTEM)
ASTATE(NONE) CHANNEL( )
CONNAME( ) CONNOPTS(MQCNO_SHARED_BINDING)
USERID(kumar) UOWLOG( )
UOWSTDA( ) UOWSTTI( )
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)
AMQ8276: Display Connection details.
CONN(3613BE4D20000D01)
EXTCONN(414D5143433120202020202020202020)
TYPE(CONN)
PID(4924) TID(1)
APPLDESC(WebSphere MQ Channel Initiator)
APPLTAG(ebSphere MQ\bin\runmqchi.exe) APPLTYPE(SYSTEM)
ASTATE(NONE) CHANNEL( )
CONNAME( ) CONNOPTS(MQCNO_SHARED_BINDING)
USERID(kumar) UOWLOG( )
UOWSTDA( ) UOWSTTI( )
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)
AMQ8276: Display Connection details.
CONN(3613BE4D20000E01)
EXTCONN(414D5143433120202020202020202020)
TYPE(CONN)
PID(4984) TID(1)
APPLDESC(WebSphere MQ Command Server)
APPLTAG(ebSphere MQ\bin\amqpcsea.exe)
APPLTYPE(SYSTEM) ASTATE(NONE)
CHANNEL( ) CONNAME( )
CONNOPTS(MQCNO_SHARED_BINDING) USERID(kumar)
UOWLOG( ) UOWSTDA( )
UOWSTTI( ) UOWLOGDA( )
UOWLOGTI( ) URTYPE(QMGR)
EXTURID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)
AMQ8276: Display Connection details.
CONN(3613BE4D20001D01)
EXTCONN(414D5143433120202020202020202020)
TYPE(CONN)
PID(3812) TID(187)
APPLDESC( )
APPLTAG(re MQ\java\jre\bin\javaw.exe)
APPLTYPE(USER) ASTATE(NONE)
CHANNEL( ) CONNAME( )
CONNOPTS(MQCNO_HANDLE_SHARE_BLOCK,MQCNO_ISOLATED_BINDING)
USERID(kumar) UOWLOG( )
UOWSTDA( ) UOWSTTI( )
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)
AMQ8276: Display Connection details.
CONN(3613BE4D20001F02)
EXTCONN(414D5143433120202020202020202020)
TYPE(CONN)
PID(2440) TID(1)
APPLDESC(WebSphere MQ Script Command Processor)
APPLTAG(WebSphere MQ\bin\runmqsc.exe) APPLTYPE(SYSTEM)
ASTATE(NONE) CHANNEL( )
CONNAME( ) CONNOPTS(MQCNO_SHARED_BINDING)
USERID(kumar) UOWLOG( )
UOWSTDA( ) UOWSTTI( )
UOWLOGDA( ) UOWLOGTI( )
URTYPE(QMGR)
EXTURID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)
#taskkill pid — Windows or Windows Task Manager
#kill -pid
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:
- First : Trigger conditions will be satisfied whenever the first message arrives on queue.
- Every : Trigger conditions will be satisfied for every message arrives on the queue.
- Depth : Trigger conditions will be satisfied whenever depth number of messsages arrived on the
queue.
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
Note: 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.
Intercommunication :
Sending a message from one queue manager(local machine) to another manager(remote machine).
Sender(FID):
- 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.
- 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.
- 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.
- 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.
- 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(FID) and the transport protcol(TCP.
- Start the channel initiator program against the initiation queue.
#runmqchi -q INITQ-NAME -m QMGR-NAME
#runmqchi -q FID.INITQ -m FID
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.
Receiver(JPMC):
- JPMC.QLOCAL : this is the target for the messages.
- Receiver channel(FID.TO.JPMC): the name must be same as the sender channel.
- 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.
Channel States:
- Initialization state: In this state channel will initialize itself.
- 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.
- 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.
- 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 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.
- 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 no defined dead letter queue for the queue manager.
- 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 issues 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 message sitting in the
transmission queue will be sent to the remote Queue Manager’s target queue.
- 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.
LOGS :
Logs contains the persistent messages, uncommited unit work(uow), the record image of an object.
MQ has two types of logs:
- Circular logs (default logging in MQ)
1.
- Linear logs
2.
Log path:
WINDOWS : C:\Program Files\IBM\WebSphere MQ\log
LINUX : /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. 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.
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:
This contains errors related to the system level.
WINDOWS : C:\Program Files\IBM\WebSphere MQ\errors:
LINUX : /var/mqm/errors
Which contains the queue manager specific errors.
WINDOWS : C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM2\errors
LINUX : /var/mqm/Qmgrs/QM1/errors
LOG: This contains the uncommitted unit of work, persistene messages and record of an objects.
Log path:
Windows : C:\Program Files\IBM\WebSphere MQ\log
LUNIX : /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.
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:
WINDOWS : C:\Program Files\IBM\WebSphere MQ\qmgrs/QMGR_NAME
LINUX : /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.
Errors:
2 types of errors:
- System level errors:
1.
WINDOWS : C:\Program Files\IBM\WebSphere MQ\errors
LINUX : /var/mqm/errors
- Queue manager level errors:
2.
WINDOWS : C:\Program Files\IBM\WebSphere MQ\Qmgrs\FID\errors
LINUX : /var/mqm/qmgrs/QMGR_NAME
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
WINDOWS : C:\Program Files\IBM\WebSphere MQ\trace
LINUX : /var/mqm/trace
Client – Sever Configuration:
Setup-1:
- Install the MQ client software on the client machine.
1.
- Install the MQ server and create and start queue manager and create a target queue for the client in the server machine.
2.
- Define Client Connection Channel using the MQServer environment variable on the client machine:
3.SET MQSERVER=CHANNEL20/TCP/192.168.1.2(1415)
3.
- Define the Server-Connection-Channel on the server side, the name of the channel must be the same as the Client-Connection-Channel on the client’s side.
4.
- Put the message from the cliet side #amqsputc Q1 TEST1
5.
- 6. The server-connection-channel on the server side will come to running state and the messages will be moved from client to server target queue.
6.
Setup-2:
- Define both the client and server channels on the server queue manager.
1.
- The names of the channels must be same.
2.
- FTP the channel definition table from C:\Program Files\IBM\WebSphere MQ\Qmgrs\TEST\@ipcc\AMQCLCHL.TAB to the client machine, the copy must be in binary format.
3.
- Copy the channel definition table to C:\PF\IBM\AMQCLCHL.TAB on the client box.
4.
- SET the environment variable MQCHLTAB on the client side SET MQCHLTAB=C:\PF\IBM\AMQCLCHL.TAB
5.
- Put the messages from the client for testing using the IBM program amqsputc #amqsputc Q1 TEST1
6.
MQIVP — Java Program.
2059 :
UNIX:
Winscp
Extended Transactional Client:
Windows —————————————————à Mainframes
MQ Client Software on Windows MQ Server on Z/OS
MQ Client Java Program ————-request msg ————> Request Queue (Trigger Queue)
Wait for the reply on the reply queue Reply Queue (reply msg)
Client Connection Channel Server Connection Channel (the name must be the
same the Client connection channel)
Server ——————- > Server
Client ——————— > Sever
Client ——————— > Client (NOT-Possiable)
NO ———————– Client/Server ( NOT-Possiable )
Middleware Tech 