Other ERO Functions

Detach Package From Release

When you detach a package from an ERO release, you sever all relationships to the release, its areas, and area libraries. You break relationships to components in area libraries for that release, and you break relationships to components in area libraries for releases that define that release as a prior release.

Note

You cannot detach a package from a release if there are components from your package in area libraries for the release. Retrieve package components from all areas before you detach the package.

Check Out Package Components from Release

Checkout from release area libraries gives you the same advantage as checkout from promotion libraries in the base ChangeMan ZMF product.

If you check out a version of the component that is scheduled for install before your version, you may be able to avoid an out-of-sync condition after the other version is installed. If you start your development where a previous development effort ended, you can avoid merging code into your new version.

Checkout from release offers these choices:

Checkout from the starting area for your package in the current release.
Checkout from any area in the current release.
Checkout from any area in a prior release.
Check out the latest version of the component in the current and prior releases.

Retrieve a Package

The retrieve package function removes all package components from the libraries for an area.

You must remove package components from area libraries to:

Detach a package from a release.
Check-in new versions of all package components from a different package.

Note

You cannot edit components in an area library. Even after your package is attached to a release and components are checked in, you change those components in the package staging libraries using ChangeMan ZMF base functions. You change a component in an area library by checking in a new version to the area. Unless you were the last person to check in a component from the same package, you must retrieve the component from the area before checking in a new version.

Package retrieve is subject to these rules and conditions.

The retrieve rule for the area determines whether you can retrieve components from the area if the area is blocked. The retrieve rule can also restrict who can perform retrieve from the area.
Package retrieve removes all package components from the area. If you want to remove selected package components from the area, use the area retrieve function.
Package retrieve only removes those components that originated in your package. Components in area libraries that originated in other change packages are not removed, even if you have components with the same name in your package.
If you attempt to use package retrieve after the area retrieve function was used to remove all of your package components from an area, an error message is issued. However, the package checked in indicator is reset, and no problems will result.

Retrieve from an Area

The retrieve area function removes components from area libraries.

You must retrieve components from area libraries to:

Detach a package from a release.
Check-in a new version of the component from a different package.
Check-in a component by a person different from the person who last checked in the component.

Note

You cannot edit components in an area library. After your package is attached to a release and components are checked in, you change those components in package staging libraries using ChangeMan ZMF base functions. You can only change a component in an area library by checking in a new version to the area. Unless you were the last person to check in a component from the same package, you must retrieve the component from the area before checking in a new version.

Area retrieve is subject to these rules and conditions.

The retrieve rule for an area determines whether you can retrieve from the area if it is blocked. The retrieve rule can also restrict who can perform retrieve from the area.
You can retrieve all components in an area or you can retrieve selected components. If you want to remove all components that originated in a particular package, use the package retrieve function.
A single area retrieve operation removes components from a set of release area application libraries. If there are several applications joined to a release, you perform multiple retrieve operations to remove all components from the area.

Test an Area

The ERO test area function compares the contents of an area to the contents of packages attached to the release to find mismatches. Error conditions are displayed online.

The contents of release areas can conflict with the contents of packages attached to a release as you consolidate subsystem areas into system areas, and as you change package components to fix errors found in testing. When you block a release, a test is executed to detect mismatches between the final release area and release packages. You can find these errors earlier in the release life cycle with the test area function.

These are some of the conditions that are detected by the test area function.

A component in the tested area is a different version than the component in the package from which it was checked in.
An attached package contains a component that was checked in to the tested area from a different package.
An attached package has no components.
A component was checked in from an attached package but not checked in to the tested area.

Unblock an Area

Unblocking an area unlocks the area for further changes to area components. When an area is blocked, you cannot check-in components to the area.

Unblocking an area also clears any check-off approvals entered up to that point.

The area blocking rule can restrict who can unblock the area.

Test a Release

The ERO test release function compares the contents of the final system area to the contents of packages attached to the release to find mismatches. Error conditions are displayed online.

The contents of the final area can conflict with the contents of packages attached to a release as you consolidate subsystem areas into system areas, and as you change package components to fix errors found in testing. When you block a release, a test is executed to detect mismatches between the final release area and release packages. You can find these errors earlier in the release life cycle with the test release function.

These are some of the conditions that are detected by the test area function.

A component in the final area is a different version than the component in the package from which it was checked in.
An attached package contains a component that was checked in to the final area from a different package.
An attached package has no components.
A component was checked in from an attached package but not checked in to the final release area.

Unblock a Release

Unblocking a release unlocks the release for further changes. Unblocking a release does not unblock the areas in the release. You must unblock release areas to change release components.