Product Readmes
Abstract
This document describes the fixes in WebSphere MQ V5.3 Fix Pack 12.
Content
Note: to download WebSphere MQ fix packs follow this link http://www.ibm.com/support/docview.wss?rs=171&uid=swg27006037
Table of Contents
APARs in Fix Pack 12
- SE22515
MQM400 CLUSTER PROBLEM RESULTS IN AMQ9498, MQCD NOT VALID - SE22035
FFST IN COMPONENT AOTADDENTRY WITH PROBE ID AO124001 CAUSING QUEUE MANAGER TO END. - SE22006
CICS HEADER FLAGS FOR THE MQCIH STRUCTURE NOT THERE IN RPG AND COBOL HEADER/COPY FILES. - SE21834
MQM400 STRMQM FAILED FOR MIGRATED QUEUE MANAGER WITH MCH0601. - SE21231
MQM400 AGENT JOBS ARE NOT BEING ENDED AFTER FDC PROBE ZL000028 HAS BEEN LOGGED - SE21176
MQM400 WRKMQM GENERATES MSGMCH6902 AND MSGCZM1212 WHEN MORE THAN NINE QUEUE MANAGERS TO BE DISPLAYED - SE21113
BROWSING MESSAGE USING WRKMQMMSG ON LOCAL QUEUE, IF F11 PRESSED FOR ALTERNATIVE VIEW, THE LOCAL DATE COLUMN VALUES ARE CORRUPT. - SE20876
MQM400 - REPLACE ABORT WITH AN FDC WHEN PCTL CORRUPTION IS
DETECTED - SE20597
MQM400 RPG FILE QMQM/QRPGLESRC(CMQCIHG) CORRUPTED IN MQ V5.3 - IY78429
CHANNEL PROCESS (AMQRMPPA) MAY FAIL DUE TO BAD DATA FROM PRE-CSD10 JAVA CLIENT - IY77854
NON-DURABLE SUBSCRIPTION MESSAGES NOT GETTING CLEANED ON Z/OS QUEUEMANAGER (OR WHEN SUBSTORE = QUEUE IS USED). - IY77769
MESSAGES REMAIN ON THE SYSTEM.CLUSTER.TRANSMIT.QUEUE AFTER THE CHANNEL IS SUPPRESSED BY A CHADEXIT. - IY77233
OBJECT CATALOG CORRUPTION DURING RESOURCE EXHAUSTION - IY77059
PROBE ID'S MQ000010 AND XY180010 FOLLOWING APPLICATION OF
IY74420. - IY76845
FAILURE TO PERFORM DATA CONVERSION OF AN MQRFH2 WHICH CONTAINS NAMEVALUEDATA WHICH IS NOT ALIGNED ON A 4 BYTE BOUNDARY. - IY76799
FAILED CALL TO GETPEERNAME LEAKS FILE DESCRIPTOR IN AMQRMPPA - IY76712
UNPREDICTABLE RESULTS WHEN THE TOPIC ASSOCIATED WITH A DURABLE SUBSCRIPTION CHANGES WHEN USING THE MQ BROKER. - IY76314
XA CLIENT ENDING ABRUPTLY LEAVES OUTSTANDING UNITS OF WORK
LOCKED UNTIL THEY SPAN THE ACTIVE LOG, WHEN THEY ARE BACKED OUT. - IY76101
SIGSEGV IN AMQFCXBA AFTER MQRFH2 MESSAGE SENT TO
SYSTEM.BROKER.CONTROL.QUEUE - IY76063
CHANNELS IN STOPPING/BINDING STATE WHICH CANNOT BE STOPPED USING STOP CHL(CHLNAME) MODE(FORCE) - IY75854
PUBLISHING APPLICATIONS ARE DELAYED BY UP TO 60 SECONDS WHEN PUBLISHING. ERROR 2033 MSG_NOT_AVAILABLE RETURN CODE IS SEEN. - IY75657
CLUSTER RECEIVER CHANNELS DO NOT WORK WITH MESSAGE RETRY EXITS - IY75589
MQJMS1061: UNABLE TO DESERIALIZE OBJECT MESSAGE DUE TO
JAVA.LANG.CLASSNOTFOUNDEXCEPTION WHEN USING WEBSPHERE MQ - IY75467
WMQ BROKER DIES WITH PROBE XC130003 FDC IN FUNCTION
FAIADDERRORTAG - IY75252
MQ COMMANDS FAIL IF THE MQ FILES PATH IS SPECIFIED AT THE END
OF THE PATH STRING AND IS NOT TERMINATED WITH A COLON (:). - IY74915
PERFORMANCE IMPACT ON AIX WHEN AN API EXIT IS INVOKED - IY74818
WMQ NOT ROLLING BACK A TRANSACTION AFTER XA CALLS RETURN
XAER_NOTA - IY74802
PROBE XC015001 FDCS, XECS_E_BLOCK_ALREADY_FREE, FROM
XCSFREEQUICKCELL - IY74567
ALTDATE AND ALTTIME OF CLUSQMGR DISPLAYED TWICE ON WMQ5.3 - IY74420
MQ HANG FOLLOWING PTHREAD_CANCEL ON SOLARIS. XCSKILLTHREAD, XLSLOCKMUTEXFN MCATYPE(THREAD) - IY74339
SIGBUS/SIGSEGV IN KQIINQUIREQUEUEHANDLESTATUS - IY74175
XLSRELEASESOCKETMUTEX FDC WITH PROBE XY033001, NO SUCH FILE OR DIRECTORY. - IY74092
PARENT PUBLISH SUBSCRIBE BROKER ENDS ABRUPTLY WHEN A CHILD
BROKER IS STARTED (FDC PROBE PU522010) - IY74045
RM409000 FFST FROM RRIWAITSECONDARY - IY73941
QUEUE MANAGER RESTART FAILURE (LOOP) AFTER SYNCQ/CHANNEL
DEFINITION FILE BECOME OUT OF SYNC. - IY73907
FDC WITH PROBE XC006001 FROM XCSFREEMEM FROM THE REPOSITORY MANAGER PROCESS. - IY73579
MQMESSAGE.RESIZEBUFFER(INT SIZE) VALUE IGNORED. - IY73548
MQ MAY WRITE A XC130003 FDC UNDER ZCPQUERYTERMINUS WHEN USING XA - IY73543
PROBE XC307004 FDC FROM XLSREQUESTMUTEX (LINUX ONLY) - IY73202
SOFTWARE MAY GET PERMISSIONS FAILURE READING AMQCAP.INF FILE - IY73062
SELECTOR IGNORED ON CONNECTIONCONSUMER - IY72996
SIGSEGV IN XPPRUNDESTRUCTORS FOR CHANNEL USING SSL - IY72981
TRUNCATED WAS FDCS (PROBES ZF178* TO ZF216*) - IY72879
CONTINUOUS USE OF ONE MQQUEUEBROWSER FOR SEVERAL
MQQUEUEENUMERATIONS USES TOO MUCH MEMORY. - IY72844
QUEUE MANAGER CANNOT RESTART: FDC WITH PROBE ID HL083114. - IY72714
FAILURE OF LDAP SERVER PROVIDING O/S USER IDENTIFICATION DATA TO WMQ THROUGH THE GETGRENT INTERFACE OBSERVED ON SOLARIS - IY72519
AMQ9652 ERROR MESSAGE GENERATED INCORRECTLY WHEN THE
CRYPTOGRAPHIC STORE / KEY REPOSITORY PASSWORD HAS EXPIRED. - IY72218
MQDISC FAILS WITH MQRC_HCONN_ERROR (2018 0X7E2) AND THE CICS
APPLICATION RETURNS ABNORMAL TERMINATION U8035. - IC47804
MQ MSCS RESOURCE FAILS TO APPLY LOCAL MQM GROUP PERMISSIONS TO THE DIRS CONTAINING THE QUEUE MANAGER DATA EVEN AFTER IC43947 - IC47481
MULTI-THREADED CLIENT RETURN MQRC_ALREADY_CONNECTED - IC47447
MESSAGES NOT ACKNOWLEDGED WHEN USING CONNECTIONBROWSERS WITH AUTO_ACK OR DUPS_OK SESSIONS - IC47443
JMS MESSAGEPRODUCER MEMORY LEAK. - IC47335
JMS CUMULATIVE INTERIM FIX FOR WEBSPHERE MQ V5.3 FIX PACK 11 - IC47332
MQ CLIENT AMQ9691 ERROR WHEN TRYING TO ADD A CERTIFICATE USING AMQMCERT -A WHEN THE CERTIFICATE IS ALREADY PRESENT IN THE STORE - IC47255.
WHEN MESSAGE SELECTOR IS USED WITH DURABLE SUBSCRIBER AND
APPLICATION TERMINATES ABRUPTLY, THE MESSAGES ARE LOST. - IC47236
MQRC_CONTEXT_HANDLE_ERROR (2097 ERROR)- WHEN PASS_ALL_CONTEXT OPTION IS USED WITH JAVA DISTRIBUTION LIST. - IC47224
MULTIPLE POOLSCAVENGER THREADS CREATED WHEN USING EITHER
WEBSPHERE APPLICATION SERVER VERSION 5.X OR WEBSPHERE MQ. - IC46987
COINITIALIZE FAILURE RPC_E_CHANGED_MODE (-2147417850) WITH MSCS - IC46955
VARIOUS SETMQSCP PROBLEMS - IC46774
MMC SHOWS INCORRECT STATUS INFORMATION, OVERLAPPING/MULTIPLE AMQMSRVN PROCESSES - IC46766
PUTDATETIME PROPERTY IN 'MQMESSAGE' MQ .NET CLASS IS READ ONLY AND CANNOT BE ALTERED OR SET. - IC46684
CUSTOM SERVICE ENTRY DISPLAYS WRONG VALUE IN "EXECUTION" BOX ON WINDOWS CHINESE EDITION - IC46653
MQQUEUEMANAGER CONSTRUCTOR DOES A CONNECT TO THE QM, BUT IT DOES NOT CHECK TO SEE IF IT IS CONNECTED ALREADY BEFORE RECONNECTING. - IC46548
MQRC_OPTIONS_ERROR IS RETURNED IF QPMO_ALTERNATE_USER_AUTHORITY IS SPECIFIED WITH MQQUEUEMANAGER.PUT() CALL. - IC46539
.NET DOTNET DYNAMIC QUEUE NAME MQRC_DYNAMIC_Q_NAME_ERROR 2011 ACCESSQUEUE - IC46530
AMQ2018 .NET MQBEGIN - IC46433
MQ .NET CLASSES NEED +INQ AUTHORITY TO GET DYNAMIC QUEUE NAME - IC46407
INCORRECT TRUNCATION OF QUEUE FILE DURING LOG FULL CAUSED A
DAMAGED QUEUE - IC46369
PUB/SUB BROKER (AMQFCXBA.EXE) TRAPS SAYING "ACCESS VIOLATION AT ADDRESS XXXXXXXX WHEN READING" - IC46301
MC011057 WHEN STOPPING WINDOWS WHILE MSCS CONTROLLED QUEUE MANAGER IS STILL RUNNING. - IC46145
MQRC_NO_MSG_AVAILABLE MQRC2033 WHEN GETTING LOCKED SEGMENTS - IC45869
MQ SERVICE FAILS TO STOP, AND TRAP OCCURS IF A QUEUE MANAGER
IS DELETED. - 96924
IMPROVE ERROR REPORTING IF LOOKUP OF PROCESS REAL UID FAILS;
AND FOR AUTHORIZATION FAILURES IN GENERAL. - 96375
OCCASIONAL XASESSION.CLOSE FAILS ON ISERIES - 95759
SIGSEGV IN AMQRRMFA, WITH RFXENUM* CALL IN RECENT FDC TRACEBACK - 95657
MQM400 WRKMQM - BAD CHARACTERS IN DESCRIPTION COLUMN WHEN USER DOES NOT HAVE *CONNECT AUTHORITY TO THE QUEUE MANAGER - 94886
FAILURE TO LOAD EXITS CORRECTLY WHEN USING THE MQ EXPLORER, AND WITH JMS CLIENTS ON WINDOWS. MQCSP STRUCTURES NOT SENT TO SERVER - 94664
UNABLE TO USE THE JMS POSTCARD APPLICATION TO SEND MESSAGES FROM LINUX MACHINES.
SE22515
|
| Abstract | MQM400 CLUSTER PROBLEM RESULTS IN AMQ9498, MQCD NOT VALID |
| Users Affected | A migrated cluster queue manager may be affected. Platforms affected: iSeries |
| Error Description | When a cluster queue manager is started after migration, messages are accumulated in SYSTEM.COMMAND.QUEUE and SYSTEM.CLUSTER.TRANSMIT.QUEUE. Also An FDC with Probe Id ZX054060 is generated. WebSphere MQ First Failure Symptom Report ========================================= Probe Id :- ZX054060 Component :- zxcRestoreObject Job Name :- 835359/QMQM/AMQZXMA0 Major Errorcode :- rrcE_INVALID_MQCD Minor Errorcode :- OK Probe Type :- MSGAMQ9498 Probe Severity :- 2 Probe Description :- AMQ9498: The MQCD structure supplied was not valid. FDCSequenceNumber :- 0 Arith1 :- 0 Arith2 :- 0 Comment1 :- TO.PHZ8.PHK02 MQM Function Stack zxcPostInitialiseSetup zxcCreateRepositoryCache zxcRestoreCache zxcRestoreObject xcsFFST |
| Problem Summary | When the FDC description is AMQ9498 "The MQCD structure supplied was not valid", additional data is restricted to the channel name in Comment1. The FDC does not have information about the CD structure in the cache. |
| Problem Conclusion | Extra diagnostic information is dumped in the FDC with probeID ZX054060. |
SE22035
|
| Abstract | FFST IN COMPONENT AOTADDENTRY WITH PROBE ID AO124001 CAUSING QUEUE MANAGER TO END. |
| Users Affected | MQ5.3 users only are affected. The error is an internal object catalogue hash table error. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | Queue manager ends suddenly. An FDC is fired by the agent job in component aotAddEntry with probe id AO124001 and Major Errorcode:- STOP_ALL |
| Problem Summary | The problem is due to the object catalogue hash table being corrupt, due to the existence of duplicate ulCounter values. |
| Problem Conclusion | Duplicate ulCounter values cause hash table corruption leading to a queue manager end. Code changes have been made to ensure that duplicate ulCounter values are avoided. |
SE22006
|
| Abstract | CICS HEADER FLAGS FOR THE MQCIH STRUCTURE NOT THERE IN RPG AND COBOL HEADER/COPY FILES. |
| Users Affected | Users of MQ5.3 needing to use CICS header flags for the MQCIH structure. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | The header file cmqg.rpg and COBOL copy files cmqv.cpy does not have all the CICS header flags for the MQCIH structure defined. |
| Problem Summary | The flags in the MQCIH structure were not defined in the header files. |
| Problem Conclusion | The CICS header flags for the MQCIH structure have been added to the RPG and COBOL copy files. |
SE21834
|
| Abstract | MQM400 STRMQM FAILED FOR MIGRATED QUEUE MANAGER WITH MCH0601. |
| Users Affected | iSeries migration to WebSphere MQ V5.3 fix pack 10 face this trouble only if MQCD structure is found incorrectly migrated. Platforms affected: iSeries |
| Error Description | STRMQM fails after upgrade from V5.2 to V5.3 FP10 with AMQ5615 and AMQZXMAO job is failing with msgMCH0601 From Program : bzeroeao_Pulsar To module AMQRFXCA_R To procedure rfxAddCLQMGR Statement 43 Message Space offset X00000000 or teraspace offset X0000008088808923 is outside |
| Problem Summary | Sometimes during the migration of cluster from MQSeries V5.2 to WebSphere MQ V5.3, MQCD fails to migrate properly during startup. This results in STRMQM failing with the generation of MCH0601. |
| Problem Conclusion | Put back the FDC with probe ZX054040, which was removed by fix pack 10. Changes done under this fix ensure that the queue manager will start smoothly even when an MQCD is found to be invalid but it will create an FDC with probe ZX054040 to inform that MQCD migration is incomplete. If such FDC is reported for any cluster migration then try circumventing problem using REFRESH ( this should be done under expert supervision ). |
SE21231
|
| Abstract | MQM400 AGENT JOBS ARE NOT BEING ENDED AFTER FDC PROBE ZL000028 HAS BEEN LOGGED |
| Users Affected | All WebSphere MQ users with a QMgr running under stress, which has threaded applications ending abruptly without doing MQ disconnect. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | The cause of the problem whereby Agent jobs are not being ended after logging FDC with probe ZL000028. The problem is that after zlaMQGET returned lrcE_CONNECTION_BROKEN (indicating that the application at the other end of the pipe had been terminated) the Agent thread should not have called zcpSendOnPipe ... because the xcsPostEventSem will wait indefinitely. |
| Problem Summary | The MQ Agent process, when handling MQI, SPI or XA requests, and after detecting an MQRC_CONNECTION_BROKEN situation, will hang in xcsPostEventSem (inside zcpSendOnPipe) trying to send back a reply to an application which no longer exists at the other end of the IPCC pipe. |
| Problem Conclusion | The problem has been fixed. The MQ Agent process will explicitly test for MQRC_CONNECTION_BROKEN, and will set the zlaSTATE_THREAD_ENDING flag instead of sending its reply down the IPCC pipe. The fix will be shipped in WebSphere MQ v5.3 Fix Pack 12. |
SE21176
|
| Abstract | MQM400 WRKMQM GENERATES MSGMCH6902 AND MSGCZM1212 WHEN MORE THAN NINE QUEUE MANAGERS TO BE DISPLAYED |
| Users Affected | All users of the WRKMQM command with WebSphere MQ v5.3 for iSeries or WebSphere MQ v6.0 for iSeries. Platforms affected: iSeries |
| Error Description | Message MCH6902 and CZM1212 are issued for command WRKMQM, when more than nine queue managers are displayed. Message do not prevent WMQ from functioning properly. Joblog: Message ID . . . . . . : MCH6902 Severity . . . . . . . : 40 Message type . . . . . : Escape Date sent . . . . . . : 07/13/05 Time sent . . . . . . : 15:11:30 Message . . . . : The requested heap space operation is invalid. Cause . . . . . : The requested heap space operation is invalid. The heap space identifier is 0. The activation group mark is 19. The activation group mark will be zero if the heap space is not associated with an activation group. The error type is 2. The error type indicating why the heap space request is invalid is ' defined as follows: 0001-Attempt to destroy the default heap space; 0002-Attempt to free or reallocate heap space storage that is not allocated: The heap space identifier and activation group mark may not be valid for this error type; 0003-Access to the heap space is not allowed; 0004-Attempt to mark a heap space that cannot be marked; Message ID . . . . . . : C2M1212 Severity . . . . . . . : 30 Message type . . . . . : Diagnostic Date sent . . . . . . : 07/13/05 Time sent . . . . . . : 15:11:30 Message . . . . : The pointer parameter passed to free or realloc is not valid. Cause . . . . . : The pointer parameter passed to free or realloc was not valid. This caused your function call to fail. Recovery . . . : Correct the invalid pointer parameter being passed to free or realloc. Technical Description: The value of the pointer passed to free or realloc is X'8000000000000000E7E5B3B363002280'. LOCAL FIX: Issue does not prevent WMQ from functioning properly. |
| Problem Summary | The problem was caused by copying too many characters into structure (StatusArray[NumOfQmgrs]).QMgrName |
| Problem Conclusion | The problem has been fixed by limiting the copy operation to the maximum length of a Queue Manager name (48 characters). The fix will be shipped in WebSphere MQ v5.3 Fix Pack 12 and WebSphere MQ v6.0 refresh pack 6.0.1.0. |
SE21113
|
| Abstract | BROWSING MESSAGE USING WRKMQMMSG ON LOCAL QUEUE, IF F11 PRESSED FOR ALTERNATIVE VIEW, THE LOCAL DATE COLUMN VALUES ARE CORRUPT. |
| Users Affected | All users using WRKMQMMSG and pressing F11 to change view get corrupted Local Date when there is a difference between Local time and GMT set by the system value QTIMZON. Platforms affected: iSeries |
| Error Description | While browsing message using WRKMQMMSG on a local queue if F11 is pressed to bring up the alternative view, the Local Date column shows corrupted values. WRKMQMMSG QNAME(SYSTEM.AUTH.DATA.QUEUE) MQMNAME(AS01) command results in the following output. Work with MQ Messages Queue Manager Name . . : AS01 Queue name . . . . . . . SYSTEM.AUTH.DATA.QUEUE Type options, press Enter. 4=Delete 5=Display Description 8=Display Data GMT GMT Opt Date Time Type UserId Format Size 20050726 05271126 DATAGRAM QMQM 88 20050726 05271135 DATAGRAM QMQM 88 20050726 05271135 DATAGRAM QMQM 4 20050726 05271181 DATAGRAM QMQM 108 20050726 05271182 DATAGRAM QMQM 108 On pressing F11=Change view on the above display panel we get Work with MQ Messages Queue Manager Name . . : AS01 Queue name . . . . . . . SYSTEM.AUTH.DATA.QUEUE Type options, press Enter. 4=Delete 5=Display Description 8=Display Data Local Local Opt Date Time Type UserId Format Size 20050726 10571126 DATAGRAM QMQM 88 20050735 10571135 DATAGRAM QMQM 88 20050735 10571135 DATAGRAM QMQM 4 20050781 10571181 DATAGRAM QMQM 108 20050782 10571182 DATAGRAM QMQM 108 The day component in the Local Date column is corrupted. |
| Problem Summary | There was a problem in date conversion from GMT to Local Date due to insufficient buffer space to return YYYYmmdd which left the buffer in an indeterminate state. The problem is evident when there is a difference between Local time and GMT. This is set by the system value QTIMZON. Also some code optimization is carried out. |
| Problem Conclusion | Changes are carried out in the Command Processing Program (CPP) for WRKMQMMSG command. The function that converts GMT to Local Date is modified and optimized. |
SE20876
|
| Abstract | MQM400 - REPLACE ABORT WITH AN FDC WHEN PCTL CORRUPTION IS DETECTED |
| Users Affected | All Users of MQ across all UNIX platforms. Platforms affected: iSeries,All Unix |
| Error Description | WAS AppServer server went down. There were no FDCs. Joblog contained ... C2M1601 Escape 30 05/06/15 19:45:02 QC2UTIL1 QSYS *STMT From module . . . . . : QC2SIGNL From procedure . . . : raise Statement . . . . . . : 1125 To module . . . . . . : AMQXTHMX_R To procedure . . . . : destroy_thread Statement . . . . . . : 76 *PRCLT Thread . . . : 00000012 Message . . . : Signal SIGABRT (abnormal termination). |
| Problem Summary | The C2M1601 at statement 76 maps into the way we exit from MQ function destroy_thread (an exit which is automatically invoked when a thread is destroyed). Normal exit = return, otherwise ... /*************************************************************/ /* We cannot safely free the thread because it was not freed */ /* from the thread chain because the eyecatcher was invalid. */ /* So we'll add the thread control block to a 'corrupted' */ /* chain for later analysis */ /*************************************************************/ xtr_text("Destroy Thread detected corrupted thread control block"); ... abort(); |
| Problem Conclusion | When a thread is destroyed and a corrupted thread block is detected, an FDC with Probe Id XCnnn225 will be logged, and then thread termination will continue without being aborted. |
SE20597
|
| Abstract | MQM400 RPG FILE QMQM/QRPGLESRC(CMQCIHG) CORRUPTED IN MQ V5.3 |
| Users Affected | All programs using QMQM/QRPGLESRC(CMQCIHG) header file. Platforms affected: iSeries |
| Error Description | Complilation of RPG(CICS) program fails with Form-Type entry for main procedure not valid or out of sequence. |
| Problem Summary | The customer is receiving errors while trying to use the QMQM/QRPGLESRC(CMQCIHG) file in their applications. The file contains two extra spaces at the start of the first line. |
| Problem Conclusion | Spaces in the beginning of QMQM/QRPGLESRC(CMQCIHG) file are removed. |
IY78429
|
| Abstract | CHANNEL PROCESS (AMQRMPPA) MAY FAIL DUE TO BAD DATA FROM PRE-CSD10 JAVA CLIENT |
| Users Affected | Users of JMS clients are recommended to apply a fix for this APAR, or to apply at least CSD10 at the client end, to eliminate what may be a highly intermittent failure at the server end. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | WMQ 5.3 GA through to CSD09 Java JMS clients may send bad data to a WMQ queue manager. This was corrected by Java APAR IY67371 at CSD10 level. This bad data may cause failure of an amqrmppa (channel pooling) process. The process may lockup (hang), report FDCs, exit prematurely, or fail in other ways. Some FDCs that could be produced from amqrmppa are: probes XC006001, XC130003 and CO400001. The failure scenario is dependent on the size of messages requested by the client, together with the size of messages available to be sent back to the client. The problem occurs at sizes within 512 bytes of 4k multiples, starting with sizes greater than 32k. |
| Problem Summary | Insufficient checking of data sent from JMS clients, coupled with this data not being correct in every aspect. |
| Problem Conclusion | Added additional server checks to avoid corruption: if the server is sent inconsistent data it will report a protocol error FDC (probe RM046004 or RM046005) and close the channel. However, in order to avoid causing problems for existing systems which may have been working successfully and not actually failing, an additional change has been introduced to compensate for the bad information from the Java client. Thus, in practice, the overall effect of this APAR should be to allow existing Java clients at whatever level, to communicate with the server, without causing corruption. Thus, the new probe RM046004 and RM046005 FDCs are not expected to be seen. |
IY77854
|
| Abstract | NON-DURABLE SUBSCRIPTION MESSAGES NOT GETTING CLEANED ON Z/OS QUEUE MANAGER (OR WHEN SUBSTORE = QUEUE IS USED). |
| Users Affected | When Pub/Sub JMS Applications uses z/OS Queue Manager. or when SUBSTORE=QUEUE is used in TopicConnectionFactory Platforms affected: z/OS OS390 |
| Error Description | For Pub/Sub functionality if we are using z/OS Queue Manager and when the Broker is very busy and lot of Non-Durable Subscriptions are continuously created and closed, we have seen that some messages may be leftover in ND subscriber queue. These messages are not getting removed by in-built JMS cleanup mechanism. |
| Problem Summary | The deregister command was sent to Broker for deleting the Non-Durable subscription when the Subscription.close() method was called. The broker takes some time to process this request and we where not waiting for the command completion status. This causes some messages to be left on the ND subscription queues. |
| Problem Conclusion | Modified the QueueSubscriptionEngine to wait for DEREGISTER command completion status. |
IY77769
|
| Abstract | MESSAGES REMAIN ON THE SYSTEM.CLUSTER.TRANSMIT.QUEUE AFTER THE CHANNEL IS SUPPRESSED BY A CHADEXIT. |
| Users Affected | Cluster users with channel definition exits capable of suppressing a channel start. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | If the start of a cluster channel with a channel definition exit is suppressed the messages on the transmission queue are not reallocated to alternative destinations in the cluster. |
| Problem Summary | The transmission queue is not open when the reallocation of messages is attempted, so no messages can be read from it. |
| Problem Conclusion | Open the transmission queue if it is not already open. |
IY77233
|
| Abstract | OBJECT CATALOG CORRUPTION DURING RESOURCE EXHAUSTION |
| Users Affected | Users experiencing file descriptor or disk resource problems. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | The queue manager object catalog can become corrupted if an attempt is made to define a new object (e.g. a dynamic queue) in the following situations: a WMQ agent process, or the system as a whole, has run out of file descriptors; or if the queue manager is unable to write data to disk due to disk space or quota exhaustion. The corruption affects the first entry of the object catalog, which is normally the entry for the queue manager object. The corruption overwrites this entry with the entry for the new object. The effect of this corruption is that the queue manager is unable to be restarted. At restart, a probe KN002003 FDC is dumped in function kpiStartup with a major error code of arcE_FILE_ERROR. If multiple new objects are attempted to be defined during resource exhaustion, then the object catalog entries for these each overwrite the location of the queue manager object entry in turn. It may be possible for IBM L2/L3 Service to recover the object catalog to a working state, probably well enough to restart the queue manager, and possibly well enough to continue working with that queue manager in the long term. Along with all FDCs etc., the /qmanager/QMQMOBJCAT file must be supplied to Service for examination to verify that the corruption affects just the first entry of the catalog. This entry can then be patched to set it up to be a valid queue manager object entry. This should allow the queue manager to restart, but the entries that overwrote the first entry will be lost. However, it is quite possible that these lost entries are inconsequential, e.g. if they represented temporary dynamic queues, which are eliminate by queue manager recycling anyway. |
| Problem Summary | A failure to allocate an entry in the object catalog due to a resource problem, correctly generated an internal error code. Unfortunately, that return code was lost prior to writing the details of the entry to the catalog. The fact that the entry failed to be allocated, meant that it had a default entry index of zero - which is the entry index of the queue manager object. Hence, that entry was overwritten. |
| Problem Conclusion | Ensured any failure to allocate an entry in the object catalog is fully propagated and acted upon. Also added a new AO063006 FDC from function aocLoadCatalogue, to report a failure to find the queue manager object in the object catalog, because it isn't at all obvious what the problem is from a probe KN002003 FDC. This new FDC includes the comment: "Queue Manager object missing or damaged". |
IY77059
|
| Abstract | PROBE ID'S MQ000010 AND XY180010 FOLLOWING APPLICATION OF IY74420. |
| Users Affected | User's who have applied IY74420. Platforms affected: Solaris |
| Error Description | The fix to IY74420 introduced a problem whereby when a session using a shared hConn (MQCNO_HANDLE_SHARE_*) disconnected then locks belonging to the base thread were released on behalf of the shared thread being destroyed. When the base thread subsequently attempted to release the locks then FDC's are generated as the thread attempting to release the lock is not the lock owner. |
| Problem Summary | When a shared hConn is disconnected then a lock is being acquired under the shared xihThread and released under the base xihThread. The fix for IY74420 did not allow for locks being acquired under one xihThread and released under another xihThread. |
| Problem Conclusion | When a shared hConn disconnects then locks associated with the OS thread performing the MQDISC are not released. |
IY76845
|
| Abstract | FAILURE TO PERFORM DATA CONVERSION OF AN MQRFH2 WHICH CONTAINS NAMEVALUEDATA WHICH IS NOT ALIGNED ON A 4 BYTE BOUNDARY. |
| Users Affected | Customers with IY65033 applied (5.3 CSD10) who are converting MQRFH2's that contain unaligned NameValueData/NameValueLength fields. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | Probe Id VP0290041 from vwb_rf_header_2. |
| Problem Summary | The APRM states that the NameValueLength's in an MQRFH2 should be multiples of 4. IY65033 added a check on this field to the data conversion code that caused data conversion to fail if this was not the case. Prior to this change then data conversion of unaligned data would succeed on platforms without strong alignment requirements (i.e not HPUX or Solaris). |
| Problem Conclusion | The data conversion code has been modified not to require the NameValueLength's to be multiples of 4, and the check added in IY65033 has been removed. |
IY76799
|
| Abstract | FAILED CALL TO GETPEERNAME LEAKS FILE DESCRIPTOR IN AMQRMPPA |
| Users Affected | Users experiencing multiple failures of the getpeername function, reported by way of AMQ9213 WMQ error messages to the queue manager error logs. One file descriptor is leaked for each reported failure from the same amqrmppa process. The failure of the getpeername call would be due to causes external to WMQ. This problem could also cause the WMQ listener process (runmqlsr) itself to run out of file descriptors, if there is no queue manager running, and lots of connections come in, whilst these connections fail with getpeername problems. Platforms affected: All Unix |
| Error Description | WMQ amqrmppa (channel) process will leak a file descriptor in the rare circumstance that a call to the getpeername function fails. Such a failed call is reported in the WMQ error logs for the queue manager by way of an AMQ9213 message reporting that the getpeername call has failed. |
| Problem Summary | Failure to close the connection socket if very early failures occur in the connection process. |
| Problem Conclusion | Ensured the standard internal conversation freeing mechanism is employed by the channel process, especially for early failures of a connection. |
IY76712
|
| Abstract | UNPREDICTABLE RESULTS WHEN THE TOPIC ASSOCIATED WITH A DURABLE SUBSCRIPTION CHANGES WHEN USING THE MQ BROKER. |
| Users Affected | Customers using JMS with durable subscriptions and moving those durable subscriptions from one topic to another. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | It is difficult to spot a duplicate of this problem from the MQ diagnostics as the problem causes memory overwrites and inconsistent results. In the case of PMR 78503,442,000 then this error was accompanied by probe PU278030. |
| Problem Summary | The cause of the problem is that when a durable subscription changes from one topic to another then the subscription is not properly removed from the initial topic, leaving a reference to a potentially invalid subscription. When a durable subscription to TopicX is move to TopicY then a control block representing the subscription should be unchained from TopicX and chained to TopicY. Because the change is recoverable then this needs to be done in such a way that if the change should subsequently fail (for example if a response could not be sent to the request) then the update can be undone. The implementation of this change did not fully remove the reference to the subscription from TopicX and this lead to the chain of subscriptions becoming invalid. |
| Problem Conclusion | The subscription block is now only ever associated with either the initial topic, or the new topic. |
IY76314
|
| Abstract | XA CLIENT ENDING ABRUPTLY LEAVES OUTSTANDING UNITS OF WORK LOCKED UNTIL THEY SPAN THE ACTIVE LOG, WHEN THEY ARE BACKED OUT. |
| Users Affected | Customers using the XA client. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | When an MQ Series XA client ends abruptly with an outstanding unit of work then the updates in the unit of work remain in a locked state until the unit of work spans the active log at which point they are backed out. The client proxy issues an xa_end() on behalf of a failing client but attempts to rollback the UOW using MQBACK. An XA coordinated UOW cannot be rolled back using MQBACK (or committed using MQCMIT) and once the UOW is disassociated from the connection (xa_end) then subsequent disconnection of that session does not result in the UOW being backed out. |
| Problem Summary | The xa_end issued from rriReleaseQMResources specifies TMNOFLAGS indicating that this is a normal xa_end(). This request should have specified TMFAIL indicating that the UOW should be marked for rollback only. |
| Problem Conclusion | XA clients that end with an associated UOW will have an implicit xa_end with TMFAIL issued on their behalf. |
IY76101
|
| Abstract | SIGSEGV IN AMQFCXBA AFTER MQRFH2 MESSAGE SENT TO SYSTEM.BROKER.CONTROL.QUEUE |
| Users Affected | Users sending invalid format messages to the WebSphere MQ publish/subscribe broker on queue managers with no dead letter queue defined. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | When an invalid format message is sent to the WebSphere MQ publish/subscribe broker (a.k.a MA0C) on a queue manager with no dead letter queue defined then the amqfcxba process suffers a SIGSEGV. Note that the WebSphere MQ publish/subscribe broker only supports PCF and RFH V1 messages (RFH2 is not supported by this broker). |
| Problem Summary | An application sent an RFH2 message to the MA0C broker. There was no dead letter queue defined and as a last resort the broker tried to send a negative reply to the message. The broker does not include support for RFH2 and due to a logic error in the error handling attempted to handle the message as if it were a PCF message, this eventually resulted in a SIGSEGV. |
| Problem Conclusion | The error handling has been corrected so that WMQ does not attempt to reply to messages sent as any format other than RFH V1 or PCF. The effect of this is that if an invalid message is sent to the broker and the message cannot be DLQ'd (or discarded) then the undeliverable stream will go into a retry loop. This could prevent further messages destined for this stream from being processed. |
IY76063
|
| Abstract | CHANNELS IN STOPPING/BINDING STATE WHICH CANNOT BE STOPPED USING STOP CHL(CHLNAME) MODE(FORCE) |
| Users Affected | This issue may affect customers using channels which reside within a channel pooling process. This includes RCVR/CLUSRCVR channels where the runmqlsr listener is used (not inetd). This also includes CLUSSDR channels. This issue is only likely to be observed when AdoptNewMCA has been enabled in the qm.ini of a queue manager, or if STOP CHL(CHLNAME) MODE(TERMINATE) has been recently used upon a channel. Network problems, affecting the time taken to complete DNS lookups, are also likely to contribute to this issue. Platforms affected: All Unix,Windows |
| Error Description | One or more channels are shown, in a DISPLAY CHSTATUS listing, with STATUS(STOPPING) or STATUS(BINDING). It is likely that a group of channels would be affected, rather than a single channel. This status persists indefinitely. Attempts to forcefully stop the channels does not change the status, and hence restarting the channels is not possible. e.g. the below command does not affect the status of the channel: STOP CHANNEL(CHLNAME) MODE(FORCE) |
| Problem Summary | Each channel pooling process (amqrmppa) has some internal locking which protects certain operations. If a single channel (thread within that amqrmppa) were to terminate in a time window where a lock is held, then that lock could remain held indefinitely. A large time window is exposed if large network delays are experienced when performing DNS lookups. Other channels within that process could then become stuck in STOPPING or BINDING status indefinitely, waiting for a lock. Termination of a channel thread can occur as a user action, using STOP CHL MODE(TERMINATE), or through MCA adoption, enabled by AdoptNewMCA. |
| Problem Conclusion | This APAR changes the internal locking of the channel pooling process; to reduce the number of circumstances where a channel can be terminated while holding a lock, and hence affect the ability of other channels to start or stop. A related APAR, IY74420, enhances the ability of WebSphere MQ to recover a lock if a channel thread is terminated while holding it. Note: If this problem is observed then restarting the queue manager, and all running listeners, should resolve the issue. For a running queue manager, issuing STOP CHL(CHNAME) MODE(TERMINATE) commands against individual channels may allow them to restart (as they may restart in a different channel pooling process). |
IY75854
|
| Abstract | PUBLISHING APPLICATIONS ARE DELAYED BY UP TO 60 SECONDS WHEN PUBLISHING. ERROR 2033 MSG_NOT_AVAILABLE RETURN CODE IS SEEN. |
| Users Affected | WebSphere MQ Clients publishing messages to an WMQ broker with PubAckInt set. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | If the publishing application experiences delays and is using PubAckInt flag which is set to 25 by default then the customer is hitting this scenario. The delay of a publisher publishing a message is tied in with when a publish with acknowledge request is made. |
| Problem Summary | This is caused because when a Publishing client requests for an acknowledgement it has to go through a get with wait cycle which involves an additional Broker Response Timeout which is set to two minutes. Acknowledgement messages can either have been cleaned up by or the broker may have been too busy to respond. In this case the publisher has to wait for the get to complete which will wait for the Broker Response Timeout (time) to elapse completely before returning with a 2033 MSG_NOT_AVAILABLE message. This message is ignored by the JMS layer. |
| Problem Conclusion | The 2033 message is ignored by the JMS layer as the possibility of 1. The message already being cleaned up OR 2. Broker not responding due to heavy load is factored as not being severe enough to throw an exception. Hence we have exposed the Broker Response Timeout value to the user so that they can modify the time and reduce the wait cycle their applications go through in case any of the above two conditions have caused the acknowledgement message not to be on the queue. To use the broker response tuning property the publisher application should be started as follows: Java -Dcom.ibm.mq.jms.tuning.brokerResponseTimeout=Milliseconds> MyPublisherApplication The DEFAULT value is 2 minutes OR 120000 Milliseconds |
IY75657
|
| Abstract | CLUSTER RECEIVER CHANNELS DO NOT WORK WITH MESSAGE RETRY EXITS |
| Users Affected | Users specifying a message retry exit for a CLUSRCVR channel. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | A message retry exit configured for a CLUSRCVR channel is not invoked. |
| Problem Summary | The message retry exit was inadvertently not configured to apply to CLUSRCVR channel types. |
| Problem Conclusion | Ensured that message retry exits are configured to apply to CLUSRCVR channel types. |
IY75589
|
| Abstract | MQJMS1061: UNABLE TO DESERIALIZE OBJECT MESSAGE DUE TO JAVA.LANG.CLASSNOTFOUNDEXCEPTION WHEN USING WEBSPHERE MQ |
| Users Affected | This problem affects customers who use the Java Message Service (JMS) functionality provided with WebSphere MQ Version 5.3 and 6.0. Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java |
| Error Description | When attempting to get a JMS Object Message using WebSphere MQ, the JMS client application receives the following error: MQJMS1061: Unable to deserialize object message due to java.lang.ClassNotFoundException |
| Problem Summary | This problem was caused by the way the MQObjectInputStream class implemented the standard Java method resolveClass(). Previously, the method made the following calls: - Call loadClass() using the MQObjectInputStream's class loader. - Call Class.forName() using the default class loader. However, in certain circumstances, this sequence of calls does not work, resulting in the ClassNotFoundException. |
| Problem Conclusion | Following recommendations from the Java Technology Center, the resolveClass() method was changed to adopt the following mechanism for locating classes: - Call Class.forName() using the MQOjbectInputStream's class loader. - Call Class.forName() using the default class loader. - Call loadClass() using the MQObjectInputStream's class loader. The Java Technology Center recommend that all customer implementations of resolveClass() adopt this method of locating classes. |
IY75467
|
| Abstract | WMQ BROKER DIES WITH PROBE XC130003 FDC IN FUNCTION FAIADDERRORTAG |
| Users Affected | Users running a detailed trace of the WMQ Broker. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | WMQ Broker dies with probe XC130003 FDC in function faiAddErrorTag. This only occurs during detailed tracing. This problem does not occur under default level tracing, or when trace is off. |
| Problem Summary | Problem with writing detailed trace information on entry to the WMQ broker function faiAddErrorTag. |
| Problem Conclusion | Corrected the detailed trace information writing in function faiAddErrorTag. |
IY75252
|
| Abstract | MQ COMMANDS FAIL IF THE MQ FILES PATH IS SPECIFIED AT THE END OF THE PATH STRING AND IS NOT TERMINATED WITH A COLON (:). |
| Users Affected | WebSphere MQ V5.3 and V6.0 users running MQ commands. Platforms affected: AIX,Linux,Linux zSeries,Linux/390 |
| Error Description | This is a rare problem and if the MQ directory paths are specified at end of the PATH or env without a : the MQ commands might fail as the complete path might not be read. |
| Problem Summary | We were not updating the string length of the last portion of the PATH env variable. If the length of the previous string was less than the current string then the path will get truncated. |
| Problem Conclusion | The fix updates the correct string length of the path string even if it is not terminated with :. |
IY74915
|
| Abstract | PERFORMANCE IMPACT ON AIX WHEN AN API EXIT IS INVOKED |
| Users Affected | Users making much use of API Exits on AIX, e.g. users of external monitoring software such as BMC Patrol which utilise API Exits as part of the monitoring function. Platforms affected: AIX |
| Error Description | Performance impact on AIX with API Exits installed. Most noticeable if the API Exit functions do little work. |
| Problem Summary | Unnecessary program name lookup, AIX-only, being performed in the wrapper code around each API Exit call. The program name lookup really only needs to be performed once, particularly since it is a relatively slow operation. |
| Problem Conclusion | Removed the unnecessary program name lookup. |
IY74818
|
| Abstract | WMQ NOT ROLLING BACK A TRANSACTION AFTER XA CALLS RETURN XAER_NOTA |
| Users Affected | In the unusual circumstance of an external RM returning XAER_NOTA from xa-prepare and then similarly from xa-end, then WMQ may unintentionally commit a transaction rather than rolling it back. This may affect at least SYBASE and Oracle users. Platforms affected: iSeries,All Unix,Windows |
| Error Description | If an external database (RM) returns XAER_NOTA from xa-prepare and then similarly from xa-end, it should cause WMQ to rollback. Unfortunately, it is getting treated as an XA_OK, which is likely to lead to WMQ committing the transaction. |
| Problem Summary | In the unusual circumstance of an external RM returning XAER_NOTA from xa-prepare and then similarly from xa-end, the WMQ intention was to handle these codes and cause a rollback of the affected transaction. Unfortunately the coded effect is likely to be that the transaction gets committed rather than rolled back. |
| Problem Conclusion | Corrected the WMQ handling of the XAER_NOTA return from xa-prepare and xa-end to ensure that the affected transaction is indeed rolled back in this circumstance. |
IY74802
|
| Abstract | PROBE XC015001 FDCS, XECS_E_BLOCK_ALREADY_FREE, FROM XCSFREEQUICKCELL |
| Users Affected | Users performing large quantities of WMQ connections and disconnections, in conjunction with some applications exiting without disconnecting. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | During Processing of messages, FDCs are created with the following information. LVLS :- 530.8 CSD08 Probe Id :- XC015001 Component :- xcsFreeQuickCell Program Name :- java Major Errorcode :- xecS_E_BLOCK_ALREADY_FREE MQM Function Stack zutReleaseSharedPCD xcsReleaseThread xcsTerminate xcsDisconnectSharedSubpool xcsFreeQuickCell xcsFFST |
| Problem Summary | The implementation of the fixes for IY60472/IY68509* did not completely fix this XC015001 form XCSFREEQUICKCELL. Whereas those fixes have improved the situation, they have not fixed it in every case. |
| Problem Conclusion | This difficult problem has hopefully now been fully resolved by a rework of the affected area to introduce extra locking to eliminate some obscure timing windows. |
IY74567
|
| Abstract | ALTDATE AND ALTTIME OF CLUSQMGR DISPLAYED TWICE ON WMQ5.3 |
| Users Affected | This is seen on all platforms on WMQ v5.3 ONLY. Not seen on v6.0. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | When we issue "dis clusqmgr(*) all" in runmqsc, the ALTDATE and ALTTIME is displayed twice. |
| Problem Summary | This is just the display problem and does not have any impact on WMQ operation. |
| Problem Conclusion | The fix in the APAR was to prevent the duplicate entry made. |
IY74420
|
| Abstract | MQ HANG FOLLOWING PTHREAD_CANCEL ON SOLARIS. XCSKILLTHREAD, XLSLOCKMUTEXFN MCATYPE(THREAD) |
| Users Affected | Any customer explicitly using pthread_cancel. Customers using STOP CHANNEL MODE(FORCE). Customers using ADOPTMCA. Platforms affected: Solaris |
| Error Description | The queue manager hangs, no related messages are issued. SIGUSR2 output will show all/many threads waiting in xcsRequestMutexSem but no long lock wait FDC's will be produced for the affected mutex. stackit (or similar) will show that the threads are waiting in mutex_lock. Note that threads waiting for an MQ mutex would normally be waiting in cond_timedwait(). |
| Problem Summary | Misunderstanding of the recovery semantics of mutices created with USYNC_PROCESS_ROBUST. |
| Problem Conclusion | Create a pthread cleanup handler to release locked mutices in the event of pthread_cancel(). |
IY74339
|
| Abstract | SIGBUS/SIGSEGV IN KQIINQUIREQUEUEHANDLESTATUS |
| Users Affected | Users performing frequent queue handle status information queries, either by way of the runmqsc command "dis qstatus(*) type (HANDLE)" or by way of PCF. This problem has particularly been noted when utilising the QPasa monitoring tool, which issues frequent such commands. Platforms affected: All Distributed |
| Error Description | SIGBUS/SIGSEGV in kqiInquireQueueHandleStatus |
| Problem Summary | The queue handle status query can be issued just as another thread is finally closing that queue. There is a small window within which the full mechanics of the query will be performed just at the point where there are no handles open on that queue. And, within that window there is a very small window within which the status information on that queue is not in a queriable state, resulting in a SIGBUS or SIGSEGV in the querying thread. |
| Problem Conclusion | Added a check to avoid attempting to access queue status information that is not in a queriable state. |
IY74175
|
| Abstract | XLSRELEASESOCKETMUTEX FDC WITH PROBE XY033001, NO SUCH FILE OR DIRECTORY. |
| Users Affected | Users on Linux platform who have many queue managers on a single system can see this FDC when the queue manager is restarted. Platforms affected: Linux |
| Error Description | On Linux, If there are multiple queue managers on a box which are created and restarted. Then the following FDCs are created. WebSphere MQ First Failure Product Long Name :- WebSphere MQ for Linux for Intel Probe Id :- XY033001 Application Name :- MQM Component :- xllReleaseSocketMutex Program Name :- MMA_Client ThreadingModel :- LinuxThreads LD_ASSUME_KERNEL :- 2.4.0 Major Errorcode :- xecF_E_UNEXPECTED_SYSTEM_RC Minor Errorcode :- OK Probe Type :- MSGAMQ6119 Probe Severity :- 2 Probe Description :- AMQ6119: An internal WebSphere MQ error has occurred ('2 - No such file or directory' from connect.) FDCSequenceNumber :- 0 Arith1 :- 2 2 Comment1 :- '2 - No such file or directory' from connect. --------------------------------------------------------------- MQM Function Stack ziiMQCONN ziiConnectToAgent zcpDetachPipe xcsReleaseMutexSem xllReleaseSocketMutex xcsFFST ... ... ---{ xcsReleaseMutexSem ----{ xllReleaseSocketMutex -----{ xllSpinLockRequest -----} xllSpinLockRequest rc=OK -----{ xcsBuildDumpPtr ------{ xcsGetMem ------} xcsGetMem rc=OK -----} xcsBuildDumpPtr rc=OK -----{ xcsStrerror -----} xcsStrerror rc=OK -----{ xcsFFST socket_address passed to connect 0xbfffc550 01002F76 61722F6D 716D2F71 6D677273 ../var/mqm/qmgrs 0xbfffc560 2F4D4346 37414C2F 40697063 632F7373 /MCF7AL/@ipcc/ss 0xbfffc570 656D2F73 6F636B65 742E3135 34332E31 em/socket.1543.1 |
| Problem Summary | The application thread creates a socket using path /var/mqm/qmgrs//@ipcc/ssem/socket.xxxxx.1 and uses it. Later when application needs to connect to a different queue manager, it does not create a new socket because its pCtl information still holds the details of the socket (unfortunately, now for the wrong queue manager). |
| Problem Conclusion | The problem is that the socket pCtl info is not being cleared during xcsTerminate. Basically we were not clearing out the cached socket mutex information when we are disconnecting from a subpool. |
IY74092
|
| Abstract | PARENT PUBLISH SUBSCRIBE BROKER ENDS ABRUPTLY WHEN A CHILD BROKER IS STARTED (FDC PROBE PU522010) |
| Users Affected | Customers using WebSphere MQ Publish/Subscribe brokers in a hierarchy, where an AIX parent broker is connected to a non-AIX child broker. Platforms affected: AIX |
| Error Description | When starting a child broker on a system which uses a different byte ordering from AIX, the AIX parent broker ends abruptly with probe ID PU522010. |
| Problem Summary | An AIX compiler optimisation defect means that some MQ code designed to perform byte swapping did not compile correctly. This meant that pub-sub inter-broker control messages sent between systems which use a different byte ordering were not correctly converted before processing. As a result, valid pub-sub control messages were wrongly interpreted as being corrupted. |
| Problem Conclusion | Disable the AIX optimiser for parts of the pub-sub library which use byte swapping. |
IY74045
|
| Abstract | RM409000 FFST FROM RRIWAITSECONDARY |
| Users Affected | Users with channels using pipelining, that is, the PipeLineLength attribute of the Channels stanza is set to 2, and with the MRRTY & MRTMR attributes of the receiver channel set to values such that uncorrected message delivery failures will result in retries over a period of time greater than 300 seconds. Platforms affected: All Distributed |
| Error Description | An FFST is produced with probe ID RM409000 from function rriWaitSecondary. Another FFST, probe ID RM409001, is produced on behalf of the secondary thread with the last function in the stack being cciTcpSend. Alternatively, an analysis of the stack in a channel which appears to have hung shows one thread waiting on a mutex, and the other thread in cciTcpSend -> send. |
| Problem Summary | If the receiver channel does many retries when writing a message to the destination queue, that is, if the MRRTY attribute of the channel is set to a high value, the sender channel may block sending data to the receiver because the TCP buffer is full. In that case, the other thread of the pipelined channel will either timeout its receive and produce the FFST, or also block causing the channel to hang. |
| Problem Conclusion | Time out the send of data across a channel if pipelining is in use. |
IY73941
|
| Abstract | QUEUE MANAGER RESTART FAILURE (LOOP) AFTER SYNCQ/CHANNEL DEFINITION FILE BECOME OUT OF SYNC. |
| Users Affected | Potentially any user using channels, in practise more likely to be users who have followed unsupported restart/restore procedures. Platforms affected: All Distributed |
| Error Description | When there is an inconsistency between the syncQ and the channel definition file then it is possible for queue manager restart to go into a loop. The amqzxma0 process goes into a loop repeatedly reading the same message from the syncQ. While this is a severe problem it should not happen in normal operation. There are no identified valid situations in which the syncQ and the channel definition file should become inconsistent. It would however be possible to get into this situation following 'operational' errors, such as the 'cold start procedure' or invalidly restoring an object from a backup. |
| Problem Summary | The queue manager finds a record in the syncQ for which there is no corresponding entry in the channel definition file. The queue manager error handling causes the browse of the syncQ to be restarted and the amqzxma0 process goes into a loop. |
| Problem Conclusion | Delete the offending message from the syncQ. |
IY73907
|
| Abstract | FDC WITH PROBE XC006001 FROM XCSFREEMEM FROM THE REPOSITORY MANAGER PROCESS. |
| Users Affected | Anyone adding a queue manager to a cluster repository. When looking through the cache for all queue managers with a particular CLUSRCVR channel name, and if the rfxQueryCLQMGR call returns more that 50 hits. This problem of incorrect heap buffer calculating will be encountered. Platforms affected: All Distributed |
| Error Description | FDC from xcsFreeMem with Probe XC006001 are fired and the amqrrmfa process dies. WebSphere MQ First Failure Symptom Report Date/Time :- Tuesday June 21 11:33:52 JST 2005 Probe Id :- XC006001 Component :- xcsFreeMem Program Name :- amqrrmfa Major Errorcode :- xecS_I_PRIVATE_MEMORY_ERROR Minor Errorcode :- OK Probe Type :- MSGAMQ6091 Arith1 :- 537560696 200a8678 Comment1 :- invalid head or tail tag MQM Function Stack rrmRepository rrmProcessMsg rrmChangeClqMgr rrmRecoClqMgr rrmGetCurClqMgr xcsFreeMem xcsFFST Head 200a8660 58535047 00000014 200a8670 000000B4 00000033 Tail 200a86a0 B4 304ACCD8 200a86b0 304AD5FC 304ADF20 304AE8 |
| Problem Summary | The problem happened when a queue manager was added to a cluster repository. A call is made to rfxQueryCLQMGR to query the queue managers in the cache. If we can't fit them on the stack then we get a bigger heap buffer and retry. In the current case we are incorrectly calculating the amount of memory to be allocated to the heap buffer. This is the reason we see the odd number of bytes being allocated and FDC fired with error PRIVATE_MEMORY_ERROR. The new heap size request should be (new size)*size of (pCluster_q_mgr) |
| Problem Conclusion | The xcsGetMem was called with incorrect size. We are calling the GetMem with the right size. |
IY73579
| Abstract | MQMESSAGE.RESIZEBUFFER(INT SIZE) VALUE IGNORED. |
| Users Affected | Any user of WebSphere MQ Classes for Java Platforms affected: All Distributed+Java |
| Error Description | When using resizeBuffer(int size) on the WMQ Java MQMessage, the value passed is ignored and a default value of 4K is used. |
| Problem Summary | resizeBuffer(size) allows the application to give the WMQ classes for Java a hint about the size of the buffer to use on a get(message, gmo). After CSD08, this hint was quietly ignored. |
| Problem Conclusion | The internal buffer is resized correctly if a hint has been provided. |
IY73548
|
| Abstract | MQ MAY WRITE A XC130003 FDC UNDER ZCPQUERYTERMINUS WHEN USING XA |
| Users Affected | Users with heavily loaded systems using XA. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | This problem is indicated by at least one FDC indicating protocol errors on an xa_close, followed by the FDC showing the SEGV from zcpQueryTerminus: WebSphere MQ First Failure Symptom Report ========================================= Product Long Name :- WebSphere MQ for AIX Probe Id :- XC130003 Application Name :- MQM Component :- xehExceptionHandler Program Name :- amqrmppa Major Errorcode :- STOP Minor Errorcode :- OK Probe Type :- HALT6109 Probe Severity :- 1 Probe Description :- AMQ6109: An internal WebSphere MQ error has occurred. FDCSequenceNumber :- 0 Arith1 :- 11 b Comment1 :- SIGSEGV MQM Function Stack ziiHealthThread zcpQueryTerminus xcsFFST |
| Problem Summary | There was a small timing window in which a piece of shared memory could be deleted before it was accessed as part of a cleanup of an agent thread. |
| Problem Conclusion | The timing window in which that error can occur has been removed. |
IY73543
|
| Abstract | PROBE XC307004 FDC FROM XLSREQUESTMUTEX (LINUX ONLY) |
| Users Affected | Very heavy Linux users only. The nature of the underlying problem is such that it is exceedingly unlikely to occur. Platforms affected: Linux |
| Error Description | From fix pack 9 on V5.3 or in version 6.0.0.0 of V6, a probe XC307004 FDC is a full indicator of this problem, and the queue manager will stop. Prior to fix pack 9 on V5.3, there could be an undetected underlying locking issue, of unknown consequences. However, the timing window for this problem is extremely small, and, in almost all cases if that window is encountered, there will be no adverse effect and indeed will self-correct. |
| Problem Summary | The probe XC307004 FDC is a new check introduced in fix pack 9 on V5.3 and in version 6.0.0.0 of V6. The check is entirely valid, and if a XC307004 FDC is written then it means that a genuine locking issue has been detected. The problem relates to the atomicity of a flag operation. |
| Problem Conclusion | Revised the locking implementation so that, as intended, the implicated flag operations are performed under lock and thus atomicity is not an issue for them. |
IY73202
|
| Abstract | SOFTWARE MAY GET PERMISSIONS FAILURE READING AMQCAP.INF FILE |
| Users Affected | Users of software, other than base WMQ, that tries to read amqcap.inf. This problem can be encountered by JMS users. Platforms affected: All Unix |
| Error Description | The amqcap.inf file, located in the @SYSTEM qmgr directory, is initially created with 600 permissions on UNIX (though these permission may be widened to 775 during a CSD install). These permissions are unduly restrictive and may cause inability of other software to read the value stored in this file. A possible error message may be: MQJE082 : File containing the license unit information could not be found - run setmqcap |
| Problem Summary | Unduly restrictive permissions set for create of amqcap.inf file (created when setmqcap is run). |
| Problem Conclusion | Create amqcap.inf file with 664 permissions on UNIX, not 600. It is ok to manually set 664 permissions for any existing occurrence of the amqcap.inf file, as a workaround for this problem. |
IY73062
|
| Abstract | SELECTOR IGNORED ON CONNECTIONCONSUMER |
| Users Affected | Any user of WebSphere MQ Classes for JMS and ASF Platforms affected: All Distributed+Java |
| Error Description | After a stop() and a close() of a ConnectionConsumer, messages could be incorrectly marked for delivery to the ConnectionBrowser. |
| Problem Summary | The count of selectors in use was decremented once too often. |
| Problem Conclusion | The count of selectors in use is now correctly calculated. |
IY72996
|
| Abstract | SIGSEGV IN XPPRUNDESTRUCTORS FOR CHANNEL USING SSL |
| Users Affected | Users of SSL where a channel SSL authorisation fails for some reason. Platforms affected: All Distributed |
| Error Description | SIGSEGV with xppRunDestructors on call stack, for a channel that is using SSL. You'll probably see the Thread id reported as 0. 90 seconds before the FDC is dumped, an error message will probably have been reported in the qmgr error logs for some kind of SLL problem, e.g. an expired certificate. |
| Problem Summary | The channel SSL initialisation involves connecting to the queue manager. If there is an SSL error, the thread remains corrected to ensure the error message, written later, goes to the queue manager error logs. However, the thread failed to mark itself as connected to the queue manager, so an automatic disconnect did not occur when the thread ended. When the thread eventually destroys itself after 90s, it attempts to run "thread destructors" for this residual queue manager connection. However, we do not expect to be connected at this point, and so the destructors are invalid and the likely result is a SIGSEGV in xppRunDestructors. |
| Problem Conclusion | Simply ensured that if the SSL initialisation remains connected to the qmgr, then it marks itself connected. This ensures that an automatic disconnection will occur at channel end. And so no thread destructors remain to be invoked when the thread destroys itself. |
IY72981
|
| Abstract | TRUNCATED WAS FDCS (PROBES ZF178* TO ZF216*) |
| Users Affected | Users of the queue manager side of the WebSphere Application Server MQ security bridge, if any FDCs are dumped due to problems such as TCP/IP issues. Platforms affected: All Distributed |
| Error Description | A number of WAS FDCs (probes ZF178* to ZF216*), e.g. ZF216110, are quite likely not to be dumped correctly. They may be truncated after dumping the traceback info, or they may dump garbled data dumps. A thread dumping one of these FDC may not recover from this problem, and indeed any intended recovery action following the dumping of one of these FDCs may be compromised. Recommendation is to recycle the queue manager if any of these FDCs are dumped, to limit any knock-on consequences. |
| Problem Summary | Mis-coded FDC dump requests. |
| Problem Conclusion | Corrected the FDC dump requests. |
IY72879
|
| Abstract | CONTINUOUS USE OF ONE MQQUEUEBROWSER FOR SEVERAL MQQUEUEENUMERATIONS USES TOO MUCH MEMORY. |
| Users Affected | All users of MQQueueBrowser (WMQ JMS) Platforms affected: All Distributed+Java |
| Error Description | The memory usage for the MQQueueBrowser increases even when all the messages have been browsed. |
| Problem Summary | MQQueueBrowser keeps track of all its MQQueueEnumerations to close the corresponding queue at close() time. However, MQQueueEnumeration may already have closed the queue if all its messages have been browsed. In this case, the reference need not be kept by the MQQueueBrowser. |
| Problem Conclusion | The reference is now removed from the list kept by the MQQueueBrowser. |
IY72844
|
| Abstract | QUEUE MANAGER CANNOT RESTART: FDC WITH PROBE ID HL083114. |
| Users Affected | Customers using externally co-ordinated XA transactions, particularly those using WebLogic (we saw this with WL v8.1.3). Platforms affected: All Distributed |
| Error Description | The error may occur after the failure of another queue manager process, such as an agent. Upon restarting the queue manager, an FDC with probe ID HL083114 is produced showing that the logger is trying to access a log record outside the active portion of the log (e.g. before the Head LSN). If dmpmqlog is used on the logs, you may see two rollback records for the same transaction. This is because an attempt has been made to roll back a transaction which had already been rolled back previously, corrupting the logs. |
| Problem Summary | After a failure, it is possible for a transaction to get into an indeterminate state. Depending on the sequence of calls issued by the transaction co-ordinator it is possible that a transaction which has already been rolled back may be rolled back again. This corrupts the logs and can prevent queue manager restart. |
| Problem Conclusion | Added an extra check to atxPerformRollback to prevent this occurring. In the event that this happens, an FDC with probe ID AT045003 will occur. |
IY72714
|
| Abstract | FAILURE OF LDAP SERVER PROVIDING O/S USER IDENTIFICATION DATA TO WMQ THROUGH THE GETGRENT INTERFACE OBSERVED ON SOLARIS |
| Users Affected | Customers using an LDAP server to provide user identification information to the Solaris operating system. Platforms affected: Solaris |
| Error Description | When using an LDAP server to provide user identification information on Solaris, startup of WMQ (specifically the sequence of setgrent/getgrent_r/endgrent calls made during startup of WMQ) may contribute to a failure within the O/S LDAP interface. |
| Problem Summary | The setgrent/getgrent/endgrent interface provided by the operating system has unexpected behaviour when endgrent is called out of sequence from setgrent/getgrent and an LDAP server is being used to provide the user information, although this is not a documented restriction of the interface. |
| Problem Conclusion | The WMQ code was changed to ensure a consistent and serialised set of setgrent/getgrent_r/endgrent calls are made in all circumstances. |
IY72519
|
| Abstract | AMQ9652 ERROR MESSAGE GENERATED INCORRECTLY WHEN THE CRYPTOGRAPHIC STORE / KEY REPOSITORY PASSWORD HAS EXPIRED. |
| Users Affected | Customers using SSL channels with WMQ V5.3 on the UNIX platforms, or WMQ V6.0 on the UNIX and Windows platforms, and having specified a password expiry interval when creating the key repository for a queue manager. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | A channel fails to start and the following error is shown in the queue manager error logs: AMQ9652: The remote SSL certificate has expired. EXPLANATION: The SSL certificate used by MQ on the remote end of the channel has expired. The channel is '????'; in some cases its name cannot be determined and so is shown as '????'. The channel did not start. ACTION: Use your key management tool to provide MQ with a current SSL certificate on the remote end of the channel. Restart the channel. However, the certificate used by WMQ at the remote end of the channel has not expired. |
| Problem Summary | The actual reason for the failure of the channel to start is that the password used to access the key repository for the local queue manager has expired. This can be confirmed by running the following command against the key repository for the local queue manager where the AMQ9652 message is observed (not the remote queue manager as described in the AMQ9652 message). It will fail with "The password has expired": gsk6cmd -cert -list -db .kdb -pw The command to reset this password is: gsk6cmd -keydb -db .kdb -changepw -pw -new_pw -stash This command required version 6.0.5.44 of GSKit or later. WebSphere MQ V6.0 is shipped with a version of GSKit which supports this command. For WebSphere MQ V5.3, this command may fail with: "The password has expired". An updated GSKit package, which supports this command, is shipped with fix pack 12 and later for WebSphere MQ V5.3. |
| Problem Conclusion | A new error message has been added to WebSphere MQ, which is output when a channel cannot start because the password used to access the key repository has expired: AMQ9770: The SSL key repository password has expired. EXPLANATION: The SSL key repository cannot be used because the password has expired. The channel is ''; in some cases its name cannot be determined and so is shown as '????'. The channel did not start. ACTION: Use your key management tool to reset the password of the SSL key repository, ensuring that a new password stash file is generated. |
IY72218
|
| Abstract | MQDISC FAILS WITH MQRC_HCONN_ERROR (2018 0X7E2) AND THE CICS APPLICATION RETURNS ABNORMAL TERMINATION U8035. |
| Users Affected | All the users using TXSeries 5.1( CICS V5.1.0.1), WMQ Extended Transactional Client, WMQ 5.3 , with TXSeries 5.1 is acting as a External Transaction coordinator and WMQ 5.3 acting as a Resource manager, and the CICS application using user exit 15 (UE014015) for Task termination. Platforms affected: iSeries,All Unix,Windows |
| Error Description | When the CICS Task termination user exit 15 (UE014015) is called by a CICS application, where TXSeries 5.1 is acting as a External Transaction Manager and a remote WMQ 5.3 queue manager is acting as a resource manager by way of WMQ Extended Transactional client, the MQDISC calls fails with MQRC_HCONN_ERROR (2018, 0X7E2) and the subsequent xa_close call fails with XAER_RMERR error. After which the CICS application terminates abnormally with abnormal termination U8035. |
| Problem Summary | When using the user exit 15, where TXSeries 5.1 was acting as an External Transaction Manger with the WMQ Extended Transactional client, during the function where we are disconnecting from the queue manager, we had a test missing to check if there were any valid MQ connections. The failure to test for any valid MQ connection caused the MQRC_HCONN_ERROR. |
| Problem Conclusion | A test was added to check for a flag when there was any real MQ connections. |
IC47804
|
| Abstract | MQ MSCS RESOURCE FAILS TO APPLY LOCAL MQM GROUP PERMISSIONS TO THE DIRS CONTAINING THE QUEUE MANAGER DATA EVEN AFTER IC43947 |
| Users Affected | All users in a Microsoft Cluster environment Platforms affected: Windows |
| Error Description | Probes AD034001 (adiDeleteDir) and Rc=5 (ACCESS DENIED) from RemoveDirectory, and possibly AD004001 (adhOpen) and adiOpenFile rc=arcE_LOCATION_INVALID received in an MSCS environment when a node swap has occurred. Objects subsequently flagged as damaged with a small possibility of the queue manager failing to start. Swapping back to the original node resolves the problem. |
| Problem Summary | When a resource comes on line in an MSCS environment, it should reapply security to all files and directories on the shared disk, however it failed to occur due to a parameter error in one of the calls. |
| Problem Conclusion | WebSphere MQ has been fixed so that the directory security of the queue managers data directory tree is correctly reapplied during the on line phase of an MSCS resource start. |
IC47481
|
| Abstract | MULTI-THREADED CLIENT RETURN MQRC_ALREADY_CONNECTED |
| Users Affected | Users who are using multi-thread clients to connect to the queue manager and not sharing the connection handles. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | A return code 2002 (MQRC_ALREADY_CONNECTED) occurs when a client thread is trying to connect to the queue manager. |
| Problem Summary | The error is caused by a memory leak in WebSphere MQ where it is not terminating the client thread properly. When a thread terminates, the memory block for the thread is not being destroyed on the remote client end. When a new thread starts up, it may get allocated to reuse this block, and therefore it finds a connection handle and thinks that it is already connected, hence the MQRC_ALREADY_CONNECTED error code. |
| Problem Conclusion | When a client thread is being terminated unexpectedly, hence not terminating by way of a MQDISC call, the client thread memory block will be destroyed. |
IC47447
|
| Abstract | MESSAGES NOT ACKNOWLEDGED WHEN USING CONNECTIONBROWSERS WITH AUTO_ACK OR DUPS_OK SESSIONS |
| Users Affected | JMS users of ConnectionBrowsers and AUTO_ACK or DUPS_OK Sessions Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | Messages are not acknowledged when using ConnectionBrowsers with AUTO_ACK or DUPS_OK Sessions. The code using the ConnectionBrowsers has no access to the acknowledgement methods. |
| Problem Summary | Due to the internal workings of the ConnectionBrowser no acknowledgement was being made internally, leaving it to the responsibility of the code using the ConnectionBrowser. However, due to checks in internal methods no acknowledgement could be called externally. |
| Problem Conclusion | Changes made to allow calls to Message.acknowledge() to proceed, if messages are retrieved by a call to consume(). |
IC47443
|
| Abstract | JMS MESSAGEPRODUCER MEMORY LEAK. |
| Users Affected | All JMS users of MessageProducers. Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java |
| Error Description | The symptoms are increasing memory usage, which could potentially cause performance problems or OutOfMemory errors. |
| Problem Summary | Entries were being made to messageProducers vector twice, but only being removed once, leading to a memory leak. |
| Problem Conclusion | The solution is to ensure the correct number of messageProducers are added to/removed from the messageProducers vector. |
IC47335
|
| Abstract | JMS CUMULATIVE INTERIM FIX FOR WEBSPHERE MQ V5.3 FIX PACK 11 |
| Users Affected | All users of JMS functions. Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java |
| Error Description | Cumulative fixes for the JMS functionality provided with WebSphere MQ V5.3 Fix pack 11. |
| Problem Summary | See conclusion. |
| Problem Conclusion | This cumulative fix includes fixes for APARs 95162 - JMS MessageProducer memory leak 96031 - Messages not acknowledged when using ConnectionBrowsers with AUTO_ACK or DUPS_OK Sessions. IY73579 - MQMessage.resizeBuffer(int size) value ignored The fix will be included in the following PTFs: V5.3 Platform Fixpack 12 -------- ---------- Windows U200242 AIX U803326 HP-UX (PA-RISC) U803577 Solaris (SPARC) U803579 iSeries TBD Linux (x86) U803580 Linux (zSeries) U803582 |
IC47332
|
| Abstract | MQ CLIENT AMQ9691 ERROR WHEN TRYING TO ADD A CERTIFICATE USING AMQMCERT -A WHEN THE CERTIFICATE IS ALREADY PRESENT IN THE STORE |
| Users Affected | Users of WebSphere MQ Client with SSL Platforms affected: Windows |
| Error Description | AMQ9691 error is reported on a WebSphere MQ client only installation while trying to add a certificate using amqmcert -a handle command, where the certificate with the specified handle is already present in the WebSphere MQ Client store (specified by MQSSLKEYR) |
| Problem Summary | AMQ9691 error occurs on MQ Client only installation while trying to add a certificate which is already present in the client store as the command tends to follow the server code path instead of the client code path resulting in a library load error. |
| Problem Conclusion | Though adding a certificate which is already present in the store would seem to be a user error, MQ should not be following the server code path in such a situation in a client-only installation. The problem has been fixed by incorporating the necessary code changes which allow the client code path to be followed in the reported problem scenario on an MQ client only installation. The fix ensures that the error message "Certificate already exists in the store" is issued instead of AMQ9691(library load error)error when users try to add an existing certificate to MQ Client store on a client only installation. |
IC47255.
| Abstract | WHEN MESSAGE SELECTOR IS USED WITH DURABLE SUBSCRIBER AND APPLICATION TERMINATES ABRUPTLY, THE MESSAGES ARE LOST. |
| Users Affected | Customers running JMS application which have durable subscriptions with message selectors. Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java |
| Error Description | When the subscriber application with message selector is started and the messages are published after setting the string for the message selector, everything works fine ( ie messages are received by subscribers ). If the subscriber is terminated abruptly and the messages are published later, these messages will be retained in durable subscriber queue. But when the subscriber is restarted all the messages retained in durable subscriber queue for that subscription are lost. |
| Problem Summary | When the durable subscriptions is created and application is terminated, the status of subscription in broker is retained as locked. When next time the application tries to create the durable subscription with same "subscription name" +"clientid" +"user name" combination, the JMS code does the unlocking of the subscription on the broker. To do that it tries to compare the existing subscription on the broker but it fails when it compares the "selector" because of the difference in format. |
| Problem Conclusion | Modified the code to change the format of selector to match the one available in broker. |
IC47236
|
| Abstract | MQRC_CONTEXT_HANDLE_ERROR (2097 ERROR)- WHEN PASS_ALL_CONTEXT OPTION IS USED WITH JAVA DISTRIBUTION LIST. |
| Users Affected | Customers using Java Distribution list to pass the Context information. Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java |
| Error Description | When PASS_ALL_CONTEXT or PASS_IDENTITY_CONTEXT options are used to send the context information of a message to the distribution list using Java, mqrc 2097 (MQRC_CONTEXT_HANDLE_ERROR) is reported. |
| Problem Summary | The context information is not passed to the underlying put call for the distribution list using Java. |
| Problem Conclusion | MQQueue put call was able to pass the context information to the queue, but the MQDistributionList put call could not pass the context information. Modifications were done to the MQDistributionList put call to pass the context information. After applying this fix, customer should be able to pass the context information to the distribution list. |
IC47224
|
| Abstract | MULTIPLE POOLSCAVENGER THREADS CREATED WHEN USING EITHER WEBSPHERE APPLICATION SERVER VERSION 5.X OR WEBSPHERE MQ. |
| Users Affected | This problem affects customers who use the Java Message Service (JMS) functionality provided with WebSphere Application Server Version 5.x and WebSphere MQ. Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java |
| Error Description | When running either a WebSphere MQ Java or JMS application that uses Connection Pooling, or using message-driven beans with WebSphere Application Server (WAS) Version 5.x, the number of com.ibm.mq.PoolScavenger threads increases over time. WAS customers will notice approximately one new thread appearing every 5 minutes. |
| Problem Summary | In certain situations, the QSimpleConnectionManager class will incorrectly create a new Pool Scavenger thread even though one already exists for that connection manager. Over time, this results in multiple Pool Scavenger threads being created and consuming resource. |
| Problem Conclusion | A check has been added to see if a Pool Scavenger thread already exists for a connection manager. If a thread does not exist, a new one is created. If a thread already exists, however, a new thread is not created. |
IC46987
|
| Abstract | COINITIALIZE FAILURE RPC_E_CHANGED_MODE (-2147417850) WITH MSCS |
| Users Affected | Customers running queue managers under Microsoft Cluster Server (MSCS) control on Windows platforms. Platforms affected: Windows |
| Error Description | Error code -2147417850 (RPC_E_CHANGED_MODE) is reported after an MSCS callback routine (for example, to bring a resource on-line) calls CoInitialize. |
| Problem Summary | The problem was caused as a result of attempting to perform a CoInitialise on the same thread as that of the MSCS callback thread, used for example, when bringing an 'IBM MQSeries MSCS' resource instance on-line or offline. This problem can occur regardless of whether the resource was running it its own resource monitor or not. |
| Problem Conclusion | The problem has been fixed by creating a separate worker thread for each defined IBM MQSeries MSCS resource. Each of these threads is then free to perform CoInitialize and CoUninitialize calls as required in order to communicate with the COM Objects, without attempting to change the threading model already associated with the callback thread. |
IC46955
|
| Abstract | VARIOUS SETMQSCP PROBLEMS |
| Users Affected | All users of WebSphere MQ and its Active Directory support for client channel tables Platforms affected: Windows |
| Error Description | This APAR addresses numerous SETMQSCP issues, including problems publishing channel tables that contain the SSLPEER attribute and also those that contain multiple authinfo entries. |
| Problem Summary | setmqscp and setmqcrl had various problems including - supporting multiple AUTHINFO's - displaying the SSL peer name - encrypting the LDAP userid and passwords in the AUTHINFO's - general lack of useful messages when operations performed - messages going to message log rather than console - supporting userids or passwords containing spaces - syntax checking of the command line flags |
| Problem Conclusion | Many changes have been made to the setmqscp and setmqcrl functionality which fix all the reported problems, as well as enhancing the usability with a number of new messages. Note for the CRL functionality to work with multiple AUTHINFO structures, it is necessary to delete and redefine the client channel table. This involves deleting the file, then redefining all CLNTCONN connections plus. |
IC46774
|
| Abstract | MMC SHOWS INCORRECT STATUS INFORMATION, OVERLAPPING/MULTIPLE AMQMSRVN PROCESSES |
| Users Affected | Windows customers running queue managers under the IBM MQSeries service. Platforms affected: Windows |
| Error Description | Users may see multiple amqmsrvn processes running on the system when there should only ever be one. These additional processes are not initialised correctly and are unable to communicate with queue managers correctly. Symptoms of this problem may include incorrect status information shown in the MMC consoles. |
| Problem Summary | The problem is caused when customers incorrectly configure the IBM MQSeries DCOM object to use the interactive user id. |
| Problem Conclusion | In order to inform customers that the MQSeries DCOM object has been incorrectly configured, an FFST is now produced. The comments added to the FFST are as follows "DCOM object configured with interactive/Launching user id" "Configure DCOM object to use specific user id" |
IC46766
|
| Abstract | PUTDATETIME PROPERTY IN 'MQMESSAGE' MQ .NET CLASS IS READ ONLY AND CANNOT BE ALTERED OR SET. |
| Users Affected | .Net applications trying to set the 'PutDateTime' property. Platforms affected: Windows |
| Error Description | After using the use MQPMO_SET_ALL_CONTEXT in an application, for example - putOptions.Options = MQC.MQPMO_SET_ALL_CONTEXT. If the application tries to 'set' the 'PutDateTime' (say, MQMessage.PutDateTime), it does not work as only the 'get' option was provided for the 'PutDateTime' property. |
| Problem Summary | Only the 'get' option was provided for the 'PutDateTime' property of the 'MQMessage' class. It was not possible to alter or set the 'PutDateTime' property. Hence, if the 'MQPMO_SET_ALL_CONTEXT' option was set while doing a MQPUT, we were unable to set the 'PutDateTime' which was a restriction. |
| Problem Conclusion | The source code (MQMessage.cs) file was altered appropriately to add the 'set' option to the 'PutDateTime' property. |
IC46684
|
| Abstract | CUSTOM SERVICE ENTRY DISPLAYS WRONG VALUE IN "EXECUTION" BOX ON WINDOWS CHINESE EDITION |
| Users Affected | All users of the MQ Services GUI using simplified Chinese. Platforms affected: Windows |
| Error Description | In WebSphere MQ v5.3 on Windows Chinese Edition, if using amqmdain to create a custom service entry the resulting service entry will be created correctly but when viewed in a MMC panel the execution box is backwards. It displays a "COMMAND" as a "PROCESS" and a "PROCESS" as a COMMAND". The service entries themselves are of the correct type, the display boxes are just displayed with the wrong names. For example, if you used amqmdain commands to create a service entry and defined it as a COMMAND, the entry would be created as a COMMAND. However, if you view the entry using the MMC GUI display it will show up as a PROCESS. This has only been seen on Windows Chinese edition. |
| Problem Summary | When defining a custom service in the MQ Services GUI, in simplified Chinese the execution type selection combo box contains the values in the wrong order (they should be the translated form of COMMAND and then PROCESS). This is because the combo box is defined to sort its contents but MQ assumes the first one is command and the second is process, but when the translations are sorted this may not be the case. |
| Problem Conclusion | The MQ Services GUI has been modified to not sort the execution combo box in the properties of defining a custom service. |
IC46653
|
| Abstract | MQQUEUEMANAGER CONSTRUCTOR DOES A CONNECT TO THE QM, BUT IT DOES NOT CHECK TO SEE IF IT IS CONNECTED ALREADY BEFORE RECONNECTING. |
| Users Affected | All users of WebSphere MQ and the .NET (dotnet) interface Platforms affected: Windows |
| Error Description | The issue is that an MQQueueManager constructor does (and is documented as doing!) a connect to the queue manager. However, if you subsequently call connect on that MQQueueManager object, it does not check to see if it is connected, and instead redoes the connection. This new connection overwrites the old one and the .NET interface no longer knows about the original one. |
| Problem Summary | Calling the MQQueueManager connect method can result in leaked agent and channel threads, because the constructor for the MQQueueManager object already creates a connection. |
| Problem Conclusion | The .NET MQQueueManager Connect method has been modified to throw an MQException of type MQCC_WARNING, MQRC_ALREADY_CONNECTED if called for an queue manager object which has a valid connection to the queue manager already. |
IC46548
|
| Abstract | MQRC_OPTIONS_ERROR IS RETURNED IF QPMO_ALTERNATE_USER_AUTHORITY IS SPECIFIED WITH MQQUEUEMANAGER.PUT() CALL. |
| Users Affected | WebSphere MQ V5.3 or V6.0 on Windows using .NET API calls Platforms affected: Windows |
| Error Description | In .NET environment, if a message needs to be put using alternate user authority, the MQQueueManager.Put() call should be used with MQPMO_ALTERNATE_USER_AUTHORITY. But this call is failing with MQRC_OPTIONS_ERROR when specify MQPMO_ALTERNATE_USER_AUTHORITY with put message options. |
| Problem Summary | The MQQueueManager.Put() should have similar functionality to a MQPUT1 call, but this call did not have an implementation of MQPUT1 call, but was opening the queue and performing an MQPUT. Hence, the alternate user authority was not supported with MQQueueManager.Put() call. Alternate user authority cannot be used with MQQueue.Put() as it implements the functionality similar to MQPUT. |
| Problem Conclusion | The .NET API call MQQueueManager.Put() is being modified to have the similar functionality of MQPUT1 call, so that the alternate user authority can be used with this call during a message put. |
IC46539
|
| Abstract | .NET DOTNET DYNAMIC QUEUE NAME MQRC_DYNAMIC_Q_NAME_ERROR 2011 ACCESSQUEUE |
| Users Affected | Users who are using WMQ classes for .NET to write .NET applications and would like to specify a Dynamic queue as a ReplyToQ when opening a model queue using the AccessQueue method in the MQQueueManager class. Platforms affected: Windows |
| Error Description | MQRC_DYNAMIC_Q_NAME_ERROR is produced when a DynamicQueueName is specified in the MQQueueManager.AccessQueue method that is less than 5 characters long in applications that are using WMQ classes for .NET. |
| Problem Summary | The DynamicQueueName field is being set to "AMQ.*" by default. The memory containing this string is being overwritten using the name supplied in the AccessQueue method in the MQQueueManager class. If the supplied DynamicQueueName is less than 5 characters, (e.g. "X*" contains only 2 characters), only the first few characters are being overwritten, and the rest of the string remains in the memory. (In the above example, the name becomes "X*Q.*"). This causes the MQRC_DYNAMIC_Q_NAME_ERROR return code. |
| Problem Conclusion | This APAR fixes the problem by ensuring that all characters in the DynamicQueueName field in the MQObjectDescriptor are now being overwritten instead of only the number of characters in the new value specified in the AccessQueue method. |
IC46530
|
| Abstract | AMQ2018 .NET MQBEGIN |
| Users Affected | Uses affected as those using transactional .NET applications. Users are affected if they use the default constructor for MQQueueManager objects. Platforms affected: Windows |
| Error Description | When a .NET application attempts to use MQBEGIN, AMQ2018 (MQRC_HCONN_ERROR) is received if the default constructor was used to instantiate the MQQueueManager object. |
| Problem Summary | The problem was caused by the incorrect connection options MQCNO_HANDLE_SHARE_BLOCK) being specified when the default constructor is used to instantiate an MQQueueManager object. Shared HCONNS are not permitted for transactions. |
| Problem Conclusion | The problem was fixed by specifying the correct connection options depending of the environment. Unless the environment is MTS, the default constructor, as in... mqQMgr = newMQQueueManager("QM1"); ... will specify that shared HCONNs (MQCNO_HANDLE_SHARE_BLOCK) can be used otherwise the connection will use MQCNO_HANDLE_SHARE_NO_BLOCK |
IC46433
|
| Abstract | MQ .NET CLASSES NEED +INQ AUTHORITY TO GET DYNAMIC QUEUE NAME |
| Users Affected | All users of WebSphere MQ .NET (dotnet) classes Platforms affected: Windows |
| Error Description | When a program opens a model queue in WebSphere MQ to create a dynamic queue, then name of the new dynamic queue is returned by the MQOPEN call. However, when an application using the MQ .NET classes tries to query the queue name, MQ is issuing an explicit MQINQ call to inquire the attribute and the user needs to have +inquire authority to succeed. MQ should save the dynamic queue name returned from MQOPEN to avoid having to call MQINQ. |
| Problem Summary | The .NET classes retrieve a queues real name by issuing a query for it, but the user may not be authorized to issue the query. This information is returned from the MQOPEN, and can instead be cached, avoiding the additional query call. |
| Problem Conclusion | Retrieving an MQQueue's name no longer results in an MQINQ (inquire) call being issued. |
IC46407
|
| Abstract | INCORRECT TRUNCATION OF QUEUE FILE DURING LOG FULL CAUSED A DAMAGED QUEUE |
| Users Affected | WebSphere MQ V5.3 or V6.0 users having large volume of messages. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
| Error Description | The following errors were reported in the error log during this time. AMQ7472: Object EHR.ODM.DATALOAD.INPUT.TEST, type queue damaged. AMQ7463: The log for queue manager QM_CRIRDS502 is full. AMQ7466: There is a problem with the size of the log file. |
| Problem Summary | A queue compaction was performing as the queue reached > 2 GB in size, and the log was full during the queue compaction. Due to the resource problem, the caller of queue compaction could not complete the activity which causes a queue damage. |
| Problem Conclusion | The queue compaction should complete even when a resource problem occurred which can avoid a partial compaction which leads to a queue damage. |
IC46369
| Abstract | PUB/SUB BROKER (AMQFCXBA.EXE) TRAPS SAYING "ACCESS VIOLATION AT ADDRESS XXXXXXXX WHEN READING" |
| Users Affected | While implementing pubsub, if the user supplies null info or data, they may encounter this problem. Platforms affected: Windows |
| Error Description | The "SYSTEM.BROKER.CONTROL.QUEUE" has a lot of messages in it. When you try to start the Pub/Sub broker (amqfcxba.exe), it trapped, throwing an FDC with probe id XC130031 having the below probe description : AMQ6119: An internal WebSphere MQ error has occurred (Access Violation at address 00CDC000 when reading) The FDC had the below MQM Function Stack: fpiTaskReply faxRunStream faiControlThread faiProcessCommandMsg faiParseCommandMsg faiProcessCommandParm xcsFFST The error logs record the below message : AMQ6119: An internal WebSphere MQ error has occurred (Access Violation at address 00977000 when reading) |
| Problem Summary | In the SYSTEM.BROKER.CONTROL.QUEUE, there are one or more messages which have a parameter length (ParmLen) zero. The broker is unable to handle these messages and is trapping. |
| Problem Conclusion | To overcome this situation, in the "faiParseCommandMsg" function call, checks are made to check if the parameter length is zero or the parameter value (pparmVal) is NULL, before processing the command parameters (i.e. faiProcessCommandParm function call). When a such a message is found processing further messages continues. A reply with reason code MQRCCF_COMMAND_FAILED is sent. |
IC46301
|
| Abstract | MC011057 WHEN STOPPING WINDOWS WHILE MSCS CONTROLLED QUEUE MANAGER IS STILL RUNNING. |
| Users Affected | All users of WebSphere MQ and Microsoft Cluster Service (MSCS) Platforms affected: Windows |
| Error Description | When running a WebSphere MQ queue manager under Microsoft Cluster Server (MSCS) control, if the Windows machine is shutdown while the queue manager is running the MQ Service will attempt to stop the queue manager. A FDC will be generated by process resrcmon.exe with Probe Id MC011057 out of component MQMCheckIsAlive. The FDC will also show a comment which says "***CMQMException Caught***: QM has stopped unexpectedly". The MSCS resource should indicate to the MQ service that it is in control of the resource and so at shutdown time, the MQ Service should ignore that queue manager. |
| Problem Summary | Stopping the MQ Service shuts down all queue manager, even if they are under MSCS control. When a machine shuts down, if the MQ service gets terminated first, then the MSCS resource may detect the queue manager going away as a failure, and attempt to restart it causing various FDC's relating to activity not permitted during machine shutdown. |
| Problem Conclusion | The MQ Service has been modified to not shut down any queue manager which is under MSCS control. Note: One side effect of this is that when applying MQ maintenance to a node, the MQ resource must be manually offline before the fix pack or CSD install process is launched. |
IC46145
|
| Abstract | MQRC_NO_MSG_AVAILABLE MQRC2033 WHEN GETTING LOCKED SEGMENTS |
| Users Affected | Customers writing WMQ applications to get messages from WMQ queues Platforms affected: All Distributed |
| Error Description | Customers' application makes an MQGET call using the BROWSE and LOCK options to identify and lock the message segments of a non-persistent logical message without the use of syncpoints. A subsequent MQGET call that is made to get the locked message segments fails with completion code MQCC_FAILED with reason code 2033 MQRC_NO_MSG_AVAILABLE. |
| Problem Summary | The problem here was introduced by the fix for a problem described in APAR IY03547. When an MQGET call is made with BROWSE and LOCK options, WMQ will apply a logical message lock to all segments of the message under the browse cursor. If the second MQGET is not within a unit of work, every time WMQ gets a segment off the queue, it releases the logical message lock that the browse cursor has to that message. (This was introduced by a fix for IY03547.) This means that the user's browser no longer has the right to access or unlock the other segments of the message that were locked by the first MQGET and hence WMQ returns with the error MQRC_NO_MSG_AVAILABLE. |
| Problem Conclusion | The logical message lock for the browser is now released after all of the segments in a logical message have been returned, so that the browse cursor will still have access to the other segments of the message. |
IC45869
|
| Abstract | MQ SERVICE FAILS TO STOP, AND TRAP OCCURS IF A QUEUE MANAGER IS DELETED. |
| Users Affected | All users of WebSphere MQ deleting local queue managers on a windows platform. Platforms affected: Windows |
| Error Description | The MQ Service is running and a queue manager is deleted. The service is then ended, but a trap occurs and the service never completely ends (it hangs in stopping state). |
| Problem Summary | The MQ Service appears to hang because it never completes due to an underlying trap attempting to stop a queue manager which has already been deleted. |
| Problem Conclusion | The MQ Service has been modified to check that a queue manager is not deleted before attempting to stop it at shutdown. |
96924
| Abstract | IMPROVE ERROR REPORTING IF LOOKUP OF PROCESS REAL UID FAILS; AND FOR AUTHORIZATION FAILURES IN GENERAL. |
| Users Affected | Users starting a queue manager, other WMQ process or utility, or application, under a user id that does not have a password entry, or has a password entry with a name that is longer than 12 characters (10 on AS400). Or users running on systems that are experiencing problems looking up uid's for whatever reason. Perhaps a password entry has been deleted. Additionally, users experiencing authorization failures can obtain greater information on the reason why, by way of a message to a WMQ error log. Platforms affected: iSeries,All Unix |
| Error Description | As part of the standard process initialisation performed by WMQ processes, and when an application connects to a queue manager, the process real uid is looked up to obtain the user name. If this lookup is unsuccessful then WMQ uses a user name of "UNKNOWN", which almost inevitably leads to a later authorization failure (rc=2035, MQRC_NOT_AUTHORIZED error). This authorization failure can be difficult to track back to the real user uid lookup failure, and so we now introduce an FDC at the point of the lookup failure. Additionally, we provide a mechanism for delivering clearer information in the event of an authorization failure. |
| Problem Summary | The difficulty of tracking process uid lookup failure to its root cause is caused by the decoupling of the failure from the point that such a failure is ultimately reported (finding that a user id of "UNKNOWN" is unauthorized to perform some action). The problem has up to now not been reported at the uid lookup failure point, because of concerns that there may be systems where, for some unexplained reasons, uid lookup failure could be tolerated. Unfortunately, this approach inevitably leads to user difficulties with understanding what has gone wrong when they find they get an authorization failure from a WMQ operation. Additionally, it is generally the case that authorization failures of any kind would benefit from improved explanation as to why the failure has occurred. |
| Problem Conclusion | Revised the process initialisation real user id lookup failure to report such a failure by way of an FDC. The FDC gives a clear explanation as to what has failed and how. The lookup is performed with the equivalent of the invocation: getpwuid (getuid(), ...) or getpwuid_r (getuid(), ...) This is now not expected to fail, and is not expected to deliver back a user name longer than 12 characters (10 on AS400). New FDCS: XY051169: Got password entry for process real uid, but it is too long. XY051170: Failed to get password entry for process real uid. Note that, despite reporting one of these FDCs, processing will continue, but utilising a user name of "UNKNOWN". It is the aim of these improvements in error reporting and additional information provided, to enable this particular uid lookup failure situation to be rectified by customers themselves. Note that, in the unlikely situation that a customer wishes to tolerate this lookup failure, the environment variable AMQ_NOFFST_PROCESS_UID can be exported globally to disable these FDCs. Additionally, an error message can now be generated to a WMQ error log, in the event of an authorization failure. This message is disabled by default, but can be enabled by ensuring that the environment variable MQS_REPORT_NOAUTH is exported in the shell from which the queue manager is started. Customers who are experiencing repeatable authorization failures that cannot be understood, are therefore recommended to reproduce the failure with this setting. The AMQ8077 error messages that will then be generated should provide useful information regarding the specific reasons for the failures. |
96375
| Abstract | OCCASIONAL XASESSION.CLOSE FAILS ON ISERIES |
| Users Affected | Iseries users using XA by way of JMS Platforms affected: iSeries |
| Error Description | DESCRIPTION OF TEST FAILURE - In this test we create an XA session from an XA CF->XA Connection and we run the close method on that session. On other platforms this completes without error, but on iSeries we get an XACLOSE failed message. [Thu Jul 28 09:37:12 UTC 2005] Testing method close [Thu Jul 28 09:37:12 UTC 2005] Attempting to close the Session [Thu Jul 28 09:37:12 UTC 2005] **** ERROR **** The following Exception was thrown [Thu Jul 28 09:37:12 UTC 2005] javax.jms.JMSException: MQJMS2012: XACLOSE failed at java/lang/Throwable.(Throwable.java:195) at java/lang/Exception.(Exception.java:41) at javax/jms/JMSException.(JMSException.java:53) at com/ibm/mq/jms/services/ConfigEnvironment.newException(ConfigEnvironment.java:567) at com/ibm/mq/jms/MQXASession.close(MQXASession.java:183) at com/ibm/mqst/apijms/GenericSessionTests.genericTests2(GenericSessionTests.java:304) at com/ibm/mqst/apijms/MDMQXASessionTest.runTest(MDMQXASessionTest.java:59) at com/ibm/mqst/apijms/harness/TestRunnerThread.run(APIJMSTestRunner.java:698) Linked exception: javax.transaction.xa.XAException: XA operation failed, see errorCode at java/lang/Throwable.(Throwable.java:195) at java/lang/Exception.(Exception.java:41) at javax/transaction/xa/XAException.(XAException.java:41) at com/ibm/mq/MQXAResource.close(MQXAResource.java:159) at com/ibm/mq/jms/MQXASession.close(MQXASession.java:183) at com/ibm/mqst/apijms/GenericSessionTests.genericTests2(GenericSessionTests.java:304) at com/ibm/mqst/apijms/MDMQXASessionTest.runTest(MDMQXASessionTest.java:59) at com/ibm/mqst/apijms/harness/TestRunnerThread.run(APIJMSTestRunner.java:698) No further chained exception |
| Problem Summary | This was an intermittent problem caused by a mistake in the conversion of a queue manager name to the native character set from Java. |
| Problem Conclusion |
95759
| Abstract | SIGSEGV IN AMQRRMFA, WITH RFXENUM* CALL IN RECENT FDC TRACEBACK |
| Users Affected | This is likely to be a rare failure. Unfortunately, there are a few places where the problem can occur and this problem has been found through code review rather than by debugging an actual failing situation. Given the complexity of the clustering operation, it is not possible to narrow down what users may be affected, other than to say, simply, users of clustering. This problem would typically result in repository manager termination, with a SIGSEGV FDC. Platforms affected: All Distributed |
| Error Description | The repository manager, amqrrmfa, may SIGSEGV in certain rare circumstances. Typically, you might see a call to rfxEnumCLSUB, rfxEnumCLQ or rfxEnumCLQMGR in the FDC traceback, and in most failure scenarios you would also see a non-zero return code from a repository manager function following an rfxEnum* call. |
| Problem Summary | Inconsistent saving and restoring of temporary result areas used internally within the code. |
| Problem Conclusion | Thoroughly reviewed this aspect of the clustering implementation. Assessed each and every usage of temporary result areas. Corrected the implementation to ensure consistent and methodical use of these areas throughout. |
95657
| Abstract | MQM400 WRKMQM - BAD CHARACTERS IN DESCRIPTION COLUMN WHEN USER DOES NOT HAVE *CONNECT AUTHORITY TO THE QUEUE MANAGER |
| Users Affected | Users of the WRKMQM command. Platforms affected: iSeries |
| Error Description | For ACTIVE QMgrs, WRKMQM uses lpiSPIMQConnect + lpiSPIInq1 + MQDISC to query the QMgr description. If the lpiSPIMQConnect or lpiSPIInq1 fails (usually because the user does not have sufficient authority) then the queue manager description remains uninitialised, and displays (by way of WRKMQM + PF20) as rubbish characters. |
| Problem Summary | The WRKMQM command displays a panel which has columns for name, status, default flag and text (use F20=Right). The descriptive text is blank for Queue Managers which are not active, and may contain rubbish characters when the end user does not have *CONNECT authority to the specific Queue Manager. |
| Problem Conclusion | In the case when the end user does not have *CONNECT authority to the specific Queue Manager, the descriptive text field will display all asterisk characters. |
94886
| Abstract | FAILURE TO LOAD EXITS CORRECTLY WHEN USING THE MQ EXPLORER, AND WITH JMS CLIENTS ON WINDOWS. MQCSP STRUCTURES NOT SENT TO SERVER |
| Users Affected | Anybody using.... (1) the GUI using CCDTs to connect to a remote queue manager where the Client Conn Channel has an exit defined (2) native Exits being used on Windows (3) native security Exits to provide security on a connection Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java |
| Error Description | Theses errors all occur with the Java MQI or JMS Client. There are 3 possible error descriptions: (1) The Explorer GUI can connect to a remote queue manager by using a Channel Definition Table. Exits can be specified on the Client Connection Channel. When connecting to a the remote queue manager in this way the GUI reports "Unable to Connect to Remote Queue Manager". Note this is a very simple error message - and is same error that is reported for any failure to connect to the remote system. (2) A Windows Java client may fail to to load the a native client library. An exception is thrown - "UnstatisfiedLinkException". (3) If a java client security exit is being used, the MQCSP structure is not sent across to the matching security exit on the server. This connection fails to connect. "Unable to establish remote connection" |
| Problem Summary | Design of exit loading has been reworked. Plus a corrections to the load path of the exits have been made. Correction made to ensure that the MQCSP structure is correctly handled. |
| Problem Conclusion | Native exits will always be loaded from EXITS directory of the Queue Manager installation. When using Client Channel Definition Tables (CCDT) to establish a connection, Java and Native exits will be loaded from the EXITS directory. Note that the Java exits should not be JAR files. They should be in the directory structure that matches their package name. This applies to connections made using CCDT either in the Explorer GUI or in code. |
94664
| Abstract | UNABLE TO USE THE JMS POSTCARD APPLICATION TO SEND MESSAGES FROM LINUX MACHINES. |
| Users Affected | Users using the JMS Postcard to verify their installation Platforms affected: HP-UX,Linux,All Unix |
| Error Description | The description from the tester summarises this " I can't send a message from one machine to another. I get "Error during send" when trying to send from the machine that is not the cluster repository to the machine that is. When I try to send a message from the machine that is the cluster repository it thinks it's sent it but it doesn't arrive at the other end. " |
| Problem Summary | The problem is that the user has 127.0.0.1 as an alias for their machine name in /etc/hosts. This means that the ip address of 127.0.0.1 gets passed to a remote machine as the address to "talk back to me on" The remote machines then gets a bit confused. |
| Problem Conclusion | Change to how the address was located in the java code to work around this. |
Related Information
[{"Product":{"code":"SSFKSJ","label":"WebSphere MQ"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"APAR \/ Maintenance","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF012","label":"IBM i"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"5.3","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Product Synonym
WMQ MQ
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg27006919