Testing CICS Programs

Testing a CICS program is not different from testing a batch program. All setup of the program is made at the Component in the repository. Non-virtualized Test will call the CICS program directly using a Call interface CICSLINK, CICSCALL or CICS, or Component type TRANSACTION where it's its own transaction. Non-virtualized Test can also start a new transaction by just providing the input data to the transaction. This scenario is described below and is not a recommended way of testing programs even though it sometimes can be necessary.

For a CICS program, the CICS applid must be set as the CICS call type and optionally a CICS channel. These values can be defined at the Environment, at the System and at the Component. Component values will override System values that will override Environment values. If the CICS program uses Db2, the Db2 Subsystem ID and plan must also be set.

The call type can either be CICSLINK, CICSCALL or CICS. See descriptions of these in Environments.

A CICS program that uses containers and/or temporary storage for input/output parameters must be setup for this and it can only be made for call type CICSLINK. Also, a program that uses containers and/or temporary storage cannot use parameters from commarea. This is not a Non-virtualized Test restriction, it is a CICS restriction. How to setup the component is described in Using CICS Containers, Temporary Storage and TWA.

STOP RUN

If a program has a STOP RUN, Total Test will generate a warning message in the execution results (execution bar displays orange).

Using Sub Module Stubbing in CICS

When setting up a test scenario, the sub module stubbing mechanism is used independently of which environment the test scenario is executed against. If the test scenario is executed against a CICS environment there is however one important difference compared to executing the test scenario against a Batch environment. Because of the nature of CICS, all programs running in a local CICS region are common to all users/transactions, which means when stubbing out a dynamic sub module for a test scenario, the sub module will replace the original sub module in the local CICS region during the time the test scenario executes execute. This might have side effects, as other programs that are executed while the stub is active may also call the stub module instead of the real module. To overcome this limitation, it is recommended to use zD&T boxes and not simultaneously execute test scenarios against the same CICS that are using the same stubs.

Direct CICS Execution Through MQ

Staring with z/OS Agent version 17.2.0, it is possible to execute a CICS program directly through an MQ queue instead of using the default protocol of submitting a batch job to issue an EXCI execution. This makes the execution faster, but has the limitation that sub module stubs cannot be handled.

Starting a CICS Transaction

A Component can be defined as a Component type Transaction. This means that Non-virtualized Test will start a transaction and provide input data in the format from the component definition. When executing a test scenario containing a component of type Transaction, the test scenario will continue after the transaction has completed. No data will be returned by the transaction (this is how a transaction works), and therefore data cannot be verified in the test scenario. Instead, other elements must be used in the test scenario to ensure that the outcome of the transaction is correct. This involves verifying data in data sets and in Db2. For this purpose, the elements Verify Dataset, SQL Select and Verify can be used.

Starting a CICS transaction is not a preferred way of testing. Instead it's better to define the program started by the transaction as a component and test this instead. Sub modules of the main program should also be tested individually.