ZMF ERO Concepts

8/3/2019 ZMF ERO Concepts

1/40

SERENA CHANGEMAN ZMF 5.5

ERO CONCEPTS


2/40

Copyright 2005 Serena Software, Inc. All rights reserved.

This document, as well as the software described in it, is furnished under license and may

be used or copied only in accordance with the terms of such license. Except as permitted

by such license, no part of this publication may be reproduced, photocopied, stored in a

retrieval system, or transmitted, in any form or by any means, electronic, mechanical,

recording, or otherwise, without the prior written permission of Serena. Any reproduction

of such software product user documentation, regardless of whether the documentation

is reproduced in whole or in part, must be accompanied by this copyright statement in itsentirety, without modification.

The content of this document is furnished for informational use only, is subject to change

without notice, and should not be construed as a commitment by Serena. Serena

assumes no responsibility or liability for any errors or inaccuracies that may appear in this

document.

Trademarks

Serena and ChangeMan are registered trademarks of Serena Software, Inc. The Serena

logo is a trademark of Serena Software, Inc.

All other products or company names are used for identification purposes only, and may

be trademarks of their respective owners.

U.S. Government Rights

Any Software product acquired by Licensee under this Agreement for or on behalf of the

U.S. Government, its agencies and instrumentalities is "commercial software" as definedby the FAR. Use, duplication, and disclosure by the U.S. Government is subject to the

restrictions set forth in the license under which the Software was acquired. The

manufacturer is Serena Software, Inc., 2755 Campus Drive, San Mateo, CA 94403.

Publication date: June 2005


3/40

ERO Concepts 3

Table of Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Manual Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Accessing the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Using the Online Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Using HTML Online Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 1 Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Chapter 2 Enterprise Release Option (ERO) Concepts . . . . . . . . . . . . 13

Key Terms and Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Release Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Release Migration Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Release Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Release Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Advantages of ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

The ERO Release Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Additional ERO Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Chapter 3 Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . 29

The Role of Global Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

The Role of Release Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

The Role of Application Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

The Role of Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39


4/40

4 Serena ChangeMan ZMF 5.5

Table of Contents


5/40

ERO Concepts 5

Preface

This document discusses concepts regarding the Enterprise Release Option (ERO) forSerena ChangeMan ZMF.

Objective

Use this document to:

Review release management concepts

Understand ERO concepts and terms

Trace a release lifecycle in ERO

Become familiar with ERO administrators roles and responsibilities

Audience

Use this document if you are responsible for any of these tasks:

Managing software releases at your enterprise

Managing test environments

Developing and changing software components managed by ChangeMan ZMF

This guide assumes that you are familiar with ChangeMan ZMF and your security system.

Manual Organization

This manual is organized as follows:

This chapter... Contains this information

"Preface" Information about this guide

"Release Management" Overview of release management concepts

"Enterprise Release Option(ERO) Concepts"

Overview of ERO concepts

"Roles and Responsibilities" Roles and responsibilities of Administrators andDevelopers


6/40


Related Publications

Accessing the Documentation

All ChangeMan ZMF documentation is included on the software distribution CD in bothAdobe Portable Document Format (PDF) and HTML format.

Even if you request the ChangeMan ZMF software on tape, you will receive the CD.

To access the documentation on the CD, open the Documentation folder in the rootdirectory to see two subfolders:

PDF Version, which contains a PDF file for each ChangeMan ZMF manual. To viewthe PDF version of a manual, double click on the PDF file to launch the Adobe

Reader.

HTML Version, which contains the HTML help files. The HTML help has the samecontent as the books in PDF format. To view the HTML help, double-click index.htmto launch your Web browser.

The PDF files and HTML help are non-compressed files. You may copy them to yourworkstation. The PDF files are suitable for printing.

ChangeMan ZMF documentation is also available through the Download Center on theSerena Online Services self-service Web site at support.serena.com.

Using the Online ManualsThe Serena online manuals use the Adobe Portable Document Format (PDF).

This section highlights some of the main Adobe Reader features. For more detailedinformation, see the Adobe Reader online help system.

The online manuals include the following features:

Bookmarks. All of the online manuals contain predefined bookmarks that make iteasy for you to quickly jump to a specific topic. By default, the bookmarks appear tothe left of each online manual.

Title Description

Serena ChangeMan ZMF

Administrators Guide

Description of ChangeMan ZMF features and

functions, with instructions for choosing options anddefining ChangeMan ZMF Administration

Serena ChangeMan ZMFUsers Guide

Description of ChangeMan ZMF features andfunctions used to manage components and packagesthrough the SCM life cycle

Serena ChangeMan ZMFERO Getting Started Guide

Description of the ChangeMan ZMF EnterpriseRelease Option, with instructions for installing ERO,configuring ERO Global Administration, and creatingand managing ERO releases.
http://support.serena.com/http://support.serena.com/


7/40

ERO Concepts 7

Links. Cross-reference links within an online manual enable you to jump to othersections within the manual and to other manuals with a single mouse click. Theselinks appear in blue.

Printing. While viewing a manual, you can print the current page, a range of pages,or the entire manual.

Advanced search. Starting with version 6, Adobe Reader includes an advanced

search feature that enables you to search across multiple PDF files in a specifieddirectory. (This is in addition to using any search index created by Adobe Catalogsee step 3 below.)

To search within multiple PDF documents at once, perform the following steps(requires Adobe Reader version 6 or higher):

1 In Adobe Reader, select Edit | Search (or press CTRL+F).

2 In the text box, enter the word or phrase for which you want to search.

3 Select the All PDF Documents in option, and browse to select the folder in whichyou want to search. (If you have a document open that has an Adobe Catalog indexattached, you can leave the In the index named... option selected to search across

all the manuals in the index.)

4 Optionally, select one or more of the additional search options, such as Whole wordsonly and Case-Sensitive.

5 Click the Search button.

Using HTML Online Libraries

The HTML help has the same content as the PDF manuals. To view the HTML help, double-click index.htm to launch your web browser.

The HTML format is intended for quick access to information across the entire documentset. It includes cross-book searching facilities and a comprehensive index.

NOTEOptionally, you can click the Use Advanced Search Options link near thelower right corner of the application window to enable additional, morepowerful search options. (If this link says Use Basic Search Optionsinstead, the advanced options are already enabled.) For details, see Adobe

Reader's online help.


8/40



9/40

Goals

ERO Concepts 9

Chapter 1

Release Management

This chapter presents an overview of release management concepts.

Goals

The goal of release management is to provide you a way to organize and manage therelease of your software applications; you establish a repeatable process to moveapplications to production so they are available to users. These applications can rangefrom simple applications to large complex systems containing dependencies betweencomponents within applications.

Requirements

For effective release management, you must:

Identify applications and their associated release dates, noting applications releasingconcurrently.

