Bad Message Queue Handler. Sit. Stay.

You may also like...

3 Responses

  1. Peter Schuetze says:

    I my naive way (without too much technical know edge of the underlying technologies) I would explain it as the receiving process closes the pipe before the sending process sent all it’s data (or tries to close the pipe). So there might be a valid reason to log that event.

    Practically I would ignore it until someone complains of missing data.


  2. Mikko Kostamo says:

    You could use variables and pipe that variable:

    db2 list applications | grep -q db2reorg


    listapp=`db2 list applications`
    echo $listapp | grep -q db2reorg

    Only problem I saw with this is output lines went a bit messy. Could be that it can be fixed with some command finetuning, but in my case it did not matter 🙂

  1. August 7, 2014

    […] Bad Message Queue Handler. Sit. Stay. […]

Leave a Reply

Your email address will not be published. Required fields are marked *