APAR status
Closed as program error.
Error description
When starting the queue manager with strmqm -ns, the OAM (this is the default authorization component for a new queue manager) is missing some basic configuration, including the CommandLevel for the queue manager. This zero CommandLevel leads to the OAM mis-handling authorization records where these have been obtained from an LDAP repository. On UNIX and Linux platforms, this affects records in which the user or group name is longer than 12 characters. If any record is stored back to the OAM permanent datastore, the user or group names in that record are truncated to 12 characters. On Windows platforms, this affects all records. If any record is stored back to the OAM permanent datastore, then the user and group names are stored in a corrupt way, including heap memory from after the record. It is possible that in attempting to copy more than the correct amount of data, a memory exception will occur. On all platforms, any record stored back to the OAM permanent datastore will lose its internal "Schema" attribute, which records which repository (LDAP or OS) was the originator of that data.
Local fix
Avoid running commands which create/alter authority records against a queue manager which was started with the -ns parameter. If such commands are required, and the queue manager was started with the -ns parameter, stop the queue manager and perform a full queue manager start (without the -ns parameter) prior to running these commands.
Problem summary
**************************************************************** USERS AFFECTED: MQ Administrators who start the queue manager using strmqm -ns, and who then define queues or use setmqaut or SET AUTHREC commands to alter authorizations. A queue manager that is using a user-supplied authorization service is not affected by this APAR. Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: The zero value for the CommandLevel leads to the OAM to mis-handle authorization records where these have been obtained from an LDAP repository.
Problem conclusion
The MQ code in the OAM has been corrected so that the true value for the CommandLevel is obtained while the OAM is initializing. This avoids the incorrect logic that is described in this APAR. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v8.0 8.0.0.15 v9.0 LTS 9.0.0.10 v9.1 CD TBC. v9.1 LTS 9.1.0.6 The latest available maintenance can be obtained from 'WebSphere MQ Recommended Fixes' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037 If the maintenance level is not yet available information on its planned availability can be found in 'WebSphere MQ Planned Maintenance Release Dates' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309 ---------------------------------------------------------------
Temporary fix
Comments
APAR Information
APAR number
IT31684
Reported component name
IBM MQ BASE MP
Reported component ID
5724H7271
Reported release
910
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2020-01-29
Closed date
2020-04-28
Last modified date
2020-04-28
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
IBM MQ BASE MP
Fixed component ID
5724H7271
Applicable component levels
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
29 April 2020