Understand the key relationships between application components. This becomesmore difficult as the number of components increases.

Accurately manage the dependencies among the applications and various releases ofthe applications.

Ensure the proper components are available for any given release of an application.

Provide environments for thorough testing by appropriate personnel.

Ensure no collisions occur among applications during the testing and releaseschedules and during deployment, especially with applications releasing concurrently.

Integrate and manage application changes into a larger system. For example,Accounts Payable and Accounts Receivable applications need to be migrated into theFinance system.

Schedule release dates, identify resource constraints, and obtain managementapproval for upcoming releases.


10/40


Chapter 1 Release Management

Considerations

Release management affects personnel across your organization:

Managers want to minimize the risk involved with placing new releases intoproduction while maintaining timely release schedules. They need to considersoftware quality, time, and cost when determining what applications will be released,

and when. For example, if software quality becomes critical, then release schedulesand costs need to be adjusted.

Developers need to accurately document complex and changing dependencies amongtheir applications and their various releases. They need to evaluate theserelationships to determine the impact of any changes to components.

Users are involved in the installation and appropriate configuration of the applicationto their particular environment. They want applications that are easy to install, test,and deploy quickly. Quality, usability, and robust features are important when theapplication is available to end users.

Objectives

To mitigate risk and ensure properly tested applications are placed into production, theobjectives of effective release management are to:

Test applications together in a consolidated environment

Manage the dependencies among the applications and releases

Support multiple changes to the same component in various releases of an application

Resolve obstacles prior to production

Strategies

Release management can be implemented in a physical manner. You establish separatesets of libraries at the application level for the development and testing of components.These libraries of changed application components are then funneled, or consolidated,until only a single set of libraries exist with all changed components. The final deploymentto production takes place from this single set of libraries.

Consider each objective listed above:

Test applications together in a consolidated environment

Developers change components in development libraries belonging to individualdevelopers or teams. The components are then moved to and tested in libraries belongingto their applications. With multiple changes to multiple applications occurringsimultaneously, there is a good chance that the same components are changed in multipleplaces.

Concurrent development of these components is detected when you consolidate librariesas applications are tested along their designated release migration path. The different


11/40

Strategies

ERO Concepts 11

versions of the same component have to be resolved to prevent overlays of the changesor loss of new function as these components move up the migration path.

For example, in the following diagram, Accounts Payable and Accounts Receivableapplications are consolidated and migrated into a set of Finance libraries. When youconsolidate libraries at the Finance level, you have to resolve different versions of thesame component. From Finance, you migrate components to Integration, then to Final.You deploy to production from these Final libraries.

Figure 1-1. Release management includes consolidating libraries.

Manage the dependencies among the applications and releases

Developers need to document the dependencies among applications, and evaluate therelationships between application components and other components they include. Withmultiple releases, there may be different versions of the same component with differentdependencies. It can be a tedious process to document these relationships.

You can use utilities to help automate the documentation of component relationships.These utilities examine the relationships between source programs and copybooks andthe relationships of load modules to the composite load modules that call them.

With a physical implementation, you can use these utilities to examine the components inlibraries for a particular application, as well as libraries up and down the establishedmigration path to determine relationships. You can also look across releases to evaluatethe relationships between releases or in the contents of a release.

Resulting component relationship information can be stored in a repository. You can usethis information for analysis purposes, and to detect and report issues in relatedapplications and releases.

Production

Release Q1

Acct

Payable

Acct

Receivable

Finance Integration Final

Release Q2

Acct

Payable

Acct

Receivable

Finance Integration Final


12/40


Chapter 1 Release Management

Support multiple changes to the same component in various releases ofan application

Components may be changed in each release, and these releases may be in motionsimultaneously. Fixes for component defects in one release may need to be applied to allcorresponding components in other releases.

With a physical implementation of release management, parallel development takes place

in the application libraries for each release. These changes are isolated from any otherapplications or releases changes.

Concurrent development of these components is detected when you consolidate librariesas applications are tested along their designated release migration path. The differentversions of the same component have to be resolved to prevent overlays of the changesor loss of new function as these components move up the migration path.

Resolve obstacles prior to production

As you are testing applications together in a consolidated environment, you mayencounter application discrepancies.Components may produce unpredictable results. Youmay encounter operational issues with hardware and operating system incompatibilities.

You need to remove these obstacles before components can be properly tested,approved, and moved forward in the migration path.

You can identify checkpoints along the way as consolidation occurs. When obstacles areencountered, you can block forward movement with applicable rules in place. You canestablish rules to allow only successfully tested components to be moved forward. Youcan also require appropriate approvals from development, management and users toensure that correct changes are implemented at the appropriate times.


13/40

ERO Concepts 13

Chapter 2

Enterprise Release Option (ERO)Concepts

With the ChangeMan ZMF Enterprise Release Option (ERO), an extension to ChangeManZMF, you manage changes as a release. A release represents a collection of ChangeManZMF simple change packages from any number of applications that must be installed atthe same time.

Releases allow you to manage high volumes of changes, as hundreds of simple changepackages can be attached to any given release. ERO maintains relationships betweencomponents and the packages that comprise a release. ERO manages multiple releases inmotion simultaneously.

ERO extends the capability of ChangeMan ZMF in the following ways:

Support for release management, with checkpoints along the way

With EROs flexible architecture, you define releases with lifecycles that correspond toyour release migration paths. The ERO release lifecycle is controlled by a set of rules tohelp manage and protect your production environment. ERO offers:

notifications at every major point in a release lifecycle

built-in approval processes

query capabilities

library concatentation definitions for build processes

Consolidation of migration paths to an integrated environment

ERO provides specific development paths for releases that progressively consolidatepackage components into a single set of libraries. Concurrent development of thesepackage components is detected when you consolidate libraries. The different versions ofthe same component have to be resolved to prevent overlays of the changes or loss ofnew function as these components move up the migration path.

Release audit capabilities, with automatic resolution of out-of-syncconditions

Similar to package audit in the base ChangeMan ZMF product, release audit evaluates

relationships between different versions of the same component. It also evaluatesrelationships between components and other components they include, like copybooksand statically linked load modules. However, release audit is more comprehensive thanpackage audit. Release audit examines:

components in libraries for a particular release

components in libraries in prior releases that will be installed sooner

components in baseline libraries


14/40


Chapter 2 Enterprise Release Option (ERO) Concepts

Automatic determination of copybook and load module concatenationsfor build processes

ERO gives you the flexibility to define copybook and load module concatenations for use inthe build processes. These concatenations are pointed to by SYSLIB JCL statements. EROmanages these SYSLIB concatenations, even as library concatenations and contents inbuild jobs change when the schedule relationship between releases is changed. ERO alsomanages the SYSLIB concatentations when applications and packages are added orremoved from a release.

