Implementer User Guide

IMPLEMENTER
User Guide
MKS Implementer User 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 410 Albert Street Waterloo, ON N2L 3V3 Canada tel: 519 884 2251 fax: 519 884 8861 sales: 800 265 2797 www.mks.com
WORLDWIDE OFFICES: 2500 S. Highland Avenue Suite 200 Lombard, IL USA 60148 tel: 630 495 2108 fax: 630 495 3591 sales: 800 633 1235 15 Third Avenue Burlington, MA USA 01803 tel: 781 359 3300 fax: 781 359 3399 12450 Fair Lakes Circle Suite 400 Fairfax, VA USA 22033 tel: 703 803 3343 fax: 703 803 3344 sales: 800 265 2797 Martinstrae 42-44 73728 Esslingen Germany tel: +49 711 351775 0 fax: +49 711 351775 11 Third Floor, Dukes Court Duke Street, Woking Surrey GU21 5BH United Kingdom tel: +44 (0)1483 733900 fax: +44 (0)1483 733901 sales: +44 (0)1483 733919
SIU5.3-020331
Table of Contents
Chapters
1 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Who Should Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What to Know Before Using This Product . . . . . . . . . . . . . . . . . . . . . . Whats Inside This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 3 4 5
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 MKS Issue Tracking Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Using DesignTracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Using Integrity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Using Integrity Manager and DesignTracker . . . . . . . . . . . . . . . 10 Issue Database Considerations and Assumptions . . . . . . . . . . . 11 Starting Implementer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Menu Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Overview of Implementer Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Integration With Integrity Manager . . . . . . . . . . . . . . . . . . . . . . . 15 The Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Technology-based Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Change Control Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Developer Productivity Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Distribution Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Test Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Inquiries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Release Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Third-Party Vendor Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Additional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Whats New in This Release? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Documentation Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Integrity Manager Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Technology-based Enhancements . . . . . . . . . . . . . . . . . . . . . . . . 32 User Interface Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Vendor Integration Enhancements . . . . . . . . . . . . . . . . . . . . . . . 36 User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 System Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Table of Contents
Project Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Environment Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Owners and Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Library List Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defaults for Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . Remote Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Environment Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Environment Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Environment Integrity Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39 39 39 40 40 41 42 42 43 44 44 44 45 45 45 45 45 46 50 52 52 53 53 53 53 53 54 54 54 54 55 55 55 55 55 56 56 56 58 58 59 60 63
Using the Workbench for Development Activities . . . . . 49

Understanding the Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reviewing Work Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workbench Ease of Use Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Optional Check Out and Promotion Methods . . . . . . . . . . . . . . Member/Object Status and History . . . . . . . . . . . . . . . . . . . . . . . Alternate Views and Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiple Selection Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concurrent Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Work With Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Prompting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Clipboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Clipboard Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Command Options to Add Clipboard Items . . . . . . . . . . Using the ICRTRQS Command to Promote Clipboard Items .
ii
u s e r
u i
Table of Contents
Using the IPRCCBD Command to Process the Clipboard . . . . 63 Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Check Out Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Checking Out From Work With Objects . . . . . . . . . . . . . . . . . . . 67 Checking Out Using the Clipboard . . . . . . . . . . . . . . . . . . . . . . . 69 Performing Emergency Check Out . . . . . . . . . . . . . . . . . . . . . . . 69 Checking Out for Concurrent Development . . . . . . . . . . . . . . . 69 Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Editing Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Using PDM User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Setting Up User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . . 72 Changing User Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Displaying PDM User-Defined Options . . . . . . . . . . . . . . . . . . . 77 Processing PDM User-Defined Options . . . . . . . . . . . . . . . . . . . 77 Workbench Compiles of Locked Objects . . . . . . . . . . . . . . . . . . . . . . 79 Identifying the Compile Object . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Workbench Testing of Locked Objects . . . . . . . . . . . . . . . . . . . . . . . . 83 Setting a Library List From an Environment Library List . . . . 83 Available PDM Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Displaying Related Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Promotion Request Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Promotion Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Creating Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Task Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Compiling and Moving Promotion Requests . . . . . . . . . . . . . . . . . . . 89 Member/Object Status and History . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Online Inquiry of Development Activity . . . . . . . . . . . . . . . . . . . . . . 95 Working With Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Changing a Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Deleting a Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Associating Multiple Design Requests With a Lock . . . . . . . . . 99 Changing a Design Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Repeating Workbench Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Creating Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Projects From Implementer . . . . . . . . . . . . . . . . . . . . . Creating Projects From ProjectMaster . . . . . . . . . . . . . . . . . . . . Setting Up a Default Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Management Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced Scheduling Features . . . . . . . . . . . . . . . . . . . . . . . . . Reporting Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 104 106 107 107 108 108 108 109 109
iii
Table of Contents
Performing Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Check Out Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Check Out Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the One Step Checkout Method . . . . . . . . . . . . . . . . . . . Using the Traditional Checkout Method . . . . . . . . . . . . . . . . . . Task Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Out Single Source With Multiple Objects . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Object Version Stamping in Check Out . . . . . . . . . . . . . . . . . Processing Versions in Check Out . . . . . . . . . . . . . . . . . . . . . . . Checking Out IFS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . IFS Object Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . Checking Out Using the IFS Object Name . . . . . . . . . . . . . . . . Checking Out the Contents of an Environment . . . . . . . . . . . . Check Out IFS (ICHKOUTIFS) Command . . . . . . . . . . . . . . . . Automatically Creating Object Codes in Check Out . . . . . . . . Support for Multi-Platform Check Out . . . . . . . . . . . . . . . . . . . Checking Out for Concurrent Development . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Out Related Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task Variation for Multiple Recurring Members/Objects . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Out With a Design Request . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using ILE Object Codes in Check Out . . . . . . . . . . . . . . . . . . . . . . . . Binding Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bound Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ILE SQL Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Update Service Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ILE Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Update ILE Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Out Physical File Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Different Source and Object Names in Check Out . . . . . . . . User Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Typical User Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LANSA Export/Import Authorities . . . . . . . . . . . . . . . . . . . . . Checking Out for Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Source and Objects From QA . . . . . . . . . . . . . . . . . . Task Variation for Rejecting From the Menu . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Name Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Name Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . Check Out (ICHKOUT) Command . . . . . . . . . . . . . . . . . . . . . . . . . . 112 113 113 115 121 123 123 125 125 127 127 128 129 130 134 135 136 138 139 140 140 141 147 148 148 149 149 149 149 149 149 150 150 151 151 152 152 153 153 154 155 155 155 156
iv
u s e r
u i
Table of Contents
Check Out Command Variations . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Converting RPG/400 or RPGIII Source Code to ILE RPG/400 . . . Converting CRTBNDxxx ILE Programs to CRTPGM Programs . . Checking Out Using PathFinder Information . . . . . . . . . . . . . . . . . Environment and Library Setup . . . . . . . . . . . . . . . . . . . . . . . . . Performing the Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
162 162 163 165 167 167 168 169 172 173 173 174 174 174 175 177 177 183 186 187 187 188 189 190 191 192 192 193 193 194 195 196 196 198 198 199 200 200 201 205 205 208 208
Performing Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Promotion Request Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . Promotion Request Numbering . . . . . . . . . . . . . . . . . . . . . . . . . Creating Promotion Requests in Batch . . . . . . . . . . . . . . . . . . . Default Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promotion Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create Request Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Requests With the One Step Promotion Method . . . . . . . Resolving Promotion Request Problems . . . . . . . . . . . . . . . . . . Creating Requests With the Traditional Promotion Method . . . . . Optimizing Physical File Promotions . . . . . . . . . . . . . . . . . . . . Overriding Job Submission Defaults . . . . . . . . . . . . . . . . . . . . . Changing Job Queues During the Compile Step . . . . . . . . . . . Changing Compile Commands . . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Requests by Selecting From Locks . . . . . . . . . . . . . . . . . . . Benefits of Selecting From Locks . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Requests From the Object List . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Requests From the Member List . . . . . . . . . . . . . . . . . . . . . Task Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Request by Copying a Request . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Requests With the ICRTRQS Command . . . . . . . . . . . . . . Creating Requests With the ICRTRQS Command PDM Option . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting Additional Target Environments . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promoting Related Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overriding Create Request Defaults . . . . . . . . . . . . . . . . . . . . . . . . . Removing Objects and Source in Promotion . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Request Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table of Contents
Maintaining Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promoting IFS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . Support for Browser-based Promotions . . . . . . . . . . . . . . . . . . Options for Promoting IFS Objects . . . . . . . . . . . . . . . . . . . . . . Considerations When Using *.* for Promotion . . . . . . . . . . . . Automatically Creating Object Codes in Create Request . . . . Upgrading a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promoting Physical File Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Different Source and Object Names in Promotion . . . . . . . . Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Staged Compiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compile Library List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Third-Party Compile Procedures . . . . . . . . . . . . . . . . . . . . . . . . Job Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compile Request (ICMPRQS) Command Option . . . . . . . . . . . . . . Moving Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Allocating Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authorities and Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source Member Considerations . . . . . . . . . . . . . . . . . . . . . . . . . Issuing Move Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Move Request (IMOVRQS) Command Option . . . . . . . . . . . . Special Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special Command Substitution Variables . . . . . . . . . . . . . . . . . Special Commands in Promotion: IEXCRQSDTL Command Special Commands to Manage DDM . . . . . . . . . . . . . . . . . . . . . Special Commands to Change Promotion Status . . . . . . . . . . Special Commands in Check Out . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Concurrent Development . . . . . . . . . . . . . . . . . . . . . . . . . Resolving a Conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Version Stamping in Promotion . . . . . . . . . . . . . . . . . . . Emergency Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problem Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Completing Failed Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . Other Creation Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using ILE Object Codes in Promotion . . . . . . . . . . . . . . . . . . . . Batch Promotion Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distributing Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . Scheduling Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
211 212 213 213 214 215 216 218 218 219 220 222 222 223 223 223 224 224 224 225 225 225 226 228 228 229 233 236 240 245 245 248 248 248 250 251 251 252 253 254 255 256 256 256 257
vi
u s e r
u i
Table of Contents
Promotion Request Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promotion Step Internal Processing . . . . . . . . . . . . . . . . . . . . . . . . . . Create Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Export Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compile Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distribution Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Move Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Work Libraries Used During Promotion . . . . . . . . . . . . . . . . . . Host Work Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Work Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
258 259 260 261 262 263 263 265 267 270 272 272 273 274 275 277 277 278 279 280 280 281 281 284 286 287 288 288 289 290 291 296 296 297 297 297 299 300 300 302 302
Performing Distributions . . . . . . . . . . . . . . . . . . . . . . . . . 271

Moving and Distributing Promotion Requests by System . . . . . . . Moving/Distributing All Promotion Requests By System . . . Submitting Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Moving/Distributing to a Specific System . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Move/Distribute by System Submission Options . . . . . . . . . . Displaying Move Requests by System/Environment . . . . . . . . . . . Filtering Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling Remote Job Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Default Job Schedule . . . . . . . . . . . . . . . . . . . . . . . . . Overriding the Default Job Schedule . . . . . . . . . . . . . . . . . . . . . Remote Job Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Remote Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Moving Remote Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Implementer Receiver Menu . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working With Requests on the Remote System . . . . . . . . . . . . Restoring Remote Requests (IRSTRMTRQS) . . . . . . . . . . . . . . Moving Remote Requests (IMOVRMTRQS) . . . . . . . . . . . . . . Working With Function Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Handling Emergency Situations . . . . . . . . . . . . . . . . . . . 295

Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Archiving Source and Objects on a Promotion Request . . . . . Using the Archive to Tape Features . . . . . . . . . . . . . . . . . . . . . . . . . . Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working With Tape Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . Archive Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Archive Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recovering Archived Source/Object by Request . . . . . . . . . . Common questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Check Out Archive Options . . . . . . . . . . . . . . . . . .
vii
Table of Contents
Emergency Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Emergency Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Member and Object Handling . . . . . . . . . . . . . . . . . . . . . 307

Compile Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Non-Source-based SQL . . . . . . . . . . . . . . . . . . . . . . . Managing Source-based SQL (DDL) . . . . . . . . . . . . . . . . . . . . . Managing Traditional DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special Object Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commands and Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing ILE Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Support for Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Support for Service Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading ILE Objects Into the Repository . . . . . . . . . . . . . . . . . Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S/36 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S/38 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extended Object Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application and CASE Software Products . . . . . . . . . . . . . . . . . . . . American Software Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Codes for Check Out and Promotion . . . . . . . . . . . . . . Compiling Cobol Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message File Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . AS/SET Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Out AS/SET Definitions . . . . . . . . . . . . . . . . . . . . . . AS/SET Dependency Checking . . . . . . . . . . . . . . . . . . . . . . . . . Promoting AS/SET Definitions . . . . . . . . . . . . . . . . . . . . . . . . . Archiving AS/SET Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BPCS Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CODE/400 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the User-Defined Options . . . . . . . . . . . . . . . . . . . . . . Launching CODE/400 from Implementer . . . . . . . . . . . . . . . . COOL:Xtras Change Management Integration . . . . . . . . . . . . . . . . Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Development Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Member/Object Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SQL Support for COOL:2E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 308 309 311 312 318 318 318 319 319 319 320 321 322 323 325 325 326 328 329 329 330 330 330 331 332 334 335 335 336 337 337 338 338 339 345 345 345
10 Integrating With Other Vendor Products . . . . . . . . . . . . 327
viii
u s e r
u i
Table of Contents
Check Out Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working With Model Object Lists . . . . . . . . . . . . . . . . . . . . . . . Checking Out Model Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . Concurrent Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Out Versionable Model Objects . . . . . . . . . . . . . . . . User Exit Program Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promoting Model Information . . . . . . . . . . . . . . . . . . . . . . . . . . Promotion Flow: COOL:2E to COOL:2E Environment . . . . . . Promotion Flow: COOL:2E to Traditional Environment . . . . Working in a Change-Controlled Model . . . . . . . . . . . . . . . . . . Model Object Audit Information . . . . . . . . . . . . . . . . . . . . . . . . Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing EXCUSRSRC and EXCUSRPGM . . . . . . . . . . . . . . . Merging Model Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J.D. Edwards Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Support for J.D. Edwards Traditional Objects . . . . . . . . . . . . . Support for J.D. Edwards DREAM Writer Versions . . . . . . . . Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying J.D. Edwards Items . . . . . . . . . . . . . . . . . . . . . . . . . . Compiling From the Workbench . . . . . . . . . . . . . . . . . . . . . . . . Promoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Archiving J.D. Edwards Special Objects . . . . . . . . . . . . . . . . . . LANSA Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying Process/Functions . . . . . . . . . . . . . . . . . . . . . . . . . . Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Save File Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LANSA Export/Import Authorities . . . . . . . . . . . . . . . . . . . . . LANSA RDML Function Compare . . . . . . . . . . . . . . . . . . . . . . Understanding the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lotus Notes and Domino Integration . . . . . . . . . . . . . . . . . . . . . . . . Powerhouse Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utility Software Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ABSTRACT Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abstract User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . . . Accessing ABSTRACT From Implementer . . . . . . . . . . . . . . . . AOS Message Manager Integration . . . . . . . . . . . . . . . . . . . . . . . . . AS/NET Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MIMIX Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
346 347 347 349 349 350 351 351 354 356 357 359 359 362 363 363 364 364 364 365 365 365 366 366 366 367 367 369 370 370 371 371 372 372 374 376 376 377 378 378 378 380 380 381 381
ix
Table of Contents
NetView/DM Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Net/Wrk400 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PathFinder Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PathFinder Database Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . PathFinder User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . PathFinder PDM Options for USERPATH . . . . . . . . . . . . . . . . PathFinder PDM Options for USERPDM . . . . . . . . . . . . . . . . . ROBOT Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
381 381 382 382 382 383 383 384
Appendixes
Compare/Merge Member Commands . . . . . . . . . . . . . . 385

