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”…
[…] Bad Message Queue Handler. Sit. Stay. […]
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
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 🙂