IBM Support

Problems fixed in fix pack 11 for WebSphere MQ V5.3

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

Click here to see this information via the internet

AbstractMQM400 SECURITY AUDIT JOURNAL ENTRIES PRODUCED WHEN USING OS V5R3 WITH USER *USER WITH NO SPECIAL AUTHORITIES
Users AffectedAll iSeries users performing WebSphere MQ 'WRK' commands such as WRKMQM, at OS/400 release V5R3M0.

Platforms affected:
iSeries
Error DescriptionA 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 SummaryCommands 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 ConclusionThe 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

Click here to see this information via the internet

AbstractMQM400- AMQ6993 MESSAGE INCORRECTLY GENERATED WHEN ENDMQM SUBMITTED IN BATCH
Users AffectedAll 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 DescriptionWhen 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 SummaryWhen 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 ConclusionWhen 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

Click here to see this information via the internet

AbstractMQM400: DIAGNOSTIC TESTFIX FOR PROVIDING ADDITIONAL DEBUGS INSIDE XCSWAITEVENTSEM.
Users AffectedThe 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 DescriptionxcsWaitEventSem 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 SummaryThis APAR is a diagnostic testfix PTF for additional debug statements.
Problem ConclusionPut additional trace statements and also dumped more information in the FDC files produced by the xcsWaitEventSem function.



SE19791

Click here to see this information via the internet

AbstractMQM400-CHANNEL PAIR REMAINS IN RETRYING/BINDING STATUS AFTER A NETWORK CHANGE AND DOES NOT RECOVER.
Users AffectedUser's using non-threaded receiver channels(AMQCRSTA) with AdoptNewMCA tuning parameters.

Platforms affected:
All Distributed
Error DescriptionMQ 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 SummaryThe 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 ConclusionThe Flag initialization and clearing of the flag and some additional checking have been introduced to prevent this problem.



SE19719

Click here to see this information via the internet

AbstractCHANNEL GETS DISCONNECTED WHEN COMMITTING A BATCH OF MESSAGES.
Users AffectedAll 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 DescriptionThe 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 SummaryThe 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 ConclusionIf the negotiated faplevel is less than 4, set BatchHeartbeat to 0.



SE19457

Click here to see this information via the internet

AbstractMQM400- REMOTE ADMINISTRATION OF ISERIES QUEUE MANAGER DROPS CONNECTION WHEN TRYING TO MAKE CHANGES TO WMQ OBJECTS.
Users AffectedAll 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 DescriptionThe 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 SummaryWhen 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 ConclusionCondition checking has been done to prevent the problem.



SE19391

Click here to see this information via the internet

AbstractISERIES GROUP PROFILE NAMES WITH A HASH IN THEM, FAIL TO BE PICKED UP FOR AUTHORITY CHECKING.
Users AffectedMQI API calls fail for users belonging to a group profile with hash in spite of having authority.

Platforms affected:
iSeries
Error DescriptionIf 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 SummaryOS/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 ConclusionChanges are carried out in the OAM program. Function to convert hash to "." is added while adding Group profiles in the authority checklist



SE19180

Click here to see this information via the internet

AbstractMQM400 WMQ 5.3 WRKMQMCHL DSPMQMCHL DISPLAYS THE QUEUE MANAGER NAME WITH SOME APPENDED GARBAGE CHARS.
Users AffectedUsers 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 DescriptionThe 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 SummaryIn 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 ConclusionA 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

Click here to see this information via the internet

AbstractWINDOWS CLIENT CRASHES WHEN TRYING TO CONNECT TO ISERIES QUEUE MANAGER USING SSL CLIENT CHANNEL DEFINITION CREATED ON ISERIES.
Users AffectedAll 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 DescriptionClient 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 SummaryThe client channel definition table created on iSeries is incompatible with PC platforms.
Problem ConclusionCode has been rewritten for client channel definition table of iSeries to be compatible with PC platforms.



IY74278

Click here to see this information via the internet

AbstractSIGSEGV FDC WITH AQHIMAGESIZE IN THE CALL STACK, AT FIX PACK 10 LEVEL.
Users AffectedThis problem may rarely occur for users running fix pack 10.