Key Terms and Concepts

ERO introduces new terms and concepts to ChangeMan ZMF.

Release

A release represents a collection of ChangeMan ZMF simple change packages from anynumber of applications that must be installed at the same time. In ERO, a release is alogical set of rules for relating the physical elements of a release. These elements are:

the baseline libraries of the applications

the release libraries

the staging libraries of the change packages

Releases are managed by a Release Manager, who has exclusive authority over therelease creation and lifecycle. Release managers can get real time information aboutcomponents within releases online.

When you create releases, you define release install date and time ranges. All packagesyou add to a particular release must have install specifications within the release installrange.

Figure 2-1. Releases are created with installation date and time ranges.

When you create a release, you define prior and next releases. This information can beupdated as additional releases are added.

Release Q1Install from:

March 29, 2005 at 5:00 am

Install to:

March 31, 2005 at 11:00 pmRelease Q2Install from:

June 28, 2005 at 5:00 am

Install to:

June 30, 2005 at 11:00 pmRelease Q3Install from:

Sept 28, 2005 at 5:00 am

Install to:

Sept 30, 2005 at 11:00 pm


15/40


ERO Concepts 15

Figure 2-2. You define prior and next releases when you create a release.

Release Area

A release area is a set of component libraries that represents a migration step in therelease lifecycle. Each area has its own set of dynamically allocated associated libraries,based on application and library type. The default format of the release area libraries is:

HLQ.ReleaseID.AreaID.ApplID.Libtype

The consolidation of components takes place in these release area libraries, which areused in SYSLIB concatenations for build processes in release packages. They are alsoused by release audit to validate release component relationships.

A minimum of two release areas are required. The start area,defined as a subsystemarea,is used to check packages into a release.The final area,defined as a system area, is

used to move the release into production, and must contain the entire release. Typically,you define one or more subsystem areas and one system area per release.

Area definitions include fields for prior and next areas, and approvals may be required formigration from one area to another. If you specify check-in approvals, they must begranted before components can be checked in to an area. If you specify check-offapprovals, they are required before components can be migrated into the next area.

As components are migrated from one area to another, prior area libraries remain fullyintact. This differs from base Changeman ZMF package promote, where packagecomponents are removed from libraries in the prior level.

Release Q1

Prior = NoneRelease Q2

Prior = Release Q1Release Q3

Prior = Release Q2

and Release Q1


16/40



Figure 2-3. Releases require a minimum of two areas.

Release Migration Path

The release migration path is defined when you link prior and next areas.

Release area definitions include fields for prior and next areas. Start areas (subsystemareas), which serve as the entry point for packages, have only next areas, while finalareas (system areas) serve as the production migration point and have only a prior areadefinition. Additional areas (subsystem areas) can have both prior and next areas defined.You define as many areas as you need to establish your release migration path.

In the following diagram, Start Area has no prior area, but has one next area (Area2).Area2 is defined with a prior area (Start Area) and a next area (Area3). Likewise, Area3 isdefined with a prior area (Area2) and a next area (Final Area). Final Area is defined withone prior area (Area3), and has no next area.

Figure 2-4. Release migration paths are defined when you link areas.

You can define multiple migration paths within a release. Multiple starting areas migrateto other areas, gradually combining until they come together in a single given area.Installation occurs from the final area into production and updates the baseline libraries ofthe participating applications. The baseline update process "ripples" current and priorversions of package components down in the stack of prior baseline versions. Thepackage components are then copied into the baseline libraries as the new currentversion.

Release Q1

Start Area(Subsystem)

Final Area(System)

Start Area

(Subsystem)

Release Q1

Final Area

(System)

Area2

(Subsystem)Area3

(Subsystem) . . . .


17/40


ERO Concepts 17

In the following diagram, Team1 and Team2s changes are migrated and consolidated tothe Group1 area, and Team3 and Team4s to the Group2 area. Both Groups are migratedand consolidated to the Integration area before migration to the Final Area. The FixesArea is used as a quick path to Integration, then to the Final Area.

Figure 2-5. Multiple migration paths can be defined in a release.

You set up migration paths within releases when you establish areas. As shown in thediagram above, you can set up migration paths for enhancement requests, which follow alonger and more robust migration path, as well as fixes, which require quick access toproduction.

Release Application

An application becomes a release application when it participates, or joins, in a release.

ERO allows you to relate applications by joining them to a release. Applications are joinedto a release by an applications administrator, who also chooses what library types fromeach application are included in the release. By restricting library types in a release,administrators can build special purpose releases. For example, an online release wouldcontain only the library types associated with CICS components. A batch release wouldcontain library types associated with JCL and batch processing.

Start Area Team1

(Subsystem)

Release Q1

Start Area Team4

(System)

Start Area Team2

(Subsystem)

Fixes(Subsystem)

Start Area Team3

(Subsystem)

Group1

(Subsystem)

Group2

(Subsystem)

Integration(Subsystem)

Final Area(System)


18/40



.

Figure 2-6. Applications are joined to a release.

By joining applications to a release, the application administrator can define:

the applications to participate in the release

the library types to include

the SYSLIB order concatenation

Release Package

You create a release package when you attach a simple change package to a particularrelease that has a starting area defined. The install date for a release package must fallwithin the range of the install dates defined for the release. When you attach a package to

a release, ERO takes control of building the SYSLIB concatenations for build jobs.

If components in area libraries must be changed, you make the changes in packagestaging libraries using the familiar ChangeMan ZMF procedures. Package check-in, asubsequent step, will then bring the changed components from a package into thestarting area.

Figure 2-7. Simple change packages are attached to a release.

ACTPCOMM GENL

Start Area

(Subsystem)

Release Q1

Final Area

(System)

Area2

(Subsystem)

Area3

(Subsystem) . . . .

ChangeMan ZMF

Applications

ACTPCOMM GENL

Start Area

(Subsystem)

Release Q1

Final Area

(System)

Area2

(Subsystem)Area3

(Subsystem) . . . .

ChangeMan

ZMF

Applications

Simple

Change

Packages

COMM000001

COMM000002

ACTP000100

GENL000057


19/40

Advantages of ERO

ERO Concepts 19

Advantages of ERO

ERO provides comprehensive management for release management:

The software delivery release cycle is predictable.

You can more accurately allocate personnel, such as Testing or Quality Assurance

staff, with the establishment of regularly scheduled maintenance and enhancementreleases.

Users of the delivered software can more effectively plan for installing andimplementing enhancement releases.

The development process is enhanced.

Developers can identify in what release a particular change of a component will beimplemented. They can then determine how that change will affect any other releasesin motion.

When release schedules shift and features get dropped from a release or added, therelease manager can make sure development teams are working with the right

components.

Many manual processes can be replaced.

