MQ and me

• Problemes de MQ ==
  • problemes de Permisos (AIX)
  • problemes de Filesystem (own, or Comunicacions, not own)

• Instead of defining a Receiver channel, define a Requester channel, so it can be initiated from the receiver end.
  You have to specify the remote's site Listener port (and IP), as SYSTEM.REQUESTER channel will be used.

  Read "Intercommunication"

• To allow Remote Administration, a Queue Manager must define a Server Connection Channel, ( SYSTEM.ADMIN/DEF.SVRCONN may be used ) have the Commans Server running, as well as the Listener.
  DEFINE CHANNEL(MY.ADMIN) CHLTYPE(SVRCONN) DESCR('Admin connection') MCAUSER('mqm') dspmqcsv <queue_manager_name> = display Command Server status strmqcsv <queue_manager_name> = start Command Server ps -ef | grep runmqlsr runmqlsr -m <queue_manager_name> -t TCP -p <port_number> alter channel(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) mcauser('mqm')

  url

• Como activar la Configuración / Administración Remota de un QMgr ? Hace falta :
  • QMgr funcionando : dspqm/strmqm SUNQM1
  • Listener running : runmqlsr -m SUNQM1 -t TCP -p 1415
  • Command Server running : strmqcsv/dspmqcsv SUNQM1
  • canales (at FMCQM) FMCQM.SUNQM1 (sender) y SUNQM1.FMCQM (receiver)

  En el explorador MQ remoto, damos :

  • Show Queue Manager
  • Remote (not Local)
  • Name ( nom REAL del Qmgr )
  • Conexion ( @ IP amb Listener Port !!! )

• Channel names are restricted to 22 chars length !

• Display listeners : use netstat -an | find "14" (win) or TCPVIEW.EXE

• DISCINT := 0 ;
  On a channel Properties, Extended tab, define Disconnect Interval as 0 (Sender channels only).

  Improvment {092008} : 900 (usual) / 300.000 (special apps)

  Resources wasted :

  • Heartbeat - communications resource
  • amqrmppa thread - memory
    Performance support packs have stats on how much memory a running chanel takes.

  Another "con" : "an Inactive channel can't be effected by temporary network problems".

  A "pro" :
  If we use triggered channels, we will recognize connection problems at the time the channel is started, which is then very close to the deadline.
  If we start the channels at night or keep them running all day, we detect problems communicating with the remote end quite early (remote queuemanager not available, bad network changes, ....) which gives us time to investigate and fix the error a long time before the deadline is reached.

• En el mensaje se especifica la ReplyQueueManager y el ReplyQueue. El Qmgr y Cola de destino se especifican al escribir en una cola remota. Ésta define :
  • un QMgr
  • una Cola Local a ese QMgr
  • una Cola de Transmisión, Local al QMgr Local.

• On "QMgr name + Properties + Communication", enable the "Automatic Channel Definition" - once the Sender channel is defined, the corresponding Received channel "magically" appears.
  This feature uses the System Object AAA.BBB.CCC !
  See Intercommunication manual : "Auto-definition of receiver and server-connection channels", page 58, SC34-6587, MQ v 6.0, "Intercommunication".

• Install "JMS = Java Message Service", rotulado al instalar como "envio de mensajes en Java" ...

• Truco : "Add Snap_IN" to MQ Console - allows to see
  • MQ Services (local)
  • (w2k) Event Log
  • (w2k) Services
  • a Folder (with MQ logs)
  • etc
  Excelent !!

• para leer mensajes específicos (a un Correl-ID), hay que
  • definir una "match options"
  • definir un intervalo de espera
  • establecer el campo a comparar

   gmo.matchOptions = MQC.MQMO_MATCH_CORREL_ID ;
   gmo.Options      = MQGMO_WAIT ;
   gmo.waitInterval = 3000 ;
   retrieveMsg.correlationId = szCorrelID.getBytes() ;
  

• si estamos visualizando un cluster, y queremos acceder al queue manager remoto, y al dar "Connect" nos dice "Not Authorized" (AMQ4036) ... hay que asignar un usuario al MCA UserId del canal SYSTEM.ADMIN.SRVCONN !

  Si nos dice
  "Queue Manager not available for Connection" (AMQ4043) ...
  definim "DDBBVA" a c:\winnt\system32\drivers\etc\HOSTS ... as "ping DDBBVA" was also failing ... ("DDBBVA" not known at DNS)

• las colas del host no se pueden administrar remotamente, pues el PDF de Host (API de Administración) no es el mismo que en las demás plataformas
  Fixed in version 6

• You can read only a local queue, not a remote.
  You can write to a local or remote queue.

• You are advised to give the transmission queue the same name as the target queue manager so that the queue is found by default.
  When you define a Remote Queue, you can provide the name of a transmission queue. You do not have to specify this. If you do not, a transmission queue with the same name as the target queue manager is used, or, if this does not exist, the default transmission queue is used.

  The XMITQ name must match the remote queue manager name in order for remote administration to work, unless you are using a queue manager alias.

  System Admin, SC34-6068-01, page 62

• You are advised to create a DLQ for any queue manager you define

• You are advised to know the name of the default queue manager and verify it exists : remote admin

• there is a parameter only available at Queue Manager creation time : Log File Size !
  See MQS.INI

• How to copy a MQ configuration from one machine to another ?
  • use runmqsc, edit the output file a little bit, and run runmqsc again - (chklst)

  • use saveqmgr.exe ( requires MQM.DLL ) or saveqmgrc.exe ( requires MQIC32.DLL / AMQZSAIC.DLL). MQjeff @ mqseries.net

    Mind it requires the Qmgr "Running" (or "MQCONN failed for MQCFGDES, CC=2 RC=2059"). It could be a problem in a cluster ...

    echo Agafar QM del CfgMgr de Desenvolupament ... SET MQSERVER=SYSTEM.ADMIN.SVRCONN/TCP/1.2.3.4(1415) SET GESTOR=DESA01QM ECHO %GESTOR% at %MQSERVER% pause del %GESTOR%.MQS ..\SAVEQMGRC -s -m %GESTOR% -o -f %GESTOR%.MQS echo Agafar QM del Broker de PreProduccio ... SET MQSERVER=SYSTEM.ADMIN.SVRCONN/TCP/1.2.3.5(1416) SET GESTOR=TEST01QM ECHO %GESTOR% at %MQSERVER% pause del %GESTOR%.MQS ..\SAVEQMGRC -s -m %GESTOR% -o -f %GESTOR%.MQS

• How to dump a queue to a file ?

  Use QLOAD (MO03) - it preserves Message ID !