Platforms affected:
All Distributed (iSeries, all Unix and Windows)
Error DescriptionA 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 SummaryA change to correct one problem with the image size function has unfortunately introduced another problem.
Problem ConclusionCorrected the logic involving the image size calculation.



IY73014

Click here to see this information via the internet

AbstractBUILD UP OF AMQRMPPA PROCESSES
Users AffectedAny user running runmqlsr. The presence of an AMQ9213 message in the error logs may indicate this defect.

Platforms affected:
All Distributed
Error DescriptionMultiple amqrmppa processes build up on the system, even though there are no channels running.
Problem SummaryIf 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 ConclusionAmend the thread count correctly after the TCP error.



IY72849

AbstractMESSAGE CORRUPTION GETTING MESSAGES > 4K IN JAVA
Users AffectedAll users saving messages > 4K after multiple MQQueue.get() (using WMQ Java).

Platforms affected:
All Distributed+Java
Error DescriptionWhen 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 SummaryThe internal message buffer used at MQQueue.get() could get overwritten.
Problem ConclusionThe internal buffer does not get rewritten.



IY71943

Click here to see this information via the internet

AbstractCHANNEL AGENT THREAD ACCUMULATION
Users AffectedUsers 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 DescriptionThis 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 SummaryMissing logic to ensure the agent thread of a channel process is ended in all circumstances that a channel ends.
Problem ConclusionAdded the missing logic.



IY71335

Click here to see this information via the internet

AbstractCHANNEL REMAINS IN STOPPING STATUS AFTER STOP CHANNEL MODE(TERMINATE) COMMAND HAS BEEN ISSUED
Users AffectedThis 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 DescriptionAfter 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 SummaryThe 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 ConclusionThe 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

Click here to see this information via the internet

AbstractSIGSEGV XAOPEN XC130003 EXTENDED TRANSACTIONAL CLIENT
Users AffectedCustomers 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 DescriptionA 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 SummaryDuring 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 ConclusionInternally 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

Click here to see this information via the internet

AbstractDAMAGED TEMPORARY DYNAMIC QUEUE INADVERTENTLY ADDED TO POOL OF REUSABLE QUEUES AT STARTUP
Users AffectedUsers of dynamic queues, who experience or cause a corruption of a dynamic queue, are potentially exposed to this problem.

Platforms affected:
All Distributed
Error DescriptionA 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 SummaryThe queue manager avoids reusing damaged dynamic queues, but unfortunately the checks at queue manager restart were not sufficient to ensure this.
Problem ConclusionImproved 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

Click here to see this information via the internet

AbstractMQ LOGS FILL UP AND THE QUEUE MANAGER WILL NOT RESTART AFTER MANY AO084010 FDCS.
Users AffectedAll users who are operating at the limit of their storage.

Platforms affected:
All Distributed (iSeries, all Unix and Windows)
Error DescriptionThe 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 SummaryThe 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 ConclusionAs 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

Click here to see this information via the internet

AbstractINCORRECT MESSAGE MAY BE RETURNED TO MQGET WITH MQGMO_WAIT AND MQGMO_MSG_UNDER_CURSOR
Users AffectedAll 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 DescriptionThis 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 SummaryThis 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 ConclusionThe 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

Click here to see this information via the internet

AbstractFDC ZD008040 FROM ZDMOPENDEFERREDQ WHEN STARTING QUEUE MANAGER
Users AffectedPlatforms affected: All Distributed

Platforms affected:
All Distributed (iSeries, all Unix and Windows)
Error DescriptionAfter 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 SummaryThe 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 ConclusionThe 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

Click here to see this information via the internet

AbstractRCDMQIMG COMMAND TO RE-CREATE A DAMAGED OBJECT UNRESPONSIVE WITH FFSTS WITH PROBEID XC307070
Users AffectedThe 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 DescriptionThis 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 SummaryThe 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 ConclusionThe code was altered so that the infinite loop condition could not be entered.



IY69906

Click here to see this information via the internet