ERO manages all components across all applications that will be participating within arelease. Release managers can get information about these components in real time.They no longer have the labor-intensive tasks of tracking down and communicatinginformation between teams, or customizing the base product.

In addition, you can create custom reports about release component informationusing the delivered Serena XML Services.

Automatic notification of major release events, like check-in, check-off, install andrelease approvals, are part of ERO. Customized exits and code are no longer

necessary.

There is enhanced functionality over participating packages.

Install date improvements

There is no date verification when you relate participating packages to complexpackages. Packages with disparate install dates can end up under the same complexpackage.

With ERO, all packages you attach to a release must have install dates within therelease install range. You are ensured the package install dates are valid for thatrelease.

SYSLIB improvements

Once you attach participating packages to a complex package, components indevelopment are included in the SYSLIB concatenations for copybooks and loadmodules. Errors in compilations and links can be the result, as the components beingdeveloped may not be ready for use by other components.

With ERO, components are not included in SYSLIB concatenations until they arechecked into the release areas.


20/40



Blocking areas

With participating packages, release managers need to freeze all the packages toprevent their content from changing. This can become complicated as the packagesmay not be under the control of the release manager.

With ERO, release managers can block entire release areas. When an area is blocked,the contents of the release area is prevented from changing, regardless of the status

of any of the release packages.

The ERO Release Lifecycle

The ERO release lifecycle overlaps the package lifecycle used in the base ChangeMan ZMFproduct. It consists of a number of steps where changed components move through therelease areas for synchronizing and testing the changes. The last step installs from thefinal area into production and ripples the baseline libraries of the participatingapplications.

The following steps trace a release lifecycle in ERO:

1. Create a Release and Areas

You make ERO administration entries to create a release and its associated areas. Thesefunctions are typically performed by ERO release managers and ChangeMan ZMFadministrators.

2. Add Install Approval Groups and Area Approvers

You add install approval groups after you create the release. Additional approvals may bedynamically added based on library types included in the release. You can also establish

area approvers.

In the following diagram, the approval group DBA is dynamically added as Release Q1contains DBRM components which reside in a DBR library type. This release will nowrequire DBA approval, along with MGRS and OPER approval.

Figure 2-8. Approval groups can be dynamically added for installation.

Release Q1

Release Q2

Release Q3

Production

Approval

DBA

Approval

OPER

Production install

approval groups

Library type DBR

approval group

Approval

MGRS


21/40


ERO Concepts 21

3. Attach Change Packages to Release

When you attach a change package to a release, it brings new or changed componentsinto the ERO release lifecycle. After you attach a package to a release, the components inthe package remain under package control but proceed through the release lifecycle. Priorreleases final system libraries and all current release area libraries are included in theSYSLIB concatenation of compliles and links within the package.

4. Approve Area Check-in

The approval process begins with notification to the area check-in approvers. Check-inapproval can be used to verify that release areas and applications are reviewed by theappropriate personnel. Check-in approval opens a release area for package or area check-in.

5. Check in a Package

When you check in a package attached to a release, components are brought into thestarting area defined for that package. This step begins the integration of the packagecomponents with other release components, which are in development in other changepackages of that release.

With the appropriate rules in place, you audit, freeze, and approve packages before theyare checked into a release.

Figure 2-9. Package check-in brings components into the releases startingarea.

6. Check-in an Area

You copy components from the libraries for one area into the libraries for another areawith area check-in. Release components are advanced through the hierarchy of areas and

progressively integrated.

You issue the check-in command on the current area, which copies the components fromthe current area to the next area. In the following diagram, the check-in command isissued on Start Area to migrate components to Unit Test Area.

Start Area

(Subsystem)

Release Q1

Final Area

(System)

Area2

(Subsystem)

Area3

(Subsystem) . . .Ch

eck-in

Promote

TEST1

Promote

TEST2

GENL000057


22/40



Figure 2-10. Area check-in copies area libraries into libraries of another area.

7. Audit an Area

Release audit checks for out-of-sync conditions across releases. For example, if youmodify a copybook after you have compiled the source that calls it, release audit will notethat condition.

Release audit examines components in:

libraries for a particular release area

libraries for other areas in the release

libraries in prior releases

baseline libraries

It evaluates relationships between:

different versions of the same component

components and other components they include, such as copybooks and staticallylinked load modules

link control cards and the associated load modules

The Audit job records audit data and out-of-sync conditions in release audit tables.Reports can be run against these tables, or queried using XML Services. The Release Auditreport produced by the sample program CMNRARPT includes these sections:

Directory information for non-load components

Directory information for load components

Copybook within Source

NCAL Loads with composite loads

Object components within composite loads

Summary

Recommendations

Start Area

(Subsystem)

Release Q1

Final Area

(System)

Area2

(Subsystem)Area3

(Subsystem) . . . .GENL000057

Unit Test

AreaSystem

Test Area

Check-In


23/40


ERO Concepts 23

A sample report produced by CMNRARPT follows.

Change Man Release Audit Report Tuesday November 30,2004 (2004/335) 01:52:26 PAGE: 1

***********************************(Release Area Processing)************************************

*Release Identifier ===> SDDUPLIC Created: 20041125 Release Install Date ===> 20041125 *

*Area Identifier ===> UNIT Area Status ===> UNBLOCKED *

*Component analysis type ===> Description of Member from Directory Entry for Lib Type-(CPY) *

************************************************************************************************************************************

*------------- V e r s i o n L i b r a r y -------------* *------------------ A r e a L i b r a r y -----------------*

************************************************************ **************************************************************

Name Build Area Changed Release Tso-id Name Build Appl/Pkge# Changed Size VV.MM Tso-ID________ ____ ________ ________________ ________ ________ ________ ____ __________ ________________ ____ _____ ________

ASMCPY 03.11.2000 14.17 WSER03 ERR0100! ASMCPY STEV000040 25.11.2004 06.10 6 04.03 WSER58





*Component analysis type ===> Description of Member from Directory Entry for Lib Type-(JCL) *

************************************************************************************************************************************


************************************************************ **************************************************************

Name Build Area Changed Release Tso-id Name Build Appl/Pkge# Changed Size VV.MM Tso-ID

________ ____ ________ ________________ ________ ________ ________ ____ __________ ________________ ____ _____ ________

CKOJORLS SYSTEM 11.11.2004 09.08 SDV1R1M0 WSER58 ERR0417! CKOJORLS STEV000040 25.11.2004 07.47 1 02.04 WSER58

P10032#2 29.11.2004 04.50 WSER58 ERR0100! P10032#2 STEV000040 30.11.2004 00.40 58 03.01 WSER58

P10032#3 UNIT 10.11.2004 03.33 SDV1R1M0 WSER58 ERR0417! P10032#3 STEV000040 30.11.2004 00.40 58 03.01 WSER58