• How to know who's increasing the "Open Input Count" of a local queue, OPPROCS ? Use
  

  dis qstatus(QUEUE.NAME) type(handle) all

  that will show you the PID, CONNAME, USERID, CHANNEL name and APPLTAG !
  The DataFlowEngine.exe is MB ...
  dis qstatus(MQPRD01) type(handle) all 13 : dis qstatus(MQPRD01) type(handle) all AMQ8450: Display queue status details. QUEUE(MQPRD01) TYPE(HANDLE) APPLTAG(runmqchl_nd) APPLTYPE(SYSTEM) BROWSE(NO) CHANNEL(MQCFGPRD.TO.MQPRD01) CONNAME(192.168.254.63) HSTATE(ACTIVE) INPUT(EXCL) INQUIRE(YES) OUTPUT(YES) PID(671864) QMURID(0.5) SET(YES) TID(1) URID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[]) URTYPE(QMGR) display qstatus(Q.FEM49.MAR_FAZIT_REPLY.1) type(handle) all 4 : display qstatus(Q.FEM49.MAR_FAZIT_REPLY.1) type(handle) all AMQ8450: Display queue status details. QUEUE(Q.FEM49.MAR_FAZIT_REPLY.1) TYPE(HANDLE) APPLTAG(r\runtime\progr\FazitSrv.exe) APPLTYPE(USER) BROWSE(NO) CHANNEL(CLI.MARECOS.1) CONNAME(10.203.15.31) HSTATE(ACTIVE) INPUT(SHARED) INQUIRE(NO) OUTPUT(NO) PID(508) QMURID(0.5) SET(NO) TID(3) URID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[]) URTYPE(QMGR) USERID(mqm)

• MQVER - display MQ version and CSD level.

