Once you have created your test data using Extract_IT and Warp_IT or through manual processes, TestBench provides facilities to ensure that this data is not unintentionally updated or corrupted. This allows you to run a program many times knowing that the starting point of all the files and data areas will be consistent. This capability is essential if you are using a ‘record and playback’ tool such as TestDrive to exercise your interactive programs, as without a data starting point identical to that when the script was created, it is inevitable that many differences will be found during the execution of the script.

This consistent starting point extends beyond data files and areas to provide a consistent starting total environment. The additional elements that can be set at the start of every test execution include; the control of the initial library, the initial values for the Local Data Area, the Job Date, and the Program Parameter Values or the initial Command String to be used.

TestBench provides these facilities by copying all the files and data areas which could be updated during a program execution into a temporary run time library named in the format @nnnnnnnnn, where the last nine positions are filled with a sequential number that is unique across all tests and Projects. This library will be placed into the default ASP on the CRTLIB command unless an alternative ASP has been defined on the System Values screen. The run time library prefix can also be changed in System Values. This library is placed at the top of the system portion of the library list of the test run. Thus it is the copy of the objects which will be updated rather than the master set of test data. When using Test Environments for managing test data, the files are not copied (see later chapter).

This approach also allows us to intercept every write, delete and update operation to the data base files which provides the basis of the powerful data effect analysis and Data Rules. The interception is based on the OS/400 journal facilities which can be initiated on the copy of the files irrelevant of whatever the site standards for its use.

Once the analysis of a test run is complete, the contents of the temporary run time library are cleared by default. If you wish to keep the modified version of these files you should specify Keep End Data options for the Process.
This type of Data Protection can be very powerful for Unit Tests where isolated parts of a system are being executed by one person. For System Testing or User Acceptance Testing, Environment Protection provides database checkpoints without creating copies in a shared testing environment.

Protection / Analysis Levels
TestBench provides several levels of data protection which allow you to select the combination of protection level, data effect analysis and recovery that you require. The only valid options are *NONE and *ENV if the CHGSYSLIBL command is not being used – see later System Library Pre-checker section for more information.
It should be noted that throughout this section the term ‘update’ is deemed to include record creation (‘writes’), record amendments (‘updates’), and record deletions (‘deletes’).

Named Library
This option allows you to direct the protection and analysis to specific data files and data areas rather than basing the protection and analysis on the information available to TestBench. This option is particularly useful in the following scenarios:

• If you have a large file which is opened for update but you know that either no updates will be processed or you are prepared to accept them, you may wish to avoid the overhead of copying this file when the test starts.
• If TestBench is unable to identify all the objects which require protection (see Exceptions), you may need to specify the objects manually.
To use this option place all data files and data areas that require protection into a single library and specify this library as your Named Library.

When this option is taken all data files and data areas within the Named Library will be protected and analysed.

Program References ( *PGMREF )
This option provides the highest level of automatic protection and analysis. It may be possible to achieve an even higher level using the Named Library option but this will require greater manual effort. This option will automatically identify all update data files and all data areas within the Test Case programs defined for each Process and all programs and service programs that they and subsequent programs, call. If the Test Case is started with a command, the references for the command processing program will only be included if the system level option ‘Expand command references’ has been set to yes. All such objects will be copied to the temporary run time library and thus protected. The rules which govern the files selected for data protection are listed below.

• All Update and Output files specifically referenced by any program in the Test Case will be protected.
• If any of the above files are Logical files, all based-on Physical files will also be protected.
• If a read-only Logical file is based on a Physical file which is already in the protection list, then this Logical file and all of it’s based-on Physical files will also be protected.
• For any Physical file already protected, all Unique-keyed Logical files built over it and all of their based-on Physical files will also be protected.

This is the default option when a Test Case is created and careful consideration should be given to the effects of the other options before it is changed.

Program ( *PGM )
This option protects the update data files and all data areas that are directly referenced by the programs attached to the Test Case Processes. If the Test Case is started with a command, the references for the command processing program will only be included if the system level option ‘Expand command references’ has been set to yes. Any update data files and any data areas that are referenced by other programs that the Test Case programs or command processing programs may call are not protected. This option is particularly useful in the following scenarios:

• If you are not concerned about the level of data protection, but do wish to analyse the data effects on the files referenced directly by the Test Case programs, this is the correct option.
• If the Test Case programs are at the top of a complex program stack, a great number of data files and areas may be identified as requiring protection if the *PGMREF option is used. However you must ensure that you will achieve sufficient protection using the *PGM option as once program calls have caused other programs to execute, the data files and areas thus referenced may not be protected. A Named Library may be a better option.
• If you have detailed knowledge of the Process programs and know that whilst they may issue program calls, you know that these do not issue any data file or data area updates, you may wish to avoid the performance overhead involved in checking these other programs during the Test Pre-Checker.

Dynamic ( *DYNAMIC )
This option enables objects to be protected only when the program referencing them is called. Objects are therefore not all protected at the start, only when they are used, reducing the performance overhead of copying objects to the run time library unnecessarily. If the Test Case is started with a command, the references for the command processing program will not be included, even if the system level option ‘Expand command references’ has been set to yes. Dynamic data protection is particularly useful in the following scenarios:

