mks implementer user guide - qas400-index implementer user... · mks implementer user guide the...

IMPLEMENTER

User Guide

w w w . m k s . c o m

MKS ImplementerUser Guide

The information in this manual is subject to change without notice.

Copyright © 1988-2002 MKS Inc. and Mortice Kern Systems International SRL. All rights reserved.

MKS Inc. and Mortice Kern Systems International SRL (collectively “MKS”) make no warranty of any kind with regard to this material, including, but not limited to the implied warranties of merchant ability, performance, or fitness for a particular purpose. MKS shall not be liable for errors contained herein, or for any direct, incidental, or consequential damages resulting from the use of this material.

All rights reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in any form by any means, without written permission from MKS.

All MKS products are trademarks or registered trademarks of MKS Inc. All rights reserved. All other trademarks or registered trademarks are the property of their respective holders.

CORPORATE HEADQUARTERS WORLDWIDE OFFICES:410 Albert StreetWaterloo, ON N2L 3V3Canada

tel: 519 884 2251fax: 519 884 8861sales: 800 265 2797

www.mks.com

2500 S. Highland AvenueSuite 200Lombard, IL USA60148tel: 630 495 2108fax: 630 495 3591sales: 800 633 1235

15 Third AvenueBurlington, MA USA01803tel: 781 359 3300fax: 781 359 3399

12450 Fair Lakes CircleSuite 400Fairfax, VA USA22033tel: 703 803 3343fax: 703 803 3344sales: 800 265 2797

Martinstraße 42-4473728 EsslingenGermanytel: +49 711 351775 0fax: +49 711 351775 11

Third Floor, Duke’s CourtDuke Street, WokingSurreyGU21 5BHUnited Kingdomtel: +44 (0)1483 733900fax: +44 (0)1483 733901sales: +44 (0)1483 733919

SIU5.3-020331

Table of Contents

Chapters 1 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Who Should Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2What to Know Before Using This Product . . . . . . . . . . . . . . . . . . . . . . 2What’s Inside This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8MKS Issue Tracking Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Using DesignTracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Using Integrity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Using Integrity Manager and DesignTracker . . . . . . . . . . . . . . . 10Issue Database Considerations and Assumptions . . . . . . . . . . . 11

Starting Implementer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Menu Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Overview of Implementer Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Integration With Integrity Manager . . . . . . . . . . . . . . . . . . . . . . . 15The Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Technology-based Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Change Control Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Developer Productivity Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Distribution Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Test Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Inquiries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Release Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Third-Party Vendor Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 28Additional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

What’s New in This Release? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Documentation Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Integrity Manager Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Technology-based Enhancements . . . . . . . . . . . . . . . . . . . . . . . . 32User Interface Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Vendor Integration Enhancements . . . . . . . . . . . . . . . . . . . . . . . 36

User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38System Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

i

Table of Contents

Project Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Understanding Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Environment Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Object Owners and Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . 42Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Library List Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Defaults for Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . 44Remote Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Environment Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Object Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Environment Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Environment Integrity Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Application Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3 Using the Workbench for Development Activities . . . . . 49Understanding the Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Using the Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Identifying Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Reviewing Work Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Changing Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Promoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Time Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Managing Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Workbench Ease of Use Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Optional Check Out and Promotion Methods . . . . . . . . . . . . . . 55Member/Object Status and History . . . . . . . . . . . . . . . . . . . . . . . 55Alternate Views and Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Multiple Selection Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Automatic Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Concurrent Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Work With Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Command Prompting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Using the Clipboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Basic Clipboard Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Using Command Options to Add Clipboard Items . . . . . . . . . . 60Using the ICRTRQS Command to Promote Clipboard Items . 63

u s e r g u i d eii

Table of Contents

Using the IPRCCBD Command to Process the Clipboard . . . . 63Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Check Out Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Checking Out From Work With Objects . . . . . . . . . . . . . . . . . . . 67Checking Out Using the Clipboard . . . . . . . . . . . . . . . . . . . . . . . 69Performing Emergency Check Out . . . . . . . . . . . . . . . . . . . . . . . 69Checking Out for Concurrent Development . . . . . . . . . . . . . . . 69Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Editing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Using PDM User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Setting Up User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . . 72Changing User Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Displaying PDM User-Defined Options . . . . . . . . . . . . . . . . . . . 77Processing PDM User-Defined Options . . . . . . . . . . . . . . . . . . . 77

Workbench Compiles of Locked Objects . . . . . . . . . . . . . . . . . . . . . . 79Identifying the Compile Object . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Workbench Testing of Locked Objects . . . . . . . . . . . . . . . . . . . . . . . . 83Setting a Library List From an Environment Library List . . . . 83Available PDM Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Displaying Related Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Promotion Request Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Promotion Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Creating Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Task Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Compiling and Moving Promotion Requests . . . . . . . . . . . . . . . . . . . 89Member/Object Status and History . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Online Inquiry of Development Activity . . . . . . . . . . . . . . . . . . . . . . 95Working With Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Changing a Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Deleting a Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Associating Multiple Design Requests With a Lock . . . . . . . . . 99

Changing a Design Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Repeating Workbench Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4 Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Creating Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Creating Projects From Implementer . . . . . . . . . . . . . . . . . . . . . 104Creating Projects From ProjectMaster . . . . . . . . . . . . . . . . . . . . 106Setting Up a Default Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Project Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Project Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Project Management Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Time Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Advanced Scheduling Features . . . . . . . . . . . . . . . . . . . . . . . . . 109Reporting Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

iii

Table of Contents

5 Performing Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Check Out Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Check Out Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Using the One Step Checkout Method . . . . . . . . . . . . . . . . . . . 113Using the Traditional Checkout Method . . . . . . . . . . . . . . . . . . 115Task Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Checking Out Single Source With Multiple Objects . . . . . . . . 123Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Using Object Version Stamping in Check Out . . . . . . . . . . . . . . . . . 125Processing Versions in Check Out . . . . . . . . . . . . . . . . . . . . . . . 125

Checking Out IFS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . 127IFS Object Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . 127Checking Out Using the IFS Object Name . . . . . . . . . . . . . . . . 128Checking Out the Contents of an Environment . . . . . . . . . . . . 129Check Out IFS (ICHKOUTIFS) Command . . . . . . . . . . . . . . . . 130Automatically Creating Object Codes in Check Out . . . . . . . . 134Support for Multi-Platform Check Out . . . . . . . . . . . . . . . . . . . 135

Checking Out for Concurrent Development . . . . . . . . . . . . . . . . . . 136Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Checking Out Related Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Task Variation for Multiple Recurring Members/Objects . . . 140Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Checking Out With a Design Request . . . . . . . . . . . . . . . . . . . . . . . . 141Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Using ILE Object Codes in Check Out . . . . . . . . . . . . . . . . . . . . . . . . 148Binding Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Bound Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149ILE SQL Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Service Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Update Service Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149ILE Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Update ILE Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Checking Out Physical File Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Using Different Source and Object Names in Check Out . . . . . . . . 151User Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Typical User Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152LANSA Export/Import Authorities . . . . . . . . . . . . . . . . . . . . . 152

Checking Out for Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Removing Source and Objects From QA . . . . . . . . . . . . . . . . . . 153Task Variation for Rejecting From the Menu . . . . . . . . . . . . . . 154Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Object Name Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Performing Name Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Check Out (ICHKOUT) Command . . . . . . . . . . . . . . . . . . . . . . . . . . 156

u s e r g u i d eiv

Table of Contents

Check Out Command Variations . . . . . . . . . . . . . . . . . . . . . . . . 162Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Converting RPG/400 or RPGIII Source Code to ILE RPG/400 . . . 163Converting CRTBNDxxx ILE Programs to CRTPGM Programs . . 165Checking Out Using PathFinder Information . . . . . . . . . . . . . . . . . 167

Environment and Library Setup . . . . . . . . . . . . . . . . . . . . . . . . . 167Performing the Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

6 Performing Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . 171Promotion Request Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Promotion Request Numbering . . . . . . . . . . . . . . . . . . . . . . . . . 173Creating Promotion Requests in Batch . . . . . . . . . . . . . . . . . . . 173Default Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Promotion Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Create Request Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Creating Requests With the One Step Promotion Method . . . . . . . 175Resolving Promotion Request Problems . . . . . . . . . . . . . . . . . . 177

Creating Requests With the Traditional Promotion Method . . . . . 177Optimizing Physical File Promotions . . . . . . . . . . . . . . . . . . . . 183Overriding Job Submission Defaults . . . . . . . . . . . . . . . . . . . . . 186Changing Job Queues During the Compile Step . . . . . . . . . . . 187Changing Compile Commands . . . . . . . . . . . . . . . . . . . . . . . . . 187Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Creating Requests by Selecting From Locks . . . . . . . . . . . . . . . . . . . 189Benefits of Selecting From Locks . . . . . . . . . . . . . . . . . . . . . . . . 190Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Creating Requests From the Object List . . . . . . . . . . . . . . . . . . . . . . 192Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Creating Requests From the Member List . . . . . . . . . . . . . . . . . . . . . 193Task Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Creating a Request by Copying a Request . . . . . . . . . . . . . . . . . . . . 195Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Creating Requests With the ICRTRQS Command . . . . . . . . . . . . . . 196Creating Requests With the ICRTRQS Command PDM Option . . 198

Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Selecting Additional Target Environments . . . . . . . . . . . . . . . . . . . . 199

Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Promoting Related Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Related Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Overriding Create Request Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 205

Removing Objects and Source in Promotion . . . . . . . . . . . . . . 205Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Changing Request Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

v

Table of Contents

Maintaining Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211Promoting IFS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . 212

Support for Browser-based Promotions . . . . . . . . . . . . . . . . . . 213Options for Promoting IFS Objects . . . . . . . . . . . . . . . . . . . . . . 213Considerations When Using *.* for Promotion . . . . . . . . . . . . 214Automatically Creating Object Codes in Create Request . . . . 215Upgrading a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Java Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Promoting Physical File Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Using Different Source and Object Names in Promotion . . . . . . . . 219Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Staged Compiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Compile Library List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Third-Party Compile Procedures . . . . . . . . . . . . . . . . . . . . . . . . 223Job Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Compile Request (ICMPRQS) Command Option . . . . . . . . . . . . . . 224Moving Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Allocating Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Authorities and Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Source Member Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 225Issuing Move Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Move Request (IMOVRQS) Command Option . . . . . . . . . . . . 228

Special Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Special Command Substitution Variables . . . . . . . . . . . . . . . . . 233Special Commands in Promotion: IEXCRQSDTL Command 236Special Commands to Manage DDM . . . . . . . . . . . . . . . . . . . . . 240Special Commands to Change Promotion Status . . . . . . . . . . 245Special Commands in Check Out . . . . . . . . . . . . . . . . . . . . . . . . 245Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Managing Concurrent Development . . . . . . . . . . . . . . . . . . . . . . . . . 248Resolving a Conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251Object Version Stamping in Promotion . . . . . . . . . . . . . . . . . . . 251Emergency Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252Problem Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Completing Failed Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . 254Other Creation Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Using ILE Object Codes in Promotion . . . . . . . . . . . . . . . . . . . . 256Batch Promotion Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Distributing Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . 256

Scheduling Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

u s e r g u i d evi

Table of Contents

Promotion Request Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Promotion Step Internal Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Create Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Export Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Compile Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Distribution Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Move Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Work Libraries Used During Promotion . . . . . . . . . . . . . . . . . . 265Host Work Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Remote Work Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

7 Performing Distributions . . . . . . . . . . . . . . . . . . . . . . . . . 271Moving and Distributing Promotion Requests by System . . . . . . . 272

Moving/Distributing All Promotion Requests By System . . . 272Submitting Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Moving/Distributing to a Specific System . . . . . . . . . . . . . . . . 275Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277Move/Distribute by System Submission Options . . . . . . . . . . 277

Displaying Move Requests by System/Environment . . . . . . . . . . . 278Filtering Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Controlling Remote Job Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Using the Default Job Schedule . . . . . . . . . . . . . . . . . . . . . . . . . 280Overriding the Default Job Schedule . . . . . . . . . . . . . . . . . . . . . 281Remote Job Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281Changing Remote Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284Moving Remote Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Using the Implementer Receiver Menu . . . . . . . . . . . . . . . . . . . . . . . 287Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Working With Requests on the Remote System . . . . . . . . . . . . 288Restoring Remote Requests (IRSTRMTRQS) . . . . . . . . . . . . . . 289Moving Remote Requests (IMOVRMTRQS) . . . . . . . . . . . . . . 290

Working With Function Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

8 Handling Emergency Situations . . . . . . . . . . . . . . . . . . . 295Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Archiving Source and Objects on a Promotion Request . . . . . 296Using the Archive to Tape Features . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297Working With Tape Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . 297Archive Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Archive Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Recovering Archived Source/Object by Request . . . . . . . . . . 300Common questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Automatic Check Out Archive Options . . . . . . . . . . . . . . . . . . 302

vii

Table of Contents

Emergency Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Emergency Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

9 Member and Object Handling . . . . . . . . . . . . . . . . . . . . . 307Compile Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

Managing Non-Source-based SQL . . . . . . . . . . . . . . . . . . . . . . . 309Managing Source-based SQL (DDL) . . . . . . . . . . . . . . . . . . . . . 311Managing Traditional DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Special Object Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318Data Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318Data Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319Commands and Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

Managing ILE Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319Support for Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Support for Service Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . 321Loading ILE Objects Into the Repository . . . . . . . . . . . . . . . . . 322Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

S/36 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325S/38 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325Extended Object Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

10 Integrating With Other Vendor Products . . . . . . . . . . . . 327Application and CASE Software Products . . . . . . . . . . . . . . . . . . . . 328American Software Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Object Codes for Check Out and Promotion . . . . . . . . . . . . . . 329Compiling Cobol Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330Message File Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

AS/SET Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330Checking Out AS/SET Definitions . . . . . . . . . . . . . . . . . . . . . . 331AS/SET Dependency Checking . . . . . . . . . . . . . . . . . . . . . . . . . 332Promoting AS/SET Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 334Archiving AS/SET Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 335Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

BPCS Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336CODE/400 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Creating the User-Defined Options . . . . . . . . . . . . . . . . . . . . . . 337Launching CODE/400 from Implementer . . . . . . . . . . . . . . . . 338

COOL:Xtras Change Management Integration . . . . . . . . . . . . . . . . 338Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339Development Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345Member/Object Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345SQL Support for COOL:2E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

u s e r g u i d eviii

Table of Contents

Check Out Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346Working With Model Object Lists . . . . . . . . . . . . . . . . . . . . . . . 347Checking Out Model Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Concurrent Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349Checking Out Versionable Model Objects . . . . . . . . . . . . . . . . 349User Exit Program Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350Promoting Model Information . . . . . . . . . . . . . . . . . . . . . . . . . . 351Promotion Flow: COOL:2E to COOL:2E Environment . . . . . . 351Promotion Flow: COOL:2E to Traditional Environment . . . . 354Working in a Change-Controlled Model . . . . . . . . . . . . . . . . . . 356Model Object Audit Information . . . . . . . . . . . . . . . . . . . . . . . . 357Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359Managing EXCUSRSRC and EXCUSRPGM . . . . . . . . . . . . . . . 359Merging Model Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Remote Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

J.D. Edwards Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Starting the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Support for J.D. Edwards Traditional Objects . . . . . . . . . . . . . 364Support for J.D. Edwards DREAM Writer Versions . . . . . . . . 364Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Displaying J.D. Edwards Items . . . . . . . . . . . . . . . . . . . . . . . . . . 365Compiling From the Workbench . . . . . . . . . . . . . . . . . . . . . . . . 365Promoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366Archiving J.D. Edwards Special Objects . . . . . . . . . . . . . . . . . . 366

LANSA Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Promoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369Displaying Process/Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 370Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370Save File Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371LANSA Export/Import Authorities . . . . . . . . . . . . . . . . . . . . . 372LANSA RDML Function Compare . . . . . . . . . . . . . . . . . . . . . . 372Understanding the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

Lotus Notes and Domino Integration . . . . . . . . . . . . . . . . . . . . . . . . 376Powerhouse Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376Utility Software Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377ABSTRACT Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

Version Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Abstract User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . . . 378Accessing ABSTRACT From Implementer . . . . . . . . . . . . . . . . 380

AOS Message Manager Integration . . . . . . . . . . . . . . . . . . . . . . . . . 380AS/NET Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381MIMIX Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

ix

Table of Contents

NetView/DM Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381Net/Wrk400 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381PathFinder Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

PathFinder Database Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 382PathFinder User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . 382PathFinder PDM Options for USERPATH . . . . . . . . . . . . . . . . 383PathFinder PDM Options for USERPDM . . . . . . . . . . . . . . . . . 383

ROBOT Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

Appendixes A Compare/Merge Member Commands . . . . . . . . . . . . . . 385Compare Member (ICMPMBR) Command . . . . . . . . . . . . . . . . . . . 386Compare Member Report Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392LANSA Compare RDML (ICMPRDML) Command . . . . . . . . . . . . 394

LANSA Compare Members Report . . . . . . . . . . . . . . . . . . . . . . 396Merge Member (IMRGMBR) Command . . . . . . . . . . . . . . . . . . . . . . 398Merge Member Merge Report Listing . . . . . . . . . . . . . . . . . . . . . . . . 408

B Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

u s e r g u i d ex

1Before You Begin

Implementer is the leading change management solution for the iSeries 400 available on the market today. It provides developers and IT managers with a feature-rich and easy to use environment that expedites development by managing and streamlining critical development processes.

This chapter covers:

� who should read this guide

� what to know before using this product

� what’s inside this guide

� document conventions

� getting help

1

Before You Begin

Who Should Read This GuideThis guide is intended for Implementer users who play the following roles in software development projects:

� Project leaders responsible for creating projects, managing concurrent development, moving and deploying promotion requests, and updating the system administrator about required system-wide changes.

� Developers responsible for checking out members/objects from production libraries into development environments, creating promotion requests targeted to test or production environments, and submitting promotion requests for compiling into staging libraries.

� Testers responsible for accepting promotion requests into test environments, testing changes, creating promotion requests to production or additional test environments, and submitting promotion requests for compiling into staging libraries.

NOTE

This guide is useful as a source of conceptual, user-related information. The Implementer System Administrator Guide provides the information that system administrators use on a daily basis.

What to Know Before Using This ProductThe instructions for using his product assume that you are familiar with the following:

� OS/400 operating system

� OS/400 security

� OS/400 communications

� Command line

� Software development policies and procedures for your organization

NOTE

Throughout this guide, any references to the IBM iSeries 400 apply also to the IBM AS/400.

u s e r g u i d e2

What’s Inside This Guide

What’s Inside This GuideThis guide contains comprehensive information about using all features that pertain to the setup and maintenance of Implementer. The guide is organized as follows:

Chapter Description

Chapter 1: Before You Begin

Introduces you to MKS Implementer. Describes who should read this guide and how to use it, and options for getting help.

Chapter 2: Getting Started

Explains where to find product installation information. Overviews the important features of Implementer, including what’s new in this release. Describes the various user roles.

Chapter 3: Using the Workbench for Development Activities

Explains the versatile features of the Workbench. Describes how to access important Implementer features while using the Workbench as a home base for your work. Identifies where to look in this guide to find detailed information about each activity.

Chapter 4: Projects Explains how to use the Implementer to interface with MKS ProjectMaster, and perform common project management related activities.

Chapter 5: Performing Check Out

Explains the two checkout methods, and how to check out members/objects. Describes the various check out related options.

Chapter 6: Performing Promotions

Explains the two promotion methods. Describes how to promote member/objects from development to QA, and from QA to production. Describes the various promotion-related options.

Chapter 7: Performing Distributions

Explains how to distribute members/objects to remote systems using the Implementer Receiver.

Chapter 8: Handling Emergency Situations

Explains how to archive and roll back to prior member/object versions. Describes how to perform emergency check out and emergency create request functions.

3

Before You Begin

Document ConventionsThroughout this guide, the following typographical conventions are used.

NOTE

Notes containing important information are bordered by lines on the top and bottom.

Chapter 9: Member and Object Handling

Explains how Implementer supports the different OS/400 types of objects and source members.

Chapter 10: Integrating With Other Vendor Products

Discusses the Implementer support for other vendor software products. Explains actions you must take to ensure maximum integration. This chapter is divided into two sections to reflect the type of software products supported, Application and CASE products, and Utility products.

Appendix A: Compare/Merge Member Commands

Explains how to use the Compare Member (ICMPMBR) and Merge Member (IMRGMBR) commands to simplify and automate the process of comparing and integrating programming modifications, during the development process.

Appendix B: Glossary Defines the terminology that relates to Implementer.

Chapter Description

Items in documentation Appear as

References to other manuals, new terms, and variables

italics

Keys you press, programs, files, directory names, and drive letters

ENTER

Code-based information, such as system messages, field syntax, macros, and commands, and information you type on menus and panels

ADDLIBLE

PC menus, commands New > Problem

PC drop-down menus the Session command

PC Dialog boxes, features Edit Options, Cancel, OK

Path names c:\mks\demo

u s e r g u i d e4

Getting Help

Getting HelpMKS Customer Support is ready to assist you with product solutions. For assistance, you can choose the online system or telephone a Customer Support Representative.

For online support, browse to www.mks.com and follow the links to the Support area. There you will find Frequently Asked Questions (FAQs), information about current releases, solution downloads, and Knowledge Base articles that can help you to quickly find the answers you need.

The hours of operation for MKS Customer Support are as follows:

� North America: 8:00 A.M. to 8:00 P.M., Monday to Friday, Eastern Standard Time (GMT-5)

� United Kingdom: 9:00 A.M. to 5:30 P.M., Monday to Friday, British Standard Time (GMT)

� Germany: 9:00 A.M. to 5:30 P.M., Monday to Friday, West Europe Standard Time (GMT+1)

Online Web www.mks.com

E-mail [email protected]

Telephone North America 800 633 6298630 652 9350519 884 2270

UK +44 (0) 1483 733910

Germany +49 711 351 775 51

Fax North America 630 495 4855

UK +44 (0) 1483 733901

Germany +49 711 351 775 11

5

http://www.mks.com

Before You Begin

u s e r g u i d e6

2Getting Started

This guide is for MIS professionals who implement change management or perform change management tasks. This chapter provides an overview of Implementer.


� system requirements

� issue tracking solutions

� starting Implementer

� overview of Implementer features

� what’s new in this release

� user roles

� understanding environments

7

Getting Started

System RequirementsThe minimum system requirement for this Implementer release is a RISC-based processor running OS/400 V4R4 or greater.

Additional requirements may apply for complete functionality of the MKS Integrity Solution multi-platform integration. For more information, see the Implementer Multi-Platform Solutions Guide.

MKS Issue Tracking Solutions MKS creates solutions that help you where it matters most—in the management of changes in all your critical files and in the promotion of workflow collaboration among people in your organization. Put simply, MKS has the right solution for your business. In fact, keeping up with the pace of technology does not have to be painful—on the contrary, MKS thinks that setting the pace is much more rewarding.

Using DesignTracker

DesignTracker, one of the MKS iSeries Solution products, is delivered with Implementer. DesignTracker resides on the iSeries 400 and provides native workstation-based problem management capabilities. It manages issues and workflow for data processing services (service requests) and software development projects (design requests) on the iSeries 400. When you install Implementer, DesignTracker is the default issue-tracking system.

Although a legacy issue-tracking system, DesignTracker serves to address the needs of less complex environments. However, even if you have a more complex environment it may also serve the needs of your organization, particularly if you have external green screen interfaces into DesignTracker, or if you use the release management features of Implementer. Likewise, if you have Implementer integrated with SupportCenter for help desk management, or ProjectMaster for project management (provides total integration of the MKS iSeries Solution).

Today, however, many organizations are realizing an increasing need to adapt to the rapidly changing realm of technology and to capitalize on solutions that address those evolving needs. For organizations with more sophisticated and complex environments, MKS provides two additional options for issue tracking and managing development workflow:

u s e r g u i d e8

MKS Issue Tracking Solutions

� The best of breed solution uses Integrity Manager (replacing DesignTracker) to provide Windows and browser-based issue management and integrates with Implementer for iSeries 400-change management.

� The alternate solution integrates Integrity Manager with DesignTracker and uses DTBridge (shipped with Implementer) to map updates between Integrity Manager and DesignTracker.

Both of these solutions are described next.

NOTE

Integrity Manager is a separately licensed component of the MKS Integrity Solution.

Using Integrity Manager

Integrity Manager is the best of breed enterprise choice for highly customizable process and workflow management. Any simple defect-tracking tool can record the status of a change request, but it does not monitor all the components that need to be modified, or the variety of tasks that need to be performed to resolve the issue. Integrity Manager extends the concept of defect tracking to include support for managing components, tasks, and workflow. This is particularly important when your organization has implemented a Software Configuration Management (SCM) process for the proposal, review, and approval of all software changes.

With this solution, Integrity Manager is the enterprise-wide issue management system that completely replaces DesignTracker. Integrity Manager integrates with other developer productivity tools—including Implementer, to control and track development activity in Implementer, and Microsoft Project, to leverage software investments and enhance coverage of the application development lifecycle.

Integrity Manager’s platform transparent, advanced, multi-tier architecture is scalable across the enterprise to support distributed developers and other constituents in the change process. Integrity Manager:

� helps your development team capture and track all data related to change in your software system

� allows you to set up a workflow to manage the change process

� allows you to create change packages to correlate issues with specific Implementer revisions

� provides metrics for your data including queries, reports, and charts

9

Getting Started

Integrity Manager is an extremely flexible issue management system that allows any number of user-defined issues, each identified by its type, and each type having its own user-defined set of fields; DesignTracker is more rigid with fixed type service requests and design requests that have various attributes.

Integrity Manager controls the activities of check out and promotion by an issues’ state, (whereas DesignTracker manages these activities by the status of a design request). Integrity Manager allows each issue type to have it’s own workflow of allowed state transitions. State based capabilities are assigned to the issue states to control the use of issues in check out and create request, and to allow Implementer to manage the check out and promotion functions.

The core of this integration allows Implementer to directly access Integrity Manager issues and update the issue state based on the development progress in Implementer. The issue ID associated with changing an item is tracked—along with the actual development change—in Implementer; the issue details and state are tracked in Integrity Manager.

Using Integrity Manager and DesignTracker

For organizations that require DesignTracker—for example, if you use Implementer’s release management feature or are using SupportCenter or ProjectMaster—but you also have a need for Windows-based issue tracking, this solution works well.

With this solution, DesignTracker is used to manage and track service requests and design requests on the iSeries 400.

Integrity Manager uses issues to track changes in the software development cycle. For example, your administrator can configure Integrity Manager in a way that a problem issue may be associated with a solution issue for easy tracking and monitoring of both issues. Each issue has an audit trail, which may be used to evaluate internal processes for the effectiveness of the problem resolution process. In effect, issues track all aspects of any engineering endeavor.

Issue types capture and track a specific change request, defect, problem, solution, or task. For example, one issue type could record bugs and deficiencies in design. Another issue type could be used to request design changes that fix problems, or propose enhancements or new functionality for your product.

DTBridge (provided in Implementer) allows you to operate the centralized issue tracking system integrated with iSeries 400 change management. When DTBridge is run, issues entered into Integrity Manager are moved to the iSeries 400—when an issue meets the criteria established within the DTBridge setup, a new design request is created on the iSeries 400 and the

u s e r g u i d e10

MKS Issue Tracking Solutions

Integrity Manager issue is updated with the new design request number. You can elect to post all issues or a subset of issues based on rules that you define.

Issue Database Considerations and Assumptions

� Throughout this manual, the terms “issue” and “design request” or “DR” are interchangeable to the extent that any references to issues assumes that Integrity Manager is installed and configured as your issue tracking system, and any references to design requests (or DRs) and Service Requests assumes that DesignTracker is installed and configured as your issue tracking system.

� On the Implementer panels that allow the use of an issue or a design request (for example, the Workbench, Check Out panel, Create Request panel, and inquiries) the field name “Issue Number” displays when Integrity Manager is installed; the field name “Design Request” displays when DesignTracker is installed. Throughout this guide, the field name “Issue Number” displays.

� On the Implementer reports that print an issue or design request (for example, Request Report, Activity Report, Lock Report) the field name “Issue Number” displays when Integrity Manager is installed; the field name “Design Request” displays when DesignTracker is installed. Throughout this guide, the field name “Issue Number” displays.

� Integrity Manager and DesignTracker cannot be used concurrently. If you currently use DesignTracker and want to convert to Integrity Manager, contact Customer Support for further information. If you currently use DesignTracker and plan to continue using DesignTracker, no further action is required.

� For detailed information about the Implementer and Integrity Manager integration, see the Implementer Multi-Platform Solutions Guide.

11

Getting Started

Starting Implementer To start Implementer, use the Start Implementer (STRIM) command.

If you received the Implementer product from Computer Associates and have Implementer enabled for COOL:2E change management:

� References to or the use of the Start Implementer command STRIM can be replaced with the STRCM command.

� References to or the use of the Start Implementer Receiver command STRIR can be replaced with the STRCR command.

� The host system default library name is Y2SYCM (not MKSIM).

� The remote system default library name is Y2SYCR (not MKSIR).

The next section provides a listing of the command parameters that can be used with the STRIM and STRCM commands.

Menu Access While My Workbench provides access to the day-to-day tasks performed by the developer, the menus allow access to all capabilities of Implementer. In addition, each menu option can be accessed directly by the STRIM command.

Menu access options are described in this guide when they are used for specific tasks.

You display the Implementer menu by using the STRIM command. The menu contains the following sections spread across multiple panels:

� implementation

� other common tasks

� emergency functions

� reports

� setup functions

� utilities

� commands

u s e r g u i d e12

Starting Implementer

Menu Access Command Options

Menu Option STRIM Command Value

Activity Report *ACTRPT

Archive History Report *ARCHRPT

Archive Recovery *ARCRCV

Check Out *CHKOUT

Compile Promotion Request *CMPRQS

Concurrent Development Report *CONDEVRPT

Create Promotion Request *CRTRQS

Move Promotion Request by System/Environment *MOVRQSSYS

Environments *WRKENV

Environment Groups *WRKENVGRP

Environment Report *ENVRPT

Function Keys *WRKFNCKEY

Integrity Manager Setup *INTMGRSET

Job Log Inquiry *JOBLOGINQ

Lock Report *LCKRPT

Menu—Panel 1 *M1 or *MENU1




Manage All Concurrent Development *MNGCONDEV

Move Promotion Request *MOVRQS

My Workbench *WRKBCH

Network Configuration *NETCFG

Objects *WRKOBJ

Object Codes *WRKOBJCDE

Object Code Report *OBJCDERPT

Work with Projects *WRKPRJ

Request Inquiry *RQSINQ

Request Maintenance *RQSMNT

13

Getting Started

Overview of Implementer FeaturesImplementer is the leading change management solution for the iSeries 400 available on the market today. It provides developers and IT managers with a feature-rich and easy to use environment that expedites development by managing and streamlining critical development processes.

� software change management

� version control software

� developer productivity tool

� distribution of software

� project tracking

� release control

� release deployment

At the heart of Implementer is the Developer’s Workbench. From it, you can perform all the essential development tasks such as check in, check out, editing, compiling, promotion, and deployment, as well as resolve conflicts associated with parallel development. The result is that you spend more time doing what you enjoy—developing software.

Development users and managers of the Implementer product have an intuitive interface in the Workbench.

Managers are able to view all requests and projects they are responsible for from the same Workbench. Implementer integrates all project information into the change management process. At the same time, application paths (either project-based or environment-based) ensure that object movement between environments occurs as defined, without requiring the constant

Request Report *RQSRPT

System Control Maintenance *SYSCTLMNT

Users *WRKUSR

User Report *USRRPT

Menu Access Command Options

Menu Option STRIM Command Value

u s e r g u i d e14

Overview of Implementer Features

attention of the developer. In addition, integration of Implementer to other vendor products provides an open and complete interface to CASE and other vendor tools.

While making developers’ lives simpler, Implementer also provides features that IT managers demand for enterprise change management. Implementer’s Secure Promotion Technology (SPT) ensures your promotion and deployment process cannot be compromised.

Integration With Integrity Manager

Managers can assign, manage, and track issues using MKS Integrity Manager, MKS’s workflow management and issue tracking solution for NT and UNIX. Using either the Windows GUI or Web interface, Integrity Manager’s powerful and customizable workflow capabilities extend control over software development processes, regardless of the platform. Plus you can have a single repository of all software changes made throughout the organization.

MKS is at the forefront of responding to new and evolving capabilities of the iSeries 400, including Integrated File System (IFS), Java, and WebSphere. Implementer provides complete change management for the IFS. For teams developing applications for the iSeries 400 using VisualAge for Java, WebSphere Studio, or other IDEs, the solution is MKS Source Integrity Enterprise Edition.

Source Integrity Enterprise Edition is MKS’s client/server, configuration management solution for NT and UNIX, which integrates with VisualAge for Java and WebSphere Studio. When a project or change is complete, Source Integrity Enterprise Edition makes the files immediately available to Implementer for deployment.

15

Getting Started

Implementer brings all Java and WebSphere components, Windows and Web files, and native OS/400 objects into a single change package, ensuring synchronized promotion and deployment of all the components of your application.

NOTE

Integrity Manager is a separately licensed component of the MKS Integrity Solution. All functionality referencing MKS Integrity Manager requires Integrity Manager be installed and configured as your issue tracking system within Implementer.

All functionality referencing DesignTracker and design requests requires DesignTracker be installed and configured as your issue tracking system within Implementer (DesignTracker is the default issue-tracking system), In addition, DesignTracker requires SupportCenter and ProjectMaster require be installed to complete the interface, unless noted otherwise. DesignTracker and ProjectMaster are automatically shipped with Implementer.

The Workbench The Workbench and the Work with Objects function provide ease of use for anyone involved in the change management process. From the Workbench, you can initiate and manage any task relating to design requests or projects. Developers get information in the form most useful to them. Managers use the Workbench to view all the changes for design requests and/or projects that are their responsibility.

The features and benefits available from My Workbench allow you to:

� Check out members/objects for a design request or project using any selection criteria.

� Edit and perform development tasks using Source Edit Utility (SEU), Screen Design Aid (SDA), Report Layout Utility (RLU), Work with Member Programming Development Manager (WRKMBRPDM), and the command line.

� Filter, change, and/or create design requests or projects to manage development.

� Check out or promote objects from multiple environments simultaneously.

� Filter development activity by user, design request, promotion request, project, and/or any other established criteria.

� Directly access other related Implementer functions such as Work with Objects, Compile Requests, Move Requests, and Request Inquiry.

u s e r g u i d e16


� Compare and merge source code from multiple environments using integrated compare and merge.

� Display member/object status and status history.

� Enter time for projects and tasks or initiate updates.

� The Clipboard provides an industry unique selection capability by allowing you to select work from multiple assignments (for example, requests, portions of related projects, and different developers).The Clipboard automatically sorts all selections, ensuring that related components are properly grouped together.

� Implementer provides an open interface to add software items to the Clipboard and to process the items on the Clipboard using commands. These commands can provide significant benefit to those companies who need to control and automate the promotion of software items received from their software vendors (for example, Program Temporary Fixes (PTFs) and new releases). A list of the delivered software items is automatically built into the Clipboard using a command, then all of the items are added to a promotion request using another command.

� The Workbench compile feature provides significant advantage to using the PDM compile. Developers can compile with the knowledge and assurance that all compilation requirements are automatically applied for each software item checked out to the Workbench. This includes library list, user ownership, authorities, and overrides.

� Options defined in PDM can be run directly from the Workbench. The Workbench supports the use of both PDM and Implementer supplied substitution characters. This adds significant value to using the Workbench over PDM, for carrying out development and testing activities for software items in progress within the development cycle.

� The controlled testing facility enables you to process an item that is on the Workbench list without having to change your library list.

� The F13 Repeat option allows you to repeat an option through the Workbench list.

� An additional filtering selection capability allows you to display only those items checked out either to a development or to a testing location. This has particular benefit to those developers and testers who work across multiple business applications.

17

Getting Started

Technology-based Features

� Implementer provides support for Integrated Language Environment (ILE) software development. This feature includes all functions associated with the check out, creation, and promotion currently available for traditional OS/400 software development. The focus of MKS is to provide the developer with the necessary tools and management information needed to develop and modify ILE software easily in a development environment. On promotion to test and production environments, all of the technical requirements associated with ILE software are automatically managed.

� Implementer provides support for Integrated File System (IFS) software development, on both the iSeries 400 and Windows NT Server. The change management of all objects in the IFS is fully supported. This feature includes all functions associated with check out, creation, and promotion currently available for traditional OS/400 software development (for example, RPG programs and display files). Within the IFS structure, Document Library Objects (DLOs) are supported. When checking out or promoting DLOs, all attributes and characteristics of DLOs are automatically retained.

� Implementer provides support for your e-Business applications by offering Web-based check out and promotion deployment of IFS objects, using a browser interface. This integration is built on the existing proven framework of Implementer technology, which includes the latest support for IFS technology and the change management of client/server development. For more information, see the Implementer Multi-Platform Solutions Guide.

� Implementer supports the retention of existing DB2/400 attributes attached to a file that is being replaced by a new version, in addition to promoting a new version of a file with additional DB2 attributes.

� Implementer provides integrated front-end and back-office change management. In conjunction with the MKS Integrity Solution, this feature allows iSeries developers to manage GUI and Web development. The MKS Integrity Solution provides state-of-the-art content management and software management and collaboration in one built-for-eBusiness integrated package. MKS Source Integrity Enterprise Edition provides deployment capabilities for both the client and back-office parts of the application—all with a single change request. This ensures that all the software components associated with a change request go into production at exactly the same time.

� Source Integrity Enterprise Edition offers change management for Windows and UNIX platforms. You can log new issues and track progress within the development organization using MKS Integrity

u s e r g u i d e18


Manager, a robust issue and change management tracking technology with Windows and Web-based interfaces. With this solution, a single issue ID can be used to manage a change across multiple platforms.

Change Control Features

Implementer is feature rich with change control features, as described next.

Application Paths

Predefining the application path through development environments simplifies the promotion process. You can define a default path, and specify whether certain users can override the path. This takes the guesswork out of check out and promotion, and provides controlled access to each environment.

You can define application paths:

� by project, or by environment and user (which allows nearly unlimited flexibility)

� for all environment relationships: development, QA, production, and remote systems

� separately, for standard and emergency paths

Concurrent Development

Implementer ensures by default that two people cannot accidentally check out the same source member. If you want to perform concurrent development, Implementer manages the development to ensure you track all changes in an orderly fashion. Concurrent development allows automatic merging of multiple versions of source member’s back into one source member. This replaces the need to wait for one user to complete work on a change before the next person begins to work on changes.

Security

Implementer ensures selected users control changes to production, development, and test libraries. You can tailor Implementer to the level of control you want. You can designate, by user, the menu options that can be used, the environments (and functions within each environment) that can be used, and the defaults that can be overridden.

Controlled Object Characteristics

Implementer ensures objects have the correct characteristics when you promote them into production or into controlled test libraries. The ownership, authority, and compile characteristics are controlled as well.

19

Getting Started

Object Version Stamping

Implementer provides for object version stamping of items under change management control. This feature is beneficial for easy auditing and the identification of deployed objects. Object version stamping can be implemented in association with or independent of another feature, Design Request stamping.

With object versioning, each object, lock record, and repository record is stamped with a version number at predetermined pre-defined stages within the development cycle. With DR stamping, each object is stamped with the design request number that the object was checked out for. When multiple locks exist with multiple DRs, the object is stamped with the primary DR associated with the initial lock. In addition, the actual description of the object is changed by updating the APAR ID attribute with the revision number, and the PTF Number attribute with the DR number. This can be viewed by using the Display Object Description (DSPOBJD) command.

Audit Trail and Status Information

A complete audit trail of every change made by your developers is maintained, and this audit trail can be maintained for as long as you need it. You can inquire or report on check out, promotion, and distribution activities. This allows complete management control over all of your development projects.

The various “Work with” functions and inquiries provide easy-to-use features that allow you to review factors such as: what projects are currently in process, who is working on that project, and what promotions occurred at any given time. In addition, several reports contain this information as well.

It is often difficult to identify what caused an error in the promotion cycle because OS/400 job logs typically contain too much detail rather than too little. Implementer minimizes the messages that are included in the job log so you can be certain that the first diagnostic or escape message listed in the job log is the actual cause of the error in the promotion cycle. This can speed up the identification of what really caused the problem.

Related Objects

When you check out primary objects or promote changes, you can optionally include other objects affected by changes to these objects. For example, for any changed logical file you can include the related programs for check out or promotion.

u s e r g u i d e20


Production Environment Protection

With Implementer, you do not compile directly into your production libraries. Implementer compiles source into a temporary work library, and moves the source and objects into the target (production) libraries only after all objects compile successfully. This methodology ensures that partial updating does not occur if a program in a series of programs on a promotion request fails to compile. Additionally, it prevents excessive downtime of your production libraries, because you do not have to wait for compiles to complete when updating production.

Implementer helps you to control unauthorized changes to production libraries, except for the developers or user profiles that have move capabilities. Users who have move capabilities for a set of libraries do not have the authority to affect the libraries they control outside Implementer. For example, a user that controls promotion (has promotion capabilities for that environment) to the production environment of Accounts Receivable has the authority to promote members/objects through Implementer menu options and commands. However, OS/400 security does not allow the same user to affect those objects or source members directly outside of Implementer (using for example, Copy Source File (CPYSRCF), Create Duplicate Object (CRTDUPOBJ), and Delete Program (DLTPGM)). Specific programs that adopt the authority to update the production libraries accomplish this during the move step.

Developer Productivity Tools

Numerous Implementer features increase your development productivity.

Personal Environments

Developers can work in their own personal environments or development libraries, Implementer environments, or libraries they share with other developers.

Optional Check Out and Promotion Methods

Implementer offers two methods for processing check out and promotion—the one step method and a traditional method. Both methods provide access to the same features and produce the same results. However, the one step method allows you to perform check out and promotion using a fast path approach that saves time and effort, thereby minimizing the number of steps required in the functions. The traditional methods, which are more interactive, display more panels and require additional input for processing.

21

Getting Started

User-Defined Options

If you use PDM (Programming Development Manager), you can set up Implementer to use PDM user-defined options for check out and promotion. If you use PathFinder or ABSTRACT, you can check out members (and their related members/objects) through the PathFinder or ABSTRACT menus. You can continue development once you have checked out the member.

Lock Identification

The Implementer check out feature saves you time locating the user who last changed an object because each member/object has a lock attached by the user who performed the check out.

Automated Move Process

The developer saves time moving objects because it is no longer a manual process.

Customized Function Keys

You can customize the function keys of the Implementer menu panels and other important functions. Use the function keys to access your own systems (such as your own problem tracking system) directly from the Implementer Menu, or to add commonly used commands to a function key.

Implementer Across Multiple Divisions

Security in the product allows for secure and restricted use of a single copy of Implementer used concurrently by multiple divisions of an organization.

Special Commands by Environment

Implementer has an extremely powerful and flexible special commands facility. Special commands provide the facility to issue external commands and programs at user-defined stages within the check out and promotion process, thus bringing significant flexibility and openness to the product. Special commands can be defined for environments, and can be automatically attached to all promotion requests targeting that environment.

u s e r g u i d e22


Special Command Promotion Processor IEXCRQSDTL

The most significant one command of the Implementer special commands runs a user-defined command against each software item in a promotion request that meets some user-defined selection criteria. The command analyzes the promotion request items, and for each item that meets the selection criteria (for example, object code, object name, promotion action) the user-defined command runs.

Distribution Software

Implementer can automatically distribute changes from a development system to remote systems with no intervention required at your remote sites.

Promotion requests can be to any of the following:

� single environment

� modified list of environments

� predefined group of environments

� specific systems per individual requests

� different systems on the same request

Implementer can accomplish the promotion in separate steps or automatically as a single step that can include compile, move, and distribute.

It is necessary to define the target environment (or environment group) before request creation. The environment group definition determines:

� Source location.

� Whether source or objects (or both) are only distributed to the remote (remote initiated move) or moved to a remote production library (host initiated move) or both.

� Whether the environment requires compilation and on what system the compile takes place (local or remote).

� The distribution information: distribution method (TCP/IP, SNADS, tape, NetView/DM, SDMCom, NetWrk/400, AnyNet/400, AS/NET), who initiates the moves, whether the host is updated, and whether to retain requests on the remote system.

You can define the environment definition during the initial set up of Implementer. As your requirements change, you can add new definitions or change existing definitions.

23

Getting Started

Test Tools Implementer supports your testing and quality assurance efforts.

Multiple Test Environments

You can define an unlimited number of environments as test environments.

These environments can exist on either the local or the remote systems.

Tester-Controlled Test Areas

For organizations that have separate testing or quality assurance teams, Implementer allows you to control and manage your own testing areas. Testers can be the users who accept changes placed into their test environments. The testers can indicate what members/objects are ready for promotion either by selecting the project that is ready for promotion or by copying previous promotion requests. This eliminates the need for the tester to select or type in each member/object during the promotion process.

If necessary, the tester can easily reject the change from quality assurance and check the member/object back out to the specific developer and environment or library.

Version Control Implementer provides several different version control features. Using version control, you can:

� Perform multiple or concurrent check out of a member/object. Implementer’s concurrent development function sends a message to other users at the start of concurrent development. You can integrate changes back together using the merge capability.

� Define multiple environments to support all versions of your software. You can implement complete (or partial) development paths (Development, Quality Assurance, User Acceptance, and Production) for each version of the software.

� Roll back up to 99 versions of your software. Rollback is accomplished by archiving members/objects.

� Compare all object versions in your environments. You can view all environments that currently contain a specific member/object to ensure they all contain the identical object.

� Enter revision numbers for tracking the member/object version. Revision numbers display on many of the panels and on various reports.

u s e r g u i d e24


Reporting Implementer provides both transaction reports and master file reports, which allow you to review your change management process.

Transaction Reports

The following reports are useful to analyze change management activities:

� Activity Report

This report can be used to analyze the status of all projects and environments. You can enter more than a dozen options to control printed information. This report is available from the Implementer Menu using option 31.

� Lock Report

This report lists source members and/or objects that are currently checked out. For object revisions and IFS management, the report includes revisions and IFS file name. You can print the report in six different orders with a variety of selection criteria. Lock history is available using the Activity Report function. This report is available from the Implementer Menu using option 32.

� Concurrent Development Report

This report lists source members and objects with ongoing concurrent development. For IFS objects, the IFS file name prints for each IFS object that has an IFS name defined. You can print information on locks, resolution detail, and historical concurrent development. This report is available from the Implementer Menu using option 33.

� Request Report

This report includes all information about the promotion request and automatically prints when a request is created. You can optionally print the report for all requests or a range of requests; and print requests for all users or a specific user. The report includes environment and member/object information, and includes revision numbers if versioning is enabled. The report also includes physical file optimization values, and related requests if a Implementer is enabled to maintain cross environment related objects. This report is available from the Implementer Menu using option 35.

On remote systems, the report is available from the Implementer Receiver Menu using option 1, Remote Requests. Select the request with option 6=Print.

25

Getting Started

� Archive History Report

This report lists all objects and source members that are currently in the archive library. This report is available from the Implementer Menu using option 34.

Master File Reports

Master file reports inform you of authorized users, libraries controlled by Implementer, the controls being implemented, and the predefined defaults for using Implementer. These reports include:

� Environment Report

This report lists the summary-level or detailed information that you have defined within Implementer for an environment. Available information includes library defaults, host and remote library list information, environment groups, related environments, standard and emergency paths, defaults for create request, promotion, (model copy details for COOL:2E environments), and compile, distribution, and move steps. It includes setup defaults for COOL:2E, AS/SET, LANSA, and J.D. Edwards (if installed). Information about products and versions built from an environment, and product versions that define an environment as the default customer environment, are available. The detailed report can include object code information (both active and inactive object codes), object authorities, and object name rules (if defined). This report is available from the Implementer Menu using option 37.

� User Profile Report

This report provides a summary of users, or a list of all information defined with Implementer for the user profiles selected. This report is available from the Implementer Menu using option 36.

� Object Code Report

This report prints information about object codes. You can include all object codes or only active object codes. You can specify the sorting sequence of the report. For IFS objects, the IFS file extension prints for each object code that has a special characteristic of PCFILE when the object code and extension are not the same. This report is available from the Implementer Menu using option 38.

Inquiries A number of inquires and “Work with” functions are provided to display information from the Implementer database. All inquiries are interactive programs.

u s e r g u i d e26


Inquiries allow for flexible queries on promoted objects, promotion requests, currently checked out items, archives, and much more. In addition, all inquiries are full OS/400 panels. The inquiries include features such as filtering, positioning, and scrollable panels.

In addition to the inquiry functions listed next, there are many “Work with” functions that provide inquiry features.

� My Workbench

My Workbench allows you to inquire about locked members/objects or work in process. You can inquire about every promotion or design request that a member/object is associated with. It allows you to view source, compare source, and view all current development and associated design requests (when more than one design request is associated with a lock). In addition, it allows direct access to SEU, WRKMBRPDM, SDA, and RLU.

� Work with Objects

The Work with Objects function allows you to inquire on the migration path of objects. You can inquire about: all member/objects or IFS objects only (in alphabetical order), every promotion or design request that a member/object is associated with, archived sources and objects, and the lock history of a particular source member/object. You can optionally use Work with Objects to inquire about members/objects that were deleted through Implementer.

� Request Inquiry

The Request Inquiry function displays all information about promotion requests. You can display any promotion request not purged from the Implementer database.

� Job Log Inquiry

The Job Log Inquiry function displays job logs saved by promotion steps. Depending on the environment definition, you can retain job logs for all batch promotion steps, or just for failed steps.

� Work with Projects

The Work with Projects function displays requests and lock history for a project.

Release Planning

Implementer supports the unique requirements of distributed information technology (IT) environments, including the independent software vendor (ISV) community. Software versioning and release facility features include:

27

Getting Started

� Release Control

This feature provides additional management control and orientation by release name or number for managing production environments and reviewing release history. Users can continue working in a continuous development model or a fixed-version development model. Both models support PTFs for each version, which optimizes developer time and productivity.

� Release Deployment

This optional feature allows you to manage, track, and deploy software changes by client, installed system, licensed product, version number, or PTF, as well as monitor current release status and shipments. Both internal and external clients have greater control and flexibility over installation of change packages, such as user-specified test libraries, scheduled installations, and control over object owners and authorities.

Third-Party Vendor Integration

Implementer interfaces with third-party solutions to provide our customers the integration needed to address their business cases.

� COOL:2E

COOL:2E is an application development tool for the iSeries 400 developed by Computer Associates. Implementer provides change control for COOL:2E developed applications and traditionally developed (3GL) applications, under as a separately licensed product. The primary difference between Implementer and COOL:2E licensed version is that with COOL:2E, programmers can check out from an option within Implementer.

� AS/SET

Implementer manages AS/SET definitions and generated traditional objects. Support for AS/SET fields, files, audit trails, action subroutine definitions, program definitions, and data models are provided.

� LANSA

Implementer manages LANSA objects such as files, fields, processes, and functions. With Implementer, you can check out and promote LANSA objects in a controlled fashion, distribute LANSA objects to remote locations, and archive LANSA objects during promotion and roll them back when necessary. Includes support for LANSA’s web interface.

u s e r g u i d e28


� J.D. Edwards

Implementer supports J.D. Edwards special objects and traditional objects for any J.D. Edwards 8.X versions and earlier. With Implementer, you can check out and promote J.D. Edwards special objects as any other object controlled by Implementer, and promote the special objects to local and remote environments.

NOTE

For more information about integrating Implementer with these and many other products, see “Integrating With Other Vendor Products” on page 327.

Additional Features

The additional features of Implementer allow you to track software changes from the initial software request through completion of the project.

Impact Analysis

Implementer allows you to determine impact analysis on specific members/objects at check out or when promoting the completed changes. Implementer determines the impact on specific objects by use of it’s own native support, PathFinder, or ABSTRACT.

Project Management Capabilities

Implementer fully integrates with project management. The ProjectMaster module, which automatically ships with Implementer, is a project management system focused on Management Information Systems (MIS) issues. You receive a closed-loop management system as a part of the Implementer change management solution. This loop extends from the initial user request, through to the completion of the change and history on the project.

� Developers can report time on a single screen that displays project assignment, time allocation, and current project status. Developers can enter time directly from the Workbench.

� Managers can filter the status on partial projects, individual projects, and groups of projects.

� Automatically schedule resources by project requirement, the resources ability to perform the task, and resource availability.

� Gantt charts provide online visibility to the status of all resource and project changes.

29

Getting Started

� Extensive reporting provides information on estimation accuracy, project status and completion, resource availability and performance, and project backlog.

� Real time scheduling or rescheduling provides instant visibility to resource and project changes.

You can assign all change management tasks to a project, and enter and track the projects with Implementer. If you use DesignTracker and ProjectMaster, you have extensive project management features available such as time entry, quantitative project status, scheduling of tasks, and auto scheduling of tasks and resources.

User Request Features

User request integration with DesignTracker uses Design Requests (DR) and Service Requests (SR) to deliver the closed-loop approach to change management.

This feature allows you to:

� Specify if design request approval is necessary for entity check out or promotion.

� Subset SRs and DRs based on nearly any criteria (including Boolean logic) providing unlimited flexibility. Subsets can be saved for reuse.

� Define when, how, and to who is sent messages for a project.

� Define details on service and design requests as write protected, dependent on the status of the request.

What’s New in This Release?This release of Implementer provides many new features and enhancements. If you are already familiar with Implementer, this section provides an overview of the new release. In addition, be sure to review the Implementer Release Notes for any late-breaking information regarding this release.

IMPORTANT

If you have made customized changes to the Implementer source file QSAMPLE, after upgrading to this release you need to recompile programs MWI0891 and MWI0891P to reflect changes in Implementer 5.3.

u s e r g u i d e30

What’s New in This Release?

Documentation Enhancements

This release of Implementer provides enhancements to the Implementer documentation set.

The iSeries Solution Documentation CD, which contains the documentation for all iSeries products, is included with your product shipment. In addition, your product shipment now includes one printed set of the following Implementer publications:

� iSeries Solution Installation Guide

� Implementer System Administrator Guide

� Implementer User Guide

� Implementer Multi-Platform Solutions Guide

� Implementer QuickView Guide

NOTE

If you need additional copies of printed manuals, they are available for a nominal fee. For more information, contact Customer Support.

With a focus to standardize on the documentation for all MKS products, this release presents a transformed Implementer documentation set that includes:

� new cover design

� new style and format

� new document size of 7-1/4 inches by 9 inches

The new format provides an integrated and user-friendly structure. For example, it provides book-wide hyperlinks for easy navigation.

For customers that also have MKS Integrity Solution products, the new format provides a familiar consistency with each product manual—regardless of the product or platform—making it easier to install, learn, and use all MKS products.

Integrity Manager Integration

Expanded integration with Integrity Manager provides a new issue management solution for Implementer users. The latest integration with Integrity Manager provides enterprise-wide issue and workflow management. To highlight a few features, this robust integration allows you to:

� access and select Integrity Manager issues directly from the Workbench, using the Web, Windows, or 5250 emulation

� view Implementer information from Integrity Manager

31

Getting Started

� control Implementer check out and promotion activities through Integrity Manager workflow rules

� track each member, how it was changed, and where it is currently in the development process

� automatically reflect development activities by progressing an issue through the workflow

� group changes by the effected production environment

For detailed information on this integration, see the Implementer Multi-Platform Solutions Guide.

Technology-based Enhancements

Improved Support for DB2/400

Implementer now provides full support for database files built using SQL DDL. This includes support for non-source-based SQL tables, indices, and views, and source-based files (OS/400 managed source). Implementer ships six new SQL object codes to support SQL objects.

In addition, Implementer allows you to optimize the promotion of DDS-based physical files created with the Create Physical File (CRTPF) command. This feature utilizes the DB2/400 ALTER TABLE command (for SQL) and the Change Physical File (CHGPF) command (for physical files) for improved performance of database file promotions.

Triggers and constraints are now automatically retained to provide application integrity during the promotion process.

Enhanced Support for ILE Development

Implementer provides improved debugging and object description information for ILE. Using a new API, Implementer sets a promoted ILE program or service program effected relationship references to the appropriate module library, module source library, and module source file for the target environment.

When a compile request includes an ILE program or service program and one of the referenced modules, the internal references and object descriptions of the resulting program or service program are appropriately set. This ensures the integrity of the module relationship reference to the program or service program.

When related objects are added to a request using Implementer or Pathfinder as the source of related objects, modules are properly added to the request for the effected relationship references. Likewise, displaying

u s e r g u i d e32


related objects shows correct relationship references on the related objects. For example, for a Module library and Module Source library, the library of the associated environment displays.

NOTE

You do not need to perform any set up functions in Implementer for the enhanced ILE support.

User Interface Enhancements

Enhancements to Implementer’s user interface include the following functional areas.

Related Objects Across Environments

You can now optionally configure Implementer to automatically generate secondary requests to compile and promote related objects that exist across environments not included in the original request. For impact analysis, use either Implementer or Hawkeye as the source of related object information.

This feature is defined globally in System Control Maintenance. You can enable and disable the feature as needed. By default, the feature is disabled.

Removing Objects and Source After Promotion

You have the ability to customize how Implementer automatically handles objects and source in a local *TST or *QAC environment, upon successful completion of a promotion request from the environment.

This feature is enabled by defaults at the environment level, with validation to environment overrides as needed. For each from environment, specify 1=always delete from the environment, 2=never delete from the environment, or 3=delete on a per object code basis. Previously, this feature allowed values of Y or N; consequently, any panels containing these fields now require a value of 1, 2, or 3.

In Work with Users, the Remove obj in from lib/env and Remove Src in from lib/env fields were renamed to Remove obj in from library and Remove src in from library, respectively. In addition, moved to the first panel under User Controls are the fields that control a user’s ability to override the remove values in promotion; the field names are Override remove src and Override remove obj.

Implementer 5.3 Upgrade Considerations

MKS recommends that you complete or delete any open promotion requests prior to upgrading.

33

Getting Started

� Field values set or changed during the upgrade

� For any incomplete requests found, the upgrade process will change the existing Remove field values from Y (Yes) to 1=always or from N (No) to 2 =never. The value 3=per object code is never set during an upgrade.

� For existing object codes and environment object code overrides, the Remove fields are set to N (No).

� For user profiles, if all user profiles are defined as Remove=Y, the Remove in from lib/env field is set to 1=always for all environments. However, if at least one user profile is defined as Remove=N, the field is set to 2=never for all environments.

� Create Request (ICRTRQS) command change

If you have any existing program references to the ICRTRQS command that include values for the REMSRC and REMOBJ parameters, you must change the parameter values from *NO to *NEVER.

� Removal of Implementer data areas

In previous releases of Implementer, the IMDLTFRMPF and IMDLTFRMLF data areas were used to remove database files in a from environment during promotion. Since this function is now performed through object code overrides, these two data areas were removed from the Implementer database.

There is no change to the COOL:Xtras CM data areas IMDLTFRMUP (user program) and IMDLTFRMUS (user source).

Execute Checkout (IEXCCKOCMD) Command

Implementer provides the Execute Checkout (IEXCCKOCMD) command, a special command that allows you to distinguish certain items during check out for additional special command processing.

The IEXCCKOCMD command conditions the processing of any special command based on the object code, member/object name, and action. Using the criteria that you define for the IEXCCKOCMD command, Implementer identifies the appropriate checked out items and issues the command that you specify for only those objects.

u s e r g u i d e34


Menu Enhancements

The Implementer Menu has the following new options:

� option 24, Archive to Tape

The Archive to Tape menu options are now accessible from the Implementer main menu. Previously, this menu was accessible only from a command option.

� option 47, Integrity Manager Setup

Use this menu option to configure Integrity Manager for integration with either Implementer, or DTBridge. For more information, see the Implementer Multi-Platform Solutions Guide.

� options 51–54 Release Control Options

Use these options to work with products, release types, release status, and access the Release Deployment Menu.

For more information on these options, see the Implementer Release Management User Guide.

For DesignTracker users, the DesignTracker Menu is condensed to a single menu for quicker access to the DesignTracker features.

Release Management Enhancements

Release management includes four enhancements.For more information on the following enhancements, see the Implementer Release Management User Guide.

IMPORTANT

If you are using release management, after upgrading to Implementer release 5.3, any packages existing at the time of the upgrade must be re-prepared after the upgrade. For each package, from Work with Packages, run option 18=Upgrade Package to Current MKSIM Host Version.

Software Distribution on CD Media

Implementer now supports software distribution on CD media. The Send Delivery (ISNDDLV) command is used specify the distribution media and submit the package creation process.

Expanded Filters in Work With Product Version Releases for a System

Expanded filters are available for displaying release information at the product level and at the customer level.

35

Getting Started

Support for Contact Types

A customizable type field is now provided for customer contacts, to assist with identifying a contacts role within the organization.

Support for Retaining Existing Data Area Values

Implementer allows you to retain the existing value in a target library data area upon promotion to the target library.

The DTAARAR object code retains the existing value in the target library during promotion. It has an object type of *DTAARA and a special characteristic of *DTA. The special characteristic is significant—it controls whether the existing data area value is retained.

Vendor Integration Enhancements

This release of Implementer provides enhancements to the various vendor integrations.

COOL:2E Integration

� Support for COOL:2E SQL

Implementer supports the SQL-related generation options available in COOL:2E 7.0. This includes the creation of SQL tables, SQL indices, and SQL views, and the corresponding functions that create RPG SQL and COBOL programs.

� Support for EXCUSRSRC and EXCUSRPGM

By default, Implementer allows you to promote EXCUSRSRC and EXCUSRPGM COOL:2E functions separately from their associated implementation 3GL source and objects. This is called “Independent EXCUSRSRC and EXCUSRPGM”. Implementer optionally allows you to automatically promote the 3GL source and objects associated with EXCUSRSRC and EXCUSRPGM functions when these functions are promoted. With this feature, the implementation source and/or objects may not be checked out or promoted separately from this model object. This is called “Dependant EXCUSRSRC and EXCUSRPGM”.

This feature provides capabilities that were available prior to COOL:Xtras CM 6.0. It is controlled by an environment level flag.

u s e r g u i d e36


When upgrading COOL:Xtras CM, the existing default method of independent EXCUSRSRC and EXCUSRPGM is retained.

NOTE

Implementer release 5.3 corresponds to COOL:Xtras Change Management version 7.0, when used with the separately licensed product Implementer Adapter for COOL:Xtras CM. The Implementer Adapter for COOL:Xtras CM provides change control for COOL:2E developed applications and traditionally developed (3GL) applications.

Hawkeye Integration

This release of Implementer provides improvements with Hawkeye related object information. When adding related objects to a promotion request using Implementer or Pathfinder as the source of related objects, modules are properly added to the request for the effected relationship references.

When displaying related objects, the correct relationship references appear on the related objects. For example, for the Module library and Module Source library, the library of the associated environment displays.

Lotus and Domino Integration

The Implementer and Lotus Domino integration now supports the management of the ACL for Domino databases by allowing you to set the ACL at various stages of the development cycle. For more information, see the Implementer Multi-Platform Solutions Guide.

CODE/400 Integration

Implementer provides integration into CODE/400 to offer a Windows-based version of the classic host tools SEU, SDA, RLU, and PDM. This integration provides seamless access to your iSeries source and objects, and offers efficient development of your ILE RPG, ILE COBOL, ILE CL, ILE C, ILE C++, database description specifications (DDS), and Java applications. For more information, see the Chapter 10 of the Implementer User Guide.

37

Getting Started

User RolesThis section describes the typical tasks that users in different roles can perform with Implementer. You can have individuals, particularly in smaller organizations that fill multiple roles. You can also have individuals that perform only part of a particular user’s role. With Implementer, you have the ability to tailor the exact role each individual fulfills. These roles are:

� System Administrator

� Project Leader

� Developer

� Tester

System Administrator

The system administrator has the highest level of authority within Implementer to maintain the Implementer control parameters. Implementer initially delivers user profiles SDMDEMO, MWIPROD, and QSECOFR with security administrator rights. You should define one or two other user profiles to serve as system administrators and use them instead of the default user profiles to limit the use of these high security profiles.

Use this role during initial setup either to install new applications in production, or to put in required user changes.

The role of the system administrator is to:

� establish system wide defaults

� enroll new users and define their capabilities

� define environments under Implementer control based on instructions from environment administrators and project leaders

� review the Implementer default object code definitions and tailor them to meet internal requirements

� identify the remote systems you distribute changes to

NOTE

For information on how to perform all of these activities, and more, see the Implementer System Administrator Guide.

u s e r g u i d e38

User Roles

Project Leader The project leader has the next descending level of authority to maintain and monitor change activity. This individual might be a senior developer, analyst, supervisor, project leader, or manager in your organization.

The role of the project leader is to:

� create projects

� manage concurrent development

� move developer-created promotion requests into the environments they control

� inform the system administrator about changes needed to environments and/or user profiles that they are responsible for

Developer The developer is a COOL:2E designer or a traditional environment programmer.

The role of the developer is to:

� check out members/objects from production libraries into their development environments to accomplish a specific programming task

� create promotion requests targeted to test or production environments

� submit promotion requests for compiling into staging libraries

Tester The tester role can exist separately from the developer or project leader.

The role of the tester is to:

� accept promotion requests into the test environments

� test changes in controlled test environments

� create promotion requests to production or to the next test environment

� submit promotion requests for compiling into staging libraries

You can have different types of testers. For example, you can have testers at a system level and different testers for a complete integration test. They would each be in control of different environments representing the different levels of testing.

39

Getting Started

Understanding EnvironmentsAn Implementer environment defines rules and conventions used to control a library or set of libraries. An example of a set of libraries in an environment is a source library, a database file library, and a program library.

Environment Types

The types of environments you define are based on how you plan to use Implementer. Support for three different environment types is provided: production, test, and development, with an unlimited number of environments being supported. Every organization defines production environments. How development and test environments are defined varies from company to company.

Production Environments

The production environment type (abbreviated *PRD) defines libraries that contain the final production member/object versions. For example, environments that are *PRD environments usually use program and/or database libraries that are in the end user’s library list.

When you promote to a production environment, the members/objects locks are released. The lock is removed at the end of the move step. Lock removal is the main technical difference between test environments and production environments.

Check out normally occurs from a production environment. Each production environment can have an application path to automate the development flow.

Test Environments

The test environment type (abbreviated *QAC) defines libraries that are not the final promotion destination. Test environments are known by a variety of names such as system test, integration test, acceptance test, verification, and user test. For a given application, you can use no test environments, one test environment, or multiple test environments. As a practical consideration, you could consider limiting the number of environments to four. The number of test environments you choose to use is a function of many variables, including the mission-critical nature of the software, number of current problems, experience level of staff, audit requirements, and user community requirements.

u s e r g u i d e40

Understanding Environments

When you promote to a test environment, the member/object locks are changed to indicate that the member/object is still checked out from production, but the current location of the member/object is this test environment.

You normally check out from production environments. However, you can also check out from a test environment. One reason would be to correct a problem that is detected during testing. When you check out from a test environment, the item being checked out must originally be checked out from a production environment.

Another use of test environments is to control when the lock is released during promotion. For example, you have a promotion request targeted to two environments (a local environment and a remote environment). If you want the lock to be released as soon as promotion to the local environment is complete, create both environments as production environments. If, however, you want the locks to be removed upon completion of the entire promotion request, create the local environment as a test environment and the remote environment as a production environment.

Development Environments

The development environment type (abbreviated *TST) defines libraries that are used and changed by the developer. It is necessary for these libraries to be controlled by Implementer because members/objects must be checked out using the Implementer check out function before they can be promoted.

Although all Implementer users have development libraries, the use of development environments is optional. Instead of using development environments, you can enter a development library in either Check Out or Create Request. Developers can use several development libraries, you do not want or need to create an environment for each one.

Development environments are beneficial to Implementer users that use common development libraries or have database files in one development library, program objects in another library, and source in a third library.

Libraries Four default libraries can be defined in Implementer. The first three are the program library, database files library, and source library.

Source members are placed into the default source library. Database files, including SQL tables and views, physical files, logical files, and data area objects are placed in the default database files library. All other objects are placed into the default program library.

41

Getting Started

Both the source and object library values can be overridden for each allowed object code in the environment. This means you could have a different source library and different object library for every type of object in this environment. There are several reasons why you might override the object codes:

� Source members for the different types of objects are stored in different source libraries.

� Data areas are placed in the program library, not the database files library.

� Logical files are placed in a different library than physical files.

� Programs are placed in different libraries than display files.

The fourth default library is the archive library, which you define if archiving is specified for the environment. It cannot be overridden for each object code. The archive library cannot be used for current objects for this environment. Different environments can use the same archive library or they can use different archive libraries.

Source Files The source files used for the environment are established by defaults from the object codes defined for this environment. The source file used for a particular type of object can be overridden for the environment on the Work with Environments, Object Code Overrides panel.

Object Owners and Authorities

The Implementer environments control the ownership and authorities of objects. This allows a test environment to be secured differently than a production environment.

The owner and authority of objects are changed during the Reset Authorities function and the move step of a promotion. The move step only changes the objects on the promotion request, whereas the Reset Authorities function changes all objects for that environment, if required.

Defining Owners

Owners can be specified for both libraries and objects. Different owners can be specified for the program library, database library, and source library. Different owners can also be specified for the different types of objects: program objects, database file objects, and source files.

u s e r g u i d e42


Defining Authorities

Authority information can be specified for the environment on the Work with Environments, Object Authorities panel. This panel allows you to set specific authorities for an unlimited number of user profiles defined in Work with Users.You also can designate an authorization list on this panel.

When you define authorities, you define the authority established for all objects promoted to this environment. By default, Implementer sets all objects to *PUBLIC *EXCLUDE. You should review the authority options each time you create a new environment.

Additional features in Implementer are used to support authorities. The first feature is Implementer data areas PFREFOBJ and LFREFOBJ. These data areas are used to override the owner and authority information for all database file objects, regardless of the environment they reside in.

The second feature is to use an Implementer user exit program to insert your own object authority granting routines. This program, IMPRMV3, is described in source member IMPRMV3 in source file QSAMPLE in the Implementer product library.

Implementer data areas and QSAMPLE options are described in more detail in Appendix A of the Implementer System Administrator Guide.

Considerations for IFS Objects

For IFS objects residing in non-OS/400 directories, ownership and authorities are not set to the Implementer environment values. In addition, the following rules apply to IFS mounted drives:

� Any IFS objects placed on the NT Server by Implementer inherit the authorities of the target directory. Any authorities defined to the environment or existing for the from object are disregarded.

� Any IFS objects placed on the NT Server by Implementer are owned by user SDMAUTUSR; the object owner is not set when the Build List or Reset Authorities is run.

� For environments defined to a mounted drive, the Reset Authorities function does not change the authorities and owners of IFS objects.

Capabilities The collective rights to perform Implementer tasks on an environment can be restricted to certain users. These are called user capabilities. User capabilities can be changed from either Work with Users or Work with Environments.

43

Getting Started

Administrator The administrator is the user profile that owns and controls a specific environment and has move capabilities to that environment. A user profile must have Move Request authority to be an administrator. The administrator can have additional capabilities to promote and archive. To modify or display these capabilities, select environment capabilities for the administrator’s profile in Work with Users. Multiple users can be granted administrative rights to an environment through Work with User Capabilities.

Library List Considerations

The environment library list is used in three ways. Primarily, it is used to compile source members during promotion and during development from the Workbench. The third use is to issue special commands of a promotion request. (When using special commands, keep in mind they cannot be used to change the environment library list.)

If the environment library list is incorrectly defined, the compile step often fails or, even worse, compilation occurs against the wrong objects, resulting in level checks. You must be certain this list has the correct libraries needed for compilation. This is a relatively common error during the initial use of a new environment.

If you use special compile procedures, such as those required by some third party software packages, their library must be added to the compile library list. It should not be put in the Implementer job description MWIJOBD. The library has no effect there, as the library list of the current job is replaced with the environment library list prior to compilation of a source member.

In addition, the environment library should not have the Implementer product library (the default is MKSIM) on the library list. It is only needed on the library list of the Implementer job description.

Defaults for Promotion Requests

The environment is used to define a set of rules and defaults for the promotion requests that target the environment. At request creation, you can elect to:

� recompile the source members

� submit the promotion request for batch processing automatically

� add related objects to the promotion request

� ensure the objects being promoted are checked out

You can override these defaults for an individual request if you have set up override capabilities for the environment.

u s e r g u i d e44


Remote Considerations

If you define remote environments, you must set up additional remote specific values. This information is discussed in detail in “Performing Distributions” on page 271.

Environment Groups

Environments can be grouped into an environment group. You use environment groups when you want to create a promotion request for more than one environment. This eliminates the need to select each environment separately every time you create a request to a group of environments. Use environment groups when you want to distribute changes to multiple remote systems or when you want to promote to a local environment and the remote production system at the same time.

Environment groups are defined in the Work with Environment Groups function.

Object Codes Object codes are defined at the system level but can be changed at the environment level. The source file can be overridden from the value defined for the object code for source-based objects. The object library and source library can also be specified for an individual object code. The overrides change the environment defaults, not the object code defaults.

You can disable a particular object code for an environment. For example, this is useful when you use database-only environments, or to ensure that certain types of programming languages are not used for particular environments, such as System/38 or System/36 environment languages.

Environment Inventory

Implementer maintains an inventory of all members and objects for each environment. This allows you to view what currently resides in the environment libraries.

The inventory is created with the Build List function. This function can be run for traditional objects or IFS objects only, or all objects. After the initial build, the inventory is automatically updated during promotion in the move step, or if you check out an object from a production environment.

Environment Integrity Check

Implementer provides the ability to perform integrity analysis of Implementer environments and libraries. The Environment Integrity Check performs validation of every member and object in the program library, files library, and source library defined for an environment, or every member and object in a specified library.

The Check Library Integrity Report, which generates after the analysis completes, highlights problems that may exist in your environment or library, making it helpful for problem determination and resolution. For example, such problems can include: Programs that adopt security officer authority, source without corresponding objects, objects without

45

Getting Started

corresponding source, source in non-standard source physical files, source members with an invalid member type, or damaged objects. For more information, see Chapter 3 of the Implementer System Administrator Guide.

Application Paths

If you use default project or environment application paths (either standard or emergency), the environment or library defaults are determined based on the current location of the item. This can be a library or an environment. If the member/object is in an environment when you begin promotion, the next path entry for the request type (standard or emergency) is used as the next promotion location. This could be an environment or an environment group.

The path represents development flow from the development environment, quality assurance, and back to the original production environment (the first *PRD environment on the path). The first environment or library represents development. The first production environment on the path is the check out from environment. If an environment is on more than one path, the path designated by the original check out from environment (lock) is used. If no lock exists, the first path found that includes the environment is used.

In both check out and promotion, the next location defaults based on the current location. This allows a developer to simply check out a member/object from the preferred production environment to a default development location specified by the path. Developers do not have to remember specific environment information, eliminating the result of an incorrect check out. You can either restrict access so members/objects cannot move outside this flow, or give individual users the capability to override paths.

Application paths and the related environments function work together to form a user-friendly environment for managing the development cycle. The information for the MODS PRD environment is in the following illustration:

Combined Environment Path and Related Environments

(Automaticcopy from)

Standard Path

PromotionMods ProductionDevelopment

Check Out

PromotionQuality Assurance

Related Environment

Production

u s e r g u i d e46


When checking out a member/object, this path defaults the From environment as mods production and the check out to environment as development. If you have not yet modified the member/object (in other words, it is not in mods production), the mods production related environment (production) is automatically copied from. The first promotion automatically defaults to quality assurance and the second promotion to mods production.

Environment Path Related Environment

Seq 10—Development Seq 10—Mods Production

Seq 20—Quality Assurance Seq 20—Production

Seq 30—Mods Production

47

Getting Started

u s e r g u i d e48

3Using the Workbench for Development Activities

This chapter provides an overview of using the Implementer Workbench for development activities and covers the following topics:

� understanding and using the Workbench

� ease of use features

� command prompting

� using the Clipboard

� check out methods

� editing members

� using PDM user-defined options

� compiling and testing locked objects

� displaying related objects

� promoting

� compiling and moving promotion requests

� member/object status history

� inquiry

� working with locks

� associating multiple Design Requests with a lock

� changing a Design Request

� repeating Workbench options

49

Using the Workbench for Development Activities

Understanding the WorkbenchThe Workbench provides you with one panel that you can efficiently manage objects from, throughout the complete development cycle. In addition, it provides a full range of developer tools to perform all necessary development work.

Developers perform many tasks: initiate work, check out member/objects, make changes, compile, test, promote changes through stages of testing back to production, and book time against projects. By selecting one menu option, My Workbench, developers have visibility to all current development activity and access to all member/objects on the system, to complete current work or initiate new projects, without returning to the menu.

In the Workbench, the project leader or developer can:

� select, filter by, change, or create Issues and projects to manage development

� select and process (display, check out, or promote) individual objects from multiple locations

� perform specific development tasks with SEU, SDA, RLU, WRKMBRPDM, or the command line

� display and manage development

� directly access Implementer functions such as Work with Objects, Compile Requests, Move Requests, and Request Inquiry

u s e r g u i d e50

Understanding the Workbench

� directly access ProjectMaster projects

� use commands to add software items to the Clipboard and to process the items on the Clipboard

� compile, with the knowledge and assurance that all of the compilation requirements (for example, library list, user ownership, authorities, and overrides) for each software item checked out to the Workbench, are automatically applied

� process options defined in PDM

� process an item that is on the Workbench list, without having to change their library list

Throughout the development cycle, a developer can simply check out and promote member/objects, with Implementer knowing exactly which environment or library to go to next. Developers do not have to remember member/object details and library information.

Development Cycle

Promotion

ProductionDevelopment

Check Out

Promotion

Quality Assurance

51


Using the Workbench

The Workbench allows you to manage the complete development process from work planning, to making changes and promotion to production.

To do development, developers need the tools necessary to create and change assigned member/objects. Managers need tools to control development activity.

The Workbench allows developers, lead programmers, and testers easy access to the tools needed to perform their work. Additionally, it provides numerous ways for managers and project leaders to track, evaluate, and control the development cycle.

The following tool groups are available.

Identifying Work

You can easily identify work by the method you choose. Flexibility is the key that allows you to filter down to your work. The options on the Workbench include:

� Projects: Prompt a list of projects and select the one you are responsible for, or create a new one.

� Issues or Design Requests: Depending on your issue tracking system, prompt a list of Integrity Manager issues (or Design Requests) and filter to your responsibilities. Select the Issue you want to work on. If authorized, you can create and maintain Issues from the Workbench, and attach specific projects to an Issue.

� User profile: All development work-in-process for the selected user displays.

� Filters: On Work in Process (WIP) or by object (in any environment or on any system).

IDENTIFY WORK(Design Request or Projec t)

(SEU, SDA, RLU,CHANGE

TEST(W RKMBRPDM,

PROMOTE(To Test or Product ion)

CHECK OUT(To a Dev elopment

MANAGE LOCKS(W ork wi th Objects)

MYWORKBENCH

REVIEW WORK(Design Request or Projec t)

COMPILE(Option 14=Com pile)

Env i ronment or Library)

WRKMBRPDM) Command Line)

u s e r g u i d e52

Using the Workbench

Implementer retains the Issue and project filters you select to define your work between sessions. When you return to the Workbench, you start the session right where you ended the time before. The Issue and project filters remain active throughout the selection process in both functions. Using subsets, you can filter on any field.

Reviewing Work Details

You can view or change (if authorized) any details about the Issue or project you have associated with your work. You can access complete information about the DR and project including development information, benefits, alternatives, approval information, and status. Approvals and status allow you to control your work or perform an inquiry. While on the Project reference or Design request field, press F4=List, to select the project or DR, or use option 15 to view work already assigned to a DR.

Checking Out Once you have identified your work on a DR or project, you check out member/objects so they can be created or changed within a controlled environment. You have numerous options for standard and emergency check out. You can select from a list of member/objects for concurrent development, or as a shortcut method, for checking out member/objects that are similar to ones already checked out. You can also quickly access Work with Objects to initiate new changes.

Changing Items You usually check out an item to change it, delete it, or reserve the name (for a new member/object). You can edit members (SEU), display files (SDA), design report layouts (RLU), use WRKMBRPDM, or use the command line. A built-in source Compare Member (ICMPMBR) command provides easy identification of changes. The Merge Member (IMRGMBR) command can automate changes when applying them to multiple versions or custom libraries or when incorporating changes from multiple developers or vendors.

Compiling You can immediately compile a locked object directly from the Workbench using option 14=Compile. This option is also available as option 67, Workbench Compile (ICOMPILE) from the Implementer Menu.

For more information, see “Workbench Compiles of Locked Objects” on page 79.

Testing To test a change, you typically start an application. A command line permanently displays in the Workbench to allow access to any OS/400 command or application.

If you have promoted changes out of development to quality assurance, you can easily reject the changes that fail testing and return them to development for rework.

53


The Set to Environment Library List (ISETLIBL) command allows you to change your job’s library list to that of any environment managed by Implementer. This provides quick and accurate changing between the appropriate development library list and the corresponding production library list when testing. This command is particularly effective when set up as a user-defined option.

For more information, see “Setting a Library List From an Environment Library List” on page 83.

Promoting Once changes are complete, you need to promote the changes to the next environment in the flow of development. Several options are available for you to promote your work from the Workbench: option 11=Promote, Clipboard options, and from Work with Objects with option 27=Promote. You can select member/objects from multiple environments. You also have emergency promote options. To provide absolute flexibility and control, you can authorize specific people to perform the various promotion steps based on user profile and environment. Implementer adapts to the way you do your work.

Time Entry You can perform time entry anytime during the development process by using option 30=Book Time, or by prompting the Monitor Progress (PMONPG) command.

Time entry allows you to compare actual time to estimated time for future work forecasting. You can easily update remaining time to maintain an accurate estimate of continuing work.

Managing Locks

The Workbench allows you to manage individual or concurrent development by specifying who is responsible for any specific change.

Workbench Ease of Use FeaturesUsing the Workbench, developers have visibility to all current development activity and access to all member/objects on the system. The developer can complete current work or initiate new projects without returning to the menu. In addition, the following features provide developers with a streamlined method of development.

u s e r g u i d e54

Workbench Ease of Use Features

Optional Check Out and Promotion Methods

From the Workbench, Implementer offers two methods for processing check out and promotions—the one step method and a traditional method. Both methods provide access to the same features and produce the same results. However, the one step method allows you to perform check out and promotion using a fast path approach that saves time and effort, thereby minimizing the number of steps required in the functions. Because of the efficient streamlined effort, the one step methods are preferred by most developers. The traditional methods, which are more interactive, display more panels and require additional input for processing.

Member/Object Status and History

From the Workbench, you can track the status and history of all member/objects under change management control. The status identifies the current state or application path of the member/object. As member/objects flow through the change management cycle, all historical software changes and associated lock information is retained as well. When the status of a member/object changes, the information is updated and the change is recorded in the Status History file (IMSTHS). The status and history is available in Work with Objects.

For more information, see “Member/Object Status and History” on page 90.

Alternate Views and Filtering

The Workbench provides several views of additional information. A developer can quickly position to specific projects and DRs, member/objects, object code, environment, and many more options, to view their specific changes. The list can display all current development or testing so that a manager knows the location and status of each member/object.

Multiple Selection Methods

The Workbench allows you to process your work using a variety of methods. Direct options exist for all daily tasks, including for example, editing, checking out, and creating requests. More involved options allow you to select member/objects for check out and promotion across panels or various positions in a subfile.

Automatic Grouping

The Workbench allows you to select member/objects by groups that are meaningful to you, even if they are in multiple environments. You can automatically check out or create promotion requests for items that you want to process together (same environment path or project path, project, or DR [DR for check out only]). If the member/objects need to be processed in multiple groups, a message alerts you during check out or create request and provides an option to either process all items as a single group or as separate groups.

55



The Workbench provides developers with options to resolve concurrent development prior to request promotion. After you identify the specific lock, select the concurrent development option for any items that have unresolved concurrent development.

For more information, see “Checking Out for Concurrent Development” on page 136.

User-Defined Options

The Workbench supports user-defined options. This allows unlimited access to OS/400 functions for items on the Workbench. With this feature, you can setup and process user-defined options, list PDM user-defined options, and change user defaults.

For more information, see “Setting Up User-Defined Options” on page 72.

Work With Objects

The Workbench allows direct access to Work with Objects. Work with Objects provides visibility to all objects controlled by Implementer, and the ability to initiate check out of a member/object not under development. It provides lock history, archive history, member/object status history, and inquiry to all member/objects on the system. You can display and work with all objects, or IFS objects only using F16=Show IFS Only.

The following tables compare the functionality of the Workbench with the functionality of Work with Objects.

My Workbench and Work with Objects, Option Comparison

My Workbench Options Work with Objects Options

2=Change (SEU) —

— 3=Promotion requests

4=Delete (Lock) —

5=Display (SEU) 5=Display (SEU)

6=Print (Mbr) 6=Print (Mbr)

7=Lock detail 7=Mbr/Obj detail

8=Related objects 8=Related objects

9=Add to Clipboard 9=Add to Clipboard

— 10=Checkout

11=Promote —

12=Concurrent development 12=Locks

— 13=Lock history

u s e r g u i d e56

Workbench Ease of Use Features

14=Compile 14=Archives

15=Issue or Design requests 15=Issue or Design requests

17=Change using SDA —

19=Change using RLU —

20=Reject 20=Reject

21=Emergency check out 21=Emergency check out

22=Emergency promote 22=Emergency promote

23=Compare member 27=Promote

24=Merge member —

26=Multiple issues or design requests

—

27=Check out —

28=Status History 28=Status History

30=Book Time —

My Workbench and Work with Objects, Function Comparison

My Workbench Function Keys Work with Objects Function Keys

F3=Exit F3=Exit

F4=List F4=List

F5=Refresh F5=Refresh

F6=Check Out F6=Workbench

F7=Process Clipboard F7=Process Clipboard

F8=Work with Objects F8=Apply Filters

F9=Retrieve (previous command) F9=Retrieve (previous command)

— F10=Display (changes the sequence of displayed fields)

F11=Display (changes the sequence of displayed fields)

F11=Display (changes the sequence of displayed fields)

F12=Cancel F12=Cancel

F13=Repeat —

My Workbench and Work with Objects, Option Comparison

My Workbench Options Work with Objects Options

57


Command PromptingThe Workbench offers the option to prompt command options.

To initiate command prompting

1 Type the option next to the appropriate item on the Workbench.

2 Press F4=List to display the command prompt panel. If command prompting is not available for the option you entered, a message displays to inform you.

Using the ClipboardThe Clipboard is a tool in the Workbench used for member/object selection and process initiation. It allows member/object selection across multiple panels or subfile positioning so that you can select the required member/objects without losing prior selections.

The one step check out and one step promotion features apply to Clipboard options 2= Check Out, and 3=Promote. (The functions run automatically without presenting the Check Out panel or the Create Request panel.)

F14=Compile requests F14=Compile requests

F15=Move requests F15=Move requests

F16=User options F16=Show IFS Object

F17=Filter —

F18=User Defaults F18=Show deleted

F19=Request inquiry F19=Request inquiry

— F20=Check out

— F21-Build IFS Obj List

F22=Promote F22=Promote

F23=More options F23=More options

F24=More keys F24=More keys

My Workbench and Work with Objects, Function Comparison

My Workbench Function Keys Work with Objects Function Keys

u s e r g u i d e58

Using the Clipboard

Basic Clipboard Functions

The Clipboard option is particularly helpful when you are positioning within the subfile rather than scrolling.

To use the Clipboard

1 From My Workbench, select the member/objects with option 9=Add to Clipboard, and press ENTER.

2 After placing all required member/objects on the Clipboard, press F7=Process Clipboard, to display the Clipboard Processing Menu.

3 Select an option and press ENTER to proceed to the next panel.

From the Clipboard Processing menu you can:

� display the Clipboard for inquiry or member/object deletion

� perform standard and emergency check out

� create standard or emergency promotion requests

� create a PTF release package

The Clipboard holds selections from several panels and facilitates check out or promotion request creation. Items that you add to the Clipboard remain on the Clipboard until you complete the process, remove them from the Clipboard, or until the current session ends.

The Clipboard allows you to back out of a process, provided you do not process the final acceptance of your selections. For example, if the member/objects that display in the Workbench Check Out panel or the traditional Check Out panel are not the ones you need, press F3=Exit to return to the Clipboard Processing Menu. At this point, you can select the

59


Clipboard display option to view, or remove a specific member/object, or press F12=Cancel to return to the Workbench to add more member/objects. Clipboard selections are not processed until you accept your selections from either the Check Out or Create Request functions. This allows greater flexibility when working with a large number of member/objects.

The Clipboard function calls the Check Out or Create Request function with your selected items pre-filled and edited. The project path (if defined) or environment path is used to determine the from and to environments and libraries in both cases. If you need to perform other actions before you accept the selections, messages display with further instructions.

Using Command Options to Add Clipboard Items

The Add to Clipboard (IADDCBD) command adds traditional member/objects to the Clipboard. The Add to Clipboard IFS (IADDCBDIFS) command adds IFS objects to the Clipboard.

These commands can be issued from the command line, or you can write your own programs to select the appropriate items and feed them to the IADDCBD or the IADDCBDIFS command.

IADDCBD and IADDCBDIFS Commands

The IADDCBD and IADDCBDIFS commands are most typically used to feed items selected by a program to the Clipboard, where they are processed within Implementer. For example, you might want to write a program that selects items from a vendor PTF and copies them to the Clipboard, where they are available for request processing.

This command can also be used as a user-defined option, as explained in “Using PDM User-Defined Options” on page 72.

u s e r g u i d e60

Using the Clipboard

NOTE

If you intend to process the items on the Clipboard using either the ICRTRQS or IPRCCBD commands discussed in the next sections of this document, ensure that the Clipboard does not already contain items. A way to do this is to issue the Process Clipboard (IPRCCBD) command, specifying the *MENU option as described in “Using the IPRCCBD Command to Process the Clipboard” on page 63. If no items are on the Clipboard, the following message displays:

“Clipboard processing not valid prior to selecting entries for the Clipboard”

If items are on the Clipboard, the Clipboard Processing menu displays offering the option to display the contents of the Clipboard using option 1, Display Clipboard. If the Clipboard is already populated, you should clear it before using the IADDCBD or IADDCBDIFS commands.

Add to Clipboard (IADDCBD) Command SyntaxIADDCBD MBROBJ(name)

OBJCODE(code)

ACTION(action)

CURENV(current environment name)

CURLIB(current library name)

PROJREF(project name)

DRNBR(design request number)

IADDCBD Command Parameters

The following parameters define the Add to Clipboard command.

MBROBJ

Specify the name of the member/object to add.

OBJCODE

Specify the valid object code of the member/object to add.

ACTION

Specify the action if the items being added are used to check out or create a promotion request. Valid options are *CHANGE (default value), *CREATE, *DELETE, or *RECOMPL.

CURENV

Specify the current environment of the member/object.

61


LIBRARY

Specify the current library of the member/object.

PRJREF

Specify a project reference (if any) for the member/object.

DRNBR

Specify a design request number (if any) associated with the member/object.

Add to Clipboard IFS (IADDCBDIFS) Command Syntax

IADDCBDIFS LNGNAM(file name)ACTION(action)

CURENV(current environment name)

PRJREF(project name)

DRNBR(design request number)

IADDCBDIFS Command Parameters

The following parameters define the Add to Clipboard IFS command.

LNGNAMJ

Specify the IFS file name (in path/file format) to add.

ACTION

Specify the action if the items being added are used to check out or create a promotion request. Valid options are *CHANGE (default value), *CHANGE, *CREATE, or *DELETE.

CURNEV

Specify the current environment of the object.

PROJREF

Specify the project reference (if any) for the object.

DRNBR

Specify a design request number (if any) associated with the object.

u s e r g u i d e62

Using the Clipboard

Using the ICRTRQS Command to Promote Clipboard Items

The Create Request (ICRTRQS) command contains a MBROBJ parameter option, *CLIPBOARD, which selects all Clipboard items for create request processing.

The *CLIPBOARD option makes it possible to create a request for all member/objects currently on the Clipboard, without the need to actually display the Clipboard. This means that the ICRTRQS command can be called from a program. Used in conjunction with the IADDCBD command, you can select items and create a request for those items, without the need for any manual processing.

CAUTION

This command processes all items on the Clipboard—not just the items selected by your program.

Using the IPRCCBD Command to Process the Clipboard

The Process Clipboard (IPRCCBD) command allows you to perform all standard Clipboard processing options outside of Implementer, in the same manner as can be done from the Workbench using the F7=Process Clipboard function.

The *CLIPBOARD option makes it possible to create a request for all member/objects currently on the Clipboard, without the need to actually display the Clipboard. This means that the ICRTRQS command can be called from a program. Used in conjunction with the IADDCBD and IADDCBDIFS commands, you can select items and create a request for those items without the need for any manual processing.

NOTE

This command processes all items on the Clipboard, including IFS objects, if they were added.

The IPRCCBD command does not process release management PTF release packages (option 6 on the Clipboard Processing Menu). The command interface to this menu option is Create PTF Release (ICRTPTFRLS). For more information about the ICRTPTFRLS command, see the Implementer Release Management User Guide.

IPRCCBD Command SyntaxIPRCCBD ACTION(value)

Where value represents one of the parameter options listed next.

63


IPRCCBD Command Parameter

The following parameter defines the Process Clipboard command.

ACTION

Specify an action for the command to perform.

Checking OutThe Workbench lists all items that are currently checked out. You can check out additional items from the Workbench by:

For detailed information on checking out, see “Performing Check Out” on page 111.

� Performing one step check out.

� Performing traditional check out.

� Selecting from the list of member/objects in an environment, from the Work with Objects panel.

� Checking out all member/objects that are on the Clipboard.

� Performing an emergency check out.

� Selecting member/objects after initiating check out.

� Checking out for concurrent development.

Check Out Methods

Implementer offers two methods for processing check out—the one step method and a traditional method. The one step method allows you to perform check out using a fast path approach that saves time and effort, thereby minimizing the number of steps required in the check out function. The major benefit to the one step method is that after selecting the items for check out, the automatic process runs quickly, and then redisplays the Workbench with your current locked items listed. Because of these efficiencies, it is the preferred method for most developers.

*MENU Displays the Clipboard Processing Menu. This is the default value.

*DISPLAY Displays the contents of the Clipboard.

*CHKOUT Checks out all items on the Clipboard.

*CRTRQS Creates a request for all items on the Clipboard.

*ECHKOUT Performs an emergency check out for all items on the Clipboard.

*ECRTRQS Performs an emergency create request for all items on the Clipboard.

u s e r g u i d e64

Checking Out

The traditional method, which is more interactive, displays more panels and requires additional input for processing. Both methods provide access to the same features and produce the same results.

The one step check out method applies to checking out from the Workbench, the Clipboard, and Work with Objects. When issuing a check out, the user profile record is validated to determine the default check out method. If the one step method is enabled and the check out is initiated from the Workbench, the Workbench Check Out panel displays for member/object selection. With the one step method enabled, you can perform any required overrides from the Workbench Check Out panel with F4=Prompt, which displays the traditional Check Out panel with any selected items populated. (Some tasks later in this chapter require processing from the traditional Check Out panel). If the check out is initiated from Work with Objects, the check out occurs automatically. If one step check out is not enabled, the traditional Check Out panel displays (requiring further input).

The following one step check out task assumes the Enable One Step Check Out flag is enabled for your user profile. Likewise, the traditional check out task assumes the Enable One Step Check Out flag is not enabled for your user profile. For more information, see “Check Out Methods” on page 113.

To perform one step check out

1 From the Workbench, press F6=Check Out. The Workbench Check Out panel displays.

65


2 Select the items with option 1=Check Out and press ENTER to automatically perform the check out and redisplay the reloaded Workbench panel.

Alternatively, you can press F16=Select All to check out all displayed items in the specified from environment. A message displays informing you that you are about to check out all items in the specified environment. You can press ENTER to continue with the check out, or press F3 to return to the Workbench Check Out panel.

Back on the Workbench, notice the Status column is updated with the latest action. In addition, a lock is created for each checked out member to indicate work in process, and a copy of the member (or object for non-source-based objects) is created in the development library or environment.

NOTE

You can perform any required overrides from the Workbench Check Out panel with F4=Prompt, which displays the traditional Check Out panel (with any selected objects populated). To create a new member/object and reserve the member/object name, check out with action code 2=Create.

If you select objects with option 1 and then attempt to reposition the subfile, the selected objects are processed through to completion, and the Workbench Check Out panel redisplays at the selected position.

To perform a traditional check out

1 From the Workbench, press F6 Check Out, or from Work with Objects, press F20=Check out. The Check Out panel displays.

u s e r g u i d e66

Checking Out

2 Complete the Check Out panel as described in “Check Out Methods” on page 113.

3 Press ENTER to verify the selected entities. If everything is correct, the message “Press F9=Accept to check out.” displays.

4 Press F9=Accept to perform the check out. A message displays to confirm the member/objects were checked out.

A lock is created for each checked out member to indicate work in process, and a copy of the member (or object for non-source-based objects) is created in the development library or environment.

Checking Out From Work With Objects

From the Workbench, you can check out unlocked member/objects through Work with Objects.

67


To check out from Work with Objects

� From My Workbench, press F8 to display the Work with Objects panel. This panel shows both locked and unlocked member/objects.

� To perform one step check out

a) Select the member/objects with option 10=Checkout and press ENTER. A message displays indicating the member/object was checked out.

b) Press F12 to redisplay to display the Workbench with the locked items listed.

� To perform traditional check out

a) Select the member/objects with option 10=Checkout and press ENTER, or press F20=Checkout. The Check Out panel displays.

b) Enter any necessary changes, and press F9 to accept your entry and initiate the check out.

NOTE

If you have one step check out enabled for your user profile and select option 10=Checkout, the check out processes automatically without displaying the Check Out panel. If enabled, you can press F20=Checkout to display the traditional Check Out panel, as needed.

u s e r g u i d e68

Checking Out

Checking Out Using the Clipboard

The Clipboard provides an easy way to store multiple member/objects for checking out.

To check out using the Clipboard

1 From My Workbench, select the member/object with option 9=Add to Clipboard.

2 After selecting all required member/objects, press F7 to display the Clipboard Processing Menu.

3 Select option 2=Standard check out to display the Check Out panel or option 4=Emergency check out to display the Emergency Check Out main panel.

NOTE

With one step check out enabled and you select option 2=Standard check out or option 4=Emergency check out, the check out processes automatically without displaying the Check Out panel.

4 Type any necessary changes on the Check Out panel, and press F9 to accept your entry and initiate the check out.

Performing Emergency Check Out

Authorized users can perform emergency check out from the Workbench.

To perform an emergency check out

1 From My Workbench, select the member/objects with option 21=Emergency check out.

2 After selecting all required member/objects, press ENTER to display the Emergency Check Out panel.

3 Enter any necessary changes, and press F9 to accept your entry and initiate the check out.

NOTE

The one step check out method, when enabled, applies to performing emergency check out initiated from the Workbench, Work with Objects option 21=Emergency Check Out, and Clipboard option 4=Emergency Check Out.

Checking Out for Concurrent Development

Many organizations restrict development on a particular member/object to a single developer at a time within one environment, due to the risks of losing changes when multiple copies are simultaneously under

69


development. This is the default development approach in Implementer. This default does not allow concurrent development. You must complete all changes to the member/object sequentially.

Your system administrator can set up Implementer to allow concurrent development. This requires selection of a specific version at check out and resolution of a conflict at promotion. Implementer is easily adapted to your requirements.

For more information on concurrent development, see “Performing Check Out” on page 111.

Common Questions

Attempting to access Work with Objects displays the message “Requested function is already active on a previous panel”. What happened?

You probably accessed the Workbench from Work with Objects. Press F12=Cancel to return to Work with Objects.

Editing MembersThis task describes the use of OS/400 utilities for creating and changing your source members. You can access SEU, SDA, and RLU directly from the Workbench. You can also automatically proceed directly to SEU when you check out. The Workbench allows you to compare or merge specific member/objects. You must have a member checked out and in development to use this function.

The following tasks assume you are working in the Workbench, unless otherwise indicated.

To use the SEU Change option

1 From My Workbench, select a member with option 2, and press ENTER to display the SEU edit panel.

2 After completing your edit, press F3 to display the SEU Exit panel.

3 Select the appropriate options and press ENTER, to redisplay the Workbench.

u s e r g u i d e70

Editing Members

To use the SEU Check Out option

In the Change User Profiles panel, the Edit source on check out field must be Y to perform check out and automatically go to SEU. You can select up to 10 members at one time and cycle through each member with SEU. If you select more than 10 members, you must access the members from the Workbench with option 2 for change.

1 From My Workbench, select a member with option 10=Checkout and press ENTER to display the Check Out main panel, or, using the Clipboard, select the item with option 9, press F7 to display the Clipboard Processing menu, and select option 2 for Check Out.

The Workbench displays member/objects that are currently checked out (locked). When you attempt to check them out again, you must select the member you want to check out.

A message displays indicating that the member/object and object code are locked, and that you must use option 13 to select the member/object to copy from.

2 Type 13 in the option field for the member/object identified in the message, and press ENTER to display the Select Version for Concurrent Development panel. The order of the selection list is significant. The locks are ordered by check out date, and the last library or environment is always the check out from production environment (to allow easy selection of the current production version).

3 On the Select Version for Concurrent Development panel, type 1 next to the member/object and press ENTER to display the Check Out panel. Repeat this step for each member/object you selected with 13 on the Check Out panel. When you complete all necessary selections, the Check Out panel redisplays.

4 Press F9=Accept to perform the check out. The SEU Edit panel displays.

5 After completing your edit, press F3 to display the SEU Exit panel. Select the required options and press ENTER to redisplay the Workbench.

71


Using PDM User-Defined Options The Workbench supports the use of Programming Development Manager (PDM) user-defined options. This allows unlimited access to OS/400 functions for items on the Workbench, including:

� setting up user-defined options

� changing user defaults

� displaying PDM user-defined options

� processing PDM user-defined options

Setting Up User-Defined Options

User-defined options are held in an options file and maintained by using the Work with User-Defined Options panel in PDM. You can access this panel from Work with Objects Using PDM (WRKOBJPDM) or Work with Members Using PDM (WRKMBRPDM) by using F16=User options. It is also available from the Display PDM User-Defined Options File panel or the User Defaults panel, by using F8=STRPDM.

User-defined options can contain either OS/400 commands or user commands, and can contain any of the following supported substitution variables (beginning with an ampersand (&)). The following table defines the valid keywords and substitutions. Those items with Yes in the Workbench Only column are supported exclusively on the Workbench.

NOTE

The substitution variable &OBJECT returns the project’s relative long object name when a long object is associated with a lock (&OBJECT returns the actual object name when a long object name is not specified).

Valid Keywords and Substitutions for PDM User-Defined Options

FieldWorkbench Only

KeywordAlternate Keyword (PDM)

Locks File Field

member object name – &LCKMBROBJ &N1 LHMONM

object code Yes &LCKOBJCOD – LHOBCD

source member name – &SRCMBR &N1 LSMBNM

source file – &SRCFIL &F LSTOFL

source file library – &SRCLIB &L2 LSTOLI

source type – &SRCTYP &T3 LSMBTY

u s e r g u i d e72

Using PDM User-Defined Options

object name – &OBJECT &N1 LOOBNM

object library – &OBJLIB &L2 LOTOLI

object type – &OBJTYP &T3 LOOBTY

object type no * – &SHTOBJTYP &S LOOBTY

object attribute – &OBJATR &A LOOBAT

design request nbr Yes &DSNNBR – LHDRNB

environment name Yes &ENVNAM – LHTOEN

member/object description (obj if no source, in ‘ ‘)

– &DESC &X –

from environment Yes &FRMENV – LHGMEN

from object library Yes &FRMOBJLIB – –

from source file Yes &FRMSRCFIL – –

from source library Yes &FRMSRCLB – –

user profile Yes &USER – –

project Yes &PROJ – –

comments Yes &COMMENT – –

option name – &OPT &C –

compile in batch – &CMPBCH (*YES/*NO) &P –

to directory (IFS only) Yes &DIR – –

object and to directory (IFS only) Yes &PATHOBJ – –

from directory (IFS only)

Yes &FRMDIR – –

Jobd name – &JOBD &H –

Jobd library – &JOBDLIB &G –

Jobd and library with ‘/’ separator – &JOBDWLIB &J –

COOL:2E model object list Yes &SYNMDOLST – –

COOL:2E object surrogate Yes &SYNOBJSGT – –

AS/SET Application set name Yes &ADKSET – –

AS/SET From application set name Yes &FRMADKSET – –


FieldWorkbench Only


Locks File Field

73


Working With CASE Tools From the Workbench

� COOL:2E: COOL:2E users can call almost any option within any menu function from the Workbench. This option is available using the Process Subfile Selection (YPRCSFLSEL) command and the object surrogate.

� LANSA: Use the LANSA command to perform most LANSA functions from the Workbench. Note that when working with RDML functions the process name is available as &COMMENT10.

� AS/SET: AS/SET users can call multiple AS/SET commands. Most important, is the ability to generate source from the Workbench (GENPGM and GENERATE1 commands).

� J.D. Edwards: J.D. Edwards group names for WORLD Writer and Fastr are available as &COMMENT10.

LANSA partition name Yes &LANPAR – –

LANSA from partition name Yes &FRMLANPAR – –

JDE common library Yes &CMNLIB – –

JDE from common library Yes &FRMCMNLIB – –

Comment (1st 10 char only) Yes &COMMENT10 – –

1 If the value of the PDM mode field in the User Defaults file is O, this variable represents the object name. If the value is M, this variable represents the source member name.

2 If the value of the PDM mode field in the User Defaults file is O, this variable represents the object library. If the value is M, this variable represents the source library.

3 If the value of the PDM mode field in the User Defaults file is O, this variable represents the object type. If the value is M, this variable represents the source member type.


FieldWorkbench Only


Locks File Field

u s e r g u i d e74


Changing User Defaults

From the Workbench, access the Change User Defaults panel by pressing F18=User Defaults.

This panel allows you to change your defaults for Implementer functions. If enrolled in Implementer through a group profile, only a user with User Profile maintenance rights can change the defaults for the group profile. Users with User Profile maintenance rights can set up other users’ defaults as well.

NOTE

These fields can be maintained from Work with Users by selecting a user with option 20=User Defaults to display the Change User Defaults panel.

On the Change user Default panel, no field is provided for Object Library because this information is determined based on the lock information. If you need to override the Object library, prompt the compile command and specify the Object library in the creation command.

Change User Defaults Field Descriptions

The following fields display on the Change User Defaults panel.

75


Edit source on check out

Specify Y or N to indicate whether you want to automatically edit source-based objects after check out. The default value is N.

NOTE

If more than 10 source-based items are checked out at one time, this option is ignored and the source is not edited.

Compile in batch

Specify Y or N to indicate whether you want to submit the compile (Y) or compile interactively (N) for option 14=Compile. This is the default value used by the Workbench Compile (ICOMPILE) command when it is issued from a command line.

Job description/Library

Specify the name of the job description, or *USRPRF to use the job description of your user profile. The job description does not control the library list used to compile; rather, when compiling items locked to environments, the environment library list is used; for objects in a library that are not part of an environment, the library list of the current job is used.

PDM option file/Library

Specify the name of the file and library that contains the member with the user-defined options. These are the default values used by the Workbench Compile (ICOMPILE) command when it is issued from a command line.

Member

When this field is set to the same value as the user’s Work with Members Using PDM options file, the same options available from within PDM are now available from the Workbench. If you want different options, specify a unique name in this field. Either way, the options need to be maintained using the Work with User Defined Options panel within PDM.

PDM mode

Specify O or M to indicate Object, or Member, respectively. This entry indicates whether substitutions are made as if you are using Work with Objects, using PDM (O) or Work with Members using PDM (M). For more information, see the table on page 72.

u s e r g u i d e76


Integrity Manager emergency update active

Indicates whether the Integrity Manager emergency update mode is active for this user. This field applies only when Integrity Manager is the issue tracking system. For more information, see Chapter 3 of the Implementer Multi-Platform Solutions Guide.

Displaying PDM User-Defined Options

You can display user-defined options from the PDM database in the Workbench.

To display PDM options from the Workbench

� From My Workbench, press F16=User Options. The PDM User-Defined Options window displays.

The file and member containing the user-defined options displays at the top of the panel. To change either the file or member used, specify a different PDM options file member on the User Defaults panel.

Processing PDM User-Defined Options

You can process user-defined options from the Workbench by entering the PDM option name in the Option field for any item. After pressing ENTER, the list of substitutions is replaced on the User Option command and processed.

You can prompt the command by pressing F4=List.

77


Working With Members Using PDM (WRKMBRPDM)

You can access PDM by using the Implementer User-Defined Options feature. Complete details on this feature are provided in “Using PDM User-Defined Options” on page 72.

To use the SDA option

1 Select a member with an object code of DSPF or MNU (object attribute DSPF), with option 17 and press ENTER to display the Start SDA (STRSDA) command.

The Start SDA (STRSDA) command defaults with information from the Workbench (*SELECT parameter). You can change the defaults (for example, use 1 to directly access the Work with Display Records panel) or press ENTER to proceed to the OS/400 Screen Design Aid (SDA).

2 Select the required option and press ENTER. When you finish editing and the optional compile of the display file, press F3 to return to the Workbench.

To use the RLU option

1 Select a member with an object code of PRTF (object attribute PRTF) with option 19, and press ENTER to display the Start Report Layout Utility (STRRLU) command.

The Start Report Layout Utility (STRRLU) command defaults with information from the Workbench.

2 Press ENTER to proceed to the Report Layout Utility Design panel.

3 When you finish editing, press F3 to display the Exit RLU panel.

4 Select the required option and press ENTER to return to the Workbench.

To use the Compare option

1 Select a member with option 23 and press ENTER to display the Compare Members (ICMPMBR) command.

In the Compare Members (ICMPMBR) command, the base member defaults to the member in the production environment and the compare member defaults to the member selected in the Workbench panel. For detailed information on using the Compare Members (ICMPMBR) command, see “Compare/Merge Member Commands” on page 385.

u s e r g u i d e78

Workbench Compiles of Locked Objects

2 Press ENTER to process the compare and return to My Workbench panel.

To use the Merge option

1 Select a member with option 24 and press ENTER to display the Merge Members (IMRGMBR) command.

2 In the Merge Members (IMRGMBR) command, the Base member defaults to the member in the production environment and the Merge member defaults to the member selected in the Workbench. For detailed information about using the Merge Members (IMRGMBR) command, see “Compare/Merge Member Commands” on page 385.

a) Change one of the enhanced members parameters (member, file, or library) to identify the third member you want to include in the merge. You can specify up to five enhanced members.

b) Change one of the target member parameters (member, file, or library) to identify the new target member you want to create by the merge.

3 Press ENTER to process the Merge and redisplay My Workbench panel.

4 After merging, use option 2 for Edit, in SEU with the Merge Report to complete development.

Workbench Compiles of Locked ObjectsFrom the Workbench, use option 14=Compile to immediately compile a locked object in a development environment or library. After selecting the member/object with option 14, you can use F4=List to prompt the command, which prompts the actual creation command defined for the associated object code. When using option 14=Compile from the Workbench, Work with Objects, or Work Member PDM all command parameters are automatically completed.

You can issue the Workbench Compile (ICOMPILE) command from any command line. If you prompt the command, the Workbench Compile panel (1 of 2) displays. This option is also available from the Implementer Menu, with option 67, Workbench Compile (ICOMPILE).

79


If the command is called from the command line and a lock exists for the source member name, source file name, and source library name that you specify, the other parameters are automatically completed based on your specification. If you do not see a creation command, press ENTER again to retrieve the correct command.

Only locked objects in development environments can be compiled using this command.

The command processes differently depending on whether the object is checked out to a development environment or to a development library, as follows:

Checked out to an environment Checked out to a library

The library list for the compile is taken from the locked to environment.

The current library list of the job calling the command is used for compilation.

If the authority method is *KEEP, the authority of the existing object is kept. If the authority method is *GRANT or the object does not exist, the authority from the locked to environment is used for the new object.

If the authority method is *KEEP, the authority of the existing object is kept. Otherwise, the library creation authority for the target library is used.

Special commands for the compile step are issued based on the locked to environment definition.

No special command is issued.

u s e r g u i d e80

Workbench Compiles of Locked Objects

Identifying the Compile Object

You can identify the item to be compiled in one of two ways:

� By specifying the lock information:

Complete the Member/object, Object code, and Checked out to LIB/ENV parameters. The ICOMPILE command automatically determines the source file and source library, based on the lock information you supply.

For example, completing the parameters as illustrated next supplies enough information to identify the item to be compiled.

� By specifying the source location:

Complete the Member/object, Source file, and Source file library parameters. Based on the source file information you supply, the ICOMPILE command automatically determines the object code and the checked out to development library or environment.

For example, completing the parameters as illustrated next supplies enough information to identify the item to be compiled.

ICOMPILE Field Descriptions

Member/Object

Specify the name of the member/object to compile.

Object Code

Specify the object code of the member/object to compile, or *SRCFIL to let the source file information specified determine the locked item to compile.

Parameter Value

Member/object (MBROBJ) PGM1

Object code (OBJCODE) RPG

Checked out to LIB/ENV (LIBENV) DEVENV

Parameter Value

Member/object (MBROBJ) PGM1

Source file (SRCFILE) IN10DEV/QRPGSRC

81


Checked out to LIB/ENV

Specify the library or environment the member/object is checked out to, or *SRCFIL to let the specified source file information determine the locked item to compile.

Source file/library

Specify the source file name and library, or *LOCK to let the specified object code and environment information determine the locked item to compile.

Authority method

Specify one of the following values:

Create command

The creation command that was used to create the object displays, although it can be overridden by prompting the command.

The creation command creates the object, as it exists in production currently (or in QA, if it was already changed). The production object is analyzed so it can be recreated in development. All attributes of the new object that can be set on the creation command are retained.

If overrides are made to the creation command and should be made to the new object when it is promoted to production, make sure the same creation command overrides are made when creating the promotion request. From the Workbench, select the member/object with option 14=Compile and use F4=List to prompt the actual creation command defined for the associated object code.

Submit, Job Queue, Library Hold on job queue

Specify the standard OS/400 submit job parameters as required. These fields default from the User Defaults panel.

*OBJCODE Object ownership and authority is based on the specifications for the object code.

*KEEP Object ownership and authority is retained based on the production environment parameters.

*GRANT Object ownership and authority is granted based on the target environment parameters.

u s e r g u i d e82

Workbench Testing of Locked Objects

Workbench Testing of Locked ObjectsImplementer provides a facility to set any job to the library list of an environment.

Setting a Library List From an Environment Library List

The Set to Environment Library List (ISETLIBL) command changes your job library list to that of any environment managed by Implementer. This allows you to change between the appropriate development library list and the corresponding production library list quickly and accurately when testing.

This command is particularly useful when testing a changed application. If you specify a command to call after setting the library list, the original library list is re-established when you return from the called command. For example, assume you use this command to set the library list and automatically run an inventory program that you are testing. Once you exit from the inventory program, the library list that was in effect before testing began is re-established, and you can continue with any activities you were performing prior to running the test.

This facility is also available on the Implementer Menu, option 68, Set to Environment Library List (ISETLIBL).

TIP

Add this command as a user-defined option to the Workbench. The user-defined options TS (Test a Change) and TO (Test an Object) are available. These options are described in “Available PDM Default Options” on page Available PDM Default Options. For instructions on how to set up user-defined options, see “Setting Up User-Defined Options” on page 72.

ISETLIBL Command Parameters

The following parameters define the Set to Env Library List (ISETLIBL) command.

Environment

Specify the environment that the library list is based on. This is a required entry.

List position

Specify the position within the library list to place the environment libraries. The default value is *REPLACE, which replaces the current library list. This is the only valid value.

83


Command

Specify a command to call after setting the library list. When you return from this command, the original library list is re-established. This feature is particularly useful for testing a changed application.

Additional library 1 and 2

You can specify two additional library names. These libraries are added above the environment library list. This feature is useful for adding a personal library to the top of the environment list.

Available PDM Default Options

The following PDM options can be set up to allow access from the Workbench:

For instructions on how to set up user-defined options, see “Setting Up User-Defined Options” on page 72.

Displaying Related ObjectsFrom the Workbench, you can display related objects for *PF, *MODULE, *SRVPGM, and *DTAARA object types. When you select one of these object types with option 8, the Select from Related Objects panel displays.

This panel shows related objects for the object selected on the Workbench. In addition, it shows module where used (usage) and cross-environment relationship information for ILE objects.

Option Purpose Command

TS Test a change ISETLIBL ENV(&envnam)

POSITION(*replace)CMD(call qcmd)

TO Test an object ISETLIBL ENV(&envnam)

POSITION(*replace)CMD(call &object)

u s e r g u i d e84

Promotion Request Overview

Promotion Request OverviewCreating a promotion request is the first step in the process of promoting a member/object into quality assurance or production. The Create Request function allows you to prepare a promotion request from a library or environment to an environment or environment group.

For all source-based member/objects (source member type entered in Work with Object Codes) with object codes referenced in a request, the source member is copied into the request work library. This “freezes” the source members and ensures they cannot be changed after the promotion request is created. To prevent access outside of Implementer, the request work library does not have *PUBLIC authority.

You must promote member/objects in a group if the selected items do not have the same from environment or library, to environment or library, and project number.

If member/objects found are not in the same group as the first item selected, a message alerts you to either process all member/objects as a single group (F16=Add all) or to process them in separate groups. You can use F20=Display, to view member/objects that have not been processed and are still on the Clipboard. Both F16 and F20 are only available if the member/objects are in distinct groups.

85


Promotion Methods

Implementer offers two methods of promotion: the “fast path” one step method and a traditional method. The one step method allows you to promote items using a fast path approach that saves time and effort, thereby minimizing the steps required in the create request function. The traditional promotion method displays the Create Request panel and requires additional input for processing.

The promotion method is defined on a per user basis, and controlled by a flag in Work With Users. When a request is created, the user profile record is validated to determine the promotion method. If the one step method is enabled, the promotion request is automatically created and submitted. If one step promotion is not enabled, the traditional Create Request panel displays for further input.

With the one step method enabled, you can perform any required overrides, for example, changing special commands or object codes, by selecting the items for promotion (option 11=Promote), and pressing F4=List, which displays the traditional Create Request panel. This is beneficial to know because some promotion task variations require processing from the Create Request panel.

The one step promotion method applies to creating requests from the Workbench (option 11=Promote), the Clipboard, and Work with Objects (option 27=Promote). When creating requests from any of the other Create Request menu, panel, or command options (including F22=Promote in the Workbench and in Work with Objects) the traditional Create Request panel defaults.

Creating Promotion Requests

This task describes the various methods for accessing the Create Request function to create a promotion request from the Workbench. The advantages of creating requests from the Workbench include:

� accessibility to locked member/objects located in development

� direct management for concurrent development

� ability to perform multiple inquiries from a single panel

You can access the Create Request function from numerous panels in Implementer. The primary development panels are the Workbench and Work with Objects. You can also access the Create Request function with the menu option 3, the STRIM *CRTRQS command or the Create Request (ICRTRQS) command from the command line or the menu.

The method listed next for creating a one step promotion runs interactively without displaying additional panels (unless an error occurs). The methods listed for creating a traditional promotion request each display the Create Request panel. When you access the Create Request panel from the Workbench and Work with Objects, it initially displays with edited

u s e r g u i d e86

Promotion Request Overview

member/objects. If there are no errors, the message “Press F9=Accept” displays. If errors exist, a message displays and the fields that contain the errors are highlighted. If you access the Create Request panel through the menu or by the function keys, you must press ENTER to edit the information.

You must create a promotion request to promote a member/object from development or quality assurance back into production, or from the host production environment to remote systems. You do not have to create a promotion request from the Workbench, however to do so allows you to associate multiple DRs with a lock on a member/object.

When creating a promotion request, all associated DRs must be at the proper DR status: ready to check out, check out, promote to test, promote to production. The approval must allow you to initiate promotion: No, Yes, Pending for development, test, or production. If errors exist, the error displays and the fields that contain the errors are highlighted.

You can define different default application paths for standard or emergency promotions, at the project level in Work with Projects, or at the environment level in Work with Environments.

NOTE

The Create Request Comments feature is automatically enabled when you install Implementer. This means, when you create a promotion request and press F9=Accept, the Comments panel displays and requires an explanation for the promotion, before allowing you to continue. You can disable this feature without impacting Design Request comments (when the objects being promoted are associated with a Design Request, the comments associated with the primary Design Request are automatically added to the promotion request). For more information, contact your Implementer System Administrator, or Chapter 3 of the Implementer System Administrator Guide.

The following one step promotion task assumes the Enable One Step Promotion flag is enabled for your user profile. Likewise, the traditional promotion task assumes the Enable One Step Promotion flag is not enabled for your user profile. For more information on this topic, see “Promotion Methods” on page 174.

87


To use the one step promotion method

� There are several ways to perform one step create request directly from the Workbench:

� Select the member/object with option 11=Promote and press ENTER.

� Press F8 to access Work with Objects and select the items with option 27=Promote, and press ENTER.

� Select the member/object with option 9 =Add to Clipboard, press F7 to display the Clipboard Processing Menu, and select option 3=Promote.

The Create Request Comments panel displays based on the setting of a global flag in System Control Maintenance. If enabled, type the required comment and press ENTER. The promotion request is automatically created and submitted.

If an error is encountered during the edit check and validation process, the Resolve Promotion Request Problems panel displays, listing the errors you need to resolve. After correcting the errors, press F9 to submit the promotion request.

To use the traditional promotion method

1 There are multiple ways to perform traditional create request directly from the Workbench:

� Select the member/objects with option 11=Promote, and press ENTER to display the Create Request main panel.

� Select the member/object with option 9 =Add to Clipboard, press F7 to display the Clipboard Processing Menu, and select option 3=Promote to display the Create Request main panel or option 5=Emergency Promote. Press ENTER to display the Emergency Create Request main panel.

� For an emergency promotion, select the member/objects with option 22=Emergency Promote, and press ENTER to display the Emergency Create Request main panel.

� Press F22=Promote to display the Create Request main panel and select member/objects from that panel.

2 In the Create Request main panel, press F9=Accept to create the request. See “Performing Promotions” on page 171 for more information.

u s e r g u i d e88

Compiling and Moving Promotion Requests

3 In the Create Request Comments panel, you must enter a comment in order to process the promotion request.

If the member/objects are associated with one or multiple DRs, the DR numbers and titles are automatically included in the comment. The automatic entries fulfill the required comments. You can add other comments if needed.

4 Press ENTER to complete the promotion request creation.

Task Variations When you access the Create Request main panel from the Workbench, your selections are edited. If an error occurs or if more processing is necessary, follow the directions indicated in the message.

� To manage concurrent development, see “Concurrent Development” on page 56.

� To use special commands, override the create request defaults, override submission defaults, promote to additional target environments, copy a request, or to select additional member/objects, see “Performing Promotions” on page 171.

Compiling and Moving Promotion Requests This task describes how to compile and move members from the Workbench.

Typically, you define production environments to automatically run only through the compile step, leaving the move step (and distribution step) to be submitted by someone with move capabilities for the production environment. You can use option 2=Change from the Create Request panel, to change the compile or move request information.

You can also access these functions from Implementer Menu.

NOTE

You do not have to perform this task if you set the environment default for the Auto submit in create request field to Y and the Through step field to 4 (which automatically includes the compile and move steps). In this case, the promotion is initiated when you create the promotion request.

To compile a promotion request

1 Press F14=Compile Request to display the Compile Request panel.

89


2 In the Compile Request panel, type 1 in the option field and press ENTER to submit the compile. For detailed information, see “Compiling” on page 220.

3 After the message displays indicating the promotion request was submitted, press F3=Exit to return to the Workbench.

To move a promotion request

1 Press F15=Move Request to display the Move Request selection panel.

2 In the Move Request panel, type 1 in the option field and press ENTER to submit the move. For detailed information, see “Moving Promotion Requests” on page 224.

3 After the message displays indicating the promotion request was submitted, press F3=Exit to redisplay the Workbench.

Member/Object Status and HistoryImplementer tracks the status and history of member/objects under change management control. The status identifies the current state or application path of the member/object. This is beneficial for knowing, at any point in time, the state, or location of a member/object.

As member/objects flow through the change management cycle, all historical software changes and associated lock information is retained as well. When the status of a member/object changes, the information is updated and the change is recorded in the Status History file (IMSTHS). A status record is created for each environment checked out to, and each environment targeted on a promotion request (a developer’s personal library is treated as a development environment).

The benefit of this is an online audit trail of every action performed to a member/object. You can display the status history for a member/object to verify the action taken, application path targeted when the change occurred, the user who performed the action, and the date and time the action occurred.

u s e r g u i d e90


NOTE

When filtering the Work with Objects panel by the Status field only, a message informs you that filtering by object status only can be time consuming. You have the option to continue with the selected filter, or to return and define additional filters. The display of this message is controlled by Implementer data area IMDSPMSG. For more information, see Appendix A of the Implementer System Administrator Guide.

In Work with Objects, when displaying the status history for an object in production, history displays for all closed locks that were promoted into the production environment. If multiple locks are rejected or promoted at the same time for a single member/object, history is added for each of the locks.

Keep in mind, any changes performed outside of Implementer, for example, changing source with PDM, are not tracked.

The Purge History function removes obsolete lock and promotion request history from environments, as well as status history from production environments.

The following table explains the member/object status codes and descriptions.

Status Description

Chkout-Chg The item is currently checked out for change to a *TST environment.

Chkout-Crt The item is currently checked out for create to a *TST environment.

Chkout-Dlt The item is currently checked out for delete to a *TST environment.

Chkout-Cmp The item is currently checked out for recompile to a *TST environment.

Chkout-Rgn The item is currently checked out for regeneration to a *TST environment.

EmgCO-Chg The item is currently checked out for emergency change.

EmgCO-Crt The item is currently checked out for emergency create.

EmgCO-Dlt The item is currently checked out for emergency delete.

EmgCO-Cmp The item is currently checked out for emergency recompile.

EmgCO-Rgn The item is currently checked out for emergency regeneration.

Src-Edited The source was just edited (implies a compile was not attempted since it was last changed).

91


To display the current status

� From the Workbench or Work with Objects, the current status information displays in initial default view.

The Status field supports subfile filtering. In Work with Objects, filter on Prod to list objects that do not currently have a status assigned. Filter on Open to list all objects that are currently locked—all objects that have a status display, regardless of the status value.

Comp-Fail The source was compiled but the object was not found in development. This status only applies to objects compiled from the Workbench (this status is not assigned when a compile is performed on a promotion request).

Comp-Ok The item is currently in development. The last action was a successful compile. This status only applies to objects compiled from the Workbench (this status is not assigned when a compile is performed on a promotion request).

Dev–>QA1 The item is currently on a promotion request, going from development to a *QAC environment.

Dev–>Prod The item is currently on a promotion request, going from development to a *PRD environment.

In QA1 The item was successfully promoted to the first *QAC environment.

QA1–>QA2 The item is currently on a promotion request, going from one *QAC environment to the next. Allows for QA1 to QA9. After the 9th QA environment, QA+ is used.

QA4–>Prod The item is currently on a promotion request, going from the last *QAC environment to a *PRD environment.

In Prod The item was successfully promoted to a *PRD environment. This status only applies when displaying the history from Work with Objects (the Current Status field on the Status History panel).

Rej–QA1 The item is currently checked out for reject.

Blank The item is currently in production. This status only applies when displaying the history from Work with Objects (the Current Status field on the Status History panel).

Status Description

u s e r g u i d e92


To display the status history

� From the Workbench or Work with Objects, select the member/object with option 28=Status History, and press ENTER. The Status History panel displays.

The current status displays at the top of the panel and the history displays below.

93


Status History Field Descriptions

Member/Object

The name of the member/object you selected to display status history for.

Object Code

The object code associated with the member/object.

Description

The description of the member/object, if one was specified.

Env/dev lb

Lists the environment name and environment description where the member/object is currently located.

Current Status

The current status or application path of the member/object.

Status

The action taken, or the application path targeted, for when the change to the member/object occurred.

Env/dev/lb

The name of the environment or development library the member/object was in or was targeting on a promotion request when the change in status occurred.

User

The name of the user who processed the action that subsequently changed the member/object status.

Event Date

The date the change in status occurred. Keep in mind that for submitted jobs, the event date is the actual date the job ran, not the date it was submitted.

Event Time

The time the change in status occurred. Keep in mind that for submitted jobs, the event time is the actual time the job ran, not the time it was submitted.

u s e r g u i d e94

Online Inquiry of Development Activity

RQS#

Displays the promotion request number, when the member/object is at a promotion-type status. For example, the current status is Dev->QA1 or Qa1->Prod.

Online Inquiry of Development ActivityThis task provides online inquiry of the current activity throughout Implementer. Use this task to identify:

� member/objects currently in development

� who they are checked out to

� the check out to environment

� the target environment

You can access Work with Objects and Request Inquiry directly from the Workbench.

To use the Workbench for inquiry

1 From the Implementer Menu, select option 1, or type STRIM (*WRKBCH) at the command line, and press ENTER to display My Workbench.

Determine the information you want to view, such as:

� what a specific user is currently working on

� current work in process for a specific member/object

� concurrent development in process and status of resolution

� Issues or DRs associated with the lock (Integrity Manager or DesignTracker, respectively, must be installed)

� emergency work in process (standard or emergency locks)

� from and to environments with current activity

� detailed lock information, including lock status

� detailed member information (view or compare members)

� status of a specific project

95


There are two primary ways to use the Workbench for inquiry:

a) To select the specific locks you want to view. General information can be restricted through the filter and position fields. See Steps 2 and 3.

b) To view detailed information use options: 7 for Display (Lock details organized by lock, object, and source information), 23 for Compare, 2 for Display member, and 6 for Print member (to print the source members). See Steps 4, 5, and 6.

2 To position to a specific member/object, type the member/object name. To position at the beginning of similar names, type a partial name and press ENTER.

3 You can filter the lock information fields directly on the Workbench. The most helpful filters are the DR number and project reference for inquiry. These filters can be used for inquiry or (if promoting) to determine if an entity is on a particular DR or associated with a specific project.

To filter on other fields, use F17=Filter to view a subset of the locks. You can use any one (or combination) of the subfile header fields or F17=Filter. This is helpful if you have a great deal of development activity on your system. The subset function allows you to filter on all the detailed information available on the Display and Change Lock panels, by using *ALL, *GENERIC, or specific name and phrases.

For example: In the User field, type the user ID IMPGMR1 and press ENTER. A list of locked member/objects displays for that developer. Now type Std in the Type field and press ENTER. The standard locks for that specific developer display.

To access the five views of the Workbench, press F11. The following information displays:

� Environment (the default view with member/object name, object code, from and to environment, user, project, and lock type)

� Action (action, date, and concurrent development)

� Description (a brief description of the member/object)

� Comments

� Revision (if revision numbers are entered)

4 To view specific lock details (organized by basic, lock, object, and source information), use option 7 for Lock details. The lock information is identical to what displays on the three views on the

u s e r g u i d e96

Working With Locks

Workbench main panel, except that it is located on one panel. For example, the object and source information includes the member/object name, type, from and to files and libraries, and changed dates.

5 Option 23 for Compare compares the production copy of the selected member to the checked out copy by prompting the Compare Members (ICMPMBR) command. The Compare Members (ICMPMBR) command produces a listing of the differences. The option compares the two members in the environment where it was checked out from, and the member in the environment or library it was checked out to.

6 Option 5 for Change displays the selected source member with SEU. Option 6 for Print member prints the selected source member. You can also print the source, if there are major changes.

7 Press F3=Exit to return to the menu.

NOTE

There are developer options for SEU, SDA, RLU, and merge (IMRGMBR). If you use these functions, ensure your current library list is correct.

Working With LocksThe Workbench allows you to manage individual or concurrent development by specifying who is responsible for any specific change.

Changing a Lock

This task changes information related to an existing lock. To change a lock, you must have lock maintenance capabilities and locks must exist on the system.

To change lock information

1 From the Implementer Menu, select option 1, or type STRIM (*WRKBCH) at the command line, and press ENTER to display My Workbench panel.

2 Type 7 next to the lock you want to change and press ENTER to display the Change Lock Details panel. If you do not have the capability to change a lock, this option is inquiry only.

97


3 On the Change Lock Details panel, edit any of the following fields:

TIP

If you change the lock information, it is helpful to add a comment explaining why it was changed.

4 Press ENTER to accept the changes and redisplay the Workbench.

Deleting a Lock This task deletes a lock. If you perform this task on a 3GL member/object, it can also remove the object and source from development. You typically perform this task after a member is checked out and further analysis proves the member/object does not require a change.

When a delete is processed for items in an environment, the lock is removed and the member/objects automatically deleted in the from environment.

When a delete is processed for items in a library, the lock is removed but the member/objects remain in the specified from library. Without deleting the member/objects, references to them are never updated in the repository and inconsistent results can occur in Object Inquiry and Work with Objects. Therefore, if you are deleting a lock from for items in a personal library, you should also issue the Delete Library Reference (IDLTLIBREF) command to clean up the member/object repository. For more information about the IDLTLIBREF command, see Chapter 3 of the Implementer System Administrator Guide.

To delete a lock

1 From the Implementer Menu, select option 1, or type STRIM (*WRKBCH) at the command line and press ENTER to display My Workbench panel.

2 Type 4 next to the lock you want to delete, and press ENTER to display the Confirm Delete of Locks panel.

User profile The user profile that created the lock.

Project reference The project reference created in Work with Projects and either assigned as the default, or changed at the time of check out by the user.

Issue or DR Number

The specific issue or design request number.

Action 1 for Change, 2 for Create, or 3 for Delete.

Lock type Std (standard) or Emerg (emergency).

Comments As required.

u s e r g u i d e98

Working With Locks

Implementer data area IMDLTLOCK controls the default values in the Delete fields on this panel.Your default values and related capabilities may differ from this illustration. For more information, see Appendix A of the Implementer System Administrator Guide.

3 Before confirming the deletion, review the following fields:

4 Press ENTER to confirm deletion and return to the Workbench. (Press F12=Cancel to redisplay the Workbench without deleting the lock.)

Associating Multiple Design Requests With a Lock

This task allows you to associate multiple DRs with a single lock, and can be used to track multiple changes on a single member/object represented by multiple DRs.

If the member/object is associated with a DR, the DR status (Ready to check out, Check Out, Promote to test, Promote to Production) and approval (No, Yes, Pending for development, test or production) must allow the required function. It is possible to associate multiple DRs with a lock on a member/object. All associated DRs must be at the proper approval and status before you can create the promotion request.

To associate multiple DRs with a single lock

1 From the Implementer Menu, select option 1, or type STRIM (*WRKBCH) at the command line and press ENTER to display My Workbench panel.

Delete locks Type Y or N to indicate whether you want to delete the locks for all items that display.

Delete sources Type Y or N to indicate whether you want to delete the source for all items that display for the environment.

Delete objects Type Y or N to indicate whether you want to delete all objects that display for the environment.

99


2 Type 26 next to the lock you want to add multiple DRs to, and press ENTER to display the Work with Design Request Entities panel. If there is a value in the Dsp field, blank it out to display all member/objects. The originally locked member/object (entity) displays.

3 Select the DR:

� By entity: Press F6=Select from entities, to display the Select Entities panel. If there is a value in the Dsp field, blank it out to display all member/objects. Type 1 next to the entity and press ENTER. The Work with Design Request Entities panel redisplays with your newly selected entities (with associated DRs) listed. This option associates a DR to the existing lock if the entity is previously assigned to the DR.

� By DR: Press F7=Select from design request, to display the Select Design Request panel. Type 1 next to the DR and press ENTER. The Work with Design Request Entities panel redisplays with your newly selected DR (and associated entities) listed. If you use this option, you associate the listed entity to the newly selected DR and the lock associated with this member/object.

4 Press ENTER to redisplay My Workbench panel.

NOTE

You cannot associate a DR with a member/object under concurrent development, or associate multiple DRs with a member/object that does not have an existing DR. You must first change the lock (option 7) to associate the DR and the proper project reference. If an Implementer project does not exist for the entity, you must create one.

You can use value *IMPRJ in the Project Name for PM field, which defaults the Proj Ref for Implementer field value (Implementer project name) into the Project name for PM field. For more information, see the DesignTracker User Guide.

u s e r g u i d e100

Changing a Design Request

Changing a Design RequestThis task allows you to view and change Design Request (DR) information associated with a lock, allowing you to determine specific DR information or to update specific DR details (you cannot change all information on a DR with this function).

To view and change DR information

1 From the Implementer Menu, select option 1, or type STRIM (*WRKBCH) at the command line, and press ENTER to display My Workbench panel.

2 Type 15 next to the lock you want to view or change the DR for, and press ENTER to display the Change Design Request panel.

3 Change or view the information. You would usually change the DR status. The DR status controls what information you can change.

4 Press ENTER to accept the changes and redisplay My Workbench panel.


Repeating Workbench OptionsThis task copies a specified Workbench option, from the line it was entered on, through the end of the list of member/objects. It provides a timesaving method for selecting member/objects without entering repetitive options.

To repeat a Workbench option

1 Enter the Workbench option in the Opt column next to the first item you want to process.

2 Press F13=Repeat. The option displays next to each item after the one you selected in Step 1.

3 Press ENTER to process the list.

NOTE

To process only certain items on the Workbench, filter the display before entering an option. For example, if you want to change all RPG programs that display on the Workbench, type RPG in the Code field, and press ENTER before proceeding to Step 2.

101

4Projects

This chapter describes how to create projects. Depending on your use of projects, you can create them with Implementer or ProjectMaster. Projects are extremely helpful for filtering in the Workbench and Work with Objects.


� creating projects

� project paths

� project reporting

� project management capabilities

103

Projects

Creating ProjectsUse this task to create or maintain a project. You can optionally assign the project as the default project for a user profile.

You must create a project before you can check out or create promotion requests, if the environment definition requires a project. You must create a project and associate it with a DR before you can check out or create a promotion request associated with the DR. An Implementer project can be created from within DesignTracker, or an existing project can be associated with the DR from within the Create or Change Design Request function.

You can access Work with Projects from the Project reference field in the Workbench and the Work with Objects panel. You can change the lock detail (option 7 in the Workbench) to include a new project or change the project.

Creating Projects From Implementer

If you check out from DesignTracker, do not use this task. Instead, follow the instructions in “Creating Projects From ProjectMaster” on page 106.

To create projects from Implementer

1 From the Implementer Menu type 15, or type STRIM (*WRKPRJ) at the command line and press ENTER to display the Work with Projects panel.

To position the panel, type the name or partial name of the project in the position field directly above the list of project names, and press ENTER.


Creating Projects

2 From the Work with Projects panel, use option 2 on an existing project to change it, or press F6=Create to create a new project.

3 From the Change Project or Create Project panel, type the description and other information, and press ENTER. The Work with Projects panel redisplays. Project creation is now complete.


Work With Projects Options

The standard options on this panel include 2=Change, 3=Copy, 4=Delete, and 5=Display. The additional options include:

8=Functions

Display the Work with Functions panel.

9=Schedule

Display the Schedule Tasks panel.

10=Workbench

Display the Workbench panel.

12=Promotion Reqs

Display the Request Inquiry panel.

14=Design Reqs

Display the Work with Design Requests panel.

17=Standard Path

Change or display the standard project path on the Standard Project Path panel.

18=Emergency Path

Change or display the emergency project path on the Emergency Project Path panel.

20=Tasks

Display the Work with Tasks panel.

21=Gantt Chart

Display the Interactive Gantt–Daily panel.

105

Projects

Creating Projects From ProjectMaster

You can access DesignTracker from within Implementer to create an Implementer project. Authorized users can create or select a DR from the Check Out main panel. You should use this option for project creation if you check out from DesignTracker.

To create a project from DesignTracker

1 Access the Select Design Request panel using one of the following methods:

� From the Workbench, position the cursor in the Design Request field and press F4=List.

� From the Work with Objects panel, position the cursor in the Default DR field and press F4=List.

� From the Check Out main panel, position the cursor in Design Request field and press F4=List.

NOTE

Depending on your DesignTracker setup, you can display the Define Subset panel before you access the Select Design Request panel.

2 From the Select Design Request panel, either select an existing DR or create a new one.

a) To create a new DR, press F6=Create. The Create Design Request panel displays.

b) Type the title of the DR and any other pertinent information. Alternatively, press F7=Select SR to display the Select Service Request to Attach panel. Select an existing service request to create the new DR from.

c) Press PAGE DOWN twice to display the third Create Design Requests panel. Type the company name.

d) Press ENTER. The Select Design Request panel redisplays.

3 Type option 12 to display the Work with Entity List panel.

4 Press F20=Create IM Project. A message displays stating “Implementer project DTxxxxx has been created”.

Where xxxxx represents the number of the selected DR.

5 Press ENTER to redisplay the Select Design Request panel.

6 Type option 1 next to a DR and press ENTER. The Check Out main panel redisplays.


Project Paths

Setting Up a Default Project

If this project is a default project for a user, perform these steps:

1 From the Implementer Menu, type 41 and press ENTER to display the Work with User Profiles panel.

2 Type 2 next to a user profile and press ENTER to display the Change User Profile panel.

3 Press PAGE DOWN and type the new project reference in the Project reference field. If you want the user to be able to change the project reference number when checking out or creating promotion requests, type Y in the Chg field.

4 Press ENTER to redisplay the Work with Users panel.

5 Press F3 to Exit.

Project PathsImplementer projects can have defined standard and emergency application paths. A path can be defined for each project, representing the development flow of members/objects associated with the project. This type of path is beneficial for those who routinely use multiple testing environments, particularly when the test environments are determined on a project-by-project basis.

For example, if two projects are active in development, it is typical that one environment path is used by one project and another environment path is used by another project at the same time. By using a project path instead of

107

Projects

an environment path, you can avoid having to perform overrides when checking out and promoting items associated with one project that may not be associated with the second project.

When using application paths in Check Out and Create Request, a project path precedes an environment path. In other words, if a project is specified that has a defined path, that path is used; otherwise, the environment path is used. For more information, see Chapter 3 of the Implementer System Administrator Guide.

Project ReportingFlexible reporting and inquiry options are available for project information. Both the Activity Report and Lock Report allow you to sort by project and report within a range of projects. The Activity Report shows detailed lock history and request information. Use the Concurrent Development Report to view either summary or detailed information (including projects) on members/objects that are under concurrent development.

Use the Work with Projects function to display information about locks and promotion requests for a specific project. You can filter the locks that display by project.

Project Management CapabilitiesAdvanced project management capabilities are provided by Implementer, with seamless integration to DesignTracker and ProjectMaster.

Time Entry You can enter time in ProjectMaster using any of three entry methods, in either a cumulative format or using from and to times.

� Developers can enter their own time directly from the Workbench, enabling project leaders to concentrate on project management tasks, or project leaders can enter the time if needed, using option 30=Book Time.

� You can perform time entry anytime during the development process by prompting the Monitor Progress (PMONPG) command from any command line.

� You can enter time through the Select Design Request panel using option 20=Project Tasks.


Project Management Capabilities

Advanced Scheduling Features

You can use ProjectMaster to schedule resources. The advanced scheduling features include scheduling one resource (person) across multiple projects, prioritization of tasks, and dependencies of one task to another.

You can create projects from user-defined templates, eliminating the repetitive setup required to define a project.

You can define resources by the set of activities they are allowed to perform or have the capabilities to do. For example, a junior developer cannot be assigned or automatically scheduled for project management activities. Resources can be set up with a proficiency level, allowing senior staff to perform some activities faster than other staff members.

Advanced scheduling features allow you to make changes such as add or remove a resource, change proficiency levels, change the amount of time a task requires, or change dependency assumptions.

You also can create project benchmarks. This allows you to compare the current project schedule to the original project schedule or to an interim benchmark. This is useful for comparing project status to a revised schedule, while retaining the ability to report against the original schedule.

Reporting Capabilities

Project reporting capabilities include:

� Weekly and cumulative time sheets

� Gantt charts

� Cost analyses

� Planned versus actual reporting

109

Projects


5Performing Check Out

This chapter describes the tasks related to check out. When you check out a member/object from a production environment or a quality assurance environment, Implementer copies it to a developer’s development library or an environment. When the check out is complete, Implementer secures a lock on the object to identify the user who has it checked out and for what purpose. You can optionally check out members/objects attached to an Integrity Manager Issue or a DesignTracker Design Request.


� check out fundamentals

� check out methods

� object version stamping

� checking out IFS files and directories

� concurrent development

� checking out related objects

� checking out with a Design Request

� using ILE object codes

� checking out physical file data

� using different source and object names during check out

� user authorities

� checking out for reject

� object name rules

� check out commands

� converting RPG/400 or RPGIII source code to ILE RPG/400

� converting CRTBNDxxx ILE programs to CRTPGM style programs

� checking out using PathFinder for information

111

Performing Check Out

Check Out Fundamentals This task checks out one or more members/objects. Implementer places members/objects in a development environment or library so that development work can begin on them.

Implementer places a lock on the members/objects that are checked out with this function. The lock indicates both the environment the member/object was checked out from and the development library or environment that it was checked out to.

The lock ensures that no other user can unknowingly change the same item. The lock is automatically removed once the item is promoted back into a production environment. Locks are not removed for a member/object promoted to a test environment. Locks can be associated with DRs and projects. You can associate multiple DRs to a single lock.

You can optionally work on two separate copies of the member/object. This is referred to as concurrent development. If concurrent development exists for a member/object, you must resolve the conflict for each lock.

Developers must be authorized (in Work with Users) to use the Check Out function, as well as be authorized (in either Work with Users or Work with Environments) to check out to and from the environments specified.

At times, it is necessary to either add special functionality or ensure that specific tasks are completed at specific times under certain conditions. Special commands provide the facility to issue external commands and programs during the check out process. Special commands in check out are defined at the environment level, and they can automatically run for each check out processed to that environment.

For more information, see “Special Command Processing” on page 229.

Implementer also provides the Execute Checkout (IEXCCKOCMD) command, a special command that allows you to distinguish certain items during check out for additional special command processing.

It is possible that certain types of objects are restricted (deactivated) from check out. Various methods exist for restricting object codes:

� Object codes can be restricted at the object level, in Work with Object Codes. For example, this could be done if your organization does not plan to use certain types of objects.

� Object codes can be restricted at the environment level. For example, this could be done because a particular application does not have System/38 environment programs.

� Object codes can be restricted at the user level. For example, this could be used to control database administrator rights.


Check Out Methods

Check Out MethodsImplementer offers two methods for processing a check out—the “fast path” one step method and a traditional method. The one step method allows you to perform check out for change using a fast path approach that saves time and effort, thereby minimizing the number of steps required in the check out function.

The traditional method, which is more interactive, requires you to access and define more panels. Both methods provide access to many of the same features and produce the same results. The major benefit to the one step method is that after selecting the items for check out, the automatic process runs quickly, and the Workbench panel displays with your current locked items listed.

The default check out method is defined on a per user basis in Work with Users, controlled by the Enable One Step Checkout flag. When initially installing Implementer, the one step method is enabled by default. For subsequent upgrades, the value defined at the time of the upgrade is retained. For more information, see Chapter 3 of the Implementer System Administrator Guide.

Using the One Step Checkout Method

The one step check out method applies to checking out from the Workbench (F6=Check Out), the Clipboard, and Work with Objects (option 1=Check Out and option 21=Emergency Check Out). When using any other Check Out option (including, option 27 in the Workbench or F20 in Work with Objects), the menu options, or Check Out command options the traditional Check Out function is performed.

When issuing a check out, the user profile record is validated to determine the default check out method. If the one step method is enabled and the check out is initiated from the Workbench, the Workbench Check Out panel displays for member/object selection. With the one step method enabled, you can perform any required overrides from the Workbench Check Out panel with F4=Prompt, which displays the traditional Check Out panel with any selected items populated. (Some tasks later in this chapter require processing from the traditional Check Out panel.) If check out is initiated from Work with Objects, the check out occurs automatically. If one step check out is not enabled, the traditional Check Out panel displays (requiring further input).

In one step check out, Implementer sequentially determines the default from environment in the following order:

1 In the Workbench, if a project reference is specified, the From environment associated with the project’s path (if a path exists).

113


2 In the Workbench, if a from environment filter is specified, the value entered in the From Env filter field defaults.

3 If existing, the From Environment value of the first record in the Workbench subfile defaults (the first environment listed under the From Env filter line).

4 If specified in Work with Users, the default Check Out From Environment value for the user performing the check out defaults.

5 If the previous attempts to retrieve an environment name are not successful, the Environment Selection panel displays to select from a list of valid check out from environments.

If errors are encountered while Implementer performs pre-processing edit checks and validations, the Resolve Check Out Problems panel displays the specific errors. You must resolve the errors before continuing.

To perform a one step check out

1 Access the check out function using any of the following methods for standard one step check out:

� From the Workbench, press F6=Check Out (the Workbench Check Out panel displays with all member/objects in the from environment loaded). Select the items with option 1=Check Out and press ENTER.

Alternatively, press F16=Select All to check out all items in the specified from environment. A message displays informing you that you are about to check out all items in the specified


Check Out Methods

environment. You can press ENTER to continue with the check out, or press F3 to return to the Workbench Check Out panel.

� From Work with Objects, select the member/object with option 10=Check Out and press ENTER.

� From the Workbench or the Work with Objects panel, select the member/object with option 9=Add to Clipboard and press ENTER. Process the clipboard with F7=Process Clipboard and use option 2.

2 The check out occurs automatically and the reloaded Workbench panel displays. A message displays indicating that the members/objects were checked out. A lock is created for each checked out member (to indicate work in process), and a copy of the member (or object for non-source-based objects) is created in the development library or environment.

NOTE

If you select objects with option 1 and then attempt to reposition the subfile, the selected objects are processed through to completion (checked out and a lock attached) and the Workbench Check Out panel displays at the selected position.

Using the Traditional Checkout Method

Traditional Check Out displays the Check Out panel. In the Check Out main panel, you can enter individual members/objects (and object codes) or select them from a list. This option is only available if the Build List function was run. The Build List function creates a list of all members and objects that exist in the environment’s library. The list displays in multiple panels throughout Implementer. The list is dynamically updated while continuously using the product. For detailed information on the Build List function, see the Implementer System Administrator Guide.

The members/objects that are selected for check out directly from the Workbench are already checked out; however, you can also use the Check Out function to initiate concurrent development. Alternatively, initiating a check out in this way provides a quick way to check out like—in other words, using an existing check out to create a check out for a similar member/object. This process is detailed in “Using the Workbench for Development Activities” on page 49.

Checking out from the Workbench initiates concurrent development so that you must select a specific version. This occurs because the Workbench shows only locked objects.

115


To perform a traditional check out

1 Access the check out function using any of the following methods for standard traditional Check Out:

� From the Workbench (which shows locked objects only) select option 27, or from the Work with Objects panel, select option 10 and press ENTER.

� From the Workbench press F6=Check Out.

� From Work with Objects press F20=Check Out.

� From the Workbench or the Work with Objects panel, select the member/object with option 9=Add to Clipboard and press ENTER. Process the clipboard with F7=Process Clipboard and use option 2.

� From the Implementer Menu, select option 2, or type STRIM (*CHKOUT) at the command line, and press ENTER to display the Check Out main panel.

� If you use a design request, you can also use F10=Select entity.

� If the member/object is in a quality assurance environment, use option 20 for Reject to display the Reject Change panel. For more information about rejecting changes from QA environments, see “Checking Out for Reject” on page 153.

2 Complete the Check Out panel as described in “Check Out Panel Field Descriptions” on page 118.


Check Out Methods

3 Press ENTER to verify the selected entities. If everything is correct, the message “Press F9=Accept to check out.” displays.

4 Press F9=Accept to perform the check out. A message displays indicating that the members/objects were checked out. A lock is created for each checked out member (to indicate work in process), and a copy of the member (or object for non-source-based objects) is created in the development library or environment.

Emergency Check Out

If authorized, you can access Emergency Check Out using any of the following methods:

� From the Workbench or Work with Objects panel, select option 21 for Emergency check out.

� From the Clipboard Processing menu, select option 4.

� From the Implementer Menu, select option 21, or type STRIM *ECHKOUT and press ENTER.

A similar panel can be accessed from the traditional Check Out panel by using option 20 for rejecting a member/object with an emergency lock.

For more information about Emergency Check out, see “Handling Emergency Situations” on page 295.

NOTE

For emergency check out, the one step check out method applies when the check out is initiated from Work with Objects, option 21=Emergency Check Out and from the Clipboard, option 4=Emergency Check Out.

Vendor Integration Considerations

� PathFinder users should note that PathFinder’s Where Used function shows ILE *MODULE objects that uses a file. However, it does not show the ILE *PGM and *SRVPGM objects that use the file because they contain those *MODULE objects. To ensure that level checks do not occur in the *PGM and *SRVPGM objects, use PathFinder’s Where Used function to list the *PGM and *SRVPGM objects containing the *MODULE objects. Then, add these objects manually to your check out requests.

Similarly, since PathFinder does not support cross-environment functionality within Implementer, you must use PathFinder’s “Where Used” feature to list the related objects in different environments.

117


Then, manually create the appropriate check out for these related objects.

� AS/SET definitions can be checked out from/to specified AS/SET environments that are defined in Work with Environments. When checking out AS/SET definitions, you must use the specific object codes defined with special characteristics starting with ADK.

If you are managing AS/SET help for display programs, create a separate object code with the special characteristic ADKHLP to check out or promote the help text associated with the display programs.

� If the member/object is a LANSA object, the from and to environments must be LANSA environments. Checking out to a library is not supported for LANSA objects.

LANSA objects entered or selected for copy are added to an export list if the environment specifies to copy LANSA objects during check out. Implementer supports checking out multiple LANSA functions with the same name and object code of different processes, when the process name is specified in the first ten characters of the Comment field.

If you do not enter the process name in the Comment field, the function is checked out from the first process containing the function. The name of the process displays in the Comment field and can be changed if the LANSA function will be checked out from a different process.

Check Out Panel Field Descriptions

The following fields display on the Check Out panel.

From environment

Use one of the following methods to identify the environment to check out from:

� If displaying, use your default From environment retrieved from the project path, environment path, or user profile.

� To list an environment to check out from, position the cursor on the From environment field and press F4=List. Type 1 next to the environment and press ENTER.

� Enter the specific environment to check out from.


Check Out Methods

To library/To environment

If you are using a default project path or environment paths (either standard or emergency), the From environment and the To environment or library defaults are based on the current location of the item. This can be a library or an environment.

If the member/object is in an environment when you begin promotion, the next project or environment path entry for the request type (standard or emergency) is used as the next promotion location. This could be an environment or an environment group.

If the environment that the member/object resides in is part of multiple paths (and the item is locked), the path associated with the check out from environment is used.

Use one of the following methods to identify the development location to check out to:

� If displaying, use your default to environment retrieved from the project path, environment path, or user profile.

� To list an environment to check out to, position the cursor on the To environment field and press F4=List. Type 1 next to the environment and press ENTER.

� Specify the environment to check out to.

� You can check out LANSA objects only to a specifically defined LANSA environment.

� You can check out AS/SET definitions only to a specifically defined AS/SET environment.

� Specify the library to check out to.

� You cannot check out AS/SET definitions to a library.

� You cannot check out LANSA objects to a library.

Project reference

Use one of the following options to identify a project.

� If displaying, use your default project.

� To list a project reference, position the cursor on the Project reference field and press F4=List. Type 1 next to the project, and press ENTER.

� Type a valid project reference.

119


If you specify a project that has a defined application path, the from and to environments default from that project’s path.

NOTE

If you want to use a design request, see “Checking Out With a Design Request” on page 141.

Member/object list

Use one of the following methods to identify the members/objects to check out:

� Accept the members/objects you selected in the Workbench or Work with Objects functions with option 10 for check out or the clipboard.

� Position the cursor on a Member/object field and press F4=List to select from a list of members/objects.

If you use related environments, the members/objects are listed in the sequence established for related environments. Use F8=First occurrence to display all the members/objects in different related environments, or display the first occurrence of the member/object that exits in the related environments list.

The two most common uses for related environments are to develop one release of an application while you continue applying changes to an earlier release (for example, release 2.0 based on release 1.0). Secondly, to keep production modifications in a separate environment from base production. In each case, the related environment list must include all of the environments you want to define as related environments.

� Specify a member/object name and code on this panel. The action defaults to 1 for change.

� Press F8=Select from object codes to select from a list of object codes:

1Type 5 next to the object code and press ENTER to display the Member/Object Selection panel. This list contains all member/objects associated with selected object code for the environment.

2In the Member/Object Selection panel, type 1 next to the members/objects and press ENTER. A message displays indicating you selected some members for check out. Press ENTER again to display the Check Out panel. The previously selected members/objects now display on the Check Out panel.


Check Out Methods

Action

Specify the action to be taken in the production environment with the members/objects being checked out. For example, if you want to replace an existing program in production with a new program, the new program action is 2 for Create. This reserves the program name, and the existing program action is 3 for Delete (to remove it after the new one replaces it during promotion).

Task Variations The following task variations explain how to perform additional actions to members/objects during check out.

Deleting a Member/Object

To delete the member/object in the target environment when the member/object is promoted, specify an action of 3 for Delete.

Creating a New Member/Object

� To create the member/object in the target environment when the item is promoted, specify an action of 2 for Create when checking out.

Some companies refer to this as reserving the name. The member/object is actually created in the development library if SEU automatically displays after check out completes. This flag can be set on a per-user basis. If SEU does not automatically display, only a lock record is created in Implementer, which still prevents anyone else from accidentally creating a new member/object of the same name.

You can also create a member/object by copying an existing member/object. This can be done in two ways. With either method you begin by accessing the Check Out panel from either: the Implementer Menu option 2, from Check Out, or from the Workbench by pressing F6=Check Out (to display the Workbench Check Out panel) and then press F4=Prompt. Enter the member/object name and object code on

1 = Change To change an existing member object.

2 = Create To create a new member/object in the production environment. When creating a new member/object, you can optionally designate an existing member/object to copy from. The lock for a new member/object only locks the use of the name because there are no source members or objects to lock.

3 = Delete To delete an existing member/object from the production environment when the item is promoted. The production environment at promotion is the target environment.

9 = Recompile To recompile an existing member/object.

121


the Check Out panel. Then, use one of the following methods to identify the member/object and location to copy from.

� To copy a member/object to a different name in the To environment, press F7=Fold, and enter an existing member/object name, source file, and library to copy from in the appropriate fields.

� To copy a member/object to the same name in the To environment, enter the name of the From environment in the Copy env field on the Check Out panel. There is no need to use the F7=Fold function.

NOTE

The F7=Fold function is not available for AS/SET definitions. The only copy function valid for AS/SET definitions is the copy from environment, which displays on the main Check Out panel.

F7=Fold Field Descriptions

The following fields display when you press F7=Fold view.

Copy from mbr/obj

Specify the member/object to copy.

Copy from source file

Specify the source file where the copy from member exists.

Copy from library

Specify the library where the copy from member exists.

Check out to user

Specify the name of a specific user to check out to, or specify *USRPRF to check out the member/object to the current user. This parameter allows project leaders to check out member/objects to specific developers.

Allow type/attr chg

Specify whether the member is copied when the type does not correspond to the object type being created. Type Y to allow the change or type N to not allow the change.

Revision number

Specify a version number that will override the next version number to be assigned. When setting the version number in check out, validation is performed to ensure that the version number entered is valid for the


Check Out Methods

specified versioning method. In addition, for existing items, it verifies that the value being assigned is not less than the value attached to the object in the *PRD environment. If the version number is invalid, a message displays informing you of the problem. If a version number is not entered, the next available version number defaults.

For example, all objects for the current release exist in production with version number 2.0. When they are checked out, the next version number automatically assigned would be 2.1. However, you are now ready to begin development on the next release—3.0. By checking out the applicable objects and overriding the revision number (in this case to 3.0), you are able to keep member/objects and version numbers synchronized with the release number.

Checking Out Single Source With Multiple Objects

Implementer supports checking out multiple objects that have single source members, allowing you to use a single source member to create multiple objects. This practice, which is seen most commonly with physical files, works for all source-based objects.

This feature uses the Implementer Multiple Objects (IMMULTOBJ) data area. Set the data area value to *YES to allow the check out of an object that has multiple objects with the same source member. Specify *NO if you do not want to allow the check out if this condition occurs (this is the default value). For more information about the IMMULTOBJ data area, see Appendix A of the Implementer System Administrator Guide.

CAUTION

The check out of single source members with multiple objects is not recognized as a concurrent development condition. Therefore, if you enable this data area be aware that you can overwrite changes to objects that are checked out and changed but not promoted through to production yet.

Common Questions

Does the comment field on the Check Out panel correspond to the source member or object text?

This field allows you to enter a brief reason why this member/object was checked out.

For LANSA functions that exist in multiple processes, Implementer requires the process from the function to be checked out in the first 10 characters of the comment field.

For the J.D. Edwards special object types WORLD Writer and Fastr, you must enter a group name in the first 10 characters of the Comment field.

123


What causes a message stating the member already exists in the to library?

If someone placed the member into the target library without using Implementer, this message could occur. It could also occur if the option to remove source from the development library was set to N on a previous promotion request, or if you deleted a lock and did not remove the members/objects.

What happens if someone else attempts to check out the same member/object?

If the second user is authorized for concurrent development, they are prompted to check out a specific version for concurrent development. At promotion, the created conflict must be resolved for both versions of the member/object.

During check out, is the source member removed from the production source library?

No. The source member is copied.

What’s the difference between the Workbench Check Out panel and the traditional Check Out panel?

Functionally, these panels are the same; however, the Workbench Check Out panel displays only if you have the one step check out method enabled for your user profile. Both panels allow access to the same options, and from the Workbench Check Out panel, you can access the traditional Check Out panel to perform any functions not directly available from the Workbench Check Out panel. The benefit to using the Workbench Check Out panel is ease of use automation, and the fast path processing that occurs when the check out runs.

Can one step check out be set up on a per developer basis?

Yes. The flags that control the check out method are at the user level (defined in Work with Users). You can enable this flag based on the needs of each developer.

Keep in mind that the one step check out method applies to checking out from the Workbench, the Clipboard, and Work with Objects. Any other Check Out option (including the commands and menu options) invokes the traditional method.


Using Object Version Stamping in Check Out

Using Object Version Stamping in Check Out

Implementer provides for object version stamping of items under change management control. This feature is beneficial for easy auditing and the identification of deployed objects. Object version stamping can be implemented in association with or independent of another feature Issue or Design Request stamping.

With object version stamping, each object, lock record, and repository record is stamped with a version number at predetermined stages within the development cycle. The version number scheme and development stage in which the object is stamped (check out only, check out and promotion, or user-defined) is determined by the versioning method. Implementer automatically determines and increments the version number based on the versioning method.

With issueor DR stamping, each object is stamped with the issue or design request number that the object was checked out for. When multiple locks exist with multiple issues or DRs, the object is stamped with the primary number associated with the initial lock. To ensure stamping of both existing and newly created objects, stamping automatically occurs in the stages at which an object can be created—check out, compiling from the Workbench, and promotion.

In addition, the description of the object is changed by updating the APAR ID attribute with the revision number, and the PTF Number attribute with the issue or DR number. This can be viewed by issuing the Display Object Description (DSPOBJD) command.

NOTE

The activation and control parameters for both object version stamping and issue or DR stamping are maintained in System Control Maintenance. For more information, see Chapter 3 of the Implementer System Administrator Guide.

Processing Versions in Check Out

For a check out action of Change, Create, Regen, or Recompile, the revision number is validated; for an action of Delete, versioning is ignored. When creating a new object, the revision number defaults to 1 or 1.0 (based on the versioning method), unless a user-defined versioning method is defined.

You can override the next version number to be assigned by specifying a value in the Revision number field, which displays when you invoke the F7=Fold view of the traditional Check Out panel. To enter a revision

125


number in check out when one step check out is enabled, from the Workbench Check Out panel, press F4=Prompt to display the traditional Check Out panel, and press F7=Fold.

When setting the version number in check out, validation is performed to ensure that the version number entered is valid for the specified versioning method. In addition, it verifies that the value you are assigning is not less than the value attached to the object in the *PRD environment. If the version number is invalid, a message displays informing you of the problem. If a version number is not entered, the next available version number defaults.

Validation is performed regardless of where the check out occurs from—the Workbench, Clipboard, Check Out menu option, Emergency Check Out, Check Out (ICHKOUT) command, Check Out IFS (ICHKOUTIFS) command, archive recovery, or a COOL:2E check out. When checking out from the Check Out panel, after pressing ENTER the Revision field displays the value that the object will have when it is checked out (if you did not override the value). When using the ICHKOUT and ICHKOUTIFS commands and a version number is not entered, the next available version number is assigned and the check out proceeds without displaying the value.

The version number displays for each object that has a version number assigned, in the Revision field in the Workbench (F11=Display Revision) and in Work with Objects (F10=Display Revision).

NOTE

If an object is checked out while versioning is inactive and versioning is then activated, the object is compiled without a stamped version number.

If object versioning is inactive and a version number is specified in check out, an error message displays to notify that versioning is not active.

Rejecting an object from a *QAC environment causes a revision number increment.

Object versioning performs the same in Emergency Check Out. For example, object A exists in the *QAC environment with version number 3.2. Emergency check out is performed, and object A now exists is the *TST environment with version number 3.3. The emergency lock for object A is promoted to production changing the version number to 4.0. When the object in *QAC (version 3.2) is promoted to production the version number will change from 3.2 to 5.0.


Checking Out IFS Files and Directories

Checking Out IFS Files and DirectoriesThe Integrated File System (IFS) files and directories can be checked out using the same basic option used for any OS/400 object. Additional options for checking out IFS objects include:

� listing individual IFS files

� listing individual subdirectories

� specifying *.* to check out an entire environment

� specifying the IFS long name

� issuing the Check Out IFS (ICHKOUTIFS) command

The IFS files and directories must be checked out to an environment rather than to a personal directory, and checked out from a host (local) environment or directory.

When checking out an IFS object using a new object code not included in the Implementer list of object codes, Implementer will automatically add the new object code to the list provided this feature is enabled in System Control Maintenance. For more information, see Chapter 3 of the Implementer System Administrator Guide.

IFS Object Naming Conventions

Within Implementer, the member/object name of an IFS file contains the IFS file name and the object code contains the dot and extension.

Implementer converts any name longer than eight characters and any extension longer than six characters (allowing one position for the “.”) to a derived, short member/object name.

Additionally, depending on your IFS naming conventions the tilde character (~) is assigned to an object name. For example:

File BOOK.NSF has an assigned object name of BOOK and an object type of NSF; object BOOK.NTF has an assigned object name of BOOK and an object type of NTF. When you check out file BOOK.NTF, Implementer verifies the entire file name—BOOK.NTF—for an existing assigned short name. If it exists, it is used. If it does not exist, Implementer attempts to assign a pseudo object name and verifies the name BOOK; however, since an entry for BOOK already exists it assigns the next available entry BOOK~1.NTF (rather than BOOK.NTF).

To check out individual IFS files

1 Perform a check out by accessing the traditional Check Out panel using any method specified earlier in this chapter.

127


2 At the top of the Check Out panel, specify From and To environments that are set up to manage IFS objects. To specify IFS files, type the file name in the Mbr/obj field, and type the extension in the Code field. For example, to check out the file ITEM.EXE, type ITEM in the Mbr/obj field and .EXE in the Code field.

NOTE

If an IFS object being checked out already exists in the target environment, a warning message allows you to bypass the check out of the duplicate object and leave the original object in place.

To check out subdirectories


2 At the top of the Check Out panel, specify From and To environments that are set up to manage IFS objects. To specify IFS subdirectories, type the directory name in the Mbr/obj field, and type a backslash (\) in the Code field. For example, to check out the subdirectory SUBDIR2, type SUBDIR2 in the Mbr/obj field and \ in the Code field.

NOTE

Although not a common practice, it is possible to have subdirectories with extensions. In this case, specify a backslash (\) followed by the extension in the Code field. For example, to check out the subdirectory SUBDIR2.DIR, type SUBDIR2 in the Mbr/obj field and type \.DIR in the Code field.

Checking Out Using the IFS Object Name

This is typically only necessary for IFS objects not previously checked out when a member/object name is not yet established. Using this method, you can enter an IFS name that is used to generate the member/object name, allowing you to uniquely identify IFS objects. The IFS object is then checked out using the member/object name.

To check out using the IFS object name


2 At the top of the Check Out panel, specify From and To environments that are set up to manage IFS objects.

3 Press F6=IFS Entry. The Convert Long Name and Post to Checkout window displays.



4 Type the IFS name and press ENTER. The Check out panel displays with the IFS object added to the panel with the generated member/object name.

5 Proceed with check out as normal.

Checking Out the Contents of an Environment

When checking out and promoting IFS files and directories using *.*, keep in mind that when promoting IFS files and directories, Implementer does not completely replace the contents of the target environment with the promoted IFS objects. The management of new, existing, and deleted IFS objects is as follows:

� New Objects: When an IFS object being promoted does not exist in the target environment, that object is added to the target environment.

� Existing Objects: When an IFS object being promoted already exists in the target environment, the existing object is deleted in the target environment and replaced with the promoted object.

� Deleted Objects: When no IFS object corresponds to any that exist in the target environment, the existing object is left in the target environment.

TIP

To ensure that only the IFS objects contained in the promotion request are stored in the target environment, be sure to clear the target environment of all objects prior to initiating the promotion request.

129


Mixing Individual Files and *.* Items

If after checking out individual items you decide to check out and then promote the entire contents of an environment using *.*, consider the potential results of this combination.

For example, assume that you initially check out a single IFS file, FILE1.TXT. After making changes and saving the file, you realize you need to change more files in the environment so you check out the entire environment’s contents to the same target environment using the *.* method. This action overwrites the FILE1.TXT that was already in the target environment, which may have been the result you wanted. If you want to retain your changes, you need to check out the additional files by specifying them as individual files.

Continuing with the example, when you later promote the environment’s contents using the *.* method, the unchanged FILE1.TXT is moved back into production. Additionally, if the Remove from objects field on the Create Request panel is set to Y, file FILE1.TXT no longer exists in the directory in the From environment since the file was also checked out individually. The locks placed on the file during the initial check out still exist, although the file does not. You can correct this situation by manually deleting the lock on the file. Again, this situation can be avoided by continuing to use the single file method for your promotion.

TIP

For most purposes, use the same check out method each time you perform a check out to the same target environment. Continue to use this method when creating promotion requests for the checked out IFS objects.

To use *.* to check out the entire contents of an environment


2 At the top of the Check Out panel, specify From and To environments that are set up to manage IFS objects. To specify the entire contents of an environment, type *.* in the Mbr/obj field, and type a backslash (\) in the Code field.

Check Out IFS (ICHKOUTIFS) Command

This task allows you to check out using the Check Out IFS (ICHKOUTIFS) command rather than the menu interface. You can issue the ICHKOUTIFS command from a command line within Implementer or embed the



command in your own user program. You can also embed the command as a user option in PDM, ABSTRACT, or PathFinder to further automate the check out process.

This command is additionally used for the MKS Integrity Solution multi-platform integration and development, to load the build numbers (the version of objects coming from the desktop). For more information about this feature, see the Implementer Multi-Platform Solutions Guide.

Developers must be authorized to perform check out, authorized to the object code, and to check out of the from environment. Specifying a project number is necessary if defined in System Control, or when using a project path.

To use the ICHKOUTIFS command

1 Type ICHKOUTIFS at a command line and press F4=Prompt.

2 Complete the parameters as defined next, and press ENTER to issue the command.

ICHKOUTIFS Command Parameters

From environment

Specify the environment to check out from (you must be authorized to check out from this environment). Check out is allowed from production (*PRD) or quality assurance (*QAC) environments.

Specify a project reference value and the default environment value *PATH and Implementer attempts to derive the environment value from the project path. If that is not successful (indicating the specified project does not have an application path defined), it looks for an environment path. If that is not successful the *PATH value is not replaced, and a message displays stating that you must enter an environment name.

*PATH Derives the environment from the project path for the project specified in the Project Reference parameter. A project path must exist to use this value. If a project path does not exist, it defaults to the environment path. If an environment path does not exist, a message displays stating you must specify an environment name. *PATH is the default value.

*USRPRF Derives the environment from the value defined as your default check out from environment, in Work with Users.

Char value Specify the environment name. The environment is determined from the environment path established for the specified environment.

131


To environment

Specify the environment or library to check out to.

Project reference

Specify the project associated with the object check out. This parameter is not valid when Integrity Manager is the enabled issue tracking system.

Issue or design request

If you manage work with Integrity Manager issues or DesignTracker DRs, specify the number associated with the object being checked out.

Lock type

Specify the type of check out and corresponding lock to place on the object.

Object

Specify the IFS name, in path\name format, of the object to check out.

*PATH Derives the environment or library from the project path of the project entered in the Project Reference parameter. A project path must exist to use this value. If a project path does not exist, it defaults to the environment path. If an environment path does not exist, a message displays stating you must specify an environment or library name. *PATH is the default value.

*USRPRF Derives the value from the value defined as your default check out to environment or library, in Work with Users.

Char value Specify a valid environment or library name.

*USRPRF Derives the default project reference defined to your user profile, in Work with Users. This is the default value.

*DRNBR Derives the project reference from the design request specified in the Issue or Design Request parameter.

Char value Specify a valid project reference. If the user profile does not have an assigned default or if you are checking out to different environments, specify the project reference.

Number Specify a valid issue or DR number.

*NONE Specifies that the member/object is not associated with an issue or DR. This is the default value.

*STD Standard check out/lock. This is the default value.

*EMERG Emergency check out/ lock.



Action

Specify the action to be taken in the production environment for the object.

Lock comment

Type a comment to describe the reason for check out.

Revision

Specify the revision number to assign (if applicable). This value will override the next version number to automatically be assigned.

Validation is performed to ensure that the version number specified is valid for the defined versioning method. For existing items, it verifies that the value being assigned is not less than the value attached to the object in the *PRD environment. If the version number is invalid, an error message displays. If a version number is not entered, the next available version number is the default value.

“Copy from” environment

Specify an environment to optionally copy object from. It is also the copy location when creating concurrent development and copying the item from another location. If the selected object is currently in development (checked out and locked), change the default from *NONE to the location you want to select it from.

“Copy from” object

Specify the name of an existing object on which to base a new object. This object must exist on the host system—it cannot be copied from a remote system. The object must exist in the environment specified as the Copy from environment. The default value *OBJ copies the object specified in the Object parameter.

*CHANGE The object will be changed. This is the default value.

*CREATE The object will be created.

*DELETE The object will be deleted.

Name Specify the environment name.

*FRMENV Copies the object from the environment specified in the From environment parameter.

*NONE The object is not copied. This is the default value.

133


Ignore warning messages

Specify whether to ignore warning messages encountered during check out. For example, a warning indicating the object already exists in the check out to environment.

Replace existing members

Specify how to handle checking out to a location where the member already exists.

Submit

Specify the standard OS/400 submit job parameter as required.

Job queue

Specify the job queue for the command to run in.

Library

Specify the library for the job queue.

Automatically Creating Object Codes in Check Out

If enabled, Implementer automatically creates new object codes when you check out IFS files or directories with extensions that do not currently exist in Work with Object Codes.

To determine if this option is enabled, contact your System Administrator.

To create an IFS object code during check out


*NO Ignores warning messages.

*YES Displays warning messages. This is the default value.

*YES The current member replaces existing members.

*NO The current member does not replace existing members. This is the default value.

*IGN Creates a lock using the existing object in the check out to location.

Name Specify the job queue name.

*PRODUCT The job queue defined as the default job queue in data area IMJOBQ is used. This is the default value.

Name Specify the library name if the library is not on the library list.

*LIBL Retrieves the library from the library list. This is the default value.



2 At the top of the Check Out panel, specify From and To environments that are set up to manage IFS objects. If the object code (preceded by a dot (.) for a file and a backslash (\) for a directory) does not currently exist, a message displays, as illustrated next.

3 Type one of the following values in the Reply field and press ENTER to create the new object code:

Support for Multi-Platform Check Out

Implementer provides support for your client/server and e-Business applications by offering check out and promotion deployment of IFS objects using a browser interface. This browser-based integration is built on the existing proven framework of Implementer technology, which includes the latest support for IFS technology and the change management of client/server development. For more information, see the Implementer Multi-Platform Solutions Guide.

1=Don’t add Use this option if you do not want the new object code added. The Check Out panel will display and you can specify a different object for check out.

2=Add Use this option to automatically add the new object code and to continue prompting during this check out session for any other object codes that do not exist. Press ENTER to create the new code. The check out proceeds normally until another non-existent object code is found.

3=Add all future without warning

Use this option to add the new object code added and to automatically create any other non-existent object codes during this check out session.

135


Implementer also provides mounted drive support for IFS objects that reside on a computer running Windows NT Server. This feature requires additional setup considerations for environments, user profiles, and communications. For more information, see Chapter 3 of the Implementer System Administrator Guide.

Checking Out for Concurrent DevelopmentThis task allows you to check out a member/object that is already checked out. This is often necessary for concurrent development or emergency fixes. You designate the copy of the member/object to use to start your development.

When you begin concurrent development, a conflict is created with all other locks on this item. The users with existing locks are notified with a message that a conflict was created. The conflicts ensure that, when concurrent development exists, no changes are lost during promotion. You must resolve the conflict for the member/object before you can promote it. A conflict is two-sided. Once a member/object is in concurrent development, you must resolve conflicts for both copies of the member/object when you promote them.

Developers must be authorized to use the Check Out function, authorized to check out from and to the environments being used, and allowed to perform concurrent development. You must use a project reference if project tracking is defined for the environment in Work with Environments. The member/object must already be locked or checked out.

To check out for concurrent development

1 Use one of the following methods to access the Check Out function:

� From My Workbench panel select option 27, or from the Work with Objects panel, select option 10 and press ENTER.

� From My Workbench press F6=Check Out.

� From the Work with Objects panel, press F20=Check Out.

� From My Workbench or the Work with Objects panel, select the member/object with option 9=Add to Clipboard, and press ENTER. Process the clipboard with F7=Process Clipboard, and use option 2.


Checking Out for Concurrent Development

� From the Implementer Menu, type 2, or type STRIM (*CHKOUT) at the command line, and press ENTER to display the Check Out main panel.

� If the member/object is in a quality assurance environment, select option 20 for Reject, to display the Reject Change panel.

2 On the Check Out main panel, use the location defaults from the project path, environment path, or user profile, or specify the from environment, to library or to environment, and project reference. You can prompt for the project reference and environments with F4=List.

3 Use one of the following methods to identify the members/objects to check out:

� Position the cursor on a member/object field and press F4=List to select from a list of members or objects to check out.

� Enter a member/object name and code on this panel. The action defaults to 1 for change.

� Press F8=Select from object codes to select from a list of object codes to be checked out. Type option 1 next to the object code, and press ENTER to select all members/objects related to that object code.

� Press F8=Select from object codes to select from a list of object codes to be checked out. Type option 5 next to the object code and press ENTER to display members/objects for selection.

Concurrent development for LANSA objects is allowed by using the copy from environment function in Check Out.

4 Press ENTER to validate the members/objects on the panel. If the members/objects are currently under development, you receive the message, “Mbr/obj XXXXX object code is locked. Use option 13 to select the copy from member/object.”

This message indicates that you must use option 13 to view the locked members/objects. Type 13 in the option field for the member/object mentioned in the message, and press ENTER to display the Select version for concurrent development panel.

NOTE

If you already know the Copy from environment (the location of the member/object you specifically need), you can type it in this field.

137


5 On the Select version for concurrent development panel, type option 1 next to the member/object and press ENTER to display the Check Out panel. You need to repeat this step for each member/object you selected with 13 on the Check Out panel. After completing all necessary selections, the Check Out panel displays.

The member/object you choose here is the starting point for your change. For example, if a member is currently checked out for a major enhancement that will not be completed for many weeks, and you only need to make a simple change, you would probably choose the member currently in production. A different example is, when a change is currently being tested in a quality assurance area and you need to make a change that includes the change currently in QA. In this case, choose the member/object that is currently in QA.

This dual check out is called concurrent development. A conflict exists between the member you want to check out and the other members that are already checked out. The members/objects that are checked out also are in conflict with the newly checked out member/object. You must resolve these conflicts before the members can be promoted. You can view the source members with option 15, or display lock information with option 8, to assist you in choosing the members.

The Design Request number field helps to determine the promotion requests associated with a DR. To filter to a specific DR, type the number in the filter entry field above the Design Request number column and press ENTER. (DesignTracker must be installed.)

6 Press F9=Accept to perform the check out and display the menu.

A message displays indicating that the member/object was checked out.

Common Questions

Will all members/objects with concurrent development have conflicts?

Yes. The conflict is the control method that ensures you track discrepancies between multiple versions of a member/object by a user with conflict resolution authority.


Checking Out Related Objects

Checking Out Related ObjectsThis task allows you to select related objects for the checked out object and add them to the list of members/objects to be checked out. It is not required, but it is helpful if the related objects must be modified as well. This feature is known as impact analysis or dependency checking.

This task ensures that you check out any related objects that require changes.

For example, if you want to make a major database change, such as changing the length of an account or part number, you would want to check out the related objects as well. If you make a minor database change, you can decide not to check out the related items; but at promotion, you would specify compilation of related objects.

During check out, either you can add all related objects to be checked out, or you can select from the related objects to be checked out. If related objects are not checked out, you can specify to recompile them during promotion. If you have a SQL table or physical file on the request, all related logical files are automatically compiled.

You can also check out related objects from the Select Entity panel when you are associating check out with a design request. For more information, see the DesignTracker User Guide.

If you use PathFinder or ABSTRACT, Implementer offers extended support for these products to obtain related object information.

This function does not support related objects for AS/SET definitions or LANSA objects.

To check out related objects

This task assumes the Workbench Check Out panel or the traditional Check Out panel is displayed, and have already selected an object of type *FILE, *MODULE, *SRVPGM, or *DTAARA for check out. (You can also use option 8=Related objs from the Workbench.)

Use one of the following methods to choose related objects:

� From the Workbench, type 8 in the option field next to the object of type *FILE or *DTAARA and press ENTER to check out related members/objects.

� From the Workbench Check Out panel or the traditional Check Out panel, type 10 in the option field next to the object of type *FILE or *DTAARA and press ENTER to check out related members/objects.

139


� Type 9 in the option field next to the object of type *FILE or *DTAARA and press ENTER to display related members/objects on the Select from Related Objects panel. Using this method requires the following additional steps:

a) Type 1 in the option field to select the members/objects.

b) Press ENTER. A message displays to indicate the members/objects were selected for check out.

c) Press ENTER again to display the Check Out panel.

The selected members/objects are added to the Check Out list.

d) On the Check Out main panel, press F9=Accept to check out the members/objects and display the menu.

Task Variation for Multiple Recurring Members/Objects

If you use related environments and multiple occurrences exist of a file or data area, checking out related objects is a two-step process:

1 If you attempt to add multiple recurring related objects, a message displays instructing you to press F4=List to display the Check Out Members/Objects Selection panel.

2 In the Check Out Members/Objects Selection panel, press F8=Display all, to display all occurrences of a member/object in different related environments. Use option 9 for Display related objects, or option 10 for Add related objects for the specific version of a multiple occurring member/object.

The resulting list is a union of the most recent versions of related objects for a multiple recurring object that resides in different related environments. If the member/object exists in more than one environment in the related environment list, review all occurrences using F4=List, and add related objects from only the Related Objects panel. You cannot add multiple related objects from the Check Out main panel.

Common Questions

If you modify a physical file by adding a field, do you need to check out related logical files and programs even if you don't need to change them?

No. You do not need to check out the related objects if you do not intend to modify them. Related objects are automatically recompiled if you specify this on the request.

Can you display related objects on an RPG program?

No. You can only display related objects on the *FILE or *DTAARA object types.


Checking Out With a Design Request

If you change a program, the database files it uses do not require recompiling and therefore, are not related. However, you can display related files for the RPG program from within PathFinder.

Why are all related objects not found when you display related objects?

The related objects were not found in the from environment. The related objects must exist in libraries defined for the from environment.

Why were no related objects found?

You probably did not run the Build List function after you set up the environment definition, or the from environment definition value for Maintain related object information is set to N (in Work with Environments).

Checking Out With a Design Request This task checks out one or more members or objects that are associated with a DR. DesignTracker must be the issue management system in order to use this feature.

This step is required if the From environment definition is defined with Design Request Number Required field set to Y in Work with Environments.

When you check out entities (members/objects) associated with a DR, the entity disposition is updated to 2 (in addition to the DR status). The entity disposition continues to be updated throughout the promotion cycle.

141


The entity dispositions for a design request are:

Depending on the DesignTracker environment definition, the changed entity disposition changes the status of the DR. If the DR is attached to a SupportCenter call the call history is updated to indicate the new DR status.

If the member/object is associated with a DR, the DR status (ready to check out, check out, promote to test, promote to production) and approval (No, Yes, pending for development, test or production) must allow the required function.

Developers must be authorized to use the Check Out function and authorized to check out from and to the environments. A project reference is required if Project Tracking is established in Work with Environments. The DesignTracker project must have an equivalent Implementer project. The developer who checks out the member/object must have the authority to maintain DRs if they want to add new entities to the DR.

When a DR is specified in Check Out, and the Dev Resource Initials field for that DR is blank, it is updated with the initials of the user performing the check out.

To perform one step check out with a DR

� From either the Workbench or Work with Objects, use the Design Request field to filter the panel to the required DR. You can use the default DR number, if displayed, or you can type the DR number.

To list DR numbers, position the cursor on the Design Request Number field and press F4=List to display the Select Design Request panel. Type option 1 next to the DR and press ENTER.

Any objects selected for check out will be checked out to the filtered DR. If you filter on a specific DR and choose to check out to a different DR, you must change the DR number to the new number and press F8

0 Not ready (always set to 0 when the entity is added to the list).

1 Ready to checkout (entity is ready to be checked out).

2 In development (entity is checked out and in development).

3 In QA (entity is checked out and in quality assurance for testing).

4 Completed (entity was moved into a *PRD (production) environment).



to re-filter. Alternatively, from the Workbench Check Out panel, press F4 to prompt the traditional check out panel.

IMPORTANT

MKS recommends that you review the Notes in the subsequent steps for additional important information related to checking out with a DR.

To perform traditional check out with a DR

1 Use one of the following methods to access the Check Out panel.

My Workbench option 27 or Work with Objects option 10 provides the easiest access to the Check Out main panel for everyday tasks.

Or, use one of the following methods from either of these panels (subsequent steps assume you have checked out from the Workbench):

� From Work with Objects, press F20=Check Out, to display the traditional Check Out panel and select members/objects from that panel. Use this method when you want to create a new member/object.

� From the Workbench, press F6=Check Out to display the traditional Check Out panel.

� Select the member/object with option 9 for the Clipboard, and press F7 to display the Clipboard Processing Menu. Select option 2 for Standard Check Out to display the Check Out main panel, or option 4 for Emergency Check Out, and press ENTER.

� If you are performing an emergency check out, select the member/object(s) with option 21 for Check out, and press ENTER to display the Emergency Check Out main panel.

2 Specify the DR number. You can perform this step from the Workbench or the Work with Objects panel before proceeding to the Check Out main panel, or from the Check Out main panel. Use one of the following options to specify the DR number:

� Use the default DR number. If the Workbench or the Work with Objects panel had a DR in the Design request number field, the same number displays in the Design request number field in the Check Out main panel. The associated project also displays.

� To list DR numbers, position the cursor on the Design Request Number field and press F4=List to display the Select Design Request panel. Type option 1 next to the DR and press ENTER.

143


� Type a valid DR number.

� To check out entities associated with a DR, the DR must be approved and at the correct status if you are using DR status.

To approve a DR, press F4=List to display the Select Design Request panel. Type option 8=Approved next to the DR and press ENTER to display the Work with Approvals panel. Type option 2=Change next to the user profile and press ENTER to display the Change Approval panel. Type option 1 in the appropriate option field to approve the specific phase of work.

� There can be different approval types per user: 1=Development, 2=Test, and 3=Production. Upon approval from all designated users, the status can be automatically changed. The approval/status relationship is defined in DesignTracker System Control. Press ENTER to process the approval and display the Work with Approvals panel. Press F3=Cancel to display the Check Out main panel.

� The DR does not need entities pre-selected to perform check out, since entities are added to the DR in this check out task. If entities exist on the DR, use F10=Select entities to select the entities after selecting the DR number.

� From the Work With Entity List panel, select F6=Select Objects to access the Member/Object Selection panel. You can select additional members/objects to add to an entity list, view lock details, perform related object processing, and a variety of other options. The environment used is based on the production environment specified on the Design Request Development Information panel in DesignTracker, or the product and version associated with the DR.

� From the Work with Entity List panel, use F20=Create IM Project to create an Implementer project. You can also use F8=Crt/Upd PM Project to directly interface from the Entity List into ProjectMaster to create and/or update a project. When you select this function, existing projects are updated. For non-existing projects, a project definition is created and updated (you can later define the specific project parameters from within ProjectMaster). A message displays to indicate what was updated, for example, “Project DT12345 created/updated with 1 function

and 0 tasks.”

When creating a ProjectMaster project, the DR number is used for the function name (defined as the DR number plus two blank spaces). Tasks for a function are created using the first seven



characters of the member/object name. Activities for a task are created based on the project creation rule.

For existing projects with project creation rules, each entity is a function; activities are assigned based on the project creation rules. If no entities are assigned to the DR, one function and no tasks are created. If the Project name for PM field is blank, this function key is disabled. For more information, see the DesignTracker User Guide and the ProjectMaster User Guide.

3 On the Check Out main panel, specify the from environment by using one of the following options:

� Use your default from environment associated with the default project path, environment path, or user profile.

� List an environment to check out from by positioning the cursor on the From Environment field, and press F4=List. Type option 1 next to the environment and press ENTER.

� Specify an environment to check out from.

4 Use one of the following options to specify the development location to check out to:

� Use your default to library or to environment as defined by the default project path, environment path, or user profile.

� To list an environment to check out to, position the cursor on the to environment field and press F4=List. Type option 1 next to the environment and press ENTER.

� Specify an environment or library name for check out.

You cannot check out AS/SET definitions, LANSA objects, or J.D. Edwards soft coding to a library.

5 The project reference defaults from the selected DR. If the project reference has a defined application path, the from and to environments default based on that project’s path.

NOTE

An equivalent Implementer project must exist for the DesignTracker project. To create a project, press F10=Select entity to display the Select Entity panel. Press F20=Create IM Project. Press F12=Cancel to display the Check Out main panel.

145


6 Use one of the following options to identify the members/objects to check out:

� Accept the members/objects you selected in the Workbench or the Work with Objects panel.

NOTE

If the selected items do not have the same grouping criteria (from environment or library, to environment or library, DR, and project number), the check out must be performed in a group. If members/objects found are not in the same group as the first item selected, a message alerts you that you must process all members/objects either as a single group or process them in separate groups.

� Position the cursor on the member/object field and press F4=List to select from a list of members or objects to check out. If you use related environments, the members/objects are listed in the sequence established for related environments. For more information, see the Implementer System Administrator Guide.

Press F8 to display either all the members/objects in different related environments, or the first occurrence of the member/object that exits in the list of the related environment.

� Press F10=Select Entity to display the Select Entity panel to select specific entities that already exist on the DR.

NOTE

A DR number is required to use this option. In the Select Entity panel, type option 1 next to the entities and press ENTER to display the Check Out panel.

� To select all members/objects of a specific object code, press F8=Select from object codes. Type option 1 next to the object code and press ENTER to select all members/objects related to that object code.

� Press F8=Select from object codes to select from a list of members/objects filtered by object code, and perform the following steps:

a) Type option 5 next to the object code, and press ENTER to display members/objects on the Member/Object Selection panel.

b) In the Member/Object Selection panel, type option 1 next to the members/objects and press ENTER. A message displays indicating that you have selected some members for check out. Press ENTER again to display the Check Out panel.



The previously selected members/objects display.

� Type a member/object name and code on this panel. The action defaults to 1 for change.

You can check out AS/SET definitions from and to specified AS/SET environments that are defined in Work with Environments. When checking out AS/SET definitions, you must use the specific object codes that are defined with special characteristics starting with ADK.

You can check out from/to specified LANSA environments that are defined in Work with Environments. When checking out LANSA objects, you must use the specific object codes that are defined with special characteristics starting with LAN.

You can check out J.D. Edwards traditional and special objects from and to specified J.D. Edwards environments that are defined in Work with Environments. When checking out J.D. Edwards definitions, you must use the specific object codes that are defined with special characteristics starting with JDE.

� To initiate check out from DesignTracker, from the Work with Entity List Members panel type option 9 for Check out, and press ENTER to check out specific entities that already exist on the DR. The Check Out main panel displays.

7 Press ENTER to verify the selected entities. If everything is correct, the following message displays:

“Press F9=Accept to check out.”

NOTE

Depending on how you access the Check Out function, you can edit the member/object selection.

8 Press F9=Accept to process the check out and display the previous panel. A message displays indicating that the member/object(s) was checked out. A lock is created for each member/object indicating work in process in the Workbench, and the member (or object for non-source-based objects) is copied into the development library or environment.

Common Questions

Can you select any DR to associate with the check out?

No. Only approved DRs with a specific Implementer project can be associated with the members/objects you want to check out.

147


Is check out the only way to associate a DR with checked out members/objects?

No. A lock exists for any members/objects that are checked out. You can associate a DR with an existing lock in the Workbench by changing the lock characteristics of the DR and project with option 7 for Change. You can add additional DRs using option 26 for Multiple design requests. However, a DR must be approved and have an associated Implementer project before it can be associated with a lock.

Must entities exist on a DR before performing a check out?

No. You can select the members/objects with any of the selection processes, or enter them in the member/object field. At the completion of the checkout, the DR entity list is updated automatically.

What authorities are needed to implement this task?

For complete description of authorities in Implementer and DesignTracker, see “User Authorities” on page 151.

Using ILE Object Codes in Check OutAs of OS/400 V3R1, support for Integrated Language Environment (ILE) objects is provided. ILE support improves performance, encourages modular programming, and provides better control over OS/400 resources. Implementer provides complete support for software development using ILE.

This section provides an overview of how the ILE object codes that are shipped with Implementer are used within the product. Authorized users can use Work with Object Codes to view object code definitions. For a complete listing of all object codes, contact your Implementer System Administrator.

Binding Directories

The BNDDIR object code is used to check out and promote binding directory objects. This is done by creating a duplicate object of the binding directory in the From environment to the To environment. The modules and service programs entered in the binding directory should use *LIBL for the LIB parameter to allow access to the modules and service program wherever they reside in your environment setup.


Using ILE Object Codes in Check Out

Modules For RPGMOD, CMOD, CLMOD, and CBLMOD the module object codes function similarly to standard program object codes (for example, RPG, CBL, and CLP). They use CRTxxxMOD commands and require no special treatment.

Bound Programs

For RPGBND, CBND, CLBND, and CBLBND the bound program object codes function similarly to standard program object codes (for example, RPG, CBL, and CLP). They use the CRTBNDxxx commands and require no special treatment.

ILE SQL Programs

For RPGSQLI, CSQLI, and CBLSQLI the ILE SQL program object codes function similarly to standard program object codes (for example, RPG, CBL, and CLP). They use the CRTSQLxxxI commands and require no special treatment.

Service Programs

For RPGSRV, CSRV, CLSRV, CBLSRV, and SRVPGM t he service program object codes use the CRTSRVPGM command. A separate code exists for each language (for example, RPG, C, CL, and CBL), and one exists for mixed language service programs. Use the language-specific codes for service programs that contain modules, or for service programs for only that specific language. Use the mixed service program code (SRVPGM) when the service program consists of modules and/or service programs of different languages. When using these codes, prompt the creation command and review the MODULE, EXPORT, and BNDDIR parameters for correctness based upon the ILE technique you are using.

Update Service Program

For SRVPGMU, the update service program object code uses the UPDSRVPGM command. When using this code, prompt the creation command and change the MODULE parameter from ENTERLIST to the modules or service programs being updated in the service program. When checking out using this code, you may need to change the Allow object attribute change flag in the unfolded view of the Check Out panel to Y.

ILE Program For RPGILE, CILE, CLILE, CBLILE, and ILEPGM the ILE program object codes use the CRTPGM command. A separate code exists for each ILE language (for example, C, CBL, CL, or RPG). The CRTPGM command assigns an object attribute based upon the language used for the Entry Point Module. You should therefore, choose the object code corresponding to that language attribute (CLE, CLLE, CBLLE, or RPGLE). Note that a generic ILEPGM object code with no attribute is included. This is only needed for early versions of V3R1M0 and V3R0M5, where mixed language ILE programs did not get an attribute assigned.

149


Update ILE Program

For ILEPGMU, the update ILE program object code uses the UPDPGM command. When using this code, prompt the creation command and change the MODULE parameter from ENTERLIST to the modules or service programs being updated in the ILE program. When checking out using this code, you may need to change the Allow object attribute change flag in the unfolded view of the Check Out panel to Y.

Checking Out Physical File DataImplementer provides the PF object code, which is used to check out physical files when you plan to change the source members. If you want to change the physical file data as well, you must check out the physical file as well, using the PFDTA object code.

The next illustration shows the Check Out panel completed for checking out a physical file and its data.

At check out, the PF object code checks out the physical file and its source while the PFDTA object code checks out the physical file data.

If you are not making changes to the physical file definition, you can check out the data only.


Using Different Source and Object Names in Check Out

Using Different Source and Object Names in Check Out

For situations where source and object names are different, Implementer provides full support based on the object name.

The following tasks must be performed prior to using different source and object name support:

� define the To and From environments for check out

� define object codes that use a creation command with the SRCMBR parameter (must use the keyword #SRCMBR)

� run the Build List function

These tasks are detailed in the Implementer System Administrator Guide.

Once these setup activities are complete, you can perform all check out activities by specifying the object name.

� If you specify the source name rather than the object name, the message, “Cannot check out with source member name” displays to notify you that you must use the object name.

� If an item you are checking out is source-based only, the source member name is allowed.

� Although the object name displays, the correct source member name is automatically used, anywhere the source must be referenced.

� Locks are based on the object name.

User AuthoritiesIn different shops, positions and responsibilities are often defined differently.

In smaller shops where there are few levels, management can allow increased capabilities (authorities) of Implementer functionality to most developers.

In larger shops, the tasks can be more divided; thus, capabilities are distributed to different positions. This task division is most often apparent in Check Out capabilities.

151


Typical User Capabilities

The following chart describes how user capabilities can be divided.

LANSA Export/Import Authorities

During the migration of LANSA objects, you can automatically be granted LANSA export/import rights. Because Implementer uses the export/import processes for the migration of LANSA objects, insufficient LANSA authorities on the objects can lead to failure of migrations. Therefore, if you are authorized to check out or create promotion requests, you are automatically granted LANSA authority to perform the export and import

PositionMaintain DR

Concurrent Dev’t

Authorities in Check Out

Junior Programmer

No No All input is predetermined by project leader. User is unable to add entities to the checkout request and is unable to change copy from information.

Programmer in a controlled shop

No Yes User is unable to add entities to the checkout request, but is able to change copy from information in a concurrent development situation.

Project Leader who does not code

Yes No User is able to create entities in DesignTracker, but never checks anything out for this user. Allows an individual programmer to make concurrent development decisions.

Project Leader in a shop that does not allow concurrent development

Yes No User is able to create entities in DesignTracker and add entities to the checkout request, but is unable to change copy from information, since concurrent development is not allowed in this shop.

Project Leader or Senior Programmer

Yes Yes User is able to create entities in DesignTracker and add entities to the checkout request, and can change copy from information in a concurrent development situation.


Checking Out for Reject

processes. This authority is in effect only during the time the export or import process is run. It is automatically revoked when migration is complete.

Checking Out for RejectThis task describes how to reject members/objects from a quality assurance (*QAC) environment and check them back to development on the original lock. For the members/objects selected, the source (for source based objects) or object (for non-source based objects) is copied back to development from the test environment. This returns the source and lock to the development environment for continued development activity. By requiring locks on promotion requests, the member/object in the test environment can remain for further testing and is not available for promotion to the next QA or production environments.

You must be using a test (*QAC) environment to use this option. If the member/object is not in a *QAC environment, an error message occurs when you attempt to reject it.

The target environment or library defaults vary, depending on the use of default application paths (project or environment) or the user profile. The existing lock is moved to the development environment or library—a new lock is not created. The check out is standard for a standard lock and emergency for an emergency lock.

When rejecting member/objects from a QAC environment, by default the source and object are retained in QA to allow for further testing (but you cannot promote it from that environment). Although this is beneficial to some companies, others require the ability to delete the source and object from the QAC environment when the need to reject occurs. Therefore, an option is provided that allows you to delete the members/objects from the QAC environment when a check out for reject is processed.

This task assumes you are managing a member/object in a test (*QAC) environment in the Workbench or in Work with Objects.

Removing Source and Objects From QA

When a check out for reject is processed, a window displays that allows you to specify, in the Delete Member/Object field, whether to remove source and objects from the *QAC environment.

The default value of the Delete Member/object field is controlled by data area IMREJECT, which is located in the Implementer product library. If IMREJECT is set to N, this field defaults to N and the member/objects are not removed from the QAC environment. Likewise, if IMREJECT is set to

153


Y, this field defaults to Y and the member/objects are removed from the QAC environment. In either case, the value can be overridden during the reject (the data area simply determines the default that displays in the Delete Member/Objects field).

For more information about the IMREJECT data area, see Appendix A in the Implementer System Administrator Guide.

To reject members/objects from a *QAC environment

1 From My Workbench, type option 20 for Reject in the Opt field next to the member/object you want to reject, and press ENTER to display the Reject Changes panel with the selected member/object(s) listed.

2 Press F9=Accept to process the checkout and proceed to the Delete Member/Objects while Rejecting window.

3 Press ENTER to continue with the check out for reject (or override the value in Delete Member/Objects field and press ENTER to continue with the check out). The original panel that you performed the Reject task from displays.

Task Variation for Rejecting From the Menu

You can reject a member/object from a test environment (*QAC) from the Check Out main panel. Type the name of the test environment in the From environment field and the development environment or library in the To environment field, and press ENTER. Continue with reject task as defined previously.


Object Name Rules

Common Questions

Can you reject a member/object from development?

No. You can only reject a member/object from a test (*QAC) environment.

Object Name RulesImplementer supports the use of rules to control the naming construct of newly created member/objects.

When you check out a member/object with action 2=Create the rules are validated and enforced. If the member/object name does not follow the specified rules, the check out is not allowed.

Naming rules are set up by the System Administrator. The rules allow for consistency in member/object naming. They also allow for flexibility—using standard Boolean logic, they allow for multiple true conditions. For more advanced requirements, user specified exit programs can also be used.

NOTE

Check with your System Administrator to verify if this feature is enabled. For information on defining rules, see the Implementer System Administrator Guide.

Performing Name Validation

Name validation is implemented on a per-environment and object code basis. Using the environment and object code, each position group of the object name is validated to the rules, by position and sequence. If a specified object name violates the rule, a message displays indicating the environment, object code, position, length, and rule that was used.

Rules are validated in the following order:

1 If the specific object code is not found, the global object code *ALL is used.

2 If the specific environment is not found, the global environment *ALL is used.

3 If both the object code and environment are not found, the global rule *ALL/*ALL is used.

4 If no rule is found, validation is not performed.

155


When an invalid checkout occurs, an error message displays indicating the positions within the rule that did not pass validation. Additional diagnostic message information is available that can help with problem resolution. After correcting any errors, you can proceed with check out.

Check Out (ICHKOUT) Command This task allows you to check out using the Check Out (ICHKOUT) command rather than the menu interface. You can embed the check out command in your own user program or as a user option in PDM, ABSTRACT, or PathFinder to further automate the check out process, or simply check out from the command line within Implementer.

You can use the Check Out (ICHKOUT) command to check out AS/SET definitions.

Developers must be authorized to perform check out, authorized to the object code, and to check out of the from environment. Specifying a project number is necessary if defined as such in System Control, or when using a project path.

To use the ICHKOUT command

1 Type ICHKOUT at a command line and press F4=Prompt.

2 Complete the parameters as defined next in “ICKHOUT Command Parameters”.

3 Press ENTER to perform the check out. A message displays stating that the member/object was checked out.

ICHKOUT Command Parameters

From environment

Specify the environment to check out from (you must be authorized to check out from the environment). Check out is allowed from production (*PRD) and quality assurance (*QAC) environments. If the member/object


Check Out (ICHKOUT) Command

is currently in development (checked out and locked), change the Copy from environment parameter default from *NONE to the location you want to select from.

To library

Specify the development library to check out to.

To environment

Specify the environment to check out to, if not checking out to a library. Check out is allowed to development (*TST) environments.

*PATH Derives the environment from the project path for the project specified in the Project Reference parameter. A project path must exist to use this value. If a project path does not exist, it defaults to the environment path. If an environment path does not exist, a message displays stating you must specify an environment name. *PATH is the default value.

*USRPRF Derives the environment from the value defined as your default check out from environment, in Work with Users.

Char value Specify the environment name. The environment is determined from the environment path of the specified environment.

*PATH Derives the library from the project path for the project specified in the Project Reference parameter. A project path must exist to use this value. If a project path does not exist, it defaults to the environment path. If an environment path does not exist, a message displays stating you must specify a library name. *PATH is the default value.

*USRPRF Derives the library from the value defined as your default check out to library, in Work with Users.

Name Specify the library name.

*PATH Derives the environment from the project path for the project specified in the Project Reference parameter. A project path must exist to use this value. If a project path does not exist, it defaults to the environment path. If an environment path does not exist, a message displays indicating that you must specify an environment name. *PATH is the default value.

*USRPRF Derives the environment from the value defined as your default check out to environment, in Work with Users.

Char value Specify the environment name. The environment is determined from the environment path of the specified environment.

157


Project reference

Specify the project associated with the member/object. This parameter is not valid when Integrity Manager is the enabled issue tracking system.

Issue or design request

If you manage work with Integrity Manager issues or DesignTracker DRs, specify the number associated with the member/object being checked out.

Lock type

Specify the type of check out and corresponding lock to place on the member/object.

Member/object

Specify the name of the member or object to check out.

Object code

Specify the Implementer object code associated with the member/object.

*USRPRF Derives the default project reference defined to your user profile, in Work with Users.

*DRNBR Derives the project reference from the design request specified in the Issue or Design Request parameter.

Char value Specify a valid project reference. If the user profile does not have an assigned default or if you are checking out to different environments, specify the project reference.

Number Specify a valid issue or DR number.

*NONE Specifies that the member/object is not associated with an issue or design request. This is the default value.

*STD Standard check out and lock. This is the default value.

*EMERG Emergency check out and lock.

Name Specify the member or object name.

generic* Specify a wildcard value to check out a group of similarly named items. For example, specify RPG* to check out from the specified environment all member/objects that begin a name of RPG.

*ALL Specifies to check out all member/objects from the specified environment.

Name Specify the object code name.

*ALL Specifies to check out all types of the specified member/object. For example, if you specify the member/object value RPG* and the object code value *ALL, the result may include various types, such as RPG, RPGILE, and RPGBND.



Action

Specify the action to take in the production environment for the member/object.

Lock comment

Specify a brief comment about the check out, for example, the reason for checking out the member/object.

Revision number

Specify a version number that will override the next version number to be assigned, if object versioning is enabled and required.

Validation is performed to ensure that the version number specified is valid for the defined versioning method. For existing items, it verifies that the value being assigned is not less than the value attached to the object in the *PRD environment.

If the version number is invalid, an error message displays. If a version number is not specified, the next available version number is the default value.

“Copy from” environment

Specify an environment to optionally copy the member/object from. It is also the copy location when creating concurrent development and copying the item from another location. If the selected member/object is currently in development (checked out and locked), change the default from *NONE to the location you want to select it from.

If a copy from environment is specified, do not specify a copy from source file and library. If a copy from source file or library are specified the copy from environment must be blank.

*CHANGE To change a member/object. This is the default value.

*CREATE To create a member/object.

*DELETE To delete a member/object.

*RECOMP To recompile a member/object.

Name Specify the environment name.

*FRMENV Copies the object from the environment specified in the From environment parameter.

*NONE The member/object is not copied. This is the default value.

159


“Copy from” member/object

Specify the name of an existing member/object on which to base a new member/object. If the object code is source-based, this entry must contain the name of a source member. If the object code is non-source-based (it is object-based), this entry must contain the name of an object to copy from.

This object must exist on the local system—it cannot be copied from a remote system. The normal use of this option is to create a new member/object with action code 2=Create.

Copy from member/object is not supported for LANSA objects.

“Copy from” source file

Specify the name of the source file to use to copy an existing source-based object to create a new one. The default is the source file defined for the from environment for the object code specified.

The Copy from source file and Copy from library fields must be blank if you enter a Copy from environment.

“Copy from” library

Specify the name of the library to copy either a source-based item or an object to create a new one. The default is the library defined in the from environment for the object code entered. A library name can also be entered.

The Copy from source file and Copy from library fields must be blank if you enter a Copy from environment.

Name Specify the member/object name.

*MBROBJ Copies the object specified in the Member/Object parameter.

Name Specify the source file name.

*CPYENV Copies from the default source file defined for the Copy from environment parameter. This is the default value.

Name Specify the library name.

*CPYENV Copies from the library defined for the Copy from environment parameter. This is the default value.



To source file

Specify the name of a source file to copy a source-based object to. The default is the source file defined for the from environment for the object code specified.

Ignore warning messages

Specify whether to ignore any warning messages encountered during check out. For example, a warning message may alert you that a member/object already exists in the check out to environment.

Replace existing members

Specify how to handle checking out to a location where the member already exists.

Submit

Specify the standard OS/400 submit job parameter as required. *NO is the default.

Job queue

Specify the job queue for the command to run in. This parameter displays when you press F9=All parameters or specify Submit *YES.

Name Specify the source file name.

*FRMENV Copies to the source file defined for the from environment for the object code specified.

*USRPRF Copies to the source file to your default development library, if specified, in Work with Users. This is the default value.

*OBJCDE Copies to the source file defined for the corresponding object code.

*YES Ignores warning messages.

*NO Displays warning messages. This is the default value.

*YES The current member replaces existing members.

*NO The current member does not replace existing members. This is the default value.

*IGN Creates a lock using the existing object in the check out to location.

Name Specify the job queue name.

*PRODUCT Uses the job queue defined as the default job queue in Implementer data area IMJOBQ. This is the default value.

161


Library

Specify the library associated with the job queue. This parameter displays when you press F9=All parameters or specify Submit *YES.

Check Out Command Variations

Additional options exist for using the ICHKOUT command in PDM and in PathFinder.

Using the ICHKOUT Command in PDM

The setup instructions describe how to set up a user-defined PDM option for this command. Once you define the command in PDM, you can use user-defined option CO (or a name of your own choosing) for check out. Many developers prefer to work within PDM. This function allows the developer to have change management control in check out, while having the development productivity of using PDM.

Using the ICHKOUT Command in PathFinder

The setup instructions for using PathFinder for the source of information describe how to establish PathFinder for use in check out. For more information, see the Implementer System Administrator Guide. Once you define the command, you can use the user-defined option IC for check out from within PathFinder. If you use PathFinder to select members/objects for the Check Out panel, use the user-defined option IS. See the Hawkeye PathFinder Reference Manual for instructions on using the PathFinder Object Where Used panel.

Common Questions

What is the difference between the check out command interfaces and the menu interface?

The command interfaces support generic parameter values and they can be submitted in batch. You can also use them for integration into PDM and PathFinder. For example, if you want to check out all accounts payable objects you could use AP* for the member/object parameter. The menu interfaces allow you to pick from a list of members/objects and display a list of environments to check out from. They also allow check out of related objects.


Converting RPG/400 or RPGIII Source Code to ILE RPG/400

Converting RPG/400 or RPGIII Source Code to ILE RPG/400

Implementer provides complete support for software development using ILE (Integrated Language Environment). ILE support improves performance, encourages modular programming, and provides better control over OS/400 resources.

There are two steps to this process: check out the code to convert and perform the conversion.

To check out the code to convert

To ensure that there is no concurrent development while you are converting the source, you should check out the source as well.

1 Display the Check Out panel using any of the methods defined earlier in this chapter.

2 Determine if you are creating a modular ILE program or a stand-alone RPG4 program, and follow the appropriate instructions listed next.

� Modular ILE Programs:

a) Add a Check Out entry for the program you are converting using the RPG object code and option 3=Delete in the Action field.

b) Add RPGMOD and ILEPGM of the same name, if the RPG and the ILE programs are kept in the same source file, using option 1=Change in the Action field. However, if the source files are different, for example, QRPGSRC and QRPGLESRC, use option 2=Create in the Action field.

The panel should now look similar to the one illustrated next.

163


c) Press F9=Accept to complete the check out.

NOTE

If you are not authorized to the production copies of source, you can specify the Copy From on the RPGMOD line to get a copy of the source checked out to the development environment.

� Standalone RPG Programs:

a) Add a Check Out entry for the program you are converting using the RPG object code and option 3=Delete in the Action field.

b) Add RPGMOD of the same name, if the RPG and the ILE programs are kept in the same source file, using option 1=Change in the Action field. However, if the source files are different, for example, QRPGSRC and QRPGLESRC, use option 2=Create in the Action field.

If you are not authorized to the production copies of source, you can specify the Copy From on the RPGBND line to get a copy of the source checked out to the development environment.

The panel should now look similar to the one illustrated next.


Converting CRTBNDxxx ILE Programs to CRTPGM Programs

c) Press F9=Accept to complete the check out.

To perform the conversion

1 After the check out is complete, issue the following command:

CVTRPGSRC FROMFILE(FROMSRCLIB/FROMSRCFIL)FROMMBR(FRM_MBR)

TOFILE(TOSRCLIB/TOSRCFIL)

TOMBR(TO_MBR)

2 Make the necessary additions/changes to the source code. If you are doing modular ILE development, build the BNDDIR with the module names to be used in the bound program.

3 Promote the RPGMOD, ILEPGM, and BNDDIR (or RPGBND for RPG4) into production together. The ILEPGM object code uses the BNDDIR entries to select the modules to be bound into the program object.

Converting CRTBNDxxx ILE Programs to CRTPGM Programs

IBM has provided an easy entry into the ILE programming model by way of the CRTBNDxxx series of commands. The CRTBNDxxx command generally results in an executable *PGM object, which consists of one *MODULE object of the same name. Behind the scenes, the CRTBNDxxx commands first create a *MODULE in QTEMP library, then creates a *PGM

165


binding the *MODULE that was created in QTEMP. Finally, the command deletes the *MODULE. As you start to implement a more extensive ILE architecture, you probably want to start changing some of these *PGMs over to include multiple modules. The following steps define how to do this.

To perform the conversion

1 Check out the program name as shown below to allow splitting the CRTBNDxxx *PGM into a *MODULE and a CRTPGM style *PGM.

2 When promoting the RPGMOD and RPGILE locks, you need to override the Activation Group parameter. This is because an attempt is made to retain the attribute of the existing *PGM object that was created using the CRTBNDxxx command. The CRTBNDxxx commands allow and default this parameter to *DFTACTGRP, which is not valid in the CRTPGM command. The result is a compile-fail during the promotion if not overridden to a value allowed by CRTPGM. You can override the creation command on the Create Request panel by typing 1 next to the RPGILE lock, pressing ENTER, and changing the Activation Group Parameter on the CRTPGM command.


Checking Out Using PathFinder Information

Checking Out Using PathFinder InformationThis task allows you to check out related members/objects identified by PathFinder. You can select related objects for the specified object and add them to the list of members/objects you are checking out. It is not required, but it is helpful if the related objects are modified as well.

You can also select a member/object for check out through the PathFinder user-defined option IS. For more information, see “Integrating With Other Vendor Products” on page 327.

This task ensures any related objects that require changes also are changed. This task is useful for developers who use PathFinder.

For example, if you make a major database change, such as changing the length of an account or part number, you should check out the related objects as well. If you make a minor database change, you can decide not to check out the related items. For example, if you change a FILE or *DTAARA object type and the related objects do not need to be changed, the related objects are automatically recompiled if add related objects is specified on the promotion request.

NOTE

PathFinder’s Where Used function shows ILE *MODULE objects that use a file; however, it does not show the ILE *PGM and *SRVPGM objects that use the file because they contain those *MODULE objects. To ensure that level checks do not occur in these *PGM and *SRVPGM objects, use PathFinder’s Where Used function to list the *PGM and *SRVPGM objects containing the *MODULE objects. Then add these objects manually to check out.

Similarly, since PathFinder does not support the cross-environment functionality within Implementer, you must use PathFinder’s Where Used feature to list the related objects in different environments, and manually create the appropriate check out for these related objects.

Environment and Library Setup

This setup is necessary if you use PathFinder as the source of information for the Implementer Related Objects panel or actual member/object selection through PathFinder.

Environment Setup

In the second Work with Environments panel (assuming the Maintain Related Object Information field is set to Y), set the Source of information field to 2 for PathFinder.

167


Maintaining the PathFinder Library

It is important to accurately maintain the default DOCLIBL for the PathFinder x-ref in order to use the feature of real-time PathFinder X-Ref update. Whenever objects are managed in environments that are defined with PathFinder as the source of related information, the x-ref is automatically updated through a PathFinder API.

To maintain the Pathfinder library

1 Access PathFinder either from the command line or from F18=PathFinder on the Check Out main panel.

2 From the PathFinder Overview menu (HAWKOVER), select option 53 for setup to display the PathFinder Setup menu (HAWKSETUP). Select option 1 to set up your library defaults in the DOCLIBL User Values panel.

3 Type the names of your from environment libraries and press ENTER. The message “Without making changes, press ENTER to confirm” displays. Press ENTER again to display the PathFinder Setup menu.

4 Type option 5 and press ENTER to display the User Defaults panel.

In the Object X-Ref library field, type the name of the library that you want to store the cross-reference information in. This library is entered again when you run the build for the cross-reference list and press ENTER.

5 Press F3=Exit to display the PathFinder main menu. Select option 54 for Object X-Ref, and press ENTER to display the Object X-Ref panel.

6 Select option 1 and press ENTER to build the cross-references list and press ENTER to display the Build/Refresh Object X-Ref panel.

7 Type option 1 and press ENTER to perform the build with the libraries you inserted in DOCLIBL User Values panel.

8 Type *DOCLIBL and press ENTER. Type the name of the library you specified earlier to store the cross-reference information and press ENTER.

9 Press ENTER to accept the defaults on the submit panel.

10 On the Build/Refresh Object X-Ref panel, press F3=Exit to display the command line or the Check Out main panel.

Performing the Check Out

This task assumes you are in the Check Out main panel and have already selected an object. It is identical to checking out related objects with Implementer as the source of information. The only difference is that the


Checking Out Using PathFinder Information

object types include *PGM and *RPG. If it is an *RPG the related objects are programs that call the selected program. This is useful if you changed the parameter list of a program and need to modify all programs that pass parameters to it.

To check out related members/objects identified by PathFinder

1 Use either of the following options to choose related objects:

� Type 10 in the option field next to the object and press ENTER to check out related members/objects.

� Type 9 in the option field next to the object and press ENTER to display related members/objects. The Select from Related Objects panel displays.

a) Type 1 in the option field to select the members/objects.

b) Press ENTER. A message displays to indicate the members/objects were checked out.

c) Press ENTER again to display the Check Out panel.

The selected members/objects are related to the Check Out list.

2 Press F9=Accept. This performs the check out of the members/objects and displays the previous panel.

NOTE

PathFinder does not currently support ILE programs in the Real Time X-Ref Update (REALUPD) command. Implementer allows you to bypass the attempted real time update for these objects to prevent errors on promotions. Data area IMBNDUPD in the Implementer product library is shipped with a value of N to bypass the update. Once you receive a version of PathFinder that supports ILE programs, you should change the value of this data area to Y. With the data area value set to N, the PathFinder database for ILE programs is not updated. Therefore, normal PathFinder updates should be run regularly to keep your data current.

Common Questions

What are the setup requirements for using PathFinder with the Implementer menu interface?

Set the Maintain Related Object Information field to Y, and set the Source of information field to 2 for PathFinder. You also need to build the PathFinder cross-reference list. For more information see “Environment and Library Setup” on page 167.

169

6Performing Promotions

The Implementer promotion request contains one or more items to be promoted. The items placed on the promotion request are those that, from your perspective, consist of a single change. This change can be as simple as one object when making a fix or a simple enhancement or it can be an entirely new version of the application software.

Promotion requests are created in the Create Request function and are assigned a unique, sequentially created request number. This function allows you to select source and objects, or a COOL:2E model list for promotion. Each promotion request can go through different steps depending on how it was created and the environment types on the request. These steps are: model copy (if a COOL:2E environment), export (if LANSA environment), compile, distribution, and move. Promotion requests can be submitted individually or together in a single job. Implementer assigns a status to each step, which you can view when displaying promotion request information.


� promotion request fundamentals

� creating requests and the various techniques

� changing overrides and request details

� using special commands

� maintaining promotion requests

� promoting IFS files and directories

� promoting physical file data

� using different source and object names in promotion

� compiling and moving promotion requests

� managing concurrent development

� advanced topics

� scheduling promotion requests

� promotion request status and internal steps

171

Performing Promotions

Promotion Request FundamentalsThe basic promotion cycle consists of creating a promotion request and moving it to the target environment or environment group. The promotion cycle can additionally include compilation and distribution of the member/objects, with the move step issued on the remote system. You can manually promote (by selecting each separate menu option) or you can submit the promotion to automatically process through the compile, distribute, and move steps. For a description of these distribution steps, see “Performing Distributions” on page 271.

You usually promote once development is complete and the member/objects are ready for transfer to either testing or production environments. You can only promote to an environment or an environment group defined in Implementer—you cannot promote to a library.

The Create Request function is the first step of the promotion cycle. It is a request for the indicated member/objects to be transferred to the specified environments. You can create the promotion request through the Workbench, Work with Objects, the Work with Entity List Members panel in DesignTracker, the menu interface, or the command interface. In addition, command interface options are available for PDM and PathFinder.

To create a promotion request, the design request status and approval must allow you to initiate promotion. In the Workbench, you can associate multiple design requests to an existing lock on a member/object. All associated design requests must be at the proper approval and status before you can create the promotion request.

Create Request identifies if an item is part of concurrent development. If it is part of concurrent development and the conflicts associated with the concurrent development are resolved, you can place the item on the promotion request. If the conflicts are not resolved, you can display the conflicts, resolve the conflicts (if you have the authority), and then promote the promotion request. This ensures that you manage concurrent development and do not lose changes when promoting to production.

The member/objects are copied as they exist at the time the promotion request is created, into a temporary work library. If the promotion includes compilation, the member/objects are compiled into this temporary work library. You can manually accomplish this step through the menu interface or the command interface. With the menu interface, you can change the compile attributes, authority methods, and target environments for the promotion request.


Promotion Request Fundamentals

The next step of the promotion cycle is the move step. The move step transfers the member/objects into the target environment or environment group. You can manually complete this task through the menu interface or the command interface. A user who has administrative capabilities for the target environment usually does this task. If you select the menu interface, you can change the attribute overrides, authority methods, and target environments for the promotion request. If the promotion is to a production environment, the member/objects are unlocked. If the promotion is to a quality assurance environment, the locks are reassigned to indicate that the member/objects exist in the new environment.

Promotion Request Numbering

A request number is the unique four positions alphanumeric value automatically assigned to a promotion request when it is created. It is how you identify a promotion request.

The request number scheme begins with number 0001 and increments by one for each new promotion request created until number 9999 is reached. When this occurs, the left-most position begins with an alpha character and the remaining positions reset to 0 (zero). Reading from right to left the cycle continues until each position goes through the range 0–9 and A–Z. When the number ZZZZ is reached, the request number scheme resets to 0001.

This method allows for all positions of the field to use alphanumeric characters, and the availability of 1,200,000 request numbers before a reset occurs.

The following table illustrates this concept.

Creating Promotion Requests in Batch

Implementer provides for batch processing of the Create Request function. Batch processing moves a significant amount of the validation and processing (such as source and object copying) that occur during create request, to the submitted job, allowing the process to run quicker. Keep in mind, that although less interactive edit processing occurs, this typically is

When the request number is … The next number issued is …

0001–9999 A000

A001–A00Z A010

A010–AZZZ B000

B000–B00Z B010

B010–B0ZZ B100

B100–BZZZ C000

173


not an issue for most shops. The batch feature is most beneficial when promoting multiple items on a request, or when issuing multiple promotion requests.

Control of this feature is defined in System Control Maintenance, by the Perform Create Request in Batch flag. When Implementer is initially installed, this feature is enabled. For more information, see Chapter 3 of the Implementer System Administrator Guide.

Default Compile Order

Implementer ensures all objects are compiled in the correct order by using the object code sequence number. This ensures files are compiled before programs, and reference files are compiled before the other files that use them. For example, by using the object code of PFREF (which has a creation sequence of 90, compared to PF, which has the creation sequence of 100) to check out and promote the item, reference files are compiled before physical files.

Promotion Methods

Implementer offers two methods of promotion—the one step method and a traditional method. The one step method allows you to create a promotion request and promote the items using a fast path approach that saves time and effort, thereby minimizing the steps required in the create request function. The traditional promotion method, which is more interactive, displays the Create Request panel and requires additional input for processing. Both methods provide access to many of the same features and produce the same results. However, because of time saving advantages to the one step method, it is typically the preferred method.

The default promotion method is defined on a per user basis in Work With Users, controlled by the Enable One Step Promotion flag. When you initially install Implementer, the one step promotion method is enabled by default.

Create Request Overview

To promote member/objects to production or test environments, you place the member/objects on a promotion request. The following tasks create a promotion request.

The Create Request task must be performed when you have made changes to member/objects and they are ready to be promoted to the next environment. You must have authority to the Create Request function, as well as authority to create a promotion request to the target environment and out of the from environment.

If the member/object is associated with a design request, the design request status (Promote to Test, Promote to Production) and approval (No, Yes, Test, or Production) must allow the promotion. The DesignTracker entity disposition, approvals, and design request status determine whether


Creating Requests With the One Step Promotion Method

you can perform this task. If you are authorized, the related information is automatically updated during the move step. Locks that are associated with a design request represent the relationship between the item and the design request.

You can promote AS/SET definitions and traditional objects on the same promotion request.

You can promote LANSA and traditional objects on the same promotion request.

All valid LANSA objects on the promotion request are bundled into an export list. LANSA objects are promoted in compiled form.

NOTE

The Create Request Comments feature is automatically enabled when you install Implementer. When you create a promotion request and press F9=Accept, the Comments panel displays and requires you type an explanation for the promotion before allowing you to continue. The feature can be disabled, while still allowing issue or design request comments to be added (when promoted objects are associated with an issue or DR, the comments associated with the primary issue or DR are automatically added to the promotion request). For more information, contact your System Administrator, or see Chapter 3 of the Implementer System Administrator Guide.

Creating Requests With the One Step Promotion Method

This task allows you to prepare a promotion request using the one step promotion method. The one step promotion method applies to creating promotion requests from the Workbench (option 11=Promote), the Clipboard, and Work with Objects (option 27=Promote). When creating requests from any of the other Create Request options or menu and command options (including F22=Promote in the Workbench and in Work with Objects) the traditional Create Request panel defaults.

When creating a promotion request, the user profile record is validated to determine the promotion method. If the one step method is enabled, the create request function automatically creates and submits the promotion request. If the one step promotion is not enabled, the traditional Create Request panel displays for further input.

175


With the one step method enabled, from the Workbench you can perform any required overrides (for example, changing special commands or object codes), by selecting the items for promotion and pressing F4=List to display the traditional Create Request panel. This is important to know, because task variations described later in this chapter require processing from the Create Request panel.

To create a one step promotion request

1 Access the Create Request function using any of the following methods for standard one step promotions:

� From the Workbench, type option 11=Promote or from Work with Objects type option 27=Promote next to the items you want to put on the promotion request, and press ENTER.

� From the Workbench or Work with Objects panel, select the member/objects with option 9=Add to Clipboard, and press ENTER. Process the Clipboard with F7=Process Clipboard and then use option 3=Promote.

2 If the Comments panel displays, type a comment and press ENTER (as explained earlier, you may or may not be required to enter comments).

After selecting and processing the items, a promotion request is automatically created and submitted.

In this example, the request was initiated from the Workbench. Notice the Status column indicates ARCMNT is currently being promoted from development to QA. A message displays at the bottom of the


Creating Requests With the Traditional Promotion Method

panel to inform you of the request number and that the move request was submitted.

Resolving Promotion Request Problems

If an error is encountered during the edit check and validation process, the Resolve Promotion Request Problems panel displays, with the appropriate errors listed at the bottom of the panel. You can position to the error and press F1 for additional message information. This panel allows you to resolve the errors; after correcting the errors, press F9=Accept to continue processing the request.


This task allows you to prepare a promotion request using the traditional promotion method. This method displays the Create Request panel, which requires further information about the items being promoted. You can add member/objects to the promotion request either by selecting them from a list or by manually typing the name. After accepting the entries for promotion, the promotion request is created.

The majority of promotion tasks are accessible from the Workbench and from Work with Objects however; they are all accessible from the menu.

The following task assumes the Create Request Comments feature is enabled. For more information, see “Create Request Overview” on page 174.

177


To create a traditional promotion request

1 Access the Create Request function using any of the following methods:

� From My Workbench, type option 11=Promote next to the member/object, or from Work with Objects type option 27=Promote, and press ENTER to display the Create Request main panel.

� Select the member/object with option 9=Add to Clipboard and press ENTER. Press F7 to display the Clipboard Processing Menu, and select option 3=Promote to display the Create Request main panel.

� From My Workbench or Work with Objects, press F22=Promote to display the Create Request main panel and select member/objects.

� From the Implementer Menu, type 3=Create Promotion Request and press ENTER.

� On the command line, type STRIM (*CRTRQS) and press ENTER.

� On the command line type ICRTRQS and press F4.

� Use the PDM option CR on the appropriate member/object.

You can access Emergency Create Request using one of the following methods:

� From the My Workbench or Work with Objects, type option 22=Emergency Promote next to the member/object and press ENTER.

� From the Clipboard Processing Menu, type option 5=Emergency Promote and press ENTER.

� From the Implementer Menu, type option 22=Emergency Create Request and press ENTER.

� On the command line, type STRIM *ECRTRQS, and press ENTER.

2 Complete this panel as described in “Create Request Panel Field Descriptions” on page 179.



3 Press ENTER to verify the entries.

4 Press F9=Accept to create the promotion request. The Create Request Comments panel displays.

An unlimited number of comments can be added to the promotion request, but you must add at least one. Individual member/objects can have a brief comment assigned to them. If a comment was entered for the member or object when it was checked out, it is added to the promotion request. These comments are stored in the Implementer database and are included in the Request Report (MWI0891P), which can be used as a sign off sheet to approve the promotion.

5 Type a comment and press ENTER. A message displays to indicate that the promotion request was created and that it is ready for the next step of the promotion process.

Create Request Panel Field Descriptions

From Library/Environment

Use one of the following options to complete the From location field.

� If displaying, use your default From environment retrieved from the project path, environment path, or user profile.

� Type the environment or library to promote from.

� To list an environment to promote from, position the cursor on the From environment field and press F4=List. Type option 1 next to the appropriate environment and press ENTER.

179


You cannot promote AS/SET definitions from a library. You can only promote AS/SET definitions from a specifically defined AS/SET environment.

Target Environment/Environment Group

Use one of the following options to complete the target environment or target environment group field:

� If displaying, use your default target environment retrieved from the project path, environment path, user profile, or target environment group.

� To list an environment, position the cursor on the target environment field and press F4=List. Type option 1 next to the appropriate environment and press ENTER.

� Type a target environment or a target environment group.

You can only promote AS/SET definitions to a specifically defined AS/SET environment. If promoting an AS/SET definition (using an object code that contains an ADK special characteristic), the from environment and target environment must be defined as AS/SET environments. If it is a target environment group, the AS/SET environment must be the primary environment.

If promoting a LANSA object (using an object code that contains a LAN special characteristic), the from environment and target environment must be defined as LANSA environments. If it is a target environment group, the LANSA environment must be the primary environment.

Project Reference

Use one of the following options to complete the Project reference field.

� Use your default project or the project you selected in the Workbench or in Work with Objects.

If you are using design requests, the associated design request project should default. If it does not, use the appropriate project reference.

� To list a project reference, position the cursor on the Project reference field and press F4=List. Type option 1 next to the project and press ENTER.

� Type a valid project reference.

If you specify a project that has a defined application path, the from and to environments default from the project’s path.



Member/object list

Use one of the following methods to determine member/objects to promote:

� If you initiated the create request process from the Workbench option 11=Promote, Work with Objects option 27=Promote, or option 9=Add to Clipboard, the member/objects currently display on the Create Request main panel.

� Press F10=Select from locks to select from a list of members that are already checked out. You can filter on the DR number to view related locks. For further details, see “Creating Requests by Selecting From Locks” on page 189.

� Type a member/object name and code on this panel and press ENTER. The action defaults based on the existence of the member/object in the target environment when promoting to a production environment.

� Press F8=Member list to display the Create Request Member List Selection panel and either choose all, changed, or specific members (options 5 or 6 to display the Create Request Member Selection panel). Press ENTER to redisplay the Create Request main panel. For further details, see “Creating Requests From the Member List” on page 193.

� Press F9=Object list, to display the Create Request Object Selection panel and choose specific members. Press ENTER to redisplay the Create Request main panel. For further details, see “Creating Requests From the Object List” on page 192.

Developers often select from a list of locked members in the Workbench, Work with Objects, or Create Request Select from Locks. These methods display a list of member/objects checked out to the developer. The items that display are determined by the defaults of the from environment and project specified on the Create Request panel. This method can display locks for other developers, which allows the developer creating the promotion request to promote those member/objects if the developer has move capabilities for the target environment.

Users in a test environment usually select from a list of existing promotion requests to copy member/objects from. In this case, the user who created the promotion request can select from one promotion request or bundle a group of promotion requests that came from development to testing. Combining multiple requests into one large request for promotion to production allows you to create a large version or release request that includes developers requests for one change at a time.

181


Changes can be grouped together to form a release. If using project tracking, changes are filtered by project reference number. Additionally, releases can be automatically rolled back with Archive Recovery.

All valid LANSA objects on the promotion request are bundled into an export list. LANSA objects are promoted in compiled form.

If the member/object being promoted is a LANSA function that exists in one or more than one LANSA process, you must enter the name of the process that the function is being promoted from in the comment field. If you do not enter the process name, the function is selected from the first process.

If the member/object being promoted has one of the special object codes denoting a LANSA or AS/SET object, the from environment should have a special environment denoting LANSA or ASSET.

If you are promoting an AS/SET display program with the associated help, you have to promote two objects with the same name. One of the objects must use the object code with the special characteristic ADKDSP for the display program. The other object must use a separate object code created with the special characteristic ADKHLP to promote the help text associated with the display program.

If you manage AS/SET generated RPG programs having X FILE overrides, use an object code that has the special characteristic RPGADK, in order to compile these programs during promotion. Implementer automatically analyzes these programs and performs the appropriate X FILE overrides before compilation. If the original file name contains 10 characters, thus not allowing an X at the end of the X FILE name, the overridden file cannot be identified. MKS suggests using file names containing less than 10 characters.

Action

Specify the action that you want to take with the member/objects included in the request.



If the action is not specified, the value defaults to 1=Change (the most frequently used action). If you are replacing an existing program with a new program, use option 2=Delete to remove the existing program.

Optimizing Physical File Promotions

Implementer provides a feature that allows you to optimize the promotion of DDS-based physical files created with the Create Physical File (CRTPF) command.

For information on enabling optimized promotions, see Chapter 3 of the Implementer System Administrator Guide.

This feature is globally defined in System Control Maintenance. When enabled, all physical file promotions are automatically optimized, although users with Move Request authority (defined in Work with Users) have the ability to change the optimize status on a per request basis—this is allowed only when creating the request. Changing the optimize status is supported when creating a request using any described method in this chapter; for example, from the menu option or using the ICRTRQS command.

For more information on promoting DDS files and SQL tables, see “Database Management” on page 308.

With optimizing, Implementer uses the Change Physical File (CHGPF) command over the target file/library in production when promoting DDS-based physical files. The processing steps of an optimized PF promotion are similar to those of an SQL DLL file promotion, in that most of the work is performed in the production library during the move step. This technique ensures the integrity of your production files, while at the same time bypasses a significant amount of the promotion processing that otherwise occurs in the Implementer work libraries. Because this technique runs directly over production files, optimized promotions are typically submitted for evening or weekend processing when the files are not used.

When optimize is not used, physical file promotions use the standard Copy File (CPYF) command over Implementer work libraries. Existing data is retained using the record format field mapping options *MAP and *DROP on the CPYF command.

1 = Change Changes the existing member/object.

2 = Create Creates a new member/object.

3 = Delete Deletes the existing member/object from the target environment.

9 = Recomp Recompiles the source member currently in the target environment. Source in the From location is not used. This is commonly done to avoid level checks in programs that do not require any logic changes when a file is changed. It is allowed for source-based objects only.

183


Implementer provides an audit trail for easy detection of optimized requests on the various inquiry panels and reports; for example, Request Inquiry, Compile Requests, and Move Request panels, and the Request Report, to name a few. This allows you to identify whether optimizing was used or is currently in use for the promotion of a particular file or request.

Benefits of Optimizing Promotions

An optimized promotion provides better performance when promoting physical files by reducing the overall promotion processing time. It also reduces the temporary use of disk space that results from having multiple copies of data associated with a traditional copy file technique. Moreover, it reduces the processing time of database file promotions an average of 50 percent over non-optimized promotions.

While this example illustrates a rather small database file, you can expect a larger file with more records to have even greater results.

Consider the following benchmark example of a physical file with 127,000 records and 11 logical files:

Other significant benefits of optimizing include:

� it automatically rebuilds any logical files or indices

� it eliminates copying of data

� it automatically retains triggers and constraints

Automatic Retention of Triggers and Constraints

When checking out DDS PFs or LFs, Implementer copies the source only. When promoting DDS-based physical files on an optimized request, Implementer automatically retains any existing DDS-based triggers and constraints in the target production environment.

When checking out SQL tables, the Primary Key, Unique, and Check constraints are copied to the development environment. The Foreign Key constraint and triggers are dropped to ensure no dependencies exist to a production environment. For sourced-based SQL files, Implementer retrieves the triggers and constraints in the from environments and promotes them forward as well.

To add or remove triggers and constraints, or to retain triggers and constraints without optimizing, use the special commands feature when creating the promotion request. Generally, this requires creating a special

Optimized...the promotion completed in

Not optimized...the promotion completed in

� 2 minutes 15 seconds � 4 minutes 51 seconds



command with the Add Physical File Trigger (ADDPFTRG) command or the Remove Physical File Trigger (RMVPFTRG) command to run After-Move Ok, either on a per request basis or at the environment level depending on the number of triggers. For example, if you create a new physical file, Implementer will only add the triggers and constraints when the file is promoted if instructed to do so in a special command.

General Precautions

When using optimized PF promotions, note that:

� When the attribute of a field changes, for example, from 8A to 10A or from 10A to 8A, any logical files that specify to include the field in the view must be explicitly added to the request to ensure they reflect the change.

� The CHGPF command does not support certain field attribute changes, for example, changing a field from 10A to 10N. If you encounter this problem due to a failed request, you can delete the original request and create a new one. Before promoting the file on the new request, change the optimize status to N. Without optimizing, the existing data is retained using the Copy File (CPYF) command with the record format field mapping options *MAP and *DROP.

Changing the Optimize Status on a Request

Your user profile must have Move Request authority (defined in Work with Users) to change the optimize status when creating a promotion request. Changing the optimize status is supported when creating a request using any described method in this chapter; for example, from the menu option, Workbench, or using the ICRTRQS command.

The following steps assume the PF is checked out and selected for promotion on the Create Request panel.

To change the optimize status for a promotion

1 From the Create Request panel, press F18=Overrides. The Create Request Overrides panel displays.

185


2 In the Optimize PF’s promotion field, type Y to optimize the promotion, or type N to create a promotion without optimizing.

3 Press ENTER. The Create Request panel redisplays.

4 Continue with creating the request as required.

If a request fails, the existing files remain in production as they were before the promotion. After correcting any problems, you can re-submit the request.

Overriding Job Submission Defaults

You can override the defaults established in Work with Environments, Promotion Scheduling for the following fields:

� Date range

� Time range

� Job queue

� Library

� Hold on job queue

To override the job submission defaults

This task assumes you are in the Create Request Overrides panel.

1 From the Create Request panel, press F18=Overrides. The Create Request Overrides panel displays.

2 Verify the Submit request field is Y, and press F18=Submission Overrides to display the Job Schedule Overrides panel.



3 Specify the overrides. Type the Request Submission defaults for the compile stage of the promotion process. The Time range fields must be entered in HH:MM:SS format.

4 Press ENTER to redisplay the Create Request Overrides panel.

5 Press F12=Cancel to redisplay the Create Request main panel.

Changing Job Queues During the Compile Step

Job queue manipulation can affect the successful completion of the CMPCHK job, because if you submit the CMPCHK job before all compiles complete, the compile step fails. To avoid this problem, place the CMPCHK job on hold and do not release it until all other jobs for the request complete. This action allows you to move the compiles to various job queues without impact, provided they process in the proper sequence.

The CMPCHK job checks the job list to verify that all member/objects successfully generated and compiled, and changes the status of the promotion to Move-Pend (or Dist-Pend for remote environments).

Changing Compile Commands

The commands used to compile objects can be modified during promotion request creation by selecting a member/object with option 1=Override creation attribute from the Create Request panel. Only the parameters designated as modifiable in Work with Objects Codes can be overridden. This feature is particularly useful for new member/objects. Existing member/objects are compiled using a combination of overrides and the existing characteristics of the object.

Using this method to change the compile command parameters for an object code only has an effect on the current promotion request.

Compile Command Parameters

At compile time, Implementer uses a combination of existing object characteristics, system command defaults, objects code defaults, and overrides to determine how to compile objects.

The following logic is used for each parameter on the creation command:

� The command parameter is verified to check if it was overridden when the promotion request was created. If it was overridden, that value is used.

� If the parameter was not overridden (or there is no override at all) and the parameter is specified in the object code, that value is used.

187


� The target object is verified to check if it already exists.

If there is no existing target object, the system default is used.

If the target object already exists, it is examined to determine how it was originally compiled. This feature, which the OS/400 standard compilers and creation commands do not perform, ensures objects are correctly created. For example, it is often important to retain customized printer file characteristics. These characteristics could include retain restore display and defer write characteristics for display files; and determine whether the programs should use user rights or owner rights for execution.

You may want to disallow users to override command parameters when they create the promotion request. For example, you may want to disallow changes to the USRPRF parameter for programs. It may be considered a security risk to allow a developer to change a parameter that is associated with adopting another user’s rights during program execution. The object codes for programs with the USRPRF parameter are initially delivered with the Allow change field set to N.

For existing objects, if you want to ensure the existing system default value is used for a parameter but do not want to override the value, you can specify the parameter with no value. For example, if you want to default the Restore Display (RSTDSP) parameter for display files, qualify it as RSTDSP() when you define the object code in Work with Object Codes.

You can promote to a remote environment that has a previous release of the operating system. Implementer checks Network Configuration for the release level of the target system. This value is used for the Target Release (TGTRLS) parameter for commands such as Create RPG Program (CRTRPGPGM) and Create COBOL Program (CRTCBLPGM). This helps to ensure that these objects can be successfully distributed to the remote system.

Compile commands must be defined with the parameter ALLOW (*YES) on the command definition. This allows the command to run with the QCMDEXC program.

For more information about the compile step, see “Compiling” on page 220.

Common Questions

Are the objects moved at this point?

No. Copies of both member/objects that will not be recompiled are placed into a temporary work library. The member/objects remain in the from environment libraries.


Creating Requests by Selecting From Locks

Can developers be restricted from option 2 (Toggle *GRANT/*KEEP authority on the Create Request panel)?

Yes. You can restrict this option for specific environments.

Can developers be restricted from option 1 (Override Creation Command Attributes on the Create Request panel)?

No, you cannot restrict this option as a whole. However, you can restrict individual keywords on the creation command. To effectively prevent changes to the creation command, you can optionally restrict all keywords.

How does Implementer handle a join logical file built over multiple physical files with the same name?

Implementer does not support qualified library names in the logical file source. MKS suggests that you use an open query file rather than a logical file to accomplish this function.

Can the one step promotions be setup on a per developer basis?

Yes. The flags that control this feature are at the user level (defined in Work with Users). You can enable this flag based on the need of each developer.

Keep in mind that the one step promotion method applies to creating requests from the Workbench, the Clipboard, and Work with Objects. All other Create Request options, including the commands and menu options, process the traditional method.

Creating Requests by Selecting From LocksYou add member/objects to a promotion request by choosing from a list of locked member/objects. This is the common way for developers to access locked member/objects from within Create Request. You perform this task when you have completed your changes to member/objects and they are ready to be promoted to the next environment.

The developer must have authority to the Create Request function, as well as authority to create a promotion request to the target environment and out of the from environment.

Member/objects must be included on a promotion request to be promoted. You do not have to use the Select from Locks function. The easiest method is to select the member/objects from within the Workbench or the Work with Objects panel, with the Create Request option or Clipboard option (these options work well for both one step and traditional promotion methods).

189


Benefits of Selecting From Locks

The Select from Locks function is powerful as both a selection method and for inquiry. With Select from Locks you can determine:

� current activity for a specific user

� current activity of member/objects

� active concurrent development and status of resolution

� design request and lock associations (DesignTracker must be installed)

� active emergency work (standard or emergency locks)

� current activity of from and to environments

� lock status

� detailed member information (view or compare members)

� state of a specific project

To select member/objects from locks

This task assumes you are working from the Create Request panel.

1 Press F10=Select Locks to display the Select from Locks panel.

2 Use either of the following options to select member/objects:

� In the Select from Locks panel, type option 1 next to the member/objects and press ENTER. A message displays indicating that the selected member/objects have been inserted on the Create Request main panel. Press ENTER again to return to the Create Request main panel.

� Press F16=Select all and press ENTER to redisplay the Create Request main panel.

NOTE

The Select from Locks panel is versatile for viewing and selecting locked member/objects. Ensure you have correctly established filters for what you want to view. For example, a default project filters out any projects created through DesignTracker that are not equal to the default project of a user.

3 In the Create Request main panel, press ENTER to verify entries.

4 Press F9=Accept to create the promotion request and display the Create Request comments panel.

5 Type your comments and press ENTER to accept the promotion request and return to the menu.


Creating Requests by Selecting From Locks

To display lock information

� From the Select From Locks panel:

a) Use filtering and positioning by key field to select locks for general information viewing. To position to a specific member/object, type in the member/object name, and press ENTER. The most prominent lock information fields can be filtered directly on the Workbench main subfile, while the others are available by the F17=Subset function for viewing a subset of the locks.

b) F17=Subset is especially helpful when you use design requests. Press F17 to display the Subset Lock panel and type the generic DT* in the project reference field, and press ENTER. All of the generated projects associated with design requests display.

� To view detailed information, use options: 5=Display (Lock details organized by lock, object and source information), 10=Compare, 15=Display member, and 16=Print member (to view the source members).

� Merge existing members to create a new member for promotion with option 11=Merge member.

� Perform conflict resolution with option 12=Concurrent development.

Common Questions

Why don’t you see everything checked out to the environment you are checking in from?

By default, this panel initially displays only the member/objects that are checked out to you in the from environment and to the project entered on the previous panel. You can display all objects checked out to this environment by blanking out the filter field on the panel.

NOTE

Even if you set the parameters so you can view member/objects checked out by another user, you are not allowed to check them in. If you attempt to check the member/objects in, you get the message, “Mbr/obj XXXXXX is checked out to XXXXXX”.

191


Creating Requests From the Object ListYou add member/objects to a promotion request by choosing from a list of all objects in the target environment. This task is only available when you promote from an environment, not from a library.

The purpose of this task is to migrate an object back into either a production or a test environment. You can create a promotion request using this function without checking out the object (the environment definition must have the Check out required field set to N). This is particularly helpful when moving objects from one production environment to a different production environment.

This selection method is infrequently used by most users. Most use it when objects have been received from a third party vendor. For example, you may have restored objects from a tape and want to promote some or all of those objects.

This task is typically performed by an environment administrator who has move capabilities or an authorized developer.

You must be in the Create Request function to perform this task.

To create requests using the object list

This task assumes you are in the Create Request main panel.

1 Press F7=Object list to select from a list of objects and display the Create Request Object Selection panel.

2 Type option 1 next to the member/object and press ENTER to select the objects and return to the Create Request main panel.

3 Press F9=Accept to display the Create Request comments panel.

4 Enter the necessary comment and press ENTER to accept the promotion request.

Common Questions

When using F7=Object List or F8=Member List, why don’t you see any member/objects to select?

Either you did not check out the member/objects in Implementer, or you did not run the Build List function for the from environment.


Creating Requests From the Member List

Creating Requests From the Member ListAfter making changes to members and you are ready to promote to the next level (*QAC or *PRD environment), you must add the member/objects to a promotion request. You can do this by choosing, by object code—from a list of members in the from environment. When changing, compiling, and moving source, this function provides ease of selection without having to remember the exact name of source objects.

This task is only available when you promote from an environment (not from a library). It is usually performed by the developer; however, it can also be performed by the environment administrator who has move capabilities.

To perform this task, you must have run the Build List function, and you must have authority to the Create Request function and the authority to create a promotion request for the target environment.

To create requests using the member list

This task assumes you are in the Create Request main panel.

1 Press F8=Member list to select from a list of members and to display the Create Request Member List Selection panel.

2 In the Create Request Member List Selection panel, type option 1 next to All members and press ENTER to redisplay the Create Request main panel.

3 Press F9=Accept to process the promotion request.

4 Enter a comment on the Create Request Comment panel and press ENTER.

Task Variations In the Create Request, Member List Selection panel, do one of the following for Step 2:

� Type option 2 next to the changed members in the Member List Selection panel and press ENTER.

� Display all members as follows:

a) Type option 5 in the option field in the Member List Selection panel and press ENTER to display the Member Selection panel.

b) Type option 1 next to specific members and press ENTER from the Member Selection panel. The Member List Selection panel redisplays. Press ENTER again to redisplay the Create Request panel.

193


� Members appear as changed if they were changed outside of Implementer and the Build List was run to detect this condition. These steps are primarily useful when using a development tool that updates many members without listing the changed members. Follow these steps:

a) From Work with Environments, select option 30 to run the Build List for the environment.

b) Use the development tool that updates source and objects.

c) Rerun option 30, Build List to record the changes for the environment since the last build.

d) Create a promotion request to another environment (using one of the previously defined methods) and select only changed member/objects.

� To select only changed objects, from the Create Request panel press F7=Object List to display Create Request Object Selection panel and press F15=Changed only.

� To select only changed members, from the Create Request panel press F8=Member List to display the Create Request Member List Selection panel and type option 2=Select Changed Members for each applicable code.

� Display the Changed members as follows:

a) Type option 6 in the option field in the Member List Selection panel and press ENTER to display the Member Selection panel.

b) Type option 1 next to specific members and press ENTER to redisplay the Member List Selection panel. Press ENTER again to redisplay the Create Request panel.

� Press F9=Accept to display the Create Request Comments panel. Complete the comment and press ENTER to accept.

Common Questions

Why doesn’t the object exist in the target environment when action type is 1 for change?

This occurs when you use the member’s list to select member/objects. You should change the actual type to 2 for Create.


Creating a Request by Copying a Request

Creating a Request by Copying a RequestTo easily duplicate or combine one or more existing promotion requests into a new single request for promotion, you can create a new promotion request by copying specific information from an existing promotion request. This feature is generally used by developers, or QA and User Acceptance testers, but can also be used by a project leader or environment administrator who has move capabilities.

This feature is particularly helpful when you have a series of special commands on an existing request. This function allows you to duplicate an existing promotion request (including all member/objects) to save time and increase accuracy in your promotions. You do this task when you have made changes to objects and they are ready to promote to the next level (the next level could be a *QAC or *PRD environment). This method is often used in multiple test environments.

The original member/objects are always copied. In addition, if it is a completed promotion request, the target environment of the existing promotion request is used for the from environment of the new promotion request, and the target environment is left unchanged. If it is an open promotion request, the target environment, from environment and project are copied to the new promotion request.

To use this feature, you must have authority to the Create Request function and the authority to create a promotion request for the target environment.

This task assumes you are in the Create Request panel.

To create a request by copying a request

1 Press F11=Copy request to display the Create Request, Request to Duplicate panel and select from a list of promotion requests to copy.

2 Type option 1 next to the specific promotion request and press ENTER to redisplay the Create Request panel.

3 Verify the target environment is correct.

If the request is complete, the target environment of the original request becomes the from environment and the target environment. If the request is not complete, the environments remain as the original promotion request. In either case, you must modify one or both of the environments.

4 Press F9=Accept to process the request. The Create Request Comments panel displays.

5 Type a comment and press ENTER.

195


Common Questions

How are sure the request on the list is the one you want, or is there a way to see the member/objects on a particular request?

Yes. Use option 5 on the Create Request, Request to Duplicate panel, or use Request Inquiry before you create the promotion request.

What happens to the objects in the request that were copied? What is their status? Are they still locked?

The original promotion request and objects remain unchanged. The new promotion request initiates a new series of promotion status codes related to the new request. If the original request was to a production environment and completed, the locks were removed at the time of the original promotion. If the original request was not to a production environment, the locks were updated by this promotion request.

Creating Requests With the ICRTRQS Command

Once you have changed member/objects and you are ready to promote them to the next level (either to full production or to a test environment), the developer or project leader can use the Create Request (ICRTRQS) command. This command allows you to create a promotion request from the command line, or embed the command in a program. It is useful, along with its PDM (CO) and PathFinder (IR) options, when you want to promote a few known member/objects. The menu interface is more helpful when there are many member/objects or you do not know the member/objects by name.

When using this command for SQL objects, ensure that you use SQL object codes (with the SQL special characteristic) only for SQL objects. For example, you cannot use the SQLT object code (for SQL Tables) to promote a DDS-based physical file.

In addition, you cannot mix SQL and DDS files—for example, you cannot promote an SQL-based logical file over a DDS-based physical file (and vice versa).

The Create Request (ICRTRQS) command does not support AS/SET definitions.

The developer must have authority to the Create Request function, as well as the authority to create a promotion request for the target environment.


Creating Requests With the ICRTRQS Command

To use the ICRTRQS command

1 At a command line type ICRTRQS and press F4.

2 Complete the following required fields:

� Member/Object

� Object code

� Comments

The other fields default based on your user profile defaults.

For the From environment and To environment parameters, use the *PATH default or type the environment names.

The project reference can default from the user profile. If the user profile is not assigned defaults for these values or if you are checking out to different environments (or neither), type the project reference.

If you specify a project reference value along with the *PATH default environment value, Implementer first attempts to derive the environment value from the project path. If it is not successful (indicating the specified project does not have a defined application path), it looks for an environment path. If that is not successful the *PATH value is not replaced and a message displays stating you must enter an environment name.

If the Optimize PF Promotions feature is enabled and your user profile has move authority, you can override the optimize the PF promotion default.

NOTE

If you need to request more than one member/object, type + in the field next to the member/object list and press ENTER to display the Specify More Values for the Member/Object panel. This allows you to insert numerous member/objects.

3 Press ENTER to accept the promotion request.

197


Creating Requests With the ICRTRQS Command PDM Option

When you make changes to member/objects and are ready to promote them to the next level (production or a test environment in the developer’s preferred PDM environment), the Create Request (ICRTRQS) command is available as the PDM option CR. This is a helpful feature because it uses Implementer change management control within a PDM environment.

The PDM option uses the ICRTRQS command, which is accessible from within PDM, and avoids disrupting a developers normal development work. Because the PDM option calls the ICRTRQS command, it does not have the full functionality of the Create Request menu option. It is helpful to define the target environment definition to have the Auto Submit field in the Create Request defaults set to Y (yes) and the Through Step field set to 2 to (compile). For more information, see “Setting Up User-Defined PDM Options” in Chapter 3 of the Implementer System Administrator Guide.

The developer must have authority to the Create Request function, as well as the authority to create a promotion request for the target environment.

NOTE

You must set the option file in PDM (F18=Change Defaults) to IMPDMOPT, the library to MKSIM, and the member to IMPDMOPT. To view the options, press F16=User options.

To create requests with the ICRTRQS command PDM option

1 Use PDM option AC (Add to Clipboard) for each member/object you want to promote. This adds the member/object to the clipboard.

2 Use PDM option CR to display the Create Request (ICRTRQS) command panel. Complete the parameters as needed. You can select individual members, or specify member *CLPBRD to process all previously selected members.

3 Press ENTER to accept the promotion request.

Common Questions

Do you need to set up the CR option?

Yes. It is necessary to set the option file in PDM (F18=Change Defaults) to IMPDMOPT, the library to MKSIM, and the member IMPDMOPT. To view the options, press F16=User options. Alternatively, this option can be added to any options file.


Selecting Additional Target Environments

Why is the CR option not in the PDM options library?

You need to insert them or change the file, library, and member defaults. To add them to the regular PDM library, write them in manually; do not copy them with the CPYF command. The IBM file is a sorted file and not a keyed access file. The options are not in the proper order.

Can you add more than one member/object on a promotion request created with ICRTRQS?

Yes. To add multiple members to the request, specify *CLPBRD to add all previously selected members to the request.

Selecting Additional Target EnvironmentsWhen the member/objects are ready for promotion back into either production or a test environment, the user profile default allows you to enter either a single environment or an environment group as the default target environment or environment group. If you want to send the promotion to more than one environment for a special situation, you can add the necessary environments by using this task. You can also use this task to change the default compile.

Normally, if you have a consistent number of target environments, the best way to promote requests to multiple environments is to use the Work with Environment Groups function. For more information, see “Working With Environment Groups” in Chapter 3 of the Implementer System Administrator Guide.

You can promote AS/SET definitions to multiple target environments as long as the primary environment is an AS/SET environment. If non-AS/SET environments exist in the target environment list, you cannot promote AS/SET definitions to these environments although promotion occurs to the AS/SET environments on the list.

To perform this task, previous member/objects must be checked out. It is helpful to choose beforehand the member/objects you want to promote in the Create Request panel.

199


To create requests to additional target environments


1 Press F14=Target environments to display the Create Request Target Environments panel.

If you use a target environment group, the panel displays the environments that are a part of the group. It does not allow you to select environments.

2 Type option 1 next to the environments, and press ENTER to accept the selected environments. The Create Request panel redisplays. (If the Target environment is an environment group, this panel is display only.)

a) Verify that the sequence number of each environment is in the appropriate order.

b) Verify that the Cmp field is set to Y if you want to compile the member/objects, or set to N if you do not want to compile the member/objects.

3 Press F9=Accept.

4 In the Create Request comments panel, type a comment (this is automatically logged on the promotion request), and press ENTER to confirm the promotion request.

Common Questions

Are all listed environments available for promotion?

No. Only the target environments that you are authorized to promote to will be available.

Promoting Related ObjectsTo prevent corruption of your production systems when a software change is made, it is critical to ensure that all impacted objects are reviewed, changed, and/or recompiled as needed. Implementer provides maximum flexibility for managing related objects within a selected environment or optionally, across multiple environments.

First, Implementer uses the Build List function as the source of related objects across environments, including remote environments. The Build List updates the repository to show the environments where related objects exist. When displaying or selecting related objects, Implementer displays a list of all related object that exist in all environments.


Promoting Related Objects

Implementer allows you to review impacted objects and select any or all of them for checkout. In addition, any impacted objects that were not checked out but still require compiling are automatically added to the promotion request, compiled, and promoted when their associated objects are promoted.

During promotion, Implementer’s advanced related object support determines related objects that exist within the target environments specified on the request. You can include related objects on the request to ensure that all programs that use a particular display file, physical file, or logical file are automatically recompiled. The related objects are added to the promotion request with an action of 9 for Recompile. Logical files that are not manually added to a promotion request are automatically recompiled if the physical files they are built over are on the request (these are referred to in Implementer as implicit logical files). You can optionally not include related programs; this requires the Add Related Objects field in the environment definition be set to N.

Impact analysis supports both Implementer and Hawkeye as an environment’s source of related object information.

You can optionally configure Implementer to determine related objects that exist outside of the target envrionments and automatically generate a promotion request for any related objects that exist in environments not included in the original request. This feature is explained next.

NOTE

When using Hawkeye, Implementer only supports cross-environment related objects when defined within the primary Hawkeye database library. In addition, Hawkeye does not support cross environment related object processing for objects that exist in *QAC environments.

Related Request Processing

You can optionally configure Implementer to automatically generate promotion requests for related objects that exist in environments not included in the original request.

The primary request is the original promotion request that you create; it contains the items for which related objects are searched. Any subsequent request that is generated from the primary request due to cross-environment related objects is called a secondary request. Secondary requests are related to the primary request. Secondary requests are created only by Implementer, when related objects are found in one or more environments not included on the primary request. A user cannot create a secondary request.

201


Implementer issues the ICRTRQS command to create a secondary request for each different environment a related object is found in. If a project is specified, it is copied from the primary request to all secondary requests. A secondary request is created with the default value of Add Related = Y.

Once the primary request is complete and all objects are moved to the target environment, Implementer submits any secondary requests that need to be generated. A single primary request can generate one to many secondary requests, depending on the number of environments a related object is found in.

For example, the following promotion request scenario causes three occurrences of the ICRTRQS command…

… And results in the creation of three secondary requests.

A secondary request can be submitted by a user (using commands or interactively) only if the request is a re-start, and only when the primary request is at a status of Completed.

When determining the target environment for generated secondary requests, Implementer processes in the following order (where “environment” is the location the cross-environment related object is found).

1 If the environment is defined on the project path of the primary request, the environment is used.

Initial Requesttargets Environment 4

Related Objectsin Environment 4

Cross-Environment Related Objects

Object 1 obj A and B obj A - Env 1 obj B - Env 2 obj C - Env 2

Object 2 obj D obj D - Env 1 obj D - Env 2 obj C - Env 2

Object 3 obj A and B obj A - Env 3 obj B - Env 3 obj C - Env 3

Object 4 obj A obj A - Env 1 obj A - Env 2 obj A - Env 3

Request TypeTarget Environment

Related Objects

Secondary Request #2 Env 1 obj A obj D - -

Secondary Request #3 Env 2 obj B obj C obj D obj A

Secondary Request #4 Env 3 obj A obj B obj C -

Primary Request #1 Env 4 obj A obj B obj D -


Promoting Related Objects

2 If the environment is part of a group on the project path of the primary request, this group is used.

3 If the environment is defined on its own environment path, the environment is used.

4 If the environment is part of a group on its own environment path, that group is used.

5 If the environment is on the environment path of the target environment of the primary request, the environment is used.

6 If the environment is part of a group on the environment path of the primary request target environment, this group is used.

7 If the environment is defined on any project path, the environment is used.

8 If the environment is part of a group on any project path, this group is used.

9 If the environment is defined on any environment path, the environment is used.

10 If the environment is part of a group on any environment path, the group is used.

11 If the environment is part of any group, the group is used.

12 Use the environment.

IMPORTANT

In previous releases of Implementer, an object code environment override method was used to handle cross-environment related object processing. While this method is still supported, be aware of the following:If you currently use the object code environment override method and decide to de-activate or delete any associated object codes (to use the automated method), you will lose the history of the relationship between the old and the new object definitions, since the object will change with the new method.

If the automated method is enabled and you continue to use the object code environment override method, the secondary request generation process will not occur.

Displaying and Selecting Related Requests

When displaying and selecting related objects, Implementer displays all related objects in all libraries. However, if Implementer determines that a related object is in a library not defined to an Implementer environment, a message displays to inform you.

203


In Request Inquiry, you can determine if a request has any related requests by the Related Requests column. When related requests do not exist, the value is blank. When related requests do exist, either the value “Primary” or “Secondary” displays to identify the related request type. Use option 15=Related Requests to display a list of the related requests. Alternatively, from Request Inquiry select the request with option 8=Request info and press ENTER. Press F15=Related requests. You can display the related request details with option 5=Display.

This feature is also available from various other Implementer panels: Compile Requests, Move Requests, Request Maintenance, Request Selection, Work with Remote Requests, and Archive Recovery.

Deleting Related Requests

When you delete a primary request, Implementer also deletes any secondary requests generated for cross-environment related objects. Secondary requests are only deleted when the primary request is deleted. However, a caveat to this rule is explained with the following example: A primary request is at a status of Completed with a secondary request at a status of Move-fail. If you select to delete all requests at an OPEN status (expecting to delete both of these requests) the secondary request will not be deleted because the primary request is not at the OPEN status specified.

Related Requests in Archive Recovery

Archive recovery supports the rollback of generated secondary requests.

From the Archive Recovery panel, you can determine if a request has any secondary requests by the value in the Related Requests column. When related requests do not exist, the value is blank indicating a standard release. When a related request does exist, the value “Primary” or “Secondary” displays to identify the release type.

Use option 1=Select to rollback a primary or secondary request. Use option 15=Related Requests to display a list of the related request detail (although recovery options are not available from the Related Request panel).

NOTE

The cross-environment related object promotion feature is controlled by a global value defined in System Control Maintenance. This gives you the ability to enable and disable the feature as needed. By default, the feature is disabled. You can also define whether Implementer causes a primary request to end (in Comp-fail) or continue, if there is an error while generating any secondary requests for cross-environment related objects. This feature also requires the Add Related Objects field in the environment definition be set to Y.


Overriding Create Request Defaults

Overriding Create Request DefaultsIn general, you establish environments and user profiles to provide consistent defaults when using Implementer. At times, however, you need the flexibility to override the specific defaults to accommodate a special situation. Overriding the create request defaults provides a development shop with this option. It allows you to override the defaults established in Work with Users and Work with Environments.

There are two typical situations where overrides are used:

� To override the defaults (set up in Work with User Profiles) to leave objects and source in developer library.

� To vary the promotion process so that you do not issue separate promotion tasks (for example, create a promotion request, compile a promotion request, move a promotion request, or move a promotion request by system steps). These defaults are set up in Work with Environments by the Auto Submit in Create Request field.

This function is generally used by project leaders, or the person who creates the promotion request. Their user profile must have the User Controls set to Y for the Override remove from obj and Override remove from src fields for authority to override these values on the request. In addition, the environment must have the three Create Request defaults Chg flags set to Y.

Perform this task when the member/object is ready to be promoted. The member/object must be checked out.

NOTE

Implementer can grant LANSA export/import rights to users automatically during the migration of LANSA objects. Because Implementer uses the export/import processes for the migration of LANSA objects, insufficient LANSA authorities on the objects can lead to failure of migrations. Therefore, if you are authorized to check out or create promotion requests, you are automatically granted LANSA authority to perform the export and import processes. This authority is in effect only during the time the export or import process is executed. It is automatically revoked when migration is complete.

Removing Objects and Source in Promotion

You have the option to customize how Implementer automatically handles objects and source in a local *TST or *QAC environment, upon successful completion of a promotion request from the environment.

This feature is enabled by defaults at the environment level, with validation to environment object code overrides as needed.

205


The valid options for removing objects and source are:

� 1=always. Automatically deletes objects and source.

� 2=never. Retains the objects and source.

� 3=per object code. Specifies to proceed on a per-object code basis, by validating to the environment’s object code overrides. If the override value is set to Y, the object and/or source is deleted. If the override value is set to N, the object and/or source is retained.

If a user attempts to change the default values for the remove flags on the promotion request, the user profile Allow Override fields are validated for authority to perform the override.

When promoting from a library the request level flags are set to the value defined for the user profile creating the request. When the user profile flags are set to N, the request level flags default to 2=never. When the user profile flags are set to Y, the request level flags default to 1=always. This can be overridden provided the user has proper authority. The value 3=per object code is not allowed when promoting from a library.

For information on setting up this feature, see the Implementer System Administrator Guide.

When promoting from a *TST or *QAC environment, the request level flags default to the value defined for the from environment. (This feature does not apply to *PRD or remote environments since Implementer does not allow promotion from these environment types.)

To override the create request defaults

This task assumes that your user profile is configured to allow overrides, you are in the Create Request main panel, and have already selected the member/objects for promotion.

1 Press F18=Overrides to display the Create Request Overrides panel.

2 Type the new values as follows:


Overriding Create Request Defaults

3 If you change the overrides for the compile step of promotion scheduling, press F18=Submission overrides to display the Job Schedule Overrides panel. Complete the changes or accept the

Field Description

Separate model copy step

For COOL:2E environments only. Specify whether to execute the Copy Model Objects command separate from the Submit Model Create function. Specify Y to execute the model copy and compile in separate steps: specify N to execute in one step.

Remove obj in from lib/env

Specify whether to automatically delete the objects in the from environment upon successful completion of the promotion request. Specify 1=always, 2=never, or 3=per obj code.

Remove src in from lib/env

Specify whether to automatically delete the source in the from environment upon successful completion of the promotion request. Specify 1=always, 2=never, or 3=per obj code.

Add related objects to request

For traditional environments only. Specify whether to add all related objects to the request before promoting the request. Adding related objects to a request ensures you do not promote an object that would cause a level check in this environment.

Submit request Specify whether to automatically submit the promotion of this request. If you specify Y, a job to promote the promotion request is submitted when you accept the promotion request. If you specify N, you must promote the promotion request using the menu options Compile Request, Move Request, and Move Requests by System/Environment.

Through step Specify how much of the promotion is performed when you auto-submit from Create Request. Each subsequent promotion includes the prior step (in other words, compile includes export (if a LANSA environment), distribute includes export (if a LANSA environment), and compile and move includes export (if a LANSA environment), compile, and distribute). 1=Export (if a LANSA environment)2=Compile (only valid for Compile Required = Y)3=Distribute (only valid for remote environments)4=Move (no special edits)

207


defaults and press ENTER to redisplay the Create Request Overrides panel. Note that Time range fields must be entered in HH:MM:SS format.

NOTE

The only time a promotion scheduling change can occur from Create Request is when the submission options for Auto-submit in Create Request is set to Y through the compile step.

4 Press ENTER to redisplay the Create Request main panel.

Common Questions

Can you stop other users from changing overrides?

Yes. Restrict their authority through user profile maintenance and environment setup.

Changing Request DetailsAuthorized users can optionally change the source of object attributes, during promotion from the target environment to the source environment. In addition, you can identify the order that objects within the same object code are created.

This task assumes you are in the Create Request panel and the member/objects are selected for promotion.

To change request details

1 In the Opt column, type 2 next to the member/objects you want to change.

2 Press ENTER to display the Request Detail Maintenance window.


Changing Request Details

3 Complete the fields as follows:

a) Action

Specify the action to take with the member/objects included in the request.

b) Obj attr source

The target environment is searched for an existing copy of the object you are promoting, and, if found, that object is analyzed to preserve as many of the existing object attributes as possible. If an existing object is not found, Implementer looks in the production environment. Any attributes explicitly entered on the creation command, however, are not replaced by the analysis process. The ability to alternatively analyze the from environment is provided.

1 = Change Changes an existing member/object. This is the default value if the object already exists.

2 = Create Creates a new member/object. This is the default value if the object does not exist in the From production environment.

3 = Delete Deletes an existing member/object from the target environment. Use this to remove an existing program when you are replacing it with a new one.

9 = Recomp Recompiles the source member currently in the target environment. Source in the from location is not used. This is commonly done to avoid level checks in programs that do not require any logic changes when a file is changed. This is allowed only for source-based objects.

209


The default value is 1. However, if the Action code for the member/object is 2=Create, the default is 2. Specify which environment to copy object attributes from.

IMPORTANT

You must have the Override object attribute source field set to Y to change the default. This is defined in Work with Users, Environment Capabilities.

c) Create sequence

Specify a value from 0 to 9999 to indicate the order to create this object within the specified object code.

4 Press ENTER to display the Create Request Comments panel and continue creating the promotion request.

1 = To environment

Copies object attributes from the target environment. If no object attributes are found in the target environment, it looks to the next target environment in the application path (project path or environment path, whichever is used).

2 = From environment

Copies object attributes in the from environment. If no object attributes are found in the from environment, it looks to the next target environment in the application path (project path or environment path, whichever is used).


Maintaining Promotion Requests

Maintaining Promotion RequestsIt is sometimes necessary to maintain certain aspects of the request (for example, target environments, member/object additions or deletions, or special commands) after a request is created and before it is successfully compiled.

This task allows you to maintain almost all aspects of a request (except environment information). It also allows you to recopy the source from the from library to the holding library for the source. This is useful when a change has been made to the source after the request is created and the source is needed on the request.

The following restrictions apply:

� Only the user that created the initial promotion request or the user that has move capabilities for the primary target environment can maintain a promotion request.

� You cannot maintain a promotion request once the objects for that promotion request are successfully compiled. You can only maintain promotion requests with a status of Comp-Pend, Comp-Fail, Expt-Pend, or Expt-Fail.

To maintain promotion requests

1 Type menu option 13 or STRIM (*RQSMNT) at the command line and press ENTER.

2 In the Request Maintenance panel, type a promotion request number, or press F4 to list the existing promotion requests.

If you want to choose from the promotion request list in the Request Maintenance Request Selection panel, type option 2 next to the promotion request you want to select, and press ENTER.

3 In the third Request Maintenance detail panel, perform the necessary maintenance and press ENTER to verify entries.

4 Press F9=Update to accept the changes.

5 In the Request Maintenance comments panel, type additional comments to describe the maintenance completed, and press ENTER to accept the promotion request. The Request Maintenance Request Selection panel redisplays.


211


Promoting IFS Files and DirectoriesIFS files and directories can be promoted using the same basic methods as are used for any OS/400 object; however, note the following variations:

� New object codes are automatically added to the Implementer list of object codes, provided this feature is enabled in System Control Maintenance.

� IFS files and directories must be promoted from an environment rather than from a personal directory.

� Implementer provides mounted drive support for IFS objects that reside on a computer running Windows NT Server. This feature requires additional setup considerations for environments, user profiles, and communications. For more information, see Chapter 3 of the Implementer System Administrator Guide.

The following actions occur during the promotion of IFS objects:

� Work folders are created for each request under a single root folder, /IMPRMRQS.

� Target environment directories are created if they do not exist, using the owner and authority defined for the environment.

� In OS/400, authorities are always set based on the environment definition. The authority method of *GRANT is required.

� On a Windows NT Server, any objects placed on the NT Server by Implementer inherit the authorities of the target directory. Any authorities defined to the environment or existing on the From object are disregarded.

� When a directory or all items in an environment (specified as *.*) are promoted, the entire target directory being updated is archived.

� Files and directories in the from location are optionally deleted.

NOTE

Support for Document Library Objects (DLO) within the IFS is included. When performing change management of DLOs, all DLO attributes and characteristics are automatically retained. However, promotion of QDLS and DLO objects is only supported within the system Auxiliary Store Pool (ASP) ASP1. This is because the Move Object (MOV) command that is used to move QDLS and IFS objects from the staging directory to the target directory does not support spanning of ASPs.


Promoting IFS Files and Directories

Support for Browser-based Promotions

Implementer provides support for your client/server and e-Business applications by offering check out and promotion deployment of IFS objects, using a browser interface. This browser-based integration is built on the existing proven framework of Implementer technology, which includes the latest support for IFS technology and the change management of client/server development. For more information, see the Implementer Multi-Platform Solutions Guide.

Options for Promoting IFS Objects

In addition to promoting IFS objects as that of any traditional OS/400 object (for example, using option 11=Promote from the Workbench), you can also promote IFS objects using any of the following methods:

� listing individual IFS files

� listing individual subdirectories

� using *.* to specify an entire environment

To promote individual files

1 Create a promotion request using any method specified in this chapter.

2 At the top of the Create Request panel, specify From and To environments that are set up to manage IFS objects.

3 To specify the IFS files for promotion, type the IFS file name in the Mbr/obj field, and type the extension in the Code field.

For example, to promote the file ITEM.EXE, type ITEM in the Mbr/obj field and .EXE in the Code field.

To promote subdirectories

1 Create a promotion request using any method specified in this chapter.


3 To specify the IFS subdirectories for promotion, type the IFS directory name in the Mbr/obj field and type a backslash (\) in the Code field.

For example, to promote the subdirectory SUBDIR2, type SUBDIR2 in the Mbr/obj field and \ in the Code field.

Although not a common practice, you can have subdirectories with extensions. In this case, specify a backslash (\) followed by the extension in the Code field. For example, to promote the subdirectory SUBDIR2.DIR, type SUBDIR2 in the Mbr/obj field and type \.DIR in the Code field.

213


To promote the entire contents of an environment (*.*)

1 Create a promotion request using any method specified earlier in this chapter.


3 To specify the entire contents of the environment for promotion, type *.* in the Mbr/obj field and type a backslash (\) in the Code field.

Considerations When Using *.* for Promotion

When checking out and promoting IFS files and directories using *.*, keep the following points in mind.

IFS Object Management

When promoting IFS files and directories, Implementer does not completely replace the current content of the target environment with the promoted IFS objects. The copy of new, existing, and deleted IFS objects is as follows:

� New Objects

When an IFS object being promoted does not exist in the target environment, that object is added to the target environment.

� Existing Objects

When an IFS object being promoted already exists in the target environment, the existing object is deleted in the target environment and replaced with the promoted object.

� Deleted Objects

When no IFS object corresponds to one that exists in the target environment, the existing object is left in the target environment.

TIP

If you need to ensure that only the IFS objects contained in the promotion request are stored in the target environment, be sure to clear the target environment of all objects prior to initiating the promotion request.

Mixing Individual File and *.* Promotions

In the event that, after checking out individual items, you decide to check out and then promote the entire contents of the environment using *.*, you must first consider the potential results of this mix.



For example, assume that you initially check out a single IFS file, FILE1.PRG. After making changes and saving the file, you realize you need to change more files in the environment, so you check out the entire environment’s contents to the same target environment using the *.* method. This action overwrites the FILE1.PRG that was already in the target environment, which may have been the result you wanted. If you wanted to retain your changes, however, you would need to check out the additional files by specifying them as individual files.

Continuing with the example, when you later promote the environment’s contents using the *.* method, the unchanged FILE1.PRG is moved back into production. Additionally, if the Remove from objects field on the Create Request panel is set to Y, file FILE1.PRG no longer exists in the directory in the From environment since this file was also checked out individually. The locks placed on the file during the initial check out still exist, although the file does not. You can correct this situation by manually deleting the lock on the file. Again, this situation can be avoided by continuing to use the single file method for your promotion.

TIP

For most purposes, use the same check out method each time you perform a check out to the same target environment. Then, continue to use this method when creating promotion requests for the checked out IFS objects.

Automatically Creating Object Codes in Create Request

When you create a request for an IFS file or directory with an extension that does not currently exist in Work with Object Codes, Implementer can automatically create the new object code.

NOTE

Contact your Implementer System Administrator to determine if this option is enabled.

To create an IFS object code during create request

1 Access the Create Request panel from Work with Objects or the Workbench (option 11), or by using option 3 from the Implementer Menu.

2 Create a request for an IFS object using environments set up to manage IFS files. If the object code (preceded by a dot (.) if a file, or a backslash (\) if a directory) does not exist, a message displays offering different processing options. This message is identical to the one that displays when checking out an object.

215


3 Type one of the following values in the Reply field:

Upgrading a Directory

To upgrade a directory, you have two options when promoting directories:

� You can update applicable files in the target directory with those contained in the promotion request. Additionally, new files on the promotion request that do not currently exist in the target directory are added. Any files that are not part of the promotion request but that already exist in the directory are not deleted from the target directory. This option is useful any time you do not want to clear the directory before the move—for example, if you are creating a promotion request to update or add new form letters to a directory. This option is the default and requires no additional action.

� You can issue a special command at the time of promotion to replace the entire contents of the target directory with the files in the promotion request. This option is useful when you want only the files in the promotion request to be in the target directory—for example, when you are totally replacing one version of an application with a new one.

Special Command Considerations

You must have authority to the target directory being removed.

The special command option deletes the target directory and removes the directory contents prior to the move step of the promotion. When the deletion is complete, the move step recreates the target directory and moves the objects in the promotion request to the newly created target directory. The result is that only those objects in the promotion request reside in the target directory.

1 = Don’t add Use this option if you do not want to add the new object code. The Check Out panel redisplays. Specify a different object code for create request.

2 = Add Use this option to automatically add the object code and continue to be prompted during this create request session if any other object codes do not exist. When you press ENTER, the new code is created, and the request proceeds normally until another non-existent object code is found.

3 = Add all future without warning

Use this option to automatically add the object code and to continue adding any other non-existent object codes during this create request session without being prompted again, type. When you press ENTER, all new object codes are created and the request proceeds normally.



The special command supports multiple distributions, provided each distribution targets a different remote system using an identical target path. To promote to multiple target paths on the same system, you must issue multiple requests.

Since the target directory is removed prior to the move step (when it is recreated), this special command does not allow archiving. However, you can perform backups using standard methods available outside of Implementer.

To replace the contents of a target directory using a special command

1 From the Create Request panel, press F17=Special Commands to display the Work with Requests Special Commands panel.

2 Press F6=Create to display the Expanded Command Display panel.

3 Complete this panel as follows:

4 Press ENTER to add the command. Press F12 twice to redisplay the Create Request panel.

For Action Type 4 to issue the command as part of the Move step.

When to do Type 1 to issue the command before the Move step.

Sequence number

Type a valid sequence number.

Command RMVDIR DIR(full_target_path) RMVLNK(*YES)(Where full_target_path is the full path of the target directory.) To remove the contents of the directory you must define the RMVLNK parameter as *YES.

217


Java Optimization

Java optimization is available for all JAR files (.jar), class files (.class), and compressed file archives (.zip) processed through Implementer. This allows you to control whether optimization occurs and the optimization level.

Java optimization occurs through the Create Java Program (CRTJVAPGM) command. You implement it by defining the Execute Request Detail (IEXCRQSDTL) special command for all applicable environments targeted on a promotion request, after move-ok.

Define the command for the *CREATE and *CHANGE actions, for the .class, .zip, and .jar object codes.

When defining the IEXCRQSDTL command with the CRTJVAPGM command, set the OPTIMIZE parameter based on your requirements and following the IBM standards for the CRTJVAPGM command. The #OBJECT value on the Class File parameter returns the IFS file name.

Define the command as illustrated next:

IEXCRQSDTL OBJCODE(‘.CLASS’)NAME(*ALL)ACTION(*CHANGE)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND(CRTJVAPGM CLSF(‘#PATHOBJ’) OPTIMIZE(20) REPLACE(*YES) ENBPFRCOL(*NONE))

Promoting Physical File DataImplementer provides the PF object code to promote physical files when you have changed the source members. To promote the contents of a physical file, you must use the PFDTA object code.

The next example illustrates how to complete the Create Request panel to promote a physical file and the related data.


Using Different Source and Object Names in Promotion

In this example, when the request is promoted the physical file will be recreated, and the data from IVCMST physical file in the IV_TST environment will be copied into the IVCMST physical file in the IV_QAC environment.

Using Different Source and Object Names in Promotion

For situations where source and object names are different, Implementer provides full support based on the object name.

The following tasks must be performed prior to using different source and object name support:

For description of these tasks, see the Implementer System Administrator Guide.

� define to and from environments for check out

� define object codes that use creation commands with the SRCMBR parameter (must use the keyword #SRCMBR)

� run the Build List function

Once the setup activities are complete, you can perform all promotion activities by specifying the object name.

� If you specify the source name rather than the object name, the following message displays to notify you that you must use the object name: “Cannot promote with source member name”

219


� For promotion of source-based only items, the source member name is allowed.

� Although the object name displays, the correct source member name is used automatically, anywhere the source must be referenced.

� Locks are based on the object name.

CompilingIn most situations it is necessary to compile the changed source or related objects before Implementer moves it back into a work environment. It may be required if the target environment has the Compile required field set to Y. You can automatically compile if you set the target environment Through Step to 2. You can also submit the compile manually through the menu interface.

When compiling from the Workbench, the compilation of selected source members occurs in alphabetical order within the creation sequence specified for the applicable object code. This allows, for example, for physical files to compile before logical files and all files to compile before programs.

When object version stamping occurs during promotion, the object is stamped with the revision number (and DR number, if specified) for requests that are defined as Compile=Y. For more information see “Object Version Stamping in Promotion” on page 251.

You can promote AS/SET definitions to multiple target environments provided the primary environment is an AS/SET environment. If non-AS/SET environments exist in the target environment list, you cannot promote AS/SET definitions to these environments, although the promotion will occur to the AS/SET environments in the list.

To perform this task, the promotion request must have the status of Comp-Pend.

To submit a promotion request for compile

1 Type menu option 4 or STRIM (*CMPRQS) at the command line and press ENTER. You can also access this function with F14=Compile requests, in the Workbench and the Work with Objects panel.

2 In the Compile Request selection panel, type 1 in the option field, and press ENTER to submit the compile.

3 When a message displays indicating the promotion request was submitted, press F3=Exit to redisplay the menu.


Compiling

Task Variations

This section describes task variations and additional processing you can perform when using the Compile Request function.

Changing and Submitting the Compile Request

1 Type menu option 4 or STRIM (*CMPRQS) at the command line and press ENTER. You can also access this function with F14=Compile requests in the Workbench and the Work with Objects panel.

2 In the Compile Requests selection panel, type option 2 next to the promotion request and press ENTER to change the promotion request.

3 In the Change Compile Request panel, change one of the following:

� Object attributes (option 1)

� Object authority (option 2)

� Target environments (F14=Target environments)

NOTE

If you want to change the overrides for the compile step of promotion scheduling, press F18=Submission overrides to display the Job Schedule Overrides panel. This can be done from either the Compile Requests selection panel or the Change Compile Request panel. Fill in the changes or accept the defaults and press ENTER to redisplay the previous panel. Note that Time range fields must be entered in HH:MM:SS format.

4 Press F9=Submit to submit the promotion request and redisplay the Compile Requests selection panel.

5 When the message displays that the promotion request was submitted, press F3=Exit to redisplay the menu.

Submitting Overrides

You can override the defaults established in Work with Environments for promotion scheduling.

This task assumes you are in either the Compile Request selection panel or the Change Compile Request panel. Both the selection and detail panels allow you to override the promotion scheduling defaults.

To override the submission defaults

1 Press F18=Submission overrides to display the Job Schedule Overrides panel.

221


2 Type the appropriate Request Submission overrides for the compile stage of the promotion process. Note that Time range fields must be entered in HH:MM:SS format.

3 Press ENTER to redisplay either the Compile Request selection panel or the Change Compile Request panel.

Staged Compiles

Compilation is done into a work library. First, this ensures that for large promotion requests, the target libraries (that could be production libraries) are not left in a partially promoted state during the compile step. This eliminates downtime of a production environment. Second, if a source member fails to compile, the target libraries are not left partially promoted and damaged. Third, the compile can be initiated by a developer and the move can be performed by someone who has control over the target libraries.

Objects are staged for compile purposes. The source is staged when the promotion request is created. This ensures that the promotion request contains the moved source member.

For example, if you create a promotion request at 10:00 a.m. and a source member in the development library was changed at 10:30 a.m., the source member, as it existed at 10:00 a.m., is used for promotion. In addition, when the promotion request is completed, the administrator receives a message that the development source member was changed after the promotion request was created.

Compile Library List

Implementer uses the compile library list defined for the target environment. This feature prevents level checks in the production library due to the wrong library list used for compilation.

In addition to the libraries on the environment library list, Implementer adds two work libraries to the library list ahead (at the front) of the other libraries—the Request Objects Library and Request Source Library. This ensures programs are compiled against the correct display files, and that the correct RPG copy blocks or COBOL copy blocks are used.

NOTE

A common cause of compile problems is incorrectly defining the library list for compilation when creating a new environment.


Compiling

Third-Party Compile Procedures

Third-party compile procedures, such as those used by commercial application software products, are supported by changing the Implementer object code to use those vendors’ commands instead of the standard compile commands, such as Create RPG (CRTRPGPGM) program. When using third-party compile procedures, make sure that the library, compile command, and programs are on the environment library list.

In addition, ensure the third-party command you use does not submit another job to perform the compile, as the command issued here must actually perform the compile.

Job Queues All source members for the promotion request are compiled in one job during the compile step. This allows you to submit the compile step to a job queue and subsystem that allows more than one active job at a time, without running into problems with the object compiling before another.

Common Questions

Do you have to compile each request every time?

No. This is optional. If N is specified in the environment defaults, use option 5, Move Request, on the menu to move the source/objects.

Who can run this task?

The target environment administrator who has move capabilities, or the user who created the promotion request, if that user has compile request authority for the target environment.

What can cause this task to fail?

The user is not authorized in the Implementer user profile to submit compiles.

What if a wrong member (especially a physical file) is deleted from a request?

Add the member again using Request Maintenance.

If a request fails to compile for a specific member, will the compile begin with that member when resubmitted?

The compile begins with the original member that initially failed compilation.

223


Compile Request (ICMPRQS) Command Option

The Compile Request (ICMPRQS) command allows you to compile a request from the command line rather than using the menu interface. It is useful when you want to promote a few known member/objects. Usually, the menu interface, option 3 for Compile Requests, which allows changing aspects of the promotion request, is more helpful.

This task is performed by the project leader after you have created the promotion request containing the member/objects, and before it is moved into the test or production environment.

You must have an existing promotion request at a status of Comp-Pend.

To compile using the ICMPRQS command

1 Type ICMPRQS at the command line and press F4.

2 Type the promotion request number or *ALL (to process all promotion requests at a compile pending status).

3 You can optionally compile by date and time range. Press F10=Additional parameters to show all parameters, and specify the from/to time and date ranges (time values must be in HH:MM:SS format).

4 Press ENTER to submit the compile and redisplay the command line.

Moving Promotion RequestsThe move step places the Implementer source members and objects into the target libraries. However, to ensure the orderly promotion of the source and objects, this involves more than simply copying the source members and duplicating objects to the target libraries. This section describes the important features of the move step.

Allocating Objects

Verification is performed to ensure that no objects are in use, or if they are in use, that the objects can be replaced successfully before any source or objects are moved to the target libraries. Physical files, programs, and panel groups are locked by the Allocate Object (ALCOBJ) command if they are not in use. If they are in use, the target environment is checked to verify it is set up to archive. If archiving is enabled, the existing object is moved to the archive library. If archiving is not enabled, the objects are renamed and moved to the system library QRPLOBJ (or an Implementer work library, if


Moving Promotion Requests

production is in a different ASP than the QRPLOBJ library). This technique is similar to the technique the OS/400 program compilers use when option REPLACE(*YES) is specified. The object is moved (instead of duplicating it) so that other jobs currently using that object can continue to function by using the old copy until the job end, or the object is no longer in use by that job.

For more information, see “Optimizing Physical File Promotions” on page 183.

Optimized PF promotions and non-source SQL are not moved out of the target library; rather, the Change Physical File (CHPGF) command (for PFs) or the ALTER TABLE command (for SQL) is issued for the object in the target library.

Logical files and display files are not allocated by the Allocate Object command. The Allocate Objects command places a lock on the based-on physical files for that logical file. This is not desirable because the logical file cannot be promoted if the based-on physical file is in use. Therefore, display files and logical files are tested for being in use by moving them from the target library to a temporary library, and then back to the target library in the Allocate phase of the move step. If they are in use, this temporary movement is allowed and the promotion does not continue, since these objects cannot be successfully replaced while being used.

These features ensure that if objects are in use and cannot be promoted, the move step ends without promoting any objects, and the currently active jobs (using the objects) do not end abnormally.

Authorities and Ownership

The move step sets the authorities to objects based on the rules defined for the environment. For detailed information about the setting of object authorities and owners, see the Implementer System Administrator Guide.

Archiving You can specify whether to archive the source members or objects. The archives can be used for automatic rollback (recovery) or for browsing previous versions of the source to assist in problem determination. For more information about this topic, see “Archive Recovery” on page 300.

Source Member Considerations

If the source type of the member is changed, the source type of the new target member is changed as well.

225


In addition, if the source files have a different length, the source members are successfully promoted. If the target source file has a shorter length than the from source file, a message is sent to the user who submitted the move and the promotion request continues.

NOTE

The Copy File (CPYF) command and the Copy Source File (CPYSRCF) command do not change the source type of an existing source member.

Issuing Move Requests

When you create a promotion request, member/objects are placed into holding libraries. The move task must be performed to move the member/objects from the work libraries into production libraries. It is necessary to complete this step to put the checked out member/objects back into production or a test environment.

This task is generally performed by an environment administrator who has move capabilities, or an authorized developer, after the promotion request has compiled. The promotion request could also be distributed to a remote system before this step is necessary.

For a list of the valid entity dispositions, see the table on page 142.

Whenever you promote entities (member/objects) associated with a design request, the entity disposition of the design request is automatically updated. The entity disposition is updated throughout the promotion cycle as well. Depending on the DesignTracker environment definition, the changed entity disposition changes the status of the design request. If the design request is attached to an SupportCenter call, the call history is updated to indicate the new design request status.

A promotion request must have the status of Move-Pend and you must have authority to move the promotion request.

To issue a move request

1 Type menu option 5 or STRIM (*MOVRQS) at the command line and press ENTER. You can also access this function from the Workbench and the Work with Objects panel with F15, Move requests.

2 In the Move Request panel, type option 1 next to the promotion request you want to move and press ENTER.

3 When the message displays that the move was submitted, press F3=Exit to return to the menu.


Moving Promotion Requests

Task Variations

This section describes task variations and additional processing you can perform when using the Move Request function.

Change and Submit the Move Request


2 In the Move Request selection panel, type option 2 next to the promotion request you want to change and press ENTER.

3 In the Change Move Request panel, change one of the following:

� Object attributes (option 1)

� Object authority (option 2)

� Target environments (F14=Target environments)

NOTE

If you want to change the overrides for the compile step of promotion scheduling, press F18=Submission overrides to display the Job Schedule Overrides panel from either the Move Requests selection panel or the Change Move Request panel. Fill in the changes or accept the defaults and press ENTER to redisplay the previous panel. Note that Time range fields must be entered in HH:MM:SS format.

4 Press F9=Submit to submit the promotion request and redisplay the Move Request selection panel.

5 When the message displays that the promotion request was submitted, press F3=Exit to return to the menu.


You can override the defaults established in Work with Environments for promotion scheduling. This task assumes you are in either the Move Request selection panel or the Change Move Request panel. Both the selection and detail panels allow you to override the promotion scheduling defaults.


2 Type the appropriate Request Submission overrides for the compile stage of the promotion process. (Note that Time Range fields must be entered in HH:MM:SS format.)

227


3 Press ENTER to redisplay either the Move Request selection panel or the Change Move Request panel.

Redistributing the Promotion Request


2 In the Move Request selection panel, type option 10 next to the promotion request you want to redistribute and press ENTER.

Special Commands

The move task allows you to create, change, or delete special commands that you can issue before or after a move, or after the failure of a move. In the Change Move Request panel, press F17=Special commands to display the Work with Special Commands panel. For more information, see “Special Command Processing” on page 229.

Common Questions

Who can use this function?

Users who have Move Request authority or who have move capabilities for the target environment.

Why would a move fail?

If it is a host move and the objects being replaced cannot be allocated. Remove the lock and resubmit the move.

Can this function be used to change the target environment of where to move the request?

Yes.

Move Request (IMOVRQS) Command Option

To put completed member/objects back into the production or test environment, you can issue the Move Request (IMOVRQS) command directly from the command line. This submits a job to move a request rather than using the menu interface. This feature is useful when you promote a few known member/objects. Usually the menu interface, which allows changing aspects of the promotion request, is more helpful.

This task is generally performed by an environment administrator who has move capabilities, or by an authorized developer, when a promotion request status is Move-Pend (or after you have created and compiled the promotion request).

You must first create and compile a promotion request. At that point, the promotion request status becomes Move-Pend.


Special Command Processing

To issue the IMOVRQS command

1 Type IMOVRQS at a command line and press F4.

2 Type the promotion request number or *ALL (for all promotion requests waiting to be moved) and press ENTER.

3 You can optionally move the request by date and time range. Press F10=Additional parameters to show all parameters, and specify the from/to time and date ranges (time values must be in HH:MM:SS format).

4 Press ENTER to submit the move and redisplay the command line.

Special Command Processing At times it is necessary to either add special functionality or ensure that specific tasks are completed at specific times under certain conditions. This task allows developers to create, change, or delete special commands at the time a request is created. Typical examples of this command use include, to perform overrides using the override database file (OVRDBF), to run data conversion programs when a physical file is promoted, and to run error correction programs. You can set the commands to run during check out and at various times in the promotion cycle, as explained in section.

Special commands can be defined on a per environment basis, or globally for all environments. This is typically done as part of environment setup. For details about the Work with Environments feature, see the Implementer System Administrator Guide. Contact your System Administrator if you have questions pertaining to your environment setup.

The environment library list is used when issuing special commands. Therefore, if you have any unqualified object references in the command, the libraries in which those objects are located must be included in the environment library list. The special command to run must reside in the environment library list defined in Work with Environments for each environment.

IMPORTANT

Special commands cannot be used to change the environment library list.

229


The special command features of Implementer include:

� Special commands can be processed during check out as well as various stages of promotion.

� Special commands can be performed for each object checked out, as well as each object on a promotion request. Likewise, they can be performed on specific objects only.

� When you submit a move, the object authority for special commands is taken from the user who submitted the move. If you want to change the object authority, use the Change Object Owner (CHGOBJOWN) command on IMPRDR10 to change the authority to a different owner.

� You can copy an existing promotion request as a template that contains your special commands, if you frequently need to perform them. Member/objects must be checked out to use this feature.

� Special commands issued from Create Requests run on the local system as the user who entered them. Those issued on a remote system run as the user profile of the communications job.

� You can add comments to the special commands to make them self-documenting. Comments can appear either before or after the command and they must be in brackets. For example:

/* This is a comment */

� Special commands support the use of a variety of substitution variables. For more information, see “Special Command Substitution Variables” on page 233.

� The Execute Request Detail (IEXCRQSDTL) command lets you use a variety of criteria to select certain items within a promotion request for processing by any other special command. For example, special commands can be triggered by the existence of specific objects on a promotion request. For more information, see “Special Commands in Promotion: IEXCRQSDTL Command” on page 236.

� Special commands can be used to enhance DDM management. For more information, see “Special Commands to Manage DDM” on page 240.

� The Change Request Detail (ICHGRQSDTL) special command sets the status of a software item within a promotion request to completed, effectively preventing any further attempts to move the item. For more information, see “CHGRQSDTL Examples” on page 242.



� The Execute Checkout (IEXCCKOCMD) command lets you use a variety of criteria to select certain items during checkout for processing by any other special command. For more information, see “Special Commands in Check Out” on page 245.

� Special commands are processed with the environment library list. Therefore, ensure that the issued command or the program to be called is on the environment library list, or qualify it with the library name. This is not required to run commands distributed with Implementer (for example, IEXCRQSDTL). However, to issue Implementer commands as special commands, the product library (MKSIM is the default), must be on the environment library list. For more information, see the description of the IMSPCCMD data area in Appendix A of the Implementer System Administrator Guide.

To use special commands when creating a promotion request


1 Press F17=Special commands to display the Work with Request Special Commands panel.

2 Do either of the following to display the Expanded Command Display panel:

� Press F6 to create a special command.

� Type option 2 in the option field to change an existing command, and press ENTER.

3 Complete the fields as defined next in “Create Request Expanded Field Descriptions” on page 232.

4 When you are finished, press ENTER to accept the command.

The Work with Request Special Commands panel redisplays.

5 Press F3=Exit.

231


Create Request Expanded Field Descriptions

For Action

Specify the promotion process to issue the special command. The For Action is based on the When to do flag as follows:

When to do

For the specified For Action, type the number representing when you want the command to run.

Sequence number

For a single command, type option 1. If using multiple special commands, type the number representing when you want the command to process in relative sequence to the other special commands.

Command

Specify the standard OS/400 command syntax for the command you want to issue. You can type the command, or use F4 to prompt.

1 = Compile Issues the command for the compile stage.

2 = Dist-Host Issues the command for the distribution stage on the host system.

3 = Dist-Rcvr Issue the command for the distribution stage on the receiver system.

4 = Move Issue the command for the move stage. For promotions that target a remote system, the special command runs where the move occurs.

5 = Move-Host Issue commands on the system where the promotion request originated, after successful distribution. This option is most meaningful for promotions that target a remote system.

6 = Checkout Issue commands during check out.

1 = Before The command runs before the specified For Action.

2 = After-OK The command runs after the specified For Action successfully completes.

3 = After Fail The command runs after the specified For Action fails.



Special Command Substitution Variables

The following tables define the substitution variables and replacement values available for special commands processed during check out and the promotion cycle.

Substitution Variable

Replacement Value

Header Level

#FRMENV Substitutes the checked out From environment.

#PROJECT Substitutes the project number that was entered on the Check Out panel.

#TRGENV Substitutes the checked out To environment.

Item Level

#DIR Substitutes the directory path of the target environment (IFS only).

#DRNBR Substitutes the Design Request that was entered on the Check Out panel.

#FILETYPE Substitutes the IFS file extension. Applies to objects associated with object codes defined with the special characteristic PCFILE.

#FILLIB Substitutes the checked out from file library.

#OBJATR Substitutes the object attributes.

#OBJCOD Substitutes the object code.

#OBJECT Substitutes the object.

#OBJLIB Substitutes the program or files library.

#OBJNM9 Substitutes the current, short object name.

#OBJTYP Substitutes the object type.

#PATHOBJ Substitutes the IFS project relative long name (#DIR and #OBJECT) for IFS objects.

#PGMLIB Substitutes the From program library (non-IFS).

#SHORTNM Substitutes the IFS short name.

#SRCFIL Substitutes the source file of the checked out From environment (non-IFS).

#SRCLIB Substitutes the source library of the checked out From environment (non-IFS).

#SRCMBR Substitutes the source member.

#SRCTYP Substitutes the source type.

233


NOTE

Due to OS400 limitations, the short member name generated by Implementer is not a valid name due to the tilde (~) character. As such, if you are using the #SHORTNM substitution variable for a parameter in a special command in check out or promotion, any tilde characters in the substituted value will be automatically translated into the number sign (#) character.


Replacement Value

Header Level

#ENVARCDIR Substitutes the archive path defined for the target environment (IFS objects).

#ENVARCLIB Substitutes the archive library defined for the target environment.

#ENVDIR Substitutes the directory path defined for the target environment (for IFS objects).

#ENVFILLIB Substitutes the file library defined for the target environment.

#ENVPGMLIB Substitutes the program library defined for the target environment.

#ENVSRCLIB Substitutes the source library defined for the target environment.

#ENVTYP Substitutes the environment type (*PRD, *QAC, or *TST) defined for the target environment.

#FRMDIR Substitutes the promotion work directory (for IFS objects).

#FRMENV Substitutes the request From environment.

#FRMLIB Substitutes the target object library name, as defined on the Change Environment–Object Code Overrides panel.Exception: When compiling secondary environments, this is the library containing all non-source-based objects that were frozen when the request was created.

#PROJECT Substitutes the request project number.

#RQSNBR Substitutes the request number.

#TRGENV Substitutes the current target environment.

#TRGGRP Substitutes the current, target environment group.

#WRKDIR Substitutes the temporary, Request work directory (for IFS objects).



#WRKOBJLIB Substitutes the temporary work library that contains the request’s program objects which will be moved into the target. For requests that are compile=Y, the objects do not exist until they are successfully compiled. Note that changing the authorities of objects in this library does not affect the authority of the object in the target environment. To set authorities, see the #OBJLIB substitution value defined in the “Item Level Substitution Variables” section.

#WRKSRCLIB Substitutes the temporary work library containing the request source that will be moved into the target environment.

Item Level

#DIR Substitutes the From environment directory path (for IFS objects).

#FILETYPE Substitutes the IFS file extension for the object.

#FILLIB Substitutes the current target file library.

#OBJATR Substitutes the current object attribute.

#OBJCOD Substitutes the current object code.

#OBJECT Substitutes the current member/object name. When used for IFS objects, substitutes the current project relative long object name when an IFS long name is associated with a request detail item.

#OBJLIB Substitutes the current target object library.

#OBJNM9 Substitutes the current, short object name.

#OBJTYP Substitutes the object type of the item being promoted.

#PATHOBJ Substitutes the IFS project relative long name (#DIR and #OBJECT) for IFS objects.

#PGMLIB Substitutes the target program library of the item being promoted.

#SHORTNM Substitutes the short object name for the IFS object being promoted.

#SRCFIL Substitutes the source file name of the item being promoted.

#SRCLIB Substitutes the target source library of the item being promoted.

#SRCMBR Substitutes the source member name of the item being promoted.


Replacement Value

235


NOTE

If the work library is needed, use #WRKOBJLIB, or #WRKSRCLIB and #WRKSRCFIL.

For example, to send yourself a message that informs you when a promotion completes normally, you can specify the following special command for the target environment YOURIDTST:

SNDMSG MSG(‘Promotion of #RQSNBR to environment #TRGENV for project #PROJECT completed normally’) TOUSR(YOURID)

SNDMSG MSG(‘Promotion of #RQSNBR to environment #TRGENV for project #PROJID completed normally’) TOUSR(YOURID)

When you successfully promote Request Number 1234, Project Number 67890 to the environment YOURIDTST, the following message displays automatically:

“Promotion of 1234 to environment YOURIDTST for project

67890 completed normally”.

Special Commands in Promotion: IEXCRQSDTL Command

Implementer provides the Execute Request Detail (IEXCRQSDTL) command, a special command that allows you to distinguish certain items within a promotion request for additional special command processing.

The IEXCRQSDTL command actually conditions the processing of whatever command you want to perform. Based on criteria that you define for the command (using substitution variables), it identifies the selected items being promoted and issues the command that you specify on those objects only.

The IEXCRQSDTL command can be used when specifying special commands when you issue a promotion request, and when specifying environment-level special commands. It can also be issued on a command line for immediate processing, or issued at specific stages within the promotion cycle.

#SRCTYP Substitutes the source type of the item being promoted.

#WRKSRCFIL Substitutes the name of the source file in the request work library. Typically used with #WRKOBJLIB and #WRKSRCLIB.


Replacement Value



To process Implementer commands as special commands, the product library (MKSIM is the default) must be on the library list of the target environment.

NOTE

For promotions of release management packages, substitution variables are available for retrieving the from product, version, and release, and the to product, version, and release that a package consists of. For more information, see Chapter 4 of the Implementer Release Management User Guide.

IEXCRQSDTL Command SyntaxIEXCRQSDTL OBJCODE(object-code)

NAME(name or *ALL)

ACTION(action)

RQSNBR(#RQSNBR)

TARGET(#TRGENV)

COMMAND(command syntax)

IEXCRQSDTL Command Parameters

The following parameters define the Execute Request Detail command.

OBJCODE

The object code associated with the object that the command will act on. Specify any object code that is defined within Implementer, or *ALL.

NAME

The name of the objects the command will act on. Specify a character value or *ALL.

ACTION

The action code of the objects the command will act on. Specify any valid action code or *ALL.

RQSNBR

The current request number. Specify #RQSNBR.

TARGET

The current target environment. Specify #TRGENV.

237


COMMAND

Specify the command to issue if the conditions specified by the command parameters are met.


Replacement Value

#FILLIB Substitutes the current target file library at the time of promotion.

#SRCLIB Substitutes the current target source library at the time of promotion.

#PGMLIB Substitutes the current target program library at the time of promotion.

#OBJECT Substitutes the current member/object name at the time of promotion. This variable can only be used within the command syntax.

#OBJTYP Substitutes the current object type at the time of promotion.

#OBJNM9 Substitutes the current, short object name at the time of promotion.

#OBJATR Substitutes the current object attribute at the time of promotion.

#OBJCOD Substitutes the current object code at the time of promotion.

#SRCMBR Substitutes the current, source member name at the time of promotion.

#SRCTYP Substitutes the current source type at the time of promotion.

#SRCFIL Substitutes the current source file name at the time of promotion.

For Release Management Packages

#FRMPRD Substitutes the name of the product the package will upgrade from.

#FRMVER Substitutes the name of the version the package will upgrade from.

#FRMRLS Substitutes the name of the release the package will upgrade from.

#TOPRD Substitutes the name of the product the package will upgrade to.

#TOVER Substitutes the name of the version the package will upgrade to.

#TORLS Substitutes the name of the release the package will upgrade to.



IEXCRQSDTL Examples

Example 1: Changing Object Characteristics

The following command issues the CHGPF command to change the size to *NOMAX for all files with an Object Code of PF (Physical File) in the current promotion request going to the current target environment. When defining this command, set the For Action field to 4 (Move), and set the When to do field to 2 (After-Ok).

IEXCRQSDTL OBJCODE(PF)NAME(*ALL)ACTION(*ALL)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND(CHGPF FILE(#FILLIB/#OBJECT)SIZE(*NOMAX))

Notice in addition to the substitution variables #RQSNBR and #TRGENV (which are required parameter values for the IEXCRQSDTL command), the #FILLIB and #OBJECT substitution variables are used to indicate the To File Library and Object, respectively, in the CHGPF command. For more information, see “Special Command Substitution Variables” on page 233.

Example 2: Customizing Object Authorities

You can use this feature to selectively grant or revoke object authorities outside of those defined against an environment. For example, an environment allows you to specify *ALL, *USE, *CHANGE, *EXCLUDE, or *AUTL. You can use the IEXCRQSDTL command to automatically issue the GRTOBJAUT command against selective object codes and object names. In this way, any combination of object authorities can be defined. The object authorities can be updated in line with changes to the OS/400 operating system, without the need to upgrade Implementer.

A typical example is an environment where *PUBLIC has *USE rights for any type of object. You can use the following commands to grant *CHANGE rights to your database files. When defining the command, set the For Action field to 4 (Move), and set the When to do field to 2 (After-Ok).

239


� For physical files:

IEXCRQSDTL OBJCODE(PF)NAME(*ALL)ACTION(*ALL)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND(GRTOBJAUT OBJ(#FILLIB #OBJECT) OBJTYPE(#ALL) USER(*PUBLIC) AUT(*CHANGE))

� For logical files:

IEXCRQSDTL OBJCODE(LF)NAME(*ALL)ACTION(*ALL)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND(GRTOBJAUT OBJ(#FILLIB/#OBJECT) OBJTYPE(#ALL) USER(*PUBLIC) AUT(*CHANGE))

Example 3: Substitution Variables for IFS Objects

When using the IEXCRQSDTL command for an IFS object, define a special command that uses the long-object substitution variable. When using the object code field, the case must match. For example, .class < > .CLASS.

In addition, the special command used in the Create Java Program (CRTJVAPGM) command must be in quotes, as illustrated next.

IEXCRQSDTL OBJCODE(.JAR)NAME(*ALL)ACTION(#ALL)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND(CRTJVAPGM CLSF(‘#PATHOBJ’) OPTIMIZE(40)

Special Commands to Manage DDM

The OS/400 Distributed Data Management (DDM) support allows objects on one system to reference the actual contents of the objects on another system. DDM objects can create that reference for the following types of objects on the target iSeries 400 system:

� physical files

� logical files

� data areas

� data queues

The following examples describe how to use Implementer and the Change Request Detail (ICHGRQSDTL) command to support a common scenario related to these types of objects. The basic requirement is to promote an



object on one system as its standard object type, and promote the corresponding object on the other system as a DDM version of the standard object.

By first defining the environment level special commands, you can specify standard object types, and when promoting, those objects are automatically switched to their corresponding DDM objects.

IMPORTANT

The ICHGRQSDTL command must be embedded within the IEXCRQSDTL command to ensure that the ICHGRQSDTL command is issued for the appropriate promotion items only.

CHGRQSDTL Command SyntaxICHGRQSDTL RQSNBR(#RQSNBR)

TARGET(#TRGENV)OBJCODE(name)NAME(#OBJECT)NEWOBJCODE(name)

ICHGRQSDTL Command Parameters

RQSNBR

Specify the current request number. You must supply the substitution variable #RQSNBR for this parameter.

TARGET

Specify the current target environment. You must supply the substitution variable #TRGENV for this parameter.

OBJCODE

Specify the object code associated with the object to reset the status for, or *ALL.

NAME

Specify the name of the object you want to reset the status for, or *ALL.

MODE

Specify if you want the item changed or removed from the request. Valid values are *CHG to change the item (this is the default), or *RMV to remove the item from the request (the item is not moved when the other items on the request are moved).

241


ACTION

Action is applicable only if you are using ICHGRQSDTL on a logical file and the logical file object exists in the target environment. The MODE must be *RMV.

If you promote a physical file and a dependent logical file exists in the target environment, the promotion request will fail. The Action determines how you want to prevent this condition and allows Implementer to continue processing.

NEWOBJCODE

Specify any valid Implementer object code to assign to the object.

CHGRQSDTL Examples

Example 1: Before the Move

The following commands, which are set to run before the move, ensure that all data areas, data queues, logical files, and physical files are not actually moved to the target environment. Instead, the For Action field is set to 4 (Move), and the When to do field is set to 2 (After-Ok). Notice that in each example a new DDM-related object code is assigned (DDMF, DDMDTAQ, and DDMDTAA, and respectively).

This command changes PF to DDMF for all actions prior to the move step.

IEXCRQSDTL OBJCODE(PF)NAME(*ALL)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND (ICHGRQSDTL RQSNBR(#RQSNBR)

TARGET(#TRGENV)OBJCODE(PF) NAME(#OBJECT)) MODE(CHG) ACTION(1) NEWOBJCODE(DDMF)

1=Cancel Cancels the processing of the ICHGRQSDTL command for this environment. This is the default value.

2=Proceed Deletes the LF from request, but not from the target (requires manual delete from target).

3=Remove Deletes the LF from request and from the target.



This command changes LF to DDMF for all actions prior to the move step.

IEXCRQSDTL OBJCODE(LF)NAME(*ALL)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND (ICHGRQSDTL RQSNBR(#RQSNBR)

TARGET(#TRGENV) OBJCODE(LF) NAME(#OBJECT)) MODE(CHG) ACTION(1) NEWOBJCODE(DDMF)

This command changes DTAQ to DDMDTAQ for all actions prior to the move step.

IEXCRQSDTL OBJCODE(DTAQ)NAME(*ALL)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND (ICHGRQSDTL RQSNBR(#RQSNBR)

TARGET(#TRGENV) OBJCODE(DTAQ) NAME(#OBJECT)) MODE(CHG)ACTION(1) NEWOBJCODE(DDMDTAQ)

This command changes DTAARA to DDMDTAA for all actions prior to the move.

IEXCRQSDTL OBJCODE(DTAARA)NAME(*ALL)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND (ICHGRQSDTL RQSNBR(#RQSNBR)

TARGET(#TRGENV) OBJCODE(DTAARA) NAME(#OBJECT)) MODE(CHG)ACTION(1) NEWOBJCODE(DDMDTAA)

Example 2: After Move-ok

The following commands, which are set to run after move-ok, create or delete a remote data area, remote data queue, and DDM file based on the action. There is no need for any changes when actions change.

243


This command deletes the existing DDMF for PFs and LFs when the action is Delete.

IEXCRQSDTL OBJCODE(DDMF)NAME(*ALL)ACTION(*DELETE)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND (DLTF FILE(#OBJLIB/#OBJECT)

RMTFILE(target-library/#OBJECT)RMTLOCNAME(target-system))

This command deletes the existing DDMDTAQ when the action is Delete.

IEXCRQSDTL OBJCODE(DDMDTAQ)NAME(*DELETE)ACTION(*DELETE)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND (DLTDTAQ DTAQ(#OBJLIB/#OBJECT))

This command deletes the existing DDMDTAA when the action is Delete.

IEXCRQSDTL OBJCODE(DDMDTAA)ACTION(*DELETE)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND (DLTDTAARA DTAARA(#OBJLIB/#OBJECT))

This command creates a DDMF for corresponding PFs and LFs when the action is Create.

IEXCRQSDTL OBJCODE(DDMF)ACTION(*CREATE)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND (CRTDDMF FILE(#OBJLIB/#OBJECT)

RMTFILE(ILEPRD/#OBJECT)RMTLOCNAME(MKS2))

This command creates a DDMDTAQ when the action is Create.

IEXCRQSDTL OBJCODE(DDMDTAQ)ACTION(*CREATE)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND (CRTDTAQ DTAQ(#OBJLIB/#OBJECT)

TYPE(*DDM)RMTDTAQ(ILEPRD/#OBJECT)RMTLOCNAME(MKS2))



This command creates a DDMDTAA when the action is Create.

IEXCRQSDTL OBJCODE(DDMDTAA)ACTION(*CREATE)RQSNBR(#RQSNBR)TARGET(#TRGENV)COMMAND (CRTDTAARA DTAARA(#OBJLIB/#OBJECT)

TYPE(*DDM)RMTDTAARA(ILEPRD/#OBJECT)RMTLOCNAME(MKS2))

Special Commands to Change Promotion Status

The ICHGRQSDTL command is designed to be embedded within the IEXCRQSDTL command, and should be issued to run before the move step. It sets the status of a software item within a promotion to a status of 5, indicating that the move stage of the promotion is successfully complete.

When you issue the ICHGRQSDTL command before the move step, the original software item is still copied to the work library on the target system. However, since ICHGRQSDTL sets the status of the software item to indicate that the move has occurred, Implementer does not actually move the item.

You can use this special-purpose command any time an object should be on one system, but not on another. A typical use of this command is to remove an item from a promotion request, or for DDM users who want physical files turned into DDM files for some environments. For more information, see “Special Commands to Manage DDM” on page 240.

IMPORTANT

The ICHGRQSDTL command should be embedded within the IEXCRQSDTL command only when used for DDM special cases.

Special Commands in Check Out

Implementer provides the Execute Checkout (IEXCCKOCMD) command, a special command that allows you to distinguish certain items during check out for additional special command processing.

The IEXCCKOCMD command conditions the processing of any special command based on the object code, member/object name, and action.

Using the criteria that you define for the IEXCCKOCMD command, Implementer identifies the appropriate checked out items and issues the command that you specify for only those objects.

245


You define the IEXCCKOCMD command as an environment-level special command for the target environment. If the special command fails while the checkout is processing, the process halts and displays the error, allowing you to identify and correct the problem, and retry the check out.

To process Implementer commands (for example, Process Clipboard IPRCCBD command) using IEXCCKOCMD, the product library (MKSIM is the default) must be on the library list of the target environment. This does not apply to processing OS/400 commands using this special command.

The IEXCCKOCMD command accepts any substitution variable valid for check out special commands. For a list of these variables, see “The following tables define the substitution variables and replacement values available for special commands processed during check out and the promotion cycle.” on page 233.

IEXCCKOCMD Command SyntaxIEXCCKOCMD OBJCODE(name or *ALL)

MBROBJ(name, generic*, or *ALL)ACTION(action or *ALL)TOENV(name or #TRGENV)COMMAND(command syntax)

IEXCCKOCMD Command Parameters

Object code (OBJCODE)

Specify the Implementer object code to issue the command for.

Member/Object name (MBROBJ)

Specify the member/object name to issue the command for.

Character value Specify an object code name.

*ALL Issues the command for all object codes. This is the default.

Name Specify a member/object name.

Generic* Specify a wildcard selection, for example, .exe*.

*ALL Issues the command for all member/objects. This is the default.



Action code (ACTION)

Specify the check out action that causes the command to run.

Target environment (TOENV)

Specify the target environment to issue the command for.

Command (CMD)

Specify the command to issue if the conditions specified by the command parameters are met.

IEXCCKOCMD ExamplesThe IEXCCKOCMD command is used with Lotus integration for setting Domino ACLs with the Set Domino ACL (ISETDOMACL) command. For more information, see the Implementer Multi-Platform Solutions Guide.

Example 1: Sending Messages

The following command issues the SNDMSG command to notify the administrator when certain objects are successfully checked out for any reason. When defining this command, set the For Action field to 6 (Checkout) and set the When to do field to 3 (After-Ok).

IEXCCKOCMD OBJCODE(.EXE)MBROBJ(*ALL)ACTION(*ALL)TOENV(#TRGENV)COMMAND(SNDMSG MSG (‘Checkout of .exe

objects was successful’) TOUSR(DEMOADM))

Example 2: Copying a File and Data

The following command issues the CPYF command when a physical file is checked out for change. It copies the file from a test library to a working library and populates the target file data. Notice the use of the #OBJECT and #OBJLIB substitution variables, which are used to indicate the From

*ALL The command runs for all check out actions. This is the default.

*CHANGE The command runs when change is the checkout action.

*CREATE The command runs when create is the checkout action.

*DELETE The command runs delete is the checkout action.

*RECOMPILE The command runs recompile is the checkout action.

247


File object and To File library, respectively, in the CPYF command. When defining this command, set the For Action field to 6 (Checkout) and set the When to do field to 3 (After-Ok).

IEXCCKOCMD OBJCODE(PF)MBROBJ(*ALL)ACTION(*CHANGE)TOENV(#TRGENV)COMMAND(CPYF FROMFILE(TESTDATA/#OBJECT) TOFILE(#OBJLIB/#OBJECT) FROMMBR(*FIRST) MBROPT(*REPLACE))

Common Questions

How can you avoid re-entering the commands for each request?

Copy an existing promotion request with the necessary special commands and adapt the rest of the promotion request to your new specific needs. Alternatively, you can define the special command at the environment level.

Why doesn’t a particular special command work?

Your user profile or group profile may not have the authority to the command.

Managing Concurrent DevelopmentConcurrent development occurs when multiple versions of the same object are being worked on at the same time. The concurrent development tasks associated with the promotion process resolve the conflicts caused by the concurrent development.

The resolution involves acknowledging one of the following:

� the necessary changes have been merged together

� no integration of the changes is required

� it is necessary to perform the compare or merge

Resolving a Conflict

This task allows developers or project leaders to resolve a conflict caused by concurrent development. This task is required when conflicts exist, before a member/object can be included on a promotion request. Objects in concurrent development with unresolved conflicts are not promoted.

You can do this task just prior to promotion, or just after the developer who is performing the development has completed the changes and it requires immediate conflict resolution.


Managing Concurrent Development

You must have concurrent development capabilities, and a member/object must be in conflict.

You can resolve conflicts from any of these functions: Create Request, Emergency Create Request, and Request Maintenance (main panel and Select from Locks), the Workbench, or Manage Concurrent Development.

Remember that a conflict is two-sided. Whenever a member/object is under concurrent development, you must resolve both versions (copies) of the member/objects separately, in order to promote them. You can automatically merge or compare the source during the resolution process.

To resolve a conflict

1 Access the Work with Conflict Resolutions panel using one of the following options:

� From the Workbench, type option 12 next to the member/objects to resolve, and press ENTER. The Work with Conflict Resolutions panel displays for all member/objects in conflict.

� From the Manage All Concurrent Development panel, type option 12 next to the specific lock of the member/object you want to resolve and press ENTER. The Work with Conflict Resolutions panel displays for all member/objects in conflict.

� From Create Request (Emergency Create Request and Request Maintenance), type option 12 next to the member/objects in the Create Request main panel or the Select from Locks panel and press ENTER. The Work with Conflict Resolutions panel displays for each member/object in conflict. For this option to work, the specific member/object must be in conflict.

2 In the Work with Conflict Locks Resolution panel, resolve the conflicts by using any of three methods:

� Type option 7 in the option field and press ENTER.

� Type option 2=Change in the option field and press ENTER to display the Change Conflict Resolution panel. Type Y in the Resolved field and press ENTER. You can add a comment to the resolution (which is helpful for later inquiry). Use option 5 for Display Resolution from the Work with Conflict Resolutions panel, or review the Conflict Report (if you select resolution for the report).

� Press F16=Resolve all. There will be only one member/object on the Work with Conflict Resolutions panel, but copies of it can be in multiple environments or libraries. Press F16=Resolve to resolve all conflicts for this specific member/object.

249


3 Press ENTER to redisplay the initial panel where you began the conflict resolution.

NOTE

The Resolved field displays the date a conflict was resolved.

If you select multiple member/objects from any of the panels in the Work with Conflict Locks Resolution panel, you can cycle through the numerous member/objects by pressing ENTER after each resolution. At the end of the series of selected member/objects, the panel where the member/objects were selected from redisplays.

To reverse a resolved conflict

From the Work with Conflict Locks Resolution panel:

1 Type option 2=Change in the option field and press ENTER to display the Change Conflict Resolution panel.

2 Type N in the Resolved field and press ENTER.

3 You can optionally add a comment to the resolution (which is helpful for later inquiry). Use option 5=Display Resolution from the Work with Conflict Resolutions panel, or review the Conflict Report (if you select resolution for the report).

Common Questions

When is a user not able to resolve a conflict?

When the user does not have change resolution authority.

When you resolve a conflict, what exactly are you doing?

You are setting a flag to indicate the member/object is ready for promotion. You must complete actual comparisons and merges to integrate the source members.


Advanced Topics

Advanced TopicsThis section describes some of the more advanced or non-routine topics associated with promotions, including:

� object version stamping

� emergency promotions

� problem determination

� completing failed promotions

� other creation features

� using ILE object codes for promotions

� batch promotion steps

� distributing promotion requests

Object Version Stamping in Promotion

When object version stamping is active with a version method that includes assigning the number in promotion, the next version number for the object is assigned when the request is submitted.

When promoting a locked object, if the check out action was Change, Create, Regen, or Recompile the revision number is validated. If the check out action was Delete, version stamping is ignored. When promoting an object without locks, the version number increments only when targeting a *PRD environment.

For more information on object version stamping, see “Performing Check Out” on page 111. For more information on the setup requirements, see the Implementer System Administrator Guide.

Validation and stamping is performed regardless of where the promotion initiates from—the Workbench, Clipboard, Create Promotion Request menu option, Emergency Create Request, Create Request (ICRTRQS) command, archive recovery, or a COOL:2E promotion.

For promotions on the host system, the version number is stamped to the object after successful compilation and the objects are duplicated into the request’s staging library (if the request is not an archive recovery request).

The issue or DR number is stamped after successful compilation from the Workbench and in the Implementer work library during promotion. For promotions to a remote system, the issue or DR number is stamped to the object for remote move requests, but is not stamped for remote compile requests.

Because object stamping in promotion occurs transparent to the user, the version number assigned to the production object does not display until after deployment of the objects. The version number displays (for each object with a version number assigned) in the Revision field of the Workbench (F11=Display Revision) and Work with Objects (F10=Display

251


Revision). In addition, the description of the object is changed by updating the PTF Number attribute with the revision number, and the APAR ID attribute with the design request number, which can be viewed using the Display Object Description (DSPOBJD) command.

Emergency Promotions

Implementer supports emergency promotion requests. You can create an emergency promotion request through a separate menu option, or using any of the options listed in “Performing Promotions” on page 171.

All the features of standard promotion requests are available.

An emergency promotion request allows you to control who can create an emergency promotion request in response to an emergency change needed in production (but cannot create a standard promotion request). This person can be a night operator, a supervisor, or a developer. You need to set up these rights in Work with Users.

When you create the emergency promotion request, you have two additional capabilities not available when creating standard promotion requests.

First, you can resolve conflicts to ensure the emergency promotion will not be stopped because of the inability to resolve a conflict.

Second, the auto-submit option defaults from the value specified for the Implementer data area IMEMGSTP (Emergency Promotion Request Submit Through Step) regardless of how you have defined the default target environment. The default value for this data area is 4 (through the move step) which ensures the change is promoted into the target libraries as quickly as possible. The auto submit field can be overridden by pressing F18=Overrides from the Emergency Create Request panel. For more information on the IMEMGSTP data area, see Appendix A of the Implementer System Administrator Guide.

Some companies might elect to use emergency promotions to bypass test environments and go directly to production environments. For more information, see“Handling Emergency Situations” on page 295.

Object Stamping in Archive Recovery

When performing archive recovery, the version number of the archived object is retrieved. To achieve this, Implementer retrieves the request that the archived object was created by, and reads the previous request that targeted this object to the given environment. The request detail records for this request are used to identify the version number of the object at the time the archive object was created.


Advanced Topics

For example, an object exists in production with version number 4.0. Archive recovery is performed to retrieve version 2.0 of the object. When recovered directly into a *PRD environment, the production object will be version number 2.0.

The next time the object is checked out to a *TST environment, it will be assigned version number 4.1.

For issue or DR stamping and archive recovery promotions run on a remote system, the issue or DR number that was stamped to the archived object is retrieved.

Problem Determination

When an error occurs, messages are sent to the user who submitted the job. You should review the Implementer job log and the OS/400 job log to help determine the problem.

The Implementer database retains the OS/400 job log for errors that occur during the export (if a LANSA environment), compile, distribution, or move steps. This facilitates better problem determination for sites that have their OS/400 job log output queues cleared on a periodic basis. If the failure occurred on a remote system, the job log from the remote system is returned to the host system. You can display the job logs using the Display Job Logs menu option.

You can specify the number of job logs to retain in System Control Maintenance. The number of job logs to retain should be large enough to keep job logs for a reasonable number of requests. For example, 50 job logs may not keep 50 requests, since a job log is generated for each target environment on the request. If you regularly promote to two environments at a time, specifying to keep 50 requests would retain 100 job logs.

In addition, you can control the job logging level for the promotion jobs in System Control Maintenance. If you need to log the CL statements, you can change the LOGCLPGM parameter on the MWIJOBD job description to *YES.

Job Log Audit Trail Information

It is often difficult to identify what caused an error in the promotion cycle because OS/400 job logs typically contain too much detail rather than too little. Implementer messages that are included in the job log are minimized, so you can be certain that the first diagnostic or escape message listed in the job log is the actual cause of the error in the promotion cycle. This can be beneficial to:

� expedite the identification of what really caused the problem

253


� enable you to identify and resolve many problems quickly, without requiring assistance from MKS Customer Support

� reduce support time, in those instances where MKS Customer Support is required for assistance

The following message IDs appear in the job log only when pertinent to problem determination:

Completing Failed Promotions

Legitimate situations can cause a promotion request not to complete, thereby leaving it in an open state. For example deleting an environment or removing a remote system after the request was created, or communications between the host and remote fail as the request is being updated, the promotion can likely fail.

The Complete Request (ICMPLRQS) command allows you to set a failed promotion request to a completed status. While this command is not needed or recommended under normal processing conditions, it is helpful in those unique situations when a promotion request does not complete normally.

The ICMPLRQS command can be used to complete a promotion when:

� a communication problem requires creating a new request

� a compile or move problem requires manually working around it

� an After-Move special command fails

Message ID Description

CPD0078 Value &3 for parameter &2 not a valid name.

CPF0001 Error found on &1 command.

CPF1015 Data area &1 in &2 not found.

CPF3012 File &1 in library &2 not found.

CPF3092 FILEATR specified not valid for &3 file &1.

CPF3213 Members for file &1 more than maximum allowed.

CPF3213 Members for file &1 more than maximum allowed.

CPF4028 Open of member &1 was changed to SEQONLY(*NO).

CPF5812 Member &3 already exists in file &1 in library &2.

CPF9801 Object &2 in library &3 not found.


Advanced Topics

Using the ICMPLRQS Command

Use this command carefully. Because of the impact that arbitrary use of this command could have on your database, QSECOFR authority is required to issue the command.

The command does not delete the Implementer work libraries or perform any other cleanup activities—these tasks must be done manually.

NOTE

The ICMPLRQS command replaces the need to use Data File Utility (DFU) on Implementer files to manually complete a promotion request.

To use the ICMPLRQS command

� At an Implementer command line, issue the following:

ICMPLRQS RQSNBR(NNNN)

Where NNNN is the promotion request number to set to a completed status.

Other Creation Features

To simplify the entry of promotion requests, the from environment (or from library) and target environment or environment group values default to what is defined for the:

� project path (if a specified project has a defined path), or

� environment path, or

� user profile

It is possible to restrict or allow specific entries in Create Request, or not allow any environment changes.

You can associate a promotion request with a specific project reference, through DesignTracker, to SupportCenter (for tracking customer issues) and ProjectMaster (for project time projections and completion).

You can establish restrictions by object types and user capabilities that affect the promotion of member/objects from the development library.

You can include related objects on the request to ensure that all programs that use a particular physical or logical file are automatically recompiled. These related objects are added to the promotion request with an action of 9 for Recompile. Logical files that are not manually added to a promotion request are automatically recompiled, if the physical files they are based upon are on the request. This requires the environment’s Add Related

255


Objects field be defined as N in Work with Environments. For more information about related object processing, see “Promoting Related Objects” on page 200.

All three steps (compile, distribute, and move) can be automated. Typically, the original defaults for the developer are set to create and compile the request. The project administrator then distributes and moves the member/objects.

Using ILE Object Codes in Promotion

Implementer provides complete support for software development using ILE. ILE support improves performance, encourages modular programming, and provides better control over OS/400 resources. For more information, see “Using ILE Object Codes in Check Out” on page 148.

Batch Promotion Steps

Batch promotion steps run with the MWIJOBD job description. Implementer controls the library list during execution. The batch job is submitted to the job queue specified in System Control Maintenance, but you can override the job queue.

If you want to run the batch jobs later, you can schedule the jobs in one of four different ways. First, you can establish promotion scheduling per environment that can be overridden for each step of the promotion process. Second, you can submit the jobs to a held job queue and release the job queue later. Third, you can submit the jobs as held and release the individual jobs later. Fourth, you can have the Compile Request (ICMPRQS) command or Move Request (IMOVRQS) command performed by your job scheduler. You can do this on the remote system with the Move Remote Request (IMOVRMTRQS) command.

Distributing Promotion Requests

The distribution step is performed only for promotions to remote systems. This step is described in more detail in “Performing Distributions” on page 271.


Scheduling Promotion Requests

Scheduling Promotion RequestsCompilation, movement, and distribution of promotion requests can be CPU intensive. Therefore, it is often better to schedule all of the promotion steps during non-business hours.

The primary methods of promotion scheduling are:

� Partial use of the promotion scheduling capacity. Schedule a request to a non-business hour job queue through the defaults in Work with Environments, or the promotion request through Create Promotion Request, Compile Promotion Request, Move Promotion Request, Move Promotion Request by System/Environment, and Archive Recovery. With this option, you accept all defaults except the job queue.

� Full use of the promotion scheduling capacity. Schedule each specific promotion request step to either an exact schedule time (or a variation of a specific time). In addition, the system defaults in Work with Environments, or the request defaults established in Create Promotion Request, Compile Promotion Request, Move Promotion Request, Move Promotion Request by System/Environment, and Archive Recovery. This option allows a variety of selections, such as:

� default date, time, library, job queue, and whether the job is held on the job queue

� default date (with a specific time for each of the promotion steps)

� specific job queue

� held on the job queue until manually released by a night operator

The following are the most commonly used: Setup promotion scheduling through Work with Environments and Setup promotion scheduling overrides through one of the promotion steps.

NOTE

You can define standard move schedules on the host iSeries 400 development system and then reschedule the move times of specific promotion requests to remote iSeries 400 systems. This enables distribution of a promotion request from your host system to multiple remote systems simultaneously, placing the remote Move step under the control of a default schedule defined for that remote system. Additional flexibility on the host system to reschedule the Move for a specific request enables you to manage the installation schedule of selected promotion requests without having to access that remote system. For more information, see “Controlling Remote Job Schedules” on page 280.

257


Promotion Request StatusThe request status informs you of the state of any promotion request in the system. For example: if the request is waiting to be compiled, the status is Comp-Pend. If the compile was submitted but not running, the status is Comp-Jobq. If the compile is currently running, the status is Comp-Run.

The status for local or remote target environments might differ for the request. This results from either: The promotion request stops at a different step within the promotion process for each environment. The lowest step of the cycle displays if you are not viewing the request at an environment level; or communication between the host and remote can be interrupted if a promotion step fails. This results in a different status being listed on both systems.

Status Filtering

Type Open in the filter field to display all requests that do not have a Completed status. The valid status codes are as follows:

Export Phase Status Codes (LANSA environments only)

Compile Request Status Codes

Expt-Pend The Export phase is ready for execution.

Expt-Jobq The Export function was submitted to the job queue for processing.

Expt-Schd The Export function is scheduled for processing.

Expt-Run The Export phase is executing.

Expt-Fail An error occurred during the Export phase. Review the LANSA Export Report to determine the cause of the failure. Make the proper corrections and resubmit the export promotion.

Comp-Pend A migration was requested and all member/objects were copied to the staging library.

Comp-Jobq The compile function was submitted to the job queue for processing.

Comp-Schd The compile function is scheduled for compilation.

Comp-Run All source-based objects for the request are currently being compiled, and all non-source-based objects are currently being moved/duplicated to the environment work libraries.

Comp-Fail An error occurred during the compile requests phase. Review the job log to establish the probable causes.


Promotion Step Internal Processing

Distribution Status Codes

Move Request Status Codes

Model Copy Status Codes (COOL:2E environments only)

Promotion Step Internal ProcessingThis section describes the internal processing that occurs during the promotion step.

Dist-Pend The compile process completed successfully (if required) and the request is ready for distribution to remote systems.

Dist-Jobq Distribution to the remote system was submitted to the job queue for processing.

Dist-Schd Distribution to the remote system is scheduled for processing.

Dist-Run The request is currently being distributed to the remote target libraries.

Dist-Fail An error occurred during the distribution phase. Review the job log to establish the probable causes.

Move-Pend The compile process (and the distribution process for remote environments) completed successfully and the request is ready for promotion.

Move-Jobq The Move Requests function was submitted to the job queue for processing.

Move-Schd The request is scheduled to move to the target libraries.

Move-Run The request is currently being moved to the target libraries.

Move-Fail An error occurred during the Move Requests phase. Review the job log to establish the probable causes.

Completed The request completed successfully.

MCpy-Pend The Model Copy phase is waiting to be executed.

MCpy-Jobq The Model Copy Request function was submitted to the job queue for processing.

MCpy-Schd The Model Copy Request function is scheduled for processing.

MCpy-Run The Model Copy phase is executing. A migration was requested and all member/objects were copied to the staging library.

MCpy-Fail An error occurred during the Model Copy phase. Review the job log to establish the probable causes.

259


Create Step This step creates the promotion request and copies the source and/or objects from the from environment/library into the Implementer work libraries. This ensures that the source and objects are frozen at the specific time the promotion request is created. If the source or objects are changed after the creation of the promotion request, the copy of the original source or objects is used and a message informs the administrator that the member/objects were changed.

These actions are performed when you process the Create Promotion Request main panel function or when you issue the Create Request (ICRTRQS) command.

Create Request Sub-steps

1 Create the promotion request in the Implementer database.

Add records to the appropriate Implementer database files.

2 Create the request source work library and request object work library.

Library

From ObjectLibrary

Target EnvironmentObjects

TargetEnvironmentSource

Removed From objectsLibrary

IM0021F TargetEnvironmentArchives

FromSource

Request SourceLibrary

IM0021S

Request Objects WorkLibrary

IM0021

IM0021002

Object StageLibrary

IM0021001X

IM0021002X

ReplacedTargetObjects

IM0021001TIM0021002T

Environment libraries

Implementer work libraries

Create Request

Compile Step Move Step uses all libraries



3 Copy the source members.

Copy the source for each source-based object with an action of Create or Change.

4 Duplicate the object.

Duplicate the objects into the request objects library from the from environment or library:

a) Always for non-source based objects.

b) For source-based objects that have the Compile required field set to N on the source environment.

For logical file promotion requests that have the Compile required field set to N, the based-on physical files are duplicated into the request object work library even if the physical files are not on the promotion request. The physical files are placed in the work library to ensure the logical file in the work library is not based on the physical files in the target library. Although the physical files are in the work library, they are not added to the promotion request and are not promoted to the target libraries.

5 Force the compile step to occur in some instances.

This is necessary to force the primary environment to go through the analysis phase of the compile step so that any needed items can be identified and added to the request and compiled. All items added by Implementer are added with action 9 for recompile and compile the source from the target environment. NONE of the explicitly added items on the request are compiled in this case. This is necessary if:

a) The Add related objects field is set to Y on the from environment (traditional only).

b) The request contains a physical file. The logical files are located and added to the promotion request.

c) The action is 9 for recompile for any item on a request that has the Compile required field set to N on the from environment.

Export Step This step performs the export of LANSA objects on the request to a save file.

The export process uses the export list created in Create Request function and performs the export into the save file in the work library.

The export function in LANSA is the first of the two step process in LANSA to move objects from one partition to another. Promotion prepares the LANSA objects for export and imports the objects to the target

261


environment. The LANSA objects are exported from the from partition and imported into the to partition (each partition is specifically associated with an environment). It is possible to limit the auto submit process to only the export step.

1 All valid LANSA objects on the request are bundled into an export list.

2 The export is done to a save file.

3 The verification of the successful completion of the export process must be done by manually looking at the export reports generated by LANSA.

LANSA requests are archived by exporting the LANSA objects in the target partition into a save file in the archive library.

Compile Step This step compiles source members for source-based objects placed on the promotion request. In addition, it adds related objects to the request (if needed) for traditional environments and recompiles them using the source in the target library. This step identifies implicit logical files and adds them to the request for compilation.

Compile Request Sub-steps

1 Create target environment libraries. If they are not already on the system, Implementer creates the libraries used by the target environment, and creates all source files for the environment.

2 Issue special commands designated as Before Compile.

3 Add items to the request.

a) Add any implicit logical files based on physicals being promoted on the request with action 9 for recompile.

b) Add related objects if requested.

4 Compile source-based items.

a) Issue the before compile special commands before the first compile is attempted.

b) Analyze the target object and modify the creation command so that any attribute not specified by you on the creation command is retained from the target object.

c) Compile the objects into the request, object work library using the source in the request source library. For action 9 for recompile, use the source in the target environment.

d) Issue the compile failed special commands, if any compiles fail.



e) Issue the compile OK special commands after all compiles successfully complete.

5 Issue special commands designated as After compile.

6 Delete the compile listings. This is done only if all compiles were successful and the flag in System Control is set to Y.

Distribution Step

The distribution step is detailed in “Performing Distributions” on page 271.

Move Step This step replaces the objects and source in the target environment with newly promoted objects and source. Optionally, the replaced objects and source can be retained in an archive library.

Move Request Sub-steps

1 Create target environment libraries. Implementer creates the libraries used by the target environment if they do not exist. All source files for the environment are also created (during the move if there were no compiles.)

2 Issue special commands designated as Before Move.

3 Create the temporary work libraries. Create the object stage library, and the replaced, target objects work libraries.

4 Allocate all objects. Allocate all objects to be replaced in the target that are exclusively allocated, with the exception of logical files currently in use. For more information, see “Allocating Objects” on page 224.

5 Pre-stage all physical and logical files. Pre-stage all physical and logical files before any objects in the target are replaced to minimize the time frame where the target environment is partially updated.

� Physical Files

a) Duplicate the physical file into the stage objects library from the request, objects work library.

b) Retain target members.

c) Retain target data.

� Logical Files

a) Duplicate the logical file to the stage objects library from the request objects library.

263


This creates a copy of the logical file with the name IMxxxxLF (where xxxx represents the promotion request number) and duplicates it into the target objects library. This ensures the logical is built over the correct physicals in the target objects library. Then it is moved to the stage objects library.

NOTE

If the physicals for the logical also are on the request, the logical is duplicated directly into the stage library. If the logical is based on multiple physical files that are not on the request, and the physicals are in different libraries in the target temporarily moved, the physicals in the target are temporarily moved to the object stage library, and then moved back again to achieve the same result.

b) Retain target members. Add the members of the existing logical file to the logical file in the object stage library. If there is no logical in the target, an attempt is made to retain the members of the from library object or compiled object, if it was compiled.

6 Stage and move the objects and source. All the steps in this section are repeated for each item on the request.

a) Duplicate objects into the object stage library. Skip physical and logical files at this time since they were pre-staged.

b) Set object authorities and owners. This is based on the authority method of *KEEP or *GRANT.

c) End journaling on any physical files or logical files on the request.

d) Archive target source and/or objects based on the environment definition. Physical file objects are never archived. If the physical file object is requested for archive, only the source is archived.

e) Remove non-archived objects. If an object is not archived, and it is a program, it is moved to the IBM QRPLOBJ library for replaced objects so that any users running the program are not affected. Other objects are moved to the replaced target objects library and are deleted after the move completes normally.

f) Move object to target objects library from the object stage library.

g) Restart journaling on all physical and/or logical files that were previously journaled.

h) Copy the source member to the target source library from the request source library.



i) Issue any Move-type creation commands. A common creation command would promote the data in a physical file and change the target object without replacing it.

j) Update Implementer lists. The member/object lists for the target environment are updated as well as the related object information, if it is being maintained by Implementer.

k) Update locks.

� Change the lock to the new test environment (type *QAC).

� Remove the lock for production environments (type *PRD).

l) Issue the move failed special commands if errors occurred during the move.

m) Notify user that the member/object has been promoted.

7 After all items are moved:

a) Issue the move-OK special commands. Issue the Copy Physical File (CPYF) command, as a special command to promote the data for the physical file. To promote a physical file on the same request with the data, copy the data along with the object by listing the object again using the PFDTA object code.

b) Delete the move work libraries. The object stage library and the removed target objects library are deleted. They are NOT deleted if errors occurred before this step.

8 Final processing. This is done after all environments on the promotion request are successfully moved.

a) Delete source in from source library if indicated on the promotion request.

For remote QA environments, automatic removal of member/objects is optional. For more information, see the Implementer System Administrator Guide.

b) Delete object in from object library if indicated on the request. These objects are moved individually into the removed from objects library and then the library is deleted. This ensures the physical and logical files are deleted in the proper sequence.

c) Update Implementer repository. The member/object list and the related object information for the From environment are updated to reflect the objects and source that were deleted in the above steps.

Work Libraries Used During Promotion

Implementer uses work libraries during promotion to ensure the orderly movement of source and objects into the correct target libraries. This section provides basic information about how the work libraries are used.

265


With the exception of the COOL:Xtras CM target model save library, the work libraries exist only while a promotion request is open (the status is not completed). These work libraries are owned by user profile MWIPROD with no public rights to ensure that these libraries stay under Implementer control.

Summary of Work Libraries

The following chart summarizes the work library names using request number 21 as the basis for the library names.

The work library naming rules use the following conventions:

For systems with multiple Auxiliary Storage Pools (ASPs), the ASP that the Implementer work library is created in is important. The user ASP that the work library is created in must be the same as the ASP of the library that Implementer moves objects into or out of, using the Move Object (MOVOBJ) command. Existing constraints on the Move Object (MOVOBJ) command prevent it from moving to a library in a different ASP.

Library Example Description

IM0021 Request object work library (primary environment, secondary environment compile=N)

IM0021F From object holding library

IM0021N NetView/DM distribution library

IM0021S Request source library

IM0021002 Environment object work library (secondary environment compile=Y)

IM0021001D Environment distribution library

IM0021001T Target object holding library

IM0021001X Environment staging library

TAP0021001 Tape distribution library

ppp Work library prefix. The default is IM, but you can define a different value in data area IMPRFX. Values can be different on the host and each remote system.

rrrr Promotion request number.

eee Environment ID number (the sequence number of the environment on the request).

CAPS Any letter in upper case is the actual literal value of that character.



Host Work Libraries

Request Source Library

This work library contains all the source members for items on the request.

Request Object Work Library

For primary environments and environments that have the Compiled required field set to N.

This work library contains all objects for the request’s primary environment and all secondary environments that are compile N. All non-source-based objects are placed in this library during Create Request. Source based objects are compiled into this library during the compile for compile Y requests.

Environment Object Work Library

For secondary environments that have the Compiled required field set to Y.

This work library contains objects for each secondary environment on the request with the Compile required field set to Y. Objects are compiled from the source in the Request Source Library.

Created During Create Requests.

Deleted When the request is completed.

ASP Any

Name ppprrrrS

Example IM0021S

Text ‘Implementer rqs rrrr source’

Created During Create Request.

Deleted When the request is completed.

ASP Any

Name ppprrrr

Example IM0021

Text ‘Implementer rqs rrrr objects’

Created During the compile step for a request if the target environment Compiled required field is set to Y.

Deleted When the environment goes to Completed status.

ASP Any

Name ppprrrreee

Example IM0021001

Text ‘Implementer rqs rrrr env name objects’

267


Environment Staging Library

This is a work library used to stage each object before it moves into the target environment. While in stage, the authorities are set and most of the database steps take place in this library (for example, ADDPFM, ADDLFM, CPYF, and journaling). It is used instead of QTEMP since QTEMP does not support moving out into any ASP other than ASP number one. The stage library is only used during the move step.

From Object Holding Library

This is a work library that holds the objects deleted in the from library. They are not deleted directly in the from library since physical files are processed before logical files and physical files cannot be deleted before logical files. This library is only used during final processing, following the move of the last environment on the request.

Created Every time a move begins (if it already exists, it is deleted).

Deleted When the move successfully completes (not deleted if errors).

ASP Same ASP as the target environment.

Name pprrreeeX (position 3 of prefix is not used)

Example IM0021001X

Text ‘Implementer rqs rrrr env name staging’

Created When final processing for the request begins and all environments are successfully moved.

Deleted When final processing is complete for the request.

ASP Same as the From objects library.

Name ppprrrrF

Example IM0021F

Text ‘Implementer rqs rrrr removed from objects’



Target Object Holding Library

Holds the objects removed from the production environment if they are not going to be archived. They are not deleted directly in the target library, since physical files are processed before logical files and they cannot be deleted before logical files. This library is only used during the move step.

Environment Distribution Library

Contains objects and source that is needed for distribution to the remote system. It can contain combinations of the following: Implementer database files for the remote system, non-source-based objects, and M type object code source.

Tape Distribution Library

Contains objects and source needed for distribution by type to the remote system, for environments distributed to by tape. It contains the same objects as the Environment Distribution Library.

Created When the move begins for the environment, only if the target environment is not archived.

Deleted When the environment is Completed.

ASP Same as the target object library.

Name pprrrreeeT (position 3 of the prefix is not used)

Example IM0021001T

Text ‘Implementer rqs rrrr env name target objects’

Created During the distribution step.

Deleted After distribution, whether successful or not.

ASP Any

Name pprrrreeeD (position 3 of the prefix is not used)

Example IM0021001D

Text ‘Implementer rqs rrrr env name dist objects’

Created During the distribution step.

Deleted After distribution, whether successful or not.

ASP Any

Name TAPrrrreee

Example TAP0021001

Text ‘Implementer rqs rrrr env name tape’

269


NetView/DM Distribution Library

Contains all the objects and source for every environment on the request. This library is left on the system and a record is written to an interface file alerting NetView/DM to pick up the library and distribute it to the correct systems. (This library name must be eight characters or less.)

Remote Work Libraries

Environment Work Library

Contains all the objects, source, and Implementer database files needed on the remote system. For this reason, there is no separate Request Source Library or Request Object Work Library. All other libraries are the same as the host, except there is no need for the From Object library or any of the distribution libraries to be included.

Created During distribution.

Deleted When NetView/DM calls to the system or the request is completed.

ASP Any

Name ppprrrrN

Example IM0021N

Text ‘Implementer rqs rrrr NetView/DM distribution’

Created During distribution on the remote system.

Deleted When environment is completed.


7Performing Distributions

This chapter describes the distribution and promotion of promotion requests to remote systems or multiple environments.


� moving and distributing promotion requests by system

� displaying move promotion requests by system

� controlling remote job schedules

� using the Implementer Receiver Menu

271

Performing Distributions

Moving and Distributing Promotion Requests by System

The environment definition determines whether you perform the distribution and move steps separately or together. The Move Promotion Request by System/Environment function allows you to submit the promotion requests separately to a system/environment or combine the promotion requests by system/environment.

The Move Request by System function now automatically submits one job per target environment for any move request that does not require compiling or adding related objects. This allows for the parallel processing of multiple targeted environments, and provides quicker processing of multi-environment move requests. Additionally, if an error occurs in any one of the targeted environments, processing continues to the secondary environments.

NOTE

The number of concurrently active jobs is determined by the OS/400 job queue configuration defined for the host system. In most cases, this is the job queue specified for the Implementer default job description MWIJOBD. However, this can be overridden in either System Control Maintenance or in Work With Environments, Promotion Scheduling. For more information about job queues, see “Job Queues” on page 223 and“Batch Promotion Steps” on page 256, or see the Implementer System Administrator Guide.

Moving/Distributing All Promotion Requests By System

This task allows you to distribute all promotion requests to remote systems independently of moving the objects into the target environment on the remote system. This task is helpful when it is necessary to distribute members/objects to remote systems and later move them to production. It is generally performed by an environment administrator who has move capabilities or by an authorized developer. The task is required any time you want the members/objects on the remote system.

You cannot distribute AS/SET definitions to remote locations.

The following requirements apply:

� Define the remote system through Network Configuration.

� Define the environments on the remote system through Work with Environments.

� The promotion request must be compiled and at Move-Pend status.



To move/distribute all promotion requests by system:

1 Type menu option 6 or type STRIM (*MOVRQSSYS) at the command line and press ENTER to display the Move Request by System panel.

2 Select the system by typing one of the following in the option field and press ENTER:

a) Option 10 to distribute all requests. This option is only for a remote environment, when you will perform the local initiated move later or when it is a remote initiated move.

b) Option 11 to move all requests. Use this option for both the host and remote systems. It indicates a local initiated move as set up in Work with Environments.

c) Option 12 to distribute and move all requests. This option is only for a remote environment. It indicates a local initiated move as set up in Work with Environments.

3 Press F3=Exit to redisplay the menu.

Move Request by System/Environment Options

The following options are available on the Move Request by System/Environment panel.

5=View requests

To view all promotion requests for the system for which you have move capabilities.

10=Distribute all

To submit the distribution of objects for all promotion requests targeted for the system for which you have move capabilities.

11=Move all

To submit the Move Requests process for all promotion requests targeted for the systems you have move capabilities to.

12=Distribute and move all

To submit the distribution and move for all promotion requests targeted for the systems you have move capabilities to.


You can override the defaults established in Work with Environments for promotion scheduling.

273


This task assumes you are in the Move Promotion Request by System/Environment selection panel or the Request panel.

NOTE

Both the selection and detail panels provide access to override the promotion scheduling defaults.


2 Type the Request Submission defaults for the distribution stage of the promotion process. Note that Time range fields must be entered in HH:MM:SS format.

3 Press ENTER to redisplay the Move Promotion Request by System/Environment selection panel or the Request panel.

Redistributing a Promotion Request

1 Type menu option 5 or STRIM (*MOVRQS) at the command line and press ENTER to display the Move Request panel. You can also access this function with F15=Move requests from the Workbench and the Work with Objects panel.


Common Questions

Why use menu option 6 for Move requests by system rather than option 5 for Move request?

Move requests by system allows you to break the move into two steps.

NOTE

If you use the Create Request defaults in the environment definition Promote Through Step, you can perform a regular move (and distribute). Menu option 6, Move Promotion Request by System/Environment, allows you to manually process this step. For example, you may want to compile on the remote or delay (while on the remote) promoting the object into production.

What is the most common problem with remote promotions?

The communications link (OS/400 physical hookup or Implementer configuration) is not correctly set up.



Moving/Distributing to a Specific System

Although completed changes are usually moved as a group to a remote system, it is sometimes necessary to move a specific set of changes to a specific remote system. This gives you specific control over the production objects.

This task allows environment administrators with move capabilities or authorized developers to distribute specific promotion requests to remote systems. In addition, it allows you to initiate: a single promotion request for all promotion requests on a system, a specific promotion request on a system, or only a single environment for a promotion request on a system.

You do this task once you have created or compiled the promotion request.


� Define the remote system through Network Configuration.

� Define the environment on the remote system through Work with Environments.

� There must be a compiled promotion request.

To move/distribute to a specific system

1 Type menu option 6 or STRIM (*MOVRQSSYS) at the command line and press ENTER.

2 Type option 5 next to the environment/system that you want to view all requests for and press ENTER to display the Request Selection panel.

NOTE

The request is listed by promotion request number and by environment. For example, a specific promotion request could be listed that contains five different target environments. The promotion request would be listed five times, once for each environment.

If you want to change the overrides for the compile step of promotion scheduling, press F18=Submission overrides to display the Job Schedule Overrides panel. This can be done from either the Move Promotion Request by System/Environment selection panel or the Move Promotion Request by System/Environment panel that displays when you use option 5=Display Requests. Type your changes or accept the defaults and press ENTER to redisplay the previous panel. Note that Time range fields must be entered in HH:MM:SS format.

275


3 In the Request Selection panel, type one of the following in the option field and press ENTER:

� Option 10 to distribute the request. This option is only valid for a remote environment, when you will perform the local initiated move later or when it is a remote initiated move.

� Option 11 to move the request. Use this option for both the host and remote systems. This option indicates a local initiated move as set up in Work with Environments.

� Option 12 to distribute and move the request. This option is only for a remote environment. It indicates a local initiated move as set up in Work with Environments.


Request Selection Options

The following options are available on the Move Request by System panel.

4=Delete entire request

Delete the promotion request for all environments and systems.

5=Display

Display the details for this promotion request for example, request originator, member/object list, and compile options.

10=Distribute

Submit the distribution of objects for this promotion request to this system.

11=Move

Submit the Move Request process for this promotion request to this system.

12=Distribute and move

Submit the distribution and move for this promotion request to this system.

15=Related Request

Display the secondary requests that were generated at create request time for any cross-environment related objects that required recompiling.



16=Job Log Inquiry

Display the OS/400 job log for this promotion request. This is useful for problem determination and resolution.

17=Job log Print

Print the OS/400 job log for this promotion request. This is also useful for problem determination and resolution.

Redistributing a Promotion Request

To redistribute a Promotion Request

1 Type menu option 5 or STRIM (*MOVRQS) at the command line and press ENTER to display the Move Request panel. You can also access this function from the Workbench and Work with Objects with F15=Move requests.


Common Questions

Why would you move a single promotion request at a time?

When applying a specific PTF to your production environment or to move an entire application to production.

Move/Distribute by System Submission Options

This task allows environment administrators with move capabilities or authorized developers to distribute specific promotion requests to remote systems by tape. Perform the task any time you cannot or do not want to set up a communication line to your remote systems.

To perform this task, you must define the environment on the remote system in Work with Environments, and a request must be in either Move-Pend or Dist-Pend status.

To use move/distribute by system options

1 Type menu option 6 or STRIM (*MOVRQSSYS) at the command line and press ENTER to display the Move Requests by System/Environment panel.

2 On the Move Requests by System/Environment panel, press F6=Options to display the Submission Options panel.

You can type option 5 to view requests in the option field of the Move Requests by System/Environment panel and press ENTER to display

277


the Request Selection panel. On this panel, press F6=Options to display the Submission Options panel.

� In the Submission Options panel, complete the necessary information:

� Tape device

� Initialize tape

� Volume identifier

� Multiple promotion requests on tape

� Press ENTER to accept the options and return to the previous panel.

3 Press ENTER to submit the distribution to tape.

NOTE

Use the Restore Remote Request (IRSTRMTRQS) command to prepare the promotion requests to move on the remote system. For more information, see “Restoring Remote Requests (IRSTRMTRQS)” on page 289.

Displaying Move Requests by System/Environment

This task provides clear visibility to the status of promotion requests that target both local and remote locations.

The Move Requests by System/Environment panel displays each system/location and includes a summary of the number of requests at a distribution status and a summary of the requests at a move status. Summary information is further sorted by the number of jobs: scheduled, in the job queue, pending, running, and failed.

To view move requests by system/environment

� From the Implementer Menu, select option 6 to access Move Requests by System/Environment.


Displaying Move Requests by System/Environment

Filtering Options

You can filter the display to show specific locations with promotion requests at a selected status.

� Position to System allows you to position to a specific system name. This is useful if you have a large number of systems defined in Implementer.

� Filter on Status allows you to display all systems that have promotion requests at a specified status level. This is useful if you have a large number of systems defined in Implementer.

From the Move Requests by System/Environment panel, you can drill-down to view all requests for a system/environment and retrieve further diagnostic information concerning the promotion request.

To drill down by system

� Type 5 on the option line of the request you want to view. From the Request Selection panel, you can select specific promotion requests to process. For problem determination and resolution, option 15=Job Log Inquiry and option 16=Job Log Print provide diagnostic capabilities from within the Request Selection panel.

279


Controlling Remote Job SchedulesRemote jobs can be controlled by defining standard move schedules on the host development system, and then reschedule the move times of specific promotion requests to the remote systems. This enables distribution of a promotion request from your host iSeries 400 to multiple remote iSeries 400 systems simultaneously, placing the remote Move step under the control of a default schedule defined for that remote system. Additional flexibility on the host, to reschedule the Move for a specific request, enables you to manage the installation schedule of selected promotion requests without having to access the remote system.

This feature requires:

� The distribution step is separate from the move step. Therefore, option 10=Distribute, must be initiated through menu option 6, Move Requests by System/Environment.

� The remote target environment is set up through Work with Environments to permit remote initiated moves.

When scheduling a remote job, you have two options: use the default schedule settings for the target remote environment, or use the Change Remote Request (ICHGRMTRQS) command to override the default schedule settings for a request. Then, issue the Move Remote Request (IMOVRMTRQS) command to reschedule the job.

Using the Default Job Schedule

To schedule a promotion request to a remote environment (based on the default settings for that environment), you must use menu option 6, Move Requests by System/Environment. This function allows you to distribute requests to any remote environment that is set up as described in “Remote Job Scheduling” on page 281.

The promotion scheduling set for the environment appropriately schedules the job based on the default move time. Then, based on the frequency you define on the remote system in the auto job schedule for the Move Remote Request (IMOVRMTRQS) command, the move is submitted using this default schedule.

NOTE

The move step must be separate from the distribution step because it must be a remote-initiated move.


Controlling Remote Job Schedules

Overriding the Default Job Schedule

The Change Remote Request (CHGRMTRQS) command allows you to enter schedule overrides to the default move schedule for promotion requests. This command evokes DDM to communicate the overrides to the schedule overrides file IMRQSO on the remote for each remote system targeted on the request. The Change Remote Request command does not update the actual move job.

The Move Remote Request (IMOVRMTRQS) command does update the Move job by reading the schedule overrides file IMRQSO on the remote and applying the processed overrides to the OS/400 auto job scheduler. Then, based on the frequency defined on the remote system auto job schedule for the command IMOVRMTRQS, the subsystem is polled for new jobs to be submitted and new overrides not yet applied.

NOTE

A log of the schedule overrides entered is maintained by Implementer in file IMRQSO on both the host and remote systems.

Remote Job Scheduling

Perform the following steps prior to using remote job scheduling:

� Define the remote environment to allow remote-initiated moves.

� Define the remote environment to have a default move time.

� Create a routinely running job on each remote system that issues the Move Remote Request (IMOVRMTRQS) command for all requests.

To set up a remote environment for remote initiated moves

1 From the Implementer Menu, select option 42 to display the Work with Environments panel.

2 Select the remote environment that you want to define using option 2=Change. The Change Environment panel displays.

3 Press PAGE DOWN twice to display the third Change Environment panel.

281


4 In the Remote initiated move field type Y.

5 In the Updates host field, type Y or N to indicate whether remote initiated moves should update the host with information such as the request header status, request detail status and information, archive information, and job log. If set to N, the status is set to complete after the request is distributed. Otherwise, the status is not updated until the move actually occurs on the remote system.

6 Press ENTER to save the change and redisplay the Work with Environments panel.

To set up default scheduling for a remote environment

1 From the Work with Environments panel, select the remote environment that you want to define with option 13=Promotion scheduling. The Change Environment panel displays.

2 Press PAGE DOWN to display the second Change Environment panel.



3 In the Move submit date range and Time range fields specify the default date and time ranges to use for the majority of requests. The left-most field represents the from-date or time. The right-most field represents the to-date or time.

NOTE

In the Time range fields, you can specify exact from and to times, or *CURRENT to default the time value from the system.

To create a job that processes the move request

1 Use the Add Job Schedule Entry (ADDJOBSCDE) command to add an entry to the OS/400 job scheduler.

This is an example of a daily job schedule entry:

*CURRENT The from and to dates default from the system. This is the default value.

Actual Date Specify an exact from and to date.

*MONTHSTR The from date is the first day of the month.

*MONTHEND The to date is the last day of the month.

*MON through *SUN

Type an asterisk followed by the first three letters of any day of the week to indicate the from date.

283


ADDJOBSCDE JOB(IMAUTOSCH)CMD(IMOVRMTRQS RQSNUM(*ALL))

FRQ(*WEEKLY)

SCDDATE(*NONE)

SCDDAY(*ALL)

SCDTIME(150000)

JOBD(IMPJOBD)

2 If you need to modify the job schedule entry or view a list of currently scheduled job entries, use the Work with Job Schedule Entry (WRKJOBSCDE) command.

Changing Remote Requests

This Change Remote Request (ICHGRMTRQS) command communicates schedule changes for each remote system targeted on the request. The schedule changes you define are processed to the schedule overrides file IMRQSO.

To use the ICHGRMTRQS command

1 Use the Create Request function to submit a request to a remote environment or select a request already created.

2 Type the command ICHGRMTRQS on the command line and press F4=Prompt.

3 Define the command parameters based on your environment, and press ENTER.

TIP

The Change Remote Request command can be issued at any point after the request is created—the request does not have to be at a Move Pend status.

ICHGRMTRQS Command Parameters

Request number (RQSNUM)

Specify the request number from the request you created.



Target environment (TGTENV)

Specify the target environment from the request.

From date (FROMDATE)/To date (TODATE)

Specify the date range to schedule the move.

From time (FROMTIME)/To time (TOTIME)

Specify the time range to schedule the move. The From date/To date and From time/To time fields, in combination, define a window of time. As such, if a value is specified for any one field, a value must be specified in all of the fields.

Job Queue Library/Queue (JOBQ)

Specify the job queue library and name for the move.

Hold on job queue (HOLD)

Complete this standard OS/400 Submit job parameter as required.

Name Specify the name of the target environment.

Generic* Specify a value that will be used to include all matching environments. For example, the entry ABC* includes all environments beginning with ABC in the scheduling change.

*ALL Includes all target environments requests are issued for.

*CURRENT The from and to dates default from the system.

Actual Date Specify an exact from and to date.

*MONTHSTR The from date is the start of the month.

*MONTHEND The to date is the end of the month.

*MON through *SUN

Type an asterisk followed by the first three letters of any day of the week to indicate the from date.

*REQUEST The dates and times do not change. This is the default value.

Actual time range

Specify exact from and to times.

*CURRENT Defaults the time range from the system.

*REQUEST The dates and times do not change. This is the default value.

Name Specify the name of a job queue and library.

*SYSCTL Uses the job queue specified in System Control.

*REQUEST The job queue and library do not change. This is the default value.

285


Moving Remote Requests

The Move Remote Request (IMOVRMTRQS) command processes the move step for each remote environment targeted on the request. If schedule overrides were entered using the Change Remote Request (ICHGRMTRQS) command, you must also issue this command to process the override updates to the OS/400 auto job scheduler.

If schedule overrides cannot be applied, (such as attempting to schedule from a date in the past) an error message is generated. All schedule updates of previously submitted jobs are attempted even if an error is encountered on another request.

The IMOVRMTRQS command runs periodically on the remote system to control the move jobs using the following criteria:

� For new requests that were not previously submitted, it submits the move job using the default move time, or if any schedule overrides were specified with the Change Remote Request (ICHGRMTRQS) command.

� For inactive requests that were previously submitted, it updates the schedule to the last request schedule override received.

� For all submitted requests, it updates the submitted request audit file IMRQSO.

To use the IMOVRMTRQS command

1 Use the Create Requests function to submit a request to a remote environment or select a request already created.

2 Type IMOVRRMTRQS on the command line and press F4=Prompt.

3 Define the command parameters based on your environment. Specify the request number as follows:

4 Press ENTER.

Character Value

Type a specific request number. This resubmits a request currently at a scheduled status. For example, use this to resubmit a specific request if the promotion job was deleted from the system while at a scheduled status. This resubmits all scheduled jobs based on the default schedule, or the last override, if one was processed.

*ALL This does not resubmit a request at a scheduled status. For new requests not previously submitted, it submits the move job using the default move time, or if any schedule overrides were specified with the Change Remote Request (ICHGRMTRQS) command. For inactive requests previously submitted, it updates the schedule to the last request schedule override processed.

*FAILED This does not resubmit a request at a scheduled status.


Using the Implementer Receiver Menu

Using the Implementer Receiver MenuThe Implementer Receiver Menu allows easy access to the following major functions used on the remote system:

� working with remote requests

� restoring remote requests

� moving remote requests

� working with function keys

The menu simplifies the restoration and move of members/objects on a remote system.

A remote environment administrator who has move capabilities performs this task when it is necessary to inquire, restore, or move members/objects in a remote production environment. You usually do not use this function if the environment is defined as a host initiated move.

The Implementer Receiver library (default library MKSIR) must be installed on the remote system and the library must be in your library list.

To access the Implementer Receiver Menu

1 Ensure the remote library is installed on the remote system and that the library is on your library list.

2 Type STRIR at the command line and press ENTER to display the Implementer Receiver menu.

287


Common Questions

What is the difference between a host initiated move and a remote initiated move?

� Host initiated moves automatically complete the distribution and move steps into the remote production environment, or with little or no user intervention.

� The remote initiated move requires user intervention before promoting the members/objects into the remote production environment. You may need to restore the objects from tape or NetView/DM and then move the members/objects into production. Remote initiated moves are usually performed by the user profile that has move capabilities during non-business hours.

Can you automatically submit a remote initiated move?

Yes. Use the IBM job scheduler to automatically submit an IMOVRMTRQS *ALL. If you have ROBOT installed, you could use ROBOT.

Working With Requests on the Remote System

The Work with Remote Requests function simplifies the tasks of promotion on a remote system by allowing request inquiry, request report printing, and remote initiation for moving the members/objects into the remote production environment. This function is generally performed by a remote environment administrator who has move capabilities.

NOTE

AS/SET definitions are not supported on the Implementer Receiver.

To work with remote requests

1 Ensure the remote library is installed on the remote system and that the library MKSIR is on your library list.

2 Type the command STRIR at the command line and press ENTER to display the Implementer Receiver Menu.

3 Type option 1 at the command line and press ENTER to display the Work with Remote Requests panel.


Using the Implementer Receiver Menu

4 Do one of the following:

� Review the actual promotion requests with option 5.

� Review the promotion request information (user profile, environments, status, type, history, and overrides) with option 8.

� Print the promotion request report with option 6.

� Move the promotion request with the Move Remote Requests (IMOVRMTRQS) command.

NOTE

The environment must be set up as a remote initiated move in Work with Environments.

Before a promotion request can be moved with this option, it must be restored and at a Move-Pend status.

You can view target environments or target environment groups on the system, or display special commands.

Restoring Remote Requests (IRSTRMTRQS)

The Restore Remote Requests (IRSTRMTRQS) command restores a promotion request that was distributed by tape or with NetView/DM. These objects are restored into a work library. This command is also available from the Work with Remote Requests panel. This step is typically performed by a remote environment administrator who has move capabilities. It must be performed before the members/objects can be moved into production.

If the promotion request is specified as remote initiated move, you can move the objects and source into the target library after the restore (by an option within the command) or submit the move separately. If you initiate the move from the host, you can submit it after the restore has completed. You must restore the members/objects before you can submit the final move step.

If the members/objects were distributed by tape, the tape must be in the drive. If the members/objects were distributed using NetView/DM, the distribution to the remote must have been successful, and the save file containing the members/objects must be in the correct library.

This task is required if members/objects are distributed using tape or NetView/DM.

289


To restore remote requests

1 Ensure the remote library is installed on the remote system and that the library is on your library list.

2 Type the command STRIR at the command line, and press ENTER to display the Implementer Receiver Menu.

3 Type option 2 at the command line and press ENTER to display the Restore Remote Requests (IRSTRMTRQS) command.

4 Define the parameters and press ENTER.

NOTE

If you want to automatically submit the move after the restore, type *YES in the Submit move request field. If you want to delay either the restore or the restore and automatic move until a later time, type *YES in the Hold on Job queue field, or move the job to the appropriate job queue.

Moving Remote Requests (IMOVRMTRQS)

The Move Remote Requests (IMOVRMTRQS) command completes the promotion process for remote initiated moves that you restored using the Restore Remote Requests (IRSTRMTRQS) command. It is used to promote the members/objects into a remote production environment.

This command can be issued by a remote environment administrator or by any user with move capabilities for that environment. It is performed after you have distributed the members/objects (and if necessary, restored the members/objects) to the remote system and are ready to promote.

To use this command, the environment definition must be designated as remote initiated move and you must have distributed the members/objects to the remote system (and if necessary restored them).

This is a required task.

To move remote requests

1 Ensure the appropriate remote library is installed on the remote system and that the library is on your library list.

2 Type the command STRIR at the command line, and press ENTER to display the Implementer Receiver Menu.

3 Type option 3 at the command line and press ENTER to display the Move Remote Requests (IMOVRMTRQS) command.


Working With Function Keys

4 Define the required parameters and press ENTER.

An alternative method to step 3 and step 4 is to type option 1 at the command line and press ENTER to display the Work with Remote Requests panel. Move the promotion request with the Move Remote Requests (IMOVRMTRQS) command.

Working With Function Keys The Work with Function Keys function allows you to change the definition of command keys on a modifiable panel.

You can add, change, or delete specific command keys. There are specific key numbers for global keys and the capacity to either make the key global, or override it for each specified panel.

You can define specific function keys to directly access your internal systems (such as a problem tracking or help desk system) from the Implementer Receiver Menu, or to add commonly issued commands to a function key.

To work with function keys

1 From the Implementer Receiver Menu, select option 4, Work with Function Keys, and press ENTER. The Work with Function Keys Panel Select panel displays.

2 Select the panel you want to work with (or *ALL) using option 1=Work with panel. The Work with Function Keys - Key Select panel displays.

A description of the fields on this panel is next. From this panel you can use option 1=Change to change function keys, or option 8=Refresh overridden global function keys.

NOTE

If the global column displays an O (indicating that it is a global function key with specific overrides for this panel), option 8 causes the key to reset to its original global values. In addition, it causes Y to appear in the global column. This option is available on all panels except the *ALL (global panel). You can use option 9=Delete to delete function keys.

291


Function Keys – Key Select Panel Field Descriptions

The following fields display on the Work with Function Keys - Key Select panel.

Panel ID

Defines the panel the function keys are defined for. This value appears in the upper left corner of all panels within the product.

Panel width

Defines how wide the panel is.

Number of lines

Defines how many lines appear on the panel.

Global

Defines whether the function key is a global key (defined to the *ALL panel ID) and whether the key definition was overridden from its global definition. This entry is not maintainable.

Function Key

The number assigned to the function key.

Y The key is an unchanged global key—the specified key definition is equal to the global key definition.

O The global definition is overridden for this function key.

Blank The key is not a global key—it is defined globally, but one of the attributes is redefined on this panel.

0 ENTER

1-24 Function keys 1 through 24

25 ROLLUP

26 ROLLDOWN

27 HELP

28 HOME

29 CLEAR

100+ Document-only function keys. This allows you to document and display some of the commonly used keys on your system keyboard. You can number document-only function keys from 100 to 999. These keys cause no processing to occur they simply document available keys that are processed outside the application program (for example, System Request, Attention, and various PC hot key sequences). When creating a document-only function key you cannot enter an action or command.


Working With Function Keys

Function Key Name

This entry is derived from the function key prefix and number. You cannot maintain it for regular function keys. You can enter this on the Work with Function Keys - Key Maintenance panel for document-only function keys.

Function Key Text

This description displays on a panel after the separator for the function key. For example, for F8=Spool Files, Spool Files is the function key text.

Valid

Defines whether the function key is valid on this panel.

Display

Defines whether the function key displays on the panel, if valid. The value for this entry is only used if the function key is valid.

Action/Command

This can be an action or a command. You can distinguish actions and commands as follows:

� Actions are prefaced by an asterisk (*). Commands are not prefaced by an asterisk.

� If an action is specified, the action returns to the program that is processing the panel. You cannot maintain actions.

� If a command is specified, the command is issued when the function key is pressed. You can maintain a command by typing 1 in the selection entry and pressing ENTER to proceed to the Work with Function Keys - Key Maint panel.

Y The function key is valid on this panel.

N The function key is not valid on this panel. Invalid function keys do not display. An example of this is PAGE DOWN on a panel containing only one page.

Y The function key displays.

N The function key does not display. If the valid flag is Y, the function key remains valid. An example of this is ENTER.

293

8Handling Emergency Situations

Implementer supports the following three emergency functions:

� Archive Recovery allows you to roll back a previously completed promotion request. This is useful when a promoted change is not working properly, and you want to return the previous versions of the objects (and source members) to production while you investigate or fix the problem.

� Emergency Check Out provides all the features of the standard Check Out function, and marks the member/object as checked out for emergency purposes.

� Emergency Create Request provides all the features of the standard Create Request function. You can optionally select emergency check out only for promotion. These promotion requests are denoted as emergency promotion requests.


� archiving

� using the Archive to Tape features

� performing archive recovery

� performing emergency check out

� performing emergency create request

295

Handling Emergency Situations

ArchivingImplementer allows source members and objects to be archived during promotion. You can use these archives to roll back (recover) a change, or to simply view a historical copy of a source.

The archiving of target source and objects is based on the environment definition. SQL tables and physical file objects are never archived. If archiving is requested for the table or physical file object, only the source is archived.

Source and objects are archived during the move step of a promotion request. The target environment definition is used to control how and when to archive. You can optionally archive the source or objects for the environments.

NOTE

Archiving is not supported for AS/SET definitions.

Archiving Source and Objects on a Promotion Request

Archived source and objects are stored in one large library. Because you cannot have two objects with the same name in a library, the objects that are placed in the archive library are renamed. This allows the ability to archive multiple copies of the same source and object. In addition, the source members are renamed when they are archived. The archive library is not accessible to Implementer users.

When you recover objects or display archived source members, what version of the source member or object to use is automatically determined. You can use the same archive library for multiple environments. The archive library must be different from any other libraries for an environment.

If you have targeted multiple environments on a promotion request that are designated for archive, the objects are archived multiple times.

A common development scenario is to archive your production environments and not your development or test environments.


Using the Archive to Tape Features

Using the Archive to Tape FeaturesImplementer users who require access to archives of every change made to all, or certain environments, must balance this requirement with disk space required for storing archive copies. The archive to tape feature provides for off line storage of archives (if your disk space is limited, this can be an issue).

Additional features allow you to selectively save archives from the system to tape. This feature provides access to archive information for each tape, and the ability to selectively restore archives to the system—to either browse the changes or recover them back into the production environment.

Process Overview

Archives continue to be made during any promotion into an environment that is being archived. On a periodic basis that you determine, all archives can be removed from the system and placed on a tape. Each save should be done on a fresh tape.

The tape label is set by Implementer.

An online query allows you to locate and list all archives that are on tapes, including their tape labels. You can also print these reports.

When archives need to be restored, a command is provided that allows you to restore archives for any archived environment on a request that must be backed out. To complete the recovery, menu option 23, Archive Recovery, is used to select the request to be recovered, and a normal, archive recovery request is created and promoted. Additionally, the source can be browsed through Archive Recovery and Object Inquiry.

NOTE

Before using the Archive to Tape features, certain setup steps must be performed. For more information, see “Set Up for Archive to Tape Capabilities” in Chapter 3 of the Implementer System Administrator Guide.

Working With Tape Archives

You must be signed on as QSECOFR, or with a profile that has a group profile of QSECOFR, to display the Archives to Tape menu or use any of the menu options.

To display the Archive to Tape menu

Select one of the following options to display the Archives to Tape menu.

� From the Implementer Menu, type option 24, Archive to Tape, and press ENTER.

297


� Issue the following command (the library MKSIM must be in your library list):

GO IMARCTAP

All of the archive to tape functions can be initiated from the Archives to Tape menu.

To save an archive to tape

� From the Archive to Tape menu, select option 1, Save Archives to Tape. The Save Archives to Tape panel displays.

This panel allows you to selectively save archives to tape. It is easily added to backup routines to remove any archives since the last save. Since multiple environments can share an archive library, this function identifies the archive library to save. Therefore, all environments using this archive library are backed up in one operation.

The tape that is used is automatically initialized with a tape volume ARC###, where ### represents a number starting with 001 and automatically increments for each save. This information is stored in Implementer data area ITAPEVOLUM. If you need to specify another


Using the Archive to Tape Features

tape volume ID, use the Change Data Area (CHGDTAARA) command.

CAUTION

Be careful not to issue this command with the incorrect tape loaded, since it will be initialized and the current tape contents cleared.

To restore an archive

� From the Archives to Tape menu, select option 2, Restore Archives from Tape. The Restore Archives from Tape panel displays.

This panel allows you to selectively restore archives from tape to recover a specific request. The queries provided allow you to easily locate the requests to restore.

Archives are restored back into the same archive library that they were saved from.

IMPORTANT

If archive libraries were saved and cleared in the past, the Implementer files that manage the archives still reflect that the object is in the archive library when, in fact, it is not. For this reason, a cleared object still appears on the reports of archived versions. If an attempt is made to recover a cleared object, it will fail (since the object is not actually on the tape). To recover the remaining items on the request being recovered, use the IBM Data File Utility (DFU) command to remove the record referring to the archive that was deleted from the Archives on Tape file (IMARTP).

Archive Reports Implementer provides three queries to manage the archives on tape:

� Archives per Tape Report

� Archives by Request Report

� Archives by Environment Report

When you select options 3, 4, or 5 from the Archives to Tape menu, the queries are prompted to allow for easy selection of online viewing or generating a printed report. In addition, standard query record selection is available to restrict the reports to only the tape, request, or environment of interest.

299


Archive RecoveryOnce you promote a change using Implementer, you can easily roll back that change in case of an emergency. For example, if a change is moved to production at 4:00 p.m. and you determine at 4:30 p.m. the change is wrong (it hard halts or is giving incorrect results), you may want to return production to the previous version and correct the problem later.

Related request processing applies to promoting cross-environment related objects, a feature activated in System Control Maintenance. For more information, see “Related Request Processing” on page 201.

Archive recovery supports the rollback of standard promotion requests, as well as related requests—that is, primary requests and their generated secondary requests.

From the Archive recovery panel, you can determine if a request has any secondary requests by the value in the Related Requests column. When related requests do not exist, the value is blank, which indicates a standard release. When related requests do exist, the value “Primary” or “Secondary” displays to identify the release type.

To roll back a promotion request, you must be authorized to use the Archive Recovery menu option, and you must be authorized to recover for this specific environment.

Recovering Archived Source/Object by Request

Whenever you promote new objects into production, it is possible for errors to occur that make the updated production environment unusable. When this happens, it is necessary to have an automated (and accurate) process to restore the last production version (or whatever version you need). Because all archived versions (up to 99 levels) are tracked, this function gives you critical control in a disaster situation.

This task allows you to return your production environment to a previously working version of one or more objects by automatically recovering or backing out implementation requests. A request is generated and the compile and move procedures are automatically performed. The recovered request is superseded by the new recovery request.

You can roll back either a single object or an entire promotion request. If you archived the objects, you can process a rapid rollback, which does not require the compilation step. If you archived source only, or if you want to recompile the source, specify source archival on the request.

The rollback procedures create a promotion request. The request type is recov. This approach ensures the same integrity as a normal promotion request and ensures that the rollback is fully logged and tracked as a change. Each production member/object is checked out and remains checked out until it is forward promoted, if you selected it for check out on the Archive Recovery Options panel.

Only promotion requests that still have source or objects in the archive library for the environment are eligible for rollback. For example, objects on a promotion request that were also promoted on another more recent promotion request may not be available. If the archive for the environment was set to only archive one version of the object, the earlier promotion


Archive Recovery

request could not be recovered because the object no longer exists in the archive library.

Targeting Multiple Environments

You can separately recover source and objects from individual environments for a promotion request that targeted multiple environments. You can select from a list of archive capable environments and a separate request is created for each.

Archive recovery is generally performed by an environment administrator who has move capabilities.


� Archive options must be enabled for the target environment.

� The members/objects must exist in an archive library (you usually set up each production environment to archive).

� The request must not have been purged.

To recover archived source/object by request

1 Type menu option 23 or STRIM (*ARCRCV) at the command line and press ENTER. The Archive Recovery panel displays.

2 Type 1 in the option field and press ENTER to select the request and display the request detail. The Request Member/Object Selection panel displays.

For a primary or secondary request, you can use option 15=Related Requests to display a list of the related request detail (recovery options are not available from the Related Request panel).

3 Type option 1 next to the member/objects to recover and press ENTER, or press F16 to select all member/objects on the request.

4 Press F9=Recover to process the selected member/objects. The menu redisplays with a message indicating the move request was submitted.

The selected members/objects are automatically promoted back into production. If necessary, members are compiled first. The request type is Recov.

IMPORTANT

If you archived both source and objects, you must select either the source or the object—you cannot select both source and objects to rollback into production.

301


Common questions

If multiple versions are archived, how do you know which one to restore?

The most current archive is at the top of the list. If you need to choose another archived version, use the Requester, From lib/environment, and Target environment columns to help delineate which version to select.

If you need to restore a deleted object, how do you determine which request processed the delete?

In Work with Objects, you can filter to the member/object, then press F18=Show deleted. The Show deleted function identifies the deletion type and promotion request that initiated the delete.

Are there cases where a request cannot be restored?

If you choose to restore a completed promotion request that another user (developer) has allocated, the restore will fail.

Does Implementer support archive and recovery of SQL files?

Yes.

Automatic Check Out Archive Options

During Archive Recovery, you have the option to check out the current version that was just promoted into production to a developer. This allows immediate development on the fix. At the same time, Archive Recovery rolls back the previous versions to production so users are able to immediately become productive.

This task allows you to automatically check out during the automatic recovery process. This is most often used when a promoted change does not work (production halts), and you need to restore the required working version and begin immediate changes on the previously promoted changes.

Archive recovery requests do not use default application paths, established in Work with Projects and Work with Environments, for Check Out and Create Request.

This task is generally performed by an environment administrator who has move capabilities, whenever you need to rollback a previous version of a member/object into production.

Archiving must be enabled and a promotion request must be complete for an archived promotion request to exist.

To automatically check out during archive recovery

1 Type menu option 23 or STRIM (*ARCRCV) at the command line and press ENTER.


Archive Recovery

2 Record the from library/environment on the Archive Recovery panel. You may need this value later in the recovery options panel. In the Archive Recovery panel, type option 1 next to the promotion request you want to put back into production and press ENTER to display the Request Member/Object Selection panel.

3 In the Request Member/Object Selection panel, type option 1 next to the members/objects you want to back out and press ENTER, or F16=Select All on the promotion request.

IMPORTANT

If you archived both source and objects, you must select either the source or the object. You cannot select both to rollback into production.

4 Record the request ID and the project reference at the top of the Request Member/Object Selection panel. You may need these in the Recovery Options panel.

5 Press F8=Recovery options to display the Archive Recovery Options panel.

6 In the Archive Recovery Options panel:

a) Type Y in the Check Out Current Member/Object field.

b) Complete the required information for the following fields. It can be the same information as on the original request or new information:

� To library or To environment fields

� To User field

� Project reference field

� Design Request field

� Recover LANSA objects on the request field

c) Press ENTER.

The Recover LANSA objects field on the Archive Recovery Options panel specifies whether LANSA objects should be recovered. Both traditional and LANSA objects can be recovered at the same time. This is particularly useful when you have a combination of LANSA objects and traditional objects on the same request.

If you want to recover only traditional objects, set the Recover LANSA objects on the request field to N when you select the

303


traditional objects. If you want to recover only LANSA objects, set the Recover LANSA objects on the request field to Y but do not select any of the traditional objects. All LANSA objects on the request are recovered. You must recover all of the LANSA objects or none of the LANSA objects.

NOTE

If you want to change the overrides for the compile step of promotion scheduling, press F18=Submission overrides to display the Job Schedule Overrides panel from the Archive Recovery Options panel. Fill in the changes or accept the defaults and press ENTER to redisplay the previous panel. Note that Time range fields must be entered in HH:MM:SS format.

7 In Request Member/Object Selection panel, press F9=Recover to rollback the members/objects.

This creates a promotion request type of recov to indicate that the promotion originated from archived members/objects. The menu redisplays with a message indicating the move request was submitted.

Emergency Check OutYou usually perform emergency development on the member/object for an emergency change to production. Emergency Check Out and Emergency Create Request provide check out and promotion functions to mark the members/objects and promotion request for emergency purposes, restricting the capability to certain users.

MKS suggests that you have an emergency path set up for the production environment. For a description of path setup, see the Implementer System Administrator Guide. The creation of standard and emergency paths is identical.

This tasks checks out a member/object for emergency purposes. It can be performed by any developer with emergency rights, when a programming change outside of the normal development process is necessary.


Emergency Check Out

The user profile must have authority to perform emergency check out. They must also have authority to perform an emergency check out from the environment.

NOTE

For emergency check out, the one step check out method applies only when the check out is initiated from Work with Objects, using option 21=Emergency Check Out.

To perform emergency check out

The actual steps after you select the menu option are identical to standard check out with the following exception: The lock type placed on a member/object in Emergency Check Out is Emerg.

1 Access Emergency Check Out using one of the following options. Option 21=Emergency Check Out in My Workbench or the Work with Objects panel, option 4 from the Clipboard Processing Menu, option 21 from the main menu, or type the command STRIM *ECHKOUT and press ENTER. A similar panel can be accessed using option 20=Reject, for rejecting a member/object with an emergency lock.

2 Check out using any of the check out tasks as described in “Performing Check Out” on page 111.

Common Questions

What is the difference between standard and emergency check out?

The action that created the lock is different and the panel headings are different.

You must assign different capabilities to a user so they can perform emergency check out versus standard check out. The functionality remains the same.

305


Emergency PromotionWhen it is necessary to promote a member/object under emergency status, use the Emergency Create Request function to create an emergency promotion request.

MKS suggests that you have an emergency path set up for the production environment. For a description of path setup, see the Implementer System Administrator Guide. Creation of standard and emergency paths is identical.

This task creates an emergency promotion request. It can be performed by any user with the capability for Emergency Create Request. This user also has (by default) the capability to resolve conflicts for items on the promotion request they are currently creating.

User profiles must exist for the System Administrator and for those users who create the environments.

NOTE

The one step promotion method does not affect this task.

To create an emergency promotion request

The steps to create an emergency promotion request are identical to those of a standard promotion request, with the following exception: The promotion request type is Emerg.

1 Access Emergency Create Request using one of the following options. Option 22=Emergency Promote in either My Workbench or the Work with Objects panel, option 5 from the Clipboard Processing Menu, option 22 from the main menu, or the command STRIM *ECRTRQS and press ENTER.

2 You can use any of the Create Promotion Request tasks as described in “Performing Promotions” on page 171.

For more information on this data area, see Appendix A of the Implementer System Administrator Guide.

3 In addition, the auto submit option defaults from the value specified for the Implementer data area IMEMGSTP (Emergency Promotion Request Submit Through Step) regardless of how the default target environment is defined. The default value for this data area is 4 (through the move step), which ensures the change is promoted into the target libraries as quickly as possible. The auto submit field can also be overridden by pressing F18=Overrides from the Emergency Create Request panel.


9Member and Object Handling

Implementer has advanced features to support the different types of OS/400 objects and source members. All OS/400 members/objects that exist in user libraries are supported as well.

The object code provides the seamless way in which Implementer supports the different types of items it must promote. Whether an item is a source member (such as OCL36 or COBOL copy blocks), an object (data areas or job descriptions), or a source-based object (such as an RPG program, display file, or physical file), you specify the same information about each item—the name of the item and the object code.

The object code defines whether the item has an associated source member and associated objects, and defines how it will be compiled.

The chapter covers how Implementer works with:

� Compile options

� Database file management

� Special object considerations

� ILE member/objects

� S/36 environment

� S/38 environment

� Extended object support

307

Member and Object Handling

Compile OptionsFor source-based objects, you can tailor the compilation commands for your particular needs. You can customize any parameter of the standard compilation commands, such as Create Display Files (CRTDSPF). You can also use your own customized compilation commands.

It is not uncommon to require different commands to support various vendor software packages. Some of the application software vendors whose compilation procedures can be included in Implementer include System Software Associates (SSA)—BPCS, J.D. Edwards, and American Software, Inc. For object codes related to a specific vendor, see “Integrating With Other Vendor Products” on page 327, or Chapter 5 of the Implementer System Administrator Guide.

Database ManagementImplementer’s support for database management includes complete support for all object and source types, including source-based objects, non-source-based objects, source-only items, and the tracking of non- OS/400 items.

This section covers the support Implementer provides for managing the following types of database files:

� non-source-based SQL

� source-based SQL (DDL)

� traditional DDS-based

� triggers and constraints

IMPORTANT

If you are working in a mixed-development environment, Implementer requires that an SQL table have only SQL indices and views built over it. In other words, Implementer does not support DDS-based logical files built over SQL tables, or SQL-based logical files built over DDS-based physical files.


Database Management

Managing Non-Source-based SQL

Implementer provides full support for database files built using non-source-based SQL. This includes SQL tables, indices, and views, as well as the retention of existing triggers and constraints.

Object Codes for Non-Source SQL

For managing SQL DDL, Implementer provides three non-source-based object codes. You may also create user-defined object codes provided they are created with the required special characteristic for non-source-based tables. The special characteristic ensures that the Implementer repository properly reflects the different object types, and also distinguishes SQL DDL-based tables from DDS-based files.

When checking out and promoting SQL DDL objects, use the following object codes, as described.

File Creation for Non-Source SQL

When creating a request to promote SQL objects, Implementer verifies:

� the request does not contain DDS-based logical files built over SQL tables

� the request does not contain SQL-based logical files built over DDS-based physical files

� only SQL type object codes are used for SQL objects

All SQL objects go through the compile step, which ensures that the tables will be installed correctly in production. Implementer uses an SQL DDL Alter Table (ALTER TABLE) statement architecture to recreate a file in the production library. During the compile, Implementer verifies the request does not contain changes that are not supported by the ALTER TABLE command. The ALTER TABLE statement detects the differences between the table being promoted and the target production table. The target table is duplicated into a temporary library without data, where the ALTER TABLE statement is run again. This ensures that only the changes supported by the ALTER TABLE command are included in the promotion.

Object Codes for Non-Source SQL

Object Type Object CodeSpecial Characteristics

SQL Table SQLT SQLTABLE

SQL View SQLV SQLVIEW

SQL Index SQLI SQLINDEX

309


For example, it detects un-supported changes in fields/columns in a table, and the use of deleted fields/columns by existing SQL indices, views, or logical files. If problems are detected, the request fails, before the move step, ensuring the integrity of the production files.

After examining the target library for related indices and views, those found are recreated in a temporary work library where they are used for recompiling any related programs. This also ensures that all unchanged indices and views that contain fields/columns that were dropped from the table are detected, before the move step, again ensuring the integrity of the production files. The target libraries are also examined for existing related indices and views that specified list of field to include in a view. If found, they are archived, deleted from production, and then recreated (rather than compiled).

The distribution step is handled as any other member/object. If archiving is selected, it occurs before the move step.

In the move step, Implementer uses the ALTER TABLE command to replace the tables in the production library. While Implementer does not explicitly require or perform journal management, a function of the ALTER TABLE command stops and re-starts the journals for journaled files. For related indices and views, Implementer issues the CREATE INDEX or CREATE VIEW command over the new production file to ensure they are correctly built.

Archive and Archive Recovery

Implementer supports the archive and recovery of SQL DDL indices and views. For archiving, it uses the CREATE INDEX or CREATE VIEW command, based on file type, to save the files to a source file in the archive library. This allows for object creation from the source file during Archive Recovery.

Build List Consideration

The Build List function distinguishes SQL-based tables, indices, and views from DDS-based files.

During a build, if Implementer finds existing SQL tables, indices, or views loaded into the repository as DDS-based, the object code for those objects will automatically be changed to it’s respective SQL-based object code. If an SQL object is found with no corresponding object code/special characteristic for that type of object, the object will not be loaded into the repository, rather a message will display indicating the object was not loaded. This is the standard way Implementer handles an object that does not have a valid corresponding object code for an environment.


Database Management

Managing Source-based SQL (DDL)

Implementer provides full support for database files built using source-based SQL (OS/400 managed source), including the retention of existing triggers and constraints for source-based tables.

For more information on optimizing promotions, see “Optimizing Physical File Promotions” on page 313.

The promotion of source-based SQL is similar to that of an optimized PF promotion, in that most of the work is performed in the production library during the move step. This technique ensures the integrity of your production files, while at the same time bypasses a significant amount of the promotion processing that occurs in the Implementer work libraries.

Implementer’s support for SQL management provides the following benefits:

� automatically adds related indices and views to the request (they do not have to be explicitly added)

� automatically rebuilds indices and views

� automatically retains triggers and constraints

� eliminates copying of data

Object Codes for Source-based SQL

For managing source-based SQL DDL objects, Implementer provides three source-based object codes. You may also create user-defined object codes, provided they are created with the applicable source member type.

The source member type identifies it as a source-based object and ensures that the Implementer repository properly reflects the different object types to distinguish SQL DDL-based tables from DDS-based files.

When checking out and promoting DDL source-based SQL objects, use the following object codes, as described.

File Creation for Source-based SQL Physical Files

Implementer supports the promotion of physical files created through SQL that exist in collection libraries.

Object Codes for Sourced-based SQL

Object Type Object CodeSource Member Type

SQL Table SQLTABL SQLTABL

SQL View SQLVIEW SQLVIEW

SQL Index SQLINDX SQLINDX

311


To promote source-based physical files, use the SQLTABL object code that has a source member type of SQLTABL.

When using SQLTABL, or the SQLINDX object code for logical files and SQLVIEW object code for views, all related PFs and LFs must be checked out and promoted together (there is no implicit logical file processing).

When promoting DDL-based physical files, Implementer automatically retains any existing triggers and constraints in the target production environment. To add or remove a trigger or constraint, use the special commands feature when creating the promotion request.

File Creation for Source-based SQL Logical Files

Implementer supports the promotion of logical files created through SQL that exist in collection libraries.

To promote source-based logical files, use the SQLINDX object code that has a source member type of SLQLINDX for indices, and the SQLVIEW object code that has a source member type of SQLVIEW for views.

Note that when using SQLINDX or SQLVIEW object codes for logical files, all related PFs and LFs must be checked out and promoted together (there is no implicit logical file processing).

When promoting DDL-based logical files, Implementer automatically retains any existing constraints in the target production environment. To add or remove a constraint, use the special commands feature when creating the promotion request.

Managing Traditional DDS

The traditional database uses Data Definition Specifications (DDS) based files, although it also uses high-level languages (such as SQL, RPG IV, and ILE Cobol) that include I/O extensions to support database files and commands.

This section covers important information about promoting traditional DDS-based physical files and logical files.

IMPORTANT

Implementer requires that a physical file created with DDS have only DDS-based logical files built over it. In other words, Implementer does not support DDS-based logical files built over SQL tables, or SQL-based logical files built over DDS-based physical files.


Database Management

Promoting Physical Files

In traditional database management, physical files are one of the most complicated objects that Implementer supports. However, a number of features exist that help you to efficiently handle these complexities.

Optimizing Physical File Promotions

For more information on this feature, see “Optimizing Physical File Promotions” on page 183.

Implementer provides a feature that allows you to optimize the promotion of DDS-based physical files created with the Create Physical File (CRTPF) command.

When optimizing, Implementer uses the Change Physical File (CHGPF) command over the target file in production when promoting DDS-based physical files. The processing steps of an optimized PF promotion are similar to those of an SQL DLL file promotion, in that most of the work is performed in the production library during the move step. This technique ensures the integrity of your production files, while at the same time bypasses a significant amount of the promotion processing that occurs in the Implementer work libraries. Because this technique runs directly over production files, optimized promotions are typically submitted for evening or weekend processing when the files are not used.

The benefits to using optimized PF promotions include:

� it reduces database file promotions an average of 50% over non-optimized promotions

� it automatically rebuilds any logical files or indices

� it eliminates copying of data

If a request fails, the existing files remain in production as they were before the promotion. After correcting any problems, you can re-submit the request.

Triggers and Constraints

When promoting DDS-based physical files on an optimized request, Implementer automatically retains any existing DDS-based triggers and constraints in the target production environment.

To add or remove triggers and constraints, or to retain triggers and constraints without optimizing, use the special commands feature when creating the promotion request. Generally, this requires creating a special command with the Add Physical File Trigger (ADDPFTRG) command or the Remove Physical File Trigger (RMVPFTRG) command, to run After-Move Ok, either on a per request basis or at the environment level

313


depending on the number of triggers. For example, if you create a new physical file, Implementer will only add the triggers and constraints when the file is promoted if instructed to do so in a special command.

Related Files

Implementer automatically determines all related logical files when promoting a physical file. If you did not explicitly select a related logical file, it is automatically added to the promotion request with a status of recompile. This designates that you did not change the logical file, but that it must be recompiled against the new physical file to work correctly.

Data Retention of Non-Optimized Promotions

When PF promotions are not optimized, existing data is retained using the record format field mapping options *MAP and *DROP on the IBM Copy File (CPYF) command. If *MAP/*DROP fails, the request status is set to Move-Fail.

In the rare case where a field has been changed from numeric to alphanumeric or vice versa, the Copy File (CPYF) command is not able to retain the data correctly.

In this case, you should promote the physical file in two steps:

1 Remove the field and promote the physical file.

2 On a second promotion request, add the field back to the file (with the changed field attributes).

This approach allows data to be retained in all fields, except for the field that was changed from numeric to alphanumeric (or vice versa).

Physical File Data

Implementer provides the object code PF to promote physical files when you have changed the source members. However, other object codes also affect physical files.

To promote or change the contents of a physical file, use the PFDTA object code. At check out, this object code copies the records in the database to the development library. When you create a promotion request, the data in the development or test library is copied to the target library, but the physical file is not compiled.

If you have added or changed records in a file and changed the source (added, changed, or deleted fields), promote that physical file with both the PF and PFDTA object codes.


Database Management

Changing Members

You can add or change members with the object codes delivered with Implementer. To change a physical file member, use the CHGPFM object code. To add a member to a physical file, use ADDPFM object code.

Journaling Files

When a database file promotion is optimized, existing journals are retained for journaled files. While Implementer does not explicitly require or perform journal management, a function of the CHGPF command stops and re-starts the journals for journaled files.

When optimize is not used, journals are automatically removed and reapplied for journaled physical files, using a technique compatible with MIMIX users. MIMIX is a software product from Lakeview Technologies that provides concurrent updates of database files on two different systems.

To start journaling on a new database file or an existing database file that is currently not journaled, use the special commands feature when creating the promotion request. Typically, you need to use the following commands: Create Journal Receiver (CRTJRNRCV), Create Journal (CRTJRN), and Start Journal Access Path (STRJRNAP).

Reference Files

To ensure field reference files are compiled before other physical files, use the PFREF object code to promote field reference files.

Conversion Programs

If you required conversion programs, you can run them as a special command on the promotion request. You can specify the exact command or call the program and the associated parameters as a special command, to be called at the same time as the promotion. This ensures Implementer converts the data as soon as the promotion occurs, not at some later time. The conversion programs must exist in the target environment before you can use them in a special command.

Create Physical File (CRTPF)

You should avoid changing the maximum members (MAXMBRS) parameter of the Create Physical File (CRTPF) command for the PF object code, which can result in errors during the move step. An example of this is an existing physical file that has two members, but the command creates a file with a maximum member of one.

315


In addition, you should avoid changing the file size (FILESIZE) parameter for existing objects. This can result in errors during the move step, if you change the file size to a size smaller than the existing members of the physical file.

Promoting Logical Files

Logical files, like physical files, are complex objects to promote. However, a number of features exist that help you to efficiently handle these complexities.

Promoting Logical Files

Implementer allows you to control the failure of promotions on remote systems due to logical file problems. These problems include, for example, implicitly added logical files (that cannot be recompiled), logical files that have no source, or logical files with duplicate keys.

For more information, see “Data Areas and User Exit Programs” in Appendix A of the Implementer System Administrator Guide.

This feature is enabled using data area IMWRNTRGLF. This data area allows you to control whether the promotion request fails, continues, or presents you with an error without interrupting production. In each case, detailed information about the logical files and the actions taken are written to the job log and sent to you.

Object Codes

The object code LF is provided to promote logical files when you have made source changes. However, other object codes also affect logical files.

You can add members or change them with object codes that are delivered with Implementer. To change a logical file member, use the CHGLF object code. To add a member to a logical file, use the CHGLFM object code.

Journals

When a database file promotion is optimized, existing journals are retained for journaled logical files. While Implementer does not explicitly require or perform journal management, a function of the CHGPF command stops and re-starts the journals for journaled files.

When optimize is not used, journals are automatically removed and reapplied for journaled logical files, using a technique compatible with MIMIX users. MIMIX is a software product from Lakeview Technologies that provides concurrent updates of database files on two different systems.


Database Management

To start journaling on a new database file or an existing database file that is currently not journaled, use the special commands feature when creating the promotion request. Typically, you need to use the following commands: Create Journal Receiver (CRTJRNRCV), Create Journal (CRTJRN), and Start Journal Access Path (STRJRNAP).

Join Logical Files

Implementer automatically handles all the complexities of join logical files. This includes retaining existing members and retaining members where the number of based-on physical files has been changed. When the logical file member cannot be read exactly as it existed before, the member is added with system defaults and a message is sent to notify you to review the logical file member.

Multiple Format Logical Files

Implementer fully supports multiple format logical files and supports promoting logical files based on physical files that exist in more than one library. When the physical files are in more than one library, an exclusive lock is required on the physical files used by that logical file at the time of promotion.

Auxiliary Storage Pool (ASP) Considerations

Logical files can have dependencies across different libraries, but OS/400 constraints dictate that these libraries reside in the same ASP. Normally, this is not a problem. However, let’s say you have a test library in one ASP and a production library in another ASP and you want to promote just one logical file. In this scenario, the physical file does not exist in the test library and the request fails. You must keep copies of the physical files in the test environment as well as the production environment. Most organizations keep copies of physical and logical files in both environments.

Create Logical File (CRTLF) Command

You should avoid changing the maximum members (MAXMBRS) parameter of the Create Logical File (CRTLF) command for the LF object code, which can result in errors during the move step. An example of this is an existing logical file that has two members, but at file creation you set the maximum members to one.

317


Common Questions

Does Implementer support triggers and constraints?

Yes. Implementer automatically retains in the target libraries any triggers and constraints associated with SQL table promotions and optimized PF promotions. To add or remove triggers and constraints, or to retain triggers and constraints without optimizing, use the special commands feature when creating the promotion request.

Can source-based SQL object codes be used to promote non-source-based tables?

No. Implementer requires you to promote source-based SQL tables using object codes that have a special characteristic that identifies them as source-based.

What are the basic guidelines for creating DDS files with SQL tables?

Implementer requires that a physical file created with DDS have only DDS-based logical files built over it. In other words, Implementer does not support DDS-based logical files built over SQL tables, or SQL-based logical files built over DDS-based physical files.

Special Object ConsiderationsThis section is helpful for understanding how Implementer handles various objects, and any additional member/object considerations.

Data Areas Implementer provides two object codes that can be used to set the target data area value upon promotion of the data area to the target library. A data area is a non-source-based object. Since it generally contains data for the application, by default, Implementer places the objects in the database files library.

� The DTAARA object code copies the data in the from library to the target library. It has no special requirementsy. If you want to put the object in the program library of the environment, you must change the DTAARA object code for that environment.

� The DTAARAR object code retains the existing value in the target library. It has an object type of *DTAARA and a special characteristic of *DTA. The special characteristic is significant—it controls whether the existing data area value is retained.

These data areas are helpful, for example, to use a single promotion request to deploy to multiple libraries or systems, while retaining or replacing data area values as needed. For example, this is useful for a data


Managing ILE Development

area that controls the next order number, when a new customer needs to have the data area value set to a newly distributed value, while an existing customer needs to retain the existing value.

For more information, see Chapter 3 of the Implementer System Administrator Guide.

Data Queues A data queue is a non-source-based object. The IBM Create Duplicate Object (CRTDUPOBJ) command is not valid for data queues, so when you check out this type of object, the object cannot be duplicated into the development library. Therefore, Implementer saves the original data queue in a save file, and restores the data queue to the target environment or to the library indicated on the Check Out panel. The same process is used to promote data queues.

To end journaling for a database, use the special command feature, End Journal Access Path (ENDJRNAP) command.

Commands and Programs

Implementer analyzes command and program objects, since the display commands for the objects Display Command (DSPCMD) and Display Program (DSPPGM) do not have outfile support. This analysis is done through assembler routines, and since there is no analysis of a spool file output, there is no dependency on the national language used in OS/400.

Managing ILE DevelopmentThis section explains the support Implementer provides for working in an ILE development model. There is not a single homogenous way to use the ILE capabilities of OS/400; this section addresses the most common scenarios that arise when managing ILE development with Implementer.

Implementer has a number of powerful features for handling ILE including:

� Support for all ILE creation commands.

� Support for retaining and overriding compile characteristics for all ILE objects.

� Support for Implementer impact analysis (related objects) module and service program dependencies.

319


� Support for check out and recompiling related objects.

� Support for binding directories, including the optional use of an Implementer-created binding directory.

� Support for export source.

In fact, all Implementer programs are ILE programs. Implementer also takes advantage of service programs in some it’s standard processing in areas such as TCP/IP processing.

Support for Modules

Modules are objects that essentially contain the executable code, but are not actually executable until they are bound into an ILE program or a service program.

Checking Out Modules

When you need to make a change to a module, you first check out the module, and the programs and service programs in which it is bound (referred to as related objects in Implementer). Implementer makes this easy through its support for automatically adding all related objects during check out. Since modules are bound by copy, a best practice typically involves checking out the related programs and service programs (with an action of 9=Recompile). If you do not, you will not be able to test the changes in your development libraries, since the programs and service programs must have the changed module bound before the new programs can be executed.

Although not recommended, you may also check out just the module. In this case, use the Implementer feature that adds all related objects to a promotion request. This automatically rebinds the modules to the existing programs and service programs the module is currently bound to.

Compiling From the Workbench

When you select the modules, programs, and service programs to compile, Implementer automatically compiles the modules, then the service programs, and finally the programs regardless of the order they appear on the Workbench. When rebinding the programs and service programs, Implementer uses the library list of the development environment to ensure that the correct versions of all modules are used for binding. Implementer uses the CRTPGM and CRTSRVPGM commands when rebinding.



If you need to add or remove modules from an ILE program or service program during compile, prompt option 14=Compile. The modules currently used by that program will be loaded into the creation command and qualified to a library list of *LIBL to ensure the correct versions of the modules are derived from the environment library list during compilation.

Promoting Modules

When promoting a module, you should also promote the related programs and service programs at the same time—just as you checked them out at the same time. You can also configure Implementer to automatically include them on the promotion request.

A caveat of dealing with modules is that because they are object-based, by default Implementer moves them on promotion requests. This is fine as an object moves through QA environments to the local production environment. However, if you deploy the application to remote systems it is typically undesirable to deploy the modules (and binding directories) since they are not required for execution of the application. To avoid this, MKS recommends that you deactivate the module object codes for remote environments.

Support for Service Programs

Service programs are objects that contain procedures that are bound to calling programs at run time. This is also referred to as bound by reference.

Checking Out Service Programs

When you need to make a change to a service program, you first check out the service program. You may also need to change the related programs and service programs that it is bound in, although typically only if the external exposed interfaces are changed. This includes adding or deleting modules, adding or deleting procedures within a module, or changing the parameters of a procedure in one of the modules. If only the logic of a procedure changes, you do not need to rebind the service programs. If no external changes were made, you typically do not need to check out the related programs and service programs.

When examining related objects, a more typical example is to check out for change the modules that require application logic changes, since typically this is the reason for service program being changed.

321


Creating Service Programs From the Workbench

When creating service programs, Implementer examines the service program in the development library to determine the characteristics. If the service program is not in the development library, the environment path is examined to choose the “nearest” version of the service program to base its creation on.

When selecting multiples items to compile from the Workbench, Implementer ensures all objects are compiled in the correct logical order regardless of the order they appear on the Workbench. When rebinding the programs and service programs, Implementer uses the library list of the development environment to ensure the correct version of all modules is used for binding.

If you need to add or remove modules from an ILE program or service program during compile, prompt option 14=Compile. The modules currently used by that program will be loaded into the creation command and qualified to a library list of *LIBL to ensure the correct versions of the modules are derived from the environment library list during compilation.

If you are using binding directories for the application, the binding directory can also be added to the object.

Promoting Service Programs

You should use the “from” characteristics when promoting ILE service programs. This causes the existing object in development to be examined and ensures the object is compiled with the correct characteristics.

Loading ILE Objects Into the Repository

Many of the same principles for loading objects into the Implementer repository apply to loading ILE objects.

Loading Modules

Modules are source-based objects that Implementer loads into the repository like any other source-based object. By default, they are assigned an object code of xxxMOD, where xxx is the language.

Loading ILE Programs and Bound Programs

Implementer first determines whether the ILE program is built using a CRTBNDxxx command, or if it consists of multiple modules assembled using the CRTPGM command. If the program consists of a single module, it is assigned an xxxBND object code. Otherwise, an object code of xxxILE



is assigned to the object, and the modules that are used by the program are added to the Implementer’s related object repository for use in check out and promotion.

When loading ILE programs, any modules and service programs that are bound into an ILE program are also inserted into the Implementer impact analysis repository.

Loading Service Programs

Service programs are loaded into Implementer and matched to an object code based on the object type (*SRVPGM) and object attribute.

When loading service programs, any modules and service programs that are bound to the service program are also loaded into the Implementer impact analysis repository.

Binding Directories

Binding directories are loaded into Implementer using the BNDDIR object code.

Export Source

Service Program Export Source is treated as a source only item, similar to OCL and copybooks.

Common Questions

Can Implementer help to convert an application from OPM to ILE?

Yes. For more information, see “Performing Check Out” on page 111.

How does Implementer support bound programs?

Bound programs are handled similar to traditional OPM programs, as there is one object for each source member.

How is impact analysis handled for ILE objects?

For modules, Implementer recognizes the bind by copy relationship for programs and service programs. For service programs, it recognizes the bind by reference relationship for programs and service programs. The previously listed topics on modules and service programs discuss the handling of these associations in more detail. Implementer uses it’s own repository or Hawkeye’s Pathfinder for determining these relationships.

323


Why are modules being sent to our remote systems?

By default, the Implementer promotion process sends all objects on a request to specified remote systems. This includes modules (*MODULE object type) since they are a simply an OS/400 object.

Most organizations do not need modules sent to a remote system. To avoid this, deactivate the module object codes for remote environments, in Work with Environments.

What characteristics are retained for ILE object types?

Implementer automatically retains the characteristics for ILE objects based on the creation command used to create those objects, as follows:

� Create Program (CRTPGM) command: Parameters retained from existing programs are MODULE, ENTMOD, BNDSRVPGM, ACTGRP, ALWUPD, USRPRF, and ALWRINZ.

� Create Service Program (CRTSRVPGM) command: Parameters retained from existing service programs are MODULE, BNDSRVPGM, ACTGRP, ALWUPD, USRPRF, ALWRINZ, EXPORT, and SRCFILE (export source file).

� Create Bound xxx Program (CRTBNDxxx) command: Parameters retained from existing programs are DFTACTGRP, ACTGRP, ALWUPD, USRPRF, and ALWRINZ.

In addition to the object characteristics that are automatically retained, you may also specify additional defaults using the Implementer object codes.

How does Implementer use binding directories?

Binding directories store a list of modules and service programs that are used when creating programs and service programs.

Implementer creates a binding directory for each Implementer environment (the name of the binding directory is the environment name) and stores it in the Implementer product library. At your option, you may use this Implementer-created binding directory to simplify the creation of new existing programs and service programs.

The binding directory can be added when creating an ILE program or service program from the Workbench, by prompting option 14=Compile. If you want to use the environment binding directory as a default for all compiles, change the appropriate object code creation command to include BNDDIR(#TRGENV).


S/36 Environment

S/36 EnvironmentImplementer supports all S/36 environment objects. This includes extended support for MNU36 objects. When you promote MNU36 objects, both the menu and secondary objects are promoted in tandem by one MNU36 object code. When you promote display files, use the DSPF36 object code. You can mix S/36 environment objects with other OS/400 objects on a promotion request and at check out.

S/38 EnvironmentImplementer supports all S/38 environment objects. This includes extended support for System/38 environments DFUs. When you promote System/38 DFUs, you promote both the program object and the related display files together, as defined by the DFU38 object code.

You can add S/38 environment objects with other OS/400 objects to a promotion request and at check out.

You can change System/38 environment source from System/38 to native source. When you change to native, you should check out using the native object code and type Y in the Allow type/attr chg field. By specifying Y, the edit that verifies the source type of the existing source member (and attribute of the object) is bypassed and object code expectations are matched. This field is available on the Check Out panel when you press F7=Fold. This feature is not available for the Check Out (ICHKOUT) command.

325


Extended Object SupportImplementer has a feature to ensure you promote complex objects using a single object code in the check out and promotion functions. Complex objects consist of more than one object and/or more than one source member. This eliminates confusion for you during check out and promotion of complex objects. Extended support is provided for the following types of objects:

� S/38 DFU

� S/36 menu

� Menu

� DFU

� American Software (ASI) display files

� Save files

� Data queues

� Cognos


10Integrating With Other Vendor Products

This chapter discusses the integration of Implementer with other vendor software. It explains any actions you must take to ensure maximum integration, and describes how to use the integration. Some of these products have seamless integration with Implementer. Other products require further user action to complete the integration. These products are described in the following sections.

The chapter is divided into two sections to reflect the type of software product supported:

� application and CASE software products

� utility software products

327

Integrating With Other Vendor Products

Application and CASE Software ProductsImplementer provides special features to support the check out and promotion of items built using the following products:

� American Software (ASI)

American Software (ASI) develops a portfolio of enterprise and supply chain, software applications.

� AS/SET

AS/SET is a CASE tool developed by System Software Associates (SSA) and used to develop the SSA BPCS product.

� BPCS

BPCS is an application software product from SSA.

� CODE/400

CODE/400 is a workstation-based client/server development environment, available with IBM’s WebSphereTM Development Tools for the iSeries 400. With CODE/400, you can edit, compile, and debug your client and server applications, as well as applications written in many OS/400 languages.

� COOL:2E

COOl:2E is an application development tool for the iSeries 400 developed by Computer Associates. The Implementer Adapter for COOL:Xtras Change Management (CM) is a separately licensed integration that manages changes for both COOL:2E developed applications and traditionally developed applications.

� J.D. Edwards

J.D. Edward is application software that was developed using their World Case product.

� LANSA

LANSA is a CASE tool developed by LANSA Corporation.

� Lotus Notes and Domino

Lotus Note and Domino are software applications developed by Lotus Development Corporation.

� Powerhouse

Powerhouse is a CASE tool developed by Cognos.


American Software Integration

American Software IntegrationAmerican Software, Incorporated (ASI) develops a portfolio of enterprise and supply chain software applications designed to automate planning and operational functions with leading e-business solutions, enterprise resource planning (ERP), supply chain management, flow manufacturing, warehouse management, and transportation operations.

The information provided here explains how to use Implementer with the ASI application software.

Object Codes for Check Out and Promotion

American Software uses a special command for compiling, which, among other things, merges both a base version of a source member, ASI PTFs, and customer changes into a temporary source member and then compiles that source member.

In order to automate ASI change management in Implementer, ASI-specific objects are used in place of the standard object codes for:

For information on object code requirements, see Chapter 5 of the Implementer System Administrator Guide.

� CBL (Cobol Programs)

� CLP (Control Language Programs)

� DSPF (Display Files)

� PRTF (External Printer Files)

� LF (Logical Files)

� PF (Physical Files)

NOTE

The standard object codes (such as CBL and RPG) should be disallowed in each environment.

To perform ASI compiles within Implementer, you need to check out and promote ASI member/objects using the ASI-specific object codes. These object codes use the Put Create Object (PUTCRTOBJ) command.

The PUTCRTOBJ command requires that the three source files used be in the same library. These source files are typically:

� QCBLSRC (unmodified current release)

� TCBLSRC (PTFs to current release)

329


� UCBLSRC (customer changes to current release)

The library you are developing changes in (in source file UCBLSRC source members) must have a copy of the TCBLSRC source file and the QCBLSRC source file in the same library as your UCBLSRC.

� The library list for the environment must be the same as the library list in the ASICOMPILE job description. In addition, the libraries must be in the same order.

Compiling Cobol Programs

To compile an ASI Cobol within Implementer, use a specific ASI Cobol object code, for example, CBLASI.

The object code controls, among other things, how objects are compiled. Instead of calling the standard IBM Create Cobol Program (CRTCBLPGM) command, the CBLASI object code (with a source member type of TXT and special characteristic of ASICBL) calls the ASI command that merges and then compiles Cobol source code. An example of the creation command is:

ASIUTILIB/PUTCRTOBJ OBJ(#PGMLIB/#OBJECT) SRCMBR(#OBJECT) SRCFL(#SRCLIB/QCBLSRC) OBJTYPE(CBL) PRMSRCFL(QCBLSRC)

Message File Considerations

The following information relates to possible problems encountered with message files.

AS/SET IntegrationAS/SET is a CASE tool developed by System Software Associates (SSA) and used to develop the SSA BPCS product.

The Implementer Adapter for AS/SET independently manages AS/SET definitions and generated traditional objects. You can check out AS/SET definitions, make modifications, promote them into QA/production, and complete the cycle. Implementer automatically takes care of locking the definitions, checking them in by promoting them in a controlled fashion.

Problem Resolution

Source mismatch Change source member type to TXT.

Checked out QSRC instead of USRC

Default source file must be USRCxxx.

TSRC and USRC not copied Object type special characteristics not entered.


AS/SET Integration

Implementer maintains an audit trail of all activities on the definitions and all existing inquiries and reports include the AS/SET definitions and generated objects managed.

Specific commands copy, delete, and verify existence of AS/SET definitions from within Implementer, which uses these functions to manage definitions. They can be used as standalone commands as well.

Checking Out AS/SET Definitions

� AS/SET definitions and generated traditional source and objects can be checked out as defined in the manuals. All the required objects can however, be checked out along with the definitions in order to have them locked. Locks are created for all the definitions and the required objects that are being checked out.

� AS/SET definitions must be checked out from a specified AS/SET environment that is defined in Work with Environments by associating an application set to a standard environment in order to create a special AS/SET environment.

� AS/SET definitions cannot be checked out to a library.

� AS/SET definitions must be checked out using the specific object codes that are defined with special characteristics starting with ADK.

� AS/SET definitions that are specified with one of the ADK object codes can only be copied from an environment defined as an AS/SET environment.

� AS/SET definitions can be checked out using the Check Out (ICHKOUT) command.

� Use the Check ADK Dependencies (ICHKADKDEP) command when checking out AS/SET objects. This command checks for AS/SET object dependencies on any ADK items. The Check Out Related Objects function does not support related objects (generated) for AS/SET definitions.

� If you check out an AS/SET display program with the associated help, it is necessary to check out the definition and help separately as two objects with the same name. One of the objects must use the object code with the special characteristic of ADKDSP for the display program. The other object must use a separate object code created with the special characteristic ADKHLP, to check out the help text associated with the display program.

� When you use the AS/SET object codes (for example, RPT) at check out, the AS/SET definition is copied from the production application set to the development application set. If you want the associated

331


OS/400 source to be checked out, use the RPG, DSPF, and PRTF object codes to check out the related source members for the AS/SET definition.

AS/SET Dependency Checking

The Check ADK Dependencies (ICHKADKDEP) command checks for AS/SET object dependencies of any ADK items during check out.

The requirements for this feature include defining the library list of the Implementer job description, and defining a special command for the development environment.

There are no setup requirements within the AS/SET for this feature.

To define the job description library list

1 On the command line, type the following command and press F4=Prompt.

CHGJOBD JOBD(MWIOBJD)

2 Define the Library parameter. This is the library where the job description exists (MKSIM is the default).

3 Define the Library List parameters as follows, and press ENTER:

� The AS/SET object library (ASSETO is the default) must appear before the AS/SET file library (ASETF is the default).

� Both the ASSET object library and file library must be positioned before the Implementer library.

� QTEMP library must appear (in any position) on the library list.

To define the development environment special command

1 From menu option 42, Work with Environments, select the *TST environment with option 19=Special commands.

2 The Work with Environment Special Commands panel displays.

(Previously defined special commands may display on this panel.) Press F6=Add to display the Expanded Command Display panel.


AS/SET Integration

3 Define the special command as follows, and press ENTER.

To use AS/SET dependency checking

1 In Check out, press F9=Accept to check out the member/object.

If a dependency is detected during the check out, a message displays. For example, “Dependent Object Detected, AS/SET object TEST1 (ADKDSP) is dependent on object TESTF1 (MDL) for

successful re-generation.”

2 You can press F2 to display the second level text. Reply with one of the following options, and press ENTER. (The reply options are valid for both first level and second level messages.)

During the check out process, messages are logged to the job log indicating what action was taken by the check out program. As with all Implementer messages, the text can be customized by maintaining a message file. For more information on maintaining messages files, see“Problem Determination” on page 253.

Environment (environment name)

For Action 6

When to do 2

Sequence number 10.0

Command ICHKADKDEP MBROBJ(#OBJECT)OBJCODE(#OBJCOD)FRMENV(#FRMENV)TOENV(#TRGENV)

Option Description

I Ignore this dependency and continue checking.

N Ignore this and all subsequent dependencies.

C Copy this dependent object to the target environment and continue checking.

A Copy this and all subsequent dependencies to the target environment.

333


Promoting AS/SET Definitions

� AS/SET definition promotions (using an object code that contains an ADK special characteristic) require that the from and target environments be defined as an AS/SET environment.

� AS/SET definitions must be promoted from a specifically defined AS/SET environment. The definitions on the request and the environments are edited for validity.

� AS/SET definitions cannot be promoted from a library.

� AS/SET definitions must be promoted to specifically defined AS/SET environments. (Defined in Work with Environments by associating an application set to a standard environment in order to create a special AS/SET environment.)

� AS/SET definitions can be promoted to multiple target environments or an environment group provided the primary environment is an AS/SET environment. If non-AS/SET environments exist in the target environment group or list, AS/SET definitions are not promoted to these environments although the promotion will occur to the AS/SET environments in the group or list. Multiple target environments can be established in the Work with Environments, Create Request, Compile Request, and Move Request functions.

� AS/SET definitions cannot be distributed to remote locations.

� When creating a promotion request, AS/SET must be included in your library list, but you should not be in the AS/SET product. If you are in it, and you are promoting from a different application set than that which you are in, generated objects will not be added to the request.

� If you are promoting an AS/SET display program with the associated help, it is necessary to promote the definition and help separately as two objects with the same name. One of the objects must use an object code with the special characteristic of ADKDSP for the display program. The other object must use a separate object code created with the special characteristic ADKHLP to promote the help text associated with the display program.

� If you are overriding defaults, the remove member from library/environment flag can be used for AS/SET definitions.

� The source and object are moved from the From environment if the request specifies No to compile.

� At promotion time, the names of the required objects are automatically copied into the target application set for the display, report, and batch program definitions. To actually promote the required objects, you must promote the required objects individually


AS/SET Integration

with the appropriate object codes, or use the Add Related Objects feature to automatically include the generated objects for the definitions on the request.

� When you use the AS/SET object codes (for example, RPT) at promotion, the AS/SET definition is copied to the target application set. If you want the associated OS/400 source to be promoted, use the RPG, DSPF, and PRTF object codes, or use the Add Related Objects feature to include the generated objects for the AS/SET definition on the promotion request.

� The Create Request (ICRTRQS) command does not support AS/SET definitions.

� If you manage AS/SET generated RPG programs having X FILE overrides, use an object code that has the special characteristic of RPGADK in order to compile these programs during promotion. Implementer automatically analyzes these programs and performs the appropriate X FILE overrides before compilation. If the original file name contains ten characters, thus not allowing an X at the end of the X FILE name, the overridden file cannot be identified. Therefore, MKS suggests using file names contain less than ten characters.

AS/SET Commands

Archiving AS/SET Definitions

After defining an archive application set for an AS/SET environment, the AS/SET definitions are automatically archived whenever you promote to the environment.

Remote Distribution

The Implementer Receiver does not support AS/SET definitions; however, it does receive the generated objects.

Command Definition

Delete AS/SET definition (IDELADKDFN)

Deletes an AS/SET definition from a given application set.

Copy AS/SET definition (ICPYADKDFN)

Copies an AS/SET definition from one application set to another, with the facility to optionally replace it in the from or target application set, if it already exists.

Retrieve AS/SET definition (IRTVADKDFN)

Verifies an AS/SET definition exists and retrieves the description.

335


Overriding Promotion of Generated Objects

You can easily override the default settings pertaining to the promotion of AS/SET-generated source and objects at the time you issue the promotion request.

To override the default settings

1 From the Implementer Menu, select option 3, Create Request, to display the Create Request panel.

2 Press F18=Overrides to display the Create Request Overrides panel.

3 Complete the Add ADK required objects field with one of the following values. The field defaults to the value defined in the environment definition.

BPCS IntegrationBPCS is an application software product from SSA. BPCS compiles are fully supported within Implementer. Keep in mind, however, that the compile step requires that the program or command used for compilation be issued within the Implementer submitted compile job. For this reason, BPCS compiles are performed using the BPCS programs that are submitted by the BPCS compile commands, not by the command itself.

Your Implementer System Administrator is responsible for setting up the appropriate object codes to ensure that BPCS compiles are handled correctly. No additional action is required by the developer to use the BPCS interface.

For instructions on compiling BPCS with Implementer, see “Third-Party Compile Procedures” on page 223.

Value Description

0 Does not add generated objects to the promotion request.

1 Adds only generated objects to the promotion request.

2 Adds both generated source and objects to the promotion request.


CODE/400 Integration

CODE/400 Integration CODE/400 (CoOperative Development Environment/400) is a workstation-based client/server development environment, available with IBM’s WebSphereTM Development Tools for the iSeries 400.

With CODE/400, you can edit, compile, and debug your client and server applications, as well as applications written in many OS/400 languages.

Implementer provides integration into CODE/400 to offer a Windows-based version of the classic host tools SEU, SDA, RLU, and PDM. This integration provides seamless access to your iSeries source and objects, and offers efficient development of your ILE RPG, ILE COBOL, ILE CL, ILE C, ILE C++, database description specifications (DDS), and Java applications.

The CODE/400 tools are invoked from the Workbench using the PDM User-Defined Options function. Options are available for browsing, editing, and designing source members.

IMPORTANT

The CODE/400 integration described herein requires that CODE/400 is already set up and running successfully within your organization.

Creating the User-Defined Options

Once you have CODE/400 set up and running successfully, access PDM to create the user-defined options that will access CODE/400 from the Workbench. For example, to invoke CODE/400 to edit a source member, create an option defined with the following command syntax:

Call qcode/evfcfdbk parm('37' 'Y' 'OS400' '<LOCAL> CODEEDIT "<OS400>&L/&F (&N)"')

Where:

Value Description

37 The coded character set identifier (CCSID) to use to send information to the desktop.

Y Specify Y to display a message or N to not display messages.

OS400 Specify the name of the server to log messages in the command shell. If you do not have the OS/400 server defined, you may get an error in the command shell.

<LOCAL> Specify a server name. You can specify <> (empty brackets) to use the first active CODE/400 server.

337


Launching CODE/400 from Implementer

The CODE/400 tools are invoked from the Workbench using the PDM User-Defined Options function.

To launch CODE/400 from the Workbench

� From the Workbench, select a member/object with the PDM option that corresponds to the CODE/400 function you want to perform, and press ENTER to launch CODE/400.

NOTE

If you do not know the PDM option name, from the Workbench press F16=User Options to display the PDM User Defined Options window and browse the PDM database to select the required option name.

COOL:Xtras Change Management Integration

The Implementer Adapter for COOL:Xtras CM is a separately licensed product that provides change control for COOL:2E developed applications and traditionally developed (3GL) applications.

The primary difference between Implementer and COOL:Xtras CM integrated with COOL:2E is that with COOL:2E programmers can create locks without accessing traditional COOL:2E screens. This minimizes the impact on the normal COOL:2E workflow.

CODEEDIT Specifies the command to run on the desktop (indicated by <LOCAL>). The command must be enclosed in double quotes. The command options are:

� CODEBRWS to browse

� CODEEDIT to edit

� CODEDSU to design (screens)

"<>&L/&F (&N)" &L is the library.&F is the source file.&N is the member name.There must be a blank space between &F and (&N) or the source file will not be substituted correctly.

Value Description



This section explains the change management features of Implementer for COOL:2E. It includes basic concepts, as well as detailed information about checking out and promoting COOL:2E developed applications.

Basic Concepts You must know a few basic concepts to understand how change management occurs for COOL:2E developed applications. These concepts are described briefly here and expanded upon later.

Change Controlled Models

The processes for enabling a model for change control differ for pre-existing models as opposed to newly created models. For newly created models, the process is as simple as creating the model with the Create Model Library (YCRTMDLLIB) command, specifying the Implementer product library (Y2SYCM or MKSIR) in the change control parameter (CHTCTL).

For established COOL:2E models, it is necessary to initialize the version type of all model objects. To accomplish this, various tools are available for analysis and modification, such as the Start Change Control (YSTRCHGCTL) and Associate Production Model (YASCPRDMDL) commands. In addition, you must define the model to Implementer as a COOL:2E environment. Enter a model library name on the COOL:2E options panel, accessible using option 10 from the Work with Environments panel.

The following examples help to clarify these concepts.

Example 1

Your site has existing development and production models and you want to implement change control.

1 Start Change Control (YSTRCHGCTL) command

If your production model is closely synchronized to the changes in development, you can achieve implementation most easily by using the YSTRCHGCTL command. You need to specify the set version type (SETVSNTYP) parameter (the parameter values are available in the command help text). The most sophisticated value for this parameter is *ASSOC, which invokes the Associate Production Model (YASCPRDMDL) command, described next.

2 Associate Production Model (YASCPRDMDL) command

The YASCPRDMDL command compares objects between two models. It matches objects by owner name, object type, and copy name in the development (source) model with the owner name, object type, and

339


object name in the target model. If a match is found, the object in the development model is set to a production version.

The production model defined to the YASCPRDMDL command should ideally be the related production environment you define in the COOL:2E environment setup. If you do not have a production model, you can use a QA model instead.

For this approach to be effective, you must achieve development cutoff of all changes, both functional and database. If functional cutoff is not an option, database cutoff is a minimum requirement to obtain a predictable result.

You should note how objects are identified between the two models. For non-versionable objects, matching is straightforward because of the one-to-one relationship.

For versionable objects such as functions, a more arbitrary pairing method could cause some unexpected results. The program reads all model objects in development by Owner/Type/Name order. If a match is found in the target model, the program attempts to make the object production (if it isn’t that already). If any other version in the group is production, the attempt fails, the information is written to a report, and processing continues. This result is the first version in a group, alphabetically, is set to production.

If the wrong version is flagged as the production version, you have to make manual changes. Use the Associate Production Model Report to identify which objects need correction. For each object, change the version that was set by the YASCPRDMDL command to development, and set the version to production. (The Work with Versions (YWRKVSN) and Change Model Object (YCHGMDLOBJ) commands can be useful.)

Example 2

Your site has a development model and traditional production library, and you want to implement change control and establish a production model.

1 If the production library in your existing system was generated from your development model you have two options: You can define a separate environment for the existing 3GL production library or you can create a new model library and define its generation library as the existing 3GL production library. Either solution will work, but the first solution carries overhead of both extra promotion steps and extra disk space requirements.



2 For either situation, you have to identify the objects in development that constitute the objects in production. If you already have Implementer as your change control system, this is not necessary since the production version types will already be set.

To identify the production objects in your existing development model, either:

� Use the Start Change Control (YSTRCHGCTL) command, particularly if your existing promotion system places permanent locks on those objects promoted to production (set the version type to *BYLOCK), or

� If the production flags are not established, follow these steps:

3 Issue the YBLDMDLLST command to create a model list of all non-versionable objects in the model, in other words, exclude functions and messages. Do not include Implementer-supplied objects.

4 Issue the Execute Model Object List (YEXCMDLLST) command to call Change Model Object (YCHGMDLOBJ) for each list entry, and change the version type of the objects to production (*PRD).

5 Create a model list of all functions and messages, excluding those supplied by COOL:2E (versionable objects). For each object, include only the version in production; do not include more than one version for a group, as this will cause an error in the next step.

6 Issue the YEXCMDLLST command as before for the non-versionable objects. (If you attempt to set more than one version in a group to production, an error occurs.)

7 Establish that all of the objects flagged as production are the current versions for their groups.

� To create a list of all objects in the model, issue the following command:

YBLDMDLLST MDLLST(PRDLST)CUROBJ(*NO)

� To remove all objects that are current or a development version type, issue the following command:

YFLTMDLLST MDLLST(PRDLST)OUTLST(PRDLST)

CUROBJ(*NO)

VSNTYP(*PRD)

OUTFLAGVAL(*SELECTED)

� To return all of the objects on the list to a current status, issue the following command:

341


YEXCMDLLST MDLLST(PRDLST)RQSDTA('YRDRMDLOBJ)

FRMOBJNAM(*CURRENT)

TOOBJSGT(&Y@)

TFRNAM(*NO)')

FLAGVAL(*SELECTED)

8 With all of the production objects in your development model correctly established, you are ready for the final step the creation of the production model objects.

To populate the production model, issue the Copy Model Object (YCPYMDLOBJ) command. If you ran YSTRCHGCTL as instructed in Step 2, or if Implementer is active for the development or production model, disable it by setting the YCHGCTL model value to *NONE.

Build a model list of all production objects in the development model, and, using the Copy Model Object (YCPYMDLOBJ) command, copy that list to the new production model.

Re-establish Implementer by setting the YCHGCTL model value to the name of your Implementer product library in the development and production models.

Model Object Lists

Model object lists are a COOL:2E feature used for change control purposes within Implementer. When you check out a model object, you must check out to a model object list. A model object list represents one logical change. When you create a promotion request from a COOL:2E environment, you select only one model object list to associate with that promotion request.

Check Out

Check out is required when you attempt to change or delete an existing model object or create a new model object. By logging the change of the model object, it ensures Implementer knows what to promote when the change is complete. Check out can occur implicitly when you change a model object or you can explicitly check out an object before making any changes.



Model Object Types

The model objects types managed by Implementer include the following:

Each object type can be checked out and promoted. When these model objects are promoted, their associated implementation objects are promoted as well.

The function (FUN) and messages (MSG) model object types are versionable.

This allows two users to check out and change different versions of the same model object. The ability to do this is referred to as concurrent development.

Model Object Lists

Model object lists are used by Implementer to control the check out and promotion of model objects. They are also used in Archive Recovery.

Model object lists allow you to create a named list that contains a subset of model objects in the model. These lists make it easier to perform change control tasks. For example, to edit a model you can edit one or more model object lists. This feature is particularly useful for large models.

Each reference to a model object on a model object list is called a model list entry. A model object can be included on an unlimited number of model object lists; however, a model object can be checked out to only one model object list at a time.

The following diagram illustrates the model object list and its relation to the COOL:2E model:

Type Definition

ACP Access path

APP Application area

ARR Array

CND Condition

FIL File

FLD Field

FUN Function (versionable)

MSG Message (versionable)

343


Change List

Implementer uses model object lists for change control purposes. When a model object list is used by Implementer, it is referred to as a change list. Model object lists created outside of Implementer cannot be used for change control purposes. You can only use a model object list in promotion if at least one model object is checked out to that model object list. A model object list can be created when checking out a model object, or prior to check out (in Work with Environments).

NOTE

It is not advisable to check out model objects to the COOL:2E session model list specified in your COOL:2E model profile. If you do, it will not be used as a change list. For detailed information about session lists, see the COOL:2E manuals Getting Started and Generating and Implementing Applications.

Change lists are secured by Implementer to specific user profiles or user profile groups. This allows you to control which users are allowed to work on specific changes. When you initially create a change list, only the user who created the list can use it. You can grant additional rights to the list in Work with Environments.

Once you successfully promote the list, it is protected by Implementer. After promotion, old lists that are not needed for archiving can be cleaned up (Archive Recovery is available if you choose to rollback a versionable model object).

MSG EFUN H

List *ALLOBJ

CND C

FIL BCND CFLD GACP D

FIL BCND CFLD GACP D

List P List QMSG EFUN HCND C

List AOBJ A

CND C

MSG EFIL B

FLD G

ACP D

APP FFUN H



To delete a list, first remove it from Implementer in Work with Model Object Lists for the environment (option 10 for the COOL:2E environment, then press F19). Use option 4 to remove any unwanted lists that have a status of Completed. After a list is removed from Implementer, it can be deleted from the model in Work with Model Lists.

Development Activities

In traditional development, activity occurs on individual discrete source members and OS/400 objects. In contrast, in COOL:2E development, all changes occur during model sessions to model objects. You do not check out and promote discrete OS/400 members/objects. Instead, you check out and promote model objects.

COOL:2E automatically manages the impact of a change on other model objects at the time the change is made.

Member/Object Naming

You can recognize COOL:2E model objects by a 25-character name, and optionally, for some object types, a model objects owner. 3GL objects and source members have 10 character names. Most of the panels in Implementer assume a 10-character name with 50 characters of descriptive text. For model objects, the model object name is stored in those 50 characters of the description. The 10 character names contain the model objects’ surrogate number (internal identifier) prefixed with Y.

SQL Support for COOL:2E

Implementer supports the SQL-related generation options available in COOL:2E 7.0. This includes the creation of SQL tables, SQL indices, and SQL views, and the corresponding functions that create RPG SQL and COBOL programs.

When creating a promotion request, Implementer recognizes these SQL types of generated objects and assigns the appropriate object code when determining the implementation objects to add to the promotion request.

This feature capitalizes on SQL-specific object codes that are already delivered with Implementer.

Managing SQL Files, Indices, and Views

For managing COOL:2E SQL files, indices, and views, Implementer uses the YSQLPF and YSQLLF objects codes.

In a COOL:2E model, these member/objects have different model object attributes; although, they share the same:

� source member type (YSQL)

� source file (QSQLSRC)

� creation command (YEXCSQL)

345


For YFIL model objects being generated as SQL, Implementer uses the object code YSQLPF for the associated implementation object. For YACP model objects being generated as SQL, Implementer uses the object code YSQLLF for the associated implementation object.

Managing SQL Functions

For managing COOL:2E SQL functions, Implementer supports the use of the RPGSQL and RPGCBL object codes. These object codes are shipped with Implementer.

In a COOL:2E model, an SQL function created over an SQL file has an object attribute of RPG or CBL. Based on the type of function, it is further created with:

� source member type of SQLRPG or SQLCBL

� source file of QRPGSRC or QCBLSRC

� creation command of CRTSQLRPG or CRTSQLCBL

By using the SQL-specific object codes to check out an SQL function, Implementer can assign the appropriate program type object code to the lock.

When you create the promotion request, Implementer adds the model objects to the promotion request for each model object using a YFUN code, and adds the corresponding 3GL objects, including the programs, with an object code of RPGSQL or CBLSQL.

NOTE

For information about the object code setup requirements, see “COOL:2E Integration” in Chapter 5 of the Implementer System Administrator Guide. If the parameter sequences of the creation commands are not defined as required, it may cause extraneous messages to appear in your job log.

Check Out Status

When editing the COOL:2E model using the Edit Model List (YEDTMDLLST) command, a check out status displays with the check out information. The check out status changes automatically when an object is



checked out, when a conflict is created, when a conflict is manually resolved, and when the model object is promoted back to Implementer. The check out status and descriptions are as follows:

Working With Model Object Lists

There are a number of COOL:2E commands that you can use to manipulate model object lists. Some list commands and their features are restricted to change lists, which ensures that all changes to model objects are known to Implementer. These model object list commands are described in the COOL:2E Command Reference Manual.

Checking Out Model Objects

Model object check out is required to create, edit, or delete a COOL:2E model object. This approach integrates the check out procedure into the normal workflow of a COOL:2E developer. You do not use traditional check out facilities for checking out model objects.

Regardless of how you check out an object, a Check Out panel displays to allow you to confirm the check out. You may not want to display this panel each time, particularly when you want to create many new model objects during one session. In this case, on the Model Object Check Out panel press F16 to bypass this panel for the rest of the session.

Status Description

Blanks Indicates a model object is not currently checked out. After a model object is promoted back to the production environment it was checked out from, the status is set to blanks.

*CHECKOUT Indicates a model object is checked out with an action of 1=Change or 2=Create. This object is not in conflict with other locks.

*REGEN Indicates a model object is checked out with an action of 8=Regen. *REGEN locks never change to a status of *CONFLICT or *RESOLVED.

*CONFLICT Indicates a model object is checked out with an action of 1=Change or 2=Create. This object is currently in conflict with other locks. Once these locks are resolved the status changes to *RESOLVED.

*RESOLVED Indicates a model object is checked out with an action of 1=Change or 2=Create. This object was, at one time, in conflict with other locks; however, the conflict no longer exists.

347


Checking Out for Change

You can check out an existing model object either explicitly or implicitly. You explicitly check out a model object before changing a model object. A project leader who assigns model objects to different developers might perform this. You perform explicit check out with the Edit Model Object List (YEDTMDLLST) command using the check out option.

Implicit check out occurs when you attempt to change a model object that is not checked out. This happens if you zoom into an object with the Z option from a COOL:2E panel. However, not all Z options attempt a check out since some model objects may not have any requested changes.

Checking Out for Create

When creating a new model object, a check out panel displays similar to the check out panel that displays when implicitly checking out existing objects.

Checking Out for Delete

Check out for delete allows you to check out and lock any model object before it is deleted. A model object must be checked out before it can be deleted. When the model object is checked out, a lock is placed on it and it is deleted from the model. Nothing is added to the model object list.

You must have all rights (A) to that type of model object. These rights are defined in the User Capabilities panel when maintaining an environment or user.

Checking Out for Regeneration

You can check out a model object for regeneration only. These objects have a check out action of Regen. They do not have versions created and are not copied to the target model when the model object list is promoted (the compile step regenerates the original object in the production model).

Model objects can be implicitly checked out for regeneration when an unlocked model object is checked out. You can also explicitly check out for regeneration from the Check Out panel.

For functions, the production version can be checked out with an action of Regen. Since there is only one production version, there can be only one version of an object checked out for regeneration at any one time. Furthermore, since a regeneration lock implies that the definition of the object itself is not changing, concurrent development processing ignores



regeneration locks. For example, regeneration locks do not cause a conflict. If an object is checked out for regeneration, that regeneration is never in conflict with another lock.

You must have edit rights (E) to that type of model object. These rights are defined in the User Capabilities panel when maintaining an environment or user.


Implementer allows you to work on multiple copies of the same model object for the versionable model objects FUN and MSG. You can restrict the ability to have multiple versions of a model object checked out to specific users for each model. Concurrent development is detected when you attempt to edit a model object already checked out to a different user, or check out a model object that is already checked out.

When concurrent development is detected, a panel displays listing all versions of the model object. This panel allows you to select an unlocked version for check out or to override the check out of a version that is already checked out.

� If you select a version that is not checked out, the standard model object check out panel displays. The version you check out can be a production version, archive version, or an un-checked out development version. When you select a production or archive version, a new development version of the model object is created. If you select an un-checked out development version, that specific development version is checked out.

� If you select a development version that is already checked out, a panel displays allowing you to override the model object to a different model object list and project. When you press ENTER on this panel, the model object is checked out to you; it is no longer checked out to the user who previously had it checked out. This allows you to work on a model object that was previously checked out to a different user. You can override the check out to yourself only if you have lock maintenance rights for the environment of the model. You can also display the model object from this panel.

Checking Out Versionable Model Objects

When checking out a version of the object, you have the option to rename the model object and make the model object being checked out current. For a complete description of the term current model object, see “Glossary” on page 413, or the COOL:2E Generating and Implementing Applications manual.

A version of a model object is created during check out when:

� The model object is not already checked out to the developer attempting to edit it.

349


� The model object is already checked out and the selected version to check out is either: the development version, a production version that is already checked out, or an archived version.

The version of the model object being checked out can optionally be made current. The current model object is the version that you can view or edit in the COOL:2E model. Non-current versions can only be worked with from the Work with Versions panel, or when editing a specific model object list that contains the non-current version. Multiple versions of the model object can be checked out to and accessible from one or more model object lists; however, only the current version displays in the model. All checked out model objects that are on a model list must be current to promote that list.

Check Out Action

A check out action is assigned when a model object is checked out. This action displays whenever you display the lock information for a checked out model object. In addition, it is used as the promotion action for the model object. The following actions are valid for model objects:

User Exit Program Option

Implementer provides a user exit program called IMCMEX01. Use this program to:

� Maintain an external repository of model object information.

You may want to retain an audit trail of model objects accessed by developers; this program provides an ideal way to maintain an external database.

� Perform additional validation.

Using the exit program to perform additional validation for which the developer is authorized (such as object level authority) is useful since Implementer provides authority at the object type level. By placing additional user-defined validation in the IMCMEX01 program, developers can obtain authority checking at the object level. This can

Action Description

1=Change Assigned when an existing model object is changed or explicitly checked out.

2=Create Assigned when a new model object is created.

3=Delete Assigned when an existing model object is deleted.

8=Regen Assigned when an existing model object that is not checked out is generated, or by specifying regeneration only when checking out a model object.



be accomplished, for example, by maintaining a file of objects that are identified by object surrogate number in a user maintained database accessed by the exit program.

The return code from this exit program can be one of the following:

The return code has a value passed into the program, since the program is invoked at the end of Implementer validation. You cannot raise the access mode for the user exit program; in other words, you cannot switch from *VIEW to *EDIT.

Source for this program is shipped in file QSAMPLE in the Implementer library. This program is called from the User Object Access exit program whenever a developer attempts to access a feature of COOL:2E (for example, to view all functions or to edit an access path). Implementer calls IMCMEX01 at the end of the validation section so you can perform the additional validations.

Promoting Model Information

Implementer promotes both model information and OS/400 source and objects. The model information is promoted prior to the compile step in the model copy step.

The model copy step uses the COOL:2E Copy Model Objects (YCPYMDLOBJ) command to copy between the from and target environment. It uses a model object list to drive the promotion.

You can change the command default parameters in the COOL:2E product library. The only parameter values that Implementer overrides is Copy CPF Name (CPYVNM) *YES and Copy Conditions (CPYCND) to *SELECTED.

Promotion Flow: COOL:2E to COOL:2E Environment

Promotion to a COOL:2E environment differs from promotion to a traditional environment. Because there is a target model to update, there is a model copy step and the compile step performs COOL:2E generations.

Creating a Request

To promote changes from a COOL:2E environment, from the Create Request menu option in Implementer create a promotion request and select a model object list. Each promotion request can only promote a single model object list. This can affect how you create model object lists,

*EDIT The developer can perform the edit action.

*VIEW The developer can view the COOL:2E model object.

*NOAUT The developer does not have authority to perform the action.

351


and affect what you check out to them. In general, the model object list should contain a single logical change or multiple logical changes that are grouped together due to dependencies between the changes.

Once a model object list is selected, you can designate other characteristics that determine how this promotion request should be handled.

You can interactively and automatically add the implementation objects for the model objects to review what is added to the request prior to request creation, or you can derive the implementation objects in batch after the request is created.

Analyzing the Model List

After you create the request, you should analyze the model object list you want to promote. MKS recommends this optional step to ensure that you understand the impact of the promotion. The analysis issues the Copy Model Object (YCPYMDLOBJ) command with the parameter CPYOPT(*PREPASS), and the Promote Model Object List (YPRMMDLLST) command with parameter ACTION(*PREPASS). To run the analysis, from the Compile Requests panel use option 7=Analyze. Note that the Copy Model Object (YCPYMDLOBJ) command generates only when the promotion request targets a COOL:2E environment.

If you have not associated the model object list with a promotion request, use the COOL:2E Analyze Model Object List (YANZMDLLST) command to analyze the model object list.

Updating the Target Model With Model Copy

After you review the resulting reports and decide to continue, perform the model copy step (YCPYMDLOBJ). This step updates the model objects in the target model, and prepares the model for the generation and compile in the next step. This step is initiated by the Compile Request option from the Implementer menu. If you requested the target model to be saved, the model library is saved to a save file prior to the copy.

You can continue to work in the source model during the model copy step but you cannot work in the target model.

The Save Model option dramatically increases the model copy step processing time. In addition, the save file is not automatically deleted at the completion of the model copy; you must manually delete it. The file is stored in a save file called ImrrrreeeM, in a library of the same name.



Where IMrrrreeeM is as follows:

Promotion of Renamed Objects

This feature renames model objects in a source model to reflect in target models after running the Copy Model Objects (YCPYMDLOBJ) command.

When copying model objects between models, model objects in a target model are identified by matching the copy name of the model object in the source model with the copy name of the model object in the target model. If the model object was renamed in the source model, the model object will be renamed in the target model during the copy process.

In release 6.0 and later, COOL:2E ensures that only selected conditions are promoted. Implementer uses the YCPYMDLOBJ Copy Conditions (CPYCND) parameter value of *SELECTED to accomplish this.

Generating and Compiling

This step is initiated by the Compile Request option from the Implementer Menu. It generates the source and compiles the appropriate objects on the request. The model objects are not regenerated or recompiled in the target model if the Compile required field is set to N for the environment.

Implementer generations and compilations are processed by the COOL:2E Submit Model Create (YSBMMDLCRT) command.

Verification of the success or failure of this step is performed by the Check Model Creates (YCHKMDLCRT) command, in a separate batch job scheduled to run after the generation and compile jobs complete. If you move the generation and compile jobs to another job queue, you must also move the job that verifies compile completion. The name of this job is CMPCHK9999, where 9999 is the request number.

Setting the Objects Created First Option

When creating a promotion request, on the COOL:2E Overrides panel the setting of the Objects Created First option depends on the contents of the request, as follows:

ppp Work library prefix. The default is M, but you can reset it in data area IMPRFX. Values can be different on the host and each remote system.

rrrr Promotion request number.

eee Environment ID number (the sequence number of the environment on the request as established in target environments or environment groups).

M Model.

353


� If the request contains assimilated files and functions defined in COOL:2E based over that file, set the Objects created first option to 1, to create traditional objects first.

� If the request contains a user program that references a COOL:2E file, set the Objects created first option to 2, to create the COOL:2E objects first.

Avoid having both of these situations on the same request.

Move Step

This step updates the implementation objects in the target library. The objects and source are moved into the libraries specified for the environment. The generation library of the target model is not used. This allows the OS/400 source members and objects to reside in different libraries; different types of objects can reside in multiple libraries as well.

The original model is updated in this step by the Promote Model List (YPRMMDLLST) command. The version type is changed for all model objects from development (DEV) to production (PRD). For versionable object types, the existing PRD version of that model object group is changed to version type archive (ARC), if archiving was requested for the COOL:2E environment. The version type is set to PRD only when promoting to the environment specified as the related production environment for the from environment. In addition, the command removes the locks and updates the check out information.

The move step optionally updates information in target libraries by generating the Convert Model Messages (YCVTMDLMSG) command and the Convert Condition Values (YCVTCNDVAL) command.

Promotion Flow: COOL:2E to Traditional Environment

Promotion to a traditional environment differs from promotion to a COOL:2E environment. Since there is no target model to update, there is no model copy step and the compile step does not perform COOL:2E generations.

Creating a Request

To promote changes from a COOL:2E environment, from the Create Request menu option in Implementer create a promotion request and select a model object list. Each promotion request can only promote a single model object list. This can affect how you create model object lists, and affect what you check out to them. In general, the model object list should contain a single logical change or multiple logical changes that are grouped together due to dependencies between the changes.



The model list is used to derive the implementation objects for the promotion request. No model objects are copied since the target environment does not contain a COOL:2E model.

In addition to the OS/400 objects added to the promotion request by selecting the model object list, based on your use of COOL:2E you may need to add the following objects, which are not automatically derived from the model object list:

� For National Language Support (NLS), the translated prompt message file specified on the YMSGVNM model value.

� If a field reference file is used and if compile is requested, the physical file specified on the YFRFVNM model value.

When the model objects are included on the promotion request, ensure that the request is set up to compile the traditional objects first.

Compiling

There is no model copy step when you promote to a traditional environment. The compiles that occur ensure that the 400 Toolkit compiler directives in the source members are applied by using the 400 Toolkit Execute with Pre-processor (YEXCOVR) command to perform the compiles.

Move Request

This step updates the implementation objects in the target library. The objects and source are moved into the libraries specified for the environment.

The original model is also updated in this step. The version type is changed for all model objects from development (DEV) to production (PRD). For versionable object types, the existing PRD version of that model object group is changed to version type archive (ARC), if archiving was requested for the COOL:2E environment.

NOTE

The version type is set to PRD only when you promote to the environment specified as the related production environment on the from environment. The command removes the locks and updates the check out information as well.

The move step optionally updates information in target libraries by generating the Convert Model Messages (YCVTMDLMSG) command and the Convert Condition Values (YCVTCNDVAL) command.

355


For a complete description of these COOL:2E commands, see the COOL:2E Command Reference Manual.

The condition values and model messages are normally converted from the model library associated with the from environment of the promotion request. If you select to convert condition values or model messages on a promotion request that targets an environment group that contains a primary COOL:2E production environment and a secondary traditional environment, all conditions and messages for the secondary traditional environment are converted from the primary COOL:2E target model.

Promotion Flow and QA Considerations

QA environments can optionally be set up so they do not use a model even when a model is defined for the production environment. This is referred to as a simulated QA environment. This feature provides the benefit of defining a QA environment for testing the implementation objects, without the disk space requirements and performance impact of having a separate QA model.

In this case, you define the QA environment to use the same model as the development environment. When promoting from development to QA, no model copy occurs since the models are the same. Once the promotion to QA is complete, the promoted model objects show as checked out to the QA environment and can no longer be edited.

To implement this scenario, from the Work with Environments panel use option 10=COOL:2E to change the QA environment as follows:

� Change the model library to the COOL:2E model you defined to the COOL:2E *TST environment.

� Change the related production environment to the COOL:2E *TST environment related production environment.

� Change the Separate model copy step to N.

You must generate and compile the objects in your COOL:2E *TST model prior to creating the request (the default YCPYMDLOBJ processing does not run). All post-move processing to the related *PRD environment correctly updates the check out information and the COOL:2E model object version type in the COOL:2E *TST environment, and the locks are removed.

Working in a Change-Controlled Model

When a model is designated as change-controlled, you will notice the following while editing the model:

� When changing, adding, or deleting a model object, Implementer verifies that you are authorized to perform the action to a model object of the type selected, and whether the model object is checked out. If authorized, the Check Out panel displays.



� You can explicitly check out model objects using option 28 from Edit Model Object List or Work with Versions.

� You can resolve conflicts with option 12 on the Work with Versions panel. Use option 19 from the Edit Model Object List panel to display the Work with Versions panel.

� You can go directly to the Implementer Menu from the COOL:2E Services Menu.

� Check out information displays on the COOL:2E Work with Model Object List panel and on the Work with Versions panel.

� Your authorities to a model object list are checked by Implementer each time that you access a list.

� Your authority to the model object type is verified each time that you access a model object.

NOTE

Use the Edit Model Object List (YEDTMDLLST) command to view the change control information of model objects. This command is designed to help you easily manage your model object lists.

Pre-load the model environment into your job with the Edit Model (YEDTMDL) command: YEDTMDL entry (*NONE). This increases your interactive response time on successive model edits.

Model Object Audit Information

When changes are made to a model object, Implementer records the date and time the object changed and the user profile who made the change. This audit trail information can be useful to track changes to objects in the model.

357


Keep in mind that an object is not considered changed when:

� accessed to edit but no changes are actually made

� copied from another model and it has not changed since being copied

� a newly-created version has not changed

Change Type

When a model object is changed, COOL:2E records the type of change and automatically determines the type of change based on what information is changed for the model object. The change types are:

For a more detailed description on how you can use this information, see “Component Change Processing” in the COOL:2E Generating and Implementing Applications manual.

NOTE

Implementer only uses the change date and time, and user model object audit information, not the change type.

Change type Description

Object Only (OBJ) A change that has no effect on any other object and does not require regeneration of the object, or any other object, to retain the integrity or functionality, either of the objects or of the implementation objects.

Generation Required (GEN)

A change that has no effect on any other model object but does require regeneration of the changed object to affect the change in its implementation object. If it is an internal object, the generable objects that use it must be regenerated.

Private (PVT) A change to an object in which its interface with all objects that contain the object has not changed. The objects that contain the changed object may need to be regenerated for the implementation objects to contain the new functionality of the changed objects.

Public (PUB) A change to an object in which its interface with other model objects has changed. The objects that contain the changed object need to be reviewed and changed to ensure their integrity.



Impact Analysis Extensive impact analysis features are available within COOL:2E. The panels allow affected objects to be easily checked out. For example, if an internal function is changed, the functions that use the internal function can be displayed or built into your model list and easily checked out.

Once a promotion request is created for a model object list, all the model objects can be analyzed to ensure the required affected objects are on the request. You can accomplish this from the Compile Requests panel with option 7=Analyze Request. This function submits a job that prints two reports that analyze whether the model object list is ready for promotion and determines if all the affected objects are included on the request.

The use of these impact analysis facilities helps you ensure change control integrity in Implementer.

Managing EXCUSRSRC and EXCUSRPGM

By default, Implementer allows you to promote EXCUSRSRC and EXCUSRPGM COOL:2E functions separately from their associated implementation 3GL source and objects. This is called “Independent EXCUSRSRC and EXCUSRPGM”.

Implementer optionally allows you to automatically promote the 3GL source and objects associated with EXCUSRSRC and EXCUSRPGM functions when these functions are promoted. When enabled, the implementation objects for EXCUSRSRC and EXCUSRPGM function types are derived and included on the promotion request. With this feature, the implementation source and/or objects may not be checked out or promoted separately from this model object. This is called “Dependent EXCUSRSRC and EXCUSRPGM”.

This feature is controlled by an environment level flag.

During check out and promotion, Implementer verifies if the 3GL source and/or objects are associated with a model object. If not allowed, the following message is sent:

Cannot check out/promote implementation object when the development environment is flagged as "Dependent" and the object type is EXCUSRSRC or EXCUSRPGM.

Check Out and Promotion of Independent Functions

When an EXCUSRSRC or EXCUSRPGM is created, only the model object (YFUN) is checked out. The traditional program (or source) object must be checked out using traditional check out, option 2 from the Implementer Menu.

An EXCUSRPGM has both source and object associated with it; therefore, you should use a standard object code (for example, RPG or COBOL) to promote it.

359


An EXCUSRSRC has only source and no program object associated with it; therefore, you should use the appropriate CPY object code (for example, RPGCPY) to promote it. The object code can be tailored to define a specific source file or copied to create a new object code. This object code is used in the check out of the traditional portion of an EXCUSRSRC.

When promoting EXCUSRSRC and EXCUSRPGM, even though the Remove Source flag is set to Y, the source for user programs is not removed.

Traditional Check Out of Dependent Functions

Checking out dependant 3GL source or objects associated with a USRSRC or USRPGM is not allowed.

Traditional Check Out of Independent Function

Checking out the EXCUSRSRC and EXCUSRPGM independent implementation source is allowed using appropriate 3GL object codes.

For the EXCUSRSRC 3GL source, check out with a source only object code that has a source member but no object associated with it. For example, use RPGCPY.

For the EXCUSRPGM 3GL source and/or object, check out with one of two object codes: If you have source for the program, use the RPG object code. If you have just the object for the 3GL program, use an object code such as (or similar to) RPGOBJ. In this case, there is no relationship assumed between the model objects and the related USRSRC and USRPGM. For example, you may check out either one without regard for the other.

Promoting Dependent Functions

The dependent implementation source and/or objects are automatically added to the promotion request. Model Objects are added to the promotion request when request dependent EXCUSRSRC and/or EXCUSRPGM is selected for promotion.

The source and objects are placed in the Implementer work library. The object code automatically assigned is derived based on the same rules for the object code assigned when checking out independent objects. This allows Implementer to distinguish between the two different types of EXCUSRPGMs—with source and without source.



Promoting Independent Functions

The independent implementation source and objects are not added to the promotion request.

You can promote EXCUSRSRC and/or EXCUSRPGM without regard for the other, although this could result in problems in some cases. For example, a parameter change could be made to a function that is a USRPGM. If that function and the associated functions are promoted, but the implementation object (a program) is not promoted, a parameter mismatch will occur when executing the application. In this situation, you must ensure the model object and the corresponding RPG/COBOL code are included on the same promotion request.

Source or Objects Outside the Generation Library

There are three common ways that COOL:2E users can store EXCUSRPGM source and objects outside the test model generation library. This section briefly describes each scenario and how to implement the solution.

Each scenario uses the XCB target HLL object attribute in COOL:2E (see note) to create a new corresponding object code in Implementer. The examples assume the EXCUSRPGMs are type CLP. If they are other HLL types, copy the appropriate shipped object code instead of CLP.

For each of the following scenarios, define the XCB object code. Copy the shipped CLP code to XCB, change its source file value to YXCBLSRC, and change its shipped sequence number to 502 (or the next sequentially available number).

� Scenario #1: Source in an alternate source file in the generation library with object in the generation library:

� Create an XCB object code.

� Scenario #2: Source in an alternate source file in the generation library with objects in a library other than the generation library:


� Change the Environment Object Code Override object location library value to the library that you want to store the EXCUSRPGM object in. (Use F8=Object code override on the Change Environment panel.)

361


� Scenario #3: Source in an alternate source file in a library other than the generation library:


� Change the Environment Object Code Override object location library value to the library that you want to store the EXCUSRPGM object in.

� Change the Environment Object Code Override source location library to the library to store the EXCUSRPGM source in.

For each scenario, perform the following steps in COOL:2E for each EXCUSRPGM and EXCUSRSRC:

1 When editing the function in COOL:2E, change the language from CLP, RPG, or CBL to XCB.

2 In the COOL:2E Edit Generation Types panel, change the name of the SCB source types source file to the source file name used on the XCB object code definition in Implementer.

Merging Model Lists

Model lists can be merged using the COOL:2E Merge Model Lists (YMRGMDLLST) command. Merging model lists that are change-controlled allows you to combine two lists for creating a promotion request. This feature is useful in several scenarios, including:

� Combining model lists for two changes that start to converge during development.

� Combining model lists for QA environments, where individual changes were moved into QA but you want to have one large move to production (or to the next QA environment).

When two lists are merged, Implementer automatically changes the locks to the target model object list. In order to merge the two lists neither list can be attached to an open promotion request. In addition, you must have:

� authority to change locks for the from environment, or

� authority to change locks for the target environment, or

� for a list that is still checked out to a *TST environment, be the user who checked out all model objects on the list


J.D. Edwards Integration

Remote Considerations

For COOL:2E-developed applications running on a remote system, it may be necessary to distribute the COOL:2E user message file, condition values, generation objects, and application objects (runtime support objects) to the remote system. Implementer automatically distributes these items for remote environments, if requested; ensure the COOL:2E options are correctly set when you create the request.

NOTE

The remote environment must be a traditional environment, as Implementer does not support distributing model changes from a COOL:2E environment on one system to another COOL:2E environment on a remote system.

J.D. Edwards IntegrationThe Implementer Adapter for J.D. Edwards provides support to manage traditional objects that require J.D. Edwards compiling, and special objects such as DREAM Writers and Member Masters. This section explains the functionality of the integration and the procedures required for managing J.D. Edwards applications using Implementer.

Implementer supports the check out and promotion of J.D. Edwards objects in a controlled fashion. An audit trail of all activities performed on these objects provides visibility to the activities on the J.D. Edwards objects being managed. Distribution of J.D. Edwards special objects to remote locations is supported.

A specific set of object codes is used to support J.D. Edwards special objects. For a list of the J.D. Edwards object codes and set up requirements for the interface, see Chapter 5 of the Implementer System Administrator Guide.

This release of Implementer provides support for any J.D. Edwards 8.X version. It requires OS/400 V4R2 or higher.

The interface objects are shipped with Implementer in save file IMJDESAVF and are automatically installed when you install Implementer. The save file must be restored to the J.D. Edwards interface library IMJDE. This library is referred to as IMJDE or the interface library in this section.

363


Starting the Interface

You must have the following libraries in your interactive library list:

� Implementer J.D. Edwards interface library (IMJDE)

� J.D. Edwards product libraries (JDFSRC, JDFDATA, and JDFOBJ)

To ensure your interactive library list is correct, start your J.D. Edwards software first. Once you are in J.D. Edwards, you can start Implementer.

IMPORTANT

The IMJDE library must be above the J.D. Edwards product libraries in your interactive library list.

Support for J.D. Edwards Traditional Objects

To manage J.D. Edwards traditional objects, you must set up object codes with specific characteristics. For details about the set up requirements, see Chapter 5 of the Implementer System Administrator Guide. This offering supports J.D. Edwards Release 5.2 through 8.X (the characteristics of the object codes to set up are different for each release).

Support for J.D. Edwards DREAM Writer Versions

For J.D. Edwards DREAM Writers, support for multiple versions in a form ID is provided. This allows you to check out and promote single versions or all versions in a form ID.

Versions can be checked out and placed on a promotion request using one of the following options:

� Single version—Specify a particular version in the Comment field to select a single version of a form ID. If versions are individually selected, you cannot specify *ALL versions for the same form ID.

� All versions—Specify *ALL in the comment to select all versions of a form ID. If you select *ALL versions, you cannot select individual versions for the same form ID.

You can check out single versions by specifying the form ID in the Member/Object field in both Check Out and Create Request. The version ID can be defined up to ten characters in length, but it must begin in the first position of the Comment field. When specifying a version name in the Comment field, the version name must be entered using all upper case letters, for example, *ALL. This rule applies to both single versions and all versions.


J.D. Edwards Integration

Checking Out Keep the following points in mind when checking out J.D. Edwards special objects:

� If you are checking out J.D. Edwards special objects, you must use the specific object codes that are defined with special characteristics starting with JDE.

� Locks are created for all special objects that are being checked out.

� J.D. Edwards special objects that are specified with one of the JDE object codes can only be checked out from an environment defined as a J.D. Edwards environment.

� For the J.D. Edwards special object types World Writer and FASTR, you must enter a group name in the first ten characters of the Comment field.

� You cannot check out J.D. Edwards special objects to a library.

� If you are managing the J.D. Edwards special object User Defined Codes with Implementer, the member/object name consists of a four-character system number and a two-character table name. If the system number is less than four characters, you must add spaces to complete the four-character requirement. For example, if you have a system number of 55 and a table name of HT, create the member/object name as 55 HT (two number 5s, two spaces, and the letters HT).

� The Check Out (ICHKOUT) command can be used to check out J.D. Edwards special objects.

� The Check Out Related Objects function does not support J.D. Edwards special objects.

Displaying J.D. Edwards Items

From the Workbench, press F11=Display comments three times to display J.D. Edwards member/objects. In addition to displaying comments entered in check out, you can display the Form ID for World Writer and FASTR, and the version reference for DREAM Writers.

Compiling From the Workbench

To compile from the Workbench (using option 14=Compile), the compile library list must contain the J.D. Edwards product libraries JDFOBJ and JDFDATA.

365


Promoting Keep the following points in mind when promoting J.D. Edwards special objects:

� To promote printer files, use the JDEPRTF object code to propagate J.D. Edwards printer file overrides at the time of promotion. This object code (with the special characteristic JDNPRTF) is shipped with Implementer. For more information, see Chapter 5 in the Implementer System Administrator Guide.

� If you are promoting a J.D. Edwards special object (using an object code that contains a JDE special characteristic), the From and To environments must be defined as J.D. Edwards environments.

� You can only promote J.D. Edwards special objects from a specifically defined J.D. Edwards environment (J.D.E). The objects on the request and the environments are edited for validity.

� The primary reason for failure of promotions containing J.D. Edwards special objects is incorrect library list setup in the Implementer environments. For setup considerations in these areas, contact your System Administrator or see the Implementer System Administrator Guide.

� You can promote J.D. Edwards special objects and traditional objects on the same request.

� If J.D. Edwards special objects target an environment group, the primary environment must be a J.D. Edwards environment. J.D. Edwards special objects are not moved to other environments in the group that do not have a special environment type of J.D. Edwards.

� If you enter the J.D. Edwards World Writer or FASTR special objects, the group name is required in the first ten characters of the comment field on the request.

� You cannot promote J.D. Edwards special objects from a library.

Remote Distribution

J.D. Edwards special objects can be distributed to remote locations by promoting to remote environments defined in the Work with Environments function. The remote environments must be valid J.D. Edwards environments, as defined in Work with Environments. This feature requires that the Implementer Receiver and the interface objects be installed on each remote system you distribute to.

Archiving J.D. Edwards Special Objects

You can archive J.D. Edwards special objects, such as DREAM Writers and Data Dictionary items, into a common archive library that you specify for the environment. Selective rollback of the archived special objects is supported.


LANSA Integration

Archive Recovery

Once setup is complete for archive recovery of J.D. Edwards special objects, the archive recovery process works the same as standard archive recovery.

If you need to rollback any archived changes, use option 23 from the Implementer Menu, select the request to recover, and select one or more special objects to recover. Details on this process are provided in “Handling Emergency Situations” on page 295.

LANSA IntegrationLANSA is a CASE tool developed by LANSA Corporation. The Implementer Adapter for LANSA manages LANSA objects such as files, fields, processes, and functions, allowing you to check out and promote LANSA objects in a controlled fashion. This interface supports LANSA for the Web. LANSA for the Web generates Web and Extensible Markup Language (XML) components, which can be managed by Implementer.

Environments are associated with a valid partition in LANSA. All changes to objects in a partition are managed using the associated environment. Special object codes accomplish check out and promotion of LANSA objects to and from LANSA environments. Check out locks the name of the LANSA object and can copy (export and import) LANSA objects to the development environment depending on the environment definition. Promotion prepares the LANSA objects for export and moves (imports) the objects to the target environment. Distribution of LANSA objects to remote locations is supported. All reports and inquiries track LANSA objects managed by Implementer.

Checking Out � You can check out LANSA objects with the appropriate object codes as defined in the Implementer System Administrator Guide. Locks are created for all the objects that are checked out.

� When checking out LANSA objects, you must use the specific object codes that are defined with special characteristics starting with LAN.

� You must use the appropriate object codes (LANWEBC and LANXMLC) for the Web and Extensible Markup Language (XML) components generated by LANSA for the Web.

367


� LANSA objects must be checked out from a specified LANSA environment that is defined in Work with Environments, by associating a partition to a standard environment in order to create a special LANSA environment.

� If the environment definition specifies that LANSA objects will be physically copied during check out, the copy of LANSA objects is performed in batch. The LANSA objects are exported from the from environment and imported into the to environment. MKS recommends that you perform a manual verification of the LANSA export and import reports.

� LANSA objects that are specified with one of the LAN object codes can only be checked out from an environment defined as a LANSA environment. If you are using copy from environments to check out LANSA objects, you must use the same copy from environment within a single check out session.

� You cannot check out LANSA objects to a library.

� LANSA objects entered or selected for copy are added to an export list if the environment specifies to copy LANSA objects during check out. The check out of multiple LANSA functions with the same name and object code from different processes is supported, when the process name is specified in the first ten characters of the comment field.

� If you do not enter the process name in the comment field, the function is checked out from the first process containing the function. The name of the process displays in the comment field. The name can be changed if the LANSA function is to be checked out from a different process.

� During check out of a LANSA file (with or without data), when the environment definition option to copy LANSA objects is Y, the import process prompts for the name of the library that the file is imported into. Watch for the prompt and enter the appropriate library name.

� Copy from environment is supported for LANSA objects so that concurrent development is allowed. The same copy from environment must be used throughout the check out session.

� Copy from member/object is not supported for LANSA objects.

� The Check Out Related Objects function does not support LANSA objects.

� The Check Out (ICHKOUT) command can be used to check out LANSA objects.


LANSA Integration

Promoting � The user profile (or group profile) used to promote LANSA objects into an Implementer environment with archiving activated must be the partition’s Security Officer user profile.

For example, the LANSA security profile QOTHPRDOWN is defined as Security Officer on the partition and used as the profile when promoting LANSA objects. An alternate user profile (such as LANPRD) could also be used as long as profile QOTHPRDOWN is defined as the group profile. If this guideline is not followed, error messages occur in the LANSA Export Report for LANFLD, LANFIL, FANFLDT, LANPROC, and LANFNC object types, and the archive becomes unusable for these items.

� When promoting a LANSA object (using an object code that contains a LAN special characteristic), the from and target environments must be defined as LANSA environments.

� LANSA objects must be promoted from a specifically defined LANSA environment. The objects on the request and the environments are edited for validity.

� LANSA definitions can only be promoted from an environment. Promotion from a library is not supported.

� All valid LANSA objects on the request are bundled into an export list. All LANSA objects are promoted in compiled form.

� Both LANSA objects and traditional objects can be promoted on the same request.

� If you are promoting a LANSA function that exists in more than one LANSA process, the name of the process that the function is being promoted from must be defined in the comment field. If you do not enter the process name, the function is selected from the first process.

� It is possible to limit the auto submit process to only the export step. The export step exports LANSA objects on the request. The export is done to a save file. The verification of the successful completion of the export process must be done by manually looking at the export reports generated by LANSA.

� If LANSA objects are targeted for a target environment group, the primary environment must be a LANSA environment. LANSA objects are only moved to other environments in the group if they have a special environment type of LANSA.

� The move request function performs an import of LANSA back into production. You should verify the Import Report manually.

369


� During the promotion of a LANSA file (with or without data), the import process prompts for the name of the library that the file should be imported into. Watch for the prompt and enter the appropriate name.

� The Export Phase status code definitions are:

Displaying Process/Functions

From My Workbench, press F11=Display comments three times to display LANSA process/functions. This also displays any comments you specify in check out.

Archiving LANSA requests are archived by exporting the LANSA objects in the target partition into a save file in the archive library. The save file name is built with the environment ID number to ensure that during recovery the correct LANSA objects are recovered.

If you choose to recover LANSA objects, all of the LANSA objects on the request are automatically recovered.

LANSA objects are archived differently than traditional objects:

� The save file name for LANSA is constructed as: LSA + request number + environment ID.

� All LANSA objects are saved into one save file and the save file is stored in the archive library, unlike the traditional objects, which are saved separately.

If you want to check out LANSA objects, specify a valid LANSA environment in the To environment field and a valid user in the To user field. A lock is created for all of the LANSA objects on the request. If the Copy LANSA Objects in Check Out field is flagged in the LANSA Work with Environments definition, the LANSA objects are copied into the archive library.

Expt-Pend The Export phase is ready for execution. The Export phase is only used by LANSA environments.

Expt-Jobq The Export function was submitted to the job queue for processing.

Expt-Schd The Export function is scheduled for processing.

Expt-Run The Export phase is executing.

Expt-Fail An error has occurred during the Export phase. Review the job log and the LANSA Export Report to determine the cause of the failure. Make the proper corrections and resubmit the export promotion.


LANSA Integration

The Recover LANSA objects field on the Archive Recovery Options panel specifies whether LANSA objects should be recovered. Both traditional and LANSA objects can be recovered at the same time. This is useful when you have a combination of LANSA objects and traditional objects on the same request.

If you want to recover only traditional objects, set the Recover LANSA objects on the request field to N when you select the traditional objects. If you want to recover only LANSA objects, set the Recover LANSA objects on the request field to Y but do not select any of the traditional objects.

Save File Libraries

LANSA creates save files in different libraries depending on the task. The libraries per task are:

� Check out—the file library specified in the to environment definition.

� Promotion—the Implementer work library.

� Archiving—the archive library specified in the environment definition.

If the save files begin to take up too much disk space, you can delete the obsolete save files.

Remote Distribution

LANSA objects can be distributed to remote locations by promoting to remote environments defined in the Work with Environments function. The remote environments must be valid LANSA environments as defined in Work with Environments.

The LANSA objects you manage with Implementer can be archived from the target environments they are promoted to. However, the Archive Recovery function allows you to recover LANSA objects that have only been archived from local environments. If you are going to recover LANSA objects from remote environments, use the following procedure:

� The archive library specified in the environment definition should contain the save file created during archiving.

� The name of the save file is LSA followed by the promotion request number (and the environment suffix). For example, if your request number is 1234, look for a save file that starts with LSA1234.

� Use the LANSA Import command to import the save file into your remote production partition.

371


LANSA Export/Import Authorities

Implementer can grant LANSA export/import rights to you automatically during the migration of LANSA objects. Because Implementer uses the export/import processes for the migration of LANSA objects, insufficient LANSA authorities on the objects can lead to failure of migrations. Therefore, if you are authorized to check out or create promotion requests, you are automatically granted LANSA authority to perform the export and import processes. This authority is in effect only during the time the export or import process is executed. It is automatically revoked when migration is complete.

LANSA RDML Function Compare

The Compare RDML (ICMPRDML) command compares and prints the differences between two LANSA RDML functions within the same partition or in two different partitions. This command can be used as a stand-alone utility, either in batch or interactively. It is also called automatically from various Implementer panels when you select option 23=Compare member against a LANSA object. Additionally, it is available as option 69, Compare LANSA RDML (ICMPRDML) from the Implementer Menu.

Using the ICMPRDML Command

You can access the ICMPRDML command using any of the following methods.

� From any command line, type the ICMPRDML command and use F4 to prompt the command, or type the parameters listed in the next section.

� From the Workbench, by selecting a LANSA function with option 23=Compare member.

� From the Select from Locks panel (accessed by using F10 from Create Requests), select a LANSA function with option 23=Compare member.

ICMPRDML Parameters

The following parameters define the Compare RMDL command.

Base function

Specify the name of the first function you want to compare. This is typically the original function that the compare to function was created from. You must enter an existing function name. The use of wild cards is not permitted.


LANSA Integration

Base process

Specify the name of the LANSA process that the base function resides in.

Partition

Specify the name of the partition that the base function resides in.

Compare to function

Specify the name of the function you want to compare against the base function.

You must enter an existing function name. The use of wild cards is not permitted.

Compare to process

Specify the name of the process that the compare to function resides in.

Partition

Specify the name of the partition that the compare to function resides in.

Exclude comment lines

Specify *YES or *NO to indicate whether difference in comment lines between the base and compare to functions are compared and reported.

Print options: All or only changed lines

Specify *ALL or *CHG to indicate whether both equal and unequal areas of each function (*ALL) or only unequal areas are printed (*CHG). If you select *CHG, you can elect to print a fixed number of equal lines before each block of differences, as defined in the next field.

Print options: Equal lines before, if *CHG

If the previous field is set to *CHG, enter the number of equal lines (0–99) prior to each detected change to print.

Output queue/Library

Specify *JOB, the output queue name and *LIBL, or the library name, to indicate the output queue associated with the job and the library that output queue resides in.

373


Hold spooled files

The valid options are:

Submit

Specify whether to submit the job to batch or process interactively.


Specify the job name and either *LIBL or a library name to be used for the submitted job. The default job description is MWIJOBD.

(Footer text field)

The last field on the panel allows you to enter text to appear at the bottom of each page on the report. This is an optional field.

Understanding the Report

The following illustration shows a page from a typical Compare Members report.

*FILE The printer file definitions determine whether to hold the report output. The name of the printer file is NVCMMBP.

*YES The report output is held.

*NO The report output is not held.

*YES Submits the job to batch. The name of the submitted job is LANSACMP.

*NO The job runs interactively.


LANSA Integration

This report is identical in format to the standard Implementer Compare Member Report, with the following terminology changes to reflect LANSA objects.

Note that old and new commands are printed in their entirety for multiple-line commands, even if only a portion of that command is different within the two versions.

This term in the Implementer Report...

Is changed to this term in the LANSA Report…

Member Function

File Process

Library Partition

Source data LANSA RDML command

375


Lotus Notes and Domino Integration Implementer provides integration with Lotus to offer change management support for OS/400-based Lotus Notes and Domino software applications developed by Lotus Development Corporation.

This integration is built on the framework of existing Implementer technology, and features that include the latest support for IFS technology and the change management of client/server development. The interface enables browser-based check out and promotion deployment of Lotus Notes Storage Facilities and Notes Template Files using a browser interface.

For information about setting up and using this integration, see the Implementer Multi-Platform Solutions Guide.

Powerhouse IntegrationPowerhouse is a CASE tool developed by Cognos. The integration of Implementer with Powerhouse requires minimal additional object code setup (as described in the Implementer System Administrator Guide).

From a user standpoint, the integration is virtually seamless; however, it is helpful to understand how the integration operates within Implementer.

Normally, it is assumed that object and source names are the same unless a creation override is performed. With Powerhouse objects, source and object names are different object names carry a two-character prefix based on the creation command:

When Powerhouse object is recognized, the appropriate two-character prefix is automatically appended during Create Request. If you have already entered the prefix on the Create Request panel, the prefix is automatically stripped to derive the source member name, thus treating these objects as if you had performed a creation override, although no override was needed.

Creation Command Prefix

QTP PT

QUICK PK

QUIZ PZ

QDESIGN PK


Utility Software Products

Implementer also automatically performs some required special object processing. Prior to compiling, *CURLIB is changed to the work library (#FILLIB). After a successful compile, *CURLIB is automatically changed to *CURDFT.

Utility Software ProductsImplementer provides features to integrate with the following, utility software products. Some of these products integrate seamlessly. Other products require further user action to complete the integration. These products are described in the following sections.

� ABSTRACT

ABSTRACT is a programming environment from Advanced Systems Concepts that includes both documentation and development tools. Through its documentation facilities, ABSTRACT provides a centralized information source for all of your iSeries 400 software. The ABSTRACT development environment is designed as a replacement for part of the IBM Programming Development Manager (PDM).

� AOS Message Manager and Pager Manager

These are two messaging products available through Syan, Limited. Implementer users can use it to notify them, through OS/400 messaging or by issuing a pager message of the status of promotions.

� AS/NET

AS/NET is an object distribution package available through System Software Associates, Inc. Implementer users can use their distribution facilities to distribute requests to remote systems.

� MIMIX

MIMIX is a software product from Lakeview Technologies that provides concurrent updates of database files on multiple systems. One of the techniques MIMX uses is journaling.

� NetView/DM

NetView/DM is a mainframe-based distribution management product from IBM that efficiently manages the distribution to multiple systems at the same time.

� Net/Wrk400

Net/Wrk400 is an object distribution package available through KnowledgeNet.

377


� PathFinder

PathFinder is a documentation utility product from Hawkeye Systems, Inc.

� ROBOT

ROBOT is a scheduling system from Help Systems, Inc.

ABSTRACT Integration ABSTRACT is a programming environment from Advanced Systems Concepts that includes both documentation and development tools. Through its documentation facilities, ABSTRACT provides a centralized information source for all of your iSeries 400 software. The ABSTRACT development environment is designed as a replacement for part of the IBM Programming Development Manager (PDM). ABSTRACT also offers a GUI plug-in to IBM’s Operations Navigator, but the integration discussed here only extends to the host-based interface.

Version Requirements

Implementer links and works with any release of ABSTRACT.

Abstract User-Defined Options

To support integration with Implementer, four PDM-style options are available for the ABSTRACT user options file.

� IS allows you to enter ABSTRACT from the Implementer Check Out panel (F17=ABSTRACT). Navigate through ABSTRACT until you find the items that you want to check out, and type IS in the option field next to the item to add it. This is very helpful when you want to do field level analysis of related objects, since this is only available through ABSTRACT menu options.

� IC allows you to check out directly from within ABSTRACT, without having to come from the Check out panel first.

� IR allows you to create a promotion request for an individual member or object while in ABSTRACT.

� DS can be used if ABSTRACT is accessed from the Work with Entity List Members panel in DesignTracker. This option selects items from ABSTRACT to the entity list for the DR you are currently working with.


ABSTRACT Integration

� IB allows you to add items to the Implementer clipboard. With this unique feature of Implementer, you may build a list of items while drilling through various ABSTRACT panels, adding one item here and a couple items there. Implementer can perform a single operation on all the items on the clipboard, such as checkout or promotion, or emergency tasks.

The options needed to use Implementer from within ABSTRACT are in the file IMPRBOPT in the Implementer product library. They can be copied into the ABSTRACT options file QAUOOPT in the ABSTRACT product library, if they are not already there.

The options are defined as follows through the Work with Object References (WRKOBJR) command:

ICHKOUTSEL

ICHKOUT

Option IS

Description Select member/object for checkout

Execution I (I=Interactive, S=Submit, Blank=Either)

Command ? ICHKOUTSEL MBROBJ(&N) OBJLIB(&L)OBJTYPE(&T) OBJATR(&A) SRCFILE(&SRCLIB/&SRCFIL)&SRCTYPE(&A)

Object type *ALL

Object attribute *ALL

Option IC

Description Check out


Command ? ICHKOUT MBROBJ(&N) OBJCODE(&A)

Object type *ALL


379


ICRTRQS

IDDCBD

Accessing ABSTRACT From Implementer

Implementer provides direct access to the ABSTRACT main menu from the Implementer Check Out menu option and DesignTracker Entity panels. In addition, any panel that supports the Implementer user defined function keys, such as the Workbench, can easily be tailored to access ABSTRACT menus using a function key.

The Implementer Workbench also supports user defined PDM options. Any ABSTRACT command that can be accessed using PDM user defined options can be used in the option field on the Workbench.

AOS Message Manager Integration You can use AOS Message Manager to monitor messages pertaining to the status of promotion steps. This includes the start, end, and abnormal end of the compile, and the distribution, move, and final processing of a promotion.

Option IR

Description Create promotion request


Command ? ICRTRQS MBROBJ((&N &A))

Object type *ALL


Option IB

Description Add item to Implementer clipboard


Command ? IADDCPD MBROBJ(&N) OBJCODE(&A)

Object type *ALL



AS/NET Integration

For details on how to monitor the message queue, see the AOS Message Manager Users Guide or the AOS Pager Manager Users Guide.

NOTE

The System Administrator must have set up the Secondary Message Queue in System Control Maintenance in order to create the interface between AOS Message Manager and Implementer.

AS/NET IntegrationAS/NET is an object distribution package available through System Software Associates, Inc. Implementer users can use their distribution facilities to distribute requests to remote systems.

Although there are some minor setup-related considerations for AS/NET, there are no special user considerations. Setup issues are described in the Implementer System Administrator Guide.

MIMIX IntegrationMIMIX is a software product from Lakeview Technologies that provides concurrent updates of database files on multiple systems. One of the techniques MIMX uses is journaling.

NetView/DM IntegrationNetView/DM is a mainframe-based distribution management product from IBM that efficiently manages distribution to multiple systems at the same time.

Net/Wrk400 IntegrationNet/Wrk400 is an object distribution package available through KnowledgeNet. Implementer users can use their distribution facilities to distribute requests to remote systems.

381


Although there are some minor setup-related considerations for Net/Wrk400, there are no special user considerations. Setup issues are described in the Implementer System Administrator Guide.

PathFinder IntegrationPathFinder is a documentation utility product from Hawkeye Systems, Inc.

PathFinder Database Updates

It is important to accurately maintain the default DOCLIBL for the PathFinder X-ref to use the real-time PathFinder X-ref update feature. Whenever objects are managed in Implementer environments that are specified with source of information 2 for PathFinder, the X-ref is automatically updated through a PathFinder API. This allows the PathFinder information to be current if you use the related objects information during Check Out and Create Request by setting the Add related objects field to Y.

Only *PGM objects are automatically updated. The PathFinder related information for all other objects is not updated during the move, unlike the Implementer related object information.

The following features are provided for PathFinder users:

� update of Hawkeye database during promotion

� during check out and promotion, direct access to PathFinder to determine related objects

� access to the PathFinder menu from the Check Out panel

� access to Implementer commands through PathFinder user defined options

IMPORTANT

In order to issue the PathFinder API commands, the PathFinder library must be in your library list.

PathFinder User-Defined Options

PathFinder PDM-style user options supports the Implementer integration. Use the following options to access Implementer functions while using PathFinder.


PathFinder Integration

� IS to add selected items to the subfile on the Check Out panel when you enter PathFinder using the F18=PathFinder function key in Implementer Check Out. This is very helpful when you want to do field level analysis of related objects since this is only available through PathFinder menu options.

� IC to check out directly from PathFinder panels without having to come through Implementer.

� IR to create a request for an individual member or object while in PathFinder.

� ID to select items from PathFinder and add to the entity list for the design request you are currently creating or changing. This option can be used if PathFinder is accessed from the Work with Entity List Members panel in DesignTracker.

� OU to display where objects are used.

PathFinder PDM Options for USERPATH

The USERPATH file, included with PathFinder software, contains the following user-defined options, which can be used within PathFinder.

PathFinder PDM Options for USERPDM

The USERPDM file, included with PathFinder software, contains the following user-defined options, which can be used within PDM.

Option Description Command

IS Add to Check Out ICHKOUTSEL MBROBJ(&N)OBJLIB(&L)OBJTYPE(&T)OBJATR(&A)SRCFILE(&SL/&SF)SRCTYPE(&ST)

IC Check Out ICHKOUT MBROBJ(&N)OBJCODE(&ST)

IR Create Request ICRTRQS MBROBJ((&N &ST))

383


Some releases of PathFinder define this command differently. It must be changed (specifically, the last parameters must be blank) to work correctly. If PathFinder is selected from DesignTracker, this option adds the selected entity to the Design Request Entity List for the design request you are currently creating or changing.

ILE *MODULE and *SRVPGM Consideration

The PathFinder Where Used function shows ILE *MODULE objects that use a file. However, it does not show the ILE *PGM and *SRVPGM objects that use the file because they contain those *MODULE objects. To ensure level checks do not occur in the *PGM and *SRVPGM objects, use the PathFinder Where Used function to list the *PGM and *SRVPGM objects containing the *MODULE objects. Then add these objects manually to your check out requests.

Since PathFinder does not support cross-environment functionality within Implementer, you must use the PathFinder Where Used feature to list the related objects in different environments and manually create the appropriate check out for these related objects.

ROBOT IntegrationAfter setup is complete as described in the Implementer System Administrator Guide, scheduling is automatically handled as specified during setup. No additional user action is required.

Option Description Command

IC Check Out ICHKOUT MBROBJ(&N)OBJCODE(&T)

IR Create Request

ICRTRQS MBROBJ((&N &T))

ID DesignTracker Entity List

CALL PGM(DTSESLC)PARM(&N &S &X &T &A &ST “ “ “ “ “ “)

OU Object Where Used

HAWKEYE/DSPOBJU OBJ(*ALL/&OBJECT)OBJTYPE(&OBJTYP)


AA P P E N D I X

Compare/Merge Member Commands

The Compare Member (ICMPMBR) and Merge Member (IMRGMBR) commands are productivity tools that simplify and automate the process of comparing and integrating programming modifications during the development process, with up to five source members.

Use these commands to:

� verify source changes before or during acceptance testing

� document changes

� control concurrent development on large programs

� apply PTFs to ongoing development

These commands are particularly helpful when concurrent development of multiple versions of source members exist. This replaces the need to wait for one person to complete work on a change before the next person begins his or her changes.

You can access the Compare Member (ICMPMBR) and Merge Member (IMRGMBR) commands from the command line or through options in the following functions:

� Menu option 65, Compare Member

� Check Out (select version for concurrent development)

� Select from Locks

� My Workbench

� Manage Concurrent Development for a member/object

� Work with conflict resolution (from Manage Concurrent Development for a member/object, or Create Request)

� Object Archives from Work with Objects (Compare Member (ICMPMBR) only)

385


The compare and merge features an advanced algorithm that does not rely on source sequence numbers or look-ahead techniques to determine what lines to add or delete. The comparison algorithm works by initially viewing all programs to be merged as individual blocks of code. The algorithm attempts to match blocks, repeatedly breaking these blocks down until it reaches the smallest block (a line). By using this approach, the comparison algorithm does not get lost or out of synchronization when determining lines that were added or deleted by you or your vendor.

The merge does a series of comparisons between:

� your base application software version

� your current production version (including your custom modifications)

� up to five new (Enhanced) software versions

Following the comparisons, the merge logic rules determine what lines should be included or excluded in the target member.

Compare Member (ICMPMBR) Command The Compare Member (ICMPMBR) command compares two source members using a command interface.

To access the command panel, type ICMPMBR at the command line and press F4 to prompt. You can also access the function by selecting option 10=Compare member and pressing ENTER from one of the following panels: Select Version for Concurrent Dev, Select from Locks, My Workbench, Manage Concurrent Development for a Member/Object, Work with Conflict Resolutions, or Object Archives (from within Work with Objects).

There are two panels for this command. After typing the required information, press PAGE DOWN to access the additional panel.

ICMPMBR Command Parameters

The following parameters define the Compare Members command.

Base member (BASEMBR)

Specify the name of the base source member, typically the original member from which the compare member was created.


Compare Member (ICMPMBR) Command

Base file (BASEFILE)

Specify the qualified name of the source file that contains the base member. You must enter the base file that is an existing source file.

Library (Base)

Specify a valid library that the source file is in that contains the Base member.

Compare to member (CMPMBR)

Specify the name of the member that is compared to the base member, or *BASEMEMBER, to default to the same member entered in the Base Member field. This member can be your current production source, a source member in development, or a modification received from your vendor.

Compare to file (CMPFILE)

Specify the qualified name of the source file that contains the Compare to member, or *BASEFILE, to default to the same file entered in the Base File field.

Library (Compare to file)

Specify a valid library the source file is in that contains the Compare to member, or *BASELIB, to default to the same library entered in the Base File field.

Source type (SRCTYPE)

Specify the source type of the member being processed. The source type allows the compare to handle language specific constraints such as comment lines and line continuation indicators.

� *BASEFILE, *CMPFILE

Causes the source type to be determined by the base, or compare source file name. This allows all the source members in a source file to be compared, including those that have a source type of TXT.

387


Listed next are the standard recognized source files and their resulting source types.

If it is not one of the standard source files above, it checks for each of the above source types in the source file name. For example, if the source file name is XRPGSRC2, the source type is assumed RPG.

� *BASEMBR, *CMPBMR

Causes the source type of each base member or compare member to be used as the source type for comparison.

Source type name

Specify any of the source types supported by OS/400. A preceding asterisk (*) on the source type name is optional. This includes any valid source type.

Source File Source Type

QASMSRC *BAS

QBASSRC *BAS

QCBLSRC *CBL

QCLSRC *CLP

QCMDSRC *CMD

QDDSSRC *DDS

QLBLSRC *CBL

QPASSRC *PAS

QPLISRC *PLI

QRPGSRC *RPG

QTXTSRC *TXT

QUDSSRC *UDS



Exclude comment lines (EXCOMMENT)

Specify if comment lines are ignored in the comparison or handled in the same manner as all other lines.

Exclude blank lines (EXCBLKLINE)

Specify if blank lines are ignored in the comparison or handled in the same manner as all other lines.

Compress blanks (COMPRESS)

Specify that multiple blank spaces are to be compressed to one space before the comparison occurs. Removal of the blanks causes lines equal in all characters, except for the spacing between words and numbers, to be seen as equal. This is particularly useful in CL programs and other free format languages such as COBOL, PL/I, and Pascal. Compressing blanks does cause some additional processing time.

*NO Determines if the comment lines are handled as any other line. Differences in comment lines are indicated.

*YES Causes all comment lines to be ignored as part of the comparison. If all lines except the comment lines are equal, then the source files are seen as being equal. The Source type parameter determines the comment lines.

*NO Causes blank lines to be viewed as regular lines, and indicates any differences in the number of blank lines and their placement.

*YES Causes all blank lines to be ignored as part of the comparison. It does not mark any differences between members as a result of blank lines.

*SRCTYPE The compression of blanks is determined on a member-by-member basis. The determining factor is the source type. It does not compress source types of RPG, and all the DDS source types. It does compress all other source types.

*YES Causes blanks within a line to be compressed before the comparison. If one blank separates the same two-words in the first member, and three blanks separate the words in the second member, the members are equal because the comparison considers only one blank space.

*NO Causes blanks to be handled as any other character. It indicates a difference if the number of blanks between words and letters is different between two members.

389


Start column (STARTCOL)

Specify the column in the source line that comparison should begin from. This can be particularly useful when processing DDS or RPG source, when one of the source members has entries in column 1 through 5 and the other does not. The range is 1 to 200. The default is 1.

End column (ENDCOL)

Specify the column you want to end the data comparison at for reporting purposes. The range is 1 to 200. The default is 80.

Use the Start/End columns to ignore comments in languages with a columnar syntax like RPG and DDS. Often in RPG and DDS, columns 1–5 contain markings that indicate a change or version that was added in the upgrade. If these markings exist in one version but not in another, you should consider using the start and end columns to ignore the markings.

You should not ignore columns 1–5 for free format languages such as CLP, PL/1, and COBOL. These languages can contain valid program statements in these columns.

Print options (PRTFILTER)

The print parameters provide the means of customizing the comparison report.

Output queue (OUTQ)

Specify which output queue to place the comparison report on.

All or only changed lines

Specify how to control the amount of printed output on the report.*ALL prints the entire member being compared, showing both equal and unequal areas of the member.*CHG prints only the unequal areas. Additionally, you can print a fixed number of equal lines before each block of differences, as defined in the next parameter.

Equal lines before, if *CHG

Use this option to indicate the number of equal lines to print before the unequal sections. This allows the unequal sections to print in context of a few equal lines before the unequal block. This field has an effect only if All or changed lines is set to *CHG. This must be a value of 0 through 99.

Name Type a specific output queue name.

*JOB Uses the output queue associated with the job.



Library (Output queue)

Specify the library the output queue resides in.

Hold spooled files (HOLD)

Specify whether to hold the report output.

Submit (SUBMIT)

Specify whether to submit the report to batch or run interactively.

Job description (JOBD)

Specify the name of the job description for the submitted job.

Library (Job description)

Specify the library the job description resides in.

Name Type the name of a specific library.

*LIBL The library list to be searched for the specific output queue. This is the default value if an output queue name is specified without a library name.

*FILE Indicates that the printer file definitions determine whether to hold the report output. The name of the printer file is NVCMMBP.



*YES Submits the report. The name of the submitted job is CRTOBJ if *ALL or *SRCMBR is entered for the object. For a specific object, the name of the object is the name of the submitted job. The Job description (next) determines the job queue to use.

*NO The report runs interactively.

MWIJOBD This is the default value.

Name The name of the job description used when submitting the job. It is ignored if not submitted.

Name The specific library name.

*LIBL Searches the library list for the specific job description.

391


Compare Member Report Listing

� Dashed lines highlight sections where differences exist between the two source members.

� In-house and Vendor are custom terms. They were entered using the Modify Compare Terms (MODCMPTRM) command. They clearly identify the version in which each unique line exists.

� The Records count is the total number of source records in each member, not the number of records printed on the report.

� The Functional equivalence count is the number of lines that were adjusted in an attempt to match with lines in the other source members. In this example, the continued lines are consolidated into a single line before comparing.


Compare Member Report Listing

Compare Member Report Field Descriptions

The following fields display on the Compare Member Report.

Version

The versions of source you are comparing. It is the base and compare entered on the Compare Members (CMPMBRS) panel.

Member

The name of either the base or compare source member.

File

The name of the file the source members reside in.

Library

The name of the library the source members reside in.

Src seq (Source sequence)

The specific source member, line sequence number.

Source data

The actual listing of the source member line. This can be up to two lines of 100 characters.

ALL Records

The number of records in the corresponding source member.

ALL Unique

The number of lines that occur in only one source member when comparing (see Glossary for dynamic common lines and static common lines).

ALL Compared

The number of actual lines compared in the specified version.

ALL Matched

The number of common records between all versions.

ALL %

The percent of records matched.

393


ALL Func equiv

The number of records adjusted by the functional equivalence processing.

UNIQUE Exec

The number of executable lines included in the Unique counts.

UNIQUE Blank

The number of blank lines included in the Unique counts.

UNIQUE Comment

The number of comment lines included in the Unique counts.

LANSA Compare RDML (ICMPRDML) Command

The Compare RDML (ICMPRDML) command compares and prints the differences between two LANSA RDML functions within the same partition, or in two different partitions. This command can be used as a stand-alone utility, either in batch or interactively. In addition, it is called automatically from various Implementer panels when you select option 23=Compare member for a LANSA object. Additionally, it is available as option 69, Compare LANSA RDML (ICMPRDML) from the Implementer Menu.

Accessing the Command

You can access the ICMPRDML command using any of the following methods.

� From any command line, type the ICMPRDML command and use F4 to prompt the command, or type the parameters listed in the next section.

� From My Workbench, by selecting a LANSA function with option 23=Compare member.

� From the Select from Locks panel, accessed by using F10 from Create Requests, select a LANSA function with option 23=Compare member.



ICMPRDML Command Parameters

The following parameters define the Compare RDML command.

Base function

Specify the name of the first function you want to compare. This is typically the original function from which the compare to function was created. You must enter an existing function name. The use of wild cards is not permitted.

Base process

Specify the name of the LANSA process in which the base function resides.

Partition

Specify the name of the partition the base function resides in.

Compare to function

Specify the name of the function you want to compare against the base function.

You must enter an existing function name. The use of wildcard is not permitted.

Compare to process

Specify the name of the process the compare to function resides in.

Partition

Specify the name of the partition the compare to function resides in.

Exclude comment lines

Specify *YES or *NO to indicate whether differences in comment lines between the base and compare to functions should be compared and reported.

Print options: All or only changed lines

Specify *ALL or *CHG to indicate whether both equal and unequal areas of each function (*ALL), or only unequal areas should be printed (*CHG). If you select *CHG, you can elect to print a fixed number of equal lines before each block of differences, as defined in the next field.

Print options: Equal lines before, if *CHG

If the previous field is set to *CHG, enter the number of equal lines (from 0 through 99) prior to each detected change that should be printed.

395


Output queue/Library

Specify *JOB, or the output queue name and *LIBL, or the library name to indicate the output queue associated with the job and the library that the output queue is in.

Hold spooled files


Submit

Specify whether the job submits to batch or runs interactively.


Specify the job name and either *LIBL or a library name to be used for the submitted job. The default job description is MWIJOBD.

(Footer text field)

Specify additional text to appear at the bottom of each page on the report.

LANSA Compare Members Report

The following illustration shows a page from a typical Compare Members report.

*FILE The printer file definitions determine whether to hold the report output. The name of the printer file is NVCMMBP.



*YES Submits the job. The name of the job is LANSACMP.

*NO The job runs interactively.



This report is identical in format to the standard Implementer Compare Member Report, with the following terminology changes to reflect LANSA objects.

This term in the Implementer Report…

Is changed to this term in the LANSA Report…

Member Function

File Process

Library Partition

Source data LANSA RDML command

397


Note that old and new commands are printed in their entirety for multiple-line commands, even if only a portion of that command is different within the two versions.

For detailed information about this report, see “Compare Member Report Listing” on page 392.

Merge Member (IMRGMBR) Command The Merge Member (IMRGMBR) command provides a method of merging multiple copies of source to produce one final (target) copy of the source using a command interface. This section briefly explains the command and its parameters. The next section, Merge Member Command Parameters, shows detail examples of most of the command parameters.

To access the command panel, from the Implementer Menu select option 66, Merge Member, or type IMRGMBR at the command line and press F4. You can also access this function by selecting option 11=Merge member from one of the following panels and pressing ENTER.

� Select Version for Concurrent Dev

� Select from Locks

� My Workbench

� Manage Concurrent Development for a Member/Object

� Work with Conflict Resolutions

There are three panels for this command. After typing the required information, press PAGE DOWN to access the additional panels.

Base member (BASEMBR)

This member is the base source (previous standard release from the vendor) from which both the production member and the enhanced member have come.

Name Specify the Base source member to be used in the merge.

*NONE Base members are not considered. This occurs when there are only two versions of the members to merge and neither of them can be considered the base member. This provides the means of only entering the source versions on the Production and Enhanced options.


Merge Member (IMRGMBR) Command

Base file (BASEFILE)

Specify the name of the source file that contains the base members. This is a required field.

Library (Base file)

Specify the name of library the base source file is in. This library contains the base version of the members to be merged. The library name entered must be an existing library.

Production member (PRODMBR)

Specify the name of the first member that changes are considered for selection from and merged into the target. This member is generally your current production copy (that is, the copy used to compile the object being used in your daily live environment).

Production file (PRODFILE)

Specify the name of the source file that contains the production member.

Library (Production file)

Specify the name of the source library that contains the production source file.

Name Specify the name of the file containing the base version of the members to merge. The file name entered must be an existing source file.

*NONE Use this option if BASEMBR is *NONE.

*BASEMBR Defaults to the same member entered in the Base Member field.

Name Specify the Production source member to use in the merge.

*BASEFILE Defaults to same file name entered in the Base File parameter. If the BASEMBR parameter is *NONE, then Production file parameter must not be *BASEFILE.

Name Specify the file containing the production version of the members to merge.

*BASELIB The Base source library is used as the production library.

Name Specify an existing library that is different from the Base library.

399


Enhanced members (ENHMBRS)

Specify the names of the other members to be considered for selecting changes and merging into the target. In the simplest case, this is the new release from the vendor. Up to five enhanced members can be entered.

Enhanced file

Specify the name of the source file that contains the enhanced members (up to five enhanced versions are supported).

Library (Enhanced file)

Specify the name of the source library that contains the enhanced source file (up to five enhanced versions are supported).

Source type (SRCTYPE)

Specify the source type of the members being processed. The source type allows the merge to handle language specific constraints, such as comment lines and line continuation indicators. The valid options are:

Enhanced member

Specify the enhanced member name.

*BASEMBR Defaults to the same member entered in the Base Member field.

Name Specify the member containing the enhanced version of the members to merge. Enter a specific name only if the base member is a specific name.

*BASEFILE The BASEFILE source file is used as the enhanced file. You cannot use the enhanced file parameter of *BASEFILE if the BASEMBR parameter is *NONE.

Name Specify a source file that is different from the base source file.

*BASELIB The Base source library is used as the enhanced library.

Name Specify an existing library that is different from the base library.



� *FILENAME

The source file name determines the source type. The following list provides the source files supported and the resulting source types.

� *MBR

The source type is determined from the member’s actual source type.

Source type name

Specify the source types supported by the system. Entry of this specific source type overrides the actual source types associated with the members.

Source File Source Type

QASMSRC *ASM

QBASSRC *BAS

QCSRC *C

QCBLSRC *CBL

QCLSRC *CLP

QCMDSRC *CMD

QDDSSRC *DDS

QIMGSRC *PRTIMG

QLBLSRC *CBL

QMISRC *ASM

QPASSRC *PAS

QPLISRC *PLI

QRPGSRC *RPG

QTBLSRC *TBL

QTXTSRC *TXT

QUDSSRC *UDS

401


Merge output (OUTPUT)

Specify whether to print the Target Source Merge Report and target source member.

Merge basis version (BASIS)

Specify which source member the functionally equivalent lines are drawn from.

Also indicates the version used to determine the proper source member. This affects the source change dates and markings outside of the Start and End Columns in the Target source.

Start column (STARTCOL)

Specify the position in the source line that the data comparison begins from.

The range is 1 to 200. The default is 1.

End column (ENDCOL)

Specify the position in the source line that the data comparison ends at. The range is 1 to 200. The default is 80.

Use the Start/End columns to ignore comments in languages with a columnar syntax like, RPG and DDS. Often in RPG and DDS, columns 1–5 contain markings to indicate a change or version that was added in the upgrade. If these markings exist in one version but not in another, you should consider using the start and end columns to ignore the markings.

*BOTH Produces the merged source in the target member and the Merge Report.

*FILE Produces the merged source in the target member and does not produce the Merge Report. The new merged source should replace any source in the designated target member.

*PRINT Produces the Merge Report. No merged source is output.

*LIST Same as *PRINT.

*NONE No merge source or report produced. Use this option only if Member List Analysis is *YES and no other output is needed.

*ENH Equal lines are drawn from the Enhanced source member.

*BASE Equal lines are drawn from the Base source member.

*PROD Equal lines are drawn from the Production source member.

*ENHn (where n is 1 through 5) Equal lines are drawn from the Enhanced N source member.



You should not ignore columns 1–5 for free format languages such as CLP, PL/1, and COBOL. The columns can contain valid program statements for these languages.

Case 1

This is the standard case of source that you currently use and the vendor still distributes. The source will be checked for are any changes that need to be merged.

Resulting Action:

IMRGMBR merges the three versions and puts the results in the target version member.

Case 2

This is assumed a source that you currently use, but that the vendor no longer distributes, or an object the vendor possibly renamed. You need to determine why the vendor no longer distributes it.

Resulting Action:

The function does not merge this member.

Case 3

This is assumed a source that you do not use, but that the vendor still uses.

Resulting Action:

Source Exists In...Description Merged

Case Base Prod Enh

1 Yes Yes Yes Standard case: You use (possibly modified); Vendor has retained (possibly modified)

Y

2 Yes Yes No You use (possibly modified), vendor has deleted (or has not modified)

N

3 Yes No Yes You do not use (or have not modified)

N

4 Yes No No Neither you nor the vendor use (nor you or the vendor modified)

N

5 No Yes Yes New for both vendor and you Y

6 No Yes No Written by you Y

7 No No Yes New from vendor Y

403



Case 4

Neither you nor the vendor supports this source.

Resulting Action:


Case 5

This case is vague. It could be that both you and the vendor created this source independently. If so, the two source members probably do nothing in common.

You need to decide whether you want the vendor’s source. It could be a source member received from the vendor after original distribution of the vendor’s last release. In this case, you will want the two source members to be merged with each other.

Resulting Action:

IMRGMBR merges the changes from the two source members and includes the results in the target file. Discard the target source member if the production and enhanced members are unrelated.

Case 6

You created this source member.

Resulting Action:

IMRGMBR copies this member to the target file.

Case 7

This is a new source member from the vendor. You should verify that you do want it.

Resulting Action:

IMRGMBR copies this member to the target file.



Target source member (TGTMBR)

Specify the name of the source member to receive the source that results from the merge. The merge only creates (or changes) the target member if the OUTPUT option is *FILE or *BOTH. Newly merged source replaces any existing source in the target member.

Target source file (TGTFILE)

Specify the name of the source file to contain the indicated Target source member.

Print options (PRTOPTIONS)

The print options provide the means of customizing the merge report.

All or only changed lines (*ALL *CHG)

Controls the amount of printed output on the report. The *ALL option prints the entire merged Target member, indicating that lines were functionally-equivalent (common) in all versions, and that lines were included or excluded from which members, based on the merge rules. The *CHG option causes only the unequal sections of each member to print, with indicates that lines were included or excluded from the members.

*BASEMBR The name of the member receiving the merged source should be the same as the base member name. *BASEMBR is not a valid entry if the BASEMBR parameter is *NONE.

Name Specify the name of an individual member to receive the merged source.

*BASEFILE The name of the BASEFILE source file is used as the target source file. The target file parameter must not be *BASEFILE if the BASEMBR option is *NONE.

Name The name of a specific target source file that the target member will be placed in.

Library (Target file)

The name of the library containing the Target source file.

*BASELIB The name of the BASEFILE source file library to use as the target source file library. The Target file library parameter must not be *BASEFILE if the BASEMBR option is *NONE.

Name Type a specific target source file library that the target member will be placed in.

405


Equal lines before, if *CHG

Specify the number of equal lines to print before the unequal sections print. This allows the unequal sections to print in context of the larger source member. Entry in this field has an effect only if the All or Changed Line parameter is set to *CHG.

Equal lines after, if *CHG

Specify the number of equal lines to print after the unequal sections print. Entry in this field has an effect only if the All or Changed Line parameter is set to *CHG.

Delimit changes with dashes (*NO *YES)

Specify *NO or *YES. *YES causes a line to print between each block of included or excluded source. This allows for clearer delimiting of changed areas.

Highlight excluded lines (*YES *NO)


Excluded lines indentation (0–10)

Specify whether excluded lines are placed in a different column than the included lines. This option only affects the report, not the merged source.

How to print messages

Specify how messages print.

Output queue (OUTQ)

Specify an output queue to place the merge report.

*YES Highlights by double printing the excluded lines.

*NO Does not highlight excluded lines.

*NONE Messages do not print.

*INLINE Messages print in-line or in the body of the report.

*SUMMARY Messages print in the summary section at the end of the report.

*BOTH Messages print in the body of the report and at the end of the report in the summary section.

*JOB Uses the output queue associated with the job.

Name Specify an output queue name.



Library (Output Queue)

Specify the library the output queue is located in.

Hold spooled files (HOLD)

Specify if the report output is held on the output queue.

Submit (SUBMIT)

Specify whether to submit the report to batch or run interactively.

Job description (JOBD)

Specify the name of the job description used for the submitted job. The default value is MWIJOBD.

Library (Job description)

Specify the library the job description resides in.

Name Specify a library for the designated output queue.

*LIBL Searches the library list for the specific output queue.

*FILE Holding of the report output is determined by the printer file definition. The printer files used are NVMGMBP for Member Analysis report and NVMGSRP for merge report.



*YES Submit the report. If you specify *ALL or *SRCMBR for the object, the name of the submitted job is CRTOBJ. For a specific object, the name of the object is the name of the submitted job. The function uses the job queue specified on the Job description (see the following parameter).

*NO The report runs interactively.

Library-name Type a specific library for the job description.

*LIBL Searches the library list for the specific job description.

407


Merge Member Merge Report Listing



Lines with blanks under the Action and File headings were functionally equivalent in all three, source members. The actual selected source line originates from the member specified by the Merge basis (Enhanced-1 in the above example).

New sequence lines 6 through 11 indicate two possibly dependent changes that must be manually merged.

The shaded lines containing a 3+ (New sequence: 12 and 25) were identified as equal (or functionally equivalent) in the Production and Enhanced versions.

The shaded line new sequence 13 was included because the Production version was identified as functionally equivalent (although different).

Merge Member Report Field Descriptions

The following fields display on the Merge Member Report.

New Seq(uence)

This is the sequence number in the Target source member. If a message was generated for the preceding lines, the Message ID is listed in this column and an asterisk is printed at the far-left side of the report.

Action

There can be one of two entries in this column: INC (include in Target source member) or EXC (exclude from Target source member). INC indicates a line that was not in the Base version, but was added in one or more of the Production and Enhanced versions. This line is added to the Target source member. EXC indicates a line that exists in the Base version and either the Production version or one of the Enhanced versions. This line is not in the Target Source member.

If changes exist from two or more versions at the same place in the source (INCludes and/or EXCludes), the function issues a message and all sets of changes are incorporated into the Target Source member. You must review these situations to identify whether the changes are compatible, mutually exclusive, or if they must be blended.

Where this column is blank, the same line existed in all versions.

File

Indicates where the line of code is either included or excluded. The entry here is one of the codes from 1 to 7, corresponding to the different versions listed at the top of the report. If there is no entry in this column, the line

409


shown comes from the Merge Basis source member. A plus (+) sign printed to the right of the file code indicates if a line was included from the Production and one of the Enhanced members.

Org Seq (Original Sequence Number)

This is the sequence number that an included line had in its original member.

On report lines listing action messages, three asterisks appear in this column.

Source Data

Under this heading are the actual lines of source. If a line was excluded from the Target (see Action above), the function inserts an arrow into the line, and moves the source over a designated number of spaces to the right as specified on the Execution Options.

Note that when comparing source lines in RPG and DDS source, Merge to Create Target Source can ignore the characters in positions 1 through 5.

Action messages

On report lines that have action messages, the message severity followed by the message text are shown in the Source Data section.

Records

The number of records in the corresponding source member.

Include

The number of records unique to the corresponding version.

Exclude

The number of records in the corresponding version that are not in the target version.

Matched

The number of common records between all versions.

%

The percent of records matched.

Func equiv (Functional equivalence)

The number of records adjusted by functional equivalence processing.



Exec

The number of executable lines included in the Include and Exclude counts.

Blank

The number of blank lines included in the Include and Exclude counts.

Comment

The number of comment lines included in the Include and Exclude counts.

411

BA P P E N D I X

Glossary

action An action is used to indicate what process will be performed on a member/object. The action is specified when checking out a member/object and when creating a request for a member/object. The following actions are valid for checking out and for creating a promotion request.

� 1 = Change

� 2 = Create

� 3 = Delete

� 8 = Regen (only valid for COOL:2E model objects)

� 9 = Recompile

application path The term application path refers to the standard and emergency paths that are set up in Work with Projects and Work with Environments. Application paths are used in the development cycle to define the flow of member/objects between environments. They are used to determine the location of source and related objects for an object, for example, when compiling with a check out or create request action of recompile.

There are two basic types of application paths:

� Project path: This term refers to the standard and emergency paths that are set up in Work with Projects. A path can be defined for each project, representing the development flow of member/objects associated with the project. This type of path is beneficial for those who routinely use multiple testing environments, particularly when the test environments are determined on a project-by-project basis. For example, if two projects are active in development, it is typical that one environment path is used by one project and another environment path is used by another project at the same time. By using a project path rather than an environment path, you can avoid having to perform overrides when checking out and promoting items associated with one project that may not be associated with the second project.

� Environment path: This term refers to the standard and emergency paths that are set up in Work with Environments. A path can be defined for each production environment, representing the

413

application set

development flow of member/objects associated with the environment. Environment paths can provide control while eliminating redundancy when checking out and promoting.

An authorized user (usually the System Administrator) defines the exact flow objects take—from the time they are checked out from the production environment, through the development and testing environments, and finally back to production.

A path restricts access so that the members/objects cannot move outside of the defined flow. This allows defaulting of the check out from and to environments, as well as the default promotion request from and to environments. Users can be restricted to the defined paths, preventing any circumvention of the predefined flow of work back into production, or they can be authorized to override a default path.

In the Check Out and Create Request functions where application paths are used, a project path precedes an environment path. In other words, if a project is specified that has a defined path, that path is used; otherwise, the environment path is used.

NOTE

The term application path should not be confused with the term path, which refers to support provided by for IFS objects.

application set An application path refers to AS/SET application sets. It is a partition of the ADK product where definitions such as programs, data models, files, and fields are stored. An application set refers to an environment such as development or production, where copies of the application definitions are stored.

archive recovery Archive recovery is a function used to recover from or back out of a promotion request. It is also called rollback.

archiving Archiving is a function that duplicates an existing production source member, object, or file (without data) into a designated library, before the object to be implemented is moved into production. You use the archive to store members and objects or file information. Members/objects are placed in the archive during the Move Request function. Archiving is optionally enabled, at the environment level. You can archive up to 99 versions of files, objects, and source.

The archive serves two purposes. The first is to support Archive Recovery or Rollback of a request. Second, the archive can be used to browse previous versions of a source member.


batch programs for AS/SET

batch programs forAS/SET

Batch programs for AS/SET are an ADK program type designed to perform file-processing functions.

No on-line display panels are involved in batch programs.

binding directory A binding directory is a list of module names and service program names that may be needed when creating an ILE or Service program. It is not a repository of the modules and service programs; rather it allows them to be referred to by name and type.

change controlledmodel

A change controlled model is a COOL:2E model that is set up to work with COOL:Xtras CM. Its model value *CHGCTL is set to be that of the COOL:Xtras CM product library.

change list A change list is a COOL:2E model object list defined in COOL:Xtras CM. You can explicitly create a model object list for a given COOL:2E environment or create one when you check out a COOL:2E model object during an editing session. This is referred to as a model object list in COOL:Xtras CM.

check in Check in describes the process of promoting a member/object back into production after it has been checked out and the lock is removed.

check out Check out takes a member/object from a production environment (or quality assurance environment), copies it to a developer’s development library or environment, and places a lock on it. This makes the member/object in use by the user who checked it out.

clipboard The clipboard is a list of items. The clipboard allows you to select a list of items and then process that list by another function. The clipboard holds the selected items until they are processed. Once you have added an item on the clipboard, you can display, remove, or add more items to the clipboard. At least one item must exist on the clipboard before you can process a clipboard function. Once you process the function for the items on the clipboard, the items on the clipboard are listed within that function.

compile requests Compile requests is a function that compiles source members into work libraries and moves non-source-based objects into object work libraries, according to migration request instructions. Developers normally perform this task.

concurrentdevelopment

Concurrent development is when two or more versions of a member/object exist at the same time. When concurrent development occurs, the multiple versions of the member/object are considered in conflict with each other. The ability to check out a member/object for concurrent work can be restricted to certain users. Concurrent development results when you check out a member/object that is already checked out.

415

conflict

conflict When concurrent development is started, a conflict is created for that specific member/object. Conflicts must be resolved before a member/object can be promoted.

constraint A constraint is a set of rules that defines the relationship between two files. For example, a constraint can be used to maintain the integrity between a customer header file and a customer detail file, by not allowing changes to the header table file without changing the detail file. See trigger.

create request Create request is the function of initiating a promotion request to migrate source and/or objects to production or quality assurance environments. Developers normally perform this task.

currency Currency is a COOL:2E model object that all other related model objects point to; an object that has usage. A non-current object has no usage in the model.

current model object The current model object is what you can view or edit in the COOL:2E model. Multiple versions of the model object can be checked out to and accessible from one or more model object lists. However, only the current version displays in the model.

data model A data model is an entity defined in ADK repository that refers to one or more files, their associated fields, and their associated relationships.

design request A design request is a DesignTracker feature used to indicate what work needs to be done. DesignTracker is automatically installed when you install library MKSIM.

design requestapproval

A design request approval can be:

� 0 = No

� 1 = Yes

� 2 = Pending

For an approval type of:

� 1 = Development

� 2 = Test

� 3 = Production environment

design requestdisposition

The design request disposition can be:

� 0 = Not Ready (always set to 0 when entity is added to the list)

� 1 = Ready for checkout (entity is ready to be checked out)


design request status

� 2 = In development (entity is checked out and in development)

� 3 = In quality assurance (entity is checked out and in QA for testing)

� 4 = Completed (entity was moved into a *PRD environment)

design request status The design request status is the current state of a design request. The Implementer entity controls related to design request status are: Allow ready to check out, Allow check out, Allow promotion to a test environment, and Allow promotion to a production environment.

There can be different approval types per user:

� 1 = Development

� 2 = Test

� 3 = Production

Upon approval from all designated users, the status can be automatically changed by DesignTracker. You set up the approval/status relationship in DesignTracker System Control.

directory See IFS directory.

DLO Document Library Object (DLO) refers to a file or folder that exists in the QDLS file system.

These objects, referred to in Implementer as IFS objects, are supported for change management. See IFS object, IFS file, and IFS directory.

document Document is a term that is used as part of support provided for IFS objects. A document is a special type of file created by OfficeVision/400 and stored in the QDLS space. A document is a file, but a file is not necessarily a document.

It is the OS/400 term for any object residing within an IFS folder on the iSeries 400. Within Implementer, the term IFS object is used.

environment An environment identifies a collection of libraries, object owners, authorized users and rules about how these libraries are controlled by Implementer. See related environment.

environment ID An environment ID is the sequential number assigned to each target environment on a promotion request. This number, which starts at one and increments by one, is used for naming some libraries, save files, and other objects used as part of the promotion request.

417

environment library list

environment librarylist

An environment library list is a list of up to 250 libraries used for compilation in the environment. Of these, 248 entries are available for your use. The last two entries are reserved for QTEMP and the Implementer work library on the promotion request. In addition, the environment library list is used when processing special commands for the request.

environment type Environment type is a field that defines whether an environment is for production (*PRD), quality assurance (*QAC) or testing (*TST). This ensures that the development staff does not attempt to copy members/objects from one production environment to another.

export An export is the process of saving LANSA objects into a device or save file, to move them from one LANSA partition to another, on the same or different machine.

export list An export list is a named list of LANSA objects to be exported from one LANSA partition to another. There are two types of lists provided by LANSA: One is visible to LANSA users and maintainable within the LANSA menu. The other is not visible to you, but provided for object management, system vendors. An export list is created in Implementer whenever it copies LANSA objects from one partition to another partition.

file The term file is used as part of the support for traditional OS/400 database files and the objects in the IFS referred to as IFS files. To avoid confusion, whenever an IFS file object is referred to in Implementer, it is referenced as an IFS file.

Implementer supports all traditional OS/400 files. For example, SQL tables, indices, and views, physical files, logical files, display files, message files, and printer files. See IFS file.

folder The term folder is used as part of support provided by Implementer for IFS objects. It represents the IBM OS/400 term for a collection of documents in a single location. This term corresponds to IFS directory, which is the term used within Implementer. See IFS directory.

function The term function describes a particular COOL:Xtras CM menu option or command. For example, the Activity Report function refers to the interactive menu option activity that prints the Activity Report and the submitted job that prints the report.

A function is also a specific type of COOL:2E model object that can be promoted (FUN); an executable program, or collection of programs.


function redirection

function redirection A function redirection is when a COOL:2E function is checked out and a new version of that function is created, function redirection occurs to ensure that the selected version of the model object is current and has its internal references directed towards the other object in the model. See currency.

IFS directory The term IFS directory is used as part of support provided by Implementer for IFS objects. The IFS directory is the location of an IFS file. When used in this capacity, the directory usually refers to the full directory path. See path.

This term corresponds to the OS/400 term, folder. In Implementer, these are referred to as directories.

IFS file The term IFS file is used as part of support provided by Implementer for IFS objects. It refers to the contents of IFS directories on the iSeries 400. It is the PC term for any object stored in a directory. Some examples of files are executable programs, database files, or video segments.

Within Implementer, the member/object name for an IFS file contains the IFS file name and the object code contains the dot and extension. If the file name has no extension, the object code is just represented by a dot. Any name longer than eight characters is converted, and any extension longer than six characters (allowing one position for the “.”) is converted.

For example:

The combination of the IFS file name and extension is known as the environment relative name. Environment relative names up to 100 characters are supported. If an environment relative name is greater than 100 characters, you are required to set up an environment where the environment path includes a deeper structure.

See IFS directory.

IFS object The term IFS object is used as part of support provided by Implementer for IFS. This term refers to the objects (IFS files and directories) that can be stored in the integrated file system on the iSeries 400 (IFS objects are not stored in libraries). It represents the IFS file names, directory names, or complete directory contents that are entered in check out and when creating a promotion request. These IFS files and directories are listed on reports and in audits.

IFS File Name Member/Object Name Object Code

HelloAS400World.class HELLOAS4~1 .CLASS

HelloAS400World HELLOAS4~1 .

419

implementation object

The three types of IFS objects that Implementer manages are:

� IFS Files: You can specify the check out or promotion of individual IFS files using member/object and object code. Each file checked out or promoted is listed on reports and audits.

� IFS Directories: You can specify the check out or promotion of the entire contents of subdirectory (including any subdirectories and their contents) using the backslash (\) object code. For example, if you check out or promote \dir2, all files and directories listed in subdirectory 2 would be included. On reports and audits, only the directory name is listed (dir2).

� *.*: You can specify the check out or promotion of the entire contents of an environment’s directory (including files and subdirectories and their contents) specifying *.* as the object name, and a backslash (\) as the object code. For example, if you check out or promote IFS\dir using the *.* specification, all IFS files and directories in IFS\dir would be included. Reports and audits would show member/object *.* to indicate that all contents were affected.

implementation object An implementation object is the resulting OS/400 source and objects that are created from the generation of a COOL:2E model object. For example, a function will usually create source and objects for a program, display file, and help text. The source and objects generated for these objects are referred to as the implementation objects.

Implementer Receiver The Implementer Receiver is a component of Implementer that resides on each remote system that changes can be distributed to.

import An import is the process of restoring LANSA objects from a device or save file created in an export activity into a different partition.

issues Issues are a feature of Integrity Manager. They are used to track changes in the software development cycle. For example, your administrator can configure Integrity Manager in a way that a problem issue may be associated with a solution issue for easy tracking and monitoring of both issues. Each issue has an audit trail, which may be used to evaluate internal processes for the effectiveness of the problem resolution process. In effect, issues track all aspects of any engineering endeavor.

JDE JDE stands for J.D. Edwards.

JDE data dictionaryelements

JDE data dictionary elements represent a record in the dictionary for every field used in the system. This file controls how a field acts and edits on the screen and report. In addition, it controls the edit processes of the field for validation.


JDE dream writers

JDE dream writers JDE dream writers have two parts that break down as follows: data selection that is translated to OPNQRYF or logical file, and processing options that are user-controlled program passed parameters.

JDE menus JDE menus are data records keyed to a menu name. This allows changes to menus without the need of programming.

JDE soft coding orvocabulary overrides

JDE soft coding or vocabulary overrides are literals on JDE screens that are not constants in the DDS of a screen object, but are retrieved from a file that is keyed to a program name. This allows changes to literals without the need for programming.

JDE softwareinventory or member

masters

JDE software inventory or member master is a file where a record for each object in JDE is kept. This file contains the general severity level for compilation and other details for JDE.

JDE special objects JDE special objects are objects supported by J.D. Edwards such as user-defined codes, DREAM Writers, Member Master, Data Dictionary, Soft Coding, and Menus.

JDE traditional objects JDE traditional objects are traditional objects that require J.D. Edwards compiling, for example, RPG programs, CL programs, Assemblers (ASM).

JDE user-definedcodes (UDC)

JDE user-defined codes (UDC) is a generic table system for data field validation, controlled by three keys:

� 1—System number

� 2—Table name

� 3—Element

keyword restriction A key restriction is a facility that restricts access to command keywords of an object code. It is used to restrict sensitive keywords such as the User Profile (USRPRF) keyword that controls adopted authorities.

LANSA function A LANSA function is an executable OS/400 program defined by you and created by LANSA.

LANSA objects LANSA objects are objects created in LANSA such as files, fields, processes, and functions. These objects are not necessarily OS/400 objects.

lock A lock is applied to a member/object when it is checked out. It is automatically released when the member object is promoted to a production (*PRD) environment.

� A Standard lock is the user action that created the lock through a standard check out.

421

member/object

� An Emergency lock is the user action that created the lock through an emergency check out.

member/object A member/object is an item under Implementer control. This can be an object or source stored in a library, an element managed by a CASE tool (such as COOL:2E), or an IFS file. For example, this refers to an object for a data area, but for an RPG program, this refers to the member and object.

model object A model object is a COOL:2E object that can be checked out. COOL:2E has eight types of objects that can be checked out. They are access paths (ACP), applications (APP), arrays (ARR), conditions (CND), field (FLD), files (FIL), functions (FUN), and messages (MSG).

model object list A model object list is a COOL:2E feature that allows some of the objects in a model to be grouped together in a named list. For change control purposes, model objects are checked out to lists to indicate a change was made or will be made to the objects. The model object lists are attached to the COOL:2E model and can be selected for COOL:2E promotion requests.

NOTE

Once you use a model object list for check out, it becomes a change list.

model object name A model object name is the 25-character name given to a COOL:2E model object.

move request A move request is the task that moves all object/sources from the environments or libraries to the target environments. In addition, it performs any request instructions that impact production data (for example, MRGMSGF). This function moves previous versions of source and objects to the archive libraries before the move, if specified.

My Workbench The Workbench is a panel where a developer can perform all necessary development work. The panel contains the items to be worked on, and provides access to all necessary tools to complete the development of the items and move them off the Workbench. The tools allow you to select and add items to the Workbench, access standard development tools to edit, compile and test items, and access user-defined tools through user-defined options. From the Workbench, you can access promotion functions to move completed items back into production, and book time against projects.


object code

object code An object code is used to define a type of object or member to be promoted. The object code in Implementer combines information from the OS/400 object type and source type. For IFS files, the object code is the file extension. Object codes are user-defined.

owning model object An owning model object is the name of the model object that owns another model object. For example, a file (FIL) object always owns an access path (ACP) model object. Not all model objects have an owning model object.

partition A partition is a division of a LANSA system that has it’s own field references, files, and processes. Each partition in LANSA is completely independent and no cross-referencing is allowed across partitions. A partition in LANSA is comparable to an environment in Implementer.

path The term path is used as part of support provided by Implementer for IFS objects. It represents the location of a directory or subdirectory. It is the complete list of all directories and subdirectories between the root directory and the directory being identified. The subdirectories in the path are separated by a backslash (\).

For example, to identify the path of the SYSTEM directory, which is nested in the WINDOWS directory, which stems from the root directory, the notation would be \WINDOWS\SYSTEM. (See qualified name and application path).

Implementer supports three paths in the IFS structure:

� Project relative path is the portion of the path that is unique to each object in the environment path.

For example: \SUBDIR\PROGRAM.EXE

� Environment path is the path specified at the environment level and is common to all IFS objects in that environment.

For example: \MKS\DEMO\PRD\INVENTORY

� Full path is the environment path appended to the project relative path.

For example: \MKS\DEMO\PRD\INVENTORY\SUBDIR\PROGRAM.EXE

NOTE

Be aware of the distinction between the term path and the term application path, which refers to standard or emergency paths for a project or environment.

423

primary target environment

primary targetenvironment

A primary target environment is the first environment in a series of multiple target environments. The primary target environment is used in Create Request to check the existence of the target members/objects (to determine if the action for a member/object should be Create or Change).

process A process is a logical group of related functions. For example, a process called ORDERENTRY consists of multiple functions such as sales order maintenance, credit limit check, and sales order print.

project Projects are used in Implementer to document why a change is made. A project reference can be used to check out and promote a member/object.

promotion Promotion takes members/objects from one environment (or library) and moves them forward to a target environment. In addition, the term refers to the whole process of returning a member/object back into production after it has been checked out (compile and promote from Development to QA, and QA to production).

promotion request A promotion request is a collection of related source members, source-based objects, non-source based objects, or non-OS/400 objects to be promoted to production libraries or quality assurance.

qualified name The term qualified name is used as part of support provided by Implementer for IFS objects. It represents the path and file name.

For example, the qualified name of the SYSEDIT.EXE file stored in the WINDOWS\SYSTEM directory is \WINDOWS\SYSTEM\SYSEDIT.EXE.

related environment Related environment is the relationship of an environment to other environments, in the format of an ordered list. This relationship is defined in Work with Related Environments. Related environment information is used in check out to display the member/object lists and related objects in different related environments. It uses the same order (sequence) to find a member/object in the list.

repository Repository is an entity within the ADK product where you can create and maintain files, fields, data models, and reusable program specifications, such as action subroutines.

requester A requester is the user who creates a promotion request.

request number A request number is the unique alphanumeric value assigned by Implementer when a new promotion request is created. It is used to identify the promotion request.


request status

Beginning with 0001, the number increments by 1 for each new promotion request until number 9999 is reached. When this occurs, the left most position begins with an alpha character and the other positions reset to 0 (zero). Reading from right to left, the cycle continues until each position goes through the range 0–9 and A–Z. When the number ZZZZ is reached, the scheme automatically resets to number 0001.

request status Request status describes where a promotion request is within the promotion cycle. It describes what steps have been performed for the request and what remains to be done.

required objects Required objects are traditional source and executable objects generated from AS/SET program definitions. This contrasts to the related object concept used for traditional objects that, for example, relates logical files to physicals and to the programs that refer to them.

reset authorities Reset authorities is an Implementer function that revokes all object authorities for the libraries as specified in the environment, then grants object authorities based on the authorities from the environment authority table.

session model list A session model list is the default model object list assigned to you when you begin a COOL:2E editing session. This model object list usually defaults to your OS/400 user profile. You should not use the default session model list as a check out model object list. Instead, change the default value using the Edit Model Profile Editing options on:

the Access to model field value of *DSNR on the Change User Capabilities panel, the COOL:2E Designer (*DSNR) menu, or make the model users create and use their own object model list.

stage library A stage library is an Implementer work library used to prepare (stage) each object before it moves into the target environment. The setting of object authorities, physical and logical members, and database file data occurs while the object is in this library. A stage library exists while the move is in process.

step A step refers to one of the up to four phases required to complete a request. They are (in order) Model copy (if a COOL:2E environment) or Export (if a LANSA environment), Compile, Distribute, and Move.

� The Model copy step only applies to COOL:2E special environments.

� The Export step only applies to LANSA special environments.

� The Compile step is optional.

425

subdirectory

� The Distribute step only applies to requests that contain remote target environments.

� The Move step is required for every request.

subdirectory This term subdirectory is used as part of support provided by Implementer for IFS objects. It refers to a directory and its contents that are stored within another directory. This term corresponds to the OS/400 term, folder. In Implementer, these are referred to as directories. See IFS directory.

surrogate A surrogate is the internal identifier to each COOL:2E model object.

target environmentgroup

A target environment group is a group of environments promoted to simultaneously. The target environment groups are used when you create a promotion request to display more than one environment. The target environment group eliminates the need to select each environment every time a promotion request is created.

trigger A trigger is a set of actions that are executed automatically whenever a specified event occurs to a specified SQL-based table. An event can be an insert, update, or delete operation. The trigger can be run either before or after the event. Triggers are used to preserve program to table integrity, by checking on or changing data in a consistent manner. They help to maintain the integrity of a database by preventing incorrect, unauthorized, or inconsistent changes to data. See constraint.

version For COOL:2E environments, a version is a copy of a model object that is created in the same model. Only functions (FUN) and messages (MSG) can have multiple versions or are versionable. Versions are created by COOL:Xtras CM when you check out a model object that is previously checked out and when archiving occurs during the move step.

version group A version group consists of all of the versions created for a model object. Only one version in the version group will be the current version.

workbench See My Workbench.

work library A work library is a temporary library Implementer uses during promotion to help ensure the orderly movement of objects and source into the correct target libraries. The work libraries only exist while a promotion request is still open (the status is not complete).


Index

Symbols*DTAARA object type

related objects 139, 167*FILE object type

related objects 139, 167*PRD environment type 40*QAC environment type 40*TST environment type 41

AABSTRACT integration

access from Implementer 378overview 378user-defined options 378using ICHKOUT command 156version requirements 378

Actionchange 98, 137, 147, 181, 350, 413

check out 120create request 194

create 98, 194, 350, 413defined 413delete 98, 350, 413

check out 121recomp 98, 201, 256, 261, 262, 413regen 98, 348, 350, 413

Activity Report 25Add to Clipboard (IADDCBD) command 60Add to Clipboard IFS (IADDCBDIFS)

command 60Adopting authority 21Advanced System Concepts

(ABSTRACT) 378Allocating objects

during move step 225American Software integration

compiling Cobol programs 330message file considerations 330object codes for checkout and

promotion 329overview 329

AOS Message Manager integration 380Application path

defined 413feature overview 19project paths 107

Application setdefined 414

Archive library 296Archive recovery 300

defined 414of related requests 204with object version stamping 252

Archive reportsArchive History Report 26Archives by Environment Report 299Archives by Request Report 299Archives per Tape Report 299

Archive to tape 297change volume ID 299menu (IMARCTAP) 297reports 299restoring 299saving 298

Archivingcheck out 303

COOL:2E model objects 303design request 303environment 303LANSA objects 303library 303project reference 303

defined 414environment library 42logical files 264, 296multiple target environments

multiple objects 296object renaming 296object version stamping in rollback 252objects not compiling source 300physical files 264promotion internals 264, 296promotion request created during 300same library, multiple

427

Index

environments 296single change or entire request (multiple

objects) 300source

compiling 300renaming 296

tables and physical files 296usually production only 296

AS/NET integration 381AS/SET integration

archiving definitions 335AS/SET commands 335checking out 331commands 335definitions

special characteristic 118dependency checking 332override promoting generated source/

object 336overview 330promoting 334remote distribution 335X file management 182, 335

Authorityenvironment information to objects 42,

43LANSA Export/Import 152, 205OS/400 security 19security administrator rights 38

MWIPROD 38QSECOFR 38

security riskobject codes 188

user 151Authority method

toggle 189Authorization list

environment information 43

BBase file

ICMPMBR parameter 387IMRGMBR parameter 399

Base memberICMPMBR parameter 386IMRGMBR parameter 398

Batchcreate request in batch 173

Batch programsin AS/SET, defined 415

Before you begin 1Binding directory

defined 415BPCS integration

compiling 223overview 336

Build Listfor changed members 194results in check out 115

Build member/object list, see Build List 45

CCapabilities

restricted 43user 43

Changeoverview 53

Change controlled model, defined 415Change delimiter

IMRGMBR parameter 406Change list, defined 415Check In

defined 415Check Out

adding related objects 139AS/SET definitions

special characteristic 118assign revision numbers 122comment 123concurrent development from

Workbench 69COOL:2E model object lists 342create member/object during 121defined 415emergency

from Workbench 69one step method 305

for concurrent development 136for reject 116from Clipboard in Workbench 69ICHKOUT command 156IEXCCKOCMD special command

overview 245substitution variables 233

IFS files and directories 127methods

overview 113where defined 113

multiple objects single source 123multiple occurring mbr/obj 140


Index

object name rules 155object version stamping 125one step method

determine default from environment 113

from Clipboard 58from Work with Objects 113overriding 68

overview 53PDM option 162physical file data 150related environments 120related objects 139restricting 112

object codes 112user capabilities 112

select environment 118select items after initiating, from

Workbench 66single source multiple objects 123special commands 112, 233, 245stamp objects with issue or DR

number 125status 346substitution variables 233task

check out for concurrent development 136

create member/object 121delete member/object 121ICHKOUT command 156ICHKOUT command via

PathFinder 162ICHKOUT command via PDM 162related objects 139single source multiple objects 123using the menu 112

traditional, from Workbench 66, 113using different source and object

names 151, 219using ILE object codes 148using PathFinder 167web-based, for IFS objects 135with design request 141Work with Objects, from Workbench 67

Check Out (ICHKOUT) command 156*PATH default 157

Check Out (ICHKOUTIFS) command*PATH default 131

CHGRMTRQS command 281Clipboard

add items with ADDCBDIFS

command 60add items with IADDCBD command 60create requests with ICRTRQS

command 63defined 415one step check out and promotion 58positioning in a subfile 59processing with IPRCCBD command 63

CODE/400 integration 337Cognos (Powerhouse) integration 376Commands 245

CHGRMTRQS Change Remote Request 281

IADDCBD Add to Clipboard 60IADDCBDIFS Add to Clipboard IFS 60ICHKADKDEP Check AS/SET

Dependencies 332ICHKOUT Check Out 156ICMPLRQS Complete Request 254ICMPMBR Compare Members 386ICMPRQS Compile Request 224, 256ICOMPILE Workbench Compile 79ICRTRQS Create Request 63, 196, 260IDLTLIBREF Delete Library

References 98IEXCCKOCMD check out special

command 112IEXCCKOCMD special command 231,

245IEXCRQSDTL promotion special

command 230, 236IMARCTAP Archive to Tape 297IMOVRMTRQS 256, 289, 290IMOVRQS 228, 256IMRGMBR Merge Members 398IPRCCBD Process Clipboard 63IRSTRMTRQS Restore Remote

Request 289ISETLIBL 54, 83RMVDIR Remove Directory (IFS) 217STRCM Start COOL:Xtras_CM 12STRCR Start COOL:Xtras_CM

Receiver 12STRIM Start Implementer 12, 13STRIR Start Implementer Receiver 12WRKMBRPDM Work with Members

using PDM 78YANZMDLLST 352YCHKMDLCRT 353YCPYMDLOBJ 352YCVTCNDVAL 354, 355YCVTMDLMSG 354, 355

429

Index

YEDTMDL 357YEDTMDLLST 348, 357YPRMMDLLST 352, 354YSBMMDLCRT 353

Commentsbypass in create request 87, 175in check out 123

Compare Members (ICMPMBR) command 386

Base file (BASEFILE) 387Base member (BASEMBR) 386Compare to file (CMPFILE) 387Compress blanks (COMPRESS) 389End column (ENDCOL) 390Exclude blank lines (EXCBLKLINE) 389Exclude comment lines

(EXCOMMENT) 389Hold spooled files (HOLD) 391Output queue (OUTQ) 390Print options (PRTFILTER) 390Source type (SRCTYPE) 387Start column (STARTCOL) 390Workbench 78

Compare to fileICMPMBR parameter 387

Compile command parameters 187Compile listings

promotion internals 263Compile request

defined 415from Workbench 79ICMPRQS command 224, 256overview 53start member after comp-fail 223submit compile request 220

Compile stepchange job queue during 187command parameters 187default compile order 174library list considerations

environment library list 44for vendor integration 44

object version stamping 220order

based on object code sequence 174promotion internals 262QCMDEXC program 188retain printer attributes 188with vendor integrations 223work library 222

Compiling 21Complete Request (ICMPLRQS)

command 255Completed, status 259Compress blanks

ICMPMBR parameter 389CompFail, status 258CompJobq, status 258CompPend, status 258CompRun, status 258CompSchd, status 258Concurrent development 112

check out for 136requests

defined 415Concurrent Development Report 25Conflict requests

defined 416Conflict resolution

before promotion 172Constraint

defined 416Constraints

in promotion 313Conventions 4COOL:2E

check outnot to COOL:2E session list 344status 346

commandsYANZMDLLST 352YCHKMDLCRT 353YCPYMDLOBJ 352YCVTCNDVAL 354, 355YCVTMDLMSG 354, 355YEDTMDL 357YEDTMDLLST 348, 357YPRMMDLLST 352, 354YSBMMDLCRT 353

managing EXCUSRPGM and EXCUSRSRC 359

model considerationsanalyzing model list 352change list 344check out 342, 347, 350concurrent development 349COOL:2E to traditional 354create request 352development activities 345explicit checkout 348generating and compiling 353impact analysis 359implicit checkout 348model object lists 342, 343, 344


Index

move step 354, 355object naming 345promoting model information 351regeneration 348remote considerations 363updating target model 352use change controlled model 356versionable model objects 349

model library 41model value

YFRFVNM 355YMSGVNM 355YSYSCHG 342

session list 344COOL:Xtras CM, see COOL:2E 342Create Object (CRTOBJ) command

Job description (JOBD) 391, 407Submit (SUBMIT) 391, 407

Create Requestadd target environments 199change compile commands 187copy request 195create requests in batch 173defined 416from Workbench 86ICRTRQS command 63, 196, 260member list 193methods, where defined 174object code list 192one step promotion

access Create Request panel 176optimize PF promotions 183overrides

change request defaults 205job submission defaults 186optimize PF promotions 185remove items in from

environment 205PDM option 198process overview 174promotion groups 85

evaluation 85promotion methods

one step promotions 175traditional promotions 177

selecting from locks 189special commands 229task 178

Create steppromotion internals 260

Currencydefined 416

Current modeldefined 416

Customer Support options 5

DData areas

environment library considerations 41IMEMGSTP emergency submit through

step 252, 306IMMULTOBJ 123IMREJECT 153IMWRNTRGLF 316ITAPEVOLUM 299LFREFOBJ 43PFREFOBJ 43promoting data area values 318

Data conversion programsenvironment library list 229

Data modelsdefined 416

Databasedefault library 41

Database filesenvironment 45

Database managementDDS files

optimize PF promotions 313process overview 312promoting logical files 316promoting physical files 313triggers and constraints 313

process overview 308SQL

archive and recovery of SQL DDL objects 310

build list consideration 310creating source SQL logical

files 312creating source SQL physical

files 311managing non-source SQL 309object codes for non-source

SQL 309object codes for source SQL 311process overview 311

DDM managementspecial commands for 230, 240

Deletemember/object at check out 121

Dependency checking 139

431

Index

Design Requestapprovals, defined 416change, from Workbench 101check out 141create promotion request 172defined 416disposition, defined 416entity list

select member/object 144promotion 172stamp object with DR number 125status, defined 417use multiple DRs from Workbench 99

DesignTrackerDesign Request, defined 416entity list 144

Developercreating promotion requests 181role defined 39

Development environment type 41Directory

defined 419Display files

move step considerations 225Distribute Request by System

task 273Distribution

by system 273Distribution step 256DistFail, status 259DistJobq, status 259DistPend, status 259DistRun, status 259DistSchd, status 259DLO

defined 417Document conventions 4

EEmergency

archive recovery 295, 300auto check out 302

check out 295from Workbench 304one step method 305

create request 295, 306from Workbench 306

create request submit through step 306promotion request 252promotions 252

End columnICMPMBR parameter 390IMRGMBR parameter 402

Enhanced membersIMRGMBR parameter 400

Entity Listselect member/object 144

Environment administratorcapabilities 44multiple administrators 44

Environment Groups 45Environment path

defined 414Environment Report 26Environments

archive library 42defined 417Environment ID

defined 417groups 45integrity check 45libraries 41library list

defined 418library list considerations 44object code information 45overview 40related 120, 140

multiple occurring mbr/obj 140related, defined 424source files 42special commands 22, 229types 40

defined 418Establish environment authorities, see Reset

Authorities 42Exclude blank lines

ICMPMBR parameter 389Exclude comment lines

ICMPMBR parameter 389Excluded lines indentation

IMRGMBR parameter 406EXCUSRPGM considerations 360EXCUSRSRC considerations 360Export

defined 418Export List

defined 418Expt-Fail, status 258, 370Expt-Jobq, status 258, 370Expt-Pend, status 258, 370Expt-Run, status 258, 370


Index

Expt-Schd, status 258, 370

FFile

defined 418, 419Files

join logicals 189promoting field reference files 174promoting logical files 316promoting non-source SQL tables 309promoting physical files 313

Folderdefined 418

Functiondefined 418

Function keyswork with, menu option 291

Function redirectiondefined 419

GGetting help 5Glossary 413

HHawkeye Systems, Inc. (PathFinder)

integration 382Highlight excluded lines

IMRGMBR parameter 406Hold spooled files


IIBM (NetView/DM software) 381ICHGRQSDTL Change Request Detail

command 245ICHKOUT Check Out command 156ICMPLRQS Complete Request command 254ICMPRQS Compile Request command 224,

256ICOMPILE Workbench Compile

command 79ICRTRQS Create Request command 260

via PDM 198Identify work

overview 52IDLTLIBREF Delete Library Reference

command 98IEXCCKOCMD command 112, 231, 245IEXCRQSDTL command 23, 230, 236IFS

auto-create object code 212directory upgrade during

promotion 216objects

auto create object code 134, 215checking out 127java optimization 218promoting 212

support for 18using mounted drives 18web-based check out 135web-based promotion 213

IFS directorydefined 419

IFS filedefined 418

IFS objectdefined 419

ILEconverting RPG source code 163enhanced support for 18managing ILE development 319object codes for check out 148

IMARCTAP command 297IMCMEX01 exit program 350IMEMGSTP data area 252IMMULTOBJ data area 123IMOVRMTRQS command 256IMOVRQS command 228, 256Impact analysis 20, 139Implementation object

defined 420Implementer Receiver

defined 420menu 287

Importdefined 420

IMPRFX data area 266IMREJECT

data area 153IMWRNTRGLF data area 316Integrated File System, See IFS 419Integrity Manger

using for issue management 9ISETLIBL command 54, 83Issue management solutions 8

433

Index

using DesignTracker and Integrity Manager 10

using DesignTracker, stand-alone 8using Integrity Manager and

Implementer 9Issues

stamp objects with issue number 125ITAPEVOLUM data area 299

JJ.D. Edwards

archive recovery 367archiving special objects 366data dictionary

defined 420defined 421Dream Writer

defined 421integration overview 363Menu

defined 421promoting printer files 366software inventory or Member Master

defined 421special objects

check out 365create request 365defined 421naming User Defined Codes 365promotion 366remote distribution 366

traditional object support 364traditional objects

defined 421user defined codes (UDC)

defined 421Java optimization, for IFS objects 218JDE

defined 420Job description

CRTOBJ parameter 391, 407MWIJOBD 44, 253, 256

batch programs 256Job logging level in

System Control Maintenance 253Job logs 20

audit trail information 253from promotion step 253number to retain 253

Job queue

compile step 223Implementer jobs 256

Journalingdatabase files 264logical files using MIMIX 316physical files using MIMIX 315

KKeyword restriction

defined 421KnowledgeNet (Net/Wrk400 software) 381

LLakeview Technologies, See MIMIX 316LANSA 367

archiving 370check out

comment field 118environment 118multiple functions 118object code 118

create request 369export list 175, 182LANSA object in compiled

form 175multiple functions 182object codes 182promote compiled form 182

distributionlocal environments 371remote environments 371

export/import authorities 152, 205function, defined 421object, defined 421promotion 369remote distribution 371

save file name 371save files and libraries 371Web components 367

Level checkadding related objects in promotion 207compiling 222library list defined incorrectly 44

LFREFOBJ data area 43Library

archive 42database default 41defaults, overriding 42development 41


Index

program default 41promotion work libraries 270source default 41stage 263, 264, 268

Library integrity check 45Library list

environment 44for compiling 222, 229for special commands 44for vendor integrations 44level check if defined incorrectly 44MKSIM library requirement 44setup, from Workbench 83

Lockdefined 421

Lock Report 25Locking objects

during move step 225Locks

assign multiple DRs with lock 99changing 97deleting 98removed on promote to production 112

Logging CL statements 253Logging level

promotion step 253Logical files

archiving 264, 296controlling remote promotions 316journaling 264move step considerations 225promotion internals 262, 263

Lotus Notes and Domino integration 376

MMaintain request 211Manage locks

overview 54, 97MCpyFail, status 259MCpyJobq, status 259MCpyPend, status 259MCpyRun, status 259MCpySchd, status 259Member/object

defined 422name rules 155special considerations 318status history 90table of status codes 91

Menus

command options, See Start Implementer (STRIM) command 13

Implementer Menu 12Implementer Receiver Menu 287

Merge basisIMRGMBR parameter 402

Merge Members (IMRGMBR) command 398Base file (BASEFILE) 399Base member (BASEMBR) 398Change delimiter 406End column (ENDCOL) 402Enhanced members (ENHMBRS) 400excluded lines indentation 406from Workbench 79highlight excluded lines 406Hold spooled files (HOLD) 407Merge basis (BASIS) 402Merge output (OUTPUT) 402Output queue (OUTQ) 406overview 398Print options (PRTOPTIONS) 405Production file (PRODFILE) 399Production member (PRODMBR) 399Source type (SRCTYPE) 400Start column (STARTCOL) 402Target file (TGTFILE) 405Target source member (TGTMBR) 405

Merge outputIMRGMBR parameter 402

Messagesfrom promotion step 253

MIMIX 381journaling logical files 316journaling physical files 315

MKSIM Implementer library 44Model object

defined 422Model object list

defined 422Model object name 343

defined 422Model value

YFRFVNM 355YMSGVNM 355YSYSCHG 342

Mounted drivesIFS on Windows NT Server 18

Move Remote Request (IMOVRMTRQS) command 256

Move requestdefined 422IMOVRQS command 228, 256

435

Index

remote job scheduling 280submit move 226

Move Request by Systemoverview 272task 273

Move requests, on remote system 290Move step 224

promotion internals 263MoveFail, status 259MoveJobq, status 259MovePend, status 259MoveRun, status 259MoveSchd, status 259Multiple environments

archive library per 296Multiple paths

environment on 46MWIJOBD job description 44, 253, 256MWIPROD

authoritysecurity administrator rights 38

user profileowner of work libraries 266

My Workbench, see Workbench 49

NNet/Wrk400 integration 381NetView/DM integration 381

work library 270Network Configuration 188

OObject allocation

during move step 225Object authority

environment information 43promotion internals 264

Object Code Report 26Object codes

ADDPFM 315CHGPFM 315creation command 188defined 423DTAARA, promote from lib value 318DTAARAR, retain existing value 318for IFS objects, automatic 134, 215object name rules 155PFDTA 314PFREF 174, 315

restricted per user 255Object locking

during move step 225Object name rules

in check out 155Object owner

environment information 42promotion internals 264

Object version stamping 125in archive recovery 252in promotion 251

Objectsremove in from environment 205

OS/400commands

ALCOBJ 225CHGOBJOWN 230CPYF 226CPYSRCF 226CRTCBLPGM 188MOVOBJ 266

securityauthority 19

Output queueICMPMBR parameter 390IMRGMBR parameter 406

Owning model objectdefined 423

PPanel groups

move step considerations 225Partition

defined 423Path

defined 423PathFinder integration

check out options 156, 167PDM option for check out 383user-defined options 382

Pathscheck out 46check out environment 46create request 46current location 46default 46development flow 46emergency 46environment 46environment group 46


Index

primary environment 46environment on

multiple paths 46library 46per production environment 46project path in promotion 180project paths 107standard 46

PDM 156IMPDMOPT option for create

request 198option for check out 162Workbench options 77

PFREFOBJ data area 43Physical file data

check out 150Physical files

archiving 264, 296checking out data 150journaling 264promoting PF data 218promotion internals 263retaining triggers and constraints 184

Powerhouse integration 376Prerequisites to using this guide 2Previous release support 188Primary request, see related request 201Primary target environment

defined 424Print options


Problem determinationjob log audit trail information 253options for troubleshooting 253working with failed promotions 254

Processdefined 424

Process Clipboard (IPRCCBD) command 63Product integration

user authorities 152Production environment type 40Production file

IMRGMBR parameter 399Production member

IMRGMBR parameter 399Program

default library 41move step considerations 225

Projectcreate 145defined 424

in ProjectMaster 144project paths 107

Project leaderenvironment administrator 39role defined 39

Project pathdefined 413in promotion 180

ProjectMasterprojects 144

Promotioncompleting failed requests 254defined 424field reference files 174IEXCRQSDTL substitution

variables 238IFS objects

directory upgrades 216IFS files and directories 212java optimization 218

internal processing 265level check 207logical files to remotes 316methods, overview 174object version stamping 251, 252one step method

from Clipboard 58overriding 86

optimize PF promotionbenefits 184change per request 185overriding 185process overview 183

overview 54project paths 180related objects 200related request processing 201special commands

ICHGRQSDTL command 240IEXCRQSDTL command 236

step 256substitution variables 234web-based, for IFS objects 213work libraries 270Workbench

compile 89move 89

Promotion methodscreating one step promotions 175creating traditional promotions 177where defined 174

Promotion request

437

Index

automation 256change compile commands 187change request details 208combining 181comments 179

bypassing 175disable comments 87

completing failed promotions 254created in archiving 300defaults

in user profile 255in Work with Environments 255

defined 171, 424difference between emergency and

standard 252distribute by system

move all 273overview 272

emergency 252environment selection 45move request by system

move all 273overview 272

move requests on remote system 290overrides

change request defaults 205job submit defaults 186optimize PF promotion 185remove items in from

environment 205product integration 255remote

job log returned on failure 253request numbers

number scheme 173when reset 173

restore remote request 289source file length 226status 171

CompSchd 258DistSchd 259Expt-Fail 258, 370Expt-Jobq 258, 370Expt-Pend 258, 370Expt-Run 258, 370Expt-Sched 258, 370MoveSchd 259

steps 171what is included 171work library 265work with, on remote system 288

Promotion request status

Completed 259CompFail 258CompJobq 258CompPend 258CompRun 258DistFail 259DistJobq 259DistPend 259DistRun 259MCpyFail 259MCpyJobq 259MCpyPend 259MCpyRun 259MCpySchd 259MoveFail 259MoveJobq 259MovePend 259

QQCMDEXC program

used for compiling 188QRPLOBJ library

promotion internals 264use during move step 225

QSECOFR user profilesecurity administrator rights 38

Qualified namedefined 424

RRejecting changes from Quality

Assurance 116Related environments

defined 424Related objects 139, 201

*DTAARA object type 167*FILE object type 139, 167*MODULE object type 139*SRVPGM object type 139checking out 139Hawkeye considerations 201process overview 200processing considerations 203recompiling 256related request processing 201selection 139

Related requests 201archive recovery of 204displaying and selecting 203


Index

promoting 202setup requirements 204

Remote job scheduling 280Remote menu

using 287Remote requests

move on remote 290restoring 289work with on remote 288

REPLACE parameter 225Reports

Activity Report 25Archive History Report 26Archives by Environment 299Archives by Request Report 299Archives Per Tape Report 299Concurrent Development Report 25Environment Report 26job logs 20job logs, for problem determination 253Lock Report 25Object Code Report 26Request Report 25User Profile Report 26

Repositorydefined 424

Request numberdefined 424resetting 173sequencing 173

Request Report 25Request status

defined 425MoveRun 259per environment 258per multiple environments 258variations per host/remote 258

Requesterdefined 424

Required objectsdefined 425

Reserve namemember/object at check out 121

Reset authorities 42defined 425

Resolve a conflicttask 248

Restoringarchives from tape 299remote requests 289

Review work detailsoverview 53

Revision numberassign in check out 122

RLUfrom Workbench 78

RMVDIR special commandfor directory upgrade in promotion 217

ROBOT integrationscheduling 288

RPG source codeconverting in ILE 163

SScheduling

promotion steps 256, 257remote jobs 280ROBOT 288

SDAfrom the Workbench 78

Secondary request, see related request 201Session model list

check out 344COOL:2E 344defined 425

Set to Environment Library List (ISETLIBL) command, overview 54

SEUfrom the Workbench 70, 71

Single source multiple objectat check out 123

Sourcedefault library 41removing in from environment 205

Source and object names, differentusing in check out 151, 219

Source fileenvironment definition 42length 226

Source typechanging 226ICMPMBR parameter 387IMRGMBR parameter 400

Special commands 245environment level 22, 229for DDM management 230, 240for directory upgrade in promotion 217for java optimization 218IEXCCKOCMD Execute Checkout 112,

231, 245IEXCRQSDTL Execute Request

Detail 23, 230, 236

439

Index

in check out 233library list considerations 44processing 229promotion internals 265substitution variables 236

Special object considerations 318SQL

archiving tables 296trigger and constraint support 184

Stage library 263, 264, 268defined 425

Stagedobjects 222source 222

Start column (STARTCOL)on Compare Members command 390on Merge Members command 402

Start COOL:Xtras_CM (STRCM) command 12

Start Implementer (STRIM) commandmenu options 13

*ACTRPT 13*ARCHRPT 13*ARCRCV 13, 301, 302*CHKOUT 13, 136, 178*CMPRQS 13, 89, 90, 220*CONDEVRPT 13*CRTRQS 13*ECHKOUT 305*ECRTRQS 306*ENVRPT 13*JOBLOGINQ 13*LCKRPT 13*M1 or *MENU1 13*M2 or *MENU2 13*M3 or *MENU3 13*M4 or *MENU4 13*MNGCONDEV 13*MOVRQS 13, 226*MOVRQSSYS 13, 273, 275, 277*NETCFG 13*OBJCDERPT 13*RQSINQ 13*RQSMNT 13, 211*RQSRPT 14*SYSCTLMNT 14*USRRPT 14*WRKBCH 13, 95, 97, 98*WRKENV 13*WRKENVGRP 13*WRKFNCKEY 13*WRKOBJ 13

*WRKOBJCDE 13*WRKPRJ 13*WRKUSR 14

options 12Status

CompFail 258CompJobq 258CompPend 258CompRun 258CompSchd 258DistFail 259DistJobq 259DistPend 259DistRun 259DistSchd 259Expt-Fail 258, 370Expt-Jobq 258, 370Expt-Pend 258, 370Expt-Run 258, 370Expt-Schd 258, 370MCpyFail 259MCpyJobq 259MCpyPend 259MCpyRun 259MCpySchd 259member/object status codes 91member/object status history 55, 90MoveJobq 259MovePend 259MoveRun 259MoveSchd 259

Stepdefined 425

Structured Query Language, See SQL 184Subdirectory

defined 426Submit

CRTOBJ parameter 391, 407Substitution variables

for check out 233for IEXCCKOCMD 233for IEXCRQSDTL 238for promotion 234for special commands 236

Subsystemcompile step 223

Support options 5Surrogate

defined 426System administrator, role defined 38System Control Maintenance

IFS object code creation 212


Index

job logging level in 253job queue 256number of job logs to retain 253

System Software AssociatesAS/NET integration 381AS/SET integration 330BPCS integration 336

TTape distribution

work library 269Tape, archiving to 297Target environment group

defined 426Target file

IMRGMBR parameter 405Target source member

IMRGMBR parameter 405Task

associate multiple DRs to a lock 99change a design request 101change a lock 97check out

add related objects 139create a member/object 121delete member/object 121for concurrent development 136from menu 112from PathFinder 167ICHKOUT command 156PDM option 162select member/object 112select member/object by object

code 112single source multiple object 123type in member/object 112with design request 141Work with Objects 112Workbench 112

compile requestICMPRQS command 224submit compile request 220

COOL:Xtras CMsubmit compile request 220

create promotion requestadd target environments 199by member list 193change overrides 205copy request 195ICRTRQS command 196

object code list 192PDM option 198select from locks 189special commands 229

create traditional promotion requestby locked source member 178

delete a lock 98edit members

SEU option 71Workbench merge option 79Workbench RLU option 78Workbench SDA option 78Workbench SEU option 70Workbench WRKMBRPDM

option 78emergency check out 304emergency create request 306move request

IMOVRQS command 228submit move 226

reject from *QAC 153request maintenance 211resolve a conflict 248Workbench

compile 89create request 86inquiry 95move 89

Testcompile, from Workbench 83creating promotion requests 181environment type 40overview 53

Tester, role defined 39TGTRLS parameter 188Third party compile procedures 223Time entry

overview 54Trigger

defined 426Triggers and constraints

in promotion 184, 313Troubleshooting

completing failed promotions 254problem determination 253

UUser

ASP 225work library considerations 266

441

Index

authorities 151capabilities 43roles 38

User defaults, in Workbench 75User Profile Report 26User-Defined options

from Workbench 17, 56, 72USRPRF parameter 188Utilities

environment/library integrity check 45working with function keys 291

VVendor integration

ABSTRACT 378American Software 329AOS Message Manager 380application software 328AS/NET 381AS/SET 330BPCS 336CASE products 328CODE/400 337J.D. Edwards 363LANSA 367Lotus Notes and Domino 376MIMIX 381Net/Wrk400 381NetView/DM 381PathFinder 382Powerhouse (Cognos) 376Utility software 377

Versionin COOL:2E, defined 426

Version control 181promotion requests 171

Version groupin COOL:2E, defined 426

WWeb-based check out 135Web-based promotion 213WebSphere integration 337What’s new in this release? 30Who should read this guide 2Work library

compiling 222defined 426in promotion 270

Work with Members Using PDM (WRKMBRPDM)

Workbench 78Work with Objects

all object inquiry 56check out 112

concurrent development 136, 139one step method 113with design request 141

function access 55initial check out 54, 97member/object status history 90one step check out, overriding 68one step promotion, overriding 86reject 153

Workbenchassociating multiple design requests 99change 53change design request 101change lock 97check out 53, 112

concurrent development 136related objects 139with a design request 141

command prompting 58compile 53, 79create request 86

access 86defined 422deleting locks 98edit members

auto SEU 71change SEU option 70compare 78merge 79RLU 78SDA 78WRKMBRPDM 78

emergencycheck out 304create request 306

F13 repeat option 17function access 55identify work 52inquiry 95library list setup 83lock information 55manage locks 54, 97member/object status history 55, 90optional check out and promotion

methods 55PDM options 77


Index

promote 54promotion

compile 89move 89

promotion request 85reject 153repeating options 101review work details 53selection 51test 53, 83time entry 54tool access 50traditional check out 66user-defined options 56, 72

YYCHKMDLCRT command 353YCPYMDLOBJ command 352YCVTCNDVAL command 354, 355YCVTMDLMSG command 354, 355YEDTMDL command 357YEDTMDLLST command 348, 357YFRFVNM model value 355YMSGVNM model value 355YPRMMDLLST command 352YSBMMDLCRT command 353YSYSCHG model value 342

443

Index


mks implementer user guide - qas400-index implementer user... · mks implementer user guide the...

Documents