Project Properties

Before working with your  project, review the default project properties and determine which of the settings need to be modified to meet your site's requirements. To do so, open the project properties by right-clicking on the project, then select Properties from the context menu.

In the list to the left, select to display the general  properties.

Common Settings

Save Time Stamped Files

After executing a test, all information regarding this test is collected in an *.archive file, including input data, output data, check conditions and their results, as well as some additional runtime information. If you activate this option, archives from previous runs are retained by adding a timestamp to the file name and moving them to the History folder of the project. If this option is not active, archives are always overwritten when you re-run a test.

Usually, the recommended solution is to use an SCM product for the purpose of archiving. If you do not have an SCM product available or, for some reason, do not want to use it for  archives, you can activate this option to obtain at least a simple versioning.

This option is inactive by default.

Execution Options

Use Stubs

With the aid of test stubs, instead of actually calling a program, a simulation is performed at runtime, acting as if the called program processed the call and returns a pre-defined set of return data.

This options controls if stubs defined in a test scenario should be used or not. If this option is active, all stubs defined in a test scenario will be activated during the test which means that the stubbed interfaces will be simulated as defined. If this option is not active, stubbing will not be used during the test run, even if the scenario contains stubs. This enables you to switch off stubbing without having to remove all stubs from the test scenarios.

This option is active by default. Its project setting can be overridden in the Test Run dialog.

Stubbing is an optional feature. Refer to Stubs for more information on stubs.

Delete Temporary Files

Some temporary files are created during the execution of a test on the client and on the target platform. These files are needed to collect the scenario specification into an archive and to transfer the input and output data between client and target platform. Usually, these temporary files are not needed any more after the execution has completed. However, if you want to re-submit the test job for use with a debugger, the temporary files are required to resume the test execution. In this case, switch this option to off to maintain the temporary files after execution.

If this option is active, then all temporary files will be deleted once the execution has been completed. If this option is not active, all temporary files will be kept.

This option is active by default. Its project setting can be overridden in the Test Run dialog.

Test Aids

Initialization with byte value (hex string)

The initialization of empty attributes with specific values is a test aid that helps to identify problems caused by the use of uninitialized data by the test target. This may apply to the use of data not passed in a call as well as missing return values. Such problems are often difficult to identify because during testing, there may be no difference between uninitialized and initialized data. Therefore, problems usually occur later, maybe even in production, and are usually not easy to reproduce. With the help of this test aid, uninitialized data can be distinguished from initialized data.

In order to activate this option, in Initialization of empty fields enter a string to be used for the initialization of all fields with no defined value. The string must be in hexadecimal representation. Choose a value that is unique so it differs significantly from common initialization values. A good and proven example is x'EE' as it largely improbable to appear within real data.

In the Test Run dialog, you can decide if this option is used or not. If not used, all fields without defined values will be initialized with a value of zero for numeric data types, and with a value of spaces for character data types. Note that this "clean" initialization renders it impossible to identify initialization problems.

Dataset allocation

Use this section to specify SMS parameters, dataset location, and working file override information for all files  creates for this project on the mainframe, including binary input (BININP), binary results (BINRES), Code Debug log (XPLOG), Code Coverage, etc. files.

SMS parameters

Specify SMS parameters if this project requires SMS settings other than your site's default SMS settings.

Management class

Specify the SMS management class if this project requires SMS settings other than your site's default SMS settings.

Storage class

Specify the SMS storage class if this project requires SMS settings other than your site's default SMS settings.

Data class

Specify the SMS data class if this project requires SMS settings other than your site's default SMS settings.

Dataset location

Specify the dataset location (Volume and Unit) if this project requires settings other than your site's default settings.

Working file overrides

Use this section to override the default number of blocks allocated for the binary input (BININP) and binary results (BINRES) datasets on the mainframe. When many records are present in a test case/stub, it might be necessary to increase the primary and/or secondary extends for these files.

Override Default Allocation Sizes

Check the Override Default Allocation Sizes check box to activate the override values you specify for the primary and secondary extends for the BININP and BINRES datasets. The value 0 (zero) specifies using the default allocation. The default allocation is based on the total size of the test data for the test run.

An allocation override is necessary when the test run produces allocation failures, typically for very large datasets with over a million records. Check the JES log for allocation failure messages as they might include references about the allocation size.

You can only enter override values for BININP and BINRES datasets when Override Default Allocation Sizes is checked. The override values will be applied the next time you execute the test (see also Unsuccessful Execution).

COBOL Copybook Importer

On the left of the project properties dialog, extend the  entry and select COBOL Copybook Importer to display the COBOL Copybook Importer properties.

Copybook Replacements

If you use text replacements in your copybooks which are resolved using a COPY REPLACING statement in your COBOL programs, it is necessary to specify replacement strings in this properties dialog. If you do not use replacements, it is not required to provide any settings here.

Add replacements by clicking Add, then enter the From text string as found in the copybook, and the To text string which will replace the former during import. Add more replacements if necessary. Edit or remove replacements by selecting the entry, then clicking on the appropriate button on the right.

During import, multiple replacements can take place. All defined replacements are used. Longer strings are replaced first to avoid unwanted side effects. For example, if you specify that ABC be replaced by XXX and ACBDE be replaced by YYY, during import, a text ACBDEF will be replaced by YYYF, not by XXXDEF – which is probably just what you would expect.

For more information, see Importing Structures.

Renaming, Moving and Deleting Resources

If you rename a structure, interface, scenario or stub file, all resources that reference it will be updated accordingly.

Similarly, if you move a file, all references it contains as well as references to it in other files will be updated accordingly, unless you are just dragging and dropping it. You must use the Move entry from the context menu in order to move a file and at the same time update all references. In order to do so, right-click on the resource you want to move, then select Move from the context menu, and in the pop-up window, select the target folder you want to move it to.

If you delete a structure, interface, scenario, or stub file, it will be removed from all resources that reference it.

Before the actual update is performed, you can always click on the Preview button in order to see which resources will be affected by the update.