• DSPMQ - display all queue manages names and status.

  Uses Registry ( HKLM/Software/IBM/MQSeries/CurrentVersion/Configuration/ ) to store its values

  • QueueManager
  • Services : [Protocol := 2 (TCP)], [Listener := x'1784 (6020)]
  
  Solaris still uses qm.ini at /var/mqm/qmgrs/SUNQM1/

• CRTMQM / STRMQM / ENDMQM / DLTMQM - create / start / stop / delete a queue manager.
  CRTMQM parameters

  Usage: crtmqm [-z] ; suppress error messages. [-q] ; make this one the default queue manager. [-c Text] ; descriptive text (64 chars). [-d DefXmitQ] ; default transmission queue. There is no default. [-h MaxHandles] ; max num of handles any application can have open. Default value is 256. [-g ApplicationGroup] ; name of the group containing members allowed to ... Default value is -g all = unrestricted access. [-t TrigInt] ; trigger interval when triggering is suspended. Default is 999 999 999 milliseconds, more than 11 days. [-u DeadQ] ; name of the local queue that is to be used as dead-letter queue. The default is no dead-letter queue. [-x MaxUMsgs] ; max num of uncommitted messages under any one syncpoint. Default value is 10 000 uncommitted messages. [-lp LogPri] ; number of log primary files (*). Default = 3, min = 2, max = 254 (win), 510 (unix). [-ls LogSec] ; number of log secondary files. Default = 2, min = 1, max = 253 (win), 509 (unix). [-lc | -ll] ; circular (default) vs linear logging. [-lf LogFileSize] ; log file pages (* specified at creation time only *) [-ld LogPath] ; directory used to hold log files. QMgrName (*) $ CRTMQM es el únic moment per especificar Log File Pages size ! Flag "-lf" = Log File pages, units of 4 KB. Unix : default is 1024, giving a log file size of 4 MB. (min 64, max 65535, this is 256 MB) Solaris : max is 16384, giving 65.535 KB log file size, 65 MB Win : default is 256, giving a log file size of 1 MB. (min 32, max 65535) If we need to store 2,5 GB of persistent messages, we shall use "-lp 10 -lf 65535" ! To store 650 MB, we use "-lp 10 -lf 16384" lp = pre-formatted disk space, used for anticipated workload ls = not-formatted disk space, used for un-anticipated traffic

  En canvi, -lp i -ls es poden canviar al QM.INI a posteriori.

  url

  STRMQM parameters

  Usage: strmqm [-a|-c|-r][-d none|minimal|all][-z][-ns] [QMgrName] -c recreates the system objects with the default values and creates SYSTEM.MQEXPLORER.REPLY.MODEL

  ENDMQM parameters

  Usage: endmqm [-z] [-c | -w | -i | -p] QMgrName "-c" = controlled = stops after all applications have disconnected. Control returns immediatelly. "-w" = wait = as "controlled" but control returns only after QM has stopped. "-i" = immediate = QM stops after it has completed all the MQI calls being processed "-p" = preemptive = does not wait for applications neither MQI calls

• put/get/browse tools : (2-nd param is QueueManager)

  AMQSPUT - *** 1 msg per line ***

  AMQSGET

  AMQSGBR - browse all messages in queue - Data only

  AMQSBCG - browse all messages in queue - Data and Headers

  Latest are in e:\mq\tools\c\samples\bin !

  Use RFHutil ! (IH03 here) - requires IMQS23VN.DLL !
  RFHUTILC requires IMQC23VN.DLL !

  How to connect the client to a (remote) Qmgr ?
  qmn := 'SYSTEM.DEF.SVRCONN/TCP/15.16.17.19(1415)' ;

• T42:\MQ\Eines\WorkLoader\WLG_SRV.exe - Work Load Generator (SAG)

  Input params : qMgr, qName, numConnect, delayConnect, numMsgs, delayMsgs, sizeMsg, fileMsg, verbose.
  Get it !

• AMQICLEN - release System V IPC resources allocated by the queue manager but not freed.

• SETmqaut / DSPmqaut / DMPmqaut -

• RUNMQLSR / ENDMQLSR - manage Listener

• STRMQCSV / ENDMQCSV / DSPMQCSV - manage Command Server

• MQRC - interpret a Return Code
  Requires AMQZST.DLL (MQ Server)
  Usual values here

• AMQAPI - GUI tool to test the MQ API

• RUNMQSC - run MQSC command line commands.

• SETMQCAP 2 ??? {gone on v6}

• Interoperability url :
  Interoperability with later versions is a contract between WebSphere MQ clients and queue managers, and between queue managers. Earlier clients and queue managers can connect to, and exchange messages with, later versions. An application connected to an earlier version of the WebSphere MQ client and queue manager is not affected by upgrading the queue manager. WebSphere MQ client applications do not need to change to connect to new versions of a queue manager. It also means that an application that exchanges messages with applications connected to other queue managers will continue to work if the other queue managers are upgraded to new versions, and the applications do not change. WebSphere MQ clients and queue managers are interoperable with later versions.

When a queue manager receives a message, it looks in the transmission header to see the name of the destination queue and queue manager. If it has a queue-manager alias definition with the same name as the queue manager referenced, it substitutes the RQMNAME from its definition for the queue manager name in the transmission header.

Clustering, page 40.

Types of ALIAS

There are three types of alias :

1. queue-manager aliases,
2. reply-to queue aliases,
3. and queue aliases.

These apply in a clustered environment just as well as in a distributed-queuing environment.

Top

Queue-manager aliases

The concept of queue-manager aliasing is described in detail in the "MQ Intercommunication book", SC34-6587.

Queue-manager aliases, which are created using a remote-queue definition with a blank RNAME, have four uses:

1. Remapping the queue-manager name when sending messages
2. Altering or specifying the transmission queue when sending messages
3. Determining the destination when receiving messages
4. Using a queue manager as a gateway into the cluster.

Reply-to queue aliases

A reply-to queue alias definition is used to specify alternative names for reply information.

Queue aliases

A QALIAS definition is used to create an ALIAS by which a queue is to be known. You might do this if, for example, you want to start using a different queue but you do not want to change your applications. You might also do this if for some reason you do not want your applications to know the real name of the queue to which they are putting messages, or because you have a naming convention that differs from the one where the queue is defined. Another reason might be security; your applications might not be authorized to access the queue by its real name but only by its alias.

MQ v 6.0, "Queue Manager Clusters", page 42 to 44 [60/201].

Few intersting things about Alias queues :

• you can't MQInq() its depth !
• you can't RUNMQSC for CURDEPTH !!
• you can't Mirror it !

Attributes for queues

url

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.

Good article : cluster design and operation

When you are defining cluster-sender channels and cluster-receiver channels choose a value for HBINT or KAINT that will detect a network or queue manager failure in a useful amount of time but not burden the network with too many heartbeat or keep alive flows.

MQ v 5.3, "Clustering", SC34-6061-02, page 79 [95/183]

On platforms other than z/OS, if you need the functionality provided by the KAINT parameter, - Keep Alive -, use the Heartbeat Interval (HBINT) parameter,

MQ v 6.0, "MQSC Reference", SC34-6597-00, page 130 [150/501]

You need not alter any of your applications if you are going to set up a simple MQ cluster. The applications name the target queue on the MQOPEN(queue_name) call as usual and need not be concerned about the location of the queue manager [MQCONNECT(qmgr_name)]

Clustering, SC34-6061-02, page 63/183

You can organize your cluster such that the queue managers in it are clones of each other, able to run the same applications and have local definitions of the same queues.

The advantages of using clusters in this way are:

• Increased availability of your queues and applications
• Faster throughput of messages
• More even distribution of workload in your network

Any one of the queue managers that hosts an instance of a particular queue can handle messages destined for that queue. This means that applications need not explicitly name the queue manager when sending messages. A workload management algorithm determines which queue manager should handle the message.

When you have clusters containing more than one instance of the same queue, MQ uses a workload management algorithm to determine the best queue manager to route a message to. The workload management algorithm selects the local queue manager as the destination whenever possible. If there is no instance of the queue on the local queue manager, the algorithm determines which destinations are suitable. Suitability is based on the state of the channel (including any priority you might have assigned to the channel), and also the availability of the queue manager and queue. The algorithm uses a round-robin approach to finalize its choice between the suitable queue managers.

If an application opens a target queue so that it can write messages to it, the MQOPEN call chooses between all available instances of the queue. Any local version of the queue is chosen in preference to other instances. This might limit the ability of your applications to exploit clustering.

If a local queue within the cluster becomes unavailable while a message is in transit, the message is forwarded to another instance of the queue but only if the queue was opened (MQOPEN) with the MQOO_BIND_NOT_FIXED open option, of the MQ_Open() specified "MQOO_BIND_AS_Q_DEF" and DEFBIND queue param value is NOTFIXED.

MQ 6.0 Queue Manager Clusters, csqzah07.pdf, SC34-6589-00, page 51

To route all messages put to a queue using MQPUT to the same queue manager by the same route, use the MQOO_BIND_ON_OPEN option on the MQOPEN call. To specify that a destination is to be selected at MQPUT time, that is, on a message-by-message basis, use the MQOO_BIND_NOT_FIXED option on the MQOPEN call.

MQ 6.0 Programming Guide, page 96 [116/601]

The workload management algorithm selects the local queue manager as the destination whenever possible.

from MQ 5.3 Clustering, SC34-6061-02, page 49

WorkLoad algorithm

                           ...
                         ..                [ server_1 ]
 [ client ]      <--->  .   [ gw ]
                         ..                [ server_2 ]
                           ...

Com codificar

Let's make it run !

• TQM1 has shared queue WLMQ1
• TQM2 has shared queue WLMQ1
• TQM3 sees "two" remote cluster queues WLMQ1
• an external application (WLG.EXE) does :
  • MQCONN() to queue manager TQM3
  • MQOPEN() to queue WLMQ1
  • MQPUT() messages addressed to WLMQ1 on TQM3
• mesages get split between TQM1 and TQM2 (better if larger that 512 bytes)

If TQM3 has an alias queue WLMAQ, whose TARGETQ is WLMQ1, the WLG.EXE can write to it, and the messages still get to (split) queues.

If another (external to the cluster) qm TQM4 writes into RMQ99, a remote queue pointing to queue WLMAQ and manager TQM3, the messages go into TQM3DLQ, TQM3's Dead Letter Queue, with Reason d'2082 = MQRC_UNKNOWN_ALIAS_BASE_Q in Dead-Letter Header, because the message carries the destination Queue Manager field ... and there is no such queue there !

Solution : in the Gateway queue manager (TQM3), set a queue manager alias

See PUT !

Tested on what virtual machine ? MB !!!

Dead Letter Queue must exist if you dont want to have problems with the channels.

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 !

Top

How to WRITE into DLQ

Method #1 :

Define a remote queue pointing to an existing queue manager, but refering to a non-existing remote queue.

Find the message in the remote queue manager's DLQ.

Method #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 a Running channel !

Find the message in the local queue manager's DLQ.

Method #3 :

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 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)

Sending messages to a distribution list
In MQ on all platforms except z/OS, an application can send a message to several destinations with a single MQPUT call. This applies in both a distributed-queuing environment and a clustering environment. You have to define the destinations in a distribution list, as described in the MQ Application Programming Guide.

Lets test it in a cluster environment

El MQ_Get pot fer conversió de codis de caracters si

• s'especifica "convert"
• el format del missatge es MQ_String

Compte amb el entorn z/OS vs Unicode ...

MQFMT_STRING
Message consisting entirely of characters. The application message data can be either an SBCS string (single-byte character set), or a DBCS string (double-byte character set). Messages of this format can be converted if the MQGMO_CONVERT option is specified on the MQGET call.

"Application Programming Reference", MQ v 6.0, SC34-6596-00, page 163 [187/665]

Application data conversion
When necessary, MCAs convert the message descriptor and header data into the required character set and encoding. Either end of the link (that is, the local MCA or the remote MCA) can do the conversion.

When you move messages between systems, you sometimes need to convert the application data into the character set and encoding required by the receiving system. This can be done either from within application programs on the receiving system or by the MCAs on the sending system.

