MQ appliance: Implement separate storage allocation for MQ configuration/metadata versus message data

Currently on MQ appliances, queue manager configuration, metadata, and message data share the same storage allocation, creating a critical operational failure mode. When disk space becomes depleted due to message accumulation, the entire queue manager becomes administratively inaccessible:

• WebUI becomes unresponsive: Cannot access administrative interface to clear queues or manage the queue manager

• API calls time out: REST calls to the Queue Manager become unusable, preventing automated recovery procedures

• Configuration corruption: Critical files like mq.ini can become corrupted during disk full conditions

• Recovery paradox: The very tools needed to resolve the disk space issue (queue clearing, message purging) become unavailable when they're most needed

This creates a cascading failure scenario where administrators cannot use normal operational procedures to resolve the root cause.

Implement storage domain separation on MQ appliances with distinct allocations for:

1. Configuration domain: Reserved storage for queue manager metadata, configuration files, logs, and administrative operations

   • Always maintain sufficient space for WebUI operations

   • Ensure API responsiveness even during data storage exhaustion

   • Protect critical configuration files from corruption during disk full events

2. Data domain: Dedicated storage for message data, queue contents, and transaction logs

   • Can reach full capacity without impacting administrative functions

Key benefits:

• Guaranteed administrative access: WebUI and APIs remain functional during message storage depletion

• Self-healing capability: Administrators can clear queues and resolve storage issues using standard tools

• Reduced recovery complexity: Eliminates need for complex recovery procedures

• Improved reliability: Prevents configuration corruption during storage exhaustion events