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