Product Readmes
Abstract
This document describes the fixes shipped in WebSphere MQ V5.3 fix pack 9.
Content
Table of Contents
APARs in Fixpack 09
- SE17209
MQM400 DUPLICATE RC3029 ENTRIES IN CMQCFG RPG COPY FILE - SE16933
MQM400-MSGMCH0601 FDC XY353001 IN XCSALLOCATEQUICKCELL CAUSING AGENT CRASH AFTER A TIMING PROBLEM WITHIN XLLSPINLOCKRELEASE - SE16901
MQM400 MAKE FDC FILE MORE INFORMATIVE BY PROVIDING THE EXPECTED CAUSE BEHIND (3489) ENOSYSRSC -RESOURCE PROBLEM FAILURE. - SE16893
MQM400 USER PROFILE NAMES BEGINNING WITH # FAIL IN WRKMQMAUTD PANEL. - SE16730
MQM400 QUEUE MANAGER AGENT JOB (AMQZLAA0) CONSUMES HIGH CPU IN RFIALLOCCACHE/RFXLINK WHEN MQOPEN FAILS CONTINUALLY - SE16713
MQM400-UNABLE TO RESTART QUEUE MANAGER WHEN END CONNECTED JOBS (ENDCCTJOB) SPECIFIED FOR ENDMQM. - SE16473
MQM400 STRMQM_R JOB HANGS AFTER RUNNING COMMAND ENDMQM WITH ENDCCTJOB(*YES) AND WITH SUBSYSTEM QMQM NOT ACTIVE - SE16073
AMQ8146 ERROR OCCURS WHEN USING STRMQMMQSC COMMAND WITH THE WAIT(0) PARAMETER AT CSD06 - SE16014
MQM400-MSGMCH0601 FDC XY353001 WHEN NUMBER OF JOURNAL RECEIVERS IN THE QUEUE MANAGER LIBRARY EXCEEDS OUR IMPOSED LIMIT OF 512. - SE15393
MQM400: ONCE F4 IS PRESSED ON MQSC COMMAND SCREEN, FURTHER ATTEMPTS TO GET USE MQSC FAIL. - SA96244
CLUSQMGR FIELD OF CLUSTER QUEUE CREATED USING CRTMQMQ IS INVALID WHEN MESSAGE QUEUE MANAGER NAME IS *DFT - IY65599
INCORRECT TRUNCATION OF A QUEUE GREATER THAN 2GB IN SIZE, CAUSING READ BEYOND END OF FILE AND LEADING TO A DAMAGED OBJECT - IY65279
ALLOWING APPLICATIONS AND CICS SWITCH LOAD FILE TO NOT NEED A RE-LINK POST FIX PACK 5 - IY63499
LOG FULL CONDITION IN A RCDMQIMG OPERATION, REPORTED BY PROBE HL010004 FDC, MAY CAUSE UNRECOVERABLE QUEUE CORRUPTION. - IY63403
WMQ5.3 TRACE HEADER IS FORMATTED INCORRECTLY. - IY63316
C++ APPLICATION CRASHES WITH A SEGMENTATION VIOLATION AFTER APPLYING INTERIM FIX FOR LINUX - IY62636
SETTING MAXMSGL OF A CHANNEL TO 0, SHOULD MEAN THE MAXMSGL OF THE QUEUE MANAGER IS USED. - IY62101
XC130004 FOR SIGSEGV OUT OF KPISPIADOPTUSER INSTEAD OF 2035 MQRC_NOT_AUTHORIZED - IY61664
CLEANUP THREAD RETURNS 2058 WHEN JMS CLIENT CONNECTION TO DEFAULT QUEUE MANAGER (NO QMNAME GIVEN IN TCF). - IY60992
XC130003 FDC AFTER AT061010 FDC UNDER THE FUNCTION ATXSTART - IY60843
MESSAGE SELECTORS THAT CONTAIN THE <> (NOT EQUAL) OPERATOR DO NOT WORK. - IY60786
FDCS FROM *MEMBLOCK COMPONENTS WITH PROBE ID LIKE XY398006 WHEN ENQUIRING QUEUE HANDLE INFORMATION. - IY60765
JMS SPEC STATES THAT A CLOSE TERMINATES ALL PENDING MESSAGE RECEIVES ON THE CONNECTION WHEN A SESSION.CLOSE() IS INVOKED. - IY60736
POTENTIAL QUEUE MANAGER HANG ON AIX, OR A SPURIOUS SEMAPHORE POST ON AIX/LINUX, IF AN APPLICATION IS KILLED DURING MQDISC - IY60590
QUEUE MANAGER HANGS AFTER ALTER QL(SYSTEM.AUTH.DATA.QUEUE) QDPHIEV(ENABLED) - IY60472
XC015001 FROM XCSFREEQUICKCELL SHOWING XECS_E_BLOCK_ALREADY_FREE - IY60448
SPURIOUS AMQ9546 ERROR OUTPUT ON STARTING CHANNEL FROM RUNMQSC - IY60106
.FDC FILE CUT WITH HL142100 FROM MQLOOPEN UPON CRTMQM. - IY59854
HEAP MEMORY LEAK WITH EACH THREAD CREATED WHEN TRACING IS ON. - IY59661
OUTPUT FROM RCDMQIMG -T ALL DOES NOT REPORT SYNCFILE RECORDED - IY58536
AL036002 FDC IN ALSRECORDCHECKPOINT: ERROR 13, PERMISSION DENIED - IY58535
QUEUE MANAGER HANG FOLLOWING AO175001 FDCS FROM AOULOCKQHANDLE. - IY57841
NL TO LF CONVERSION DOES NOT WORK TO EUC CODEPAGES. - IY57820
SSL CHANNELS BETWEEN WINDOWS AND OTHER PLATFORMS FAIL WITH ERROR MESSAGE AMQ9636 IF SSLPEER HAS MORE THAN ONE OU. - IY57545
CLIENT APP CREATES NON-MQM UID:GID IPC RESOURCES/FAILS WITH 2059 AFTER FIX FOR IY54058 IS APPLIED. - IY52823
INSTALLATION OR CONTROL COMMANDS FAIL ON LINUX WITHOUT ENVIRONMENT VARIABLE LD_ASSUME_KERNEL SET - IC43531
CLIENT APPLICATIONS TRAP WHEN TRACING IS ENABLED UNDER WMQ 5.3 CSD08 - IC43446
CLUSTERS: AMQ9248 WHEN TRYING TO START A CLUSTER SENDER CHANNEL AFTER APPLYING FIX PACK 8 - IC42742
APPLICATION RECEIVES A 2009 MQRC_CONNECTION_BROKEN OCCASIONALLY EVEN THOUGH APPLICATION STILL ALIVE. - IC42634
COMPILING C++ PROGRAM RESULTS IN UNDEFINED SYMBOL ERROR IMQCHL::SETLOCALADDRESS(CONST CHAR*) - IC42618
THE DIRECTORY PERMISSIONS ARE NOT INITIALIZED FOR MQM GROUP BY HAMVMQM. - IC42612
LOSE ASSIGNED CERTIFICATE INFORMATION ON A CLIENT DUE TO NETWORK FAILURE. - IC42089
USING JMS_IBM_LAST_MSG_IN_GROUP=TRUE IN A MESSAGE SELECTOR FAILS TO RETURN THE LAST MESSAGE IN A GROUP. - IC41626
AMQ4514 REPORTED BY MMC WHEN SHARING A QUEUE IN A CLUSTER ON WINDOWS. - IC41621
ERROR UNHANDLED EXCEPTION: SYSTEM.PLATFORMNOTSUPPORTEDEXCEPTION IS GOT WHEN .NET APPLICATION RUNS ON WINDOWS NT - IC41546
ACTIVEX / COM / MQAX200 PROBLEM WITH GETMESSAGEDATA RETURNING DOUBLE THE EXPECTED LENGTH - IC41495
OPENOUTPUTCOUNT IS INCORRECT IN C++ AND ACTIVEX / COM. - IC41483
MEMORY LEAK IN MQAX200 ACTIVEX INTERFACE. - IC41290
FDC WITH PROBE ID UN074001 SEEN WHEN RUNNING AMQMDAIN. - IC41284
MQ EXPLORER GUI DOES NOT RETAIN SSL DISTINGUISHED NAME SETTING IF INFORMATION IS UPDATED ON ANOTHER TAB. - IC41237
WHEN A QUEUE MANAGER ENDS DEPENDENT CUSTOM SERVICES DO NOT END. - IC41084
LOGPATH FORMAT UNDER MSCS - IC39879
ADD SEND EXIT, RECEIVE EXIT AND MESSAGE EXIT PROPERTIES IN THE MQENVIRONMENT CLASS OF THE .NET INTERFACE - 85215
MQM400 THE QUEUE MANAGER WILL NOT START AND OTHER MQSERIES JOBS WILL NOT RUN WHEN QMQM IS IN THE SYSTEM LIBRARY LIST - 84797
IN ORDER TO USE THE REQUEST METRICS APPLICATION WITH WEBSPHERE APPLICATION SERVER VERSION 6 THIS IFIX MUST BE APPLIED. - 84739
ENABLE SUPPORT FOR WEBSPHERE MQ 5.3 ON RED HAT ENTERPRISE LINUX VERSION 3 - 84698
APPLICATION ERROR. MCH0601 UNMONITORED BY AMQOUICX AT STATEMENT 00000000...?. - 82952
GSKIT MAY CREATE A KEY DATABASE FILE WITH A FILE EXTENSION OF '..KDB', FOR EXAMPLE 'KEY..KDB' - 82028
MQM400 RCDMQMIMG MISLEADING STATISTICS IN MESSAGE AMQ8190 - 81896
AN MQPUT OF A VALID SEGMENTED PCF MESSAGE FAILS WITH REASON MQRC_CFH_ERROR. - 74539
STRMQMCHL FAILS WITH JOB DESCRIPTION QMQMJOBD IN QMGR LIBRARY NOT FOUND. - 67267
MQM400 INCONSISTENT REFERENCE TO OS/400 COMMANDS IN QSYS.
SE17209
|
| Abstract | MQM400 DUPLICATE RC3029 ENTRIES IN CMQCFG RPG COPY FILE |
| Users Affected | This APAR has negligible impact on users of WebSphere MQ. Platforms affected: iSeries |
| Error Description | The CMQCFG COPY file in member QMQM/QRPGLESRC contains duplicate entries for constant RC3029. |
| Problem Summary | The CMQCFG COPY file in member QMQM/QRPGLESRC contains duplicate entries for constant RC3029. |
| Problem Conclusion | The duplicate definition for constant RC3029 has been removed. |
SE16933
|
| Abstract | MQM400-MSGMCH0601 FDC XY353001 IN XCSALLOCATEQUICKCELL CAUSING AGENT CRASH AFTER A TIMING PROBLEM WITHIN XLLSPINLOCKRELEASE |
| Users Affected | All users of WebSphere MQ R530, especially those using machines with Power-PC technology. Platforms affected: iSeries |
| Error Description | A timing problem exist within function xllSpinLockRelease, which is used by the xcsAllocateQuickCell and xcsFreeQuickCell routines. |
| Problem Summary | WebSphere MQ uses two locking mechanisms; mutex semaphores and spinlocks. Mutex semaphores use OS/400 pthread routines, and are used in situations where the lock is expected to be held for long (or indefinite) periods of time. Spinlocks use simple status flags, with minimal run-time overhead, and are typically used for quick lock-update-unlock situations. The function xllSpinLockRelease is changing it's status flag to 'AVAILABLE' without forcing into memory all the updates being protected by the spinlock. The main MQ functions which use spinlocks are: Event Sem, Socket Events, Heap Memory, Shared Mem(type xcsSA_SPINLOCK), Quickcell Blocks, Subpool Tasks and some parts of the LQM kernal. Thus, this APAR could be the cause of many intermittent and unexplained problems involving memory corruption. The customer who raised this APAR encountered unexpected termination of an Agent job due to an MCH0601 exception which was recorded in the FDC report below: Date/Time :- Wednesday May 05 21:55:43 2004 PIDS :- 5724B4106 LVLS :- 530.6 CSD06 Product Long Name :- WebSphere MQ for iSeries Probe Id :- XY353001 Component :- xehAS400ConditionHandler Build Date :- Jan 26 2004 Job Name :- 238256/QMQM/AMQZLAA0 Process :- 00114335 Thread :- 00000644 QueueManager :- PRODA_QM Major Errorcode :- STOP Minor Errorcode :- OK Probe Type :- HALT6109 Probe Severity :- 1 Arith1 :- 644 284 Comment1 :- MCH0601 MQM Function Stack zlaMainThread zlaProcessMessage zlaProcessMQIRequest zlaMQPUT zsqMQPUT kpiMQPUT kqiPutIt kqiPutMsgSegments apiPutMessage aqmPutMessage aqhPutMessage aqhAddGroupCell aqhAddMsgCell xcsAllocateQuickCell xcsFFST |
| Problem Conclusion | The problem has been fixed. Function _CMPSWP will harden updates to shared memory, before xllSpinLockRelease changes the spinlock status flag. |
SE16901
|
| Abstract | MQM400 MAKE FDC FILE MORE INFORMATIVE BY PROVIDING THE EXPECTED CAUSE BEHIND (3489) ENOSYSRSC -RESOURCE PROBLEM FAILURE. |
| Users Affected | All the AS/400 users. Platforms affected: iSeries |
| Error Description | CRTMQM failed with the following FDC, reporting 3489, System resources not available to complete request. Here the FDC does not provide enough information about the cause behind 3489. WebSphere MQ First Failure Symptom Report ========================================= Date/Time :- Sunday July 18 06:28:25 2004 Date/Time :- Sunday July 18 06:28:25 2004 Probe Id :- OP002001 Arith1 :- 3489 da1 Arith2 :- 5 5 Comment1 :- /qsys.lib/QMQM.lib/CRTMQM_R.pgm |
| Problem Summary | Here the problem is the lack of information in the FDC generated during the time of CRTMQM failed with AMQ6125 00000DA1 = 3489, Looking at the FDC the user can see that System resources are not available to complete request but the FDC does not provide enough information to determine the real cause behind the 3489. Date/Time :- Sunday July 18 06:28:25 2004 Date/Time :- Sunday July 18 06:28:25 2004 Probe Id :- OP002001 Arith1 :- 3489 da1 Arith2 :- 5 5 Comment1 :- /qsys.lib/QMQM.lib/CRTMQM_R.pgm |
| Problem Conclusion | The FDC did not contain enough of information to debug the failure giving rise by 3489 i.e.ENOSYSRSC RESOURCE PROBLEM. Modified the FDC contents in order to make more informative. Now user or system operator can see following text in the FDC which will explain the expected cause behind ENOSYSRSC:- "Spawn failed with CPF1105" |
SE16893
|
| Abstract | MQM400 USER PROFILE NAMES BEGINNING WITH # FAIL IN WRKMQMAUTD PANEL. |
| Users Affected | OS400 user profiles created starting with # fails on WRKMQMAUTD panel for grant, revoke, display, or delete options. CPD0020 error message is displayed. Platforms affected: iSeries |
| Error Description | OS400 user profiles created starting with # fails on WRKMQMAUTD panel for grant, revoke, display, and delete options. CPD0020 error message is displayed. Message ID . . . . . . : CPD0020 Severity . . . . . . . : 30 Message type . . . . . : Diagnostic Message . . . . : Character 'I' not valid following string '. '. Cause . . . . . : A delimiter is missing between two values or a delimiter that is not valid was found. Recovery . . . : Change the character that is not valid or if a delimiter is missing insert one. More information on delimiters can be found in the CL Reference manual. |
| Problem Summary | OS/400 User profile names beginning with # are valid names but these are being rejected by WMQ. Internally WMQ converts hashes to dots, since reading hashes from a ini file results in a line being treated as a remark. While displaying the OS/400 user profile names on display panels MQ converts back dots to hashes. This conversion function of dots to hashes is missing in WRKMQMAUTD panel program. |
| Problem Conclusion | Modification made in the OAM program. Function to convert dots to hashes is added in Enumerate Authority Data function code. |
SE16730
|
| Abstract | MQM400 QUEUE MANAGER AGENT JOB (AMQZLAA0) CONSUMES HIGH CPU IN RFIALLOCCACHE/RFXLINK WHEN MQOPEN FAILS CONTINUALLY |
| Users Affected | All users of WebSphere MQ v5.3 Platforms affected: All Distributed |
| Error Description | Using WebSphere MQ V5.3 with CSD 06 under OS/400 5.1, the job AMQZLAA0 has a very high CPU usage. |
| Problem Summary | API calls such as MQOPEN will search the cluster repository cache when the MQ object does not exist on the local Queue Manager. Each search will attempt to allocate, and subsequently free, a registration entry (of 320 bytes) in the cluster cache memory block. A problem with pointer/offset arithmetic made each freed entry appear to have size zero, causing each new allocate to request a new entry from the memory block. After a few hours, the number of freed entries had grown so large that rfiAllocateCache was consuming high CPU scanning the chain of freed cache entries. |
| Problem Conclusion | The problem has been fixed; rfiAllocateCache will re-use a freed registration entry, instead of continually allocating new registration entries. |
SE16713
|
| Abstract | MQM400-UNABLE TO RESTART QUEUE MANAGER WHEN END CONNECTED JOBS (ENDCCTJOB) SPECIFIED FOR ENDMQM. |
| Users Affected | All users of WebSphere MQ v5.3 Platforms affected: iSeries |
| Error Description | The user has quiesced the queue manager by issuing the following command ENDMQM MQMNAME(*ALL) OPTION(*IMMED) ENDCCTJOB (*YES). When the user attempted to restart the queue manager message AMQ8041 was generated. Applications which were connected to the queue manager had not been ended. When MQSeries V5.2 was installed any job connected to the queue manager was terminated. However now with WebSphere MQ V5.3, the ENDCCTJOB(*YES) does not terminated the applications. This causes the connects to remain and the restart of the queue manager to fail. Sample STRMQM joblog: AMQ8041 The queue manager cannot be restarted. AMQ8321 Process 567477/MAYFCT/QPADEV0008 is still running. AMQ7018 The queue manager operation cannot be completed. |
| Problem Summary | With option ENDCCTJOB(*YES), WMQ v5.3 behaves differently to MQ v5.2 as described above. |
| Problem Conclusion | Option ENDCCTJOB(*YES) will be changed to force clean-up of all shared memory, irrespective of whether, or not, it is being used by a connected application. This will allow a subsequent restart the queue manager to proceed without logging message AMQ8041. Connected applications will receive MQRC_CONNECTION_BROKEN or MQRC_Q_MGR_NOT_AVAILABLE at the next invocation of an MQ API call. Such programs can be written to terminate themselves by way of MQDISC, or the corresponding application jobs can be terminated by the end-user. |
SE16473
|
| Abstract | MQM400 STRMQM_R JOB HANGS AFTER RUNNING COMMAND ENDMQM WITH ENDCCTJOB(*YES) AND WITH SUBSYSTEM QMQM NOT ACTIVE |
| Users Affected | All users of WebSphere MQ for iSeries V5.3 Platforms affected: iSeries |
| Error Description | After the fix for SE13837 is installed MQM400 using ENDMQM ENDCCTJOB(*YES) requires the queue manager subsystem to be active. |
| Problem Summary | The customer ended the QMQM subsystem prior to issuing ENDMQM with parameter ENDCCTJOB(*YES), and then IPLed his machine. The ENDMQM submitted an AMQICLEN job, which was placed in the *JOBQ waiting for subsystem QMQM to become active. After the IPL, both subsystem QMQM and the Queue Manager were started simultaneously. This caused the STRMQM_R and AMQICLEN jobs to both be running at the same time, and the STRMQM_R job hangs. The fix for SE13837 changed the way that the shared memory clean-up program (AMQICLEN) is invoked during ENDMQM with ENDCCTJOB(*YES), by using SBMJOB instead of CALL. The drawback with this approach is that SBMJOB requires that subsystem QMQM is active, otherwise shared memory clean-up will not take place simultaneously with the ENDMQM command. |
| Problem Conclusion | This APAR will not require any update to the WebSphere MQ for iSeries System Administration Guide, because the method for invoking the AMQICLEN program will be changed back to use CALL. The reason for using SBMJOB has been circumvented by 'changing' the job profile to QMQM inside program AMQICLEN. |
SE16073
|
| Abstract | AMQ8146 ERROR OCCURS WHEN USING STRMQMMQSC COMMAND WITH THE WAIT(0) PARAMETER AT CSD06 |
| Users Affected | STRMQMMQSC command failed with AMQ8146(Queue Manager not available) with WAIT(0) parameter. Platforms affected: iSeries |
| Error Description | When executing the STRMQMMQSC command interactively using the WAIT(0) parameter, received error AMQ8146(Queue Manager not available). |
| Problem Summary | Error was given if waiting time was less than 1. |
| Problem Conclusion | Valid range for waiting time is changed to 0-999999. |
SE16014
|
| Abstract | MQM400-MSGMCH0601 FDC XY353001 WHEN NUMBER OF JOURNAL RECEIVERS IN THE QUEUE MANAGER LIBRARY EXCEEDS OUR IMPOSED LIMIT OF 512. |
| Users Affected | All MQ users having more than 512 receivers in the queue manager library. Platforms affected: iSeries |
| Error Description | The error is linked to a memory overwrite when the number of journal receivers in the queue manager library exceeds our imposed limit of 512. FDC for Agent failing MCH0601 is: | Date/Time :- Wednesday May 19 13:06:46 2004 | LVLS :- 530.6 CSD06 5724B4106 | Probe Id :- XY353001 | Component :- xehAS400ConditionHandler | Build Date :- Jan 26 2004 | Job Name :- 159023/QMQM/AMQZLAA0 | Process :- 00006012 | Thread :- 00000004 | QueueManager :- COMPVIEW.QMGR.DEV | Major Errorcode :- STOP MQM Function Stack |
| Problem Summary | The error is linked to a memory overwrite problem which happens when the number of journal receivers in the queue manager library exceeds the arbitrary limit of 512. The memory allocation was not dynamic which caused this problem. The error was generating an FDC with major errorcode zrcX_AGENT_DEAD. The joblog of the agent showed MCH0601. To workaround this problem a customer should amend their journal receiver threshold to prevent the creation of an excessive number of receivers, and save off and delete old receivers, to avoid hitting the 512 limit. |
| Problem Conclusion | The dynamic memory allocation code has been modified to reallocate memory based on the number of receivers. This will eliminate the MCH0601 happening on agent threads. |
SE15393
|
| Abstract | MQM400: ONCE F4 IS PRESSED ON MQSC COMMAND SCREEN, FURTHER ATTEMPTS TO GET USE MQSC FAIL. |
| Users Affected | Customer using F4 Key instead of END command to quit the MQSC command entry screen are affected by this error. Once they use F4 Key to quit the screen, further attempts of entering the screen will fails with the following message on the status line :- 0 MQSC commands completed successfully. Platforms affected: iSeries |
| Error Description | While in the MQSC command screen, if exited using F4 key to return back to the Work with queue managers screen. Then using the option 26(MQSC) beside the queue manager to reenter MQSC, fails to get the screen with the following message on the status line:- 0 MQSC commands completed successfully. |
| Problem Summary | Pressing of F4 Key on MQSC screen sets a static EOF flag for the standard input and we no longer go to the session manager. Hence whenever a user attempts to re-enter the screen without doing a re-login , the execution fails in fgets() function call and user can't get MQSC screen. Re-login can be used as a workaround. |
| Problem Conclusion | This solution comprise of WMQ-FIX as well as OS-fix. This OS-fix should be considered as a prerequisite for WMQ-FIX. OS-fix :- We have noticed that the function calls like clearerr (), freopen etc meant to clear off the EOF flag, are not clearing the flag. The iSeries Rochester team has done the necessary changes to "freopen()" so that it clears off the EOF flag whenever we do freopen to the standard input. This fix is made available to us by way of TESTPTF SI15054. WMQ-FIX :- In WMQ we introduced "freopen" system call in order to clear off the EOF flag which gets set if an operator use F4 Key on the preceded MQSC screen. Conclusion from testing:- With only WMQ-FIX on the system, The attempt of option 26 on WRKMQM panel immediately after the customer quits MQSC using F4 Key, will fail with the following message :- Message ID . . . . . . : CEE9901 Severity . . . . . . . : 30 Message type . . . . . : Diagnostic Date sent . . . . . . : 08/19/04 Time sent . . . . . . : 13:00:17 Message . . . . : Application error. *N unmonitored by *N at statement *N, instruction '4000'. Cause . . . . . : The application ended abnormally because an exception occurred and was not handled. The name of the program to which the unhandled exception is sent is *N *N. The program was stopped at the high-level language statement number(s) *N at the time the message was sent. If more than one statement number is shown, the program is an optimized ILE program. Optimization does not allow a single statement number to be determined. If *N is shown as a value, it means the real value was not available. Recovery . . . : See the low level messages previously listed to locate the cause of the exception. Correct any errors, and then try the request again. The next attempts after this failure will be a successful attempt. We conclude from the test results that only those attempts of getting MQSC screen fails, which are preceded by F4 KEY with only the WMQ fix applied. The problem doesn't occur if system has both the OS and the WMQ fix applied. Hence our recommendation is to apply OS PTF before using this fix. |
SA96244
| Abstract | CLUSQMGR FIELD OF CLUSTER QUEUE CREATED USING CRTMQMQ IS INVALID WHEN MESSAGE QUEUE MANAGER NAME IS *DFT |
| Users Affected | All MQ/400 users working with the CRTMQMQ command. Platforms affected: iSeries |
| Error Description | WHEN THE CRTMQMQ COMMAND IS USED TO CREATE A CLUSTER QUEUE, AND THE MESSAGE QUEUE MANAGER NAME FIELD IS SET AS *DFT, THE RESULTING CLUSTER QUEUE CREATED SHOWS AN INVALID CLUSQMGR FIELD. IN ALL INSTANCES, THE CLUSQMGR NAME IS SET TO *D. IF THE MESSAGE QUEUE MANAGER IS NOT *DFT, THE PROBLEM DOES NOT OCCUR. |
| Problem Summary | PROBLEM REPORTED BECAUSE ANYTHING PREFIXED WITH '*' IF PASSED TO MQMNAME WHILE CREATING CLUSTER QUEUE , MQ TREATS THAT MQMNAME AS DEFAULT QMGR. BECAUSE ONCE IT FINDS '*' AT THE FIRST PLACE FOR MQMNAME IT DOESN'T PERFORM ANY VALIDITY CHECK ON THE REMAINING CHARACTERS. |
| Problem Conclusion | The problem has been fixed for the CRTMQMQ command, and also the CPYMQMQ and CHGMQMQ commands, when used to create or modify a cluster queue object for the default Queue Manager by specifying value *DFT for parameter MQMNAME. Thus, the field called 'Cluster queue manager name' shown when displaying a cluster queue from the WRKMQMCLQ list, will show the correct name. |
IY65599
|
| Abstract | INCORRECT TRUNCATION OF A QUEUE GREATER THAN 2GB IN SIZE, CAUSING READ BEYOND END OF FILE AND LEADING TO A DAMAGED OBJECT |
| Users Affected | Only queues greater than 2Gb in size are at risk from this problem. Only queue files in a certain state of physical organisation are at risk, and only following a WMQ checkpoint. One "risky" scenario is where you have a queue where the getting applications are turned off, but messages continue to be put to the queue, allowing it to build up past the 2Gb point. Then the getting applications are turned back on. If the putting and getting applications operate at about the same rate, the queue will be refilling at about the rate it is being drained, and this, coupled with the earlier build-up past the 2Gb point, is the kind of situation that may lead to the reported problem if the queue is checkpointed before the accumulated messages are fully consumed. Platforms affected: All Distributed |
| Error Description | FDC with probe AD030001 from adiReadFile with an errno of 0; and perhaps later FDC with probe AQ123002 from aqqLoadMsgHdr, errorcode arcE_OBJECT_DAMAGED. Possibly other similar FDCs also or instead of these. The information dumped in the probe AD030001 FDC shows a QFileActiveLen of between 2GB and 4Gb, which will be less than the read-beyond-eof FilePosn value. |
| Problem Summary | The WMQ logic that maintains knowledge of queue file size may mishandle the update of this information, dependent on the current queue file physical organisation of messages, during queue reload following a checkpoint. This mishandling may lead to incorrect q file truncation at a later message put operation. |
| Problem Conclusion | Fixed the logic maintaining the knowledge of queue file size. |
IY65279
|
| Abstract | ALLOWING APPLICATIONS AND CICS SWITCH LOAD FILE TO NOT NEED A RE-LINK POST FIX PACK 5 |
| Users Affected | All users of CICS switch load files, Encina, Tuxedo and Extended Transactional Client applications who have not already recompiled and linked with libmqmz on AIX and HP. Platforms affected: AIX,HP-UX |
| Error Description | With the changes done in WebSphere MQ 5.3 CSD05, all CICS switch load files, Encina, Tuxedo and Extended Transactional Client applications needed a re-link upon installation of CSD05 or late later. This APAR will change this behaviour for WMQ5.3. This should avoid the need for a recompile on certain platforms |
| Problem Summary | On AIX and HP only, it is possible to avoid the recompile and relink with mqmz which fix pack 5 introduced for a specific set of applications. |
| Problem Conclusion | This APAR modifies MQ to re-export functions removed at fix pack 5, using operating system mechanisms to indicate the exported function is contained in libmqmz. |
IY63499
|
| Abstract | LOG FULL CONDITION IN A RCDMQIMG OPERATION, REPORTED BY PROBE HL010004 FDC, MAY CAUSE UNRECOVERABLE QUEUE CORRUPTION. |
| Users Affected | Users performing a rcdmqimg operation whilst there are large queues of persistent messages, and messages continue to be put or got from those queues as the rcdmqimg proceeds. Users are only at risk of the problem if WebSphere MQ log space becomes full during this operation. Platforms affected: All Unix |
| Error Description | If a log full condition during a rcdmqimg operation is reported by an FDC that mentions aqhMoveMessage in the Function Stack, then there is a possibility that the log full condition is handled incorrectly, and that further logging may occur - which is inappropriate and may then cause queue corruption. The queue corruption may later be reported by way of FDCs reporting a damaged object, with probe IDs such as AQ123000, AQ060020. |
| Problem Summary | One of the WebSphere MQ functions involved with moving a message on a queue mishandled the log full condition whilst reserving log space to record the move. |
| Problem Conclusion | Corrected the handling of the log full condition. |
IY63403
|
| Abstract | WMQ5.3 TRACE HEADER IS FORMATTED INCORRECTLY. |
| Users Affected | Users using AIX trace facility to trace WMQ would find incorrect information in the formatted trace header. Platforms affected: AIX |
| Error Description | WMQ5.3 trace header is formatted incorrectly. The header appeared 3 times with incorrect timestamp. |
| Problem Summary | Error in trace template file. |
| Problem Conclusion | Problem has been fixed. |
IY63316
|
| Abstract | C++ APPLICATION CRASHES WITH A SEGMENTATION VIOLATION AFTER APPLYING INTERIM FIX FOR LINUX |
| Users Affected | This only affects customers using the C++ Bindings for WebSphere MQ with an interim fix for Red Hat Enterprise Linux 3 or SuSE Linux Enterprise Server 8, which does not contain this APAR, applied. Platforms affected: Linux,Linux/390 |
| Error Description | After being supplied an interim fix for Red Hat Enterprise Linux 3 , or SuSE Linux Enterprise Server 8, a SIGSEGV may be received from a C++ application linked to the GCC 3.2 libraries supplied after executing a number of WebSphere MQ C++ calls. |
| Problem Summary | A mismatch in system structure sizes between operating systems caused some internal structures to be corrupted in the trace interface between the C++ bindings and base WebSphere MQ. |
| Problem Conclusion | A code change was made to protect the C++ bindings from the mismatch in system structure size. |
IY62636
|
| Abstract | SETTING MAXMSGL OF A CHANNEL TO 0, SHOULD MEAN THE MAXMSGL OF THE QUEUE MANAGER IS USED. |
| Users Affected | Customers setting MAXMSGL(0) on channel definitions. Platforms affected: All Distributed |
| Error Description | The MQSC Command Reference states that if you set the MAXMSGL of a channel to 0, this means the MAXMSGL of the queue manager is used. However, this does not appear to be the case. If you set the MAXMSGL of the queue manager on the sending and receiving side of a channel to the maximum value of 100MB and you set the MAXMSGL of the sender and receiver channel to 0, a message larger than 4MB fails, being moved to the dead letter queue with reason code 2218 MQRC_MSG_TOO_BIG_FOR_CHANNEL. |
| Problem Summary | The logic used by the code when negotiating the maximum message length of a channel, with either side having a value of zero specified in the channel definition, did not match the WebSphere MQ manuals. |
| Problem Conclusion | The code was changed so that the behaviour when MAXMSGL(0) is specified on the definition of a channel matches the documented behavior. |
IY62101
|
| Abstract | XC130004 FOR SIGSEGV OUT OF KPISPIADOPTUSER INSTEAD OF 2035 MQRC_NOT_AUTHORIZED |
| Users Affected | This APAR affects users of WMQ with CICS enabled as the XA Transaction Manager. Platforms affected: All Distributed |
| Error Description | With CICS enabled as the XA Transaction Manager, an application attempts to connect to a queue manager but the userid is not authorized to do a MQCONN. Instead of getting a rc =2035 the application hangs. The MQ agent process amqzlaa0 issues a FDC to report a SIGSEGV with Probe Id XC130004. MQM Function Stack zlaMainThread zlaProcessMessage zlaProcessSPIRequest zlaSPIAdoptUser zsqSPIAdoptUser kpiSPIAdoptUser xcsFFST |
| Problem Summary | As part of the coordination between WMQ and CICS, privileged functions were being called using an invalid HConn, after the connection had failed with due to the authorization error. This resulted in the SIGSEGV observed. |
| Problem Conclusion | The code was fixed so that the privileged functions are only called after the connection is successful and the HConn is valid. |
IY61664
|
| Abstract | CLEANUP THREAD RETURNS 2058 WHEN JMS CLIENT CONNECTION TO DEFAULT QUEUE MANAGER (NO QMNAME GIVEN IN TCF). |
| Users Affected | All users using JMS to connect in client mode to the default queue manager, leaving the name blank in TCF. Platforms affected: All Distributed+Java |
| Error Description | Customer has JMS client code that wants to access the default queue manager. The QMNAME in the TopicConnectionFactory is left blank. The code works first time then the Queue Manager Name gets set and it fails to work due to wrong format of QMgrName. The trace shows Cleanup returning with MQRC_Q_MGR_NAME_ERROR. The queue manager name is postfixed with address and port information. |
| Problem Summary | Additional connection information was appended to the resolved queue manager name. |
| Problem Conclusion | The name passed to connect is now trimmed to only include the queue manager name. |
IY60992
|
| Abstract | XC130003 FDC AFTER AT061010 FDC UNDER THE FUNCTION ATXSTART |
| Users Affected | Customers with resource shortages may experience this SIGSEGV as a result. However, the resource shortage will still prevent WMQ from performing the required function. Platforms affected: All Distributed |
| Error Description | WebSphere MQ incorrectly handles an internal error code from the function atxPerformStart, leading to a SIGSEGV and an FDC showing Probe Id XC130003. This error may be seen when a system is very low on resources or when parameters like semmni are set too low for MQ to function. |
| Problem Summary | An internal call was failing due to resources on the system being too low. This error was not being handled properly, causing the SIGSEGV observed. |
| Problem Conclusion | The fix for this APAR will allow WMQ to correctly deal with the internal return code without a SIGSEGV. However, the solution for customers experiencing this issue will generally be increasing the resources on the system, such as the number of available semaphore resources. |
IY60843
|
| Abstract | MESSAGE SELECTORS THAT CONTAIN THE <> (NOT EQUAL) OPERATOR DO NOT WORK. |
| Users Affected | This problem affects customers who use the Java Message Service (JMS) functionality provided with either WebSphere MQ 5.3 CSD06 or CSD07, and WebSphere Application Server Version 5.1.1.x. Platforms affected: All Distributed+Java |
| Error Description | When using message-driven beans (MDBs) or JMS applications that have a message selector containing the <> (not equals) operator, the MDB or application is not invoked when a message which meets the criteria specified in the selector is placed on the target queue. This results in messages being left on the queue. |
| Problem Summary | There were two problems here: - A defect in the matching engine was introduced in WebSphere MQ CSD06 that caused the <>(not equals) pattern matching to fail. - The SelectorDataAccessor class was incorrectly returning a BooleanValue object to represent a NULL value - this has been changed to return a null. |
| Problem Conclusion | The matching engine and the SelectorDataAccessor class have been updated to correctly identify messages that meet the <> (not equals) message selector. |
IY60786
|
| Abstract | FDCS FROM *MEMBLOCK COMPONENTS WITH PROBE ID LIKE XY398006 WHEN ENQUIRING QUEUE HANDLE INFORMATION. |
| Users Affected | Users enquiring queue handle status information whilst the number of open handles on that queue is rapidly increasing. Platforms affected: All Distributed |
| Error Description | WebSphere MQ may exceed the buffer size it acquires in function kqiInquireQueueHandleStatus. We call this function to enquire on queue handle information. We do a preliminary check to find the number of open handles. If the number of open handles on a queue grows significantly while we are doing the inquiry it can cause us to exceed the buffer size and overlay the tail of that buffer. This overlay can result in unpredictable results but some of the FDCs which we have seen have symptoms such as: Probe Id :- XY398006 Component :- xcsFreeMemBlock Comment1 :- Failed to match eyecatcher on end memory CB during free or Probe Id :- XC130003 |
| Problem Summary | The check for exceeding the buffer size to return the queue handle status information may not be accurate for a queue with a rapidly increasing number of open handles. |
| Problem Conclusion | Corrected the check for exceeding the buffer size. |
IY60765
|
| Abstract | JMS SPEC STATES THAT A CLOSE TERMINATES ALL PENDING MESSAGE RECEIVES ON THE CONNECTION WHEN A SESSION.CLOSE() IS INVOKED. |
| Users Affected | Users using unlimited receive with a session.close() on MQ 5.3. Platforms affected: All Distributed+Java |
| Error Description | When the customer invokes a Session.close() all pending receive() calls should terminate, per the JMS specifications. Currently, we are not releasing the receive() call causing the application to hang indefinitely. |
| Problem Summary | On closing a session, at CSD06 the application will hang until a message has been received. At CSD07 an illegalStateException is returned. This problem only occurred with PubSub not Point to Point. |
| Problem Conclusion | The receiveT method in the MQMessageConsumer class was making a GET call with the time-out set to unlimited. This was preventing the close method returning a message or null. This has been changed so that an unlimited receive times-out after the default of 5000 ms. An extra check to see if the session is closed has been introduced in the receiveT method to prevent the illegalStateException. |
IY60736
|
| Abstract | POTENTIAL QUEUE MANAGER HANG ON AIX, OR A SPURIOUS SEMAPHORE POST ON AIX/LINUX, IF AN APPLICATION IS KILLED DURING MQDISC |
| Users Affected | Users killing server binding applications during an MQDISC call on AIX/Linux. Platforms affected: AIX,Linux |
| Error Description | If a server bindings application is killed, or hangs, at just the wrong point during an MQDISC call, it is possible to cause the application's agent health thread to hang, which in turn can cause the queue manager to stop processing further application connection attempts. There is also a possibility that this could cause a spurious semaphore post FDC (probe XC034071), rather than a queue manager hang. This latter symptom is possible on Linux as well as AIX, whereas the queue manager hang is only a possibility on AIX. |
| Problem Summary | The MQDISC code failed to take into account certain small windows in the disconnect logic where, if an application is killed or hangs, there was the potential for locking up the whole queue manager. A further small window could give rise to a spurious semaphore post. |
| Problem Conclusion | Improved the MQDISC logic to close the windows of opportunity for things to go wrong. |
IY60590
|
| Abstract | QUEUE MANAGER HANGS AFTER ALTER QL(SYSTEM.AUTH.DATA.QUEUE) QDPHIEV(ENABLED) |
| Users Affected | Affects all flavours of MQv5.3 where Qdphiev is enabled for system.auth.data.queue and KqiSetPerformanceEvent is called Platforms affected: All Distributed |
| Error Description | Here are the steps used to recreate this problem: 1) crtmqm QMA 2) strmqm QMA 3) runmqsc QMA 4) alter qmgr perfmev(enabled) 5) alter ql(system.auth.data.queue) qdphiev(enabled) 6) def ql(Q_AFTER) <===== there is no return (amq8006) 7) Use control-C to exit MQSC, but MQSC command dis ql will hang even under a new runmqsc session. Also the queue manager can not be stopped with endmqm. The queue manager hangs waiting on zcpRecieveOnPipe. This happens only when the system.auth.data.queue is altered. |
| Problem Summary | The problem was caused due to overflow in one condition statements which used to set the hievent for every message put in system.auth.data.queue |
| Problem Conclusion | The overflow is avoided in the if condition check |
IY60472
|
| Abstract | XC015001 FROM XCSFREEQUICKCELL SHOWING XECS_E_BLOCK_ALREADY_FREE |
| 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 | WebSphere MQ may in some situations generate an FDC file showing Probe Id XC015001 from xcsFreeQuickCell with a major error code of xecS_E_BLOCK_ALREADY_FREE. The MQM Function Stack in the FDC is likely to show the thread disconnecting (MQDISC) or executing the function zutReleaseSharedPCD. |
| Problem Summary | If applications exit without disconnecting from WMQ, the queue manager detects this periodically and cleans up the connection on behalf of the application. There is a very small timing window whereby the cleanup mechanism can interfere with applications normally connecting and disconnecting, which can cause a problem with internal WMQ "quickcell" management, leading to the observed FDC. |
| Problem Conclusion | Improved the dead connection cleanup mechanism to eliminate the window. |
IY60448
|
| Abstract | SPURIOUS AMQ9546 ERROR OUTPUT ON STARTING CHANNEL FROM RUNMQSC |
| Users Affected | User issuing start channel from runmqsc on MQ5.3, on Unixes and Windows Platforms affected: All Distributed |
| Error Description | Spurious AMQ9546 error output on starting channel from runmqsc. AMQ9546 means Error return code received from internal function. The channel starts successfully. User issues start channel from runmqsc. Causes rrxStartChannel to be issued. The channel goes into STARTED state. Writes a message to the channel initiator to start it. The channel initiator also calls rrxStartChannel for the channel. The first rriAddStatusEntry in rrxStartChannel is called. This notices that the channel is already started, and returns the warning internal return code rrcW_ALREADY_STARTED. In this context this is not an error and the warning should be ignored on return to rrxStartChannel. |
| Problem Summary | When rrxStartChannel returns to the main loop of the channel initiator, an attempt is made to output any error messages which have been set with rrxError. This fails as no error message corresponds to rrcW_ALREADY_STARTED and this leads to the output of message "AMQ9546 Error return code received." |
| Problem Conclusion | The channel is already started, and returns the warning internal return code rrcW_ALREADY_STARTED. In this context this is not an error and the warning should be ignored on return to rrxStartChannel. |
IY60106
|
| Abstract | .FDC FILE CUT WITH HL142100 FROM MQLOOPEN UPON CRTMQM. |
| Users Affected | MQv5.3 for SOLARIS users using filesystem which does not support directio call. Platforms affected: Solaris |
| Error Description | crtmqm fails cutting a .FDC file that reports EINVAL from mqloopen. |
| Problem Summary | directio system failing with EINVAL and was dumping FDC with probe HL142100. The failure was caused while dumping this FDC. |
| Problem Conclusion | The FDC was informational and the error value EINVAL has no effect on the execution of crtmqm or other mq process. Block the FDC creation. |
IY59854
|
| Abstract | HEAP MEMORY LEAK WITH EACH THREAD CREATED WHEN TRACING IS ON. |
| Users Affected | Users running with WMQ (or AIX) tracing on, who are running processes which cycle through a lot of WMQ threads. E.g. a Java application, or even certain WMQ queue manager processes (depending on how they are driven). Platforms affected: All Distributed |
| Error Description | When tracing is active, WebSphere MQ may leak some heap memory in applications which are connected to it. This leak is exacerbated by many threads connecting and disconnecting repeatedly. |
| Problem Summary | The tracing mechanism typically allocates 4k of heap space for a traced thread. This is not reclaimed when the thread is destroyed. The cumulative leak may become significant if the process cycles through a large number of threads. Note that processes often pool threads to avoid the performance overhead of repeated thread creation and destruction, so this mitigates the impact. Note: this leak only occurs if tracing is on. |
| Problem Conclusion | Ensured that when threads are destroyed, the memory allocated for tracing is reclaimed. |
IY59661
|
| Abstract | OUTPUT FROM RCDMQIMG -T ALL DOES NOT REPORT SYNCFILE RECORDED |
| Users Affected | Users worrying that WMQ does not report that it has recorded the syncfile when a rcdmqimg -t all is done. Platforms affected: All Distributed |
| Error Description | When running rcdmqimg -t all, it does not report that the syncfile has been recorded. Nevertheless, it does actually record the syncfile information. |
| Problem Summary | There is special logic for the recording of syncfile information, to avoid reporting a potentially large number of messages, since recording the image of a syncfile causes the images of each channel scratchpad to be recorded. This was coded in such a way that it inadvertently failed to report that it had recorded the syncfile, in the case that rcdmqimg -t all was requested. |
| Problem Conclusion | Reworked the logic pertaining to reporting that we have recorded syncfile information, to ensure we do report that it is recorded when a rcdmqimg -t all is done. |
IY58536
|
| Abstract | AL036002 FDC IN ALSRECORDCHECKPOINT: ERROR 13, PERMISSION DENIED |
| Users Affected | Probably, only users deploying WMQ queue manager data on file systems which are not explicitly supported by WMQ. Platforms affected: All Unix |
| Error Description | In some rare cases, MQ may fail with an FDC showing Probe Id AL036002 from alsRecordCheckPoint with an Arith1 of 13 d and Comment1 of open(). Near the bottom of the FDC MQ will show a filename of amqalchk.fil and an error string of Permission denied. This error usually occurs during crtmqm and brings down the queue manager each time it is started. |
| Problem Summary | For some unknown reason, presumably relating to the use of a NAS disk device for the queue manager data, the WMQ checkpoint file, amqalchk.fil, was created with incorrect permissions. When WMQ later tried to access this file, the permissions did not allow access. |
| Problem Conclusion | WMQ contributed to this issue by a mistaken permissions value for the system "open" function with create. This has been corrected to use appropriate permissions. Note that this has never, to date, manifested as a problem on local filesystems (which is the explicit usage recommendation). |
IY58535
|
| Abstract | QUEUE MANAGER HANG FOLLOWING AO175001 FDCS FROM AOULOCKQHANDLE. |
| Users Affected | Users with a damaged reusable dynamic queue. It would be a rare circumstance for this to occur. Platforms affected: All Distributed |
| Error Description | When deleting a damaged queue, WebSphere MQ may in some cases fail to release a lock on the queue. The result may be a series of FDCs showing Probe Id AO175001 from aouLockQHandle. After some time, the queue manager may hang due to the orphaned lock. |
| Problem Summary | It is unclear how the customer's queue manager got into the state it did to provoke the MQ issue with recovering from this particular inconsistency. Possibly disk corruption or a prior processing abnormality. MQ's recovery action unfortunately meant that a queue lock was retained when it should not. |
| Problem Conclusion | Corrected the recovery action to handle the case of locking a damaged reusable dynamic queue, when that object is about to be deleted. |
IY57841
|
| Abstract | NL TO LF CONVERSION DOES NOT WORK TO EUC CODEPAGES. |
| Users Affected | Data conversion from EBCDIC to EUC codepages, where the data contains the EBCDIC newline (NL) chax x15, on platforms where conversion is by internal functions rather than O/S supplied functions, i.e. Linux, Solaris, Windows. Note that although the problem does occur on Windows, it is unlikely to happen because it is unlikely that any user will convert to an EUC (extended UNIX codepage) on Windows. Platforms affected: Linux,Linux/390,Solaris,Windows |
| Error Description | The parameter ConvEBCDICNewline, specified in /var/mqm/mqs.ini AllQueueManagers stanza, defines the way in which an EBCDIC newline character, x15, is converted to ASCII. Note that EUC is an extended form of ASCII. The parameter can have the values: NL_TO_LF - convert x15 to x0A. This is the DEFAULT. TABLE - convert x15 according to the conversion table. ISO - convert ISO CCSIDs using the TABLE method, other CCSIDs using the NL_TO_LF method On Linux, Solaris and Windows the NL_TO_LF setting (the default) does not work when the conversion is to an EUC codepage. On these platforms, which do not use iconv(), x15 is converted to x85, regardless of the setting of the parameter or the default. |
| Problem Summary | The 'special' conversion of EBCDIC NL x15 was only enabled where the target codepage was ASCII or ISO type, not where it was EUC (extended ASCII), on Linux, Solaris, Windows. |
| Problem Conclusion | Extend 'special conversion' to EUC codepages on affected platforms. |
IY57820
|
| Abstract | SSL CHANNELS BETWEEN WINDOWS AND OTHER PLATFORMS FAIL WITH ERROR MESSAGE AMQ9636 IF SSLPEER HAS MORE THAN ONE OU. |
| Users Affected | This problem will affect customers who are using Windows platforms who use SSL channels and specify an SSLPEER value on their channels which contains multiple 'OU' attributes. If you have only one (or no) 'OU' attributes specified in the SSLPEER value or you are not running a Windows based Queue Manager this problem WILL NOT affect you. Platforms affected: Windows |
| Error Description | When using Distinguished Names (DN) in SSL certificates the Organization Levels (OUs) appear in the reverse order on Windows when compared to other platforms (UNIX, z/OS, iSeries etc). If a queue manager on a platform other than Windows has a sender channel to another machine and specifies an SSLPEER value containing multiple OUs which work fine, when a Windows Queue Manager is defined with the same sender channel definition the SSLPEER value will not allow the channel to start up, producing the error message AMQ9636. When the SSLPEER value attributes are reversed the problem will not be seen. |
| Problem Summary | The Microsoft APIs return the DN of a certificate in reverse order to the GSKit APIs (as used on other platforms) which caused a matching problem when comparing SSLPEER strings on platforms. |
| Problem Conclusion | The Microsoft APIs used have an option to reverse the DN attributes and this flag has been enabled to make MQ interpret the DNs of certificates in the same order as the other platforms. |
IY57545
|
| Abstract | CLIENT APP CREATES NON-MQM UID:GID IPC RESOURCES/FAILS WITH 2059 AFTER FIX FOR IY54058 IS APPLIED. |
| Users Affected | Any customer using client applications. Platforms affected: All Distributed |
| Error Description | Client applications can create various IPC resources with non- mqm uid:gid. If a server is running on the same machine, it will make use of these same critical IPC resources and if they are deleted by mistake because they have non-mqm uid:gid, this can cause the WMQ server to hang or generate FDCs complaining of EINVAL or EIDRM from semaphore operations. Also, if the customer has the fix for IY54058 applied, it is possible that client applications will fail with 2059 even if they are correctly configured. The fix for IY54058 is shipped in Fix Pack 8. |
| Problem Summary | User applications can create critical WMQ IPC resources if they do not already exist. Previous APARs fixed this problem for bindings applications, but not for client applications. |
| Problem Conclusion | This APAR allows all applications, client or bindings to create the critical IPC resources if required, but then ensures, that their uid:gid is changed to mqm:mqm to ensure customers understand that these resources are being used by WMQ. |
IY52823
|
| Abstract | INSTALLATION OR CONTROL COMMANDS FAIL ON LINUX WITHOUT ENVIRONMENT VARIABLE LD_ASSUME_KERNEL SET |
| Users Affected | Customers installing or using WebSphere MQ 5.3 with a Linux (Intel or zSeries) distribution based on a Linux 2.4 kernel with the Linux 2.6 kernel feature Native Posix Thread Library (NPTL) included. Platforms affected: Linux,Linux/390 |
| Error Description | Unexpected behaviour is observed on some Linux distributions, when the environment variable LD_ASSUME_KERNEL is not set: - The mqlicense.sh script fails with 'Segmentation fault' when attempting to accept the WebSphere MQ license prior to installation. - Installation of the WebSphere MQ RPM packages causes a hang. - WebSphere MQ control commands fail with: AMQ6090: WebSphere MQ was unable to display an error message 20006220. |
| Problem Summary | WebSphere MQ 5.3 does not support the NPTL threading implementation. The LD_ASSUME_KERNEL environment variable is provided by Linux distributions with an NPTL threading implementation as a method of enabling a LinuxThread threading implementation which is supported by WebSphere MQ. Use of this environment variable should be detailed in the release notes for the Linux distribution. |
| Problem Conclusion | Fix pack 9 and higher provide full support for Red Hat Enterprise Linux 3, which is a Linux distribution based upon a Linux 2.4 core with Linux 2.6 features including NPTL. Customers wishing to use WebSphere MQ with other Linux distributions based on a Linux 2.4 kernel with NPTL should consult the release notes of the operating system for details of enabling a LinuxThreads threading implementation. The license script mqlicense_lnx.sh, as included in the package for fix pack 9 and higher, is required for license acceptance for WebSphere MQ on any such distribution. Instructions for installation of WebSphere MQ on Red Hat Enterprise Linux 3 are provided in the 'Special Information' section of the memo.ptf included in fix pack 9 or later. |
IC43531
|
| Abstract | CLIENT APPLICATIONS TRAP WHEN TRACING IS ENABLED UNDER WMQ 5.3 CSD08 |
| Users Affected | All users using client connections while tracing is enabled at level WMQ 5.3 CSD08 Platforms affected: All Distributed |
| Error Description | When tracing is enabled under WMQ 5.3 CSD08, a client application issuing an MQCONN will trap. In Windows, the DrWatson log shows: eip=4e8a016b FAULT ->4e8a016b 8a01 mov al,[ecx] ds:0023:00000006=?? and a callstack of: ChildEBP RetAddr Args to Child AMQXCS2!xtrEstablishTraceStatus+0x1b9b (FPO: [EBP 0x00000004] [6,142,4]) AMQXCS2!xtr_data_api+0x74 (FPO: [EBP 0x0012fb50] [4,1,4]) AMQRMQIA!rzstMQCONNX+0x1669 |
| Problem Summary | This is a basic C coding problem, where the value of the hconn is passed into the data trace, not the pointer. This code was introduced in fixpack 8 to give client side api trace, something which has been desperately needed for a number of problems. |
| Problem Conclusion | The pointer issues have been resolved, so trace can now be run on client applications. |
IC43446
|
| Abstract | CLUSTERS: AMQ9248 WHEN TRYING TO START A CLUSTER SENDER CHANNEL AFTER APPLYING FIX PACK 8 |
| Users Affected | Customers using clustering experiencing AMQ9248 errors in the queue manager error logs after applying fix pack 8. Platforms affected: All Distributed |
| Error Description | AMQ9248 when trying to start a cluster sender channel when a manually defined cluster sender exists, after applying fix pack 8. The second insert of the AMQ9248 message appears corrupted. This usually impacts systems where MQNOREMPOOL is set, which is used almost exclusively as a workaround on the Windows platform for a return code 10038 problem when launching channels. However, this problem has been observed on AIX systems without MQNOREMPOOL set. |
| Problem Summary | A Cluster Sender channel may fail to start on a system (usually where MQNOREMPOOL is configured) and a manual cluster sender is defined. The main symptom of this problem is the AMQ9248 return code with the corrupted second insert. |
| Problem Conclusion | MQ has been modified to correctly launch the cluster sender channels. |
IC42742
|
| Abstract | APPLICATION RECEIVES A 2009 MQRC_CONNECTION_BROKEN OCCASIONALLY EVEN THOUGH APPLICATION STILL ALIVE. |
| Users Affected | All users of distributed MQ who mix shared and non-shared HCONN's Platforms affected: All Distributed |
| Error Description | Application is using shared hconns (eg. any Java application), and it periodically gets back connection broken. A trace shows that the application is definitely alive, but the zlaPerformHealthcheck routine thinks the process has died. |
| Problem Summary | If an agent thread is processing on behalf of a non-shared connection, and that application does an MQDISC, the thread remains around for a short time in case another application tries to connect. If a second application MQCONN's it reuses this original thread, and if it asks for a shared hconn then MQ does not correctly notice this. This does not cause any functional problems, unless the thread who issues the MQCONN actually terminates, in which case the shared hconn becomes invalidated. |
| Problem Conclusion | MQ has been modified to ensure if an agent thread is reused, then it correctly tracks whether a shared connection was made. |
IC42634
|
| Abstract | COMPILING C++ PROGRAM RESULTS IN UNDEFINED SYMBOL ERROR IMQCHL::SETLOCALADDRESS(CONST CHAR*) |
| Users Affected | WMQ5.3 for AIX and windows applications C++ API ImqChl::setLocalAddress Platforms affected: AIX,Windows |
| Error Description | Compiling C++ program results in Undefined symbol error ImqChl::setLocalAddress(const char*). Investigation into the problem showed that the localAddress is not exported into the library libimqb23ia. |
| Problem Summary | The API setLocalAddress symbol was not exported in libimqb23ia. |
| Problem Conclusion | The symbol setLocalAddress was exported under libimqb23ia library. |
IC42618
|
| Abstract | THE DIRECTORY PERMISSIONS ARE NOT INITIALIZED FOR MQM GROUP BY HAMVMQM. |
| Users Affected | All users of hamvmqm on Windows WebSphere MQ 5.3 Platforms affected: Windows |
| Error Description | The directory permissions are not initialized for mqm group by hamvmqm for directories it creates or copies. Copied files are correctly secured by way of mqm |
| Problem Summary | hamvmqm does not add security for the mqm group on directories it creates or copies across |
| Problem Conclusion | hamvmqm has been modified to correctly apply the mqm group authority to directories it creates or copies across. |
IC42612
|
| Abstract | LOSE ASSIGNED CERTIFICATE INFORMATION ON A CLIENT DUE TO NETWORK FAILURE. |
| Users Affected | All users of SSL support on Windows clients who store their keystore on non-local media. Platforms affected: Windows |
| Error Description | After a major network failure key.sto is no longer available. When using a keystore for the client on a network drive, after a network outage (and recover) the certificate on longer works, you have to re-import the certificate. |
| Problem Summary | When a failure to open a client keystore is detected, MQ unassigns the personal certificate. This means that, should the failure be temporary, the client application will no longer work until manual intervention reassigns the certificate back. |
| Problem Conclusion | MQ has been modified on the windows platform so that a failure to load a keystore is handled without unassigning the personal certificate, and hence when the keystore becomes available then it will work immediately |
IC42089
| Abstract | USING JMS_IBM_LAST_MSG_IN_GROUP=TRUE IN A MESSAGE SELECTOR FAILS TO RETURN THE LAST MESSAGE IN A GROUP. |
| Users Affected | WebSphere MQ Server V5.3 users, using selectors to access JMS provider specific properties from an MQ message. Platforms affected: All Distributed+Java |
| Error Description | The customer has coded an MDB in a WAS environment and this uses a selector that includes JMS_IBM_Last_Msg_In_Group=true. However, this fails to return the last message in the group. A browse of the message shows that MQMD.MQMF_LAST_MSG_IN_GROUP has been correctly set, yet a JMS trace confirms that it is not being returned. This problem occurs if JMS_IBM_Last_Msg_In_Group =true is the only clause in the selector or if it is paired with another clause, for example JMSXGroupID IS NULL OR JMS_IBM_Last_Msg_In_Group=true |
| Problem Summary | We should be mirroring the MQMD fields into the JMSMessage but we have not done this at the point where the selector is checked; we are relying on having an MQMsg2 object to get these values from instead. Seeing as we are passing a null in instead of the MQMsg2 we fail on any check requiring that MQMsg2, that is, anything that is held in the MQMD rather than in the JMSMessage (RFH2) itself. |
| Problem Conclusion | The method now passes the MQMsg2 instead of a null to the SelectorDataAccessor. |
IC41626
|
| Abstract | AMQ4514 REPORTED BY MMC WHEN SHARING A QUEUE IN A CLUSTER ON WINDOWS. |
| Users Affected | Users administering cluster queues using the MMC interface (available on Windows platforms). Platforms affected: Windows |
| Error Description | Users of the NT MMC Administration interface receive a message box reporting error AMQ4514 when completing (clicking OK) the cluster properties page for various wizards (Create Local Queue etc). No error messages are logged and no FDCs are cut. The queue is correctly added to the cluster and functions as expected. Message AMQ4514 states "The queue manager is not a member of cluster ...". |
| Problem Summary | The problem was caused by an incorrect initialisation during the population/ queue manager dispensing routines for the results pane of the MMC Console. |
| Problem Conclusion | To resolve the problem, the correct initialization is performed at queue manager dispense time when populating the results pane of the MMC console with queue manager objects. |
IC41621
|
| Abstract | ERROR UNHANDLED EXCEPTION: SYSTEM.PLATFORMNOTSUPPORTEDEXCEPTION IS GOT WHEN .NET APPLICATION RUNS ON WINDOWS NT |
| Users Affected | Users implementing the ContextID() property of the 'System.enterpriseServices' namespace in their .Net application on an Windows NT environment Platforms affected: Windows |
| Error Description | There are some software components that are required by some parts of the .NET Framework but that do not block the innstallation. If components are required at runtime but not available, the .NET Framework will throw an exception of the type PlatformNotSupportedException that our applications should be prepared for. Windows NT 4.0 supported the installation Microsoft Transaction Server (MTS), which is different from COM+ 1.0 which came with Windows 2000, or COM+ 1.5 which comes with Windows XP. XML Enterprise Services in the .NET Framework will only work with COM+ 1.0 or higher, so the functionality offered through the System.EnterpriseServices namespace |
| Problem Summary | When a .NET application uses the "System.enterpriseServices.ContextUtil.get_ContextID()" property of the 'System.enterpriseServices' namespace & executes it on a Windows NT platform, we encounter the "System.PlatformNotSupportedException". In the method "IsMTSEnvironment()" we try to use the "ContextUtil.ContextId" which is nothing but "System.enterpriseServices.ContextUtil.get_ContextID()". This is not valid call on Windows NT & hence the "System.PlatformNotSupportedException" error is encountered. |
| Problem Conclusion | To overcome this problem & to avoid the "System.PlatformNotSupportedException" exception, we check if the environment is Win NT first, before calling the 'getContext' call. Then we query the env var 'TMQ_DEFAULT_MODEL' to verify if it is a MTS environment. Due to the .NET framework restriction, automatic detection of an MTS environment is not possible in NT4, and hence to run a .NET program under MTS on NT4, the environment variable TMQ_DEFAULT_MODEL must be set to MULTI in the environment launching the .NET program. |
IC41546
|
| Abstract | ACTIVEX / COM / MQAX200 PROBLEM WITH GETMESSAGEDATA RETURNING DOUBLE THE EXPECTED LENGTH |
| Users Affected | All users of the COM (ActiveX MQAX200) interface Platforms affected: Windows |
| Error Description | Normally, when data conversion occurs the expected length of the data returned is twice the original length. The data conversion routines then set the correct length after conversion. In cases where a conversion does not actually occur the length of the data is not set correctly. |
| Problem Summary | In some of the cases where no data conversion is required, the message returned is double the length it should be. This is due to an assumption that data conversion may produce Unicode output, and a failure to reset the message length if no conversion occurs. |
| Problem Conclusion | The ActiveX layer has been modified so that it recognizes the case when no data conversion is required and ensures the final message length is set correctly to the length of the message. |
IC41495
|
| Abstract | OPENOUTPUTCOUNT IS INCORRECT IN C++ AND ACTIVEX / COM. |
| Users Affected | All users of C++ and COM/ActiveX who query the OpenOutputCount. Platforms affected: Windows |
| Error Description | When querying the OpenOutputCount using the C++ interfaces to mqqueue, or interfaces which call the C++ layer, such as activeX (COM, MQAX200), they incorrectly return the OpenInputCount. |
| Problem Summary | Querying the OpenOutputCount returns the OpenInputCount instead. |
| Problem Conclusion | The C++ and COM (ActiveX MQAX200) interfaces are modified to correctly return the OpenOutputCount when it is queried. |
IC41483
|
| Abstract | MEMORY LEAK IN MQAX200 ACTIVEX INTERFACE. |
| Users Affected | All users of ActiveX (COM MQAX200) in an MTS / COM+ environment Platforms affected: Windows |
| Error Description | If an application, which uses the ActiveX interface, loads the MQAX200 library, connects to a queue manager, and then disconnects and unloads MQAX200 there is a memory leak. Although this is not a desired sequence of events, it is what happens when the application is run under MTS / COM+ as DLLHOST dynamically loads the components and releases them later. |
| Problem Summary | Dynamically loading and unloading the MQAX200 library results in a slight memory leak due to an assumption that the dll will only be unloaded at process termination time. In a COM+ environment this is not the case as the DLL may get unloaded when the COM+ object is freed, potentially resulting in a memory leak over time. |
| Problem Conclusion | The ActiveX library, MQAX200, has been modified to free up storage on process detach time, rather than assuming the operating system will do it. |
IC41290
|
| Abstract | FDC WITH PROBE ID UN074001 SEEN WHEN RUNNING AMQMDAIN. |
| Users Affected | This problem affects users who are not in the Administrators group but are running AMQMDAIN. Platforms affected: Windows |
| Error Description | When running the following commands: amqmdain reg QMGR_NAME -c add -s Channels -v MaxActiveChannels=500 or amqmdain regsec you may see an FDC similar to the following written many times by the amqmdain process if the user ID running the command is NOT in the Administrators group: LVLS :- 530.7 CSD07 Product Long Name :- WebSphere MQ for Windows Vendor :- IBM Probe Id :- UN074001 Application Name :- MQM Component :- AMQMDAIN SetSecInfo Build Date :- May 28 2004 CMVC level :- p530-07-L040527 Build Type :- IKAP - (Production) There are so many (identical) FDCs written that the amqmdain command takes a long time to complete (5-10 seconds) |
| Problem Summary | Users must run 'amqmdain regsec' and 'amqmdain reg' commands under an Administrator ID. |
| Problem Conclusion | The code has been modified so that only one FDC is written (to stop users getting the performance hit of multiple identical FDCs). The FDC has been modified to ask users to run the command as an Administrator. |
IC41284
|
| Abstract | MQ EXPLORER GUI DOES NOT RETAIN SSL DISTINGUISHED NAME SETTING IF INFORMATION IS UPDATED ON ANOTHER TAB. |
| Users Affected | Users of the Windows NT MMC Administration interface to modify channel attributes. Platforms affected: Windows |
| Error Description | If a Distinguished Name is specified on the SSL tab of a channel, the information is deleted if you update information on another tab and do not click on the SSL tab. This only occurs using the explorer to update channel information. This causes the channel table to be updated without the SSL Peer Name parameter which could subsequently cause the channel not to start. |
| Problem Summary | At creation time of the dialog, all of the properties pages are allocated. The problem arises because the first page of the channels properties dialog (General), maintained a reference to the SSL properties page. When attempting to apply the changes, the General page used the reference to the SSL page to modify some data in the model. However, each page on the dialog is only ever initialised (from the model) when first selected. As the SSL page had never been selected, it was not initialised and the General page uses invalid data which causes the peer name parameter to be erased. |
| Problem Conclusion | To resolve the problem, the reference to the SSL property page was removed from the General property page, and the code causing the invalid data to reset the peer name property, was moved to the appropriate location. |
IC41237
|
| Abstract | WHEN A QUEUE MANAGER ENDS DEPENDENT CUSTOM SERVICES DO NOT END. |
| Users Affected | Customers specifying customer services dependent on queue managers using the MMC - MQ Services interface. Platforms affected: Windows |
| Error Description | Custom services that have been set up as dependent on a queue manager do not end when the queue manager ends, even though the mqdaiqmgrsvc attempts to end all dependent services. |
| Problem Summary | Custom services that have been set up as dependent on a queue manager do not end when the queue manager ends, even though the mqdaiqmgrsvc attempts to end all dependent services. The reason for this is that the End command for a custom service checks the processID associated with that service and, at End time, the MQDAIQmgrSvc class loads a new list of custom services from the registry - thereby obliterating the process ID information stored. |
| Problem Conclusion | The End method should actually just be ensuring the existing custom service list is up to date - then ending those in the list. |
IC41084
|
| Abstract | LOGPATH FORMAT UNDER MSCS |
| Users Affected | WebSphere MQ for Windows for V5.3, customers using MSCS. Platforms affected: Windows |
| Error Description | When running the command: hamvmqm /m REGR /dd E:\folder1 /ld E:\folder1\log the LogPath for the queue manager gets changed to E:\folder1\log\REGR with no trailing backslash. |
| Problem Summary | When the queue manager is created with the MQ Explorer GUI, or with crtmqm, the logs folder name specified by the user gets concatenated with the queue manager name, followed by a backslash. For example, if I do a "crtmqm -ld C:\folder1\log REGR", the LogPath for that queue manager is set to "C:\folder1 \log\REGR\". Now, do an "hamvmqm /m REGR /dd E:\folder1 /ld E:\folder1\log", the LogPath for that queue manager gets changed to "E:\folder1 \log\REGR" with no trailing backslash. |
| Problem Conclusion | The problem was that, we set the registry key directly, then amqmsrvn updates the queue manager logging parameters without the '\'. The solution was to pass the LogPath appended with the '\' to amqmsrvn. |
IC39879
|
| Abstract | ADD SEND EXIT, RECEIVE EXIT AND MESSAGE EXIT PROPERTIES IN THE MQENVIRONMENT CLASS OF THE .NET INTERFACE |
| Users Affected | Users who want to use the exit properties in the .NET application should apply this fix & use the properties provided. Platforms affected: Windows |
| Error Description | Make code changes to add the send, receive & message exit properties to the MQEnvironment class of the .NET interface. |
| Problem Summary | The send, receive and message exit properties were not added in the code. Prior to applying this fix, only the security exit property was made available in fix pack 6. |
| Problem Conclusion | The send, receive and msgexit properties which were not available for the .NET interface are made available once this fix is applied. The properties are added in the MQEnvironment class. Format/Syntax to use the new properties - MQEnvironment.SendExit = "Exit Name"; MQEnvironment.ReceiveExit = "Exit Name"; MQEnvironment.MsgExit = "Exit Name"; |
85215
| Abstract | MQM400 THE QUEUE MANAGER WILL NOT START AND OTHER MQSERIES JOBS WILL NOT RUN WHEN QMQM IS IN THE SYSTEM LIBRARY LIST |
| Users Affected | All MQSeries users who have library QMQM or QTEMP or QGPL in the *SYSTEM portion of the library list. Platforms affected: iSeries |
| Error Description | The Queue Manager will not start and MQSeries jobs will not run. The MQSeries job ends abnormally, and the joblog states that the QMQM library was duplicated (CPF1151). |
| Problem Summary | The problem will happen when MQSeries is using SBMJOB to start an MQSeries job in functions xcsExecProgram or cciTcpStartResponder. These functions derive the initial library list (INLLIBL) from the default MQSeries job description. This job description (QMQM/QMQMJOBD) has QTEMP, QMQM & QGPL in the INLLIBL. If any of these libraries are in the system portion (QSYSLIBL) of the library list, then the submit job will fail a CPF1151 error in the MQSeries job log. |
| Problem Conclusion | The problem has been fixed. When an MQSeries job cannot be started because one or more of the required run-time libraries is already in the system portion of the library list, then the job will be re-submitted using INLLIBL(*CURRENT). If this second SBMJOB also fails, then an FDC error report with error code xecP_E_SUBMISSION_ERROR and probe id XC037003 in xcsExecProgram or probe id CO212002 in cciTcpStartResponder. |
84797
| Abstract | IN ORDER TO USE THE REQUEST METRICS APPLICATION WITH WEBSPHERE APPLICATION SERVER VERSION 6 THIS IFIX MUST BE APPLIED. |
| Users Affected | All users of the Request Metrics application in WebSphere Application Server version 6 Platforms affected: All Distributed+Java |
| Error Description | The Request Metrics application requires WMQJMS to carry extra Properties. This iFix allows the WMQJMS client to carry the properties required. If this iFix is not applied the following errors may be seen : javax.jms.MessageFormatException: MQJMS1058: Invalid message property name: JMS_IBM_RMCorrelator at com.ibm.jms.JMSMessage.newMessageFormatException (JMSMessage.java:4750) at com.ibm.jms.JMSMessage.setStringProperty (JMSMessage.java:5757) at TestBytesMessage.main(TestBytesMessage.java:22) javax.jms.MessageFormatException: MQJMS1058: Invalid message property name: JMS_IBM_ARMCorrelator at com.ibm.jms.JMSMessage.newMessageFormatException (JMSMessage.java:4750) at com.ibm.jms.JMSMessage.setStringProperty (JMSMessage.java:5757) at TestBytesMessage.main(TestBytesMessage.java:22) |
| Problem Summary | The Request Metrics application requires Vendor specific JMS properties to be used. By default the WMQJMS client refuses Vendor specific properties that it does not know about. |
| Problem Conclusion | The JMS Vendor specific properties can be carried on WMQJMS messages. These properties were required between WMQ service releases for WAS6. |
84739
| Abstract | ENABLE SUPPORT FOR WEBSPHERE MQ 5.3 ON RED HAT ENTERPRISE LINUX VERSION 3 |
| Users Affected | This fix addresses problems seen on Red Hat Enterprise Linux version 3 Platforms affected: Linux,Linux/390 |
| Error Description | This fix enables support for WebSphere MQ 5.3 on Red Hat Enterprise Linux version 3. Without this fix customers may see various problems including segmentation violations, problems with C++ applications, install problems and problems starting Queue Managers. |
| Problem Summary | There are a couple of problems with running WebSphere MQ on Red Hat Enterprise Linux version 3. When WebSphere MQ 5.3 was originally released it was designed to support Linux Threads on 2.4 kernels and C++ applications were expected to be compiled with g++ versions 3.0.3 or 2.95.2. However Red Hat Enterprise Linux version 3 uses NPTL threads and ships g++ 3.2 compiler. These changes to the OS architecture cause problems for WebSphere MQ, which as a result requires this fix to enable support. |
| Problem Conclusion | This fix enables support for WebSphere MQ 5.3 on Red Hat Enterprise Linux version 3 by: * Supplying 3.2 C++ libraries. These MUST be used when compiling C++ applications * Supplying a later service release of the JRE which is used to run the GSKit administration tools gsk6cmd and gsk6ikm. This was necessary because previous service releases are unsupported on Red Hat Enterprise Linux version 3 * Stipulating that this APAR is _ONLY_ supported on the condition that customers export the environment variable 'LD_ASSUME_KERNEL=2.4.19'. Note this _MUST_ be set in the environment when doing _ANY_ WebSphere MQ related activities including installing the product, starting/running/stopping Queue Managers, running applications, tracing, using runmqsc etc. This environment variable is needed to enable the threading model which WebSphere MQ requires. |
84698
| Abstract | APPLICATION ERROR. MCH0601 UNMONITORED BY AMQOUICX AT STATEMENT 00000000...?. |
| Users Affected | WMQ 5.3 users on iSeries that use WRKMQMMSG on a queue having large number of messages to view the message data. Platforms affected: iSeries |
| Error Description | The following command used to browse the messages in a queue having large number of messages: WRKMQMMSG QNAME(?TESTQ?) MQMNAME(?TESTQM?) MAXMSG(99999) MAXMSGLEN(999999) The MAXMSG and MAXMSGLEN parameters set to large values. The action code 8 in front of messages after certain number of messages cause the application error MCH0601. The message number from where the problem starts depends on the values set on MAXMSG and MAXMSGLEN parameters of WRKMQMMSG command. |
| Problem Summary | The WRMQMMSG can display maximum of 40,000 messages in the panel list due to the OS400 limitation of 16Meg max list size. The WRKMQMMSG program receives MQRC_BUFFER_ERROR after certain number of MQGETs. But it ignores this error and adds messages into the list. This causes the MCH0601 when WRKMQMMSG option 8 tries to access data after getting the MQRC_BUFFER_ERROR. |
| Problem Conclusion | If the MQRC_BUFFER_ERROR returned by MQGET, then stop adding the messages into the list. The error should be reported back to the user. Limited the calculation of total messages data size to a maximum of 40000 messages. |
82952
| Abstract | GSKIT MAY CREATE A KEY DATABASE FILE WITH A FILE EXTENSION OF '..KDB', FOR EXAMPLE 'KEY..KDB' |
| Users Affected | This problem only occurs if customers create a key database on the command line and do not specify the file extension explicitly. Platforms affected: All Unix |
| Error Description | The problem occurs when customers try to create a key database using the GSKit product. It was possible that GSKit would create a key database file with the extension '..kdb' instead of '.kdb' as it should be. This only happened if customers created a key database on the command line and did not specify the file extension explicitly. |
| Problem Summary | This problem was caused by a GSKit defect |
| Problem Conclusion | The new version of GSKit corrects this behavior |
82028
| Abstract | MQM400 RCDMQMIMG MISLEADING STATISTICS IN MESSAGE AMQ8190 |
| Users Affected | Record media image issues misleading count of succeeded/failed objects in AMQ8190 message. Platforms affected: iSeries,All Unix,Windows |
| Error Description | When RCDMQMIMG is used with generic object names and multiple object types the count of succeeded/failed objects applies only to one object type (usually Queue objects). Failed objects is not counting the process objects. Succeeded objects is not counting the catalogue and queue manager objects. |
| Problem Summary | When RCDMQMIMG is used with generic object names and multiple object types the count of succeeded/failed objects applies only to one object type (usually Queue objects). Failed objects is not counting the process objects. Succeeded objects is not counting the catalogue and queue manager objects. For example: RCDMQMIMG OBJ(B*) OBJTYPE(*ALL) MQMNAME(ALGF) AMQ7086 Media image for object ALGF, type CATALOGUE recorded. AMQ7086 Media image for object ALGF, type QMGR recorded. AMQ7084 Object BBC, type PROCESS damaged. AMQ7084 Object BPROC, type PROCESS damaged. AMQ7084 Object BBC, type QUEUE damaged. AMQ7085 Media image for object BLCLQ, type QUEUE recorded. AMQ7460 WebSphere MQ startup journal information. AMQ7462 WebSphere MQ media recovery journal information. AMQ8190 RCDMQMIMG succeeded on 1 objects and failed on 1 objects. CPF0001 Error found on RCDMQMIMG command. |
| Problem Conclusion | Changes are made in record media image service program. The code to count number of objects recorded/failed added to all object types (catalogue , queue manager , process ) and generic object names. |
81896
| Abstract | AN MQPUT OF A VALID SEGMENTED PCF MESSAGE FAILS WITH REASON MQRC_CFH_ERROR. |
| Users Affected | Application message segmentation and PCF messages. Platforms affected: All Distributed |
| Error Description | Messages with a version 2 message descriptor are validated during the MQPUT call as described in the WebSphere MQ Application Programming Reference documentation. For PCF messages validation can only occur if the MQCFH structure is present in the PCF message. If a PCF message is segmented, only the first segment will contain the MQCFH structure; subsequent segment will only contain PCF parameters. If a PCF message is segmented by an application rather than by the queue manager and put with the option MQPMO_LOGICAL_ORDER, all non-first segments will fail to be put with reason MQRC_CFH_ERROR because the queue manager incorrectly detects that the MQCFH structure should not be present in the message. |
| Problem Summary | The validation function was checking whether the MQCFH structure was expected using the Offset field in the message descriptor. However, when MQPMO_LOGICAL_ORDER is used the Offset field is not set until after the validation function has completed. The unset Offset field led the validation function to assume the MQCFH structure should be present. |
| Problem Conclusion | The validation function no longer checks the Offset field of the message descriptor but uses internal state to find the offset. Non-first segments now no longer require an MQCFH structure to be present to pass validation. |
74539
| Abstract | STRMQMCHL FAILS WITH JOB DESCRIPTION QMQMJOBD IN QMGR LIBRARY NOT FOUND. |
| Users Affected | Users who delete the MQ job description, QMQMJOBD of type *JOBD in the qmgr library when MQ is up and running. Platforms affected: iSeries |
| Error Description | MQ commands that uses QMQMJOBD in the QMGR library fails with this error under certain conditions. Example of MQ commands are STRMQMCHL, STRMQMLSR etc. A FDC is generated with Probe Id:- XC037003 on Component:- xcsExecProgram. Error message "WebSphere MQ job submission error" and "An internal WebSphere MQ error has occurred" are received. The job log shows "Job description QMQMJOBD in library QM not found". |
| Problem Summary | Caching of *JOBDs for a performance improvement for customers using the non-threaded listener and having lots of client channel connections/jobs caused the problem to occur if the JOBD was deleted and it was still cached. The *JOBDs are cached in the activation group - and so the circumvention is sign off then sign on again. |
| Problem Conclusion | Caching of *JOBDS has been removed completely. |
67267
| Abstract | MQM400 INCONSISTENT REFERENCE TO OS/400 COMMANDS IN QSYS. |
| Users Affected | If there is different version of OS/400 command in the system part of the library list and above QSYS. Platforms affected: iSeries |
| Error Description | AMQ7047 message is seen while creating queue manager. The MQSeries trace shows OS/400 message CPF0006 for the submit job of the execution controller. The above error is seen when SBMJOB command is having different version in the system part of the library list and above QSYS. e.g. OS/400 is updated from V4R2 to V4R4. The SBMJOB command is not updated since moving from V4R2 to V4R4 and V4R4 introduces new parameters to the SBMJOB command. |
| Problem Summary | AMQ7047 message is seen while creating queue manager. The MQSeries trace shows OS/400 message CPF0006 for the submit job of the execution controller. The above error is seen when SBMJOB command has different versions in the system part of the library list and above QSYS. e.g. OS/400 is updated from V4R2 to V4R4. The SBMJOB command is not updated since moving from V4R2 to V4R4 and V4R4 introduces new parameters to the SBMJOB command. |
| Problem Conclusion | The MQ programs calling OS/400 system commands are prefixed with 'QSYS/' |
[{"Product":{"code":"SSFKSJ","label":"WebSphere MQ"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"APAR \/ Maintenance","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF012","label":"IBM i"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"5.3","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Product Synonym
WMQ MQ
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg27007218