AbstractAMQTRC.FMT DOES NOT FORMAT A TRACE CORRECTLY ON A 64BIT KERNEL
Users AffectedUsers using WMQ for AIX will see wrong timestamp at the last line of the formatted trace.

Platforms affected:
AIX
Error DescriptionMQ 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 SummarySo far, T4 was being used for TRACE OFF. This would give problems in formatting traces gathered on 64-bit environment.
Problem ConclusionTo 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

Click here to see this information via the internet

AbstractPCF COMMAND MQCMD_INQUIRE_Q_STATUS DOES NOT RETURN ANY DATA IF ONLY THE DEFAULT PARAMETERS ARE SUPPLIED.
Users AffectedCommand Server, PCF messages.

Platforms affected:
All Distributed (iSeries, all Unix and Windows)
Error DescriptionFrom 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 SummaryIf no optional parameters were supplied with the command the attributes to put into the reply message were not set.
Problem ConclusionCheck whether any reply attributes have been requested after parsing the command message. If none, add the default reply attributes to the reply message.



IY69885

Click here to see this information via the internet

AbstractRUNNING OUT OF SEMAPHORES DOESN'T OUTPUT A USEFUL ERROR MESSAGE.
Users AffectedAny users attempting to diagnose problems involving running out of semaphores.

Platforms affected:
All Unix
Error DescriptionRunning 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 SummaryNo FDC was specifically coded for the situation of running out of semaphores.
Problem ConclusionCoded a specific FDC to report this problem. Other than dumping an FDC, this change does not modify the operation of WMQ.



IY69883

Click here to see this information via the internet

AbstractFFST WITH PROBE ID XC130003, COMMENT1 :- SIGSEGV AND ATMQUERYACTIVE IN MQM FUNCTION STACK.
Users AffectedThis 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 DescriptionA 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 SummaryA 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 ConclusionThe WMQ code was changed to correctly process this list of transactions under these specific circumstances.



IY69753

Click here to see this information via the internet

AbstractHANG IN XIHQUERYTHREADENTRY ON SOLARIS
Users AffectedThis 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 DescriptionThis 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 SummaryIf 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 ConclusionThe 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

Click here to see this information via the internet

AbstractWITH PIPELINING ENABLED, THE CHANNEL SYNCHRONISATION FILE MAY NOT BE CLOSED BY THE SECOND THREAD - NO EXTERNAL SYMPTOMS KNOWN.
Users AffectedUsers 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 DescriptionDue 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 SummaryIncorrect internal ordering of the closure operations necessary to fully and properly close down the second thread of work of a pipelined channel.
Problem ConclusionCorrected the ordering of the closure operations for the second thread of work.



IY69385

Click here to see this information via the internet

AbstractLDAP NAMING SERVICE NOT SUPPORTED ON AIX MQRC_NOT_AUTHORIZED RETURNED WHEN LDAP IS USED
Users AffectedAll WebSphere MQ operations on AIX where an LDAP naming service is used to perform user authentication.

Platforms affected:
AIX
Error DescriptionOn 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 SummaryThe API used by WebSphere MQ to interrogate the user database does not support an LDAP naming service.
Problem ConclusionUse 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

Click here to see this information via the internet

AbstractWEBSPHERE MQ IS NOT PROPERLY RE-OWNING A SPINLOCK FROM A DEAD OWNER. FFST PROBE ID: XC028018 IS GENERATED.
Users AffectedThe 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 DescriptionCustomer 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 SummaryWMQ 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 ConclusionCorrected the recovery code to avoid dumping the spurious "not owner" FDCs.



IY68798

Click here to see this information via the internet

AbstractTHE 2ND THREAD OF PIPELINED CHANNELS FAILS TO RETURN MESSAGES TO XMITQ WHEN CHANNEL FAILS, LEAVING XMITQ IN UNCOM(YES) STATUS.
Users AffectedCustomers with PipeLineLength=2 specified in the qm.ini/registry of the queue managers on both sides of the channel.

Platforms affected:
All Distributed
Error DescriptionAfter 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 SummaryPipelined 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 ConclusionThe 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

