Bad Message Queue Handler. Sit. Stay.

Posted by

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

2014-07-30- 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:

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”…

Lead Database Administrator
Ember is always curious and thrives on change. Working in IT provides a lot of that change, but after 18 years developing a top-level expertise on Db2 for mid-range servers and more than 7 years blogging about it, Ember is hungry for new challenges and looks to expand her skill set to the Data Engineering role for Data Science. With in-depth SQL and RDBMS knowledge, Ember shares both posts about her core skill set and her journey into Data Science. Ember lives in Denver and work from home


  1. 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. 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 🙂

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.