"Application Programming Guide", MQ v 6.0, page 140 [160/601]

"Application Programming Guide", MQ v 6.0, page 149 [169/601]

MCA max speed = 35 M Bytes / sec = 280 M bits / sec ;

What if we have 1 GB LAN o 100 GB ?

• Paralel (cluster) channels. Design the MQ applications to leverage multiple MQ Channels to move the data / messages.
• Increase the TCP/IP Window size to 64KB
• On Open System, increase the Queue Buffer size using the Tuning parameter overrides in the qm.ini

If we want to know the received (still enqueued) message length (to allocate the exact amount of memory) before effectively receiving it ....

1. Set BufLen to zero.
2. Set MQGMO_ACCEPT_TRUNCATED_MSG.
3. Accept the RC = MQRC_TRUNCATED_MSG_ACCEPTED
4. Use DataLength (output) -
5. This allows the application to determine the size of the buffer required to accommodate the message data, and then reissue the call with a buffer of the appropriate size.

"Application Programming Reference", MQ v 5.3, SC34-6062-02, page 377 [403/781]

To know the name of the Default Queue Manager ...

• guindows :
  
  HKLM\SOFTWARE\IBM\MQSeries\Currentversion\Configuration\DefaultQueueManager
• AIX : MQS.INI

If I set queue manager name to "" or null when connecting, I get a connection to whatever is set as default manager. Once I connected: is there a way to find what manager I am connected to?

Use amqscnxc.c !

Hint : it is required for remote admin

Listening on SYSTEM.ADMIN.COMMAND.QUEUE for PCF messages, there's a Command Server.
Where does it send its answers ?
The command server servicing this queue sends the replies to the queue defined by the ReplyToQ and ReplyToQMgr fields in the message descriptor of the command message.

PCF and Admin Interface, SC34-6598-00, page 35/725.

Command Server. The MQ component that reads commands from the system-command input queue, verifies them, and passes valid commands to the command processor.

MQ 5.3 Bibliography and Glossary, SC34-6113-02, page 26

Commands to manage it are STRMQCSV / ENDMQCSV / DSPMQCSV. Under normal circumstances, the Display command shows :

The process doing so is AMQPCSEA.EXE

Commands :

• pPCFHeader->Command = MQCMD_INQUIRE_Q ; // SC34-6598-00, 526/725

A namelist is a MQ object that contains a list of other MQ objects. Typically, namelists are used by applications such as trigger monitors, where they are used to identify a group of queues. The advantage of using a namelist is that it is maintained independently of applications; that is, it can be updated without stopping any of the applications that use it. Also, if one application fails, the namelist is not affected and other applications can continue using it.
Namelists are also used with queue manager clusters so that you can maintain a list of clusters referenced by more than one MQ object.

iSeries System Administration Guide WebSphere MQ for iSeries Version 6.0 SC34-6586-00

A namelist is a MQ object that contains a list of cluster names, queue names or AUTHINFO object names. In a cluster, it can be used to identify a list of clusters for which the queue manager holds the repositories. Programs can use the MQI to find out which queues are included in these namelists. The organization of the namelists is the responsibility of the application designer and system administrator.

"Application Programming Guide" WebSphere MQ 5.3 SC34-6064-02, page 44 [66/643]

Overlapping clusters :

"Queue Manager Clusters" WebSphere MQ 6.0, SC34-6598-00, page 105 [123/201]

A namelist is used to define a list of names that all apply to an object. For example, to specify that a qmgr belongs to more than one cluster add the cluster names to a namelist and put the namelist in the CLUSNL attribute of the qmgr.

The only thing you can do to a namelist is open it to do an MQINQ call to get a list of all the names on there.

1 - Identity context
Identity context information identifies the user of the application that first put the message on a queue:
The queue manager fills the UserIdentifier field with a name that identifies the user. The way that the queue manager can do this depends on the environment in which the application is running.
The queue manager fills the AccountingToken field with a token or number that it determined from the application that put the message. Applications can use the ApplIdentityData field for any extra information that they want to include about the user (for example, an encrypted password).

2 - Origin context
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 may want to include about the origin of the message. For example, it could be set by suitably authorized applications to indicate whether the identity data is trusted.

Application Programming, page 32 [55 of 643]

MQ counters use Windows Management Instrumentation ...

... that are displayed thru ASP pages ...

.. that require PWS = Personal Web Server (W98) / IIS (W2K & WXP)

See [T42:\{isb}\mqmon.asp] !

In MQ the parameter is "EXPIRY" and it is located in MQMD, the Message Descriptor used on every MQPUT().
It is measured in "tenths of a second", while TTL in TCP/IP I think is a number of "hops", isn't it ?

See page 148 of "SC34-6062-02", Application Programming Reference for MQ version 5.3

If a message does expire, does it go to DLQ or is it removed from MQ without a trace ? Detail

Expired messages - Messages that have expired are discarded by the next appropriate MQGET call. However, if no such call occurs, the expired messages are not discarded, and, for some queues, particularly those where message retrieval is done by MessageId, CorrelId, or GroupId and the queue is indexed for performance, a large number of expired messages can accumulate. The queue manager can periodically scan any queue for expired messages, which are then deleted.

MQ v 6.0 for z/OS, Concepts and Planning Guide, GC34-6582-00, page 45, 61/207

mq.net :
Expiry is documented in substantial detail in SC34-6596-00 MQ v 6.0 Application Programming Reference, Chapter 12, page 152. Included is behavior in both midrange and z/OS.

mq.net :
Expired messages are never available for GETting. In v6 on most platforms, they are removed by a background cleanup process. In v5.3, they are removed by a background cleanup process in some CSDs on most platforms, and in most or all CSDs on zOS.

SYSTEM.ADMIN.COMMAND.QUEUE	(qu) Command Server queue
SYSTEM.ADMIN.SVRCONN	(ch) Server-connection channel
SYSTEM.CHANNEL.INITQ	(ch) Channel initiator
SYSTEM.DEFAULT.INITIATION.QUEUE	(qu) Trigger monitor

It is very useful to have this configuration :

Advantatges ?

Unless you set the AMQCHLTAB and AMQCHLLIB variables and export the channel table file to the client-based machine, CLNTCONN will not be used.

Description of MQ tasks :
When a queue manager is running, you see some or all of the following batch jobs running under the QMQM user profile in the MQ subsystem.

"Description of MQ tasks", iSeries : System Admin Guide, url

End the processes in the following order:

"Stopping queue managers", System Admin Guide, SC34-6068-01, appendix D page 485 [507/560]

The amqzlsa0 process is the local queue manager (LQM) socket agent main program. It handles socket connections to the queue manager when the application to queue manager connection is set to isolated bindings.

If DefaultBindType is set to ISOLATED, then applications and the queue manager run in separate processes, and no resources are shared between them.

