MKS Implementer User Guide v.5.3 PDF

IMPLEMENTER
User Guide
w w w . m k s . c o m
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 WORLDWIDE OFFICES:

410 Albert Street 2500 S. Highland Avenue Martinstraße 42-44
Waterloo, ON N2L 3V3 Suite 200 73728 Esslingen
Canada Lombard, IL USA Germany
60148 tel: +49 711 351775 0
tel: 519 884 2251
tel: 630 495 2108 fax: +49 711 351775 11
fax: 519 884 8861
fax: 630 495 3591
sales: 800 265 2797 Third Floor, Duke’s Court
sales: 800 633 1235
Duke Street, Woking
www.mks.com
15 Third Avenue Surrey
Burlington, MA USA GU21 5BH
01803 United Kingdom
tel: 781 359 3300 tel: +44 (0)1483 733900
fax: 781 359 3399 fax: +44 (0)1483 733901
sales: +44 (0)1483 733919
12450 Fair Lakes Circle
Suite 400
Fairfax, VA USA
22033
tel: 703 803 3343
fax: 703 803 3344
sales: 800 265 2797
SIU5.3-020331
Table of Contents
Chapters 1 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Who Should Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
What to Know Before Using This Product . . . . . . . . . . . . . . . . . . . . . . 2
What’s Inside This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 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
What’s 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
i
Table of Contents
Project Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Understanding Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Environment Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Object Owners and Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Library List Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Defaults for Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . 44
Remote Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Environment Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Object Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Environment Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Environment Integrity Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Application Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3 Using the Workbench for Development Activities . . . . . 49

Understanding the Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Using the Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Identifying Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Reviewing Work Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Changing Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Promoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Time Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Managing Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Workbench Ease of Use Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Optional Check Out and Promotion Methods . . . . . . . . . . . . . . 55
Member/Object Status and History . . . . . . . . . . . . . . . . . . . . . . . 55
Alternate Views and Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Multiple Selection Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Automatic Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Concurrent Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Work With Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Command Prompting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Using the Clipboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Basic Clipboard Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Using Command Options to Add Clipboard Items . . . . . . . . . . 60
Using the ICRTRQS Command to Promote Clipboard Items . 63
ii u s e r g u i d e
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
4 Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Creating Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Creating Projects From Implementer . . . . . . . . . . . . . . . . . . . . . 104
Creating Projects From ProjectMaster . . . . . . . . . . . . . . . . . . . . 106
Setting Up a Default Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Project Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Project Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Project Management Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Time Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Advanced Scheduling Features . . . . . . . . . . . . . . . . . . . . . . . . . 109
Reporting Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
iii
Table of Contents
5 Performing Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Check Out Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Check Out Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Using the One Step Checkout Method . . . . . . . . . . . . . . . . . . . 113
Using the Traditional Checkout Method . . . . . . . . . . . . . . . . . . 115
Task Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Checking Out Single Source With Multiple Objects . . . . . . . . 123
Common Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Using Object Version Stamping in Check Out . . . . . . . . . . . . . . . . . 125
Processing Versions in Check Out . . . . . . . . . . . . . . . . . . . . . . . 125
Checking Out IFS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . 127
IFS Object Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . 127
Checking Out Using the IFS Object Name . . . . . . . . . . . . . . . . 128
Checking Out the Contents of an Environment . . . . . . . . . . . . 129
Check Out IFS (ICHKOUTIFS) Command . . . . . . . . . . . . . . . . 130
Automatically Creating Object Codes in Check Out . . . . . . . . 134
Support for Multi-Platform Check Out . . . . . . . . . . . . . . . . . . . 135
Checking Out for Concurrent Development . . . . . . . . . . . . . . . . . . 136
Checking Out Related Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Task Variation for Multiple Recurring Members/Objects . . . 140
Checking Out With a Design Request . . . . . . . . . . . . . . . . . . . . . . . . 141
Using ILE Object Codes in Check Out . . . . . . . . . . . . . . . . . . . . . . . . 148
Binding Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Bound Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
ILE SQL Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Service Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Update Service Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
ILE Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Update ILE Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Checking Out Physical File Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Using Different Source and Object Names in Check Out . . . . . . . . 151
User Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Typical User Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
LANSA Export/Import Authorities . . . . . . . . . . . . . . . . . . . . . 152
Checking Out for Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Removing Source and Objects From QA . . . . . . . . . . . . . . . . . . 153
Task Variation for Rejecting From the Menu . . . . . . . . . . . . . . 154
Object Name Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Performing Name Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Check Out (ICHKOUT) Command . . . . . . . . . . . . . . . . . . . . . . . . . . 156
iv u s e r g u i d e
Table of Contents
Check Out Command Variations . . . . . . . . . . . . . . . . . . . . . . . . 162

Converting RPG/400 or RPGIII Source Code to ILE RPG/400 . . . 163
Converting CRTBNDxxx ILE Programs to CRTPGM Programs . . 165
Checking Out Using PathFinder Information . . . . . . . . . . . . . . . . . 167
Environment and Library Setup . . . . . . . . . . . . . . . . . . . . . . . . . 167
Performing the Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
6 Performing Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Promotion Request Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Promotion Request Numbering . . . . . . . . . . . . . . . . . . . . . . . . . 173
Creating Promotion Requests in Batch . . . . . . . . . . . . . . . . . . . 173
Default Compile Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Promotion Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Create Request Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Creating Requests With the One Step Promotion Method . . . . . . . 175
Resolving Promotion Request Problems . . . . . . . . . . . . . . . . . . 177
Creating Requests With the Traditional Promotion Method . . . . . 177
Optimizing Physical File Promotions . . . . . . . . . . . . . . . . . . . . 183
Overriding Job Submission Defaults . . . . . . . . . . . . . . . . . . . . . 186
Changing Job Queues During the Compile Step . . . . . . . . . . . 187
Changing Compile Commands . . . . . . . . . . . . . . . . . . . . . . . . . 187
Creating Requests by Selecting From Locks . . . . . . . . . . . . . . . . . . . 189
Benefits of Selecting From Locks . . . . . . . . . . . . . . . . . . . . . . . . 190
Creating Requests From the Object List . . . . . . . . . . . . . . . . . . . . . . 192
Creating Requests From the Member List . . . . . . . . . . . . . . . . . . . . . 193
Task Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Creating a Request by Copying a Request . . . . . . . . . . . . . . . . . . . . 195
Creating Requests With the ICRTRQS Command . . . . . . . . . . . . . . 196
Creating Requests With the ICRTRQS Command PDM Option . . 198
Selecting Additional Target Environments . . . . . . . . . . . . . . . . . . . . 199
Promoting Related Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Related Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Overriding Create Request Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 205
Removing Objects and Source in Promotion . . . . . . . . . . . . . . 205
Changing Request Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
v
Table of Contents
Maintaining Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Promoting IFS Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . 212
Support for Browser-based Promotions . . . . . . . . . . . . . . . . . . 213
Options for Promoting IFS Objects . . . . . . . . . . . . . . . . . . . . . . 213
Considerations When Using *.* for Promotion . . . . . . . . . . . . 214
Automatically Creating Object Codes in Create Request . . . . 215
Upgrading a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Java Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Promoting Physical File Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Using Different Source and Object Names in Promotion . . . . . . . . 219
Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Staged Compiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Compile Library List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Third-Party Compile Procedures . . . . . . . . . . . . . . . . . . . . . . . . 223
Job Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Compile Request (ICMPRQS) Command Option . . . . . . . . . . . . . . 224
Moving Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Allocating Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Authorities and Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Source Member Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 225
Issuing Move Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Move Request (IMOVRQS) Command Option . . . . . . . . . . . . 228
Special Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Special Command Substitution Variables . . . . . . . . . . . . . . . . . 233
Special Commands in Promotion: IEXCRQSDTL Command 236
Special Commands to Manage DDM . . . . . . . . . . . . . . . . . . . . . 240
Special Commands to Change Promotion Status . . . . . . . . . . 245
Special Commands in Check Out . . . . . . . . . . . . . . . . . . . . . . . . 245
Managing Concurrent Development . . . . . . . . . . . . . . . . . . . . . . . . . 248
Resolving a Conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Object Version Stamping in Promotion . . . . . . . . . . . . . . . . . . . 251
Emergency Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Problem Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Completing Failed Promotions . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Other Creation Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Using ILE Object Codes in Promotion . . . . . . . . . . . . . . . . . . . . 256
Batch Promotion Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Distributing Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . 256
Scheduling Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
vi u s e r g u i d e
Table of Contents
Promotion Request Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Promotion Step Internal Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Create Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Export Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Compile Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Distribution Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Move Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Work Libraries Used During Promotion . . . . . . . . . . . . . . . . . . 265
Host Work Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Remote Work Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
7 Performing Distributions . . . . . . . . . . . . . . . . . . . . . . . . . 271

Moving and Distributing Promotion Requests by System . . . . . . . 272
Moving/Distributing All Promotion Requests By System . . . 272
Submitting Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Moving/Distributing to a Specific System . . . . . . . . . . . . . . . . 275
Move/Distribute by System Submission Options . . . . . . . . . . 277
Displaying Move Requests by System/Environment . . . . . . . . . . . 278
Filtering Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Controlling Remote Job Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Using the Default Job Schedule . . . . . . . . . . . . . . . . . . . . . . . . . 280
Overriding the Default Job Schedule . . . . . . . . . . . . . . . . . . . . . 281
Remote Job Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Changing Remote Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Moving Remote Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Using the Implementer Receiver Menu . . . . . . . . . . . . . . . . . . . . . . . 287
Working With Requests on the Remote System . . . . . . . . . . . . 288
Restoring Remote Requests (IRSTRMTRQS) . . . . . . . . . . . . . . 289
Moving Remote Requests (IMOVRMTRQS) . . . . . . . . . . . . . . 290
Working With Function Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
8 Handling Emergency Situations . . . . . . . . . . . . . . . . . . . 295

Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Archiving Source and Objects on a Promotion Request . . . . . 296
Using the Archive to Tape Features . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Working With Tape Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Archive Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Archive Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Recovering Archived Source/Object by Request . . . . . . . . . . 300
Common questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Automatic Check Out Archive Options . . . . . . . . . . . . . . . . . . 302
vii
Table of Contents
Emergency Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Emergency Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
9 Member and Object Handling . . . . . . . . . . . . . . . . . . . . . 307

Compile Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Managing Non-Source-based SQL . . . . . . . . . . . . . . . . . . . . . . . 309
Managing Source-based SQL (DDL) . . . . . . . . . . . . . . . . . . . . . 311
Managing Traditional DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Special Object Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Data Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Data Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Commands and Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Managing ILE Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Support for Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Support for Service Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Loading ILE Objects Into the Repository . . . . . . . . . . . . . . . . . 322
S/36 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
S/38 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Extended Object Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
10 Integrating With Other Vendor Products . . . . . . . . . . . . 327

Application and CASE Software Products . . . . . . . . . . . . . . . . . . . . 328
American Software Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Object Codes for Check Out and Promotion . . . . . . . . . . . . . . 329
Compiling Cobol Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Message File Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
AS/SET Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Checking Out AS/SET Definitions . . . . . . . . . . . . . . . . . . . . . . 331
AS/SET Dependency Checking . . . . . . . . . . . . . . . . . . . . . . . . . 332
Promoting AS/SET Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 334
Archiving AS/SET Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
BPCS Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
CODE/400 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Creating the User-Defined Options . . . . . . . . . . . . . . . . . . . . . . 337
Launching CODE/400 from Implementer . . . . . . . . . . . . . . . . 338
COOL:Xtras Change Management Integration . . . . . . . . . . . . . . . . 338
Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Development Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Member/Object Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
SQL Support for COOL:2E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
viii u s e r g u i d e
Table of Contents
Check Out Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

Working With Model Object Lists . . . . . . . . . . . . . . . . . . . . . . . 347
Checking Out Model Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Concurrent Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Checking Out Versionable Model Objects . . . . . . . . . . . . . . . . 349
User Exit Program Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Promoting Model Information . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Promotion Flow: COOL:2E to COOL:2E Environment . . . . . . 351
Promotion Flow: COOL:2E to Traditional Environment . . . . 354
Working in a Change-Controlled Model . . . . . . . . . . . . . . . . . . 356
Model Object Audit Information . . . . . . . . . . . . . . . . . . . . . . . . 357
Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Managing EXCUSRSRC and EXCUSRPGM . . . . . . . . . . . . . . . 359
Merging Model Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Remote Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
J.D. Edwards Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Starting the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Support for J.D. Edwards Traditional Objects . . . . . . . . . . . . . 364
Support for J.D. Edwards DREAM Writer Versions . . . . . . . . 364
Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Displaying J.D. Edwards Items . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Compiling From the Workbench . . . . . . . . . . . . . . . . . . . . . . . . 365
Promoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Archiving J.D. Edwards Special Objects . . . . . . . . . . . . . . . . . . 366
LANSA Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Checking Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Promoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Displaying Process/Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Save File Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
LANSA Export/Import Authorities . . . . . . . . . . . . . . . . . . . . . 372
LANSA RDML Function Compare . . . . . . . . . . . . . . . . . . . . . . 372
Understanding the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Lotus Notes and Domino Integration . . . . . . . . . . . . . . . . . . . . . . . . 376
Powerhouse Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Utility Software Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
ABSTRACT Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Version Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Abstract User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . . . 378
Accessing ABSTRACT From Implementer . . . . . . . . . . . . . . . . 380
AOS Message Manager Integration . . . . . . . . . . . . . . . . . . . . . . . . . 380
AS/NET Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
MIMIX Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
ix
Table of Contents
NetView/DM Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Net/Wrk400 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
PathFinder Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
PathFinder Database Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
PathFinder User-Defined Options . . . . . . . . . . . . . . . . . . . . . . . 382
PathFinder PDM Options for USERPATH . . . . . . . . . . . . . . . . 383
PathFinder PDM Options for USERPDM . . . . . . . . . . . . . . . . . 383
ROBOT Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Appendixes A Compare/Merge Member Commands . . . . . . . . . . . . . . 385

Compare Member (ICMPMBR) Command . . . . . . . . . . . . . . . . . . . 386
Compare Member Report Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
LANSA Compare RDML (ICMPRDML) Command . . . . . . . . . . . . 394
LANSA Compare Members Report . . . . . . . . . . . . . . . . . . . . . . 396
Merge Member (IMRGMBR) Command . . . . . . . . . . . . . . . . . . . . . . 398
Merge Member Merge Report Listing . . . . . . . . . . . . . . . . . . . . . . . . 408
B Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
x u s e r g u i d e
Before You Begin
1
I 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
what’s inside this guide
document conventions
getting help
1
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.
2 u s e r g u i d e
What’s Inside This Guide
What’s 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 Description
Chapter 1: Before You Introduces you to MKS Implementer. Describes who

Begin should read this guide and how to use it, and options
for getting help.
Chapter 2: Getting Explains where to find product installation information.

Started Overviews the important features of Implementer,
including what’s new in this release. Describes the
various user roles.
Chapter 3: Using the Explains the versatile features of the Workbench.

Workbench for Describes how to access important Implementer
Development Activities features while using the Workbench as a home base
for your work. Identifies where to look in this guide to
find detailed information about each activity.
Chapter 4: Projects Explains how to use the Implementer to interface with

MKS ProjectMaster, and perform common project
management related activities.
Chapter 5: Performing Explains the two checkout methods, and how to check
Check Out out members/objects. Describes the various check out
related options.
Chapter 6: Performing Explains the two promotion methods. Describes how

Promotions to promote member/objects from development to QA,
and from QA to production. Describes the various
promotion-related options.
Chapter 7: Performing Explains how to distribute members/objects to remote

Distributions systems using the Implementer Receiver.
Chapter 8: Handling Explains how to archive and roll back to prior member/
Emergency Situations object versions. Describes how to perform emergency
check out and emergency create request functions.
3
Before You Begin
Chapter Description
Chapter 9: Member Explains how Implementer supports the different OS/

and Object Handling 400 types of objects and source members.
Chapter 10: Integrating Discusses the Implementer support for other vendor
With Other Vendor software products. Explains actions you must take to
Products ensure maximum integration. This chapter is divided
into two sections to reflect the type of software
products supported, Application and CASE products,
and Utility products.
Appendix A: Compare/ Explains how to use the Compare Member

Merge Member (ICMPMBR) and Merge Member (IMRGMBR)
Commands commands to simplify and automate the process of
comparing and integrating programming modifications,
during the development process.
Appendix B: Glossary Defines the terminology that relates to Implementer.
Document Conventions
Throughout this guide, the following typographical conventions are used.
Items in documentation Appear as
References to other manuals, new terms, and italics

variables
Keys you press, programs, files, directory names, ENTER

and drive letters
Code-based information, such as system ADDLIBLE

messages, field syntax, macros, and commands,
and information you type on menus and panels
PC menus, commands New > Problem
PC drop-down menus the Session command
PC Dialog boxes, features Edit Options, Cancel, OK
Path names c:\mks\demo
NOTE
Notes containing important information are bordered by lines on the top and
bottom.
4 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 www.mks.com
E-mail support@mks.com
Telephone North America 800 633 6298

630 652 9350
519 884 2270
UK +44 (0) 1483 733910
Germany +49 711 351 775 51
Fax North America 630 495 4855
UK +44 (0) 1483 733901
Germany +49 711 351 775 11
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)
5
Before You Begin
6 u s e r g u i d e
Getting Started
2
T his guide is for MIS professionals who implement change management
or perform change management tasks. This chapter provides an overview
of Implementer.
system requirements
issue tracking solutions
starting Implementer
overview of Implementer features
what’s new in this release
user roles
understanding environments
7
Getting Started
System Requirements
The minimum system requirement for this Implementer release is a RISC-
based processor running OS/400 V4R4 or greater.
Additional requirements may apply for complete functionality of the

MKS Integrity Solution multi-platform integration. For more information,
see the Implementer Multi-Platform Solutions Guide.
MKS Issue Tracking Solutions

MKS creates solutions that help you where it matters most—in the
management of changes in all your critical files and in the promotion of
workflow collaboration among people in your organization. Put simply,
MKS has the right solution for your business. In fact, keeping up with the
pace of technology does not have to be painful—on the contrary, MKS
thinks that setting the pace is much more rewarding.
Using DesignTracker, one of the MKS iSeries Solution products, is delivered with
Implementer. DesignTracker resides on the iSeries 400 and provides native
DesignTracker 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:
8 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 Integrity Manager is the best of breed enterprise choice for highly
customizable process and workflow management. Any simple defect-
Manager tracking tool can record the status of a change request, but it does not
monitor all the components that need to be modified, or the variety of tasks
that need to be performed to resolve the issue. Integrity Manager extends
the concept of defect tracking to include support for managing
components, tasks, and workflow. This is particularly important when
your organization has implemented a Software Configuration
Management (SCM) process for the proposal, review, and approval of all
software changes.
With this solution, Integrity Manager is the enterprise-wide issue

management system that completely replaces DesignTracker. Integrity
Manager integrates with other developer productivity tools—including
Implementer, to control and track development activity in Implementer,
and Microsoft Project, to leverage software investments and enhance
coverage of the application development lifecycle.
Integrity Manager’s platform transparent, advanced, multi-tier

architecture is scalable across the enterprise to support distributed
developers and other constituents in the change process. Integrity
Manager:
helps your development team capture and track all data related to
change in your software system
allows you to set up a workflow to manage the change process
allows you to create change packages to correlate issues with specific

Implementer revisions
provides metrics for your data including queries, reports, and charts
9
Getting Started
Integrity Manager is an extremely flexible issue management system that

allows any number of user-defined issues, each identified by its type, and
each type having its own user-defined set of fields; DesignTracker is more
rigid with fixed type service requests and design requests that have
various attributes.
Integrity Manager controls the activities of check out and promotion by an

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

Manager issues and update the issue state based on the development
progress in Implementer. The issue ID associated with changing an item is
tracked—along with the actual development change—in Implementer; the
issue details and state are tracked in Integrity Manager.
Using Integrity For organizations that require DesignTracker—for example, if you use
Implementer’s release management feature or are using SupportCenter or
Manager and ProjectMaster—but you also have a need for Windows-based issue
DesignTracker tracking, this solution works well.
With this solution, DesignTracker is used to manage and track service

requests and design requests on the iSeries 400.
Integrity Manager uses issues to track changes in the software development

cycle. For example, your administrator can configure Integrity Manager in
a way that a problem issue may be associated with a solution issue for easy
tracking and monitoring of both issues. Each issue has an audit trail, which
may be used to evaluate internal processes for the effectiveness of the
problem resolution process. In effect, issues track all aspects of any
engineering endeavor.
Issue types capture and track a specific change request, defect, problem,
solution, or task. For example, one issue type could record bugs and
deficiencies in design. Another issue type could be used to request design
changes that fix problems, or propose enhancements or new functionality
for your product.
DTBridge (provided in Implementer) allows you to operate the centralized

issue tracking system integrated with iSeries 400 change management.
When DTBridge is run, issues entered into Integrity Manager are moved to
the iSeries 400—when an issue meets the criteria established within the
DTBridge setup, a new design request is created on the iSeries 400 and the
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 Throughout this manual, the terms “issue” and “design request” or
“DR” are interchangeable to the extent that any references to issues
Considerations assumes that Integrity Manager is installed and configured as your
and issue tracking system, and any references to design requests (or DRs)
and Service Requests assumes that DesignTracker is installed and
Assumptions 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
Starting Implementer
Menu Access Command Options
Menu Option STRIM Command Value
Activity Report *ACTRPT
Archive History Report *ARCHRPT
Archive Recovery *ARCRCV
Check Out *CHKOUT
Compile Promotion Request *CMPRQS
Concurrent Development Report *CONDEVRPT
Create Promotion Request *CRTRQS
Move Promotion Request by System/Environment *MOVRQSSYS
Environments *WRKENV
Environment Groups *WRKENVGRP
Environment Report *ENVRPT
Function Keys *WRKFNCKEY
Integrity Manager Setup *INTMGRSET
Job Log Inquiry *JOBLOGINQ
Lock Report *LCKRPT
Menu—Panel 1 *M1 or *MENU1
Manage All Concurrent Development *MNGCONDEV
Move Promotion Request *MOVRQS
My Workbench *WRKBCH
Network Configuration *NETCFG
Objects *WRKOBJ
Object Codes *WRKOBJCDE
Object Code Report *OBJCDERPT
Work with Projects *WRKPRJ
Request Inquiry *RQSINQ
Request Maintenance *RQSMNT
13
Getting Started
Menu Access Command Options
Menu Option STRIM Command Value
Request Report *RQSRPT
System Control Maintenance *SYSCTLMNT
Users *WRKUSR
User Report *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 Developer’s Workbench. From it, you
can perform all the essential development tasks such as check in, check out,
editing, compiling, promotion, and deployment, as well as resolve conflicts
associated with parallel development. The result is that you spend more
time doing what you enjoy—developing software.
Development users and managers of the Implementer product have an

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

vendor products provides an open and complete interface to CASE and
other vendor tools.
While making developers’ lives simpler, Implementer also provides

features that IT managers demand for enterprise change management.
Implementer’s Secure Promotion Technology (SPT) ensures your
promotion and deployment process cannot be compromised.
Integration With Managers can assign, manage, and track issues using MKS Integrity
Manager, MKS’s workflow management and issue tracking solution for
Integrity NT and UNIX. Using either the Windows GUI or Web interface, Integrity
Manager Manager’s powerful and customizable workflow capabilities extend
control over software development processes, regardless of the platform.
Plus you can have a single repository of all software changes made
throughout the organization.
MKS is at the forefront of responding to new and evolving capabilities of

the iSeries 400, including Integrated File System (IFS), Java, and
WebSphere. Implementer provides complete change management for the
IFS. For teams developing applications for the iSeries 400 using VisualAge
for Java, WebSphere Studio, or other IDEs, the solution is MKS Source
Integrity Enterprise Edition.
Source Integrity Enterprise Edition is MKS’s client/server, configuration

management solution for NT and UNIX, which integrates with VisualAge
for Java and WebSphere Studio. When a project or change is complete,
Source Integrity Enterprise Edition makes the files immediately available
to Implementer for deployment.
15
Getting Started
Implementer brings all Java and WebSphere components, Windows and

Web files, and native OS/400 objects into a single change package,
ensuring synchronized promotion and deployment of all the components
of your application.
NOTE
Integrity Manager is a separately licensed component of the MKS Integrity
Solution. All functionality referencing MKS Integrity Manager requires
Integrity Manager be installed and configured as your issue tracking system
within Implementer.
All functionality referencing DesignTracker and design requests requires

DesignTracker be installed and configured as your issue tracking system
within Implementer (DesignTracker is the default issue-tracking system), In
addition, DesignTracker requires SupportCenter and ProjectMaster require be
installed to complete the interface, unless noted otherwise. DesignTracker and
ProjectMaster are automatically shipped with Implementer.
The Workbench The Workbench and the Work with Objects function provide ease of use
for anyone involved in the change management process. From the
Workbench, you can initiate and manage any task relating to design
requests or projects. Developers get information in the form most useful to
them. Managers use the Workbench to view all the changes for design
requests and/or projects that are their responsibility.
The features and benefits available from My Workbench allow you to:
Check out members/objects for a design request or project using any

selection criteria.
Edit and perform development tasks using Source Edit Utility (SEU),
Screen Design Aid (SDA), Report Layout Utility (RLU), Work with
Member Programming Development Manager (WRKMBRPDM), and
the command line.
Filter, change, and/or create design requests or projects to manage

development.
Check out or promote objects from multiple environments

simultaneously.
Filter development activity by user, design request, promotion

request, project, and/or any other established criteria.
Directly access other related Implementer functions such as Work

with Objects, Compile Requests, Move Requests, and Request Inquiry.
Compare and merge source code from multiple environments using

integrated compare and merge.
Display member/object status and status history.
Enter time for projects and tasks or initiate updates.
The Clipboard provides an industry unique selection capability by

allowing you to select work from multiple assignments (for example,
requests, portions of related projects, and different developers).
The Clipboard automatically sorts all selections, ensuring that related
components are properly grouped together.
Implementer provides an open interface to add software items to the

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

using the PDM compile. Developers can compile with the knowledge
and assurance that all compilation requirements are automatically
applied for each software item checked out to the Workbench. This
includes library list, user ownership, authorities, and overrides.
Options defined in PDM can be run directly from the Workbench.

The Workbench supports the use of both PDM and Implementer
supplied substitution characters. This adds significant value to using
the Workbench over PDM, for carrying out development and testing
activities for software items in progress within the development cycle.
The controlled testing facility enables you to process an item that is on

the Workbench list without having to change your library list.
The F13 Repeat option allows you to repeat an option through the
Workbench list.
An additional filtering selection capability allows you to display only

those items checked out either to a development or to a testing location.
This has particular benefit to those developers and testers who work
across multiple business applications.
17
Getting Started
Technology- Implementer provides support for Integrated Language Environment

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

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

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

attached to a file that is being replaced by a new version, in addition to
promoting a new version of a file with additional DB2 attributes.
Implementer provides integrated front-end and back-office change

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

Windows and UNIX platforms. You can log new issues and track
progress within the development organization using MKS Integrity
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 Implementer is feature rich with change control features, as described next.
Features Application Paths

Predefining the application path through development environments
simplifies the promotion process. You can define a default path, and
specify whether certain users can override the path. This takes the
guesswork out of check out and promotion, and provides controlled access
to each environment.
You can define application paths:
by project, or by environment and user (which allows nearly

unlimited flexibility)
for all environment relationships: development, QA, production, and

remote systems
separately, for standard and emergency paths
Concurrent Development
Implementer ensures by default that two people cannot accidentally check
out the same source member. If you want to perform concurrent
development, Implementer manages the development to ensure you track
all changes in an orderly fashion. Concurrent development allows
automatic merging of multiple versions of source member’s back into one
source member. This replaces the need to wait for one user to complete
work on a change before the next person begins to work on changes.
Security
Implementer ensures selected users control changes to production,
development, and test libraries. You can tailor Implementer to the level of
control you want. You can designate, by user, the menu options that can be
used, the environments (and functions within each environment) that can
be used, and the defaults that can be overridden.
Controlled Object Characteristics

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

Implementer provides for object version stamping of items under change
management control. This feature is beneficial for easy auditing and the
identification of deployed objects. Object version stamping can be
implemented in association with or independent of another feature, Design
Request stamping.
With object versioning, each object, lock record, and repository record is
stamped with a version number at predetermined pre-defined stages
within the development cycle. With DR stamping, each object is stamped
with the design request number that the object was checked out for. When
multiple locks exist with multiple DRs, the object is stamped with the
primary DR associated with the initial lock. In addition, the actual
description of the object is changed by updating the APAR ID attribute
with the revision number, and the PTF Number attribute with the DR
number. This can be viewed by using the Display Object Description
(DSPOBJD) command.
Audit Trail and Status Information

A complete audit trail of every change made by your developers is
maintained, and this audit trail can be maintained for as long as you need
it. You can inquire or report on check out, promotion, and distribution
activities. This allows complete management control over all of your
development projects.
The various “Work with” functions and inquiries provide easy-to-use

features that allow you to review factors such as: what projects are
currently in process, who is working on that project, and what promotions
occurred at any given time. In addition, several reports contain this
information as well.
It is often difficult to identify what caused an error in the promotion cycle

because OS/400 job logs typically contain too much detail rather than too
little. Implementer minimizes the messages that are included in the job log
so you can be certain that the first diagnostic or escape message listed in
the job log is the actual cause of the error in the promotion cycle. This can
speed up the identification of what really caused the problem.
Related Objects
When you check out primary objects or promote changes, you can
optionally include other objects affected by changes to these objects. For
example, for any changed logical file you can include the related programs
for check out or promotion.
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 Numerous Implementer features increase your development productivity.
Productivity Personal Environments

Tools Developers can work in their own personal environments or development
libraries, Implementer environments, or libraries they share with other
developers.
Optional Check Out and Promotion Methods

Implementer offers two methods for processing check out and
promotion—the one step method and a traditional method. Both methods
provide access to the same features and produce the same results.
However, the one step method allows you to perform check out and
promotion using a fast path approach that saves time and effort, thereby
minimizing the number of steps required in the functions. The traditional
methods, which are more interactive, display more panels and require
additional input for processing.
21
Getting Started
User-Defined Options
If you use PDM (Programming Development Manager), you can set up
Implementer to use PDM user-defined options for check out and
promotion. If you use PathFinder or ABSTRACT, you can check out
members (and their related members/objects) through the PathFinder or
ABSTRACT menus. You can continue development once you have
checked out the member.
Lock Identification
The Implementer check out feature saves you time locating the user who
last changed an object because each member/object has a lock attached by
the user who performed the check out.
Automated Move Process

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

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

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

Implementer has an extremely powerful and flexible special commands
facility. Special commands provide the facility to issue external commands
and programs at user-defined stages within the check out and promotion
process, thus bringing significant flexibility and openness to the product.
Special commands can be defined for environments, and can be
automatically attached to all promotion requests targeting that
environment.
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 Implementer can automatically distribute changes from a development

system to remote systems with no intervention required at your remote
Software sites.
Promotion requests can be to any of the following:
single environment
modified list of environments
predefined group of environments
specific systems per individual requests
different systems on the same request
Implementer can accomplish the promotion in separate steps or

automatically as a single step that can include compile, move, and
distribute.
It is necessary to define the target environment (or environment group)

before request creation. The environment group definition determines:
Source location.
Whether source or objects (or both) are only distributed to the remote
(remote initiated move) or moved to a remote production library (host
initiated move) or both.
Whether the environment requires compilation and on what system

the compile takes place (local or remote).
The distribution information: distribution method (TCP/IP, SNADS,

tape, NetView/DM, SDMCom, NetWrk/400, AnyNet/400, AS/NET),
who initiates the moves, whether the host is updated, and whether to
retain requests on the remote system.
You can define the environment definition during the initial set up of
Implementer. As your requirements change, you can add new definitions
or change existing definitions.
23
Getting Started
Test Tools Implementer supports your testing and quality assurance efforts.
Multiple Test Environments

You can define an unlimited number of environments as test
environments.
These environments can exist on either the local or the remote systems.
Tester-Controlled Test Areas

For organizations that have separate testing or quality assurance teams,
Implementer allows you to control and manage your own testing areas.
Testers can be the users who accept changes placed into their test
environments. The testers can indicate what members/objects are ready
for promotion either by selecting the project that is ready for promotion or
by copying previous promotion requests. This eliminates the need for the
tester to select or type in each member/object during the promotion
process.
If necessary, the tester can easily reject the change from quality assurance
and check the member/object back out to the specific developer and
environment or library.
Version Control Implementer provides several different version control features. Using
version control, you can:
Perform multiple or concurrent check out of a member/object.

Implementer’s concurrent development function sends a message to
other users at the start of concurrent development. You can integrate
changes back together using the merge capability.
Define multiple environments to support all versions of your

software. You can implement complete (or partial) development paths
(Development, Quality Assurance, User Acceptance, and Production)
for each version of the software.
Roll back up to 99 versions of your software. Rollback is accomplished

by archiving members/objects.
Compare all object versions in your environments. You can view all
environments that currently contain a specific member/object to
ensure they all contain the identical object.
Enter revision numbers for tracking the member/object version.

Revision numbers display on many of the panels and on various
reports.
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
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
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
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
Inquiries A number of inquires and “Work with” functions are provided to display
information from the Implementer database. All inquiries are interactive
programs.
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 Implementer supports the unique requirements of distributed information

technology (IT) environments, including the independent software vendor
Planning (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 Implementer interfaces with third-party solutions to provide our

customers the integration needed to address their business cases.
Vendor
COOL:2E
Integration
COOL:2E is an application development tool for the iSeries 400
developed by Computer Associates. Implementer provides change
control for COOL:2E developed applications and traditionally
developed (3GL) applications, under as a separately licensed product.
The primary difference between Implementer and COOL:2E licensed
version is that with COOL:2E, programmers can check out from an
option within Implementer.
AS/SET
Implementer manages AS/SET definitions and generated traditional
objects. Support for AS/SET fields, files, audit trails, action subroutine
definitions, program definitions, and data models are provided.
LANSA
Implementer manages LANSA objects such as files, fields, processes,

and functions. With Implementer, you can check out and promote
LANSA objects in a controlled fashion, distribute LANSA objects to
remote locations, and archive LANSA objects during promotion and
roll them back when necessary. Includes support for LANSA’s web
interface.
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 The additional features of Implementer allow you to track software

changes from the initial software request through completion of the
Features project.
Impact Analysis
Implementer allows you to determine impact analysis on specific
members/objects at check out or when promoting the completed changes.
Implementer determines the impact on specific objects by use of it’s own
native support, PathFinder, or ABSTRACT.
Project Management Capabilities

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

assignment, time allocation, and current project status. Developers can
enter time directly from the Workbench.
Managers can filter the status on partial projects, individual projects,

and groups of projects.
Automatically schedule resources by project requirement, the

resources ability to perform the task, and resource availability.
Gantt charts provide online visibility to the status of all resource and
project changes.
29
Getting Started
Extensive reporting provides information on estimation accuracy,

project status and completion, resource availability and performance,
and project backlog.
Real time scheduling or rescheduling provides instant visibility to

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

User request integration with DesignTracker uses Design Requests (DR)
and Service Requests (SR) to deliver the closed-loop approach to change
management.
This feature allows you to:
Specify if design request approval is necessary for entity check out or

promotion.
Subset SRs and DRs based on nearly any criteria (including Boolean
logic) providing unlimited flexibility. Subsets can be saved for reuse.
Define when, how, and to who is sent messages for a project.
Define details on service and design requests as write protected,

dependent on the status of the request.
What’s New in This Release?

This release of Implementer provides many new features and
enhancements. If you are already familiar with Implementer, this section
provides an overview of the new release. In addition, be sure to review the
Implementer Release Notes for any late-breaking information regarding this
release.
IMPORTANT
If you have made customized changes to the Implementer source file
QSAMPLE, after upgrading to this release you need to recompile programs
MWI0891 and MWI0891P to reflect changes in Implementer 5.3.
Documentation This release of Implementer provides enhancements to the Implementer

documentation set.
Enhancements
The iSeries Solution Documentation CD, which contains the
documentation for all iSeries products, is included with your product
shipment. In addition, your product shipment now includes one printed
set of the following Implementer publications:
iSeries Solution Installation Guide
Implementer System Administrator Guide
Implementer User Guide
Implementer Multi-Platform Solutions Guide
Implementer QuickView Guide
NOTE
If you need additional copies of printed manuals, they are available for a
nominal fee. For more information, contact Customer Support.
With a focus to standardize on the documentation for all MKS products,

this release presents a transformed Implementer documentation set that
includes:
new cover design
new style and format
new document size of 7-1/4 inches by 9 inches
The new format provides an integrated and user-friendly structure. For

example, it provides book-wide hyperlinks for easy navigation.
For customers that also have MKS Integrity Solution products, the new
format provides a familiar consistency with each product manual—
regardless of the product or platform—making it easier to install, learn,
and use all MKS products.
Integrity Expanded integration with Integrity Manager provides a new issue

management solution for Implementer users. The latest integration with
Manager Integrity Manager provides enterprise-wide issue and workflow
Integration management. To highlight a few features, this robust integration allows
you to:
access and select Integrity Manager issues directly from the

Workbench, using the Web, Windows, or 5250 emulation
view Implementer information from Integrity Manager
31
Getting Started
control Implementer check out and promotion activities through

Integrity Manager workflow rules
track each member, how it was changed, and where it is currently in

the development process
automatically reflect development activities by progressing an issue

through the workflow
group changes by the effected production environment
For detailed information on this integration, see the Implementer Multi-

Platform Solutions Guide.
Technology- Improved Support for DB2/400

based Implementer now provides full support for database files built using SQL
DDL. This includes support for non-source-based SQL tables, indices, and
Enhancements views, and source-based files (OS/400 managed source). Implementer
ships six new SQL object codes to support SQL objects.
In addition, Implementer allows you to optimize the promotion of DDS-

based physical files created with the Create Physical File (CRTPF)
command. This feature utilizes the DB2/400 ALTER TABLE command (for
SQL) and the Change Physical File (CHGPF) command (for physical files)
for improved performance of database file promotions.
Triggers and constraints are now automatically retained to provide

application integrity during the promotion process.
Enhanced Support for ILE Development

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

one of the referenced modules, the internal references and object
descriptions of the resulting program or service program are appropriately
set. This ensures the integrity of the module relationship reference to the
program or service program.
When related objects are added to a request using Implementer or

Pathfinder as the source of related objects, modules are properly added to
the request for the effected relationship references. Likewise, displaying
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 to Implementer’s user interface include the following

functional areas.
Enhancements
Related Objects Across Environments
You can now optionally configure Implementer to automatically generate
secondary requests to compile and promote related objects that exist across
environments not included in the original request. For impact analysis, use
either Implementer or Hawkeye as the source of related object information.
This feature is defined globally in System Control Maintenance. You can

enable and disable the feature as needed. By default, the feature is
disabled.
Removing Objects and Source After Promotion

You have the ability to customize how Implementer automatically handles
objects and source in a local *TST or *QAC environment, upon successful
completion of a promotion request from the environment.
This feature is enabled by defaults at the environment level, with

validation to environment overrides as needed. For each from
environment, specify 1=always delete from the environment, 2=never
delete from the environment, or 3=delete on a per object code basis.
Previously, this feature allowed values of Y or N; consequently, any panels
containing these fields now require a value of 1, 2, or 3.
In Work with Users, the Remove obj in from lib/env and Remove Src in
from lib/env fields were renamed to Remove obj in from library and
Remove src in from library, respectively. In addition, moved to the first
panel under User Controls are the fields that control a user’s ability to
override the remove values in promotion; the field names are Override
remove src and Override remove obj.
Implementer 5.3 Upgrade Considerations
MKS recommends that you complete or delete any open promotion

requests prior to upgrading.
33
Getting Started
Field values set or changed during the upgrade
For any incomplete requests found, the upgrade process will

change the existing Remove field values from Y (Yes) to 1=always
or from N (No) to 2 =never. The value 3=per object code is never
set during an upgrade.
For existing object codes and environment object code overrides,

the Remove fields are set to N (No).
For user profiles, if all user profiles are defined as Remove=Y, the
Remove in from lib/env field is set to 1=always for all
environments. However, if at least one user profile is defined as
Remove=N, the field is set to 2=never for all environments.
Create Request (ICRTRQS) command change
If you have any existing program references to the ICRTRQS

command that include values for the REMSRC and REMOBJ
parameters, you must change the parameter values from *NO to
*NEVER.
Removal of Implementer data areas
In previous releases of Implementer, the IMDLTFRMPF and

IMDLTFRMLF data areas were used to remove database files in a
from environment during promotion. Since this function is now
performed through object code overrides, these two data areas were
removed from the Implementer database.
There is no change to the COOL:Xtras CM data areas IMDLTFRMUP

(user program) and IMDLTFRMUS (user source).
Execute Checkout (IEXCCKOCMD) Command

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

command based on the object code, member/object name, and action.
Using the criteria that you define for the IEXCCKOCMD command,
Implementer identifies the appropriate checked out items and issues the
command that you specify for only those objects.
Menu Enhancements
The Implementer Menu has the following new options:
option 24, Archive to Tape
The Archive to Tape menu options are now accessible from the
Implementer main menu. Previously, this menu was accessible only
from a command option.
option 47, Integrity Manager Setup
Use this menu option to configure Integrity Manager for integration

with either Implementer, or DTBridge. For more information, see the
Implementer Multi-Platform Solutions Guide.
options 51–54 Release Control Options
Use these options to work with products, release types, release status,
and access the Release Deployment Menu.
For more information on these options, see the Implementer Release

Management User Guide.
For DesignTracker users, the DesignTracker Menu is condensed to a single

menu for quicker access to the DesignTracker features.
Release Management Enhancements

Release management includes four enhancements.For more information
on the following enhancements, see the Implementer Release Management
User Guide.
IMPORTANT
If you are using release management, after upgrading to Implementer
release 5.3, any packages existing at the time of the upgrade must be re-
prepared after the upgrade. For each package, from Work with Packages, run
option 18=Upgrade Package to Current MKSIM Host Version.
Software Distribution on CD Media
Implementer now supports software distribution on CD media. The Send

Delivery (ISNDDLV) command is used specify the distribution media and
submit the package creation process.
Expanded Filters in Work With Product Version Releases for a System
Expanded filters are available for displaying release information at the

product level and at the customer level.
35
Getting Started
Support for Contact Types
A customizable type field is now provided for customer contacts, to assist

with identifying a contacts role within the organization.
Support for Retaining Existing Data Area Values
Implementer allows you to retain the existing value in a target library data
area upon promotion to the target library.
The DTAARAR object code retains the existing value in the target library
during promotion. It has an object type of *DTAARA and a special
characteristic of *DTA. The special characteristic is significant—it controls
whether the existing data area value is retained.
Vendor This release of Implementer provides enhancements to the various vendor

integrations.
Integration
Enhancements 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.
When upgrading COOL:Xtras CM, the existing default method of

independent EXCUSRSRC and EXCUSRPGM is retained.
NOTE
Implementer release 5.3 corresponds to COOL:Xtras Change Management
version 7.0, when used with the separately licensed product Implementer
Adapter for COOL:Xtras CM. The Implementer Adapter for COOL:Xtras CM
provides change control for COOL:2E developed applications and traditionally
developed (3GL) applications.
Hawkeye Integration
This release of Implementer provides improvements with Hawkeye
related object information. When adding related objects to a promotion
request using Implementer or Pathfinder as the source of related objects,
modules are properly added to the request for the effected relationship
references.
When displaying related objects, the correct relationship references appear

on the related objects. For example, for the Module library and Module
Source library, the library of the associated environment displays.
Lotus and Domino Integration

The Implementer and Lotus Domino integration now supports the
management of the ACL for Domino databases by allowing you to set the
ACL at various stages of the development cycle. For more information, see
the Implementer Multi-Platform Solutions Guide.
CODE/400 Integration
Implementer provides integration into CODE/400 to offer a Windows-
based version of the classic host tools SEU, SDA, RLU, and PDM. This
integration provides seamless access to your iSeries source and objects, and
offers efficient development of your ILE RPG, ILE COBOL, ILE CL, ILE C,
ILE C++, database description specifications (DDS), and Java applications.
For more information, see the Chapter 10 of the Implementer User Guide.
37
Getting Started
User 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 user’s role. With Implementer, you
have the ability to tailor the exact role each individual fulfills. These roles
are:
System Administrator
Project Leader
Developer
Tester
System The system administrator has the highest level of authority within
Implementer to maintain the Implementer control parameters.
Administrator 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.
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 The types of environments you define are based on how you plan to use
Implementer. Support for three different environment types is provided:
Types production, test, and development, with an unlimited number of
environments being supported. Every organization defines production
environments. How development and test environments are defined varies
from company to company.
Production Environments
The production environment type (abbreviated *PRD) defines libraries that
contain the final production member/object versions. For example,
environments that are *PRD environments usually use program and/or
database libraries that are in the end user’s library list.
When you promote to a production environment, the members/objects

locks are released. The lock is removed at the end of the move step. Lock
removal is the main technical difference between test environments and
production environments.
Check out normally occurs from a production environment. Each

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

changed to indicate that the member/object is still checked out from
production, but the current location of the member/object is this test
environment.
You normally check out from production environments. However, you can
also check out from a test environment. One reason would be to correct a
problem that is detected during testing. When you check out from a test
environment, the item being checked out must originally be checked out
from a production environment.
Another use of test environments is to control when the lock is released

during promotion. For example, you have a promotion request targeted to
two environments (a local environment and a remote environment). If you
want the lock to be released as soon as promotion to the local environment
is complete, create both environments as production environments. If,
however, you want the locks to be removed upon completion of the entire
promotion request, create the local environment as a test environment and
the remote environment as a production environment.
Development Environments
The development environment type (abbreviated *TST) defines libraries
that are used and changed by the developer. It is necessary for these
libraries to be controlled by Implementer because members/objects must
be checked out using the Implementer check out function before they can
be promoted.
Although all Implementer users have development libraries, the use of

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

common development libraries or have database files in one development
library, program objects in another library, and source in a third library.
Libraries Four default libraries can be defined in Implementer. The first three are the
program library, database files library, and source library.
Source members are placed into the default source library. Database files,
including SQL tables and views, physical files, logical files, and data area
objects are placed in the default database files library. All other objects are
placed into the default program library.
41
Getting Started
Both the source and object library values can be overridden for each
allowed object code in the environment. This means you could have a
different source library and different object library for every type of object
in this environment. There are several reasons why you might override the
object codes:
Source members for the different types of objects are stored in

different source libraries.
Data areas are placed in the program library, not the database files
library.
Logical files are placed in a different library than physical files.
Programs are placed in different libraries than display files.
The fourth default library is the archive library, which you define if
archiving is specified for the environment. It cannot be overridden for each
object code. The archive library cannot be used for current objects for this
environment. Different environments can use the same archive library or
they can use different archive libraries.
Source Files The source files used for the environment are established by defaults from
the object codes defined for this environment. The source file used for a
particular type of object can be overridden for the environment on the
Work with Environments, Object Code Overrides panel.
Object Owners The Implementer environments control the ownership and authorities of
objects. This allows a test environment to be secured differently than a
and Authorities production environment.
The owner and authority of objects are changed during the Reset
Authorities function and the move step of a promotion. The move step
only changes the objects on the promotion request, whereas the Reset
Authorities function changes all objects for that environment, if required.
Defining Owners
Owners can be specified for both libraries and objects. Different owners
can be specified for the program library, database library, and source
library. Different owners can also be specified for the different types of
objects: program objects, database file objects, and source files.
Defining Authorities
Authority information can be specified for the environment on the Work
with Environments, Object Authorities panel. This panel allows you to set
specific authorities for an unlimited number of user profiles defined in
Work with Users.
You also can designate an authorization list on this panel.
When you define authorities, you define the authority established for all
objects promoted to this environment. By default, Implementer sets all
objects to *PUBLIC *EXCLUDE. You should review the authority options
each time you create a new environment.
Additional features in Implementer are used to support authorities. The

first feature is Implementer data areas PFREFOBJ and LFREFOBJ. These
data areas are used to override the owner and authority information for all
database file objects, regardless of the environment they reside in.
The second feature is to use an Implementer user exit program to insert

your own object authority granting routines. This program, IMPRMV3, is
described in source member IMPRMV3 in source file QSAMPLE in the
Implementer product library.
Implementer data areas and QSAMPLE options are described in more

detail in Appendix A of the Implementer System Administrator Guide.
Considerations for IFS Objects

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

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

by user SDMAUTUSR; the object owner is not set when the Build List
or Reset Authorities is run.
For environments defined to a mounted drive, the Reset Authorities

function does not change the authorities and owners of IFS objects.
Capabilities The collective rights to perform Implementer tasks on an environment can

be restricted to certain users. These are called user capabilities. User
capabilities can be changed from either Work with Users or Work with
Environments.
43
Getting Started
Administrator The administrator is the user profile that owns and controls a specific
environment and has move capabilities to that environment. A user profile
must have Move Request authority to be an administrator. The
administrator can have additional capabilities to promote and archive. To
modify or display these capabilities, select environment capabilities for the
administrator’s profile in Work with Users. Multiple users can be granted
administrative rights to an environment through Work with User
Capabilities.
Library List The environment library list is used in three ways. Primarily, it is used to
compile source members during promotion and during development from
Considerations the Workbench. The third use is to issue special commands of a promotion
request. (When using special commands, keep in mind they cannot be used
to change the environment library list.)
If the environment library list is incorrectly defined, the compile step often
fails or, even worse, compilation occurs against the wrong objects,
resulting in level checks. You must be certain this list has the correct
libraries needed for compilation. This is a relatively common error during
the initial use of a new environment.
If you use special compile procedures, such as those required by some

third party software packages, their library must be added to the compile
library list. It should not be put in the Implementer job description
MWIJOBD. The library has no effect there, as the library list of the current
job is replaced with the environment library list prior to compilation of a
source member.
In addition, the environment library should not have the Implementer

product library (the default is MKSIM) on the library list. It is only needed
on the library list of the Implementer job description.
Defaults for The environment is used to define a set of rules and defaults for the
promotion requests that target the environment. At request creation, you
Promotion can elect to:
Requests 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.
Remote If you define remote environments, you must set up additional remote
specific values. This information is discussed in detail in “Performing
Considerations Distributions” on page 271.
Environment Environments can be grouped into an environment group. You use

environment groups when you want to create a promotion request for
Groups 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 Implementer maintains an inventory of all members and objects for each
environment. This allows you to view what currently resides in the
Inventory 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 Implementer provides the ability to perform integrity analysis of

Implementer environments and libraries. The Environment Integrity
Integrity Check 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 If you use default project or environment application paths (either

standard or emergency), the environment or library defaults are
Paths 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 Standard Path
and Related Environments
Check Out
Development Quality Assurance Mods Production

Promotion Promotion
(Automatic
copy from)
Related Environment
Production
Environment Path Related Environment
Seq 10—Development Seq 10—Mods Production
Seq 20—Quality Assurance Seq 20—Production
Seq 30—Mods Production
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
Using the Workbench for
Development Activities 3
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
Using the Workbench for Development Activities
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
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 Quality Assurance Production
Promotion Promotion
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
( De si gn Req ue st or P roj ec t)
MANAGE LOCKS REVIEW WORK
(W or k wi t h O bj ec ts)
( De si gn Req ue st or P roj ec t)
PRO MOT E MY CHECK OUT

( To a Dev el op m ent
(T o Te st o r Prod uct i on)
Env i r onm ent or Li br ary)
WORKBENCH
CHANG E
T EST (S EU, S DA, RLU,
(W RKMB RPDM ,
W RKM BRP DM)
Com m and Li ne) COM PILE
(O pti on 14= Com pil e)
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 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
Work 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).
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 You can view or change (if authorized) any details about the Issue or
project you have associated with your work. You can access complete
Details information about the DR and project including development information,
benefits, alternatives, approval information, and status. Approvals and
status allow you to control your work or perform an inquiry. While on the
Project reference or Design request field, press F4=List, to select the project
or DR, or use option 15 to view work already assigned to a DR.
Checking Out Once you have identified your work on a DR or project, you check out
member/objects so they can be created or changed within a controlled
environment. You have numerous options for standard and emergency
check out. You can select from a list of member/objects for concurrent
development, or as a shortcut method, for checking out member/objects
that are similar to ones already checked out. You can also quickly access
Work with Objects to initiate new changes.
Changing Items You usually check out an item to change it, delete it, or reserve the name
(for a new member/object). You can edit members (SEU), display files
(SDA), design report layouts (RLU), use WRKMBRPDM, or use the
command line. A built-in source Compare Member (ICMPMBR) command
provides easy identification of changes. The Merge Member (IMRGMBR)
command can automate changes when applying them to multiple versions
or custom libraries or when incorporating changes from multiple
developers or vendors.
Compiling You can immediately compile a locked object directly from the Workbench
using option 14=Compile. This option is also available as option 67,
Workbench Compile (ICOMPILE) from the Implementer Menu.
For more information, see “Workbench Compiles of Locked Objects” on

page 79.
Testing To test a change, you typically start an application. A command line

permanently displays in the Workbench to allow access to any OS/400
command or application.
If you have promoted changes out of development to quality assurance,

you can easily reject the changes that fail testing and return them to
development for rework.
53
The Set to Environment Library List (ISETLIBL) command allows you to

change your job’s library list to that of any environment managed by
Implementer. This provides quick and accurate changing between the
appropriate development library list and the corresponding production
library list when testing. This command is particularly effective when set
up as a user-defined option.
For more information, see “Setting a Library List From an Environment

Library List” on page 83.
Promoting Once changes are complete, you need to promote the changes to the next
environment in the flow of development. Several options are available for
you to promote your work from the Workbench: option 11=Promote,
Clipboard options, and from Work with Objects with option 27=Promote.
You can select member/objects from multiple environments. You also
have emergency promote options. To provide absolute flexibility and
control, you can authorize specific people to perform the various
promotion steps based on user profile and environment. Implementer
adapts to the way you do your work.
Time Entry You can perform time entry anytime during the development process by
using option 30=Book Time, or by prompting the Monitor Progress
(PMONPG) command.
Time entry allows you to compare actual time to estimated time for future
work forecasting. You can easily update remaining time to maintain an
accurate estimate of continuing work.
Managing The Workbench allows you to manage individual or concurrent

development by specifying who is responsible for any specific change.
Locks
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.
Optional Check From the Workbench, Implementer offers two methods for processing
check out and promotions—the one step method and a traditional method.
Out and Both methods provide access to the same features and produce the same
Promotion results. However, the one step method allows you to perform check out
and promotion using a fast path approach that saves time and effort,
Methods thereby minimizing the number of steps required in the functions. Because
of the efficient streamlined effort, the one step methods are preferred by
most developers. The traditional methods, which are more interactive,
display more panels and require additional input for processing.
Member/Object From the Workbench, you can track the status and history of all member/
objects under change management control. The status identifies the current
Status and state or application path of the member/object. As member/objects flow
History through the change management cycle, all historical software changes and
associated lock information is retained as well. When the status of a
member/object changes, the information is updated and the change is
recorded in the Status History file (IMSTHS). The status and history is
available in Work with Objects.
For more information, see “Member/Object Status and History” on

page 90.
Alternate Views The Workbench provides several views of additional information. A

developer can quickly position to specific projects and DRs, member/
and Filtering objects, object code, environment, and many more options, to view their
specific changes. The list can display all current development or testing so
that a manager knows the location and status of each member/object.
Multiple The Workbench allows you to process your work using a variety of
methods. Direct options exist for all daily tasks, including for example,
Selection editing, checking out, and creating requests. More involved options allow
Methods you to select member/objects for check out and promotion across panels or
various positions in a subfile.
Automatic The Workbench allows you to select member/objects by groups that are
meaningful to you, even if they are in multiple environments. You can
Grouping automatically check out or create promotion requests for items that you
want to process together (same environment path or project path, project,
or DR [DR for check out only]). If the member/objects need to be processed
in multiple groups, a message alerts you during check out or create request
and provides an option to either process all items as a single group or as
separate groups.
55
Concurrent The Workbench provides developers with options to resolve concurrent

development prior to request promotion. After you identify the specific
Development 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 The Workbench supports user-defined options. This allows unlimited

access to OS/400 functions for items on the Workbench. With this feature,
Options 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 The Workbench allows direct access to Work with Objects. Work with
Objects provides visibility to all objects controlled by Implementer, and the
Objects ability to initiate check out of a member/object not under development. It
provides lock history, archive history, member/object status history, and
inquiry to all member/objects on the system. You can display and work
with all objects, or IFS objects only using F16=Show IFS Only.
The following tables compare the functionality of the Workbench with the
functionality of Work with Objects.
My Workbench and Work with Objects, Option Comparison
My Workbench Options Work with Objects Options
2=Change (SEU) —
— 3=Promotion requests
4=Delete (Lock) —
5=Display (SEU) 5=Display (SEU)
6=Print (Mbr) 6=Print (Mbr)
7=Lock detail 7=Mbr/Obj detail
8=Related objects 8=Related objects
9=Add to Clipboard 9=Add to Clipboard
— 10=Checkout
11=Promote —
12=Concurrent development 12=Locks
— 13=Lock history
My Workbench and Work with Objects, Option Comparison
My Workbench Options Work with Objects Options
14=Compile 14=Archives
15=Issue or Design requests 15=Issue or Design requests
17=Change using SDA —
19=Change using RLU —
20=Reject 20=Reject
21=Emergency check out 21=Emergency check out
22=Emergency promote 22=Emergency promote
23=Compare member 27=Promote
24=Merge member —
26=Multiple issues or design —

requests
27=Check out —
28=Status History 28=Status History
30=Book Time —
My Workbench and Work with Objects, Function Comparison
My Workbench Function Keys Work with Objects Function Keys
F3=Exit F3=Exit
F4=List F4=List
F5=Refresh F5=Refresh
F6=Check Out F6=Workbench
F7=Process Clipboard F7=Process Clipboard
F8=Work with Objects F8=Apply Filters
F9=Retrieve (previous command) F9=Retrieve (previous command)
— F10=Display (changes the sequence of

displayed fields)
F11=Display (changes the F11=Display (changes the sequence of

sequence of displayed fields) displayed fields)
F12=Cancel F12=Cancel
F13=Repeat —
57
My Workbench and Work with Objects, Function Comparison
My Workbench Function Keys Work with Objects Function Keys
F14=Compile requests F14=Compile requests
F15=Move requests F15=Move requests
F16=User options F16=Show IFS Object
F17=Filter —
F18=User Defaults F18=Show deleted
F19=Request inquiry F19=Request inquiry
— F20=Check out
— F21-Build IFS Obj List
F22=Promote F22=Promote
F23=More options F23=More options
F24=More keys F24=More keys
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.)
Using the Clipboard
Basic Clipboard The Clipboard option is particularly helpful when you are positioning
within the subfile rather than scrolling.
Functions
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 The Add to Clipboard (IADDCBD) command adds traditional member/

objects to the Clipboard. The Add to Clipboard IFS (IADDCBDIFS)
Command command adds IFS objects to the Clipboard.
Options to Add These commands can be issued from the command line, or you can write
Clipboard Items 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.
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.
Using the Clipboard
Using the The Create Request (ICRTRQS) command contains a MBROBJ parameter
option, *CLIPBOARD, which selects all Clipboard items for create request
ICRTRQS processing.
Command to The *CLIPBOARD option makes it possible to create a request for all
Promote member/objects currently on the Clipboard, without the need to actually
display the Clipboard. This means that the ICRTRQS command can be
Clipboard Items called from a program. Used in conjunction with the IADDCBD command,
you can select items and create a request for those items, without the need
for any manual processing.
CAUTION
This command processes all items on the Clipboard—not just the items
selected by your program.
Using the The Process Clipboard (IPRCCBD) command allows you to perform all
standard Clipboard processing options outside of Implementer, in the
IPRCCBD same manner as can be done from the Workbench using the F7=Process
Command to Clipboard function.
Process the The *CLIPBOARD option makes it possible to create a request for all
member/objects currently on the Clipboard, without the need to actually
Clipboard 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 Displays the Clipboard Processing Menu. This is the default

value.
*DISPLAY Displays the contents of the Clipboard.
*CHKOUT Checks out all items on the Clipboard.
*CRTRQS Creates a request for all items on the Clipboard.
*ECHKOUT Performs an emergency check out for all items on the
Clipboard.
*ECRTRQS Performs an emergency create request for all items on the
Clipboard.
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 Performing one step check out.
checking out, see “Performing
Check Out” on page 111. 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 Implementer offers two methods for processing check out—the one step
method and a traditional method. The one step method allows you to
Methods 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.
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.
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 the Workbench, you can check out unlocked member/objects
through Work with Objects.
From 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.
Checking Out
Checking Out The Clipboard provides an easy way to store multiple member/objects for
checking out.
Using the
Clipboard 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 Authorized users can perform emergency check out from the Workbench.
Emergency To perform an emergency check out

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 Many organizations restrict development on a particular member/object

to a single developer at a time within one environment, due to the risks of
for Concurrent losing changes when multiple copies are simultaneously under
Development
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 Attempting to access Work with Objects displays the message

“Requested function is already active on a previous panel”. What
Questions 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.
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 are held in an options file and maintained by using
the Work with User-Defined Options panel in PDM. You can access this
User-Defined panel from Work with Objects Using PDM (WRKOBJPDM) or Work with
Options Members Using PDM (WRKMBRPDM) by using F16=User options. It is
also available from the Display PDM User-Defined Options File panel or
the User Defaults panel, by using F8=STRPDM.
User-defined options can contain either OS/400 commands or user

commands, and can contain any of the following supported substitution
variables (beginning with an ampersand (&)). The following table defines
the valid keywords and substitutions. Those items with Yes in the
Workbench Only column are supported exclusively on the Workbench.
NOTE
The substitution variable &OBJECT returns the project’s relative long object
name when a long object is associated with a lock (&OBJECT returns the actual
object name when a long object name is not specified).
Valid Keywords and Substitutions for PDM User-Defined Options
Alternate
Workbench Locks File
Field Keyword Keyword
Only Field
(PDM)
member object name – &LCKMBROBJ &N1 LHMONM
object code Yes &LCKOBJCOD – LHOBCD
source member name – &SRCMBR &N1 LSMBNM
source file – &SRCFIL &F LSTOFL
source file library – &SRCLIB &L2 LSTOLI
source type – &SRCTYP &T3 LSMBTY
Alternate
Only Field
(PDM)
object name – &OBJECT &N1 LOOBNM
object library – &OBJLIB &L2 LOTOLI

3
object type – &OBJTYP &T LOOBTY
object type no * – &SHTOBJTYP &S LOOBTY
object attribute – &OBJATR &A LOOBAT
design request nbr Yes &DSNNBR – LHDRNB
environment name Yes &ENVNAM – LHTOEN
member/object description (obj if no – &DESC &X –

source, in ‘ ‘)
from environment Yes &FRMENV – LHGMEN
from object library Yes &FRMOBJLIB – –
from source file Yes &FRMSRCFIL – –
from source library Yes &FRMSRCLB – –
user profile Yes &USER – –
project Yes &PROJ – –
comments Yes &COMMENT – –
option name – &OPT &C –
compile in batch – &CMPBCH (*YES/*NO) &P –
to directory (IFS only) Yes &DIR – –
object and to directory (IFS only) Yes &PATHOBJ – –
from directory Yes &FRMDIR – –

(IFS only)
Jobd name – &JOBD &H –
Jobd library – &JOBDLIB &G –
Jobd and library with ‘/’ separator – &JOBDWLIB &J –
COOL:2E model object list Yes &SYNMDOLST – –
COOL:2E object surrogate Yes &SYNOBJSGT – –
AS/SET Application set name Yes &ADKSET – –
AS/SET From application set name Yes &FRMADKSET – –
73
Alternate
Only Field
(PDM)
LANSA partition name Yes &LANPAR – –
LANSA from partition name Yes &FRMLANPAR – –
JDE common library Yes &CMNLIB – –
JDE from common library Yes &FRMCMNLIB – –
Comment (1st 10 char only) Yes &COMMENT10 – –

1 If the value of the PDM mode field in the User Defaults file is O, this variable represents the object name. If the value
is M, this variable represents the source member name.
2
If the value of the PDM mode field in the User Defaults file is O, this variable represents the object library. If the value
is M, this variable represents the source library.
3
If the value of the PDM mode field in the User Defaults file is O, this variable represents the object type. If the value is
M, this variable represents the source member type.
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.
Changing User From the Workbench, access the Change User Defaults panel by pressing
F18=User Defaults.
Defaults
This panel allows you to change your defaults for Implementer functions.
If enrolled in Implementer through a group profile, only a user with User
Profile maintenance rights can change the defaults for the group profile.
Users with User Profile maintenance rights can set up other users’ defaults
as well.
NOTE
These fields can be maintained from Work with Users by selecting a user with
option 20=User Defaults to display the Change User Defaults panel.
On the Change user Default panel, no field is provided for Object Library
because this information is determined based on the lock information. If you
need to override the Object library, prompt the compile command and specify
the Object library in the creation command.
Change User Defaults Field Descriptions

The following fields display on the Change User Defaults panel.
75
Edit source on check out
Specify Y or N to indicate whether you want to automatically edit source-

based objects after check out. The default value is N.
NOTE
If more than 10 source-based items are checked out at one time, this option is
ignored and the source is not edited.
Compile in batch
Specify Y or N to indicate whether you want to submit the compile (Y) or

compile interactively (N) for option 14=Compile. This is the default value
used by the Workbench Compile (ICOMPILE) command when it is issued
from a command line.
Job description/Library
Specify the name of the job description, or *USRPRF to use the job
description of your user profile. The job description does not control the
library list used to compile; rather, when compiling items locked to
environments, the environment library list is used; for objects in a library
that are not part of an environment, the library list of the current job is
used.
PDM option file/Library
Specify the name of the file and library that contains the member with the
user-defined options. These are the default values used by the Workbench
Compile (ICOMPILE) command when it is issued from a command line.
Member
When this field is set to the same value as the user’s Work with Members
Using PDM options file, the same options available from within PDM are
now available from the Workbench. If you want different options, specify a
unique name in this field. Either way, the options need to be maintained
using the Work with User Defined Options panel within PDM.
PDM mode
Specify O or M to indicate Object, or Member, respectively. This entry

indicates whether substitutions are made as if you are using Work with
Objects, using PDM (O) or Work with Members using PDM (M). For more
information, see the table on page 72.
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 You can display user-defined options from the PDM database in the
Workbench.
User-Defined
Options To display PDM options from the Workbench
From My Workbench, press F16=User Options. The PDM User-

Defined Options window displays.
The file and member containing the user-defined options displays at

the top of the panel. To change either the file or member used, specify
a different PDM options file member on the User Defaults panel.
Processing 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,
PDM User- the list of substitutions is replaced on the User Option command and
Defined Options 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.
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 Checked out to a library
The library list for the compile is taken The current library list of the job calling
from the locked to environment. the command is used for compilation.
If the authority method is *KEEP, the If the authority method is *KEEP, the
authority of the existing object is kept. authority of the existing object is kept.
If the authority method is *GRANT or Otherwise, the library creation
the object does not exist, the authority authority for the target library is used.
from the locked to environment is used
for the new object.
Special commands for the compile No special command is issued.

step are issued based on the locked to
environment definition.
Identifying the You can identify the item to be compiled in one of two ways:
Compile Object 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 Value
Member/object (MBROBJ) PGM1
Object code (OBJCODE) RPG
Checked out to LIB/ENV (LIBENV) 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 Value
Member/object (MBROBJ) PGM1
Source file (SRCFILE) 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 Object ownership and authority is based on the

specifications for the object code.
*KEEP Object ownership and authority is retained based on the
production environment parameters.
*GRANT Object ownership and authority is granted based on the
target environment parameters.
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.
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 The Set to Environment Library List (ISETLIBL) command changes your
job library list to that of any environment managed by Implementer. This
Library List allows you to change between the appropriate development library list
From an and the corresponding production library list quickly and accurately when
testing.
Environment
This command is particularly useful when testing a changed application. If
Library List you specify a command to call after setting the library list, the original
library list is re-established when you return from the called command. For
example, assume you use this command to set the library list and
automatically run an inventory program that you are testing. Once you
exit from the inventory program, the library list that was in effect before
testing began is re-established, and you can continue with any activities
you were performing prior to running the test.
This facility is also available on the Implementer Menu, option 68, Set to
Environment Library List (ISETLIBL).
TIP
Add this command as a user-defined option to the Workbench. The user-
defined options TS (Test a Change) and TO (Test an Object) are available. These
options are described in “Available PDM Default Options” on page Available
PDM Default Options. For instructions on how to set up user-defined options,
see “Setting Up User-Defined Options” on page 72.
ISETLIBL Command Parameters

The following parameters define the Set to Env Library List (ISETLIBL)
command.
Environment
Specify the environment that the library list is based on. This is a required
entry.
List position
Specify the position within the library list to place the environment
libraries. The default value is *REPLACE, which replaces the current
library list. This is the only valid value.
83
Command
Specify a command to call after setting the library list. When you return
from this command, the original library list is re-established. This feature is
particularly useful for testing a changed application.
Additional library 1 and 2
You can specify two additional library names. These libraries are added
above the environment library list. This feature is useful for adding a
personal library to the top of the environment list.
Available PDM The following PDM options can be set up to allow access from the
Workbench:
Default Options
Option Purpose Command
TS Test a change ISETLIBL ENV(&envnam)

POSITION(*replace)
CMD(call qcmd)
TO Test an object ISETLIBL ENV(&envnam)

POSITION(*replace)
CMD(call &object)
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.
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 Implementer offers two methods of promotion: the “fast path” one step
method and a traditional method. The one step method allows you to
Methods 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 This task describes the various methods for accessing the Create Request
function to create a promotion request from the Workbench. The
Promotion advantages of creating requests from the Workbench include:
Requests 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
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.
Compiling and Moving Promotion Requests
3 In the Create Request Comments panel, you must enter a comment in

order to process the promotion request.
If the member/objects are associated with one or multiple DRs, the DR

numbers and titles are automatically included in the comment. The
automatic entries fulfill the required comments. You can add other
comments if needed.
4 Press ENTER to complete the promotion request creation.
Task Variations When you access the Create Request main panel from the Workbench,
your selections are edited. If an error occurs or if more processing is
necessary, follow the directions indicated in the message.
To manage concurrent development, see “Concurrent Development”

on page 56.
To use special commands, override the create request defaults,

override submission defaults, promote to additional target
environments, copy a request, or to select additional member/objects,
see “Performing Promotions” on page 171.
Compiling and Moving Promotion Requests

This task describes how to compile and move members from the
Workbench.
Typically, you define production environments to automatically run only

through the compile step, leaving the move step (and distribution step) to
be submitted by someone with move capabilities for the production
environment. You can use option 2=Change from the Create Request
panel, to change the compile or move request information.
You can also access these functions from Implementer Menu.
NOTE
You do not have to perform this task if you set the environment default for the
Auto submit in create request field to Y and the Through step field to 4 (which
automatically includes the compile and move steps). In this case, the
promotion is initiated when you create the promotion request.
To compile a promotion request
1 Press F14=Compile Request to display the Compile Request panel.
89
2 In the Compile Request panel, type 1 in the option field and press
ENTER to submit the compile. For detailed information, see
“Compiling” on page 220.
3 After the message displays indicating the promotion request was

submitted, press F3=Exit to return to the Workbench.
To move a promotion request
1 Press F15=Move Request to display the Move Request selection panel.
2 In the Move Request panel, type 1 in the option field and press
ENTER to submit the move. For detailed information, see “Moving
Promotion Requests” on page 224.
3 After the message displays indicating the promotion request was

submitted, press F3=Exit to redisplay the Workbench.
Member/Object Status and History

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 developer’s personal
library is treated as a development environment).
The benefit of this is an online audit trail of every action performed to a

member/object. You can display the status history for a member/object to
verify the action taken, application path targeted when the change
occurred, the user who performed the action, and the date and time the
action occurred.
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
In Work with Objects, when displaying the status history for an object in
production, history displays for all closed locks that were promoted into the
production environment. If multiple locks are rejected or promoted at the same
time for a single member/object, history is added for each of the locks.
Keep in mind, any changes performed outside of Implementer, for example,

changing source with PDM, are not tracked.
The Purge History function removes obsolete lock and promotion request
history from environments, as well as status history from production
environments.
The following table explains the member/object status codes and

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

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

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

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

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

environment.
EmgCO-Chg The item is currently checked out for emergency change.
EmgCO-Crt The item is currently checked out for emergency create.
EmgCO-Dlt The item is currently checked out for emergency delete.
EmgCO-Cmp The item is currently checked out for emergency recompile.
EmgCO-Rgn The item is currently checked out for emergency regeneration.
Src-Edited The source was just edited (implies a compile was not
attempted since it was last changed).
91
Status Description
Comp-Fail The source was compiled but the object was not found in
development. This status only applies to objects compiled from
the Workbench (this status is not assigned when a compile is
performed on a promotion request).
Comp-Ok The item is currently in development. The last action was a

successful compile. This status only applies to objects
compiled from the Workbench (this status is not assigned
when a compile is performed on a promotion request).
Dev–>QA1 The item is currently on a promotion request, going from

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

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

environment.
QA1–>QA2 The item is currently on a promotion request, going from one

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

last *QAC environment to a *PRD environment.
In Prod The item was successfully promoted to a *PRD environment.

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

when displaying the history from Work with Objects (the
Current Status field on the Status History panel).
To display the current status
From the Workbench or Work with Objects, the current status

information displays in initial default view.
The Status field supports subfile filtering. In Work with Objects, filter
on Prod to list objects that do not currently have a status assigned.
Filter on Open to list all objects that are currently locked—all objects
that have a status display, regardless of the status value.
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.
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
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 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
Lock 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 The user profile that created the lock.

Project reference The project reference created in Work with Projects
and either assigned as the default, or changed at the
time of check out by the user.
Issue or DR The specific issue or design request number.
Number
Action 1 for Change, 2 for Create, or 3 for Delete.
Lock type Std (standard) or Emerg (emergency).
Comments As required.
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
To delete a lock

(*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.
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 Type Y or N to indicate whether you want to delete the

locks for all items that display.
Delete sources Type Y or N to indicate whether you want to delete the
source for all items that display for the environment.
Delete objects Type Y or N to indicate whether you want to delete all
objects that display for the environment.
4 Press ENTER to confirm deletion and return to the Workbench. (Press

F12=Cancel to redisplay the Workbench without deleting the lock.)
Associating 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
Multiple Design by multiple DRs.
Requests With If the member/object is associated with a DR, the DR status (Ready to
a Lock 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

(*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.
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
Projects
4
T 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.
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 If you check out from DesignTracker, do not use this task. Instead, follow
the instructions in “Creating Projects From ProjectMaster” on page 106.
Projects From
Implementer To create projects from Implementer
1 From the Implementer Menu type 15, or type STRIM (*WRKPRJ) at

the command line and press ENTER to display the Work with Projects
panel.
To position the panel, type the name or partial name of the project in
the position field directly above the list of project names, and press
ENTER.
Creating Projects
2 From the Work with Projects panel, use option 2 on an existing project
to change it, or press F6=Create to create a new project.
3 From the Change Project or Create Project panel, type the description
and other information, and press ENTER. The Work with Projects
panel redisplays. Project creation is now complete.
Work With Projects Options

The standard options on this panel include 2=Change, 3=Copy, 4=Delete,
and 5=Display. The additional options include:
8=Functions
Display the Work with Functions panel.
9=Schedule
Display the Schedule Tasks panel.
10=Workbench
Display the Workbench panel.
12=Promotion Reqs
Display the Request Inquiry panel.
14=Design Reqs
Display the Work with Design Requests panel.
17=Standard Path
Change or display the standard project path on the Standard Project Path
panel.
18=Emergency Path
Change or display the emergency project path on the Emergency Project

Path panel.
20=Tasks
Display the Work with Tasks panel.
21=Gantt Chart
Display the Interactive Gantt–Daily panel.
105
Projects
Creating You can access DesignTracker from within Implementer to create an

Implementer project. Authorized users can create or select a DR from the
Projects From Check Out main panel. You should use this option for project creation if
ProjectMaster you check out from DesignTracker.
To create a project from DesignTracker
1 Access the Select Design Request panel using one of the following
methods:
From the Workbench, position the cursor in the Design Request

field and press F4=List.
From the Work with Objects panel, position the cursor in the
Default DR field and press F4=List.
From the Check Out main panel, position the cursor in Design
Request field and press F4=List.
NOTE
Depending on your DesignTracker setup, you can display the Define Subset
panel before you access the Select Design Request panel.
2 From the Select Design Request panel, either select an existing DR or

create a new one.
a) To create a new DR, press F6=Create. The Create Design Request

panel displays.
b) Type the title of the DR and any other pertinent information.

Alternatively, press F7=Select SR to display the Select Service
Request to Attach panel. Select an existing service request to
create the new DR from.
c) Press PAGE DOWN twice to display the third Create Design

Requests panel. Type the company name.
d) Press ENTER. The Select Design Request panel redisplays.
3 Type option 12 to display the Work with Entity List panel.
4 Press F20=Create IM Project. A message displays stating

“Implementer project DTxxxxx has been created”.
Where xxxxx represents the number of the selected DR.
5 Press ENTER to redisplay the Select Design Request panel.
6 Type option 1 next to a DR and press ENTER. The Check Out main
panel redisplays.
Project Paths
Setting Up a If this project is a default project for a user, perform these steps:
Default Project 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
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.
Advanced You can use ProjectMaster to schedule resources. The advanced scheduling
features include scheduling one resource (person) across multiple projects,
Scheduling prioritization of tasks, and dependencies of one task to another.
Features 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 Project reporting capabilities include:
Capabilities Weekly and cumulative time sheets
Gantt charts
Cost analyses
Planned versus actual reporting
109
Projects
Performing Check Out
5
T 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 developer’s development library
or an environment. When the check out is complete, Implementer secures a
lock on the object to identify the user who has it checked out and for what
purpose. You can optionally check out members/objects attached to an
Integrity Manager Issue or a DesignTracker Design Request.
check out fundamentals
check out methods
object version stamping
checking out IFS files and directories
concurrent development
checking out related objects
checking out with a Design Request
using ILE object codes
checking out physical file data

using different source and object names during check out
user authorities
checking out for reject
object name rules
check out commands
converting RPG/400 or RPGIII source code to ILE RPG/400
converting CRTBNDxxx ILE programs to CRTPGM style programs
checking out using PathFinder for information
111
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 Implementer also provides the Execute Checkout (IEXCCKOCMD)
“Special Command command, a special command that allows you to distinguish certain items
Processing” on page 229.
during check out for additional special command processing.
It is possible that certain types of objects are restricted (deactivated) from
check out. Various methods exist for restricting object codes:
Object codes can be restricted at the object level, in Work with Object
Codes. For example, this could be done if your organization does not
plan to use certain types of objects.
Object codes can be restricted at the environment level. For example,

this could be done because a particular application does not have
System/38 environment programs.
Object codes can be restricted at the user level. For example, this could
be used to control database administrator rights.
Check Out Methods
Check Out Methods

Implementer offers two methods for processing a check out—the “fast
path” one step method and a traditional method. The one step method
allows you to perform check out for change using a fast path approach that
saves time and effort, thereby minimizing the number of steps required in
the check out function.
The traditional method, which is more interactive, requires you to access

and define more panels. Both methods provide access to many of the same
features and produce the same results. The major benefit to the one step
method is that after selecting the items for check out, the automatic process
runs quickly, and the Workbench panel displays with your current locked
items listed.
The default check out method is defined on a per user basis in Work with
Users, controlled by the Enable One Step Checkout flag. When initially
installing Implementer, the one step method is enabled by default. For
subsequent upgrades, the value defined at the time of the upgrade is
retained. For more information, see Chapter 3 of the Implementer System
Using the One The one step check out method applies to checking out from the
Workbench (F6=Check Out), the Clipboard, and Work with Objects
Step Checkout (option 1=Check Out and option 21=Emergency Check Out). When using
Method any other Check Out option (including, option 27 in the Workbench or F20
in Work with Objects), the menu options, or Check Out command options
the traditional Check Out function is performed.
When issuing a check out, the user profile record is validated to determine
the default check out method. If the one step method is enabled and the
check out is initiated from the Workbench, the Workbench Check Out
panel displays for member/object selection. With the one step method
enabled, you can perform any required overrides from the Workbench
Check Out panel with F4=Prompt, which displays the traditional Check
Out panel with any selected items populated. (Some tasks later in this
chapter require processing from the traditional Check Out panel.) If check
out is initiated from Work with Objects, the check out occurs
automatically. If one step check out is not enabled, the traditional Check
Out panel displays (requiring further input).
In one step check out, Implementer sequentially determines the default

from environment in the following order:
1 In the Workbench, if a project reference is specified, the From

environment associated with the project’s path (if a path exists).
113
2 In the Workbench, if a from environment filter is specified, the value

entered in the From Env filter field defaults.
3 If existing, the From Environment value of the first record in the

Workbench subfile defaults (the first environment listed under the
From Env filter line).
4 If specified in Work with Users, the default Check Out From

Environment value for the user performing the check out defaults.
5 If the previous attempts to retrieve an environment name are not

successful, the Environment Selection panel displays to select from a
list of valid check out from environments.
If errors are encountered while Implementer performs pre-processing edit

checks and validations, the Resolve Check Out Problems panel displays
the specific errors. You must resolve the errors before continuing.
To perform a one step check out
1 Access the check out function using any of the following methods for
standard one step check out:
From the Workbench, press F6=Check Out (the Workbench

Check Out panel displays with all member/objects in the from
environment loaded). Select the items with option 1=Check Out
and press ENTER.
Alternatively, press F16=Select All to check out all items in the

specified from environment. A message displays informing you
that you are about to check out all items in the specified
Check Out Methods
environment. You can press ENTER to continue with the check

out, or press F3 to return to the Workbench Check Out panel.
From Work with Objects, select the member/object with option

10=Check Out and press ENTER.
From the Workbench or the Work with Objects panel, select the
member/object with option 9=Add to Clipboard and press
ENTER. Process the clipboard with F7=Process Clipboard and use
option 2.
2 The check out occurs automatically and the reloaded Workbench

panel displays. A message displays indicating that the members/
objects were checked out. A lock is created for each checked out
member (to indicate work in process), and a copy of the member (or
object for non-source-based objects) is created in the development
library or environment.
NOTE
If you select objects with option 1 and then attempt to reposition the subfile,
the selected objects are processed through to completion (checked out and a
lock attached) and the Workbench Check Out panel displays at the selected
position.
Using the Traditional Check Out displays the Check Out panel. In the Check Out
main panel, you can enter individual members/objects (and object codes)
Traditional or select them from a list. This option is only available if the Build List
Checkout function was run. The Build List function creates a list of all members and
objects that exist in the environment’s library. The list displays in multiple
Method panels throughout Implementer. The list is dynamically updated while
continuously using the product. For detailed information on the Build List
function, see the Implementer System Administrator Guide.
The members/objects that are selected for check out directly from the
Workbench are already checked out; however, you can also use the Check
Out function to initiate concurrent development. Alternatively, initiating a
check out in this way provides a quick way to check out like—in other
words, using an existing check out to create a check out for a similar
member/object. This process is detailed in “Using the Workbench for
Development Activities” on page 49.
Checking out from the Workbench initiates concurrent development so

that you must select a specific version. This occurs because the Workbench
shows only locked objects.
115
To perform a traditional check out
1 Access the check out function using any of the following methods for
standard traditional Check Out:
From the Workbench (which shows locked objects only) select

option 27, or from the Work with Objects panel, select option 10
and press ENTER.
From the Workbench press F6=Check Out.
From Work with Objects press F20=Check Out.
From the Workbench or the Work with Objects panel, select the
member/object with option 9=Add to Clipboard and press
ENTER. Process the clipboard with F7=Process Clipboard and use
option 2.
From the Implementer Menu, select option 2, or type STRIM

(*CHKOUT) at the command line, and press ENTER to display the
Check Out main panel.
If you use a design request, you can also use F10=Select entity.
If the member/object is in a quality assurance environment, use

option 20 for Reject to display the Reject Change panel. For more
information about rejecting changes from QA environments, see
“Checking Out for Reject” on page 153.
2 Complete the Check Out panel as described in “Check Out Panel Field
Descriptions” on page 118.
Check Out Methods

message “Press F9=Accept to check out.” displays.
4 Press F9=Accept to perform the check out. A message displays

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

If authorized, you can access Emergency Check Out using any of the
following methods:
From the Workbench or Work with Objects panel, select option 21 for
Emergency check out.
From the Clipboard Processing menu, select option 4.
From the Implementer Menu, select option 21, or type STRIM

*ECHKOUT and press ENTER.
A similar panel can be accessed from the traditional Check Out panel
by using option 20 for rejecting a member/object with an emergency
lock.
For more information about Emergency Check out, see “Handling

Emergency Situations” on page 295.
NOTE
For emergency check out, the one step check out method applies when the
check out is initiated from Work with Objects, option 21=Emergency Check
Out and from the Clipboard, option 4=Emergency Check Out.
Vendor Integration Considerations
PathFinder users should note that PathFinder’s Where Used function

shows ILE *MODULE objects that uses a file. However, it does not
show the ILE *PGM and *SRVPGM objects that use the file because they
contain those *MODULE objects. To ensure that level checks do not
occur in the *PGM and *SRVPGM objects, use PathFinder’s Where Used
function to list the *PGM and *SRVPGM objects containing the *MODULE
objects. Then, add these objects manually to your check out requests.
Similarly, since PathFinder does not support cross-environment

functionality within Implementer, you must use PathFinder’s “Where
Used” feature to list the related objects in different environments.
117
Then, manually create the appropriate check out for these related
objects.
AS/SET definitions can be checked out from/to specified AS/SET

environments that are defined in Work with Environments. When
checking out AS/SET definitions, you must use the specific object
codes defined with special characteristics starting with ADK.
If you are managing AS/SET help for display programs, create a

separate object code with the special characteristic ADKHLP to check
out or promote the help text associated with the display programs.
If the member/object is a LANSA object, the from and to

environments must be LANSA environments. Checking out to a
library is not supported for LANSA objects.
LANSA objects entered or selected for copy are added to an export list
if the environment specifies to copy LANSA objects during check out.
Implementer supports checking out multiple LANSA functions with
the same name and object code of different processes, when the
process name is specified in the first ten characters of the Comment
field.
If you do not enter the process name in the Comment field, the
function is checked out from the first process containing the function.
The name of the process displays in the Comment field and can be
changed if the LANSA function will be checked out from a different
process.
Check Out Panel Field Descriptions

The following fields display on the Check Out panel.
From environment
Use one of the following methods to identify the environment to check out
from:
If displaying, use your default From environment retrieved from the

project path, environment path, or user profile.
To list an environment to check out from, position the cursor on the

From environment field and press F4=List. Type 1 next to the
environment and press ENTER.
Enter the specific environment to check out from.
Check Out Methods
To library/To environment
If you are using a default project path or environment paths (either

standard or emergency), the From environment and the To environment or
library defaults are based on the current location of the item. This can be a
library or an environment.
If the member/object is in an environment when you begin promotion, the

next project or environment path entry for the request type (standard or
emergency) is used as the next promotion location. This could be an
environment or an environment group.
If the environment that the member/object resides in is part of multiple

paths (and the item is locked), the path associated with the check out from
environment is used.
Use one of the following methods to identify the development location to

check out to:
If displaying, use your default to environment retrieved from the

To list an environment to check out to, position the cursor on the To

environment field and press F4=List. Type 1 next to the environment
and press ENTER.
Specify the environment to check out to.
You can check out LANSA objects only to a specifically defined

LANSA environment.
You can check out AS/SET definitions only to a specifically

defined AS/SET environment.
Specify the library to check out to.

You cannot check out AS/SET definitions to a library.
You cannot check out LANSA objects to a library.
Project reference
Use one of the following options to identify a project.
If displaying, use your default project.
To list a project reference, position the cursor on the Project reference

field and press F4=List. Type 1 next to the project, and press ENTER.
Type a valid project reference.
119
If you specify a project that has a defined application path, the from and to
environments default from that project’s path.
NOTE
If you want to use a design request, see “Checking Out With a Design Request”
on page 141.
Member/object list
Use one of the following methods to identify the members/objects to check

out:
Accept the members/objects you selected in the Workbench or Work

with Objects functions with option 10 for check out or the clipboard.
Position the cursor on a Member/object field and press F4=List to

select from a list of members/objects.
If you use related environments, the members/objects are listed in the

sequence established for related environments. Use F8=First
occurrence to display all the members/objects in different related
environments, or display the first occurrence of the member/object
that exits in the related environments list.
The two most common uses for related environments are to develop
one release of an application while you continue applying changes to
an earlier release (for example, release 2.0 based on release 1.0).
Secondly, to keep production modifications in a separate environment
from base production. In each case, the related environment list must
include all of the environments you want to define as related
environments.
Specify a member/object name and code on this panel. The action

defaults to 1 for change.
Press F8=Select from object codes to select from a list of object codes:
1Type 5 next to the object code and press ENTER to display the
Member/Object Selection panel. This list contains all member/
objects associated with selected object code for the environment.
2In the Member/Object Selection panel, type 1 next to the members/

objects and press ENTER. A message displays indicating you
selected some members for check out. Press ENTER again to
display the Check Out panel. The previously selected members/
objects now display on the Check Out panel.
Check Out Methods
Action
Specify the action to be taken in the production environment with the

members/objects being checked out. For example, if you want to replace
an existing program in production with a new program, the new program
action is 2 for Create. This reserves the program name, and the existing
program action is 3 for Delete (to remove it after the new one replaces it
during promotion).
1 = Change To change an existing member object.

2 = Create To create a new member/object in the production
environment. When creating a new member/object, you
can optionally designate an existing member/object to
copy from. The lock for a new member/object only locks
the use of the name because there are no source
members or objects to lock.
3 = Delete To delete an existing member/object from the production
environment when the item is promoted. The production
environment at promotion is the target environment.
9 = Recompile To recompile an existing member/object.
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
Check Out Methods
specified versioning method. In addition, for existing items, it verifies that

the value being assigned is not less than the value attached to the object in
the *PRD environment. If the version number is invalid, a message
displays informing you of the problem. If a version number is not entered,
the next available version number defaults.
For example, all objects for the current release exist in production with
version number 2.0. When they are checked out, the next version number
automatically assigned would be 2.1. However, you are now ready to
begin development on the next release—3.0. By checking out the applicable
objects and overriding the revision number (in this case to 3.0), you are
able to keep member/objects and version numbers synchronized with the
release number.
Checking Out Implementer supports checking out multiple objects that have single
source members, allowing you to use a single source member to create
Single Source multiple objects. This practice, which is seen most commonly with physical
With Multiple files, works for all source-based objects.
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 Does the comment field on the Check Out panel correspond to the
source member or object text?
Questions
This field allows you to enter a brief reason why this member/object was
checked out.
For LANSA functions that exist in multiple processes, Implementer

requires the process from the function to be checked out in the first 10
characters of the comment field.
For the J.D. Edwards special object types WORLD Writer and Fastr, you
must enter a group name in the first 10 characters of the Comment field.
123
What causes a message stating the member already exists in the to

library?
If someone placed the member into the target library without using
Implementer, this message could occur. It could also occur if the option to
remove source from the development library was set to N on a previous
promotion request, or if you deleted a lock and did not remove the
members/objects.
What happens if someone else attempts to check out the same

member/object?
If the second user is authorized for concurrent development, they are

prompted to check out a specific version for concurrent development. At
promotion, the created conflict must be resolved for both versions of the
member/object.
During check out, is the source member removed from the production
source library?
No. The source member is copied.
What’s the difference between the Workbench Check Out panel and
the traditional Check Out panel?
Functionally, these panels are the same; however, the Workbench Check
Out panel displays only if you have the one step check out method enabled
for your user profile. Both panels allow access to the same options, and
from the Workbench Check Out panel, you can access the traditional
Check Out panel to perform any functions not directly available from the
Workbench Check Out panel. The benefit to using the Workbench Check
Out panel is ease of use automation, and the fast path processing that
occurs when the check out runs.
Can one step check out be set up on a per developer basis?
Yes. The flags that control the check out method are at the user level
(defined in Work with Users). You can enable this flag based on the needs
of each developer.
Keep in mind that the one step check out method applies to checking out
from the Workbench, the Clipboard, and Work with Objects. Any other
Check Out option (including the commands and menu options) invokes
the traditional method.
Using Object Version Stamping in Check Out
Using Object Version Stamping in

Check Out
Implementer provides for object version stamping of items under change
management control. This feature is beneficial for easy auditing and the
identification of deployed objects. Object version stamping can be
implemented in association with or independent of another feature Issue
or Design Request stamping.
With object version stamping, each object, lock record, and repository
record is stamped with a version number at predetermined stages within
the development cycle. The version number scheme and development
stage in which the object is stamped (check out only, check out and
promotion, or user-defined) is determined by the versioning method.
Implementer automatically determines and increments the version
number based on the versioning method.
With issueor DR stamping, each object is stamped with the issue or design
request number that the object was checked out for. When multiple locks
exist with multiple issues or DRs, the object is stamped with the primary
number associated with the initial lock. To ensure stamping of both
existing and newly created objects, stamping automatically occurs in the
stages at which an object can be created—check out, compiling from the
Workbench, and promotion.
In addition, the description of the object is changed by updating the APAR

ID attribute with the revision number, and the PTF Number attribute with
the issue or DR number. This can be viewed by issuing the Display Object
Description (DSPOBJD) command.
NOTE
The activation and control parameters for both object version stamping and
issue or DR stamping are maintained in System Control Maintenance. For more
information, see Chapter 3 of the Implementer System Administrator Guide.
Processing 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
Versions in creating a new object, the revision number defaults to 1 or 1.0 (based on the
Check Out versioning method), unless a user-defined versioning method is defined.
You can override the next version number to be assigned by specifying a

value in the Revision number field, which displays when you invoke the
F7=Fold view of the traditional Check Out panel. To enter a revision
125
number in check out when one step check out is enabled, from the
Workbench Check Out panel, press F4=Prompt to display the traditional
Check Out panel, and press F7=Fold.
When setting the version number in check out, validation is performed to

ensure that the version number entered is valid for the specified versioning
method. In addition, it verifies that the value you are assigning is not less
than the value attached to the object in the *PRD environment. If the
version number is invalid, a message displays informing you of the
problem. If a version number is not entered, the next available version
number defaults.
Validation is performed regardless of where the check out occurs from—

the Workbench, Clipboard, Check Out menu option, Emergency Check
Out, Check Out (ICHKOUT) command, Check Out IFS (ICHKOUTIFS)
command, archive recovery, or a COOL:2E check out. When checking out
from the Check Out panel, after pressing ENTER the Revision field
displays the value that the object will have when it is checked out (if you
did not override the value). When using the ICHKOUT and ICHKOUTIFS
commands and a version number is not entered, the next available version
number is assigned and the check out proceeds without displaying the
value.
The version number displays for each object that has a version number
assigned, in the Revision field in the Workbench (F11=Display Revision)
and in Work with Objects (F10=Display Revision).
NOTE
If an object is checked out while versioning is inactive and versioning is then
activated, the object is compiled without a stamped version number.
If object versioning is inactive and a version number is specified in check out,

an error message displays to notify that versioning is not active.
Rejecting an object from a *QAC environment causes a revision number

increment.
Object versioning performs the same in Emergency Check Out. For example,
object A exists in the *QAC environment with version number 3.2. Emergency
check out is performed, and object A now exists is the *TST environment with
version number 3.3. The emergency lock for object A is promoted to production
changing the version number to 4.0. When the object in *QAC (version 3.2) is
promoted to production the version number will change from 3.2 to 5.0.
Checking Out IFS Files and Directories

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
IFS Object Within Implementer, the member/object name of an IFS file contains the
IFS file name and the object code contains the dot and extension.
Naming
Implementer converts any name longer than eight characters and any
Conventions extension longer than six characters (allowing one position for the “.”) to a
derived, short member/object name.
Additionally, depending on your IFS naming conventions the tilde

character (~) is assigned to an object name. For example:
File BOOK.NSF has an assigned object name of BOOK and an object type of
NSF; object BOOK.NTF has an assigned object name of BOOK and an object
type of NTF. When you check out file BOOK.NTF, Implementer verifies the
entire file name—BOOK.NTF—for an existing assigned short name. If it
exists, it is used. If it does not exist, Implementer attempts to assign a
pseudo object name and verifies the name BOOK; however, since an entry
for BOOK already exists it assigns the next available entry BOOK~1.NTF
(rather than BOOK.NTF).
To check out individual IFS files
1 Perform a check out by accessing the traditional Check Out panel

using any method specified earlier in this chapter.
127
2 At the top of the Check Out panel, specify From and To environments
that are set up to manage IFS objects. To specify IFS files, type the file
name in the Mbr/obj field, and type the extension in the Code field.
For example, to check out the file ITEM.EXE, type ITEM in the Mbr/obj
field and .EXE in the Code field.
NOTE
If an IFS object being checked out already exists in the target environment, a
warning message allows you to bypass the check out of the duplicate object
and leave the original object in place.
To check out subdirectories

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 This is typically only necessary for IFS objects not previously checked out
when a member/object name is not yet established. Using this method,
Using the IFS you can enter an IFS name that is used to generate the member/object
Object Name 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.
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 When checking out and promoting IFS files and directories using *.*,
keep in mind that when promoting IFS files and directories, Implementer
the Contents of does not completely replace the contents of the target environment with
an Environment the promoted IFS objects. The management of new, existing, and deleted
IFS objects is as follows:
New Objects: When an IFS object being promoted does not exist in the
target environment, that object is added to the target environment.
Existing Objects: When an IFS object being promoted already exists in

the target environment, the existing object is deleted in the target
environment and replaced with the promoted object.
Deleted Objects: When no IFS object corresponds to any that exist in

the target environment, the existing object is left in the target
environment.
TIP
To ensure that only the IFS objects contained in the promotion request are
stored in the target environment, be sure to clear the target environment of all
objects prior to initiating the promotion request.
129
Mixing Individual Files and *.* Items

If after checking out individual items you decide to check out and then
promote the entire contents of an environment using *.*, consider the
potential results of this combination.
For example, assume that you initially check out a single IFS file,
FILE1.TXT. After making changes and saving the file, you realize you
need to change more files in the environment so you check out the entire
environment’s contents to the same target environment using the *.*
method. This action overwrites the FILE1.TXT that was already in the
target environment, which may have been the result you wanted. If you
want to retain your changes, you need to check out the additional files by
specifying them as individual files.
Continuing with the example, when you later promote the environment’s
contents using the *.* method, the unchanged FILE1.TXT is moved back
into production. Additionally, if the Remove from objects field on the
Create Request panel is set to Y, file FILE1.TXT no longer exists in the
directory in the From environment since the file was also checked out
individually. The locks placed on the file during the initial check out still
exist, although the file does not. You can correct this situation by manually
deleting the lock on the file. Again, this situation can be avoided by
continuing to use the single file method for your promotion.
TIP
For most purposes, use the same check out method each time you perform a
check out to the same target environment. Continue to use this method when
creating promotion requests for the checked out IFS objects.
To use *.* to check out the entire contents of an environment

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 This task allows you to check out using the Check Out IFS (ICHKOUTIFS)
command rather than the menu interface. You can issue the ICHKOUTIFS
(ICHKOUTIFS) command from a command line within Implementer or embed the
Command
command in your own user program. You can also embed the command as
a user option in PDM, ABSTRACT, or PathFinder to further automate the
check out process.
This command is additionally used for the MKS Integrity Solution multi-
platform integration and development, to load the build numbers (the
version of objects coming from the desktop). For more information about
this feature, see the Implementer Multi-Platform Solutions Guide.
Developers must be authorized to perform check out, authorized to the

object code, and to check out of the from environment. Specifying a project
number is necessary if defined in System Control, or when using a project
path.
To use the ICHKOUTIFS command
1 Type ICHKOUTIFS at a command line and press F4=Prompt.
2 Complete the parameters as defined next, and press ENTER to issue

the command.
ICHKOUTIFS Command Parameters

From environment
Specify the environment to check out from (you must be authorized to

check out from this environment). Check out is allowed from production
(*PRD) or quality assurance (*QAC) environments.
Specify a project reference value and the default environment value

*PATH and Implementer attempts to derive the environment value from
the project path. If that is not successful (indicating the specified project
does not have an application path defined), it looks for an environment
path. If that is not successful the *PATH value is not replaced, and a
message displays stating that you must enter an environment name.
*PATH Derives the environment from the project path for the project
specified in the Project Reference parameter. A project path
must exist to use this value. If a project path does not exist, it
defaults to the environment path. If an environment path does
not exist, a message displays stating you must specify an
environment name. *PATH is the default value.
*USRPRF Derives the environment from the value defined as your
default check out from environment, in Work with Users.
Char value Specify the environment name. The environment is
determined from the environment path established for the
specified environment.
131
To environment
Specify the environment or library to check out to.
*PATH Derives the environment or library from the project path of the
project entered in the Project Reference parameter. A project
path must exist to use this value. If a project path does not
exist, it defaults to the environment path. If an environment
path does not exist, a message displays stating you must
specify an environment or library name. *PATH is the default
value.
*USRPRF Derives the value from the value defined as your default check
out to environment or library, in Work with Users.
Char value Specify a valid environment or library name.
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 Derives the default project reference defined to your user

profile, in Work with Users. This is the default value.
*DRNBR Derives the project reference from the design request
specified in the Issue or Design Request parameter.
Char value Specify a valid project reference. If the user profile does not
have an assigned default or if you are checking out to different
environments, specify the project reference.
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 Specify a valid issue or DR number.

*NONE Specifies that the member/object is not associated with an
issue or DR. This is the default value.
Lock type
Specify the type of check out and corresponding lock to place on the object.
*STD Standard check out/lock. This is the default value.

*EMERG Emergency check out/ lock.
Object
Specify the IFS name, in path\name format, of the object to check out.
Action
Specify the action to be taken in the production environment for the object.
*CHANGE The object will be changed. This is the default value.

*CREATE The object will be created.
*DELETE 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 *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 Specify the environment name.

*FRMENV Copies the object from the environment specified in the From
environment parameter.
*NONE The object is not copied. This is the default value.
“Copy from” object

Specify the name of an existing object on which to base a new object. This
object must exist on the host system—it cannot be copied from a remote
system. The object must exist in the environment specified as the Copy
from environment. The default value *OBJ copies the object specified in the
Object parameter.
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.

*YES 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 The current member replaces existing members.

*NO The current member does not replace existing members. This
is the default value.
*IGN Creates a lock using the existing object in the check out to
location.
Submit
Specify the standard OS/400 submit job parameter as required.
Job queue
Specify the job queue for the command to run in.
Name Specify the job queue name.

*PRODUCT The job queue defined as the default job queue in data area
IMJOBQ is used. This is the default value.
Library
Specify the library for the job queue.
Name Specify the library name if the library is not on the library list.
*LIBL Retrieves the library from the library list. This is the default
value.
Automatically If enabled, Implementer automatically creates new object codes when you
check out IFS files or directories with extensions that do not currently exist
Creating Object in Work with Object Codes.
Codes in Check To determine if this option is enabled, contact your System Administrator.
Out
To create an IFS object code during check out

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=Don’t add Use this option if you do not want the new object code
added. The Check Out panel will display and you can
specify a different object for check out.
2=Add Use this option to automatically add the new object
code and to continue prompting during this check out
session for any other object codes that do not exist.
Press ENTER to create the new code. The check out
proceeds normally until another non-existent object
code is found.
3=Add all future Use this option to add the new object code added and
without warning to automatically create any other non-existent object
codes during this check out session.
Support for Implementer provides support for your client/server and e-Business
applications by offering check out and promotion deployment of IFS
Multi-Platform objects using a browser interface. This browser-based integration is built
Check Out 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
135
Implementer also provides mounted drive support for IFS objects that
reside on a computer running Windows NT Server. This feature requires
additional setup considerations for environments, user profiles, and
communications. For more information, see Chapter 3 of the Implementer
System Administrator Guide.
Checking Out for Concurrent Development

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.
Checking Out for Concurrent Development
From the Implementer Menu, type 2, or type STRIM (*CHKOUT)

at the command line, and press ENTER to display the Check Out
main panel.
If the member/object is in a quality assurance environment, select

option 20 for Reject, to display the Reject Change panel.
2 On the Check Out main panel, use the location defaults from the
project path, environment path, or user profile, or specify the from
environment, to library or to environment, and project reference. You
can prompt for the project reference and environments with F4=List.
3 Use one of the following methods to identify the members/objects to

check out:
Position the cursor on a member/object field and press F4=List to

select from a list of members or objects to check out.
Enter a member/object name and code on this panel. The action

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 Will all members/objects with concurrent development have

conflicts?
Questions
Yes. The conflict is the control method that ensures you track discrepancies
between multiple versions of a member/object by a user with conflict
resolution authority.
Checking Out Related Objects
Checking Out Related 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 If you use related environments and multiple occurrences exist of a file or
data area, checking out related objects is a two-step process:
for Multiple
1 If you attempt to add multiple recurring related objects, a message
Recurring displays instructing you to press F4=List to display the Check Out
Members/ Members/Objects Selection panel.
Objects 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 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
Questions change them?
No. You do not need to check out the related objects if you do not intend to
modify them. Related objects are automatically recompiled if you specify
this on the request.
Can you display related objects on an RPG program?
No. You can only display related objects on the *FILE or *DTAARA object
types.
Checking Out With a Design Request
If you change a program, the database files it uses do not require

recompiling and therefore, are not related. However, you can display
related files for the RPG program from within PathFinder.
Why are all related objects not found when you display related
objects?
The related objects were not found in the from environment. The related
objects must exist in libraries defined for the from environment.
Why were no related objects found?
You probably did not run the Build List function after you set up the
environment definition, or the from environment definition value for
Maintain related object information is set to N (in Work with
Environments).

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 Not ready (always set to 0 when the entity is added to the list).
1 Ready to checkout (entity is ready to be checked out).
2 In development (entity is checked out and in development).
3 In QA (entity is checked out and in quality assurance for testing).
4 Completed (entity was moved into a *PRD (production) environment).
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
to re-filter. Alternatively, from the Workbench Check Out panel, press

F4 to prompt the traditional check out panel.
IMPORTANT
MKS recommends that you review the Notes in the subsequent steps for
additional important information related to checking out with a DR.
To perform traditional check out with a DR
1 Use one of the following methods to access the Check Out panel.
My Workbench option 27 or Work with Objects option 10 provides

the easiest access to the Check Out main panel for everyday tasks.
Or, use one of the following methods from either of these panels
(subsequent steps assume you have checked out from the
Workbench):
From Work with Objects, press F20=Check Out, to display the

traditional Check Out panel and select members/objects from
that panel. Use this method when you want to create a new
member/object.
From the Workbench, press F6=Check Out to display the

traditional Check Out panel.
Select the member/object with option 9 for the Clipboard, and

press F7 to display the Clipboard Processing Menu. Select option
2 for Standard Check Out to display the Check Out main panel, or
option 4 for Emergency Check Out, and press ENTER.
If you are performing an emergency check out, select the

member/object(s) with option 21 for Check out, and press
ENTER to display the Emergency Check Out main panel.
2 Specify the DR number. You can perform this step from the
Workbench or the Work with Objects panel before proceeding to the
Check Out main panel, or from the Check Out main panel. Use one of
the following options to specify the DR number:
Use the default DR number. If the Workbench or the Work with

Objects panel had a DR in the Design request number field, the
same number displays in the Design request number field in the
Check Out main panel. The associated project also displays.
To list DR numbers, position the cursor on the Design Request

Number field and press F4=List to display the Select Design
Request panel. Type option 1 next to the DR and press ENTER.
143
Type a valid DR number.
To check out entities associated with a DR, the DR must be

approved and at the correct status if you are using DR status.
To approve a DR, press F4=List to display the Select Design

Request panel. Type option 8=Approved next to the DR and press
ENTER to display the Work with Approvals panel. Type option
2=Change next to the user profile and press ENTER to display the
Change Approval panel. Type option 1 in the appropriate option
field to approve the specific phase of work.
There can be different approval types per user: 1=Development,

2=Test, and 3=Production. Upon approval from all designated
users, the status can be automatically changed. The approval/
status relationship is defined in DesignTracker System Control.
Press ENTER to process the approval and display the Work with
Approvals panel. Press F3=Cancel to display the Check Out main
panel.
The DR does not need entities pre-selected to perform check out,

since entities are added to the DR in this check out task. If entities
exist on the DR, use F10=Select entities to select the entities after
selecting the DR number.
From the Work With Entity List panel, select F6=Select Objects to
access the Member/Object Selection panel. You can select
additional members/objects to add to an entity list, view lock
details, perform related object processing, and a variety of other
options. The environment used is based on the production
environment specified on the Design Request Development
Information panel in DesignTracker, or the product and version
associated with the DR.
From the Work with Entity List panel, use F20=Create IM Project
to create an Implementer project. You can also use F8=Crt/Upd
PM Project to directly interface from the Entity List into
ProjectMaster to create and/or update a project. When you select
this function, existing projects are updated. For non-existing
projects, a project definition is created and updated (you can later
define the specific project parameters from within ProjectMaster).
A message displays to indicate what was updated, for example,
“Project DT12345 created/updated with 1 function
and 0 tasks.”
When creating a ProjectMaster project, the DR number is used for

the function name (defined as the DR number plus two blank
spaces). Tasks for a function are created using the first seven
characters of the member/object name. Activities for a task are

created based on the project creation rule.
For existing projects with project creation rules, each entity is a

function; activities are assigned based on the project creation
rules. If no entities are assigned to the DR, one function and no
tasks are created. If the Project name for PM field is blank, this
function key is disabled. For more information, see the
DesignTracker User Guide and the ProjectMaster User Guide.
3 On the Check Out main panel, specify the from environment by using
one of the following options:
Use your default from environment associated with the default

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
Specify an environment or library name for check out.
You cannot check out AS/SET definitions, LANSA objects, or

J.D. Edwards soft coding to a library.
5 The project reference defaults from the selected DR. If the project
reference has a defined application path, the from and to
environments default based on that project’s path.
NOTE
An equivalent Implementer project must exist for the DesignTracker project.
To create a project, press F10=Select entity to display the Select Entity panel.
Press F20=Create IM Project. Press F12=Cancel to display the Check Out main
panel.
145
6 Use one of the following options to identify the members/objects to

check out:
Accept the members/objects you selected in the Workbench or

the Work with Objects panel.
NOTE
If the selected items do not have the same grouping criteria (from environment
or library, to environment or library, DR, and project number), the check out
must be performed in a group. If members/objects found are not in the same
group as the first item selected, a message alerts you that you must process all
members/objects either as a single group or process them in separate groups.
Position the cursor on the member/object field and press F4=List

to select from a list of members or objects to check out. If you use
related environments, the members/objects are listed in the
sequence established for related environments. For more
information, see the Implementer System Administrator Guide.
Press F8 to display either all the members/objects in different

related environments, or the first occurrence of the member/
object that exits in the list of the related environment.
Press F10=Select Entity to display the Select Entity panel to select

specific entities that already exist on the DR.
NOTE
A DR number is required to use this option. In the Select Entity panel, type
option 1 next to the entities and press ENTER to display the Check Out panel.
To select all members/objects of a specific object code, press

F8=Select from object codes. Type option 1 next to the object code
and press ENTER to select all members/objects related to that
object code.
Press F8=Select from object codes to select from a list of

members/objects filtered by object code, and perform the
following steps:
a) Type option 5 next to the object code, and press ENTER to display
members/objects on the Member/Object Selection panel.
b) In the Member/Object Selection panel, type option 1 next to the

members/objects and press ENTER. A message displays
indicating that you have selected some members for check out.
Press ENTER again to display the Check Out panel.
The previously selected members/objects display.
Type a member/object name and code on this panel. The action

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.

following message displays:
“Press F9=Accept to check out.”
NOTE
Depending on how you access the Check Out function, you can edit the
member/object selection.
8 Press F9=Accept to process the check out and display the previous
panel. A message displays indicating that the member/object(s) was
checked out. A lock is created for each member/object indicating
work in process in the Workbench, and the member (or object for non-
source-based objects) is copied into the development library or
environment.
Common Can you select any DR to associate with the check out?
Questions 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 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
Directories directory in the From environment to the To environment. The modules
and service programs entered in the binding directory should use *LIBL
for the LIB parameter to allow access to the modules and service program
wherever they reside in your environment setup.
Using ILE Object Codes in Check Out
Modules For RPGMOD, CMOD, CLMOD, and CBLMOD the module object codes
function similarly to standard program object codes (for example, RPG,
CBL, and CLP). They use CRTxxxMOD commands and require no special
treatment.
Bound For RPGBND, CBND, CLBND, and CBLBND the bound program object
codes function similarly to standard program object codes (for example,
Programs RPG, CBL, and CLP). They use the CRTBNDxxx commands and require no
special treatment.
ILE SQL For RPGSQLI, CSQLI, and CBLSQLI the ILE SQL program object codes
function similarly to standard program object codes (for example, RPG,
Programs CBL, and CLP). They use the CRTSQLxxxI commands and require no
special treatment.
Service For RPGSRV, CSRV, CLSRV, CBLSRV, and SRVPGM t he service program
object codes use the CRTSRVPGM command. A separate code exists for
Programs each language (for example, RPG, C, CL, and CBL), and one exists for
mixed language service programs. Use the language-specific codes for
service programs that contain modules, or for service programs for only
that specific language. Use the mixed service program code (SRVPGM)
when the service program consists of modules and/or service programs of
different languages. When using these codes, prompt the creation
command and review the MODULE, EXPORT, and BNDDIR parameters
for correctness based upon the ILE technique you are using.
Update Service For SRVPGMU, the update service program object code uses the
UPDSRVPGM command. When using this code, prompt the creation
Program command and change the MODULE parameter from ENTERLIST to the
modules or service programs being updated in the service program. When
checking out using this code, you may need to change the Allow object
attribute change flag in the unfolded view of the Check Out panel to Y.
ILE Program For RPGILE, CILE, CLILE, CBLILE, and ILEPGM the ILE program object
codes use the CRTPGM command. A separate code exists for each ILE
language (for example, C, CBL, CL, or RPG). The CRTPGM command
assigns an object attribute based upon the language used for the Entry
Point Module. You should therefore, choose the object code corresponding
to that language attribute (CLE, CLLE, CBLLE, or RPGLE). Note that a
generic ILEPGM object code with no attribute is included. This is only
needed for early versions of V3R1M0 and V3R0M5, where mixed language
ILE programs did not get an attribute assigned.
149
Update ILE For ILEPGMU, the update ILE program object code uses the UPDPGM
command. When using this code, prompt the creation command and
Program 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.
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 The following chart describes how user capabilities can be divided.
Capabilities
Maintain Concurrent
Position Authorities in Check Out
DR Dev’t
Junior No No All input is predetermined

Programmer by project leader. User is
unable to add entities to the
checkout request and is
unable to change copy from
information.
Programmer in a No Yes User is unable to add

controlled shop entities to the checkout
request, but is able to
change copy from
information in a concurrent
development situation.
Project Leader Yes No User is able to create

who does not entities in DesignTracker,
code but never checks anything
out for this user. Allows an
individual programmer to
make concurrent
development decisions.
Project Leader in Yes No User is able to create

a shop that does entities in DesignTracker
not allow and add entities to the
concurrent checkout request, but is
development unable to change copy from
information, since
concurrent development is
not allowed in this shop.
Project Leader Yes Yes User is able to create

or Senior entities in DesignTracker
Programmer and add entities to the
checkout request, and can
change copy from
information in a concurrent
development situation.
LANSA Export/ During the migration of LANSA objects, you can automatically be granted
LANSA export/import rights. Because Implementer uses the export/
Import import processes for the migration of LANSA objects, insufficient LANSA
Authorities 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
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 library—a new
lock is not created. The check out is standard for a standard lock and
emergency for an emergency lock.
When rejecting member/objects from a QAC environment, by default the

source and object are retained in QA to allow for further testing (but you
cannot promote it from that environment). Although this is beneficial to
some companies, others require the ability to delete the source and object
from the QAC environment when the need to reject occurs. Therefore, an
option is provided that allows you to delete the members/objects from the
QAC environment when a check out for reject is processed.
This task assumes you are managing a member/object in a test (*QAC)

environment in the Workbench or in Work with Objects.
Removing 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 source and objects from the *QAC environment.
Objects From The default value of the Delete Member/object field is controlled by data
QA 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 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
for Rejecting environment field and the development environment or library in the To
From the Menu environment field, and press ENTER. Continue with reject task as defined
previously.
Object Name Rules
Common Can you reject a member/object from development?
Questions 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 is implemented on a per-environment and object code

basis. Using the environment and object code, each position group of the
Name Validation 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
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.
not exist, a message displays stating you must specify an
environment name. *PATH is the default value.
default check out from environment, in Work with Users.
determined from the environment path of the specified
environment.
To library
Specify the development library to check out to.
*PATH Derives the library from the project path for the project
not exist, a message displays stating you must specify a
library name. *PATH is the default value.
*USRPRF Derives the library from the value defined as your default
check out to library, in Work with Users.
Name Specify the library name.
To environment
Specify the environment to check out to, if not checking out to a library.
Check out is allowed to development (*TST) environments.
not exist, a message displays indicating that you must specify
an environment name. *PATH is the default value.
default check out to environment, in Work with Users.
determined from the environment path of the specified
environment.
157
Project reference
Specify the project associated with the member/object. This parameter is

not valid when Integrity Manager is the enabled issue tracking system.
*USRPRF Derives the default project reference defined to your user

profile, in Work with Users.
*DRNBR Derives the project reference from the design request
specified in the Issue or Design Request parameter.
Char value Specify a valid project reference. If the user profile does not
have an assigned default or if you are checking out to different
environments, specify the project reference.
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 Specify a valid issue or DR number.

*NONE Specifies that the member/object is not associated with an
issue or design request. This is the default value.
Lock type
Specify the type of check out and corresponding lock to place on the
member/object.
*STD Standard check out and lock. This is the default value.
*EMERG Emergency check out and lock.
Member/object
Specify the name of the member or object to check out.
Name Specify the member or object name.

generic* Specify a wildcard value to check out a group of similarly
named items. For example, specify RPG* to check out from
the specified environment all member/objects that begin a
name of RPG.
*ALL Specifies to check out all member/objects from the specified
environment.
Object code
Specify the Implementer object code associated with the member/object.
Name Specify the object code name.

*ALL Specifies to check out all types of the specified member/
object. For example, if you specify the member/object value
RPG* and the object code value *ALL, the result may include
various types, such as RPG, RPGILE, and RPGBND.
Action
Specify the action to take in the production environment for the member/
object.
*CHANGE To change a member/object. This is the default value.

*CREATE To create a member/object.
*DELETE To delete a member/object.
*RECOMP To recompile a member/object.
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 *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 Specify the environment name.

*FRMENV Copies the object from the environment specified in the From
environment parameter.
*NONE The member/object is not copied. This is the default value.
159
“Copy from” member/object
Specify the name of an existing member/object on which to base a new

member/object. If the object code is source-based, this entry must contain
the name of a source member. If the object code is non-source-based (it is
object-based), this entry must contain the name of an object to copy from.
This object must exist on the local system—it cannot be copied from a
remote system. The normal use of this option is to create a new member/
object with action code 2=Create.
Copy from member/object is not supported for LANSA objects.
Name Specify the member/object name.

*MBROBJ 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 Specify the source file name.

*CPYENV 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 Specify the library name.

*CPYENV Copies from the library defined for the Copy from environment
parameter. This is the default value.
To source file
Specify the name of a source file to copy a source-based object to. The
default is the source file defined for the from environment for the object
code specified.
Name Specify the source file name.

*FRMENV Copies to the source file defined for the from environment for
the object code specified.
*USRPRF Copies to the source file to your default development library, if
specified, in Work with Users. This is the default value.
*OBJCDE Copies to the source file defined for the corresponding object
code.
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 Ignores warning messages.

*NO 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 The current member replaces existing members.

*NO The current member does not replace existing members. This
is the default value.
*IGN Creates a lock using the existing object in the check out to
location.
Submit
Specify the standard OS/400 submit job parameter as required. *NO is the
default.
Job queue
Specify the job queue for the command to run in. This parameter displays
when you press F9=All parameters or specify Submit *YES.
Name Specify the job queue name.

*PRODUCT Uses the job queue defined as the default job queue in
Implementer data area IMJOBQ. This is the default value.
161
Library
Specify the library associated with the job queue. This parameter displays
when you press F9=All parameters or specify Submit *YES.
Check Out Additional options exist for using the ICHKOUT command in PDM and in
PathFinder.
Command
Variations 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 What is the difference between the check out command interfaces
and the menu interface?
Questions
The command interfaces support generic parameter values and they can be
submitted in batch. You can also use them for integration into PDM and
PathFinder. For example, if you want to check out all accounts payable
objects you could use AP* for the member/object parameter. The menu
interfaces allow you to pick from a list of members/objects and display a
list of environments to check out from. They also allow check out of related
objects.
Converting RPG/400 or RPGIII Source Code to ILE RPG/400
Converting RPG/400 or RPGIII Source Code

to ILE RPG/400
Implementer provides complete support for software development using
ILE (Integrated Language Environment). ILE support improves
performance, encourages modular programming, and provides better
control over OS/400 resources.
There are two steps to this process: check out the code to convert and
perform the conversion.
To check out the code to convert

To ensure that there is no concurrent development while you are
converting the source, you should check out the source as well.
1 Display the Check Out panel using any of the methods defined earlier
in this chapter.
2 Determine if you are creating a modular ILE program or a stand-alone

RPG4 program, and follow the appropriate instructions listed next.
Modular ILE Programs:
a) Add a Check Out entry for the program you are converting using
the RPG object code and option 3=Delete in the Action field.
b) Add RPGMOD and ILEPGM of the same name, if the RPG and
the ILE programs are kept in the same source file, using option
1=Change in the Action field. However, if the source files are
different, for example, QRPGSRC and QRPGLESRC, use option
2=Create in the Action field.
The panel should now look similar to the one illustrated next.
163
c) Press F9=Accept to complete the check out.
NOTE
If you are not authorized to the production copies of source, you can specify
the Copy From on the RPGMOD line to get a copy of the source checked out to
the development environment.
Standalone RPG Programs:
a) Add a Check Out entry for the program you are converting using
the RPG object code and option 3=Delete in the Action field.
b) Add RPGMOD of the same name, if the RPG and the ILE
programs are kept in the same source file, using option 1=Change
in the Action field. However, if the source files are different, for
example, QRPGSRC and QRPGLESRC, use option 2=Create in
the Action field.
If you are not authorized to the production copies of source, you

can specify the Copy From on the RPGBND line to get a copy of
the source checked out to the development environment.
The panel should now look similar to the one illustrated next.
Converting CRTBNDxxx ILE Programs to CRTPGM Programs
c) Press F9=Accept to complete the check out.
To perform the conversion
1 After the check out is complete, issue the following command:
CVTRPGSRC FROMFILE(FROMSRCLIB/FROMSRCFIL)
FROMMBR(FRM_MBR)
TOFILE(TOSRCLIB/TOSRCFIL)
TOMBR(TO_MBR)
2 Make the necessary additions/changes to the source code. If you are

doing modular ILE development, build the BNDDIR with the module
names to be used in the bound program.
3 Promote the RPGMOD, ILEPGM, and BNDDIR (or RPGBND for

RPG4) into production together. The ILEPGM object code uses the
BNDDIR entries to select the modules to be bound into the program
object.
Converting CRTBNDxxx ILE Programs to

CRTPGM Programs
IBM has provided an easy entry into the ILE programming model by way
of the CRTBNDxxx series of commands. The CRTBNDxxx command
generally results in an executable *PGM object, which consists of one
*MODULE object of the same name. Behind the scenes, the CRTBNDxxx
commands first create a *MODULE in QTEMP library, then creates a *PGM
165
binding the *MODULE that was created in QTEMP. Finally, the command
deletes the *MODULE. As you start to implement a more extensive ILE
architecture, you probably want to start changing some of these *PGMs
over to include multiple modules. The following steps define how to do
this.
To perform the conversion
1 Check out the program name as shown below to allow splitting the
CRTBNDxxx *PGM into a *MODULE and a CRTPGM style *PGM.
2 When promoting the RPGMOD and RPGILE locks, you need to

override the Activation Group parameter. This is because an attempt
is made to retain the attribute of the existing *PGM object that was
created using the CRTBNDxxx command. The CRTBNDxxx
commands allow and default this parameter to *DFTACTGRP, which
is not valid in the CRTPGM command. The result is a compile-fail
during the promotion if not overridden to a value allowed by
CRTPGM. You can override the creation command on the Create
Request panel by typing 1 next to the RPGILE lock, pressing ENTER,
and changing the Activation Group Parameter on the CRTPGM
command.
Checking Out Using PathFinder Information

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/ This task ensures any related objects that require changes also are changed.
object for check out through This task is useful for developers who use PathFinder.
the PathFinder user-defined
option IS. For more For example, if you make a major database change, such as changing the
information, see “Integrating length of an account or part number, you should check out the related
With Other Vendor Products”
objects as well. If you make a minor database change, you can decide not to
on page 327.
check out the related items. For example, if you change a FILE or
*DTAARA object type and the related objects do not need to be changed,
the related objects are automatically recompiled if add related objects is
specified on the promotion request.
NOTE
PathFinder’s Where Used function shows ILE *MODULE objects that use a file;
however, it does not show the ILE *PGM and *SRVPGM objects that use the file
because they contain those *MODULE objects. To ensure that level checks do
not occur in these *PGM and *SRVPGM objects, use PathFinder’s Where Used
function to list the *PGM and *SRVPGM objects containing the *MODULE
objects. Then add these objects manually to check out.
Similarly, since PathFinder does not support the cross-environment

functionality within Implementer, you must use PathFinder’s Where Used
feature to list the related objects in different environments, and manually create
the appropriate check out for these related objects.
Environment This setup is necessary if you use PathFinder as the source of information
for the Implementer Related Objects panel or actual member/object
and Library selection through PathFinder.
Setup
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 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
Check Out Implementer as the source of information. The only difference is that the
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 What are the setup requirements for using PathFinder with the
Implementer menu interface?
Questions
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
Performing Promotions
6
T 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.
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 Implementer—you cannot promote to a library.
The Create Request function is the first step of the promotion cycle. It is a
request for the indicated member/objects to be transferred to the specified
environments. You can create the promotion request through the
Workbench, Work with Objects, the Work with Entity List Members panel
in DesignTracker, the menu interface, or the command interface. In
addition, command interface options are available for PDM and
PathFinder.
To create a promotion request, the design request status and approval

must allow you to initiate promotion. In the Workbench, you can associate
multiple design requests to an existing lock on a member/object. All
associated design requests must be at the proper approval and status
before you can create the promotion request.
Create Request identifies if an item is part of concurrent development. If it

is part of concurrent development and the conflicts associated with the
concurrent development are resolved, you can place the item on the
promotion request. If the conflicts are not resolved, you can display the
conflicts, resolve the conflicts (if you have the authority), and then promote
the promotion request. This ensures that you manage concurrent
development and do not lose changes when promoting to production.
The member/objects are copied as they exist at the time the promotion
request is created, into a temporary work library. If the promotion includes
compilation, the member/objects are compiled into this temporary work
library. You can manually accomplish this step through the menu interface
or the command interface. With the menu interface, you can change the
compile attributes, authority methods, and target environments for the
promotion request.
Promotion Request Fundamentals
The next step of the promotion cycle is the move step. The move step
transfers the member/objects into the target environment or environment
group. You can manually complete this task through the menu interface or
the command interface. A user who has administrative capabilities for the
target environment usually does this task. If you select the menu interface,
you can change the attribute overrides, authority methods, and target
environments for the promotion request. If the promotion is to a
production environment, the member/objects are unlocked. If the
promotion is to a quality assurance environment, the locks are reassigned
to indicate that the member/objects exist in the new environment.
Promotion A request number is the unique four positions alphanumeric value

automatically assigned to a promotion request when it is created. It is how
Request you identify a promotion request.
Numbering The request number scheme begins with number 0001 and increments by
one for each new promotion request created until number 9999 is reached.
When this occurs, the left-most position begins with an alpha character and
the remaining positions reset to 0 (zero). Reading from right to left the
cycle continues until each position goes through the range 0–9 and A–Z.
When the number ZZZZ is reached, the request number scheme resets to
0001.
This method allows for all positions of the field to use alphanumeric
characters, and the availability of 1,200,000 request numbers before a reset
occurs.
The following table illustrates this concept.
When the request number is … The next number issued is …
0001–9999 A000
A001–A00Z A010
A010–AZZZ B000
B000–B00Z B010
B010–B0ZZ B100
B100–BZZZ C000
Creating Implementer provides for batch processing of the Create Request function.
Batch processing moves a significant amount of the validation and
Promotion processing (such as source and object copying) that occur during create
Requests in request, to the submitted job, allowing the process to run quicker. Keep in
mind, that although less interactive edit processing occurs, this typically is
Batch
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
Default Compile Implementer ensures all objects are compiled in the correct order by using
the object code sequence number. This ensures files are compiled before
Order programs, and reference files are compiled before the other files that use
them. For example, by using the object code of PFREF (which has a
creation sequence of 90, compared to PF, which has the creation sequence
of 100) to check out and promote the item, reference files are compiled
before physical files.
Promotion Implementer offers two methods of promotion—the one step method and
a traditional method. The one step method allows you to create a
Methods promotion request and promote the items using a fast path approach that
saves time and effort, thereby minimizing the steps required in the create
request function. The traditional promotion method, which is more
interactive, displays the Create Request panel and requires additional
input for processing. Both methods provide access to many of the same
features and produce the same results. However, because of time saving
advantages to the one step method, it is typically the preferred method.
The default promotion method is defined on a per user basis in Work With
Users, controlled by the Enable One Step Promotion flag. When you
initially install Implementer, the one step promotion method is enabled by
default.
Create Request To promote member/objects to production or test environments, you place

the member/objects on a promotion request. The following tasks create a
Overview promotion request.
The Create Request task must be performed when you have made changes
to member/objects and they are ready to be promoted to the next
environment. You must have authority to the Create Request function, as
well as authority to create a promotion request to the target environment
and out of the from environment.
If the member/object is associated with a design request, the design

request status (Promote to Test, Promote to Production) and approval (No,
Yes, Test, or Production) must allow the promotion. The DesignTracker
entity disposition, approvals, and design request status determine whether
Creating Requests With the One Step Promotion Method
you can perform this task. If you are authorized, the related information is
automatically updated during the move step. Locks that are associated
with a design request represent the relationship between the item and the
design request.
You can promote AS/SET definitions and traditional objects on the same
promotion request.
You can promote LANSA and traditional objects on the same promotion
request.
All valid LANSA objects on the promotion request are bundled into an
export list. LANSA objects are promoted in compiled form.
NOTE
The Create Request Comments feature is automatically enabled when you
install Implementer. When you create a promotion request and press
F9=Accept, the Comments panel displays and requires you type an explanation
for the promotion before allowing you to continue. The feature can be disabled,
while still allowing issue or design request comments to be added (when
promoted objects are associated with an issue or DR, the comments associated
with the primary issue or DR are automatically added to the promotion
request). For more information, contact your System Administrator, or see
Chapter 3 of the Implementer System Administrator Guide.
Creating Requests With the One Step

Promotion Method
This task allows you to prepare a promotion request using the one step
promotion method. The one step promotion method applies to creating
promotion requests from the Workbench (option 11=Promote), the
Clipboard, and Work with Objects (option 27=Promote). When creating
requests from any of the other Create Request options or menu and
command options (including F22=Promote in the Workbench and in Work
with Objects) the traditional Create Request panel defaults.
When creating a promotion request, the user profile record is validated to

determine the promotion method. If the one step method is enabled, the
create request function automatically creates and submits the promotion
request. If the one step promotion is not enabled, the traditional Create
Request panel displays for further input.
175
With the one step method enabled, from the Workbench you can perform
any required overrides (for example, changing special commands or object
codes), by selecting the items for promotion and pressing F4=List to
display the traditional Create Request panel. This is important to know,
because task variations described later in this chapter require processing
from the Create Request panel.
To create a one step promotion request
1 Access the Create Request function using any of the following

methods for standard one step promotions:
From the Workbench, type option 11=Promote or from Work

with Objects type option 27=Promote next to the items you want
to put on the promotion request, and press ENTER.
From the Workbench or Work with Objects panel, select the

member/objects with option 9=Add to Clipboard, and press
ENTER. Process the Clipboard with F7=Process Clipboard and
then use option 3=Promote.
2 If the Comments panel displays, type a comment and press ENTER (as
explained earlier, you may or may not be required to enter comments).
After selecting and processing the items, a promotion request is

automatically created and submitted.
In this example, the request was initiated from the Workbench. Notice
the Status column indicates ARCMNT is currently being promoted
from development to QA. A message displays at the bottom of the
Creating Requests With the Traditional Promotion Method
panel to inform you of the request number and that the move request
was submitted.
Resolving If an error is encountered during the edit check and validation process, the
Resolve Promotion Request Problems panel displays, with the appropriate
Promotion errors listed at the bottom of the panel. You can position to the error and
Request press F1 for additional message information. This panel allows you to
resolve the errors; after correcting the errors, press F9=Accept to continue
Problems processing the request.
Creating Requests With the Traditional

Promotion Method
This task allows you to prepare a promotion request using the traditional
promotion method. This method displays the Create Request panel, which
requires further information about the items being promoted. You can add
member/objects to the promotion request either by selecting them from a
list or by manually typing the name. After accepting the entries for
promotion, the promotion request is created.
The majority of promotion tasks are accessible from the Workbench and
from Work with Objects however; they are all accessible from the menu.
The following task assumes the Create Request Comments feature is

enabled. For more information, see “Create Request Overview” on
page 174.
177
To create a traditional promotion request
1 Access the Create Request function using any of the following

methods:
From My Workbench, type option 11=Promote next to the

member/object, or from Work with Objects type option
27=Promote, and press ENTER to display the Create Request
main panel.
Select the member/object with option 9=Add to Clipboard and

press ENTER. Press F7 to display the Clipboard Processing Menu,
and select option 3=Promote to display the Create Request main
panel.
From My Workbench or Work with Objects, press F22=Promote

to display the Create Request main panel and select member/
objects.
From the Implementer Menu, type 3=Create Promotion Request

and press ENTER.
On the command line, type STRIM (*CRTRQS) and press ENTER.
On the command line type ICRTRQS and press F4.
Use the PDM option CR on the appropriate member/object.
You can access Emergency Create Request using one of the following
methods:
From the My Workbench or Work with Objects, type option

22=Emergency Promote next to the member/object and press
ENTER.
From the Clipboard Processing Menu, type option 5=Emergency

Promote and press ENTER.
From the Implementer Menu, type option 22=Emergency Create

Request and press ENTER.
On the command line, type STRIM *ECRTRQS, and press ENTER.
2 Complete this panel as described in “Create Request Panel Field

Descriptions” on page 179.
3 Press ENTER to verify the entries.
4 Press F9=Accept to create the promotion request. The Create Request

Comments panel displays.
An unlimited number of comments can be added to the promotion

request, but you must add at least one. Individual member/objects
can have a brief comment assigned to them. If a comment was entered
for the member or object when it was checked out, it is added to the
promotion request. These comments are stored in the Implementer
database and are included in the Request Report (MWI0891P), which
can be used as a sign off sheet to approve the promotion.
5 Type a comment and press ENTER. A message displays to indicate

that the promotion request was created and that it is ready for the next
step of the promotion process.
Create Request Panel Field Descriptions

From Library/Environment
Use one of the following options to complete the From location field.
If displaying, use your default From environment retrieved from the

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
Type a target environment or a target environment group.
You can only promote AS/SET definitions to a specifically defined AS/

SET environment. If promoting an AS/SET definition (using an object code
that contains an ADK special characteristic), the from environment and
target environment must be defined as AS/SET environments. If it is a
target environment group, the AS/SET environment must be the primary
environment.
If promoting a LANSA object (using an object code that contains a LAN

special characteristic), the from environment and target environment must
be defined as LANSA environments. If it is a target environment group,
the LANSA environment must be the primary environment.
Project Reference
Use one of the following options to complete the Project reference field.
Use your default project or the project you selected in the Workbench
or in Work with Objects.
If you are using design requests, the associated design request project
should default. If it does not, use the appropriate project reference.
To list a project reference, position the cursor on the Project reference

field and press F4=List. Type option 1 next to the project and press
ENTER.
Type a valid project reference.
If you specify a project that has a defined application path, the from and to
environments default from the project’s path.
Member/object list
Use one of the following methods to determine member/objects to

promote:
If you initiated the create request process from the Workbench option
11=Promote, Work with Objects option 27=Promote, or option 9=Add
to Clipboard, the member/objects currently display on the Create
Request main panel.
Press F10=Select from locks to select from a list of members that are
already checked out. You can filter on the DR number to view related
locks. For further details, see “Creating Requests by Selecting From
Locks” on page 189.
Type a member/object name and code on this panel and press

ENTER. The action defaults based on the existence of the member/
object in the target environment when promoting to a production
environment.
Press F8=Member list to display the Create Request Member List

Selection panel and either choose all, changed, or specific members
(options 5 or 6 to display the Create Request Member Selection panel).
Press ENTER to redisplay the Create Request main panel. For further
details, see “Creating Requests From the Member List” on page 193.
Press F9=Object list, to display the Create Request Object Selection

panel and choose specific members. Press ENTER to redisplay the
Create Request main panel. For further details, see “Creating Requests
From the Object List” on page 192.
Developers often select from a list of locked members in the Workbench,

Work with Objects, or Create Request Select from Locks. These methods
display a list of member/objects checked out to the developer. The items
that display are determined by the defaults of the from environment and
project specified on the Create Request panel. This method can display
locks for other developers, which allows the developer creating the
promotion request to promote those member/objects if the developer has
move capabilities for the target environment.
Users in a test environment usually select from a list of existing promotion

requests to copy member/objects from. In this case, the user who created
the promotion request can select from one promotion request or bundle a
group of promotion requests that came from development to testing.
Combining multiple requests into one large request for promotion to
production allows you to create a large version or release request that
includes developers requests for one change at a time.
181
Changes can be grouped together to form a release. If using project

tracking, changes are filtered by project reference number. Additionally,
releases can be automatically rolled back with Archive Recovery.
All valid LANSA objects on the promotion request are bundled into an
export list. LANSA objects are promoted in compiled form.
If the member/object being promoted is a LANSA function that exists in

one or more than one LANSA process, you must enter the name of the
process that the function is being promoted from in the comment field. If
you do not enter the process name, the function is selected from the first
process.
If the member/object being promoted has one of the special object codes
denoting a LANSA or AS/SET object, the from environment should have a
special environment denoting LANSA or ASSET.
If you are promoting an AS/SET display program with the associated help,
you have to promote two objects with the same name. One of the objects
must use the object code with the special characteristic ADKDSP for the
display program. The other object must use a separate object code created
with the special characteristic ADKHLP to promote the help text associated
with the display program.
If you manage AS/SET generated RPG programs having X FILE overrides,

use an object code that has the special characteristic RPGADK, in order to
compile these programs during promotion. Implementer automatically
analyzes these programs and performs the appropriate X FILE overrides
before compilation. If the original file name contains 10 characters, thus not
allowing an X at the end of the X FILE name, the overridden file cannot be
identified. MKS suggests using file names containing less than 10
characters.
Action
Specify the action that you want to take with the member/objects included
in the request.
If the action is not specified, the value defaults to 1=Change (the most
frequently used action). If you are replacing an existing program with a
new program, use option 2=Delete to remove the existing program.
1 = Change Changes the existing member/object.

2 = Create Creates a new member/object.
3 = Delete Deletes the existing member/object from the target
environment.
9 = Recomp Recompiles the source member currently in the target
environment. Source in the From location is not used. This is
commonly done to avoid level checks in programs that do
not require any logic changes when a file is changed. It is
allowed for source-based objects only.
Optimizing Implementer provides a feature that allows you to optimize the promotion
of DDS-based physical files created with the Create Physical File (CRTPF)
Physical File command.
Promotions
For information on enabling This feature is globally defined in System Control Maintenance. When
optimized promotions, see enabled, all physical file promotions are automatically optimized, although
Chapter 3 of the Implementer
users with Move Request authority (defined in Work with Users) have the
ability to change the optimize status on a per request basis—this is allowed
only when creating the request. Changing the optimize status is supported
when creating a request using any described method in this chapter; for
example, from the menu option or using the ICRTRQS command.
For more information on With optimizing, Implementer uses the Change Physical File (CHGPF)
promoting DDS files and SQL command over the target file/library in production when promoting DDS-
tables, see “Database
based physical files. The processing steps of an optimized PF promotion
Management” on page 308.
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.
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 Consider the following benchmark example of a physical file with 127,000
a rather small database file, records and 11 logical files:
you can expect a larger file
with more records to have
even greater results. Optimized... Not optimized...
the promotion completed in the promotion completed in
2 minutes 15 seconds 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
command with the Add Physical File Trigger (ADDPFTRG) command or

the Remove Physical File Trigger (RMVPFTRG) command to run After-
Move Ok, either on a per request basis or at the environment level
depending on the number of triggers. For example, if you create a new
physical file, Implementer will only add the triggers and constraints when
the file is promoted if instructed to do so in a special command.
General Precautions
When using optimized PF promotions, note that:
When the attribute of a field changes, for example, from 8A to 10A or

from 10A to 8A, any logical files that specify to include the field in the
view must be explicitly added to the request to ensure they reflect the
change.
The CHGPF command does not support certain field attribute

changes, for example, changing a field from 10A to 10N. If you
encounter this problem due to a failed request, you can delete the
original request and create a new one. Before promoting the file on the
new request, change the optimize status to N. Without optimizing, the
existing data is retained using the Copy File (CPYF) command with
the record format field mapping options *MAP and *DROP.
Changing the Optimize Status on a Request

Your user profile must have Move Request authority (defined in Work
with Users) to change the optimize status when creating a promotion
request. Changing the optimize status is supported when creating a
request using any described method in this chapter; for example, from the
menu option, Workbench, or using the ICRTRQS command.
The following steps assume the PF is checked out and selected for
promotion on the Create Request panel.
To change the optimize status for a promotion

1 From the Create Request panel, press F18=Overrides. The Create
Request Overrides panel displays.
185
2 In the Optimize PF’s promotion field, type Y to optimize the

promotion, or type N to create a promotion without optimizing.
3 Press ENTER. The Create Request panel redisplays.
4 Continue with creating the request as required.
If a request fails, the existing files remain in production as they were

before the promotion. After correcting any problems, you can re-
submit the request.
Overriding Job You can override the defaults established in Work with Environments,
Promotion Scheduling for the following fields:
Submission
Date range
Defaults
Time range
Job queue
Library
Hold on job queue
To override the job submission defaults
This task assumes you are in the Create Request Overrides panel.
1 From the Create Request panel, press F18=Overrides. The Create

Request Overrides panel displays.
2 Verify the Submit request field is Y, and press F18=Submission

Overrides to display the Job Schedule Overrides panel.
3 Specify the overrides. Type the Request Submission defaults for the
compile stage of the promotion process. The Time range fields must be
entered in HH:MM:SS format.
4 Press ENTER to redisplay the Create Request Overrides panel.
5 Press F12=Cancel to redisplay the Create Request main panel.
Changing Job Job queue manipulation can affect the successful completion of the
CMPCHK job, because if you submit the CMPCHK job before all compiles
Queues During complete, the compile step fails. To avoid this problem, place the
the Compile 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
Step 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 The commands used to compile objects can be modified during promotion
request creation by selecting a member/object with option 1=Override
Compile creation attribute from the Create Request panel. Only the parameters
Commands designated as modifiable in Work with Objects Codes can be overridden.
This feature is particularly useful for new member/objects. Existing
member/objects are compiled using a combination of overrides and the
existing characteristics of the object.
Using this method to change the compile command parameters for an

object code only has an effect on the current promotion request.
Compile Command Parameters

At compile time, Implementer uses a combination of existing object
characteristics, system command defaults, objects code defaults, and
overrides to determine how to compile objects.
The following logic is used for each parameter on the creation command:
The command parameter is verified to check if it was overridden

when the promotion request was created. If it was overridden, that
value is used.
If the parameter was not overridden (or there is no override at all) and
the parameter is specified in the object code, that value is used.
187
The target object is verified to check if it already exists.
If there is no existing target object, the system default is used.
If the target object already exists, it is examined to determine how it

was originally compiled. This feature, which the OS/400 standard
compilers and creation commands do not perform, ensures objects are
correctly created. For example, it is often important to retain
customized printer file characteristics. These characteristics could
include retain restore display and defer write characteristics for
display files; and determine whether the programs should use user
rights or owner rights for execution.
You may want to disallow users to override command parameters when

they create the promotion request. For example, you may want to disallow
changes to the USRPRF parameter for programs. It may be considered a
security risk to allow a developer to change a parameter that is associated
with adopting another user’s rights during program execution. The object
codes for programs with the USRPRF parameter are initially delivered
with the Allow change field set to N.
For existing objects, if you want to ensure the existing system default value
is used for a parameter but do not want to override the value, you can
specify the parameter with no value. For example, if you want to default
the Restore Display (RSTDSP) parameter for display files, qualify it as
RSTDSP() when you define the object code in Work with Object Codes.
You can promote to a remote environment that has a previous release of

the operating system. Implementer checks Network Configuration for the
release level of the target system. This value is used for the Target Release
(TGTRLS) parameter for commands such as Create RPG Program
(CRTRPGPGM) and Create COBOL Program (CRTCBLPGM). This helps
to ensure that these objects can be successfully distributed to the remote
system.
Compile commands must be defined with the parameter ALLOW (*YES)

on the command definition. This allows the command to run with the
QCMDEXC program.
For more information about the compile step, see “Compiling” on

page 220.
Common Are the objects moved at this point?
Questions No. Copies of both member/objects that will not be recompiled are placed
into a temporary work library. The member/objects remain in the from
environment libraries.
Creating Requests by Selecting From Locks
Can developers be restricted from option 2 (Toggle *GRANT/*KEEP

authority on the Create Request panel)?
Yes. You can restrict this option for specific environments.
Can developers be restricted from option 1 (Override Creation

Command Attributes on the Create Request panel)?
No, you cannot restrict this option as a whole. However, you can restrict
individual keywords on the creation command. To effectively prevent
changes to the creation command, you can optionally restrict all keywords.
How does Implementer handle a join logical file built over multiple
physical files with the same name?
Implementer does not support qualified library names in the logical file
source. MKS suggests that you use an open query file rather than a logical
file to accomplish this function.
Can the one step promotions be setup on a per developer basis?
Yes. The flags that control this feature are at the user level (defined in Work
with Users). You can enable this flag based on the need of each developer.
Keep in mind that the one step promotion method applies to creating
requests from the Workbench, the Clipboard, and Work with Objects. All
other Create Request options, including the commands and menu options,
process the traditional method.

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 The Select from Locks function is powerful as both a selection method and
for inquiry. With Select from Locks you can determine:
Selecting From
current activity for a specific user
Locks
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.
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 Why don’t you see everything checked out to the environment you are
checking in from?
Questions
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 When using F7=Object List or F8=Member List, why don’t you see any
member/objects to select?
Questions
Either you did not check out the member/objects in Implementer, or you
did not run the Build List function for the from environment.
Creating Requests From the Member List
Creating Requests From the Member 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
code—from a list of members in the from environment. When changing,
compiling, and moving source, this function provides ease of selection
without having to remember the exact name of source objects.
This task is only available when you promote from an environment (not
from a library). It is usually performed by the developer; however, it can
also be performed by the environment administrator who has move
capabilities.
To perform this task, you must have run the Build List function, and you
must have authority to the Create Request function and the authority to
create a promotion request for the target environment.
To create requests using the member list
This task assumes you are in the Create Request main panel.
1 Press F8=Member list to select from a list of members and to display

the Create Request Member List Selection panel.
2 In the Create Request Member List Selection panel, type option 1 next
to All members and press ENTER to redisplay the Create Request
main panel.
3 Press F9=Accept to process the promotion request.
4 Enter a comment on the Create Request Comment panel and press

ENTER.
Task Variations In the Create Request, Member List Selection panel, do one of the following
for Step 2:
Type option 2 next to the changed members in the Member List

Selection panel and press ENTER.
Display all members as follows:
a) Type option 5 in the option field in the Member List Selection

panel and press ENTER to display the Member Selection panel.
b) Type option 1 next to specific members and press ENTER from

the Member Selection panel. The Member List Selection panel
redisplays. Press ENTER again to redisplay the Create Request
panel.
193
Members appear as changed if they were changed outside of

Implementer and the Build List was run to detect this condition. These
steps are primarily useful when using a development tool that
updates many members without listing the changed members. Follow
these steps:
a) From Work with Environments, select option 30 to run the Build

List for the environment.
b) Use the development tool that updates source and objects.
c) Rerun option 30, Build List to record the changes for the
environment since the last build.
d) Create a promotion request to another environment (using one of

the previously defined methods) and select only changed
member/objects.
To select only changed objects, from the Create Request panel

press F7=Object List to display Create Request Object
Selection panel and press F15=Changed only.
To select only changed members, from the Create Request

panel press F8=Member List to display the Create Request
Member List Selection panel and type option 2=Select
Changed Members for each applicable code.
Display the Changed members as follows:
a) Type option 6 in the option field in the Member List Selection

panel and press ENTER to display the Member Selection panel.
b) Type option 1 next to specific members and press ENTER to

redisplay the Member List Selection panel. Press ENTER again to
redisplay the Create Request panel.
Press F9=Accept to display the Create Request Comments panel.

Complete the comment and press ENTER to accept.
Common Why doesn’t the object exist in the target environment when action
type is 1 for change?
Questions
This occurs when you use the member’s list to select member/objects. You
should change the actual type to 2 for Create.
Creating a Request by Copying a Request
Creating a Request by Copying a 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 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?
Questions
Yes. Use option 5 on the Create Request, Request to Duplicate panel, or use
Request Inquiry before you create the promotion request.
What happens to the objects in the request that were copied? What is
their status? Are they still locked?
The original promotion request and objects remain unchanged. The new
promotion request initiates a new series of promotion status codes related
to the new request. If the original request was to a production environment
and completed, the locks were removed at the time of the original
promotion. If the original request was not to a production environment,
the locks were updated by this promotion request.
Creating Requests With the ICRTRQS

Command
Once you have changed member/objects and you are ready to promote
them to the next level (either to full production or to a test environment),
the developer or project leader can use the Create Request (ICRTRQS)
command. This command allows you to create a promotion request from
the command line, or embed the command in a program. It is useful, along
with its PDM (CO) and PathFinder (IR) options, when you want to
promote a few known member/objects. The menu interface is more
helpful when there are many member/objects or you do not know the
member/objects by name.
When using this command for SQL objects, ensure that you use SQL object
codes (with the SQL special characteristic) only for SQL objects. For
example, you cannot use the SQLT object code (for SQL Tables) to promote
a DDS-based physical file.
In addition, you cannot mix SQL and DDS files—for example, you cannot
promote an SQL-based logical file over a DDS-based physical file (and vice
versa).
The Create Request (ICRTRQS) command does not support AS/SET

definitions.
as the authority to create a promotion request for the target environment.
Creating Requests With the ICRTRQS Command
To use the ICRTRQS command
1 At a command line type ICRTRQS and press F4.
2 Complete the following required fields:
Member/Object
Object code
Comments
The other fields default based on your user profile defaults.
For the From environment and To environment parameters, use the

*PATH default or type the environment names.
The project reference can default from the user profile. If the user
profile is not assigned defaults for these values or if you are checking
out to different environments (or neither), type the project reference.
If you specify a project reference value along with the *PATH default
environment value, Implementer first attempts to derive the
environment value from the project path. If it is not successful
(indicating the specified project does not have a defined application
path), it looks for an environment path. If that is not successful the
*PATH value is not replaced and a message displays stating you must
enter an environment name.
If the Optimize PF Promotions feature is enabled and your user profile

has move authority, you can override the optimize the PF promotion
default.
NOTE
If you need to request more than one member/object, type + in the field next to
the member/object list and press ENTER to display the Specify More Values
for the Member/Object panel. This allows you to insert numerous member/
objects.
3 Press ENTER to accept the promotion request.
197
Creating Requests With the ICRTRQS

Command PDM Option
When you make changes to member/objects and are ready to promote
them to the next level (production or a test environment in the developer’s
preferred PDM environment), the Create Request (ICRTRQS) command is
available as the PDM option CR. This is a helpful feature because it uses
Implementer change management control within a PDM environment.
The PDM option uses the ICRTRQS command, which is accessible from
within PDM, and avoids disrupting a developers normal development
work. Because the PDM option calls the ICRTRQS command, it does not
have the full functionality of the Create Request menu option. It is helpful
to define the target environment definition to have the Auto Submit field
in the Create Request defaults set to Y (yes) and the Through Step field set
to 2 to (compile). For more information, see “Setting Up User-Defined
PDM Options” in Chapter 3 of the Implementer System Administrator Guide.
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 Do you need to set up the CR option?
Questions Yes. It is necessary to set the option file in PDM (F18=Change Defaults) to
IMPDMOPT, the library to MKSIM, and the member IMPDMOPT. To view
the options, press F16=User options. Alternatively, this option can be
added to any options file.
Selecting Additional Target Environments
Why is the CR option not in the PDM options library?
You need to insert them or change the file, library, and member defaults.
To add them to the regular PDM library, write them in manually; do not
copy them with the CPYF command. The IBM file is a sorted file and not a
keyed access file. The options are not in the proper order.
Can you add more than one member/object on a promotion request

created with ICRTRQS?
Yes. To add multiple members to the request, specify *CLPBRD to add all
previously selected members to the request.
Selecting Additional Target 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
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 Are all listed environments available for promotion?
Questions 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.
Implementer allows you to review impacted objects and select any or all of
them for checkout. In addition, any impacted objects that were not checked
out but still require compiling are automatically added to the promotion
request, compiled, and promoted when their associated objects are
promoted.
During promotion, Implementer’s advanced related object support

determines related objects that exist within the target environments
specified on the request. You can include related objects on the request to
ensure that all programs that use a particular display file, physical file, or
logical file are automatically recompiled. The related objects are added to
the promotion request with an action of 9 for Recompile. Logical files that
are not manually added to a promotion request are automatically
recompiled if the physical files they are built over are on the request (these
are referred to in Implementer as implicit logical files). You can optionally
not include related programs; this requires the Add Related Objects field in
the environment definition be set to N.
Impact analysis supports both Implementer and Hawkeye as an

environment’s source of related object information.
You can optionally configure Implementer to determine related objects

that exist outside of the target envrionments and automatically generate a
promotion request for any related objects that exist in environments not
included in the original request. This feature is explained next.
NOTE
When using Hawkeye, Implementer only supports cross-environment related
objects when defined within the primary Hawkeye database library. In
addition, Hawkeye does not support cross environment related object
processing for objects that exist in *QAC environments.
Related You can optionally configure Implementer to automatically generate

promotion requests for related objects that exist in environments not
Request included in the original request.
Processing The primary request is the original promotion request that you create; it
contains the items for which related objects are searched. Any subsequent
request that is generated from the primary request due to cross-
environment related objects is called a secondary request. Secondary
requests are related to the primary request. Secondary requests are created
only by Implementer, when related objects are found in one or more
environments not included on the primary request. A user cannot create a
secondary request.
201
Implementer issues the ICRTRQS command to create a secondary request

for each different environment a related object is found in. If a project is
specified, it is copied from the primary request to all secondary requests. A
secondary request is created with the default value of Add Related = Y.
Once the primary request is complete and all objects are moved to the
target environment, Implementer submits any secondary requests that
need to be generated. A single primary request can generate one to many
secondary requests, depending on the number of environments a related
object is found in.
For example, the following promotion request scenario causes three

occurrences of the ICRTRQS command…
Initial Request Related Objects

Cross-Environment Related Objects
targets Environment 4 in Environment 4
Object 1 obj A and B obj A - Env 1 obj B - Env 2 obj C - Env 2
Object 2 obj D obj D - Env 1 obj D - Env 2 obj C - Env 2
Object 3 obj A and B obj A - Env 3 obj B - Env 3 obj C - Env 3
Object 4 obj A obj A - Env 1 obj A - Env 2 obj A - Env 3
… And results in the creation of three secondary requests.
Target
Request Type Related Objects
Environment
Secondary Request #2 Env 1 obj A obj D - -
Secondary Request #3 Env 2 obj B obj C obj D obj A
Secondary Request #4 Env 3 obj A obj B obj C -
Primary Request #1 Env 4 obj A obj B obj D -
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.
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

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

10 If the environment is part of a group on any environment path, the

group is used.
11 If the environment is part of any group, the group is used.
12 Use the environment.
IMPORTANT
In previous releases of Implementer, an object code environment override
method was used to handle cross-environment related object processing. While
this method is still supported, be aware of the following:
If you currently use the object code environment override method and decide
to de-activate or delete any associated object codes (to use the automated
method), you will lose the history of the relationship between the old and the
new object definitions, since the object will change with the new method.
If the automated method is enabled and you continue to use the object code
environment override method, the secondary request generation process will
not occur.
Displaying and Selecting Related Requests

When displaying and selecting related objects, Implementer displays all
related objects in all libraries. However, if Implementer determines that a
related object is in a library not defined to an Implementer environment, a
message displays to inform you.
203
In Request Inquiry, you can determine if a request has any related requests
by the Related Requests column. When related requests do not exist, the
value is blank. When related requests do exist, either the value “Primary”
or “Secondary” displays to identify the related request type. Use option
15=Related Requests to display a list of the related requests. Alternatively,
from Request Inquiry select the request with option 8=Request info and
press ENTER. Press F15=Related requests. You can display the related
request details with option 5=Display.
This feature is also available from various other Implementer panels:

Compile Requests, Move Requests, Request Maintenance, Request
Selection, Work with Remote Requests, and Archive Recovery.
Deleting Related Requests

When you delete a primary request, Implementer also deletes any
secondary requests generated for cross-environment related objects.
Secondary requests are only deleted when the primary request is deleted.
However, a caveat to this rule is explained with the following example: A
primary request is at a status of Completed with a secondary request at a
status of Move-fail. If you select to delete all requests at an OPEN status
(expecting to delete both of these requests) the secondary request will not
be deleted because the primary request is not at the OPEN status specified.
Related Requests in Archive Recovery

Archive recovery supports the rollback of generated secondary requests.
From the Archive Recovery panel, you can determine if a request has any
secondary requests by the value in the Related Requests column. When
related requests do not exist, the value is blank indicating a standard
release. When a related request does exist, the value “Primary” or
“Secondary” displays to identify the release type.
Use option 1=Select to rollback a primary or secondary request. Use option

15=Related Requests to display a list of the related request detail (although
recovery options are not available from the Related Request panel).
NOTE
The cross-environment related object promotion feature is controlled by a
global value defined in System Control Maintenance. This gives you the ability
to enable and disable the feature as needed. By default, the feature is disabled.
You can also define whether Implementer causes a primary request to end (in
Comp-fail) or continue, if there is an error while generating any secondary
requests for cross-environment related objects. This feature also requires the
Add Related Objects field in the environment definition be set to Y.
Overriding Create Request Defaults

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 You have the option to customize how Implementer automatically handles
objects and source in a local *TST or *QAC environment, upon successful
Objects and completion of a promotion request from the environment.
Source in This feature is enabled by defaults at the environment level, with
Promotion validation to environment object code overrides as needed.
205
The valid options for removing objects and source are:
1=always. Automatically deletes objects and source.
2=never. Retains the objects and source.
3=per object code. Specifies to proceed on a per-object code basis, by

validating to the environment’s object code overrides. If the override
value is set to Y, the object and/or source is deleted. If the override
value is set to N, the object and/or source is retained.
If a user attempts to change the default values for the remove flags on the
promotion request, the user profile Allow Override fields are validated for
authority to perform the override.
When promoting from a library the request level flags are set to the value
defined for the user profile creating the request. When the user profile flags
are set to N, the request level flags default to 2=never. When the user
profile flags are set to Y, the request level flags default to 1=always. This
can be overridden provided the user has proper authority. The value 3=per
object code is not allowed when promoting from a library.
For information on setting up When promoting from a *TST or *QAC environment, the request level
this feature, see the flags default to the value defined for the from environment. (This feature
Implementer System
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:
Field Description
Separate model For COOL:2E environments only. Specify whether to

copy step execute the Copy Model Objects command separate
from the Submit Model Create function. Specify Y to
execute the model copy and compile in separate steps:
specify N to execute in one step.
Remove obj in from Specify whether to automatically delete the objects in the
lib/env from environment upon successful completion of the
promotion request. Specify 1=always, 2=never, or 3=per
obj code.
Remove src in from Specify whether to automatically delete the source in the
lib/env from environment upon successful completion of the
promotion request. Specify 1=always, 2=never, or 3=per
obj code.
Add related objects For traditional environments only. Specify whether to add
to request all related objects to the request before promoting the
request. Adding related objects to a request ensures you
do not promote an object that would cause a level check
in this environment.
Submit request Specify whether to automatically submit the promotion of

this request. If you specify Y, a job to promote the
promotion request is submitted when you accept the
promotion request. If you specify N, you must promote
the promotion request using the menu options Compile
Request, Move Request, and Move Requests by System/
Environment.
Through step Specify how much of the promotion is performed when

you auto-submit from Create Request. Each subsequent
promotion includes the prior step (in other words, compile
includes export (if a LANSA environment), distribute
includes export (if a LANSA environment), and compile
and move includes export (if a LANSA environment),
compile, and distribute).
1=Export (if a LANSA environment)
2=Compile (only valid for Compile Required = Y)
3=Distribute (only valid for remote environments)
4=Move (no special edits)
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 Can you stop other users from changing overrides?
Questions 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.
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 Changes an existing member/object. This is the default

value if the object already exists.
2 = Create Creates a new member/object. This is the default value
if the object does not exist in the From production
environment.
3 = Delete Deletes an existing member/object from the target
environment. Use this to remove an existing program
when you are replacing it with a new one.
9 = Recomp Recompiles the source member currently in the target
environment. Source in the from location is not used.
This is commonly done to avoid level checks in
programs that do not require any logic changes when a
file is changed. This is allowed only for source-based
objects.
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 Copies object attributes from the target environment.

environment If no object attributes are found in the target
environment, it looks to the next target environment
in the application path (project path or environment
path, whichever is used).
2 = From Copies object attributes in the from environment. If
environment 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).
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.
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, Expt-
Pend, or Expt-Fail.
To maintain promotion requests
1 Type menu option 13 or STRIM (*RQSMNT) at the command line and

press ENTER.
2 In the Request Maintenance panel, type a promotion request number,

or press F4 to list the existing promotion requests.
If you want to choose from the promotion request list in the Request
Maintenance Request Selection panel, type option 2 next to the
promotion request you want to select, and press ENTER.
3 In the third Request Maintenance detail panel, perform the necessary

maintenance and press ENTER to verify entries.
4 Press F9=Update to accept the changes.
5 In the Request Maintenance comments panel, type additional

comments to describe the maintenance completed, and press ENTER
to accept the promotion request. The Request Maintenance Request
Selection panel redisplays.
211
Promoting IFS Files and 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 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.
Support for Implementer provides support for your client/server and e-Business
applications by offering check out and promotion deployment of IFS
Browser-based objects, using a browser interface. This browser-based integration is built
Promotions 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
Options for In addition to promoting IFS objects as that of any traditional OS/400
object (for example, using option 11=Promote from the Workbench), you
Promoting IFS can also promote IFS objects using any of the following methods:
Objects listing individual IFS files
listing individual subdirectories
using *.* to specify an entire environment
To promote individual files
1 Create a promotion request using any method specified in this

chapter.
2 At the top of the Create Request panel, specify From and To

environments that are set up to manage IFS objects.
3 To specify the IFS files for promotion, type the IFS file name in the
Mbr/obj field, and type the extension in the Code field.
For example, to promote the file ITEM.EXE, type ITEM in the Mbr/obj
field and .EXE in the Code field.
To promote subdirectories
1 Create a promotion request using any method specified in this

chapter.

3 To specify the IFS subdirectories for promotion, type the IFS directory
name in the Mbr/obj field and type a backslash (\) in the Code field.
For example, to promote the subdirectory SUBDIR2, type SUBDIR2 in

the Mbr/obj field and \ in the Code field.
Although not a common practice, you can have subdirectories with

extensions. In this case, specify a backslash (\) followed by the
extension in the Code field. For example, to promote the subdirectory
SUBDIR2.DIR, type SUBDIR2 in the Mbr/obj field and type \.DIR in
the Code field.
213
To promote the entire contents of an environment (*.*)
1 Create a promotion request using any method specified earlier in this

chapter.

3 To specify the entire contents of the environment for promotion, type

*.* in the Mbr/obj field and type a backslash (\) in the Code field.
Considerations When checking out and promoting IFS files and directories using *.*,
keep the following points in mind.
When Using *.*
for Promotion IFS Object Management
When promoting IFS files and directories, Implementer does not
completely replace the current content of the target environment with the
promoted IFS objects. The copy of new, existing, and deleted IFS objects is
as follows:
New Objects
When an IFS object being promoted does not exist in the target
environment, that object is added to the target environment.
Existing Objects
When an IFS object being promoted already exists in the target

environment, the existing object is deleted in the target environment
and replaced with the promoted object.
Deleted Objects
When no IFS object corresponds to one that exists in the target

environment, the existing object is left in the target environment.
TIP
If you need to ensure that only the IFS objects contained in the promotion
request are stored in the target environment, be sure to clear the target
environment of all objects prior to initiating the promotion request.
Mixing Individual File and *.* Promotions

In the event that, after checking out individual items, you decide to check
out and then promote the entire contents of the environment using *.*,
you must first consider the potential results of this mix.
For example, assume that you initially check out a single IFS file,
FILE1.PRG. After making changes and saving the file, you realize you
need to change more files in the environment, so you check out the entire
environment’s contents to the same target environment using the *.*
method. This action overwrites the FILE1.PRG that was already in the
target environment, which may have been the result you wanted. If you
wanted to retain your changes, however, you would need to check out the
additional files by specifying them as individual files.
Continuing with the example, when you later promote the environment’s
contents using the *.* method, the unchanged FILE1.PRG is moved back
into production. Additionally, if the Remove from objects field on the
Create Request panel is set to Y, file FILE1.PRG no longer exists in the
directory in the From environment since this file was also checked out
individually. The locks placed on the file during the initial check out still
exist, although the file does not. You can correct this situation by manually
deleting the lock on the file. Again, this situation can be avoided by
continuing to use the single file method for your promotion.
TIP
For most purposes, use the same check out method each time you perform a
check out to the same target environment. Then, continue to use this method
when creating promotion requests for the checked out IFS objects.
Automatically 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
Creating Object automatically create the new object code.
Codes in Create
Request 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 = Don’t add Use this option if you do not want to add the new object
code. The Check Out panel redisplays. Specify a
different object code for create request.
2 = Add Use this option to automatically add the object code and
continue to be prompted during this create request
session if any other object codes do not exist. When you
press ENTER, the new code is created, and the request
proceeds normally until another non-existent object code
is found.
3 = Add all Use this option to automatically add the object code and
future without to continue adding any other non-existent object codes
warning 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.
Upgrading a To upgrade a directory, you have two options when promoting directories:
Directory You can update applicable files in the target directory with those
contained in the promotion request. Additionally, new files on the
promotion request that do not currently exist in the target directory
are added. Any files that are not part of the promotion request but that
already exist in the directory are not deleted from the target directory.
This option is useful any time you do not want to clear the directory
before the move—for example, if you are creating a promotion request
to update or add new form letters to a directory. This option is the
default and requires no additional action.
You can issue a special command at the time of promotion to replace

the entire contents of the target directory with the files in the
promotion request. This option is useful when you want only the files
in the promotion request to be in the target directory—for example,
when you are totally replacing one version of an application with a
new one.
Special Command Considerations

You must have authority to the target directory being removed.
The special command option deletes the target directory and removes the
directory contents prior to the move step of the promotion. When the
deletion is complete, the move step recreates the target directory and
moves the objects in the promotion request to the newly created target
directory. The result is that only those objects in the promotion request
reside in the target directory.
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 Type 4 to issue the command as part of the Move step.
When to do Type 1 to issue the command before the Move step.
Sequence Type a valid sequence number.
number
Command RMVDIR DIR(full_target_path) RMVLNK(*YES)
(Where full_target_path is the full path of the target
directory.) To remove the contents of the directory you
must define the RMVLNK parameter as *YES.
4 Press ENTER to add the command. Press F12 twice to redisplay the
Create Request panel.
217
Java Java optimization is available for all JAR files (.jar), class files (.class),
and compressed file archives (.zip) processed through Implementer. This
Optimization 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.
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, define to and from environments for check out
see the Implementer System
Administrator Guide. 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 Comp-
Pend.
To submit a promotion request for compile
1 Type menu option 4 or STRIM (*CMPRQS) at the command line and

press ENTER. You can also access this function with F14=Compile
requests, in the Workbench and the Work with Objects panel.
2 In the Compile Request selection panel, type 1 in the option field, and
press ENTER to submit the compile.
3 When a message displays indicating the promotion request was

submitted, press F3=Exit to redisplay the menu.
Compiling
Task Variations
This section describes task variations and additional processing you can
perform when using the Compile Request function.
Changing and Submitting the Compile Request
1 Type menu option 4 or STRIM (*CMPRQS) at the command line and

press ENTER. You can also access this function with F14=Compile
requests in the Workbench and the Work with Objects panel.
2 In the Compile Requests selection panel, type option 2 next to the

promotion request and press ENTER to change the promotion request.
3 In the Change Compile Request panel, change one of the following:
Object attributes (option 1)
Object authority (option 2)
Target environments (F14=Target environments)
NOTE
If you want to change the overrides for the compile step of promotion
scheduling, press F18=Submission overrides to display the Job Schedule
Overrides panel. This can be done from either the Compile Requests selection
panel or the Change Compile Request panel. Fill in the changes or accept the
defaults and press ENTER to redisplay the previous panel. Note that Time
range fields must be entered in HH:MM:SS format.
4 Press F9=Submit to submit the promotion request and redisplay the

Compile Requests selection panel.
5 When the message displays that the promotion request was

submitted, press F3=Exit to redisplay the menu.
Submitting Overrides
You can override the defaults established in Work with Environments for
promotion scheduling.
This task assumes you are in either the Compile Request selection panel or
the Change Compile Request panel. Both the selection and detail panels
allow you to override the promotion scheduling defaults.
To override the submission defaults
1 Press F18=Submission overrides to display the Job Schedule Overrides

panel.
221
2 Type the appropriate Request Submission overrides for the compile

stage of the promotion process. Note that Time range fields must be
3 Press ENTER to redisplay either the Compile Request selection panel

or the Change Compile Request panel.
Staged Compilation is done into a work library. First, this ensures that for large
promotion requests, the target libraries (that could be production libraries)
Compiles 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 Implementer uses the compile library list defined for the target
environment. This feature prevents level checks in the production library
List due to the wrong library list used for compilation.
In addition to the libraries on the environment library list, Implementer

adds two work libraries to the library list ahead (at the front) of the other
libraries—the Request Objects Library and Request Source Library. This
ensures programs are compiled against the correct display files, and that
the correct RPG copy blocks or COBOL copy blocks are used.
NOTE
A common cause of compile problems is incorrectly defining the library list for
compilation when creating a new environment.
Compiling
Third-Party Third-party compile procedures, such as those used by commercial

application software products, are supported by changing the
Compile Implementer object code to use those vendors’ commands instead of the
Procedures standard compile commands, such as Create RPG (CRTRPGPGM)
program. When using third-party compile procedures, make sure that the
library, compile command, and programs are on the environment library
list.
In addition, ensure the third-party command you use does not submit
another job to perform the compile, as the command issued here must
actually perform the compile.
Job Queues All source members for the promotion request are compiled in one job
during the compile step. This allows you to submit the compile step to a
job queue and subsystem that allows more than one active job at a time,
without running into problems with the object compiling before another.
Common Do you have to compile each request every time?
Questions No. This is optional. If N is specified in the environment defaults, use

option 5, Move Request, on the menu to move the source/objects.
Who can run this task?
The target environment administrator who has move capabilities, or the

user who created the promotion request, if that user has compile request
authority for the target environment.
What can cause this task to fail?
The user is not authorized in the Implementer user profile to submit

compiles.
What if a wrong member (especially a physical file) is deleted from a

request?
Add the member again using Request Maintenance.
If a request fails to compile for a specific member, will the compile

begin with that member when resubmitted?
The compile begins with the original member that initially failed
compilation.
223
Compile Request (ICMPRQS) Command

Option
The Compile Request (ICMPRQS) command allows you to compile a
request from the command line rather than using the menu interface. It is
useful when you want to promote a few known member/objects. Usually,
the menu interface, option 3 for Compile Requests, which allows changing
aspects of the promotion request, is more helpful.
This task is performed by the project leader after you have created the
promotion request containing the member/objects, and before it is moved
into the test or production environment.
You must have an existing promotion request at a status of Comp-Pend.
To compile using the ICMPRQS command
1 Type ICMPRQS at the command line and press F4.
2 Type the promotion request number or *ALL (to process all promotion
requests at a compile pending status).
3 You can optionally compile by date and time range. Press

F10=Additional parameters to show all parameters, and specify the
from/to time and date ranges (time values must be in HH:MM:SS
format).
4 Press ENTER to submit the compile and redisplay the command line.
Moving Promotion 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 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 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
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 Optimized PF promotions and non-source SQL are not moved out of the
“Optimizing Physical File target library; rather, the Change Physical File (CHPGF) command (for
Promotions” on page 183.
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 The move step sets the authorities to objects based on the rules defined for
the environment. For detailed information about the setting of object
Ownership authorities and owners, see the Implementer System Administrator Guide.
Archiving You can specify whether to archive the source members or objects. The
archives can be used for automatic rollback (recovery) or for browsing
previous versions of the source to assist in problem determination. For
more information about this topic, see “Archive Recovery” on page 300.
Source Member If the source type of the member is changed, the source type of the new
target member is changed as well.
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 When you create a promotion request, member/objects are placed into
holding libraries. The move task must be performed to move the member/
Requests 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 Whenever you promote entities (member/objects) associated with a design
dispositions, see the table on request, the entity disposition of the design request is automatically
page 142.
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.
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
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
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 Who can use this function?
Questions 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 To put completed member/objects back into the production or test
environment, you can issue the Move Request (IMOVRQS) command
(IMOVRQS) directly from the command line. This submits a job to move a request
Command rather than using the menu interface. This feature is useful when you
promote a few known member/objects. Usually the menu interface, which
Option allows changing aspects of the promotion request, is more helpful.

move capabilities, or by an authorized developer, when a promotion
request status is Move-Pend (or after you have created and compiled the
promotion request).
You must first create and compile a promotion request. At that point, the
promotion request status becomes Move-Pend.
Special Command Processing
To issue the IMOVRQS command
1 Type IMOVRQS at a command line and press F4.
2 Type the promotion request number or *ALL (for all promotion

requests waiting to be moved) and press ENTER.
3 You can optionally move the request by date and time range. Press
F10=Additional parameters to show all parameters, and specify the
from/to time and date ranges (time values must be in HH:MM:SS
format).
4 Press ENTER to submit the move and redisplay the command line.

At times it is necessary to either add special functionality or ensure that
specific tasks are completed at specific times under certain conditions. This
task allows developers to create, change, or delete special commands at the
time a request is created. Typical examples of this command use include, to
perform overrides using the override database file (OVRDBF), to run data
conversion programs when a physical file is promoted, and to run error
correction programs. You can set the commands to run during check out
and at various times in the promotion cycle, as explained in section.
Special commands can be defined on a per environment basis, or globally

for all environments. This is typically done as part of environment setup.
For details about the Work with Environments feature, see the Implementer
System Administrator Guide. Contact your System Administrator if you have
questions pertaining to your environment setup.
The environment library list is used when issuing special commands.

Therefore, if you have any unqualified object references in the command,
the libraries in which those objects are located must be included in the
environment library list. The special command to run must reside in the
environment library list defined in Work with Environments for each
environment.
IMPORTANT
Special commands cannot be used to change the environment library list.
229
The special command features of Implementer include:
Special commands can be processed during check out as well as

various stages of promotion.
Special commands can be performed for each object checked out, as

well as each object on a promotion request. Likewise, they can be
performed on specific objects only.
When you submit a move, the object authority for special commands
is taken from the user who submitted the move. If you want to change
the object authority, use the Change Object Owner (CHGOBJOWN)
command on IMPRDR10 to change the authority to a different owner.
You can copy an existing promotion request as a template that

contains your special commands, if you frequently need to perform
them. Member/objects must be checked out to use this feature.
Special commands issued from Create Requests run on the local

system as the user who entered them. Those issued on a remote
system run as the user profile of the communications job.
You can add comments to the special commands to make them self-
documenting. Comments can appear either before or after the
command and they must be in brackets. For example:
/* This is a comment */
Special commands support the use of a variety of substitution

variables. For more information, see “Special Command Substitution
Variables” on page 233.
The Execute Request Detail (IEXCRQSDTL) command lets you use a

variety of criteria to select certain items within a promotion request for
processing by any other special command. For example, special
commands can be triggered by the existence of specific objects on a
promotion request. For more information, see “Special Commands in
Promotion: IEXCRQSDTL Command” on page 236.
Special commands can be used to enhance DDM management. For

more information, see “Special Commands to Manage DDM” on
page 240.
The Change Request Detail (ICHGRQSDTL) special command sets the

status of a software item within a promotion request to completed,
effectively preventing any further attempts to move the item. For
more information, see “CHGRQSDTL Examples” on page 242.
The Execute Checkout (IEXCCKOCMD) command lets you use a

variety of criteria to select certain items during checkout for
processing by any other special command. For more information, see
“Special Commands in Check Out” on page 245.
Special commands are processed with the environment library list.

Therefore, ensure that the issued command or the program to be
called is on the environment library list, or qualify it with the library
name. This is not required to run commands distributed with
Implementer (for example, IEXCRQSDTL). However, to issue
Implementer commands as special commands, the product library
(MKSIM is the default), must be on the environment library list. For
more information, see the description of the IMSPCCMD data area in
Appendix A of the Implementer System Administrator Guide.
To use special commands when creating a promotion request
1 Press F17=Special commands to display the Work with Request

Special Commands panel.
2 Do either of the following to display the Expanded Command Display

panel:
Press F6 to create a special command.
Type option 2 in the option field to change an existing command,

and press ENTER.
3 Complete the fields as defined next in “Create Request Expanded

Field Descriptions” on page 232.
4 When you are finished, press ENTER to accept the command.
The Work with Request Special Commands panel redisplays.
5 Press F3=Exit.
231
Create Request Expanded Field Descriptions

For Action
Specify the promotion process to issue the special command. The For
Action is based on the When to do flag as follows:
1 = Compile Issues the command for the compile stage.

2 = Dist-Host Issues the command for the distribution stage on the
host system.
3 = Dist-Rcvr Issue the command for the distribution stage on the
receiver system.
4 = Move Issue the command for the move stage. For promotions
that target a remote system, the special command runs
where the move occurs.
5 = Move-Host Issue commands on the system where the promotion
request originated, after successful distribution. This
option is most meaningful for promotions that target a
remote system.
6 = Checkout Issue commands during check out.
When to do
For the specified For Action, type the number representing when you want
the command to run.
1 = Before The command runs before the specified For Action.

2 = After-OK The command runs after the specified For Action
successfully completes.
3 = After Fail The command runs after the specified For Action fails.
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.
Special The following tables define the substitution variables and replacement
values available for special commands processed during check out and the
Command promotion cycle.
Substitution
Variables Substitution
Replacement Value
Variable
Header Level
#FRMENV Substitutes the checked out From environment.
#PROJECT Substitutes the project number that was entered on the

Check Out panel.
#TRGENV Substitutes the checked out To environment.
Item Level
#DIR Substitutes the directory path of the target environment (IFS

only).
#DRNBR Substitutes the Design Request that was entered on the

Check Out panel.
#FILETYPE Substitutes the IFS file extension. Applies to objects

associated with object codes defined with the special
characteristic PCFILE.
#FILLIB Substitutes the checked out from file library.
#OBJATR Substitutes the object attributes.
#OBJCOD Substitutes the object code.
#OBJECT Substitutes the object.
#OBJLIB Substitutes the program or files library.
#OBJNM9 Substitutes the current, short object name.
#OBJTYP Substitutes the object type.
#PATHOBJ Substitutes the IFS project relative long name (#DIR and
#OBJECT) for IFS objects.
#PGMLIB Substitutes the From program library (non-IFS).
#SHORTNM Substitutes the IFS short name.
#SRCFIL Substitutes the source file of the checked out From

environment (non-IFS).
#SRCLIB Substitutes the source library of the checked out From

environment (non-IFS).
#SRCMBR Substitutes the source member.
#SRCTYP Substitutes the source type.
233
NOTE
Due to OS400 limitations, the short member name generated by Implementer is
not a valid name due to the tilde (~) character. As such, if you are using the
#SHORTNM substitution variable for a parameter in a special command in
check out or promotion, any tilde characters in the substituted value will be
automatically translated into the number sign (#) character.
Substitution
Replacement Value
Variable
Header Level
#ENVARCDIR Substitutes the archive path defined for the target

environment (IFS objects).
#ENVARCLIB Substitutes the archive library defined for the target

environment.
#ENVDIR Substitutes the directory path defined for the target

environment (for IFS objects).
#ENVFILLIB Substitutes the file library defined for the target environment.
#ENVPGMLIB Substitutes the program library defined for the target

environment.
#ENVSRCLIB Substitutes the source library defined for the target

environment.
#ENVTYP Substitutes the environment type (*PRD, *QAC, or *TST)

defined for the target environment.
#FRMDIR Substitutes the promotion work directory (for IFS objects).
#FRMENV Substitutes the request From environment.
#FRMLIB Substitutes the target object library name, as defined on the

Change Environment–Object Code Overrides panel.
Exception: When compiling secondary environments, this is
the library containing all non-source-based objects that were
frozen when the request was created.
#PROJECT Substitutes the request project number.
#RQSNBR Substitutes the request number.
#TRGENV Substitutes the current target environment.
#TRGGRP Substitutes the current, target environment group.
#WRKDIR Substitutes the temporary, Request work directory (for IFS

objects).
Substitution
Replacement Value
Variable
#WRKOBJLIB Substitutes the temporary work library that contains the

request’s program objects which will be moved into the
target. For requests that are compile=Y, the objects do not
exist until they are successfully compiled. Note that changing
the authorities of objects in this library does not affect the
authority of the object in the target environment. To set
authorities, see the #OBJLIB substitution value defined in the
“Item Level Substitution Variables” section.
#WRKSRCLIB Substitutes the temporary work library containing the request

source that will be moved into the target environment.
Item Level
#DIR Substitutes the From environment directory path (for IFS

objects).
#FILETYPE Substitutes the IFS file extension for the object.
#FILLIB Substitutes the current target file library.
#OBJATR Substitutes the current object attribute.
#OBJCOD Substitutes the current object code.
#OBJECT Substitutes the current member/object name. When used for

IFS objects, substitutes the current project relative long
object name when an IFS long name is associated with a
request detail item.
#OBJLIB Substitutes the current target object library.
#OBJNM9 Substitutes the current, short object name.
#OBJTYP Substitutes the object type of the item being promoted.
#PATHOBJ Substitutes the IFS project relative long name (#DIR and
#OBJECT) for IFS objects.
#PGMLIB Substitutes the target program library of the item being

promoted.
#SHORTNM Substitutes the short object name for the IFS object being
promoted.
#SRCFIL Substitutes the source file name of the item being promoted.
#SRCLIB Substitutes the target source library of the item being

promoted.
#SRCMBR Substitutes the source member name of the item being

promoted.
235
Substitution
Replacement Value
Variable
#SRCTYP Substitutes the source type of the item being promoted.
#WRKSRCFIL Substitutes the name of the source file in the request work
library. Typically used with #WRKOBJLIB and
#WRKSRCLIB.
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 Implementer provides the Execute Request Detail (IEXCRQSDTL)

command, a special command that allows you to distinguish certain items
Commands in within a promotion request for additional special command processing.
Promotion: The IEXCRQSDTL command actually conditions the processing of
IEXCRQSDTL whatever command you want to perform. Based on criteria that you define
for the command (using substitution variables), it identifies the selected
Command 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.
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
Replacement Value
n Variable
#FILLIB Substitutes the current target file library at the time of promotion.
#SRCLIB Substitutes the current target source library at the time of

promotion.
#PGMLIB Substitutes the current target program library at the time of

promotion.
#OBJECT Substitutes the current member/object name at the time of

promotion. This variable can only be used within the command
syntax.
#OBJTYP Substitutes the current object type at the time of promotion.
#OBJNM9 Substitutes the current, short object name at the time of

promotion.
#OBJATR Substitutes the current object attribute at the time of promotion.
#OBJCOD Substitutes the current object code at the time of promotion.
#SRCMBR Substitutes the current, source member name at the time of

promotion.
#SRCTYP Substitutes the current source type at the time of promotion.
#SRCFIL Substitutes the current source file name at the time of

promotion.
For Release Management Packages
#FRMPRD Substitutes the name of the product the package will upgrade
from.
#FRMVER Substitutes the name of the version the package will upgrade
from.
#FRMRLS Substitutes the name of the release the package will upgrade
from.
#TOPRD Substitutes the name of the product the package will upgrade to.
#TOVER Substitutes the name of the version the package will upgrade to.
#TORLS Substitutes the name of the release the package will upgrade to.
IEXCRQSDTL Examples
Example 1: Changing Object Characteristics
The following command issues the CHGPF command to change the size to
*NOMAX for all files with an Object Code of PF (Physical File) in the
current promotion request going to the current target environment. When
defining this command, set the For Action field to 4 (Move), and set the
When to do field to 2 (After-Ok).
IEXCRQSDTL OBJCODE(PF)
NAME(*ALL)
ACTION(*ALL)
RQSNBR(#RQSNBR)
TARGET(#TRGENV)
COMMAND(CHGPF FILE(#FILLIB/#OBJECT)
SIZE(*NOMAX))
Notice in addition to the substitution variables #RQSNBR and #TRGENV

(which are required parameter values for the IEXCRQSDTL command),
the #FILLIB and #OBJECT substitution variables are used to indicate the
To File Library and Object, respectively, in the CHGPF command. For
more information, see “Special Command Substitution Variables” on
page 233.
Example 2: Customizing Object Authorities
You can use this feature to selectively grant or revoke object authorities
outside of those defined against an environment. For example, an
environment allows you to specify *ALL, *USE, *CHANGE, *EXCLUDE, or
*AUTL. You can use the IEXCRQSDTL command to automatically issue
the GRTOBJAUT command against selective object codes and object
names. In this way, any combination of object authorities can be defined.
The object authorities can be updated in line with changes to the OS/400
operating system, without the need to upgrade Implementer.
A typical example is an environment where *PUBLIC has *USE rights for

any type of object. You can use the following commands to grant
*CHANGE rights to your database files. When defining the command, set
the For Action field to 4 (Move), and set the When to do field to 2 (After-
Ok).
239
For physical files:

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 The OS/400 Distributed Data Management (DDM) support allows objects
on one system to reference the actual contents of the objects on another
Commands to system. DDM objects can create that reference for the following types of
Manage DDM objects on the target iSeries 400 system:
physical files
logical files
data areas
data queues
The following examples describe how to use Implementer and the Change
Request Detail (ICHGRQSDTL) command to support a common scenario
related to these types of objects. The basic requirement is to promote an
object on one system as its standard object type, and promote the
corresponding object on the other system as a DDM version of the
standard object.
By first defining the environment level special commands, you can specify
standard object types, and when promoting, those objects are
automatically switched to their corresponding DDM objects.
IMPORTANT
The ICHGRQSDTL command must be embedded within the IEXCRQSDTL
command to ensure that the ICHGRQSDTL command is issued for the
appropriate promotion items only.
CHGRQSDTL Command 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 Cancels the processing of the ICHGRQSDTL command for

this environment. This is the default value.
2=Proceed Deletes the LF from request, but not from the target (requires
manual delete from target).
3=Remove Deletes the LF from request and from the target.
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.
NAME(*ALL)
RQSNBR(#RQSNBR)
TARGET(#TRGENV)
COMMAND (ICHGRQSDTL RQSNBR(#RQSNBR)
TARGET(#TRGENV)
OBJCODE(PF)
NAME(#OBJECT))
MODE(CHG)
ACTION(1)
NEWOBJCODE(DDMF)
This command changes LF to DDMF for all actions prior to the move step.
IEXCRQSDTL OBJCODE(LF)
NAME(*ALL)
RQSNBR(#RQSNBR)
TARGET(#TRGENV)
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)
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)
TARGET(#TRGENV)
OBJCODE(DTAARA)
NAME(#OBJECT))
MODE(CHG)
ACTION(1)
NEWOBJCODE(DDMDTAA)
Example 2: After Move-ok
The following commands, which are set to run after move-ok, create or
delete a remote data area, remote data queue, and DDM file based on the
action. There is no need for any changes when actions change.
243
This command deletes the existing DDMF for PFs and LFs when the action
is Delete.
IEXCRQSDTL OBJCODE(DDMF)
NAME(*ALL)
ACTION(*DELETE)
RQSNBR(#RQSNBR)
TARGET(#TRGENV)
COMMAND (DLTF FILE(#OBJLIB/#OBJECT)
RMTFILE(target-library/
#OBJECT)
RMTLOCNAME(target-system))
This command deletes the existing DDMDTAQ when the action is Delete.
IEXCRQSDTL OBJCODE(DDMDTAQ)
NAME(*DELETE)
ACTION(*DELETE)
RQSNBR(#RQSNBR)
TARGET(#TRGENV)
COMMAND (DLTDTAQ DTAQ(#OBJLIB/#OBJECT))
This command deletes the existing DDMDTAA when the action is Delete.
IEXCRQSDTL OBJCODE(DDMDTAA)
ACTION(*DELETE)
RQSNBR(#RQSNBR)
TARGET(#TRGENV)
COMMAND (DLTDTAARA DTAARA(#OBJLIB/
#OBJECT))
This command creates a DDMF for corresponding PFs and LFs when the
action is Create.
IEXCRQSDTL OBJCODE(DDMF)
ACTION(*CREATE)
RQSNBR(#RQSNBR)
TARGET(#TRGENV)
COMMAND (CRTDDMF FILE(#OBJLIB/#OBJECT)
RMTFILE(ILEPRD/#OBJECT)
RMTLOCNAME(MKS2))
This command creates a DDMDTAQ when the action is Create.
IEXCRQSDTL OBJCODE(DDMDTAQ)
ACTION(*CREATE)
RQSNBR(#RQSNBR)
TARGET(#TRGENV)
COMMAND (CRTDTAQ DTAQ(#OBJLIB/#OBJECT)
TYPE(*DDM)
RMTDTAQ(ILEPRD/#OBJECT)
RMTLOCNAME(MKS2))
This command creates a DDMDTAA when the action is Create.

IEXCRQSDTL OBJCODE(DDMDTAA)
ACTION(*CREATE)
RQSNBR(#RQSNBR)
TARGET(#TRGENV)
COMMAND (CRTDTAARA DTAARA(#OBJLIB/#OBJECT)
TYPE(*DDM)
RMTDTAARA(ILEPRD/#OBJECT)
RMTLOCNAME(MKS2))
Special The ICHGRQSDTL command is designed to be embedded within the

IEXCRQSDTL command, and should be issued to run before the move
Commands to step. It sets the status of a software item within a promotion to a status of 5,
Change indicating that the move stage of the promotion is successfully complete.
Promotion When you issue the ICHGRQSDTL command before the move step, the
original software item is still copied to the work library on the target
Status 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 Implementer provides the Execute Checkout (IEXCCKOCMD) command,

a special command that allows you to distinguish certain items during
Commands in check out for additional special command processing.
Check Out 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 Specify an object code name.

*ALL 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 Specify a member/object name.

Generic* Specify a wildcard selection, for example, .exe*.
*ALL Issues the command for all member/objects. This is the
default.
Action code (ACTION)
Specify the check out action that causes the command to run.
*ALL The command runs for all check out actions. This is the
default.
*CHANGE The command runs when change is the checkout action.
*CREATE The command runs when create is the checkout action.
*DELETE The command runs delete is the checkout action.
*RECOMPILE The command runs recompile is the checkout action.
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 Example 1: Sending Messages
command is used with Lotus
integration for setting Domino The following command issues the SNDMSG command to notify the
ACLs with the Set Domino administrator when certain objects are successfully checked out for any
ACL (ISETDOMACL) reason. When defining this command, set the For Action field to 6
command. For more
(Checkout) and set the When to do field to 3 (After-Ok).
information, see the
Implementer Multi-Platform IEXCCKOCMD OBJCODE(.EXE)
Solutions Guide. 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 How can you avoid re-entering the commands for each request?
Questions Copy an existing promotion request with the necessary special commands
and adapt the rest of the promotion request to your new specific needs.
Alternatively, you can define the special command at the environment
level.
Why doesn’t a particular special command work?
Your user profile or group profile may not have the authority to the
command.
Managing Concurrent 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 This task allows developers or project leaders to resolve a conflict caused
by concurrent development. This task is required when conflicts exist,
Conflict before a member/object can be included on a promotion request. Objects
in concurrent development with unresolved conflicts are not promoted.
You can do this task just prior to promotion, or just after the developer
who is performing the development has completed the changes and it
requires immediate conflict resolution.
Managing Concurrent Development
You must have concurrent development capabilities, and a member/object

must be in conflict.
You can resolve conflicts from any of these functions: Create Request,
Emergency Create Request, and Request Maintenance (main panel and
Select from Locks), the Workbench, or Manage Concurrent Development.
Remember that a conflict is two-sided. Whenever a member/object is

under concurrent development, you must resolve both versions (copies) of
the member/objects separately, in order to promote them. You can
automatically merge or compare the source during the resolution process.
To resolve a conflict
1 Access the Work with Conflict Resolutions panel using one of the
following options:
From the Workbench, type option 12 next to the member/objects

to resolve, and press ENTER. The Work with Conflict Resolutions
panel displays for all member/objects in conflict.
From the Manage All Concurrent Development panel, type

option 12 next to the specific lock of the member/object you want
to resolve and press ENTER. The Work with Conflict Resolutions
panel displays for all member/objects in conflict.
From Create Request (Emergency Create Request and Request

Maintenance), type option 12 next to the member/objects in the
Create Request main panel or the Select from Locks panel and
press ENTER. The Work with Conflict Resolutions panel displays
for each member/object in conflict. For this option to work, the
specific member/object must be in conflict.
2 In the Work with Conflict Locks Resolution panel, resolve the conflicts
by using any of three methods:
Type option 7 in the option field and press ENTER.
Type option 2=Change in the option field and press ENTER to

display the Change Conflict Resolution panel. Type Y in the
Resolved field and press ENTER. You can add a comment to the
resolution (which is helpful for later inquiry). Use option 5 for
Display Resolution from the Work with Conflict Resolutions
panel, or review the Conflict Report (if you select resolution for
the report).
Press F16=Resolve all. There will be only one member/object on

the Work with Conflict Resolutions panel, but copies of it can be
in multiple environments or libraries. Press F16=Resolve to
resolve all conflicts for this specific member/object.
249
3 Press ENTER to redisplay the initial panel where you began the
conflict resolution.
NOTE
The Resolved field displays the date a conflict was resolved.
If you select multiple member/objects from any of the panels in the Work with
Conflict Locks Resolution panel, you can cycle through the numerous
member/objects by pressing ENTER after each resolution. At the end of the
series of selected member/objects, the panel where the member/objects were
selected from redisplays.
To reverse a resolved conflict
From the Work with Conflict Locks Resolution panel:
1 Type option 2=Change in the option field and press ENTER to display
the Change Conflict Resolution panel.
2 Type N in the Resolved field and press ENTER.
3 You can optionally add a comment to the resolution (which is helpful

for later inquiry). Use option 5=Display Resolution from the Work
with Conflict Resolutions panel, or review the Conflict Report (if you
select resolution for the report).
Common When is a user not able to resolve a conflict?
Questions When the user does not have change resolution authority.
When you resolve a conflict, what exactly are you doing?
You are setting a flag to indicate the member/object is ready for

promotion. You must complete actual comparisons and merges to
integrate the source members.
Advanced Topics
Advanced 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 When object version stamping is active with a version method that
includes assigning the number in promotion, the next version number for
Stamping in the object is assigned when the request is submitted.
Promotion When promoting a locked object, if the check out action was Change,
Create, Regen, or Recompile the revision number is validated. If the check
out action was Delete, version stamping is ignored. When promoting an
object without locks, the version number increments only when targeting a
*PRD environment.
For more information on Validation and stamping is performed regardless of where the promotion
object version stamping, see initiates from—the Workbench, Clipboard, Create Promotion Request
“Performing Check Out” on
menu option, Emergency Create Request, Create Request (ICRTRQS)
page 111. For more
information on the setup command, archive recovery, or a COOL:2E promotion.
requirements, see the
For promotions on the host system, the version number is stamped to the
Implementer System
Administrator Guide. object after successful compilation and the objects are duplicated into the
request’s staging library (if the request is not an archive recovery request).
The issue or DR number is stamped after successful compilation from the

Workbench and in the Implementer work library during promotion. For
promotions to a remote system, the issue or DR number is stamped to the
object for remote move requests, but is not stamped for remote compile
requests.
Because object stamping in promotion occurs transparent to the user, the

version number assigned to the production object does not display until
after deployment of the objects. The version number displays (for each
object with a version number assigned) in the Revision field of the
Workbench (F11=Display Revision) and Work with Objects (F10=Display
251
Revision). In addition, the description of the object is changed by updating

the PTF Number attribute with the revision number, and the APAR ID
attribute with the design request number, which can be viewed using the
Display Object Description (DSPOBJD) command.
Emergency Implementer supports emergency promotion requests. You can create an

emergency promotion request through a separate menu option, or using
Promotions 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
Some companies might elect to use emergency promotions to bypass test

environments and go directly to production environments. For more
information, see“Handling Emergency Situations” on page 295.
Object Stamping in Archive Recovery

When performing archive recovery, the version number of the archived
object is retrieved. To achieve this, Implementer retrieves the request that
the archived object was created by, and reads the previous request that
targeted this object to the given environment. The request detail records
for this request are used to identify the version number of the object at the
time the archive object was created.
Advanced Topics
For example, an object exists in production with version number 4.0.

Archive recovery is performed to retrieve version 2.0 of the object. When
recovered directly into a *PRD environment, the production object will be
version number 2.0.
The next time the object is checked out to a *TST environment, it will be
assigned version number 4.1.
For issue or DR stamping and archive recovery promotions run on a

remote system, the issue or DR number that was stamped to the archived
object is retrieved.
Problem 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
Determination 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 Description
CPD0078 Value &3 for parameter &2 not a valid name.
CPF0001 Error found on &1 command.
CPF1015 Data area &1 in &2 not found.
CPF3012 File &1 in library &2 not found.
CPF3092 FILEATR specified not valid for &3 file &1.
CPF3213 Members for file &1 more than maximum allowed.
CPF3213 Members for file &1 more than maximum allowed.
CPF4028 Open of member &1 was changed to SEQONLY(*NO).
CPF5812 Member &3 already exists in file &1 in library &2.
CPF9801 Object &2 in library &3 not found.
Completing Legitimate situations can cause a promotion request not to complete,

thereby leaving it in an open state. For example deleting an environment or
Failed removing a remote system after the request was created, or
Promotions 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
Advanced Topics
Using the ICMPLRQS Command

Use this command carefully. Because of the impact that arbitrary use of
this command could have on your database, QSECOFR authority is
required to issue the command.
The command does not delete the Implementer work libraries or perform
any other cleanup activities—these tasks must be done manually.
NOTE
The ICMPLRQS command replaces the need to use Data File Utility (DFU) on
Implementer files to manually complete a promotion request.
To use the ICMPLRQS command
At an Implementer command line, issue the following:

ICMPLRQS RQSNBR(NNNN)
Where NNNN is the promotion request number to set to a completed status.
Other Creation To simplify the entry of promotion requests, the from environment (or
from library) and target environment or environment group values default
Features to what is defined for the:
project path (if a specified project has a defined path), or
environment path, or
user profile
It is possible to restrict or allow specific entries in Create Request, or not

allow any environment changes.
You can associate a promotion request with a specific project reference,

through DesignTracker, to SupportCenter (for tracking customer issues)
and ProjectMaster (for project time projections and completion).
You can establish restrictions by object types and user capabilities that
affect the promotion of member/objects from the development library.
You can include related objects on the request to ensure that all programs
that use a particular physical or logical file are automatically recompiled.
These related objects are added to the promotion request with an action of
9 for Recompile. Logical files that are not manually added to a promotion
request are automatically recompiled, if the physical files they are based
upon are on the request. This requires the environment’s Add Related
255
Objects field be defined as N in Work with Environments. For more

information about related object processing, see “Promoting Related
Objects” on page 200.
All three steps (compile, distribute, and move) can be automated.

Typically, the original defaults for the developer are set to create and
compile the request. The project administrator then distributes and moves
the member/objects.
Using ILE Implementer provides complete support for software development using
ILE. ILE support improves performance, encourages modular
Object Codes in programming, and provides better control over OS/400 resources. For
Promotion more information, see “Using ILE Object Codes in Check Out” on
page 148.
Batch Batch promotion steps run with the MWIJOBD job description.
Implementer controls the library list during execution. The batch job is
Promotion submitted to the job queue specified in System Control Maintenance, but
Steps 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 The distribution step is performed only for promotions to remote systems.
This step is described in more detail in “Performing Distributions” on
Promotion page 271.
Requests
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 The Export phase is ready for execution.

Expt-Jobq The Export function was submitted to the job queue for
processing.
Expt-Schd The Export function is scheduled for processing.
Expt-Run The Export phase is executing.
Expt-Fail An error occurred during the Export phase. Review the
LANSA Export Report to determine the cause of the failure.
Make the proper corrections and resubmit the export
promotion.
Compile Request Status Codes
Comp-Pend A migration was requested and all member/objects were

copied to the staging library.
Comp-Jobq The compile function was submitted to the job queue for
processing.
Comp-Schd The compile function is scheduled for compilation.
Comp-Run All source-based objects for the request are currently being
compiled, and all non-source-based objects are currently
being moved/duplicated to the environment work libraries.
Comp-Fail An error occurred during the compile requests phase.
Review the job log to establish the probable causes.
Promotion Step Internal Processing
Distribution Status Codes
Dist-Pend The compile process completed successfully (if required)

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

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

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

This section describes the internal processing that occurs during the
promotion step.
259
Create Request
Compile Step Move Step uses all libraries
IM0021S
From Request
Source Source Target
Library Library
Environment
Source
IM0021002 IM0021002X
From IM0021 IM0021001X

Request Object Target
Object
Objects Work Stage Environment
Library Library Library Objects
Environment libraries
IM0021F Target
Implementer work libraries
Removed Environment
From objects Archives
Library
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.
3 Copy the source members.
Copy the source for each source-based object with an action of Create
or Change.
4 Duplicate the object.
Duplicate the objects into the request objects library from the from
environment or library:
a) Always for non-source based objects.
b) For source-based objects that have the Compile required field set
to N on the source environment.
For logical file promotion requests that have the Compile

required field set to N, the based-on physical files are duplicated
into the request object work library even if the physical files are
not on the promotion request. The physical files are placed in the
work library to ensure the logical file in the work library is not
based on the physical files in the target library. Although the
physical files are in the work library, they are not added to the
promotion request and are not promoted to the target libraries.
5 Force the compile step to occur in some instances.
This is necessary to force the primary environment to go through the

analysis phase of the compile step so that any needed items can be
identified and added to the request and compiled. All items added by
Implementer are added with action 9 for recompile and compile the
source from the target environment. NONE of the explicitly added
items on the request are compiled in this case. This is necessary if:
a) The Add related objects field is set to Y on the from environment

(traditional only).
b) The request contains a physical file. The logical files are located
and added to the promotion request.
c) The action is 9 for recompile for any item on a request that has the
Compile required field set to N on the from environment.
Export Step This step performs the export of LANSA objects on the request to a save
file.
The export process uses the export list created in Create Request function
and performs the export into the save file in the work library.
The export function in LANSA is the first of the two step process in
LANSA to move objects from one partition to another. Promotion prepares
the LANSA objects for export and imports the objects to the target
261
environment. The LANSA objects are exported from the from partition and
imported into the to partition (each partition is specifically associated with
an environment). It is possible to limit the auto submit process to only the
export step.
1 All valid LANSA objects on the request are bundled into an export list.
2 The export is done to a save file.
3 The verification of the successful completion of the export process

must be done by manually looking at the export reports generated by
LANSA.
LANSA requests are archived by exporting the LANSA objects in the

target partition into a save file in the archive library.
Compile Step This step compiles source members for source-based objects placed on the
promotion request. In addition, it adds related objects to the request (if
needed) for traditional environments and recompiles them using the
source in the target library. This step identifies implicit logical files and
adds them to the request for compilation.
Compile Request Sub-steps

1 Create target environment libraries. If they are not already on the
system, Implementer creates the libraries used by the target
environment, and creates all source files for the environment.
2 Issue special commands designated as Before Compile.
3 Add items to the request.
a) Add any implicit logical files based on physicals being promoted

on the request with action 9 for recompile.
b) Add related objects if requested.
4 Compile source-based items.
a) Issue the before compile special commands before the first

compile is attempted.
b) Analyze the target object and modify the creation command so

that any attribute not specified by you on the creation command
is retained from the target object.
c) Compile the objects into the request, object work library using the
source in the request source library. For action 9 for recompile,
use the source in the target environment.
d) Issue the compile failed special commands, if any compiles fail.
e) Issue the compile OK special commands after all compiles

successfully complete.
5 Issue special commands designated as After compile.
6 Delete the compile listings. This is done only if all compiles were
successful and the flag in System Control is set to Y.
Distribution The distribution step is detailed in “Performing Distributions” on

page 271.
Step
Move Step This step replaces the objects and source in the target environment with
newly promoted objects and source. Optionally, the replaced objects and
source can be retained in an archive library.
Move Request Sub-steps

1 Create target environment libraries. Implementer creates the libraries
used by the target environment if they do not exist. All source files for
the environment are also created (during the move if there were no
compiles.)
2 Issue special commands designated as Before Move.
3 Create the temporary work libraries. Create the object stage library,
and the replaced, target objects work libraries.
4 Allocate all objects. Allocate all objects to be replaced in the target that
are exclusively allocated, with the exception of logical files currently
in use. For more information, see “Allocating Objects” on page 224.
5 Pre-stage all physical and logical files. Pre-stage all physical and
logical files before any objects in the target are replaced to minimize
the time frame where the target environment is partially updated.
Physical Files
a) Duplicate the physical file into the stage objects library from the
request, objects work library.
b) Retain target members.
c) Retain target data.
Logical Files
a) Duplicate the logical file to the stage objects library from the
request objects library.
263
This creates a copy of the logical file with the name IMxxxxLF
(where xxxx represents the promotion request number) and
duplicates it into the target objects library. This ensures the logical
is built over the correct physicals in the target objects library.
Then it is moved to the stage objects library.
NOTE
If the physicals for the logical also are on the request, the logical is duplicated
directly into the stage library. If the logical is based on multiple physical files
that are not on the request, and the physicals are in different libraries in the
target temporarily moved, the physicals in the target are temporarily moved to
the object stage library, and then moved back again to achieve the same result.
b) Retain target members. Add the members of the existing logical

file to the logical file in the object stage library. If there is no
logical in the target, an attempt is made to retain the members of
the from library object or compiled object, if it was compiled.
6 Stage and move the objects and source. All the steps in this section are
repeated for each item on the request.
a) Duplicate objects into the object stage library. Skip physical and
logical files at this time since they were pre-staged.
b) Set object authorities and owners. This is based on the authority

method of *KEEP or *GRANT.
c) End journaling on any physical files or logical files on the request.
d) Archive target source and/or objects based on the environment

definition. Physical file objects are never archived. If the physical
file object is requested for archive, only the source is archived.
e) Remove non-archived objects. If an object is not archived, and it is

a program, it is moved to the IBM QRPLOBJ library for replaced
objects so that any users running the program are not affected.
Other objects are moved to the replaced target objects library and
are deleted after the move completes normally.
f) Move object to target objects library from the object stage library.
g) Restart journaling on all physical and/or logical files that were

previously journaled.
h) Copy the source member to the target source library from the
request source library.
i) Issue any Move-type creation commands. A common creation

command would promote the data in a physical file and change
the target object without replacing it.
j) Update Implementer lists. The member/object lists for the target

environment are updated as well as the related object
information, if it is being maintained by Implementer.
k) Update locks.
Change the lock to the new test environment (type *QAC).
Remove the lock for production environments (type *PRD).
l) Issue the move failed special commands if errors occurred during

the move.
m) Notify user that the member/object has been promoted.
7 After all items are moved:
a) Issue the move-OK special commands. Issue the Copy Physical

File (CPYF) command, as a special command to promote the data
for the physical file. To promote a physical file on the same
request with the data, copy the data along with the object by
listing the object again using the PFDTA object code.
b) Delete the move work libraries. The object stage library and the
removed target objects library are deleted. They are NOT deleted
if errors occurred before this step.
8 Final processing. This is done after all environments on the promotion

request are successfully moved.
a) Delete source in from source library if indicated on the promotion

request.
For remote QA environments, b) Delete object in from object library if indicated on the request.
automatic removal of These objects are moved individually into the removed from
member/objects is optional.
objects library and then the library is deleted. This ensures the
For more information, see the
Implementer System 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 Implementer uses work libraries during promotion to ensure the orderly
movement of source and objects into the correct target libraries. This
Used During section provides basic information about how the work libraries are used.
Promotion
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 Description
IM0021 Request object work library (primary environment,

secondary environment compile=N)
IM0021F From object holding library
IM0021N NetView/DM distribution library
IM0021S Request source library
IM0021002 Environment object work library (secondary environment

compile=Y)
IM0021001D Environment distribution library
IM0021001T Target object holding library
IM0021001X Environment staging library
TAP0021001 Tape distribution library
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.
rrrr Promotion request number.
eee Environment ID number (the sequence number of the
environment on the request).
CAPS Any letter in upper case is the actual literal value of that
character.
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.
Host Work Request Source Library

Libraries This work library contains all the source members for items on the request.
Created During Create Requests.

Deleted When the request is completed.
ASP Any
Name ppprrrrS
Example IM0021S
Text ‘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 request’s primary
environment and all secondary environments that are compile N. All non-
source-based objects are placed in this library during Create Request.
Source based objects are compiled into this library during the compile for
compile Y requests.
Created During Create Request.

Deleted When the request is completed.
ASP Any
Name ppprrrr
Example IM0021
Text ‘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 During the compile step for a request if the target environment
Compiled required field is set to Y.
Deleted When the environment goes to Completed status.
ASP Any
Name ppprrrreee
Example IM0021001
Text ‘Implementer rqs rrrr env name objects’
267
Environment Staging Library

This is a work library used to stage each object before it moves into the
target environment. While in stage, the authorities are set and most of the
database steps take place in this library (for example, ADDPFM, ADDLFM,
CPYF, and journaling). It is used instead of QTEMP since QTEMP does not
support moving out into any ASP other than ASP number one. The stage
library is only used during the move step.
Created Every time a move begins (if it already exists, it is deleted).

Deleted When the move successfully completes (not deleted if errors).
ASP Same ASP as the target environment.
Name pprrreeeX (position 3 of prefix is not used)
Example IM0021001X
Text ‘Implementer rqs rrrr env name staging’
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 When final processing for the request begins and all
environments are successfully moved.
Deleted When final processing is complete for the request.
ASP Same as the From objects library.
Name ppprrrrF
Example IM0021F
Text ‘Implementer rqs rrrr removed from objects’
Target Object Holding Library

Holds the objects removed from the production environment if they are
not going to be archived. They are not deleted directly in the target library,
since physical files are processed before logical files and they cannot be
deleted before logical files. This library is only used during the move step.
Created When the move begins for the environment, only if the target
environment is not archived.
Deleted When the environment is Completed.
ASP Same as the target object library.
Name pprrrreeeT (position 3 of the prefix is not used)
Example IM0021001T
Text ‘Implementer rqs rrrr env name target objects’
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 During the distribution step.

Deleted After distribution, whether successful or not.
ASP Any
Name pprrrreeeD (position 3 of the prefix is not used)
Example IM0021001D
Text ‘Implementer rqs rrrr env name dist objects’
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 During the distribution step.

Deleted After distribution, whether successful or not.
ASP Any
Name TAPrrrreee
Example TAP0021001
Text ‘Implementer rqs rrrr env name tape’
269
NetView/DM Distribution Library

Contains all the objects and source for every environment on the request.
This library is left on the system and a record is written to an interface file
alerting NetView/DM to pick up the library and distribute it to the correct
systems. (This library name must be eight characters or less.)
Created During distribution.

Deleted When NetView/DM calls to the system or the request is
completed.
ASP Any
Name ppprrrrN
Example IM0021N
Text ‘Implementer rqs rrrr NetView/DM distribution’
Remote Work Environment Work Library

Libraries Contains all the objects, source, and Implementer database files needed on
the remote system. For this reason, there is no separate Request Source
Library or Request Object Work Library. All other libraries are the same as
the host, except there is no need for the From Object library or any of the
distribution libraries to be included.
Created During distribution on the remote system.

Deleted When environment is completed.
Performing Distributions
7
T his chapter describes the distribution and promotion of promotion
requests to remote systems or multiple environments.
moving and distributing promotion requests by system
displaying move promotion requests by system
controlling remote job schedules
using the Implementer Receiver Menu
271
Moving and Distributing Promotion

Requests by System
The environment definition determines whether you perform the
distribution and move steps separately or together. The Move Promotion
Request by System/Environment function allows you to submit the
promotion requests separately to a system/environment or combine the
promotion requests by system/environment.
The Move Request by System function now automatically submits one job
per target environment for any move request that does not require
compiling or adding related objects. This allows for the parallel processing
of multiple targeted environments, and provides quicker processing of
multi-environment move requests. Additionally, if an error occurs in any
one of the targeted environments, processing continues to the secondary
environments.
NOTE
The number of concurrently active jobs is determined by the OS/400 job queue
configuration defined for the host system. In most cases, this is the job queue
specified for the Implementer default job description MWIJOBD. However, this
can be overridden in either System Control Maintenance or in Work With
Environments, Promotion Scheduling. For more information about job queues,
see “Job Queues” on page 223 and“Batch Promotion Steps” on page 256, or see
Moving/ This task allows you to distribute all promotion requests to remote systems
independently of moving the objects into the target environment on the
Distributing All remote system. This task is helpful when it is necessary to distribute
Promotion members/objects to remote systems and later move them to production. It
is generally performed by an environment administrator who has move
Requests By capabilities or by an authorized developer. The task is required any time
System 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.
Moving and Distributing Promotion Requests by System
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 You can override the defaults established in Work with Environments for
promotion scheduling.
Overrides
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.

Common Why use menu option 6 for Move requests by system rather than
option 5 for Move request?
Questions
Move requests by system allows you to break the move into two steps.
NOTE
If you use the Create Request defaults in the environment definition Promote
Through Step, you can perform a regular move (and distribute). Menu option
6, Move Promotion Request by System/Environment, allows you to manually
process this step. For example, you may want to compile on the remote or
delay (while on the remote) promoting the object into production.
What is the most common problem with remote promotions?
The communications link (OS/400 physical hookup or Implementer

configuration) is not correctly set up.
Moving/ 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
Distributing to a specific remote system. This gives you specific control over the production
Specific System objects.
This task allows environment administrators with move capabilities or

authorized developers to distribute specific promotion requests to remote
systems. In addition, it allows you to initiate: a single promotion request
for all promotion requests on a system, a specific promotion request on a
system, or only a single environment for a promotion request on a system.
You do this task once you have created or compiled the promotion request.
Define the remote system through Network Configuration.
Define the environment on the remote system through Work with

Environments.
There must be a compiled promotion request.
To move/distribute to a specific system
1 Type menu option 6 or STRIM (*MOVRQSSYS) at the command line

and press ENTER.
2 Type option 5 next to the environment/system that you want to view

all requests for and press ENTER to display the Request Selection
panel.
NOTE
The request is listed by promotion request number and by environment.
For example, a specific promotion request could be listed that contains five
different target environments. The promotion request would be listed five
times, once for each environment.
Overrides panel. This can be done from either the Move Promotion Request by
System/Environment selection panel or the Move Promotion Request by
System/Environment panel that displays when you use option 5=Display
Requests. Type your changes or accept the defaults and press ENTER to
redisplay the previous panel. Note that Time range fields must be entered in
HH:MM:SS format.
275
3 In the Request Selection panel, type one of the following in the option
field and press ENTER:
Option 10 to distribute the request. This option is only valid for a

remote environment, when you will perform the local initiated
move later or when it is a remote initiated move.
Option 11 to move the request. Use this option for both the host
and remote systems. This option indicates a local initiated move
as set up in Work with Environments.
Option 12 to distribute and move the request. This option is only

for a remote environment. It indicates a local initiated move as set
up in Work with Environments.
Request Selection Options

The following options are available on the Move Request by System panel.
4=Delete entire request
Delete the promotion request for all environments and systems.
5=Display
Display the details for this promotion request for example, request
originator, member/object list, and compile options.
10=Distribute
Submit the distribution of objects for this promotion request to this system.
11=Move
Submit the Move Request process for this promotion request to this
system.
12=Distribute and move
Submit the distribution and move for this promotion request to this
system.
15=Related Request
Display the secondary requests that were generated at create request time
for any cross-environment related objects that required recompiling.
16=Job Log Inquiry
Display the OS/400 job log for this promotion request. This is useful for
problem determination and resolution.
17=Job log Print
Print the OS/400 job log for this promotion request. This is also useful for
problem determination and resolution.
Redistributing a Promotion Request

To redistribute a Promotion Request

press ENTER to display the Move Request panel. You can also access
this function from the Workbench and Work with Objects with
F15=Move requests.

Common Why would you move a single promotion request at a time?
Questions When applying a specific PTF to your production environment or to move

an entire application to production.
Move/Distribute This task allows environment administrators with move capabilities or

authorized developers to distribute specific promotion requests to remote
by System systems by tape. Perform the task any time you cannot or do not want to
Submission set up a communication line to your remote systems.
Options To perform this task, you must define the environment on the remote
system in Work with Environments, and a request must be in either Move-
Pend or Dist-Pend status.
To use move/distribute by system options
1 Type menu option 6 or STRIM (*MOVRQSSYS) at the command line

and press ENTER to display the Move Requests by System/
Environment panel.
2 On the Move Requests by System/Environment panel, press

F6=Options to display the Submission Options panel.
You can type option 5 to view requests in the option field of the Move
Requests by System/Environment panel and press ENTER to display
277
the Request Selection panel. On this panel, press F6=Options to

display the Submission Options panel.
In the Submission Options panel, complete the necessary

information:
Tape device
Initialize tape
Volume identifier
Multiple promotion requests on tape
Press ENTER to accept the options and return to the previous

panel.
3 Press ENTER to submit the distribution to tape.
NOTE
Use the Restore Remote Request (IRSTRMTRQS) command to prepare the
promotion requests to move on the remote system. For more information, see
“Restoring Remote Requests (IRSTRMTRQS)” on page 289.
Displaying Move Requests by System/

Environment
This task provides clear visibility to the status of promotion requests that
target both local and remote locations.
The Move Requests by System/Environment panel displays each system/

location and includes a summary of the number of requests at a
distribution status and a summary of the requests at a move status.
Summary information is further sorted by the number of jobs: scheduled,
in the job queue, pending, running, and failed.
To view move requests by system/environment
From the Implementer Menu, select option 6 to access Move Requests

by System/Environment.
Displaying Move Requests by System/Environment
Filtering You can filter the display to show specific locations with promotion
requests at a selected status.
Options
Position to System allows you to position to a specific system name.
This is useful if you have a large number of systems defined in
Implementer.
Filter on Status allows you to display all systems that have promotion
requests at a specified status level. This is useful if you have a large
number of systems defined in Implementer.
From the Move Requests by System/Environment panel, you can drill-

down to view all requests for a system/environment and retrieve further
diagnostic information concerning the promotion request.
To drill down by system

Type 5 on the option line of the request you want to view. From the
Request Selection panel, you can select specific promotion requests to
process. For problem determination and resolution, option 15=Job
Log Inquiry and option 16=Job Log Print provide diagnostic
capabilities from within the Request Selection panel.
279
Controlling Remote Job 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 To schedule a promotion request to a remote environment (based on the

default settings for that environment), you must use menu option 6, Move
Default Job Requests by System/Environment. This function allows you to distribute
Schedule 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.
Overriding the The Change Remote Request (CHGRMTRQS) command allows you to
enter schedule overrides to the default move schedule for promotion
Default Job requests. This command evokes DDM to communicate the overrides to the
Schedule 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 Perform the following steps prior to using remote job scheduling:
Scheduling Define the remote environment to allow remote-initiated moves.
Define the remote environment to have a default move time.
Create a routinely running job on each remote system that issues the
Move Remote Request (IMOVRMTRQS) command for all requests.
To set up a remote environment for remote initiated moves
1 From the Implementer Menu, select option 42 to display the Work

with Environments panel.
2 Select the remote environment that you want to define using option
2=Change. The Change Environment panel displays.
3 Press PAGE DOWN twice to display the third Change Environment

panel.
281
4 In the Remote initiated move field type Y.
5 In the Updates host field, type Y or N to indicate whether remote

initiated moves should update the host with information such as the
request header status, request detail status and information, archive
information, and job log. If set to N, the status is set to complete after
the request is distributed. Otherwise, the status is not updated until
the move actually occurs on the remote system.
6 Press ENTER to save the change and redisplay the Work with
Environments panel.
To set up default scheduling for a remote environment
1 From the Work with Environments panel, select the remote

environment that you want to define with option 13=Promotion
scheduling. The Change Environment panel displays.
2 Press PAGE DOWN to display the second Change Environment

panel.
3 In the Move submit date range and Time range fields specify the
default date and time ranges to use for the majority of requests. The
left-most field represents the from-date or time. The right-most field
represents the to-date or time.
*CURRENT The from and to dates default from the system. This is
the default value.
Actual Date Specify an exact from and to date.
*MONTHSTR The from date is the first day of the month.
*MONTHEND The to date is the last day of the month.
*MON through Type an asterisk followed by the first three letters of any
*SUN 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 This Change Remote Request (ICHGRMTRQS) command communicates

schedule changes for each remote system targeted on the request. The
Remote schedule changes you define are processed to the schedule overrides file
Requests IMRQSO.
To use the ICHGRMTRQS command
1 Use the Create Request function to submit a request to a remote

environment or select a request already created.
2 Type the command ICHGRMTRQS on the command line and press

F4=Prompt.
3 Define the command parameters based on your environment, and

press ENTER.
TIP
The Change Remote Request command can be issued at any point after the
request is created—the request does not have to be at a Move Pend status.
ICHGRMTRQS Command Parameters

Request number (RQSNUM)
Specify the request number from the request you created.
Target environment (TGTENV)
Specify the target environment from the request.
Name Specify the name of the target environment.

Generic* Specify a value that will be used to include all matching
environments. For example, the entry ABC* includes all
environments beginning with ABC in the scheduling
change.
*ALL Includes all target environments requests are issued for.
From date (FROMDATE)/To date (TODATE)
Specify the date range to schedule the move.
*CURRENT The from and to dates default from the system.

Actual Date Specify an exact from and to date.
*MONTHSTR The from date is the start of the month.
*MONTHEND The to date is the end of the month.
*MON through Type an asterisk followed by the first three letters of any
*SUN day of the week to indicate the from date.
*REQUEST 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 Specify exact from and to times.

range
*CURRENT Defaults the time range from the system.
*REQUEST 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 Specify the name of a job queue and library.

*SYSCTL Uses the job queue specified in System Control.
*REQUEST The job queue and library do not change. This is the
default value.
Hold on job queue (HOLD)
Complete this standard OS/400 Submit job parameter as required.
285
Moving Remote The Move Remote Request (IMOVRMTRQS) command processes the
move step for each remote environment targeted on the request. If
Requests 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 Type a specific request number. This resubmits a request

Value currently at a scheduled status. For example, use this to
resubmit a specific request if the promotion job was
deleted from the system while at a scheduled status. This
resubmits all scheduled jobs based on the default
schedule, or the last override, if one was processed.
*ALL This does not resubmit a request at a scheduled status.
For new requests not previously submitted, it submits the
move job using the default move time, or if any schedule
overrides were specified with the Change Remote
Request (ICHGRMTRQS) command. For inactive
requests previously submitted, it updates the schedule to
the last request schedule override processed.
*FAILED This does not resubmit a request at a scheduled status.
4 Press ENTER.
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 What is the difference between a host initiated move and a remote
initiated move?
Questions
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 The Work with Remote Requests function simplifies the tasks of promotion
on a remote system by allowing request inquiry, request report printing,
Requests on and remote initiation for moving the members/objects into the remote
the Remote production environment. This function is generally performed by a remote
environment administrator who has move capabilities.
System
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.
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 The Restore Remote Requests (IRSTRMTRQS) command restores a

promotion request that was distributed by tape or with NetView/DM.
Remote These objects are restored into a work library. This command is also
Requests available from the Work with Remote Requests panel. This step is typically
performed by a remote environment administrator who has move
(IRSTRMTRQS) 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 The Move Remote Requests (IMOVRMTRQS) command completes the
promotion process for remote initiated moves that you restored using the
Requests Restore Remote Requests (IRSTRMTRQS) command. It is used to promote
(IMOVRMTRQS) 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.
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 The key is an unchanged global key—the specified key definition is

equal to the global key definition.
O The global definition is overridden for this function key.
Blank The key is not a global key—it is defined globally, but one of the
attributes is redefined on this panel.
Function Key
The number assigned to the function key.
0 ENTER
1-24 Function keys 1 through 24
25 ROLLUP
26 ROLLDOWN
27 HELP
28 HOME
29 CLEAR
100+ Document-only function keys. This allows you to document and
display some of the commonly used keys on your system
keyboard. You can number document-only function keys from 100
to 999. These keys cause no processing to occurthey simply
document available keys that are processed outside the application
program (for example, System Request, Attention, and various PC
hot key sequences). When creating a document-only function key
you cannot enter an action or command.
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 The function key is valid on this panel.

N The function key is not valid on this panel. Invalid function keys do
not display. An example of this is PAGE DOWN on a panel
containing only one page.
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 The function key displays.

N The function key does not display. If the valid flag is Y, the function
key remains valid. An example of this is ENTER.
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
Handling Emergency
Situations 8
Implementer supports the following three emergency functions:
Archive Recovery allows you to roll back a previously completed
promotion request. This is useful when a promoted change is not
working properly, and you want to return the previous versions of the
objects (and source members) to production while you investigate or
fix the problem.
Emergency Check Out provides all the features of the standard Check
Out function, and marks the member/object as checked out for
emergency purposes.
Emergency Create Request provides all the features of the standard

Create Request function. You can optionally select emergency check
out only for promotion. These promotion requests are denoted as
emergency promotion requests.

archiving
using the Archive to Tape features
performing archive recovery
performing emergency check out
performing emergency create request
295
Handling Emergency Situations
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 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
Source and are placed in the archive library are renamed. This allows the ability to
Objects on a archive multiple copies of the same source and object. In addition, the
source members are renamed when they are archived. The archive library
Promotion is not accessible to Implementer users.
Request When you recover objects or display archived source members, what
version of the source member or object to use is automatically determined.
You can use the same archive library for multiple environments. The
archive library must be different from any other libraries for an
environment.
If you have targeted multiple environments on a promotion request that
are designated for archive, the objects are archived multiple times.
A common development scenario is to archive your production
environments and not your development or test environments.
Using the Archive to Tape Features

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 system—to either
browse the changes or recover them back into the production environment.
Process Archives continue to be made during any promotion into an environment

that is being archived. On a periodic basis that you determine, all archives
Overview 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 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
Tape Archives 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
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 Archive recovery supports the rollback of standard promotion requests, as
applies to promoting cross- well as related requests—that is, primary requests and their generated
environment related objects, a secondary requests.
feature activated in System
Control Maintenance. For From the Archive recovery panel, you can determine if a request has any
more information, see secondary requests by the value in the Related Requests column. When
“Related Request Processing” related requests do not exist, the value is blank, which indicates a standard
on page 201. 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 Whenever you promote new objects into production, it is possible for
errors to occur that make the updated production environment unusable.
Archived When this happens, it is necessary to have an automated (and accurate)
Source/Object process to restore the last production version (or whatever version you
need). Because all archived versions (up to 99 levels) are tracked, this
by Request function gives you critical control in a disaster situation.
This task allows you to return your production environment to a
previously working version of one or more objects by automatically
recovering or backing out implementation requests. A request is generated
and the compile and move procedures are automatically performed. The
recovered request is superseded by the new recovery request.
You can roll back either a single object or an entire promotion request. If
you archived the objects, you can process a rapid rollback, which does not
require the compilation step. If you archived source only, or if you want to
recompile the source, specify source archival on the request.
The rollback procedures create a promotion request. The request type is
recov. This approach ensures the same integrity as a normal promotion
request and ensures that the rollback is fully logged and tracked as a
change. Each production member/object is checked out and remains
checked out until it is forward promoted, if you selected it for check out on
the Archive Recovery Options panel.
Only promotion requests that still have source or objects in the archive
library for the environment are eligible for rollback. For example, objects
on a promotion request that were also promoted on another more recent
promotion request may not be available. If the archive for the environment
was set to only archive one version of the object, the earlier promotion
Archive Recovery
request could not be recovered because the object no longer exists in the
archive library.
Targeting Multiple Environments

You can separately recover source and objects from individual
environments for a promotion request that targeted multiple
environments. You can select from a list of archive capable environments
and a separate request is created for each.
Archive recovery is generally performed by an environment administrator
who has move capabilities.
Archive options must be enabled for the target environment.
The members/objects must exist in an archive library (you usually set

up each production environment to archive).
The request must not have been purged.
To recover archived source/object by request
1 Type menu option 23 or STRIM (*ARCRCV) at the command line and

press ENTER. The Archive Recovery panel displays.
2 Type 1 in the option field and press ENTER to select the request and
display the request detail. The Request Member/Object Selection
panel displays.
For a primary or secondary request, you can use option 15=Related

Requests to display a list of the related request detail (recovery options
are not available from the Related Request panel).
3 Type option 1 next to the member/objects to recover and press

ENTER, or press F16 to select all member/objects on the request.
4 Press F9=Recover to process the selected member/objects. The menu

redisplays with a message indicating the move request was submitted.
The selected members/objects are automatically promoted back into

production. If necessary, members are compiled first. The request type
is Recov.
IMPORTANT
If you archived both source and objects, you must select either the source or the
object—you cannot select both source and objects to rollback into production.
301
Common If multiple versions are archived, how do you know which one to
restore?
questions
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 During Archive Recovery, you have the option to check out the current
version that was just promoted into production to a developer. This allows
Check Out immediate development on the fix. At the same time, Archive Recovery
Archive Options 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.
move capabilities, whenever you need to rollback a previous version of a
member/object into production.
Archiving must be enabled and a promotion request must be complete for
an archived promotion request to exist.
To automatically check out during archive recovery
1 Type menu option 23 or STRIM (*ARCRCV) at the command line and

press ENTER.
Archive Recovery
2 Record the from library/environment on the Archive Recovery panel.

You may need this value later in the recovery options panel. In the
Archive Recovery panel, type option 1 next to the promotion request
you want to put back into production and press ENTER to display the
Request Member/Object Selection panel.
3 In the Request Member/Object Selection panel, type option 1 next to

the members/objects you want to back out and press ENTER, or
F16=Select All on the promotion request.
IMPORTANT
If you archived both source and objects, you must select either the source or the
object. You cannot select both to rollback into production.
4 Record the request ID and the project reference at the top of the
Request Member/Object Selection panel. You may need these in the
Recovery Options panel.
5 Press F8=Recovery options to display the Archive Recovery Options

panel.
6 In the Archive Recovery Options panel:
a) Type Y in the Check Out Current Member/Object field.
b) Complete the required information for the following fields. It can

be the same information as on the original request or new
information:
To library or To environment fields
To User field
Project reference field
Design Request field
Recover LANSA objects on the request field

c) Press ENTER.
The Recover LANSA objects field on the Archive Recovery

Options panel specifies whether LANSA objects should be
recovered. Both traditional and LANSA objects can be recovered
at the same time. This is particularly useful when you have a
combination of LANSA objects and traditional objects on the
same request.
If you want to recover only traditional objects, set the Recover

LANSA objects on the request field to N when you select the
303
traditional objects. If you want to recover only LANSA objects, set

the Recover LANSA objects on the request field to Y but do not
select any of the traditional objects. All LANSA objects on the
request are recovered. You must recover all of the LANSA objects
or none of the LANSA objects.
NOTE
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.
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 What is the difference between standard and emergency check out?
Questions 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 3 In addition, the auto submit option defaults from the value specified
data area, see Appendix A of for the Implementer data area IMEMGSTP (Emergency Promotion
the Implementer System
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.
Member and Object
Handling 9
Implementer has advanced features to support the different types of
OS/400 objects and source members. All OS/400 members/objects that
exist in user libraries are supported as well.
The object code provides the seamless way in which Implementer supports
the different types of items it must promote. Whether an item is a source
member (such as OCL36 or COBOL copy blocks), an object (data areas or
job descriptions), or a source-based object (such as an RPG program,
display file, or physical file), you specify the same information about each
item—the name of the item and the object code.
The object code defines whether the item has an associated source member
and associated objects, and defines how it will be compiled.
The chapter covers how Implementer works with:
Compile options
Database file management
Special object considerations
ILE member/objects
S/36 environment
S/38 environment
Extended object support
307
Member and Object Handling
Compile 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
Database Management
Implementer’s support for database management includes complete
support for all object and source types, including source-based objects,
non-source-based objects, source-only items, and the tracking of non-
OS/400 items.
This section covers the support Implementer provides for managing the
following types of database files:
non-source-based SQL
source-based SQL (DDL)
traditional DDS-based
triggers and constraints
IMPORTANT
If you are working in a mixed-development environment, Implementer
requires that an SQL table have only SQL indices and views built over it. In
other words, Implementer does not support DDS-based logical files built over
SQL tables, or SQL-based logical files built over DDS-based physical files.
Database Management
Managing Non- Implementer provides full support for database files built using non-
source-based SQL. This includes SQL tables, indices, and views, as well as
Source-based the retention of existing triggers and constraints.
SQL
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
Object Type Object Code
Characteristics
SQL Table SQLT SQLTABLE
SQL View SQLV SQLVIEW
SQL Index SQLI SQLINDEX
File Creation for Non-Source SQL

When creating a request to promote SQL objects, Implementer verifies:
the request does not contain DDS-based logical files built over SQL
tables
the request does not contain SQL-based logical files built over DDS-
based physical files
only SQL type object codes are used for SQL objects
All SQL objects go through the compile step, which ensures that the tables
will be installed correctly in production. Implementer uses an SQL DDL
Alter Table (ALTER TABLE) statement architecture to recreate a file in the
production library. During the compile, Implementer verifies the request
does not contain changes that are not supported by the ALTER TABLE
command. The ALTER TABLE statement detects the differences between
the table being promoted and the target production table. The target table
is duplicated into a temporary library without data, where the ALTER
TABLE statement is run again. This ensures that only the changes
supported by the ALTER TABLE command are included in the promotion.
309
For example, it detects un-supported changes in fields/columns in a table,

and the use of deleted fields/columns by existing SQL indices, views, or
logical files. If problems are detected, the request fails, before the move
step, ensuring the integrity of the production files.
After examining the target library for related indices and views, those
found are recreated in a temporary work library where they are used for
recompiling any related programs. This also ensures that all unchanged
indices and views that contain fields/columns that were dropped from the
table are detected, before the move step, again ensuring the integrity of the
production files. The target libraries are also examined for existing related
indices and views that specified list of field to include in a view. If found,
they are archived, deleted from production, and then recreated (rather
than compiled).
The distribution step is handled as any other member/object. If archiving

is selected, it occurs before the move step.
In the move step, Implementer uses the ALTER TABLE command to

replace the tables in the production library. While Implementer does not
explicitly require or perform journal management, a function of the ALTER
TABLE command stops and re-starts the journals for journaled files. For
related indices and views, Implementer issues the CREATE INDEX or
CREATE VIEW command over the new production file to ensure they are
correctly built.
Archive and Archive Recovery
Implementer supports the archive and recovery of SQL DDL indices and
views. For archiving, it uses the CREATE INDEX or CREATE VIEW
command, based on file type, to save the files to a source file in the archive
library. This allows for object creation from the source file during Archive
Recovery.
Build List Consideration
The Build List function distinguishes SQL-based tables, indices, and views
from DDS-based files.
During a build, if Implementer finds existing SQL tables, indices, or views

loaded into the repository as DDS-based, the object code for those objects
will automatically be changed to it’s respective SQL-based object code. If
an SQL object is found with no corresponding object code/special
characteristic for that type of object, the object will not be loaded into the
repository, rather a message will display indicating the object was not
loaded. This is the standard way Implementer handles an object that does
not have a valid corresponding object code for an environment.
Database Management
Managing Implementer provides full support for database files built using source-
based SQL (OS/400 managed source), including the retention of existing
Source-based triggers and constraints for source-based tables.
SQL (DDL)
For more information on The promotion of source-based SQL is similar to that of an optimized PF
optimizing promotions, see promotion, in that most of the work is performed in the production library
“Optimizing Physical File
during the move step. This technique ensures the integrity of your
Promotions” on page 313.
production files, while at the same time bypasses a significant amount of
the promotion processing that occurs in the Implementer work libraries.
Implementer’s support for SQL management provides the following

benefits:
automatically adds related indices and views to the request (they do

not have to be explicitly added)
automatically rebuilds indices and views
automatically retains triggers and constraints
eliminates copying of data
Object Codes for Source-based SQL

For managing source-based SQL DDL objects, Implementer provides three
source-based object codes. You may also create user-defined object codes,
provided they are created with the applicable source member type.
The source member type identifies it as a source-based object and ensures

that the Implementer repository properly reflects the different object types
to distinguish SQL DDL-based tables from DDS-based files.
When checking out and promoting DDL source-based SQL objects, use the
following object codes, as described.
Object Codes for Sourced-based SQL
Source Member
Object Type Object Code
Type
SQL Table SQLTABL SQLTABL
SQL View SQLVIEW SQLVIEW
SQL Index SQLINDX 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 The traditional database uses Data Definition Specifications (DDS) based
files, although it also uses high-level languages (such as SQL, RPG IV, and
Traditional DDS ILE Cobol) that include I/O extensions to support database files and
commands.
This section covers important information about promoting traditional

DDS-based physical files and logical files.
IMPORTANT
Implementer requires that a physical file created with DDS have only DDS-
based logical files built over it. In other words, Implementer does not support
DDS-based logical files built over SQL tables, or SQL-based logical files built
over DDS-based physical files.
Database Management
Promoting Physical Files

In traditional database management, physical files are one of the most
complicated objects that Implementer supports. However, a number of
features exist that help you to efficiently handle these complexities.
Optimizing Physical File Promotions

For more information on this Implementer provides a feature that allows you to optimize the promotion
feature, see “Optimizing of DDS-based physical files created with the Create Physical File (CRTPF)
Physical File Promotions” on
command.
page 183.
When optimizing, Implementer uses the Change Physical File (CHGPF)
command over the target file in production when promoting DDS-based
physical files. The processing steps of an optimized PF promotion are
similar to those of an SQL DLL file promotion, in that most of the work is
performed in the production library during the move step. This technique
ensures the integrity of your production files, while at the same time
bypasses a significant amount of the promotion processing that occurs in
the Implementer work libraries. Because this technique runs directly over
production files, optimized promotions are typically submitted for evening
or weekend processing when the files are not used.
The benefits to using optimized PF promotions include:
it reduces database file promotions an average of 50% over non-

optimized promotions
it automatically rebuilds any logical files or indices
it eliminates copying of data
If a request fails, the existing files remain in production as they were before
the promotion. After correcting any problems, you can re-submit the
request.
Triggers and Constraints
When promoting DDS-based physical files on an optimized request,

Implementer automatically retains any existing DDS-based triggers and
constraints in the target production environment.
To add or remove triggers and constraints, or to retain triggers and

constraints without optimizing, use the special commands feature when
creating the promotion request. Generally, this requires creating a special
command with the Add Physical File Trigger (ADDPFTRG) command or
the Remove Physical File Trigger (RMVPFTRG) command, to run After-
Move Ok, either on a per request basis or at the environment level
313
depending on the number of triggers. For example, if you create a new

physical file, Implementer will only add the triggers and constraints when
the file is promoted if instructed to do so in a special command.
Related Files
Implementer automatically determines all related logical files when

promoting a physical file. If you did not explicitly select a related logical
file, it is automatically added to the promotion request with a status of
recompile. This designates that you did not change the logical file, but that
it must be recompiled against the new physical file to work correctly.
Data Retention of Non-Optimized Promotions
When PF promotions are not optimized, existing data is retained using the
record format field mapping options *MAP and *DROP on the IBM Copy
File (CPYF) command. If *MAP/*DROP fails, the request status is set to
Move-Fail.
In the rare case where a field has been changed from numeric to
alphanumeric or vice versa, the Copy File (CPYF) command is not able to
retain the data correctly.
In this case, you should promote the physical file in two steps:
1 Remove the field and promote the physical file.
2 On a second promotion request, add the field back to the file (with the
changed field attributes).
This approach allows data to be retained in all fields, except for the field
that was changed from numeric to alphanumeric (or vice versa).
Physical File Data

Implementer provides the object code PF to promote physical files when
you have changed the source members. However, other object codes also
affect physical files.
To promote or change the contents of a physical file, use the PFDTA object
code. At check out, this object code copies the records in the database to the
development library. When you create a promotion request, the data in the
development or test library is copied to the target library, but the physical
file is not compiled.
If you have added or changed records in a file and changed the source
(added, changed, or deleted fields), promote that physical file with both
the PF and PFDTA object codes.
Database Management
Changing Members
You can add or change members with the object codes delivered with
Implementer. To change a physical file member, use the CHGPFM object
code. To add a member to a physical file, use ADDPFM object code.
Journaling Files
When a database file promotion is optimized, existing journals are retained

for journaled files. While Implementer does not explicitly require or
perform journal management, a function of the CHGPF command stops
and re-starts the journals for journaled files.
When optimize is not used, journals are automatically removed and

reapplied for journaled physical files, using a technique compatible with
MIMIX users. MIMIX is a software product from Lakeview Technologies
that provides concurrent updates of database files on two different
systems.
To start journaling on a new database file or an existing database file that is

currently not journaled, use the special commands feature when creating
the promotion request. Typically, you need to use the following
commands: Create Journal Receiver (CRTJRNRCV), Create Journal
(CRTJRN), and Start Journal Access Path (STRJRNAP).
Reference Files
To ensure field reference files are compiled before other physical files, use
the PFREF object code to promote field reference files.
Conversion Programs
If you required conversion programs, you can run them as a special

command on the promotion request. You can specify the exact command
or call the program and the associated parameters as a special command,
to be called at the same time as the promotion. This ensures Implementer
converts the data as soon as the promotion occurs, not at some later time.
The conversion programs must exist in the target environment before you
can use them in a special command.
Create Physical File (CRTPF)
You should avoid changing the maximum members (MAXMBRS)

parameter of the Create Physical File (CRTPF) command for the PF object
code, which can result in errors during the move step. An example of this
is an existing physical file that has two members, but the command creates
a file with a maximum member of one.
315
In addition, you should avoid changing the file size (FILESIZE) parameter
for existing objects. This can result in errors during the move step, if you
change the file size to a size smaller than the existing members of the
physical file.
Promoting Logical Files

Logical files, like physical files, are complex objects to promote. However,
a number of features exist that help you to efficiently handle these
complexities.
Promoting Logical Files
Implementer allows you to control the failure of promotions on remote

systems due to logical file problems. These problems include, for example,
implicitly added logical files (that cannot be recompiled), logical files that
have no source, or logical files with duplicate keys.
For more information, see This feature is enabled using data area IMWRNTRGLF. This data area
“Data Areas and User Exit allows you to control whether the promotion request fails, continues, or
Programs” in Appendix A of
presents you with an errorwithout interrupting production. In each case,
the Implementer System
Administrator Guide. detailed information about the logical files and the actions taken are
written to the job log and sent to you.
Object Codes
The object code LF is provided to promote logical files when you have
made source changes. However, other object codes also affect logical files.
You can add members or change them with object codes that are delivered
with Implementer. To change a logical file member, use the CHGLF object
code. To add a member to a logical file, use the CHGLFM object code.
Journals
When a database file promotion is optimized, existing journals are retained
for journaled logical files. While Implementer does not explicitly require or
perform journal management, a function of the CHGPF command stops
and re-starts the journals for journaled files.
When optimize is not used, journals are automatically removed and

reapplied for journaled logical files, using a technique compatible with
MIMIX users. MIMIX is a software product from Lakeview Technologies
that provides concurrent updates of database files on two different
systems.
Database Management
To start journaling on a new database file or an existing database file that is

currently not journaled, use the special commands feature when creating
the promotion request. Typically, you need to use the following
commands: Create Journal Receiver (CRTJRNRCV), Create Journal
(CRTJRN), and Start Journal Access Path (STRJRNAP).
Join Logical Files
Implementer automatically handles all the complexities of join logical files.

This includes retaining existing members and retaining members where
the number of based-on physical files has been changed. When the logical
file member cannot be read exactly as it existed before, the member is
added with system defaults and a message is sent to notify you to review
the logical file member.
Multiple Format Logical Files
Implementer fully supports multiple format logical files and supports

promoting logical files based on physical files that exist in more than one
library. When the physical files are in more than one library, an exclusive
lock is required on the physical files used by that logical file at the time of
promotion.
Auxiliary Storage Pool (ASP) Considerations
Logical files can have dependencies across different libraries, but OS/400
constraints dictate that these libraries reside in the same ASP. Normally,
this is not a problem. However, let’s say you have a test library in one ASP
and a production library in another ASP and you want to promote just one
logical file. In this scenario, the physical file does not exist in the test library
and the request fails. You must keep copies of the physical files in the test
environment as well as the production environment. Most organizations
keep copies of physical and logical files in both environments.
Create Logical File (CRTLF) Command
You should avoid changing the maximum members (MAXMBRS)

parameter of the Create Logical File (CRTLF) command for the LF object
code, which can result in errors during the move step. An example of this
is an existing logical file that has two members, but at file creation you set
the maximum members to one.
317
Common Does Implementer support triggers and constraints?
Questions Yes. Implementer automatically retains in the target libraries any triggers
and constraints associated with SQL table promotions and optimized PF
promotions. To add or remove triggers and constraints, or to retain
triggers and constraints without optimizing, use the special commands
feature when creating the promotion request.
Can source-based SQL object codes be used to promote non-source-

based tables?
No. Implementer requires you to promote source-based SQL tables using

object codes that have a special characteristic that identifies them as
source-based.
What are the basic guidelines for creating DDS files with SQL tables?
Implementer requires that a physical file created with DDS have only DDS-
based logical files built over it. In other words, Implementer does not
support DDS-based logical files built over SQL tables, or SQL-based logical
files built over DDS-based physical files.
Special Object 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 significant—it controls whether
the existing data area value is retained.
These data areas are helpful, for example, to use a single promotion
request to deploy to multiple libraries or systems, while retaining or
replacing data area values as needed. For example, this is useful for a data
Managing ILE Development
area that controls the next order number, when a new customer needs to
have the data area value set to a newly distributed value, while an existing
customer needs to retain the existing value.
For more information, see Chapter 3 of the Implementer System

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 Implementer analyzes command and program objects, since the display
commands for the objects Display Command (DSPCMD) and Display
Programs 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 it’s standard processing in
areas such as TCP/IP processing.
Support for Modules are objects that essentially contain the executable code, but are
not actually executable until they are bound into an ILE program or a
Modules service program.
Checking Out Modules

When you need to make a change to a module, you first check out the
module, and the programs and service programs in which it is bound
(referred to as related objects in Implementer). Implementer makes this
easy through its support for automatically adding all related objects during
check out. Since modules are bound by copy, a best practice typically
involves checking out the related programs and service programs (with an
action of 9=Recompile). If you do not, you will not be able to test the
changes in your development libraries, since the programs and service
programs must have the changed module bound before the new programs
can be executed.
Although not recommended, you may also check out just the module. In
this case, use the Implementer feature that adds all related objects to a
promotion request. This automatically rebinds the modules to the existing
programs and service programs the module is currently bound to.
Compiling From the Workbench

When you select the modules, programs, and service programs to compile,
Implementer automatically compiles the modules, then the service
programs, and finally the programs regardless of the order they appear on
the Workbench. When rebinding the programs and service programs,
Implementer uses the library list of the development environment to
ensure that the correct versions of all modules are used for binding.
Implementer uses the CRTPGM and CRTSRVPGM commands when
rebinding.
If you need to add or remove modules from an ILE program or service

program during compile, prompt option 14=Compile. The modules
currently used by that program will be loaded into the creation command
and qualified to a library list of *LIBL to ensure the correct versions of the
modules are derived from the environment library list during compilation.
Promoting Modules
When promoting a module, you should also promote the related programs
and service programs at the same time—just as you checked them out at
the same time. You can also configure Implementer to automatically
include them on the promotion request.
A caveat of dealing with modules is that because they are object-based, by

default Implementer moves them on promotion requests. This is fine as an
object moves through QA environments to the local production
environment. However, if you deploy the application to remote systems it
is typically undesirable to deploy the modules (and binding directories)
since they are not required for execution of the application. To avoid this,
MKS recommends that you deactivate the module object codes for remote
environments.
Support for Service programs are objects that contain procedures that are bound to
calling programs at run time. This is also referred to as bound by reference.
Service
Programs 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 Many of the same principles for loading objects into the Implementer
repository apply to loading ILE objects.
Objects Into the
Repository Loading Modules
Modules are source-based objects that Implementer loads into the
repository like any other source-based object. By default, they are assigned
an object code of xxxMOD, where xxx is the language.
Loading ILE Programs and Bound Programs

Implementer first determines whether the ILE program is built using a
CRTBNDxxx command, or if it consists of multiple modules assembled
using the CRTPGM command. If the program consists of a single module,
it is assigned an xxxBND object code. Otherwise, an object code of xxxILE
is assigned to the object, and the modules that are used by the program are
added to the Implementer’s related object repository for use in check out
and promotion.
When loading ILE programs, any modules and service programs that are
bound into an ILE program are also inserted into the Implementer impact
analysis repository.
Loading Service Programs

Service programs are loaded into Implementer and matched to an object
code based on the object type (*SRVPGM) and object attribute.
When loading service programs, any modules and service programs that
are bound to the service program are also loaded into the Implementer
impact analysis repository.
Binding Directories
Binding directories are loaded into Implementer using the BNDDIR object
code.
Export Source
Service Program Export Source is treated as a source only item, similar to
OCL and copybooks.
Common Can Implementer help to convert an application from OPM to ILE?
Questions Yes. For more information, see “Performing Check Out” on page 111.
How does Implementer support bound programs?

Bound programs are handled similar to traditional OPM programs, as
there is one object for each source member.
How is impact analysis handled for ILE objects?
For modules, Implementer recognizes the bind by copy relationship for

programs and service programs. For service programs, it recognizes the
bind by reference relationship for programs and service programs. The
previously listed topics on modules and service programs discuss the
handling of these associations in more detail. Implementer uses it’s own
repository or Hawkeye’s Pathfinder for determining these relationships.
323
Why are modules being sent to our remote systems?
By default, the Implementer promotion process sends all objects on a

request to specified remote systems. This includes modules (*MODULE
object type) since they are a simply an OS/400 object.
Most organizations do not need modules sent to a remote system. To avoid

this, deactivate the module object codes for remote environments, in Work
with Environments.
What characteristics are retained for ILE object types?
Implementer automatically retains the characteristics for ILE objects based

on the creation command used to create those objects, as follows:
Create Program (CRTPGM) command: Parameters retained from

existing programs are MODULE, ENTMOD, BNDSRVPGM,
ACTGRP, ALWUPD, USRPRF, and ALWRINZ.
Create Service Program (CRTSRVPGM) command: Parameters

retained from existing service programs are MODULE,
BNDSRVPGM, ACTGRP, ALWUPD, USRPRF, ALWRINZ, EXPORT,
and SRCFILE (export source file).
Create Bound xxx Program (CRTBNDxxx) command: Parameters

retained from existing programs are DFTACTGRP, ACTGRP,
ALWUPD, USRPRF, and ALWRINZ.
In addition to the object characteristics that are automatically retained, you

may also specify additional defaults using the Implementer object codes.
How does Implementer use binding directories?
Binding directories store a list of modules and service programs that are
used when creating programs and service programs.
Implementer creates a binding directory for each Implementer

environment (the name of the binding directory is the environment name)
and stores it in the Implementer product library. At your option, you may
use this Implementer-created binding directory to simplify the creation of
new existing programs and service programs.
The binding directory can be added when creating an ILE program or

service program from the Workbench, by prompting option 14=Compile.
If you want to use the environment binding directory as a default for all
compiles, change the appropriate object code creation command to include
BNDDIR(#TRGENV).
S/36 Environment
S/36 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
Integrating With Other
Vendor Products 10
T 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
Integrating With Other Vendor Products
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 IBM’s WebSphereTM Development Tools
for the iSeries 400. With CODE/400, you can edit, compile, and debug
your client and server applications, as well as applications written in
many OS/400 languages.
COOL:2E
COOl:2E is an application development tool for the iSeries 400

developed by Computer Associates. The Implementer Adapter for
COOL:Xtras Change Management (CM) is a separately licensed
integration that manages changes for both COOL:2E developed
applications and traditionally developed applications.
J.D. Edwards
J.D. Edward is application software that was developed using their

World Case product.
LANSA
LANSA is a CASE tool developed by LANSA Corporation.
Lotus Notes and Domino
Lotus Note and Domino are software applications developed by Lotus

Development Corporation.
Powerhouse
Powerhouse is a CASE tool developed by Cognos.
American Software Integration
American Software 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 American Software uses a special command for compiling, which, among
other things, merges both a base version of a source member, ASI PTFs,
for Check Out and customer changes into a temporary source member and then compiles
and Promotion that source member.
In order to automate ASI change management in Implementer, ASI-

specific objects are used in place of the standard object codes for:
For information on object code CBL (Cobol Programs)
requirements, see Chapter 5 of
the Implementer System 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 To compile an ASI Cobol within Implementer, use a specific ASI Cobol
object code, for example, CBLASI.
Cobol
The object code controls, among other things, how objects are compiled.
Programs 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 The following information relates to possible problems encountered with
message files.
Considerations
Problem Resolution
Source mismatch Change source member type to TXT.
Checked out QSRC instead of Default source file must be USRCxxx.

USRC
TSRC and USRC not copied 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.
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 and generated traditional source and objects can
be checked out as defined in the manuals. All the required objects can
AS/SET however, be checked out along with the definitions in order to have
Definitions 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 The Check ADK Dependencies (ICHKADKDEP) command checks for

AS/SET object dependencies of any ADK items during check out.
Dependency
The requirements for this feature include defining the library list of the
Checking Implementer job description, and defining a special command for the
development environment.
There are no setup requirements within the AS/SET for this feature.
To define the job description library list
1 On the command line, type the following command and press

F4=Prompt.
CHGJOBD JOBD(MWIOBJD)
2 Define the Library parameter. This is the library where the job
description exists (MKSIM is the default).
3 Define the Library List parameters as follows, and press ENTER:
The AS/SET object library (ASSETO is the default) must appear

before the AS/SET file library (ASETF is the default).
Both the ASSET object library and file library must be positioned
before the Implementer library.
QTEMP library must appear (in any position) on the library list.
To define the development environment special command
1 From menu option 42, Work with Environments, select the *TST
environment with option 19=Special commands.
2 The Work with Environment Special Commands panel displays.
(Previously defined special commands may display on this panel.)

Press F6=Add to display the Expanded Command Display panel.
AS/SET Integration
3 Define the special command as follows, and press ENTER.
Environment (environment name)

For Action 6
When to do 2
Sequence number 10.0
Command 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 Description
I Ignore this dependency and continue checking.
N Ignore this and all subsequent dependencies.
C Copy this dependent object to the target environment and continue

checking.
A Copy this and all subsequent dependencies to the target

environment.
During the check out process, messages are logged to the job log
indicating what action was taken by the check out program. As with
all Implementer messages, the text can be customized by maintaining
a message file. For more information on maintaining messages files,
see“Problem Determination” on page 253.
333
Promoting AS/ AS/SET definition promotions (using an object code that contains an
ADK special characteristic) require that the from and target
SET Definitions environments be defined as an AS/SET environment.
AS/SET definitions must be promoted from a specifically defined

AS/SET environment. The definitions on the request and the
environments are edited for validity.
AS/SET definitions cannot be promoted from a library.
AS/SET definitions must be promoted to specifically defined AS/SET

environments. (Defined in Work with Environments by associating an
application set to a standard environment in order to create a special
AS/SET environment.)
AS/SET definitions can be promoted to multiple target environments

or an environment group provided the primary environment is an
AS/SET environment. If non-AS/SET environments exist in the target
environment group or list, AS/SET definitions are not promoted to
these environments although the promotion will occur to the AS/SET
environments in the group or list. Multiple target environments can be
established in the Work with Environments, Create Request, Compile
Request, and Move Request functions.
AS/SET definitions cannot be distributed to remote locations.
When creating a promotion request, AS/SET must be included in your

library list, but you should not be in the AS/SET product. If you are in
it, and you are promoting from a different application set than that
which you are in, generated objects will not be added to the request.
If you are promoting an AS/SET display program with the associated

help, it is necessary to promote the definition and help separately as
two objects with the same name. One of the objects must use an object
code with the special characteristic of ADKDSP for the display
program. The other object must use a separate object code created
with the special characteristic ADKHLP to promote the help text
associated with the display program.
If you are overriding defaults, the remove member from library/

environment flag can be used for AS/SET definitions.
The source and object are moved from the From environment if the
request specifies No to compile.
At promotion time, the names of the required objects are

automatically copied into the target application set for the display,
report, and batch program definitions. To actually promote the
required objects, you must promote the required objects individually
AS/SET Integration
with the appropriate object codes, or use the Add Related Objects
feature to automatically include the generated objects for the
definitions on the request.
When you use the AS/SET object codes (for example, RPT) at
promotion, the AS/SET definition is copied to the target application
set. If you want the associated OS/400 source to be promoted, use the
RPG, DSPF, and PRTF object codes, or use the Add Related Objects
feature to include the generated objects for the AS/SET definition on
the promotion request.
The Create Request (ICRTRQS) command does not support AS/SET

definitions.
If you manage AS/SET generated RPG programs having X FILE

overrides, use an object code that has the special characteristic of
RPGADK in order to compile these programs during promotion.
Implementer automatically analyzes these programs and performs the
appropriate X FILE overrides before compilation. If the original file
name contains ten characters, thus not allowing an X at the end of the
X FILE name, the overridden file cannot be identified. Therefore, MKS
suggests using file names contain less than ten characters.
AS/SET Commands
Command Definition
Delete AS/SET definition Deletes an AS/SET definition from a given

(IDELADKDFN) application set.
Copy AS/SET definition Copies an AS/SET definition from one

(ICPYADKDFN) application set to another, with the facility to
optionally replace it in the from or target
application set, if it already exists.
Retrieve AS/SET definition Verifies an AS/SET definition exists and

(IRTVADKDFN) retrieves the description.
Archiving AS/ After defining an archive application set for an AS/SET environment, the
AS/SET definitions are automatically archived whenever you promote to
SET Definitions the environment.
Remote The Implementer Receiver does not support AS/SET definitions; however,
it does receive the generated objects.
Distribution
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 Description
0 Does not add generated objects to the promotion request.
1 Adds only generated objects to the promotion request.
2 Adds both generated source and objects to the promotion request.
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.
CODE/400 (CoOperative Development Environment/400) is a
workstation-based client/server development environment, available with
IBM’s WebSphereTM Development Tools for the iSeries 400.
With CODE/400, you can edit, compile, and debug your client and server
applications, as well as applications written in many OS/400 languages.
Implementer provides integration into CODE/400 to offer a Windows-

based version of the classic host tools SEU, SDA, RLU, and PDM. This
integration provides seamless access to your iSeries source and objects, and
offers efficient development of your ILE RPG, ILE COBOL, ILE CL, ILE C,
ILE C++, database description specifications (DDS), and Java applications.
The CODE/400 tools are invoked from the Workbench using the PDM
User-Defined Options function. Options are available for browsing,
editing, and designing source members.
IMPORTANT
The CODE/400 integration described herein requires that CODE/400 is
already set up and running successfully within your organization.
Creating the 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
User-Defined Workbench. For example, to invoke CODE/400 to edit a source member,
Options create an option defined with the following command syntax:
Call qcode/evfcfdbk parm('37' 'Y' 'OS400' '<LOCAL>
CODEEDIT "<OS400>&L/&F (&N)"')
Where:
Value Description
37 The coded character set identifier (CCSID) to use to

send information to the desktop.
Y Specify Y to display a message or N to not display

messages.
OS400 Specify the name of the server to log messages in the

command shell. If you do not have the OS/400 server
defined, you may get an error in the command shell.
<LOCAL> Specify a server name. You can specify <> (empty

brackets) to use the first active
CODE/400 server.
337
Value Description
CODEEDIT Specifies the command to run on the desktop

(indicated by <LOCAL>). The command must be
enclosed in double quotes.
The command options are:
CODEBRWS to browse
CODEEDIT to edit
CODEDSU to design (screens)
"<>&L/&F (&N)" &L is the library.

&F is the source file.
&N is the member name.
There must be a blank space between &F and (&N)
or the source file will not be substituted correctly.
Launching The CODE/400 tools are invoked from the Workbench using the PDM
User-Defined Options function.
CODE/400 From
Implementer 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.
COOL:Xtras Change Management Integration
This section explains the change management features of Implementer for

COOL:2E. It includes basic concepts, as well as detailed information about
checking out and promoting COOL:2E developed applications.
Basic Concepts You must know a few basic concepts to understand how change
management occurs for COOL:2E developed applications. These concepts
are described briefly here and expanded upon later.
Change Controlled Models

The processes for enabling a model for change control differ for pre-
existing models as opposed to newly created models. For newly created
models, the process is as simple as creating the model with the Create
Model Library (YCRTMDLLIB) command, specifying the Implementer
product library (Y2SYCM or MKSIR) in the change control parameter
(CHTCTL).
For established COOL:2E models, it is necessary to initialize the version

type of all model objects. To accomplish this, various tools are available for
analysis and modification, such as the Start Change Control
(YSTRCHGCTL) and Associate Production Model (YASCPRDMDL)
commands. In addition, you must define the model to Implementer as a
COOL:2E environment. Enter a model library name on the COOL:2E
options panel, accessible using option 10 from the Work with
Environments panel.
The following examples help to clarify these concepts.
Example 1
Your site has existing development and production models and you want
to implement change control.
1 Start Change Control (YSTRCHGCTL) command
If your production model is closely synchronized to the changes in

development, you can achieve implementation most easily by using
the YSTRCHGCTL command. You need to specify the set version type
(SETVSNTYP) parameter (the parameter values are available in the
command help text). The most sophisticated value for this parameter
is *ASSOC, which invokes the Associate Production Model
(YASCPRDMDL) command, described next.
2 Associate Production Model (YASCPRDMDL) command
The YASCPRDMDL command compares objects between two models.

It matches objects by owner name, object type, and copy name in the
development (source) model with the owner name, object type, and
339
object name in the target model. If a match is found, the object in the
development model is set to a production version.
The production model defined to the YASCPRDMDL command

should ideally be the related production environment you define in
the COOL:2E environment setup. If you do not have a production
model, you can use a QA model instead.
For this approach to be effective, you must achieve development

cutoff of all changes, both functional and database. If functional cutoff
is not an option, database cutoff is a minimum requirement to obtain a
predictable result.
You should note how objects are identified between the two models.
For non-versionable objects, matching is straightforward because of
the one-to-one relationship.
For versionable objects such as functions, a more arbitrary pairing

method could cause some unexpected results. The program reads all
model objects in development by Owner/Type/Name order. If a
match is found in the target model, the program attempts to make the
object production (if it isn’t that already). If any other version in the
group is production, the attempt fails, the information is written to a
report, and processing continues. This result is the first version in a
group, alphabetically, is set to production.
If the wrong version is flagged as the production version, you have to

make manual changes. Use the Associate Production Model Report to
identify which objects need correction. For each object, change the
version that was set by the YASCPRDMDL command to development,
and set the version to production. (The Work with Versions
(YWRKVSN) and Change Model Object (YCHGMDLOBJ) commands
can be useful.)
Example 2
Your site has a development model and traditional production library, and
you want to implement change control and establish a production model.
1 If the production library in your existing system was generated from

your development model you have two options: You can define a
separate environment for the existing 3GL production library or you
can create a new model library and define its generation library as the
existing 3GL production library. Either solution will work, but the first
solution carries overhead of both extra promotion steps and extra disk
space requirements.
2 For either situation, you have to identify the objects in development

that constitute the objects in production. If you already have
Implementer as your change control system, this is not necessary since
the production version types will already be set.
To identify the production objects in your existing development

model, either:
Use the Start Change Control (YSTRCHGCTL) command,

particularly if your existing promotion system places permanent
locks on those objects promoted to production (set the version
type to *BYLOCK), or
If the production flags are not established, follow these steps:
3 Issue the YBLDMDLLST command to create a model list of all non-

versionable objects in the model, in other words, exclude functions
and messages. Do not include Implementer-supplied objects.
4 Issue the Execute Model Object List (YEXCMDLLST) command to call

Change Model Object (YCHGMDLOBJ) for each list entry, and change
the version type of the objects to production (*PRD).
5 Create a model list of all functions and messages, excluding those

supplied by COOL:2E (versionable objects). For each object, include
only the version in production; do not include more than one version
for a group, as this will cause an error in the next step.
6 Issue the YEXCMDLLST command as before for the non-versionable

objects. (If you attempt to set more than one version in a group to
production, an error occurs.)
7 Establish that all of the objects flagged as production are the current
versions for their groups.
To create a list of all objects in the model, issue the following

command:
YBLDMDLLST MDLLST(PRDLST)
CUROBJ(*NO)
To remove all objects that are current or a development version
type, issue the following command:
YFLTMDLLST MDLLST(PRDLST)
OUTLST(PRDLST)
CUROBJ(*NO)
VSNTYP(*PRD)
OUTFLAGVAL(*SELECTED)
To return all of the objects on the list to a current status, issue the
following command:
341
YEXCMDLLST MDLLST(PRDLST)
RQSDTA('YRDRMDLOBJ)
FRMOBJNAM(*CURRENT)
TOOBJSGT(&Y@)
TFRNAM(*NO)')
FLAGVAL(*SELECTED)
8 With all of the production objects in your development model

correctly established, you are ready for the final stepthe creation of
the production model objects.
To populate the production model, issue the Copy Model Object

(YCPYMDLOBJ) command. If you ran YSTRCHGCTL as instructed in
Step 2, or if Implementer is active for the development or production
model, disable it by setting the YCHGCTL model value to *NONE.
Build a model list of all production objects in the development model,

and, using the Copy Model Object (YCPYMDLOBJ) command, copy
that list to the new production model.
Re-establish Implementer by setting the YCHGCTL model value to the

name of your Implementer product library in the development and
production models.
Model Object Lists

Model object lists are a COOL:2E feature used for change control purposes
within Implementer. When you check out a model object, you must check
out to a model object list. A model object list represents one logical change.
When you create a promotion request from a COOL:2E environment, you
select only one model object list to associate with that promotion request.
Check Out
Check out is required when you attempt to change or delete an existing
model object or create a new model object. By logging the change of the
model object, it ensures Implementer knows what to promote when the
change is complete. Check out can occur implicitly when you change a
model object or you can explicitly check out an object before making any
changes.
Model Object Types

The model objects types managed by Implementer include the following:
Type Definition
ACP Access path
APP Application area
ARR Array
CND Condition
FIL File
FLD Field
FUN Function (versionable)
MSG 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
List P List Q List A

FIL B FIL B
CND C MSG E OBJ A
MSG E CND C
ACP D FUN H
FLD G
ACP D
FUN H
APP F List *ALLOBJ
FIL B
CND C
CND C ACP D
FLD G
MSG E
CND C
FLD G 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).
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 In traditional development, activity occurs on individual discrete source

members and OS/400 objects. In contrast, in COOL:2E development, all
Activities 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 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
Naming source members have 10 character names. Most of the panels in
Implementer assume a 10-character name with 50 characters of descriptive
text. For model objects, the model object name is stored in those 50
characters of the description. The 10 character names contain the model
objects’ surrogate number (internal identifier) prefixed with Y.
SQL Support Implementer supports the SQL-related generation options available in

COOL:2E 7.0. This includes the creation of SQL tables, SQL indices, and
for COOL:2E SQL views, and the corresponding functions that create RPG SQL and
COBOL programs.
When creating a promotion request, Implementer recognizes these SQL

types of generated objects and assigns the appropriate object code when
determining the implementation objects to add to the promotion request.
This feature capitalizes on SQL-specific object codes that are already

delivered with Implementer.
Managing SQL Files, Indices, and Views

For managing COOL:2E SQL files, indices, and views, Implementer uses
the YSQLPF and YSQLLF objects codes.
In a COOL:2E model, these member/objects have different model object

attributes; although, they share the same:
source member type (YSQL)
source file (QSQLSRC)
creation command (YEXCSQL)
345
For YFIL model objects being generated as SQL, Implementer uses the
object code YSQLPF for the associated implementation object. For YACP
model objects being generated as SQL, Implementer uses the object code
YSQLLF for the associated implementation object.
Managing SQL Functions

For managing COOL:2E SQL functions, Implementer supports the use of
the RPGSQL and RPGCBL object codes. These object codes are shipped
with Implementer.
In a COOL:2E model, an SQL function created over an SQL file has an

object attribute of RPG or CBL. Based on the type of function, it is further
created with:
source member type of SQLRPG or SQLCBL
source file of QRPGSRC or QCBLSRC
creation command of CRTSQLRPG or CRTSQLCBL
By using the SQL-specific object codes to check out an SQL function,

Implementer can assign the appropriate program type object code to the
lock.
When you create the promotion request, Implementer adds the model
objects to the promotion request for each model object using a YFUN code,
and adds the corresponding 3GL objects, including the programs, with an
object code of RPGSQL or CBLSQL.
NOTE
For information about the object code setup requirements, see “COOL:2E
Integration” in Chapter 5 of the Implementer System Administrator Guide. If the
parameter sequences of the creation commands are not defined as required, it
may cause extraneous messages to appear in your job log.
Check Out When editing the COOL:2E model using the Edit Model List
(YEDTMDLLST) command, a check out status displays with the check out
Status information. The check out status changes automatically when an object is
checked out, when a conflict is created, when a conflict is manually

resolved, and when the model object is promoted back to Implementer.
The check out status and descriptions are as follows:
Status Description
Blanks Indicates a model object is not currently checked out. After a

model object is promoted back to the production environment it
was checked out from, the status is set to blanks.
*CHECKOUT Indicates a model object is checked out with an action of

1=Change or 2=Create. This object is not in conflict with other
locks.
*REGEN Indicates a model object is checked out with an action of

8=Regen. *REGEN locks never change to a status of
*CONFLICT or *RESOLVED.
*CONFLICT Indicates a model object is checked out with an action of

1=Change or 2=Create. This object is currently in conflict with
other locks. Once these locks are resolved the status changes to
*RESOLVED.
*RESOLVED Indicates a model object is checked out with an action of

1=Change or 2=Create. This object was, at one time, in conflict
with other locks; however, the conflict no longer exists.
Working With 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
Model Object change lists, which ensures that all changes to model objects are known to
Lists Implementer. These model object list commands are described in the
COOL:2E Command Reference Manual.
Checking Out 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
Model Objects 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
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.
Concurrent 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
Development 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 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
Versionable a complete description of the term current model object, see “Glossary” on
Model Objects 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 Description
1=Change Assigned when an existing model object is changed or explicitly

checked out.
2=Create Assigned when a new model object is created.
3=Delete Assigned when an existing model object is deleted.
8=Regen Assigned when an existing model object that is not checked out is
generated, or by specifying regeneration only when checking out
a model object.
User Exit Implementer provides a user exit program called IMCMEX01. Use this
program to:
Program Option
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
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 The developer can perform the edit action.

*VIEW The developer can view the COOL:2E model object.
*NOAUT The developer does not have authority to perform the action.
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 Implementer promotes both model information and OS/400 source and
objects. The model information is promoted prior to the compile step in the
Model model copy step.
Information 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 Promotion to a COOL:2E environment differs from promotion to a

traditional environment. Because there is a target model to update, there is
Flow: COOL:2E a model copy step and the compile step performs COOL:2E generations.
to COOL:2E
Environment 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.
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.
rrrr Promotion request number.
eee Environment ID number (the sequence number of the environment
on the request as established in target environments or
environment groups).
M Model.
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 Promotion to a traditional environment differs from promotion to a

COOL:2E environment. Since there is no target model to update, there is
Flow: COOL:2E no model copy step and the compile step does not perform COOL:2E
to Traditional generations.
Environment
Creating a Request
To promote changes from a COOL:2E environment, from the Create
Request menu option in Implementer create a promotion request and
select a model object list. Each promotion request can only promote a
single model object list. This can affect how you create model object lists,
and affect what you check out to them. In general, the model object list
should contain a single logical change or multiple logical changes that are
grouped together due to dependencies between the changes.
The model list is used to derive the implementation objects for the
promotion request. No model objects are copied since the target
environment does not contain a COOL:2E model.
In addition to the OS/400 objects added to the promotion request by

selecting the model object list, based on your use of COOL:2E you may
need to add the following objects, which are not automatically derived
from the model object list:
For National Language Support (NLS), the translated prompt message

file specified on the YMSGVNM model value.
If a field reference file is used and if compile is requested, the physical

file specified on the YFRFVNM model value.
When the model objects are included on the promotion request, ensure
that the request is set up to compile the traditional objects first.
Compiling
There is no model copy step when you promote to a traditional
environment. The compiles that occur ensure that the 400 Toolkit compiler
directives in the source members are applied by using the 400 Toolkit
Execute with Pre-processor (YEXCOVR) command to perform the
compiles.
Move Request
This step updates the implementation objects in the target library. The
objects and source are moved into the libraries specified for the
environment.
The original model is also updated in this step. The version type is changed
for all model objects from development (DEV) to production (PRD). For
versionable object types, the existing PRD version of that model object
group is changed to version type archive (ARC), if archiving was requested
for the COOL:2E environment.
NOTE
The version type is set to PRD only when you promote to the environment
specified as the related production environment on the from environment. The
command removes the locks and updates the check out information as well.
The move step optionally updates information in target libraries by

generating the Convert Model Messages (YCVTMDLMSG) command and
the Convert Condition Values (YCVTCNDVAL) command.
355
For a complete description of The condition values and model messages are normally converted from
these COOL:2E commands, the model library associated with the from environment of the promotion
see the COOL:2E Command
request. If you select to convert condition values or model messages on a
Reference Manual.
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 When a model is designated as change-controlled, you will notice the

following while editing the model:
Change-
When changing, adding, or deleting a model object, Implementer
Controlled verifies that you are authorized to perform the action to a model object
Model of the type selected, and whether the model object is checked out. If
authorized, the Check Out panel displays.
You can explicitly check out model objects using option 28 from Edit
Model Object List or Work with Versions.
You can resolve conflicts with option 12 on the Work with Versions
panel. Use option 19 from the Edit Model Object List panel to display
the Work with Versions panel.
You can go directly to the Implementer Menu from the COOL:2E

Services Menu.
Check out information displays on the COOL:2E Work with Model

Object List panel and on the Work with Versions panel.
Your authorities to a model object list are checked by Implementer

each time that you access a list.
Your authority to the model object type is verified each time that you
access a model object.
NOTE
Use the Edit Model Object List (YEDTMDLLST) command to view the change
control information of model objects. This command is designed to help you
easily manage your model object lists.
Pre-load the model environment into your job with the Edit Model
(YEDTMDL) command: YEDTMDL entry (*NONE). This increases your
interactive response time on successive model edits.
Model Object 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.
Audit This audit trail information can be useful to track changes to objects in the
Information 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 Description
Object Only (OBJ) A change that has no effect on any other object and
does not require regeneration of the object, or any other
object, to retain the integrity or functionality, either of the
objects or of the implementation objects.
Generation Required A change that has no effect on any other model object
(GEN) but does require regeneration of the changed object to
affect the change in its implementation object. If it is an
internal object, the generable objects that use it must be
regenerated.
Private (PVT) A change to an object in which its interface with all

objects that contain the object has not changed. The
objects that contain the changed object may need to be
regenerated for the implementation objects to contain
the new functionality of the changed objects.
Public (PUB) A change to an object in which its interface with other

model objects has changed. The objects that contain
the changed object need to be reviewed and changed to
ensure their integrity.
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.
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 By default, Implementer allows you to promote EXCUSRSRC and

EXCUSRPGM COOL:2E functions separately from their associated
EXCUSRSRC implementation 3GL source and objects. This is called “Independent
and EXCUSRSRC and EXCUSRPGM”.
EXCUSRPGM Implementer optionally allows you to automatically promote the 3GL

source and objects associated with EXCUSRSRC and EXCUSRPGM
functions when these functions are promoted. When enabled, the
implementation objects for EXCUSRSRC and EXCUSRPGM function types
are derived and included on the promotion request. With this feature, the
implementation source and/or objects may not be checked out or
promoted separately from this model object. This is called “Dependent
EXCUSRSRC and EXCUSRPGM”.
This feature is controlled by an environment level flag.
During check out and promotion, Implementer verifies if the 3GL source
and/or objects are associated with a model object. If not allowed, the
following message is sent:
Cannot check out/promote implementation object when the
development environment is flagged as "Dependent" and the
object type is EXCUSRSRC or EXCUSRPGM.
Check Out and Promotion of Independent Functions

When an EXCUSRSRC or EXCUSRPGM is created, only the model object
(YFUN) is checked out. The traditional program (or source) object must be
checked out using traditional check out, option 2 from the Implementer
Menu.
An EXCUSRPGM has both source and object associated with it; therefore,
you should use a standard object code (for example, RPG or COBOL) to
promote it.
359
An EXCUSRSRC has only source and no program object associated with it;
therefore, you should use the appropriate CPY object code (for example,
RPGCPY) to promote it. The object code can be tailored to define a specific
source file or copied to create a new object code. This object code is used in
the check out of the traditional portion of an EXCUSRSRC.
When promoting EXCUSRSRC and EXCUSRPGM, even though the

Remove Source flag is set to Y, the source for user programs is not
removed.
Traditional Check Out of Dependent Functions

Checking out dependant 3GL source or objects associated with a USRSRC
or USRPGM is not allowed.
Traditional Check Out of Independent Function

Checking out the EXCUSRSRC and EXCUSRPGM independent
implementation source is allowed using appropriate 3GL object codes.
For the EXCUSRSRC 3GL source, check out with a source only object code
that has a source member but no object associated with it. For example, use
RPGCPY.
For the EXCUSRPGM 3GL source and/or object, check out with one of two
object codes: If you have source for the program, use the RPG object code.
If you have just the object for the 3GL program, use an object code such as
(or similar to) RPGOBJ. In this case, there is no relationship assumed
between the model objects and the related USRSRC and USRPGM. For
example, you may check out either one without regard for the other.
Promoting Dependent Functions

The dependent implementation source and/or objects are automatically
added to the promotion request. Model Objects are added to the
promotion request when request dependent EXCUSRSRC and/or
EXCUSRPGM is selected for promotion.
The source and objects are placed in the Implementer work library. The
object code automatically assigned is derived based on the same rules for
the object code assigned when checking out independent objects. This
allows Implementer to distinguish between the two different types of
EXCUSRPGMs—with source and without source.
Promoting Independent Functions

The independent implementation source and objects are not added to the
promotion request.
You can promote EXCUSRSRC and/or EXCUSRPGM without regard for

the other, although this could result in problems in some cases. For
example, a parameter change could be made to a function that is a
USRPGM. If that function and the associated functions are promoted, but
the implementation object (a program) is not promoted, a parameter
mismatch will occur when executing the application. In this situation, you
must ensure the model object and the corresponding RPG/COBOL code
are included on the same promotion request.
Source or Objects Outside the Generation Library

There are three common ways that COOL:2E users can store EXCUSRPGM
source and objects outside the test model generation library. This section
briefly describes each scenario and how to implement the solution.
Each scenario uses the XCB target HLL object attribute in COOL:2E (see
note) to create a new corresponding object code in Implementer. The
examples assume the EXCUSRPGMs are type CLP. If they are other HLL
types, copy the appropriate shipped object code instead of CLP.
For each of the following scenarios, define the XCB object code. Copy the
shipped CLP code to XCB, change its source file value to YXCBLSRC, and
change its shipped sequence number to 502 (or the next sequentially
available number).
Scenario #1: Source in an alternate source file in the generation library

with object in the generation library:
Create an XCB object code.
Scenario #2: Source in an alternate source file in the generation library

with objects in a library other than the generation library:
Change the Environment Object Code Override object location

library value to the library that you want to store the
EXCUSRPGM object in. (Use F8=Object code override on the
Change Environment panel.)
361
Scenario #3: Source in an alternate source file in a library other than

the generation library:
Change the Environment Object Code Override object location

library value to the library that you want to store the
EXCUSRPGM object in.
Change the Environment Object Code Override source location

library to the library to store the EXCUSRPGM source in.
For each scenario, perform the following steps in COOL:2E for each
EXCUSRPGM and EXCUSRSRC:
1 When editing the function in COOL:2E, change the language from

CLP, RPG, or CBL to XCB.
2 In the COOL:2E Edit Generation Types panel, change the name of the
SCB source types source file to the source file name used on the XCB
object code definition in Implementer.
Merging Model Model lists can be merged using the COOL:2E Merge Model Lists
(YMRGMDLLST) command. Merging model lists that are change-
Lists controlled allows you to combine two lists for creating a promotion
request. This feature is useful in several scenarios, including:
Combining model lists for two changes that start to converge during
development.
Combining model lists for QA environments, where individual

changes were moved into QA but you want to have one large move to
production (or to the next QA environment).
When two lists are merged, Implementer automatically changes the locks
to the target model object list. In order to merge the two lists neither list can
be attached to an open promotion request. In addition, you must have:
authority to change locks for the from environment, or
authority to change locks for the target environment, or
for a list that is still checked out to a *TST environment, be the user
who checked out all model objects on the list
J.D. Edwards Integration
Remote For COOL:2E-developed applications running on a remote system, it may

be necessary to distribute the COOL:2E user message file, condition values,
Considerations 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 You must have the following libraries in your interactive library list:
Interface 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 To manage J.D. Edwards traditional objects, you must set up object codes
with specific characteristics. For details about the set up requirements, see
J.D. Edwards Chapter 5 of the Implementer System Administrator Guide. This offering
Traditional supports J.D. Edwards Release 5.2 through 8.X (the characteristics of the
object codes to set up are different for each release).
Objects
Support for 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
J.D. Edwards or all versions in a form ID.
DREAM Writer Versions can be checked out and placed on a promotion request using one
Versions of the following options:
Single version—Specify a particular version in the Comment field to

select a single version of a form ID. If versions are individually
selected, you cannot specify *ALL versions for the same form ID.
All versions—Specify *ALL in the comment to select all versions of a

form ID. If you select *ALL versions, you cannot select individual
versions for the same form ID.
You can check out single versions by specifying the form ID in the
Member/Object field in both Check Out and Create Request. The version
ID can be defined up to ten characters in length, but it must begin in the
first position of the Comment field. When specifying a version name in the
Comment field, the version name must be entered using all upper case
letters, for example, *ALL. This rule applies to both single versions and all
versions.
Checking Out Keep the following points in mind when checking out J.D. Edwards special
objects:
If you are checking out J.D. Edwards special objects, you must use the
specific object codes that are defined with special characteristics
starting with JDE.
Locks are created for all special objects that are being checked out.
J.D. Edwards special objects that are specified with one of the JDE
object codes can only be checked out from an environment defined as
a J.D. Edwards environment.
For the J.D. Edwards special object types World Writer and FASTR,
you must enter a group name in the first ten characters of the
Comment field.
You cannot check out J.D. Edwards special objects to a library.
If you are managing the J.D. Edwards special object User Defined
Codes with Implementer, the member/object name consists of a four-
character system number and a two-character table name. If the
system number is less than four characters, you must add spaces to
complete the four-character requirement. For example, if you have a
system number of 55 and a table name of HT, create the member/
object name as 55 HT (two number 5s, two spaces, and the letters
HT).
The Check Out (ICHKOUT) command can be used to check out

J.D. Edwards special objects.
The Check Out Related Objects function does not support

J.D. Edwards special objects.
Displaying J.D. From the Workbench, press F11=Display comments three times to display
J.D. Edwards member/objects. In addition to displaying comments
Edwards Items entered in check out, you can display the Form ID for World Writer and
FASTR, and the version reference for DREAM Writers.
Compiling From To compile from the Workbench (using option 14=Compile), the compile
library list must contain the J.D. Edwards product libraries JDFOBJ and
the Workbench 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
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 J.D. Edwards special objects can be distributed to remote locations by

promoting to remote environments defined in the Work with
Distribution Environments function. The remote environments must be valid
J.D. Edwards environments, as defined in Work with Environments. This
feature requires that the Implementer Receiver and the interface objects be
installed on each remote system you distribute to.
Archiving 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
J.D. Edwards the environment. Selective rollback of the archived special objects is
Special Objects supported.
LANSA Integration
Archive Recovery
Once setup is complete for archive recovery of J.D. Edwards special
objects, the archive recovery process works the same as standard archive
recovery.
If you need to rollback any archived changes, use option 23 from the
Implementer Menu, select the request to recover, and select one or more
special objects to recover. Details on this process are provided in
“Handling Emergency Situations” on page 295.
LANSA 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.
LANSA Integration
Promoting The user profile (or group profile) used to promote LANSA objects
into an Implementer environment with archiving activated must be
the partition’s Security Officer user profile.
For example, the LANSA security profile QOTHPRDOWN is defined

as Security Officer on the partition and used as the profile when
promoting LANSA objects. An alternate user profile (such as
LANPRD) could also be used as long as profile QOTHPRDOWN is
defined as the group profile. If this guideline is not followed, error
messages occur in the LANSA Export Report for LANFLD, LANFIL,
FANFLDT, LANPROC, and LANFNC object types, and the archive
becomes unusable for these items.
When promoting a LANSA object (using an object code that contains a

LAN special characteristic), the from and target environments must be
defined as LANSA environments.
LANSA objects must be promoted from a specifically defined LANSA

environment. The objects on the request and the environments are
edited for validity.
LANSA definitions can only be promoted from an environment.

Promotion from a library is not supported.
All valid LANSA objects on the request are bundled into an export list.
All LANSA objects are promoted in compiled form.
Both LANSA objects and traditional objects can be promoted on the

same request.
If you are promoting a LANSA function that exists in more than one
LANSA process, the name of the process that the function is being
promoted from must be defined in the comment field. If you do not
enter the process name, the function is selected from the first process.
It is possible to limit the auto submit process to only the export step.
The export step exports LANSA objects on the request. The export is
done to a save file. The verification of the successful completion of the
export process must be done by manually looking at the export
reports generated by LANSA.
If LANSA objects are targeted for a target environment group, the

primary environment must be a LANSA environment. LANSA objects
are only moved to other environments in the group if they have a
special environment type of LANSA.
The move request function performs an import of LANSA back into

production. You should verify the Import Report manually.
369
During the promotion of a LANSA file (with or without data), the

import process prompts for the name of the library that the file should
be imported into. Watch for the prompt and enter the appropriate
name.
The Export Phase status code definitions are:
Expt-Pend The Export phase is ready for execution. The Export phase is
only used by LANSA environments.
Expt-Jobq The Export function was submitted to the job queue for
processing.
Expt-Schd The Export function is scheduled for processing.
Expt-Run The Export phase is executing.
Expt-Fail An error has occurred during the Export phase. Review the
job log and the LANSA Export Report to determine the cause
of the failure. Make the proper corrections and resubmit the
export promotion.
Displaying From My Workbench, press F11=Display comments three times to display

LANSA process/functions. This also displays any comments you specify
Process/ in check out.
Functions
Archiving LANSA requests are archived by exporting the LANSA objects in the
target partition into a save file in the archive library. The save file name is
built with the environment ID number to ensure that during recovery the
correct LANSA objects are recovered.
If you choose to recover LANSA objects, all of the LANSA objects on the
request are automatically recovered.
LANSA objects are archived differently than traditional objects:
The save file name for LANSA is constructed as: LSA + request
number + environment ID.
All LANSA objects are saved into one save file and the save file is
stored in the archive library, unlike the traditional objects, which are
saved separately.
If you want to check out LANSA objects, specify a valid LANSA

environment in the To environment field and a valid user in the To user
field. A lock is created for all of the LANSA objects on the request. If the
Copy LANSA Objects in Check Out field is flagged in the LANSA Work
with Environments definition, the LANSA objects are copied into the
archive library.
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 LANSA creates save files in different libraries depending on the task. The
libraries per task are:
Libraries
Check out—the file library specified in the to environment definition.
Promotion—the Implementer work library.
Archiving—the archive library specified in the environment

definition.
If the save files begin to take up too much disk space, you can delete the
obsolete save files.
Remote LANSA objects can be distributed to remote locations by promoting to

remote environments defined in the Work with Environments function.
Distribution 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/ Implementer can grant LANSA export/import rights to you automatically
during the migration of LANSA objects. Because Implementer uses the
Import export/import processes for the migration of LANSA objects, insufficient
Authorities LANSA authorities on the objects can lead to failure of migrations.
Therefore, if you are authorized to check out or create promotion requests,
you are automatically granted LANSA authority to perform the export and
import processes. This authority is in effect only during the time the export
or import process is executed. It is automatically revoked when migration
is complete.
LANSA RDML The Compare RDML (ICMPRDML) command compares and prints the
differences between two LANSA RDML functions within the same
Function partition or in two different partitions. This command can be used as a
Compare stand-alone utility, either in batch or interactively. It is also called
automatically from various Implementer panels when you select option
23=Compare member against a LANSA object. Additionally, it is available
as option 69, Compare LANSA RDML (ICMPRDML) from the
Implementer Menu.
Using the ICMPRDML Command

You can access the ICMPRDML command using any of the following
methods.
From any command line, type the ICMPRDML command and use F4 to
prompt the command, or type the parameters listed in the next
section.
From the Workbench, by selecting a LANSA function with option

23=Compare member.
From the Select from Locks panel (accessed by using F10 from Create
Requests), select a LANSA function with option 23=Compare
member.
ICMPRDML Parameters
The following parameters define the Compare RMDL command.
Base function
Specify the name of the first function you want to compare. This is
typically the original function that the compare to function was created
from. You must enter an existing function name. The use of wild cards is
not permitted.
LANSA Integration
Base process
Specify the name of the LANSA process that the base function resides in.
Partition
Specify the name of the partition that the base function resides in.
Compare to function
Specify the name of the function you want to compare against the base
function.
You must enter an existing function name. The use of wild cards is not
permitted.
Compare to process
Specify the name of the process that the compare to function resides in.
Partition
Specify the name of the partition that the compare to function resides in.
Exclude comment lines
Specify *YES or *NO to indicate whether difference in comment lines

between the base and compare to functions are compared and reported.
Print options: All or only changed lines
Specify *ALL or *CHG to indicate whether both equal and unequal areas of
each function (*ALL) or only unequal areas are printed (*CHG). If you
select *CHG, you can elect to print a fixed number of equal lines before
each block of differences, as defined in the next field.
Print options: Equal lines before, if *CHG
If the previous field is set to *CHG, enter the number of equal lines (0–99)
prior to each detected change to print.
Output queue/Library
Specify *JOB, the output queue name and *LIBL, or the library name, to
indicate the output queue associated with the job and the library that
output queue resides in.
373
Hold spooled files
The valid options are:
*FILE The printer file definitions determine whether to hold the report
output. The name of the printer file is NVCMMBP.
*YES The report output is held.
*NO The report output is not held.
Submit
Specify whether to submit the job to batch or process interactively.
*YES Submits the job to batch. The name of the submitted job is
LANSACMP.
*NO The job runs interactively.
Specify the job name and either *LIBL or a library name to be used for the
submitted job. The default job description is MWIJOBD.
(Footer text field)
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 following illustration shows a page from a typical Compare Members
report.
the Report
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 Is changed to this term in the

Report... LANSA Report…
Member Function
File Process
Library Partition
Source data LANSA RDML command
Note that old and new commands are printed in their entirety for multiple-
line commands, even if only a portion of that command is different within
the two versions.
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 differentobject names carry a two-character prefix
based on the creation command:
Creation Command Prefix
QTP PT
QUICK PK
QUIZ PZ
QDESIGN 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.
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 IBM’s Operations Navigator, but the integration discussed
here only extends to the host-based interface.
Version Implementer links and works with any release of ABSTRACT.
Requirements
Abstract User- To support integration with Implementer, four PDM-style options are
available for the ABSTRACT user options file.
Defined Options
IS allows you to enter ABSTRACT from the Implementer Check Out
panel (F17=ABSTRACT). Navigate through ABSTRACT until you find
the items that you want to check out, and type IS in the option field
next to the item to add it. This is very helpful when you want to do
field level analysis of related objects, since this is only available
through ABSTRACT menu options.
IC allows you to check out directly from within ABSTRACT, without

having to come from the Check out panel first.
IR allows you to create a promotion request for an individual member

or object while in ABSTRACT.
DS can be used if ABSTRACT is accessed from the Work with Entity

List Members panel in DesignTracker. This option selects items from
ABSTRACT to the entity list for the DR you are currently working
with.
ABSTRACT Integration
IB allows you to add items to the Implementer clipboard. With this

unique feature of Implementer, you may build a list of items while
drilling through various ABSTRACT panels, adding one item here and
a couple items there. Implementer can perform a single operation on
all the items on the clipboard, such as checkout or promotion, or
emergency tasks.
The options needed to use Implementer from within ABSTRACT are in the
file IMPRBOPT in the Implementer product library. They can be copied
into the ABSTRACT options file QAUOOPT in the ABSTRACT product
library, if they are not already there.
The options are defined as follows through the Work with Object
References (WRKOBJR) command:
ICHKOUTSEL
Option IS
Description Select member/object for checkout
Execution I (I=Interactive, S=Submit, Blank=Either)
Command ? ICHKOUTSEL MBROBJ(&N) OBJLIB(&L)
OBJTYPE(&T) OBJATR(&A)
SRCFILE(&SRCLIB/&SRCFIL)
&SRCTYPE(&A)
Object type *ALL
Object attribute *ALL
ICHKOUT
Option IC
Description Check out
Command ? ICHKOUT MBROBJ(&N) OBJCODE(&A)
Object type *ALL
379
ICRTRQS
Option IR
Description Create promotion request
Command ? ICRTRQS MBROBJ((&N &A))
Object type *ALL
IDDCBD
Option IB
Description Add item to Implementer clipboard
Command ? IADDCPD MBROBJ(&N) OBJCODE(&A)
Object type *ALL
Accessing Implementer provides direct access to the ABSTRACT main menu from
the Implementer Check Out menu option and DesignTracker Entity
ABSTRACT panels. In addition, any panel that supports the Implementer user defined
From function keys, such as the Workbench, can easily be tailored to access
ABSTRACT menus using a function key.
Implementer
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.
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
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 It is important to accurately maintain the default DOCLIBL for the

PathFinder X-ref to use the real-time PathFinder X-ref update feature.
Database Whenever objects are managed in Implementer environments that are
Updates 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 PathFinder PDM-style user options supports the Implementer integration.

Use the following options to access Implementer functions while using
User-Defined PathFinder.
Options
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 The USERPATH file, included with PathFinder software, contains the
following user-defined options, which can be used within PathFinder.
Options for
USERPATH Option Description Command
IS Add to Check Out ICHKOUTSEL MBROBJ(&N)

OBJLIB(&L)
OBJTYPE(&T)
OBJATR(&A)
SRCFILE(&SL/&SF)
SRCTYPE(&ST)
IC Check Out ICHKOUT MBROBJ(&N)

OBJCODE(&ST)
IR Create Request ICRTRQS MBROBJ((&N &ST))
PathFinder PDM The USERPDM file, included with PathFinder software, contains the
following user-defined options, which can be used within PDM.
Options for
USERPDM
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 Description Command
IC Check Out ICHKOUT MBROBJ(&N)

OBJCODE(&T)
IR Create ICRTRQS MBROBJ((&N &T))

Request
ID DesignTracker CALL PGM(DTSESLC)

Entity List PARM(&N &S &X &T &A &ST “ “ “ “ “ “)
OU Object Where HAWKEYE/DSPOBJU

Used 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.
A P P E N D I X
Compare/Merge
Member Commands
A
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
Compare/Merge Member Commands
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.
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 Source Type
QASMSRC *BAS
QBASSRC *BAS
QCBLSRC *CBL
QCLSRC *CLP
QCMDSRC *CMD
QDDSSRC *DDS
QLBLSRC *CBL
QPASSRC *PAS
QPLISRC *PLI
QRPGSRC *RPG
QTXTSRC *TXT
QUDSSRC *UDS
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.
Exclude comment lines (EXCOMMENT)
Specify if comment lines are ignored in the comparison or handled in the

same manner as all other lines.
*NO Determines if the comment lines are handled as any other

line. Differences in comment lines are indicated.
*YES Causes all comment lines to be ignored as part of the
comparison. If all lines except the comment lines are equal,
then the source files are seen as being equal. The Source
type parameter determines the comment lines.
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.
*YES Causes all blank lines to be ignored as part of the comparison.
It does not mark any differences between members as a result
of blank lines.
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-by-

member basis. The determining factor is the source type. It
does not compress source types of RPG, and all the DDS
source types. It does compress all other source types.
*YES Causes blanks within a line to be compressed before the
comparison. If one blank separates the same two-words in the
first member, and three blanks separate the words in the
second member, the members are equal because the
comparison considers only one blank space.
*NO Causes blanks to be handled as any other character. It
indicates a difference if the number of blanks between words
and letters is different between two members.
389
Start column (STARTCOL)
Specify the column in the source line that comparison should begin from.
This can be particularly useful when processing DDS or RPG source, when
one of the source members has entries in column 1 through 5 and the other
does not. The range is 1 to 200. The default is 1.
End column (ENDCOL)
Specify the column you want to end the data comparison at for reporting
purposes. The range is 1 to 200. The default is 80.
Use the Start/End columns to ignore comments in languages with a

columnar syntax like RPG and DDS. Often in RPG and DDS, columns 1–5
contain markings that indicate a change or version that was added in the
upgrade. If these markings exist in one version but not in another, you
should consider using the start and end columns to ignore the markings.
You should not ignore columns 1–5 for free format languages such as CLP,
PL/1, and COBOL. These languages can contain valid program statements
in these columns.
Print options (PRTFILTER)
The print parameters provide the means of customizing the comparison

report.
All or only Specify how to control the amount of printed output on the
changed lines report.
*ALL prints the entire member being compared, showing
both equal and unequal areas of the member.
*CHG prints only the unequal areas. Additionally, you can
print a fixed number of equal lines before each block of
differences, as defined in the next parameter.
Equal lines Use this option to indicate the number of equal lines to
before, if *CHG 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.
Output queue (OUTQ)
Specify which output queue to place the comparison report on.
Name Type a specific output queue name.

*JOB Uses the output queue associated with the job.
Library (Output queue)
Specify the library the output queue resides in.
Name Type the name of a specific library.

*LIBL The library list to be searched for the specific output queue.
This is the default value if an output queue name is specified
without a library name.
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.
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.
*NO The report runs interactively.
Job description (JOBD)
Specify the name of the job description for the submitted job.
MWIJOBD This is the default value.

Name 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 The specific library name.

*LIBL Searches the library list for the specific job description.
391
Compare Member Report Listing
Dashed lines highlight sections where differences exist between the

two source members.
In-house and Vendor are custom terms. They were entered using the
Modify Compare Terms (MODCMPTRM) command. They clearly
identify the version in which each unique line exists.
The Records count is the total number of source records in each

member, not the number of records printed on the report.
The Functional equivalence count is the number of lines that were

adjusted in an attempt to match with lines in the other source
members. In this example, the continued lines are consolidated into a
single line before comparing.
Compare Member Report Listing
Compare Member Report Field Descriptions

The following fields display on the Compare Member Report.
Version
The versions of source you are comparing. It is the base and compare
entered on the Compare Members (CMPMBRS) panel.
Member
The name of either the base or compare source member.
File
The name of the file the source members reside in.
Library
The name of the library the source members reside in.
Src seq (Source sequence)
The specific source member, line sequence number.
Source data
The actual listing of the source member line. This can be up to two lines of
100 characters.
ALL Records
The number of records in the corresponding source member.
ALL Unique
The number of lines that occur in only one source member when
comparing (see Glossary for dynamic common lines and static common
lines).
ALL Compared
The number of actual lines compared in the specified version.
ALL Matched
The number of common records between all versions.
ALL %
The percent of records matched.
393
ALL Func equiv
The number of records adjusted by the functional equivalence processing.
UNIQUE Exec
The number of executable lines included in the Unique counts.
UNIQUE Blank
The number of blank lines included in the Unique counts.
UNIQUE Comment
The number of comment lines included in the Unique counts.
LANSA Compare RDML (ICMPRDML)

Command
The Compare RDML (ICMPRDML) command compares and prints the
differences between two LANSA RDML functions within the same
partition, or in two different partitions. This command can be used as a
stand-alone utility, either in batch or interactively. In addition, it is called
automatically from various Implementer panels when you select option
23=Compare member for a LANSA object. Additionally, it is available as
option 69, Compare LANSA RDML (ICMPRDML) from the Implementer
Menu.
Accessing the Command

You can access the ICMPRDML command using any of the following
methods.
From any command line, type the ICMPRDML command and use F4 to
prompt the command, or type the parameters listed in the next
section.
From My Workbench, by selecting a LANSA function with option

23=Compare member.
From the Select from Locks panel, accessed by using F10 from Create
Requests, select a LANSA function with option 23=Compare member.
LANSA Compare RDML (ICMPRDML) Command
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.

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
*FILE The printer file definitions determine whether to hold the report
output. The name of the printer file is NVCMMBP.
Submit
Specify whether the job submits to batch or runs interactively.
*YES Submits the job. The name of the job is LANSACMP.

*NO The job runs interactively.
Specify the job name and either *LIBL or a library name to be used for the
submitted job. The default job description is MWIJOBD.
(Footer text field)
Specify additional text to appear at the bottom of each page on the report.
LANSA The following illustration shows a page from a typical Compare Members
report.
Compare
Members
Report
LANSA Compare RDML (ICMPRDML) Command
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 Is changed to this term in the

Report… LANSA Report…
Member Function
File Process
Library Partition
Source data LANSA RDML command
397
Note that old and new commands are printed in their entirety for multiple-
line commands, even if only a portion of that command is different within
the two versions.
For detailed information about this report, see “Compare Member Report
Listing” on page 392.
Merge Member (IMRGMBR) Command

The Merge Member (IMRGMBR) command provides a method of merging
multiple copies of source to produce one final (target) copy of the source
using a command interface. This section briefly explains the command and
its parameters. The next section, Merge Member Command Parameters,
shows detail examples of most of the command parameters.
To access the command panel, from the Implementer Menu select option
66, Merge Member, or type IMRGMBR at the command line and press F4.
You can also access this function by selecting option 11=Merge member
from one of the following panels and pressing ENTER.
Select Version for Concurrent Dev
Select from Locks
My Workbench
Manage Concurrent Development for a Member/Object
Work with Conflict Resolutions
There are three panels for this command. After typing the required
information, press PAGE DOWN to access the additional panels.
Base member (BASEMBR)
This member is the base source (previous standard release from the
vendor) from which both the production member and the enhanced
member have come.
Name Specify the Base source member to be used in the merge.

*NONE Base members are not considered. This occurs when there
are only two versions of the members to merge and neither of
them can be considered the base member. This provides the
means of only entering the source versions on the Production
and Enhanced options.
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.
*NONE Use this option if BASEMBR is *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 Defaults to the same member entered in the Base

Member field.
Name 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.
Name Specify the file containing the production version of the
members to merge.
Library (Production file)

Specify the name of the source library that contains the production source
file.
*BASELIB The Base source library is used as the production library.

Name Specify an existing library that is different from the Base
library.
399
Enhanced members (ENHMBRS)
Specify the names of the other members to be considered for selecting

changes and merging into the target. In the simplest case, this is the new
release from the vendor. Up to five enhanced members can be entered.
Enhanced Specify the enhanced member name.

member
*BASEMBR Defaults to the same member entered in the Base
Member field.
Name Specify the member containing the enhanced version of
the members to merge. Enter a specific name only if the
base member is a specific name.
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.
Name Specify a source file that is different from the base
source file.
Library (Enhanced file)
Specify the name of the source library that contains the enhanced source
file (up to five enhanced versions are supported).
*BASELIB The Base source library is used as the enhanced library.

Name 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:
*FILENAME
The source file name determines the source type. The following
list provides the source files supported and the resulting source
types.
Source File Source Type
QASMSRC *ASM
QBASSRC *BAS
QCSRC *C
QCBLSRC *CBL
QCLSRC *CLP
QCMDSRC *CMD
QDDSSRC *DDS
QIMGSRC *PRTIMG
QLBLSRC *CBL
QMISRC *ASM
QPASSRC *PAS
QPLISRC *PLI
QRPGSRC *RPG
QTBLSRC *TBL
QTXTSRC *TXT
QUDSSRC *UDS
*MBR
The source type is determined from the member’s actual source

type.
Source type name
Specify the source types supported by the system. Entry of this specific
source type overrides the actual source types associated with the members.
401
Merge output (OUTPUT)
Specify whether to print the Target Source Merge Report and target source
member.
*BOTH Produces the merged source in the target member and the
Merge Report.
*FILE Produces the merged source in the target member and does
not produce the Merge Report. The new merged source
should replace any source in the designated target member.
*PRINT Produces the Merge Report. No merged source is output.
*LIST Same as *PRINT.
*NONE No merge source or report produced. Use this option only if
Member List Analysis is *YES and no other output is needed.
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 Equal lines are drawn from the Enhanced source member.
*BASE Equal lines are drawn from the Base source member.
*PROD Equal lines are drawn from the Production source member.
*ENHn (where n is 1 through 5) Equal lines are drawn from the
Enhanced N source member.
Start column (STARTCOL)
Specify the position in the source line that the data comparison begins
from.
The range is 1 to 200. The default is 1.
End column (ENDCOL)
Specify the position in the source line that the data comparison ends at.
The range is 1 to 200. The default is 80.
Use the Start/End columns to ignore comments in languages with a

columnar syntax like, RPG and DDS. Often in RPG and DDS, columns 1–5
contain markings to indicate a change or version that was added in the
upgrade. If these markings exist in one version but not in another, you
should consider using the start and end columns to ignore the markings.
You should not ignore columns 1–5 for free format languages such as CLP,
PL/1, and COBOL. The columns can contain valid program statements for
these languages.
Source Exists In...

Description Merged
Case Base Prod Enh
1 Yes Yes Yes Standard case: You use (possibly Y

modified); Vendor has retained
(possibly modified)
2 Yes Yes No You use (possibly modified), N

vendor has deleted (or has not
modified)
3 Yes No Yes You do not use (or have not N

modified)
4 Yes No No Neither you nor the vendor use N

(nor you or the vendor modified)
5 No Yes Yes New for both vendor and you Y
6 No Yes No Written by you Y
7 No No Yes New from vendor Y
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
Case 4
Neither you nor the vendor supports this source.
Resulting Action:
Case 5
This case is vague. It could be that both you and the vendor created this
source independently. If so, the two source members probably do nothing
in common.
You need to decide whether you want the vendor’s source. It could be a
source member received from the vendor after original distribution of the
vendor’s last release. In this case, you will want the two source members to
be merged with each other.
Resulting Action:
IMRGMBR merges the changes from the two source members and includes
the results in the target file. Discard the target source member if the
production and enhanced members are unrelated.
Case 6
You created this source member.
Resulting Action:
IMRGMBR copies this member to the target file.
Case 7
This is a new source member from the vendor. You should verify that you
do want it.
Resulting Action:
IMRGMBR copies this member to the target file.
Target source member (TGTMBR)
Specify the name of the source member to receive the source that results
from the merge. The merge only creates (or changes) the target member if
the OUTPUT option is *FILE or *BOTH. Newly merged source replaces any
existing source in the target member.
*BASEMBR The name of the member receiving the merged source

should be the same as the base member name.
*BASEMBR is not a valid entry if the BASEMBR
parameter is *NONE.
Name Specify the name of an individual member to receive the
merged source.
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.
Name The name of a specific target source file that the target
member will be placed in.
Library (Target The name of the library containing the Target source file.
file)
*BASELIB The name of the BASEFILE source file library to use as
the target source file library. The Target file library
parameter must not be *BASEFILE if the BASEMBR
option is *NONE.
Name Type a specific target source file library that the target
member will be placed in.
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)
*YES Highlights by double printing the excluded lines.

*NO Does not highlight excluded lines.
Excluded lines indentation (0–10)
Specify whether excluded lines are placed in a different column than the
included lines. This option only affects the report, not the merged source.
How to print messages
Specify how messages print.
*NONE Messages do not print.

*INLINE Messages print in-line or in the body of the report.
*SUMMARY Messages print in the summary section at the end of the
report.
*BOTH Messages print in the body of the report and at the end of the
report in the summary section.
Output queue (OUTQ)
Specify an output queue to place the merge report.
*JOB Uses the output queue associated with the job.

Name Specify an output queue name.
Library (Output Queue)
Specify the library the output queue is located in.
Name Specify a library for the designated output queue.

*LIBL 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.
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).
*NO The report runs interactively.
Job description (JOBD)
Specify the name of the job description used for the submitted job. The
default value is MWIJOBD.
Library (Job description)
Specify the library the job description resides in.
Library-name Type a specific library for the job description.

*LIBL Searches the library list for the specific job description.
407
Merge Member Merge Report Listing
Lines with blanks under the Action and File headings were functionally
equivalent in all three, source members. The actual selected source line
originates from the member specified by the Merge basis (Enhanced-1 in
the above example).
New sequence lines 6 through 11 indicate two possibly dependent changes

that must be manually merged.
The shaded lines containing a 3+ (New sequence: 12 and 25) were

identified as equal (or functionally equivalent) in the Production and
Enhanced versions.
The shaded line new sequence 13 was included because the Production
version was identified as functionally equivalent (although different).
Merge Member Report Field Descriptions

The following fields display on the Merge Member Report.
New Seq(uence)
This is the sequence number in the Target source member. If a message

was generated for the preceding lines, the Message ID is listed in this
column and an asterisk is printed at the far-left side of the report.
Action
There can be one of two entries in this column: INC (include in Target
source member) or EXC (exclude from Target source member). INC
indicates a line that was not in the Base version, but was added in one or
more of the Production and Enhanced versions. This line is added to the
Target source member. EXC indicates a line that exists in the Base version
and either the Production version or one of the Enhanced versions. This
line is not in the Target Source member.
If changes exist from two or more versions at the same place in the source
(INCludes and/or EXCludes), the function issues a message and all sets of
changes are incorporated into the Target Source member. You must review
these situations to identify whether the changes are compatible, mutually
exclusive, or if they must be blended.
Where this column is blank, the same line existed in all versions.
File
Indicates where the line of code is either included or excluded. The entry
here is one of the codes from 1 to 7, corresponding to the different versions
listed at the top of the report. If there is no entry in this column, the line
409
shown comes from the Merge Basis source member. A plus (+) sign printed
to the right of the file code indicates if a line was included from the
Production and one of the Enhanced members.
Org Seq (Original Sequence Number)
This is the sequence number that an included line had in its original
member.
On report lines listing action messages, three asterisks appear in this

column.
Source Data
Under this heading are the actual lines of source. If a line was excluded
from the Target (see Action above), the function inserts an arrow into the
line, and moves the source over a designated number of spaces to the right
as specified on the Execution Options.
Note that when comparing source lines in RPG and DDS source, Merge to
Create Target Source can ignore the characters in positions 1 through 5.
Action messages
On report lines that have action messages, the message severity followed
by the message text are shown in the Source Data section.
Records
The number of records in the corresponding source member.
Include
The number of records unique to the corresponding version.
Exclude
The number of records in the corresponding version that are not in the
target version.
Matched
The number of common records between all versions.
The percent of records matched.
Func equiv (Functional equivalence)
The number of records adjusted by functional equivalence processing.
Exec
The number of executable lines included in the Include and Exclude

counts.
Blank
The number of blank lines included in the Include and Exclude counts.
Comment
The number of comment lines included in the Include and Exclude counts.
411
A P P E N D I X
Glossary B
action An action is used to indicate what process will be performed on a member/
object. The action is specified when checking out a member/object and
when creating a request for a member/object. The following actions are
valid for checking out and for creating a promotion request.
1 = Change
2 = Create
3 = Delete
8 = Regen (only valid for COOL:2E model objects)
9 = Recompile
application path The term application path refers to the standard and emergency paths that
are set up in Work with Projects and Work with Environments.
Application paths are used in the development cycle to define the flow of
member/objects between environments. They are used to determine the
location of source and related objects for an object, for example, when
compiling with a check out or create request action of recompile.
There are two basic types of application paths:
Project path: This term refers to the standard and emergency paths
that are set up in Work with Projects. A path can be defined for each
project, representing the development flow of member/objects
associated with the project. This type of path is beneficial for those
who routinely use multiple testing environments, particularly when
the test environments are determined on a project-by-project basis. For
example, if two projects are active in development, it is typical that
one environment path is used by one project and another environment
path is used by another project at the same time. By using a project
path rather than an environment path, you can avoid having to
perform overrides when checking out and promoting items associated
with one project that may not be associated with the second project.
Environment path: This term refers to the standard and emergency

paths that are set up in Work with Environments. A path can be
defined for each production environment, representing the
413
application set
development flow of member/objects associated with the

environment. Environment paths can provide control while
eliminating redundancy when checking out and promoting.
An authorized user (usually the System Administrator) defines the exact

flow objects take—from the time they are checked out from the production
environment, through the development and testing environments, and
finally back to production.
A path restricts access so that the members/objects cannot move outside of

the defined flow. This allows defaulting of the check out from and to
environments, as well as the default promotion request from and to
environments. Users can be restricted to the defined paths, preventing any
circumvention of the predefined flow of work back into production, or
they can be authorized to override a default path.
In the Check Out and Create Request functions where application paths
are used, a project path precedes an environment path. In other words, if a
project is specified that has a defined path, that path is used; otherwise, the
environment path is used.
NOTE
The term application path should not be confused with the term path, which
refers to support provided by for IFS objects.
application set An application path refers to AS/SET application sets. It is a partition of the
ADK product where definitions such as programs, data models, files, and
fields are stored. An application set refers to an environment such as
development or production, where copies of the application definitions are
stored.
archive recovery Archive recovery is a function used to recover from or back out of a
promotion request. It is also called rollback.
archiving Archiving is a function that duplicates an existing production source

member, object, or file (without data) into a designated library, before the
object to be implemented is moved into production. You use the archive to
store members and objects or file information. Members/objects are placed
in the archive during the Move Request function. Archiving is optionally
enabled, at the environment level. You can archive up to 99 versions of
files, objects, and source.
The archive serves two purposes. The first is to support Archive Recovery
or Rollback of a request. Second, the archive can be used to browse
previous versions of a source member.
batch programs for AS/SET
batch programs for Batch programs for AS/SET are an ADK program type designed to perform
AS/SET file-processing functions.
No on-line display panels are involved in batch programs.
binding directory A binding directory is a list of module names and service program names
that may be needed when creating an ILE or Service program. It is not a
repository of the modules and service programs; rather it allows them to be
referred to by name and type.
change controlled A change controlled model is a COOL:2E model that is set up to work with
model COOL:Xtras CM. Its model value *CHGCTL is set to be that of the
COOL:Xtras CM product library.
change list A change list is a COOL:2E model object list defined in COOL:Xtras CM.
You can explicitly create a model object list for a given COOL:2E
environment or create one when you check out a COOL:2E model object
during an editing session. This is referred to as a model object list in
COOL:Xtras CM.
check in Check in describes the process of promoting a member/object back into

production after it has been checked out and the lock is removed.
check out Check out takes a member/object from a production environment (or
quality assurance environment), copies it to a developer’s development
library or environment, and places a lock on it. This makes the member/
object in use by the user who checked it out.
clipboard The clipboard is a list of items. The clipboard allows you to select a list of
items and then process that list by another function. The clipboard holds
the selected items until they are processed. Once you have added an item
on the clipboard, you can display, remove, or add more items to the
clipboard. At least one item must exist on the clipboard before you can
process a clipboard function. Once you process the function for the items
on the clipboard, the items on the clipboard are listed within that function.
compile requests Compile requests is a function that compiles source members into work
libraries and moves non-source-based objects into object work libraries,
according to migration request instructions. Developers normally perform
this task.
concurrent Concurrent development is when two or more versions of a member/object

development exist at the same time. When concurrent development occurs, the multiple
versions of the member/object are considered in conflict with each other.
The ability to check out a member/object for concurrent work can be
restricted to certain users. Concurrent development results when you
check out a member/object that is already checked out.
415
conflict
conflict When concurrent development is started, a conflict is created for that

specific member/object. Conflicts must be resolved before a member/
object can be promoted.
constraint A constraint is a set of rules that defines the relationship between two files.
For example, a constraint can be used to maintain the integrity between a
customer header file and a customer detail file, by not allowing changes to
the header table file without changing the detail file. See trigger.
create request Create request is the function of initiating a promotion request to migrate
source and/or objects to production or quality assurance environments.
Developers normally perform this task.
currency Currency is a COOL:2E model object that all other related model objects
point to; an object that has usage. A non-current object has no usage in the
model.
current model object The current model object is what you can view or edit in the COOL:2E
model. Multiple versions of the model object can be checked out to and
accessible from one or more model object lists. However, only the current
version displays in the model.
data model A data model is an entity defined in ADK repository that refers to one or
more files, their associated fields, and their associated relationships.
design request A design request is a DesignTracker feature used to indicate what work
needs to be done. DesignTracker is automatically installed when you
install library MKSIM.
design request A design request approval can be:

approval
0 = No
1 = Yes
2 = Pending
For an approval type of:
1 = Development
2 = Test
3 = Production environment
design request The design request disposition can be:

disposition
0 = Not Ready (always set to 0 when entity is added to the list)
1 = Ready for checkout (entity is ready to be checked out)
design request status
2 = In development (entity is checked out and in development)
3 = In quality assurance (entity is checked out and in QA for testing)
4 = Completed (entity was moved into a *PRD environment)
design request status The design request status is the current state of a design request. The
Implementer entity controls related to design request status are: Allow
ready to check out, Allow check out, Allow promotion to a test
environment, and Allow promotion to a production environment.
There can be different approval types per user:
1 = Development
2 = Test
3 = Production
Upon approval from all designated users, the status can be automatically
changed by DesignTracker. You set up the approval/status relationship in
DesignTracker System Control.
directory See IFS directory.
DLO Document Library Object (DLO) refers to a file or folder that exists in the
QDLS file system.
These objects, referred to in Implementer as IFS objects, are supported for

change management. See IFS object, IFS file, and IFS directory.
document Document is a term that is used as part of support provided for IFS objects.
A document is a special type of file created by OfficeVision/400 and stored
in the QDLS space. A document is a file, but a file is not necessarily a
document.
It is the OS/400 term for any object residing within an IFS folder on the
iSeries 400. Within Implementer, the term IFS object is used.
environment An environment identifies a collection of libraries, object owners,

authorized users and rules about how these libraries are controlled by
Implementer. See related environment.
environment ID An environment ID is the sequential number assigned to each target

environment on a promotion request. This number, which starts at one and
increments by one, is used for naming some libraries, save files, and other
objects used as part of the promotion request.
417
environment library list
environment library An environment library list is a list of up to 250 libraries used for compilation
list in the environment. Of these, 248 entries are available for your use. The last
two entries are reserved for QTEMP and the Implementer work library on
the promotion request. In addition, the environment library list is used
when processing special commands for the request.
environment type Environment type is a field that defines whether an environment is for
production (*PRD), quality assurance (*QAC) or testing (*TST). This
ensures that the development staff does not attempt to copy members/
objects from one production environment to another.
export An export is the process of saving LANSA objects into a device or save file,
to move them from one LANSA partition to another, on the same or
different machine.
export list An export list is a named list of LANSA objects to be exported from one
LANSA partition to another. There are two types of lists provided by
LANSA: One is visible to LANSA users and maintainable within the
LANSA menu. The other is not visible to you, but provided for object
management, system vendors. An export list is created in Implementer
whenever it copies LANSA objects from one partition to another partition.
file The term file is used as part of the support for traditional OS/400 database
files and the objects in the IFS referred to as IFS files. To avoid confusion,
whenever an IFS file object is referred to in Implementer, it is referenced as
an IFS file.
Implementer supports all traditional OS/400 files. For example, SQL

tables, indices, and views, physical files, logical files, display files, message
files, and printer files. See IFS file.
folder The term folder is used as part of support provided by Implementer for IFS
objects. It represents the IBM OS/400 term for a collection of documents in
a single location. This term corresponds to IFS directory, which is the term
used within Implementer. See IFS directory.
function The term function describes a particular COOL:Xtras CM menu option or

command. For example, the Activity Report function refers to the
interactive menu option activity that prints the Activity Report and the
submitted job that prints the report.
A function is also a specific type of COOL:2E model object that can be

promoted (FUN); an executable program, or collection of programs.
function redirection
function redirection A function redirection is when a COOL:2E function is checked out and a new
version of that function is created, function redirection occurs to ensure
that the selected version of the model object is current and has its internal
references directed towards the other object in the model. See currency.
IFS directory The term IFS directory is used as part of support provided by Implementer
for IFS objects. The IFS directory is the location of an IFS file. When used in
this capacity, the directory usually refers to the full directory path. See
path.
This term corresponds to the OS/400 term, folder. In Implementer, these are
referred to as directories.
IFS file The term IFS file is used as part of support provided by Implementer for
IFS objects. It refers to the contents of IFS directories on the iSeries 400. It is
the PC term for any object stored in a directory. Some examples of files are
executable programs, database files, or video segments.
Within Implementer, the member/object name for an IFS file contains the
IFS file name and the object code contains the dot and extension. If the file
name has no extension, the object code is just represented by a dot. Any
name longer than eight characters is converted, and any extension longer
than six characters (allowing one position for the “.”) is converted.
For example:
IFS File Name Member/Object Name Object Code
HelloAS400World.class HELLOAS4~1 .CLASS
HelloAS400World HELLOAS4~1 .
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 environment’s directory (including files and subdirectories and
their contents) specifying *.* as the object name, and a backslash (\)
as the object code. For example, if you check out or promote IFS\dir
using the *.* specification, all IFS files and directories in IFS\dir
would be included. Reports and audits would show member/object
*.* to indicate that all contents were affected.
implementation object An implementation object is the resulting OS/400 source and objects that are
created from the generation of a COOL:2E model object. For example, a
function will usually create source and objects for a program, display file,
and help text. The source and objects generated for these objects are
referred to as the implementation objects.
Implementer Receiver The Implementer Receiver is a component of Implementer that resides on

each remote system that changes can be distributed to.
import An import is the process of restoring LANSA objects from a device or save
file created in an export activity into a different partition.
issues Issues are a feature of Integrity Manager. They are used to track changes in
the software development cycle. For example, your administrator can
configure Integrity Manager in a way that a problem issue may be
associated with a solution issue for easy tracking and monitoring of both
issues. Each issue has an audit trail, which may be used to evaluate internal
processes for the effectiveness of the problem resolution process. In effect,
issues track all aspects of any engineering endeavor.
JDE JDE stands for J.D. Edwards.
JDE data dictionary JDE data dictionary elements represent a record in the dictionary for every
elements field used in the system. This file controls how a field acts and edits on the
screen and report. In addition, it controls the edit processes of the field for
validation.
JDE dream writers
JDE dream writers JDE dream writers have two parts that break down as follows: data selection
that is translated to OPNQRYF or logical file, and processing options that
are user-controlled program passed parameters.
JDE menus JDE menus are data records keyed to a menu name. This allows changes to
menus without the need of programming.
JDE soft coding or JDE soft coding or vocabulary overrides are literals on JDE screens that are not
vocabulary overrides 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 JDE software inventory or member master is a file where a record for each
inventory or member object in JDE is kept. This file contains the general severity level for
masters compilation and other details for JDE.
JDE special objects JDE special objects are objects supported by J.D. Edwards such as user-
defined codes, DREAM Writers, Member Master, Data Dictionary, Soft
Coding, and Menus.
JDE traditional objects JDE traditional objects are traditional objects that require J.D. Edwards
compiling, for example, RPG programs, CL programs, Assemblers (ASM).
JDE user-defined JDE user-defined codes (UDC) is a generic table system for data field
codes (UDC) validation, controlled by three keys:
1—System number
2—Table name
3—Element
keyword restriction A key restriction is a facility that restricts access to command keywords of
an object code. It is used to restrict sensitive keywords such as the User
Profile (USRPRF) keyword that controls adopted authorities.
LANSA function A LANSA function is an executable OS/400 program defined by you and
created by LANSA.
LANSA objects LANSA objects are objects created in LANSA such as files, fields, processes,
and functions. These objects are not necessarily OS/400 objects.
lock A lock is applied to a member/object when it is checked out. It is

automatically released when the member object is promoted to a
production (*PRD) environment.
A Standard lock is the user action that created the lock through a
standard check out.
421
member/object
An Emergency lock is the user action that created the lock through an
emergency check out.
member/object A member/object is an item under Implementer control. This can be an object

or source stored in a library, an element managed by a CASE tool (such as
COOL:2E), or an IFS file. For example, this refers to an object for a data
area, but for an RPG program, this refers to the member and object.
model object A model object is a COOL:2E object that can be checked out. COOL:2E has
eight types of objects that can be checked out. They are access paths (ACP),
applications (APP), arrays (ARR), conditions (CND), field (FLD), files
(FIL), functions (FUN), and messages (MSG).
model object list A model object list is a COOL:2E feature that allows some of the objects in a
model to be grouped together in a named list. For change control purposes,
model objects are checked out to lists to indicate a change was made or will
be made to the objects. The model object lists are attached to the COOL:2E
model and can be selected for COOL:2E promotion requests.
NOTE
Once you use a model object list for check out, it becomes a change list.
model object name A model object name is the 25-character name given to a COOL:2E model
object.
move request A move request is the task that moves all object/sources from the
environments or libraries to the target environments. In addition, it
performs any request instructions that impact production data (for
example, MRGMSGF). This function moves previous versions of source
and objects to the archive libraries before the move, if specified.
My Workbench The Workbench is a panel where a developer can perform all necessary
development work. The panel contains the items to be worked on, and
provides access to all necessary tools to complete the development of the
items and move them off the Workbench. The tools allow you to select and
add items to the Workbench, access standard development tools to edit,
compile and test items, and access user-defined tools through user-defined
options. From the Workbench, you can access promotion functions to
move completed items back into production, and book time against
projects.
object code
object code An object code is used to define a type of object or member to be promoted.
The object code in Implementer combines information from the OS/400
object type and source type. For IFS files, the object code is the file
extension. Object codes are user-defined.
owning model object An owning model object is the name of the model object that owns another
model object. For example, a file (FIL) object always owns an access path
(ACP) model object. Not all model objects have an owning model object.
partition A partition is a division of a LANSA system that has it’s own field
references, files, and processes. Each partition in LANSA is completely
independent and no cross-referencing is allowed across partitions. A
partition in LANSA is comparable to an environment in Implementer.
path The term path is used as part of support provided by Implementer for IFS
objects. It represents the location of a directory or subdirectory. It is the
complete list of all directories and subdirectories between the root
directory and the directory being identified. The subdirectories in the path
are separated by a backslash (\).
For example, to identify the path of the SYSTEM directory, which is nested
in the WINDOWS directory, which stems from the root directory, the notation
would be \WINDOWS\SYSTEM. (See qualified name and application path).
Implementer supports three paths in the IFS structure:
Project relative path is the portion of the path that is unique to each
object in the environment path.
For example: \SUBDIR\PROGRAM.EXE
Environment path is the path specified at the environment level and is

common to all IFS objects in that environment.
For example: \MKS\DEMO\PRD\INVENTORY
Full path is the environment path appended to the project relative

path.
For example: \MKS\DEMO\PRD\INVENTORY\SUBDIR\PROGRAM.EXE
NOTE
Be aware of the distinction between the term path and the term application path,
which refers to standard or emergency paths for a project or environment.
423
primary target environment
primary target A primary target environment is the first environment in a series of multiple
environment target environments. The primary target environment is used in Create
Request to check the existence of the target members/objects (to determine
if the action for a member/object should be Create or Change).
process A process is a logical group of related functions. For example, a process

called ORDERENTRY consists of multiple functions such as sales order
maintenance, credit limit check, and sales order print.
project Projects are used in Implementer to document why a change is made. A

project reference can be used to check out and promote a member/object.
promotion Promotion takes members/objects from one environment (or library) and
moves them forward to a target environment. In addition, the term refers
to the whole process of returning a member/object back into production
after it has been checked out (compile and promote from Development to
QA, and QA to production).
promotion request A promotion request is a collection of related source members, source-based

objects, non-source based objects, or non-OS/400 objects to be promoted to
production libraries or quality assurance.
qualified name The term qualified name is used as part of support provided by Implementer
for IFS objects. It represents the path and file name.
For example, the qualified name of the SYSEDIT.EXE file stored in the
WINDOWS\SYSTEM directory is \WINDOWS\SYSTEM\SYSEDIT.EXE.
related environment Related environment is the relationship of an environment to other

environments, in the format of an ordered list. This relationship is defined
in Work with Related Environments. Related environment information is
used in check out to display the member/object lists and related objects in
different related environments. It uses the same order (sequence) to find a
member/object in the list.
repository Repository is an entity within the ADK product where you can create and
maintain files, fields, data models, and reusable program specifications,
such as action subroutines.
requester A requester is the user who creates a promotion request.
request number A request number is the unique alphanumeric value assigned by

Implementer when a new promotion request is created. It is used to
identify the promotion request.
request status
Beginning with 0001, the number increments by 1 for each new promotion
request until number 9999 is reached. When this occurs, the left most
position begins with an alpha character and the other positions reset to 0
(zero). Reading from right to left, the cycle continues until each position
goes through the range 0–9 and A–Z. When the number ZZZZ is reached,
the scheme automatically resets to number 0001.
request status Request status describes where a promotion request is within the promotion
cycle. It describes what steps have been performed for the request and
what remains to be done.
required objects Required objects are traditional source and executable objects generated
from AS/SET program definitions. This contrasts to the related object
concept used for traditional objects that, for example, relates logical files to
physicals and to the programs that refer to them.
reset authorities Reset authorities is an Implementer function that revokes all object
authorities for the libraries as specified in the environment, then grants
object authorities based on the authorities from the environment authority
table.
session model list A session model list is the default model object list assigned to you when you
begin a COOL:2E editing session. This model object list usually defaults to
your OS/400 user profile. You should not use the default session model list
as a check out model object list. Instead, change the default value using the
Edit Model Profile Editing options on:
the Access to model field value of *DSNR on the Change User Capabilities
panel, the COOL:2E Designer (*DSNR) menu, or make the model users
create and use their own object model list.
stage library A stage library is an Implementer work library used to prepare (stage) each
object before it moves into the target environment. The setting of object
authorities, physical and logical members, and database file data occurs
while the object is in this library. A stage library exists while the move is in
process.
step A step refers to one of the up to four phases required to complete a request.
They are (in order) Model copy (if a COOL:2E environment) or Export (if a
LANSA environment), Compile, Distribute, and Move.
The Model copy step only applies to COOL:2E special environments.
The Export step only applies to LANSA special environments.
The Compile step is optional.
425
subdirectory
The Distribute step only applies to requests that contain remote target
environments.
The Move step is required for every request.
subdirectory This term subdirectory is used as part of support provided by Implementer

for IFS objects. It refers to a directory and its contents that are stored within
another directory. This term corresponds to the OS/400 term, folder. In
Implementer, these are referred to as directories. See IFS directory.
surrogate A surrogate is the internal identifier to each COOL:2E model object.
target environment A target environment group is a group of environments promoted to

group simultaneously. The target environment groups are used when you create
a promotion request to display more than one environment. The target
environment group eliminates the need to select each environment every
time a promotion request is created.
trigger A trigger is a set of actions that are executed automatically whenever a

specified event occurs to a specified SQL-based table. An event can be an
insert, update, or delete operation. The trigger can be run either before or
after the event. Triggers are used to preserve program to table integrity, by
checking on or changing data in a consistent manner. They help to
maintain the integrity of a database by preventing incorrect, unauthorized,
or inconsistent changes to data. See constraint.
version For COOL:2E environments, a version is a copy of a model object that is

created in the same model. Only functions (FUN) and messages (MSG) can
have multiple versions or are versionable. Versions are created by
COOL:Xtras CM when you check out a model object that is previously
checked out and when archiving occurs during the move step.
version group A version group consists of all of the versions created for a model object.
Only one version in the version group will be the current version.
workbench See My Workbench.
work library A work library is a temporary library Implementer uses during promotion
to help ensure the orderly movement of objects and source into the correct
target libraries. The work libraries only exist while a promotion request is
still open (the status is not complete).
Index
AOS Message Manager integration 380

Symbols Application path
*DTAARA object type defined 413
related objects 139, 167 feature overview 19
*FILE object type project paths 107
related objects 139, 167 Application set
*PRD environment type 40 defined 414
*QAC environment type 40 Archive library 296
*TST environment type 41 Archive recovery 300
defined 414
of related requests 204
A with object version stamping 252
ABSTRACT integration Archive reports
access from Implementer 378 Archive History Report 26
overview 378 Archives by Environment Report 299
user-defined options 378 Archives by Request Report 299
using ICHKOUT command 156 Archives per Tape Report 299
version requirements 378 Archive to tape 297
Action change volume ID 299
change 98, 137, 147, 181, 350, 413 menu (IMARCTAP) 297
check out 120 reports 299
create request 194 restoring 299
create 98, 194, 350, 413 saving 298
defined 413 Archiving
delete 98, 350, 413 check out 303
check out 121 COOL:2E model objects 303
recomp 98, 201, 256, 261, 262, 413 design request 303
regen 98, 348, 350, 413 environment 303
Activity Report 25 LANSA objects 303
Add to Clipboard (IADDCBD) command 60 library 303
Add to Clipboard IFS (IADDCBDIFS) project reference 303
command 60 defined 414
Adopting authority 21 environment library 42
Advanced System Concepts logical files 264, 296
(ABSTRACT) 378 multiple target environments
Allocating objects multiple objects 296
during move step 225 object renaming 296
American Software integration object version stamping in rollback 252
compiling Cobol programs 330 objects not compiling source 300
message file considerations 330 physical files 264
object codes for checkout and promotion internals 264, 296
promotion 329 promotion request created during 300
overview 329 same library, multiple
427
Index
environments 296 Before you begin 1

single change or entire request (multiple Binding directory
objects) 300 defined 415
source BPCS integration
compiling 300 compiling 223
renaming 296 overview 336
tables and physical files 296 Build List
usually production only 296 for changed members 194
AS/NET integration 381 results in check out 115
AS/SET integration Build member/object list, see Build List 45
archiving definitions 335
AS/SET commands 335
checking out 331 C
commands 335 Capabilities
definitions
restricted 43
special characteristic 118
user 43
dependency checking 332
Change
override promoting generated source/
overview 53
object 336
Change controlled model, defined 415
overview 330
Change delimiter
promoting 334
IMRGMBR parameter 406
remote distribution 335
Change list, defined 415
X file management 182, 335
Check In
Authority
defined 415
environment information to objects 42,
Check Out
43
adding related objects 139
LANSA Export/Import 152, 205
AS/SET definitions
OS/400 security 19
special characteristic 118
security administrator rights 38
assign revision numbers 122
MWIPROD 38
comment 123
QSECOFR 38
concurrent development from
security risk
Workbench 69
object codes 188 COOL:2E model object lists 342
user 151
create member/object during 121
Authority method
defined 415
toggle 189 emergency
Authorization list
from Workbench 69
environment information 43
one step method 305
for concurrent development 136
for reject 116
B from Clipboard in Workbench 69
Base file ICHKOUT command 156
ICMPMBR parameter 387 IEXCCKOCMD special command
IMRGMBR parameter 399 overview 245
Base member substitution variables 233
ICMPMBR parameter 386 IFS files and directories 127
IMRGMBR parameter 398 methods
Batch overview 113
create request in batch 173 where defined 113
Batch programs multiple objects single source 123
in AS/SET, defined 415 multiple occurring mbr/obj 140
Index
object name rules 155 command 60

object version stamping 125 add items with IADDCBD command 60
one step method create requests with ICRTRQS
determine default from command 63
environment 113 defined 415
from Clipboard 58 one step check out and promotion 58
from Work with Objects 113 positioning in a subfile 59
overriding 68 processing with IPRCCBD command 63
overview 53 CODE/400 integration 337
PDM option 162 Cognos (Powerhouse) integration 376
physical file data 150 Commands 245
related environments 120 CHGRMTRQS Change Remote
related objects 139 Request 281
restricting 112 IADDCBD Add to Clipboard 60
object codes 112 IADDCBDIFS Add to Clipboard IFS 60
user capabilities 112 ICHKADKDEP Check AS/SET
select environment 118 Dependencies 332
select items after initiating, from ICHKOUT Check Out 156
Workbench 66 ICMPLRQS Complete Request 254
single source multiple objects 123 ICMPMBR Compare Members 386
special commands 112, 233, 245 ICMPRQS Compile Request 224, 256
stamp objects with issue or DR ICOMPILE Workbench Compile 79
number 125 ICRTRQS Create Request 63, 196, 260
status 346 IDLTLIBREF Delete Library
substitution variables 233 References 98
task IEXCCKOCMD check out special
check out for concurrent command 112
development 136 IEXCCKOCMD special command 231,
create member/object 121 245
delete member/object 121 IEXCRQSDTL promotion special
ICHKOUT command 156 command 230, 236
ICHKOUT command via IMARCTAP Archive to Tape 297
PathFinder 162 IMOVRMTRQS 256, 289, 290
ICHKOUT command via PDM 162 IMOVRQS 228, 256
related objects 139 IMRGMBR Merge Members 398
single source multiple objects 123 IPRCCBD Process Clipboard 63
using the menu 112 IRSTRMTRQS Restore Remote
traditional, from Workbench 66, 113 Request 289
using different source and object ISETLIBL 54, 83
names 151, 219 RMVDIR Remove Directory (IFS) 217
using ILE object codes 148 STRCM Start COOL:Xtras_CM 12
using PathFinder 167 STRCR Start COOL:Xtras_CM
web-based, for IFS objects 135 Receiver 12
with design request 141 STRIM Start Implementer 12, 13
Work with Objects, from Workbench 67 STRIR Start Implementer Receiver 12
Check Out (ICHKOUT) command 156 WRKMBRPDM Work with Members
*PATH default 157 using PDM 78
Check Out (ICHKOUTIFS) command YANZMDLLST 352
*PATH default 131 YCHKMDLCRT 353
CHGRMTRQS command 281 YCPYMDLOBJ 352
Clipboard YCVTCNDVAL 354, 355
add items with ADDCBDIFS YCVTMDLMSG 354, 355
429
Index
YEDTMDL 357 command 255

YEDTMDLLST 348, 357 Completed, status 259
YPRMMDLLST 352, 354 Compress blanks
YSBMMDLCRT 353 ICMPMBR parameter 389
Comments CompFail, status 258
bypass in create request 87, 175 CompJobq, status 258
in check out 123 CompPend, status 258
Compare Members (ICMPMBR) CompRun, status 258
command 386 CompSchd, status 258
Base file (BASEFILE) 387 Concurrent development 112
Base member (BASEMBR) 386 check out for 136
Compare to file (CMPFILE) 387 requests
Compress blanks (COMPRESS) 389 defined 415
End column (ENDCOL) 390 Concurrent Development Report 25
Exclude blank lines (EXCBLKLINE) 389 Conflict requests
Exclude comment lines defined 416
(EXCOMMENT) 389 Conflict resolution
Hold spooled files (HOLD) 391 before promotion 172
Output queue (OUTQ) 390 Constraint
Print options (PRTFILTER) 390 defined 416
Source type (SRCTYPE) 387 Constraints
Start column (STARTCOL) 390 in promotion 313
Workbench 78 Conventions 4
Compare to file COOL:2E
ICMPMBR parameter 387 check out
Compile command parameters 187 not to COOL:2E session list 344
Compile listings status 346
promotion internals 263 commands
Compile request YANZMDLLST 352
defined 415 YCHKMDLCRT 353
from Workbench 79 YCPYMDLOBJ 352
ICMPRQS command 224, 256 YCVTCNDVAL 354, 355
overview 53 YCVTMDLMSG 354, 355
start member after comp-fail 223 YEDTMDL 357
submit compile request 220 YEDTMDLLST 348, 357
Compile step YPRMMDLLST 352, 354
change job queue during 187 YSBMMDLCRT 353
command parameters 187 managing EXCUSRPGM and
default compile order 174 EXCUSRSRC 359
library list considerations model considerations
environment library list 44 analyzing model list 352
for vendor integration 44 change list 344
object version stamping 220 check out 342, 347, 350
order concurrent development 349
based on object code sequence 174 COOL:2E to traditional 354
promotion internals 262 create request 352
QCMDEXC program 188 development activities 345
retain printer attributes 188 explicit checkout 348
with vendor integrations 223 generating and compiling 353
work library 222 impact analysis 359
Compiling 21 implicit checkout 348
Complete Request (ICMPLRQS) model object lists 342, 343, 344
Index
move step 354, 355 Current model

object naming 345 defined 416
promoting model information 351 Customer Support options 5
regeneration 348
remote considerations 363
updating target model 352 D
use change controlled model 356
Data areas
versionable model objects 349
environment library considerations 41
model library 41
IMEMGSTP emergency submit through
model value
step 252, 306
YFRFVNM 355
IMMULTOBJ 123
YMSGVNM 355
IMREJECT 153
YSYSCHG 342
IMWRNTRGLF 316
session list 344 ITAPEVOLUM 299
COOL:Xtras CM, see COOL:2E 342
LFREFOBJ 43
Create Object (CRTOBJ) command
PFREFOBJ 43
Job description (JOBD) 391, 407
promoting data area values 318
Submit (SUBMIT) 391, 407
Data conversion programs
Create Request
environment library list 229
add target environments 199
Data models
change compile commands 187
defined 416
copy request 195
Database
create requests in batch 173
default library 41
defined 416
Database files
from Workbench 86
environment 45
ICRTRQS command 63, 196, 260
Database management
member list 193
DDS files
methods, where defined 174
optimize PF promotions 313
object code list 192
process overview 312
one step promotion
promoting logical files 316
access Create Request panel 176
promoting physical files 313
triggers and constraints 313
overrides
change request defaults 205
SQL
job submission defaults 186
archive and recovery of SQL DDL
objects 310
remove items in from
build list consideration 310
environment 205
creating source SQL logical
PDM option 198
files 312
creating source SQL physical
promotion groups 85
files 311
evaluation 85
managing non-source SQL 309
promotion methods
object codes for non-source
one step promotions 175
SQL 309
traditional promotions 177
object codes for source SQL 311
selecting from locks 189
special commands 229 DDM management
task 178
special commands for 230, 240
Create step
Delete
promotion internals 260
member/object at check out 121
Currency
Dependency checking 139
defined 416
431
Index
Design Request End column

approvals, defined 416 ICMPMBR parameter 390
change, from Workbench 101 IMRGMBR parameter 402
check out 141 Enhanced members
create promotion request 172 IMRGMBR parameter 400
defined 416 Entity List
disposition, defined 416 select member/object 144
entity list Environment administrator
select member/object 144 capabilities 44
promotion 172 multiple administrators 44
stamp object with DR number 125 Environment Groups 45
status, defined 417 Environment path
use multiple DRs from Workbench 99 defined 414
DesignTracker Environment Report 26
Design Request, defined 416 Environments
entity list 144 archive library 42
Developer defined 417
creating promotion requests 181 Environment ID
role defined 39 defined 417
Development environment type 41 groups 45
Directory integrity check 45
defined 419 libraries 41
Display files library list
move step considerations 225 defined 418
Distribute Request by System library list considerations 44
task 273 object code information 45
Distribution overview 40
by system 273 related 120, 140
Distribution step 256 multiple occurring mbr/obj 140
DistFail, status 259 related, defined 424
DistJobq, status 259 source files 42
DistPend, status 259 special commands 22, 229
DistRun, status 259 types 40
DistSchd, status 259 defined 418
DLO Establish environment authorities, see Reset
defined 417 Authorities 42
Document conventions 4 Exclude blank lines
ICMPMBR parameter 389
E ICMPMBR parameter 389
Emergency Excluded lines indentation
archive recovery 295, 300 IMRGMBR parameter 406
EXCUSRPGM considerations 360
auto check out 302
check out 295 EXCUSRSRC considerations 360
Export
from Workbench 304
defined 418
one step method 305
create request 295, 306 Export List
from Workbench 306 defined 418
Expt-Fail, status 258, 370
create request submit through step 306
promotion request 252 Expt-Jobq, status 258, 370
Expt-Pend, status 258, 370
promotions 252
Expt-Run, status 258, 370
Index
Expt-Schd, status 258, 370 overview 52

IDLTLIBREF Delete Library Reference
command 98
F IEXCCKOCMD command 112, 231, 245
File IEXCRQSDTL command 23, 230, 236
IFS
defined 418, 419
auto-create object code 212
Files
directory upgrade during
join logicals 189
promoting field reference files 174 promotion 216
objects
promoting logical files 316
auto create object code 134, 215
promoting non-source SQL tables 309
checking out 127
promoting physical files 313
java optimization 218
Folder
promoting 212
defined 418
support for 18
Function
using mounted drives 18
defined 418
web-based check out 135
Function keys
web-based promotion 213
work with, menu option 291
IFS directory
Function redirection
defined 419
defined 419
IFS file
defined 418
IFS object
G defined 419
Getting help 5 ILE
Glossary 413 converting RPG source code 163
enhanced support for 18
managing ILE development 319
H object codes for check out 148
Hawkeye Systems, Inc. (PathFinder) IMARCTAP command 297
integration 382 IMCMEX01 exit program 350
Highlight excluded lines IMEMGSTP data area 252
IMRGMBR parameter 406 IMMULTOBJ data area 123
Hold spooled files IMOVRMTRQS command 256
ICMPMBR parameter 391 IMOVRQS command 228, 256
IMRGMBR parameter 407 Impact analysis 20, 139
Implementation object
defined 420
I Implementer Receiver
defined 420
IBM (NetView/DM software) 381
menu 287
ICHGRQSDTL Change Request Detail Import
command 245 defined 420
ICHKOUT Check Out command 156
IMPRFX data area 266
ICMPLRQS Complete Request command 254 IMREJECT
ICMPRQS Compile Request command 224,
data area 153
256
IMWRNTRGLF data area 316
ICOMPILE Workbench Compile Integrated File System, See IFS 419
command 79
Integrity Manger
ICRTRQS Create Request command 260
using for issue management 9
via PDM 198 ISETLIBL command 54, 83
Identify work
Issue management solutions 8
433
Index
using DesignTracker and Integrity compile step 223

Manager 10 Implementer jobs 256
using DesignTracker, stand-alone 8 Journaling
using Integrity Manager and database files 264
Implementer 9 logical files using MIMIX 316
Issues physical files using MIMIX 315
stamp objects with issue number 125
ITAPEVOLUM data area 299
K
Keyword restriction
J defined 421
J.D. Edwards KnowledgeNet (Net/Wrk400 software) 381
archive recovery 367
archiving special objects 366
data dictionary L
defined 420
Lakeview Technologies, See MIMIX 316
defined 421
LANSA 367
Dream Writer
archiving 370
defined 421
check out
integration overview 363
comment field 118
Menu
environment 118
defined 421
multiple functions 118
promoting printer files 366
object code 118
software inventory or Member Master
create request 369
defined 421
export list 175, 182
special objects
LANSA object in compiled
check out 365
form 175
create request 365
multiple functions 182
defined 421
object codes 182
naming User Defined Codes 365
promote compiled form 182
promotion 366
distribution
local environments 371
traditional object support 364
remote environments 371
traditional objects
export/import authorities 152, 205
defined 421 function, defined 421
user defined codes (UDC)
object, defined 421
defined 421
promotion 369
Java optimization, for IFS objects 218
JDE
save file name 371
defined 420
save files and libraries 371
Job description
Web components 367
CRTOBJ parameter 391, 407
Level check
MWIJOBD 44, 253, 256
adding related objects in promotion 207
batch programs 256
compiling 222
Job logging level in
library list defined incorrectly 44
System Control Maintenance 253
LFREFOBJ data area 43
Job logs 20
Library
audit trail information 253
archive 42
from promotion step 253 database default 41
number to retain 253
defaults, overriding 42
Job queue
development 41
Index
program default 41 command options, See Start Implementer

promotion work libraries 270 (STRIM) command 13
source default 41 Implementer Menu 12
stage 263, 264, 268 Implementer Receiver Menu 287
Library integrity check 45 Merge basis
Library list IMRGMBR parameter 402
environment 44 Merge Members (IMRGMBR) command 398
for compiling 222, 229 Base file (BASEFILE) 399
for special commands 44 Base member (BASEMBR) 398
for vendor integrations 44 Change delimiter 406
level check if defined incorrectly 44 End column (ENDCOL) 402
MKSIM library requirement 44 Enhanced members (ENHMBRS) 400
setup, from Workbench 83 excluded lines indentation 406
Lock from Workbench 79
defined 421 highlight excluded lines 406
Lock Report 25 Hold spooled files (HOLD) 407
Locking objects Merge basis (BASIS) 402
during move step 225 Merge output (OUTPUT) 402
Locks Output queue (OUTQ) 406
assign multiple DRs with lock 99 overview 398
changing 97 Print options (PRTOPTIONS) 405
deleting 98 Production file (PRODFILE) 399
removed on promote to production 112 Production member (PRODMBR) 399
Logging CL statements 253 Source type (SRCTYPE) 400
Logging level Start column (STARTCOL) 402
promotion step 253 Target file (TGTFILE) 405
Logical files Target source member (TGTMBR) 405
archiving 264, 296 Merge output
controlling remote promotions 316 IMRGMBR parameter 402
journaling 264 Messages
move step considerations 225 from promotion step 253
promotion internals 262, 263 MIMIX 381
Lotus Notes and Domino integration 376 journaling logical files 316
journaling physical files 315
MKSIM Implementer library 44
M Model object
defined 422
Maintain request 211
Manage locks Model object list
overview 54, 97 defined 422
Model object name 343
MCpyFail, status 259
MCpyJobq, status 259 defined 422
Model value
MCpyPend, status 259
YFRFVNM 355
MCpyRun, status 259
MCpySchd, status 259 YMSGVNM 355
YSYSCHG 342
Member/object
Mounted drives
defined 422
IFS on Windows NT Server 18
name rules 155
Move Remote Request (IMOVRMTRQS)
special considerations 318
command 256
status history 90
table of status codes 91 Move request
defined 422
Menus
IMOVRQS command 228, 256
435
Index
remote job scheduling 280 restricted per user 255

submit move 226 Object locking
Move Request by System during move step 225
overview 272 Object name rules
task 273 in check out 155
Move requests, on remote system 290 Object owner
Move step 224 environment information 42
promotion internals 263 promotion internals 264
MoveFail, status 259 Object version stamping 125
MoveJobq, status 259 in archive recovery 252
MovePend, status 259 in promotion 251
MoveRun, status 259 Objects
MoveSchd, status 259 remove in from environment 205
Multiple environments OS/400
archive library per 296 commands
Multiple paths ALCOBJ 225
environment on 46 CHGOBJOWN 230
MWIJOBD job description 44, 253, 256 CPYF 226
MWIPROD CPYSRCF 226
authority CRTCBLPGM 188
security administrator rights 38 MOVOBJ 266
user profile security
owner of work libraries 266 authority 19
My Workbench, see Workbench 49 Output queue
N Owning model object
defined 423
Net/Wrk400 integration 381
NetView/DM integration 381
work library 270
Network Configuration 188 P
Panel groups
move step considerations 225
O Partition
Object allocation defined 423
Path
during move step 225
defined 423
Object authority
PathFinder integration
environment information 43
check out options 156, 167
Object Code Report 26 PDM option for check out 383
user-defined options 382
Object codes
Paths
ADDPFM 315
check out 46
CHGPFM 315
check out environment 46
creation command 188
create request 46
defined 423
DTAARA, promote from lib value 318 current location 46
default 46
DTAARAR, retain existing value 318
development flow 46
for IFS objects, automatic 134, 215
object name rules 155 emergency 46
environment 46
PFDTA 314
environment group 46
PFREF 174, 315
Index
primary environment 46 in ProjectMaster 144

environment on project paths 107
multiple paths 46 Project leader
library 46 environment administrator 39
per production environment 46 role defined 39
project path in promotion 180 Project path
project paths 107 defined 413
standard 46 in promotion 180
PDM 156 ProjectMaster
IMPDMOPT option for create projects 144
request 198 Promotion
option for check out 162 completing failed requests 254
Workbench options 77 defined 424
PFREFOBJ data area 43 field reference files 174
Physical file data IEXCRQSDTL substitution
check out 150 variables 238
Physical files IFS objects
archiving 264, 296 directory upgrades 216
checking out data 150 IFS files and directories 212
journaling 264 java optimization 218
promoting PF data 218 internal processing 265
promotion internals 263 level check 207
retaining triggers and constraints 184 logical files to remotes 316
Powerhouse integration 376 methods, overview 174
Prerequisites to using this guide 2 object version stamping 251, 252
Previous release support 188 one step method
Primary request, see related request 201 from Clipboard 58
Primary target environment overriding 86
defined 424 optimize PF promotion
Print options benefits 184
ICMPMBR parameter 390 change per request 185
IMRGMBR parameter 405 overriding 185
Problem determination process overview 183
job log audit trail information 253 overview 54
options for troubleshooting 253 project paths 180
working with failed promotions 254 related objects 200
Process related request processing 201
defined 424 special commands
Process Clipboard (IPRCCBD) command 63 ICHGRQSDTL command 240
Product integration IEXCRQSDTL command 236
user authorities 152 step 256
Production environment type 40 substitution variables 234
Production file web-based, for IFS objects 213
IMRGMBR parameter 399 work libraries 270
Production member Workbench
IMRGMBR parameter 399 compile 89
Program move 89
default library 41 Promotion methods
move step considerations 225 creating one step promotions 175
Project creating traditional promotions 177
create 145 where defined 174
defined 424 Promotion request
437
Index
automation 256 Completed 259

change compile commands 187 CompFail 258
change request details 208 CompJobq 258
combining 181 CompPend 258
comments 179 CompRun 258
bypassing 175 DistFail 259
disable comments 87 DistJobq 259
completing failed promotions 254 DistPend 259
created in archiving 300 DistRun 259
defaults MCpyFail 259
in user profile 255 MCpyJobq 259
in Work with Environments 255 MCpyPend 259
defined 171, 424 MCpyRun 259
difference between emergency and MCpySchd 259
standard 252 MoveFail 259
distribute by system MoveJobq 259
move all 273 MovePend 259
overview 272
emergency 252
environment selection 45 Q
move request by system
QCMDEXC program
move all 273
used for compiling 188
overview 272
QRPLOBJ library
move requests on remote system 290
overrides
use during move step 225
change request defaults 205
QSECOFR user profile
job submit defaults 186
security administrator rights 38
optimize PF promotion 185
Qualified name
remove items in from
defined 424
environment 205
product integration 255
remote
job log returned on failure 253
R
request numbers Rejecting changes from Quality
number scheme 173 Assurance 116
when reset 173 Related environments
restore remote request 289 defined 424
source file length 226 Related objects 139, 201
status 171 *DTAARA object type 167
CompSchd 258 *FILE object type 139, 167
DistSchd 259 *MODULE object type 139
Expt-Fail 258, 370 *SRVPGM object type 139
Expt-Jobq 258, 370 checking out 139
Expt-Pend 258, 370 Hawkeye considerations 201
Expt-Run 258, 370 process overview 200
Expt-Sched 258, 370 processing considerations 203
MoveSchd 259 recompiling 256
steps 171 related request processing 201
what is included 171 selection 139
work library 265 Related requests 201
work with, on remote system 288 archive recovery of 204
Promotion request status displaying and selecting 203
Index
promoting 202 Revision number

setup requirements 204 assign in check out 122
Remote job scheduling 280 RLU
Remote menu from Workbench 78
using 287 RMVDIR special command
Remote requests for directory upgrade in promotion 217
move on remote 290 ROBOT integration
restoring 289 scheduling 288
work with on remote 288 RPG source code
REPLACE parameter 225 converting in ILE 163
Reports
Activity Report 25
Archive History Report 26 S
Archives by Environment 299 Scheduling
Archives by Request Report 299
promotion steps 256, 257
Archives Per Tape Report 299
remote jobs 280
Concurrent Development Report 25
ROBOT 288
Environment Report 26
SDA
job logs 20
from the Workbench 78
job logs, for problem determination 253
Secondary request, see related request 201
Lock Report 25
Session model list
Object Code Report 26
check out 344
Request Report 25
COOL:2E 344
User Profile Report 26
defined 425
Repository
Set to Environment Library List (ISETLIBL)
defined 424
command, overview 54
Request number
SEU
defined 424
from the Workbench 70, 71
resetting 173
Single source multiple object
sequencing 173
at check out 123
Request Report 25
Source
Request status
default library 41
defined 425 removing in from environment 205
MoveRun 259
Source and object names, different
per environment 258
using in check out 151, 219
per multiple environments 258
Source file
variations per host/remote 258
environment definition 42
Requester length 226
defined 424 Source type
Required objects
changing 226
defined 425
Reserve name
member/object at check out 121
Special commands 245
Reset authorities 42 environment level 22, 229
defined 425
for DDM management 230, 240
Resolve a conflict
for directory upgrade in promotion 217
task 248
for java optimization 218
Restoring
IEXCCKOCMD Execute Checkout 112,
archives from tape 299
231, 245
remote requests 289 IEXCRQSDTL Execute Request
Review work details
Detail 23, 230, 236
overview 53
439
Index
in check out 233 *WRKOBJCDE 13

library list considerations 44 *WRKPRJ 13
processing 229 *WRKUSR 14
promotion internals 265 options 12
substitution variables 236 Status
Special object considerations 318 CompFail 258
SQL CompJobq 258
archiving tables 296 CompPend 258
trigger and constraint support 184 CompRun 258
Stage library 263, 264, 268 CompSchd 258
defined 425 DistFail 259
Staged DistJobq 259
objects 222 DistPend 259
source 222 DistRun 259
Start column (STARTCOL) DistSchd 259
on Compare Members command 390 Expt-Fail 258, 370
on Merge Members command 402 Expt-Jobq 258, 370
Start COOL:Xtras_CM (STRCM) Expt-Pend 258, 370
command 12 Expt-Run 258, 370
Start Implementer (STRIM) command Expt-Schd 258, 370
menu options 13 MCpyFail 259
*ACTRPT 13 MCpyJobq 259
*ARCHRPT 13 MCpyPend 259
*ARCRCV 13, 301, 302 MCpyRun 259
*CHKOUT 13, 136, 178 MCpySchd 259
*CMPRQS 13, 89, 90, 220 member/object status codes 91
*CONDEVRPT 13 member/object status history 55, 90
*CRTRQS 13 MoveJobq 259
*ECHKOUT 305 MovePend 259
*ECRTRQS 306 MoveRun 259
*ENVRPT 13 MoveSchd 259
*JOBLOGINQ 13 Step
*LCKRPT 13 defined 425
*M1 or *MENU1 13 Structured Query Language, See SQL 184
*M2 or *MENU2 13 Subdirectory
*M3 or *MENU3 13 defined 426
*M4 or *MENU4 13 Submit
*MNGCONDEV 13 CRTOBJ parameter 391, 407
*MOVRQS 13, 226 Substitution variables
*MOVRQSSYS 13, 273, 275, 277 for check out 233
*NETCFG 13 for IEXCCKOCMD 233
*OBJCDERPT 13 for IEXCRQSDTL 238
*RQSINQ 13 for promotion 234
*RQSMNT 13, 211 for special commands 236
*RQSRPT 14 Subsystem
*SYSCTLMNT 14 compile step 223
*USRRPT 14 Support options 5
*WRKBCH 13, 95, 97, 98 Surrogate
*WRKENV 13 defined 426
*WRKENVGRP 13 System administrator, role defined 38
*WRKFNCKEY 13 System Control Maintenance
*WRKOBJ 13 IFS object code creation 212
Index
job logging level in 253 object code list 192

job queue 256 PDM option 198
number of job logs to retain 253 select from locks 189
System Software Associates special commands 229
AS/NET integration 381 create traditional promotion request
AS/SET integration 330 by locked source member 178
BPCS integration 336 delete a lock 98
edit members
SEU option 71
T Workbench merge option 79
Tape distribution Workbench RLU option 78
Workbench SDA option 78
work library 269
Workbench SEU option 70
Tape, archiving to 297
Target environment group Workbench WRKMBRPDM
defined 426 option 78
emergency check out 304
Target file
emergency create request 306
move request
Target source member
IMOVRQS command 228
submit move 226
Task
reject from *QAC 153
associate multiple DRs to a lock 99
request maintenance 211
change a design request 101
resolve a conflict 248
change a lock 97
Workbench
check out
compile 89
add related objects 139
create request 86
create a member/object 121
inquiry 95
delete member/object 121
move 89
for concurrent development 136
Test
from menu 112
from PathFinder 167 compile, from Workbench 83
creating promotion requests 181
ICHKOUT command 156
environment type 40
PDM option 162
overview 53
select member/object 112
Tester, role defined 39
select member/object by object
TGTRLS parameter 188
code 112
Third party compile procedures 223
single source multiple object 123
Time entry
type in member/object 112
overview 54
with design request 141
Work with Objects 112 Trigger
defined 426
Workbench 112
compile request Triggers and constraints
ICMPRQS command 224 in promotion 184, 313
Troubleshooting
submit compile request 220
completing failed promotions 254
COOL:Xtras CM
problem determination 253
submit compile request 220
create promotion request
add target environments 199
by member list 193 U
change overrides 205 User
copy request 195 ASP 225
ICRTRQS command 196 work library considerations 266
441
Index
authorities 151 Work with Members Using PDM

capabilities 43 (WRKMBRPDM)
roles 38 Workbench 78
User defaults, in Workbench 75 Work with Objects
User Profile Report 26 all object inquiry 56
User-Defined options check out 112
from Workbench 17, 56, 72 concurrent development 136, 139
USRPRF parameter 188 one step method 113
Utilities with design request 141
environment/library integrity check 45 function access 55
working with function keys 291 initial check out 54, 97
member/object status history 90
one step check out, overriding 68
V one step promotion, overriding 86
reject 153
Vendor integration
Workbench
ABSTRACT 378
associating multiple design requests 99
American Software 329
change 53
AOS Message Manager 380
change design request 101
application software 328
change lock 97
AS/NET 381
check out 53, 112
AS/SET 330
concurrent development 136
BPCS 336
related objects 139
CASE products 328
with a design request 141
CODE/400 337
command prompting 58
J.D. Edwards 363
compile 53, 79
LANSA 367
create request 86
Lotus Notes and Domino 376
access 86
MIMIX 381
defined 422
Net/Wrk400 381
deleting locks 98
NetView/DM 381
edit members
PathFinder 382
auto SEU 71
Powerhouse (Cognos) 376
change SEU option 70
Utility software 377
compare 78
Version
merge 79
in COOL:2E, defined 426
RLU 78
Version control 181
SDA 78
promotion requests 171
Version group WRKMBRPDM 78
emergency
in COOL:2E, defined 426
check out 304
create request 306
F13 repeat option 17
W function access 55
Web-based check out 135 identify work 52
Web-based promotion 213 inquiry 95
WebSphere integration 337 library list setup 83
What’s new in this release? 30 lock information 55
Who should read this guide 2 manage locks 54, 97
Work library member/object status history 55, 90
compiling 222 optional check out and promotion
defined 426 methods 55
in promotion 270 PDM options 77
Index
promote 54
promotion
Y
compile 89 YCHKMDLCRT command 353
move 89 YCPYMDLOBJ command 352
promotion request 85 YCVTCNDVAL command 354, 355
reject 153 YCVTMDLMSG command 354, 355
repeating options 101 YEDTMDL command 357
review work details 53 YEDTMDLLST command 348, 357
selection 51 YFRFVNM model value 355
test 53, 83 YMSGVNM model value 355
time entry 54 YPRMMDLLST command 352
tool access 50 YSBMMDLCRT command 353
traditional check out 66 YSYSCHG model value 342
user-defined options 56, 72
443
Index

MKS Implementer User Guide v.5.3 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

MKS Implementer User Guide v.5.3 PDF

Caricato da

Copyright:

Formati disponibili

IMPLEMENTER

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

CORPORATE HEADQUARTERS WORLDWIDE OFFICES:

Chapters 1 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

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

Using the IPRCCBD Command to Process the Clipboard . . . . 63

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

Check Out Command Variations . . . . . . . . . . . . . . . . . . . . . . . . 162

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

Maintaining Promotion Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Promotion Request Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

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

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

Emergency Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

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

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

Check Out Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

NetView/DM Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Appendixes A Compare/Merge Member Commands . . . . . . . . . . . . . . 385

This chapter covers:

who should read this guide

what to know before using this product

what’s inside this guide

Who Should Read This Guide

Project leaders responsible for creating projects, managing concurrent

Developers responsible for checking out members/objects from

Testers responsible for accepting promotion requests into test

What to Know Before Using This Product

OS/400 operating system

Software development policies and procedures for your organization

What’s Inside This Guide

Chapter 1: Before You Introduces you to MKS Implementer. Describes who

Chapter 2: Getting Explains where to find product installation information.

Chapter 3: Using the Explains the versatile features of the Workbench.

Chapter 4: Projects Explains how to use the Implementer to interface with

Chapter 6: Performing Explains the two promotion methods. Describes how

Chapter 7: Performing Explains how to distribute members/objects to remote

Chapter 9: Member Explains how Implementer supports the different OS/

Appendix A: Compare/ Explains how to use the Compare Member

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

Items in documentation Appear as

References to other manuals, new terms, and italics

Keys you press, programs, files, directory names, ENTER

Code-based information, such as system ADDLIBLE

PC menus, commands New > Problem

PC drop-down menus the Session command

PC Dialog boxes, features Edit Options, Cancel, OK

Path names c:\mks\demo

Online Web www.mks.com

Telephone North America 800 633 6298

UK +44 (0) 1483 733910

Germany +49 711 351 775 51

Fax North America 630 495 4855

UK +44 (0) 1483 733901

Germany +49 711 351 775 11

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

United Kingdom: 9:00 A.M. to 5:30 P.M., Monday to Friday, British

Germany: 9:00 A.M. to 5:30 P.M., Monday to Friday, West Europe

This chapter covers:

issue tracking solutions

overview of Implementer features

what’s new in this release

Menu—Panel 1 M1 or MENU1

Menu—Panel 2 M2 or MENU2

Menu—Panel 3 M3 or MENU3

Menu—Panel 4 M4 or MENU4