You use PREPARE and EXECUTE if the SQL statement text s not known in
advance. SQL allows only values to be passed in at execution (through
parameter markers or variables).
Identifiers (such as a table name) cannot be variable.
That is:
'SELECT * FROM ? WHERE ?.? = 5' is not legal SQL.
So, if you want to compose SQL on the fly you have to glue together the
SQL string:
SET txt = 'SELECT * FROM ' || mytable || 'WHERE ' || mytable || '.' ||
mycolumn || '= 5'
And then prepare (compile) and execute the statement.
Note that queries (as above) are executed by opening a CURSOR, while
UPDATE/DELETE/INSERT/MERGE/CALL and DDL statements get executed using
the EXECUTE statement (they don't return resultsets).

If are are using SQL Procedures you can afford to stay reasonably
ignorant on those.
Compilation of any procedure happens in up to three phases:
1. PREP
   Separate the SQL from the programming logic (e.g. C)
2. BIND compile the SQL and store the result in a PACKAGE on the server
3. Compile and Link the programming logic for external procedure

For an SQL Procedure there are really only 2 interfaces you have with
the package:
REBIND_ROUTINE_PACKAGE() which you call after statistics for tables used
in the procedure have been updated or e.g. an index has been dropped.
http://publib.boulder.ibm.com/infocenter/db2luw/v8//topic/com.ibm.db2.udb.doc/ad
min/r0009863.htm

SET_ROUTINE_OPTS()
which you can call before creating a procedure to change its semantics
(such as the isolation level) from the default.
http://publib.boulder.ibm.com/infocenter/db2luw/v8//topic/com.ibm.db2.udb.doc/ad
min/r0011873.htm

Cheers
Serge