MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  AMQ8149S error questions

    Posted 08/29/22 10:17 AM
    We had an issue with one of our mounted volumes that MQ is using.  When MQ restarted I noticed the following errors in the log.  This is from a uniform cluster configuration and the error occurs at startup.  

    1 : DEFINE CHANNEL('+AUTOCL+_+QMNAME+') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('+CONNAME+') CLUSTER('+AUTOCL+') REPLACE
    AMQ8149S: IBM MQ object damaged.
    AMQ8149S: IBM MQ object damaged.
    AMQ8014I: IBM MQ channel created.

    The 8149 severe error occurs twice and then I see the 8014 info message saying the channel was created.  Can I assume from this that MQ was able to recover whatever was damaged?  I don't see any additional errors after this.

    If something were unrecoverable then my assumption is the 8014 message would be some other error message instead, stating the channel could not be created.  Is there a way to detect this sort of condition and pre-empt it, maybe by running the rcrmqobj command.  I'm looking for the appropriate way to handle this sort of error scenario.

    Thanks,
    Jim

    ------------------------------
    Jim Creasman
    ------------------------------


  • 2.  RE: AMQ8149S error questions

    Posted 09/12/22 12:50 PM
    Hi Jim,

    I don't think it would ever be expected to have a damaged object from creating a channel. I would expect that an FDC file would have been created indicating what object was damaged and why. If you're using linear logging, then you could use rcrmqobj to recover the objects, but it's always a good idea to try and understand what caused the damage to try and avoid it.

    Is this a recreatable problem? Can you find any more information on the damage?

    Kind regards,
    David

    ------------------------------
    David McCann
    IBM
    ------------------------------



  • 3.  RE: AMQ8149S error questions

    Posted 09/13/22 02:34 PM
    This is stated to be a queue manager restart, and it would not be normal for a new channel to be created as part of QM restart.
    The define is a "define replace" and so perhaps it is intended to ensure the channel always exists, rather than to recreate the object?
    However, the AMQ8014I message states "channel created" which seems a bit of a surprise.

    "The log" clearly isn't the AMQERRnn.LOG, and in addition to there likely being FDC's with further details of the issue there are also likely to be further messages in the AMQERRnn.LOG logs giving further details of the issue.

    Perhaps the damaged object could be the SYNCQ? Which might then be automatically recovered, and could be recovered even in the event of a circular logging queue manager, but that wouldn't explain why the channel would be "created" unless the customer knows that this channel didn't exist at the time the Qmgr was "restarted".

    It's hard to be sure of anything given the lack of detail provided, however it does seem quite likely there's something here worth investigating further.

    ------------------------------
    Andrew Hickson
    ------------------------------

    Original Message


  • 4.  RE: AMQ8149S error questions

    Posted 09/14/22 05:17 PM
    David/Andrew,

         Thanks for your responses.  I did look for FDC errors and found some.  The background on this is we have MQ deployed in Kubernetes containers.  By "restart" I mean when the pod is forced to restart.  This action reruns the basic configuration that was initially set up in an MQSC file.  We use the REPLACE option so the command files are re-runnable and everything starts from a fixed state.

         There were some issues with the persistent storage volumes that caused the original problem for MQ (volumes became read-only).  After resolving the storage issue I noticed the above error occurred when some of the pods with MQ restarted.  Our fix was to remove the PVCs as well so K8s would recreate them along with the MQ pods.  Now, everything comes up cleanly. 

         This occurred in one of our development environments so data loss is not a concern.  My main interest was to find out more about the severe errors.  I'll look through the FDC files to see if I can pinpoint exactly what was corrupted.

    Thanks,
    Jim

    ------------------------------
    Jim Creasman
    ------------------------------



Related Content