Help

Defining and Using Components

In this section, we will go into details about the center of Non-virtualized Test – the components. We will discuss how a component is defined in the repository and the options available when setting up a component execution in a test scenario. Appendix A: Tutorial — Add a Component to the Repository with the Web Client also contains a tutorial for adding components to the repository.

A component in the repository represents a physical program and contains all information needed for executing the program. The component also contains descriptive information such as a label and description and location of its source code. The component inherits parameters from the environment and optionally the system it references, and it can override the values by specifying the parameters for the component.

The following information can be specified:

Component

  • Component. Required name of the program

  • Label. An optional descriptive label for the program. Default is the same as the program name.

  • System. Optional system to use. A system (see also Systems) specifies source and runtime parameters used by a group of programs and is a way to normalize these parameters. The component will use the system source and runtime parameters as default and can override the values in its own specifications

  • Environment. Required environment at which the program is located.

  • Component Type: Required type – COBOL, ASSEMBLER, PL/I, TRANSACTION.

General information

  • Version: The version of the program in the repository. Refer to Versioning for more information about using versions.

  • Category. Optional category used for categorizing components.

  • Access control. Optional. Restriction on which user groups that are allowed to see the component.

  • Tags. Optional textural tags that can be used when searching for the component.

  • Allow execute without credentials. Toggle that is used for allowing users to execute the program through graphical skins without logging into Total Test.

Source parameters

  • Main source library. Optional source library for the component source code. Used for extracting copybook names, sub modules and analyzing the linkage section for extracting metadata.

  • Additional source libraries. Optional additional source libraries for copybooks used by the component. Used for analyzing linkage section.

  • Optional Copybook names. Optional list of names of the copybooks used. Only used for documentation purposes and for the possibility to extract data definitions from the copybooks, which can be really useful for non-COBOL programs where Non-virtualized Test (Functional Test) does not have a source code scanner.

Runtime parameters

  • Load libraries. Required load libraries where the program executable is located.

  • Optional main module. Only for testing statically linked subprograms/entry points.

  • Db2 Subsystem Id. Optional Db2 Subsystem ID to use at runtime. Needed when the program uses Db2.
            Note: When using the CALL Attach Facility (CAF), leave this field blank, instead include the Db2 load libraries in the Load Libraries field.

  • Db2 plan. Optional Db2 plan. Needed when the program uses Db2.
            Note: When using the CALL Attach Facility (CAF), leave this field blank.

CALL Attach Facility Considerations

When a main program includes CAF calls and it calls a subroutine that includes Db2 calls (EXEC SQL), then Non-virtualized Test has no direct way to supply the contents of the CAF calls that establish a connection to Db2. However, there are two alternatives: One is to rely on implicit connections. The other is to use DSNULI instead of DSNALI. Then the TSO attach mechanism can be used.

  • Module is AMODE24. Toggle that must be enabled for 24 bit mainframe programs.

  • Call interface. How to call the program. Options depend on the environment (CICS or BATCH).

JCL/Script

  • JCL/Script. Optional JCL used when executing the component. If the Only use component references is selected, then JCL specified for the system will not be used. A list of datasets to be deleted before execution can also be specified. This will often be output datasets that the component will produce during execution.

JCL Pre Step

  • JCL Pre Step. Optional JCL to be used in a step before executing the component. The pre step can also contain user libs used in the JCL.

Data structure

  • Data structure. Another required part of the Component definition — for programs with a call interface — is the data structure, i.e. what the call area looks like. The data structure can be defined manually by adding structures and fields to the structure, but it is much easier to use the Total Test COBOL scanner from the browser or the EGL and COBOL scanner from Eclipse to return the data. Based on the source libraries it will scan the source code and return the data structure. For programming languages other than COBOL and EGL, it is possible to write a COBOL copy book that declares the data structure. The name of the copybook can be entered into the Copybook names field, and copybooks can be analyzed by clicking the Extract data definition button.

It is possible to define more information for each field in the data structure. The following information can be added to a field:

Note:  Components can be added and modified from the web client and the Eclipse client.

  • Minimum length. Optional minimum length of field that Total Test will verify before executing the component.

  • Minimum count. Optional minimum count when count is larger than 0. Can be used for components that allow a variable number of input fields.

  • Default value. Optional default value that will be automatically used when using the component in test scenarios.

  • Description. A descriptive field used for usability purposes.

  • Native type. The original type definition from the parsed language.

  • Input/Output type. Specifies whether the field is used for input, output or both. Used for usability purposes.

  • Optional Encoding. Optional encoding to use for the field when calling the program. This can be Default(EBCDIC), UTF8 or UTF16. If the encoding is UTF8/16, values will be transferred to the host as Unicode and used as Unicode when executing the component.

  • Show one field for all occurrences. If enabled on a structure or field with count or occurs larger than one, then Total Test will show just one input field where the user can enter a value. This value will be parted into data pieces that will be assigned to the individual occurrences.

  • Reference. Used for a pointer field to reference another structure

  • Type. Property that can be set on top level elements only. It tells what kind of area type it is. Default area type is called Default and is used for comm area. The Pointer area type is used for a top level element that is not included in the call, but instead specifies the structure of data for a pointer field. For CICS programs using CICS LINK, there are five more area types: CICS BIT container, CICS CHAR container, CICS temporary storage main and CICS temporary storage auxiliary and CICS TWA. More properties need to be setup for elements using CICS area types (see also Using CICS Containers, Temporary Storage and TWA).