Compare Member (ICMPMBR) Command . . . . . . . . . . . . . . . . . . . Compare Member Report Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . LANSA Compare RDML (ICMPRDML) Command . . . . . . . . . . . . LANSA Compare Members Report . . . . . . . . . . . . . . . . . . . . . . Merge Member (IMRGMBR) Command . . . . . . . . . . . . . . . . . . . . . . Merge Member Merge Report Listing . . . . . . . . . . . . . . . . . . . . . . . . 386 392 394 396 398 408
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
u s e r
u i
Before You Begin
mplementer 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 whats inside this guide document conventions getting help
Before You Begin
Who Should Read This Guide

This 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 Product

The 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 e
Whats Inside This Guide
Whats Inside This Guide

This guide contains comprehensive information about using all features that pertain to the setup and maintenance of Implementer. The guide is organized as follows:
Chapter Chapter 1: Before You Begin Chapter 2: Getting Started Description Introduces you to MKS Implementer. Describes who should read this guide and how to use it, and options for getting help. Explains where to find product installation information. Overviews the important features of Implementer, including whats new in this release. Describes the various user roles. 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. Explains how to use the Implementer to interface with MKS ProjectMaster, and perform common project management related activities. Explains the two checkout methods, and how to check out members/objects. Describes the various check out related options. 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. Explains how to distribute members/objects to remote systems using the Implementer Receiver. Explains how to archive and roll back to prior member/ object versions. Describes how to perform emergency check out and emergency create request functions.
Chapter 3: Using the Workbench for Development Activities
Chapter 4: Projects
Chapter 5: Performing Check Out Chapter 6: Performing Promotions
Chapter 7: Performing Distributions Chapter 8: Handling Emergency Situations
Before You Begin
Chapter Chapter 9: Member and Object Handling Chapter 10: Integrating With Other Vendor Products
Description Explains how Implementer supports the different OS/ 400 types of objects and source members. 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. 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. Defines the terminology that relates to Implementer.
Appendix A: Compare/ Merge Member Commands
Appendix B: Glossary
Document Conventions
Throughout this guide, the following typographical conventions are used.
Items in documentation References to other manuals, new terms, and variables Keys you press, programs, files, directory names, and drive letters Code-based information, such as system messages, field syntax, macros, and commands, and information you type on menus and panels PC menus, commands PC drop-down menus PC Dialog boxes, features Path names Appear as italics ENTER
ADDLIBLE
New > Problem the Session command Edit Options, Cancel, OK
c:\mks\demo
NOTE
Notes containing important information are bordered by lines on the top and bottom.
u s e r
g u i d e
Getting Help
Getting Help
MKS 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.
Online Web E-mail Telephone North America www.mks.com support@mks.com 800 633 6298 630 652 9350 519 884 2270 +44 (0) 1483 733910 +49 711 351 775 51 630 495 4855 +44 (0) 1483 733901 +49 711 351 775 11
UK Germany Fax North America UK Germany
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)
Before You Begin
u s e r
g u i d e
Getting Started
his guide is for MIS professionals who implement change management or perform change management tasks. This chapter provides an overview of Implementer. This chapter covers: system requirements issue tracking solutions starting Implementer overview of Implementer features whats new in this release user roles understanding environments
Getting Started
System Requirements
The minimum system requirement for this Implementer release is a RISCbased 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 mostin 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 painfulon 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 e
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 defecttracking 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 toolsincluding 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 Managers 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
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 its 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 trackedalong with the actual development changein Implementer; the issue details and state are tracked in Integrity Manager.
Using Integrity Manager and DesignTracker
For organizations that require DesignTrackerfor example, if you use Implementers release management feature or are using SupportCenter or ProjectMasterbut 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 400when an issue meets the criteria established within the DTBridge setup, a new design request is created on the iSeries 400 and the
10
u s e r
g u i d e
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
12
u s e r
g u i d e
Starting Implementer
Menu Access Command Options

Menu Option Activity Report Archive History Report Archive Recovery Check Out Compile Promotion Request Concurrent Development Report Create Promotion Request Move Promotion Request by System/Environment Environments Environment Groups Environment Report Function Keys Integrity Manager Setup Job Log Inquiry Lock Report MenuPanel 1 MenuPanel 2 MenuPanel 3 MenuPanel 4 Manage All Concurrent Development Move Promotion Request My Workbench Network Configuration Objects Object Codes Object Code Report Work with Projects Request Inquiry Request Maintenance STRIM Command Value *ACTRPT *ARCHRPT *ARCRCV *CHKOUT *CMPRQS *CONDEVRPT *CRTRQS *MOVRQSSYS *WRKENV *WRKENVGRP *ENVRPT *WRKFNCKEY *INTMGRSET *JOBLOGINQ *LCKRPT *M1 or *MENU1 *M2 or *MENU2 *M3 or *MENU3 *M4 or *MENU4 *MNGCONDEV *MOVRQS *WRKBCH *NETCFG *WRKOBJ *WRKOBJCDE *OBJCDERPT *WRKPRJ *RQSINQ *RQSMNT
13
Getting Started
Menu Access Command Options

Menu Option Request Report System Control Maintenance Users User Report STRIM Command Value *RQSRPT *SYSCTLMNT *WRKUSR *USRRPT
Overview of Implementer Features

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. 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 Developers 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 enjoydeveloping 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
14
u s e r
g u i d e
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. Implementers 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, MKSs workflow management and issue tracking solution for NT and UNIX. Using either the Windows GUI or Web interface, Integrity Managers 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 MKSs 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.
16
u s e r
g u i d e
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
Technologybased 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 applicationall 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
18
u s e r
g u i d e
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 members 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.
20
u s e r
g u i d e
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 promotionthe 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.
22
u s e r
g u i d e
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. Implementers 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.
24
u s e r
g u i d e
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.
26
u s e r
g u i d e
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 LANSAs web interface.
28
u s e r
g u i d e
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 its 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.
Whats 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.
30
u s e r
g u i d e
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 platformmaking 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 MultiPlatform Solutions Guide.
Technologybased 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 DDSbased 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
32
u s e r
g u i d e
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 Implementers 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 users 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.
34
u s e r
g u i d e
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 5154 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 reprepared 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 significantit 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.
36
u s e r
g u i d e
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 Windowsbased 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 Roles
This 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 users 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.
38
u s e r
g u i d e
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 Environments
An 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 users 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.
40
u s e r
g u i d e
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. 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.
Object Owners and Authorities
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.
42
u s e r
g u i d e
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 administrators profile in Work with Users. Multiple users can be granted administrative rights to an environment through Work with User Capabilities. 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.
Library List Considerations
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.
44
u s e r
g u i d e
Remote Considerations Environment Groups
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. 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
Standard Path
Check Out
Development Promotion
Quality Assurance Promotion
Mods Production
Related Environment
Production
(Automatic copy from)
46
u s e r
g u i d e
Environment Path Seq 10Development Seq 20Quality Assurance Seq 30Mods Production
Related Environment Seq 10Mods Production Seq 20Production
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.
47
Getting Started
48
u s e r
g u i d e
Using the Workbench for Development Activities

T
his 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
Understanding the Workbench

The 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
50
u s e r
g u i d e
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
Development Cycle
Check Out
Development Promotion
Quality Assurance Promotion
Production
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.
51
Using the Workbench

IDENT IFY WORK MANAGE LOCKS
(W or k wi t h O bj ec ts) ( De si gn Req ue st or P roj ec t)
REVIEW WORK
( De si gn Req ue st or P roj ec t)
PRO MOT E
(T o Te st o r Prod uct i on)
MY WORKBENCH
CHECK OUT
( To a Dev el op m ent Env i r onm ent or Li br ary)
T EST
(W RKMB RPDM , Com m and Li ne)
CHANG E COM PILE

(O pti on 14= Com pil e) (S EU, S DA, RLU, W RKM BRP DM)
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).
52
u s e r
g u i d e
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. 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. 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. 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.
Checking Out
Changing Items
Compiling
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 jobs 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. 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.
Time Entry
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 Features

Using 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.
54
u s e r
g u i d e
Optional Check Out and Promotion Methods
From the Workbench, Implementer offers two methods for processing check out and promotionsthe 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. 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.
Member/Object Status and History
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. 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. 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.
Multiple Selection Methods Automatic Grouping
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 2=Change (SEU) 4=Delete (Lock) 5=Display (SEU) 6=Print (Mbr) 7=Lock detail 8=Related objects 9=Add to Clipboard 11=Promote 12=Concurrent development Work with Objects Options 3=Promotion requests 5=Display (SEU) 6=Print (Mbr) 7=Mbr/Obj detail 8=Related objects 9=Add to Clipboard 10=Checkout 12=Locks 13=Lock history
56
u s e r
g u i d e
My Workbench and Work with Objects, Option Comparison

My Workbench Options 14=Compile 15=Issue or Design requests 17=Change using SDA 19=Change using RLU 20=Reject 21=Emergency check out 22=Emergency promote 23=Compare member 24=Merge member 26=Multiple issues or design requests 27=Check out 28=Status History 30=Book Time Work with Objects Options 14=Archives 15=Issue or Design requests 20=Reject 21=Emergency check out 22=Emergency promote 27=Promote 28=Status History
My Workbench and Work with Objects, Function Comparison

My Workbench Function Keys F3=Exit F4=List F5=Refresh F6=Check Out F7=Process Clipboard F8=Work with Objects F9=Retrieve (previous command) F11=Display (changes the sequence of displayed fields) F12=Cancel F13=Repeat Work with Objects Function Keys F3=Exit F4=List F5=Refresh F6=Workbench F7=Process Clipboard F8=Apply Filters F9=Retrieve (previous command) F10=Display (changes the sequence of displayed fields) F11=Display (changes the sequence of displayed fields) F12=Cancel
57
My Workbench and Work with Objects, Function Comparison

My Workbench Function Keys F14=Compile requests F15=Move requests F16=User options F17=Filter F18=User Defaults F19=Request inquiry F22=Promote F23=More options F24=More keys Work with Objects Function Keys F14=Compile requests F15=Move requests F16=Show IFS Object F18=Show deleted F19=Request inquiry F20=Check out F21-Build IFS Obj List F22=Promote F23=More options F24=More keys
Command Prompting
The 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 Clipboard

The 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.)
58
u s e r
g u i d e
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.
60
u s e r
g u i d e
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 Syntax

IADDCBD 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.
62
u s e r
g u i d e
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 Clipboardnot 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 Syntax

IPRCCBD 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.
*MENU *DISPLAY *CHKOUT *CRTRQS *ECHKOUT *ECRTRQS Displays the Clipboard Processing Menu. This is the default value. Displays the contents of the Clipboard. Checks out all items on the Clipboard. Creates a request for all items on the Clipboard. Performs an emergency check out for all items on the Clipboard. Performs an emergency create request for all items on the Clipboard.
Checking Out
The 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 outthe 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.
64
u s e r
g u i d e
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.
66
u s e r
g u i d e
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.
68
u s e r
g u i d e
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 Members
This 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.
70
u s e r
g u i d e
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 projects 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

Alternate Keyword (PDM) &N1 &N1 &F &L2 &T3
Field member object name object code source member name source file source file library source type
Workbench Only Yes
Keyword
&LCKMBROBJ &LCKOBJCOD &SRCMBR &SRCFIL &SRCLIB &SRCTYP
Locks File Field LHMONM LHOBCD LSMBNM LSTOFL LSTOLI LSMBTY
72
u s e r
g u i d e

