gtpa2m40Application Programming

Test System Components

The following components of the test facilities will be discussed in somewhat more detail in this section:

System Test Compiler (STC)

All testing requires test data. Three types of data are generally required: program data, data representing system or application records, and message data. The system test compiler (STC) programs provide the basic tool for this data preparation. Figure 43 shows the STC environment. STC is also used to generate initial system and application data records, including global area data.

STC, executing offline under MVS control, generates a test unit tape that is the primary input for testing under the program test vehicle (PTV). The test unit tape contains one or more test units. A test unit is generated via STC statements in the form of card image inputs. Some of the input is merely copied to tape and represents commands ultimately interpreted by PTV or DOF. Other input contains statements that invoke STC offline programs to insert programs and data into the test unit. The programs and data in an STC-generated test unit are used by PTV to modify a TPF set of online files with a function equivalent to a TPF system load. When PTV is in control, the set of online files is ordinarily called a test database. The following card image inputs are processed by STC to form a test unit.

Figure 43. System Test Compiler


RUNID
This identifies the beginning of a test unit. The card image is placed on tape for use by PTV.

PTV options
These options are used by PTV and RTT to control test options, and will be described in the following sections. STC places an exact image of the following PTV option card images on the test unit tape:

Data
This is used by STC to generate a sentinel on the test unit tape which marks the beginning of data records for PTV.

Data Card Images (STC Instructions)
Data records and test messages are generated with the same procedures. STC either extracts records or messages from a file called Standard Data/Message File (SDMF) or by generating them through the use of data declarations placed on a file called Data Record Information Library (DRIL). The DRIL file contains a data declaration of all the records in the TPF system for which there is a corresponding declarative macro in the TPF macro library. The DRIL declaration of a record is composed of a series of assembly language statements which define the data record. The STC user is, therefore, capable of generating data to be placed on a test unit by using STC statements and the macro name and definition of the record. A data record or message is produced with an STC generation start (GSTAR) instruction.

For example:

AM0SG     GSTAR 1
AM0LIT    ENT X'020406'.

causes STC to create an input message and place the value 020406 in the terminal address field of the message. (Absolute values rather than symbolic references can be used to create data records and messages).

The SDMF file contains "canned" data records and messages. The same procedure used to generate data records and messages through a DRIL reference is also used to generate the canned data contained on the SDMF file. This data can be transferred to the test unit tape by using the appropriate STC segments.

All data records generated by STC contain a 200-byte prefix that is used to communicate address information to the loading program. The address information usually consists of record types and ordinal numbers which are converted, via FACE or FACS, to absolute file addresses at load time. These card images are illustrated in Figure 44.

Figure 44. Multiple Test Units


MSG
This is used by STC generate a sentinel on the test unit tape which marks the beginning of messages for PTV.

Message Card Images
These are the procedures used to create messages are identical to those used for data records.

In addition to generating the test unit tape input for PTV, STC may also be used to generate pilot tapes. These tapes contain predefined sets of data records which can be loaded onto the TPF files either by the TPF system loader facility or by PTV. This facility can be used either in a test environment or to load initial data for an operational environment.

For further details on the use of STC see the following documents:

Program Test Vehicle (PTV)

PTV controls the execution of test cases. In order to execute PTV in a multi-I-stream environment, the system must be IPLed in uniprocessor mode since the PTV facility is not capable of multiprocessing. PTV testing requires the use of the TPF system loader to create the equivalent of online files.

Files adhering to the standard TPF data structure but generated for the purpose of testing are the test database and are maintained using the TPF system loading facility. Data can be dynamically and temporarily replaced or added by the PTV loading facilities for the duration of a test.

Following the IPL sequence and TPF system initialization, the TPF restart scheduler program enters the first PTV program which starts the test environment.

PTV provides extensive test facilities to execute application programs in an environment which runs under the control of the TPF system control program. Inputs to PTV are one or more test units on a test unit tape (TUT) created by the system test compiler (STC). STC may also be used to create an input pilot tape (SDF) for PTV which contains application data records. A file pool directory file is used to initialize the pool directories. Information generated by a test run is written to the real-time log tape, RTL, or the real-time tape, RTA, for later processing by the diagnostic output formatter (DOF). Figure 45 represents an overview of PTV.

Figure 45. Program Test Vehicle


The following capabilities are provided by PTV:

Control information generated by STC and placed on a test unit tape (TUT) is used to specify PTV options for each test unit in unit and package testing. A system restart is used to invoke PTV. Before PTV processes an input tape, an operator is requested to input a command to identify the type of test, that is, unit/package test or system test. If the test is a system test, then some of the PTV options must be selected by a command, otherwise the options are selected with parameters in the RUNID statement. The significant PTV options are:

Package Test

Package test may be at the individual program level or the package level. It depends on standard TPF facilities; no special test macros are provided (or allowed). It is ideal for testing interfaces among system and application programs in a controlled environment.

Package testing consists of:

System Test

The system test environment consists of a major application or class of applications loaded on the test database files and a TPF system which includes the PTV programs activated. Generally the files include a structured test database which eases the analysis of test results. The only input placed on the test unit tape is a collection of input messages (no PTV options, programs or data). PTV options are selected at the beginning of a test run with a command. The application is driven by creating multiple entries from the messages found on the test unit tape. The application is, in essence, in an online environment. Terminals may be used in addition to the test unit tape input.

Live Test

At times, the test database is used without PTV programs activated. Terminals are used for input instead. This means that test SCRIPTs are provided to the people who enter messages. This is often called live testing. Real-time trace (RTT) options and selective file dump and trace (SFDT) options are selected through the use of commands. PTV options may not be used.

For additional information on the use of PTV see TPF Operations and TPF Program Development Support Reference.

Real-Time Trace (RTT)

The real-time trace program (RTT) is used to monitor and record the activity of application programs in the TPF system. RTT can be run in an operational system or when testing under the control of PTV. The output of the RTT is a historical record of input message and control program macro activity. The level of detail of the output is controlled by option indicators in commands when used in an operational environment and by control cards when used in a PTV environment.

RTT sets indicators in the ECB to indicate which macros are to be traced and the output required. Options may be selected to trace:

Macros and macro groups (for example, all Find macros) are used to select conditions upon which RTT should provide trace information. The type and amount of data included in the trace option may be specified to include only a simple logging of the macro execution or more extensive logging. The logging option may be further modified by the PTV dump option if RTT is used in conjunction with PTV package testing. All output is written to the real time log tape.

For additional information, see the TPF Program Development Support Reference.

Selective File Dump and Trace (SFDT)

The selective file dump and trace program (SFDT) provides a debugging aid for file type activities. Like real-time trace, selective file dump and trace can be run on the online system or when testing under the control of PTV. All output is written to the real time log tape.

The selective file dump programs write specified file records (primary and chain if desired) to the real-time log tape. Functional messages during online operation and control cards during PTV testing may be included at any point in the processing to help determine the point at which records are altered.

The selective file trace option dumps only updated records from a set of specified file records during a file trace period. At the end of the period, only the updated records are written to the real-time log tape. If any record is updated more than once, the intermediate updates are not recorded and only the final contents are output. This function enables information to be obtained about specific file record update activity for a given period of time. A subfunction provides a list of addresses of all file records updated during a trace period. Online command or PTV control cards define the trace period.

For additional information, see the TPF Program Development Support Reference.

Diagnostic Output Formatter (DOF)

The program test vehicle (PTV), real-time trace (RTT), selective file dump and trace (SFDT), TPF system error dump routine and CCP I/O trace routines produce output which is written to the real-time log tape (RTL). The Diagnostic Output Formatter (DOF) deblocks, decodes, and formats the real-time log tape data in the form of an easily readable printer listing used for debugging. DOF is executed offline under MVS control.

System test terminal simulator (STTS) programs are operated in conjunction with DOF. Each of the simulators formats and prints input and output messages as the message would appear on a specified terminal. The printed output from each of the simulators is used as a debugging aid to check message format and content.

The real-time log tape which becomes input to DOF may be processed at any time after a test run. DOF is made up of the various subroutines that format the logical record data types found on the input tape. Encoded data is formatted and interpreted for ease of readability. For example, the SVC interrupt code in the old PSW is printed as a macro mnemonic as well as a hexadecimal value. Labels are assigned to significant main storage. The ECB work area is in hexadecimal with the EBCDIC translation (if possible) on the line below. Data blocks attached to a unique ECB are grouped with that ECB for output.

For more information, see the diagnostic output formatter in TPF Program Development Support Reference and TPF Operations.

The programming event recording (PER) facility enables applications programmers to monitor specific events in a native TPF 4.1 environment. Use the ZSPER command to trace:

The information you supplied in the data parameter of the ZSPER command is compared to the particular event you are monitoring in the range you specified. If a match is detected, a PER interrupt occurs. Using the ZSPEP command specify an output device with the PRINTER parameter. This parameter lets you specify a device that is meaningful to your installation. The default is the RO CRAS. You must write a program to support the information provided at the PER exit. See TPF Program Development Support Reference and TPF Operations for additional information.