• If your starting point for the test is a top level program from which many other functions can be accessed, but there is a specific path which will be followed as part of the test.
• If your starting point is a menu which is being called via a command, and only specific options will be taken as part of the test.
In order for dynamic data protection to work, the initial program (or programs if taking several options from a menu) must be defined either as the execution program for the Process, or in Manual References. If dynamic protection is used for files with constraints, a message will be written to the warnings file at run time and the Test Run is ended. It is not possible to recreate constraints over files under these circumstances. Also, it is not possible to dynamically protect any objects referenced by service programs. This includes any program calls which may exist within a service program. These objects must be specified as manual references to be included within the scope of data protection and therefore any references against these programs will be protected at the start of the test.

When using Dynamic Data Protection, it is not possible to use the Track Submitted Jobs option at the same time. If the option is set to Yes, it will be ignored at run time and there will be no results data for the submitted jobs.

No Protection ( *NONE )
This option turns off all automatic protection and analysis. As a result no objects (unless defined in manual references) are copied into the run time library when the test is executed so there will be a performance benefit. When a test is run the data files and data areas needed will be searched for via the current library list. The library list for a test can be set and retained within TestBench at the Test Case level. This option will be useful under certain circumstances:

• If your test data is reset every night from your live environment and your test files are very large, you may be prepared to allow the test data to be updated during the course of the day.
• Alternatively once you are satisfied that a program is executing correctly you may wish to allow the data updates to occur to generate test data for the next program in the process.

Environment ( *ENV )
Use in conjunction with the ‘Environment’ option to specify which Test Environment will be used when running the Test Case. The library list set up for the Environment will be used in preference to the Test Case library list and if this is blank the current library list will be used. All journals attached to the Environment will be analysed and results reported. The time taken to create the run time environment is small because no objects are being copied, but data analysis in the form of file effects and data rules can still be achieved. See the following chapter on Test Environments.

*DIRECT If you find there is a long delay at the start of a test case, when using *DYNAMIC, try this alternative. This data protection method will short cut the program reference analysis.
The program analysis will run for just the programs called by each of the test case processes.
This will generate a list of files used by the first level programs. These files will then be copied into the run time library regardless of the way they are accessed.
An interception program will be created in the run time library for each of the programs that could be called by the top level programs. When one of these programs is called that program will be analysed, any files it accesses will be copied to the run time library, if it does not already exist there, and any further program interceptions will be generated.

Advantages
If a test case calls a menu or very high level program the program references may result in most of the system being analysed. This is time consuming and would not be necessary with the new approach.
If a test case calls a menu it is unlikely that all potential call paths will be part of the test. As a result there may be many files that would appear in the references but never get used within the test.

Disadvantages
All files referenced by a program will be copied into the run time library just before the program is called. This means that files that are only used for input are still copied along with their access paths.
If there are many files that are only used for input, or the files contain a large amount of data then this could be counterproductive. Data sets need to be of a manageable size.
This data protection type will be based upon the current *Dynamic logic, this means it will be subject to the same conditions as dynamic. Criteria such as not being able to track submitted jobs will remain in place.

Manual References
Manual References can be defined at the System or Test Case levels and enable data protection to be extended to user specified objects. This is in addition to that specified through the Data Protection options described above. If a program is specified, *PGMREF or *PGM level protection can be applied, or *DYNAMIC can be specified if the Test Case data protection option is also set to *DYNAMIC. If a file or data area is specified, this object and any based-on physical files will be protected. Manual References can also be used to exclude certain objects from protection which would normally be included through the Data Protection options above. Manual References can also be used where the initial program is accessed via a command (provided that *PGM or *PGMREF is specified against the Test Case Options) and the system level option ‘Expand command references’ is set to ‘No’.

Unlike *PGM or *PGMREF type protection which will consider related logical or physical files derived from the referenced objects, manual references require each object to be individually described. Therefore, if you wish to include a physical file and there is also a logical file which will be referenced, this must be listed also. If these files have similar names, generic values can be keyed, for example ORD* will include all files beginning with the letters ORD.

Data analysis can be achieved without protecting data by specifying a maximum of 99 journals to analyse. This may be particularly useful for large test files for which it is not always practical to turn on data protection and make copies. The journal must exist and the required files must have journaling already started in order for TestBench to perform the analysis.

Object The File or Program to be protected or the Journal for analysis purposes. Generic naming can also be used as shown above for files and data areas being included or excluded, or for programs that are being excluded only.

Library For file protection, if this entry is a file or a program, the library must be *LIBL (this is the default if left blank). Otherwise this defines the Journal location.

Type *FILE File to be protected. *PGM or *SRVPGM Program or Service Program for which protection will apply. *JRNL Existing Journal for file analysis.

Include/Exclude Either add this object to those already protected for the Test Case, or exclude this object if it is already included for protection via the Data Protection option.

Protection Relates to program or service program manual references only, and determines whether *PGM, *PGMREF or *DYNAMIC level protection will be applied.

Function Keys

F7 – Libl This is used to define the initial library list required to execute the programs under test correctly. It can be left blank in which case the current Job library list is used. This library list will also be used when searching for the objects (Files and Data Areas) which may require protection including those that are defined on the Manual References display.

Temporary Files
Files that are created as part of the test can be protected by setting the OVRDBF option in Test Case Options (F21 from Maintain a Test Case). If a file is created and then the OVRDBF command is used before opening the file in a program, it will be copied into the run-time library and protected, and file effects can be viewed in TestBench results.

Overridden Files
If a program under test uses the Override Data Base File command (OVRDBF), this potentially could bypass a protected file and write directly to an unprotected copy of the file which may be undesirable. Please refer to the previous section for additional information on protecting these files.