TESTAA1 29.11.2004 04.50 WSER58 ERR0100! TESTAA1 STEV000040 25.11.2004 06.31 5 04.01 WSER58





*Component analysis type ===> Description of Member from Directory Entry for Lib Type-(LST) *

************************************************************************************************************************************


************************************************************ **************************************************************


________ ____ ________ ________________ ________ ________ ________ ____ __________ ________________ ____ _____ ________

CKOSORLS SYSTEM 11.11.2004 09.10 SDV1R1M0 SERD CKOSORLS STEV000040 30.11.2004 00.40 458 01.00 SERD

EROPGM07 29.11.2004 05.08 SERD EROPGM07 STEV000040 30.11.2004 00.41 469 01.00 SERD

EROPGM10 29.11.2004 05.07 SERD EROPGM10 STEV000040 30.11.2004 00.41 469 01.00 SERD





*Component analysis type ===> Description of Member from Directory Entry for Lib Type-(SRC) *

************************************************************************************************************************************


************************************************************ **************************************************************


________ ____ ________ ________________ ________ ________ ________ ____ __________ ________________ ____ _____ ________

CKOSORLS SYSTEM 11.11.2004 09.09 SDV1R1M0 WSER58 ERR0100! CKOSORLS STEV000040 30.11.2004 00.39 5 02.03 WSER58

EROPGM07 29.11.2004 05.03 WSER58 ERR0100! EROPGM07 STEV000040 30.11.2004 00.40 6 03.01 WSER58

EROPGM10 29.11.2004 05.03 WSER58 ERR0100! EROPGM10 STEV000040 30.11.2004 00.40 6 03.01 WSER58





*Component analysis type ===> Description of Member from Directory Entry for Lib Type-(LOD) *

************************************************************************************************************************************

*------------- V e r s i o n L i b r a r y --------------* *----------------- A r e a L i b r a r y -----------------*

************************************************************* *************************************************************

Name Size Linkdate Setssi Build Area Release Name Appl/Pkg# Build Size Linkdate Setssi AC

________ ________ __________ ________ ____ ________ ________ ________ __________ ____ ________ __________ ________ __

CKOSORLS 00000000 11.11.2004 546323C3 SYSTEM SDV1R1M0 CKOSORLS STEV000040 00000000 30.11.2004 547BB8D8 00

EROPGM07 00000000 29.11.2004 547AA54D EROPGM07 STEV000040 00000000 30.11.2004 547BB8EB 00

EROPGM10 00000000 29.11.2004 547AA54E EROPGM10 STEV000040 00000000 30.11.2004 547BB8F9 00





*Component analysis type ===> Copybook (CPY) Members within Source (SRC) Code *

************************************************************************************************************************************


************************************************************* *************************************************************

Copybook Source Copybook Lib

Name Build Area Changed Release Tso-id Name Name Type Build Appl/Pkg# Changed Tso-id

________ ____ ________ ________________ ________ ________ ________ ________ ____ ____ __________ ________________ ________

27.02.2003 02.12 WSER58 BDTH0000ASMCPY 03.11.2000 14.17 WSER03 ERR0308! ASMCPY CPY STEV000040 25.11.2004 06.10 WSER58

26.02.2003 07.48 WSER58 DIFFNAME

ASMCPY 03.11.2000 14.17 WSER03 ERR0308! ASMCPY CPY STEV000040 25.11.2004 06.10 WSER58

29.11.2004 05.03 WSER58 EROPGM07 SRC STEV000040 30.11.2004 00.40 WSER58

COMMONCB 27.07.2004 06.13 WSER58

29.11.2004 05.03 WSER58 EROPGM10 SRC STEV000040 30.11.2004 00.40 WSER58

COMMONCB 27.07.2004 06.13 WSER58

28.02.2003 00.00 WSER58 P3165COM

ASMCPY 03.11.2000 14.17 WSER03 ERR0308! ASMCPY CPY STEV000040 25.11.2004 06.10 WSER58





*Component analysis type ===> NCAL (NCL) Loads within Composite Load Module (LOD) *

************************************************************************************************************************************


************************************************************* *************************************************************

Called Module Calling Called Lib


24/40



Module Size Linkdate Setssi Build Area Release Module Module Type Appl/Pkg# Build Size Linkdate Setssi

________ ________ __________ ________ ____ ________ ________ ________ ________ ____ __________ ____ ________ __________ ________

8 11.11.2004 546323C3 SYSTEM SDV1R1M0 CKOSORLS LOD STEV000040 8 30.11.2004 547BB8D8

CKOSORLS 8 11.11.2004 546323C3 SYSTEM SDV1R1M0 CKOSORLS LOD STEV000040 8 30.11.2004 547BB8D8

8 29.11.2004 547AA54D EROPGM07 LOD STEV000040 8 30.11.2004 547BB8EB

EROPGM07 8 29.11.2004 547AA54D EROPGM07 LOD STEV000040 8 30.11.2004 547BB8EB

8 29.11.2004 547AA54E EROPGM10 LOD STEV000040 8 30.11.2004 547BB8F9

EROPGM10 8 29.11.2004 547AA54E EROPGM10 LOD STEV000040 8 30.11.2004 547BB8F9


***********************************(Release Area Proc essing)************************************



*Component analysis type ===> Object (OBJ) Components within Composite Load Module (LOD) *

*************************************************************************************************************************************------------- V e r s i o n L i b r a r y --------------* *----------------- A r e a L i b r a r y -----------------*

************************************************************* *************************************************************

Object Changed Date Module Calling Object Lib Changed date Module

Name Size /Linkdate Setssi Build Area Release Module Name Type Appl/Pkg# Build Size /Linkdate Setssi

________ ________ __________ ________ ____ ________ ________ ________ ________ ____ __________ ____ ________ __________ ________

NO CLOD RECORDS FOUND





*Component analysis type ===> LCT Components and included load modules *

************************************************************************************************************************************


************************************************************* *************************************************************

Include Module LCT Include Lib

Module Size Linkdate Setssi Build Area Release Module Module Type Appl/Pkg# Build Size Linkdate Setssi

________ ________ __________ ________ ____ ________ ________ ________ ________ ____ __________ ____ ________ __________ ________

NO CLCT RECORDS FOUND


Legend and Summary Report

The area level of audit chosen at this point is 0 -

Audit is recommended but entirely optional.Error Conditions Detected:

ERR0100! (IDENTICAL COMPONENTS) ===> 06

ERR0308! (CPY HAS MORE RECENT DATE THAN SRC) ===> 03

ERR0417! (VERSION REGRESSION) ===> 02

Highest return code encountered ===> 12

Area UNIT passed the Audit with a return code of 12.


Recommendation Summary Report