The amqzlsa0 process will not be running throughout the life of the queue manager. Once isolated bindings are enabled, then amqzlsa0 is called to initialize the resources that are necessary to support isolated bindings, and the WebSphere® MQ processes interacts as usual.

• on Solaris, use MQ J Explorer : start mqj.sh after export DISPLAY=your_ip:0.0 and X-server.

• download from url - http://www.kolban.com/mqjexplorer/code/MQJExplorer.zip

• old code : JPG

• uses SYSTEM.ADMIN.SVRCONN !

• or ... use MO71 !!

• Interessant : MQIVP.class : Installation Verification Program !

14062006 :

Santi : llibreria JMS !

• www.MQseries.net (u/k). Has a nice software repository ... ( T42:\MQ\Java\Repository )

• IBM'rs Blog , from here.

• Open Source mailing list knowledge

• WebSphere MQ Forums, 2008 & WS

• MainframeForum (u/k)

• Sun Developer (u/k)

• Information about MQ : http://www.mywiseowl.com/

You can run two MQ queue managers on the same machine by making sure they both use a unique port. Here are the definitions and how you can do this on a Windows system.

1. Create two queue managers and start them :

  crtmqm QMGR1
  crtmqm QMGR2
  strmqm QMGR1
  strmqm QMGR2

def channel(QMGR1.TO.QMGR2) chltype(SDR) +
  trptype(tcp) conname('hostname(1415)') +
  xmitq(QMGR2) +
  replace descr('QMGR1 to QMGR2 sender')
def channel(QMGR2.TO.QMGR1) chltype(rcvr) +
  trptype(tcp) replace
def qlocal(QMGR2) like(SYSTEM.DEFAULT.LOCAL.QUEUE) +
  replace share usage(xmitq)
def qremote('TO.QMGR2') +
  like(SYSTEM.DEFAULT.REMOTE.QUEUE) xmitq(QMGR2) +
  replace rname('FROM.QMGR1') rqmname(QMGR2)
def qlocal('FROM.QMGR2') replace
end

def channel(QMGR2.TO.QMGR1) chltype(SDR) +
  trptype(tcp) conname(hostname) xmitq(QMGR1) +
  replace descr('QMGR2 to QMGR1 sender')
def channel(QMGR1.TO.QMGR2) chltype(rcvr) +
  trptype(tcp) replace
def qlocal(QMGR1) like(SYSTEM.DEFAULT.LOCAL.QUEUE) +
  replace share usage(xmitq)
def qremote('TO.QMGR1') +
  like(SYSTEM.DEFAULT.REMOTE.QUEUE) xmitq(QMGR1) +
  replace rname('FROM.QMGR2') rqmname(QMGR1)
