When installing TestBench you may be required to alter some OS/400 object authorities for all functions to work correctly.
The installation process will make the required authority changes on your behalf if you wish (option 4 below).
There are four typical approaches:-
- Give each user of TestBench the required authorities as an individual.
- Make a group profile for all TestBench users, give the group profile the required authorities
- Create an authorisation list, name the TestBench users as part of this list and reference the list against the objects listed below.
- Grant the required authorities to the @TBEXEC profile, see full explanation below.
Option 4 above has the lowest maintenance, and once set up will not require modification in order to add a new TestBench user.
During the installation process two profiles are automatically created, @TBOWNER and @TBEXEC. For both of these profiles the password is defined as *NONE which prevents anyone signing on with them. Most objects within TestBench will be owned by @TBOWNER and for security reasons this should not be changed.
However the majority of the TestBench programs that use IBM commands are owned by @TBEXEC and they adopt owner authority. During the installation process the command SETCMDAUT is automatically prompted and if Enter is pressed @TBEXEC will be granted the required authority to the commands listed.
These are the commands that are often not part of a typical authority profile. If there are any additional commands that the User does not have authority to, these can either be added to the list or the SETCMDAUT command can be run again at a later date to include them (use F4 to prompt the command and specify a profile of @TBEXEC).
TestBench includes an authority checking command that is run automatically when the product starts and this will notify you of any authority issues that exist. Each object identified as an issue is listed in the job log with the level of authority required. The Utilities and Information menu in TestBench also has an option to run this command at any time as well as an option to display the joblog. Hence you can run this while making authority changes until all the issues are resolved.
TestBench uses certain IBM commands and optionally makes copies of others either to intercept functions that might corrupt the test environment, or to control submitted jobs.
The full list of access to IBM commands is checked in the Authority check command, but certain ones are sometimes not part of a typical authority profile and hence some of them have been listed here with an explanation for your understanding. These are the commands that will be listed by the SETCMDAUT command during the installation process, and if Enter is pressed on the command screen the required authorities will be granted to the @TBEXEC profile.
The following authorities are required on the following commands if you wish to make full use of the TestBench functionality. This is not an exhaustive list, the full list of commands and their required authorities is shown on the screen print above.
Command Authority Purpose
CRTLIB *USE To build a temporary test environment, or to create a new library to contain extracted data.
DLTLIB *USE To delete temporary libraries created (as above).
CHGSYSLIBL *USE Put test environment first in the library list.
RTVSYSVAL *OBJMGT To be copied to log system date retrievals.
OVRDBF *OBJMGT To be copied to log/fix file overrides to non-protected file copies.
ENDGRPJOB *OBJMGT To be copied to track all jobs created as part of a test.
RMVJRNCHG *OBJMGT To be copied to remove changes from a test environment.
If you do not wish to allow the use of the CHGSYSLIBL command there is an alternative approach which also means that a reduced level of authority is acceptable for some other IBM commands. This however reduces the amount of testing functionality that can be used. See the following section for further information.
This is an essential command for TestBench if you wish to use the full testing functionality that is available. During the execution of a test a temporary library is created that must reside above all other System, Product and User libraries. This ensures that the files designated for protection during the test run and any other objects copied by TestBench for the duration of the test are always higher in the library list than other copies of the same objects in the library list. Achieving this via the system library list is important because:-
- Many applications alter the User portion of the library list and any attempt to provide TestBench facilities at this level would be rapidly corrupted. Whilst it would be possible to monitor for all alterations to the User portion of the library list, this very monitoring would require the use of the CHGSYSLIBL command.
- Certain applications issue proprietary commands which include a Product Library. When executed such libraries are placed at the top of the Product portion of the library list, once again with the potential to corrupt the very test data that TestBench is designed to protect. It should also be noted that there is no reason why data files cannot exist in the System portion of the library list and these again cannot be protected without access to the CHGSYSLIBL command.
- Interception of OS/400 commands that can cause TestBench facilities to be corrupted. An example would be when an Override Database File command is issued which includes a TOFILE with a hard-coded Library. Unattended such a command can cause the very test data that TestBench is designed to protect, to become corrupted.
If you do not wish to allow the use of the CHGSYSLIBL command there is a flag on the System Values screen that must be set to ‘2’. If you do this there are several implications due to the fact that there will be no test run time library and therefore no objects can be copied into it. The following testing functionality cannot be used:-
• Data Protection. Environment protection only is allowed.
• Tracking submitted jobs.
• Program interception.
• Data Queue interception.
• RTVSYSVAL or OVRDBF interception.
• Testing of Group Jobs.
The further implication of this is that *OBJMGT authority is no longer required for the IBM commands RTVSYSVAL, OVRDBF, SBMJOB and ENDGRPJOB.
OVRDBF & RTVSYSVAL
TestBench allows each of these commands to be intercepted so that a user can monitor for application processes which would corrupt the facilities that TestBench is designed to provide. As stated above an OVRDBF command that includes a hard-coded library could cause the master version of the test data to be corrupted. The RTVSYSVAL command can be monitored so that any attempt to retrieve the System Date can be logged and made to terminate a test run. This is because retrieving the System Date might bypass a date environment in a Test run based on Job date.
This command is needed for Environment protection. It is used to roll back the data from the file as long as it is being journaled.
During a test all Group Jobs are tracked so that results can be saved for each. If any of these jobs are still active at the end of the test, TestBench will be unable to delete the run-time environment. This command is used to end any active Group Jobs that were created during this test.
The first time that TestBench is launched, the product logo will be displayed. This comprises the word ‘TEST’ dropping vertically from the top of the screen, the word ‘BENCH’ arriving horizontally from the right-hand side of the screen and our company details appearing character by character in the bottom half of the screen. To enjoy this display once the product has been initially launched, take the option 1 from the Utilities Menu.
In most circumstances the logo is displayed without significant delay. For example it takes 6 seconds to display the logo on a dial-up connection running under TCP/IP against a dedicated iSeries.
However, if it takes more than 2 seconds for the word ‘TEST’ to drop from the top of the screen to its correct position, TestBench will terminate the staged creation of the logo and display it immediately in its entirety with a performance warning message at the foot of the screen.
If you wish to inhibit the display of the logo even on the first execution of TestBench, specify option ‘4’ on the System Values screen for the logo display parameter. Alternatively, specify options ‘2’ or ‘3’ to remove the drop-down display and show the full logo screen immediately.
These cosmetic effects are achieved by direct creation of the 5250 data stream. It should be noted that some PC based 5250 screen emulators do not always display our logo correctly. To correct any difficulties you may be having, contact your emulator supplier for the appropriate fix.