Click here to see this information via the internet

AbstractCUSTOMER IS RECEIVING FDC WITH XC015001 FROM XCSFREEQUICKCELL. FIX FOR APAR IY60472 WAS SUPPOSED TO RESOLVE PROBLEM.
Users AffectedUsers performing large quantities of WMQ connections and disconnections, in conjunction with some applications exiting without disconnecting.

Platforms affected:
All Distributed
Error DescriptionDuring 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 SummaryThe 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 ConclusionCompleted the implementation of IY60472 to cover all cases where this situation can arise.



IY68487

Click here to see this information via the internet

AbstractUSERIDS BETWEEN 9 AND 12 CHARACTERS ON UNIX WMQ CLIENTS ARE PASSED TO WMQ SERVER AS 'UNKNOWN'.
Users AffectedUsers 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 DescriptionWMQ 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 SummaryWMQ 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 ConclusionThe 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

Click here to see this information via the internet

AbstractMQ CLUSTER REPOSITORY PROCESS FAILS WITH PROBE ID RM220005
Users AffectedUsers 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 DescriptionIf 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 SummaryThe 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 ConclusionDisable the checking of the maximum number of messages in a single Unit of Work for operations carried out by the repository manager process.



IY67777

Click here to see this information via the internet

AbstractAN UNINITIALIZED MUTEX WAS ACCESSED AS PART OF THE UNREGISTER OF THE SIGNAL HANDLER BECAUSE AMQ_SIGCHLD_SIGACTION WAS SET.
Users AffectedLinux users with AMQ_SIGCHLD_SIGACTION set.

Platforms affected:
Linux
Error DescriptionOn 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 SummaryThere 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 ConclusionThis mutex is now initialized for Linux.



IY67232

Click here to see this information via the internet

AbstractSLOW MQ CHANNEL STARTUP/SHUTDOWN DUE TO STATUS TABLE LOCKING
Users AffectedCustomers 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 DescriptionUnder 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 SummaryThis 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 ConclusionThe MCA adoption logic was corrected, and the possibility of the status table being locked was removed.



IY67176

Click here to see this information via the internet

AbstractCOMMAND SERVER CRASH WITH SIGSEGV XC130003 WHEN PROCESSING CHANNEL PCF COMMANDS WITH NO OAM.
Users AffectedUsers 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 DescriptionDisable 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 SummaryThe failure to find a userID was not tested when checking authority to access WMQ objects.
Problem Conclusion1. 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

AbstractHANDLE LEAK IN JMS PRODUCING APPLICATION (2017- MQRC_HANDLE_NOT_AVAILABLE).
Users AffectedAll users using PERSISTENCE(HIGH) and null queue passed to a QueueSender.

Platforms affected:
All Distributed+Java
Error DescriptionIn 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 SummaryPassing 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 ConclusionA check was done to resolve the queue, which left the queue open. It is now closed after the check.



IC47044.
AbstractSSL AUTHENTICATION WITH JMS REALTIME NODE FAILS FROM JMS CLIENT WHEN JDK1.4.2 IS USED AT CLIENT SIDE WITH LEGALARGUMENTEXCEPTION
Users AffectedJMS PubSub client connecting to JMS RealTime node with SSL Authentication.

Platforms affected:
All Distributed (iSeries, all Unix and Windows) and +Java
Error DescriptionWhen 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 SummaryThe methods SSLSocket.setNeedClientAuth(boolean) and SSLSocket.setUseClientMode(boolean)from SSLSocket will throw IllegalArgumentException when used after Handshake.
Problem ConclusionAfter 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

Click here to see this information via the internet

Abstract.NET INTERFACE THROWS UNCATCHABLE EXCEPTIONS
Users AffectedAll users of the WebSphere MQ dotnet (.NET) interface

Platforms affected:
Windows
Error DescriptionDestructors for the .NET MQQueueManager and MQQueue throw exceptions and if these occur during garbage collection they can cause problems
Problem SummaryIn 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 ConclusionThe 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

Click here to see this information via the internet