def qlocal('FROM.QMGR1'
end

runmqlsr -t tcp -m QMGR1 -p 1414
runmqlsr -t tcp -m QMGR2 -p 1415

runmqchl -c QMGR1.TO.QMGR2
runmqchl -c QMGR2.TO.QMGR1

e:\mqm\tools\samples\c\bin\amqsput TO.QMGR2  QMGR1
  Message to QMGR2
*blank ends program.

*send a message to QMGR1 from QMGR2.

e:\mqm\tools\samples\c\bin\amqsput TO.QMGR1 QMGR2
  Message to QMGR1
*blank ends program.

*get the message on QMGR1 sent by QMGR2.

e:\mqm\tools\samples\c\bin\amqsget FROM.QMGR2 QMGR1
  Message to QMGR1
  no more messages
  program ends
*get the message on QMGR2 sent by QMGR1.

e:\mqm\tools\samples\c\bin\amqsget from.QMGR1 QMGR2
  Message to QMGR2
  no more messages
program ends

A "channel" is the mechanism that one queue manager uses to pass messages to another queue manager.
Each channel consists of a message channel agent (MCA) program at the sending end which passes messages to an MCA program at the receiving end.
The MCA programs can have exit programs attached to them:

• Security exits - one at each end. Used at channel-initiation time.
• Message exits - one at each end - (GET) message exit at sending end; (PUT) message exit at receiving end. Invoked once per message.
• Send exit - at the sending end. Invoked once per message segment.
• Receive exit - at the receiving end. Invoked once per message segment.

Application considerations involved with MQ, GG24-4469, page 65 [87/250], "14.4 - MCA Exits".

Consideracions per llenguatges i per plataformes :

Using and writing API exits, chapter 15, MQ v 6.0 Application Programming Guide

From MQSC Command Reference :

• MSGDATA + MSGEXIT
• RCVDATA + RCVEXIT
• SCYDATA + SCYEXIT
• SENDDATA + SENDEXIT

Security exits normally work in pairs; one at each end of a channel. They are called immediately after the initial data negotiation has completed on channel startup, but before any messages start to flow. The primary purpose of the security exit is to enable the MCA at each end of a channel to authenticate its partner. However, there is nothing to prevent a security exit from performing other function, even function that has nothing to do with security.

Security exits can communicate with each other by sending security messages. The format of a security message is not defined and is determined by the user. One possible outcome of the exchange of security messages is that one of the security exits might decide not to proceed any further. In that case, the channel is closed and messages do not flow. If there is a security exit at only one end of a channel, the exit is still called and can elect whether to continue or to close the channel.

Security exits can be called on both message and MQI channels. The name of a security exit is specified as a parameter in the channel definition at each end of a channel.

(5.3) "Security.pdf" (pg 52)

User exits provide a mechanism for you to insert your own code into a queue manager function. The user exits supported include:

• Channel exits
  These exits change the way that channels operate. Channel exits are described in MQ Intercommunication (csqzae05.pdf, SC34-6059-02, chapter 46).
• Data conversion exits
  These exits create source code fragments that can be put into application programs to convert data from one format to another. Data conversion exits are described in the MQ Application Programming Guide (csqzal05.pdf).
• The cluster workload exit
  The function performed by this exit is defined by the provider of the exit. Call definition information is given in MQ Queue Manager Clusters (csqzah03.pdf).

(5.3) "Extending Queue Manager facilities", System Administration Guide, SC34-6068-02, page 12 [36/567].

User exits and channel-exit programs are able to make use of all MQI calls, except as noted in the sections that follow. To get the connection handle, an MQCONN must be issued, even though a warning, MQRC_ALREADY_CONNECTED, is returned because the channel itself is connected to the queue manager.

You are recommended to avoid issuing the following MQI calls in channel-exit programs:

• MQCMIT
• MQBACK
• MQBEGIN
• MQDISC

Channel-exit programs should not modify the Channel Data structure (MQCD).

Cluster workload exits must not use MQI calls.

All exits are called with a channel exit parameter structure (MQCXP), a channel definition structure (MQCD), a prepared data buffer, data length parameter, and buffer length parameter. The buffer length must not be exceeded.

(5.3) "Writing and compiling channel-exit programs", Intercommunication, SC34-6059-02, page 633 [657/815].

The exit is a DLL that must be written in C.

The exit name is the name of a dynamic-link library, suffixed with the name of a function residing in that library. The function name must be enclosed in parentheses. The library name can optionally be prefixed with a directory path and drive: [d:][path]library(function) The name is limited to a maximum of 128 characters.

"MQCD - Channel definition", (6.0) Intercommunication, SC34-6587, page 453 [475/573].

When writing channel exits for these products using Visual C++, you should do the following:

• Add MQMVX.LIB to project as a source file.

• Change the box labelled "Use Run-Time Library" from "Multithreaded" to "Multithreaded using DLL" in the project settings under C/C++ code generation.

• write a nom.DEF file as :
  LIBRARY exit PROTMODE DESCRIPTION 'Provides Retry and Channel exits' CODE SHARED LOADONCALL DATA NONSHARED MULTIPLE HEAPSIZE 4096 STACKSIZE 8192 EXPORTS Retry

Intercommunication, v 5.3, SC34-6059-02, page 641.

MQ Series Distributed Queuing Guide, SC33-1139-06, pg 274.

A amqsxrma.c la definició és :

The contents of this depend upon the exit type:

• For a channel security exit, on invocation of the exit it contains a security message if ExitReason is MQXR_SEC_MSG. If the exit wishes to send a security message back, it can either use this buffer or its own buffer (ExitBufferAddr).

• For a channel message exit, on invocation of the exit this contains:

  - The transmission queue header (MQXQH), which includes the message descriptor (which itself contains the context information for the message), immediately followed by
  - The message data

  If the message is to proceed, the exit can do one of the following:

  - Leave the contents of the buffer untouched
  - Modify the contents in place (returning the new length of the data in DataLength; this must not be greater then AgentBufferLength)
  - Copy the contents to the ExitBufferAddr, making any required changes

  Any changes that the exit makes to the transmission queue header are not checked; however, erroneous modifications may mean that the message cannot be put at the destination.

• For a channel send or receive exit, on invocation of the exit this contains the transmission data. The exit can do one of the following:

  - Leave the contents of the buffer untouched
  - Modify the contents in place (returning the new length of the data in DataLength; this must not be greater then AgentBufferLength)
  - Copy the contents to the ExitBufferAddr, making any required changes

  Note that the first 8 bytes of the data must not be changed by the exit. Why ?

• la compilació ha de ser amb els paràmetres /MD (multithread) i /LD (crear DLL)

• la linkedició ha de ser amb els fitxers mqm.lib i mqmvx.lib

• put the DLL files into c:\Program Files\IBM\Websphere MQ\exits

• Noms :
  • T42:\MQ\Eines\Exit_Minima\exit_minima.c => T42:\MQ\Eines\Exit_Novato\TESTEXIT.dll [security]
  • T42:\MQ\Eines\Exit_Duplicadora
  • T42:\MQ\Eines\Exit_Traza => T42:\CPP\MQEXIT\Exit_Traza

• Data Trace - traces all messages sent over a channel into a file
  File ubication is T42:\CPP\MQEXIT\Exit_Traza\EXES.DLL The header is void MQENTRY MQAExit ( So we have to code MSGEXIT('EXES(MQAExit)') + MSGDATA('c:\MVQTRXIT.TRC)') And we get a trace of all traffic in file c:\MVQTRXIT.TRC
  
  Probar de ficar una destinació estil "unix" ...

• Duplication - creates a copy of all messages sent over a channel and enqueues them on a specified queue

  Original Destination Queue and Destination Queue Manager are lost

  File ubication is T42:\CPP\MQEXIT\Gas_Natural\GNX2.DLL The header is void MQENTRY gnxit ( So we have to code MSGEXIT('gnx2(gnxit)') + MSGDATA('Q2SAGCOPY RQM)') + And we get the messages in local queue Q2SAGCOPY And a trace in file c:\GNX2.TRC
  
  Aquest fitxer de sortida no ès vàlid per a "unix" ...

Under W2K, the Message Exit DLL has to be placed in d:\IBM\WebSphere MQ\exits !

Message Exit Code

El canal Q1TOQ2 del QMgr Q1 té :

El canal Q2TOQ1 del QMgr Q2 té :

See the MQ Application Programming Guide.

url

Es molt interessant la MirrorQ exit - duplica missatges !

Sequència de instalació (win) :

1. copiar la DLL a c:\MQ\exits\
2. crear la Namelist fent servir MIRRORQ.MQSC
3. configurar :
   • obrir MQ Explorer
   • seleccionar el gestor (QMB)
   • botó dret, escollir "Properties" i "Exits", escollir "Add"
   • Name := "MirrorQ" ;
   • Function := "EntryPoint" ;
   • Module := browse to DLL
   • check "Data" checkbox
   • write Data := "mirrorq", name of the NameList (see bellow).
4. reiniciar el gestor & probar

Que fa ? Tot missatge que es posa a la cua TEST_IN1 resulta duplicat a la cua TEST_IN1_COPY.

url & file

Unix : Configuring API exits on UNIX® systems.

An invalid magic number for a module implies that there is a 32-bit to 64-bit missmatch.

Per generar el module (es la "dll" de AIX), es a dir, per compilar una Exit :

Si us dona l'error "ld: 0711-317 ERROR: Undefined symbol: .MQXEP", es que no heu afegit "-lmqmzf" !

Compte que a la URL també hi ha un mirrorq.cpp que fa el mateix, però per Triggering !

• runmqsc queuemangername < mirrorq.mqsc
• start runmqtrm -m queuemanagername -q MIRRORQ.TRIGGER
• amqsput MIRRORQ.STAGEQ queuemanagername
• amqsbcg MIRRORQ.BUSINESSQ queuemanagername
• amqsbcg MIRRORQ.MIRRORQ queuemanagername

Compte que a vegades cal que es conservi el MsgId !

If you install MQ v5.3 undel SuSE or RedHat Linux, and get a "Segmentation Fault", fix it by

MQ HA 5.3 installation under Linux [url]

Gracias, Pablo !

If you use BCC32 instead of CL, then the MQM.LIB has not the proper format. To convert it to "Borland's" format, use COFF2OMF.exe, that can be found at "c:\Borland\BCC55\Bin" !

• *) install MQ software on each computer in the cluster.

  Queue managers themselves need to exist only on the computer on which you create them. In the event of failover, the MSCS initiates the queue managers on the other computer. The queue managers, however, must have their log and data files on a cluster shared disk, and not on a local drive.

• *) set Queue Manager to have MANUAL startup.
• *) set IBM MQ Service to have MANUAL startup.
• *) create ONE queue manager ( with Persistent queues )
• *) move the queue manager Data and Log files to shared disk :

  hamvmqm /m qmname /dd "f:\WebSphere MQ" /ld "f:\WebSphere MQ\log"

• *) register MQ resource to MSCS

  haregtyp /r

