Testing an Area
The ERO test area function compares the contents of a system or subsystem area to the contents of packages attached to the release. Error conditions are displayed online.
As you consolidate package components in a release and as you work in packages to correct errors you find in release testing, you may create mismatches between the contents of areas and the contents of packages attached to the release. When you block a release, ERO automatically executes a test to detect mismatches between the final release area and contents of release packages.
You can find these errors earlier in the release life cycle by manually executing the test area function against any release area.
These are some of the conditions that are detected by the test area function.
-
A component is in multiple attached packages. Only one version can be installed with a release, so all but one version are invalid.
-
A component is in only one attached package, but the version in the package is different from the version in the tested area.
-
An attached package contains a component that is not checked in to the tested area.
-
An attached package contains no components, no utility requests (scratch or rename), and no Online Forms, so it is extraneous to the release.
Follow these steps to test a release area.
-
Follow these steps to access the release area that you want to test.
-
Type =7 on the Command or Option line of any panel in ChangeMan ZMF, then press Enter.
-
Type release selection criteria in fields on the Release List Specifications Parameters panel, or leave the fields blank, and press Enter.
The Release List panel is displayed.
CMNRMRLF Release List Row 1 to 2 of 2 Command ===> Scroll ===> CSR Release Sta Install Work request Dept Aud Creator Pkgs FIN6410 DEV 20160328 WR 9010 FINANCE USER015 00001 FIN6430 DEV 20160328 WR 9030 FINANCE USER015 00003 ******************************* Bottom of data *******************************
The Release List panel shows releases that satisfy the selection criteria you typed on the Release List Parameters panel.
-
On the Release List panel, type line command AR on a release row to select the release that contains the area you want to test. The release Release Area List panel is displayed.
CMNRMALF FIN6430 Release Area List Row 1 to 3 of 3 Command ===> Scroll ===> CSR Area Status Area Prior Next Name Type Aud BLK CIA COA CIR COR step area area ACCTPAY SUBSYS 00 N N N Y N 0001 FINANCE GENLEDGR SUBSYS N N N N N 0002 FINANCE FINANCE SYSTEM N N N N N 0003 GENLEDGR ******************************* Bottom of data *******************************
The release Release Area List panel shows all areas that are defined in the release that you selected.
The fields on release Release Area List panel are described in Notifying Area Check-in Approvers.
-
-
On the release Release Area List panel, type TA in the line command of the area that you want to test and press Enter. The next panel allows a filter by package name to include or exclude:
CMNRMTPK Release Area Test Packages Command ===> Release: FIN6430 Area : ACCTPAY Package Name . . . . . . (Blank, Full name or mask) Include Only or Exclude I (I-Include Only X-Exclude)
Press Enter to continue, and ERO compares the contents of the release area to the contents of packages attached to the release. If errors are found, the Release Install Components Disallowed panel is displayed.
CMNTST03 Components Disallowed Components Failed Command ===> Scroll ===> CSR Component Type Package Sta User Orig. pkg User Reason ACPSRCEE SRC ACTP000032 D USER015 NOT CHECKED IN ACPSRCEE LOD ACTP000032 D USER015 NOT CHECKED IN ACPSRCEE LST ACTP000032 D USER015 NOT CHECKED IN ACTCOB01 SRC ACTP000032 D USER015 NOT CHECKED IN ACTCPY01 CPY ACTP000032 D USER015 NOT CHECKED IN ACTCPY02 CPY ACTP000032 D USER015 NOT CHECKED IN COB001 SRC ACTP000032 D USER015 NOT CHECKED IN COB001 LOD ACTP000032 D USER015 NOT CHECKED IN COB001 LST ACTP000032 D USER015 NOT CHECKED IN CPY001 CPY ACTP000032 D USER015 NOT CHECKED IN ******************************* Bottom of Data ******************************** ... +------------------------------------------------------------------------------+ | CMR1506I - Release FIN6430 area ACCTPAY and package components do not match. | +------------------------------------------------------------------------------+
This panel displays the results of the area test. Only components that fail the test are displayed together with the reason for the failure. The TSO ID of the developers who staged the component in the tested package and the developer who checked the component in to the tested area is provided to help you resolve the problem.
This table describes the fields on the Release Install Components Disallowed panel.
Field Description Component The name of the component that fails the test area. Type The library type of the failed component. Package The package where the failed component was staged. User The TSO ID of the developer who staged the failed component. Orig. pkg The package from which the failed component was checked in to the release subsystem area and ultimately into the area being tested. User The TSO ID of the developer checked in the failed component into the area being tested. Reason FROM DIFF PKGE The component is in two attached packages, the tested package and the originating package. The component in the originating package is the one that is checked in to the tested area.
DIFF VERSIONS The component is in only one attached package, but the version in the package is different from the version in the tested area.
EMPTY RLS PKGE The tested package contains no components., no utility requests (scratch or rename), and no Online Forms.
NOT CHECKED IN The component is in only one attached package, but it is not checked in to the tested area. -
To resolve test area exceptions manually, take these actions:
-
FROM DIFF PKGE: Verify that you have the correct version checked in to the tested area and that differences between all versions are reconciled in the component in the tested area. Then, retrieve from all areas the version that you do not want installed, and delete that version from its package.
-
DIFF VERSIONS: Check-in the latest version from the tested package.
-
EMPTY RLS PKGE: Detach the package from the release.
-
NOT CHECKED IN: Delete the component from the tested package or check it in to the release and tested area.
If you are running test area in the final release area, you may be able to use automatic cleanup. See Automatic Cleanup.
-
-
When an area is tested and no errors are found, the release Release Area List panel is displayed with the short message “Components Passed”.
CMNRMALF FIN6430 Release Area List Components Passed Command ===> Scroll ===> CSR Area Status Area Prior Next Name Type Aud BLK CIA COA CIR COR step area area ACCTPAY SUBSYS 00 N N N Y N 0001 FINANCE GENLEDGR SUBSYS N N N N N 0002 FINANCE FINANCE SYSTEM N N N N N 0003 GENLEDGR ******************************* Bottom of data *******************************
-
Test area is complete.
Automatic Cleanup
When you run test area in the final area of a release, test area can automatically resolve many of the mismatches between the contents of the final area and the packages attached to the release.
Automatic cleanup is an alternative to manual procedures, which involve retrieving package components from release areas, reverting attached packages, deleting package components not needed in the release, running package audit, freezing the packages, and obtaining package approvals for a second time.
The automated cleanup of the test area function is especially attractive to ERO customers who have large releases that cross organizational boundaries.
Caution
Use automatic cleanup with caution. Query the tested package and browse the component before you let automatic cleanup delete the component. Make sure the component in the tested area is the version you want to install with the release.
Automated cleanup of test area follows these rules.
-
Automatic cleanup of test area exceptions is enabled by your release manager who sets indicators in the release definition that determine what attached packages can be automatically cleaned up:
-
No packages,
-
Packages in DEV status, and/or
-
Packages in FRZ status, and/or
-
Packages in APR status.
-
-
Automatic cleanup can resolve these test area exceptions:
-
NOT CHECKED IN
-
FROM DIFF PKGE
-
EMPTY PACKAGE
-
-
Automatic cleanup cannot resolve this test area exception:
-
DIFF VERSIONS
When a version of a component in a package is different from the version in the tested area, you must manually reconcile the differences. You can check in the package version into the final area, or you can check out from the final area and stage the new version of the component in the package.
-
-
When automatic cleanup is enabled, you can select which test exceptions in your area you want processed automatically.
-
A package component is not deleted if the corresponding area component is promoted.
-
Automatic cleanup cannot delete a component from a tested package if the corresponding component in the tested area was checked in through a different starting area.
-
An empty package is one with no components in staging libraries, no utility requests (scratch or rename), and no Online Forms.
-
All versions of a component in the release packages that are different from the version in the final area are reported by the Test Area function. You select which ones you want to be automatically deleted from their packages.
-
Normal ChangeMan ZMF security requirements apply to automatic cleanup. -
-
You must have update access to the application mnemonic to execute automatic cleanup for packages in the application.
-
You cannot cleanup components locked by another TSO ID.
-
You must have authorized access to components protected by component level security to automatically cleanup the components.
Release managers can execute automatic cleanup to update packages in applications to which they do not have UPDATE authority.
-
If automatic cleanup is not enabled in the release definition for any package status, test area exceptions are displayed on the Release Install Components Disallowed panel, where no automatic cleanup options are offered.
If automatic cleanup is enabled for packages in DEV, FRZ, or APR status, test area exceptions in the final release area are displayed on the Release Package Components Clean-up panel.
CMNTST53 RELEASE PACKAGE Component Clean-up Components Failed
Command ===> Scroll ===> CSR
Component Type Package Sta User Orig. pkg User Reason
_ ACPJCL10 JCL ACTP000038 D USER239 NOT CHECKED IN
_ ACPPRC10 PRC ACTP000038 D USER240 NOT CHECKED IN
_ ACPCTC10 CTC ACTP000039 D USER239 ACTP000039 USER239 DIFF VERSIONS
_ ACPPRC10 PRC ACTP000039 D USER239 NOT CHECKED IN
_ ACTP000055 D EMPTY PACKAGE
******************************* Bottom of Data ********************************
This table describes the fields on the Release Package Components Clean-up panel.
Field | Description |
---|---|
Command | Type a command, or leave Command blank to type a Line Command on a component. CANCEL Cancel panel without update. (Abbreviation: C) LOCATE component   Locate a component. (Abbreviation: L) SETALL Sets all line commands to S to select all listed components. SETOFF Sets all line commands to blank to deselect all selected components. |
Line Command | Type S to select a component for automatic cleanup. |
Component | The name of the component that fails the test area. |
Type | The library type of the failed component. |
Package | The package where the failed component was staged. |
Sta | The status (D, F, or A) of the package where the failed component resides. |
User | The TSO ID of the developer who staged the failed component. |
Orig. pkg | The package from which the failed component was checked in to the release subsystem area and ultimately into the final area being tested. |
User | The TSO ID of the developer checked in the failed component into the final area being tested. |
Reason | FROM DIFF PKGE The component is in two attached packages, the tested package and the originating package. The component in the originating package is the one that is checked in to the tested area. DIFF VERSIONS The component is in only one attached package, but the version in the package is different from the version in the tested area. EMPTY RLS PKGE The tested package contains no components., no utility requests (scratch or rename), and no Online Forms. NOT CHECKED IN The component is in only one attached package, but it is not checked in to the tested area. |
Select components for automatic cleanup by typing S in the line command for a component, or type SETALL in the Command field and press Enter to select all eligible components for cleanup. Press Enter to process your selections.
If the component you select for automatic cleanup is in a package with a status for which automatic cleanup is not enabled, short ISPF message Invalid Status is displayed. If the component you select for automatic cleanup is in a package with a status for which automatic cleanup is enabled, these are the actions that are taken online.
-
FROM DIFF PKGE: Delete the component from the package that was not the originating package for the version in the final area.
-
NOT CHECKED IN: Delete the component from the tested package.
-
EMPTY RLS PKGE: Detach the package from the release.
When you execute test area again, the exceptions are resolved.
CMNTST53 RELEASE PACKAGE Component Clean-up Row 000001 Of 000001
Command ===> Scroll ===> CSR
Component Type Package Sta User Orig. pkg User Reason
_ ACPCTC10 CTC ACTP000039 D USER239 ACTP000039 USER239 DIFF VERSIONS
******************************* Bottom of Data ********************************