S0C4 resolved with upgrade to latest T4Z BUILD.
Article ID: 367787
Updated On:
Products
Issue/Introduction
The customer used T4Z replay job and this failed with a S0C4.
Environment
Test4Z 1.0
Resolution
The customer upgraded to the latest, [email protected] build, and this resolved their S0C4 issue. Our recommendation to assist in problem resolution is to add the ZLOPTS parameters and set options to DEEP, COVERAGE, INSTRUCTION, STEP, so the ZLMSG output captures information from the run.
There are four different modes that can be executed for Test4z. Some of these modes are for regression testing and others are for unit testing.
1. RECORD runs the user program under control of the record & replay test, to collect and record program-program argument data along with any of the arguments that are passed to and from middleware. The recorded output can then be used by the unit testing, replay, or verification processors. Access to the program and middleware arguments is available through the ZLTEST user-defined input. By specifying commands in the ZLTEST input, arguments can be altered during the recording process to allow the creation of a test for non-standard (unhappy path) flows through the program. These altered argument values are recorded so that when replay or unit testing executes the program, it continues to execute the altered flow path resulting in wider program testing. Also recorded data, whether it is the happy path or the unhappy path, can be directly fed into unit testing.
2. REPLAY runs the user program under control of the record & replay test, but virtualizes (mocks out) the calls to the middleware. No actual middleware is accessed during replay processing and the middleware environment is not used. During replay processing, program-program and input arguments to middleware are compared to ensure that the data is the same as when recorded during record processing. Any mismatches are identified as possible problems. This process is useful for stable applications or when validating applications during compiler upgrades.
3. VERIFICATION runs the user program under control of the record & replay test, using both the real middleware and the recorded data. During verification processing, program-program and all arguments to and from middleware are compared against the values that are recorded during record processing. Any mismatches are identified as possible problems. This process is useful for validating middleware during middleware upgrades. If a ZLNEXT DD statement is provided (using similar DCB details as the ZLDATA dataset), new JSON data is written to it that matches the real middleware that is used by the verification calls. The output written to ZLNEXT output provides a user with a new baseline set of recorded data.
4. UNIT TESTING allows a user to define a collection of tests on a unit of work (one or more programs within a load module, or one or more sections within a COBOL program). These tests use either the real middleware, the recorded JSON data, or provide mocked values.
Test4z runtime options can be specified for any of the processing modes by using the ZLOPTS input file. These options allow a user to specify the processing mode or activate many of the features that the runtime supports. To specify these options a user must define a ZLOPTS DD statement in their JCL and specify their required options. The options that are specified in the input file can be on a single line or multiple lines and space or comma delimited. Leading spaces are ignored. The options can be in upper, lower, or mixed case and the order in which they are given does not matter.
DEEP and TRACE are the Test4z runtime options that are available in all testing modes to provide some tracing of the events that occur during execution.
1. DEEP turns on a deeper tracing than the standard tracing level that the TRACE option provides.
2. TRACE turns on module load, function invocation and some internal tracing. For deeper internal tracing, refer to the DEEP option.
COVERAGE is Test4z runtime options that can be used for Test4z code coverage in all modes.
1. COVERAGE turns on code coverage processing for the current mode. This is the default for unit testing only. Other execution modes have code coverage turned off by default, which can be altered to provide code coverage if desired.
INSTRUCTION and STEP show the execution of the program as each machine instruction runs. Register contents are displayed and watched memory can be displayed. The Test4z batch tracing facility can be turned on to trace the execution of machine code of a user application as it executes. To activate this mode, specify the following.
1. INSTRUCTION turns on tracing at the machine instruction level. Once the Test4z batch tracing facility has been activated by using the INSTRUCTION option, then Test4z runtime options can be used to modify the type of tracing to be produced.
2. STEP turns on a single machine instruction stepping, instead of setting the next breakpoint at the next branch type statement.
Feedback
