ree,
Amazing. Yesterday in the CB, I was asking about options of limiting the scope of unsafe signals. When prompted "why would you want to do that?", I indicated that I was trying to get an exclusive lock on a table using DBD::DB2 but instead of failing instantly it was going into a lock-wait state. After discovering alarm didn't work as desired with safe signals, I tested and found unsafe signals to work. It turns out there is a way to limit how long you are willing to wait for a lock at the session level. The setting is not exposed through DBD::DB2 but rather is done using $dbh->do($statement).

It was pointed out to me by Corion as it has been to you here that this is likely because the DB driver is also using alarm to handle the built-in time out. Assuming we are right, you have two options. The first is to use unsafe signals. The second is to discover how to time out your connection natively and trap it in a eval as I did.