Something I forgot to mention in my recent DB2-for-non-i-developers post is that database tables created using DDS are frequently left to the default CCSID of 65535, which means 'treat stored data as binary'.
This causes trouble when you access the database via ODBC (or indeed JDBC - see hint/tip #14), since alphanumeric fields are not transcoded, resulting in a lot of EBCDIC data that is meaningless in a PC context. (If you get a load of incomprehensible output with lots of @ signs in it, this is what's happened - the @ signs (hex 40) are spaces in EBCDIC.)
To resolve this, you need to tell the ODBC driver to ignore the 65535 setting and transcode the data. (It will use the CCSID on your user profile.) Here's the setting: