Defining and Using Components

In this section, we will go into details about the center of Functional 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 D: Tutorial — Add a Component to the Repository with the Web Client and Appendix E: Tutorial – Add a Component to the Repository with the Eclipse Client also contain tutorials 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. Required name of the program

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

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

  • 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.

  • 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 Functional Test.

  • 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.

  • 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 Functional Test does not have a source code scanner.

  • Main load library. Required load library where the program executable is located.

  • Additional load libraries. Optional additional load libraries needed for executing the component.

  • Db2 Id. Optional Db2 ID. Needed when the program uses Db2.

  • Db2 plan. Optional Db2 plan. Needed when the program uses Db2.

  • Rollback. Toggle that specifies if the transaction should be rolled back after the execution. Default is false.

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

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

  • JCL/Test Scenario. 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. 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. 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 Functional 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 button.

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

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

  • Minimum length. Optional minimum length of field that Functional 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. Specifies if the field is used for input, output or both. Used for usability purposes.

  • 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 Functional 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

  • Area 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).