• *) create the MQ resource to Cluster Admin
• *) verify it works : "bring online" + put/get messages
• *) Failover ! Or "Move" the cluster resources to second PC.
• *) see previous messages, and put more msg into a queue
• *) failover (back)
• *) see all messages ! (if "persistent")

System Admin Guide, SC34-6068-02, chapter 13 - Supporting MSCS

This indicates whether the message survives system failures and restarts of the queue manager.

Message persistence
Persistent messages are written to logs and queue data files. If a queue manager is restarted after a failure, it recovers these persistent messages as necessary from the logged data.

MQ 6.0 Programming Guide, pg 30 [50/601], SC34-6595-01

This means that the message survives system failures and restarts of the queue manager. Once the message has been put, and the putter's unit of work committed (if the message is put as part of a unit of work), the message is preserved on auxiliary storage. It remains there until the message is removed from the queue, and the getter's unit of work committed (if the message is retrieved as part of a unit of work).

MQ 5.3 Application Programming Guide, pg 171 [197/781], SC34-6062-02

Data for persistent messages is written to log buffers. These buffers are written to the log data sets when:

• a commit occurs
• a message is got or put out of syncpoint
• WRTHRSH buffers are filled

MQ z/OS Problem Determination Guide, GC34-6600-00

La persistencia de un missatge es determina :

• per l'aplicació
• per la cua

When you create a message, if you initialize the message descriptor (MQMD) using the defaults, the persistence for the message is taken from the DefPersistence attribute of the queue specified in the MQOPEN command. Alternatively, you can set the persistence of the message using the Persistence field of the MQMD structure to define the message as persistent or nonpersistent.

url

Persistence is really a message attribute and not a queue attribute.

url

Si els missatges son no persistents, i el log creix 7 GB cada dia, com podem investigar el seu contingut ? Create a new qmgr, start it, create a queue, put a persistent message, end the qmgr, print the log.

Top

Are those in which other resources, such as tables in a relational database, are also updated. When more than one resource manager is involved, there is a need for transaction manager software that uses a two-phase commit process to coordinate the global unit of work. Use global units of work when you also need to include updates to relational database manager software, such as DB2, Oracle, and Sybase.
We define two scenarios for global units of work:

• In the first, the queue manager itself acts as the transaction manager. In this scenario, MQI verbs control the global units of work; they are started in applications using the MQBEGIN verb and then committed using MQCMIT or backed out using MQBACK.

• In the second, the transaction manager role is performed by other software, such as TXSeries, Encina©, or Tuxedo. In this scenario, an API provided by the transaction manager software is used to control the unit of work (for example, EXEC CICS SYNCPOINT for TXSeries).

MQ 5.3 System Admin Guide - SC34-6068-02, chapter 11 : Transactional support.

Using CICS with WebSphere MQ & setting up the TXSeries interface to WebSphere MQ :

• CICS Administration Guide for Open Systems.
• TxSeries library [***]
• Using CICS with WebSphere MQ
• CICS Application Programming Guide

Circular logging
Use circular logging if all you want is restart recovery, using the log to roll back transactions that were in progress when the system stopped.

Linear logging
Use linear logging if you want both restart recovery and media or forward recovery (recreating lost or damaged data by replaying the contents of the log).

De que no ens protegeix el Log circular ?

• de que s'espatlli el disc on son les dades o el log
• de que es corrompeixin les dades d'una cua
• de que algu ens robi un missatge

Another EXCELENT T-Rob's article :

El SaveQmgr ens porta cap a un "arranque en frio" !

With circular logging, you only get stop/restart capability for a "healthy" queue manager. MQ objects are not written to circular logs. To restart a queue manager if objects have been damaged or lost, you also need media recovery. In order to perform media recovery, the queue manager must have written media images of MQ objects in the logs. MQSeries stores media images in logs only if you are using linear logging.

"Backup and Recovery" redbook, SG24-5222.pdf

Logged messages and other things logged are not removed from logs. Logs are history. Logs are required for queue manager restart to ensure consistency. Non-persistent messages are not logged. UofW information is logged.
There are four types of log record, described under the following headings:

• "Unit-of-recovery log records"
• "Checkpoint records"
• "Page set control records" on page 34
• "CF structure backup records" on page 34

GC34-6582-00, WebSphere MQ for z/OS Concepts and Planning Guide. Chapter 4, Logging.

LogFilePagesSize=number ("-lf=NN")

The log data is held in a series of files called log files. The log file size is specified in units of 4 KB pages.

In MQ for UNIX systems, the default number of log file pages is 1024, measured in units of 4 KB. giving a log file size of 4 MB. The minimum number of log file pages is 64 and the maximum is 65 535.

In MQ for Windows, the default number of log file pages is 256, measured in units of 4 KB. giving a log file size of 1 MB. The minimum number of log file pages is 32 (128 KB) and the maximum is 65 535 (262 MB).

Note: The size of the log files specified during queue manager creation cannot be changed for a queue manager.

MQ v 6.0 System Administration Guide, SC34-6584-01, page 118 [140/647]

• in : persistent message average size
• in : number of persistent messages per day
• in : number of days to be able to recover
• out : log size

MQ v 6.0 System Administration Guide, SC34-6584-01, page 238 [260/647]

If a large (500 KB) BAR file has to be deployed, the (Windows) default values are not enough

If we have to store 5.000 messages of 500 KB each (2,5 GB), we shall use "-lp 10" !

url

• Log ubication
  • Intel :
    • c:\Program Files\IBM\WebSphere\Errors - unrelated to any queue manager
    • c:\Program Files\IBM\WebSphere\Qmgrs\<qmgr_name>\Errors - related to <qmgr_name>
  • Unix :
    • /var/mqm/errors - unrelated to any queue manager
    • /var/mqm/qmgrs/<qmgr_name>/errors - related to <qmgr_name>

• Channel management
  1. stop both send and receive ends of the channel
  2. start the Receive end of the channel - the status stays "Inop"
  3. start the Send end of the channel - the status goes "Running"

• Book : Clustering, SC34-6061-02, page 110/183

• PPT : T42:\MQ\TroubleShooting\MQ_V6_Troubleshooting_v1.pps or url (internal)

• Mind Client TroubleShooting

Primeros auxilios. A continuación se presentan una serie de pasos a realizar cuando se encuentra algún problema con el MQ.

• Verificar que el gestor de colas esta arrancado, utilizando el comando dspmq. Si no lo está, dar el comando strmqm <nombre gestor>
• Verificar que el listener del gestor de colas esta arrancado, con el comando tasklist /svc | find "runmqlsr"
  runmqlsr.exe 1024 N/A
• Verificar el contenido de AMQERR01.LOG
• Verificar la profundidad y el contenido de la DLQ
• Verificar que todos los canales estén Running
• Verificar que todas las colas estén vacías

• rename MQS.INI
• rename \qmgr_name\QM.INI
• set S0000000.LOG (active log) to "read-only"
• set general/specific AMQERR01.LOG owner to "root" (chown)