Listed below are some solutions to resolving error situations that have

been detected within this audit report.

ERR0100! IDENTICAL COMPONENTS

CHANGED THE COMPONENT AND CHECK IT IN AGAIN. IF NOT NEEDED, RETRIEVE IT FROM

THE AUDITED AREA AND DELETE IT FROM THE RELEASE PACKAGE.

ERR0308! CPY HAS MORE RECENT DATE THAN SRC

RECOMPILE THE SOURCE FROM THE BASELINE LIBRARY INTO THE AUDITED AREA TO INCLUDE

THE RECENTLY CHANGED COPYBOOK.

ERR0417! VERSION REGRESSION

CHECK-OUT THE NEW LATEST VERSION IN MOTION OF THE COMPONENT AND MERGE IT WITH

THE VERSION IN THE AUDITED AREA.

End of job; RC = 12

8. Block an Area

Blocking an area locks the area down to prevent further changes to area components.When an area is blocked, you cannot check-in or retrieve components. The area ownercan set rules for blocking, such as requiring an audit before an area is blocked.

If subsequent area changes are necessary, you can unblock the area. Unblocking an areaunlocks the area for further changes to area components.

9. Approve Area Check-offCheck-off approval is an administrative function that grants permission to check-in thecontents of area libraries to the next area. You begin the process by notifying check-offapprovers. The requirement for check-off approval is determined by the area approvalrule. A check-off approval signifies successful completion of the area testing as a step ofthe release lifecycle.


25/40


ERO Concepts 25

10. Block a Release

Blocking a release locks down the release and its areas in preparation for install. All areasin a release must be blocked before a release can be blocked, and all packages attachedto the release must be approved. When you attempt to block a release, ERO executes apre-install test to validate the release and the contents of the final release area.

The installation JCL is built for each package attached to the release when the release is

blocked.

11. Approve a Release for Install

After a release is blocked, all install approvers must enter their approvals before therelease is installed. When the last approval is entered, the release status is changed toApprove (APR).

12. Install a Release

Packages are installed from their final system area libraries. This differs from the baseChangeMan ZMF product, where package install occurs from the package staging libraries.

Each package is installed based on its own install date and time information. Promotionarea libraries are cleaned out during the installation process, and package areacomponents are baselined.

Figure 2-11. Packages are installed from the final system area.

13. (Optional) Back Out a Release

Release backout first verifies that all packages attached to the release are in a state thatpermits package backout, then submits package backout jobs for the entire release.

Start Area

(Subsystem)

Blocked

Release Q1

Final Area(System)

Area2

(Subsystem)Area3

(Subsystem) . . . .GENL000057

Unit Test

AreaSystem

Test Area Production

Baseline

Area Components Baselined

Package install information

used to install area

components

Promotion libraries cleaned

out during the install process


26/40



When complete, the packages and the release are in backout (BAK) status. Both packagesand release can then be reverted for further development.

14. (Optional) Revert a Release

When you revert a release, it clears all release install approvals, unblocks the release, andchanges the status of the release from approve (APR) or backout (BAK) to development

(DEV) status. The status of release areas is not changed, and packages attached to therelease are not automatically reverted. This allows you to selectively unblock areas andrevert specific packages to rectify the problems before a next attempt to install therelease is made.

Additional ERO Functions

These functions are available with ERO and can be performed when necessary:

Detaching a Package from ReleaseWhen you detach a package from a release, you sever all relationships to the release, itsareas, and area libraries. You break relationships to components in area libraries for thatrelease, and to components in area libraries which identify that release as a prior release.

Retrieving a Package

The retrieve package function removes all package components from the libraries for anarea. 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

Retrieving from an Area

The retrieve area function removes components from area libraries. You must retrievecomponents 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 thecomponent

Testing an Area

The test area function compares the contents of an area to the contents of packagesattached to the release. Error conditions are displayed online.

As you consolidate package components in a release and as you work in packages tocorrect errors you find in release testing, you may create mismatches between thecontents of areas and the contents of packages attached to the release. When you block arelease, ERO automatically executes a test to detect mismatches between the finalrelease area and contents of release packages. You can find these errors earlier in therelease lifecycle by manually executing the test area function against any release area.


27/40

Additional ERO Functions

ERO Concepts 27

Testing a Release

The test release function executes the test area function against the final area of arelease. You cannot block a release until all discrepancies between the final area andpackages attached to the release are resolved.

If automatic cleanup is enabled in the release definition, then automatic cleanup isexecuted in test release the same as it is in test area.


28/40




29/40

The Role of Global Administrator

ERO Concepts 29

Chapter 3

Roles and Responsibilities

This chapter presents ERO roles and responsibilities for administrators and developers.

The Role of Global Administrator

Global administrators establish global parameters for the release environment. Theirresponsibilities include:

Deciding Global Configuration

The global administrator, working with the release manager, determines the high-levelqualifier used during the dynamic allocation of release area libraries, and the datasetpattern for the naming convention to be used for these libraries.

The following panel shows the Global Parameters of High Level Qualifier and DatasetPattern.

Deciding Approvers

All approvers are defined at the global level. When you subsequently build a release, youselect approvers from the global approver list. The following panel shows a list of globalapprovers, and indicates the CREATE command is used to create an approver to add tothis list.

CMNRMGA1 --------------- GLOBAL PARAMETERS PART 1 OF 1 ------------------------

COMMAND ===> SCROLL ===> PAGE

Release Management High Level Qualifier ===> PROD3

Release Management Dataset Pattern ===> HRAPL (Default is HRAPL)

H - High Level Qualifier

R - Release Name

A - Release Area Name

P - Release Application Name

L - Release Library Type (must be the last in the pattern)

Press ENTER to process; Enter END command to exit.


30/40


Chapter 3 Roles and Responsibilities

Approvers are automatically notified at certain checkpoints in the release lifecycle. Thefollowing notifications are sent:

INSTALL APPROVER notification indicates approval is required for a release to beinstalled.

CHECK-IN APPROVER notification indicates approval is required for a release orrelease package to be checked into an area.

CHECK-OFF APPROVER notification indicates approval is required to signify a releaseis ready to be checked into the next area.

ASSOCIATED APPROVER notification indicates approval is required, as components forthe library type which requires their approval became part of the release.

The Role of Release Manager

ERO introduces the role of a Release Manager. This role creates and manages releasesand their associated areas. The responsibilities of a release manager include:

Creating Releases

You create releases with a unique 1-8 character release identifier. The release identifier is

used as a node in the dataset names for release area libraries. Information requiredincludes:

Release Description

Audit Level

The minimum rules that may be used for areas in the release. The least restrictiverules can be set for Approvals, Blocking, Check-in, Generate, and Retrieve.

Ascending or Descending SYSLIB Order of Area libraries

