Bad Message Queue Handler. Sit. Stay.

There’s an error message that appears in my db2 diagnostic logs rather frequently. It looks like this:

2014-07-30-13.34.58.446316+000 E1638372A476         LEVEL: Error (OS)
PID     : 32374944             TID : 1              PROC : db2
INSTANCE: db2inst1             NODE : 000
HOSTNAME: redacted
EDUID   : 1
FUNCTION: DB2 UDB, oper system services, sqlodque, probe:2
MESSAGE : ZRC=0x870F003E=-2029060034=SQLO_QUE_BAD_HANDLE "Bad Queue Handle"
          DIA8555C An invalid message queue handle was encountered.
CALLED  : OS, -, msgctl
OSERR   : EINVAL (22) "Invalid argument"

Mostly I’ve just ignored it, but recently had a client with an over-zealous Tivoli implementation that started sending me alerts every time they occurred. Dozens of times per day. Now I’m personally just fine with figuring out something isn’t really a problem and then ignoring it. But when I have to explain why it isn’t a problem to a client, I have to provide more details. It didn’t take long to come up with this technote:http://www-01.ibm.com/support/docview.wss?uid=swg21259051

Reading through that, I learned that this error message is written to the diagnostic log whenever someone pipes the output of a db2 command to head, tail, or more (which I do fairly frequently). It also occurs when several different languages execute db2 commands without a database interface – so in Perl when I use open, system, or “. Yeah, I run scripts that do that at least hourly if not more frequently.

The part that perplexes me here is why DB2 considers this type of thing an ERROR level event? Is there a scenario where this same error is returned and it is a really serious problem.

I have to go now, so I can train some Tivoli admins on working with a DBA rather than just blindly alerting on everything in the DB2 diagnostic log that says “Error”…

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.

    Peter

  2. Mikko Kostamo says:

    You could use variables and pipe that variable:

    db2 list applications | grep -q db2reorg

    vs.

    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 *