Rational® Integration Tester and Agent for z/OS technical overview

Multiple software components are involved in the recording and virtualization of EXEC SQL statements. On z/OS®, IBM z/OS Debugger intercepts the EXEC SQL commands. The information involved in the EXEC SQL statements is then passed to the Agent for z/OS, which runs on either a Windows or Linux computer.

The agent polls Rational® Test Control Panel to determine whether any Rational® Integration Tester users are recording or whether any stubs are running. If the agent finds any active recording sessions or stubs, the agent passes the Db2® EXEC SQL related data to them, based on the criteria specified within the Agent for z/OS filter.

The following diagram illustrates the interactions amongst Rational® Integration Tester, Rational® Test Control Panel, the Agent for z/OS, and IBM z/OS Debugger when you record EXEC SQL statements from a program that runs under CICS.
Note: The events that occur when you record a program that runs as part of a batch job are different.

Agent for z/OS overview

  1. Within the Recording Studio of Rational® Integration Tester, you select a Db2® event monitor, and then start to record.
  2. You are prompted to specify the name of an Agent for z/OS Filter that contains the filter criteria to use to determine which programs SQL statements is to be recorded. The filter criteria can include the program name, the ID of the user who runs the program, the terminal or IP address from which the program was initiated, and several other factors.
  3. Rational® Integration Tester passes the recording rule to Rational® Test Control Panel, which then notifies the Agent for z/OS of the rule.
  4. The Agent for z/OS contacts the Profile Service in IBM z/OS Debugger to create a DTCN profile that contains the filter criteria, the hostname, and port number where the agent is running, and a unique identifier for the recording session in Rational® Integration Tester.
  5. You start the program under test within CICS.
  6. IBM z/OS Debugger traps the EXEC SQL statement and passes it to the Agent for z/OS.
  7. The Agent for z/OS passes the SQL statement and any result set to Rational® Integration Tester.
  8. If a stub is created from the recording, the Db2® artifacts are created or updated within the simulation database.

Agent for z/OS considerations

Consider the following points about the Agent for z/OS:

  • The processing of Db2 calls from COBOL and PL/I programs is slower when running against a stub (virtually) than when running against the actual Db2 for z/OS database.
  • The Agent for z/OS intercepts calls from programs that run on z/OS to Db2® that runs on z/OS. Because the agent runs on another platform, the speed and latency of the network connection between the z/OS system and the Agent for z/OS can impact performance.
  • A single instance of the agent can accommodate multiple Db2® subsystems across multiple z/OS systems.
  • Each transport is associated with a simulation database schema. All stubs associated with the transport share the simulation database and schema. For this reason, stubs associated with a transport must only be run one at a time.
  • The agent appears to Rational® Test Control Panel as both an Agent for z/OS and a JDBC agent.
  • During a simulation, the z/OS Agent populates the SQLCODE, SQLSTATE, and SQLERRM fields within the SQLCA if an error condition is encountered.
  • The maximum heap size for the z/OS Agent is set to 1GB by the -Xmx1024m parameter in the zosAgent.ini file. If you process large tables, you might need to increase the heap size if you encounter OutOfMemory exceptions in the z/OS Agent log file. This is also a consideration for Rational® Integration Tester. For more information about setting the maximum memory usage for Rational® Integration Tester, see JVM Arguments.
  • When recording and learning large tables, there might be a delay between the start of the job being recorded, and the first events that appear in the Recording Studio.
  • When recording and learning large tables, messages such as The Green Hat JDBC driver is not able to process events quickly enough to keep up with the application. The simulation database may be incomplete might be displayed. You can avoid these messages by adjusting the number of events that the z/OS Agent queues by changing the value of the event-queue-depth parameter in the registration.xml within the z/OS Agent directory. If you increase this value, you might also need to increase the heap size for the z/OS Agent.