Get ALL the info manually :

Some Tuning here ...

• Improved Usability
  • Simple File Transfer (Windows & Linux) - a simple application that works "out-of-the-box", command line and GUI. No need to write own test programs.
  • Quick Tour (Windows & Linux)
  • New cross-platform configuration tooling (Windows & Linux)
• Improvements to manageability
  • Find out what the system is doing, and influence it
    • DISPLAY QSTATUS
    • DISPLAY CHSTATUS
    • DISPLAY CONN(*) ALL
    • TRACEROUTE
  • Easier problem determination and problem avoidance
• Enhanced Availability
  • Exploiting z/OS services
• Extended performance, capacity and scalability
  • Exploiting 64-bit address space
• Eclipse configuration tool - can configure WMQ on all platforms
  (including WMQ V6 for z/OS - but not earlier versions on z/OS)
• Trace Route
• IPV6
• zOS : messages (in Shared queues) larger than 63 KB are now supported (using DB2) - up to 100 MB.
• AIX : 64-bit support

Platform coverage :

• AIX 5 (64-bit systems only)
• Solaris (64-bit Sparc systems only)
• HP-UX 11i (64-bit PA-RISC only)
• Linux/Intel (32-bit), Linux/pSeries (64-bit distros only), Linux/zSeries
• z/OS 1.4
  DB2 v 7.1 with PQ71179, IMS v 7.1, Coupling Facility Level 9.
• Windows 2000, XP, 2003
• OS/400
• Other platforms/environments (eg 64-bit) under consideration for a later GA2

Sources :

• see "WSMQv6 Technical Overview.ppt" [T42:\MQ\Presentacions]
• MQ version 6 (internal) Search (for trigger)

Trick :

2 items to remotely administer z/OS MQ :

1. you need the client attach facility (CAF) installed on the z/OS
2. you need to use at Windows a User and Password accepted by RACF, as the Windows logon is what is passed. It's all that is passed, unless you have a security exit. [jeff]
   Otherwise, you will see a RACF problem by looking into the log of the MSTR on z/OS. [butcher]

It would be advisable to compile and link your apps with the new libraries

• Important MQ V6.0 upgrade information information [*****] - llista de technotes, publicacions, redbooks, etc.

• Migration Information - Some issues affecting migration to MQ Version 6.0
  • 64-bit qmgrs
  • IP v6
  • SSL migration

• use MS03 - SaveQmgr

• use amqoamd -s to save security information.

• save
  • mqs.ini & all qm.ini files
  • /var/mqm/exits & /var/mqm/exits64
  • /var/mqm/qmgrs
  • /var/mqm/logs

• Unix : you must uninstall MQ and any FixPacks

• use
  • AIX - SMIT
  • Solaris - pkgadd

• After you migrate a queue manager to MQ Version 6.0, you must start that queue manager to migrate your file system structure before you start any MQ listener associated with that queue manager. Otherwise, you will not be able to start the MQ listeners after migration.

• If you cannot connect to a migrated queue manager and see an error like "SYSTEM.MQEXPLORER.REPLY.MODEL not defined", run strmqm -c command; it refreshes the default system objects, including creating the queue required by MQ Explorer, SYSTEM.MQEXPLORER.REPLY.MODEL

• DeveloperWorks Migrating MQ queue manager clusters to MQ V6

WebSphere MQ Quick Beginnings Guides :

• AIX - url
• HP-UX - url
• iSeries - url
• Linux - url
• Solaris - url
• Windows - url

WebSphere MQ Migration Information Manual - url

Online Information Center for WebSphere MQ v6.0 - url

SupportPac MS6A: WebSphere MQ V6.0 for UNIX Automatic Migration & Maintenance Installation - url

Announcement: End of support for WebSphere MQ 5.3 - url

End of Service dates for WebSphere MQ - url

WebSphere MQ Detailed System Requirements - url

WebSphere MQ Recommended Fixes - url

Technotes :

• Important MQ V6.0 migration information - url
• Migration to WebSphere MQ Version 6.0 - url
• Exits are removed from MQ directory during V6 migration - url
• WebSphere MQ V6: Rollback Procedure from WebSphere MQ V6 to V5.3 - url
• Checklist : Unable to Create or Start Queue Manager (iSeries) - url
• WebSphere MQ V6: Alternative method of migration from WMQ V5 to WMQ V6 (iSeries) - url
• World executable files in WebSphere MQ v6.0 distribution - url
• STRMQM fails with AMQ5522 and AMQ6109 - url
• Are the HP-UX 2004 GOLDBASE and GOLDAPPS environments supported - url
• WebSphere MQ installation hangs with no errors (Windows) - url
• Installation fails when migrating from WebSphere MQ V5.3 - url

DeveloperWorks Article related to Migration : "Migrating WebSphere MQ queue manager clusters to WebSphere MQ V6" - url

Migration to MQ v6 on Distributed Platforms.pdf - url

2002, x'07D2	MQRC_ALREADY_CONNECTED
2009, x'07D9	MQRC_CONNECTION_BROKEN
2016, x'07E0	MQRC_GET_INHIBITED
2019, x'07E3	MQRC_HOBJ_ERROR - object handle is not valid.
2030, x'07EE	MQRC_MSG_TOO_BIG_FOR_Q
2033, x'07F1	MQRC_NO_MSG_AVAILABLE
2035, x'07F3	MQRC_NOT_AUTHORIZED
2051, x'0803	MQRC_PUT_INHIBITED
2053, x'0805	MQRC_Q_FULL
2058, x'080A	MQRC_Q_MGR_NAME_ERROR - QMgrName parameter is not valid or not known.
2059, x'080B	MQRC_Q_MGR_NOT_AVAILABLE - QMgrName is not available for connection.
2079	MQRC_TRUNCATED_MSG_ACCEPTED
2082	MQRC_UNKNOWN_ALIAS_BASE_Q
2085, x'0825	MQRC_UNKNOWN_OBJECT_NAME
2087, x'0827	MQRC_UNKNOWN_REMOTE_Q_MGR
2103, x'0837	MQRC_ANOTHER_Q_MGR_CONNECTED
2196, x'0894	MQRC_UNKNOWN_XMIT_Q
2218, x'08AA	MQRC_MSG_TOO_BIG_FOR_CHANNEL
0265	MQFB_APPL_CANNOT_BE_STARTED - trigger problem - url
0271	MQFB_XMIT_Q_MSG_ERROR - you can't write to a Xmit Q.
65536, x'10000	MQFB_APPL_FIRST

MQ v 5.3, "Messages", chapter 8, 'API completion and reason codes', page 111 [120/223]

url; "Messages" On-Line

Client envir : 2009, 2018, 2019 2033, 2119, 2080, 2079, 2016, 2051, 2059, 2162

API CC's & RC's : on-line.