CMNRMAPL ---------- GLOBAL RELEASE MANAGEMENT APPROVE Global Approver Created


(CREATE xxxxxxx to create an approver)

Line Command: QA-Query, UA-Update, DA-Delete, AA-Associations

Security OrderEntity No. Approver Description

__ ACCTPAY 0010 Accounts Payable Manager____________________

__ ACTPLEAD 0010 Lead Developer - ACTP Application___________

__ CIO 0010 Chief Information Officer___________________

__ FINACCTG 0010 Financial Accounting Manager________________

__ GENLEDGR 0010 General Ledger Manager______________________

__ GENLLEAD 0010 Lead Developer - GENL Application___________

__ SYSDVMGR 0010 System Development Manager__________________

__ OPS 0020 Data Center Operations______________________

__ DBA 0030 Database Administrator______________________

******************************* Bottom of data ********************************


31/40


ERO Concepts 31

Ascending order is forward from the current area libraries to the final area libraries.Ascending order ensures you that the latest changes checked into areas starting fromthe target area to the final area are used instead of earlier changes that are residentin the final area.

Descending order is backward from the final area libraries to the current area libraries.Descending order ensures you that the earliest changes checked into areas startingfrom the final area to the target area are used instead of later changes.

Auto Clean-up of Release Packages

When you test the content of the final release area against the content of the releasepackages, components in the staging libraries that have not made it into the final areacan automatically be deleted.

Install Date and Time Range

Installation/Problem Handling Instructions

Release Order

The following panel shows the first part of release parameters you enter when you define

a release. The input fields include, among others, Release Description, Minimum rulelevels, and SYSLIB Concatenation Order.

Defining Install Approvers for a Release

You can select which approvers are needed for a particular release from the list ofapprovers defined at a global level.

Defining Areas to a Release

You create areas with a unique 1-8 character area name, which is used in the datasetname for release area libraries. At least one start (subsystem area) and one final (systemarea) must be defined in a release.

Required information includes:

CMNRMRC0 ---- R041218 RELEASE MANAGEMENT PARAMETERS - PART 1 OF 2 -------------

COMMAND ===>

Release Description ===> Release for December 2005_________________________

Creator's Name ===> AGUSTO YEARWOOD

Creator's Phone Number ===> 800-555-1212

Work Request Number ===> WR 9012

Department ===> FINANCE

Minimum Audit Level ===> 0 (0,1,2,3,4,5)

Minimum Approval Rule ===> 0 (0,1,2,3)

Minimum Blocking Rule ===> 0 (0,1,2,3)

Minimum Check-in Rule ===> 0 (0,1,2,3,4,5,6,7)

Minimum Generate Rule ===> 0 (0,1)

Minimum Retrieve Rule ===> 0 (0,1,2,3)

SYSLIB Concatenation Order ===> A (A-Ascending,D-Descending)

Auto Clean-up of Release Packages:

-in DEV status ===> N (Y/N)

-in FRZ status ===> N (Y/N)

-in APR status ===> N (Y/N)



32/40



Area Description

Audit level

Any Prior Area Name

The Next Area Name

The minimum rules that may be used for areas in the release. The least restrictive

rules can be set for Approvals, Blocking, Check-in, Generate, and Retrieve. TheseArea Functions Rules can be more restrictive than the Release minimum rules.

The following panel shows the above parameters as input fields when defining an area.

Adding Check-In and Check-Off Area Approvers

You can add area check-in and check-off area approvers, which are selected from theGlobal Approval List. If specified, check-in approval is required before check-in to the areais permitted. Check-off approval is required before migration from this area.

The following panel shows part 1 of 2 for defining area approvers. Input fields areApprover Order Number, Check-in Approver, Check-off Approver, and Approver ListCount.

CMNRMAC0 ------ R041218 ACCTPAY AREA PARAMETERS - PART 1 OF 1 -----------------

COMMAND ===>

Area Description ===> Starting area for Accounts Payable components___________

Area Step Number ===> 0001

Area Step type ===> 0 (Subsystem-0 or System-1)

Any Prior Area Name ===>

The Next Area Name ===> FINANCE

Area Audit Level ===> 0 (0,1,2,3,4,5)

Area Approval Rule ===> 0 (0,1,2,3)

Area Blocking Rule ===> 0 (0,1,2,3)

Blocking Entity ===> (Entity Name)

Area Check-in Rule ===> 0 (0,1,2,3,4,5,6,7)

Check-in Entity ===> (Entity Name)

Area Generate Rule ===> 0 (0,1)

Generate Entity ===> (Entity Name)

Generate Synch Packages ===> N (Y/N)

Area Retrieve Rule ===> 0 (0,1,2,3)

Retrieve Entity ===> (Entity Name)

Allow Component Checkout ===> Y (Y/N)

Add Associated Approvers ===> Y (Y/N)

Exclude Area From SYSLIB ===> N (Y/N)

Override Overlaid Components ===> N (Y/N)



33/40


ERO Concepts 33

Blocking a Release

When you block a release, it locks down the release and its areas in preparation forinstall.

The following panel lists releases, and indicates the line command BK is used to block arelease. Other available line commands include AR, which is used to approve a release.

Approving a Release

After a release is blocked, all install approvers must enter their approvals before therelease will install. If a release is unblocked, all approvals entered up to that point arecleared, and they must be entered again after the release is blocked. If an approverrejects the release, the release must be reverted to clear the rejection, and all installapprovals must be entered again.

Installing a Release

Packages attached to a release are distributed when all release approvals are entered andthe release status is changed to approved (APR). Each package attached to a release isinstalled according to the package Schedulerand Install Date/Time. When a packageattached to a release is installed successfully, the package status in the developmentinstance is changed to baseline (BAS).

CMNRMAA0 041218 - ACCTPAY - ACTPLEAD APPROVER PARAMETERS - PART 1 OF 2 --------

COMMAND ===>

Approver Description ===> Lead Developer - ACTP Application___________

Approver Order Number ===> 0010

Check-in Approver ===> N (Y/N)Check-off Approver ===> Y (Y/N)

Approver List Count ===> 0001


CMNRMRLF ------------------------ RELEASE LIST --------------- Row 1 to 3 of 3


Line Command: QR-Query, BK-Block, UB-Unblock, BB-Batch Block, AR-Approve

RV-Revert, RR-View Revert Reasons, RJ-View Reject Reasons

BO-Backout, QC-Query Components, TR-Test Release Components

Release Sta Install Work Request Dept Aud Creator Pkgs

__ R041030 BAS 20051030 WR 9010 FINANCE USER239 00005

__ R041127 BAS 20051127 WR 9011 FINANCE USER239 00005__ R041218 DEV 20051218 WR 9012 FINANCE USER239 00005

