Testing and debugging an application program on Db2 for z/OS®
Depending on the situation, testing your application program
might involve setting up a test environment, testing SQL statements,
debugging your programs, and reading output from the precompiler.
Designing a test data structure
When you test an application that accesses Db2 data, you should have Db2 data available for testing. To do this, you can create test tables and views.
Populating the test tables with data
To populate test tables, use SQL INSERT statements or the LOAD utility.
Methods for testing SQL statements
You can test your SQL statements by using SQL Processing Using File Input (SPUFI) or the command line processor.
Executing SQL by using SPUFI
You can execute SQL statements dynamically in a TSO session by using the SPUFI (SQL processor using file input) facility.
Testing an external user-defined function
Some commonly used debugging tools, such as TSO TEST, are not available in the environment where user-defined functions run. You need to use alternative testing strategies.
Debugging stored procedures
When debugging stored procedures, you might need to use different techniques than you would use for regular application programs. For example, some commonly used debugging tools, such as TSO TEST, are not available in the environment where stored procedures run.
Debugging an application program
Many sites have guidelines regarding what to do if a program abnormally terminates.
Finding a violated referential or check constraint
When you receive an SQL error because of a constraint violation, look at the SQLCA for specific information.