CSQV086E QUEUE MANAGER ABNORMAL TERMINATION REASON=00D96001 due to ABN=5C6-00D70108 in CSQP1CON

Resolving The Problem

• Set REGION=0M for the IBM MQ job as recommended in the Address space storage topic.
  
  
• Check LOGLOAD in the queue manager parameters. The default setting of 500000 is preferred. Using the maximum setting of 16000000 means there will be many more recovery log records to process since the last checkpoint. The storage used to process those records can cause the storage shortage in SP229 KEY7. Storage has many IUWD control block eyecatchers.
  
  If the restart failure is due to a high LOGLOAD parameter, lower it to prevent the problem in the future. For the present, restart will still fail until sufficient storage is available. Temporarily lower settings such as BUFFPOOL size (for example to 1000), trace table size, and OUTBUFF, or take other steps to allow enough storage for the recovery to complete. Then, do a normal restart of the queue manger with the original BUFFPOOL and trace settings.
  
  
• If the queue manager still will not restart, cold start it as described in the topic "Reinitializing a queue manager".
  Warning: You should only perform a cold start if you cannot restart the queue manager any other way. Performing a cold start enables you to recover your queue manager and your object definitions; you will not be able to recover your message data.

Additional information
The 5C6 abend codes do not always appear in the joblog or syslog if their dumps were suppressed. If you see the CSQV086E message for ABEND=S6C6 REASON=00000000 without a dump or message for a more detailed reason code, run an EREP report for the time of the restart. You should see a LOGREC record for another abend code which had its dump suppressed. Modify DAE, so that a dump can be taken for the symptom and repeat the restart. PM77250 for MQ 7.0.1 and 7.1.0 (included in base V8.0) will cause CSQY291E to be issued if the SDUMP is suppressed.

Another symptom of the problem is