AbstractCHANNEL TERMINATES ON CLIENT CONNECTED TO SERVER AT 5.3FP10 OR HIGHER WITH PROBE RM046002 FDCS - INVALID DATA FORMAT
Users AffectedAll users of the XMS client connecting via a 5.3 fix pack 10 client installation

Platforms affected:
All Distributed
Error DescriptionAt 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 SummaryA 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 ConclusionThe 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

Click here to see this information via the internet

AbstractCLIENT CHANNEL TO Z/OS NEVER TIMES OUT AFTER A CONNECTION DROP
Users AffectedAll users of client channels to pre-v6 z/OS queue managers

Platforms affected:
All Distributed
Error DescriptionA 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 SummaryMQRCVBLKTO 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 ConclusionMQRCVBLKTO 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

Click here to see this information via the internet

AbstractCLUSTER ADMINISTRATOR OR MQ MMCS HANGS WHEN AN MSCS CLUSTER CONTAINS MORE THAN QUEUE MANAGER RESOURCE OR CUSTOM SERVICE.
Users AffectedUsers using more than one MQ queue manager or a queue manager with custom services defined under MSCS control.

Platforms affected:
Windows
Error DescriptionOne 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 SummaryA 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 ConclusionCorrected thread locking in the amqmsrvn process.



IC45877

Click here to see this information via the internet

AbstractUSING THE AMQMSRVN -REGSERVER COMMAND CAUSES THE USER ID SELF TO BE REMOVED FROM DEFAULT COM SECURITY ON WINDOWS 2003
Users AffectedCustomers using WebSphere MQ 5.3 on Windows 2003

Platforms affected:
Windows
Error DescriptionOn 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 SummaryOn 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 ConclusionFixed the problem by adding the user SELF to the list of users/group having the default COM security permissions.



IC45816

Click here to see this information via the internet

AbstractFDC FILES WITH PROBE IDS XC130031 AND HL081010 BUT NO MESSAGE WHEN THE LOGPATH IS SET INCORRECTLY.
Users AffectedAll users of WebSphere MQ.

Platforms affected:
All Distributed (iSeries, all Unix and Windows)
Error DescriptionWhen 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 SummaryIf 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 ConclusionMQ 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

Click here to see this information via the internet

AbstractPROBE XY051025, REPORTING DUPLICATE AMQXCS2.DLL FOUND REPORTED INCORRECTLY, AND THE PATH TO THE DUPLICATE COPY IS EMPTY
Users AffectedAll users of WebSphere MQSeries

Platforms affected:
Windows
Error DescriptionProbe 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 SummaryThere 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 ConclusionMQ has been modified so the reported problem no longer occurs.



IC45797

Click here to see this information via the internet

Abstract.NET APPLICATION RUNNING ON MQ EXTENDED TRANSACTIONAL CLIENT (MQ XA CLIENT) THROWS ERROR 2354 I.E. MQRC_UOW_ENLISTMENT_ERROR
Users AffectedAll users having MQ XA Client on top of MQ Client who try to run an application which uses XA transactions.

Platforms affected:
Windows
Error DescriptionTrying 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 SummaryThe 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 ConclusionTo overcome this issue, the 'MTS_XA_TYPE_CLIENT' was appended in the 'Makefile.mq' file, which helped build the XA client components.



IC45623

Click here to see this information via the internet

AbstractTHE CREATE QMGR WIZARD RESTRICTS THE MAXUMSGS PARAMETER VALUE TO 10,000 MESSAGES WHEN THE LIMIT SHOULD BE 999,999,999.
Users AffectedAll users of the MQ Explorer MMC GUI

Platforms affected:
Windows
Error DescriptionThe 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 SummaryThe 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 ConclusionThe MQ Explorer has been updated to allow a correct range of values for the number of uncommitted messages.



IC45571

Click here to see this information via the internet

AbstractINSTALLATION OF A FIX PACK ON TOP OF MQ 5.3 FAILS REPORTING COPY FAILED FOR FILE AMQXMS0N.DLL WITH RETURN CODE 1224.
Users AffectedAll users of WebSphere MQ installing fix packs.

