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

Ember Crooks
Ember Crooks

Ember is always curious and thrives on change. She has built internationally recognized expertise in IBM Db2, spent a year working with high-volume MySQL, and is now learning Snowflake. Ember shares both posts about her core skill sets and her journey learning Snowflake.

Ember lives in Denver and work from home

Articles: 554


  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.