Alternate Keyword (PDM) &N1 &L2 &T
3
Field object name object library object type object type no * object attribute design request nbr environment name member/object description (obj if no source, in ) from environment from object library from source file from source library user profile project comments option name compile in batch to directory (IFS only) object and to directory (IFS only) from directory (IFS only) Jobd name Jobd library Jobd and library with / separator COOL:2E model object list COOL:2E object surrogate AS/SET Application set name AS/SET From application set name
Workbench Only Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Keyword
&OBJECT &OBJLIB &OBJTYP &SHTOBJTYP &OBJATR &DSNNBR &ENVNAM &DESC &FRMENV &FRMOBJLIB &FRMSRCFIL &FRMSRCLB &USER &PROJ &COMMENT &OPT &CMPBCH (*YES/*NO) &DIR &PATHOBJ &FRMDIR &JOBD &JOBDLIB &JOBDWLIB &SYNMDOLST &SYNOBJSGT &ADKSET &FRMADKSET
Locks File Field LOOBNM LOTOLI LOOBTY LOOBTY LOOBAT LHDRNB LHTOEN LHGMEN
&S &A &X &C &P &H &G &J
73

Alternate Keyword (PDM)
Field LANSA partition name LANSA from partition name JDE common library JDE from common library Comment (1st 10 char only)
1
Workbench Only Yes Yes Yes Yes Yes
Keyword
&LANPAR &FRMLANPAR &CMNLIB &FRMCMNLIB &COMMENT10
Locks File Field
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.
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.
74
u s e r
g u i d e
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 sourcebased 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 users 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.
76
u s e r
g u i d e
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 UserDefined 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 UserDefined 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.
78
u s e r
g u i d e
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.

From 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 The library list for the compile is taken from the locked to environment. 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. Special commands for the compile step are issued based on the locked to environment definition. Checked out to a library 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. Otherwise, the library creation authority for the target library is used.
No special command is issued.
80
u s e r
g u i d e
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.
Parameter Member/object (MBROBJ) Object code (OBJCODE) Checked out to LIB/ENV (LIBENV) Value PGM1 RPG DEVENV
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.
Parameter Member/object (MBROBJ) Source file (SRCFILE) Value PGM1 IN10DEV/QRPGSRC
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.
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:
*OBJCODE *KEEP *GRANT Object ownership and authority is based on the specifications for the object code. Object ownership and authority is retained based on the production environment parameters. Object ownership and authority is granted based on the target environment parameters.
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.
82
u s e r
g u i d e
Workbench Testing of Locked Objects
Workbench Testing of Locked Objects

Implementer 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 userdefined 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:
Option TS Purpose Test a change Command
ISETLIBL ENV(&envnam) POSITION(*replace) CMD(call qcmd) ISETLIBL ENV(&envnam) POSITION(*replace) CMD(call &object)
TO
Test an object
For instructions on how to set up user-defined options, see Setting Up User-Defined Options on page 72.
Displaying Related Objects

From 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.
84
u s e r
g u i d e
Promotion Request Overview

Creating 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
86
u s e r
g u i d e
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.
88
u s e r
g u i d e
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.

Implementer 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 developers 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.
90
u s e r
g u i d e
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 Chkout-Chg Chkout-Crt Chkout-Dlt Chkout-Cmp Chkout-Rgn EmgCO-Chg EmgCO-Crt EmgCO-Dlt EmgCO-Cmp EmgCO-Rgn Src-Edited Description The item is currently checked out for change to a *TST environment. The item is currently checked out for create to a *TST environment. The item is currently checked out for delete to a *TST environment. The item is currently checked out for recompile to a *TST environment. The item is currently checked out for regeneration to a *TST environment. The item is currently checked out for emergency change. The item is currently checked out for emergency create. The item is currently checked out for emergency delete. The item is currently checked out for emergency recompile. The item is currently checked out for emergency regeneration. The source was just edited (implies a compile was not attempted since it was last changed).
91
Status Comp-Fail
Description 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). 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). The item is currently on a promotion request, going from development to a *QAC environment. The item is currently on a promotion request, going from development to a *PRD environment. The item was successfully promoted to the first *QAC environment. 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. The item is currently on a promotion request, going from the last *QAC environment to a *PRD environment. 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). The item is currently checked out for reject. 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).
Comp-Ok
Dev>QA1 Dev>Prod In QA1 QA1>QA2
QA4>Prod In Prod
RejQA1 Blank
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 lockedall objects that have a status display, regardless of the status value.
92
u s e r
g u i d e
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.
94
u s e r
g u i d e
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 Activity

This 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
96
u s e r
g u i d e
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 Locks

The 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
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:
User profile Project reference The user profile that created the lock. 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. The specific issue or design request number. 1 for Change, 2 for Create, or 3 for Delete. Std (standard) or Emerg (emergency). As required.
Issue or DR Number Action Lock type Comments
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.
98
u s e r
g u i d e
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:

Delete locks Delete sources Delete objects Type Y or N to indicate whether you want to delete the locks for all items that display. Type Y or N to indicate whether you want to delete the source for all items that display for the environment. Type Y or N to indicate whether you want to delete all objects that display for the environment.
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.
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.
100
u s e r
g u i d e
Changing a Design Request
Changing a Design Request

This 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
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 Options

This 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
102
u s e r
g u i d e
Projects
4
his 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. This chapter covers: creating projects project paths project reporting project management capabilities
103
Projects
Creating Projects
Use 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.
104
u s e r
g u i d e
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 GanttDaily 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.
106
u s e r
g u i d e
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 Paths
Implementer 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 Reporting
Flexible 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.

Advanced 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.
108
u s e r
g u i d e
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
110
u s e r
g u i d e
Performing Check Out
his 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 developers 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. This chapter covers: 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
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.
112
u s e r
g u i d e
Check Out Methods
Check Out Methods

Implementer offers two methods for processing a check outthe 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 projects 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
114
u s e r
g u i d e
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 environments 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 likein 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.
116
u s e r
g u i d e
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 PathFinders 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 PathFinders 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 PathFinders 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.
118
u s e r
g u i d e
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 projects 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.
120
u s e r
g u i d e
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).
1 = Change 2 = Create To change an existing member object. 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. To delete an existing member/object from the production environment when the item is promoted. The production environment at promotion is the target environment. To recompile an existing member/object.
3 = Delete
9 = Recompile
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
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
122
u s e r
g u i d e
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 release3.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. Whats 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.
124
u s e r
g u i d e
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 createdcheck 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.
126
u s e r
g u i d e
Checking Out IFS Files and Directories

The 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 nameBOOK.NTFfor 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


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

that are set up to manage IFS objects.

3 Press F6=IFS Entry. The Convert Long Name and Post to Checkout
window displays.
128
u s e r
g u i d e
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 environments 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 environments 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


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
130
u s e r
g u i d e
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 multiplatform 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. Derives the environment from the value defined as your default check out from environment, in Work with Users. Specify the environment name. The environment is determined from the environment path established for the specified environment.
*USRPRF Char value
131
To environment Specify the environment or library to check out to.

*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. Derives the value from the value defined as your default check out to environment or library, in Work with Users. Specify a valid environment or library name.
*USRPRF Char value
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.
*USRPRF *DRNBR Char value Derives the default project reference defined to your user profile, in Work with Users. This is the default value. Derives the project reference from the design request specified in the Issue or Design Request parameter. 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.
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.
Number *NONE Specify a valid issue or DR number. Specifies that the member/object is not associated with an issue or DR. This is the default value.
Lock type Specify the type of check out and corresponding lock to place on the object.
*STD *EMERG Standard check out/lock. This is the default value. Emergency check out/ lock.
Object Specify the IFS name, in path\name format, of the object to check out.
132
u s e r
g u i d e
Action Specify the action to be taken in the production environment for the object.
*CHANGE *CREATE *DELETE The object will be changed. This is the default value. The object will be created. The object will be deleted.
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.
Name *FRMENV *NONE Specify the environment name. Copies the object from the environment specified in the From environment parameter. The object is not copied. This is the default value.
Copy from object Specify the name of an existing object on which to base a new object. This object must exist on the host systemit 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.
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.
*NO
Ignores warning messages. Displays warning messages. This is the default value.
*YES
Replace existing members Specify how to handle checking out to a location where the member already exists.
*YES *NO *IGN The current member replaces existing members. The current member does not replace existing members. This is the default value. Creates a lock using the existing object in the check out to location.
Submit Specify the standard OS/400 submit job parameter as required. Job queue Specify the job queue for the command to run in.
Name *PRODUCT Specify the job queue name. The job queue defined as the default job queue in data area IMJOBQ is used. This is the default value.
Library Specify the library for the job queue.

Name *LIBL Specify the library name if the library is not on the library list. Retrieves the library from the library list. This is the default value.
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
134
u s e r
g u i d e
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:

1=Dont 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. 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. 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.
2=Add
3=Add all future without warning
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.
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.

This 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.
136
u s e r
g u i d e
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.
138
u s e r
g u i d e
Checking Out Related Objects
Checking Out Related Objects

This 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.
140
u s e r
g u i d e
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).

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:

0 1 2 3 4 Not ready (always set to 0 when the entity is added to the list). Ready to checkout (entity is ready to be checked out). In development (entity is checked out and in development). In QA (entity is checked out and in quality assurance for testing). Completed (entity was moved into a *PRD (production) environment).
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
142
u s e r
g u i d e
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
144
u s e r
g u i d e
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 projects 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.
146
u s e r
g u i d e
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 nonsource-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 Out

As 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.
148
u s e r
g u i d e
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. 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. 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. 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. 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. 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.
Bound Programs ILE SQL Programs Service Programs
Update Service Program
ILE Program
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 Data

Implementer 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.
150
u s e r
g u i d e
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 Authorities
In 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.

Maintain DR No Concurrent Devt No
Position Junior Programmer
Authorities in Check Out 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. User is unable to add entities to the checkout request, but is able to change copy from information in a concurrent development situation. 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. 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. 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.
Programmer in a controlled shop
No
Yes
Project Leader who does not code
Yes
No
Project Leader in a shop that does not allow concurrent development
Yes
No
Project Leader or Senior Programmer
Yes
Yes
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
152
u s e r
g u i d e
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 Reject

This 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 librarya 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.
154
u s e r
g u i d e
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 Rules

Implementer 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
156
u s e r
g u i d e
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.
*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. Derives the environment from the value defined as your default check out from environment, in Work with Users. Specify the environment name. The environment is determined from the environment path of the specified environment.
*USRPRF Char value
To library Specify the development library to check out to.

*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. Derives the library from the value defined as your default check out to library, in Work with Users. Specify the library name.
*USRPRF Name
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 indicating that you must specify an environment name. *PATH is the default value. Derives the environment from the value defined as your default check out to environment, in Work with Users. Specify the environment name. The environment is determined from the environment path of the specified environment.
*USRPRF Char value
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.
*USRPRF *DRNBR Char value Derives the default project reference defined to your user profile, in Work with Users. Derives the project reference from the design request specified in the Issue or Design Request parameter. 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.
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.
Number *NONE Specify a valid issue or DR number. Specifies that the member/object is not associated with an issue or design request. This is the default value.
Lock type Specify the type of check out and corresponding lock to place on the member/object.
*STD *EMERG Standard check out and lock. This is the default value. Emergency check out and lock.
Member/object Specify the name of the member or object to check out.

Name generic* Specify the member or object name. 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. Specifies to check out all member/objects from the specified environment.
*ALL
Object code Specify the Implementer object code associated with the member/object.
Name *ALL Specify the object code name. 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.
158
u s e r
g u i d e
Action Specify the action to take in the production environment for the member/ object.
*CHANGE *CREATE *DELETE *RECOMP To change a member/object. This is the default value. To create a member/object. To delete a member/object. To recompile a 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.
Name *FRMENV *NONE Specify the environment name. Copies the object from the environment specified in the From environment parameter. 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 systemit 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.
Name *MBROBJ Specify the member/object name. Copies the object specified in the Member/Object parameter.
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.
Name *CPYENV Specify the source file name. Copies from the default source file defined for the Copy from environment parameter. This is the default value.
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 *CPYENV Specify the library name. Copies from the library defined for the Copy from environment parameter. This is the default value.
160
u s e r
g u i d e
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.
Name *FRMENV *USRPRF *OBJCDE Specify the source file name. Copies to the source file defined for the from environment for the object code specified. Copies to the source file to your default development library, if specified, in Work with Users. This is the default value. Copies to the source file defined for the corresponding object code.
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.
*YES *NO Ignores warning messages. Displays warning messages. This is the default value.
Replace existing members Specify how to handle checking out to a location where the member already exists.
*YES *NO *IGN The current member replaces existing members. The current member does not replace existing members. This is the default value. Creates a lock using the existing object in the check out to location.
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 *PRODUCT Specify the job queue name. 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.
162
u s e r
g u i d e
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.
164
u s e r
g u i d e
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.
166
u s e r
g u i d e
Checking Out Using PathFinder Information

This 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
PathFinders 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 PathFinders 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 PathFinders 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

168
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 u s e r g u i d e
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
170
u s e r
g u i d e
Performing Promotions
he 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. This chapter covers: 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
Promotion Request Fundamentals

The 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 Implementeryou 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.
172
u s e r
g u i d e
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 09 and AZ. 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.
When the request number is 00019999 A001A00Z A010AZZZ B000B00Z B010B0ZZ B100BZZZ The next number issued is A000 A010 B000 B010 B100 C000
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
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. Implementer offers two methods of promotionthe 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.
Promotion Methods
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
174
u s e r
g u i d e
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
176
u s e r
g u i d e
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.
178
u s e r
g u i d e
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 projects path.
180
u s e r
g u i d e
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.
182
u s e r
g u i d e
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.
1 = Change 2 = Create 3 = Delete 9 = Recomp Changes the existing member/object. Creates a new member/object. Deletes the existing member/object from the target environment. 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.
Optimizing Physical File Promotions

For information on enabling optimized promotions, see Chapter 3 of the Implementer System Administrator Guide.
Implementer provides a feature that allows you to optimize the promotion of DDS-based physical files created with the Create Physical File (CRTPF) command. 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 basisthis 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. With optimizing, Implementer uses the Change Physical File (CHGPF) command over the target file/library in production when promoting DDSbased 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.
For more information on promoting DDS files and SQL tables, see Database Management on page 308.
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:
Optimized... the promotion completed in 2 minutes 15 seconds Not optimized... the promotion completed in 4 minutes 51 seconds
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
184
u s e r
g u i d e
command with the Add Physical File Trigger (ADDPFTRG) command or the Remove Physical File Trigger (RMVPFTRG) command to run AfterMove 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 PFs 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 resubmit 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.
186
u s e r
g u i d e
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 users 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.
188
u s e r
g u i d e
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.

You 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.
190
u s e r
g u i d e
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 dont 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 List

You 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 dont 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.
192
u s e r
g u i d e
Creating Requests From the Member List
Creating Requests From the Member List

After 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 codefrom 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 doesnt the object exist in the target environment when action type is 1 for change? This occurs when you use the members list to select member/objects. You should change the actual type to 2 for Create.
194
u s e r
g u i d e
Creating a Request by Copying a Request
Creating a Request by Copying a Request

To 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 filesfor 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.
196
u s e r
g u i d e
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 developers 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.
198
u s e r
g u i d e
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 Environments

When 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 This task assumes you are in the Create Request panel.
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 Objects

To 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.
200
u s e r
g u i d e
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, Implementers 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 environments 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 crossenvironment 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
Initial Request targets Environment 4 Object 1 Object 2 Object 3 Object 4 Related Objects in Environment 4 obj A and B obj D obj A and B obj A
Cross-Environment Related Objects obj A - Env 1 obj D - Env 1 obj A - Env 3 obj A - Env 1 obj B - Env 2 obj D - Env 2 obj B - Env 3 obj A - Env 2 obj C - Env 2 obj C - Env 2 obj C - Env 3 obj A - Env 3
And results in the creation of three secondary requests.

Target Environment Env 1 Env 2 Env 3 Env 4 obj A obj B obj A obj A
Request Type Secondary Request #2 Secondary Request #3 Secondary Request #4 Primary Request #1
Related Objects obj D obj C obj B obj B obj D obj C obj D obj A -
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.
202
u s e r
g u i d e
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.
204
u s e r
g u i d e
Overriding Create Request Defaults

In 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 environments 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:
206
u s e r
g u i d e
Field Separate model copy step
Description 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. 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. 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. 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. 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. 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)
Remove obj in from lib/env
Remove src in from lib/env
Add related objects to request
Submit request
Through step
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
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 Details

Authorized 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.
208
u s e r
g u i d e
Changing Request Details
3 Complete the fields as follows: a) Action
Specify the action to take with the member/objects included in the request.
1 = Change 2 = Create Changes an existing member/object. This is the default value if the object already exists. Creates a new member/object. This is the default value if the object does not exist in the From production environment. 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. 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.
3 = Delete
9 = Recomp
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.
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.
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). 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).
2 = From environment
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.
210
u s e r
g u i d e
Maintaining Promotion Requests
Maintaining Promotion Requests

It 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, ExptPend, 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 Directories

IFS 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.
212
u s e r
g u i d e
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. 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
Options for Promoting IFS Objects
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.
214
u s e r
g u i d e
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 environments 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 environments 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:

1 = Dont 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. 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. 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.
2 = Add
3 = Add all future without warning
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 movefor 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 directoryfor 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.
216
u s e r
g u i d e
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:

For Action When to do Sequence number Command Type 4 to issue the command as part of the Move step. Type 1 to issue the command before the Move step. Type a valid sequence number.
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.
4 Press ENTER to add the command. Press F12 twice to redisplay the
Create Request panel.
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 Data

Implementer 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.
218
u s e r
g u i d e
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.
Compiling
In 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 CompPend. 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.
220
u s e r
g u i d e
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 librariesthe 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.
222
u s e r
g u i d e
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. 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.
Common Questions
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 Requests

The 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 u s e r g u i d e
224
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 Archiving
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. 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. If the source type of the member is changed, the source type of the new target member is changed as well.
Source Member Considerations
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.
226
u s e r
g u i d e
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. Submitting Overrides 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.
panel.
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

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.
228
u s e r
g u i d e
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.

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 selfdocumenting. 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.
230
u s e r
g u i d e
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 This task assumes you are in the Create Request panel.
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:
1 = Compile 2 = Dist-Host 3 = Dist-Rcvr 4 = Move Issues the command for the compile stage. Issues the command for the distribution stage on the host system. Issue the command for the distribution stage on the receiver system. Issue the command for the move stage. For promotions that target a remote system, the special command runs where the move occurs. 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. Issue commands during check out.
5 = Move-Host
6 = Checkout
When to do For the specified For Action, type the number representing when you want the command to run.
1 = Before 2 = After-OK 3 = After Fail The command runs before the specified For Action. The command runs after the specified For Action successfully completes. The command runs after the specified For Action fails.
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.
232
u s e r
g u i d e
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 #PROJECT #TRGENV
Substitutes the checked out From environment. Substitutes the project number that was entered on the Check Out panel. Substitutes the checked out To environment. Item Level
#DIR #DRNBR #FILETYPE
Substitutes the directory path of the target environment (IFS only). Substitutes the Design Request that was entered on the Check Out panel. Substitutes the IFS file extension. Applies to objects associated with object codes defined with the special characteristic PCFILE. Substitutes the checked out from file library. Substitutes the object attributes. Substitutes the object code. Substitutes the object. Substitutes the program or files library. Substitutes the current, short object name. Substitutes the object type. Substitutes the IFS project relative long name (#DIR and #OBJECT) for IFS objects. Substitutes the From program library (non-IFS). Substitutes the IFS short name. Substitutes the source file of the checked out From environment (non-IFS). Substitutes the source library of the checked out From environment (non-IFS). Substitutes the source member. Substitutes the source type.
#FILLIB #OBJATR #OBJCOD #OBJECT #OBJLIB #OBJNM9 #OBJTYP #PATHOBJ #PGMLIB #SHORTNM #SRCFIL #SRCLIB #SRCMBR #SRCTYP
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.
Substitution Variable
Replacement Value Header Level
#ENVARCDIR #ENVARCLIB #ENVDIR #ENVFILLIB #ENVPGMLIB #ENVSRCLIB #ENVTYP #FRMDIR #FRMENV #FRMLIB
Substitutes the archive path defined for the target environment (IFS objects). Substitutes the archive library defined for the target environment. Substitutes the directory path defined for the target environment (for IFS objects). Substitutes the file library defined for the target environment. Substitutes the program library defined for the target environment. Substitutes the source library defined for the target environment. Substitutes the environment type (*PRD, *QAC, or *TST) defined for the target environment. Substitutes the promotion work directory (for IFS objects). Substitutes the request From environment. Substitutes the target object library name, as defined on the Change EnvironmentObject 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. Substitutes the request project number. Substitutes the request number. Substitutes the current target environment. Substitutes the current, target environment group. Substitutes the temporary, Request work directory (for IFS objects).
#PROJECT #RQSNBR #TRGENV #TRGGRP #WRKDIR
234
u s e r
g u i d e
Substitution Variable #WRKOBJLIB
Replacement Value Substitutes the temporary work library that contains the requests 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. Substitutes the temporary work library containing the request source that will be moved into the target environment. Item Level
#WRKSRCLIB
#DIR #FILETYPE #FILLIB #OBJATR #OBJCOD #OBJECT
Substitutes the From environment directory path (for IFS objects). Substitutes the IFS file extension for the object. Substitutes the current target file library. Substitutes the current object attribute. Substitutes the current object code. 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. Substitutes the current target object library. Substitutes the current, short object name. Substitutes the object type of the item being promoted. Substitutes the IFS project relative long name (#DIR and #OBJECT) for IFS objects. Substitutes the target program library of the item being promoted. Substitutes the short object name for the IFS object being promoted. Substitutes the source file name of the item being promoted. Substitutes the target source library of the item being promoted. Substitutes the source member name of the item being promoted.
#OBJLIB #OBJNM9 #OBJTYP #PATHOBJ #PGMLIB #SHORTNM #SRCFIL #SRCLIB #SRCMBR
235
Substitution Variable #SRCTYP #WRKSRCFIL
Replacement Value Substitutes the source type of the item being promoted. Substitutes the name of the source file in the request work library. Typically used with #WRKOBJLIB and #WRKSRCLIB.
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.
236
u s e r
g u i d e
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 Syntax

IEXCRQSDTL 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.
Substitutio n Variable #FILLIB #SRCLIB #PGMLIB #OBJECT
Replacement Value Substitutes the current target file library at the time of promotion. Substitutes the current target source library at the time of promotion. Substitutes the current target program library at the time of promotion. Substitutes the current member/object name at the time of promotion. This variable can only be used within the command syntax. Substitutes the current object type at the time of promotion. Substitutes the current, short object name at the time of promotion. Substitutes the current object attribute at the time of promotion. Substitutes the current object code at the time of promotion. Substitutes the current, source member name at the time of promotion. Substitutes the current source type at the time of promotion. Substitutes the current source file name at the time of promotion. For Release Management Packages
#OBJTYP #OBJNM9 #OBJATR #OBJCOD #SRCMBR #SRCTYP #SRCFIL
#FRMPRD #FRMVER #FRMRLS #TOPRD #TOVER #TORLS
Substitutes the name of the product the package will upgrade from. Substitutes the name of the version the package will upgrade from. Substitutes the name of the release the package will upgrade from. Substitutes the name of the product the package will upgrade to. Substitutes the name of the version the package will upgrade to. Substitutes the name of the release the package will upgrade to.
238
u s e r
g u i d e
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 (AfterOk).
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
240
u s e r
g u i d e
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 Syntax

ICHGRQSDTL 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.
1=Cancel 2=Proceed 3=Remove Cancels the processing of the ICHGRQSDTL command for this environment. This is the default value. Deletes the LF from request, but not from the target (requires manual delete from target). Deletes the LF from request and from the target.
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)
242
u s e r
g u i d e
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))
244
u s e r
g u i d e
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 Syntax

IEXCCKOCMD 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.
Character value *ALL Specify an object code name. Issues the command for all object codes. This is the default.
Member/Object name (MBROBJ) Specify the member/object name to issue the command for.
Name Generic* *ALL Specify a member/object name. Specify a wildcard selection, for example, .exe*. Issues the command for all member/objects. This is the default.
246
u s e r
g u i d e
Action code (ACTION) Specify the check out action that causes the command to run.
*ALL *CHANGE *CREATE *DELETE *RECOMPILE The command runs for all check out actions. This is the default. The command runs when change is the checkout action. The command runs when create is the checkout action. The command runs delete is the checkout action. The command runs recompile is the checkout action.
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 Examples
The 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
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 doesnt a particular special command work? Your user profile or group profile may not have the authority to the command.
Managing Concurrent Development

Concurrent 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.
248
u s e r
g u i d e
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.
250
u s e r
g u i d e
Advanced Topics
Advanced Topics
This 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. Validation and stamping is performed regardless of where the promotion initiates fromthe 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 requests 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
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.
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, seeHandling 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.
252
u s e r
g u i d e
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:
Message ID CPD0078 CPF0001 CPF1015 CPF3012 CPF3092 CPF3213 CPF3213 CPF4028 CPF5812 CPF9801 Description Value &3 for parameter &2 not a valid name. Error found on &1 command. Data area &1 in &2 not found. File &1 in library &2 not found. FILEATR specified not valid for &3 file &1. Members for file &1 more than maximum allowed. Members for file &1 more than maximum allowed. Open of member &1 was changed to SEQONLY(*NO). Member &3 already exists in file &1 in library &2. Object &2 in library &3 not found.
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
254
u s e r
g u i d e
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 activitiesthese 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 environments 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 Batch Promotion Steps
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 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.
256
u s e r
g u i d e
Scheduling Promotion Requests
Scheduling Promotion Requests

Compilation, 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 Status

The 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)
Expt-Pend Expt-Jobq Expt-Schd Expt-Run Expt-Fail The Export phase is ready for execution. The Export function was submitted to the job queue for processing. The Export function is scheduled for processing. The Export phase is executing. 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.
Compile Request Status Codes

Comp-Pend Comp-Jobq Comp-Schd Comp-Run A migration was requested and all member/objects were copied to the staging library. The compile function was submitted to the job queue for processing. The compile function is scheduled for compilation. 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. An error occurred during the compile requests phase. Review the job log to establish the probable causes.
Comp-Fail
258
u s e r
g u i d e
Promotion Step Internal Processing
Distribution Status Codes

Dist-Pend Dist-Jobq Dist-Schd Dist-Run Dist-Fail The compile process completed successfully (if required) and the request is ready for distribution to remote systems. Distribution to the remote system was submitted to the job queue for processing. Distribution to the remote system is scheduled for processing. The request is currently being distributed to the remote target libraries. An error occurred during the distribution phase. Review the job log to establish the probable causes.
Move Request Status Codes

Move-Pend The compile process (and the distribution process for remote environments) completed successfully and the request is ready for promotion. The Move Requests function was submitted to the job queue for processing. The request is scheduled to move to the target libraries. The request is currently being moved to the target libraries. An error occurred during the Move Requests phase. Review the job log to establish the probable causes. The request completed successfully.
Move-Jobq Move-Schd Move-Run Move-Fail Completed
Model Copy Status Codes (COOL:2E environments only)

MCpy-Pend MCpy-Jobq MCpy-Schd MCpy-Run The Model Copy phase is waiting to be executed. The Model Copy Request function was submitted to the job queue for processing. The Model Copy Request function is scheduled for processing. The Model Copy phase is executing. A migration was requested and all member/objects were copied to the staging library. An error occurred during the Model Copy phase. Review the job log to establish the probable causes.
MCpy-Fail

This section describes the internal processing that occurs during the promotion step.
259
Create Request
Compile Step
IM0021S
Move Step uses all libraries
From Source Library
Request Source Library
Target Environment Source
IM0021002
IM0021002X IM0021001X
From Object Library
IM0021
Request Objects Work Library
Object Stage Library
Target Environment Objects
Environment libraries
IM0021F
Removed From objects Library
Implementer work libraries
Target Environment Archives
IM0021002T IM0021001T
Replaced Target Objects
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.
260
u s e r
g u i d e
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.
262
u s e r
g u i d e
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 Move Step
The distribution step is detailed in Performing Distributions on page 271.
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.
264
u s e r
g u i d e
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.
Library Example IM0021 IM0021F IM0021N IM0021S IM0021002 IM0021001D IM0021001T IM0021001X TAP0021001 Description Request object work library (primary environment, secondary environment compile=N) From object holding library NetView/DM distribution library Request source library Environment object work library (secondary environment compile=Y) Environment distribution library Target object holding library Environment staging library Tape distribution library
The work library naming rules use the following conventions:

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. Promotion request number. Environment ID number (the sequence number of the environment on the request). Any letter in upper case is the actual literal value of that character.
rrrr eee CAPS
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.
266
u s e r
g u i d e
Host Work Libraries
Request Source Library

This work library contains all the source members for items on the request.
Created Deleted ASP Name Example Text During Create Requests. When the request is completed. Any ppprrrrS IM0021S Implementer rqs rrrr source
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 requests primary environment and all secondary environments that are compile N. All nonsource-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.
Created Deleted ASP Name Example Text During Create Request. When the request is completed. Any ppprrrr IM0021 Implementer rqs rrrr objects
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 Deleted ASP Name Example Text During the compile step for a request if the target environment Compiled required field is set to Y. When the environment goes to Completed status. Any ppprrrreee IM0021001 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.
Created Deleted ASP Name Example Text Every time a move begins (if it already exists, it is deleted). When the move successfully completes (not deleted if errors). Same ASP as the target environment. pprrreeeX (position 3 of prefix is not used) IM0021001X Implementer rqs rrrr env name staging
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 Deleted ASP Name Example Text When final processing for the request begins and all environments are successfully moved. When final processing is complete for the request. Same as the From objects library. ppprrrrF IM0021F Implementer rqs rrrr removed from objects
268
u s e r
g u i d e
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.
Created Deleted ASP Name Example Text When the move begins for the environment, only if the target environment is not archived. When the environment is Completed. Same as the target object library. pprrrreeeT (position 3 of the prefix is not used) IM0021001T Implementer rqs rrrr env name target objects
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.
Created Deleted ASP Name Example Text During the distribution step. After distribution, whether successful or not. Any pprrrreeeD (position 3 of the prefix is not used) IM0021001D Implementer rqs rrrr env name dist objects
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 Deleted ASP Name Example Text During the distribution step. After distribution, whether successful or not. Any TAPrrrreee TAP0021001 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.)
Created Deleted ASP Name Example Text During distribution. When NetView/DM calls to the system or the request is completed. Any ppprrrrN IM0021N Implementer rqs rrrr NetView/DM distribution
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 Deleted During distribution on the remote system. When environment is completed.
270
u s e r
g u i d e
Performing Distributions
his chapter describes the distribution and promotion of promotion requests to remote systems or multiple environments. This chapter covers: moving and distributing promotion requests by system displaying move promotion requests by system controlling remote job schedules using the Implementer Receiver Menu
271
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 andBatch 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.
272
u s e r
g u i d e
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.
Submitting Overrides
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.
panel.
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

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.
promotion request you want to redistribute and press ENTER.
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.
274
u s e r
g u i d e
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. The following requirements apply: 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.
276
u s e r
g u i d e
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
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.
promotion request you want to redistribute and press ENTER.
Common Questions Move/Distribute by System Submission Options
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. 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 MovePend 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.
278
u s e r
g u i d e
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 drilldown 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 Schedules

Remote 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.
280
u s e r
g u i d e
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.
282
u s e r
g u i d e
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.
*CURRENT Actual Date *MONTHSTR *MONTHEND *MON through *SUN The from and to dates default from the system. This is the default value. Specify an exact from and to date. The from date is the first day of the month. The to date is the last day of the month. Type an asterisk followed by the first three letters of any day of the week to indicate the from date.
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:
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 createdthe 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.
284
u s e r
g u i d e
Target environment (TGTENV) Specify the target environment from the request.
Name Generic* Specify the name of the target environment. 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. Includes all target environments requests are issued for.
*ALL
From date (FROMDATE)/To date (TODATE) Specify the date range to schedule the move.
*CURRENT Actual Date *MONTHSTR *MONTHEND *MON through *SUN *REQUEST The from and to dates default from the system. Specify an exact from and to date. The from date is the start of the month. The to date is the end of the month. Type an asterisk followed by the first three letters of any day of the week to indicate the from date. The dates and times do not change. This is the default value.
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.
Actual time range *CURRENT *REQUEST Specify exact from and to times. Defaults the time range from the system. The dates and times do not change. This is the default value.
Job Queue Library/Queue (JOBQ) Specify the job queue library and name for the move.
Name *SYSCTL *REQUEST Specify the name of a job queue and library. Uses the job queue specified in System Control. The job queue and library do not change. This is the default value.
Hold on job queue (HOLD) Complete this standard OS/400 Submit job parameter as required.
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:

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. 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. This does not resubmit a request at a scheduled status.
*ALL
*FAILED
4 Press ENTER.
286
u s e r
g u i d e
Using the Implementer Receiver Menu

The 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

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.
288
u s e r
g u i d e
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

the library is on your library list.

2 Type the command STRIR at the command line, and press ENTER to

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

Move Remote Requests (IMOVRMTRQS) command.
290
u s e r
g u i d e
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.

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.
Y O Blank The key is an unchanged global keythe specified key definition is equal to the global key definition. The global definition is overridden for this function key. The key is not a global keyit is defined globally, but one of the attributes is redefined on this panel.
Function Key The number assigned to the function key.

0 1-24 25 26 27 28 29 100+ ENTER Function keys 1 through 24 ROLLUP ROLLDOWN HELP HOME CLEAR 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 occurthey 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.
292
u s e r
g u i d e
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.
Y N The function key is valid on this panel. 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.
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.
Y N The function key displays. The function key does not display. If the valid flag is Y, the function key remains valid. An example of this is ENTER.
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.
293
294
u s e r
g u i d e
Handling 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. This chapter covers: archiving using the Archive to Tape features performing archive recovery performing emergency check out performing emergency create request
295
Archiving
Implementer 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.
296
u s e r
g u i d e
Using the Archive to Tape Features

Implementer 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 systemto 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
298
u s e r
g u i d e
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 Recovery
Once 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 crossenvironment 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 requeststhat 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
300
u s e r
g u i d e
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. The following requirements apply: 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 objectyou 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.
302
u s e r
g u i d e
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 Out

You 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.
304
u s e r
g u i d e
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 Promotion
When 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.
306
u s e r
g u i d e
Member and Object Handling

I
mplementer 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 itemthe 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
Compile Options
For 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 Management
Implementers 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 nonOS/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.
308
u s e r
g u i d e
Database Management
Managing NonSource-based SQL
Implementer provides full support for database files built using nonsource-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. Object Codes for Non-Source SQL
Special Characteristics SQLTABLE SQLVIEW SQLINDEX
Object Type SQL Table SQL View SQL Index
Object Code SQLT SQLV SQLI
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 DDSbased 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.
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 its 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.
310
u s e r
g u i d e
Database Management
Managing Source-based SQL (DDL)

For more information on optimizing promotions, see Optimizing Physical File Promotions on page 313.
Implementer provides full support for database files built using sourcebased SQL (OS/400 managed source), including the retention of existing triggers and constraints for source-based tables. 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. Implementers 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. Object Codes for Sourced-based SQL
Source Member Type SQLTABL SQLVIEW SQLINDX
Object Type SQL Table SQL View SQL Index
Object Code SQLTABL SQLVIEW SQLINDX
File Creation for Source-based SQL Physical Files Implementer supports the promotion of physical files created through SQL that exist in collection libraries.
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 DDSbased 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.
312
u s e r
g u i d e
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 nonoptimized 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 AfterMove 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.
314
u s e r
g u i d e
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 errorwithout 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.
316
u s e r
g u i d e
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, lets 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-sourcebased 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 DDSbased 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 Considerations

This 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 significantit 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
318
u s e r
g u i d e
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.

This 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 its 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.
320
u s e r
g u i d e
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 timejust 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
322
u s e r
g u i d e
is assigned to the object, and the modules that are used by the program are added to the Implementers 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 its own repository or Hawkeyes 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).
324
u s e r
g u i d e
S/36 Environment
S/36 Environment
Implementer 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 Environment
Implementer 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 Support

Implementer 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
326
u s e r
g u i d e
Integrating With Other Vendor Products

T
10
his 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
Application and CASE Software Products

Implementer 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 IBMs 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.
328
u s e r
g u i d e
American Software Integration
American Software Integration

American 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, ASIspecific 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.
Problem Source mismatch Checked out QSRC instead of USRC TSRC and USRC not copied Resolution Change source member type to TXT. Default source file must be USRCxxx. Object type special characteristics not entered.
AS/SET Integration
AS/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.
330
u s e r
g u i d e
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.
332
u s e r
g u i d e
AS/SET Integration
3 Define the special command as follows, and press ENTER.

Environment For Action When to do Sequence number Command (environment name) 6 2 10.0
ICHKADKDEP MBROBJ(#OBJECT) OBJCODE(#OBJCOD) FRMENV(#FRMENV) TOENV(#TRGENV)
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.)
Option
I N C
Description Ignore this dependency and continue checking. Ignore this and all subsequent dependencies. Copy this dependent object to the target environment and continue checking. Copy this and all subsequent dependencies to the target environment.
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, seeProblem Determination on page 253.
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
334
u s e r
g u i d e
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
Command Delete AS/SET definition (IDELADKDFN) Copy AS/SET definition (ICPYADKDFN) Definition Deletes an AS/SET definition from a given application set. 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. Verifies an AS/SET definition exists and retrieves the description.
Retrieve AS/SET definition (IRTVADKDFN)
Archiving AS/ SET Definitions Remote Distribution
After defining an archive application set for an AS/SET environment, the AS/SET definitions are automatically archived whenever you promote to the environment. The Implementer Receiver does not support AS/SET definitions; however, it does receive the generated objects.
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.
Value
0 1 2
Description Does not add generated objects to the promotion request. Adds only generated objects to the promotion request. Adds both generated source and objects to the promotion request.
BPCS Integration
BPCS 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.
336
u s e r
g u i d e
CODE/400 (CoOperative Development Environment/400) is a workstation-based client/server development environment, available with IBMs 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 Windowsbased 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 The coded character set identifier (CCSID) to use to send information to the desktop. Specify Y to display a message or N to not display messages. 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. Specify a server name. You can specify <> (empty brackets) to use the first active CODE/400 server.
37
OS400
<LOCAL>
337
Value
Description 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)
CODEEDIT
"<>&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.
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.
338
u s e r
g u i d e
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 preexisting 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 isnt 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.
340
u s e r
g u i d e
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 stepthe 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.
342
u s e r
g u i d e
Model Object Types

The model objects types managed by Implementer include the following:
Type ACP APP ARR CND FIL FLD FUN MSG Definition Access path Application area Array Condition File Field Function (versionable) Message (versionable)
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:
343
FIL B MSG E
List P FIL B CND C ACP D FLD G
List Q MSG E CND C FUN H
List A OBJ A
ACP D
FUN H
APP F CND C
FLD G
List *ALLOBJ FIL B CND C ACP D FLD G MSG E CND C FUN H
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).
344
u s e r
g u i d e
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. 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.
SQL Support for COOL:2E
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
346
u s e r
g u i d e
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:
Status
Blanks
Description 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. 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. Indicates a model object is checked out with an action of 8=Regen. *REGEN locks never change to a status of *CONFLICT or *RESOLVED. 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. 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.
*CHECKOUT
*REGEN
*CONFLICT
*RESOLVED
Working With Model Object Lists Checking Out Model Objects
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. 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.
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
348
u s e r
g u i d e
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:
Action 1=Change 2=Create 3=Delete 8=Regen Description Assigned when an existing model object is changed or explicitly checked out. Assigned when a new model object is created. Assigned when an existing model object is deleted. Assigned when an existing model object that is not checked out is generated, or by specifying regeneration only when checking out a model object.
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
350
u s e r
g u i d e
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:
*EDIT *VIEW *NOAUT The developer can perform the edit action. The developer can view the COOL:2E model object. The developer does not have authority to perform the action.
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,
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.
352
u s e r
g u i d e
Where IMrrrreeeM is 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. Promotion request number. Environment ID number (the sequence number of the environment on the request as established in target environments or environment groups). Model.
rrrr eee
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:
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.
354
u s e r
g u i d e
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
Integrating With Other Vendor Products 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 ChangeControlled 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.
356
u s e r
g u i d e
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:
Change type Object Only (OBJ) Description 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. 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. 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. 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.
Generation Required (GEN)
Private (PVT)
Public (PUB)
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.
358
u s e r
g u i d e
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 EXCUSRPGMswith source and without source.
360
u s e r
g u i d e
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: Create an XCB object code. 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: Create an XCB object code. 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 changecontrolled 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
362
u s e r
g u i d e
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.

The 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 Support for J.D. Edwards DREAM Writer Versions
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).
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 versionSpecify 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 versionsSpecify *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.
364
u s e r
g u i d e
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 fourcharacter 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 Compiling From the Workbench
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. 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. 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.
Archiving J.D. Edwards Special Objects

366
u s e r
g u i d e
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 Integration
LANSA 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.
368
u s e r
g u i d e
LANSA Integration
Promoting
The user profile (or group profile) used to promote LANSA objects into an Implementer environment with archiving activated must be the partitions 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:
Expt-Pend Expt-Jobq Expt-Schd Expt-Run Expt-Fail The Export phase is ready for execution. The Export phase is only used by LANSA environments. The Export function was submitted to the job queue for processing. The Export function is scheduled for processing. The Export phase is executing. 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.
Displaying Process/ Functions Archiving
From My Workbench, press F11=Display comments three times to display LANSA process/functions. This also displays any comments you specify in check out.
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.
370
u s e r
g u i d e
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 outthe file library specified in the to environment definition. Promotionthe Implementer work library. Archivingthe 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. 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.
LANSA RDML Function Compare
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.
372
u s e r
g u i d e
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 (099) 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:

*FILE *YES *NO The printer file definitions determine whether to hold the report output. The name of the printer file is NVCMMBP. The report output is held. The report output is not held.
Submit Specify whether to submit the job to batch or process interactively.

*YES *NO Submits the job to batch. The name of the submitted job is LANSACMP. The job runs interactively.
Job description/Library 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.
374
u s e r
g u i d e
LANSA Integration
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... Member File Library Source data Is changed to this term in the LANSA Report Function Process Partition LANSA RDML command
Note that old and new commands are printed in their entirety for multipleline commands, even if only a portion of that command is different within the two versions.
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 Integration
Powerhouse 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 differentobject names carry a two-character prefix based on the creation command:
Creation Command QTP QUICK QUIZ QDESIGN Prefix PT PK PZ PK
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.
376
u s e r
g u i d e
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 Products

Implementer 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 IBMs Operations Navigator, but the integration discussed here only extends to the host-based interface.
Version Requirements Abstract UserDefined Options
Implementer links and works with any release of ABSTRACT.
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.
378
u s e r
g u i d e
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
Option Description Execution Command IS Select member/object for checkout I (I=Interactive, S=Submit, Blank=Either)
ICHKOUTSEL MBROBJ(&N) OBJLIB(&L) OBJTYPE(&T) OBJATR(&A) SRCFILE(&SRCLIB/&SRCFIL) &SRCTYPE(&A)
Object type Object attribute
*ALL *ALL
ICHKOUT
Option Description Execution Command Object type Object attribute IC Check out I (I=Interactive, S=Submit, Blank=Either)
?
*ALL *ALL
ICHKOUT MBROBJ(&N) OBJCODE(&A)
379
ICRTRQS
Option Description Execution Command Object type Object attribute IR Create promotion request I (I=Interactive, S=Submit, Blank=Either)
?
*ALL *ALL
ICRTRQS MBROBJ((&N &A))
IDDCBD
Option Description Execution Command Object type Object attribute IB Add item to Implementer clipboard I (I=Interactive, S=Submit, Blank=Either)
?
*ALL *ALL
IADDCPD MBROBJ(&N) OBJCODE(&A)
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.
380
u s e r
g u i d e
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 Integration
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. 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 Integration
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 Integration
NetView/DM is a mainframe-based distribution management product from IBM that efficiently manages distribution to multiple systems at the same time.
Net/Wrk400 Integration
Net/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 Integration
PathFinder 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.
382
u s e r
g u i d e
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.
Option IS Description Add to Check Out Command
ICHKOUTSEL MBROBJ(&N) OBJLIB(&L) OBJTYPE(&T) OBJATR(&A) SRCFILE(&SL/&SF) SRCTYPE(&ST) ICHKOUT MBROBJ(&N) OBJCODE(&ST) ICRTRQS MBROBJ((&N &ST))
IC IR
Check Out Create Request
PathFinder PDM Options for USERPDM
The USERPDM file, included with PathFinder software, contains the following user-defined options, which can be used within PDM.
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.
Option IC IR ID OU Description Check Out Create Request DesignTracker Entity List Object Where Used Command
ICHKOUT MBROBJ(&N) OBJCODE(&T) ICRTRQS MBROBJ((&N &T))
CALL PGM(DTSESLC) PARM(&N &S &X &T &A &ST ) HAWKEYE/DSPOBJU OBJ(*ALL/&OBJECT)OBJTYPE(&OBJTYP)
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 Integration
After 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.
384
u s e r
g u i d e
P P E N D I X
Compare/Merge Member Commands

T
he 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.
386
u s e r
g u i d e
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.
Source File QASMSRC QBASSRC QCBLSRC QCLSRC QCMDSRC QDDSSRC QLBLSRC QPASSRC QPLISRC QRPGSRC QTXTSRC QUDSSRC Source Type *BAS *BAS *CBL *CLP *CMD *DDS *CBL *PAS *PLI *RPG *TXT *UDS
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.
388
u s e r
g u i d e
Exclude comment lines (EXCOMMENT) Specify if comment lines are ignored in the comparison or handled in the same manner as all other lines.
*NO *YES Determines if the comment lines are handled as any other line. Differences in comment lines are indicated. 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.
Exclude blank lines (EXCBLKLINE) Specify if blank lines are ignored in the comparison or handled in the same manner as all other lines.
*NO Causes blank lines to be viewed as regular lines, and indicates any differences in the number of blank lines and their placement. 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.
*YES
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.
*SRCTYPE The compression of blanks is determined on a member-bymember 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. 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. 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.
*YES
*NO
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 15 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 15 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.
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. 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.
Equal lines before, if *CHG
Output queue (OUTQ) Specify which output queue to place the comparison report on.
Name *JOB Type a specific output queue name. Uses the output queue associated with the job.
390
u s e r
g u i d e
Library (Output queue) Specify the library the output queue resides in.
Name *LIBL Type the name of a specific library. 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.
Hold spooled files (HOLD) Specify whether to hold the report output.
*FILE Indicates that the printer file definitions determine whether to hold the report output. The name of the printer file is NVCMMBP. The report output is held. The report output is not held.
*YES *NO
Submit (SUBMIT) Specify whether to submit the report to batch or run interactively.
*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. The report runs interactively.
*NO
Job description (JOBD) Specify the name of the job description for the submitted job.
MWIJOBD Name This is the default value. The name of the job description used when submitting the job. It is ignored if not submitted.
Library (Job description) Specify the library the job description resides in.
Name *LIBL The specific library name. 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.
392
u s e r
g u i d e
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.
394
u s e r
g u i d e
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 The valid options are:
*FILE *YES *NO The printer file definitions determine whether to hold the report output. The name of the printer file is NVCMMBP. The report output is held. The report output is not held.
Submit Specify whether the job submits to batch or runs interactively.

*YES *NO Submits the job. The name of the job is LANSACMP. The job runs interactively.
Job description/Library 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.
396
u s e r
g u i d e
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 Member File Library Source data Is changed to this term in the LANSA Report Function Process Partition LANSA RDML command
397
Note that old and new commands are printed in their entirety for multipleline 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 *NONE Specify the Base source member to be used in the merge. 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.
398
u s e r
g u i d e
Base file (BASEFILE) Specify the name of the source file that contains the base members. This is a required field.
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. Use this option if BASEMBR is *NONE.
*NONE
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).
*BASEMBR Name Defaults to the same member entered in the Base Member field. Specify the Production source member to use in the merge.
Production file (PRODFILE) Specify the name of the source file that contains the production member.
*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. Specify the file containing the production version of the members to merge.
Name
Library (Production file) Specify the name of the source library that contains the production source file.
*BASELIB Name The Base source library is used as the production library. 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 member *BASEMBR Name Specify the enhanced member name. Defaults to the same member entered in the Base Member field. 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.
Enhanced file Specify the name of the source file that contains the enhanced members (up to five enhanced versions are supported).
*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. Specify a source file that is different from the base source file.
Name
Library (Enhanced file) Specify the name of the source library that contains the enhanced source file (up to five enhanced versions are supported).
*BASELIB Name The Base source library is used as the enhanced library. Specify an existing library that is different from the base library.
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:
400
u s e r
g u i d e
*FILENAME The source file name determines the source type. The following list provides the source files supported and the resulting source types.
Source File QASMSRC QBASSRC QCSRC QCBLSRC QCLSRC QCMDSRC QDDSSRC QIMGSRC QLBLSRC QMISRC QPASSRC QPLISRC QRPGSRC QTBLSRC QTXTSRC QUDSSRC Source Type *ASM *BAS *C *CBL *CLP *CMD *DDS *PRTIMG *CBL *ASM *PAS *PLI *RPG *TBL *TXT *UDS
*MBR The source type is determined from the members 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.
401
Merge output (OUTPUT) Specify whether to print the Target Source Merge Report and target source member.
*BOTH *FILE Produces the merged source in the target member and the Merge Report. 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. Produces the Merge Report. No merged source is output. Same as *PRINT. No merge source or report produced. Use this option only if Member List Analysis is *YES and no other output is needed.
*PRINT *LIST *NONE
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.
*ENH *BASE *PROD *ENHn Equal lines are drawn from the Enhanced source member. Equal lines are drawn from the Base source member. Equal lines are drawn from the Production source member. (where n is 1 through 5) Equal lines are drawn from the Enhanced N source member.
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 15 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.
402
u s e r
g u i d e
You should not ignore columns 15 for free format languages such as CLP, PL/1, and COBOL. The columns can contain valid program statements for these languages.
Source Exists In... Description Case 1 Base Yes Prod Yes Enh Yes Standard case: You use (possibly modified); Vendor has retained (possibly modified) You use (possibly modified), vendor has deleted (or has not modified) You do not use (or have not modified) Neither you nor the vendor use (nor you or the vendor modified) New for both vendor and you Written by you New from vendor Y Merged
Yes
Yes
No
3 4 5 6 7
Yes Yes No No No
No No Yes Yes No
Yes No Yes No Yes
N N Y Y Y
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:
403
The function does not merge this member. Case 4 Neither you nor the vendor supports this source. Resulting Action: The function does not merge this member. 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 vendors source. It could be a source member received from the vendor after original distribution of the vendors 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.
404
u s e r
g u i d e
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.
*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. Specify the name of an individual member to receive the merged source.
Name
Target source file (TGTFILE) Specify the name of the source file to contain the indicated Target source member.
*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. The name of a specific target source file that the target member will be placed in. The name of the library containing the Target source file. 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. Type a specific target source file library that the target member will be placed in.
Name Library (Target file) *BASELIB
Name
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.
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) The valid options are:
*YES *NO Highlights by double printing the excluded lines. Does not highlight excluded lines.
Excluded lines indentation (010) 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.
*NONE *INLINE *SUMMARY *BOTH Messages do not print. Messages print in-line or in the body of the report. Messages print in the summary section at the end of the report. Messages print in the body of the report and at the end of the report in the summary section.
Output queue (OUTQ) Specify an output queue to place the merge report.
*JOB Name Uses the output queue associated with the job. Specify an output queue name.
406
u s e r
g u i d e
Library (Output Queue) Specify the library the output queue is located in.
Name *LIBL Specify a library for the designated output queue. Searches the library list for the specific output queue.
Hold spooled files (HOLD) Specify if the report output is held on the 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. The report output is held. The report output is not held.
*YES *NO
Submit (SUBMIT) Specify whether to submit the report to batch or run interactively.
*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). The report runs interactively.
*NO
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.
Library-name *LIBL Type a specific library for the job description. Searches the library list for the specific job description.
407
Merge Member Merge Report Listing
408
u s e r
g u i d e
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.
410
u s e r
g u i d e
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
412
u s e r
g u i d e
P P E N D I X
Glossary
action
B
1 = Change 2 = Create 3 = Delete 8 = Regen (only valid for COOL:2E model objects) 9 = Recompile
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.
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 takefrom 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 is a function used to recover from or back out of a promotion request. It is also called rollback. 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.
archive recovery archiving
414
u s e r
g u i d e
batch programs for AS/SET
batch programs for AS/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. 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. 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 describes the process of promoting a member/object back into production after it has been checked out and the lock is removed. Check out takes a member/object from a production environment (or quality assurance environment), copies it to a developers development library or environment, and places a lock on it. This makes the member/ object in use by the user who checked it out. 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 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. 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.
change controlled model change list
check in check out
clipboard
compile requests
concurrent development
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. 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 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 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. 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. A data model is an entity defined in ADK repository that refers to one or more files, their associated fields, and their associated relationships. 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. A design request approval can be: 0 = No 1 = Yes 2 = Pending For an approval type of: 1 = Development 2 = Test 3 = Production environment
constraint
create request
currency
current model object
data model design request
design request approval
design request disposition
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)
416
u s e r
g u i d e
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 DLO
See IFS directory. 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. 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.
environment ID
417
environment library list
environment library list
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 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. 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. 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. 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.
environment type
export
export list
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. 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
418
u s e r
g u i d e
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. 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 directory
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:
IFS File Name Member/Object Name Object Code
HelloAS400World.class HelloAS400World
HELLOAS4~1 HELLOAS4~1
.CLASS .
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.
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 environments 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. The Implementer Receiver is a component of Implementer that resides on each remote system that changes can be distributed to. 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 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 stands for J.D. Edwards. 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.
Implementer Receiver import issues
JDE JDE data dictionary elements
420
u s e r
g u i d e
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 are data records keyed to a menu name. This allows changes to menus without the need of programming. 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 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 are objects supported by J.D. Edwards such as userdefined codes, DREAM Writers, Member Master, Data Dictionary, Soft Coding, and Menus. JDE traditional objects are traditional objects that require J.D. Edwards compiling, for example, RPG programs, CL programs, Assemblers (ASM). JDE user-defined codes (UDC) is a generic table system for data field validation, controlled by three keys: 1System number 2Table name 3Element
JDE menus JDE soft coding or vocabulary overrides
JDE software inventory or member masters JDE special objects
JDE traditional objects JDE user-defined codes (UDC)
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. A LANSA function is an executable OS/400 program defined by you and created by LANSA. LANSA objects are objects created in LANSA such as files, fields, processes, and functions. These objects are not necessarily OS/400 objects. 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.
LANSA function LANSA objects lock
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. 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). 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
model object
model object list
Once you use a model object list for check out, it becomes a change list.
model object name move request
A model object name is the 25-character name given to a COOL:2E model object. 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. 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.
My Workbench
422
u s e r
g u i d e
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. 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. A partition is a division of a LANSA system that has its 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. 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
owning model object
partition
path
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 target environment
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). 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. 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 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). 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. 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.
process
project promotion
promotion request
qualified name
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 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. A requester is the user who creates a promotion request. 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.
repository
requester request number
424
u s e r
g u i d e
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 09 and AZ. 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 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 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. 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.
required objects
reset authorities
session 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. 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.
step
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. A surrogate is the internal identifier to each COOL:2E model object. 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. 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. 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. 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. See My Workbench. 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).
surrogate target environment group
trigger
version
version group workbench work library
426
u s e r
g u i d e
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
A
ABSTRACT integration access from Implementer 378 overview 378 user-defined options 378 using ICHKOUT command 156 version requirements 378 Action change 98, 137, 147, 181, 350, 413 check out 120 create request 194 create 98, 194, 350, 413 defined 413 delete 98, 350, 413 check out 121 recomp 98, 201, 256, 261, 262, 413 regen 98, 348, 350, 413 Activity Report 25 Add to Clipboard (IADDCBD) command 60 Add to Clipboard IFS (IADDCBDIFS) command 60 Adopting authority 21 Advanced System Concepts (ABSTRACT) 378 Allocating objects during move step 225 American Software integration compiling Cobol programs 330 message file considerations 330 object codes for checkout and promotion 329 overview 329
AOS Message Manager integration 380 Application path defined 413 feature overview 19 project paths 107 Application set defined 414 Archive library 296 Archive recovery 300 defined 414 of related requests 204 with object version stamping 252 Archive reports Archive History Report 26 Archives by Environment Report 299 Archives by Request Report 299 Archives per Tape Report 299 Archive to tape 297 change volume ID 299 menu (IMARCTAP) 297 reports 299 restoring 299 saving 298 Archiving check out 303 COOL:2E model objects 303 design request 303 environment 303 LANSA objects 303 library 303 project reference 303 defined 414 environment library 42 logical files 264, 296 multiple target environments multiple objects 296 object renaming 296 object version stamping in rollback 252 objects not compiling source 300 physical files 264 promotion internals 264, 296 promotion request created during 300 same library, multiple
427
Index environments 296 single change or entire request (multiple objects) 300 source compiling 300 renaming 296 tables and physical files 296 usually production only 296 AS/NET integration 381 AS/SET integration archiving definitions 335 AS/SET commands 335 checking out 331 commands 335 definitions special characteristic 118 dependency checking 332 override promoting generated source/ object 336 overview 330 promoting 334 remote distribution 335 X file management 182, 335 Authority environment information to objects 42, 43 LANSA Export/Import 152, 205 OS/400 security 19 security administrator rights 38 MWIPROD 38 QSECOFR 38 security risk object codes 188 user 151 Authority method toggle 189 Authorization list environment information 43 Before you begin 1 Binding directory defined 415 BPCS integration compiling 223 overview 336 Build List for changed members 194 results in check out 115 Build member/object list, see Build List
45
C
Capabilities restricted 43 user 43 Change overview 53 Change controlled model, defined 415 Change delimiter IMRGMBR parameter 406 Change list, defined 415 Check In defined 415 Check Out adding related objects 139 AS/SET definitions special characteristic 118 assign revision numbers 122 comment 123 concurrent development from Workbench 69 COOL:2E model object lists 342 create member/object during 121 defined 415 emergency from Workbench 69 one step method 305 for concurrent development 136 for reject 116 from Clipboard in Workbench 69 ICHKOUT command 156 IEXCCKOCMD special command overview 245 substitution variables 233 IFS files and directories 127 methods overview 113 where defined 113 multiple objects single source 123 multiple occurring mbr/obj 140
B
Base file ICMPMBR parameter 387 IMRGMBR parameter 399 Base member ICMPMBR parameter 386 IMRGMBR parameter 398 Batch create request in batch 173 Batch programs in AS/SET, defined 415
428
u s e r
g u i d e
Index object name rules 155 object version stamping 125 one step method determine default from environment 113 from Clipboard 58 from Work with Objects 113 overriding 68 overview 53 PDM option 162 physical file data 150 related environments 120 related objects 139 restricting 112 object codes 112 user capabilities 112 select environment 118 select items after initiating, from Workbench 66 single source multiple objects 123 special commands 112, 233, 245 stamp objects with issue or DR number 125 status 346 substitution variables 233 task check out for concurrent development 136 create member/object 121 delete member/object 121 ICHKOUT command 156 ICHKOUT command via PathFinder 162 ICHKOUT command via PDM 162 related objects 139 single source multiple objects 123 using the menu 112 traditional, from Workbench 66, 113 using different source and object names 151, 219 using ILE object codes 148 using PathFinder 167 web-based, for IFS objects 135 with design request 141 Work with Objects, from Workbench 67 Check Out (ICHKOUT) command 156 *PATH default 157 Check Out (ICHKOUTIFS) command *PATH default 131 CHGRMTRQS command 281 Clipboard add items with ADDCBDIFS command 60 add items with IADDCBD command 60 create requests with ICRTRQS command 63 defined 415 one step check out and promotion 58 positioning in a subfile 59 processing with IPRCCBD command 63 CODE/400 integration 337 Cognos (Powerhouse) integration 376 Commands 245 CHGRMTRQS Change Remote Request 281 IADDCBD Add to Clipboard 60 IADDCBDIFS Add to Clipboard IFS 60 ICHKADKDEP Check AS/SET Dependencies 332 ICHKOUT Check Out 156 ICMPLRQS Complete Request 254 ICMPMBR Compare Members 386 ICMPRQS Compile Request 224, 256 ICOMPILE Workbench Compile 79 ICRTRQS Create Request 63, 196, 260 IDLTLIBREF Delete Library References 98 IEXCCKOCMD check out special command 112 IEXCCKOCMD special command 231, 245 IEXCRQSDTL promotion special command 230, 236 IMARCTAP Archive to Tape 297 IMOVRMTRQS 256, 289, 290 IMOVRQS 228, 256 IMRGMBR Merge Members 398 IPRCCBD Process Clipboard 63 IRSTRMTRQS Restore Remote Request 289 ISETLIBL 54, 83 RMVDIR Remove Directory (IFS) 217 STRCM Start COOL:Xtras_CM 12 STRCR Start COOL:Xtras_CM Receiver 12 STRIM Start Implementer 12, 13 STRIR Start Implementer Receiver 12 WRKMBRPDM Work with Members using PDM 78 YANZMDLLST 352 YCHKMDLCRT 353 YCPYMDLOBJ 352 YCVTCNDVAL 354, 355 YCVTMDLMSG 354, 355
429
Index YEDTMDL 357 YEDTMDLLST 348, 357 YPRMMDLLST 352, 354 YSBMMDLCRT 353 Comments bypass in create request 87, 175 in check out 123 Compare Members (ICMPMBR) command 386 Base file (BASEFILE) 387 Base member (BASEMBR) 386 Compare to file (CMPFILE) 387 Compress blanks (COMPRESS) 389 End column (ENDCOL) 390 Exclude blank lines (EXCBLKLINE) 389 Exclude comment lines (EXCOMMENT) 389 Hold spooled files (HOLD) 391 Output queue (OUTQ) 390 Print options (PRTFILTER) 390 Source type (SRCTYPE) 387 Start column (STARTCOL) 390 Workbench 78 Compare to file ICMPMBR parameter 387 Compile command parameters 187 Compile listings promotion internals 263 Compile request defined 415 from Workbench 79 ICMPRQS command 224, 256 overview 53 start member after comp-fail 223 submit compile request 220 Compile step change job queue during 187 command parameters 187 default compile order 174 library list considerations environment library list 44 for vendor integration 44 object version stamping 220 order based on object code sequence 174 promotion internals 262 QCMDEXC program 188 retain printer attributes 188 with vendor integrations 223 work library 222 Compiling 21 Complete Request (ICMPLRQS) command 255 Completed, status 259 Compress blanks ICMPMBR parameter 389 CompFail, status 258 CompJobq, status 258 CompPend, status 258 CompRun, status 258 CompSchd, status 258 Concurrent development 112 check out for 136 requests defined 415 Concurrent Development Report 25 Conflict requests defined 416 Conflict resolution before promotion 172 Constraint defined 416 Constraints in promotion 313 Conventions 4 COOL:2E check out not to COOL:2E session list 344 status 346 commands YANZMDLLST 352 YCHKMDLCRT 353 YCPYMDLOBJ 352 YCVTCNDVAL 354, 355 YCVTMDLMSG 354, 355 YEDTMDL 357 YEDTMDLLST 348, 357 YPRMMDLLST 352, 354 YSBMMDLCRT 353 managing EXCUSRPGM and EXCUSRSRC 359 model considerations analyzing model list 352 change list 344 check out 342, 347, 350 concurrent development 349 COOL:2E to traditional 354 create request 352 development activities 345 explicit checkout 348 generating and compiling 353 impact analysis 359 implicit checkout 348 model object lists 342, 343, 344
430
u s e r
g u i d e
Index move step 354, 355 object naming 345 promoting model information 351 regeneration 348 remote considerations 363 updating target model 352 use change controlled model 356 versionable model objects 349 model library 41 model value YFRFVNM 355 YMSGVNM 355 YSYSCHG 342 session list 344 COOL:Xtras CM, see COOL:2E 342 Create Object (CRTOBJ) command Job description (JOBD) 391, 407 Submit (SUBMIT) 391, 407 Create Request add target environments 199 change compile commands 187 copy request 195 create requests in batch 173 defined 416 from Workbench 86 ICRTRQS command 63, 196, 260 member list 193 methods, where defined 174 object code list 192 one step promotion access Create Request panel 176 optimize PF promotions 183 overrides change request defaults 205 job submission defaults 186 optimize PF promotions 185 remove items in from environment 205 PDM option 198 process overview 174 promotion groups 85 evaluation 85 promotion methods one step promotions 175 traditional promotions 177 selecting from locks 189 special commands 229 task 178 Create step promotion internals 260 Currency defined 416 Current model defined 416 Customer Support options
D
Data areas environment library considerations 41 IMEMGSTP emergency submit through step 252, 306 IMMULTOBJ 123 IMREJECT 153 IMWRNTRGLF 316 ITAPEVOLUM 299 LFREFOBJ 43 PFREFOBJ 43 promoting data area values 318 Data conversion programs environment library list 229 Data models defined 416 Database default library 41 Database files environment 45 Database management DDS files optimize PF promotions 313 process overview 312 promoting logical files 316 promoting physical files 313 triggers and constraints 313 process overview 308 SQL archive and recovery of SQL DDL objects 310 build list consideration 310 creating source SQL logical files 312 creating source SQL physical files 311 managing non-source SQL 309 object codes for non-source SQL 309 object codes for source SQL 311 process overview 311 DDM management special commands for 230, 240 Delete member/object at check out 121 Dependency checking 139
431
Index Design Request approvals, defined 416 change, from Workbench 101 check out 141 create promotion request 172 defined 416 disposition, defined 416 entity list select member/object 144 promotion 172 stamp object with DR number 125 status, defined 417 use multiple DRs from Workbench 99 DesignTracker Design Request, defined 416 entity list 144 Developer creating promotion requests 181 role defined 39 Development environment type 41 Directory defined 419 Display files move step considerations 225 Distribute Request by System task 273 Distribution by system 273 Distribution step 256 DistFail, status 259 DistJobq, status 259 DistPend, status 259 DistRun, status 259 DistSchd, status 259 DLO defined 417 Document conventions 4 End column ICMPMBR parameter 390 IMRGMBR parameter 402 Enhanced members IMRGMBR parameter 400 Entity List select member/object 144 Environment administrator capabilities 44 multiple administrators 44 Environment Groups 45 Environment path defined 414 Environment Report 26 Environments archive library 42 defined 417 Environment ID defined 417 groups 45 integrity check 45 libraries 41 library list defined 418 library list considerations 44 object code information 45 overview 40 related 120, 140 multiple occurring mbr/obj 140 related, defined 424 source files 42 special commands 22, 229 types 40 defined 418 Establish environment authorities, see Reset Authorities 42 Exclude blank lines ICMPMBR parameter 389 Exclude comment lines ICMPMBR parameter 389 Excluded lines indentation IMRGMBR parameter 406 EXCUSRPGM considerations 360 EXCUSRSRC considerations 360 Export defined 418 Export List defined 418 Expt-Fail, status 258, 370 Expt-Jobq, status 258, 370 Expt-Pend, status 258, 370 Expt-Run, status 258, 370
E
Emergency archive recovery 295, 300 auto check out 302 check out 295 from Workbench 304 one step method 305 create request 295, 306 from Workbench 306 create request submit through step promotion request 252 promotions 252
306
432
u s e r
g u i d e
Index Expt-Schd, status

258, 370
F
File defined Files join logicals 189 promoting field reference files 174 promoting logical files 316 promoting non-source SQL tables 309 promoting physical files 313 Folder defined 418 Function defined 418 Function keys work with, menu option 291 Function redirection defined 419
418, 419
G
Getting help 5 Glossary 413
H
Hawkeye Systems, Inc. (PathFinder) integration 382 Highlight excluded lines IMRGMBR parameter 406 Hold spooled files ICMPMBR parameter 391 IMRGMBR parameter 407
I
IBM (NetView/DM software) 381 ICHGRQSDTL Change Request Detail command 245 ICHKOUT Check Out command 156 ICMPLRQS Complete Request command 254 ICMPRQS Compile Request command 224, 256 ICOMPILE Workbench Compile command 79 ICRTRQS Create Request command 260 via PDM 198 Identify work
overview 52 IDLTLIBREF Delete Library Reference command 98 IEXCCKOCMD command 112, 231, 245 IEXCRQSDTL command 23, 230, 236 IFS auto-create object code 212 directory upgrade during promotion 216 objects auto create object code 134, 215 checking out 127 java optimization 218 promoting 212 support for 18 using mounted drives 18 web-based check out 135 web-based promotion 213 IFS directory defined 419 IFS file defined 418 IFS object defined 419 ILE converting RPG source code 163 enhanced support for 18 managing ILE development 319 object codes for check out 148 IMARCTAP command 297 IMCMEX01 exit program 350 IMEMGSTP data area 252 IMMULTOBJ data area 123 IMOVRMTRQS command 256 IMOVRQS command 228, 256 Impact analysis 20, 139 Implementation object defined 420 Implementer Receiver defined 420 menu 287 Import defined 420 IMPRFX data area 266 IMREJECT data area 153 IMWRNTRGLF data area 316 Integrated File System, See IFS 419 Integrity Manger using for issue management 9 ISETLIBL command 54, 83 Issue management solutions 8
433
Index using DesignTracker and Integrity Manager 10 using DesignTracker, stand-alone 8 using Integrity Manager and Implementer 9 Issues stamp objects with issue number 125 ITAPEVOLUM data area 299 compile step 223 Implementer jobs 256 Journaling database files 264 logical files using MIMIX 316 physical files using MIMIX 315
K
Keyword restriction defined 421 KnowledgeNet (Net/Wrk400 software)
381
J
J.D. Edwards archive recovery 367 archiving special objects 366 data dictionary defined 420 defined 421 Dream Writer defined 421 integration overview 363 Menu defined 421 promoting printer files 366 software inventory or Member Master defined 421 special objects check out 365 create request 365 defined 421 naming User Defined Codes 365 promotion 366 remote distribution 366 traditional object support 364 traditional objects defined 421 user defined codes (UDC) defined 421 Java optimization, for IFS objects 218 JDE defined 420 Job description CRTOBJ parameter 391, 407 MWIJOBD 44, 253, 256 batch programs 256 Job logging level in System Control Maintenance 253 Job logs 20 audit trail information 253 from promotion step 253 number to retain 253 Job queue
L
Lakeview Technologies, See MIMIX 316 LANSA 367 archiving 370 check out comment field 118 environment 118 multiple functions 118 object code 118 create request 369 export list 175, 182 LANSA object in compiled form 175 multiple functions 182 object codes 182 promote compiled form 182 distribution local environments 371 remote environments 371 export/import authorities 152, 205 function, defined 421 object, defined 421 promotion 369 remote distribution 371 save file name 371 save files and libraries 371 Web components 367 Level check adding related objects in promotion 207 compiling 222 library list defined incorrectly 44 LFREFOBJ data area 43 Library archive 42 database default 41 defaults, overriding 42 development 41
434
u s e r
g u i d e
Index program default 41 promotion work libraries 270 source default 41 stage 263, 264, 268 Library integrity check 45 Library list environment 44 for compiling 222, 229 for special commands 44 for vendor integrations 44 level check if defined incorrectly 44 MKSIM library requirement 44 setup, from Workbench 83 Lock defined 421 Lock Report 25 Locking objects during move step 225 Locks assign multiple DRs with lock 99 changing 97 deleting 98 removed on promote to production 112 Logging CL statements 253 Logging level promotion step 253 Logical files archiving 264, 296 controlling remote promotions 316 journaling 264 move step considerations 225 promotion internals 262, 263 Lotus Notes and Domino integration 376 command options, See Start Implementer (STRIM) command 13 Implementer Menu 12 Implementer Receiver Menu 287 Merge basis IMRGMBR parameter 402 Merge Members (IMRGMBR) command 398 Base file (BASEFILE) 399 Base member (BASEMBR) 398 Change delimiter 406 End column (ENDCOL) 402 Enhanced members (ENHMBRS) 400 excluded lines indentation 406 from Workbench 79 highlight excluded lines 406 Hold spooled files (HOLD) 407 Merge basis (BASIS) 402 Merge output (OUTPUT) 402 Output queue (OUTQ) 406 overview 398 Print options (PRTOPTIONS) 405 Production file (PRODFILE) 399 Production member (PRODMBR) 399 Source type (SRCTYPE) 400 Start column (STARTCOL) 402 Target file (TGTFILE) 405 Target source member (TGTMBR) 405 Merge output IMRGMBR parameter 402 Messages from promotion step 253 MIMIX 381 journaling logical files 316 journaling physical files 315 MKSIM Implementer library 44 Model object defined 422 Model object list defined 422 Model object name 343 defined 422 Model value YFRFVNM 355 YMSGVNM 355 YSYSCHG 342 Mounted drives IFS on Windows NT Server 18 Move Remote Request (IMOVRMTRQS) command 256 Move request defined 422 IMOVRQS command 228, 256
M
Maintain request 211 Manage locks overview 54, 97 MCpyFail, status 259 MCpyJobq, status 259 MCpyPend, status 259 MCpyRun, status 259 MCpySchd, status 259 Member/object defined 422 name rules 155 special considerations 318 status history 90 table of status codes 91 Menus
435
Index remote job scheduling 280 submit move 226 Move Request by System overview 272 task 273 Move requests, on remote system 290 Move step 224 promotion internals 263 MoveFail, status 259 MoveJobq, status 259 MovePend, status 259 MoveRun, status 259 MoveSchd, status 259 Multiple environments archive library per 296 Multiple paths environment on 46 MWIJOBD job description 44, 253, 256 MWIPROD authority security administrator rights 38 user profile owner of work libraries 266 My Workbench, see Workbench 49 restricted per user 255 Object locking during move step 225 Object name rules in check out 155 Object owner environment information 42 promotion internals 264 Object version stamping 125 in archive recovery 252 in promotion 251 Objects remove in from environment 205 OS/400 commands ALCOBJ 225 CHGOBJOWN 230 CPYF 226 CPYSRCF 226 CRTCBLPGM 188 MOVOBJ 266 security authority 19 Output queue ICMPMBR parameter 390 IMRGMBR parameter 406 Owning model object defined 423
N
Net/Wrk400 integration 381 NetView/DM integration 381 work library 270 Network Configuration 188
P
Panel groups move step considerations 225 Partition defined 423 Path defined 423 PathFinder integration check out options 156, 167 PDM option for check out 383 user-defined options 382 Paths check out 46 check out environment 46 create request 46 current location 46 default 46 development flow 46 emergency 46 environment 46 environment group 46
O
Object allocation during move step 225 Object authority environment information 43 promotion internals 264 Object Code Report 26 Object codes ADDPFM 315 CHGPFM 315 creation command 188 defined 423 DTAARA, promote from lib value 318 DTAARAR, retain existing value 318 for IFS objects, automatic 134, 215 object name rules 155 PFDTA 314 PFREF 174, 315
436
u s e r
g u i d e
Index primary environment 46 environment on multiple paths 46 library 46 per production environment 46 project path in promotion 180 project paths 107 standard 46 PDM 156 IMPDMOPT option for create request 198 option for check out 162 Workbench options 77 PFREFOBJ data area 43 Physical file data check out 150 Physical files archiving 264, 296 checking out data 150 journaling 264 promoting PF data 218 promotion internals 263 retaining triggers and constraints 184 Powerhouse integration 376 Prerequisites to using this guide 2 Previous release support 188 Primary request, see related request 201 Primary target environment defined 424 Print options ICMPMBR parameter 390 IMRGMBR parameter 405 Problem determination job log audit trail information 253 options for troubleshooting 253 working with failed promotions 254 Process defined 424 Process Clipboard (IPRCCBD) command 63 Product integration user authorities 152 Production environment type 40 Production file IMRGMBR parameter 399 Production member IMRGMBR parameter 399 Program default library 41 move step considerations 225 Project create 145 defined 424 in ProjectMaster 144 project paths 107 Project leader environment administrator 39 role defined 39 Project path defined 413 in promotion 180 ProjectMaster projects 144 Promotion completing failed requests 254 defined 424 field reference files 174 IEXCRQSDTL substitution variables 238 IFS objects directory upgrades 216 IFS files and directories 212 java optimization 218 internal processing 265 level check 207 logical files to remotes 316 methods, overview 174 object version stamping 251, 252 one step method from Clipboard 58 overriding 86 optimize PF promotion benefits 184 change per request 185 overriding 185 process overview 183 overview 54 project paths 180 related objects 200 related request processing 201 special commands ICHGRQSDTL command 240 IEXCRQSDTL command 236 step 256 substitution variables 234 web-based, for IFS objects 213 work libraries 270 Workbench compile 89 move 89 Promotion methods creating one step promotions 175 creating traditional promotions 177 where defined 174 Promotion request
437
Index automation 256 change compile commands 187 change request details 208 combining 181 comments 179 bypassing 175 disable comments 87 completing failed promotions 254 created in archiving 300 defaults in user profile 255 in Work with Environments 255 defined 171, 424 difference between emergency and standard 252 distribute by system move all 273 overview 272 emergency 252 environment selection 45 move request by system move all 273 overview 272 move requests on remote system 290 overrides change request defaults 205 job submit defaults 186 optimize PF promotion 185 remove items in from environment 205 product integration 255 remote job log returned on failure 253 request numbers number scheme 173 when reset 173 restore remote request 289 source file length 226 status 171 CompSchd 258 DistSchd 259 Expt-Fail 258, 370 Expt-Jobq 258, 370 Expt-Pend 258, 370 Expt-Run 258, 370 Expt-Sched 258, 370 MoveSchd 259 steps 171 what is included 171 work library 265 work with, on remote system 288 Promotion request status Completed 259 CompFail 258 CompJobq 258 CompPend 258 CompRun 258 DistFail 259 DistJobq 259 DistPend 259 DistRun 259 MCpyFail 259 MCpyJobq 259 MCpyPend 259 MCpyRun 259 MCpySchd 259 MoveFail 259 MoveJobq 259 MovePend 259
Q
QCMDEXC program used for compiling 188 QRPLOBJ library promotion internals 264 use during move step 225 QSECOFR user profile security administrator rights 38 Qualified name defined 424
R
Rejecting changes from Quality Assurance 116 Related environments defined 424 Related objects 139, 201 *DTAARA object type 167 *FILE object type 139, 167 *MODULE object type 139 *SRVPGM object type 139 checking out 139 Hawkeye considerations 201 process overview 200 processing considerations 203 recompiling 256 related request processing 201 selection 139 Related requests 201 archive recovery of 204 displaying and selecting 203
438
u s e r
g u i d e
Index promoting 202 setup requirements 204 Remote job scheduling 280 Remote menu using 287 Remote requests move on remote 290 restoring 289 work with on remote 288 REPLACE parameter 225 Reports Activity Report 25 Archive History Report 26 Archives by Environment 299 Archives by Request Report 299 Archives Per Tape Report 299 Concurrent Development Report 25 Environment Report 26 job logs 20 job logs, for problem determination 253 Lock Report 25 Object Code Report 26 Request Report 25 User Profile Report 26 Repository defined 424 Request number defined 424 resetting 173 sequencing 173 Request Report 25 Request status defined 425 MoveRun 259 per environment 258 per multiple environments 258 variations per host/remote 258 Requester defined 424 Required objects defined 425 Reserve name member/object at check out 121 Reset authorities 42 defined 425 Resolve a conflict task 248 Restoring archives from tape 299 remote requests 289 Review work details overview 53 Revision number assign in check out 122 RLU from Workbench 78 RMVDIR special command for directory upgrade in promotion ROBOT integration scheduling 288 RPG source code converting in ILE 163
217
S
Scheduling promotion steps 256, 257 remote jobs 280 ROBOT 288 SDA from the Workbench 78 Secondary request, see related request 201 Session model list check out 344 COOL:2E 344 defined 425 Set to Environment Library List (ISETLIBL) command, overview 54 SEU from the Workbench 70, 71 Single source multiple object at check out 123 Source default library 41 removing in from environment 205 Source and object names, different using in check out 151, 219 Source file environment definition 42 length 226 Source type changing 226 ICMPMBR parameter 387 IMRGMBR parameter 400 Special commands 245 environment level 22, 229 for DDM management 230, 240 for directory upgrade in promotion 217 for java optimization 218 IEXCCKOCMD Execute Checkout 112, 231, 245 IEXCRQSDTL Execute Request Detail 23, 230, 236
439
Index in check out 233 library list considerations 44 processing 229 promotion internals 265 substitution variables 236 Special object considerations 318 SQL archiving tables 296 trigger and constraint support 184 Stage library 263, 264, 268 defined 425 Staged objects 222 source 222 Start column (STARTCOL) on Compare Members command 390 on Merge Members command 402 Start COOL:Xtras_CM (STRCM) command 12 Start Implementer (STRIM) command menu 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 12 Status CompFail 258 CompJobq 258 CompPend 258 CompRun 258 CompSchd 258 DistFail 259 DistJobq 259 DistPend 259 DistRun 259 DistSchd 259 Expt-Fail 258, 370 Expt-Jobq 258, 370 Expt-Pend 258, 370 Expt-Run 258, 370 Expt-Schd 258, 370 MCpyFail 259 MCpyJobq 259 MCpyPend 259 MCpyRun 259 MCpySchd 259 member/object status codes 91 member/object status history 55, 90 MoveJobq 259 MovePend 259 MoveRun 259 MoveSchd 259 Step defined 425 Structured Query Language, See SQL 184 Subdirectory defined 426 Submit CRTOBJ parameter 391, 407 Substitution variables for check out 233 for IEXCCKOCMD 233 for IEXCRQSDTL 238 for promotion 234 for special commands 236 Subsystem compile step 223 Support options 5 Surrogate defined 426 System administrator, role defined 38 System Control Maintenance IFS object code creation 212
440
u s e r
g u i d e
Index job logging level in 253 job queue 256 number of job logs to retain System Software Associates AS/NET integration 381 AS/SET integration 330 BPCS integration 336 object code list 192 PDM option 198 select from locks 189 special commands 229 create traditional promotion request by locked source member 178 delete a lock 98 edit members SEU option 71 Workbench merge option 79 Workbench RLU option 78 Workbench SDA option 78 Workbench SEU option 70 Workbench WRKMBRPDM option 78 emergency check out 304 emergency create request 306 move request IMOVRQS command 228 submit move 226 reject from *QAC 153 request maintenance 211 resolve a conflict 248 Workbench compile 89 create request 86 inquiry 95 move 89 Test compile, from Workbench 83 creating promotion requests 181 environment type 40 overview 53 Tester, role defined 39 TGTRLS parameter 188 Third party compile procedures 223 Time entry overview 54 Trigger defined 426 Triggers and constraints in promotion 184, 313 Troubleshooting completing failed promotions 254 problem determination 253
253
T
Tape distribution work library 269 Tape, archiving to 297 Target environment group defined 426 Target file IMRGMBR parameter 405 Target source member IMRGMBR parameter 405 Task associate multiple DRs to a lock 99 change a design request 101 change a lock 97 check out add related objects 139 create a member/object 121 delete member/object 121 for concurrent development 136 from menu 112 from PathFinder 167 ICHKOUT command 156 PDM option 162 select member/object 112 select member/object by object code 112 single source multiple object 123 type in member/object 112 with design request 141 Work with Objects 112 Workbench 112 compile request ICMPRQS command 224 submit compile request 220 COOL:Xtras CM submit compile request 220 create promotion request add target environments 199 by member list 193 change overrides 205 copy request 195 ICRTRQS command 196
U
User ASP
225 work library considerations 266
441
Index authorities 151 capabilities 43 roles 38 User defaults, in Workbench 75 User Profile Report 26 User-Defined options from Workbench 17, 56, 72 USRPRF parameter 188 Utilities environment/library integrity check working with function keys 291 Work with Members Using PDM (WRKMBRPDM) Workbench 78 Work with Objects all object inquiry 56 check out 112 concurrent development 136, 139 one step method 113 with design request 141 function access 55 initial check out 54, 97 member/object status history 90 one step check out, overriding 68 one step promotion, overriding 86 reject 153 Workbench associating multiple design requests 99 change 53 change design request 101 change lock 97 check out 53, 112 concurrent development 136 related objects 139 with a design request 141 command prompting 58 compile 53, 79 create request 86 access 86 defined 422 deleting locks 98 edit members auto SEU 71 change SEU option 70 compare 78 merge 79 RLU 78 SDA 78 WRKMBRPDM 78 emergency check out 304 create request 306 F13 repeat option 17 function access 55 identify work 52 inquiry 95 library list setup 83 lock information 55 manage locks 54, 97 member/object status history 55, 90 optional check out and promotion methods 55 PDM options 77
45
V
Vendor integration ABSTRACT 378 American Software 329 AOS Message Manager 380 application software 328 AS/NET 381 AS/SET 330 BPCS 336 CASE products 328 CODE/400 337 J.D. Edwards 363 LANSA 367 Lotus Notes and Domino 376 MIMIX 381 Net/Wrk400 381 NetView/DM 381 PathFinder 382 Powerhouse (Cognos) 376 Utility software 377 Version in COOL:2E, defined 426 Version control 181 promotion requests 171 Version group in COOL:2E, defined 426
W
Web-based check out 135 Web-based promotion 213 WebSphere integration 337 Whats new in this release? 30 Who should read this guide 2 Work library compiling 222 defined 426 in promotion 270
442
u s e r
g u i d e
Index promote 54 promotion compile 89 move 89 promotion request 85 reject 153 repeating options 101 review work details 53 selection 51 test 53, 83 time entry 54 tool access 50 traditional check out 66 user-defined options 56, 72
Y
YCHKMDLCRT command 353 YCPYMDLOBJ command 352 YCVTCNDVAL command 354, 355 YCVTMDLMSG command 354, 355 YEDTMDL command 357 YEDTMDLLST command 348, 357 YFRFVNM model value 355 YMSGVNM model value 355 YPRMMDLLST command 352 YSBMMDLCRT command 353 YSYSCHG model value 342
443
Index
444
u s e r
g u i d e

Implementer User Guide

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Implementer User Guide

Hochgeladen von

Copyright:

Verfügbare Formate

IMPLEMENTER

MKS Implementer User Guide

Using the Workbench for Development Activities . . . . . 49

Performing Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Performing Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Performing Distributions . . . . . . . . . . . . . . . . . . . . . . . . . 271

Handling Emergency Situations . . . . . . . . . . . . . . . . . . . 295

Member and Object Handling . . . . . . . . . . . . . . . . . . . . . 307

10 Integrating With Other Vendor Products . . . . . . . . . . . . 327

381 381 382 382 382 383 383 384

Compare/Merge Member Commands . . . . . . . . . . . . . . 385

Before You Begin

Before You Begin

Who Should Read This Guide

What to Know Before Using This Product

Whats Inside This Guide

Whats Inside This Guide

Chapter 3: Using the Workbench for Development Activities

Chapter 5: Performing Check Out Chapter 6: Performing Promotions

Chapter 7: Performing Distributions Chapter 8: Handling Emergency Situations

Before You Begin

Appendix A: Compare/ Merge Member Commands

New > Problem the Session command Edit Options, Cancel, OK

UK Germany Fax North America UK Germany

Before You Begin

MKS Issue Tracking Solutions

MKS Issue Tracking Solutions

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

Using Integrity Manager

Using Integrity Manager and DesignTracker

MKS Issue Tracking Solutions

Issue Database Considerations and Assumptions

Menu Access Command Options

Menu Access Command Options

Overview of Implementer Features

Overview of Implementer Features

Integration With Integrity Manager

Overview of Implementer Features

Overview of Implementer Features

Change Control Features

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

Controlled Object Characteristics

Object Version Stamping

Audit Trail and Status Information

Overview of Implementer Features

Production Environment Protection

Developer Productivity Tools

Numerous Implementer features increase your development productivity.

Optional Check Out and Promotion Methods

Automated Move Process

Customized Function Keys

Implementer Across Multiple Divisions

Special Commands by Environment

Overview of Implementer Features

Special Command Promotion Processor IEXCRQSDTL

Implementer supports your testing and quality assurance efforts.

Multiple Test Environments

Tester-Controlled Test Areas

Overview of Implementer Features

Master File Reports

Overview of Implementer Features

Third-Party Vendor Integration

Overview of Implementer Features