PI15847: DFSOTMAQ QUEUE NOT PROCESSING AFTER CQS0270I ADDED IT TO CQS OVERFLOW STRUCTURE.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• In a Shared Queues environment DFSOMTAQ was added to
  a CQS Overflow Structure. Once it was moved it was no longer
  processing messages. No more GU's were being done for
  DFSOTMAQ after the move to Overflow as no more CQS
  INFORMs were being done.
  This could potentially happen with other Queues moved to
  Overflow as well, not just DFSOMTAQ.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All IMS V11 users of shared message queues   *
  *                 or shared EMH queues with an overflow        *
  *                 structure defined.                           *
  ****************************************************************
  * PROBLEM DESCRIPTION: Queues that are selected to be moved to *
  *                      the CQS overflow structure may stop     *
  *                      being processed by one or more IMSs.    *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  A timing problem exists in CQS overflow processing where queue
  names that are selected to be moved to the CQS overflow
  structure stop being processed by one or more of the IMSs
  connected to the shared message queue or shared EMH structures.
  
  When a queue is moved to the overflow structure, CQS must issue
  an IXLLIST MONITOR_SUBLIST call to begin monitoring the queue
  name on the overflow structure.  This monitoring is used to
  know when to notify an IMS with interest in the queue name
  that there is work to do on the queue.  CQS overflow processing
  sends an asynchronous request to perform this "inform"
  processing, via an AWE (asynchronous work element) queued to
  the INFM AWE server.  The overflow thread continues to execute
  after sending this asynchronous request.
  
  The AWE sent to the INFM server points to a buffer that contains
  the list of queue names that were moved to the overflow
  structure.  That buffer can be freed by the overflow thread that
  queued the AWE.  There is no synchronization between the
  overflow thread and the INFM AWE server.  If the buffer is freed
  and reused before the INFM AWE is processed, the list of queue
  names moved to overflow may be overlaid.  This could cause the
  inform registrations to search for the wrong queue names, and to
  not issue the IXLLIST MONITOR_SUBLIST calls for the queues that
  were moved.  Those queues will not be monitored as long as they
  are in the overflow structure, and thus, CQS will not receive
  notifications when there is work to do on those queues, and in
  turn will not notify IMS to process the work.
  
  Also note another possible symptom of this is an ABEND0C4 in
  the INFM AWE server if the buffer that was released by the
  overflow process is physically FREEMAINed, rather than being
  reused.
  
  This same timing exposure exists for the "uninform" process that
  occurs when queue names are removed from the overflow process.
  While this uninform timing window will not cause queues to not
  be processed, there is still the risk of an ABEND0C4 if the
  buffer containing the removed queue names is physically freed.
  

Problem conclusion

• GEN:
  KEYWORDS:
   SYSPLEXSQ
  
  *** END IMS KEYWORDS ***
  A new AWE server type -- OINF -- is created.  This server
  executes module CQSINF00, just as the existing INFM server does.
  However, it is only used for processing overflow inform and
  uninform requests.
  
  The AWE enqueue for the overflow inform and uninform requests in
  CQSOFL50 is changed from asynchronous to synchronous.  CQSOFL50
  will wait until posted back from CQSINF00 indicating that the
  AWE is processed, and only then will it continue the processing
  that will eventually free the queue name buffers.  Additionally,
  the overflow inform and uninform AWEs are now queued to the
  new OINF AWE server instead of the INFM AWE server.  Queuing to
  a separate server avoids a deadlock that could otherwise occur
  if a prior AWE was waiting under the INFM server for the
  quiesce latch, which is held by the CQSOFL50 thread now waiting
  for the AWE to be processed.
  
  CQSINF00 is changed to create a new trace record in the STR
  trace table for each queue name that is considered for inform or
  uninform processing.  Note that queue names are traced, even if
  no IXLLIST MONITOR_SUBLIST is issued for them (as would be the
  case if the IMS connected to the CQS had no interest in the
  queue name).  This provides improved diagnosability in the
  overflow inform / uninform area.
  
  CQSFTRC0 is changed to format the new CQSOFL00 trace entries.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

  PI15503

• APAR is sysrouted TO one or more of the following:

  UI17797

Modules/Macros

• CQSBPAW0 CQSFTRC0 CQSINF00 CQSOFL50 CQSTRINF
  

Fix information

• Fixed component name

  IMS V11

• Fixed component ID

  5635A0200

Applicable component levels

• R100 PSY UI17797

     UP14/05/14 P F405 ¢

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.