Platforms affected:
Windows
Error DescriptionInstallation 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 SummaryDuring 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 ConclusionThe 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

Click here to see this information via the internet

AbstractAMQMSRVN DOES NOT CHECK THE USER NAME SPECIFIED
Users AffectedAll users of WebSphere MQ and the amqmsrvn command

Platforms affected:
Windows
Error DescriptionWhen 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 SummaryThe 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 ConclusionThere 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

Click here to see this information via the internet

AbstractAMQZLAA0 USES 100% CPU WHILE LOADING A QUEUE WITH PERSISTENT AND NON-PERSISTENT MESSAGES
Users AffectedAll users of WebSphere MQ who mix persistent and non persistent messages on the same queue

Platforms affected:
All Distributed
Error DescriptionCustomer reporting 100% CPU usage each morning in amqzlaa0.exe. Slow queue loading - persistent and non-persistent messages. Applications hang while load completes.
Problem SummaryWhen 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 ConclusionThe 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

Click here to see this information via the internet

AbstractEVENT ID 1016 LOGGED BY PERFMON FOR LIBRARY AMQMPERF.DLL
Users AffectedAll Windows users of WebSphere MQ

Platforms affected:
Windows
Error DescriptionEvent 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 SummaryA 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 ConclusionThe MQ Performance tokens have been modified to ensure all data passed back is aligned to an 8 byte boundary.



IC45049

Click here to see this information via the internet

AbstractWRONG ERROR MESSAGE (AMQ9658) WHEN AN EXPIRED CA CERTIFICATE ATTEMPTS TO VALIDATE A PERSONAL CERTIFICATE.
Users AffectedAnyone using SSL on Windows if certificates are allowed to expire.

Platforms affected:
Windows
Error DescriptionWhen 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 SummaryThe 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 ConclusionThe 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

Click here to see this information via the internet

AbstractPERFORMANCE SLOW DOWNS AND TIMEOUTS WHILST USING A QUEUE STATUS MONITOR
Users AffectedUsers using WebSphere MQ server on Windows platforms and monitoring queue status of critical queues.

Platforms affected:
Windows
Error DescriptionSome 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 SummaryThe problem was caused by the time taken to lookup user account information, needed for the query, whilst holding the queue locked.
Problem ConclusionThe user account information is obtained after the queue lock is released.



IC44759

Click here to see this information via the internet

AbstractFDC WITH PROBE ID UN074001 SEEN WHEN RUNNING AMQMDAIN.
Users AffectedThis 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 DescriptionThe 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 SummaryThe 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 ConclusionThe amqmdain's function has been fixed so that it doesn't grow the DACL.



IC44049

Click here to see this information via the internet

AbstractINTERMITTENT ACCESS VIOLATIONS IN MTS OR COM+ APPLICATIONS
Users AffectedWebSphere MQ users running applications under MTS or COM+ environments.

Platforms affected:
Windows
Error DescriptionAccess 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 SummaryLocking code, protecting data shared between threads in these environments was incorrectly implemented. MSDTC and Queue Manager shutdowns were not correctly detected.
Problem ConclusionLocking operations have been corrected.



IC43749


AbstractSHIFT-OUT CHARACTER TRUNCATED WHEN MESSAGE DATA ENDS WITH DBCS
Users AffectedAll users using mixed EBCDIC DBCS/SBCS strings.

Platforms affected:
All Distributed+Java
Error DescriptionA 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 SummaryThe 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 ConclusionThe String is copied differently to preserve the SHIFT-IN mark



96293
AbstractMISSING INSTRUCTIONS FOR BUILDING XA SWITCH FILE FOR ORACLE 10G ON AIX PLATFORM.
Users AffectedAll users using Oracle 10G with WebSphere MQ on AIX Platform.

