Testing with IBM® Db2® on z/OS® systems

With the Agent for z/OS® that works together with IBM® Debug for z/OS®, you can record SQL statements to Db2® for z/OS® databases from COBOL and PL/I programs that run on z/OS®.

The programs can run within CICS® or as a step within a batch job. You can store the results of these SQL statements in a simulation database, which you can use to virtualize calls from z/OS® programs to Db2®. You can use either Db2® for z/OS®, Db2® for Linux®, UNIX®, or Windows™, or an integrated Derby database as the simulation database. The Agent for z/OS® uses the Profile Service in IBM® z/OS Debugger to select which programs to intercept.

Agent for z/OS® software requirements

The Agent for z/OS® supports the following versions of software:

z/OS®: 2.1, 2.2, 2.3, and 2.4.
Db2®: 11.1 and 12.1.
CICS® Transaction Server: 5.2, 5.3, 5.4, and 5.5.
Enterprise COBOL: 4.2, 5.1, 5.2, 6.1, 6.2, and 6.3.
Enterprise PL/I: 4.5, 5.1, 5.2, and 5.3.
In addition, the Agent for z/OS® relies on IBM® z/OS® Debugger to intercept the EXEC SQL statements.

IBM® z/OS® Debugger is included with the following products:

IBM® Debug for z/OS® 15.

Note: The minimum supported IBM® z/OS® Debugger release is 15.0. However, 15.0.2 provides significant performance improvements when fetching a large number of columns.
IBM® Developer for z/OS® Enterprise Edition 15.
IBM® Application Delivery Foundation for z/OS® 3.3.

Rational® Integration Tester software requirements

As part of the support for Db2® for z/OS®, Rational® Integration Tester connects directly to Db2® for z/OS®. This connection requires a Db2® Connect license (db2jcc_license_cisuz.jar).

General limitations

Only IBM® Data Server Driver for JDBC and SQLJ is supported for use by Rational® Integration Tester and the Agent for z/OS® to connect to Db2®.
You can use the JDBC driver when the Oracle compatibility mode of a Db2® instance is turned on. However, the following limitations apply:
- The following Oracle data types are not supported: BFILE, BINARY_FLOAT, BINARY_DOUBLE, TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE.
- If a stored procedure has a parameter in FLOAT type, Db2® converts it to DOUBLE type. Therefore, you must use DOUBLE type when you set input parameters and register output parameters.
- A user-defined array type cannot be used as the column type.
- If HAVING and GROUP BY are used in the same SQL statement, GROUP BY must precede HAVING.
DBRM (Database Request Module) data sets for the application must be made available to the Agent for z/OS®.
- When you create a filter within Rational® Integration Tester, you must specify the DBRM data set name. Alternatively, if you update your batch job JCL to invoke IBM® z/OS® Debugger, you must set the EQA_DBG_DBRM z/OS® environment variable to specify the data set that contains the DBRM data sets.
- Only DBRM data sets with Entry Statement format 2 as specified in DSNXNBRM are supported.
- The DBRM data sets must use the same name as the corresponding program name.
If the result set returned by a stored procedure is scroll-sensitive and dynamic, the Agent for z/OS® cannot learn the stored procedure call.
Depending on the host variable, rounding of floating point data might be processed differently by the z/OS Agent than it is by Db2® for z/OS.

SQL statements

You cannot use the following SQL statements and behaviors to record, learn, or virtualize:

FETCH CURRENT CONTINUE
PREVIOUS VALUE FOR clause within SELECT, INSERT, and UPDATE statements
ALTER INDEX with REGENERATE or ADD INCLUDE clause
ALTER VIEW

The following features are not supported:

Virtualizing the use of ROWID columns for direct row access
Learning with UPDATE or DELETE with cursor statement
Learning or virtualizing SELECT, INSERT, or UPDATE statements that refer to columns that have data types:
- TIMESTAMP(0)
- TIMESTAMP(P)
- TIMESTAMP(0) WITH TIME ZONE
- TIMESTAMP(P) WITH TIME ZONE
- BLOB file reference
- CLOB file reference
- DBCLOB file reference
- XML BLOB file reference
- XML CLOB file reference
- XML DBCLOB file reference
- Result set locator
- Table locator
- DBCLOB locator

For the SQL limitations that are specific to the simulation database that is used, see Choosing a simulation database.

Encoding considerations

The following encoding considerations apply for character-string host variables:

When the Database Character Large Object (DBCLOB) file references are interpreted as a single-byte Coded Character Set Identifiers (CCSID) that contain an odd number of characters, a garbage-character might be appended at the end. DBCLOB values in PL/I applications might be truncated to half of their original lengths.
CLOB, DBCLOB, XML_CLOB, and XML_DBCLOB host variable data are interpreted as CCSID 37. All the other character-string host variable types are interpreted by using CCSID defined in the DECLARE :HV1 VARIABLE CCSID ccsid SQL statement for that variable.
If the host variable does not include a DECLARE :HV1 VARIABLE CCSID ccsid SQL statement, it is interpreted by using the CCSID that is specified by the CODEPAGE compile option. It does not matter whether the application was compiled by using the CCSID0 option (for PL/I applications), the NOSQLCCSID option (for COBOL/PL/I applications), or both.
If you want to create stubs for tables that contain VARGRAPHIC columns, the Db2® MIXED installation parameter must be set to YES.
For XML column types, the agent supports only the implicit use of XMLPARSE and XMLSERIALIZE. When the agent is simulating implicit XMLSERIALIZE, stubs include an XML element that specifies the CCSID at the beginning of each document returned in response to a SELECT or FETCH action. The inclusion of the CCSID is similar to the response that is returned by Db2® z/OS®.

PL/I limitations

The following limitations apply to PL/I programs:

Programs must be compiled with the TEST option.
Programs compiled with the RENT option are not supported.
PL/I program variables with the same names, but within different structures are not supported.