C
HANGE
M
AN
®
U
SER
G
UIDE
notice, and should not be construed as a commitment by SERENA Software, Inc. SERENA Software, Inc. assumes no responsibility or liability for any errors or inaccuracies that may appear in this book.
Except as permitted by such license, no part of this publication may be reproduced, 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 Software, Inc.
Copyright © 1999 SERENA Software Inc. All rights reserved.
T
RADEMARKSChange Man, Comparex, and StarTool are registered trademarks of SERENA Software, Inc. CDF (Concurrent Development Facility), Detect+Resolve, FULL.CYCLE, Merge+Reconcile, SERNET, SERPOWER, StarWarp, and X:Change are trademarks of
SERENA Software, Inc. Change Transfer is a trademark of SERENA Software, Inc. and High Power Software, Inc. Detect+Resolve Mainframe is jointly owned and developed by SERENA Software, Inc. and High Power Software, Inc. SyncTrac is a registered trademark of SERENA Software, Inc. and High Power Software, Inc.
CA-ACF2, CA-Librarian, CA-Panvalet, CA-Top Secret, and CA-Endevor are registered trademarks of Computer Associates International, Inc. DB2, DR/RACF, IMS, and ISPF are trademarks and registered trademarks of the International Business Machines Corporation (IBM). Microsoft Windows NT and Microsoft SNA Server are registered trademarks of Microsoft Corporation. All other products or company names are used for identification purposes only, and may be trademarks of their respective owners.
C
ONTENTS
1
Introduction
Change Man Server 4.1.6 Enhancements 1-1
Year 2000 Compliance 1-1
Mass Recompile 1-2
Change Man/IMS 1.1.0 1-2
Formatted Component Description Data 1-2
Enhanced Info/Man Interface 1-2
SERENA Network 3.1.1 1-3
Additional Remote Procedure Calls 1-3
Machine Readable Documentation 1-3
Substantial Quality Improvement 1-3
2
What is Change Man?
Features of Change Man 2-1
Change Packages 2-1
The Change Man Life Cycle 2-2
Inside Change Man Development 2-3
Create 2-3
The Checkout Process 2-3
The Staging Process 2-4
Auditing 2-5
Freezing Packages 2-6
Promoting Packages and Components 2-6
Approving Packages 2-7
Installation 2-9
Backing Up 2-9
Backing Out Packages or Components 2-11
Checkout 2-12
Impact Analysis 2-13
Staging 2-13
Audit 2-14
Recompile and Relink 2-15
Freeze 2-16
Promotion 2-16
Approve 2-16
Production Installation 2-17
Baseline Libraries and Delta Decks 2-17
Backout Management Facilities 2-17
Emergency Changes 2-18
Storage Name Considerations 2-18
3
Accessing Change Man and Navigating Panels
Accessing the Primary Option Menu 3-1
Accessing the Build Options Menu 3-3
Navigating Through Change Man Panels 3-3
Panel By Panel Navigation 3-3
Using Direct Access Navigation 3-4
Using Package List Option 3-4
Working with Lists of Libraries, Packages and Components 3-4
Using Commands 3-4
Using Patterns 3-5
Using Lists 3-5
Using a Selection List 3-7
Scrolling Through Lists 3-8
Using Basic Edit Line Commands 3-8
Inserting a Line 3-8
Repeating a Line 3-8
Deleting a Line 3-9
Read-Only Versus Data Entry Fields 3-9
Accessing the Online Tutorial 3-9
Exiting Change Man 3-9
Canceling Changes on a Panel 3-10
Change Man Online Error Messages 3-10
Contents
4
Creating a Change Package
Creating a New Package 4-1
Using Short and Long Methods 4-2
Providing a Package Description 4-5
Specify Package Installation Instructions 4-6
Package Scheduling Dependencies 4-8
Scheduling Installation Date and Time 4-9
An All Site Environment 4-9
A Remote Site Environment 4-11
Package Levels 4-12
Complex or Super Packages 4-13
Participating Packages 4-14
5
Updating Change Package Information
Updating a Change Man Package 5-1
Control Information 5-2
Updating Package Description 5-4
Package Installation Instructions 5-5
Package Scheduling Dependencies 5-6
Affected Applications 5-7
Complex or Super Package Information 5-8
Package Installation and Site Information 5-8
Remote Site 5-9
Single Site 5-10
Updating Package Status for Super and Complex Packages 5-12
6
Checking Out a Component
Checkout Restrictions, Rules, and Options 6-1
Checking Out Components 6-3
Selecting Components from Baseline or Promotion Libraries 6-3
Using the Package List to Select Componentst 6-7
7
Staging a Component
Stage Compile and Link Edit Panel 7-8
User Options 7-11
Mass Compile and Link Edit Components 7-12
Staging Other Type Components Panel 7-13
Staging from Packages 7-13
Source to Load Relationship Panel 7-15
User ID Work List Panel 7-16
Staging Using Package Parameters 7-16
Component List Parameters 7-17
8
Auditing Packages
How Audit Works 8-1
Audit Options 8-2
The Audit Change Package Panel 8-2
Two Audit Methods 8-7
Pre-Audit (Staging Library Audit only) 8-7
Full Audit 8-8 Running an Audit 8-9 Success or Failure 8-9 Additional Features 8-9 Audit Auto-Resolve 8-9 Diagnostic Information 8-9
Filtering the Number of Reported Out-of-Synch Conditions 8-10
Specifying a Participating Package as a Primary Package 8-10
Processing Participating Packages by Install Date 8-10
The Audit Report 8-11
Audit Report Format 8-12
Locating Information in the Audit Report Header 8-12
Audit Report Header 8-12
The Report Body 8-14
Report Sections 8-14
Section Layout Areas 8-14
Example 1: The Three Layout Areas: An Introduction to Audit Reports 8-15
Baseline and Staging Areas 8-15
Component History Area 8-16
Example 2: Fields in the Three Layout Areas: Copy Report Section 8-17
Contents
Example 3: Fields in the Three Layout Areas: Source Report Section 8-19
Baseline and Staging Area Fields: Source 8-19
Component History Area Fields: Source 8-20
Example 4: Fields in the Three Layout Areas: Load Report Section 8-20
Baseline and Staging Area Fields: Load 8-20
Component History Area Fields: Load 8-22
Example 5: Flags 8-22
Example 6: Staging Library Audit: Link-Edited Statically Called Subroutines 8-23
Audit Report Output Similarities 8-24
Legend and Summary Report 8-24
Recommendation Summary Report 8-26
Evaluating Audit Reports 8-26
Out-of-Synch Conditions 8-26
Return Codes 8-33
Differentiating Install Dates 8-33
Complex or Super Packages 8-33
Participating Packages 8-33
Examples for Handling Install Dates 8-34
Summary of Exampes of Audit Situations 8-35
8-36 Example A: Auditing a Participating Package as a Simple Package 8-37
Overview of Auditing Participating Package 5 as a Simple Package 8-38
Example B: Auditing a Complex Package 8-38
Overview of Auditing Complex Package 1 8-39
Example C: Auditing a Participating Package as a Primary Package with Process by
Install Date Set to No 8-39
Overview of Auditing Participating Package 5 as a Primary Package with
Process by Install Date Set to NO 8-40
Example D: Auditing a Participating Package as a Primary Package with Process by
Install Date Set to Yes 8-40
Overview of Auditing Participating Package 5 as a Primary Package with
Process by Install Date Set to YES 8-41
Example: Auditing a Participating Package as a Primary Package with Process by
Install Date Set to No 8-41
Summary of Auditing Participating Package 5 with Process by Install Date
Set to NO 8-42
Summary of Auditing Participating Package 5 by Department Number
with Process by Install Date Set to NO 8-45
Summary of Auditing Participating Package 5 by Department Number
with Process by Install Date Set to YES 8-46
Resolution Scenarios 8-46
Case 1: SYNCH4! (within the same change package) 8-46
Case 2: SYNCH5! (within the application) 8-47
Case 3: DUPLIC! (within a change package) 8-47
List of Upgraded Components 8-48
Source 8-48
Copybook 8-48
Panels 8-49
Skeletons 8-49
9
Freezing a Package
Accessing the Freeze Options Panel 9-3
Freeze a Package Online 9-4
Freeze A Package in Batch 9-5
Unfreeze and Refreeze Components 9-6
Reset the Freeze in Progress Indicator 9-9
10
Promoting to a Local System
Using The Promotion Facility for Intermediate Testing 10-2
Third Party Testing 10-2
Unit Testing of Online Systems 10-2
Promoting and Demoting Changes 10-2
Promoting a Change Package 10-4
Promoting Online 10-4
Promoting in Batch 10-5
Demoting a Change Package 10-6
Demoting A Package Online 10-7
Demoting in Batch 10-7
Promoting and Demoting Components 10-8
Promoting Components 10-8
Selectively Promote Components 10-8
Repromote Select Components. 10-8
Contents
11
Promoting to a Remote System
How Administrators Can Configure Remote Promotion 11-1 Promoting Change Packages or Components to a Remote Site 11-2
Selective Promotion of Components 11-9
Demoting Change Packages or Components from a Remote Site 11-11 Checking for Common Components at a Remote Site 11-16
12
Recompiling and Relinking Components
Recompile Overview 12-1
Recompiling into Staging Libraries 12-1
Providing Recompile Job Information 12-4
Browsing Recompile Source List 12-5
Relinking Load Components 12-5
Example 12-6
Stage User Options Panel 12-8
Link Edit Control Cards List 12-9
13
Approving or Rejecting a Package
Approving or Rejecting Packages 13-2
Approving or Rejecting a Package 13-5
Approving a Package 13-5
Rejecting a Package 13-6
Resubmitting the Batch Approve and Batch Build X Node Data Set JCL 13-6
Using the Component User ID Work Record 13-7
Using the Component User ID Work Record during Approval 13-7
Viewing the Component User ID Work List 13-7
Deleting the Component User ID Work Record 13-9 Distribution and Installation of the Change Package 13-9
Distribution to Remote Sites 13-9
14
Reverting a Package
Reverting a change package. 14-2
16
Using Package List for Change Man Functions
Accessing the Package List Parameters Panel 16-1
Browsing the Change Package List 16-5
Acting on Packages 16-5
17
Utility Requests
Compress Staging Libraries 17-1
Accessing the Compress Staging Libraries Panel 17-1
Renaming or Deleting Components 17-2
Accessing the Rename or Scratch Options Panel 17-2
Creating Utility Requests from Baseline 17-3
Activating or Deleting Utility Requests from Packages 17-4
Deleting and Undeleting Packages 17-5
Deletion Considerations 17-5
Setting up a Memo Delete 17-6
Canceling a Deleted Change Package Request 17-6
18
Comparing Staging Libraries
Comparing Staging Libraries to Baseline or Promotion 18-1 Printing, Deleting or Keeping Comparison Information 18-4
19
Browsing and Printing Package Information
Using the Activity Log 19-1
Providing Browse Activity Log Filtering Information 19-1
Reviewing the Activity Log 19-3
Produce a Log Activity Report 19-4
Using the Baseline Browse/Print Facility 19-6
Browsing Baseline and Promotion Library Components 19-9
Editing Components in Browse Mode 19-11
Use ISPF Edit Commands 19-11
Copy Components to Target Data Sets 19-11
Printing Copies of Components 19-13
Print Copies of Components with Expanded Copybooks 19-13
Browsing a Compressed Listing 19-13
Browsing Compressed Listings 19-14
Contents
Browsing the Global Notification Facility 19-16
Using the Scan Library Utility 19-18
Scanning Online 19-18
Allowing a Library Scan 19-21
Restricting a Library Scan 19-21
Search for Dependencies 19-22
Batch Scan 19-23
Search for Character String 19-23
Search for Dependencies 19-25
Running the Batch Scan 19-26
20
Querying Packages and Components
Accessing the Query Options Panel 20-1
Querying Change Packages 20-2
Specifying Filter Criteria 20-2
Using the Extended Search Criteria Panel 20-5
Browsing the Query Package List 20-5
Querying Components 20-9
Querying Impact Analysis Data 20-11
Specify Search Criteria for the Component List 20-12
Query the Component Selection List 20-15
20-16
A
Package Category Panels
General Information A-1
Non-Source A-2
Source A-3
Source and Load Relationship A-5
Renames and Scratches A-5
Approval List A-5
Site Activities Date and Time A-6
Site and Install Date Information A-6
Custom Forms A-7
Participating Package A-8
Remote Promotion History A-10
Promotion Libraries A-11
Remote Promotion Libraries A-12
Query Development Staging Libraries A-14
Query Production Staging Libraries A-15
Production Libraries A-15
Baseline Libraries A-16
Glossary
G-1I
NTRODUCTION
1
The Change Man User Guide is designed for persons wanting to use Change Man functions in order to migrate software, or applications, from a
development environment to a production environment.
After reading this publication, you should be able to perform any of the functions of Change Man and access any package information, reports or analysis information for packages.
C
HANGE
M
AN
S
ERVER
4.1.6 E
NHANCEMENTS
Change Man Server 4.1.6 is designed to be Year 2000 compliant. The 4.1.6 release contains a minimum number of new features, so as to make the conversion effort for the existing customer base as painless as possible. SERENA recognizes that a number of Change Man customers will convert to 4.1.6 in the immediate future to satisfy their specific Year 2000 compliance issues.
As it stands, the conversion to Change Man Server 4.1.6 from earlier versions of Change Man depends upon the customization at a client’s site. A majority of the panels and skeletons are modified in 4.1.6; these modifications are required to support four digit years in all date input and output fields. A number of panels are also redesigned; this is necessitated when year expansion results in a line that cannot be accommodated in an 80-character field.
Following are the enhancements for Change Man Server Version 4.1.6.
Year 2000 Compliance
Change Man Server 4.1.6 is fully Year 2000 compliant. In implementing Year 2000 compliance, SERENA realizes that a number of customers read the
below the base year are assumed to be in the 20th century, and years base and above are assumed to be in the 21st century. Customers who adopt this same technique can modify any programs that access the package master to be Year 2000 compliant. The key length of the log data set did change in this release; the date is a part of the key and the key length changed from eleven to fourteen.
Mass Recompile
Change Man Server 4.1.6 includes the ability to specify batch mass recompiles, through the MASS and MASSALL primary commands. The MASS command will recompile all selected members; MASSALL will recompile all members displayed. Included is the ability to suppress the history while processing compile parameters and to specify a set of compile parameters for the
components in a mass recompile. In a mass recompile, the CMNRCOMP will submit a single CMNRPC2 job, which will then invoke the high level
recompile RPC and submit a compile job for each component selected/ processed.
Change Man/IMS 1.1.0
Change Man Server 4.1.6 is the first release of Change Man to support the CMN/IMS interface option. This option supports compiles for PSBs, DBDs and MFSs. Also supported is the promotion and installation of these component types, along with the generation of ACBs for PSBs and DBDs. Overrides can also be specified for PSBs and DBDs. Exit CMNEX041 is available to help the administrator control who can update the IMS information within a package. This is similar to CMNEX001 for package information updates.
Formatted Component Description Data
Change Man Server 4.1.6 includes a feature known as Formatted Component Description Data. The Component Description Data string that Change Man previously supported was free form text. Exit CMNEX042 now lets you format this free form area and validate the information there.
Enhanced Info/Man Interface
Exit CMNEX100 information is now passed along to the Change Man Info/ Man interface to let you set up additional information for Info/Man. This information is passed 4096 bytes behind the standard information and does not show in CMNINFAP. Program samples that access this area are available from Technical Services.
Change Man Server 4.1.6 Enhancements
SERENA Network 3.1.1
SERENA Network 3.1.1 offers Change Man Server users substantial performance enhancements, as well as a bridge to the future SERNET versions.
Additional Remote Procedure Calls
Change Man Server 4.1.6 includes 31 new RPCs. This follows SERENA’s stated direction in moving all Change Man functions to RPCs.
Machine Readable Documentation
All of the Change Man Server 4.1.6 manuals are available in Adobe Acrobat Portable Document Format (PDF). These machine-readable manuals are not distributed on the Change Man tape, but are available on SERENA’s FTP server. Contact Technical Services for more information on obtaining an FTP userid and password, or for additional information on viewing the PDF files.
Substantial Quality Improvement
Change Man Server 4.1.6 includes substantial product fixes. All fix packages are included, and a substantial number of errors from previous releases have been corrected. The quality of Change Man Server is important to SERENA.
W
HAT
IS
C
HANGE
M
AN
?
2
Change Man is a comprehensive system designed to provide reliable and streamlined implementation of software changes on the MVS system. It is a system that manages and automates the process of migrating software changes, or applications, from a development environment to any test
environment and to the production environment. A comprehensive TSO/ISPF interface guides you through various change management processes.
F
EATURES
OF
C
HANGE
M
AN
• Unique package concept guarantees the coordination of your change • Concurrent development are managed
• Controls version discrepancy and out-of-synch component relationships • Maintains listings on-line for immediate access
• Provides notifications
• Manage your libraries (Librarian, Panvalet, or PDS, PDS/e) • Full suite of on-line and batch query and reporting capabilities • Maintain historical information in a single repository.
C
HANGE
P
ACKAGES
Within Change Man, a Change Package is the vehicle in which all changes are moved from a development environment to a production environment. A change package may contain one or more components (source, copybook,
T
HE
C
HANGE
M
AN
L
IFE
C
YCLE
This section provides an overview of the Change Man life cycle. It provides a step-by-step description of migrating a change from development to
production within Change Man. Figure 1:
1 Create a Change package. A Change package contains the elements to be edited and installed into production, and is identified by an unique package identification generated by Change Man. When you create a package, you provide the information that Change Man needs to track and control the package.
2 Checkout components from baseline. The checkout process allows you copy components from your baseline libraries to a Change Man staging library or to a personal development library where you can make changes. 3 Editing changes. You may edit changes in the Change Man staging or in
the development libraries.
4 Staging components. For source components, staging will run the appropriate translation procedures to create associated load modules. Components such as documentation or copy members are copied into the staging libraries, if they are not there already.
5 Audit process. The audit process ensures that no unexpected problems will occur.
6 Freeze process. The freeze process locks the package and makes the package available for the promotion and approval processes.
7 Promotion process (optional). Promotion allows a package to be moved through various levels of testing. For example, promote from system testing to acceptance testing.
8 Installation. After all of the approvals have been gathered by Change Man, the package is ready to be installed. If the manual installation method was selected when the package was created, the package will be installed immediately after the final approver has approved the package. If the Change Man’s internal scheduler method was selected, Change Man will automatically install the package on the date and time specified at
package creation. If an external scheduler is used, Change Man will convey the install information to that scheduler so that it can install the package.
Inside Change Man Development
9 Baseline ripple. After installing the package, Change Man will baseline ripple the package. Baseline ripple is the process that Change Man executes to version all package components.
I
NSIDE
C
HANGE
M
AN
D
EVELOPMENT
Behind the displayed Change Man panels, there are jobs being performed that ensure the smooth flow of enhancements to each application maintained by development analysts.
Create
Create is a first step of the Change Man life cycle. After you Create a change package, Change Man allocates Staging Libraries as needed. The dataset names of the Staging Libraries reflect the application mnemonic chosen for your application, the package number assigned by Change Man for this change, and the type of components placed in the library; for example, DEMO.CMNSTAGE.#000023.SRC. The Global Administrator decides on the format of the data set name. The package information is recorded on the Package Master along with the TSOID of the creator. A record of this event (Package Creation) is placed on the Log.
The Checkout Process
Checkout is the process of copying components from the Baseline Library (any level back or from Promotion Libraries) to a development area for modification in a change package. You can Checkout online in the foreground or in background as a batch job. If you Checkout in background mode, Change Man asks you to verify (initially type or update) the jobcard statements needed to perform the batch job.
When you Checkout a component, the standard PDF statistics are carried forward and the version number (the vv portion of vv.mm) is incremented. Change Man adds the Checkout information to the statistics that make up a component’s history. A record of this event (Checkout component) is placed on the Activity Log. Anyone can browse this log for information not only on Checkout actions, but also other Change Man activities.
If you associate the Checkout to a valid change package ID, the component name is added to the package’s Staging List. This means that when you select the Stage option from the Build Options Menu and select to Stage from the Package Driven option, the component is already listed with a Checkout status. This means that it is ready for copying into the appropriate Staging Library; to do this you simply type an S next to the item and press Enter. In some applications, package association may be required by the administrator; in all cases, package association can simplify (reduce the number of required keystrokes in) the Staging process.
The Staging Process
Staging introduces components into Change Man by copying them from development or personal libraries into Change Man Staging Libraries. All Staging Library components must be associated with pre-defined change packages.
Depending on how your administrator configures Staging parameters for your site, you can either Stage any newly created application component into any change package, or only components previously associated with change packages.
For instance, your administrator may want to restrict new development on an application and designate that only existing components be maintained. The administrator can restrict the Staging process so that only components previously associated with change packages can be Staged back into the change cycle.
Before staging, verify that your administrator has:
• Designated compile procedures for each language type you intend to Stage.
• Assigned appropriate compilers during installation of Change Man Staging Libraries contain components of the same type. The following table lists component types that Change Man recognizes and considers when staging.
Type Description
SRC Source modules
Inside Change Man Development
You can Stage components either online or Mass Stage them in batch.
Auditing
When you audit a package’s Staging Libraries, Change Man analyzes and reports on every module contained in both the Baseline Library and your change package. The Audit function also validates all copies and program
JCL JCL
DOC Documentation
CPY Copybooks
LCT Linkage Control Cards
LIKE SRC LIKE LOD LIKE CPY
Assign this type to SRC, LOD, or CPY components when you want to Stage
components of same type into separate Staging Libraries.
OTHER Assign this type to components when you want to customize processing of a component.
PRC Compiling Procedures
Staging Type Enables User to do the Following:
Online Use confirmation panels to review relevant parameters and compile procedures prior to Staging a component.
Use language assumption, a feature that automatically assigns language types, and designated compile procedures when Staging source components.
Batch Stage multiple components simultaneously. Stage complete libraries of components.
By-pass confirmation panels to Stage components faster. Use the language assumption feature.
Freezing Packages
When you are ready to Freeze the package for Promotion and/or Approval (Approval is required), Change Man checks two things:
• Are all components in an Active status?
During the Stage process if the component is successfully copied into the appropriate Staging Library and if source components’ have compiled, link/ edited, and their bind has completed then Change Man will change the status of the component to Active.
• Did the package pass the audit?
The audit level selected by the application's administrator must not be exceeded.
When the package is successfully Frozen, the package's status changes from DEV to FRZ, which locks out anyone from Staging into the package's libraries. A record of this event (Freeze package) is placed in the Activity Log.
Promoting Packages and Components
The Promotion facility allows you to set up intermediate environments or Promotion levels where you can perform quality assurance, unit and system tests on packages and components. Promoting involves migrating change packages or components through these intermediate environments. Demoting is the deleting of components logically or physically from these environments. Before using the Promotion facility, your application administrator must first set up:
Generally, you Promote packages from Staging Libraries to specified Promotion levels.
• Promotion levels: You can have one or more levels of Promotion, each level having one or more libraries associated with it.
• Promotion process: You can Promote packages and components either online or in batch.
• Promotion authorization: Each Promotion level can be secured. Your administrator can build rules within Change Man and your security system that will designate which users can Promote a package to a specific level.
Inside Change Man Development
The following functional characteristics of the Promotion facility may affect decisions you make about when and how to Promote and Demote packages and components:
• After components are copied from package Staging Libraries, they will continue to reside in the Staging Libraries. This implies that you should only include executable libraries in your Promotion environment. Source modules do not have to be promoted because they will be retained in the package libraries.
• Promotion from level to level may be a logical copy or a logical move; that is, the components may remain in the previous environment or they may be deleted from the previous environment upon Promotion.
• Each time you Promote (or Demote), Change Man updates the statistics constituting the component's history. A record of this event (Promote package) is placed in the Activity Log.
• Staging skeletons for source components may reference Promotion copybook libraries as part of the copybook concatenation. Therefore, if copybooks are Promoted, they may be made available to source compilation of other packages.
• Change Man does not enforce the use of Promotion, even if it has been set up by an administrator. Moreover, upon completion of the Approval process, the package is Distributed (and Installed) regardless of the level of Promotion reached. This gives you the flexibility to alter the path of migration of each package. However, if you do want to require a
Promotion path, you can administratively link your Promotion security to your Approval security. This technique allows a promoter to offer his/her Approval of a package once it has been successfully Promoted and tested.
Approving Packages
When a person accesses the Change Man panels, that person’s TSOID is passed along and used to determine which functions are available. Approval may be performed only by those TSOIDs associated to the Entity names that the application's administrator has specified as approvers.
• The approval process consists of browsing the package information and Staging Libraries for quality control and standards and selecting to Approve (or Reject) the package.
• All Approvals for a package must be gathered before Change Man will Install a package. In fact, the final Approval of a package will actually initiate or schedule the package Installation.
• A change package must be in Frozen (FRZ) status to be Approved or Rejected.
• In general, a package’s components cannot be modified while in Frozen status. This implies that a package’s components cannot be modified while approvals are being gathered. However, components can be selectively unfrozen, modified, and refrozen while the package is still in Frozen status.
• There can be multiple levels of Approvals. Change Man requires at least one approval but allows administrators to set up more than one level. • Multiple levels of Approval may be set up in a hierarchy. This implies that
Change Man will enforce an order of Approvals. Change Man will not allow Approvals to be gathered out of order.
• More than one User ID may be authorized to satisfy a given Approval level. This is set up in your security system.
• Your application administrator may have set up Approval notifications. Each approval level can be configured with multiple User ID notifications. The User IDs that are notified may or may not coincide with the User IDs that can actually satisfy the Approval.
• Different packages may have different Approvals. Change Man allows administrators to set up separate Approval Lists by application and by time of day. Change Man will attach an abbreviated Approval List to unplanned packages Created outside of normal business hours. Change Man will attach a complete Approval List to all other packages.
Furthermore, your administrator may have tailored a user exit to customize Approvals Lists further.
• Change Man provides special processing for packages with an abbreviated Approval List attached. These Approvals must, of course, be gathered before the package can be Installed. However, once Installed, the package continues to be available for Approval or Rejection by approvers on the
complete Approval List. This allows for a post-Installation Approval
strategy.
• Packages may be Promoted and Demoted while Approvals are being gathered. This implies that the final Approval of a package will Install it,
regardless of the Promotion status. Therefore, the final approver of package
Inside Change Man Development
• If a package is Rejected, it must be Reverted if it is to be updated to conform to the Reject reasons. Package Revert will reset the Rejection and place it in Development status. The package must then be Frozen again to reinitiate Approvals.
• If a package was Promoted before it was Rejected, then it must be Demoted before it can be Reverted.
• Package Revert will reset any gathered Approvals. This is true regardless of whether the package is first Rejected.
Installation
Installation depends on whether or not an internal scheduler is set up by the global administrator or if the Install job JCL has been specially modified. There are three variations on Installation:
• If no scheduling system is specified, the package goes through the Installation process immediately.
• If the Install job JCL is set up with a TYPRUN=HOLD, the user releases the job when they are ready to Install.
• If a scheduling system other than Change Man's internal scheduler is specified, then Change Man performs a batch interface to add the Install job to the scheduler's list. The operator, however, must still demand the job for the package to be Installed.
• If Change Man is the scheduler, it checks the package master every few minutes for any packages which are ready and Installs those that meet the criteria.
Backing Up
Backup is the first job to be performed when Installation time arrives. This job copies the production libraries (only those components which are about to be overlaid with updates) to a backup set, in case they are needed to back out the incoming enhancement. Next, the contents of the change package Staging Libraries are copied into production libraries. A record of this event (Package Installation) is placed on the Activity Log. This occurs each time the package is Installed at one of the Remote Sites.
2 A job is sent to the development center to clear out the last level of Promotion reached and ripple the Baseline Libraries for that application. 3 The package status is changed from INS to BAS.
4 A record of this event (Baseline Ripple) is placed on the Log.
NOTES
Only the various versions of changed software components are updated; Change Man ripples the changes through the versions of an application’s Baseline Libraries.
Assume that the following is true:
• An application maintains up to three versions of its Baseline Library software: current (0), -1, and -2.
• You want to update the Baseline Libraries with a change package in which component A is changed, component B is scratched and component C is added.
• There already is a -1 and -2 version of component A. Thus, the baseline library is updated as follows:
• The -1 version of component A is copied to overlay the -2 version of component A.
• The 0 version of component A is copied to overlay the -1 version of component A.
• The newly Installed version of component A is copied from the production Staging Libraries to overlay the Baseline Library 0 version of A.
• Component B is scratched.
• The newly installed version of component C is copied from Staging Libraries and added to the Baseline 0 Libraries.
Inside Change Man Development
Backing Out Packages or Components
If there is a problem with the change package (backout is allowed only for permanent packages) after it has been Installed, the change package is backed out by deleting the updated component in production and then retrieving the previous version of application software from the Backup Library. This option is selected by an authorized user in the production environment, usually an operator or production analyst. Change Man will back out the entire package by copying the components from the Backup Libraries to overlay production. The package status is changed from BAS to BAK. A record of this event (Package Backout) is placed in the Activity Log.
A job is submitted in the development area to reverse ripple the Baseline Library. A record of this event (Baseline Reverse Ripple) is placed in the Activity Log.
Temporary Change Cycle
When a temporary change package is Created, the user must type the number of days the change is to remain in the temporary (override) environment (if your global administrator has setup this option). The Installation process is different from other package types because the contents of the temporary change package Staging Libraries are copied into Temporary Libraries, which are concatenated ahead of production libraries. Since the production library components are not touched, Change Man does not perform the Hot Backup. The components are never rippled into the Baseline Library. After the package is Installed, Change Man begins the aging process at each site selected to receive the temporary change. The package is deleted from the Temporary Library when the number of elapsed days is met and the administrative housekeeping tasks which delete them are executed. After the package has been deleted from all sites, its status is changed from INS to TCC, and a record of this event (Temporary Change Cycle Completed) is placed on the Activity Log.
Distribution to Remote Sites
The next step after approval depends on the environment type configured for the site.
• If there are Remote Sites, then the package Staging Libraries, the Installation JCL, and a copy of the package master record pertaining to this change are:
— Installed there. A record of this event (Package Distribution) is placed in the Activity Log and a Distribution acknowledgment is sent back to the development center. The package status is changed from APR to DIS.
• If Remote Sites exist, the package is ready for Installation. For further information, see ”Installation“ on page 2-9.
Distributing and Installing Components at Remote Sites
Remote Sites are additional CPUs where Change Man Installs components. An additional CPU can be:
• A separate computer in another building • A separate computer in the same building
• A logical CPU on the same machine as part of an LPAR (logical partition) without shared DASD
Any of these Remote Site configurations enables you to develop components on one CPU and distribute and Install production level components on a different CPU.
Remote Sites act only as a receiver of production level components. The only time developers interact with Remote Sites is when they select which Remote Site to Distribute and Install production level components.
C
HANGE
M
AN
L
IBRARY
E
NVIRONMENT
Checkout
Checkout enables you to reintroduce components residing in baseline or promotion libraries to the change cycle. Generally, production level
components are checked out for modification. However, you can check out any previous version of a baseline component that exists (-1, -2, -3, etc.). Depending on the way your administrator has configured Change Man, you can check out components:
• To personal libraries • To staging libraries
Change Man Library Environment
• In batch • Online
• Concurrently with other components
If your site has applications that require parallel development, you can configure Change Man to allow concurrent checkout of components. Change Man has an automated process for managing this concurrent development. As part of this process, Change Man ensures that each owner of a version is aware of the actions of the other owners.
After you check out components and make necessary modifications, Change Man records the components and the associated change package for further impact analysis. This ensures that your developers are always working with the proper version of a component.
Impact Analysis
To analyze the impact of changes, many organizations rely on data from a variety of sources, such as batch library scans and cross reference files. This method makes it difficult to maintain all sources of data and ensure that they are current. Change Man provides a comprehensive facility to capture, query, and enforce relationships between components.
These relationships include not only the traditional ones, such as a source and executable relationship, but also other relationships based on common
references to copybooks, SQL Include components, CA-PANVALET ++INCLUDE components, CA-LIBRARIAN - INC components, called
subroutines, and JCL fields such as program name, filename, or data set name.
Staging
Staging is the process of introducing newly developed or previously
developed components into the Change Man change cycle for modification or enhancement, and packaging with related change package components. When you stage a component, Change Man recognizes the type of component that you are staging and copies it into a staging library of corresponding type (source, load, JCL, documentation, copybook, etc.). Staged components are also associated with a pre-defined change package, the vehicle Change Man uses to move components through the change cycle and track the history of change management activities for each staged component.
Change Man staging libraries, however, are more than pre-production holding libraries. Components can be modified and tested within protected Change Man staging libraries. Moreover, when you stage source components, they are compiled and the resulting load modules are identified, helping you to maintain the integrity of source-to-load relationships.
In addition, Change Man maintains up-to-date records of all staging activities for packages and components. For example, when you stage a source
component, Change Man records the time that the component was staged, the name of any associated load modules, or copybooks, and the compiling procedures and linkage parameters used during the compile. This information is kept in Change Man’s master file, the package master. You can view this component and package information any time by using the query function within staging.
Change Man further extends the concept of staging by providing a means of isolating components from other changes in progress. This prevents
uncontrolled and unknown copybooks and subroutines from being inadvertently referenced, allowing parallel or concurrent development without the risk of accidental overlays. The stable coexistence of multiple versions of a single component simplifies the blending of changes.
Audit
The Change Man audit process enables you to ensure correct synchronization of components and procedures. Because of the range of features offered by the package master and the impact analysis database, Change Man maintains control of current and past modifications and component versions. Therefore, potential production problems can be identified before they impact
production.
The audit function inspects the staging library contents of an evolving change package (in the DEV/FRZ status) with respect to baseline library contents. The inspection looks for situations such as a package that shows no change from the baseline library, or a package that contains a LOD component that does not match its SRC component. Recognizing these situations, called
out-of-synch components, are part of Change Man’s ability to help you detect code
that is inconsistent with your development procedure and other code problems. Examples of out-of-synch situations that the Change Man audit addresses include:
• Copybooks that have been changed after a source program has been compiled
Change Man Library Environment
• Called subroutines that have been changed after a referencing source program has been compiled and linked
With Change Man you can enforce by application whether you want an audit, and if so, whether you want to correct or leave potential uncovered problems.
Recompile and Relink
You can use audit to analyze the staging library contents of an evolving change package, with respect to baseline contents, for the purpose of finding any out-of-synch situations. The recompile function is used to resolve certain types of out-of-synch conditions found during the audit. The allowable audit return code is determined during global and application parameter
generation, and you are not allowed to freeze the change package without passing the audit return value entered for the application.
Using the relink option you can:
• Relink load components without associating them with source code • Delete previously relinked components
The relink process is similar to compile since you select a component from a baseline list. A new load component is produced and copied into the
package's staging library.
Use the delete function to remove recompiled or relinked components that do not have associated source in the package. You can also delete the resulting LST file and any other non-load components that have been associated with it through the CMNBAT90 service. (See your administrator for details on this service.)
A component’s history is picked up from the history record for that
component in the package master. For example, the relink picks up the user options on CMNUSR01 that were there when the program was last compiled. When relinking you can include LCT cards that contain the link control cards from staging or baseline libraries, or you can dynamically generate them if there is no component available. You do this if you:
• Do not have source code for a component, but make a change to a subroutine
Freeze
Another unique Change Man feature is the ability to freeze change packages. When the change package is ready for the next phase of the change
implementation life cycle, a freeze is performed to prevent further
modifications. The freeze also positions the change package for promotion or approval. Traditional methods accomplish this function by moving
components from the development libraries to a separate set of libraries or, in some cases, separate environments. With Change Man, however, the started task controls your updates in conjunction with your security system, so component movement is no longer necessary.
If further modifications are required, you can unfreeze a change package, and the approval process is reset.
Promotion
Change Man has the ability to promote change packages through multiple shared, pseudo-production promotion environments. These promotion environments are secured as if they are production, and Change Man controls all updates.
Change Man considers shared promotion environments a place where full integrated system testing may be performed. When the time comes for a full system or an integrated system test, authorized approvers promote the acceptable components into the promotion environments.
When testing is complete and the change package is approved, Change Man (optionally) removes the components from the promotion environments. All production installation occurs from the change package staging environment. With Change Man, you define your testing methodology and the number of testing levels that are required.
Approve
Approvals for change package installation are performed online, eliminating the requirement for manual approval processes. During the Change Man approval process, authorized approvers can indicate that the change package is acceptable for production implementation, or they have the option to reject or review the change and generate a checklist of questionable or unclear items for the programmer to resolve.
Change Man relies on your security system. Change Man does not use internal personnel tables. Approval lists of specific USERIDs or approving entities are defined to your security system so that electronic signatures can be
Baseline Libraries and Delta Decks
For each application, a variety approvers can be included on the approver list. Separate approval lists can be created for scheduled, planned changes and for unplanned, emergency changes, or you can choose to use an approval
hierarchy. With Change Man, you have the flexibility to make these choices.
Production Installation
Change Man is actively involved in the management and control of actual production component installation. Component installation can be automated through Change Man’s internal scheduling system or through Change Man’s direct interface with a job scheduling system. In addition to component movement, Change Man performs other production installation activities such as DB2 Plan binding.
Change Man also has a unique change quantity threshold facility that allows you to control the number of changes that occur within a given time period. For example, you may want to limit the number of change packages that are installed during month-end processing.
B
ASELINE
L
IBRARIES
AND
D
ELTA
D
ECKS
Change Man recognizes that your software components are vitally important business asset. Change Man gives you the ability to store your production source components in a structure that works for your organization.
Components can be stored in PDSs, CA-LIBRARIAN files or CA-PANVALET files. Components can be segregated by application or by categories, such as batch versus online. Equally, applications can share libraries.
Change Man automatically stores prior versions of components. These versions can be stored as full copies (inherent for load components), or as delta
decks. Change Man uses a unique reverse base/delta technique known as stacked reverse deltas. With this technique, the current version of the component
is the base, and delta decks are created to backtrack to previous versions.
B
ACKOUT
M
ANAGEMENT
F
ACILITIES
Comprehensive backout management requires more than simply backing up the components of a change. In addition to backing up the source, it is
Change Man has comprehensive backout management facilities. In addition to source components, the prior functioning executable components can be automatically backed up. If a backout becomes necessary, Change Man automatically restores these executable components to production. Change Man also performs all necessary DB2 Plan rebinding automatically.
Because Change Man is package driven, it backs out all the components of a change automatically.
E
MERGENCY
C
HANGES
Critical abends occur at inopportune times and require immediate attention. Because Change Man contains the ability to create Unplanned Change Packages, and the ability to maintain a separate list of approvers for unplanned changes, emergency changes are safe, fast and easy to perform. Additionally, because of the facility (optional) to concurrently check out components. Change Man provides notification to any developer affected by the change so that the emergency fix can be incorporated globally into all change packages.
Change Man does not impede the emergency change process by requiring that the component be released, reassigned, or renamed by the original owner.
S
TORAGE
N
AME
C
ONSIDERATIONS
Panvalet has a ten-character allowance which Change Man does not recognize, because it looks for eight character names. References in this manual assume PDS naming is the convention.
A
CCESSING
C
HANGE
M
AN
AND
N
AVIGATING
P
ANELS
3
Change Man runs as a started task in the MVS subsystem and utilizes cross-memory services for accessing ISPF. The started task architecture provides a single point of control and secure access to your production and development libraries. Interfacing to your security system for access, Change Man provides the optimum amount of control without sacrificing performance.
The Primary Options Menu is the first panel the user sees when they sign onto the system. From this panel the user can select whichever function they require. The Primary Option Menu contains some of the Change Package Life Cycle processes like Freeze, Promote and Approve. The remainder of the Life Cycle processes can be found in the Build Options panel. The Build Options panel is accessed from the Primary Option Menu.
A
CCESSING
THE
P
RIMARY
O
PTION
M
ENU
Accessing Change Man is accomplished by selecting Change Man from your initial ISPF menu or executing the designated CLIST that initiates the started task. During the sign-on initiation a temporary Change Man title panel appears. Once the sign-on initiation is complete, the Primary Option Menu appears.
The Primary Option Menu displays options built upon the authorization of your User ID and your site configuration. After verifying with your host security system which Change Man functions that you can access, Change Man builds the menu. If you are licensed for Online Forms Manager (OFM) or Concurrent Development Facility (CDF), those options will appear on the Primary Option menu. The security administrator as well as the global and application administrators can provide information about user and site security configurations.
From the Primary Option Menu, you can access Change Man services and functions by using the panel-by-panel access method, the direct access method, or package list method.
The Primary Option Menu and the Build Options menu are the main navigational panels in the Change Man system. Their primary function enables the user to access all the Change Man functions.
CMN@PRIM --- CHANGE MAN 4.1.68 PRIMARY OPTION MENU ---INIT Complete OPTION ===> 1 Build - Create, update and review package data 2 Freeze - Freeze or unfreeze a package 3 Promote - Promote or demote a package 4 Approve - Approve or reject a package 5 List - Display (to process) package list A Admin - Perform administrative functions C CDF - Concurrent Development Facility D Delete - Delete or undelete a package L Log - Browse the activity log N Notify - Browse the Global Notification File O OFMlist - Online Forms package list Q Query - Query packages, components and relationships R Revert - Revert a package to DEV status T Tutorial - Display information about Change Man X Exit - Exit Change Man Press ENTER to process; enter END command to exit.
Accessing the Build Options Menu
A
CCESSING
THE
B
UILD
O
PTIONS
M
ENU
The Build Options panel allows the user to navigate throughout many of the Change Package Life Cycle processes and many other additional functions. The Build Options panel can also be displayed at the completion of the package create process. It will be displayed with the Change Package ID in the upper right-hand corner after a successful creation of a Change Package.
N
AVIGATING
T
HROUGH
C
HANGE
M
AN
P
ANELS
Panel By Panel Navigation
In the Option field of a menu, type the number or letter that designates a specific function and press Enter. For example, from the Primary Option Menu, you type 1 and press Enter to display the Build Options menu.
CMNBUILD --- BUILD OPTIONS OPTION ===> 0 Dates - Display the installation calendar 1 Create - Create a new package 2 Update - Update package information 3 Custom - Create, update, approve or review custom forms 4 Utility - Rename and Scratch information 5 Checkout - Check out components from baseline or promotion 6 Stage - Stage, edit, browse and delete components 7 Audit - Audit a package 8 Recompile - Recompile source code from baseline or promotion 9 Relink - Relink load modules B Browse - Browse\print\copy baseline or promotion C Compare - Compare staging to baseline or promotion L Listing - Browse compressed listings S Scan - Scan baseline for character strings Z Compress - Compress change package Staging Libraries Press ENTER to process; Enter END command to exit.
Use panel by panel navigation as you learn Change Man. When you become more familiar with the product, you can use the direct access method for navigation.
Using Direct Access Navigation
In the Option or Command field, type a sequence of numbers or letters with a plus sign or an equal sign preceding the string and place a period between each command. For example, in the Option or Command field, you type:
+1.2
or
=1.2
where 1 and 2 are single character options on successive panels. Change Man displays the panel of the last character in the direct access stacked commands. To return to a previous menu or panel, type END in the Option or Command
field on any panel or press the appropriate PF key command.
Using Package List Option
Almost all functions within Change Man are available to every package through the List
Option (option 5 in the Primary Option Menu). Once the users become more familiar with the product, will usually switch to the Package List option. This method of panel navigation is very fast as the user can do all their work from the Package List panel.
W
ORKING
WITH
L
ISTS
OF
L
IBRARIES
, P
ACKAGES
AND
C
OMPONENTS
There are lists in Change Man that let you view contents of libraries, packages and components.
Using Commands
Following are a set of standard commands used to work with these types of lists. To use them, type the command letter and a component or package name in the panel. Press ENTER to execute the command.
Working with Lists of Libraries, Packages and Components
• B to browse
• S to select an item for action. • H to display history for an item.
Type the following commands on the Command line: • REFRESH to Update the list.
• CANCEL to Cancel the request.
• SORT to Sort the list. (Only valid for member and procedure/language displays)
• L to locate an item in the list. For example, L xxxxxxxxx where xxxxxxxx is the component name.
After executing one of these commands, a message normally appears in the status column to indicate your action (such as BROWSE for a browsed list item).
Not all commands are available from all lists. If you type an incorrect command or character in a panel, Change Man displays the correct available commands from that panel.
Using Patterns
The system often encourages you to input a pattern to get a range of values in a list from Change Man. Pattern rules are:
* A ‘*’ at the end of a character string is a wildcard for any number of characters. It must be used at the end of a string.
* A ‘?’ can replace any single character in a string.
Using Lists
When using lists within Change Man, there are many options for masking the list you display so that you can work with only a portion of the total list. The following table contains some examples of the masking options and their results.
When masking, the package name must be at least four characters. For example, if the package name is DAM, and you typed D*M, to display all DAM packages for application that begin with D and end with M, you will receive a message indicating a package error.
If there is an “*” in the number part of the package ID, there are no zeroes filled in before the number; e.g., A*10* is resolved to Aaaa10nnnn, not 00010n. However, if an “*” is not found in the number area, there is zero fill; e.g., A*10 is resolved to Aaaa000010). Also, remember that if the application is only three characters, there
will be a blank before the package number.
Often when using Change Man, you are asked to complete a list or table of items. There are standard ways to insert, repeat, and delete lines of
information from these lists.
Each of the following tasks assumes that you have already accessed the required panel to build a list. Refer to the individual panels for information about saving your changes to the list or for functions that are unique to that list.
Masking (or Pattern) Description
* or * * all packages for all applications
A* all packages for all applications that start with A
A*B all packages for all applications that start with A and end with B
*A all packages for all applications ending with A
* 1 all packages in all applications that begin with 1
ABCD1* all packages whose number starts with 1 in application ABCD (e.g., ABCD100000 to ABCD199999)
ABCD*1 all packages ending in 1 in application ABCD
ABCD10* all packages whose number starts with 10 in application ABCD (e.g., ABCD100000 to ABCD109999)
Working with Lists of Libraries, Packages and Components
Using a Selection List
Change Man has many types of panels, one of which is a selection list. A selection list is a panel that has a list from which you can select one or more items. You often access a selection list from a main panel field to help you identify available items, such as a list of all possible library types. There are several options you have for displaying a selection list.
To select or deselect items from a list, take the following steps:
1 Move the cursor to the line command (LCMD) column of a desired row in the list, type S, and press Enter to select the desired row. If there is a status column *SELECT appears to indicate the selection.
2 You can type D and press Enter to deselect a desired row. If there is a STATUS column, *DESEL displays to indicate the deselection. 3 Type End and press Enter (or PF3) when you are finished.
The original panel from which you accessed the selection list displays. The selections or deselections in the list are shown in the panel field from which you accessed the selection list.
CMNSTG08 --- LIBRARY TYPE SELECTION LIST ---ROW 1 TO 14 OF 14 COMMAND ===> SCROLL ===> PAGE LIB DESCRIPTION _ CLI CLIST -User Customized CLISTs _ CPY Copybooks _ CP1 Like-CPY (1) _ CTC Control Cards s JCL Job Control Language _ LCI LOADCICS-CICS Load Library _ LCT Linkedit Control Cards _ LDG LOADDLG -ISPF Dialog Load Library _ LD1 Like-LOD (1) _ LOD Load Modules _ OTH OTHER library type _ SKL ISPF Skeletons _ SRC Source Code _ VLD Load Modules ***************************** Bottom of data ******************************
Scrolling Through Lists
Often, lists that you build or access through Change Man are too long to view on the screen. Use the UP and DOWN keys (normally PF7 and PF8 keys, respectively) on your keyboard to scroll up and down through the lists. To move forward or backward a specific number of lines, type a number and use the PF7 key to go forward that number of lines, or the PF8 key to go backward that number of lines.
Using the combination of a command character and a PF key, you can also immediately move the maximum number of lines to the top or bottom of a panel or dataset/member. By typing M on the command line and using the
PF7key, you move backward (toward the top of the data). Alternatively, you can use M +PF8 to move forward (toward the bottom of the data).
U
SING
B
ASIC
E
DIT
L
INE
C
OMMANDS
Inserting a Line
1 Move the cursor to the first column or the LCMD column of the last row in the list.
2 Type Iand press Enter to Insert a new row. Change Man inserts a new row.
3 Provide the information required for each column of that row.
Repeating a Line
1 Move the cursor to the first column, the LCMD column, of the row that you want to repeat in the list.
2 Type R and press Enter to Repeat a new row.
Change Man copies the row and inserts it at the end of the list. 3 Move the cursor to the newly repeated row.
4 Provide the information required for each column of that row. See the individual sections of this manual for each panel for a table that describes each column of the list (since these lists differ depending on what
