Middleware News

Control commands - Middleware News * amqccert (check certificate chains) * amqmdain (WebSphere MQ services control) * Topic closedamqtcert (transfer certificates) * crtmqcvx (data conversion) * crtmqm (create queue manager) * dltmqm (delete queue manager) * dmpmqaut (dump authority) * dmpmqlog (dump log) * dspmq (display queue managers) * dspmqaut (display authority) * dspmqcsv (display command server) * dspmqfls (display files) * dspmqrte (WebSphere MQ display route application) * dspmqtrc (display formatted trace output) * dspmqtrn (display transactions) * dspmqver (display version information) * endmqcsv (end command server) * endmqlsr (end listener) * endmqdnm (stop .NET monitor) * endmqm (end queue manager) * endmqtrc (end trace) * mqftapp (run File Transfer Application GUI) * mqftrcv (receive file on server) * mqftrcvc (receive file on client) * mqftsnd (send file from server) * mqftsndc (send file from client) * rcdmqimg (record media image) * rcrmq

COMPHDR AND COMPMSG CHANNEL ATTRIBUTES CAN'T HAVE SPACES AROUND THEIR VALUES WHEN BEING ACCESSED BY RUNMQSC - Middleware News Data compression (COMPMSG) This is a list of message data compression techniques supported by the channel. For sender, server, cluster-sender, cluster-receiver, and client-connection channels the values specified are in order of preference. The first compression technique supported by the remote end of the channel is used. The channels' mutually supported compression techniques are passed to the sending channel's message exit where the compression technique used can be altered on a per message basis. Compression will alter the data passed to send and receive exits. See Header compression (COMPHDR) for compression of the message header. The possible values are: NONE No message data compression is performed. This is the default value. RLE Message data compression is performed using run-length encoding. ZLIBFAST Message data compression

2033 MQRC NO MSG AVAILABLE - Middleware News Problem(Abstract) You attempt to get a message from your queue. The getting application fails with the following: 2033 0x000007f1 MQRC_NO_MSG_AVAILABLE Cause The following are the most likely causes for MQRC 2033: * There are no messages on the queue. * The unit of work (UOW) for the MQPUT was not committed. * The messages have expired. Resolving the problem * Consider this reason code as a normal condition and handle this condition in your getting application. Use the MQGET MQGMO_WAIT option and retry the MQGET. o The amqsget sample programs demonstrate the use of MQGET MQGMO_WAIT. * Verify that the putting application is committing the UOW. The current depth of the queue increments at MQPUT. However, messages are not available to the getting application until they are committed. * Messages that have expired will be counted in the current depth of the queue and they are discarded at the point of MQGET. Expired messages

IBM Websphere MQ Reason Codes - Middleware News # 0 (0000) (RC0000): MQRC_NONE # 900 (0384) (RC900): MQRC_APPL_FIRST # 999 (03E7) (RC999): MQRC_APPL_LAST # 2001 (07D1) (RC2001): MQRC_ALIAS_BASE_Q_TYPE_ERROR # 2002 (07D2) (RC2002): MQRC_ALREADY_CONNECTED # 2003 (07D3) (RC2003): MQRC_BACKED_OUT # 2004 (07D4) (RC2004): MQRC_BUFFER_ERROR # 2005 (07D5) (RC2005): MQRC_BUFFER_LENGTH_ERROR # 2006 (07D6) (RC2006): MQRC_CHAR_ATTR_LENGTH_ERROR # 2007 (07D7) (RC2007): MQRC_CHAR_ATTRS_ERROR # 2008 (07D8) (RC2008): MQRC_CHAR_ATTRS_TOO_SHORT # 2009 (07D9) (RC2009): MQRC_CONNECTION_BROKEN # 2010 (07DA) (RC2010): MQRC_DATA_LENGTH_ERROR # 2011 (07DB) (RC2011): MQRC_DYNAMIC_Q_NAME_ERROR # 2012 (07DC) (RC2012): MQRC_ENVIRONMENT_ERROR # 2013 (07DD) (RC2013): MQRC_EXPIRY_ERROR # 2014 (07DE) (RC2014): MQRC_FEEDBACK_ERROR # 2016 (07E0) (RC2016): MQRC_GET_INHIBITED # 2017 (07E1) (RC2017): MQRC_HANDLE_NOT_AVAILABLE # 2018 (07E2) (RC2018): MQRC_HCONN_ERROR # 2019 (07E3) (RC2019): MQRC_HOB

2010 MQRC_DATA_LENGTH_ERROR when sending MQ messages larger than 4MB on client connection - Middleware News Problem(Abstract) Your WebSphere MQ client application is trying to send messages larger than 4 MB. It receives a data length error and is unable to send the messages. Cause The client channel did not have large enough MAXMSGL specified. Resolving the problem Increase the MAXMSGL attribute for the following: * SVRCONN channel * CLNTCONN channel * Queue Manager * Queue The MAXMSGL attribute for theses MQ objects must be large enough to handle your largest messages. However, for this value to be picked up in a client channel it must be accepted by both the client and the server. One way to do this is to define it in both the CLNTCONN channel definition and the SVRCONN channel definition using runmqsc on the server. Then copy the amqclchl.tab file from your server to the client machine, so the client can use that CLNTCONN channel definition with the new MAXM

THE WMQ JAVA CLIENT THROWS A MQRC 2010 WHEN THE SPECIFIED BUFFERLENGTH IS LARGER THAN MAXMSGL ON THE CHANNEL - Middleware News Error description * If a WebSphere MQ classes for Java client specifies a BufferLength value on a MQGET call that is larger than the value that is defined for the MaxMsgLength (MAXMSGL) on the channel, then it must result in a reason code of 2010 MQRC_DATA_LENGTH_ERROR and the message must remain on the queue. The V6 WebSphere MQ classes for Java Client allows the application to receive the message from the queue. Although the 2010 error is thrown in the V6 client, it is consumed internally and a second MQGET is performed with the BufferLength reduced to a value equal to the channel's MaxMsgLength. This means only a portion of the message is delivered to the application and the rest of the data is lost if MQGMO_ACCEPT_TRUNCATED_MSG option has been used in the MQGMO structure. Under similar circumstances, a V7.0 WebSphere MQ clas