When the set up tasks are complete ( Setting up the test environment), you can begin NaviQuest testing. The initial testing establishes the base line test set against data sets that will never be SMS managed. Because they are not managed, they have an expected result of null ('') for each storage class, storage group, data class, and management class.
Requirement: For these test cases, you must use the subtype prefix NEVR.
After the base line test is complete, you can test each phase, or cycle, of the SMS implementation, one subtype at a time. Normally, a SMS implementation phase is made up of either a single data type or several data subtypes. Each data subtype is tested independently. Once each data subtype tests correctly, you can begin data conversion for SMS for that phase.
Recommendation: Put all test cases into the initial base line test set. This will save you from having to repeat adding data types or subtypes one at a time.
Use the following procedure to test your base line test set or any other phase.
The multivolume variable is always set to "Yes" in an ISMF table if the data set is not open at the time the table is saved. The value is set correctly at the time the data set is opened, which can sometimes cause errors in the bulk test case generator.
After you have created the list, enter the SAVE command on the command line to save the list into a table. For information on the SAVE command, see z/OS DFSMS Using the Interactive Storage Management Facility.
_______________________________________________________________
Use the Test Case Generation Selection Menu panel to turn the ISMF list, DCOLLECT data, SMS data generated by the storage class ACS exit, and VMA data into standard SMS test cases.
Recommendation: If you do not enter a PDS name, NaviQuest will generate one based on the format userid.Tnn.TESTCASE. Instead, specify a name so that the test case library conforms to your installation’s naming standards.
To generate test cases from DCOLLECT data, select option 2, DCOLLECT Data, and then use Test Case Generation from DCOLLECT Data Entry panel.
Enter the following information:Before you can use this function, you must have DCOLLECT data that includes D (data set) records.
To generate test cases from the ACSTST program, select option 3, SMF Data, and then use Test Case Generation from SMF Data Entry panel.
Enter both the data set name containing the system management facility (SMF) data and the name of the test case PDS.Recommendation: This function requires that you have the IGDACSSC storage class exit installed and have extracted the SMF type 127 records. The ACSTST program is also required. Both are available in the sample library SYS1.SACBCNTL.
To generate a test case from a VMA extract file, select option 4, VMA Extract Data, and then use the Test Case Generation from VMA Extract Data Entry panel.
Enter the following information:Requirement: To use this function, you must have already run GFTAXTR from your saved SMF records (types 14, 15, 21 and 30). JCL for GFTAXTR can be found in SYS1.SAMPLIB member GFTAXTRP.
Add a 1-to-4 character subtype prefix to each test case member. The prefix must be unique for each data subtype. For example, the first group of TSO data could have subtype prefix TSOA, the second TSOB, and so on.
See step 1 for creating the ISMF table. ACBJBAG2, ACBJBAG1, ACBJBAOW, and ACBJBAI1 in SYS1.SACBCNTL JCL library can perform this task in batch (see How to run storage administration tasks in batch).
_______________________________________________________________
You must change (but not activate) the ACS code and constructs to reflect the new phase of implementation that you want to test. Before you change the ACS code and construct definitions contained in the source control data set (SCDS), save the old source in case it is needed for recovery.
For information on recovering the ACDS, refer to Recovering Storage Management Subsystem information.
You can now update the ACS routines to reflect the new data subtype you want migrated to SMS.
_______________________________________________________________
When the ACS code is changed, you might want to use the COPYFILT function of NaviQuest to update all the ACS routines from a common definition of the filter lists. You will be prompted to provide a change log entry that reflects changes you are making to the ACS routines. This entry will be automatically placed into the change log in the ACS routines.
To use the COPYFILT macro, see COPYFILT macro: COPYLIB facility for FILTLISTs.
_______________________________________________________________
You must translate and validate (but not activate) the ACS routines. refids="vs76475 ts64795">The ISMF translate function transforms ACS routines into a table format. Translation checks for syntax errors and transforms the ACS routines into a format suitable for input to the validation.
The ISMF validate function verifies that all possible constructs that can be assigned with the ACS logic have been defined to the SCDS used for testing. ACS routines must be translated before they can be validated; however, validation of ACS routines is optional.
To translate and validate, you can either use the online ISMF functions or you can use the NaviQuest ISMF-in-batch EXEC.
For online translation and validation, choose option 7 (ACS Class Selection) from the ISMF Primary Option menu. To translate, choose option 2 (Translate). To validate, choose option 3 (Validate).
To use the translate facility in batch, see ACS routine translate: ACBQBAO1.
For more information on translation, see Translating ACS routines. For more information on validation, see Validating ACS routines or an entire SCDS.
_______________________________________________________________
Create a new ACS listing by using the ISMF Test ACS Routines option (7.4.3). The testbed library contains the test cases. Specify an asterisk (*) to run all test cases in the library.
The new ACS listing represents the SMS configuration after the ACS routines have been changed for the new data subtype.
_______________________________________________________________
After the base line test, every test includes both testing of new data subtypes and regression testing of previously tested data subtypes, including the base line test set.
At this time, you use the NaviQuest ACS comparison test function to compare the results of all test cases in the testbed library with their expected results. The ACS comparison test produces a report of exceptions. Because you have not yet stored the expected results of the test cases for this data subtype, these test cases appear as exceptions. Later, in step 9, you will store the expected results for the current data subtype test cases. But for now, the exceptions you get are either these valid initial (that is, first run) test cases, or they are errors.
To run the ACS comparison test, choose option 2 from the NaviQuest Primary Option Menu.
Specify a comparison data set name to be used to store the results of the comparison. Also input whether you want to write over the data set specified if it already exists. If N is specified, and the data set name already exists, an error message will be returned. If Y is specified, the data set will be deleted, a new data set with the same name will be allocated, and the report will be written to this data set. Then press the Enter key.
You will be automatically placed into ISPF "browse" when the comparison completes. The comparison data set you are browsing lists only the test cases identified as exceptions.
If exceptions other than the test cases for the subtype you are initially testing are listed, you have probably made an error in coding the revisions to your ACS routines. Changes in coding that have caused errors must be corrected before you can proceed. This means repeating the operations until the test cases match the exceptions.
Important: Each test is an initial test for one data subtype but may include many regression tests for previously tested data subtypes. Expected values are not stored in the initially tested data subtype until its testing completes successfully.
Current test results of each previously tested data subtype should match the saved expected results previously stored with the test cases. If the results are the same, the regression test is successful. If the results differ, there is an error in the new ACS logic; that is, the ACS routine is assigning different values.
Because this is an initial test, this test case has no expected results stored in the test cases, other than null. Thus, during the comparison in step 7, all test cases for this new data subtype show an exception; that is, new results will no longer be null.
For more information about running the ACBQBAC1 EXEC in batch, see ACS test listings comparison: ACBQBAC1.
_______________________________________________________________
You must manually compare the new test cases to their expected results for the single data subtype that has been initially tested. This comparison determines if there are initial test errors. If the exceptions contain any test cases from the data subtypes previously tested correctly (in regression testing), these exceptions are also errors.
It is the manual verification of the results that makes sure that the values are the expected results. When all test cases are correct, the test values are stored in the test cases as save expected results, to be used for later regression testing.
If you find errors, you can generate the NaviQuest ACS cross-reference report for additional information about the specific test cases that produced the errors. Use this report to help you debug the ACS logic. If you find errors (from either step 7 or step 8), you must correct the ACS code before returning to step 3 and retest until the data subtype results have no errors.
If you do not find errors, the test is complete, as all the test cases in the subtype test set have the correct expected results.
Indicate whether the specified data set should be written over if it already exists. If N is specified, and the data set name already exists, an error message will be returned. If Y is specified, the data set will be deleted, a new data set with the same name will be allocated, and the report will be written to this data set.
Specify with a Y or an N which variables you want included in your report. Once you have specified all variables that you want, press the Enter key and the report will be produced.
_______________________________________________________________
Once the subtype test is correct, you can use NaviQuest to place the results of the test (that is, the expected results for later regression testing) into the test case definition as the saved expected results for later regression testing. Test results are only saved after all test cases in the subtype test set have completed with the expected results for that data subtype. The saved expected results will be used for later regression testing, as explained in step 7.
To save the test results, choose Test Case Update With Test Results Entry Panel (option 4) from the ISMF Primary Option menu, which takes you to the Test Case Update With Test Results Entry panel.
Enter the names of the testbed PDS library, the exception test case PDS, the PDS created in the ACS comparison report, and the new ACS test case listing.
The test case members for the exceptions are read and copied into the testbed library. The saved expected results are obtained from the comparison report and are also saved in the testbed library.
You have now completed testing for this data subtype and can now start testing the next data subtype.
For more information about running the ACBQBAU1 EXEC in batch, see Update test cases with expected results: ACBQBAU1.
_______________________________________________________________
Continue NaviQuest testing for each data subtype in the current SMS implementation phase. This testing either repeats Steps 1 through 10 or repeats Steps 3 through 10, depending on whether all subtype test sets are initially placed into the testbed.
After the initial test of the base line, all additional tests include regression testing along with initial testing.
_______________________________________________________________
Once an entire phase (that is, all the subtypes within the implementation phase) have tested correctly, you can activate the new configuration by using the SETSMS command at an MVS console.
For more information on activating your configuration, see Activating Storage Management Subsystem configurations.
You might want to use the NaviQuest reporting capabilities to determine the amount of DASD space required to convert the data in each phase, prior to attempting conversion. Use this information to ensure that enough DASD is available for the conversion.
_______________________________________________________________