Choosing a simulation database

When you create and run a stub to virtualize calls from z/OS® programs to Db2®, the data is stored in a simulation database. You can choose to use the integrated database of Rational® Integration Tester, a Db2® database on z/OS®, or a Db2® database on either Linux or Windows.

Some Db2® for z/OS® SQL statements can only be simulated when a Db2® simulation database is used.

There are also some limitations to what you can simulate when you use Db2® as the simulation database because JDBC is used to access both the Db2® and integrated simulation databases.

The following table provides the SQL statements that can be simulated with each simulation database:
EXEC SQL Command Considerations when you use Db2® as the simulation database Considerations when you use the integrated simulation database
ALLOCATE CURSOR
ALTER INDEX
ALTER SEQUENCE
ALTER TABLE
ASSOCIATE RESULTSET
CALL
CLOSE CURSOR
CREATE INDEX
CREATE SEQUENCE
CREATE TABLE CHAR columns with length greater than 254 are not supported.
CREATE VIEW
DELETE WHERE CURRENT OF is not supported.
DROP INDEX
DROP SEQUENCE
EXECUTE Not supported.
EXECUTE IMMEDIATE Not supported.
FETCH Fetching LOB, XML, and other column types from an insensitive scrollable cursor are not supported.
INSERT
MERGE
OPEN CURSOR
PREPARE Not supported
SELECT Use of the DISTINCT keyword in the WHERE clause is not supported.
UPDATE WHERE CURRENT OF is not supported.

You should also consider performance when you choose a simulation database. Because the z/OS Agent uses a network connection to connect to the simulation database, you experience the best performance when you use a database that is located on the same system as the z/OS Agent.