******************************* Bottom of data ********************************


34/40



Although release components are installed on a package-by-package basis, thecomponents are copied from final release area libraries rather than from package staginglibraries.

Backing Out a Release

Release backout submits backout jobs for all packages attached to the release. After

completion, the release status is changed to BAK. To return the release to DEV status,you would revert the release.

Unblocking a Release

Unblocking a release unlocks the release for further changes. Unblocking a release doesnot unblock the areas in the release. You must unblock release areas to change releasecomponents.

If a release is unblocked, all approvals entered up to that point are cleared, and they mustbe entered again after the release is blocked.

Unblocking an AreaRelease managers can block area libraries to disallow component migration into pre-defined release areas. They unblock areas libraries to allow component migration tobegin.

The Role of Application Administrator

Application Administrators can manage which applications will participate, or join, in aparticular release.

Joining Applications to a Release

Joining applications to a release helps manage if, when, and with what release anapplication will be updated. Before an application can join in a release, you must defineareas to the release.

The following panel shows the ACTP application has joined a release. The other listed andother applicationss which can be joined to a release by using the S line command.

CMNRMJAP -------- JOIN - R041218 - APPLICATION SELECT Application Joined


Line Command: S-Select to Join release

Appl Status Application Description

_ ACTP *Joined* Accounts Payable____________________________

_ COMM Common Components___________________________

_ GENL General Ledger Accounting___________________

******************************* Bottom of data ********************************


35/40

The Role of Application Administrator

ERO Concepts 35

Selecting Library Types

You select which library types will be eligible to participate in the application joined to arelease.

You can build special purpose releases by omitting some library types from the applicationjoined to the release. For example, you can create a release for on-line components byomitting library types for batch components from all applications joined to the release. If

you then attempt to check-in a package that contains batch components, the batchcomponents will be disallowed from check-in, and the release cannot be blocked.

The following screen shows a list of library types. With the S line command, you selectwhich library types can participate in the application joined to a release.

Defining SYSLIB Concatenations

ERO allows you to define SYSLIB concatenations, which are based on:

application

library type

language

procedures

These SYSLIB concatentations are used for build processes to determine whichcomponents will be used for copybook and load module inclusion. The release applicationlibrary types eligible for SYSLIB definition are like-source, like-load, and like-linkcontrollibrary types defined to the joined application.

CMNRMLAL ------------- ACTP - LIBRARY SELECTION LIST ------- Row 1 to 15 of 15


Line Command: S-Select, D-Deselect

Lib

Type Request Description

_ ACT ________ Component Activity File______________________ CPS ________ Copybooks with same name, different library_

_ CPY ________ Copybooks for ACTP Application______________

_ CTL ________ Job Control Statements (x)__________________

_ DBB ________ DB2 BIND PLAN Command Members_______________

_ DBR ________ DB2 DBRM____________________________________

_ JCL ________ Execution JCL_______________________________

_ LCT ________ Link Edit Control Statements________________

_ LOD ________ Executable Load Modules_____________________

_ LOS ________ Load for Subprograms to be Statically Linked

_ LST ________ Compressed Stage Listings___________________

_ PKG ________ DB2 BIND PACKAGE Command Members____________

_ PRC ________ Cataloged Procedures________________________

_ SRC ________ Source for programs to be Linked Executable_

_ SRS ________ Source for Subpgms to be Statically Linked__******************************* Bottom of data ********************************


36/40



The following panel shows libraries for type CPY will be concatenated over libraries fortype CPS. This is in application ACTP for library type SRC, with language COBOL2 andprocedure CMNCOB2.

The Role of Developer

As a developer, you work at a component level to ensure the correct changes are made tocomponents 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 theERO release lifecycle. The components in your package remain under package control,and you execute standard change package lifecycle functions to prepare thesecomponents for installation into production.

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

CMNRMSY1 --------- ACTP - SRC - SYSLIB LIBRARY ORDER --------- Row 1 to 2 of 2


Library Type: SRC Language: COBOL2 Procedure: CMNCOB2

Line Command: D-Delete, *-Library Type List

Library Order

Type Number

_ CPS 00000

_ CPY 00000

******************************* Bottom of data ********************************


37/40

The Role of Developer

ERO Concepts 37

Checking Out Components

After you attach a package to a release, you can check out components into your packagefrom releases that have not been installed yet. Checkout from release lets you startcoding 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. Ifyou check out a component from an area in the current release, you will eventuallyencounter an overlay condition in package or area check-in unless the other version isretrieved.

Checking In Packages

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

Package check-in initiates these activities:

Allocates area libraries for all areas in the release for the library types that arecontained in the package

Populates starting release area libraries

Makes the components available to build processes in other packages in the sameapplication that are attached to the release

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

CMNCRT0R ---------------- CREATE: CREATE A NEW PACKAGE ------------------------

OPTION ===>

L Long method - Prompt for package description and special instructions

S Short method - Use default package description and instructions

PACKAGE TITLE===> Add week-to-date accrual calculation

APPLICATION ===> ACTP (Blank or pattern for list)

REQUESTER'S NAME ===> Angelique Pavao

REQUESTER'S PHONE ===> 555-1212

WORK REQUEST ID ===> WS 77309A

DEPARTMENT ===> D440

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)ATTACH PACKAGE TO RELEASE ===> YES (Yes/No)


38/40



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

With appropriate area rules in place, you audit, freeze, and approve packages before theyare checked into a releases starting area.

Checking In an Area

Area check-in allows you to copy components from the libraries for one area into thelibraries for another area. Check-in advances release components through the hierarchyof 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 sameapplication that are attached to the release

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

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

Continues the process of squeezing out multiple versions of the same component, asonly 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 loadcomponent in the area libraries.

Auditing an Area

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


39/40

ERO Concepts 39

Index

Aadvantages19Application Administrator34approvals21, 24approver groups20approvers29, 30, 31area15

auditing38blocking20, 24, 34check-in38checking in21creating20

final16generating38retrieving26starting16subsystem16system16testing26

areasdefining31

auto clean-up31

C

component check out37concurrent development12, 13

D

Developer36

G

Global Administrator29

I

install date19installation JCL25

L

library types35

Ppackage18

attaching21, 36check-in37checking in18, 21detaching26retrieving26

R

release13, 14

application17approving25, 33backing out25, 34blocking25, 33creating20,30installing25, 33

joining applications17, 34lifecycle20migration path16package18reverting26testing27unblocking34

release area15release audit13, 22, 38

report23release management

considerations10goals9objectives10physical implementation10requirements9strategies10

Release Manager14, 30release order31

SSYSLIBs14, 19, 30, 35


40/40

Index

Date post:	06-Apr-2018
Category:	Documents
Upload:	poojarjadhav
View:	234 times
Download:	1 times