Considerations for stubbing calls to Db2® on z/OS

When you stub calls to Db2® on z/OS, you must review several considerations.

Stubs that are created from the recordings of calls to Db2® on z/OS use the same agent for z/OS filters that were used in the recording. The name of the filter and the corresponding EQA_DBG_RIT_ID are displayed on the Summary tab of the Stub editor.

When a stub is started, the agent for z/OS connects to the Profile Service to create either a DTCN profile, a Delay Debug profile, or both. When a program that matches the filter criteria within the profile runs, the programs EXEC SQL calls are routed to the stub.

The Db2® for z/OS stubs contain multiple options to enable some calls to be passed through to the real database. The options are as follows:

Option	Description
Pass-through unlearned tables	This option causes the stub to process SELECT and FETCH statements that reference tables that exist in the simulation database, while passing SELECT and FETCH statements that reference tables that are not in the simulation database back to the real database.
Pass-through unlearned stored procedures	This option causes the stub to process stored procedures that are known to the simulation database, while passing stored procedures that are not in the simulation database back to the real database. Note: When a stub passes a stored procedure through to the real Db2® database, the stub is unable to process FETCH commands against a cursor allocated to the stored procedure.
Pass-through unlearned INSERT/UPDATE/DELETE statements	This option causes the stub to process INSERT, UPDATE, and DELETE statements that reference tables that exist in the simulation database, while passing INSERT, UPDATE, and DELETE statements that reference tables that are not in the simulation database back to the real database.
Automatically learn Queries after pass-through	This option causes result sets created from passed through SELECT and FETCH statements to be added to the simulation database. When you use this option, you must also select the Persistent stub option on the Summary tab. When a stub is run with this option, when the stub is stopped, you can see that the stub shows in the Test Factory as updated. You must save the updated stub for the learned data to be saved in the simulation database.
Empty Results	This option enables for each table that is selected, the SELECT statements that produce no rows are passed through to the real database. If the SELECT statement contains joined tables, all the joined tables must be selected in the Empty Results list to be passed through to the real database.