Product Readmes
Abstract
This document describes the fixes shipped in WebSphere MQ V5.3 fix pack 11.
Content
Table of Contents
APARs in Fix pack 11
- SE21259
MQM400 SECURITY AUDIT JOURNAL ENTRIES PRODUCED WHEN USING OS V5R3 WITH USER *USER WITH NO SPECIAL AUTHORITIES - SE20571
MQM400- AMQ6993 MESSAGE INCORRECTLY GENERATED WHEN ENDMQM SUBMITTED IN BATCH - SE19814
MQM400: DIAGNOSTIC TESTFIX FOR PROVIDING ADDITIONAL DEBUGS INSIDE XCSWAITEVENTSEM. - SE19791
MQM400-CHANNEL PAIR REMAINS IN RETRYING/BINDING STATUS AFTER A NETWORK CHANGE AND DOES NOT RECOVER. - SE19719
CHANNEL GETS DISCONNECTED WHEN COMMITTING A BATCH OF MESSAGES. - SE19457
MQM400- REMOTE ADMINISTRATION OF ISERIES QUEUE MANAGER DROPS CONNECTION WHEN TRYING TO MAKE CHANGES TO WMQ OBJECTS. - SE19391
ISERIES GROUP PROFILE NAMES WITH A HASH IN THEM, FAIL TO BE PICKED UP FOR AUTHORITY CHECKING. - SE19180
MQM400 WMQ 5.3 WRKMQMCHL DSPMQMCHL DISPLAYS THE QUEUE MANAGER NAME WITH SOME APPENDED GARBAGE CHARS. - SE18797
WINDOWS CLIENT CRASHES WHEN TRYING TO CONNECT TO ISERIES QUEUE MANAGER USING SSL CLIENT CHANNEL DEFINITION CREATED ON ISERIES. - IY74278
SIGSEGV FDC WITH AQHIMAGESIZE IN THE CALL STACK, AT FIX PACK 10 LEVEL. - IY73014
BUILD UP OF AMQRMPPA PROCESSES - IY72849
MESSAGE CORRUPTION GETTING MESSAGES > 4K IN JAVA - IY71943
CHANNEL AGENT THREAD ACCUMULATION - IY71335
CHANNEL REMAINS IN STOPPING STATUS AFTER STOP CHANNEL MODE(TERMINATE) COMMAND HAS BEEN ISSUED - IY71223
SIGSEGV XAOPEN XC130003 EXTENDED TRANSACTIONAL CLIENT - IY71204
DAMAGED TEMPORARY DYNAMIC QUEUE INADVERTENTLY ADDED TO POOL OF REUSABLE QUEUES AT STARTUP - IY71004
MQ LOGS FILL UP AND THE QUEUE MANAGER WILL NOT RESTART AFTER MANY AO084010 FDCS. - IY70415
INCORRECT MESSAGE MAY BE RETURNED TO MQGET WITH MQGMO_WAIT AND MQGMO_MSG_UNDER_CURSOR - IY70366
FDC ZD008040 FROM ZDMOPENDEFERREDQ WHEN STARTING QUEUE MANAGER - IY70233
RCDMQIMG COMMAND TO RE-CREATE A DAMAGED OBJECT UNRESPONSIVE WITH FFSTS WITH PROBEID XC307070 - IY69906
AMQTRC.FMT DOES NOT FORMAT A TRACE CORRECTLY ON A 64BIT KERNEL - IY69886
PCF COMMAND MQCMD_INQUIRE_Q_STATUS DOES NOT RETURN ANY DATA IF ONLY THE DEFAULT PARAMETERS ARE SUPPLIED. - IY69885
RUNNING OUT OF SEMAPHORES DOESN'T OUTPUT A USEFUL ERROR MESSAGE. - IY69883
FFST WITH PROBE ID XC130003, COMMENT1 :- SIGSEGV AND ATMQUERYACTIVE IN MQM FUNCTION STACK. - IY69753
HANG IN XIHQUERYTHREADENTRY ON SOLARIS - IY69464
WITH PIPELINING ENABLED, THE CHANNEL SYNCHRONISATION FILE MAY NOT BE CLOSED BY THE SECOND THREAD - NO EXTERNAL SYMPTOMS KNOWN. - IY69385
LDAP NAMING SERVICE NOT SUPPORTED ON AIX MQRC_NOT_AUTHORIZED RETURNED WHEN LDAP IS USED - IY68875
WEBSPHERE MQ IS NOT PROPERLY RE-OWNING A SPINLOCK FROM A DEAD OWNER. FFST PROBE ID: XC028018 IS GENERATED. - IY68798
THE 2ND THREAD OF PIPELINED CHANNELS FAILS TO RETURN MESSAGES TO XMITQ WHEN CHANNEL FAILS, LEAVING XMITQ IN UNCOM(YES) STATUS. - IY68509
CUSTOMER IS RECEIVING FDC WITH XC015001 FROM XCSFREEQUICKCELL. FIX FOR APAR IY60472 WAS SUPPOSED TO RESOLVE PROBLEM. - IY68487
USERIDS BETWEEN 9 AND 12 CHARACTERS ON UNIX WMQ CLIENTS ARE PASSED TO WMQ SERVER AS 'UNKNOWN'. - IY67891
MQ CLUSTER REPOSITORY PROCESS FAILS WITH PROBE ID RM220005 - IY67777
AN UNINITIALIZED MUTEX WAS ACCESSED AS PART OF THE UNREGISTER OF THE SIGNAL HANDLER BECAUSE AMQ_SIGCHLD_SIGACTION WAS SET. - IY67232
SLOW MQ CHANNEL STARTUP/SHUTDOWN DUE TO STATUS TABLE LOCKING - IY67176
COMMAND SERVER CRASH WITH SIGSEGV XC130003 WHEN PROCESSING CHANNEL PCF COMMANDS WITH NO OAM. - IY67021
HANDLE LEAK IN JMS PRODUCING APPLICATION (2017- MQRC_HANDLE_NOT_AVAILABLE). - IC47044.
SSL AUTHENTICATION WITH JMS REALTIME NODE FAILS FROM JMS CLIENT WHEN JDK1.4.2 IS USED AT CLIENT SIDE WITH LEGALARGUMENTEXCEPTION - IC46239
.NET INTERFACE THROWS UNCATCHABLE EXCEPTIONS - IC46238
CHANNEL TERMINATES ON CLIENT CONNECTED TO SERVER AT 5.3FP10 OR HIGHER WITH PROBE RM046002 FDCS - INVALID DATA FORMAT - IC46074
CLIENT CHANNEL TO Z/OS NEVER TIMES OUT AFTER A CONNECTION DROP - IC45894
CLUSTER ADMINISTRATOR OR MQ MMCS HANGS WHEN AN MSCS CLUSTER CONTAINS MORE THAN QUEUE MANAGER RESOURCE OR CUSTOM SERVICE. - IC45877
USING THE AMQMSRVN -REGSERVER COMMAND CAUSES THE USER ID SELF TO BE REMOVED FROM DEFAULT COM SECURITY ON WINDOWS 2003 - IC45816
FDC FILES WITH PROBE IDS XC130031 AND HL081010 BUT NO MESSAGE WHEN THE LOGPATH IS SET INCORRECTLY. - IC45799
PROBE XY051025, REPORTING DUPLICATE AMQXCS2.DLL FOUND REPORTED INCORRECTLY, AND THE PATH TO THE DUPLICATE COPY IS EMPTY - IC45797
.NET APPLICATION RUNNING ON MQ EXTENDED TRANSACTIONAL CLIENT (MQ XA CLIENT) THROWS ERROR 2354 I.E. MQRC_UOW_ENLISTMENT_ERROR - IC45623
THE CREATE QMGR WIZARD RESTRICTS THE MAXUMSGS PARAMETER VALUE TO 10,000 MESSAGES WHEN THE LIMIT SHOULD BE 999,999,999. - IC45571
INSTALLATION OF A FIX PACK ON TOP OF MQ 5.3 FAILS REPORTING COPY FAILED FOR FILE AMQXMS0N.DLL WITH RETURN CODE 1224. - IC45516
AMQMSRVN DOES NOT CHECK THE USER NAME SPECIFIED - IC45414
AMQZLAA0 USES 100% CPU WHILE LOADING A QUEUE WITH PERSISTENT AND NON-PERSISTENT MESSAGES - IC45158
EVENT ID 1016 LOGGED BY PERFMON FOR LIBRARY AMQMPERF.DLL - IC45049
WRONG ERROR MESSAGE (AMQ9658) WHEN AN EXPIRED CA CERTIFICATE ATTEMPTS TO VALIDATE A PERSONAL CERTIFICATE. - IC45004
PERFORMANCE SLOW DOWNS AND TIMEOUTS WHILST USING A QUEUE STATUS MONITOR - IC44759
FDC WITH PROBE ID UN074001 SEEN WHEN RUNNING AMQMDAIN. - IC44049
INTERMITTENT ACCESS VIOLATIONS IN MTS OR COM+ APPLICATIONS - IC43749
SHIFT-OUT CHARACTER TRUNCATED WHEN MESSAGE DATA ENDS WITH DBCS - 96293
MISSING INSTRUCTIONS FOR BUILDING XA SWITCH FILE FOR ORACLE 10G ON AIX PLATFORM. - 95064
XY132006 FROM XSTCREATEEXTENT OR XC035040 FROM XCSCREATETHREAD ON SLES9 WITH WMQ FOR LINUX FOR ZSERIES, V5.3 OR V6.0 - 94168
USING CRL WITH JMS, WITH REVOKED CERTIFICATES, THE FIRST CONNECT FAILS BUT FOLLOWING CONNECTS SUCCEED. - 94073
XASWIT.MAK FILE WITH ORACLE 10G ON SOLARIS PLATFORM FOR USE WITH WMQ 5.3 + FIXPACK - 93078
COMPLETE SHIPMENT OF FIX FOR IC43892 - 92775
USE CORRECT BIND OPTION WHEN PUTTING TO A CLUSTERED QUEUE MANAGER ALIAS. - 92560
AMQTSIVT (MTS/COM+ IVT PROGRAM) MAY FAIL ON WINDOWS XP OR 2003 WITH RETURN CODE 0X80070057 - 92451
AMQMSRVN DOES NOT CHECK THE USER NAME SPECIFIED - 92244
CHANNEL NAMELIST ALTERATION ON THE LOCAL PARTIAL REPOSITORY QUEUE MANAGER - 91730
A .NET APPLICATION TERMINATING MAY COMMIT MESSAGES WHICH ARE IN A UNIT OF WORK - 89105
UNABLE TO VIEW QUEUES BELONGING TO REMOTE QUEUE MANAGER THROUGH MMC. - 87457
"INVALID PROPERTY FOR A COM.IBM.MQ.JMS.MQTOPICCONNECTIONFACTORY: MAXBUFFSIZE" IN WEBSPHERE MQ V5.3 FIX PACK 8 JMSADMIN.
SE21259
|
Abstract | MQM400 SECURITY AUDIT JOURNAL ENTRIES PRODUCED WHEN USING OS V5R3 WITH USER *USER WITH NO SPECIAL AUTHORITIES |
Users Affected | All iSeries users performing WebSphere MQ 'WRK' commands such as WRKMQM, at OS/400 release V5R3M0. Platforms affected: iSeries |
Error Description | A user created as *USER with no special authority produces security audit journal entries when an MI instruction is issued. For example, when issuing the WRKMQM, an AF/K entry is inserted into the audit journal. Additional Symptom: Journal . . . . . . : QAUDJRN Library . . . . . . : QSYS Sequence . . . . . . : nnn Code . . . . . . . . : T - Audit trail entry Type . . . . . . . . : AF - Authority failure The same problem happens at WMQ v6.0 on OS/400 530. THe AF entry with violation type 'K' is new in OS/400 R530. Entry specific data Column *...+....1....+....2....+....3....+....4....+....5 00001 'K*INSTR *N *N QPADEV0003TESTUSER ' 00051 '027881 TESTUSER 0000' 00101 '000 ' |
Problem Summary | Commands such as WRKMQM need to connect to an active Queue Manager to query attributes such as 'Description'. The connect process uses function xcsCheckProcess to check that the Queue Manager is still running. The underlying unix function in check process is kill (pid, 0). For OS V5R3M0, an audit failure is logged if the job which is performing kill (even with harmless signal 0) does not have *JOBCTL authority. |
Problem Conclusion | The problem has been fixed. The check process function will perform the 'kill' operation with QSYS authority, which by default includes *JOBCTL. The fix will be shipped in WebSphere MQ v5.3 Fix Pack 11. |
SE20571
|
Abstract | MQM400- AMQ6993 MESSAGE INCORRECTLY GENERATED WHEN ENDMQM SUBMITTED IN BATCH |
Users Affected | All users of MQ on iSeries performing ENDMQM in batch are affected. When the queue manager is running with one or more listeners, and users submits ENDMQM with ENDCCTJOB(*YES) in batch, the AMQ6993 error message is wrongly generated in the ENDMQM joblog. Platforms affected: iSeries |
Error Description | When ENDMQM with ENDCCTJOB(*YES) is submitted in batch, the following AMQ6993 error message is incorrectly generated in the joblog of ENDMQM job: AMQ6993 Diagnostic 40 03/15/05 03:09:32 LIBMQMR QMQM *STMT ENDMQLSR QMQM *STMT From module . . . . . . . . : AMQCJOBA_N From procedure . . . . . . : cccJobEnd Statement . . . . . . . . . : 42 To module . . . . . . . . . : AMQCLENA_N To procedure . . . . . . . : _C_pep Statement . . . . . . . . . : *N Message . . . . : Program END ended abnormally. Cause . . . . . : A WebSphere MQ for iSeries program, END, is ending abnormally. Recovery . . . : Display the job log, using the DSPJOBLOG command, for information why the job or subsystem ended abnormally. Correct the error and retry the request. |
Problem Summary | When ENDMQM is submitted in batch, after ending the queue manager, if ccxENDMQLSR is returning with rrcI_ONE_LISTENER_TERMINATED or rrcI_LISTENERS_TERMINATED, the ENDMQM joblog wrongly displays message AMQ6993. |
Problem Conclusion | When the listener program has normally terminated with rrcI_ONE_LISTENER_TERMINATED or rrcI_LISTENERS_TERMINATED, we should not be generating the AMQ6993 message in joblog. Condition checking has been done to prevent the problem. |
SE19814
|
Abstract | MQM400: DIAGNOSTIC TESTFIX FOR PROVIDING ADDITIONAL DEBUGS INSIDE XCSWAITEVENTSEM. |
Users Affected | The actual root cause of EINVAL is not yet detected . We suspect this problem is not limited to iSeries, but could occur on any busy system. Platforms affected: iSeries,All Unix,Windows |
Error Description | xcsWaitEventSem failed with 3021 i.e. EINVAL. To find out exactly which parameter is invalid, put additional debug statements in the piece of code concerned. |
Problem Summary | This APAR is a diagnostic testfix PTF for additional debug statements. |
Problem Conclusion | Put additional trace statements and also dumped more information in the FDC files produced by the xcsWaitEventSem function. |
SE19791
|
Abstract | MQM400-CHANNEL PAIR REMAINS IN RETRYING/BINDING STATUS AFTER A NETWORK CHANGE AND DOES NOT RECOVER. |
Users Affected | User's using non-threaded receiver channels(AMQCRSTA) with AdoptNewMCA tuning parameters. Platforms affected: All Distributed |
Error Description | MQ channels go into a Retrying/Binding state after a network outage and do not recover. The receiver AMQCRSTA job does not show a start channel message id in it's job log(AMQ9002). The AMQCRSTA jobs get SIGKILLS which can be seen in the job logs. These end but then new AMQCRSTA jobs startup which experience the same problem i.e. they fail to start and are eventually killed (SIGKILL). New jobs then start and the whole process repeats over and over again. To recover one has to end the AMQCRSTA job, and stop and start the sender on the Windows server. The Trace shows the following characteristic function calls/trace statements: 005 .....> rriAdoptMCA 006 ......> rrxStopChannel 007 Stop Phase:1 Pass:0 007 Stop Phase:2 Pass:1 and so on until... 007 Stop Phase:5 Pass:0 007 .......> rriStopChannel 008 ........> cccJobKill 009 .........> xcsKillProgram 008 ........< cccJobKill rc=OK 007 .......< rriStopChannel rc=OK and finally out of AdoptMCA 005 .....< rriAdoptMCA rc=OK and then into ccxSend 004 ....> ccxSend 005 .....> cciTcpSend 006 ......> send and then into a loop in xcsSleep 005 .....< cciTcpSend rc=OK 005 Waiting to be killed 005 .....> xcsSleep 005 .....< xcsSleep rc=OK 005 Waiting to be killed |
Problem Summary | The problem was caused because of the KillPending flag in the status table being set when case SP_KILL_CHANNEL && Running. This flag was not being cleared after the channel was killed. Thus new receiver jobs starting had this flag set and were waiting to be killed. |
Problem Conclusion | The Flag initialization and clearing of the flag and some additional checking have been introduced to prevent this problem. |
SE19719
|
Abstract | CHANNEL GETS DISCONNECTED WHEN COMMITTING A BATCH OF MESSAGES. |
Users Affected | All users of Channels which have MQ with a Fap level less than 4 (MQ version 2.x) on the remote end and the channel BatchHeartbeat parameter set to value other than 0 on the Sender side. Platforms affected: iSeries,All Unix,Windows |
Error Description | The problem occurs when committing a batch of messages on the Sender side channel which has BatchHeartbeat parameter set to a value other than 0. The sender channel gets disconnected and the AMQ9523 (rrcE_REMOTE_PROTOCOL_ERROR) message followed by the AMQ9528 (rrcI_CHANNEL_CLOSED) message are logged in Error log. |
Problem Summary | The Sender Side channel fap level is 7 and the receiver side Fap level is 1. On Starting the channel, the negotiated faplevel is 1. When committing a batch of messages on Sender side, a check is made to ensure that the Remote end is responding. If the response time from the Remote side exceeds the heartbeat interval, the Sender side sends a Batch Heartbeat. However as the Remote end is faplevel 1, the heart beat is not supported causing the channel to close. |
Problem Conclusion | If the negotiated faplevel is less than 4, set BatchHeartbeat to 0. |
SE19457
|
Abstract | MQM400- REMOTE ADMINISTRATION OF ISERIES QUEUE MANAGER DROPS CONNECTION WHEN TRYING TO MAKE CHANGES TO WMQ OBJECTS. |
Users Affected | All users of MQ Explorer on Windows performing Remote Admin on iSeries queue manager having CCSID 937 (Traditional Chinese) or any other Double Byte CCSID. Also affected are all users using the V6 GUI administrator. Users cannot create queues or change queue attributes remotely . Platforms affected: iSeries |
Error Description | The problem occurs when performing Remote Administration from Windows V5.3 using MQExplorer on iSeries Queue Manager at CCSID 937. It also occurs when using V6 Administration GUI on Windows and Linux(Intel). An attempt to create a queue or change the attributes of a queue causes the connection to queue manager drop immediately, with AMQ4043 error message being produced. The problem does not occur if CCSID of the queue manager is 37 or any other single byte CCSID when using the V5.3 MQExplorer, but occurs for all queue manager CCSIDs when using the V6 GUI. |
Problem Summary | When performing remote administration on queues of queue manager on iSeries, an MCH3601 exception occurred in vwb_space_pad at statement no 44. This was due to a null pointer parameter passed to memset (count field in the String list is zero). |
Problem Conclusion | Condition checking has been done to prevent the problem. |
SE19391
|
Abstract | ISERIES GROUP PROFILE NAMES WITH A HASH IN THEM, FAIL TO BE PICKED UP FOR AUTHORITY CHECKING. |
Users Affected | MQI API calls fail for users belonging to a group profile with hash in spite of having authority. Platforms affected: iSeries |
Error Description | If the group profile name has a hash in it, then the authority given to it is not picked up by members of the group. Even if the group profiles with hash are given adequate MQ authority, applications run under the group member's profile fail on issuing MQI API calls. For example when *ALLMQI authority is granted for group profile, whose profile has got an hash in it, no member of the group will be able to perform MQI calls. (eg: MQCONN)...and the call fails with reason code RC2035. |
Problem Summary | OS/400 Group profile names with hash are valid names. Internally MQ converts hashes to dots, since reading hashes from an ini file results in a line being treated as a remark. While checking for authority we need to convert the hash to ".". This conversion function of hash to "." is missing and hence authority check fails. |
Problem Conclusion | Changes are carried out in the OAM program. Function to convert hash to "." is added while adding Group profiles in the authority checklist |
SE19180
|
Abstract | MQM400 WMQ 5.3 WRKMQMCHL DSPMQMCHL DISPLAYS THE QUEUE MANAGER NAME WITH SOME APPENDED GARBAGE CHARS. |
Users Affected | Users who have used the CL command CRTMQMCHL to create a channel on V5R3 OS version are affected. The DSPMQMCHL command displays the error. Channels created through MQSC commands are not affected. Platforms affected: iSeries |
Error Description | The display of the channel ( DSPMQMCHL ) shows queue manager name appended with some garbage characters. This happens only with channels created using CRTMQMCHL CL command and only on the latest current OS version V5R3. |
Problem Summary | In general, the CMD and CL do not null terminate strings. Command line arguments passed via arg[] to a C program are not automatically null terminated in all cases. The uninitialized storage being used will be zero for most but not all of the time. At the times when it is not zero, some unintended characters will be created. The Queue Manager name that is copied to the MQCD channel definition record during channel creation is thus appended with some unintentional characters. These will be visible while displaying the channel. For example: Message Queue Manager name . . : QMGREIGH6E??? |
Problem Conclusion | A fix has been put in place to prevent uninitialized storage from being used. Thus new channels created with CRTMQMCHL command will create a channel definition record for the channel, ensuring that the queue manager name will not have any garbage characters included. |
SE18797
|
Abstract | WINDOWS CLIENT CRASHES WHEN TRYING TO CONNECT TO ISERIES QUEUE MANAGER USING SSL CLIENT CHANNEL DEFINITION CREATED ON ISERIES. |
Users Affected | All users of WebSphere MQ client on Windows connecting to iSeries queue manager using SSL client channel definition created on iSeries. Platforms affected: iSeries,Windows |
Error Description | Client application amqsputc crashes when trying to connect to an iSeries queue manager using SSL client channel definition which were created on iSeries. The error message received is : "The instruction at "0x4..." referenced memory at "0x0...." An FDC with Probe Id XC130031 is generated . Probe Id :- XC130031 Application Name :- MQM Component :- xehExceptionHandler Major Errorcode :- xecF_E_UNEXPECTED_SYSTEM_RC Probe Type :- MSGAMQ6119 Probe Description :- AMQ6119: An internal WebSphere MQ error has occurred (Access Violation at address 0039D000 when reading) MQM Function Stack DoConnect rriInitSess ccxSecureAllocConv cciSslSecureAllocConv cciSslRemoteCert cciSslCopyDN xcsFFST |
Problem Summary | The client channel definition table created on iSeries is incompatible with PC platforms. |
Problem Conclusion | Code has been rewritten for client channel definition table of iSeries to be compatible with PC platforms. |
IY74278
|
Abstract | SIGSEGV FDC WITH AQHIMAGESIZE IN THE CALL STACK, AT FIX PACK 10 LEVEL. |
Users Affected | This problem may rarely occur for users running fix pack 10. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
Error Description | A change at fix pack 10 has introduced the rare possibility of a SIGSEGV within the calculation performed by the aqhImageSize function. This function is used, for example, during rcdmqimg. |
Problem Summary | A change to correct one problem with the image size function has unfortunately introduced another problem. |
Problem Conclusion | Corrected the logic involving the image size calculation. |
IY73014
|
Abstract | BUILD UP OF AMQRMPPA PROCESSES |
Users Affected | Any user running runmqlsr. The presence of an AMQ9213 message in the error logs may indicate this defect. Platforms affected: All Distributed |
Error Description | Multiple amqrmppa processes build up on the system, even though there are no channels running. |
Problem Summary | If there is a TCP error accepting the connection in the pool process amqrmppa, the count of threads used in the pool becomes wrong, i.e. too high. In consequence, the process will never end because the thread count will not be reduced back to zero. |
Problem Conclusion | Amend the thread count correctly after the TCP error. |
IY72849
Abstract | MESSAGE CORRUPTION GETTING MESSAGES > 4K IN JAVA |
Users Affected | All users saving messages > 4K after multiple MQQueue.get() (using WMQ Java). Platforms affected: All Distributed+Java |
Error Description | When getting several messages of the same size and larger than 4096 bytes then saving them, when they are read later, they all show the same message body as the last message read. |
Problem Summary | The internal message buffer used at MQQueue.get() could get overwritten. |
Problem Conclusion | The internal buffer does not get rewritten. |
IY71943
|
Abstract | CHANNEL AGENT THREAD ACCUMULATION |
Users Affected | Users where a channel has become out of synchronization and so AMQ9526 errors are reported when the channel is restarted. Note that in the normal case this does not result in a build up of agent threads. However, in some exceptional cases the problem may occur. Investigations to date have failed to reproduce this problem, so the full necessary conditions to cause it are unclear. Platforms affected: All Distributed |
Error Description | This problem occurs when a channel is out of synchronization, and AMQ9526 channel synchronization errors are reported to the error log. In this situation, the channel agent thread corresponding to the channel may not be reusable, and so every time the channel is restarted, an agent thread is "leaked". A build up of agent processes will be observed over time, even though there may be relatively few actual active connections. |
Problem Summary | Missing logic to ensure the agent thread of a channel process is ended in all circumstances that a channel ends. |
Problem Conclusion | Added the missing logic. |
IY71335
|
Abstract | CHANNEL REMAINS IN STOPPING STATUS AFTER STOP CHANNEL MODE(TERMINATE) COMMAND HAS BEEN ISSUED |
Users Affected | This problem only occurs if a channel has become unresponsive and a stop channel command with mode terminate is required in order to bring down the channel. Platforms affected: All Distributed |
Error Description | After issuing the following sequence of MQSC commands, for a channel which had failed and was no longer flowing messages, the status for the channel returned from a DISPLAY CHSTATUS command remained 'STOPPING': 1) STOP CHL() STATUS(INACTIVE) MODE(QUIESCE) 2) STOP CHL() STATUS(INACTIVE) MODE(FORCE) 3) STOP CHL() STATUS(INACTIVE) MODE(TERMINATE) All three commands appeared to complete successfully, with the last command taking a number of seconds to complete. However, it was not possible to restart the channel due to the STOPPING status. |
Problem Summary | The stop channel commands with mode QUIESCE and FORCE are not able to stop a channel which has become entirely unresponsive. The stop channel command with mode TERMINATE actually terminates the channel thread or process which has become unresponsive, and should allow the channel to restart. However, the status of the channel was not being correctly hardened after successful execution of this command, allowing the channel to remain in STOPPING status even though the channel thread/process no longer existed. |
Problem Conclusion | The code was changed to correctly update the status, and provide an appropriate AMQ9604 entry in the error logs for the termination of the channel. |
IY71223
|
Abstract | SIGSEGV XAOPEN XC130003 EXTENDED TRANSACTIONAL CLIENT |
Users Affected | Customers using WMQ Extended Transactional Client for global units of work that are being co-ordinated by external transaction managers (such as WebSphere Application Server) using XA. Platforms affected: All Distributed |
Error Description | A customer application may receive a SIGSEGV signal (or an equivalent on Windows platforms) when using WMQ Extended Transactional Client. An FDC with the following function stack will be produced: MQM Function Stack XAOpen xcsFFST |
Problem Summary | During the XAOpen call, the xa_info string is copied into an internal buffer using the buffer's size as the basis of the copy instead of the size of the xa_info string. Under certain circumstances this might cause an access violation and hence generate a SIGSEGV signal. |
Problem Conclusion | Internally we have changed the mechanism for copying the xa_info string from a memcpy to a strncpy, making use of the size of the xa_info string instead of the internal buffer size. |
IY71204
|
Abstract | DAMAGED TEMPORARY DYNAMIC QUEUE INADVERTENTLY ADDED TO POOL OF REUSABLE QUEUES AT STARTUP |
Users Affected | Users of dynamic queues, who experience or cause a corruption of a dynamic queue, are potentially exposed to this problem. Platforms affected: All Distributed |
Error Description | A dynamic queue becomes corrupted, e.g. due to killing queue manager processes whilst the queue is being created. The queue manager is restarted. It reports the following sequence of FDCs for the corruption: Probe AD004001 from function adhOpen Probe AQ168001 from function aqpReadData Probe AQ143008 from function aqqAccessQHeader This is correct, and the queue manager restarts. Later, an application tries to create a dynamic queue and typically gets the following FDCs: Probe AD004001 from function adhOpen Probe AO077002 from function aocPerformCreation Probe AO074001 from function aocReaper These latter FDCs are the problem. Note that this problem is persistent, i.e. it is not cured by restarting the queue manager. |
Problem Summary | The queue manager avoids reusing damaged dynamic queues, but unfortunately the checks at queue manager restart were not sufficient to ensure this. |
Problem Conclusion | Improved the checking that the queue manager makes regarding the suitability of a dynamic queue for reuse. In particular, ensured that the detection of a damaged queue is propagated to the checking logic. |
IY71004
|
Abstract | MQ LOGS FILL UP AND THE QUEUE MANAGER WILL NOT RESTART AFTER MANY AO084010 FDCS. |
Users Affected | All users who are operating at the limit of their storage. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
Error Description | The first FDC indicating this problem will be probe AD020000 from adiSetFSize, with a comment in the FDC: "There is not enough space in the file system". This will be followed by a large number of AO084010 FDCs, and an indication that the logs are full. Once the queue manager gets into this state it will not be able to restart. |
Problem Summary | The problem here is triggered by the queue manager running out of disk space for its queues. Every time the checkpoint processor begins a new checkpoint (and this would happen with increasing rapidity as the log grows fuller) it logs at least three records for the beginning of the checkpoint, which will eventually force us up to the 2Gb active log space limit (the checkpoints do not complete because of the resource issue). Once the queue manager was stopped, it could no longer restart because the logs were completely filled with these checkpoint records, leaving no room to do the redo/undo pass. |
Problem Conclusion | As the resource issue which triggers this issue happens during an unload of the non-persistent queue buffer, which is an optional event, the fix here is to prevent the unload of the queue in these circumstances. This will mean the the buffer will remain in memory rather than be flushed to disk. |
IY70415
|
Abstract | INCORRECT MESSAGE MAY BE RETURNED TO MQGET WITH MQGMO_WAIT AND MQGMO_MSG_UNDER_CURSOR |
Users Affected | All users who have multiple connections to a queue all of which are doing a browse then MQGET with MQRC_NO_MSG_UNDER_CURSOR and MQGMO_WAIT set. Platforms affected: All Distributed |
Error Description | This problem arose when two clients were doing a browse for the same message on a queue (shared), then getting the message found with MQGMO_MSG_UNDER_CURSOR. If one client had browsed for the message but and then removed it before the next MQGET the message then there should have been an error code of MQRC_NO_MSG_UNDER_CURSOR. However, in some cases, the MQGET returned rc=OK but with the next message in the queue - so, getting the wrong message. |
Problem Summary | This problem can only occur if MQGMO_MSG_UNDER_CURSOR and MQGMO_WAIT are set for the same MQGET. If this is the case, then if there is no message under the cursor, instead of receiving a MQRC_NO_MSG_UNDER_CURSOR, sometimes WMQ goes into a wait for the message to appear. This is then interrupted with the next message in the queue being passed to it. |
Problem Conclusion | The fix for this issue is to ensure that we do not wait in this case, but rather report the MQRC_NO_MSG_UNDER_CURSOR. |
IY70366
|
Abstract | FDC ZD008040 FROM ZDMOPENDEFERREDQ WHEN STARTING QUEUE MANAGER |
Users Affected | Platforms affected: All Distributed Platforms affected: All Distributed (iSeries, all Unix and Windows) |
Error Description | After migrating MQSeries V5.2 with CSD less than 4 to WebSphere MQ V5.3 or V6, when starting the queue manager first time FDC files with probe IDs ZX008040 and ZD005030 created. |
Problem Summary | The MQSeries V5.2 with CSD less than 4 does not have SYSTEM.PENDING.DATA.QUEUE. Hence after migrating to WebSphere MQ V5.3 or V6, while starting the queue manager the AMQZDMAA process will try to create this queue, if it doesn't exist. At the same time strmqm creates this queue. So, the AMQZDMAA process gets MQRCCF_OBJECT_ALREADY_EXISTS and creates an FDC file with probeID ZD008040 from zdmOpenDeferredQ. |
Problem Conclusion | The AMQZDMAA process returns the error MQRCCF_OBJECT_ALREADY_EXISTS. The problem is fixed by converting MQRCCF_OBJECT_ALREADY_EXISTS into OK in zslCrt_SysDefLocalQ. |
IY70233
|
Abstract | RCDMQIMG COMMAND TO RE-CREATE A DAMAGED OBJECT UNRESPONSIVE WITH FFSTS WITH PROBEID XC307070 |
Users Affected | The circumstances required to observe this problem involve a queue entering a very specific state, with a particular combination of messages fragmented through the queue file combined with other specific factors affecting the queue compaction algorithm. Customers with a very large number of messages on a queue are most likely to be affected by this issue. Platforms affected: All Distributed |
Error Description | This problem was observed by a customer who was attempting to re-create a damaged object using rcrmqobj. The command did not return within 30 minutes, and the following FFSTs were observed: Probe Id :- XC307070 Component :- xlsRequestMutex CMVC level :- p530-09-L041213 Program Name :- amqzllp0 Major Errorcode :- xecL_W_LONG_LOCK_WAIT Probe Description :- AMQ6150: MQ semaphore is busy. --------------------------------------------------- MQM Function Stack zllpMain alsCheckPointLoop aocPerformCheckpoint xcsRequestMutexSem xlsRequestMutex xcsFFST And... Probe Id :- XC307070 Component :- xlsRequestMutex CMVC level :- p530-09-L041213 Program Name :- amqzlaa0_nd Major Errorcode :- xecL_W_LONG_LOCK_WAIT Probe Description :- AMQ6150: MQ semaphore is busy. --------------------------------------------------- MQM Function Stack zlaMainThread zlaProcessMessage zlaProcessSPIRequest zlaSPIRebuildObject zsqSPIRebuildObject kpiSPIRebuildObject apiEnquireObject aouLockObjectCatalogue xcsRequestMutexSem xlsRequestMutex xcsFFST The specific identifier for this problem, is that gathering two stack outputs for WMQ processes, separated by a time interval, would show a thread within stuck within aqhCompactQueue. |
Problem Summary | The xecL_W_LONG_LOCK_WAIT FFSTs from a thread performing a checkpoint and the thread attempting the rcrmqobj operation, were not actually from the threads causing the problem; they were waiting on a lock being held by a third thread. This thread was performing a queue compaction operation, in which it had entered an infinite loop. No trace occurs within this loop, so only stack information showed that this thread had become stuck within this function. |
Problem Conclusion | The code was altered so that the infinite loop condition could not be entered. |
IY69906
|
Abstract | AMQTRC.FMT DOES NOT FORMAT A TRACE CORRECTLY ON A 64BIT KERNEL |
Users Affected | Users using WMQ for AIX will see wrong timestamp at the last line of the formatted trace. Platforms affected: AIX |
Error Description | MQ Trace is not formatted correctly if trace file is gathered on AIX 64bit kernel. The Hook Id 002 is incorrect. If the trace of 64bit kernel is formatted, Hook Id 002 shows: TRACE OFF channel 0000 Thu Jan 1 09:00:00 1970 |
Problem Summary | So far, T4 was being used for TRACE OFF. This would give problems in formatting traces gathered on 64-bit environment. |
Problem Conclusion | To solve this issue, entry for hookid 002 should have $chan TW instead of $chan T4. TW will format either 4 or 8 bytes of data depending upon whether this is a 32 or 64 bit hook. |
IY69886
|
Abstract | PCF COMMAND MQCMD_INQUIRE_Q_STATUS DOES NOT RETURN ANY DATA IF ONLY THE DEFAULT PARAMETERS ARE SUPPLIED. |
Users Affected | Command Server, PCF messages. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
Error Description | From a program which creates Programmable Command Format (PCF) messages, send a message with the command MQCMD_INQUIRE_Q_STATUS and the queue name, and no optional parameters. The reply message contains no data, not even the queue name. The reply message only contains data if the optional parameter QStatusAttrs is supplied. |
Problem Summary | If no optional parameters were supplied with the command the attributes to put into the reply message were not set. |
Problem Conclusion | Check whether any reply attributes have been requested after parsing the command message. If none, add the default reply attributes to the reply message. |
IY69885
|
Abstract | RUNNING OUT OF SEMAPHORES DOESN'T OUTPUT A USEFUL ERROR MESSAGE. |
Users Affected | Any users attempting to diagnose problems involving running out of semaphores. Platforms affected: All Unix |
Error Description | Running out of semaphores doesn't output a useful error message. This will typically be reported in the WMQ error logs, but a specific FDC would be clearer. Note that this is a clarity of diagnostics issue, not a functional error in WMQ. |
Problem Summary | No FDC was specifically coded for the situation of running out of semaphores. |
Problem Conclusion | Coded a specific FDC to report this problem. Other than dumping an FDC, this change does not modify the operation of WMQ. |
IY69883
|
Abstract | FFST WITH PROBE ID XC130003, COMMENT1 :- SIGSEGV AND ATMQUERYACTIVE IN MQM FUNCTION STACK. |
Users Affected | This problem has been observed on the HP-UX platform with TXSeries acting as an external transaction manager for WMQ. It is only possible for this problem to occur if an external transaction manager is involved. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
Error Description | A required WMQ agent process fails, causing applications to become disconnected from WMQ. An external transaction manager (such as TXSeries) is co-ordinating WMQ transactions. An FDC file is produced containing the following lines: +------------------------------------------ | WebSphere MQ First Failure Symptom Report | ========================================= ... | Component :- xehExceptionHandler ... | Program Name :- amqzlaa0_nd ... | Major Errorcode :- STOP ... | Comment1 :- SIGSEGV +----------------------------------------- MQM Function Stack zlaMainThread kpiTerminate apiTerminate atmQueryActive xcsFFST The failure is likely to be in combination with the failure, or unclean disconnection of a user application. |
Problem Summary | A set of circumstances had been entered where an application had terminated or disconnected from WMQ while a transaction (co-ordinated by an external transaction manager) remained associated with that thread of execution within WMQ. One or more transactions had been associated with that thread of execution but their association had been suspended. A failure occurred while WMQ was processing this list of associated or suspended transactions, which caused an inconsistent state within WMQ. This state lead to a subsequent function producing a SIGSEGV. |
Problem Conclusion | The WMQ code was changed to correctly process this list of transactions under these specific circumstances. |
IY69753
|
Abstract | HANG IN XIHQUERYTHREADENTRY ON SOLARIS |
Users Affected | This APAR only applies to the Solaris platform, and is generally only observed when a limit of file descriptors is reached by a WMQ application process. Platforms affected: Solaris |
Error Description | This problem is known to occur on Solaris when more than 256 file descriptors are in use prior to performing a client connection. However, other hangs which exhibit the stack trace shown below are likely to relate to this problem. This problem may be encountered in combination with a XY017001 FFST showing fopen failing with EMFILE in xufOpenIniRead. The external symptoms of this problem are a hung application process with a call stack similar to the following (as seen in pstack output): ----------------- lwp# 1 / thread# 1 -------------------- ff31f48c lwp_sema_wait ff2496dc _park ff2493a4 _swtch ff24ada0 _mutex_adaptive_lock ff24b834 pthread_mutex_lock ff145698 xihQueryThreadEntry ff127484 xcsBuildDumpPtr ff129228 xcsFFST ff17b054 xufOpenIniRead ff17ea14 xcsBrowseIniCallback fefd77e0 zutPreReadMachineIniFile fefd73c4 lpiObtainQMDetails fefc4714 DoConnect fefc4464 zstMQCONN ff3774e4 MQCONN 000109b4 main 000108b8 _start |
Problem Summary | If an fopen call fails while attempting to open a WMQ ini file during an MQCONN call,( for instance because Solaris specifies a maximum fd number of 255 which can be returned by an fopen call on 32bit platforms)then WMQ will dump an FFST. This happens very early in the MQCONN call, before some initialisation has been performed. There was a fault in the Solaris specific code which meant that these specific circumstances caused a function to exit while holding a process global WMQ lock. Subsequent attempts by WMQ to gain this lock, while dumping a second FFST, caused the process to hang when attempting to request this lock a second time. |
Problem Conclusion | The Solaris specific code was fixed to prevent the function in question (xihQueryThreadEntry) from returning while holding the lock. This prevents the hang condition and allows the FFST to be dumped successfully. However, the MQCONN call in the circumstances described above (O/S file descriptor limit reached) will still fail with 2195 MQRC_UNEXPECTED_ERROR as WMQ is unable to continue due to this O/S limit having been reached. |
IY69464
|
Abstract | WITH PIPELINING ENABLED, THE CHANNEL SYNCHRONISATION FILE MAY NOT BE CLOSED BY THE SECOND THREAD - NO EXTERNAL SYMPTOMS KNOWN. |
Users Affected | Users of pipelined channels, may need to apply a fix for this problem if they encounter otherwise-undiagnosed issues which might relate to the ending of the second thread of work. Platforms affected: All Unix |
Error Description | Due to a problem with the internal order of closedown of a second thread of work for a pipelined channel, the channel synchronisation file may not be closed. This is likely to result in a small (not particularly significant) memory leakage in concerned channel process. Note that in practice it is unlikely that this leakage will amount to a quantity that could cause a failure. It is not clear whether the failure to close the synchronisation file would have repercussions - it was not possible to generate a test case that had adverse consequences of this second thread shutdown internal anomaly. |
Problem Summary | Incorrect internal ordering of the closure operations necessary to fully and properly close down the second thread of work of a pipelined channel. |
Problem Conclusion | Corrected the ordering of the closure operations for the second thread of work. |
IY69385
|
Abstract | LDAP NAMING SERVICE NOT SUPPORTED ON AIX MQRC_NOT_AUTHORIZED RETURNED WHEN LDAP IS USED |
Users Affected | All WebSphere MQ operations on AIX where an LDAP naming service is used to perform user authentication. Platforms affected: AIX |
Error Description | On AIX only, if user authentication is via an LDAP naming service, WebSphere MQ does not find the user names and so can fail in a number of programs - crtmqm, strmqm, user application - with MQRC_NOT_AUTHORIZED or MQRC_SECURITY_ERROR. |
Problem Summary | The API used by WebSphere MQ to interrogate the user database does not support an LDAP naming service. |
Problem Conclusion | Use a different API which does support the LDAP naming service. At WebSphere MQ 5.3 the changes in the APAR have to be implemented by setting and exporting an environment variable in the shell from which the queue manager, or any WebSphere MQ process, is started. For example, in the kshell the command is: export MQS_USERATTR_API=YES At releases after 5.3 this is not necessary; the change is implemented by default. To revert to the previous behaviour, a different environment variable can be used: export MQS_GETGRENT_API=YES |
IY68875
|
Abstract | WEBSPHERE MQ IS NOT PROPERLY RE-OWNING A SPINLOCK FROM A DEAD OWNER. FFST PROBE ID: XC028018 IS GENERATED. |
Users Affected | The circumstances in which this problem arises are extreme, such as the death of important queue manager processes. The impact is slight - spurious "not owner" FDCs are dumped. Platforms affected: All Unix |
Error Description | Customer experienced an amqldmpa/xecL_E_NOT_OWNER (AMQ6125), followed by an AMQ6150 (xecL_W_LONG_LOCK_WAIT). The FFST showed a probe Id of XC028018. |
Problem Summary | WMQ attempts to recover as best it can from a situation where an important process dies holding a "spinlock". Some coded situations, whilst performing this recovery, may dump a spurious "not owner" FDC such as probe XC028018. |
Problem Conclusion | Corrected the recovery code to avoid dumping the spurious "not owner" FDCs. |
IY68798
|
Abstract | THE 2ND THREAD OF PIPELINED CHANNELS FAILS TO RETURN MESSAGES TO XMITQ WHEN CHANNEL FAILS, LEAVING XMITQ IN UNCOM(YES) STATUS. |
Users Affected | Customers with PipeLineLength=2 specified in the qm.ini/registry of the queue managers on both sides of the channel. Platforms affected: All Distributed |
Error Description | After successfully restarting a pipelined channel (and resolving the INDOUBT(YES) channel status) which experienced a communications failure resulting in a channel terminating abnormally and becoming in-doubt, messages remain stranded on the transmission queue in uncommitted status. This is signified by UNCOM(YES) in the output from a DISPLAY QSTATUS command for the XMITQ associated with the channel. |
Problem Summary | Pipelined channels have 2 units of work associated with the channel (2 separate threads). This allows the second thread to send a batch of messages while the first thread is preparing the unit of work associated with the first batch of messages. If the channel is broken after the first batch has been prepared, and the request for confirmation has been sent, but whilst the second thread is sending the second batch down the channel, then the first batch is in an in-doubt state (it has been prepared, but this has not been confirmed with the partner on the other side of the channel). The second batch is not in-doubt, as the unit of work has not been prepared and no confirmation request has been sent. However, the unit of work must be backed out so that all messages already sent as part of this batch are returned to the transmission queue. The problem was that the unit of work was not being backed out as part of the process of the channel thread disconnecting from WMQ, and was remaining in an unresolved state, leaving the messages on the transmission queue uncommitted. Only being resolved when the queue manager was restarted. |
Problem Conclusion | The code was altered so that the process of the channel thread disconnecting from WMQ caused the unit of work to be resolved corrected, and the messages to be returned to the transmission queue. |
IY68509
|
Abstract | CUSTOMER IS RECEIVING FDC WITH XC015001 FROM XCSFREEQUICKCELL. FIX FOR APAR IY60472 WAS SUPPOSED TO RESOLVE PROBLEM. |
Users Affected | Users performing large quantities of WMQ connections and disconnections, in conjunction with some applications exiting without disconnecting. Platforms affected: All Distributed |
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 fix for IY60472 did not completely fix this XC015001 form XCSFREEQUICKCELL. Whereas that fix has improved the situation, it has not fixed it in every case. |
Problem Conclusion | Completed the implementation of IY60472 to cover all cases where this situation can arise. |
IY68487
|
Abstract | USERIDS BETWEEN 9 AND 12 CHARACTERS ON UNIX WMQ CLIENTS ARE PASSED TO WMQ SERVER AS 'UNKNOWN'. |
Users Affected | Users with WMQ 5.3 client bound applications running on UNIX platforms under usernames with a length of 9 to 12 characters. Platforms affected: AIX,HP-UX,Linux,Linux/390,Solaris |
Error Description | WMQ 5.3 client applications on UNIX platforms pass usernames longer than 8 characters as UNKNOWN. UNKNOWN is then authenticated at the WMQ server and normally results in the application receiving 2035 MQRC_NOT_AUTHORIZED. This is unexpected behaviour as the 'User IDs' section in Chapter 7 of the WMQ 5.3 Clients book states: "On all other platforms and configurations, the maximum length for user IDs is 12 characters." where "On all other platforms" includes the UNIX platforms. |
Problem Summary | WMQ client bound applications imposed a limit on the length of usernames on the UNIX platforms of 8 characters. Usernames longer than 8 characters were replaced with 'UNKNOWN' and this value was flowed to the server. |
Problem Conclusion | The code was changed so that usernames between 9 and 12 characters in length are flowed to the WMQ server. Usernames longer than 12 characters in length are replaced with 'UNKNOWN'. |
IY67891
|
Abstract | MQ CLUSTER REPOSITORY PROCESS FAILS WITH PROBE ID RM220005 |
Users Affected | Users with clusters containing a large number of queue managers, or a large number of cluster objects. The startup of the queue manager, or a REFRESH CLUSTER on a full repository, may trigger the problem. Platforms affected: All Distributed |
Error Description | If the MQ cluster repository manager process (amqrrmfa) has to process a very large number of messages, for example due to a large number of cluster additions or deletions, it may fail with an FDC showing Probe Id RM220005 from the function rrmRepository and error messages like AMQ9510 or AMQ9511 ( Messages cannot be retrieved from/put to a queue ) with reason code 2024, AMQ9448 ( Repository manager stopping because of errors ), and AMQ9409 ( Repository manager ended abnormally ). The RM220005 FDC trace history should show an error code of lrcE_SYNCPOINT_LIMIT_REACHED. |
Problem Summary | The number of messages read from the cluster repository queue, or the number of messages written in response to a cluster command message, is more than the MAXUMSGS attribute of the queue manager. |
Problem Conclusion | Disable the checking of the maximum number of messages in a single Unit of Work for operations carried out by the repository manager process. |
IY67777
|
Abstract | AN UNINITIALIZED MUTEX WAS ACCESSED AS PART OF THE UNREGISTER OF THE SIGNAL HANDLER BECAUSE AMQ_SIGCHLD_SIGACTION WAS SET. |
Users Affected | Linux users with AMQ_SIGCHLD_SIGACTION set. Platforms affected: Linux |
Error Description | On a Linux system with AMQ_SIGCHLD_SIGACTION set, a queue manager cannot be created. There is an FDC with probe id XC130003 and stack: MQM Function Stack zslStartEC xcsExecProgram xcsUnregisterAsySigHandler xcsRequestThreadMutexSem xcsFFST The FDC comment field reports a SIGSEGV |
Problem Summary | There is a mutex which is not initialized for Linux. However, an attempt to access it is made (as part of the unregister of the signal handler) if the environment variable AMQ_SIGCHLD_SIGACTION is set. |
Problem Conclusion | This mutex is now initialized for Linux. |
IY67232
|
Abstract | SLOW MQ CHANNEL STARTUP/SHUTDOWN DUE TO STATUS TABLE LOCKING |
Users Affected | Customers using Requester (RQSTR) / Sender (SDR) channel pairs, with AdoptNewMCA parameters specified in the Channels stanza of their queue manager configuration. Platforms affected: All Distributed |
Error Description | Under certain unusual conditions one MQ channel which is starting up can lock the internal channel status table for a relatively long period of time. While this lock is held other channels which are starting or stopping will have to wait before updating their status. One effect is that many channel related commands in runmqsc may take seconds or minutes to complete. |
Problem Summary | This issue was caused by the MCA adoption logic in the specific circumstances where the SDR side of a RQSTR/SDR pair was initiated while the channel was in REQUESTING status. After the REQUESTING status was resolved, the adoption logic incorrectly assumed that a new SDR instance of the channel would start, after choosing not to adopt the MCA (due to the AdoptNewMCACheck=ADDRESS parameter). This caused attempts to open the XMITQ of the channel while holding the status table lock (for up to 60 seconds). |
Problem Conclusion | The MCA adoption logic was corrected, and the possibility of the status table being locked was removed. |
IY67176
|
Abstract | COMMAND SERVER CRASH WITH SIGSEGV XC130003 WHEN PROCESSING CHANNEL PCF COMMANDS WITH NO OAM. |
Users Affected | Users doing remote administration, and where the Object Authority Manager (OAM) has been disabled on the remote queue manager. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
Error Description | Disable the authorisation service, by removing the Authorization Service entries from qm.ini. If Explorer is then used to administer channel definitions and the logged-on user in Windows is not defined on the UNIX system the command server crashes with a SIGSEGV in pcmCheckChannelCmdAut. ADDITIONAL KEYWORDS: xcsGetpwnam xcsGetgrnam command server amqpcsea amqpcsea_d pcmCheckChannelCmdAut MQ Explorer mmc GUI remote admin administration SYSTEM.ADMIN.SVRCONN SEGV |
Problem Summary | The failure to find a userID was not tested when checking authority to access WMQ objects. |
Problem Conclusion | 1. Test whether a userID was found before continuing authority checks. 2. Determine if the OAM is enabled on the queue manager. If not, allow any userID to access WMQ objects without any authority checking. |
IY67021
Abstract | HANDLE LEAK IN JMS PRODUCING APPLICATION (2017- MQRC_HANDLE_NOT_AVAILABLE). |
Users Affected | All users using PERSISTENCE(HIGH) and null queue passed to a QueueSender. Platforms affected: All Distributed+Java |
Error Description | In JMS, when using PERSISTENCE(HIGH) and using a null queue creating the QueueSender, there's an inquire done to resolve the queue and set the NPMClass but the queue is never closed after the inquire, resulting in a handle leak. |
Problem Summary | Passing null to the QueueSender is acceptable, provided the send (queue, message) method is then used to send the message. When resolving the queue in a loop at each send, there is a possibility of a handle leak leading to the premature ending of the application after 254 messages for a JMSException MQJMS2007: failed to send message to MQ and a LinkedException of com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2017. 2017 is MQRC_HANDLE_NOT_AVAILABLE. |
Problem Conclusion | A check was done to resolve the queue, which left the queue open. It is now closed after the check. |
IC47044.
Abstract | SSL AUTHENTICATION WITH JMS REALTIME NODE FAILS FROM JMS CLIENT WHEN JDK1.4.2 IS USED AT CLIENT SIDE WITH LEGALARGUMENTEXCEPTION |
Users Affected | JMS PubSub client connecting to JMS RealTime node with SSL Authentication. Platforms affected: All Distributed (iSeries, all Unix and Windows) and +Java |
Error Description | When a JMS application running in JDK1.4.2 is used to connect to the JMS RealTime Node in EventBroker or WBIMB V5/V6 we have seen that the connection fails with IllegalArgumentException. This is seen when the customer uses JMS PubSub application to connect to JMS RealTime node in SSL mode. |
Problem Summary | The methods SSLSocket.setNeedClientAuth(boolean) and SSLSocket.setUseClientMode(boolean)from SSLSocket will throw IllegalArgumentException when used after Handshake. |
Problem Conclusion | After JDK1.4.2 the above methods started throwing exception if used after Handshake and now the code is changed to call these methods before the handshake. |
IC46239
|
Abstract | .NET INTERFACE THROWS UNCATCHABLE EXCEPTIONS |
Users Affected | All users of the WebSphere MQ dotnet (.NET) interface Platforms affected: Windows |
Error Description | Destructors for the .NET MQQueueManager and MQQueue throw exceptions and if these occur during garbage collection they can cause problems |
Problem Summary | In their destructors, an MQQueue object will try to close an open queue, and an MQQueueManager object will try to release its connection to the server. However, if these fail they may result in a thrown exception - This causes problems if the exception occurs during garbage collection as there is no easy way to catch it. |
Problem Conclusion | The MQQueueManager and MQQueue objects have been modified so that any exception generated by their underlying MQ operations are caught and not left as unhandled. |
IC46238
|
Abstract | CHANNEL TERMINATES ON CLIENT CONNECTED TO SERVER AT 5.3FP10 OR HIGHER WITH PROBE RM046002 FDCS - INVALID DATA FORMAT |
Users Affected | All users of the XMS client connecting via a 5.3 fix pack 10 client installation Platforms affected: All Distributed |
Error Description | At fix pack 10 a new check was added to the server to ensure that received data lengths are valid. However, it has exposed a problem with a specific client call whose length is miscalculated. After applying fix pack 10, the server now cuts an FDC RM046002 and terminates the channel when it notices the lengths are invalid. |
Problem Summary | A particular client API call results in a length miscalculation which if left unchecked could result in buffer overflows on the server. At fix pack 10 a change went into the product to validate the inbound lengths, and this highlighted that the call made by the XMS client supplies a length which is 12 bytes short. The check on the server recognizes a length miscalculation and terminates the channel. |
Problem Conclusion | The MQ client code has been modified so the particular API call made via the XMS client, correctly calculates its length and no longer fails when connected to a fixpack 10 or higher server. |
IC46074
|
Abstract | CLIENT CHANNEL TO Z/OS NEVER TIMES OUT AFTER A CONNECTION DROP |
Users Affected | All users of client channels to pre-v6 z/OS queue managers Platforms affected: All Distributed |
Error Description | A client channel is connected to a pre-V6 qmgr on z/OS. WebSphere MQ for z/OS 5.3.1 and below doesn't support heartbeats. Hence, if the client issues an MQGET with a long or indefinite wait, then the client side will sit looping in recvs indefinitely until a response is received or the socket becomes invalidated. The MQRCVBLKTO environment variable is not timing out the connection as it should. * Additional keywords: clntconn svrconn hang hung wait MQGET MQWI_UNLIMITED unlimited CSQX014E CSQX513E CSQX569E network outage 5655f1000 r300 r310 5.3.0 5.3.1 z/OS |
Problem Summary | MQRCVBLKTO is an undocumented tuning parameter and as such is not guaranteed in its operations. Currently however it only impacts channels who have a heartbeat configured, whereas client channels to z/OS have a heartbeat of zero. |
Problem Conclusion | MQRCVBLKTO has been modified so it also impacts channels with a zero heartbeat. Note that its operation is still undocumented and it is a tuning parameter which should be used with care. |
IC45894
|
Abstract | CLUSTER ADMINISTRATOR OR MQ MMCS HANGS WHEN AN MSCS CLUSTER CONTAINS MORE THAN QUEUE MANAGER RESOURCE OR CUSTOM SERVICE. |
Users Affected | Users using more than one MQ queue manager or a queue manager with custom services defined under MSCS control. Platforms affected: Windows |
Error Description | One or all of the Microsoft Cluster Service administration tool or the WebSphere MQ Services MMC or MQ Explorer MMC becomes unresponsive and is effectively hung. |
Problem Summary | A thread in the amqmsrvn process dies holding a critical section. Other threads performing work on behalf of the cluster administrator or MQ MMCs are then blocked waiting for the critical section, causing the hang symptoms. |
Problem Conclusion | Corrected thread locking in the amqmsrvn process. |
IC45877
|
Abstract | USING THE AMQMSRVN -REGSERVER COMMAND CAUSES THE USER ID SELF TO BE REMOVED FROM DEFAULT COM SECURITY ON WINDOWS 2003 |
Users Affected | Customers using WebSphere MQ 5.3 on Windows 2003 Platforms affected: Windows |
Error Description | On Windows 2003 running MQ 5.3, running the amqmsrvn -regserver command breaks the default COM security by removing the special user SELF from the list of users/group having default COM security permissions. MQ does not include SELF in the list of default users/groups where as it does include SYSTEM along with mqm. |
Problem Summary | On Windows 2003 running MQ 5.3, running the amqmsrvn -regserver command breaks the default COM security. The registry key which is affected is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole. While running the amqmsrvn -regserver command, MQ does not seem to honour the special user SELF (one among the well-known SIDs). Hence while creating the registry entry DefaultAccessPermission or DefaultLaunchPermission, if not present under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, MQ does not include SELF in the list of default users/groups whereas it does include SYSTEM along with mqm. |
Problem Conclusion | Fixed the problem by adding the user SELF to the list of users/group having the default COM security permissions. |
IC45816
|
Abstract | FDC FILES WITH PROBE IDS XC130031 AND HL081010 BUT NO MESSAGE WHEN THE LOGPATH IS SET INCORRECTLY. |
Users Affected | All users of WebSphere MQ. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
Error Description | When attempting to start a WebSphere MQ v5.3 queue manager the strmqm fails with two FDC files. One FDC shows there is a probe id XC130031 from process amqzfuma reporting an access violation with the stack showing: MQM Function Stack zfuTerminate zfuLockHashTable xllFifoLockRequest xcsAllocateQuickCell xcsFFST There is another FDC from amqzxma0 reporting probe id HL081010 from component mqlpgolf with a Minor Errorcode of hrcE_MQLO_FNEX. The trace showed that the queue manager was looking for amqhlctl.lfh in .../log/qmgrname/errors instead of .../log/qmgrname. We checked in the registry and found the log path was wrong in HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion\ Configuration\QueueManager\QM\Log. This resulted in a failure to start the queue manager. The problem was due to a change made by the customer to the log path but the diagnostics were not very helpful in pointing this out and some improvements in this area could help make the mistake easier to identify. In particular there was no error message written to help identify the problem. NOTE: The same failure could occur on other platforms if the qm.ini file is altered to point to the wrong LogPath in the Log: stanza. |
Problem Summary | If the LogPath in the qm.ini or registry is modified for a queue manager to point to a valid directory, but one which does not contain the log information, then the queue manager fails to start but the diagnostics are not clear. |
Problem Conclusion | MQ has been modified to ensure an AMQ6767 error message is issued should this condition arise, which highlights the fact that the log file header (amqhlctl.lfh) could not be found. |
IC45799
|
Abstract | PROBE XY051025, REPORTING DUPLICATE AMQXCS2.DLL FOUND REPORTED INCORRECTLY, AND THE PATH TO THE DUPLICATE COPY IS EMPTY |
Users Affected | All users of WebSphere MQSeries Platforms affected: Windows |
Error Description | Probe XY051025 is cut incorrectly reporting duplicate amqxcs2 files exist on the machine. In the data block dumped, the path to the copy in use is correct, but the path to the duplicate copy is empty. |
Problem Summary | There was a timing window whereby if two applications both were the first MQ related applications to run on the machine, and they both managed to go through a particular code check at the same time, then an incorrect FDC would report that there is a duplicate AMQXCS2.DLL on the machine, but the path to the second version would be empty. |
Problem Conclusion | MQ has been modified so the reported problem no longer occurs. |
IC45797
|
Abstract | .NET APPLICATION RUNNING ON MQ EXTENDED TRANSACTIONAL CLIENT (MQ XA CLIENT) THROWS ERROR 2354 I.E. MQRC_UOW_ENLISTMENT_ERROR |
Users Affected | All users having MQ XA Client on top of MQ Client who try to run an application which uses XA transactions. Platforms affected: Windows |
Error Description | Trying to run .NET application with MTS (MSDTC) on a system having MQ CLient + MQ Extended Transactional Client (MQ XA Client), throws the following errors - # The application throws an MQException with reason 2354 on the queue.Put() call (in the sample appl given in the 'Problem Recreation' section) # Just before the exception is thrown a pop up window appears with message: "msdtc.exe - Unable To Locate DLL : The dynamic link library AMQZST.dll could not be found in the specified path ...." # The windows application event log contains the message: "The XA Transaction Manager attempted to load the XA resource manager DLL. The call to LOADLIBRARY for the XA resource manager DLL failed ...." |
Problem Summary | The makefile for the XA build did not '#define MTS_XA_TYPE' for building the XA client components. This was causing the client application which was using MTS to pick up the server dll (amqmtmgr.dll), when it should have actually picked up the client dll (amqmtmgc.dll). The application searches for the server dll but since it is executing on a MQ client, it fails to locate the server dll. |
Problem Conclusion | To overcome this issue, the 'MTS_XA_TYPE_CLIENT' was appended in the 'Makefile.mq' file, which helped build the XA client components. |
IC45623
|
Abstract | THE CREATE QMGR WIZARD RESTRICTS THE MAXUMSGS PARAMETER VALUE TO 10,000 MESSAGES WHEN THE LIMIT SHOULD BE 999,999,999. |
Users Affected | All users of the MQ Explorer MMC GUI Platforms affected: Windows |
Error Description | The create queue manager wizard restricts the uncommitted messages to 10,000. The actual limit for uncommitted messages is 999,999,999. The workaround is to use the control command crtmqm using the -x flag to designate the number of uncommitted messages to its actual documented limit. |
Problem Summary | The MQ Explorer GUI configuration tool allows the maximum number of uncommitted messages to be specified, but restricts the range to 10,000 whereas it should be 999,999,999. |
Problem Conclusion | The MQ Explorer has been updated to allow a correct range of values for the number of uncommitted messages. |
IC45571
|
Abstract | INSTALLATION OF A FIX PACK ON TOP OF MQ 5.3 FAILS REPORTING COPY FAILED FOR FILE AMQXMS0N.DLL WITH RETURN CODE 1224. |
Users Affected | All users of WebSphere MQ installing fix packs. Platforms affected: Windows |
Error Description | Installation of a fix pack on top of MQ 5.3 fails reporting Copy failed for file amqxms0n.dll with return code 1224 (ERROR_USER_MAPPED_FILE). This problem is being caused by the DLL being loaded at some point by a process, the resources for the event messages are then mapped into the event viewer's address space and stay there even after the message being displayed is closed. |
Problem Summary | During install of a fix pack, MQ finds a file is not replaceable because part of is is still mapped into memory. This results in an install failure reporting in the log that the copy failed with return code 1224. This is similar to finding a file in use which would do the same, although the flag MQPINUSEOK should override that. In this case, the flag does not override the failure and it is not possible to install the fix pack |
Problem Conclusion | The fix pack installer has been modified to allow install when files are still part of a memory mapping. This may result in a reboot being requested at the end of install even though the check for locked files has been successful. The need for reboot is unavoidable. |
IC45516
|
Abstract | AMQMSRVN DOES NOT CHECK THE USER NAME SPECIFIED |
Users Affected | All users of WebSphere MQ and the amqmsrvn command Platforms affected: Windows |
Error Description | When running the command: amqmsrvn -user xxx -password yyy where 'xxx' is an invalid local/domain user name & 'yyy' the password, the command updates this information into the dcom setting without checking the validity of the user/password. |
Problem Summary | The command amqmsrvn -user ... -password ... fills the supplied information into the dcom configuration without a validation. Although ideally the password would be verified, this APAR adds in user name verification. |
Problem Conclusion | There is no simple Windows API by which we can validate both the user name and the password specified in the 'amqmsrvn' command. Hence as a partial solution, a check of the validity of the user name alone has been added. Should the user name be invalid we would pop-up a message box with a warning stating that the user name specified is not a valid local/domain account. However, this new check and pop-up can be overridden using the environment variable 'AMQMSRVN_NOCHECK'. If this is set as a system environment variable to any value it will disable the user name check. |
IC45414
|
Abstract | AMQZLAA0 USES 100% CPU WHILE LOADING A QUEUE WITH PERSISTENT AND NON-PERSISTENT MESSAGES |
Users Affected | All users of WebSphere MQ who mix persistent and non persistent messages on the same queue Platforms affected: All Distributed |
Error Description | Customer reporting 100% CPU usage each morning in amqzlaa0.exe. Slow queue loading - persistent and non-persistent messages. Applications hang while load completes. |
Problem Summary | When a queue is not used for a period of time, it may get unloaded. If it does, it will be reloaded on the next access, and the load will restore all the persistent messages first and then add in the non persistent messages. The algorithm for reloading the non-persistent messages was not optimal, and resulted in frequent walks through the complete message chain, which consumed disk i/o and CPU resource. |
Problem Conclusion | The algorithm for reloading a queue has been modified to optimize the reloading when the queue contains a mixture of persistent and non persistent messages. |
IC45158
|
Abstract | EVENT ID 1016 LOGGED BY PERFMON FOR LIBRARY AMQMPERF.DLL |
Users Affected | All Windows users of WebSphere MQ Platforms affected: Windows |
Error Description | Event id 1016 logged by perfmon for library amqmperf.dll. The data buffer created for the "MQSeriesServices" service in the ... amqmperf.dll library is not aligned on an 8-byte boundary. This may cause problems for applications that are trying to read the performance data buffer. Contact the manufacturer of this library of service to have this problem corrected or get a newer version of this library |
Problem Summary | A periodic warning is logged in the event viewer indicating that the MQSeries performance tokens are not 8 byte aligned. The warning is harmless and does not cause any problems to MQ. |
Problem Conclusion | The MQ Performance tokens have been modified to ensure all data passed back is aligned to an 8 byte boundary. |
IC45049
|
Abstract | WRONG ERROR MESSAGE (AMQ9658) WHEN AN EXPIRED CA CERTIFICATE ATTEMPTS TO VALIDATE A PERSONAL CERTIFICATE. |
Users Affected | Anyone using SSL on Windows if certificates are allowed to expire. Platforms affected: Windows |
Error Description | When an expired CA signer certificate(local to the box) attempts to validate a personal certificate, the wrong error message description is produced - . AMQ9658: "An invalid SSL certificate was received from the remote system." The error message AMQ9658 (above) should only be produced when there is a problem with the personal certificate. A different message should be produced in cases like this, where the problem lies with the CA signer certificate. |
Problem Summary | The error message AMQ9658 is the wrong error message for this problem as it refers to a remote certificate. The actual cause of the problem is an expired certificate on the local system i.e. the CA certificate which has been used to sign this remote certificate. |
Problem Conclusion | The AMQ9658 message in this instance has been replaced with AMQ9630: AMQ9630: An expired SSL certificate was loaded. EXPLANATION: An SSL certificate that was loaded was not corrupt, but failed validation checks on its date fields. The certificate has either expired, or its date is not valid yet (that is, the from date is later than today), or the validity date range is incorrect (for example, the to date is earlier than the from date). ACTION: Ensure that the specified SSL certificate has a valid expiry date. |
IC45004
|
Abstract | PERFORMANCE SLOW DOWNS AND TIMEOUTS WHILST USING A QUEUE STATUS MONITOR |
Users Affected | Users using WebSphere MQ server on Windows platforms and monitoring queue status of critical queues. Platforms affected: Windows |
Error Description | Some applications involve large numbers of clients putting requests to a remote queue, for example at mainframe, causing the transmission queue to the remote system to become a critical resource. On Windows platforms, the locking of the queue whilst queue status queries (eg. from the MMC Gui or other monitor applications) are satisfied, can cause client or application slow downs or blockages on accesses to the queue. |
Problem Summary | The problem was caused by the time taken to lookup user account information, needed for the query, whilst holding the queue locked. |
Problem Conclusion | The user account information is obtained after the queue lock is released. |
IC44759
|
Abstract | FDC WITH PROBE ID UN074001 SEEN WHEN RUNNING AMQMDAIN. |
Users Affected | This problem could occur only with the following set of amqmdain commands, - security permissions assigned to the Registry keys (regsec) - set the Tuning Parameters (reg QMgrName RegParams ) - imports definitions of custom services (cstmig) Platforms affected: Windows |
Error Description | The problem occurred when the following command was running in a loop of 200: amqmdain reg QMGR_NAME -c add -s Channels -v MaxActiveChannels=500 The following FDC was seen written by the amqmdain process that showed probe id UN074001 - with Arith 1340 |
Problem Summary | The return code coming back from amqmdain's registry securing code is 1340, ERROR_BAD_INHERITANCE_ACL. Whenever a user issues the amqmdain command, 6 ACEs are explicitly added to the DACL. The high level security function SetNamedSecurityInfo is then used to set the DACL back into the registry key. These functions don't merge the ACEs back into the ACL. |
Problem Conclusion | The amqmdain's function has been fixed so that it doesn't grow the DACL. |
IC44049
|
Abstract | INTERMITTENT ACCESS VIOLATIONS IN MTS OR COM+ APPLICATIONS |
Users Affected | WebSphere MQ users running applications under MTS or COM+ environments. Platforms affected: Windows |
Error Description | Access violation are seen intermittently in MQ MTS or COM+ applications or when MSDTC or Queue Managers are stopped. In the reported case the MSDTC had filled up such that it was no longer possible to enlist in transactions. |
Problem Summary | Locking code, protecting data shared between threads in these environments was incorrectly implemented. MSDTC and Queue Manager shutdowns were not correctly detected. |
Problem Conclusion | Locking operations have been corrected. |
IC43749
Abstract | SHIFT-OUT CHARACTER TRUNCATED WHEN MESSAGE DATA ENDS WITH DBCS |
Users Affected | All users using mixed EBCDIC DBCS/SBCS strings. Platforms affected: All Distributed+Java |
Error Description | A WebSphere MQ Java application is building an EBCDIC data message. A problem can occur when using DBCS characters or a mix of SBCS (Single Byte) and DBCS (Double Byte). If the message characters end with DBCS characters the SHIFT-OUT (x 0E ) is there to mark the beginning of the DBCS characters but the SHIFT-IN (x 0F )character is missing in the final message data. If the message data contains DBCS characters followed by SBCS characters then the SHIFT-IN character will be on the end of the DBCS string. |
Problem Summary | The problem is caused by the use of the JVM's OutputStreamWriter to do the conversion, followed by a copy of the resulting byte array. |
Problem Conclusion | The String is copied differently to preserve the SHIFT-IN mark |
96293
Abstract | MISSING INSTRUCTIONS FOR BUILDING XA SWITCH FILE FOR ORACLE 10G ON AIX PLATFORM. |
Users Affected | All users using Oracle 10G with WebSphere MQ on AIX Platform. Platforms affected: AIX |
Error Description | Missing Instructions for building XA Switch file for oracle 10G on AIX platform. |
Problem Summary | The AIX make file for oracle XA Switch file , had instructions missing for oracle 10G as can be seen below #--------------------------------------------------------------- # Oracle XA switch file #--------------------------------------------------------------- ORALIBS=-lclntsh -lm ORALIBPATH=-L $(ORACLE_HOME)/lib # Uncomment the following line to use Oracle9 # ORALIBPATH=-L $(ORACLE_HOME)/lib32 oraswit: xlc_r -e MQStart $(ORALIBPATH) $(ORALIBS) -o $@ oraswit.c -bE:xaswit.exp |
Problem Conclusion | Added the necessary comments for use with Oracle 10G #--------------------------------------------------------------- # Oracle XA switch file #--------------------------------------------------------------- ORALIBS=-lclntsh -lm ORALIBPATH=-L $(ORACLE_HOME)/lib # Uncomment the following line if using Oracle9 or Oracle 10G # ORALIBPATH=-L $(ORACLE_HOME)/lib32 oraswit: xlc_r -e MQStart $(ORALIBPATH) $(ORALIBS) -o $@ oraswit.c -bE:xaswit.exp |
95064
Abstract | XY132006 FROM XSTCREATEEXTENT OR XC035040 FROM XCSCREATETHREAD ON SLES9 WITH WMQ FOR LINUX FOR ZSERIES, V5.3 OR V6.0 |
Users Affected | Customers running WMQ V5.3 or WMQ V6.0 on a Linux for zSeries distribution based upon a Linux 2.6 kernel. Please see the SOE for your WebSphere MQ release for details of supported Linux for zSeries distributions. Platforms affected: Linux,Linux/390 |
Error Description | During lifecycle testing of WebSphere MQ for Linux for zSeries V5.3 on SUSE Linux Enterprise Server 9, under high load situations with many threads accessing WMQ concurrently, the following two FFSTs were observed: Probe Id :- XY132006 Component :- xstCreateExtent Probe Description :- AMQ6119: An internal WebSphere MQ error has occurred. Failed to attach shared memory segment: shmat (ShmId 0x0096801a)[rc=-1 errno=12] Cannot allocate memory) Probe Id :- XC035040 Component :- xcsCreateThread Probe Description :- AMQ6119: An internal WebSphere MQ error has occurred ('11 - Resource temporarily unavailable' from pthread_create.) These FFSTs represent the operating system function shmat failing with ENOMEM and the operating system function pthread_create failing with EAGAIN (which would be the outcome of an ENOMEM being encountered internally in pthread_create as this function cannot return ENOMEM). These failures would be expected to signify resource problems, but no such resource problems existed at the time the FFSTs were encountered. |
Problem Summary | The root cause of this issue was a bug in the Linux 2.6 kernel. This bug caused a wild growth in stack usage of WMQ processes when making valid calls to the operating system writev function to harden WMQ message data to the 'q' files contained under /var/mqm. The calls themselves completed successfully, so no loss of message integrity was observed, but the wild stack growth (from 30KB to 1GB approximately, in the test environment) caused subsequent operating system functions to fail with ENOMEM. This bug is not specific to the writev function, or to the Linux for zSeries s390 / s390x kernels. However, WMQ has only been observed to trigger the specific circumstances which expose this bug when calling writev on the Linux for zSeries platform. |
Problem Conclusion | The WMQ code on the Linux for zSeries platform has been changed to utilise the operating system write function in replacement for the operating system writev function, which is expected to have a negligible impact on performance. This does not represent a genuine fix for this issue, as utilising the write function does not bypass the kernel code which contains the bug. However, no circumstances have been observed in testing in which WMQ exposes the kernel bug while utilising the write operating system call. This workaround is contained in WebSphere MQ for Linux (zSeries) V6.0 and will is contained in WebSphere MQ for Linux for zSeries V5.3 fix pack 11. The kernel bug which represents the root cause of this issue is currently expected to be contained SLES9 SP2 RC3, and the Novell SUSE Linux reference number is 64857. This kernel bug is also evident in Red Hat Enterprise Server 4, although this platform was not supported by any current release of WebSphere MQ at the time this issue was observed. The Red Hat reference number for this issue is RIT74336. |
94168
Abstract | USING CRL WITH JMS, WITH REVOKED CERTIFICATES, THE FIRST CONNECT FAILS BUT FOLLOWING CONNECTS SUCCEED. |
Users Affected | Any customer who uses JMS Client. Platforms affected: iSeries,All Unix,Windows |
Error Description | This problem may be seen when the customer uses CRL to check for revoked certificates and the QueueManager has a revoked certificate. When the JMS client tries to connect to the QueueManager for the first time, the connection fails but subsequent connections succeed from the same ConnectionFactory. |
Problem Summary | When the CertStore is checked to get the information from the specified LDAP server, whenever the Exception is thrown because the LDAP server is not found, the Vector which is storing the list of CertStore is not set with NULL. So the connection call assumes that there is no CertStore entry for this connection. |
Problem Conclusion | Whenever the exception is thrown because of LDAP server is not found or for any other reason, the CertStore Vector is set with null value. |
94073
Abstract | XASWIT.MAK FILE WITH ORACLE 10G ON SOLARIS PLATFORM FOR USE WITH WMQ 5.3 + FIXPACK |
Users Affected | All users using oracle 10g on Solaris Platform with WMQ 5.3 + CSDXX Platforms affected: Solaris |
Error Description | In Oracle-10g for Solaris there is 64-bit and 32-bit libraries available.Hence the problem in building oraswit file , as the default settings points to 64-bit libraries in xasiwt.mak file provided in FP9. |
Problem Summary | In Oracle-10g for Solaris there is 64-bit and 32-bit libraries available.The current xaswit.mak by default points to the $ORACLE_HOME/lib, which is 64-bit. This has to be changed to point to the 32-bit libraries for the oraswit file to be built properly and an addition of LIBDIR setting for further Oracle libraries to be picked up correctly. |
Problem Conclusion | Changes were made to the xaswit.mak file to include the instructions for using with Oracle 10G . |
93078
Abstract | COMPLETE SHIPMENT OF FIX FOR IC43892 |
Users Affected | Users of the amqsblst sample Platforms affected: All Unix,Windows |
Error Description | The fix for IC43892 in fix pack 10 only shipped the compiled object on Unix platforms. |
Problem Summary | The fix pack did not include the updated source for the sample. |
Problem Conclusion | This APAR ships the updated source for file amqsblst.c. |
92775
Abstract | USE CORRECT BIND OPTION WHEN PUTTING TO A CLUSTERED QUEUE MANAGER ALIAS. |
Users Affected | Users with more than one instance of a queue manager alias in a cluster, putting messages with default bind options, and the messages only travel to a single instance of the queue manager alias. Platforms affected: All Distributed |
Error Description | When the queue manager name passed into MQOPEN is a clustered queue manager alias, and the open options MQOO_AS_Q_DEF, the bind option is always set to BIND_ON_OPEN rather than the DEFBIND attribute on the queue manager alias. In other words, there is no workload balancing of messages put to multiple instances of queue manager aliases in a cluster when MQOPEN uses the default bind options. |
Problem Summary | The DEFBIND attribute of the queue manager alias is not honoured. Instead, it is always treated as BIND_ON_OPEN. |
Problem Conclusion | Honour the DEFBIND attribute. |
92560
Abstract | AMQTSIVT (MTS/COM+ IVT PROGRAM) MAY FAIL ON WINDOWS XP OR 2003 WITH RETURN CODE 0X80070057 |
Users Affected | All users of the MTS/COM+ sample ivt program AMQTSIVT Platforms affected: Windows |
Error Description | When the install and verification test program, AMQTSIVT, is run on Windows XP or 2003 then the transaction test may fail with a return code 0x80070057. |
Problem Summary | The IVT program defines a component and tries to register it as transactional, but the interface it calls seems to be broken in some Windows XP / 2003 systems. |
Problem Conclusion | The IVT program, AMQTSIVT, has been modified to work around the problem with the interface it uses to make its demo component transactional |
92451
Abstract | AMQMSRVN DOES NOT CHECK THE USER NAME SPECIFIED |
Users Affected | Users using amqmsrvn at the command line to change the dcom user id Platforms affected: Windows |
Error Description | When the customer runs the below command, amqmsrvn -user xxx -password yyy where 'xxx' is a invalid local/domain user name & 'yyy' the password The command updates the same into the dcom setting without checking the validity of the user/password |
Problem Summary | There was no userid checking in place |
Problem Conclusion | Checking the validity of the user id (local or domain)supplied to the amqmsrvn command has been implemented. A message box will pop up, if the user id is non-existing |
92244
Abstract | CHANNEL NAMELIST ALTERATION ON THE LOCAL PARTIAL REPOSITORY QUEUE MANAGER |
Users Affected | Users amending cluster details on partial repositories. Platforms affected: All Distributed |
Error Description | Occurrence of AMQ9430 message in the queue manager error logs. |
Problem Summary | Publishing of information to all queue managers in the cluster, where it should only have been published to full repository queue managers. |
Problem Conclusion | Determine whether a queue manger in the cluster is a full repository before publishing the information. |
91730
Abstract | A .NET APPLICATION TERMINATING MAY COMMIT MESSAGES WHICH ARE IN A UNIT OF WORK |
Users Affected | All dotnet (.NET) users Platforms affected: Windows |
Error Description | The MQQueueManager destructor calls MQDISC to break its connection from the queue manager. However, on distributed platforms this also has a side effect of committing any uncommitted messages. |
Problem Summary | A normal MQ application which fails to disconnect is treated as one which has abnormally terminated and any outstanding unit of work is rolled back. However, in the .NET environment, the MQQueueManager destructor gets called as the application terminates, which will do a disconnect and effectively commit any outstanding unit of work. |
Problem Conclusion | The MQQueueManager destructor has been modified to first issue an MQBACK and then an MQDISC, so any outstanding unit of work is rolled back before the application terminates |
89105
Abstract | UNABLE TO VIEW QUEUES BELONGING TO REMOTE QUEUE MANAGER THROUGH MMC. |
Users Affected | Customers using MMC to view queues of a remote queue manager. Platforms affected: All Distributed (iSeries, all Unix and Windows) |
Error Description | # When trying to view remote queues using MMC, AMQ4048 / AMQ4032 error message is encountered. # An FDC with Probe Description - 'AMQ7925: Message version 36 is not supported' is also cut. # The below AMQ8507 error message is logged in the MQ server error logs - AMQ8507: Command server MQPUT1 request for an undelivered message failed with reason code 2085. EXPLANATION: An attempt by the command server to put a message to the dead- letter queue, using MQPUT1, failed with reason code 2085. The MQDLH reason code was 2053. |
Problem Summary | When we click on the queues folder of the remote queue manager in the MMC, the MMC puts a 'Inquire Q' to the command server, and then the amqrmppa goes into an MQGET on the reply queue. It will then loop doing the MQGETs. The problem here was a timing window during the PUT and the GET, where the command server filled up the reply to queue (MQRC_Q_FULL). |
Problem Conclusion | The problem here was a timing window during the PUT and the GET, where the command server filled up the reply to queue (MQRC_Q_FULL). This is when we get the AMQ4032 pop up error message in the MMC explorer. Since the queue is full, the command server tries to put the message to the dead letter queue, but in this case, there is no DLQ defined for that queue manager. This is what causes the FDC to be cut and the AMQ8507 error message to be logged in the MQ server error logs. |
87457
Abstract | "INVALID PROPERTY FOR A COM.IBM.MQ.JMS.MQTOPICCONNECTIONFACTORY: MAXBUFFSIZE" IN WEBSPHERE MQ V5.3 FIX PACK 8 JMSADMIN. |
Users Affected | All users of the TopicConnectionFactory definition in JMSAdmin wishing to set MAXBUFFSIZE, where Transport(DIRECT) is set. Platforms affected: All Distributed+Java |
Error Description | If a user attempts to set the MAXBUFFSIZE attribute of a TopicConnectionFactory, where TRANSPORT is set to DIRECT, the following error is thrown. Invalid property for a com.ibm.mq.jms.MQTopicConnectionFactory: MAXBUFFSIZE Unable to create a valid object, please check the parameters supplied Invalid property for a TCF: MAXBUFFSIZE |
Problem Summary | The MAXBUFFSIZE definition was missing from a properties listing. |
Problem Conclusion | The MAXBUFFSIZE definition was included in the properties listing. |
[{"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":"PF025","label":"Platform Independent"},{"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
swg27007221