Skip to content

The Role of the Developer

As a developer, you work at a component level to ensure the correct changes are made to components belonging to the correct release. Typical functions include:

Attaching Packages to a Release

You attach a change package to a release to bring components you are changing into the ERO release life cycle. The components in your package remain under package control, and you execute standard change package life-cycle functions to prepare these components for installation into production.

The following screen shows Package Create parameters. Set ATTACH PACKAGE TO RELEASE to YES at package creation or package update to attach a package to an ERO release. There is no ERO function to attach a package.

CMNCRT0R                    Create: Create a New Package
Option ===> ______________________________________________

        L Long method                   S Short method
        D No package description        I No installation instructions

Package title
Demo package ___________________________________________
Application . . . . . . . .  DEMO     (Blank or pattern for list)
Requester's name . . . . . . John Doe________________
Requester's phone . . . . .  (555) 555-5555________
Work request . . . . . . . . 100001000106________
Department . . . . . . . . . IDD___
Package level . . . . . . .  1_          (1. Simple 2. Complex 
                                          3. Super 4. Participating)
Package type . . . . . . . . PLANNED__   (Planned or Unplanned)
Package time span . . . . .  PERM__      (Permanent or Temporary)
Package to copy forward . .  _________   (Optional package name)
Unplanned reason code . . .  ___         (* for list)
Temporary change duration .  ___         (In days)
Notify user . . . . . . . .  JDOE__

Enter "/" to select option
 __ Attach package to release

Checking Out Components

After you attach a package to a release, you can check out components into your package from releases that have not been installed yet. Checkout from release lets you start coding from a version of a component that is more recent than the version in baseline, and which already contains earlier changes from your project or another project.

If you check out a version of a component from a prior release, you may be able to avoid a regression out-of-sync audit error in your release after the prior release is installed. If you check out a component from an area in the current release, you will eventually encounter an overlay condition in package or area check-in unless the other version is retrieved.

Checking In Packages

When you check in a package, you bring components from that package attached to a release into the starting subsystem area defined for that package. This step begins the integration of your package components with other release components in development in other change packages.

Package check-in initiates these activities:

  • Allocates area libraries for all areas in the release for the library types that are contained in the package

  • Populates starting release area libraries

  • Makes the components available to build processes in other packages in the same application that are attached to the release

  • Makes the components available to build processes in packages in other applications that have this application defined as a related application

  • Starts the process of resolving multiple versions of the same component, as only one version of the component can reside in the same area

With appropriate area rules in place, you audit, freeze, and approve packages before they are checked into a release’s starting area.

Checking In an Area

Area check-in allows you to copy components from the libraries for one area into the libraries for another area. Check-in advances release components through the hierarchy of areas that progressively integrate release components.

Area check-in initiates the following:

  • Populates the area application libraries for the next area defined for the release

  • Makes the components available to build processes in other packages in the same application that are attached to the release

  • Makes the components available to build processes in other packages in the same application that define this release as a prior release

  • Makes the components available to build processes in packages in other applications if this application is defined as a related application

  • Continues the process of squeezing out multiple versions of the same component, as only one version of the component can reside in the same area

Generating an Area

Generating an area allows you to initiate build processing for every source and load component in the area libraries.

Auditing an Area

Release audit examines the components in libraries for a particular release area, as well as libraries for other areas in the release, libraries in prior releases that will be installed sooner, and baseline libraries. It evaluates relationships between different versions of the same component, and it evaluates relationships between components and other components they include like copybooks and statically linked load modules.

More information