Platforms affected:
AIX
Error DescriptionMissing Instructions for building XA Switch file for oracle 10G on AIX platform.
Problem SummaryThe 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 ConclusionAdded 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
AbstractXY132006 FROM XSTCREATEEXTENT OR XC035040 FROM XCSCREATETHREAD ON SLES9 WITH WMQ FOR LINUX FOR ZSERIES, V5.3 OR V6.0
Users AffectedCustomers 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 DescriptionDuring 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 SummaryThe 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 ConclusionThe 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
AbstractUSING CRL WITH JMS, WITH REVOKED CERTIFICATES, THE FIRST CONNECT FAILS BUT FOLLOWING CONNECTS SUCCEED.
Users AffectedAny customer who uses JMS Client.

Platforms affected:
iSeries,All Unix,Windows
Error DescriptionThis 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 SummaryWhen 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 ConclusionWhenever 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
AbstractXASWIT.MAK FILE WITH ORACLE 10G ON SOLARIS PLATFORM FOR USE WITH WMQ 5.3 + FIXPACK
Users AffectedAll users using oracle 10g on Solaris Platform with WMQ 5.3 + CSDXX

Platforms affected:
Solaris
Error DescriptionIn 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 SummaryIn 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 ConclusionChanges were made to the xaswit.mak file to include the instructions for using with Oracle 10G .



93078
AbstractCOMPLETE SHIPMENT OF FIX FOR IC43892
Users AffectedUsers of the amqsblst sample

Platforms affected:
All Unix,Windows
Error DescriptionThe fix for IC43892 in fix pack 10 only shipped the compiled object on Unix platforms.
Problem SummaryThe fix pack did not include the updated source for the sample.
Problem ConclusionThis APAR ships the updated source for file amqsblst.c.



92775
AbstractUSE CORRECT BIND OPTION WHEN PUTTING TO A CLUSTERED QUEUE MANAGER ALIAS.
Users AffectedUsers 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 DescriptionWhen 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 SummaryThe DEFBIND attribute of the queue manager alias is not honoured. Instead, it is always treated as BIND_ON_OPEN.
Problem ConclusionHonour the DEFBIND attribute.



92560
AbstractAMQTSIVT (MTS/COM+ IVT PROGRAM) MAY FAIL ON WINDOWS XP OR 2003 WITH RETURN CODE 0X80070057
Users AffectedAll users of the MTS/COM+ sample ivt program AMQTSIVT

Platforms affected:
Windows
Error DescriptionWhen 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 SummaryThe 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 ConclusionThe IVT program, AMQTSIVT, has been modified to work around the problem with the interface it uses to make its demo component transactional



92451
AbstractAMQMSRVN DOES NOT CHECK THE USER NAME SPECIFIED
Users AffectedUsers using amqmsrvn at the command line to change the dcom user id

Platforms affected:
Windows
Error DescriptionWhen 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 SummaryThere was no userid checking in place
Problem ConclusionChecking 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
AbstractCHANNEL NAMELIST ALTERATION ON THE LOCAL PARTIAL REPOSITORY QUEUE MANAGER
Users AffectedUsers amending cluster details on partial repositories.

Platforms affected:
All Distributed
Error DescriptionOccurrence of AMQ9430 message in the queue manager error logs.
Problem SummaryPublishing of information to all queue managers in the cluster, where it should only have been published to full repository queue managers.
Problem ConclusionDetermine whether a queue manger in the cluster is a full repository before publishing the information.



91730
AbstractA .NET APPLICATION TERMINATING MAY COMMIT MESSAGES WHICH ARE IN A UNIT OF WORK
Users AffectedAll dotnet (.NET) users

Platforms affected:
Windows
Error DescriptionThe 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 SummaryA 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 ConclusionThe 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
AbstractUNABLE TO VIEW QUEUES BELONGING TO REMOTE QUEUE MANAGER THROUGH MMC.
Users AffectedCustomers 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 SummaryWhen 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 ConclusionThe 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 AffectedAll users of the TopicConnectionFactory definition in JMSAdmin wishing to set MAXBUFFSIZE, where Transport(DIRECT) is set.

Platforms affected:
All Distributed+Java
Error DescriptionIf 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 SummaryThe MAXBUFFSIZE definition was missing from a properties listing.
Problem ConclusionThe 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

Document Information

Modified date:
17 June 2018

UID

swg27007221