Definition of the TU_TYPE input structure

Edit online

The exectu( ) interface is dependent on the definition of a Test Unit Control Block (TUCB) structure. The TUCB is defined as a C language data type called TU_TYPE, and is located in the diag/tucb.h header file. This header file must be used without modification and included in each source file using the structure.

To make the test unit functions available to a wide range of managing applications, this TUCB structure must not deviate from the defined structure. No new data types or structures may be added. Each test unit should be self-sufficient in the function provided. The data types OUTPUT_DATA and INPUT_DATA are declared as 'void' in the diag/tucb.h file. If these structures are to be used, two header files are required to redefine these parameters:

  • The {DEVICE}_err_detail.h File file should be used to define device specific error log detail output data (OUTPUT_DATA).
  • The {DEVICE}_input_params.h File file should be used to define device specific input parameter data for a test unit (INPUT_DATA).

Both header files (if used) should be included before the diag/tucb.h file.

The TU_TYPE structure is specified as follows: 

typedef struct tucb_t {
           char  *resource_name;
           TU_INPUT_TYPE parms;
} TU_TYPE;
The resource_name is a string containing the name of the hardware or physical device (as defined by the operating system) on which to run the test unit. TU_INPUT_TYPE is a substructure of TU_TYPE, and contains several input parameters, as specified in the following: 

typedef struct tucb_in_t {
            ulong tu;
            ulong loop;
            OUTPUT_DATA *data_log;
            ulong data_log_length;
            INPUT_DATA *tu_data;
            ulong tu_data_length;
            FILE *msg_file;
} TU_INPUT_TYPE;
See "Definition of EXECTU()" for structure member definitions.
Note: For most applications, the TU number and loop count are the only parameters required. However, this interface allows for an open way of passing special parameters into the Test Units and receiving detailed data back out, to allow for specialized testing environments.

Using such data requires specific knowledge about the Test Unit design in the calling application, and does not allow for generic diagnostic handling, as would be required from a system management application. However, this design would allow a remote diagnostic application, which could have detailed diagnostic design knowledge, to work through a local agent function which only has generic diagnostic knowledge. The local agent would only have to allocate buffers of the requested size, and pass data between the Test Units and the remote diagnostic application.