MKS Implementer 2006 Administration Guide

® 

Integrity 

MKS Implementer® 

2006 

Administration Guide

MKS Implementer® 2006 

Administration Guide 

Copyright © 1988-2006 MKS Software Inc.; in Canada copyright owned by MKS Inc. All rights reserved. 

MKS makes no warranty of any kind with regard to this material, including, but not limited to the implied warranties of merchantability, 

performance, or fitness for a particular purpose. MKS shall not be liable for errors contained herein, or for any direct, indirect, incidental, 

or consequential damages resulting from the use of this material. 

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. 

MKS Source Integrity, MKS Integrity Manager, Implementer, MKS Toolkit, Nutcracker, MKS Integrity Solution, MKS Integrity Suite, 

Alertcentre, and MKS Federated Server are trademarks or registered trademarks of MKS Inc. in Canada, the United States and other 

countries. All other trademarks or registered trademarks are the property of their respective holders. 

U.S. Government Restricted Rights. The software and documentation provided to you (the "Software and Documentation") are 

"commercial items," developed exclusively at private expense, consisting of "commercial computer software" and "commercial computer 

software documentation" as such terms are defined in the applicable acquisition regulations. If you are the U.S. Government or any 

agency or department thereof (collectively referred to as the "Government"), the Software and Documentation are licensed hereunder (i) 

only as a commercial item and (ii) with only those rights as are granted to all other end users to the extent that such rights are consistent 

with this paragraph. If you are any agency of the Department of Defense of the Government, the following notice is given: The Software 

and Documentation are provided with RESTRICTED RIGHTS. You shall not use, duplicate or disclose the Software or Documentation in 

any way not specifically permitted by MKS Software Inc. or mandated by U.S. law. Manufacturer is MKS Software Inc., 410 Albert Street, 

Waterloo, Ontario Canada N2L 3V3. 

This product contains the edtFTPj java library. Copyright © 2003 Enterprise Distributed Technologies Ltd. All Rights Reserved http:// 

www.enterprisedt.com. THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT 

NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 

DISCLAIMED. IN NO EVENT SHALL ANY PERSON WHO HAS CONTRIBUTED TO OR IS THE OWNER OF ANY PART OF THIS 

SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 

(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; 

OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 

LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 

SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 

This product contains Java software developed by Sun Microsystems, Inc. © Copyright Sun Microsystems, Inc. All Rights Reserved. 

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. 

This product includes Apache Tomcat v. 4.1.27 developed by The Apache Software Foundation (http://www.apache.org/). Licensed 

under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a 

copy of the License at http://www.apache.org/licenses/LICENSE-2.0. Unless required by applicable law or agreed to in writing, 

software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, 

either express or implied. See the License for the specific language governing permissions and limitations under the License. 

Copyright © up to and including 2006 International Business Machines Corporation ("IBM") and others. All Rights Reserved. This 

product contains IBM Toolbox for Java software developed by IBM and is licensed under the IBM Public License Version 1.0 (the 

"License"); you may not use this file except in compliance with the License. See the License at http://www-128.ibm.com/ 

developerworks/library/os-ipl.html for the specific language governing permissions and limitations under the License. THE 

SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 

TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO 

EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 

WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE 

SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. IN NO EVENT SHALL THE CONTRIBUTORS BE LIABLE FOR 

ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 

LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 

INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR 

TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 

ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 

This product contains JBoss version 4.0.0. Copyright © 2004-2006 JBoss, Inc. This library is free software; you can redistribute it and/or 

modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of 

the License, or (at your option) any later version. Copyright © 1991, 1999 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, 

Boston, MA 02110-1301 USA. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without 

even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public 

License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write 

to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 

This product contains jMimeMagic software. Copyright (C) 2003-2004, David Castro. This library is free software; you can redistribute it 

and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 

2.1 of the License, or (at your option) any later version. Copyright © 1991, 1999 Free Software Foundation, Inc., 51 Franklin Street,

Fifth Floor, Boston, MA 02110-1301 USA. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; 

without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General 

Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, 

write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 

This product contains Jakarta Oro developed by The Apache Software Foundation (http://www.apache.org/) licensed under the Apache 

License, Version 1.1. Copyright (c) 2000-2002 The Apache Software Foundation. All rights reserved. Redistribution and use in source and 

binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source 

code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must 

reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials 

provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following 

acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."; 4. The 

names "Apache" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software 

without prior written permission. For written permission, please contact apache@apache.org. 5. Products derived from this software may 

not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation. 

THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, 

THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 

EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 

INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT 

OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 

AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 

OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 

DAMAGE. 

This product contains Log4J software licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in 

compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0. Unless 

required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT 

WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing 

permissions and limitations under the License. 

This product contains Xerces 2.6.0 developed by The Apache Software Foundation (http://www.apache.org/) licensed under the Apache 

License, Version 1.1. Copyright (c) 2000-2002 The Apache Software Foundation. All rights reserved. Redistribution and use in source and 

binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source 

code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must 

reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials 

provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following 

acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/). 4. The 

names "Xerces", "Apache" and "Apache Software Foundation" must not be used to endorse or promote products derived from this 

software without prior written permission. For written permission, please contact apache@apache.org. 5. Products derived from this 

software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software 

Foundation. THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 

LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 

DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY 

DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 

TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 

HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 

OF THE POSSIBILITY OF SUCH DAMAGE.

Corporate Headquarters Worldwide Offices 

410 Albert Street 

Waterloo, ON N2L 3V3 

Canada 

tel: 519 884 2251 

fax: 519 884 8861 

sales (toll free): 800 265 2797 

www.mks.com 

This document is uncontrolled when printed or copied. 

1815 South Meyers Rd. 

Suite 220 

Oakbrook Terrace, IL USA 

60181 

tel: 630 827 4900 

fax: 630 629 9167 


12701 Fair Lakes Circle 

Suite 350 

Fairfax, VA USA 

22033 

tel: 703 803 3343 

fax: 703 803 3344 


Martinstraße 42-44 

73728 Esslingen 

Germany 

tel: +49 711 351775 0 

fax: +49 711 351775 7555 

Third Floor, Duke’s Court 

Duke Street, Woking 

Surrey 

GU21 5BH 

United Kingdom 

tel: +44 (0)1483 733900 

fax: +44 (0)1483 733901 

sales: +44 (0)1483 733919

Table of Contents 

Chapters 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

Related Implementer Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

What You Need to Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

Typographical Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

Your Feedback Is Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2 Understanding Implementer . . . . . . . . . . . . . . . . . . . . . . . . 9 

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Terms You Should Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Starting Implementer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Overview of Setup Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

Scenario Summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Host System Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

Basic Host: Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

One Test Environment: Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . 18 

Multiple Test Environments: Scenario 3. . . . . . . . . . . . . . . . . . . . 19 

Concurrent Development: Scenario 4 . . . . . . . . . . . . . . . . . . . . . . 21 

Emergency Development: Scenario 5 . . . . . . . . . . . . . . . . . . . . . . 23 

Multiple Data Libraries, Identical Structures: Scenario 6 . . . . . 25 

Separate Production Modifications: Scenario 7. . . . . . . . . . . . . . 27 

Multiple Software Releases: Scenario 8 . . . . . . . . . . . . . . . . . . . . 29 

Modifications to Vendor Software: Scenario 9 . . . . . . . . . . . . . . 33 

Release Control: Scenario 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

Remote System Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

Remote Production on Same Request: Scenario 11. . . . . . . . . . . 40 

Remote Production on Different Request: Scenario 12 . . . . . . . 41 

Testing on Remote: Scenario 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

Multiple Remote Productions Same Changes: Scenario 14 . . . . 45 

Multiple Remote Systems: Scenario 15. . . . . . . . . . . . . . . . . . . . . 46 

Check Out From Remote: Scenario 16 . . . . . . . . . . . . . . . . . . . . . 48 

i


ii 

Multi-Platform Development and Deployment Scenarios . . . . . . . . 49 

Integrated Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

Software Development Lifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . 52 

Managing Change Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

Change Request Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 

Implementer and MKS Integrity Integration: Scenario 17. . . . . 60 

Communications Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

Distribution Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

3 Implementer Administration . . . . . . . . . . . . . . . . . . . . . . . 63 

Overview of Administrative Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

System Control Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 

Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 

Typical Values for Different User Roles . . . . . . . . . . . . . . . . . . . . 78 

User Profile Object Code Overrides . . . . . . . . . . . . . . . . . . . . . . . 80 

User Profile Environment Capabilities. . . . . . . . . . . . . . . . . . . . . 80 

Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 

Object Code Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 

Establishing Object Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 

Deleting an Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 

Environment Library List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 

Promotion Job Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 

Related Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 

Environment Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

Special Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 

Environment Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 

Third Party Integration Prerequisites . . . . . . . . . . . . . . . . . . . . . 107 

Environments and User Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . 109 

Environment Repository Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 

Environment Build Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 

Environment Repository Report . . . . . . . . . . . . . . . . . . . . . . . . . 122 

Environment Verification Report . . . . . . . . . . . . . . . . . . . . . . . . 123 

Environment Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 

Object Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 

Environment Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 

Object Codes for Third Party Integrations . . . . . . . . . . . . . . . . . 133 

Object Codes for DDM Support. . . . . . . . . . . . . . . . . . . . . . . . . . 135 

Object Codes for IFS Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 

Object Codes for Setting a Data Area Value . . . . . . . . . . . . . . . 136 

Object Name Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 

Option 1: Specific Object Code for Specific Environment . . . . 138 

Option 2: All Object Codes for a Specific Environment. . . . . . 141 

Option 3: Specific Object Code for All Environments . . . . . . . 141 

Project-based Application Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 

User-Defined PDM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144


Issue or Design Request Stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

Object Version Stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 

Versioning Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 

Considerations With OS/400 and Implementer . . . . . . . . . . . . . . . . 153 

Operating System Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 

Changing the System Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

System Library List Requirements . . . . . . . . . . . . . . . . . . . . . . . 154 

Independent Auxiliary Storage Pools. . . . . . . . . . . . . . . . . . . . . 154 

Web-based Development for IFS Objects. . . . . . . . . . . . . . . . . . . . . . 155 

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 

iSeries Web Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 

Mounted Drive Support for IFS Objects. . . . . . . . . . . . . . . . . . . . . . . 159 

4 Remote Distribution Concepts and Setup . . . . . . . . . . . 161 

Implementer Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

Integration With Local Promotions. . . . . . . . . . . . . . . . . . . . . . . 163 

Remote System Inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

Remote Source Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

Consideration for Database Files. . . . . . . . . . . . . . . . . . . . . . . . . 164 

Distribution Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 

Communications Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 

APPC Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 

Communication Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 

APPN Lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 

Switched Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 

Network Control Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

Setting Up Communications Entries. . . . . . . . . . . . . . . . . . . . . . . . . . 169 

Option 1: Using Existing Communication Entries . . . . . . . . . . 170 

Option 2: Using an Existing Mode Description. . . . . . . . . . . . . 170 

Option 3: Using a Specific Mode Description . . . . . . . . . . . . . . 171 

Defining the Host for Remote Initiated Moves . . . . . . . . . . . . . 173 

Setting Up for TCP/IP Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 173 

Key Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 

Communication Subsystem and Job Queue IMCOM . . . . . . . 176 

Communications Control Command . . . . . . . . . . . . . . . . . . . . . 177 

Setting Up for SNADS Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 179 

Distribution Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

Single Step Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

Two Step Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

Remote Initiated Moves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

Simultaneous Distribution to Multiple Remote Sites . . . . . . . . 181 

iii


iv 

Controlling Remote Job Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

Using the Default Job Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

Overriding the Default Job Schedule . . . . . . . . . . . . . . . . . . . . . 182 

Remote Job Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

Change Remote Request (ICHGRMTRQS) Command . . . . . . 185 

Move Remote Request (IMOVRMTRQS) Command . . . . . . . . 187 

Distribution Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

Move Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

Multiple System Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

Starting and Ending Remote Database Support . . . . . . . . . . . . 190 

Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 

Request Number Considerations . . . . . . . . . . . . . . . . . . . . . . . . 191 

Saving and Restoring Remote Tape Archives . . . . . . . . . . . . . . . . . . 192 

Problem Determination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 

5 MKS Integrity Integration. . . . . . . . . . . . . . . . . . . . . . . . . 195 

Implementer and MKS Integrity Integration. . . . . . . . . . . . . . . . . . . 196 

Multitiered Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 

The iSeries Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 

Process and Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 

Assumptions and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 202 

MKS Integrity Setup and Administration . . . . . . . . . . . . . . . . . 203 

Implementer Setup and Administration . . . . . . . . . . . . . . . . . . 216 

Managing Implementer Server . . . . . . . . . . . . . . . . . . . . . . . . . . 223 

Converting From DesignTracker to MKS Integrity . . . . . . . . . . . . . 243 

Conversion Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 

Converting Without Data Retention . . . . . . . . . . . . . . . . . . . . . . 244 

Converting With Data Retention. . . . . . . . . . . . . . . . . . . . . . . . . 247 

Emergency Update Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 

Changing the Emergency Update Mode . . . . . . . . . . . . . . . . . . 255 

Applying Pending Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 

Implementer and MKS Source Integration . . . . . . . . . . . . . . . . . . . . 259 

Process and Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

Assumptions and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 261 

MKS Source Setup and Administration . . . . . . . . . . . . . . . . . . . 262 

Implementer Setup and Administration . . . . . . . . . . . . . . . . . . 274 

Preparing for the Next Release . . . . . . . . . . . . . . . . . . . . . . . . . . 293 

Preparing for the Next Version . . . . . . . . . . . . . . . . . . . . . . . . . . 293 

MKS Integrity Integrations Task Checklists . . . . . . . . . . . . . . . . . . . 295 

Export to Implementer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 

Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302


6 Third Party Integrations . . . . . . . . . . . . . . . . . . . . . . . . . . 303 

ABSTRACT Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 

AllFusion 2E Change Management Integration . . . . . . . . . . . . . . . . 304 

Considerations for Libraries and Commands . . . . . . . . . . . . . . 304 

Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 

Support for EXCUSRSRC and EXCUSRPGM . . . . . . . . . . . . . . 308 

Support for SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 

Object Code Setup for Parallel Installation . . . . . . . . . . . . . . . . 312 

American Software Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 

Object Code Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 

Library and Library List Requirements . . . . . . . . . . . . . . . . . . . 314 

Troubleshooting Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 

AOS Message Manager Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 315 

AS/SET Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 

Setting Up the Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 

Setting Up for Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 

Setting Capabilities for Checked Out Generated Objects . . . . 318 

Setting Up for Generated Object Promotions . . . . . . . . . . . . . . 319 

AS/SET Dependency Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 

BPCS Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 

Compile Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 

Setting Up Object Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 

Setting Up Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 

BRMS/400 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 

Code/400 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 

Requirements and Setting Up . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 

Help Desk Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 

Setting Up the Help Desk Integration. . . . . . . . . . . . . . . . . . . . . 325 

Updating Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 

LANSA Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 

Setting Up the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 

Defining Environments and Loading the Repository . . . . . . . 330 

Ending Promotions Based on Message ID . . . . . . . . . . . . . . . . . 331 

LANSA Object Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 

LANSA Task Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 

Visual LANSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 

Lawson Software Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 

Source and Object Library Structure. . . . . . . . . . . . . . . . . . . . . . 334 

LID Method of Screen and Report Generation . . . . . . . . . . . . . 334 

v


vi 

Lotus Domino Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 

iSeries Setup and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 339 

Implementer Setup and Configuration . . . . . . . . . . . . . . . . . . . 339 

Domino Designer Setup and Configuration . . . . . . . . . . . . . . . 340 

Managing the Domino Access Control List . . . . . . . . . . . . . . . . 343 

Setting ACLs in Check Out. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 

Setting ACLs in Promotion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 

Database and Template Signing . . . . . . . . . . . . . . . . . . . . . . . . . 351 

PathFinder Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 

PeopleSoft World Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 

Configuring the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 

Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 

Object Codes for Soft Coding Items . . . . . . . . . . . . . . . . . . . . . . 359 

Object Codes for Traditional Objects . . . . . . . . . . . . . . . . . . . . . 360 

Deactivating Standard Object Codes . . . . . . . . . . . . . . . . . . . . . 361 

Installing the Interface on Remote Systems . . . . . . . . . . . . . . . . 361 

Powerhouse (Cognos) Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 

ROBOT Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 

Setting Up Non Promotion Jobs . . . . . . . . . . . . . . . . . . . . . . . . . 365 

Setting Up Promotion Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 

WebSphere Development Studio Client for iSeries Integration . . . 365 

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 

WDSc for iSeries Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 368 

Implementer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 

7 Administrative Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . 371 

Submitting Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 

Resetting Authorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 


Common Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 

Purging Environment History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 

Repository Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 


Development Library Maintenance . . . . . . . . . . . . . . . . . . . . . . 378 

Saving and Restoring Tape Archives . . . . . . . . . . . . . . . . . . . . . . . . . 379 

Working With Tape Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 

Archive Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 

Clearing Remote QA Environments . . . . . . . . . . . . . . . . . . . . . . . . . . 384


User Capability Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 

Installing on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 

Installing on the Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 

Using the Capability Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 

Selecting Enrolled Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 

Selecting Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 

User Capability Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 

Customizing User Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 394 

Updating the Implementer Database . . . . . . . . . . . . . . . . . . . . . 395 

Deleting Tutorial Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 

Function Key Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 

vii


Appendixes A Implementer Data Areas and User Exit Programs. . . . . 401 

Implementer Data Areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 

Customizing Implementer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 

User Exit Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 

Edit Library List Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 

vii 

B Environment Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 417 

Local Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 

Local Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 

Local Quality Assurance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 

Local User Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 

Remote Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 

C Converting DesignTracker Data to MKS Integrity . . . . . 431 

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 

Rules and Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 

User Profile and Resource Fields. . . . . . . . . . . . . . . . . . . . . . . . . 434 

Entities Added as Change Package Entries . . . . . . . . . . . . . . . . 434 

Conversion Log File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 

Message and Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 

Organizational Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 

Example of a Basic Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . 437 

Convert DT to MKS Integrity (ICVTDT) Command . . . . . . . . 438 

Generating and Configuring the Conversion Properties File . . . . . 441 

Data Mapping Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . 442 

Generating the Conversion File . . . . . . . . . . . . . . . . . . . . . . . . . . 445 

Implementer Conversion Properties. . . . . . . . . . . . . . . . . . . . . . 446 

Post Conversion Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 

D Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469

C HAPTER ONE 

Introduction 

Understanding and Using This Guide 

1 

MKS Implementer® is the premier software configuration management and 

deployment solution for the IBM iSeries. Utilizing host-based and graphical user 

interfaces, Implementer provides the simplicity necessary for first time users, and the 

breadth and depth for more advanced users. In addition to simplifying development and 

software change management, including full traceability and auditability of all software 

changes, Implementer ensures the integrity of software installations in production, 

development, and testing environments on iSeries servers. Implementer integrates with 

traditional OS/400 development environments and is leading the way with integrations 

into new development environments. 

Implementer integrates with MKS Integrity (formerly MKS Integrity Manager®) and 

MKS Source (formerly MKS Source Integrity® Enterprise). MKS Integrity is the 

enterprise choice for flexible process and workflow management, helping create 

repeatable processes for managing software development. MKS Integrity’s platform 

transparent, advanced, multi-tier architecture is scalable across the enterprise to support 

distributed developers and other constituents in the change process. MKS Source is the 

enterprise choice for comprehensive, cross-platform software configuration 

management. It is the most technologically advanced SCM solution on the market today, 

enabling secure and flexible process-centric management for local and distributed 

software development teams in the enterprise. These products and solutions seamlessly 

marry for full enterprise software configuration management and workflow. 

The MKS Implementer 2006 Administration Guide provides you with the information you 

need to build a basic understanding of Implementer. The guide explains how to 

configure and maintain Implementer within your organization. 

This chapter covers the following topics: 

“About This Guide” on page 2 

“Related Implementer Documentation” on page 3 

“What You Need to Know” on page 4 

“Typographical Conventions” on page 4 

“Getting Help” on page 5 

“Professional Services” on page 6 

“Your Feedback Is Welcome” on page 7 

1

Chapter 1: Introduction 

About This Guide 

2 

The person responsible for setting up Implementer is referred to as the administrator 

throughout this guide. This guide provides the administrator with all the information needed 

to configure and maintain Implementer. The guide also provides information on configuring 

and maintaining the Implementer Receiver. 

NOTE For information on installing or upgrading Implementer, see the MKS 

Implementer 2006 Installation Guide. 

The guide is organized as follows: 

Chapter 2: “Understanding Implementer” on page 9 

Explains important things you need to know and consider before setting up and 

configuring Implementer. Describes an overview of the change management process in a 

multi-platform environment. 

Chapter 3: “Implementer Administration” on page 63 

Explains how to configure the Implementer host system to suit the development 

activities of your organization. Explains important information related to Implementer 

when making changes to the operating system or other system related changes. 

Chapter 4: “Remote Distribution Concepts and Setup” on page 161 

Explains the role of the Implementer Receiver and the various distribution options and 

concepts. Explains how to set up communications within Implementer to distribute 

software to remote iSeries systems. 

Chapter 5: “MKS Integrity Integration” on page 195 

Describes the integration between Implementer and MKS Integrity that provides an 

enterprise-wide solution for tracking issues correlated with Implementer managed 

development. Explains how to set up the integration and convert from DesignTracker to 

MKS Integrity. Additionally describes the Implementer and MKS Source integration, an 

export feature that enables client-based software changes initiated by an MKS Integrity 

issue and modified under MKS Source control, to be checked out and optionally 

deployed to an IFS location under Implementer change management control. 

Chapter 6: “Third Party Integrations” on page 303 

Explains special setup considerations for organizations that use any of the third party 

integrations supported by Implementer, such as Computer Aided Software Engineering 

(CASE), utility, application, cross-referencing, communications, and other tools. 

Chapter 7: “Administrative Utilities” on page 371 

Explains the various utilities and tools Implementer provides to assist with setting up 

and using the product, and maintaining the integrity of your Implementer 

environments.

Related Implementer Documentation 

Appendix A: “Implementer Data Areas and User Exit Programs” on page 401 

Describes the Implementer data areas that control many aspects of Implementer 

processing. An additional topic is QSAMPLE, a source file shipped with Implementer 

that provides source of technical information for customizing Implementer. 

Appendix B: “Environment Examples” on page 417 

Describes typical environment setup examples for the most common environment 

scenarios. 

Chapter : “Converting DesignTracker Data to MKS Integrity” on page 431 

Describes how to convert DesignTracker data to MKS Integrity issues. This chapter is for 

customers who are converting to MKS Integrity for issue management (as described in 

Chapter 5) and have a requirement to convert existing DesignTracker data. 

Appendix D: “Glossary” on page 457 

Defines common terms related to Implementer and the MKS Integrity integration. 

Related Implementer Documentation 

To provide you with the most convenient means of retrieving information, product 

documentation is available in print and in Adobe Acrobat’s Portable Document Format 

(PDF). Online help is also included with the product. 

Documentation Print PDF 

MKS Implementer 2006 Administration Guide Yes Yes 

MKS Implementer 2006 User Guide Yes Yes 

MKS Implementer 2006 Release Management Guide No Yes 

MKS Implementer 2006 Release Notes No Yes 

MKS DesignTracker User Guide No Yes 

MKS Implementer 2006 Installation Guide Yes Yes 

Additional copies of the printed guides are available for a nominal fee. For further information, send your 

request to pubs-mgr@mks.com. 

3


What You Need to Know 

4 

Before installing or configuring Implementer, you should be familiar with the software 

development policies and procedures for your organization, as well as: 

OS/400 operating system and command line. 

OS/400 security. 

OS/400 communications. 

Typographical Conventions 

Throughout this guide, the following typographical conventions identify the features, 

functions, and components of Implementer. 

Items in documentation... Appear as... 

New terms, variables to_env 

Keyboard keys, programs, files, directory names, and 

drive letters 

Code-based information, such as system messages, 

field syntax, macros, and commands, and information 

you type on menus and panels 

appear in capitals, for example: ENTER, F6 

ADDLIBLE 

Graphical menus, commands New > Problem 

Graphical user interface commands the Session command 

Dialog boxes, features, field names Edit Options, Cancel, OK 

Path names c:/mks/demo 

NOTE A note provides you with information that supplements the key points of the 

subject. A note may also supply information that applies only in particular cases. 

TIP A tip provides you with information for using the product effectively. 

IMPORTANT An important note provides you with information that is essential for 

completing a task. 

CAUTION A caution note advises you about situations that have the potential to 

result in a loss of data.

Getting Help 

Getting Help 

MKS Customer Care is focused on delivering the right solutions to issues as they arise. For 

assistance, you can choose online support or telephone a technical support representative. 

For online support, browse to www.mks.com/support. There you will find easy access to 

e–mail, Web request services, automatic product notifications, and the MKS Customer 

Community—a secure database that provides helpful resources such as product 

documentation, knowledge base articles, product downloads, user forums, presentations, 

and more. 

MKS’s global support professionals comprise a tightly knit team of problem solvers, sharing 

critical information to help you resolve issues in the shortest possible time with optimal 

results. Support representatives can provide you with a variety of product related tips and 

innovative solutions to your unique requirements. 

Online Web www.mks.com 

E-mail support@mks.com 

Telephone Toll Free North America 800 219 4842 

Outside North America 800 219 48424 

India 000 800 100 6273 

Direct North America 519 884 2270 

UK +44 (0) 1483 733910 

Germany +49 711 351775 7575 

Fax North America 519 884 8861 

UK +44 (0) 1483 733901 

Germany +49 711 351775 7555 

The hours of operation for Customer Care in your region 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) 

India: 8:30 A.M. to 5:30 P.M., Monday to Friday, India Standard Time (GMT+5.5) 

5


Professional Services 

6 

A successful configuration management system is not built on software alone. At MKS, our 

professional services team is committed to understanding the ever changing development 

environments of our clients. The professional services team can provide training, upgrade, 

migration, implementation, and installation services that meet your unique requirements. 

MKS professional services can help guide you through process analysis, software 

installation, source code archive migration, and product and process training. This ensures 

that the implementation of your new solution goes smoothly, while allowing your 

developers to make progress on critical projects. 

The professional services team can truly add value to your MKS technology investment by 

providing the following services: 

process assessment 

best practice consultation 

migration services 

upgrade services 

implementation services 

education and training 

For more information on MKS professional services: 

Online Web Global www.mks.com/services 

E-mail North America consulting@mks.com 

Europe europe@mks.com 

Telephone North America 800 633 1235 

UK +44 (0) 1483 733904 

Germany +49 711 351775 0

Your Feedback Is Welcome 

Your Feedback Is Welcome 

MKS welcomes your feedback on the documentation included with these products. If you 

have comments or suggestions about any of the guides or the online help, send them to: 

pubs-mgr@mks.com 

Include the following information with your feedback: 

product name and version number 

title of manual or online help topic 

page number (for manuals only) 

your suggested correction or improvement 

NOTE The e-mail address is provided for comments on the MKS documentation 

only. For technical questions or for software support, contact MKS Customer Care 

(support@mks.com). 

7


8

C HAPTER TWO 

Understanding Implementer 

Getting Prepared for Setup 

This chapter helps you to prepare for setting up Implementer by providing an 

overview of the tasks and scenarios that describe different approaches to using the 

product based on various development models. 

2 

It is possible that a scenario fits the needs of one business application while a different 

scenario fits another. You can blend characteristics of multiple scenarios to meet the 

needs of your applications. The scenarios focus on the major decisions involved in 

setting up Implementer for your use; they do not list every set up option available in 

Implementer. 


“System Requirements” on page 10 

“Terms You Should Know” on page 10 

“Starting Implementer” on page 10 

“Overview of Setup Tasks” on page 12 

“Scenario Summaries” on page 14 

“Host System Scenarios” on page 17 

“Remote System Scenarios” on page 39 

“Multi-Platform Development and Deployment Scenarios” on page 49 

“Communications Options” on page 61 

“Distribution Methods” on page 61 

9

Chapter 2: Understanding Implementer 

System Requirements 

10 

The system requirement for this Implementer release is OS/400 V5R1 or later, or i5/OS V5R3 

or later. Additional requirements may apply to using certain features or functions of 

Implementer. For detailed information, see the requirements described with the respective 

feature or function. 

Terms You Should Know 

Before you begin setting up Implementer, it is important to understand several basic terms 

used within the software: 

environment 

object code 

check out 

promotion 

For a definition of these terms and many other terms, see “Glossary” on page 457. 

Starting Implementer 

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

Implementer Receiver, use the Start Implementer Receiver (STRIR) command. To start the 

Implementer Receiver for Release Management, use the (STRIRM) command. 

To access a specific Implementer panel, issue any of the start commands followed by the 

respective keyword or menu option number. For example, to access Implementer Menu 

option 45, System Control Maintenance, issue the command STRIM *SYSCTLMNT or STRIM 

45. For a list of valid keywords, see the table page 11. You can also prompt the commands 

and use F4=Prompt on the OPTIONS parameter to view and select a valid keyword. 

If you received the Implementer product from Computer Associates and have Implementer 

enabled for AllFusion 2E change management, the following substitutions apply: 

STRCM command replaces the STRIM command. 

STRCR command replaces the STRIR command. 

Library Y2SYCM replaces the default host system library name MKSIM. 

Library Y2SYCR replaces the default remote system library name MKSIR.

Starting Implementer 

The Implementer menus allow access to all capabilities and functions of Implementer and 

Implementer Receiver. Menu access options are described in this guide when they are used 

for specific tasks. 

The Implementer Menu contains the following sections across multiple panels: 

implementation 

other common tasks 

emergency handling 

reports 

administration 

release control 

commands 

The following table describes the command parameters you can use with the STRIM and 

STRCM commands. 

Start Implementer Command Keywords 

Menu Option STRIM Command Value 

Activity Report *ACTRPT 

Archive History Report *ARCHRPT 

Archive Recovery *ARCRCV 

Archive to Tape Menu *ARCTAP 

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 

Job Log Inquiry *JOBLOGINQ 

Lock Report *LCKRPT 

Menu—Panel 1 *M1 or *MENU1 


11


Overview of Setup Tasks 

12 

Start Implementer Command Keywords 

Menu Option STRIM Command Value 



Manage All Concurrent Development *MNGCONDEV 

MKS Integrity Setup *INTMGRSET 

MKS Source Setup *SRCMGT 

Move Promotion Request *MOVRQS 

My Workbench *WRKBCH 

Network Configuration *NETCFG 

Objects *WRKOBJ 

Object Codes *WRKOBJCDE 

Object Code Report *OBJCDERPT 

Release Deployment Menu *WRKRLSDPL 

Request Inquiry *RQSINQ 

Request Maintenance *RQSMNT 

Request Report *RQSRPT 

System Control Maintenance *SYSCTLMNT 

Users *WRKUSR 

User Report *USRRPT 

Work with Projects *WRKPRJ 

This section describes an overview of the basic tasks you need to complete to configure 

Implementer for your specific needs. Used in conjunction with the scenarios provided later in 

the chapter, this information helps you to organize Implementer. 

NOTE This list is not all-inclusive of the setup required to gain full advantage of all 

Implementer’s robust features and functions. For more information, see the 

requirements listed for each specific feature.

The following list identifies the basic functions you use to set up Implementer: 

Overview of Setup Tasks 

System Control Maintenance allows you to define your company name, default job 

queue, and numerous other system-wide defaults. 

Create User Profile allows you to define the rights and characteristics of each 

Implementer user. 

Create Environment allows you to define the characteristics of the different types of 

environments and related environments for your applications, and establish default 

development paths for production environments. 

Work with Object Codes allows you to define the specific types of objects used for 

promotion. 

Reset Authorities allows you to change the OS/400 owners and authorities to objects in 

the environment libraries. 

Build List allows you to load members and objects into Implementer’s environment 

repository. 

Create Environment Groups allows you to define environment groups for promotion or 

distribution purposes. 

Set up User-defined Programming Development Manager allows you set up PDM to 

perform Implementer functions for environments. 

Implementer Server allows you to configure the Implementer Server, which is the 

gateway to MKS Integrity integrations, as well as the primary contact point for many 

external and third party integrations. For details, see “Configuring the Implementer 

Server” on page 217. 

MKS Integrity Setup allows you to configure the communications and other variables 

required to use MKS Integrity for issue management with Implementer. For details, see 

“Implementer and MKS Integrity Integration” on page 196. 

MKS Source Setup allows you to configure the communications and other variables 

required to use MKS Source for source archiving with Implementer. For details, see 

“Implementer and MKS Source Integration” on page 259. 

Before setting up Implementer, it is necessary to conceptually understand two features that 

apply to all development scenarios: projects and archiving. 

Projects are a common element of the development cycle. The primary decisions regarding 

projects are whether you use projects, and how you use them. The following options are 

available for managing projects in Implementer: 

Implementer projects 

MKS Integrity projects (requires using MKS Integrity for issue management); for more 

information, see “Implementer and MKS Integrity Integration” on page 196 

DesignTracker projects (requires using DesignTracker for issue management) 

13


14 

ProjectMaster projects (requires using ProjectMaster for project management) 

You create Implementer projects in Implementer. If using DesignTracker, you can create 

projects from the Work with Entity List Members panel by using F20=Create IM Project 

(creates one project or group of projects for each design request). Implementer projects allow 

for project paths (similar to environment paths) that control the development flow of 

members/objects associated with a project. The project path can be defined on a project-byproject 

basis. For details, see “Project-based Application Paths” on page 142. 

When DesignTracker is not used, for example, when using MKS Integrity, you must 

determine a method of naming your projects and determine when to create them. For 

example, you might create a project for every fix or minor change needed, or create a single 

project for fixes this month or this year, or a continuous project for all fixes. You may already 

have a system in place for logging user requests that match Implementer project references. 

Archiving serves two main purposes: The main purpose is to recover original source and/or 

objects when the promoted source and/or objects do not function appropriately in 

production. Secondly, it provides access to the initial source of a specific program to review 

before promoting the current changes. 

You should determine the value of being able to rollback a change, and the ability to view 

historical versions of source. MKS recommends you archive production environments but 

not archiving test environments. 

If you have remote systems, you can archive on the remote system or the local system. 

However, archiving on the remote allows you to rollback more quickly because it does not 

require redistributing the objects to the remote system. 

Scenario Summaries 

The following tables list each scenario with a description of the important characteristics of 

each scenario. This information is helpful to understand why a specific scenario might be 

useful. The detailed description for each scenario includes: 

illustration of the development cycle 

brief scenario description 

description of development steps 

setup tasks for the scenario

Host System Scenarios 

Scenario Important Characteristics 

Scenario Summaries 

1. Basic (page 17) developers check out from production to development 

developers initiate promotion back to production 

project leader promotes back to production 

does not use separate test environments 

2. One test environment (page 18) developers check out from production to development 

developers initiate promotion to a test environment 

project leader promotes back to production 

test administrator promotes to production 

3. Multiple test environments (page 19) similar to Scenario 2, with more testing areas 

testers promote to other test environments and 

production 

4. Concurrent development (page 21) allows checking out multiple versions of same member 

by same or different developers 

uses two development environments 

5. Emergency (page 23) allows checking out multiple versions of same member 

by same or different developers 

uses two development environments 

6. Multiple database libraries (page 25) testing or production environments have multiple 

copies of database files 

7. Separate production modifications 

(page 27) 

multiple related production environments 

automatic check out from most current version 

8. Multiple software releases (page 29) multiple related production environments 

automatic check out from either release 

9. Modifications to vendor software 

(page 33) 

can be used with any scenario previously listed 

searches multiple environments at check out 

does not update unmodified vendor libraries 

10. Release control (page 37) can be used with any scenario previously listed 

supports both single version and multiple version 

development models 

15


16 

Remote System Scenarios 


11. Remote host and remote production 

on same promotion request (page 40) 

12. Host and a single remote on different 

promotion request (page 41) 

production on a single remote system 

remote production and local image distributed to in 

one step 

testing is not performed on remote system 

production on a single remote system 

distribute to remote production and local system in two 

separate steps 

testing is not performed on remote system 

13. Perform testing on remote (page 43) testing occurs on remote system 

distribute to remote production and local system in one 

step 

14. Multiple remote systems with same 

changes (page 45) 

production on multiple remote systems with same 

changes on each system 

15. Multiple remote sites (page 46) production on multiple remote systems with different 

changes on each system 

16. Remote source check out (page 48) production source on remote system 

source checked out from remote to host development 

Multi-Platform Scenarios 


17. Multi-platform development and 

deployment (page 60) 

can be used with any scenario previously listed 

Implementer users log new issues using MKS Integrity 

MKS Integrity eliminates the need to sign on to the 

iSeries to log issues 

a single issue ID is used to manage a change across 

multiple platforms


Basic Host: Scenario 1 

Overview 


Each developer checks out to a personal environment, a project environment, a shared 

development environment, or a personal library. The developer checks in directly to the 

production environment. Contrast this scenario with the next scenario, which includes a test 

environment. 

Development Tasks 

This is the typical task sequence from the start of a programming change to completion. 

1 Check out. Developer checks out to a personal environment, project environment, or 

shared development environment. 

2 Develop and test. Developer codes, compiles, and tests programs. 

3 Promote to production. Developer creates the promotion request. 

Developer can compile the request into the work library as a separate task or when 

creating the request. 

User who has move capabilities moves the members/objects into production. 

Setup Tasks 

The setup tasks required for this scenario are as follows: 

1 Create an Environment task. Define the following environments: 

Production, one production environment. 

Development, one development environment for all developers, or specific 

environments per developer or project. 

17


18 

2 Create a User Profile task. Define user profiles for the following user roles: 

Developer, checks out members/objects, performs development, and creates a 

promotion request that targets production. Additionally compiles the promotion 

request to the work library. 

Administrator or project leader, creates projects and moves the promotion request to 

production. 

One Test Environment: Scenario 2 

Overview 

Each developer checks out to a personal library, a project library, or a shared development 

library. The developer promotes to a quality assurance environment. Testers test in this 

environment and then promote to production. 



1 Check out. Developer checks out to a personal library, project library, or shared 

development library. 


3 Promote to test. Developer creates the promotion request. 

Developer compiles the promotion request into the work library, as a separate task 

or when creating the request. 

Authorized user moves the members/objects into quality assurance. 

4 Quality assurance testing. Tester tests the change for functional consistency and 

accuracy. 

5 Promote to production. 

Tester creates the promotion request. 

The promotion request can be compiled into the work library, as a separate task or 

when creating the request. 

Administrator moves the members/objects into production.

Setup Tasks 




Quality Assurance, one QA environment. 





Developer checks out members/objects, performs development, and creates a 

promotion request that targets quality assurance environments. The developer 

compiles the promotion request in the work library. 

Tester performs the tests in the test environment with their own copy of the changes. 

Administrator promotes changes into the QA environment to allow the tester to start 

testing a change. 

Administrator or project leader creates projects and moves the promotion request to 

production. 

Multiple Test Environments: Scenario 3 

Overview 

Each developer checks out to a personal library, a project library, or a shared development 

library. The developer completes the necessary changes and checks in to a quality assurance 

environment. The testers in this environment perform the necessary testing, and then 

promote from quality assurance to another test environment for user acceptance. This is 

accomplished by copying the request that initially promoted the changes into the quality 

assurance environment. After user acceptance testing, you promote the change to 

production. 




development library. 

19


20 


3 Promote to test. Developer creates the promotion request. 

Developer can compile the promotion request into the work library, as a separate 

task or when creating the request. 

Administrator moves the members/objects into quality assurance. 


accuracy. 

5 Promote to test. 

Tester creates the request for promotion by copying the original promotion request. 

Administrator moves the members/objects into user acceptance testing. 

6 User acceptance testing. End users test the change for functional consistency and 

accuracy. 


Authorized user creates the request for promotion by copying the original 

promotion request. 

Administrator moves the members/objects into production. 

Setup Tasks 




Quality Assurance, the first QA environment. 

User Acceptance testing, the second QA environment. 





promotion request that targets quality assurance environments. Additionally 


Tester performs the test in this environment with their own copy of the changes. 




production.

Concurrent Development: Scenario 4 

Overview 

This scenario allows checking out multiple versions of one member. 


The first developer checks out to a personal library, a project library, or a shared 

development library. The second developer checks out to a personal library, a project library, 

or a shared development library by selecting from existing versions. 

The developer must have concurrent development capabilities, unless the activity involves 

emergency check out, in which case the user’s emergency check out and promotion rights 

override the concurrent development capabilities. For more information, see the definitions 

for “concurrent development” on page 459, and “conflict” on page 459. 

To complete the necessary changes, the first developer notifies the administrator or project 

leader to resolve a conflict. Once the conflict is resolved, the developer or administrator 

promotes the request back into production. The next program completes the same action. 

To focus on the concurrent development features, this scenario has only one quality 

assurance environment. 



1 Check out the first version of a member. Developer checks out to a personal library, 

project library, or shared development library. 

2 Develop and test. Developer begins a programming change. 

3 Check out second version for a concurrent development. Developer checks out a second 

copy for another change to a different environment. Concurrent check out requires you 

have concurrent development rights. Depending on the situation, you may want to start 

with a current development copy or the production version. The developer working on 

the first version receives a message that a different developer is doing concurrent 

development. 

21


22 

4 Make the development change to the second version. Developer codes, compiles, and 

tests. 

5 Resolve the conflict for the first version of the member. 

Developer notifies the administrator that conflict resolution is necessary or, if 

allowed, resolves the conflict himself. 

Administrator resolves all conflicts of the first completed version of the member. 

Promoting a request often includes conflict resolution, as described in the next task. 

6 Promote the first version to testing. 

Developer or administrator creates the promotion request. 

Developer can compile the promotion request into the work library, as a separate 

task or when creating the request. 


7 Complete the second change. Developer codes, compiles, and tests. 

8 Resolve the conflict for the second change. 

Developer notifies the administrator that conflict resolution is necessary. 

Administrator resolves all conflicts of the second completed version of the member. 

Promoting a request often includes conflict resolution, as described in the next task. 

This step could include reviewing the source code of the emergency version, or even 

performing a merge or compare of the version. 

9 Promote the second version to testing. 

Developer creates the promotion request. 

Developer can compile the promotion request into the work library, either as a 

separate task or when creating the request. 



accuracy. 


Tester creates the promotion request. 


Setup Tasks 



Production, one production environment with a standard path. 

Quality Assurance, the first QA environment. 


Development environment, one development environment for all developers, or 

specific environments per developer or project. 


Developer checks out members/objects, performs development, creates a promotion 

request that targets production, and is allowed to perform concurrent development. 

The developer compiles the promotion request in the work library. 

Tester performs the tests in the test environment with their own copy of the changes. 




production. This user also has conflict resolution capabilities. 

Emergency Development: Scenario 5 

Overview 

This scenario allows checking out multiple versions of one member. The second check out is 

for emergency purposes. 

The first developer checks out to a personal library, a project library, or a shared 

development library. The second developer checks out to a personal library, a project library, 

or a shared development library by selecting from an existing version. To do this, the 

23


24 

developer must have emergency capabilities. The developer completing the emergency 

development resolves the conflict and promotes the request back into production. The next 

programmer and/or administrator completes the same actions. 

To focus on the emergency features, this scenario includes only one quality assurance 

environment. 



1 Check out the first version of a member. Developer checks out to a personal library, 

project library, or shared development library. 

2 Develop and test. Developer begins a programming change. 

3 Check out second version for an emergency. Developer checks out a second copy for an 

emergency change to a different environment. This is often an emergency check out. You 

must also select a specific version of the member to start with. For emergency 

development, this is probably the original production member/object. This is normally 

considered concurrent development that requires specific authority, however, in this 

case the emergency check out rights override the concurrent development requirement. 

4 Make the emergency change. Developer codes, compiles, and tests. 

5 Resolve the conflict for emergency version. This resolves all conflicts of the emergency 

version of the member. Promoting a request often includes conflict resolution as 

described in the next task. Usually, the user who has emergency capabilities to resolve 

conflicts and complete moves has this authority. 

6 Promote the emergency version to production. Developer creates the promotion request. 

You normally promote this request directly into production using the Auto Submit 

Through Step in the move function. 

7 Complete the first change. Developer codes, compiles, and tests. 

8 Resolve the conflict for first change. 

Developer notifies the administrator that conflict resolution is necessary. 

Administrator resolves all conflicts of the first completed version of the member. 

Promoting a request often includes conflict resolution as described in the next task. 

This step could include reviewing the source code of the emergency version, or even 

performing a merge or compare of the version. 

9 Promote the first version to production. 

Developer creates the promotion request. 




Setup Tasks 







Emergency development environment, one development environment for all 

developers, or specific environments per developer or project. 



request that targets production. Additionally compiles the promotion request in the 

work library. 

Developer with emergency capabilities checks out members/objects using Emergency 

Check Out, performs development, and creates an emergency promotion request 

that targets production. This developer compiles and moves the promotion request 

into the production environment and has conflict resolution capabilities. 

Administrator creates projects and moves the promotion request to production. 

Multiple Data Libraries, Identical Structures: Scenario 6 

Overview 

In this scenario, the production application has two database libraries. Both libraries have 

identical structures containing the same file objects, however, the data may differ between 

one set and the other. Implementer supports this scenario by creating two environments and 

25


26 

combining them in an environment group. These extra database libraries are either for 

training and testing, or for a second division of the organization that uses the same program 

libraries but requires separate data. 

The example given is for multiple production database libraries, but you could also use this 

for multiple database environments for a quality assurance environment. In this case, the 

extra database files libraries are usually for different test databases. 




development library. The developer checks out from the full production environment. 



Developer creates the promotion request targeting an environment group. The 

environment group has the check out From environment as the first environment. 

The database environments are also part of this environment group. 

Developer can compile the promotion request into the work library. 

Administrator moves the members/objects into the production environments. You 

can perform the moves to the different environments at different times. 

Setup Tasks 



Production, one production environment for the complete application. 

Database files environment (for production), one production environment for each 

database files library. 



2 Create an Environment Group task. Define the following environment group: 

Production, one environment group that combines the full production environment 

with the database files environments. 



promotion request targeting the quality assurance environments. The developer 


Administrator creates projects and moves the promotion request to production.

Separate Production Modifications: Scenario 7 

Overview 


This scenario allows for managing modifications to production in a separate environment 

from the base production application. This method is commonly used when making 

modifications to a standard packaged application, and when you are not making the 

modifications directly to the application. 

You define the base production and modified production libraries as two separate 

environments so you can control them separately. You can add additional modification levels 

to this scenario. In many cases there is only one copy of the database in a separate library, and 

since both reference it, it is defined as part of both the modified and base production 

environments. 

After checking out from the modified production environment, you bring all development 

changes back to the modified production environment. You always check out the member 

from the modified environment to development, regardless of whether the item to be 

changed is already in the modification library. If you have not modified the item, it is 

automatically copied from the base production environment. 

This scenario is similar to the scenario for Modifications to Vendor Software, except there are 

no external changes from a vendor (or a common development group) that you must 

periodically incorporate into the application. 


This is the typical sequence from the start of a programming change to completion. 

1 Check out the member/object from the Mods environment. Developer selects the 

member/object from a list of all items in modified production and/or base production. 

Check out automatically determines to take the version from modified or base 

production for new development. 

2 Develop and test. Developer begins the programming change and tests the member/ 

object in their development environment. 

27


28 

3 Promote the member/object to quality assurance. 






accuracy. 

5 Promote the member/object to Mods production. 

Tester copies the original promotion request and changes the target environment (or 

environment group) to the Mods environment. 

Administrator moves the members/objects into modified production. 

Setup Tasks 



Base Production, one production environment for the base version of the application. 

If all files are in a single library, define that library as the file library for this 

environment, as well as for the modified production environment. 

Mods Production, one production environment for the modifications of a particular 

application. Set up the related environments with modified production above the 

base production environment to allow automatic selection of the correct version 

during check out. If all files are in a single library, define that library as the file 

library for this environment, as well as for the modified production environment. 

Quality Assurance, one QA environment for each release of a particular application. 

Development environment, one development environment for all developers for each 

release, or specific environments per developer or project. 

NOTE Related environments are always connected to the modification environment, 

never to the base environment. 



request targeting quality assurance, and is allowed to perform concurrent 

development. The developer compiles the promotion request in the work library. 

This user only has authority to check out from the modified production 

environments and promote to the quality assurance environments being supported. 

Tester performs the tests in the test environment with his own copy of the changes.

Multiple Software Releases: Scenario 8 

Overview 


This scenario allows you to manage multiple software releases for a given application. 

You can create a new release that contains only the changes to the prior release(s). 

NOTE This illustrates a delta scenario, where the new release contains only the 

objects that are different from the original release. It is also possible to set up a non 

delta scenario, where both libraries contain the entire product. The differences in 

setting up these two variations are described in “Differences Between Delta and 

Non Delta Variations” on page 32. 

During check out for development on the new release, Implementer searches each release 

and copies the item from the most recent release. A list of all items logically a part of the new 

release is available, whether they are physically in the new release or only in the old release. 

Development on the previous (1.0) release can continue using the basic development 

scenario. You may need ongoing support for this release, since it is in production while you 

are developing the newer release. You can add unlimited additional releases—allowing for 

the support of multiple prior releases—while developing the newest release. 

You frequently use concurrent development with this scenario to manage concurrent 

changes to the same object in multiple releases. 



Separate development activities occur for both releases. 

29


30 

Changes to Release 2.0 

1 Check out the member/object from Production 2.0 environment. Developer for release 

2.0 selects the member/object from a list of all items in release 2.0 production and/or 

release 1.0 production. Check out automatically determines to copy the version from 

release 2.0 or release 1.0 production for new development. 

2 Develop and test Release 2.0. Developer begins the programming changes and tests the 

member/object in his development environment for release 2.0. 

3 Promote the member/object to quality assurance 2.0. 




Administrator moves the members/objects into quality assurance 2.0. 

4 Quality assurance testing release 2.0. Tester tests the change for functional consistency 

and accuracy. 

5 Promote the member/object to Production 2.0. 


environment group) to Production 2.0. 

Administrator moves the members/object into Production 2.0. 

Changes to Release 1.0 

1 Check out the member/object from Production 1.0 environment. Developer for release 

1.0 selects the member/object from a list of all items in release 1.0 production. 

2 Develop and test Release 1.0. Developer begins the programming change and tests the 

member/object in his development environment for release 1.0. 

3 Promote the member/object to quality assurance 1.0. 




Administrator moves the members/objects into quality assurance 1.0. 

4 Quality assurance testing release 1.0. Tester tests the change for functional consistency 

and accuracy. 

5 Promote the member/object to Production 1.0. 


environment group) to Production 1.0. 

Administrator moves the members/objects into Production 1.0.

Setup Tasks 



1 Create an Environment task. Define the following environments for Release 2.0: 

Production 2.0, one production environment for release 2.0 of a particular 

application. Define related environments and place production 2.0 above 

production 1.0 to allow the automatic selection of the correct version during check 

out. 

Quality Assurance 2.0, one QA environment for release 2.0 of a particular application. 

Development environment 2.0, one development environment for all developers for 

each release, or specific environments per developer or project. 

Define the following environments for Release 1.0: 

Production 1.0, one production environment for release 1.0 of a particular 

application. 

Quality Assurance 1.0, one QA environment for release 1.0 of a particular application. 

Development environment 1.0, one development environment for all developers for 

each release, or specific environments per developer or project. 

2 Create a User Profile task. 

Define user profiles for the following user roles for Release 2.0. 

Developer 2.0 checks out members/objects, performs development, creates a 

promotion request targeting release 2.0 quality assurance, and is allowed to perform 

concurrent development. The developer compiles the promotion request in the 

work library. This user only has authority to check out or promote to the most 

current release supported. 

Tester 2.0 performs the tests in the test environment with their own copy of the 

changes. 

Administrator 2.0 promotes changes into the test environment to allow the tester to 

start testing a change. 

Administrator 2.0 creates projects and moves the promotion request to release 2.0 


Define user profiles for the following user roles for Release 1.0. 

Developer 1.0 checks out members/objects, performs development, creates a 

promotion request targeting release 1.0 quality assurance, and is allowed to perform 

concurrent development. The developer compiles the promotion request in the 

work library. This user only has authority to check out or promote to releases other 

than the new one in development. 

31


32 

Tester 1.0 performs the tests in the test environment with their own copy of the 

changes. 

Administrator 1.0 promotes changes into the test environment to allow the tester to 


Administrator 1.0 creates projects and moves the promotion request to release 1.0 


Differences Between Delta and Non Delta Variations 

The previous tasks described how to set up a delta scenario, where the new release library 

contains only the objects that are different from the original release. You can also set up for 

multiple releases using a non delta scenario, where both libraries contain the entire 

application. 

TIP The delta scenario is recommended when disk space is an overriding concern 

and you have limited changes. The non delta scenario, which is easy to use, is 

recommended when disk space is not a consideration and when frequent changes 

are made to the database. 

The following table describes the differences in setting up delta and non delta scenarios. 

Delta Scenario Non Delta Scenario 

Description Release 2.0 library contains only 

objects that are different from 

release 1.0. If some changed 

programs use additional files, those 

files may also need to be copied. 

Release 2.0 and release 1.0 both 

contain the entire application. 

Related environments Requires set up. Does not require set up. 

Related objects Requires set up. Does not require set up. 

Library lists Requires release 1.0 libraries in 

release 2.0 library list. 

Should not have release 1.0 

libraries in release 2.0 library list.

Modifications to Vendor Software: Scenario 9 

Overview 


This scenario is for users who have modified vendor-supplied software and at the same time 

need to receive PTFs and new releases from the vendor. Several types of development 

activities exist in this scenario: modifying the application, applying vendor PTFs, and 

applying an entire new release from the vendor. You define each of these activities in detail. 

Applying a new release for a large application that has been heavily modified can be a very 

large project; however, it can be greatly simplified by using MKS NewVersion with 


To receive support from the vendor for the original application, all modifications to the 

package reside in separate libraries. This allows duplicating any problems using just the basic 

application from the vendor to determine if an issue occurred with a custom modification, or 

is part of the base application. 

For simplicity, this scenario illustrates making the changes directly to the base, although it is 

not required. You can keep modified vendor changes in a separate environment. 

This scenario is similar to the scenario for Separate Production Modifications, except there 

are external changes received from a vendor or from a common development group that you 

must periodically incorporate into the application. 

This scenario capitalizes on the concurrent development features of Implementer, and the 

source merging capabilities of NewVersion. 


There are multiple development tasks for this scenario: 

change a vendor-delivered member/object or create a new member/object 

apply vendor PTFs 

33


34 

apply a new release from the vendor 

Change a Vendor-Supplied Member/Object or Create a New One 

1 Check Out from custom Mods production. Developer selects the member/object from a 

list of all items in custom Mods production and/or the vendor base production. Check 

out automatically determines whether to use the version from custom Mods production 

or the vendor base production for each change. Implementer copies the correct source 

into development for custom modifications. 

2 Develop and test. Developer codes, compiles, and tests the members/objects. 

3 Promote the member/object to Mods quality assurance. 

Developer promotes the member/object from Mods development to Mods quality 

assurance. 



4 Quality assurance. 

Tester tests programs. 

Tester copies the original promotion request for promotion. 

5 Promote to custom Mods production. Administrator for custom Mods production 

promotes the members/objects to customer Mods production. 

Apply Vendor PTFs 

1 Restore the PTF. Use the instructions supplied by the application software vendor to 

restore the PTF into a new library (referred to as the PTF library). 

2 Check out all items on the PTF and compile. Check out all items on the PTF, from the 

vendor base production environment to the vendor PTF development environment. 

Replace the entire source and objects with those from the PTF library and compile all 

source. Test the PTF using the development environment and the vendor base 

application. 

3 Check out any modified items included in the PTF. You can identify custom 

modifications to any item included with the PTF using Work with Objects. You must 

check out each modified item that is part of the PTF as if making another custom 

modification. You must have concurrent development capabilities to perform this check 

out since the object was previously checked out to the PTF environment. The next step 

applies the PTF to the customized version. 

4 Merge the PTF into the customized version. Using the Workbench, merge the PTF 

changes into the customized member in development. Specify modified development as 

the target library, modified production as production, the PTF development library as 

enhanced, and the base application library as base. This applies all vendor-supplied PTF


changes to the modified member. Review the Merge report and respond to any 

messages. Compile the member and perform testing. Ensure the PTF development 

library is on the library list for testing. 

5 Promote any modified items to testing. Promote any modified items that now contain 

the PTF to Mods quality assurance. 

6 Promote all PTF items to testing. Promote all items changed from the vendor PTF 

development environment to the vendor quality assurance environment. 

7 Promote modified items to modified custom Mods production. After testing, promote 

any modified items from Mods quality assurance to custom Mods production. 

8 Promote PTF objects to base application. After testing, promote all vendor objects from 

vendor testing to the vendor base production. 

Apply the New Release From the Vendor 

These tasks require the use of NewVersion, a separately-licensed MKS product. 

1 Load the new release from the application vendor. Use the instructions supplied by the 

application software vendor. The vendor should supply instructions to install the 

changes into test libraries, rather than directly into your custom Mods production 

version of that software. The directions from the vendor may be as simple as telling you 

which libraries to restore from tape, using the Restore Object (RSTOBJ) or Restore 

Library (RSTLIB) command. The vendor may provide installation utilities that you must 

run as described by the vendor. 

2 Analyze the new release libraries. Complete this step using the NewVersion functions 

“Define Target Libraries” and “Build Target Object Entries” to analyze the libraries. Use 

the “Print Action Messages” function to print a list of action or exception messages to 

review or resolve. Use the “Print Object Report” function to determine which objects 

require merging. 

3 Check out the objects that NewVersion has determined require merging. This checks out 

from the custom modifications production environment (with an automatic copy from 

the vendor base production, if needed) to a development environment. At this point, you 

might encounter members/objects that are already checked out. If you have some of 

these members/objects checked out already, check them out to a different development 

environment or library. Implementer considers this concurrent development. 

Concurrent development requires you to resolve conflicts before or during creation of 

the promotion request. The library you check out to must be the same library as the 

target library defined to NewVersion. 

The check out being performed is simply securing a lock on each of the members/ 

objects. The source that is copied as part of this check out is replaced with the source 

merged in the next step. 

35


36 

4 Merge the source members and analyze the results. In NewVersion, use the “Create 

Target Source” function to create the new source members. Use the “Merge Reports” 

function to verify correct results and resolve object differences. 

5 Compile the new source members. In NewVersion, use the “Create Objects” function to 

compile the new source members. 

6 Test the changes. Use a library list that has the NewVersion target library at the top, with 

libraries containing the unmodified version of the objects below it. 

7 Promote to the custom modifications environment. The promotion request promotes 

from the NewVersion Target library to the custom modification environment. This 

promotion request can require resolving conflicts caused by the concurrent 

development. For details on concurrent development, see “Concurrent Development: 

Scenario 4” on page 21. 

Setup Tasks 


1 Create an Environment task. Define the following custom Mods environments for this 

scenario: 

Custom Mods Production, define a production environment. Related environments 

set up with modified production above the base production environment allow 

automatic selection of the correct version in check out. If all files reside in a single 

library, that library is defined as the file library for this environment, as well as for 

the vendor base production environment. 

Mods Development, define a development environment. 

Mods Quality Assurance, define a quality assurance environment. 

Define the following Vendor environments for this scenario: 

Vendor Base Production, define a production environment. If all files are in a single 

library, define that library as the file library for this environment, as well as for the 

modified production environment. 

Vendor PTF Development, define a development environment. 

Vendor Quality Assurance, define a quality assurance environment. 

2 Create a User Profile task. The same group of developers and testers are commonly 

responsible for custom changes, as well as applying vendor PTFs and new releases. 


request targeting quality assurance, and is allowed to perform concurrent 

development. The developer compiles the promotion request in the work library.


This user has authority to check out from the modified and base production 

environments and promote to the modified and vendor PTF quality assurance 

environments. 

Tester performs the tests either in the modified quality assurance or vendor PTF 

environments using their own copy of the changes. 

Administrator promotes changes into the test environments to allow the tester to 


Administrator creates projects and moves the promotion requests to modified 

production or to the vendor base production environments. This user also has 

conflict resolution capabilities. 

Release Control: Scenario 10 

Overview 

A typical release control development scenario starts with setting up your products and 

versions, and attaching the environments associated with each product at the version level. 

You then create an open release (the release must be at a status that allows software changes 

to occur, for example, ENV-OPEN). Any issues or design requests that have at least one 

entity promoted to production while the release is open are attached to that release. 

Follow your normal change management procedures for checking out and promoting 

member/objects. When you are ready to close a release (for example, for system test or to 

target production) set the release to a status that does not allow software changes (for 

example, ENV-CLOSED). This prevents promotions from targeting the environments 

defined for the version that allow creating standard releases from it (defined when you attach 

an environment to a version). Changing the status from one that allows software changes to 

one that does not allows you to capture an image of the Implementer repository so you know 

exactly which objects were in the release when it closed. 

37


38 

When you are finished with the release, set it to a status where all four status fields, Allow 

software change, Allow packaging, Allow controlled distribution, and Allow distribute changes 

are set to N (for example, NOT SUPPORTED). Changing the release status allows you to 

control movement into production environments. You can now create a new open release, 

allowing the change management cycle to begin again. 

Setup Tasks 

In most cases the implementation of this feature requires minimal setup to your existing 

configuration, allowing you to quickly append release control into your existing change 

management operation. 


1 Create environments. No special considerations are required when defining 

environments for release control. Follow the environment setup steps described in a 

previous scenario, or see “Implementer Administration” on page 63 for information on 

creating environments. 

2 Define user authorities. Users must have authority to work with products and versions. 

This is defined in the Work with Users function. Set the Maintain Products and Maintain 

Versions fields to Y for each user who maintains product versions. 

3 Define products, versions, and releases. For details, see the MKS Implementer 2006 Release 

Management Guide. 

4 Verify the software release process configuration. This consists of release types and the 

release status; together, they determine the development path that each release must 

follow. 

Release types are user-defined values that identify the types of releases you manage 

within the release control process. Release types are classified as either standard 

(STD) or program temporary fix (PTF). 

Release status defines the path a release must follow before you can changed it to 

the next available status. It also defines the functions you can perform to the release 

during each phase of the development cycle. A person with product management 

responsibility typically controls this stage progression. 

The release status controls four functions: 

Allow software changes controls whether software can be promoted into the 

environments attached to the product version. 

Allow create package controls whether packages can be created. 

Allow controlled distribution controls whether the release is available for 

selection to distribute to a customer system, but does not make it a default 

release. This is also used for release deployment.


Allow distribute changes controls whether the release can be the default release 

to distribute to a customer system as the most current release available. This is 

also used for release deployment. 

The release category and the release status together determine the development path 

that a release must follow, and the dependency automatically associated between a 

current release and a previous release. 

Release Control Development Cycle 

The development cycle associated with release control effectively handles when objects are 

promoted back to production, without hindering the start of new development. Release 

control supports both single version and multiple version development models, as illustrated 

in the following chart. 


The next six scenarios pertain to promotions that target remote iSeries systems using the 

Implementer Receiver. 

39


Remote Production on Same Request: Scenario 11 

40 

Overview 

In this scenario you distribute changes to a single remote system on the same promotion 

request as a local version of production environment. This scenario ensures the production 

system remains synchronous with the development system. 




development library. The developer checks out from the local production version. 


3 Promote and distribute to production. 


environment group has the check out From environment listed as the first 

environment, and the remote environment as the second environment. 

Developer can compile the promotion request into the work library. Typically, you 

compile just for the first environment. 


can perform the moves to different environments at different times, if needed. Many 

options exist for distributing changes to the remote system.

Setup Tasks 




Local Production, one production environment for the local development system. 

Remote Production, one production environment for the remote production system. 




Production, create an environment group that combines the local production 

environment with the remote production environment. 






production. 

Remote Production on Different Request: Scenario 12 

Overview 

In this scenario you distribute changes to a single remote system on a different promotion 

request than the local promotion, to the production environment. This scenario ensures the 

production system remains synchronous with the development system. 






41


42 


Developer creates the promotion request targeting an environment. 



Administrator moves the members/objects into the production environment. You 

can perform the moves to the different environments at different times, if needed. 

Many options exist for distributing the changes to the remote system. 

4 Promote and distribute to remote production. 

Developer creates the promotion request targeting a remote environment. You can 

create the request by copying the original request. 




Setup Tasks 








Production, one environment group that combines the local production environment 

with the remote production environment. 






production.

Testing on Remote: Scenario 13 

Overview 

In this scenario, you distribute changes to a single remote system in two phases: 

1 To test environments on the host and remote. 


2 From test environment on the host to both the local and remote production. You 

distribute the changes for testing on the same promotion request as a local version of the 

quality assurance environment. You distribute the changes for production on the same 

promotion request as a local version of production environment. 






3 Promote and distribute to local and remote test environments. 


environment group has the environment you checked out from listed as the first 




Administrator moves the members/objects into the test environments. You can 

perform the moves to the different environments at different times, if needed. Many 

options exist for distributing changes to the remote system. 

43


44 

4 Quality assurance testing. Testers (on both the local and remote systems) test the change 

for functional consistency and accuracy. 

5 Promote and distribute to local and remote production environments. 

Tester on the local system creates the promotion request targeting an environment 

group. The environment group has the environment you checked out from listed as 

the first environment, and the remote environment as the second environment. 






Setup Tasks 





Local Quality Assurance, the local QA environment. 

Remote Quality Assurance, the remote QA environment. 



2 Create an Environment Group task. Define the following environment groups: 



Testing, one environment group that combines the local test environment with the 

remote test environment. 





Tester performs the test in this environment with their own copy of the changes. 

Administrators promotes changes into the QA environment to allow the tester to 



production.

Multiple Remote Productions Same Changes: Scenario 14 

Overview 


In this scenario, you distribute the same changes to multiple remote systems on a different 

promotion request than the local version of production environment. This scenario ensures 

the production system remains synchronous with the development system. 






3 Promote to local production. 




Administrator moves the members/objects into the production environment. 


Developer creates the promotion request targeting an environment group. 

Administrator moves the members/objects into the remote production 

environments. You can perform the moves to the different environments at different 

times, if needed. Many options exist for distributing the changes to the remote 

system. 

45


46 

Setup Tasks 









with the remote production environments. 






production. 

Multiple Remote Systems: Scenario 15 

Overview 

In this scenario, you distribute base changes to multiple remote systems and a specific 

promotion request to remote systems.This scenario ensures the production system remains 

synchronous with the development system.




1 Check out from base production. Developer checks out to a personal library, project 

library, or shared development library. The developer checks out from the local 

production version. 


3 Promote and distribute to base production and multiple remote sites. 


environment group has the environment you checked out from listed as the first 







4 Check out from Site N Mods on local system. Developer checks out to a personal library, 

project library, or shared development library. The developer checks out from the Local 

Site N version. 


6 Promote and distribute to remote site N production. 







Setup Tasks 






environments per developer, project, or site. 

47


48 









production. 

Check Out From Remote: Scenario 16 

Overview 

In this scenario you check out the source from a remote system to development on the host 

system. You promote the changes to the production environment on the host and distribute 

the changes to the remote system where the original check out occurred. You distribute these 

changes on a different promotion request than the local version to the production 

environment. 



1 Check out. Developer checks out source from the remote system to a personal library, 

project library, or shared development library. The developer checks out to the local 

development environment. 


3 Promote to local production. 

Developer creates the promotion request targeting the local production environment. 



Administrator moves the members/objects into the production environment.


Multi-Platform Development and Deployment Scenarios 

Developer creates the promotion request targeting by system/environment. In this 

case, you would probably distribute only the source. 

Administrator compiles the members/objects into work libraries on the remote 

system. 

Administrator moves the members/objects into the remote production 

environments. 

Setup Tasks 












production. 

Multi-Platform Development and Deployment 

Scenarios 

Change is always certain. In every industry, companies face the difficult task of trying to 

manage a multitude of changes. The companies that handle changes best are the ones that 

excel and rise above their competition. 

With the rapid migration towards e-Business solutions, the rate at which you need to turn 

around system solutions has increased dramatically. There is no buffer for backtracking and 

reworking when things are missed or overlooked. 

There is also a much greater need to integrate many different system components from 

various teams. The days of long release cycles are disappearing, and this changing business 

model demands tighter management and coordination. Now, more than ever, development 

teams need support for Software Configuration Management (SCM) and for handling change 

requests quickly and efficiently, especially across multiple platforms. 

49


50 

MKS Integrity enables collaboration across the enterprise, connecting technical and non 

technical teams—even partners and customers—in rapidly building, sustaining, and 

evolving e-Business processes, Web content, and software applications. MKS Integrity can be 

used to manage your development work on the iSeries, as well as your Java and C++ 

development. 

Integrated Solution 

In a rapidly evolving organization, change happens at Web speed. Rapid business evolution 

means rapid customer growth, requiring new forms of collaboration, rapid content 

expansion, and application adaptation leading to rapid system instability. The result is 

evolution shock. MKS Integrity can prevent evolution shock, providing you with content 

management, software management, and collaboration in one built-for-e-Business integrated 

package. 

Software Configuration Management 

Rapid business evolution means rapid software adaptation to truly evolve to e-Business. 

Organizations now must rapidly integrate and evolve back end systems for maximum 

competitive advantage. 

Implementer and MKS Source allow team members to effectively manage multiple 

development projects, secure software assets, meet deadlines, and contribute throughout the 

application and development lifecycle. Using MKS’s SCM solutions, organizations can track 

their e-Business evolution with precision and avoid the pitfalls of evolution shock. 

Change Management 

Rapid business evolution means new forms of collaboration. In an e-Business, virtual teams 

of people from inside and outside of the organization create a powerful chain of actions that 

join together to continually evolve content, software, and business processes. 

MKS Integrity automates and synchronizes your business and IT processes so that only 

authorized content and application changes are delivered with accuracy at the right time. 

Organizations using MKS Integrity will strengthen their chain-of-action, particularly when 

faced with constant business pressure to respond to changes. 

iSeries Design and Implementation Management 

The MKS iSeries products offers both functionally and technically advanced tools that protect 

your company’s corporate investment in application systems on the iSeries, while ensuring 

production software integrity and quality. It is designed to fulfill the short- and long-term 

requirements of your application development lifecycle.


Implementer provides implementation management controls for the check out and 

promotion of traditional and non traditional members and objects as they move from 

production to development, from development to QA, and from QA to production. During 

these processes, status information is fed back to MKS Integrity that, in turn, serves to inform 

anyone interested in the issue of the project’s status. 

Implementer supports Windows and Web-based applications being developed on a 

Windows desktop, using MKS Source to manage the desktop. With Implementer, you can 

automatically pull the files needed for execution (or in the case of HTML, the content to be 

deployed) from the MKS Source build Sandbox®, and deploy these items using the 

Implementer Receiver. 

MKS Integrity provides issue tracking using a Windows or Web interface. MKS Integrity is 

completely customizable and eliminates the need for a user to sign on to the iSeries to log 

issues. 

A single issue ID is used to manage a change across multiple platforms with MKS Integrity, 

when using Implementer and MKS Source to manage your IFS multiple platform 

development on the iSeries. 

Working in a multi-platform environment places additional requirements on the 

development process. Dealing with problems and issues is part of the normal development 

lifecycle, and during multi-platform development and deployment, the need to deal with 

them becomes particularly acute. Consequently, there is a critical need to: 

manage change requests in the software development lifecycle, including across 

platforms and during deployment 

manage the physical movement of source and objects 

ensure the context for deployment is appropriate for the: 

platform 

file type (HTML, client Java, server Java, native objects, databases) 

target technology environment (such as, Web server and database server) 

Multi-platform development and deployment is defined as software development where: 

objects are built on one platform and deployed on another, or 

objects deployed on multiple platforms inter-operate to form a single solution and are 

managed together 

A platform in this case does not just refer to hardware—it can also be a logical platform. For 

example, Java provides a target platform no matter what hardware it is run on, and the 

iSeries, NT, and UNIX operating systems also provide platforms. 

51


Software Development Lifecycle 

52 

The software development lifecycle is highly involved and has many variables. Accordingly, 

only the steps in the software development lifecycle applicable to problems encountered in 

multi-platform development and deployment are discussed herein. The software 

development lifecycle is described in more detail in “Managing the Physical Movement of 

Objects” on page 54. 

Many multi-platform development models are possible. Some examples of the types of 

development and deployment are as follows: 

development object (such as static Web content (HTML, GIF)) is deployed using the 

iSeries as the target Web server 

development object is one-to-one with the release object, such as for server Java 

development 

client Java development, for example, Implementer Capability Wizard 

client Visual Basic development (an application, such as MKS Integrity, accesses an 

OS/400 database) 

client C/C ++ development 

any application using a SETUP.EXE executable 

a proprietary development and deployment model (for example, PeopleSoft World) 

Another way to look at the various development environments is to look at several of the 

metrics that apply to all development types. Each environment has varying degrees of 

change being made during development through to the final object being placed in 

production. The metrics to consider are as follows: 

Degree of Transformation 

Between Development and 

Production 

Same (HTML, OCL) 

One to one (RPG, Java) 

One to many (C, dll, JAR 

(Java Archive), *SRVPGM 

One to many several times 

(SETUP.EXE) 

The development process can involve many users and many roles. The major roles of interest 

in multi-platform development and deployment are: 

developer 

builder (the buildmaster) of the release object 

Deployment Environments Execution Locations 

Native RPG 

Java programs 

Application server 

Web server 

Visual Basic applications 

Open environment (servlets) 

Proprietary environments 

Server 

Client 

Client (served from server)

deployer 

tester 

development manager/project leader 


Additional roles may be added at each point in the process; however, adding roles changes 

the process, but it does not alter the change management activities. 

Managing Change Requests 

Software systems require change. Change is identified by a change request. A change goes 

through the appropriate software development lifecycle based on the technology and the 

platform. By using change requests, two classes of management information must be 

available at all times. These can be represented by the following questions: 

Where in the software development lifecycle and deployment is the change request? 

What change requests are resolved in this new version of an object? 

In addition to tracking by change request, it is also important to be able to work based on 

change requests. This allows work to be done on a change request and at the same time to 

affect all of the related objects. 

The General Process 

Typically, change requests flow through the following stages: 

Does an issue 

exist? 

Customer 

Deliver 

Analyze 

Change 

Requests 

Design 

Implement 

Test 

53


54 

Identifying an Issue 

A user submits a change request to report a bug, enhance functionality, or add new 

features. 

Analyze 

Once you decide to accept the change request, you analyze the problem and identify 

what needs to be created or changed to provide a suitable solution. This may include 

things other than software, such as technical publications or training materials. 

Design 

You define the solution, establish a schedule for completion, and assign the tasks to 

individuals. 

Implement 

You develop each solution component, which may include coding or documenting the 

changes to the product, system, or application. 

Test 

You test the solution to ensure it performs as designed and meets the customer’s original 

need. 

Deliver 

The cycle is completed once you deliver the requested change back to the customer, 

ensuring their satisfaction. This corresponds to delivering a new release of a product or 

releasing the changes to the production systems. 

“Identifying an issue” and “Analyze” represent the Decision Phase, which addresses the 

assessment and negotiation steps that are required to ensure that changes are prioritized 

and scheduled for a timely resolution. “Design” and “Implement” are referred to as the 

Development Phase. “Test” is referred to as the Verification Phase, and “Deliver” as the 

Deployment Phase. 

Sometimes, for small changes, a person may quickly go through the thought process for 

the first four steps in one step (for example, correcting a typographical error). For more 

complicated cases, these steps may be handled by different roles such as a review board, 

developer, or QA manager. It is important, therefore, to structure your process to 

incorporate the ability to hand off the issue to the responsible parties. Whatever process 

you enforce, you want to verify that it supports these four basic phases. 

Managing the Physical Movement of Objects 

The purpose of a change management system is to manage the movement of software objects. 

Yo must accomplish this in an appropriate way for the platform containing the objects. This 

includes, for example, honoring and enforcing the security and integrity of the platform. 

MKS Integrity provides an effective means of dealing with the problems and issues 

surrounding multi-platform development and deployment.


MKS Integrity provides a complete SCM solution. It helps development, QA, and 

geographically distributed team members to easily organize, manage, and contribute to the 

software development lifecycle. This system provides Web-based access to software 

configuration management, defect tracking and task management (MKS Integrity)—all the 

tools a team needs to move projects from code to release. 

MKS Source and MKS Integrity introduce some new terms you may not be familiar with. The 

glossary provides brief descriptions of some of the common terms this guide uses when 

discussing change management. 

The following diagram shows the typical object flow during the Development, Verification, 

and Deployment Phases of the software development lifecycle. 

55


56 

The Change Request Process Desktop iSeries 400 

Step One: Log Change Request 

Step Two: Initiate and Complete 

Development 

Step Three: Create Release Object for 

Production (Build) 

Step Four: Move Release Object to Testing 

Step Five: Move Release Object to 

Production 

Development 

Sandbox 

MKS Source 

Archives 

(Source, Objects) 

Build Sandbox 

Source 

Objects 

Verification 

Phase 

Deployment 

Phase 

Promotion 

Request 

Development 

Phase 

Development 

Testing 

Details of this flow are described in the following sections. The process describes typical new 

product (released-based) desktop development. Another form of similar software 

development is continuous desktop development. The next table characterizes each type. 

IFS 

Production 

Production 

Archive 

Production 

Production n 

Archive

Release-based 

Development 

Continuous 

Development 


Characteristics Significance of Characteristics 

Problems typically represent requirements or 

new features and functions as specified by 

product management or business analysis. 

The initial development process requires the 

coordination of the analysis, design, and 

development tasks across various team 

members. This model supports the iterative 

steps of the development process. 

There is a clear distinction between the 

various components that need to be 

developed, and the testing process that 

focuses on black box functionality. 

Need to track all tasks being done according 

to relevant components. 

With larger development tasks, multiple 

people may need to work on the same 

proposal and their work status needs to be 

coordinated. 

Need to separate the problem process from 

the proposal and work instruction processes 

to allow for separate levels of monitoring. 

Certification and acceptance testing are 

typically handled by a Quality Assurance 

(QA) team. 

Decisions to release the product are based 

on the results of the system testing phase. 

Initial development phase has passed and 

software has been released to the customer. 

Maintenance cycle has begun. 

All work is generated by issues or problems 

raised against the released product. 

Changes are typically bugs or small 

enhancements. 

Several problems are gathered together to 

be fixed in a particular release. 

Development and product managers work 

together to negotiate priorities and decide 

what will be fixed in a release. 

Requirements analysis and design are 

minimal and it is not necessary to track them 

with separate states. 

Need to ensure all code changes are tracked 

along with the original problem. 

Functional testing is handled within the 

development team. 

Proposals and work instructions may be used 

but are not tracked with a process. 

Work is planned and monitored closely to 

distribute work evenly across resources and 

synchronize parallel tasks. 

When various groups within an organization 

are monitoring the progress of problems, 

they may not be interested in the detailed 

development status. By separating the 

process from development tracking, it is 

possible for various managers to monitor the 

status of the problems they are interested in 

at a high level. 

Separate process flows for proposals and 

work instructions help to focus the process 

details as needed rather than having one 

long overwhelming process on a problem. 

Supports parallel development tasks and 

allows for independent tracking of each task. 

Process focused on the problem only, since 

the goal is to manage a high volume of 

issues rapidly. 

It is important to record changes with a 

proposal change package, but the process 

flow for the proposal is not significant. 

Simplified process facilitates the rapid handoff 

of responsibility among the developer, 

build coordinator, and QA team. 

Able to handle a high volume of problems 

and ensure they do not fall through the 

cracks or get lost along the way. 

57


Change Request Process 

58 

Step One: Log Change Request 

Enter change requests (problems or program modification requests) as MKS Integrity issues. 

Step Two: Initiate and Complete Development 

Using MKS Integrity issues, assign work to developers. 

The developer checks out the required source in either Implementer or MKS Source, 

depending on the platform location and tool appropriateness of the objects needing to be 

changed. 

An example of mixed development is a client/server application where the iSeries is used as 

the server. The server programs are written in RPG and the client side is written in C, Visual 

Basic, or Java. In this scenario, a single issue could result in a development effort on both 

platforms, with Implementer supporting the OS/400 side and MKS Source supporting the 

rest. 

The developers finish the work. MKS Source-side developers check in a change package to 

the appropriate source project, and specify the proposal number associated with the issue 

they have fixed. OS/400 developers promote their changes to the appropriate QA 

environment on the iSeries. If these changes rely on the client-based changes also being 

made, the changes are left in the development environment on the iSeries pending receipt 

and deployment of the client objects from MKS Source. Once the client objects are deployed 

to the OS/400 development environment, all objects are then promoted on a single 

Implementer promotion request to the QA environment. 

Step Three: Create Release Object for Production (Build) 

Two types of desktop development need to be considered here: release-based and continuous. 

The following describes released-based development. Continuous development is essentially 

the same, except there is no build reference. 

The buildmaster updates all proposals associated with the issues addressed by the current 

build. That way all the issues can be tied back to the build using a build number (custom field 

on a proposal). This build number field can either be entered manually to the proposals in 

cases where few issues are involved, or it can be set using the MKS Integrity batch operation 

function in larger impact changes. 

NOTE In continuous development, the buildmaster uses the Export to Implementer 

command to export by issue number. 

The buildmaster builds the code that includes the set of issue fixes. The buildmaster also 

gathers the source code version information from the change packages attached to the 

proposals that address the issues, either using the MKS Integrity Change Package feature or 

by manually determining what source items are required based on the level of complexity


and type of work. After resolving any conflicts (manually), the buildmaster checks out all 

required source objects to a build sandbox and generates the required binaries. When the 

buildmaster is satisfied the built objects are correct, they have the option to check in the 

objects to a project to archive the release objects themselves. 

After the binaries (or non binaries that should be deployed) are ready and all proposals 

addressed by this build are flagged with a build number identifier, the buildmaster manually 

moves the objects to be deployed to an IFS location on the iSeries to stage the objects for 

deployment. 

NOTE This location should be a non cumulative location that only contains objects 

specifically related to this build. 

At this point, you issue the Export to Implementer command. For details on running the 

export, see “Exporting to Implementer” on page 140. 

Step Four: Move Release Object to Quality Assurance 

At this point, the build is ready for system testing. Depending on the circumstances, the QA 

group may do either of the following from Implementer: 

process the promotion request from step 4, if created 

access the Workbench, filter the issue, and then create a promotion request 

If user acceptance tests fail, the issues must go back to development for investigation and 

resolution. Once the build is accepted and released, all the issues addressed by that release 

are marked as closed. 

Step Five: Move Release Object to Production 

Once the objects are promoted to a production environment using Implementer, the status of 

all the appropriate MKS Integrity issues are updated. 

Appropriate Deployment 

Objects for deployment are being installed into a production system. In the simplest case, just 

placing an object in the proper location updates the production system, as required. At the 

other end of the scale, significant pre- and post-processing may be required to update the 

production system properly. For example, you must stop and restart the Weblogic 

Application Server before the server can recognize changed classes, because the classes were 

cached earlier by the server. These functions can be performed using promotion request 

special commands. For more information on special commands, see the MKS Implementer 

2006 User Guide. 

59


Implementer and MKS Integrity Integration: Scenario 17 

60 

In this scenario, Implementer users log new issues using MKS Integrity, which provides 

workflow management and issue tracking using a Windows or Web interface, eliminating 

the need for you to sign on to the iSeries to log issues. 

MKS Integrity is the best of breed enterprise choice for highly customizing process and 

workflow management. Any simple defect tracking tool can record the status of a change 

request, but it does not monitor all the components that need to be modified, or the variety of 

tasks that need to be performed to resolve the issue. MKS Integrity 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, MKS Integrity is the enterprise-wide issue management system. 

MKS Integrity integrates with other developer productivity tools—including Implementer, to 

control and track development activity in Implementer, and Microsoft Project. This leverages 

your software investments and enhances the coverage of your application development 

lifecycle. MKS Integrity allows you to manage your Integrated File System (IFS) development 

on the iSeries and PC platforms with a single issue ID that tracks a software change across 

multiple platforms. 


1 Log change request. Enter change requests (problems or program modification requests) 

as MKS Integrity issues. 

2 Initiate and complete development. Using MKS Integrity issues, assign work to 

developers. 

3 Create release object for production (build). Two types of desktop development need to 

be considered here: release-based and continuous. Continuous development is 

essentially the same as released-based development, except there is no build reference. 

4 Move release object to quality assurance. The build is ready for system testing. 

5 Move release object to production. Once the objects are promoted to a production 

environment on the iSeries, the status of all appropriate MKS Integrity issues is updated 

and the related Implementer change packages are closed. 

Setup Tasks 


1 Install and configure Implementer Server. For details, see “Configuring the Implementer 


1 Install and configure MKS Integrity Server and MKS Integrity. For details, see the 

MKS Integrity Server 2006 Administration Guide.

Communications Options 

2 Configure Implementer to use MKS Integrity for issue tracking. For details, see 


3 (Optional) Configure Implementer to use MKS Source archiving. For details, see 


Communications Options 

Implementer provides three options for communications entries between host and remote 

systems: 

Use existing communication entries. This is the recommended method, and no 

additional set up is required. 

Add communication entries to a generic mode description. Using a generic 

communications entry provides some additional control over your communication, and 

must be specifically set up. 

Add communication entries to a specific mode description. You can create an 

Implementer-specific mode description that reserves the communication sessions 

exclusively for Implementer use. This ensures a session is available to Implementer 

when it attempts to communicate with the remote system (unless the maximum 

numbers of sessions for the mode are already in use by other Implementer jobs). This 

option provides the greatest control over your communications. It requires setup on both 

the host and remote systems. 

For details on this topic, see “Setting Up Communications Entries” on page 169. 

Distribution Methods 

Implementer supports software distribution on tape and DVD, as well as the following 

distribution methods: 

SDMCom. Distributions using Implementer’s own object distribution facility, SDMCom, 

provides between 20–35 percent better performance over SNADS distribution. Its 

advanced features use compression algorithms and blocking specifically for remote 

distributions. 

TCP/IP (FTP or tape). Requires additional setup as described in “Setting Up for TCP/IP 

Distribution” on page 173. 

SNADS. Requires additional setup as described in “Setting Up for SNADS Distribution” 

on page 179. 

For details on this topic, see “Distribution Methods” on page 164. 

61


62

C HAPTER THREE 

Implementer Administration 

Configuring Implementer on the Host System 

3 

This chapter describes the administrative tasks you must complete to configure 

Implementer on the host system. Use this chapter, along with the previous chapter that 

describes the various scenarios, to help organize and perform the setup requirements. 


“Overview of Administrative Tasks” on page 64 

“System Control Maintenance” on page 65 

“Users” on page 72 

“Environments” on page 81 

“Environments and User Capabilities” on page 109 

“Environment Repository Build” on page 117 

“Environment Groups” on page 125 

“Object Codes” on page 127 

“Object Name Rules” on page 137 

“Project-based Application Paths” on page 142 

“User-Defined PDM Options” on page 144 

“Issue or Design Request Stamping” on page 145 

“Object Version Stamping” on page 146 

“Considerations With OS/400 and Implementer” on page 153 

“Web-based Development for IFS Objects” on page 155 

“Mounted Drive Support for IFS Objects” on page 159 

63

Chapter 3: Implementer Administration 

Overview of Administrative Tasks 

64 

The tasks in this chapter explain how to define the system wide control parameters within 

Implementer. The tasks also explain how to create and maintain the different types of users, 

environments, and object codes. 

If you distribute software to remote systems using the Implementer Receiver, you must also 

complete the setup tasks described in “Remote Distribution Concepts and Setup” on 

page 161. 

The user who performs these tasks must have authority to the Setup options in Work with 

Users (see page 74). Initially, the iSeries user profile QSECOFR and the Implementer user 

profile MWIPROD have these rights. MKS recommends you designate a different user profile 

with these authorities to use for ongoing administrative tasks. 

Perform the administrative tasks in the following order: 

1 System control maintenance: Set up your company name, default job queue, and many 

other system-wide defaults. Task information begins on page 65. 

2 Create user profile: Define the characteristics and authorities of each Implementer user. 

Task information begins on page 72. 

3 Create environment: Define the characteristics of the different types of environments for 

your applications, related environments, and establish application paths for production 

environments. Task information begins on page 81. 

4 Work with user capabilities: Define the authorities each user has to environments. Task 

information begins on page 109. 

5 Work with object codes: Define each type of object used for promotion. Task information 

begins on page 127. 

6 Reset authorities: Change the OS/400 owners and authorities of objects in the 

environment libraries. Task information begins on page 372. 

7 Build list: Load members/objects into the Implementer environment repository. Task 

information begins on page 117. 

8 Create environment groups: Define environment groups for promotion or distribution 

purposes. Task information begins on page 125. 

9 Set up user-defined PDM: Enable PDM to perform Implementer check out for traditional 

environments. Task information begins on page 144. 

10 Issue management: Set up the integration with MKS Integrity, if applicable. Task 

information is described in “Implementer and MKS Integrity Integration” beginning on 

page 63. 

When you have completed the administrative tasks, you can start using Implementer to 

control your application development.

System Control Maintenance 


This task allows you to set up and maintain the system-wide parameters used throughout 

Implementer. System Control Maintenance also controls the activation of many optional 

features in Implementer. 

Most users change the company name, job queue, CASE tool installation (if applicable), and 

any other values as needed. You can define the system parameters at the time of initial setup, 

once you have completed installation, or when you need to change the configuration. 

Implementer also provides many data areas that allow you to further customize your 

implementation. For details, see “Implementer Data Areas” on page 402. 

Your user profile must have authority to this function. 

To perform System Control Maintenance 

1 From the Implementer Menu, type 45, or type STRIM (*SYSCTLMNT) at the command 

line and press ENTER to display the first of four System Control Maintenance panels. 

The actions you can perform on this panel are: 

F3=Exit returns to the previous panel without updating changes. 

F10=*ALL Special commands allows you to work with global special commands. 

For details, see “Special Command Processing” on page 103. 

F18=Name Rules allows you to work with global object naming rules. For details, 

see “Object Name Rules” on page 137. 

2 Complete the required fields as defined in the following tables beginning. Press 

PAGE DOWN to display the additional panels. 

65


66 

3 When you have finished entering the information, press ENTER to update the 

information and return to the Implementer Menu. 

System Control Maintenance Field Descriptions: Panel 1 

Field Description 

Company name Specify the name to display on the Implementer Menu and on Implementer 

reports (usually the Implementer licensee name). 

Next request number Specify the next request number to issue. A request number is the unique, 

four-character alphanumeric identifier assigned by Implementer when you 

create a new promotion request. 

Beginning with number 0001, the number increments by one for each new 

promotion request. When 9999 is reached, the left most position changes 

to 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 number ZZZZ is reached, the number scheme 

automatically resets to number 0001. The maximum number of available 

request numbers before resetting is 1,200,000. 

Delete compile 

listings 

Message queue 

delivery 

CAUTION You usually do not change this value. If you change it, you must 

specify a number that does not overwrite existing request numbers. 

Specify whether to delete compile listings after successful promotions. 

Compile listings are located in the output queue specified by the interactive 

job when a request is submitted to compile. 

Y: Cancels all successful compile listings and retains all unsuccessful 

compile listings. Eliminates the disk space requirements of retaining all 

compile listings. Successful compiles ensure source-to-object integrity; 

typically, you do not need to retain these job logs. 

N: Retains all successful and unsuccessful compile listings. Use with 

caution; can cause excessive spool files. 

Specify how to deliver messages to the user workstation. 

*BREAK: Displays messages immediately. 

*NOTIFY: Notifies the user of pending messages. Includes turning on a 

message light and sounding a buzzer (if available). 

*HOLD: Retains messages in the message queue for the user to display. 

*SAME: Uses the same message notification as the previous message. 

*DFT: Answers messages requiring a reply with the default message 

reply. Does not add messages to the message queue.

Job log message 

logging 

Number of job logs to 

retain 

Default job queue/ 

Library 


Specify the data to record in the OS/400 job log for Implementer 

processing. 

Level: Corresponds to the first value of the OS/400 job logging level. 

Valid options are 0–4. 

Severity: Severity level used during create request. Corresponds to the 

second value of the OS/400 job logging level. Valid options are 00–99. 

Text: Message text recorded in the job log. Corresponds to the third 

value of the OS/400 job logging level. Valid options are *MSG, *SECLVL, 

and *NOLIST. 

Specify the number of job logs to save before deleting. Determine a number 

that is large enough to keep job logs for a reasonable number of requests. 

For example, 50 job logs may not represent 50 promotion requests, as a job 

log generates for each target environment on the request. Thus, if you 

regularly promote to two environments at a time, specify 100 job logs to 

retain 50 requests. 

Specify the default job queue and library for Implementer-submitted jobs. 

You can change the job queue at job execution for most jobs. 

Initialize tape Specify Y to automatically initialize a tape before saving objects for 

distribution on tape media to remote systems. The default value N does not 

initialize tapes. 

Default tape device Specify the name of the tape device used to save objects on tape media for 

distribution to remote systems. 

Default volume 

identifier 



Specify the volume identifier to use for tape initialization. Required only to 

distribute to remote systems on tape media when the Initialize tape field is 

set to Y. 

Volume: Specify a a six-character value for the volume ID. 

*NONE: Initializes the tape without a volume ID. 

67


68 



Submission method for 

non promotion 

functions 

Lib authority to include 

on env 

Specify which utility controls the submission of non promotion type jobs 

such as the Build List, Reset Authorities, and Purge History functions. 

1=OS/400: OS/400 operating system controls job submission. This is 

the default value. 

2=ROBOT: ROBOT controls job submission. 

Specify a user’s ability to include libraries in an environment definition, 

based on the user’s OS/400 authority to the library. 

*ALL: Only users with *ALL authority to a library can include the library 

in an environment definition. 

*CHANGE: Only users with *CHANGE authority to a library can include 

the library in an environment definition. 

*USE: Only users with *USE authority to a library can include the 

library in an environment definition. 

*BLANK: Authority to the library is not verified. 

AllFusion 2E installed Specify Y if AllFusion 2E is installed to manage 2E through Implementer. 

Required to create special environments for AllFusion 2E, and to display 

related fields and function keys for AllFusion 2E. The default value is N. 

AS/SET installed Specify Y if AS/SET is installed to manage AS/SET through Implementer. 

Required to create special environments for AS/SET, and to display 

related fields and function keys for AS/SET. The default value is N. 

LANSA installed Specify Y if LANSA is installed to manage LANSA through Implementer. 

Required to create special environments for LANSA, and to display 

related fields and function keys for LANSA. The default value is N. 

PeopleSoft World 

installed 

Secondary message 

queue 

Allow IFS object code 

creation from Check 

Out and Create Rqs 

Specify Y if PeopleSoft World is installed to manage PeopleSoft World 

applications through Implementer. Required to create special 

environments for PeopleSoft World, and to display related fields and 

function keys for PeopleSoft World. The default value is N. 

If using a third party messaging product such as AOS Message Manager, 

specify an additional message queue to send Implementer messages. 

Applies to messages regarding the status of promotion steps: start, end, 

and abnormal end of compile, distribution, move, and final processing. 

Specify Y to allow the automatic creation of an IFS object code when 

checking out or creating a promotion request using an IFS object code 

that does not exist. This is useful due to the abundant number of possible 

extensions of IFS files. Valid for IFS objects only (create traditional object 

codes through Work with Object Codes). 

IFS object codes are created based on the extension of the object being 

checked out or promoted. Applies to any IFS file or directory object code 

that does not already exist.

Display Comments 

panel when performing 

Create Request 

Perform create request 

in batch 


Specify whether to display the Comments panel when creating a 

promotion request and enforce the entry of a descriptive comment. 

Y: Enables the Comments panel and requires entry of a comment. This 

is the default value. 

N: Disables the Comments panel. 

This feature is mutually exclusive of promoting objects associated with an 

issue or design request, whereby the comments associated with the 

primary issue or DR are added to the promotion request. 

Specify whether to create promotion requests interactively or in batch. 

Causes less interactive edit processing and expedites the create request 

process by placing most edit checks, validation, and processing in the 

submitted job. Useful when promoting multiple items on a request or 

when issuing multiple requests. 

Y: Request processing occurs in batch. This is the default value. 

N: Request processing occurs interactively. 

Optimize PFs promotion Specify whether to optimize the promotion of physical files. For details on 

this feature, see the MKS Implementer 2006 User Guide. 

Y: Optimizes physical file promotions to reduce processing time. 

N: Does not optimize physical file promotions (uses traditional file 

promotion). 

Maintain X-env related 

objects 

Specify whether to maintain related objects across environments and 

allow Implementer to automatically generate secondary requests for each 

environment related objects are found in. 

Y: Enables cross-environment related object processing and 

secondary requests for cross-environment related objects. 

N: Disables cross-environment related object processing and 

automatic secondary requests. This is the default value. 

After you change this value from N to Y and press ENTER to update your 

selection, a message instructs you to run the Build List function. Type Y to 

activate the feature, or N to return without activating the feature. For 

details, see “Maintain X-env related objects” on page 69. 

NOTE For details on related object processing based on the development path for 

QA environments, see “Add related objects from path” on page 72. 

Continue rqs if X-env 

error 



When maintaining cross-environment related objects, specify how 

Implementer handles a primary request if an error occurs while 

generating secondary requests for cross-environment related objects. 

Requires the Maintain X-env related objects field set to Y. 

Y: Primary request continues processing if errors occur while 

generating secondary requests. 

N: Primary request ends in failure if an error occurs while generating 

secondary requests. 

69


70 



Activate issue object 

stamping 

Specify whether Implementer automatically stamps each object with the 

issue or DR number the object is checked out with. To ensure stamping 

of both new and existing objects, stamping occurs in the three stages 

that allow object creation: check out, compile from the Workbench, and 

promotion. For details, see page 145. 

Y: Enables object stamping. When multiple locks exist with multiple 

issues or DRs, the object is stamped with the primary number 

associated with the initial lock. 

N: Disables object stamping. This is the default value. 

NOTE When MKS Integrity is the issue management system, this field name is 

Activate issue object stamping. When DesignTracker is the issue management 

system, the field name is Activate DR object stamping. 

Activate object version 

stamping 

Assign native version 

number at 

Specify if Implementer automatically stamps each object, lock, and 

repository record with a unique version number at defined stages within 

the development cycle. For details, see page 146. 

Y: Enables object version stamping. You must define the remaining 

fields on this panel as described. This is the required value for the 

Build List function to assign revision numbers to unstamped objects. 

For details, see “Environment Repository Build” on page 117. 

N: Disables object version stamping. This is the default value. 

If the Activate object version stamping field is set to Y (active), specify 

the versioning method. 

1=checkout only: 

Assigns the version number during check out. Implements a wholenumber 

versioning scheme (no decimal). For example, checking out 

version 2 of an object in production to a *TST environment increments 

the version number to 3. Each new concurrent development lock 

increments the version by 1 (for example, 4, 5, 6). When promoted 

back to production, the version is set to that of the last *QAC object 

version. 

2=checkout and promotion to *PRD environments: 

Assigns the version number in check out and promotion to *PRD 

environments. Implements a decimal number versioning scheme 

using both the left and right side of the decimal. For example, checking 

out version 2.0 of an object in production to a *TST environment 

increments the version number to 2.1. Each new concurrent 

development lock increments the right side of the decimal by 1 (for 

example, 2.2, 2.3, 2.4). When promoted back to production, the 

version is set to 3.0 (the left side of the decimal is updated only when 

promoted to production). 

3=user defined: 

Assigns the version number based on a custom, user-defined 

versioning method. Requires a Versioning program name and Library 

name as described next.


NOTE If MKS Source integration is enabled, the native revision number scheme 

applies only to objects and items not archived in MKS Source. If MKS Source 

integration is not enabled, the native revision number scheme applies to all items. 

Versioning program Specify the name of a custom versioning program to call to perform 

object version stamping. Required if versioning is active and the Assign 

native version number at field is set to 3=user defined. 

IMPORTANT If the custom program references objects, for example, files or data 

areas, the library list for the Implementer job description MWIJOBD and each 

user’s interactive library list must include the library containing those objects. 

Library Specify the library location of the custom versioning program. Required if 

versioning is active and the Assign native version number at field value 

is 3=user defined. Valid options are a specific library name, *LIBL, or 

*CURLIB. 

Concurrent 

Development Scope 



Specify which locks establish concurrent development—either all locks 

from all production environments, or only those locks from the same 

production environment as the current check out From environment. 

1=All Production Env: 

Concurrent development is based on locks from all production 

environments. Activates concurrent development for the current check 

out, if, among all existing locks, a lock exists for the same member/ 

object and object code. 

2=Per Production Env: 

Concurrent development is based only on locks from the same 

production environment as the check out From environment. Activates 

concurrent development for the current check out if a lock exists for the 

same member/object and object code and the same production 

environment as the current check out From environment. This is the 

default value. 

To define a user’s environment capabilities for concurrent development, 

see “Locks” on page 110. To further customize concurrent development 

processing, see “Customizing Implementer” on page 414. 

71


Users 

72 

Add related objects 

from path 



For requests that target a *QAC environment, specify whether to 

automatically add related objects that exist in environments higher on the 

promotion path. Allows you to recompile related objects that exist in 

production without creating locks for the objects. 

Y: Searches the current promotion path to locate related objects not in 

the target *QAC environment or on the current promotion request. 

Related objects are added to the request and recompiled in the QA 

environment (locks are not created for these objects). Requires the 

production environment’s Add related objects to rqs field set to Y. For 

details, see page 86. 

N: Does not search forward on the path to locate related objects. This 

is the default value. 

Domino server URL For Lotus Domino integration and database signing, specify the Lotus 

Domino server URL that Implementer uses when invoking actions that 

can only be performed within Domino. Must be a valid URL notation that 

includes subdirectories required to find the Implementer utility database, 

for example, http://servername.domain:port/subdir. 

For details on setting up Domino, see “Lotus Domino Integration” on 

page 336. 

Default SMTP Server For notifying users of promotion request status through e-mail sent as 

request special command. Specify the default SMTP server used by the 

ISNDMAIL command. The value must be an IP address or host name, 

for example, 127.1.1.1 or localhost. Requires Java 1.3 or later 

installed on your iSeries. 

Requires the Send eMail Message (ISNDMAIL) command set up as an 

Implementer special command. For details, see the MKS Implementer 


This task allows you to enroll OS/400 user profiles into Implementer. You must enroll each 

user of Implementer before they can access and use the features. When enrolling a user, you 

also define the Implementer user authorities that control the features and functions the user 

is allowed to perform. For a table of suggested field values for the different roles each type of 

user performs, see “Typical Values for Different User Roles” on page 78. 

You can enroll users individually or under a group profile. Perform this task during the 

initial setup of Implementer or any time after installation when you need to add, change, or 

delete a user profile. 

NOTE Some user profile fields, as noted, apply to using Implementer with 

MKS Integrity for issue tracking. For details, see “User Profile Setup” on page 235.

To create or work with users 

1 From the Implementer Menu, type 41, or type STRIM (*WRKUSR) at the command line 

and press ENTER to display the Work with User Profiles panel. 

2 To change an existing profile, type option 2 and press ENTER. 

To create a new user profile, press F6=Create, or type 3 in the Opt field of an existing 

user and press ENTER to copy the user profile information into a new user profile. 

The Create User Profile panel displays. The following example illustrates the default 

field values when creating a new user profile. 

Users 

3 Complete the required fields as defined in the following tables of Create User Profile 

Field Descriptions. When you reach the end of a panel, press PAGE DOWN to display the 

additional panels. 

4 When finished, press ENTER to add or update the record. The initial Work with User 

Profiles panel displays. 

73


74 


Create User Profile Field Descriptions: Panel 1 

User Profile Specify the name and a description for the user profile. You can edit a 

name only when enrolling a new profile. You cannot rename existing user 

profiles. 

MKS Integrity User ID Specify the name this user logs on with to access the MKS Integrity 

Server. Field is valid only when MKS Integrity is used for issue tracking or 

MKS Source is used for source archiving. For details, see “User Profile 

Setup” on page 235, and “Implementer and MKS Source Integration” on 

page 259. 

*USRPRF: The MKS Integrity user ID defaults from the user’s iSeries 

user profile. This is the default value. 

Name: Specify the valid MKS Integrity user ID. The value *NONE is not 

authorized to access MKS Integrity. 

Programmer/env admin options 

The following fields, in conjunction with user capabilities by environment on page 109, define the 

user’s access to functions used on a daily and emergency basis. 

Check out Specify if this user has authority to use the Check Out option on the menu 

or command interface. Developers usually use the Check Out function. 

The default value is Y. 

Create request Specify if this user has authority to use the Create Request option on the 

menu or command interface. Developers usually use the Create Request 

function. The default value is Y. 

Compile requests Specify if this user has authority to use the Compile Requests option on 

the menu or command interface. Developers usually use the Compile 

Requests function. The default value is Y. 

Project maintenance Specify if this user has authority to use the Projects option on the menu. 

Project leaders usually use this function. The default value is N. 

Emergency check out Specify if this user has authority to use the Emergency Check Out 

function on the menu. The default value is N. 

Emergency create 

request 

Specify if this user has authority to use the Emergency Create Request 

function on the menu. The default value is N. 

Move requests Specify if this user has authority to use the Move Requests option on the 

menu or command interface. Project leaders usually use this function. 

The default value is N. 

Setup options 

The following fields define the user’s access to functions such as data maintenance and system and 

environment configuration defaults. The default value for each of these options is N (not allowed). 

User profile 

maintenance 

Specify if this user has authority to change user profile information in 

Work with Users. 

Host env maintenance Specify if this user has authority to change environment information in 

Work with Environments.


Network configuration Specify if this user has authority to use the Network Configuration menu 

option. 

Object code 

maintenance 

System control 

maintenance 

Remote env 

maintenance 

Specify if this user has authority to change object code information in 

Work with Object Codes. 

Specify if this user has authority to use the System Control menu option. 

Specify if this user has authority to change the system name on an 

existing environment. 

User controls 

The following fields define whether the user is authorized to override certain default values when 

promoting. The default value for each of these options is N (not allowed). 

Override standard paths Specify if this user has authority to change the standard path option on 

the menu or command interface. An application path (standard or 

emergency) automatically determines the from and target promotion 

locations based on the current location of an object. For a description of 

path setup, see page 102. 

Override emergency 

paths 

MKS Integrity 

emergency update 

Override 

remove from objs 

Override 

remove from src 


Specify if this user has authority to change the emergency path option on 

the menu or command interface. 

Users 

Specify if this user has authority to activate and de-activate the 

MKS Integrity emergency update mode. This allows the user to change 

the value of the MKS Integrity Emergency Update Active field on the 

Change User defaults panel accessed from either Work with Users using 

option 20=User Defaults or the Workbench using F18=User Defaults. 

Y: User has authority to activate and de-activate emergency update 

mode. 

N: User does not have authority to emergency update mode. 

Specify if this user has authority to change the Remove obj in from lib/ 

env field when creating a promotion request. a 

Specify if this user has authority to change the Remove src in from lib/ 

env field when creating a promotion request. a 

a Pertains to deleting members/objects in a From library or environment after promotion (user profile 

defaults are defined on the second Work with User Profile panel). For details, see “Removing Source 

and Objects After Promotion” on page 92. 

75


76 



Defaults for check out and create request 

The following fields define the check out and promotion defaults for the user. The Chg field allows you 

to define whether the user can override the default value in the corresponding function. For example, 

specify a default target environment for promotion and specify Y in the Chg field allows the user to 

change the target environment when creating a request. 

NOTE When using a standard or emergency path to identify the check out or 

promotion location, the path values have precedence. The path value *USRPRF 

defaults the development environment or library from the user profile. This 

provides user-specific development locations, allowing you to control the default 

promotion locations. 

Check out from env Specify the default environment this user checks out from (usually a 

production environment). 

Development library Specify the default development library this user checks out to and 

promotes from. The library must not be defined to an Implementer 

environment. Development library and development environment are 

mutually exclusive (personal development libraries are used when 

environments are not). MKS suggests using environments in place of 

personal libraries. 

Development env Specify the default development environment this user checks out to and 

promotes from. The development library and development environment 

are mutually exclusive. 

Crt rqs target env Specify the default primary environment this user promotes to (usually 

production or QA environment.) Mutually exclusive of Crt rqs tgt env grp 

field. 

Crt rqs tgt env grp Specify the existing default target environment group when this user 

creates a promotion request. Mutually exclusive of Crt rqs target env field. 

Project reference Specify the name of the default project when checking out or creating a 

promotion request. For example, when a developer is assigned to a 

general project or a single project for a long period, the developer does 

not have to repeatedly specify the project value. 

If the project has a defined application path, that path is the default when 

this user performs check out and create request. For details, see “Projectbased 

Application Paths” on page 142. 

Remove obj in from 

library 

Specify whether to automatically delete or retain objects in the from library 

after successful promotion. 

Y: Deletes objects after promotion. This is the default value. 

N: Retains objects after promotion. Authority to override this default 

when creating a request is defined in the User Controls fields on the 

previous panel.


Remove src in from 

library 

Enable one step 

checkout 

Enable one step 

promotion 

Specify whether to automatically delete source in the from library after 

successful promotion. 

Y: Deletes source after promotion. This is the default value. 

N: Retains source after promotion. Authority to override this default 

when creating a request is defined in the User Controls fields on the 

previous panel. 

Users 

Specify the default check out method: one step or traditional. The one 

step method processes the check out transparent to the user. The 

traditional method requires more steps and processing of the Check Out 

panel. For details, see the MKS Implementer 2006 User Guide. 

Y: Enables one step checkout. This is the default value. 

N: Enables traditional checkout. 

Specify the default promotion method: one step or traditional. The one 

step method performs promotion processing transparent to the user. The 

traditional method requires more steps and processing of the Create 

Request panel. For details, see the MKS Implementer 2006 User Guide. 

Y: Enables one step promotion. This is the default value. 

N: Enables traditional promotion. 

Conflict msg queue Specify a message queue to receive a message notify when a check out 

causes a conflict with a lock for this user (when a member/object checked 

out by this user is concurrently checked out by another user). The 

developer is notified that concurrent development is in process—a conflict 

with their lock now exists and must be resolved before promoting the lock. 

Useful for a group profile to ensure all messages are observed. 

Specify *USRPRF to default the message queue from the users OS/400 

user profile, or specify the name of an existing message queue. 

Library Specify the library containing the user’s message queue. 

Issue Management 

System 


Specify the current issue management system for this user. Only used 

when co-existing to allow certain users to use MKS Integrity while others 

use DesignTracker. 

1=Default: The user uses the default issue management system. 

2=DesignTracker: When the default issue management system is 

MKS Integrity, allows the user to temporarily use DesignTracker. 

For details, see “Implementer and MKS Integrity Integration” on page 196. 

77


Typical Values for Different User Roles 

78 



Product / Customer Options 

Specify Y to authorize this user profile to maintain the following product and customer records used 

for release management and MKS Source archiving (if enabled). The default value is N. For details, 

see the MKS Implementer 2006 Release Management Guide. 

Maintain products Authority to maintain products. 

Maintain product versions Authority to maintain product versions. 

Maintain customers Authority to maintain customer records. 

The following table describes the most common users involved with Implementer, and the 

suggested options to define for each type of user. You can change these suggested values to 

meet your specific needs. 

Capability Option Administrator 

Programmer/env admin options 

Project 

Leader 

Developer QA 

Check out Y Y Y N 

Emergency check out Y Y N N 

Create request Y Y Y Y 

Emergency create request Y Y N N 

Compile requests Y Y Y N 

Move requests Y Y N N 

Project maintenance Y Y N N 

Setup options 

User profile maintenance Y N N N 

Object code maintenance Y N N N 

Host env maintenance Y N N N 

System control maintenance Y N N N 

Network configuration Y N N N 

Remote env maintenance Y N N N 

User controls 

Override standard paths Y Y N N

Capability Option Administrator 

Override emergency paths Y Y N N 

Override remove from obj Y Y N N 

Override remove from src Y Y N N 

Defaults for check out and create request 

Check out from env Y Y Y N 

Develop lib. (or Env. below) Y Y Y N 

Develop env. (or Library above) Y Y Y N 

Crt rqs target env (or Env Group below) Y Y Y Y 

Crt rqs target env grp (or Env above) Y Y Y Y 

Project reference Y Y Y Y 

Remove obj in from library Y Y Y Y 

Remove src in from library Y Y Y Y 

Enable one step checkout Y Y Y Y 

Enable one step promotion Y Y Y Y 

Products / Customer Options 

Common Questions 

How much authority should be given to developers? 

Developers should be able to check out, create a request, compile a request, and access the 

Workbench. Usually, you do not allow developers to move a request or perform setup 

functions. 

If users are restricted through Implementer to specific environments, is it possible for them to access 

libraries outside of the product? 

Yes. To restrict a user from a specific library outside of Implementer, use standard OS/400 

security by using the Edit Object Authority (EDTOBJAUT) command to specify the user’s 

authority to the library. 

Should a developer be allowed to change the default path? 

Project 

Leader 

Developer QA 

Maintain Products Y Y Y Y 

Maintain Product Versions Y Y Y Y 

Maintain Customers Y Y Y Y 

Users 

This depends on how strictly your company wants to control member/object location along a 

predefined path during development. 

79


User Profile Object Code Overrides 

80 

Users have access to all object codes defined to an environment, as well as rights to promote 

any type of object. This is an optional task that allows you to place restrictions on a user’s 

access rights. For example, you may want to restrict the PF object code, as, typically, only a 

Database Administrator (DBA) has authority to promote physical files. To limit the number 

of users who can act as a DBA, you can disallow a user’s access to the PF object code. 

To change object code overrides for a user 

1 From the Work with User Profiles panel, type 8=Object code overrides next to the user 

profile and press ENTER. The Change User Profile - Object Codes panel displays. 

2 In the Allow Code field, type N for each object code you do not want this user to access, 

and press ENTER. The Work with User Profiles panel displays. 

User Profile Environment Capabilities 

Environment capabilities allow you to tailor each user’s authorities to specific environments. 

For example, you can enable multiple users to have move capabilities for an environment, or 

enable select users to perform emergency functions for an environment. 

You typically perform this task when you initially install and configure Implementer, after 

setting up the environment (not when you set up the user profile). The task is mentioned here 

within the Work with Users topic because you need to complete it after you create an 

environment. You also perform this task for a new user for existing environments. The 

functionality and setup are the same in both Work with Users and Work with Environments. 

Implementer provides two options for defining user environment capabilities: 

The Implementer Menu options provide standard iSeries entry screens. For details on 

this option and the environment capabilities task, see “Environments and User 

Capabilities” on page 109. 

The Capability Wizard is a graphical user interface (GUI) tool designed to minimize the 

maintenance of user authorities in Implementer. Administrators or anyone responsible 

for working with user authorities in Implementer can benefit from using this time saving 

tool. You must add new users through the Implementer Menu option. Once added, you 

can maintain the profiles with the Capability Wizard. The major advantage to using the 

Capability Wizard over the Work with Users function is that it allows you to set 

capabilities for multiple users and environments concurrently. For details, see “User 

Capability Wizard” on page 385.

Environments 

Environments 

An environment identifies a collection of libraries, object owners, authorized users, and rules 

of the libraries that make up one or more applications controlled by Implementer. 

Environments are an important concept in Implementer, as they automate many common 

tasks and the organization of your system. 

Implementer supports the following three environment types: 

Production (*PRD) 

Quality Assurance (*QAC) 

Test (development) (*TST) 

The *PRD environment is under tight control in Implementer. It is the final production 

version. You cannot check out to a *PRD environment or to a library defined to a *PRD 

environment. *PRD environments usually use program and/or database libraries that are in 

the end user’s library list. The major difference between a *PRD and *QAC environment 

relates to the move; when the move to a *PRD environment is complete, member/object locks 

are released—this is not the case for a *QAC environment. 

A *QAC environment is also under tight control in Implementer. It is not the final production 

version. You cannot check out to a *QAC environment or to a library that is defined in a 

*QAC environment. Examples of *QAC environments are: libraries used for system testing 

by developers, libraries used by a separate quality assurance group, and libraries used for 

user acceptance testing. 

A *TST environment is considered a developer’s set of libraries. Implementer does not 

control these libraries as tightly as *PRD or *QAC. For example, you can check out to a *TST 

environment or to a library not defined to any environment, whereas you cannot check out to 

libraries that are defined in *PRD or *QAC environments. This is typically considered a 

development environment. 

MKS recommends you define production environments. However, to fully capitalize on 

Implementer’s robust features and benefits, you should define environments for all 

application libraries. 

Key Considerations 

At a minimum, define a production environment that is used to manage the related 

application libraries. For the basic setup of common environment scenarios, see 

“Environment Examples” on page 417. 

Define all environments for an application before using any environment for that 

application. 

Define an environment before adding it to an environment group. 

81


82 

Define an environment before defining related environments, paths, CASE applications, 

or scheduling. 

Define from and target environments for check out. Implementer also supports checking 

out from an environment to a library. 

Authorize the user profiles that may access the new environment. Change the user 

profile in Change User Capabilities, accessed through Work with Environments, Work 

with Users, or the Capability Wizard. 

When setting up to archive, set the number of archive versions to 99 for each applicable 

environment to ensure every change to an object is always available in an archive. This 

enables the retention of 99 changes for a single object in an environment, without having 

to save them to tape in between, and ensures an older archive in the archive library is not 

replaced with a new copy. Normally, however, archives on the system would not be 

allowed to grow that large, and, would be saved off more regularly to make the archive 

disk space available. 

If using the MKS Source integration, conventions apply to environment names you use. 

The environment name must be representable on the file system of the operating system 

hosting the server for MKS Source. The environment name must start with a letter A–Z 

and continue with a contiguous sequence of letters A–Z, numbers 0–9, or underscores 

‘_’. 

In System Control Maintenance, review the library authority parameter for a user’s 

ability to include libraries in environment definitions. For more information, see the 

table of field descriptions on page 68. 

To create or change an environment 

1 From the Implementer Menu, type option 42, or type STRIM (*WRKENV) at the 

command line and press ENTER to display the Work with Environments panel. 

2 From the Work with Environments panel, do one of the following: 

Press F6=Add to create a new environment on the Create Environment panel. 

Type 2 in the Option field next to an existing environment and press ENTER to 

display the Change Environment panel. 

Type 3 in the Option field of an existing environment and press ENTER to create a 

new environment by copying the selected environment.

Environments 

3 Complete the fields as described in the following tables of Create Environment Field 

Descriptions. Press PAGE DOWN to access the additional panels. 

4 When finished, press ENTER to add or update the environment. 


Create Environment Field Descriptions: Panel 1 

Environment Specify the name of the environment. You can enter a name only when 

creating a new environment. You cannot change the name of an existing 

environment. 

Description Type a brief description for the environment. 

Administrator Specify a user profile that has authority to Move Requests for this 

environment. To the right of this field is the description of the administrator. 

Env type Specify whether the environment is Production (*PRD), Quality Assurance 

(*QAC), or Test (*TST) environment. 

*PRD: You can check out from and promote to a *PRD environment. You 

cannot check out to a *PRD environment or to a library defined to a 

*PRD environment, or promote from a *PRD environment. 

*QAC: You can promote to and from a *QAC environment. You cannot 

check out to a *QAC environment or to a library defined to a *QAC 

environment. 

*TST: You can check out to a *TST environment or to a library not 

defined to any environment. You can promote from a *TST environment. 

You cannot check out to libraries that are defined in *PRD or *QAC 

environments, or promote to *TST environments. A *TST environment is 

considered a developer’s set of libraries. 

83


84 


Library Defaults 

The following fields define the default values Implementer uses when you create a promotion request 

and specify this environment as the primary target environment. 

Name Specify the name of the corresponding library on the system. 

Library owner Specify the user profile who owns the corresponding library. This field must 

be blank if the Library field is *NONE. The Reset Authorities function uses 

this value to change the library owner. If environment libraries do not exist 

when targeted in promotion, Implementer creates the libraries and assigns 

this value as the library owner. 

Obj owner Specify the user profile who owns the objects in the corresponding library. 

The field must be blank if the Library field is *NONE. The Reset Authorities 

function uses this value to assign the object owner. If source files do not 

exist in promotion, Implementer creates the source files and assigns this 

value as the object owner. If an object being moved has *GRANT authority, 

Implementer uses this value when moving objects into the environment. 

Typically, the default value is *KEEP. 

Archive Versions/ 

Archive Category 


The field name is Archive Versions for all environments, except for release 

management environments the field name is Archive Category. 

Archive Versions is the number of archive versions to save for this type of 

object or member. Supports up to 99 archive versions of each. You can 

archive for the program library, files library, and source library. 

To archive PeopleSoft World soft coding items, specify a value in this field 

and complete the Source library fields. To archive AS/SET definitions to an 

AS/SET archive application set, specify the number of levels in the Archive 

versions field for the source library. 

Archive Category allows any of the following values: 

0=None: Does not archive. 

1=Standard Only: Archives the standard release category only. 

2=PTF: Archives the PTF release category only. 

3=Standard and PTF: Archives both standard and PTF releases. 

Program library Specify the library that contains the programs and device files, such as 

display and printer files. Often referred to as the program or object library. 

If the environment contains only database objects, specify *NONE. 

Files library Specify the library that contains the physical and logical files. If the 

environment does not contain database objects, specify *NONE. 

Source library Specify the library that contains the source members for the objects in the 

two preceding environment libraries. 

To archive PeopleSoft World soft coding items, define values in the Source 

library fields and the Archive Versions field.


Environments 

Archive library Specify the library to contain the archived versions of source/objects. Only 

required when archiving objects. You must specify a library name to add 

the number of versions in the Archive versions field. 

AS/SET definitions and generated traditional objects are managed 

independently and require separate archive locations for traditional objects 

and definitions. 

The value *CALC applies to primary release management environments. 

For details, see the MKS Implementer 2006 Release Management Guide. 

Create Request defaults 

The following fields define the default values when creating a promotion request for this environment. 

The Chg field defines whether the user can override the default value when creating a request. 

Compile required Specify whether to compile all source-based objects using the Compile 

Requests function before moving the objects into this environment. Ensure 

the objects compile with the correct library list. 

Y: Objects compile before the move. 

N: Bypasses the Compile Request function. After creating a request, 

you can move the objects into this environment using the Move 

Requests function. Use this option for AS/SET definitions and LANSA 

objects. 

Auto submit in 

create rqs 


Specify whether to automatically submit the promotion when creating a 

request. 

Y: Promotions automatically submit. 

N: Promotions are held. To promote the request use: Compile Request, 

Move Request, or Move Requests by System/Environment. 

Through step Specify how many steps of the promotion to perform when auto-submitted 

from Create Request. Each subsequent step includes the prior step, for 

example, compile includes model copy, distribute includes model copy and 

compile, and move includes model copy, compile, and distribute. If using 

promotion scheduling, it is performed for the last step specified as the 

submit through step. 

1=Export: Valid only for LANSA environments. Exports LANSA objects 

on the request to a save file. Verify successful completion of the process 

by manually reviewing the export reports generated by LANSA. 

2=Compile: Valid only when Compile required = Y. 

3=Distribute: Valid only for remote environments. 

4=Move: No special edits. 

85


86 


Add related objects 

to rqs 


Specify whether to add related objects to a request before promotion. 

Ensures objects are promoted without level checks in production. For 

example, when promoting a physical file or display file, all programs that 

reference the PF or any related LFs are added to the request before the 

compile step with an action of 9 for Recompile. Implementer uses the 

source in this environment to recompile the program against the changed 

physical file, thus avoiding the possibility of a level check. 

When a request targets multiple environments, the derived related objects 

are based on the primary environment. If this environment is a secondary 

environment for a request, the related objects are added based on the 

value of this field in the primary environment, not this environment. 

Y: Adds all related objects to the request. This is required to add related 

objects from the development path without locking the objects. For 

details, see page 72. 

N: Bypasses related object processing. For physical files, Implementer 

adds the logicals to the request even when N is specified. 


Create Request options 

The following fields define additional defaults for the environment. 

Check out required Specify if users must check out a member/object in this environment before 

it can be placed on a promotion request. 

Y: Check out is required. 

N: Check out is not required. 

Allow authority 

overrides 


Specify if users can change the authority method of this environment when 

creating a promotion request. 

Y: Authority method can be changed. 

N: Authority method cannot be changed. All moves into the environment 

use the default authority method defined for the object code.


Environment information 

Specify the following default information for the environment. 

Environments 

Special environment Displays the special environment type for the environment. Pertains to the 

installed CASE tools specified in System Control. The value updates 

based on the third party product details in Work with Environments options 

10=AllFusion 2E, 11=AS/SET, 12=LANSA, or 16=PeopleSoft World. 

Standard: Not a special environment. This is the default value. 

ALLFusion: AllFusion 2E special environment. 

AS/SET: AS/SET special environment. 

LANSA: LANSA special environment. 

PeopleSoft: PeopleSoft World special environment. 

You can change a special environment to different special environment 

type by first removing the special environment details to establish it as a 

standard environment. For details, see “Third Party Integration 

Prerequisites” on page 107, and “Third Party Integrations” on page 303. 

Issue or Design rqs 

rqd in check out 

Project reference 

required 

Retain error-free 

joblogs 

Remove obj in from 

lib/env 

and 

Remove src in from 

lib/env 


Specify if an issue (MKS Integrity installed) or a design request 

(DesignTracker installed) is required to check out an item from this 

environment. Applies only to traditional *PRD environments and 

AllFusion 2E *TST environments. 

Y: Issue (or DR) is required. 

N: Issue (or DR) is not required. This is the default value. 

Specify if a project reference is required to check out a member/object from 

this environment. 

Y: Project reference is required. 

N: Project reference is not required. This is the default value. It is the 

required value for *TST environments. 

Specify whether to retain the job log in the Implementer database for any 

job processed for this environment. 

Y: Retains job logs. 

N: Deletes job logs when the related job completes normally. Retains 

the job log if a job terminates abnormally to assist with resolution 

Specify whether to delete objects and source from the environment 

libraries after successful promotion from this environment (must be a local 

*TST or *QAC environment). The value defined here is the default value for 

the corresponding fields in Create Request. For details, see “Removing 

Source and Objects After Promotion” on page 92. 

1=always: Automatically deletes objects and/or source. This is the 


2=never: Retains objects and/or source. 

3=per obj code: Validates each object code to the environment’s object 

code overrides. 

87


88 


Maintain related 

object info 

Specify whether to maintain related object information for the environment. 

Y: Maintains related object information. Required value to check out 

related objects and add related objects to a request. 

N: Bypasses related object information. 

Source of information Specify which product maintains related object information for the 

environment. 

1=Implementer: Implementer uses the Display Program Reference 

(DSPPGMREF) command to generate and maintain related object 

information. Initially, the related information for an environment is 

processed by the Build List function; thereafter, it automatically updates 

during the move step. Displays related objects for file (*FILE) and data 

area (*DTAARA) object types. When activating this feature for the first 

time, you must run the Build List for the environment to establish the 

initial related object information (or use PathFinder). 

2=Pathfinder: PathFinder generated information is used. Automatically 

updates PathFinder as objects move in and out of libraries documented 

by PathFinder. Displays related objects for any object type. Define the 

remaining fields for PathFinder to maintain related object information. 

Pathfinder X-ref library Specify the PathFinder x-ref library to store related object information if 

related objects are maintained by PathFinder. 

Name: Specify the PathFinder x-reference library. You must run the build 

within PathFinder for the library before defining it here. 

*DEFAULTS: Uses the object x-ref files for the library specified in the 

PathFinder Object X-ref library field in the PathFinder user defaults. 

Update Pathfinder X-ref Specify whether Implementer automatically updates PathFinder 

information during request promotion. 

Y: Automatically updates PathFinder. Specify a value in the DOCLIBL for 

X-ref updates field. 

N: Bypasses PathFinder updates. 

DOCLIBL for X-ref 

updates 


Specify the documentation library list defined in PathFinder that contains 

the names of the libraries with object cross references. 

Name: Specify the name of an alternate documentation library list. 

*DEFAULTS: Uses the DOCLIBL specified in user defaults for one of the 

following: alternate name, *USER, *STANDARD, or *ALL parameters. 

*USER: Uses the DOCLIBL defined in the user profile. 

*STANDARD: Uses the DOCLIBL for the standard values.


MKS Integrity issue state 


Environments 

The following fields are valid for entry when you use MKS Integrity for issue tracking. For details, see 


When arrives in 

this env 

When rejected from 

this env 

Specify the MKS Integrity state to assign to a member/object checked out 

or promoted to this environment. 

NAME: Specify the name of a valid MKS Integrity status. This value 

overrides the global value if defined. 

*DEFAULT: Assigns the default value as defined in MKS Integrity setup. 

If the MKS Integrity default is blank or not set, no updates occur. This is 

the default value for this field. The status is set as follows: 

If checking out to this environment, assigns the default status *TST. 

If promoting to this environment and it is type *PRD, assigns the default 

status *PRD. 

If promoting to this environment and it is the first *QAC on the path, 

assigns the default status *QAC1. 

If promoting to this environment and it is the second *QAC on the path, 

assigns the default status *QAC2. Cycle continues for each *QAC 

environment. 

*NONE: No updates occur. 

Specify the MKS Integrity state to assign to a member/object rejected from 


*NAME: Specify the name of a valid MKS Integrity status. This value 

overrides the global value if defined. Valid for *QAC environments only. 

*DEFAULT: Assigns the default value as defined in MKS Integrity setup. 

If the MKS Integrity default is blank or not set, no updates occur. This is 

the default value for this field for all environment types. The status is set 

as follows: 

If rejecting from this environment and it is the first *QAC environment on 

the path (the path used to promote from the current location), assigns 

the *QAC1 default status. 

If rejecting from this environment and it is the second *QAC environment 

on the path (the path used to promote from the current location) assigns 

the *QAC2 default status. Cycle continues for each *QAC environment. 

*NONE: No updates occur. 

Remote information 

The following options allow you to define and control the remote systems. 

System name Specify the name of the system where this environment is located. You 

must first define the system in Network Configuration. Specify a local 

system name for a local environment, or a remote system name for a 

remote environment. 

Source library location Specify the location of the environment’s source library. 

L: Source library is on the local system. 

R: Source library is on a remote system. 

89


90 


Compile location Specify where to compile for this environment. 

L: Compile on local system. 

R: Compile on remote system. 

Distribution method Specify the distribution method when deploying to the remote system. 

1=SNADS (SNA Distribution Services). 

2=Tape. 

3=DVD (release management environments only; for details, see the 

MKS Implementer 2006 Release Management Guide). 

4=SDMCom. 

7=TCP/IP-FTP (default value when creating a new environment). 

8=TCP/IP-Tape. 

NOTE TCP/IP-FTP is for bulk file transfers. TCP/IP-Tape is for distribution on 

tape media. Both options allow you to use the “Remote Initiated Move Update 

Host” functionality. To alternate between TCP/IP and SNADS distributions, 

change the value in this field as needed. 

If you use SNA or TCP/IP to distribute to remote systems, additional setup is 

required. For details, see “Setting Up for SNADS Distribution” on page 179, or 

“Setting Up for TCP/IP Distribution” on page 173. 

Remote initiated move Specify whether to initiate the move step on the host system or the remote 

system. Allows users on a remote system to control when to move a 

request into this environment and allows initiating the move on the remote. 

Y: Initiates the move on the remote system by a remote user. 

N: Initiates the move on the host system by a host user. 

Updates host Specify whether to update the host with remote initiated move information 

that includes: request header status, request detail status and information, 

archive information, and job log. Sets the request status to complete after 

request distribution. 

Y: Updates the host with the remote move data. Requires the Remote 

initiated move field set to Y. 

N: Bypasses the host update. 

Retain requests on 

remote 


NOTE If you use MKS Source archiving and promote using remote initiated 

moves with host updates, the MWIPROD user profile must have an 

MKS Integrity user ID that is part of the group to ensure it is 

configured to work with MKS Source. For details, see “Creating the Implementer 

Developer Group” on page 264. 

Specify whether to retain requests on the remote system after promotions 

complete successfully. 

Y: Retains requests on remote system. 

N: Deletes requests on remote system. This is the default value.


Promotion notification 

queue 

Object Code Overrides 


Environments 

Specify the name and library of the promotion notification queue for 

Implementer on the remote system. The queue holds messages that notify 

remote users of completed promotion steps. The value *NETA uses the 

queue defined in the network attributes. 

Target release Specify the OS/400 target release for the environment. The value 

*NETCONFIG retrieves the value from the network configuration. 

Implementer uses object codes to define the various types of members/objects you check out 

and promote. An object code combines information from the OS/400 object type and source 

type. Global object codes are defined in Implementer Menu option 44, Object Codes. This 

function allows you to override the global values and establish different values at the 

environment level. 

You can maintain object code overrides in Work with Environments using F8=Object codes, 

and in Work with Object Codes using option 7=Environment Overrides. Both panels look the 

same and provide the same functionality, with variation only in how the data is structured: 

In Work with Environments, view by environment to work with overrides at the global 

level. This option displays the object code defaults and overrides for a specific 

environment. 

In Work with Object Codes, view by object code to work with overrides at the 

environment level. This option displays the defaults and overrides for all environments 

for a specified object code. For details on this option, see “Environment Overrides” on 

page 133. 

Object code overrides applied to an environment affect the environment default values only. 

When creating a new environment, the values specified at the global level are the default 

values assigned to the object code overrides for the new environment. 

You can override the default source file for source-based objects, as well as the default object 

library and source library. Through overrides, you can activate or deactivate particular object 

codes for specific environments without impact to other environments. For example, you can 

deactivate certain object codes if you use database-only environments, and ensure that 

certain types of programming languages are not used for specific environments, such as 

System/38 or System/36 environment languages. 

You can apply overrides at any time. When you change an object code, it applies the latest 

overrides created from that point forward; it does not change existing active overrides. 

Inactive overrides reflect the object code level changes. 

91


92 

Removing Source and Objects After Promotion 

Implementer allows you to control how source and objects are handled in the From 

environment by allowing you to retain or automatically delete the items after successful 

promotion from a local *TST or *QAC environment. 

This feature is controlled by the defaults you establish for the environment and the 

environment’s object code overrides as defined in the fields Remove obj in from lib/env and 

Remove src in from lib/env as follows: 

Option 1=always automatically deletes objects and/or source. 

Option 2=never automatically retains objects and/or source. 

Option 3=per obj code validates to the environment’s object code overrides. An override 

is validated only if the promotion request is defined to delete objects per object code. 

When you create a promotion request, the Remove fields on the request default to the values 

defined for the same fields as the From environment. When promoting from a library, the 

Remove fields on the request are set to the default values defined for the user profile creating 

the request as follows: 

If the user profile Remove fields are set to Y, then the Remove fields on the request 

default to 1 (always). 

If the user profile Remove fields are set to N, then the Remove fields on the request 

default to 2 (never). 

The value 3 (per object code) is not allowed when promoting from a library. 

You must have authority to perform overrides to change the request defaults. For details on 

user profile defaults and overrides, see the table on page 78. 

NOTE 

The global object code values are only used to supply the initial defaults when 

creating new object code overrides for an environment. 

Implementer does not delete from *PRD or remote environments. For details on 

how to delete items from a remote QA environment after successful promotion 

from the environment. For details, see “Clearing Remote QA Environments” on 

page 384. 

To define object code overrides for an environment 

1 From the Change Environment panel or Create Environment panel, press F8=Object 

Codes. The Change Environment Object Code Overrides panel displays. 

2 Press F7=Fold to toggle the view to include the object code description. 

NOTE For details on option 7=Work with Object Name Rules, see “Object Name 

Rules” on page 137.

Environments 

3 The values that display for each code default from the corresponding global object code 

definition. Establish the overrides for this environment as follows: 

In the Object Library, Source File, and Source Library fields, type the new value in 

the appropriate field. The default value *NONE in any of these fields indicates the 

field does not allow entry and must first be changed at the global level. 

In the Act Flg field, type Y to activate the object code for the environment. The object 

code must be active to check out or promote using the object code. Type N to 

deactivate the object code. 

In the Rmv Obj and Rmv Src fields, specify whether to delete the corresponding 

object and/or source upon successful completion of a promotion request from this 

environment. Specify Y to delete the item. Specify N to retain the item. 

4 Press ENTER to process your changes. The Change Environment panel (or Create 

Environment panel) displays. 

To set up IFS directories for an environment 

1 From the Work with Environments panel, type option 20=Directory setup next to the 

environment and press ENTER. The Work with Environments Directory Setup panel 

displays. 

93


94 

2 Complete this panel as defined in following table and press ENTER. 


Directory Setup Field Descriptions 

Directory path Specify the full IFS directory path covered by the environment. 

Implementer automatically creates the directory path for a *QAC 

environment if it does not exist when a promotion targets the environment. 

You must manually create directory paths for *PRD and *TST 

environments. 

For IFS objects located on a system running Windows NT Server, the 

directory path of environments associated with the NT Server mounted 

drive must begin with \QNTC, for example, 

\QNTC\MKS\PRD\ACCOUNTS_PAYABLE. 

Directory path owner Specify the owner of the directory. Directories managed in this environment 

are owned by the user profile defined as the directory path owner. 

IFS file owner Specify the owner of IFS files managed within the environment directory. 

The user defined as the IFS file owner owns all objects created in the 

environment directory path, including all sub-folders. 

IFS objects promoted to a Windows NT Server are owned by user 

SDMAUTUSR (or the user profile defined to Implementer data area 

SDMAUTUSR). For details, see “Mounted Drive Support for IFS Objects” 

on page 159. 

IFS file archive 

versions 

Specify a value from 0–99 to indicate the number of archive versions to 

retain when promoting objects into production. 

Archive directory path Specify the full IFS path name for storing archive versions. Implementer 

automatically creates the directory if it does not exist when a promotion 

request targets the directory for archiving.

Establishing Object Authorities 

Environments 

An environment has specific authorities that control access to the objects in the environment. 

The Change Environment - Object Authorities panel allows you to add and change the 

OS/400 user profiles or OS/400 authorization list that have authority to reference objects 

within the environment. 

Key Considerations for IFS Objects 

Implementer sets authorities to IFS files in an environment directory the same as it sets 

authorities on libraries and objects. You must set the authorities when defining the 

environment to enable this feature. 

When promoting IFS objects to a Windows NT Server, the objects are owned by user 

SDMAUTUSR (or the user profile defined to Implementer data area SDMAUTUSR). 

Unlike traditional objects, the Reset Authorities function does not set the object owner. In 

addition, IFS objects inherit the authorities of the target directory; authorities defined to 

the environment or existing on the from object are disregarded. 

NOTE The Resent Authorities function allows you to grant or revoke object 

authorities for an environment based on how the authorities are defined for the 

environment. For details, see “Resetting Authorities” on page 372. 

To establish object authorities for an environment 

1 From the Change Environment panel or Create Environment panel, press 

F11=Authorities to display the Change Environment Object Authorities panel. 

95


96 

2 Do one of the following: 

In the Authorization list field, type the name of an existing OS/400 authorization list. 

In the User field, type the name of an existing OS/400 user profile. 

3 In the Authority field, type the authority *CHANGE, *ALL, *USE, *EXCLUDE, or *AUTL. 

4 Press ENTER. 

Deleting an Environment 

Deleting an environment removes the environment from the Implementer database. It also 

removes the environment from the related environment list for other environments. It does 

not delete the system libraries or source files associated with the environment. 


You must have authority to maintain environments to delete an environment. 

If an environment has closed locks or an attached promotion request, you must use 

option 32=Purge history or F19=Purge All History before you can delete the 

environment. For details, see “Purging Environment History” on page 374. 

You cannot delete an environment that is part of a development path, project path, 

related environment, or a From environment for a product version. 

You cannot delete an environment that is a From environment or target environment for 

a release management package. You must first use Work with Packages to manually 

purge the packages. For details, see the MKS Implementer 2006 Release Management Guide. 

To delete an environment 

1 From the Implementer Menu, type option 42, or type STRIM (*WRKENV) at the 

command line and press ENTER to display the Work with Environments panel. 

2 From the Work with Environments panel, select each environment with option 4=Delete 

and press ENTER. The Confirm Delete of Environments panel displays. 

3 Press ENTER to delete the selected environment. 

Environment Library List 

Implementer uses the environment library list to compile source members during promotion. 

It is also used during development from the Workbench and to issue special commands on a 


IMPORTANT You cannot use special commands to change the environment library list.


Environments 

You can specify a list of up to 250 libraries for compilation in the environment. Of these, 

248 entries are available for your use. The last two are reserved for QTEMP and the 

Implementer work library on the promotion request. 

IMPORTANT An incorrectly defined library list can cause the compile step to fail, or 

worse yet, compile using the wrong objects, and thus, result in level checks. You 

must ensure the library list has the correct libraries needed for compilation. This is a 

common error during the initial use of a new environment. 

The task of copying an environment includes copying associated library lists. 

Define local environments with a local library list and libraries that exist on the local 

system. You cannot define a remote library list for a local environment. 

Define remote environments with a remote library list and libraries that exist on the 

remote system. When a required library exists on both systems, you must also define a 

local library list for the remote environment. This allows you to establish an 

environment library list for local compiles, set up for move related special commands on 

the remote system, and locate database files related to the promoted files when explicitly 

added to the request. 

When initially defining the library list for a remote environment, the entries in the 

remote library list are also added to the local library list. Pressing F7 to access the local 

library list automatically loads the remote library list entries. You can modify the local 

library list as needed. 

If a remote environment has both remote and local library lists defined and you later 

change the environment to a local environment, the remote library list is no longer 

accessible because the environment is now local. However, Implementer retains the 

remote library list record, avoiding the need to recreate the library list if you later change 

the environment back to a remote environment. 

If you use special compile procedures such as those required by some third party 

software packages, you must add any applicable libraries to the compile library list. 

NOTE Prior to compiling a source member, Implementer replaces the library list of 

the current job with the environment library list; thus, do not put the libraries in the 

Implementer job description MWIJOBD. 

To edit an environment library list 

1 From the Change Environment panel or Create Environment panel, press F13=Library 

List. 

For a local environment, the Edit Environment Library List - Local panel displays. For a 

remote environment, the Edit Environment Library List - Remote panel displays. These 

panels are like the OS/400 Edit Library List (EDTLIBL) command panel. 

97


98 

2 In the Sequence Number field, specify the number to order the library in relation to other 

libraries. For traditional (non AllFusion 2E) environments, use the sequence number to 

order the libraries in the sequence required for compilation when promoting to the 

environment. 

3 In the Library field, specify the required library name. 

4 Press ENTER. The Edit Environment Library List panel displays the current libraries in 

sequential increments of 10. 

On the Edit Environment Library List - Remote panel, you can press F7 to save the 

remote library list and display the Edit Environment Library List - Local panel. Press F7 

again to save any local library list changes and return to the Edit Environment Library 

List - Remote panel. 

If you press ENTER without making any changes to the library list, the previous library 

list is saved and the Edit Environment Library List panel displays. 

Promotion Job Scheduling 

This task allows you to set up automatic job scheduling for the promotion steps: compile, 

move, and distribution for traditional environments, model copy step for AllFusion 2E 

environments, and export for LANSA environments. Job scheduling gives you control over 

the management of production environments and optimizes the utilization of your OS/400 

resources. 

Job scheduling is typically used to process jobs during non business hours, for example, 

nights or weekends, or to run jobs in a specific job queue.

To change promotion scheduling defaults 

1 From the Work with Environments panel, select the environment with option 

13=Promotion Scheduling and press ENTER. The Change Environment Promotion 

Scheduling panel displays. 

Environments 

2 Specify the Request Submission Defaults for the following stages of promotion: 

Model copy fields (for AllFusion 2E environments), or Compile fields for traditional 

environments. 

It is not necessary to change the scheduling defaults from *CURRENT, *SYSCTL, and N 

for Hold on job queue. Override options are available for each promotion step, (for 

example, export if a LANSA environment, compile, move, and distribute) and archiving. 

If the to and from time settings cross over into the next day, for example, from Day 1 at 

8:00 p.m. to Day 2 at 4:00 a.m., it uses the *CURRENT default that the second time period 

falls on in the second day and schedules accordingly. 

3 Press PAGE DOWN to display the second Promotion Scheduling panel and specify the 

Request Submission Defaults for the distribute (or export if a LANSA environment) and 

move stages of the promotion. 

4 Press ENTER to process the update. 

99


Related Environments 

100 

This function allows you to define the relationship of an environment with other 

environments in the form of an ordered list. Implementer uses this list in check out to display 

the member/object lists and related objects in an environment. For this reason, related 

environment lists are only used by Implementer for production environments, although you 

can define them for development and test environments for reference purposes. 

The two common uses of related environments are when: 

developing one release of an application as changes to an earlier release (release 2.0 

based on release 1.0) 

modifications to production are in a separate environment from the base production 

In either scenario, the related environment list must include all the environments, in order, 

that are logically included in the environment being defined. You must also include the 

necessary libraries on the environment library list for proper compilation when you define 

the environment. 

An environment always has at least one environment on the related environment list, the 

environment itself. You add additional related environments in sequence number order, 

which is the search order you want Implementer to follow to locate a member/object in the 

list. 

To define related environments 

1 From the Work with Environments panel, select the environment with option 

14=Related environments, and press ENTER. The Work with Related Environments 

panel displays.

Environment Path 

2 Press F6=Add. The Add Related Environment panel displays. 

3 Complete the following fields: 

Environments 

In the Sequence number field, specify the number to order the environment in 

relation to other related environments. 

In the Related environment field, type the name of the related environment, or press 

F4=List to select from a list of environments. 

The Display as locked field allows you to define, when an item in the specified 

related environment is locked, if the item in the related environment displays as 

locked in Work with Objects (the actual object in the related environment is locked). 

This pertains to the mods and base environment models, when the item in base 

shows as locked but the actual lock is from the mods environment. 

Specify Y to show lock history as locked for the base environment. This is the 

required value when the related environment is on the related environment list 

of multiple environments, for example, multiple releases of an application, and 

when the Environment and Related environment fields have the same 

environment name. 

Specify N to show lock history as not locked for the base environment. 

4 Press ENTER to add the related environment. 

This function allows you to add additional controls that define a standard and emergency 

development path for production environments. The path defines the exact flow of 

members/objects through the development, testing, and production environments, and 

restricts access so they cannot move outside this flow. It also allows defaulting the From 

environment and target environment in check out and promotion. You can restrict users to 

the defined paths, preventing any circumvention of the predefined flow of work back into 

production. 

You can define a path for each production environment, representing the flow from the 

development environment, quality assurance, environment group, and original production 

environment (the first *PRD environment on the path). If an environment is on more than one 

path, Implementer uses the path designated by the original check out From environment 

(lock). If no lock exists, Implementer uses the first path found, including the environment, as 

the first production environment in the path. 

NOTE The terms environment path and application path are also referred to as a 

development path. 

101


102 


You can define application paths at the environment level and at the project level. If you 

use both environment paths and project paths, the project path is the default path in 

check out and create request when a project with a defined path is specified. For details, 

see “Project-based Application Paths” on page 142. 

Each application path can have a standard path and an emergency path that represents 

the flow member/objects follow from the initial check out to the final promotion into 

production. 

A standard path typically has a development environment (*TST) or library in the first 

sequence. The next sequence can be optional QA environments or environment groups 

(*QAC). The first production environment (*PRD) on the path must be the environment 

you check out from. For an environment group, the primary environment in the group 

must be the environment you check out from. Subsequent production environments or 

environment groups are allowed depending on your development model. 

An emergency path typically allows check out from production to development, and 

promotion directly from development back to production. You can modify this flow as 

needed. 

To define a standard or emergency path for an environment 

1 From the Work with Environments panel, type option 17=Standard path, or option 

18=Emergency path, and press ENTER to display the respective Environment Path panel. 

This panel allows you to create, change, delete, and display paths. The top environment 

or library represents development. The first production environment on the path is the 

check out from environment.

2 Press F6=Add. The Add Standard Path Entry panel displays. 


In the Sequence number field, type the appropriate number. 

Environments 

In the Entry field, type the environment name or press F4=Prompt to select from a 

list of environments. 

The value *USRPRF allows each developer to define a different development 

environment or library in the user profile entry (defined in Work with Users). The 

development environment or library must be the first sequence. 

4 Press ENTER to add the new path entries. 

Special Command Processing 

Implementer’s special commands feature allows you to define commands or programs that 

process each time a promotion targets a specified environment. You can define special 

commands to run on an environment basis, or globally for all environments. 

Implementer uses the environment library list when issuing the special commands. 

Therefore, if you have any unqualified object references in the command, you must include 

in the environment library list each library where the objects are located. The special 

command must exist in the environment library list (defined in Work with Environments) for 

each environment. 

NOTE You can use substitution variables within your command, and add comments 

to the special commands to make them self-documenting. Comments can display 

either before or after the command, and they must be in brackets, for example, 

/* This is a comment */ 

For details on special commands and substitution variables, see the 

MKS Implementer 2006 User Guide. 

To define special commands for an environment 

1 From the Work with Environments panel, type option 19=Special commands next to the 

environment and press ENTER. The Work with Environment Special Commands panel 

displays. Any existing special commands display on this panel. 

103


104 

2 Press F6=Create to display the Expanded Command Display panel. 

3 Complete the fields as described in “Expanded Command Display Field Descriptions” 

on page 105. 

4 Press ENTER to save the special command. The Expanded Command Display panel 

displays blank. Create additional special commands, or press F12 to display the Work 

with Environments panel. The panel displays the special command you created. 

5 Press ENTER again to permanently save the new special command. The Work with 

Environments panel displays. 

Global Special Commands 

You define global special commands for environments by using the *ALL option. This option 

applies to all environments currently defined, as well as new environments you may add 

later. 

To create a special command for all environments 

1 From Work with Environments, press F10=*ALL Special Commands. The Work with 

Environment Special Commands panel displays. 

Any existing special commands display on this panel. Notice the Environment field 

defaults to *ALL.

2 Press F6=Create to display the Expanded Command Display panel. 

Environments 

3 Complete the fields as described in the following table, and press ENTER to add the 

command. 


Expanded Command Display Field Descriptions 

For Action Specify which promotion step processes the special command. The default 

value is blank. 

1=Compile: Special command runs in the compile stage. 

2=Dist-Host: Special command runs in the distribution stage on the host 

system. 

3=Dist-Rcvr: Special command runs in the distribution stage on the remote 

system. 

4=Move: Special command runs in the move stage. For promotions that 

target a remote system, the special command occurs where the move 

occurs. 

5=Move-Host: Special command runs on the system where the request 

originated, after successful distribution. This option is meaningful for 

promotions that target a remote system. 

6=Checkout: Special command runs in check out. 

When to do Specify when, during the selected For Action, to issue the special command. 

1=Before: Special command runs before the specified For Action. 

2=After-OK: Special command runs after the specified For Action 

successfully completes. 

3=After Fail: Special command runs after the specified For Action fails. 

105


Environment Report 

106 


The Environment Report lists the information defined for an environment. You can select to 

print summary level or detail information. 

The information includes: library type and defaults; host and remote library list; environment 

groups that contain the environment; related environments; standard and emergency paths; 

create request defaults; model copy details for AllFusion 2E environments; and promotion 

scheduling and submission overrides. 

The report also includes the setup defaults for AllFusion 2E, AS/SET, LANSA, and 

PeopleSoft World if installed. 

You can include information on the products and versions built from an environment, and 

the product versions that define an environment as a default customer environment. 

For environments that manage IFS objects, the report includes directory setup and archive 

information. The summary report can include object code information for both active and 

inactive object codes, object authorities, and object name rules. For environments that 

manage 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). 

To print a detailed Environment Report for a specific environment 

From Work with Environments, select the environment with option 6=Print, and press 

ENTER. A message at the lower-left of the panel confirms the report printed. 

To print a summary or detailed Environment Report for all environments 

1 From the Implementer Menu, type 37, Environment Report, and press ENTER. 

2 Complete the fields as follows: 

Expanded Command Display Field Descriptions 

Sequence number Specify when to issue the command relative to other special commands. The 

number must be unique from other special commands for the environment. 

Command Specify the standard OS/400 command syntax of the command to run, or 

press F4 to prompt the command. 

In the Print object codes field, specify whether to include object codes for the 

environment. Type Y to print object codes. The default value N omits object codes. 

In the Print object authorities field, specify whether to include object authorities for 

the environment. Type Y to print object authorities. The default value N omits object 

authorities.

Environments 

In the Print object codes rules field, specify whether to include object name rules if 

defined for the environment. Type Y to print object name rules. The default value N 

omits object name rules. 

In the Output Queue and Library fields, specify the standard OS/400 submit job 

parameters as required. 

3 Press ENTER. A message at the lower-left of the panel confirms the report submitted. 

Third Party Integration Prerequisites 

The following information pertains to working with environments when using Implementer 

with certain third party integrations. 

AS/SET Prerequisites 

To perform the initial setup for an AS/SET environment 

1 In System Control Maintenance, type Y in the AS/SET installed field and press ENTER. 

This allows you to define a standard environment with AS/SET information. 

2 In the Work with Environments panel, select the environment with option 11=AS/SET 

and press ENTER to display the Change Environment panel. 

3 In the AS/SET application set field, type the name of an existing application set. 

4 In the Archive application set field, type the name of the archive application set to 

archive AS/SET definitions. 

5 On the Change Environment panel, specify the number of archive versions in the 

Archive Versions field. In addition, specify the source library and archive library for 

traditional objects, and the required number of versions. 

6 Press ENTER. The Work with Environments panel displays. 

After completing this step, the Special environment field in the second Change 

Environment panel displays AS/SET. For details on configuring AS/SET integration, see 

page 316. 

LANSA Prerequisites 

To perform the initial setup for a LANSA environment 

1 In System Control Maintenance, type Y in the LANSA installed field and press ENTER. 

This allows you to define a standard environment with LANSA information. 

2 In the Work with Environments panel, select the environment with option 12=LANSA, 

and press ENTER to display the Change Environment panel. 

3 In the LANSA partition name field, type the name of the partition. 

107


108 

4 In the Copy LANSA object in check out field, specify whether to copy LANSA objects 

during check out. 

If the environment definition specifies to copy LANSA objects during check out, the 

copy runs in batch. The LANSA objects are exported out of the From environment and 

imported into the target environment. MKS recommends you manually verify the 

LANSA export and import reports. 

When checking out or promoting LANSA objects, the partition of the From environment 

should not be the same as the partition of the target environment. 


After completing this step, the Special environment field in the second Change 

Environment panel displays LANSA. For details on configuring LANSA integration, see 

page 328. 

PeopleSoft World Prerequisites 

To complete the initial setup for a PeopleSoft World environment 

1 In System Control Maintenance, type Y in the PeopleSoft World installed field and press 

ENTER. This allows you to define a standard environment with PeopleSoft World 

information. 

2 In the Work with Environments panel, select the environment with option 

16=PeopleSoft World, and press ENTER to display the Change Environment panel. 

3 In the PeopleSoft World common library field, type the name of the PeopleSoft World 

common library. 

4 In the PeopleSoft World archive library field, type the name of the archive library for 

archiving. 

5 On the Change Environment panel, define the number of archive versions in the Archive 

Versions field. In addition, specify the source library and archive library for traditional 

objects, and the required number of versions. 


After completing this task, the Special environment field in the second Change 

Environment panel displays PeopleSoft. For details on configuring PeopleSoft World 

integration, see page 355.


Why is it necessary to use environments rather than just libraries? 

Environments and User Capabilities 

Two reasons are: Implementer only allows promotion into an environment to ensure positive 

tracking of all members/objects at each step of the development process, and, environments 

are an organizational aid for libraries and members/objects. Because environments are 

usually set up by application, it allows strict organization of all objects within the libraries. 

Environments automate many manual tasks, a primary advantage for the developer. 

What are the most common user errors that occur during environment setup? 

The necessary libraries are not included in the environment definition, and an incorrect 

library compilation order (compile library list). 


An environment has user capability flags that allow you to control the authority each user 

has to the environment for check out and promotion, as well as the authority to lock activities 

related to concurrent development and lock maintenance. This task allows you to grant each 

user specific rights that reflect the development activities the user is allowed to perform to an 

environment. This task is necessary for each user enrolled in Implementer for each 

environment they need to work in. 

The default rights you define in Implementer restrict rather than enable free access to the 

functions in Implementer. Thus, it is necessary to establish user authorities in two functional 

areas: 

Work with Users for basic authorities 

Work with Environments User Capabilities or Work with User - Environment 

Capabilities for environment-specific capabilities 

When initially setting up or changing environments, you can establish user capabilities while 

working with the environment—for this purpose, access the Change User Environment 

Capabilities panel through Work with Environments as described in the following task. 

When setting up or changing user profiles, access the panel from Work with Users. To set up 

required default libraries, environments, projects, or other user defaults, see “Users” on 

page 72. 

To assign user capabilities for an environment 

1 From the Implementer Menu, type option 42 or type STRIM (*WRKENV) at the 

command line and press ENTER. The Work with Environments panel displays. 

2 Select the environment with option 15=User capabilities and press ENTER. The Work 

with User Capabilities panel displays for the selected environment. 

109


110 

3 Select the user profile with option 2=Change and press ENTER. The first of two Change 

User Environment Capabilities panels displays. 

4 Establish the basic authorities for check out, locks and concurrent development, and 

promotion (press PAGE DOWN) as described in the following tables, and press ENTER to 

process the changes. 

Change User Environment Capabilities Field Descriptions: Panel 1 


Check out 

The following fields define the user’s authority to the environment for check out related tasks. 

Standard 

check out to 

Standard 

check out from 

Emergency 

check out to 

Emergency 

check out from 

Specify if the user has authority to perform standard check out to the 

environment. 

Specify if the user has authority to perform standard check out from the 

environment. 

Specify if the user has authority to perform emergency check out to the 

environment. a 

Specify if the user has authority to perform emergency check out from the 

environment. 

Locks 

The following fields define the user’s authority to the environment for tasks related to locks and 

concurrent development.




Allow concurrent dev Specify if the user has authority to perform concurrent development and 

check out a member/object from this environment when the item is checked 

out by another user. b,c Does not apply to emergency check out or promotion. 

1=No: User does not have authority to perform concurrent development. 

2=Seq Only: User has authority to perform concurrent development only 

for items under sequential development. User is not allowed to override 

the default copy From environment in check out. 

3=All-Auto: User has authority to perform concurrent development and 

override the copy From environment in check out. In sequential 

development, the copy From environment value defaults automatically. In 

non sequential development, user must manually select the copy From 

environment. This is the default value when Implementer is installed. 

4=All-Manual: User has authority to perform concurrent development and 

select the copy From environment in check out. In both sequential and non 

sequential development, the copy From environment defaults to blank and 

user must select it manually. 

Resolve conflicts Specify if the user has authority to resolve concurrent development conflicts 

on the Manage Concurrent Development - Work with Conflict Resolution 

panel. b,c 

For a production environment, applies to resolving conflicts for locks from the 

environment. For a development or test environment, applies to resolving 

conflicts for locks to the environment. Does not apply to emergency 

promotion. 

1=No: User does not have authority to resolve conflicts. 

2=Seq Only: User has authority to resolve conflicts only for items under 

sequential development (allows automatic conflict resolution). 

3=All-Auto: User has authority to resolve conflicts. In sequential 

development, conflicts resolve automatically. In non sequential 

development, user must resolve conflicts manually. This is the default 

value when Implementer is installed. 

4=All-Manual: User has authority to resolve conflicts. In both sequential 

and non sequential development, user must resolve conflicts manually. 

Lock maintenance Specify if the user has authority to maintain or delete locks on the 

Workbench. A project leader or another user that has move capabilities 

generally performs this function. 

a Emergency check out of a locked member/object causes concurrent development that requires users 

have authority to perform concurrent development for the From environment. In the case of an 

emergency, however, the authorities required to perform emergency check out override the authorities 

required to perform concurrent development. This allows a user who does not have authority to 

concurrent development to perform an emergency check out. 

b When using the Implementer Web interface for check out and promotion, the values 3=All-Auto and 

4=All-Manual function like the value 2=Seq Only. This is because the Web interface does not allow the 

manual entry of a copy From environment. 

c For details on how concurrent development is globally activated, see “Concurrent Development Scope” 

on page 71. For a description of sequential and non sequential development, see “Glossary” on 

page 457. For details on how the default copy From environment is determined, see the 


111


112 

Typical Environment Capabilities by User Type 

Implementer has the following types of users: 

administrator 

project leader (*PRD, *TST, or *QAC environments) 

senior developer (*PRD, *TST, or *QAC environments) 

user acceptance tester (*QAC environments) 

Implementer software owner 

security officer 



Request Promotion 

The following fields define the user’s authority to the environment for tasks related to promotion. 

Standard 

create request to 

Standard 

create request from 

Emergency 

create request to 

Emergency 

create request frm 

Distribute 

standard request 

Distribute 

emergency request 

Move 

standard request 

Move 

emergency request 

Specify if the user has authority to create a standard promotion request to 


Specify if the user has authority to create a standard promotion request from 


Specify if the user has authority to create an emergency promotion request 

to this environment. 

Specify if the user has authority to create an emergency promotion request 

from this environment. 

Specify if the user has authority to distribute a standard promotion request to 


Specify if the user has authority to distribute an emergency promotion 

request to this environment. 

Specify if the user has authority to move a standard promotion request to this 

environment. 

Specify if the user has authority to move an emergency promotion request to 


Maintain request Specify if the user has authority to maintain promotion requests for the 

environment. 

Recover request Specify if the user has authority to recover archived requests for the 

environment. 

Override 

obj attribute sourc 

Specify if the user has authority to change the source of object attributes at 

for the environment.


The following sections define the overall role of each type of user with. The tables identify the 

typical capabilities assigned to each type of user based on the environment type. You must 

determine how to assign capabilities based on your organization’s operations. 

Administrator 

The administrator has the highest level of authority within Implementer to maintain the 

Implementer control parameters. Use this role for initial set up, to install new applications, 

and to change environments and users’ capabilities. The following table lists the typical 

settings for administrators for production environments. 

Capabilities Production 

Check Out 

Standard check out to - 

Standard check out from Y 

Emergency check out to - 

Emergency check out from Y 

Locks 

Allow concurrent dev 2, 3 or 4 (Yes) a 

Resolve conflicts 2, 3, or 4 (Yes) a 

Lock maintenance Y 

Request promotion 

Standard create request to Y 

Standard create request from Y 

Emergency create request to Y 

Emergency create request from Y 

Distribute standard request Y 

Distribute emergency request Y 

Move standard request Y 

Move emergency request Y 

Maintain requests Y 

Recover requests Y 

Override obj attribute source Y 

a Based on how concurrent development is defined within your organization: 2=Sequential only, 

3=All-Auto, 4=All-Manual. For details, see page 110. 

113


114 

Project Leader: Any Environment Type 

The project leader or a user profile that has move capabilities has the next ascending level of 

authority to maintain and monitor change activity. This person might be a senior developer, 

analyst, project leader, or manager. This user typically creates projects, manages concurrent 

development, and moves developer-created promotion requests into the environments the 

administrator controls. The following table lists the typical settings for environment 

administrators for production, development, and quality assurance environments. 

Capabilities Development QA Production 

Check Out 

Standard check out to Y - - 

Standard check out from - Y Y 

Emergency check out to N - - 

Emergency check out from - N Y 

Locks 

Allow concurrent dev 1 (No) 1 (No) 2, 3 or 4 (Yes) a 

Resolve conflicts 1 (No) 1 (No) 2, 3, or 4 (Yes) a 

Lock maintenance Y Y Y 


Standard create request to - - Y 

Standard create request frm Y Y Y 

Emergency create request to - - Y 

Emergency create request frm Y Y Y 

Distribute standard request Y Y Y 

Distribute emergency request N N Y 

Move standard request Y Y Y 

Move emergency request N N Y 

Maintain requests Y Y Y 

Recover requests - - Y 

Override obj attribute source Y Y Y 


3=All-Auto, 4=All-Manual. For details, see page 110.

Senior Developer: Any Environment Type 


The senior developer checks out source members, performs programming changes, and 

creates promotion requests. A senior developer is often given emergency capabilities. The 

following table lists the typical settings for senior developers for development, quality 

assurance, and development environments. 

Capabilities Development QA Production 

Check Out 

Standard check out to Y - - 

Standard check out from - Y Y 

Emergency check out to N - - 

Emergency check out from - N Y 

Locks 

Allow concurrent dev 1 (No) 1 (No) 2, 3 or 4 (Yes) a 

Resolve conflicts 1 (No) 1 (No) 2, 3, or 4 (Yes) a 

Lock maintenance N N Y 


Standard create request to - Y Y 

Standard create request frm Y Y Y 

Emergency create request to - N Y 

Emergency create request frm N N N 

Distribute standard request N N Y 

Distribute emergency request N N Y 

Move standard request N N Y 

Move emergency request N N Y 

Maintain requests N N Y 

Recover requests N - N 

Override obj attribute source - Y N 


3=All-Auto, 4=All-Manual. For details, see page 110. 

115


116 

User Acceptance Tester: QA Environment 

This user typically accepts promotion requests into their test environments, tests the changes 

in a controlled test environment, and creates promotion requests to production or the next 

test environment. The following table lists the typical settings for user acceptance testers for 

quality assurance environments. 

Capabilities QA 

Check Out 

Standard check out to - 

Standard check out from N 

Emergency check out to - 

Emergency check out from N 

Locks 

Allow concurrent dev 1 (No) 

Resolve conflicts 1 (No) 

Lock maintenance N 


Standard create request to N 

Standard create request frm Y 

Emergency create request to N 

Emergency create request frm N 

Distribute standard request N 

Distribute emergency request N 

Move standard request N 

Move emergency request N 

Maintain requests N 

Recover requests N 

Override obj attribute source N

Implementer Software Owner MWIPROD 

Environment Repository Build 

Implementer includes the user profile MWIPROD. This user profile has security 

administrator rights to set up Implementer and owns most of the objects in Implementer. 

MWIPROD typically does not have capabilities to the environments in Implementer. MKS 

recommends you define a user profile other than MWIPROD to serve as the administrator; 

however, this profile should not have specific authorities to the environments. 

NOTE MKS recommends you set the MWIPROD profile to bypass expiring the 

password. To do this, issue the CHGUSRPRF command with parameter value 

PWDEXPITV(*NOMAX). 

Security Officer 

MKS recommends you use the default user profile in the event that access is accidentally 

denied to other users in the system. The IBM-shipped security officer user profile QSECOFR 

has security administrator rights to administer Implementer. 

The security officer typically does not have capabilities to the environments in Implementer. 

MKS recommends you define a user profile other than QSECOFR to serve as the 

administrator. Again, this profile should not have specific authorities to the environments. 

NOTE Any of these user profiles can be group profiles; however, if a specific user is 

a member of a group but not enrolled under a separate OS/400 profile, the user has 

the same rights as those defined for the group profile. 


The Build List function, also called the “build”, loads source and object, and object code 

information from an environment’s set of libraries into Implementer’s environment 

repository. The repository provides a productivity aid that allows you to select members and 

objects from lists rather than having to manually type each name in the check out and create 

request functions. In addition, Implementer uses the repository for impact analysis to 

determine the source of related objects across environments. 

You can create the environment repository by using any of the following build types: 

*ALL processes all member/object types including related objects. By using additional 

parameters you can control whether to show build objects in the report, retain existing 

valid object codes, add new member/objects, remove records for items that no longer 

exist in the environment libraries, or completely clear the repository and rebuild it from 

start. 

*IFS processes IFS object only. This is useful when an environment has been actively 

managing traditional member/objects, and you add new IFS objects. 

117


118 

*REL processes related objects only. It updates the repository to show the environments 

where related objects exist. 

For more information on build types, see “Build List (IBLDMBOLST) Command Parameters” 

on page 119. 

The build generates the Environment Build Report, which provides member/object status 

and information on errors and warnings that occurred during the build. You can use this 

report in place of the job log or user message queue for troubleshooting errors with the build. 

For details, see “Environment Build Report” on page 121. 


You must have authority to host environment maintenance to run the build for a host 

environment, and authority to remote environment maintenance to run the build for a 

remote environment. These authorities are defined in Work with Users. 

The environment’s program library, file library, and source library must exist or the 

build ends in error. 

You can run the build from an option in Work with Environments or by using a 

command interface. 

In Work with Environments, the Build List field confirms the repository status for an 

environment. 

For each *PRD and *QAC environment in Work with Environments, specify to maintain 

related object information and specify the source of information. This is not required for 

development environments. 

If you use related objects in check out or create request, you must run the build for each 

new *PRD and *QAC environment to create the initial list of member/objects in the 

environment. 

Once you create the member/object list and the environment/libraries are handled by 

Implementer, the member/object list is maintained dynamically. You can rebuild the list 

for maintenance purposes at any time, for example, if you edit object codes that support 

source and object with different names. 

If multiple object codes exist with the same characteristics, the object code with the 

lowest sequence number is selected by the build when the Retain Object Codes value is 

set to *NO. This gives better control over which object code is selected for the 

environment. 

Changing the sequence number of an object code may change the compile sequence of 

members/objects in Compile Request. 

The build does not assign object codes used to change the characteristics or data of an 

existing object. This applies to any object code defined with creation process M or a 

special characteristic beginning with “*”. For example, the build does not assign the 

object codes PFDTA, PFCHG, and MRGMSGF.


For AS/SET environments, the build includes both traditional objects and AS/SET 

definitions that exist in the application set specified for the environment. 

Object Version Stamping 

During the build for production environments, Implementer if object version stamping is 

active in System Control Maintenance. If active, and the actual object is stamped with a 

version number, Implementer processes the corresponding repository record as follows: 

If the object version is valid, the build assigns that version number to the repository 

record. 

If the object is not stamped or stamped with an invalid version number, the build assigns 

the repository record with version number 1 or 1.0 based on the specified versioning 

method. If a user-defined versioning method is specified, a user exit allows you to set the 

version number. 

The repository records for *TST and *QAC environments are built with a blank version 

number, and source-only objects built by Implementer are disregarded (they are not assigned 

a version number). For more information on object version stamping, see page 146. 

NOTE The build updates the repository record with the object version, not the actual 

object. The build also does not stamp objects with issue or DR numbers. 

To run the build list 

1 From the Implementer Menu, type option 42, Environments, and press ENTER. 

2 Select the environment with option 30=Build List, and press ENTER. The Build Member/ 

Object Lists (IBLDMBOLST) command panel displays. 

3 Complete the command parameters as described in “Build List (IBLDMBOLST) 

Command Parameters” on page 119. 

Upon successful completion a message confirms the job completed normally. In Work 

with Environments, the Build List field reflects the repository status for each 

environment. 

TIP You can run the environment build list for IFS objects only from Work with 

Objects option F21=Build IFS Object List. 

Build List (IBLDMBOLST) Command Parameters 

The Build List (IBLDMBOLST) command is the command interface to Work with 

Environments option 30=Build List. 

119


120 

Environment 

Specify the environment to build the repository for. 

Build type 

Specify the objects to include in the repository. 

*ALL Builds the repository for all objects in the environment libraries, including 

IFS objects. Generates the Environment Build Report. 

*IFS Builds the repository for IFS objects only. Generates the Environment Build 

Report. Requires the following Retain object codes parameter value set to 

*NO. 

*REL Builds the repository for related objects only. Does not generate the 

Environment Build Report. Requires the following Retain object codes 

parameter value set to *YES. 

Retain object codes 

The build validates each repository record in the environment’s libraries to ensure the 

associated object code is valid. If valid, the record remains as is. If not valid, derives a new 

object code and recreates the repository record. 

Specify how to build the repository. 

*YES Validates the object code, object and/or source, and retains the existing 

object code for valid items. Builds the repository with new source/objects 

added to the environment’s libraries. Removes source/objects that no 

longer exist in the environment’s libraries. This is useful for environments 

with object codes modified after the initial repository build, for example, 

changes to sequence numbers, compile parameters, or compile commands, 

as it retains valid records you otherwise have to recreate. 

This is the default value and requires the Build Type value *ALL. 

*NO Clears the repository of existing records and rebuilds it based on current 

information in the environment’s libraries. 

Show built objects in report 

Specify whether to include built objects in the Environment Build Report. 

*YES The report includes a list of all member/objects in the environment 

repository. 

*NO The report excludes the environment repository section. 

Output queue/Library 

Specify the output queue and library for the Environment Build Report. The value *JOB uses 

the output queue and library of the user submitting the job.

Submit 

Specify *YES to submit the job to batch processing, or *NO to run interactively. 

Job queue/Library 


Specify the job queue and library for the build list. The value *PRODUCT uses the default 

output queue and library specified in System Control Maintenance. 

Hold on job queue 

Specify whether to hold the build list job on the job queue. 

*JOBD Uses the value specified in the job description of the user submitting the 

job. This is the default value. 

*NO The job is not held on the job queue. 

*YES The job is held on the job queue. 


When do you need to run the build list? 

Run the build list for each newly created environment, or if you add source or objects to the 

environment library outside of Implementer. 

If you create a new member using Implementer, is it necessary to rerun the build list? 

No. Implementer automatically updates the list. When you check out a new member with an 

action code of 2, Implementer creates a new member. 

Environment Build Report 

The Environment Build Report generates automatically for the build types *ALL and *IFS. 

The report does not generate for the build type *REL. This report is helpful for problem 

resolution if errors or unexpected results occur during a build, as it replaces having to use the 

job log or user message queue for troubleshooting errors with the build. 

The report includes the following information: 

general environment information 

list of all source members and objects in the environment libraries not added to the 

repository, with specific messages for each source member and object 

optionally, a list of all source, objects, and object codes loaded into the repository 

list of objects in the environment libraries not added to the repository 

list of source members in the environment libraries not added to the repository 

warnings that occurred during the build for specific related objects 

121


122 

message legend that guides you to specific actions to resolve the errors 

NOTE Although rare, the job log may also include unique problems not detectable 

by Implementer. 

Environment Repository Report 

The Environment Repository Report provides a listing of all source members and objects 

currently in the repository. The report is a print snapshot of the environment information 

that displays when filtering by environment and viewing detail in Work with Objects. 

The report includes general environment information and a list of all objects and object codes 

currently in the repository. You can optionally include related objects. You can sort the report 

by object name or object code. 

When both traditional and IFS objects exist for an environment, the report is divided into two 

sections; one for traditional objects and the other for IFS objects. IFS object names include the 

full object name and relative path. If the long name and path are longer than 100 characters, 

the field truncates at the end. 

The values stored in the Chg Date/Time fields are the latter of the date and time of the last 

environment build or the last promotion. 

The report is available by using Work with Environments option 27=Repository Report. 

When selected, it prompts the Repository Report (IPRTREPRPT) command. You can also 

issue the command from a command line. This is a host-only feature (not available on remote 

systems). 

To generate the Environment Repository Report 

1 Do either of the following to prompt the Repository Report (IPRTREPRPT) command: 

From Work with Environments, type option 27=Repository Report next to the 

environment, and press ENTER. 

On a command line, type IPRTREPRPT and press F4=Prompt. 

2 Complete the parameters as defined next in “Repository Report (IPRTREPRPT) 

Command Parameters” and press ENTER. The report generates to the user’s default spool 

file based on the command parameters. 

NOTE Running the Environment Repository Report for an environment when the 

build list has not been run causes an empty report. In Work with Environments, 

check the Build List field to verify the environment’s build status.

Repository Report (IPRTREPRPT) Command Parameters 

Environment 


Specify the environment name. If using Work with Environments option 27=Repository 

Report, this value defaults to the environment selected. 

Show related objects 

Specify *YES to include related objects, or *NO to omit related objects. 

Member/object sort method 

Specify the report sort order. 

*OBJECT The report sorts in member/object order. This is the default value. 

*OBJCODE The report sorts in object code order. 


Specify the output queue and library for the report output. The default value *JOB uses the 

output queue and library associated with the user generating the report. 

Submit 

Specify whether to submit the job for batch processing or run interactively. The default value 

*YES submits the job. 


Specify the job queue and library for job processing. The default value *PRODUCT uses the 

default job queue and library defined in System Control Maintenance. 


Specify whether to hold the report job on the job queue. 



*NO Does not hold the job. 

*YES Holds the job. 

Environment Verification Report 

The Environment Verification Report is an audit tool that allows you to compare the actual 

source and objects in an environment’s set of libraries to the source and object definitions 

recorded in the Implementer repository for the environment. It is useful to run after using 

Implementer to manage member/objects, to verify the accuracy or validity of the 

environment’s contents and to identify potential problems. 

123


124 

The verification identifies: compile dates, source location, authorities, unexpected source and 

objects in the environment libraries—and vice versa—expected source or objects not located, 

and changes made outside of Implementer. 

The report lists items by section ID according to the potential issue identified, as follows: 

objects in the environment libraries that do not exist in the repository 

source members in the environment libraries that do not exist in the repository 

objects in the repository that do not exist in the environment libraries 

source members in the repository that do not exist in the environment libraries 

source-based objects in environment libraries that were created from source other than 

that defined to the environment 

source members in the repository where the change date/time stamp on the actual 

source member does not match that of the repository record 

objects in the repository where the change date/time stamp on the actual object does not 

match that of the repository record 

IFS files in a directory but not in the repository 

IFS files in the repository but not in a directory 

This feature is available for both host and remote environments by using Work with 

Environments option 26=Verification Report. When selected, it prompts the Verification 

Report (IVFYRPT) command. You can also issue the command from the command line. 

To generate the analysis and print the Environment Verification Report 

1 Do either of the following to prompt the Verification Report (IVFYRPT) command: 

From Work with Environments, type option 26=Verification Report next to the 

environment, and press ENTER. 

On a command line, type IVFYRPT and press F4=Prompt. 

2 Complete the parameters as defined next in “Verification Report (IVFYRPT) Command 

Parameters” and press ENTER. The report generates to the user’s default spool file based 

on the command parameters. 

Verification Report (IVFYRPT) Command Parameters 

Environment 

Specify the environment name to process. If using Work with Environments option 

26=Verification Report, the value defaults to the environment selected.


Environment Groups 

Specify the output queue and library to place the report. The default value *JOB uses the 

output queue and library of the user submitting the job. 

Submit 

Specify whether to submit the job or process interactively. The default value *YES submits 

the job. Specify *NO to process interactively. 


Specify a job queue and library name, or use the default value *PRODUCT to use the job 

queue and library defined in System Control Maintenance. 


Specify whether to hold the report job on the job queue. 



*NO Does not hold the job. 

*YES Holds the job. 

Environment Groups 

An environment group is a collection of two or more environments, called a target 

environment group. You can use a target environment group to promote a request containing 

one or more objects to more than one environment. The target environment group function 

eliminates the need to select a list of environments every time you create a promotion request 

to multiple target environments. 


You can specify an environment group on an application path. For details on path setup, 

see “Environment Path” on page 101, and “Project-based Application Paths” on 

page 142. 

If the environment group’s primary environment is the first production environment on 

the path, it is the check out From environment. 

If a production environment precedes the environment group on the path, the first 

production environment is the check out From environment. 

If the environment group targets AS/SET environments, the first environment in the 

environment group must be an AS/SET environment. You can include other AS/SET 

environments in the environment group. 

125


126 

When using environment groups for promotion, AS/SET information is promoted only 

to the environments defined as AS/SET environments. 

To minimize potential errors with promoting to incorrect environments, you cannot 

modify an environment group using the Target Environments function in Create 

Request, Compile Request, Move Request, or Request Maintenance. 

If you use MKS Source archiving, when a promotion targets an environment group that 

has both local and remote environments, only the local environment has the revision 

update (you cannot archive remote environments in MKS Source). If you later promote 

the items to a group, either QA environments further on the path or production, both the 

host and remote repository entries for the items reference the associated revision IDs. 

To create or change an environment group 

1 From the Implementer Menu, type option 43, or type STRIM (*WRKENVGRP) on the 

command line and press ENTER. The Work with Environment Groups selection panel 

displays. 


To add an environment group, press F6=Add. 

To copy an existing environment group, type 3 in the Opt field and press ENTER. 

To change an environment group, type 2 in the Opt field and press ENTER. 

3 On the Work with Environment Groups detail panel, complete the following fields: 

In the Environment group field, type the group name. The value must begin with an 

asterisk (*) and include a description. 

In the Opt field, type 1 to select the environments to include. 

For each selected environment, in the Seq field type the sequence for promotion. 

The primary environment must be sequence 1. Additional environments must have 

a sequence greater than 1. 

In the Cmp field, specify Y or N to indicate whether to compile for this environment. 

4 Press ENTER. The Work with Environment Groups selection panel displays. 

TIP To work with an environment, press F20 to display the Work with 

Environments panel. 


Can you target multiple environments if an environment group is not defined? 

Yes. During Create Request, press F14=Target environments and select the additional 

environments.

Object Codes 

What signifies an environment group name? 

Environment group names must begin with an asterisk (*). 

How is a primary environment identified from other environments in an environment group? 

A primary environment must be sequence 1. Typically, this is a host production 

environment. Additional environments must be a sequence greater than 1. 

Can a target environment group be used on a path? 

Object Codes 

Yes. You can use an environment group on a path. If the environment group’s primary 

environment is the first production environment on the path, it is the check out From 

environment. If a production environment precedes the environment group on the path, the 

first production environment is the check out From environment. 

Implementer uses object codes to define the various types of members/objects you check out 

and promote. They also enable automatic functions when you associate an object with an 

object code. 

An object code combines information from the OS/400 object type and source type and 

directly associates the following to an object: OS/400 object type, object attribute, source 

member type, default source file, and default authority. You can manually override the 

default creation command and authority when you create the promotion request. 

The Work with Object Codes function allows you to create, change, delete, activate, and 

deactivate object codes. Most users do not need to change the default values; however, this 

parameter-driven approach allows you to: 

Create new object codes for object types not shipped in Implementer (for example, other 

programming languages). 

Change the standard source file for existing objects codes. For example, you can specify 

that COBOL programs default to using the source file name QCBLSRC instead of the 

standard OS/400 default name QLBLSRC. Changes you make to global object codes in 

Work with Object Codes do not overwrite overrides defined at the environment level. 

Change the compile options. For example, you can optimize all RPG programs during 

compilation without changing the actual CRTRPGPGM command. 

Call your own compile procedures by changing the commands used for compiling. For 

example, many third-party application software packages have their own compile 

commands. 

Deactivate object codes you do not use, for example, System/36 and System/38 

environment object codes. 

127


128 

Control source archiving in MKS Source (requires active integration between 

Implementer and MKS Source). For details, see “Implementer and MKS Source 

Integration” on page 259. 


You can define object codes at three levels: object code, environment, and system. Object 

codes defined at the object code level and environment level can be activated or 

deactivated for one or all environments. Object codes defined at the system level can be 

activated or deactivated at the system or environment level. 

Object codes must be active and enabled to the specific environment before you can use 

them. Inactive object codes cannot be used within Implementer. 

When you make an object code inactive, Implementer retains any existing environment 

overrides. To reactivate, simply change the value of the Activity flag field. Reactivating 

the object code also reactivates the environment overrides. 

When defining object codes for source members and corresponding objects with 

different names, object codes that use a creation command with the SRCMBR parameter 

(for example, CRTPLIPGM) must specify the keyword #SRCMBR in the Source Member 

Name parameter. In the Creation command field, add SRCMBR(#SRCMBR. 

After editing object codes for an environment that has source and object with different 

names, run the Build List, option 30 in Work with Environments. For details, see 

“Environment Repository Build” on page 117. 

When using the SQLTABL (for physical files) and SQLINDX (for logical files) object 

codes, you must check out all related PFs and LFs together—implicit LF processing does 

not occur. 

To create or change an object code 

1 From the Implementer Menu, select option 44, Object Codes, or type STRIM 

(*WRKOBJCDE) at the command line, and press ENTER. 


To add a new object code, press F6=Add. The Create Object Code panel displays. 

To copy an existing object code, type 3 in the Opt field and press ENTER. The Create 

Object Code panel displays. 

To change an existing object code, type 2 in the Opt field and press ENTER. The 

Change Object Code panel displays.

Object Codes 

3 Complete the fields as described in “Object Code Field Descriptions” on page 129 and 

press ENTER. 

4 On the Object Code Override Defaults window, the activation reply options pertain to 

the action you performed: create, change, or reactivate. Select one of the following values 

and press ENTER. 

A=All: Activates to all environments. Use this when the object code is valid for all or 

most environments. You can selectively deactivate it for any environment as 

needed. Valid for actions create, change, and delete. 

N=None: Does not activate to any environment. Use this when few environments 

use the object code. You can selectively activate it for any environment as needed. 

Valid for actions create and reactivate. 

K=Keep: Activates the object code to the environments it was previously active to. 

Use this when reactivating an object code and the environments it was previously 

active to has not significantly changed. Valid for actions change and reactivate. 


Object Code Field Descriptions 

Object code Specify the name of the object code. The code relates to the source 

member type, not the OS/400 object type. 

Object codes for IFS files must begin with a dot (.) and can be followed 

by a character string. Object codes for IFS directories must begin with a 

backward slash (\). If the directory name has an extension, define the 

object code with a backward slash followed by a dot and the extension. 

For example, the object code for directory DIR.ONE is \.ONE. 

129


130 



Activity flag Specify the status of the object code. You cannot check out or create a 

request for a member/object using an inactive object code. You can use 

an inactive object code for inquiry purposes. 

1=Active: Object code is active. This is the default value for most object 

codes. 

0=Inactive: Object code is inactive. Some infrequently used object 

codes are delivered inactive with Implementer. 

Object type Specify the type of object associated with this object code. 

When this field blank, the object code is referred to as non object based. 

This occurs, for example, when you use Implementer to check out non 

OS/400 objects such as printed user manuals or source-based items that 

only have a source member, such as OCL36 source members. 

Object attribute Specify the system attribute of the object associated with this object 

code. 

Source member type For object codes related to source members or source-based objects, 

specify the system source member type. When this field is blank, the 

object code is referred to as non source-based. 

Match the source member type code of the actual object to what is 

defined in Implementer. For example, the source member type for a 

reference file defaults to PF (like a standard physical file). To compile the 

reference file before the physical file, change this type to PFREF and 

specify a lower sequence number. 

Default source file For object codes related to source-based objects, specify the name of the 

source file. You can override the source file name in Work with 

Environments when you define object codes for an environment, or in 

Work with User Profiles by specifying the development source files of the 

developer. 

Creation sequence Specify the sequence to compile members and objects. The value must 

be a unique number between 1–ZZZZ. Certain object types require 

compiling before others. In general, the logical order is as follows: field 

reference files, physical files, logical files, device files (such as display 

and printer files), commands, and programs. The object codes delivered 

with Implementer use this order. 

When automatically assigning object codes in check out or promotion, 

Implementer assigns sequence 8000 to IFS directory object codes, and 

sequence 8010 to IFS files. 

Special characteristics Specify any special characteristics for the object code, such as copy data 

only rather than a file, merge messages in message files, or any CASE 

related characteristics. Implementer considers these characteristics when 

processing the object code. 

For IFS files, specify PCFILE. For IFS directories, specify PCDIR.



Object authority Specify whether to keep object authority of existing object or assign 

based on the target environment definition. 

Object Codes 

*KEEP: Retains authority of the object in the target environment. If the 

object does not exist in the target environment, then *GRANT is 

assigned. This is the default value. 

*GRANT: Grants authority to the object based on the target 

environment. Assigns the object owner as defined in the Obj Owner 

field on the Change Environment panel. Assigns object authorities 

based on the list of authorities on the Work with Environments - Object 

Authorities panel. Ignores existing authorities if object exists in the 

target environment library. 

Remove obj in from env Specify whether to delete objects of this type in the From environment 

after successful promotion. a 

Remove src in from env Specify whether to delete the source for objects of this type in the From 

environment after successful promotion. a 

Creation process Specify when to issue the creation command: 

C=Compile: Creation command runs during the Compile Requests 

function. Most object codes delivered with Implementer have this 

creation process. 

Use this for: objects requiring compilation, duplicating or moving 

objects into production, creating a new object, replacing an existing 

object. Implementer places the object/source member into a work 

library before the move. Move Requests function replaces the existing 

object and/or source member. During the move, Implementer executes 

the commands required to move the object or source member into the 

environment library. This is the default value. 

M=Move: Creation command runs during the Move Requests function. 

Use this only to copy source members and execute commands that 

directly change production database files, such as conversion 

programs or copying data. During the compile step, Implementer does 

not perform any action on items with this object code. Use this process 

only for object codes that leave the existing object and/or source 

member in place and simply change or affect the object or member, for 

example, object codes CHGPGM or CHGPRTF, or CPYF command 

when promoting data in a file. 

131


132 



Archive in MKS Source Specify whether to archive the source for this object code in MKS Source. 

Requires active integration between Implementer and MKS Source. By 

default, source-based object codes and those with a special 

characteristic of PCFILE are set for archiving in MKS Source. Non 

source-based object codes and those with a special characteristic of 

PCDIR are not eligible for archiving in MKS Source. 

Y=Yes: Archives source for the object code if the target environment is 

eligible. Valid only for source-based object codes and those with 

special characteristic PCFILE. This is the default value. 

N=No: Does not archive source for the object code. Required value for 

non source-based object codes and those with special characteristic 

PCDIR. 

For details, see “Implementer and MKS Source Integration” on page 259. 

Creation command Specify the OS/400 command required to create an object or perform the 

migration task for the object code. Implementer replaces any substitution 

variables (references to objects within the creation command) with the 

actual names and libraries associated with the implementation request. 

The valid substitution variables are as follows: 

#FILLIB: For creation process C, substitutes the temporary work library 

where the request’s files and program objects are moved or compiled 

into. For compile=Y requests, objects do not exist until successfully 

compiled. Changing the authorities of objects in this library does not 

affect the authority of the object in the target environment. For creation 

process M, substitutes the target library. 

#FRMLIB: For creation process C, substitutes the temporary work 

library where the request’s files and program objects are moved or 

compiled into. For compile=Y requests, the objects do not exist until 

successfully compiled. For creation process M, substitutes the work 

library created for the request. Changing authorities of objects in this 

library does not affect authority of objects in the target environment. 

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

promotion. 

#OBJNM9: Substitutes the current, short object name at the time of 

promotion. 

#PGMLIB: Same as #FRMLIB. 

#SRCFIL: Substitutes the source file name of the promoted item. For 

creation process C, it is the same as #WRKSRCFIL. For creation 

process M, it is the target source file. 

#SRCLIB: Substitutes the target source library of the promoted item. 

For creation process C, it is the work source library. For creation 

process M, it is the target source library. 

#SRCMBR: Substitutes the source member name of the promoted 

item. 

a The value specified here is only used as the default value when creating new environment object code 

overrides. You can override it at the environment level. Changing this value affects overrides created 

from this point forward, it does not affect existing overrides. For details, see “Removing Source and 

Objects After Promotion” on page 92.

Environment Overrides 

Object Codes 

This function allows you to work with specific object codes by environment. You can 

override the object library, source file, or source library for an environment, and activate or 

deactivate specific object codes. You can also override the default values that determine 

whether Implementer automatically deletes source and objects when promoting from the 

environment. 

To work with object code overrides for environments 

From Work with Object Codes, select an object code with option 7=Environment Overrides 

and press ENTER. The Work with Object Code/Environment panel displays. 

This panel is similar to the Change Environment Object Code Overrides panel you access 

from Work with Environments—the only difference is the data sort order. This view allows 

you to work with all environments for a specific object code. For information on defining this 

panel, or to view all object codes for a specific environment, see “Object Code Overrides” on 

page 91. 

Object Codes for Third Party Integrations 

Implementer supports integrations with a variety of other software vendors. For this 

purpose, Implementer reserves the following object code special characteristics: ADK for 

AS/SET definitions, LAN for LANSA objects, and JDE for PeopleSoft World soft coding 

items. 

133


134 

AS/SET Integration 

The following special characteristic codes are for managing AS/SET definitions. 

ADKDSP ADKMDL 

ADKDSP ADKFLD 

ADKHLP ADKFIL 

ADKBAT ADKAUD 

ADKRPT ADKSUB 

Create object codes that have special characteristics beginning with ADK as non source and 

non object based object codes. Create object codes using special characteristics beginning 

with ADK as non source and non object based object codes. For more information, see 

“AS/SET Integration” on page 316. 

PeopleSoft World Integration 

The following special characteristic codes are for managing PeopleSoft World applications. 

JDEUDE JDEDDC JDEWCS 

JDEUDS JDEVOV JDNSPC 

JDEDWR JDEMNU JDNPRTF 

JDEMBM JDEFST 

JDEWWR JDEPRO 

If you use Implementer to manage the PeopleSoft World User Defined Code, see the 

instructions for constructing the member/object name of this soft coding item in “PeopleSoft 

World Integration” on page 355. 

LANSA Integration 

The following special characteristic codes are used for managing LANSA objects. 

LANFLD LANXMLC 

LANFIL LANSVAR 

LANFLDT LANMVAR 

LANPROC LANWEBC 

LANFNC LANXMLC 

For more information, see “LANSA Integration” on page 328.

Object Codes for DDM Support 

Object Codes 

Implementer supports the management of Distributed Data Management (DDM) software. 

For this purpose, you must create three new object codes: DDMDTAA, DDMDTAQ, and 

following table. 

To create this object code ... copy this object code ... and specify this Object Attribute 

DDMDTAA DTAARA DDMDTAARA 

DDMDTAQ DTAQ DDMDTAQUE 

DDMF PF DDMF 

For more information on managing DDM software, see “Using Special Commands to 

Manage DDM Software” in the MKS Implementer 2006 User Guide. 

Object Codes for IFS Objects 

Implementer provides a variety of default object codes for managing IFS directories and files. 

When you need to use an object code that does not exist, you can create an IFS object code the 

same as a traditional object code in Work with Object Codes, or you can define Implementer 

to automatically create them when you check out or create a promotion request. The latter 

option requires activation in System Control Maintenance as described in “Allow IFS object 

code creation from Check Out and Create Rqs” on page 68. 

Object codes defined with a special characteristic of PCFILE display the PC file extension 

name in the Creation command field. When you display a PCFILE or PCDIR object code, the 

Creation command field name changes to IFS Object Extension. When you edit or copy an IFS 

object code the field name is Creation command. 

Due to the way that Implementer matches the object code for files with long extensions to the 

short form in the object code, MKS recommends you deactivate (rather than delete) obsolete 

object codes to ensure the retention of accurate history. 

NOTE Implementer supports Document Library Objects (DLO) within the IFS and 

automatically retains all DLO attributes and characteristics during promotion. 

However, because the Move Object (MOV) command used to move QDLS and IFS 

objects from the staging directory to the target directory does not support spanning 

ASPs, the promotion of QDLS and DLO objects must run in the system Auxiliary 

Store Pool (ASP) ASP1. 

To define object codes for IFS files and directories 

1 Access the Create Object Code panel as described in “Object Codes” on page 127. 

An example object code displays next. 

135


136 

2 Define the required fields as follows: 

In the Object code field, object codes for files must begin with a dot (.), and can 

have a trailing character string. An object code for a directory must have a unique 

object code that begins with a backward slash (\). If the directory name has an 

extension, define the object code with a backward slash followed by a dot and the 

extension, for example, the object code for directory DIR.ONE is \.ONE. 

In the Description field, type a description for the object code. 

In the Activity flag field, type 1 to activate the object code. Use option 2 to deactivate 

the object code. Object codes must be active to use them in Implementer. 

In the Creation sequence field, specify a number from 1–9999 to identify the order of 

creation for this type of object (does not have to be unique per object code). IFS 

object codes created by Implementer during check out or create request have 

creation sequence 8000. IFS files have creation sequence 8010. 

In the Special characteristics field, type PCFILE for a file or PCDIR for a directory. 

NOTE The Archive in MKS Source field defaults to Y for PCFILE or N for PCDIR. 

3 Press ENTER to save the changes. 

Object Codes for Setting a Data Area Value 

Implementer provides two object codes that allow you to populate a target data area value 

upon promotion of the data area to the target library.

Object Name Rules 

The object codes allow you to use a single request to promote to one or more libraries or 

systems and retain or replace specific data area values as needed. This is useful, for example, 

for a data area that controls the next order number when a new customer needs the data area 

value set to a newly distributed value, and an existing customer needs to retain the existing 

value. 

The object codes for setting a data area value are as follows: 

Use object code DTAARA to copy data in the From library to the target library. It has no 

special requirements. 

Use object code DTAARAR to retain the existing value of a data area in the target library. 

It has an the object type *DTAARA and the special characteristic *DTA. The special 

characteristic is significant—it controls whether the existing data area value is retained. 

You must define the DTAARAR object code with the *DTA special characteristic to 

function as described. 


Why are object codes necessary? Can’t objects just be compiled into production libraries? 

Object codes allow you to consistently and accurately control how Implementer creates 

objects and updates your production libraries. 

Is the creation sequence critical? 

Yes. The creation sequence determines the compilation order. For example, the PF object code 

should have a lower sequence than the LF object code to allow compiling the physical file 

before the logical file. 


Implementer supports the use of rules to control the naming construct of new member/ 

objects. This allows an administrator to enforce a standard set of naming rules that 

developers must follow when creating member/objects in check out. 

Object name rules allow for flexibility in member/object naming, and provide for multiple 

true conditions using standard Boolean logic. This feature also supports the ability to call 

user exit programs. 

Name validation is performed on an environment and object code basis, where each 

positional group of the object name validates to a position and sequence in the rules 

database. If more than one rule exists for a specific position, each rule must have a unique 

sequence number. Any additional rules defined after the first rule for a specific position must 

specify *AND or *OR to indicate a complex condition. 

137


138 

When you check out a member/object with Action 2=Create, the rules are validated and 

enforced. Rule validation occurs in the following order: 

1 If the specific object code is not found, then the global object code *ALL is used. 

2 If the specific environment is not found, then the global environment *ALL is used. 

3 If the object code and environment are not found, then the global rule *ALL/*ALL is 

used. 

4 If no rules are found, then name validation is bypassed. 

If the member/object name breaches the rule, the check out is not allowed and a message 

confirms the environment, object code, position, length, and rule used. Additional message 

information is available for problem resolution. After correcting any errors, continue with the 

check out. 

You create and maintain name rules in the Work with Object Name Rules panel. You have 

three options for accessing this panel based on how you implement name rules as follows: 

specific object codes for specific environments 

all object codes for a specific environment 

specific object codes for all environments 

When maintaining a rule set on the Work with Object Name Rules panel, each current rule is 

graphically represented by a value in the Mask field. This represents which rule applies to 

each position of the object name. 

CAUTION Due to the inherent flexibility within the name rule structure, it is possible 

to define a rule that blocks compliance and thereby causes unpredictable results. Be 

sure to test all rules before using in production. 

Option 1: Specific Object Code for Specific Environment 

This option allows you to define name rules that enforce validation of a specific object code 

for a specific environment. 

To work with name rules for a specific object code and environment 

1 From the Implementer Menu, select option 42 to access Work with Environments. 

2 Select an environment with option 2=Change and press ENTER. 

3 Press F8=Object Codes.


4 Select an object code with option 7=Work with Object Name Rules, and press ENTER. The 

Work with Object Name Rules panel displays. 

Use option 2 to edit an existing rule. 

Use option 3 to copy a rule. 

Use option 4 to delete a rule. 

Use option 5 to view rule details. 

The Environment, Object Code, and Mask fields display in the upper-left section of the 

panel. The mask defines which rules apply to each section of the object name. Creating a 

name rule automatically creates a mask. The mask is defined in lower-case letters. Each 

letter within the mask name corresponds to a set of rules based on position as follows: 

If more than one rule exists for a specific position, each rule must have a unique 

sequence number. 

Any rules after the first rule for a position must have *AND or *OR specified in the 

And/Or field to indicate a Boolean condition. 

Overlapping rules is not allowed. Overlapping a new rule with an existing rule 

(based on position and length) causes an error message. 

Each time you modify a rule, the Mask field updates to reflect the fields added or 

removed from the rule set. 

Deleting the first rule for a position (And/Or = BLANK) deletes all rules for that 

position. Deleting any other rule (And/Or < > BLANK) only deletes that rule. If the 

Comparison field value is *CALL, the program calls your external user exit program 

with the required parameters. 

139


140 

To add an object name rule 

1 Press F6=Add to display the Add Obj Name Rule window. 

2 Complete the fields as described in the following table and press ENTER. The Object 

Name Rules panel displays. 


Add Object Name Rules Field Descriptions 

Position Specify the starting position of the object name portion to validate. Valid values 

are 1–10 (standard OS/400 object length). 

Length Specify the length of the object name portion to validate. Valid values are 1–10 

(standard OS/400 object length). The length cannot overlap an existing rule. 

Sequence Specify the sequential order to process the name rules. Valid values are 1–999. 

And/Or (Optional) Specify a logical operator between two expressions. Valid values are 

BLANK in the first rule for a position, and *AND or *OR in subsequent rules. 

Comparison Specify a logical operator that compares a portion of the object name to the value 

specified in the Value field. Valid values are *EQ, *NE, *LT, *LE, *GT, *GE, or 

*CALL (user exit program). 

For *CALL, the Comparison field user exit program parameters to define are: 

Environment: (10,a) 

Object Code: (7,a) 

Name Section: (10,a) The contents of the object name (starting position for the 

specified length). 

Return Code: (1,a) Set the return code in the user program to 1 for a valid 

object name or 0 for an invalid object name. If the program ends in error, 

Implementer assumes the value is invalid.


Add Object Name Rules Field Descriptions 

Option 2: All Object Codes for a Specific Environment 


Value Specify a value to compare to the logical operator defined in the Comparison 

field. Valid values are a constant value (no quotes), a special value (see special 

values listed next), or a user exit program (see user exit program parameters 

listed for Comparison). The special values valid for the comparison values *EQ 

and *NE are: 

*NUM: Generic numeric value. 

*ALPHA: Generic alphanumeric value. 

*BLANK: Generic blank value. 

Deleting the first rule for a position (And/Or = BLANK) deletes all rules for that 

position. Deleting any other rule And/Or < > BLANK) deletes only that rule. If the 

Comparison field value is *CALL, the program calls your external user exit 

program with the required parameters. 

This option allows you to define name rules that enforce validation for all active object codes 

for a specific environment. 

To work with name rules for all object codes for a specific environment 

1 From the Implementer Menu, type 42 and press ENTER to access Work with 

Environments. 

2 Select an environment with option 2=Change, and press ENTER. The Change 

Environment panel displays. 

3 Press F18=Name Rules. The Work with Object Name Rules panel displays. The Object 

Code field displays the default value *ALL, indicating all object codes specific to this 

environment. 

4 Press F6=Add. The Add Object Name Rule window displays. 

5 Complete the fields as described in “Add Object Name Rules Field Descriptions” on 

page 140. 

6 Press ENTER. The Object Name Rules panel displays. 

Option 3: Specific Object Code for All Environments 

This option allows you to define name rules that enforce validation of a specific object code 

active to all environments. 

141


142 

To work with name rules for a specific object code for all environments 

1 From the Implementer Menu, type 44 and press ENTER to access Work with Object 

Codes. 

2 Select an object code with option 2=Change, and press ENTER. 

3 Press F18=Name Rules. The Work with Object Name Rules panel displays. The 

Environment field displays the default value *ALL, indicating specific object codes for all 

environments. 

4 Press F6=Add. The Add Object Name Rules window displays. 

5 Complete the fields as described in “Add Object Name Rules Field Descriptions” on 

page 140. 

6 Press ENTER. The Object Name Rules panel displays. 

Project-based Application Paths 

Implementer uses application paths in the development cycle to define the flow of members/ 

objects between environments. Implementer also uses application paths 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. 

The application path provides control by restricting access so members/objects cannot move 

outside of the defined flow. It also allows defaulting the From environment and target 

environment values when checking out and creating a promotion request. 

You can define an application path at the environment level or project level. Each path can 

have a standard and an emergency path that a member/object follows from the time it is 

checked out to the time it is promoted back into production. 

Functionally, environment paths and project paths are identical, but certain business 

situations make it more practical to use a project path. For example, two active projects in 

development typically use different environment paths. By using a project path instead of an 

environment path, you can avoid performing excessive overrides when checking out and 

promoting items associated with one project that are not associated with the other project. 

Project paths are beneficial when your development model consists of multiple test 

environments, particularly when the test environments are determined on a project-byproject 

basis. 


In check out and create request a project path overrides an environment path. In other 

words, if a project with a defined path is specified, the project path is followed; 

otherwise, the environment path is followed. For details, see page 101.

Project-based Application Paths 

You can specify an environment group on a project path. For details, see “Environment 

Groups” on page 125. 

You must define the project path to the project before using it in Implementer. 

You cannot delete an environment that is defined on a project path. 

When copying or deleting a project also copies or deletes the related path records. 

For customers using the Implementer and MKS Source integration, project paths are not 

available when using the Export to Implementer (ISIEXPORT) command. For details, see 


A user must have authority to override both standard and emergency paths to override a 

default project path when performing standard and emergency functions. These 

authorities are defined in Work with Users. 

The administrator usually performs this task. Adding or changing a project path 

requires authority to project maintenance and authority to host environment 

maintenance. 

To define a standard or emergency path for a project 

1 From the Implementer Menu, type option 15, Work with Projects, and press ENTER. 

The Work with Projects panel displays. 

2 Type option 17=Standard Path, or option 18=Emergency Path next to the project and 

press ENTER. The Environment Path panel displays. 

3 To add a new path entry, press F6=Add. The Add Path Entry panel displays. The Project 

field displays the name of the project you selected on the previous panel. 

143


144 

4 Complete this panel as follows: 

In the Sequence number field, specify a the number that represents the sequence 

order in relation to the other entries on the default project path. Create sequences 

with sufficient numeric space in between to allow adding future sequences without 

having to alter each sequence on the path, for example, use sequence 10, 20, and 30. 

In the Entry field, specify the name or parameter of the library or environment. 

*USRPRF: Entry defaults from the user profile for both check out environment 

or library, and target environment or target environment group. 

Development library: Specify the name of the development library. This is the 

target library in check out. 

Environment: Specify the name of the *PRD, *TST, or *QAC environment. Can 

be the From or target environment in check out or create request. Use F4=List to 

select from the Select Environment list. 

Environment group: Specify the name of the environment group. This is the 

target environment group when creating a request. 

The Entry type field, is a display-only field that automatically defaults after you 

create the sequence. 

Lib is a development library. 

*PRD is a production environment or primary environment of a target 

environment group. 

*TST is a development environment. 

*QAC is a quality assurance or test environment. 

5 When finished, press ENTER to add the record. The panel remains open for the entry of 

additional records. Press F12 to return to the Standard Project Path panel with the new 

path records listed in sequential order. 

User-Defined PDM Options 

Implementer allows you to create IBM Programming Development Manager (PDM) options 

to perform check out and create promotion request functions directly from within PDM. 

You typically perform this task once to set up the user-defined options, although you can 

perform the function any time thereafter as it does not have the interdependencies that some 

of the other setup tasks have.

To view sample PDM options 

1 From the PDM Work with Members panel, press F18=Change defaults. 

Issue or Design Request Stamping 

To view the example PDM options, set the Option file on the Change Defaults panel as 

follows: 

Option File IMPDMOPT 

Library MKSIM 

Member IMPDMOPT 


3 Press F16=User options to view the Implementer options interface. 

Sample PDM options for the check out and create request functions are included. The 

default option names are CO (check out) and CR (create request). You can name the 

user-defined options as needed when adding them directly to your PDM options file. 

These options use the ICHKOUT and ICRTRQS commands respectively. 

TIP Many customers use the CO option to check out individual members in PDM, 

but use the Create Request menu option because it is easier to select objects. 


Can you copy PDM options from IMOPT directly into a PDM options file with the Copy File (CPYF) 

command? 

No. PDM does not properly order your options in the options file when you do this. You 

must manually add them into your standard PDM options file. 

Issue or Design Request Stamping 

Implementer allows you to stamp objects with the issue or design request number the object 

was checked out for. This provides an audit trail that ties each object change back to the issue 

or DR that requested the change. With similar information available in the corresponding 

issue or DR, you have a complete circle of cross-references and auditable information for 

every software change. 

To ensure the stamping of both new and existing objects, the process automatically occurs in 

the three functions that support object creation: check out, compiling from the Workbench, 

and promotion. During these development stages, Implementer updates the description of 

the object by recording the issue or DR number in the PTF Number attribute. If multiple locks 

exist with multiple issues or DRs, the object is stamped with the primary number associated 

with the initial lock. For inquiry, use the Display Object Description (DSPOBJD) command to 

view the PTF Number attribute. 

145


146 

For information on using object version stamping in check out and promotion, see the 


NOTE Due to IFS constraints, Implementer does not support stamping issue or DR 

numbers directly to IFS objects. However, for inquiry and reporting through 

Implementer, the information is available in the repository. 

To set up issue or DR object stamping 

1 From the Implementer Menu, type option 45, System Control, and press ENTER. The 

System Control Maintenance panel displays. 

2 Press PAGE DOWN three times. 

3 In the Activate issue object stamping field, specify Y to activate this feature. For more 

information on this field, see “Activate object version stamping” on page 70. 

4 Press ENTER to process the change. 


Implementer allows you to stamp objects, lock records, and repository records with a version 

number at pre-determined stages within the development cycle. This provides an audit trail 

that allows you to track every version of an object. It also allows you to identify specific 

information about deployed objects under change control. 

The version number scheme and development stage the object is stamped in, either 

check out, check out and promotion, or user-defined, is determined by the versioning method 

you define in System Control. Implementer automatically increments the version number 

based on the versioning method you specify. During the applicable development stage, 

Implementer updates the description of the object by recording the new revision number in 

the APAR ID attribute. The repository record is updated when you run the build list as 

described in the next section. 

During the build list for a *PRD environment, Implementer stamps the version number to the 

repository record for each object in the production environment (repository records for *TST 

and *QAC environments have a blank version number) as follows: 

If the object has a valid version number, then Implementer assigns that version to the 

repository record. For details, see “Environment Repository Build” on page 117. 

If the object does not have a version or has an invalid version, then Implementer assigns 

the version number 1 or 1.0 (based on the defined versioning method) to the repository 

record. If a user-defined versioning method is specified, a user exit is allowed for you to 

set the version number.


For inquiry, use the Display Object Description (DSPOBJD) command to view the APAR ID 

attribute. In addition, you can display an object’s revision number in the Revision field on the 

Workbench (F11=Display Revision) and Work with Objects (F10=Display Revision) panels. 

NOTE 

Due to IFS constraints, Implementer cannot stamp version numbers directly to 

IFS objects. However, for inquiry and reporting through Implementer, the 

information is available in the repository. 

Implementer disregards source-only objects during version number processing. 

The build does not stamp actual objects—only development activity does this. 

To set up object version stamping 

Versioning Methods 

1 From the Implementer Menu, type option 45, System Control, and press ENTER. The 

System Control Maintenance panel displays. 

2 Press PAGE DOWN three times. 

3 In the Activate object version stamping field, type Y to activate the feature. For more 

information on this field, “Activate object version stamping” on page 70. 

4 In the Assign native version number at field, specify the versioning method as follows: 

1 = checkout only. For details on this method, see “Method 1: Assign Version in 

Check Out” on page 148. 

2 = checkout and promotion to production environments. For details on this 

method, see “Method 2: Assign Version in Check Out and Promotion” on page 148. 

3 = user defined. For details on this method, see “Method 3: User-Defined Version” 

on page 149. 

5 Press ENTER to process the change. 

Implementer supports three native versioning methods. The first two methods are defined in 

Implementer; the third method allows you to implement your own user-defined routine. 

NOTE If you have MKS Source integration enabled, then the native revision number 

scheme applies only to objects and items not archived in MKS Source. The version 

number is assigned during promotion to the first *QAC environment enabled for 

MKS Source archiving. If MKS Source integration is not enabled, then the native 

revision number scheme applies to all items. 

147


148 

Method 1: Assign Version in Check Out 

This method implements a whole numbering scheme (no decimal), for example: 

Version 1 

Version 2 

Version 3 

Version 4 

With this method, Implementer assigns the version number when an object is checked out for 

create or change, and when rejected from a *QAC environment. Each time the object is 

checked out, the number increments by one. 

Scenario Example 

Object A in *PRD environment is version 2. Object A is checked out to *TST 

environment. Object A in *PRD is still version 2. Object A in *TST is now version 3. 

Object A version 3 is promoted to *QAC environment. 

Object A is concurrently checked out to *TST environment, making it version 4. Object A 

in *PRD is still version 2. Object A in *QAC is still version 3. 

Object A version 4 is promoted to *QAC environment. Object A now has two lock 

records in the *QAC environment—one is version 3, and the other is version 4. 

Object A version 4 in *QAC is promoted to *PRD. Object A in *PRD environment is now 

version 4. 

Method 2: Assign Version in Check Out and Promotion 

This method implements a decimal numbering scheme with numbers left and right of the 

decimal, for example: 

Version 2.0 

Version 2.1 

Version 2.2 

Version 3.0 

With this method, Implementer assigns the version number when an object is checked out for 

create or change, when promoted to production environments, and when rejected from a 

*QAC environment. When the object is checked out (including concurrent check out) the


number to the right of the decimal increments by one. When promoted to production, the 

number to the left of the decimal increments by one and the number to the right of the 

decimal resets to zero. 

NOTE Promoting without locks causes the version number to increment only when 

the object is promoted to a *PRD environment. 

Scenario Example 

Object A in *PRD environment is version 2.0. Object A is checked out to *TST 

environment. Object A in *PRD is still 2.0. Object A in *TST is version 2.1. 

Object A version 2.1 is promoted to *QAC environment. 

Object A is concurrently checked out to *TST environment, making it version 2.2. 

Object A in *PRD is still version 2.0. Object A in *QAC is still version 2.1. 

Object A version 2.2 is promoted to *QAC environment. Object A now has two lock 

records in the *QAC environment—one is version 2.1 and the other is version 2.2. 

Object A version 2.2 in *QAC is promoted to *PRD. Object A in *PRD environment is 

now version 3.0. 

Method 3: User-Defined Version 

You can define a program with a versioning scheme of up to 30 characters, which is the 

length of the Revision field that displays on various panels in Implementer. However, 

because the field updated in the actual object description is only seven characters long, only 

the first seven characters of the version number are recorded in the object’s description. Thus, 

to update the object description parameter on the actual object, define your program with a 

number scheme of seven characters or less. To apply object versioning without actual object 

stamping, the versioning scheme can be up to 30 characters. 

The versioning program must exist in the same library on all host and remote systems. If the 

program references objects, for example, files or data areas, the library containing the objects 

must be in the user’s interactive library list and in the library list of the Implementer job 

description MWIJOBD. 

Define your versioning program with an entry parameter group as described next. 

Parameter Length Description 

Description 512, alpha Data passed into the versioning program. See format 

requirements in the next table. 

Version Number 30, alpha Parameter the version number is returned in. 

Return Value 10, alpha Returns blanks if no errors occur. If a value is returned, the 

version number is ignored. 

149


150 

where the format of the Description parameter is as follows: 

Description Parameter 

Field Format 

The following tables describe the events that trigger the user-defined object versioning 

program and the parameter values passed at each trigger point. 

Trigger Point: Build List 

Triggers when the Build List is run for a *PRD environment. 

passed version number = *Blanks 

values for P@Data 

Valid Values 

Start 

Position 

From Environment environment name 1 10 

To Environment environment name 11 20 

From Environment Type *PRD, *QAC, or *TST 21 24 

To Environment Type *PRD, *QAC, or *TST 25 28 

Object object name 29 38 

Object Code environment name 39 45 

Function see Trigger Points listed next 46 55 

Action 1=Change, 2=Create, or 3=Recompile 56 56 

PRD Environment production environment name 57 66 

PRD Library production library name 67 76 

Description Parameter Field Parameter Value Passed 

From Environment *Blank 

To Environment Build List environment name 

From Environment Type *Blank 

To Environment Type *PRD 

Object Object name 

Object Code Object code 

Function '*BUILD' 

Action *Blank 

PRD Environment Build List environment name 

PRD Library Build List environment object library 

End 

Position

Trigger Point: Check Out 


Triggers when loading the subfile for the Check Out panel, loading the Check Out panel, and 

calling to retrieve the next valid version number. Program called any time ENTER or 

F9=Accept is pressed. 

passed version number = Subfile value 



From Environment Check out FROM environment 

To Environment Check out TO environment 

From Environment Type FROM environment type 

To Environment Type TO environment type 



Function '*CO-RTV' 

Action Value of Action field in the subfile 

PRD Environment *PRD environment of FROM environment 

PRD Library *Blanks 

Trigger Point: Check Out 

Triggers when you enter the value for revision number. Program called to validate the 

specified version number. 

version number = Subfile value 



From Environment Check out FROM environment 

To Environment Check out TO environment 

From Environment Type FROM environment type 

To Environment Type TO environment type 



Function '*CO-VLD' 

Action Value of the Action field in subfile 

151


152 




Trigger Point: ICHKOUT and ICHKOUTIFS Commands 

Triggers when using the ICHKOUT and ICHKOUTIFS commands. Program called once to 

verify if object version stamping is active and to retrieve the next valid version number. 




From Environment From environment 

To Environment To environment 

From Environment Type From environment type 

To Environment Type To environment type 

Object Member/Object name 


Function '*CO-RTV' 




Trigger Point: Create Request and ICRTRQS Command 

Triggers in create request and when using the ICRTRQS command. Program called once to 

verify if object version stamping is active and to retrieve the next valid version number. 




From Environment From environment 

To Environment To environment 

From Environment Type From environment type 

To Environment Type To environment type 

Object Member/Object name



Function '*PROMOTE' 


Considerations With OS/400 and Implementer 

Considerations With OS/400 and Implementer 



This section covers iSeries system information as it relates to Implementer and Implementer 

Receiver. 

Operating System Upgrades 

The following considerations apply to installing a new release of the OS/400 operating 

system. No special considerations are required for PTF installation. 

Before you upgrade to a new release of the operating system, contact your distributor or 

MKS Customer Care to determine any impact the new release may have on your version 

of Implementer. At publication of this guide, Implementer required no changes for 

compatibility with the versions of OS/400 currently supported. 

If you use Implementer Receiver to distribute changes to a remote system, you may have 

changed communication entries when you initially installed Implementer. After the 

operating system upgrade, you must verify and reapply the changes as needed—this 

step is frequently overlooked. 

By default, an OS/400 upgrade does not retain the Implementer communication entry 

because the default communications subsystem QCMN is in library QSYS, and the 

objects in library QSYS are replaced during the operating system upgrade/installation. 

Before the upgrade, you can move subsystem QCMN to another library such as QGPL, 

or after installing the new release, you must reapply the communications entry to the 

QCMN subsystem. 

If you upgrade the host system to a release level later than the release level of the remote 

system, verify Implementer is set up to distribute using the previous release support 

feature of OS/400. To do this, in Implementer’s Network Configuration, change the 

target release to the version of the operating system on the remote system. To determine 

the previous versions the host OS/400 version allows, verify the allowed values for the 

Target Release (TGTRLS) parameter on the Restore Library (RSTLIB) command. 

153


Changing the System Name 

154 

The name of the host system is stored in the Implementer database. If you change the OS/400 

system name, for example, to use a descriptive name other than that delivered with the 

system, you must make the corresponding change in Implementer. 

To change the host system name, use Implementer Menu option 46, Network 

Configuration, which lists the host system and each remote system for distribution. Add 

the new system and specify the new OS/400 system name (use the OS/400 Display 

Network Attributes (DSPNETA) command to verify). Delete the obsolete system name. 

For details, see “Network Configuration” on page 167. 

In Work with Environments, you must also change each environment defined as a local 

environment to reflect the new host system name. For details, see “Environments” on 

page 81. 

NOTE The system name Implementer uses for the remote system is the OS/400 

remote location name, not the remote system name. Thus, changing the OS/400 

system name of the remote system does not require a change to Implementer. 

System Library List Requirements 

Do not place the Implementer product library (MKSIM is the default library name) or the 

Implementer Receiver library (MKSIR is the default library name) on the system library 

list. Implementer does not work correctly if these libraries are on the system library list. 

For C ‘#include’ members and externally defined files, you must manually maintain the 

Implementer database file IMSYSLIB. The file consists of one field for library entries. 

You must specify any system libraries that contain header file ‘#include’ members that 

are used for C development. When ‘#include’ statements are found in a C source 

member, Implementer determines if the ‘#include’ member exists in this list of system 

libraries in IMSYSLIB. If the ‘#include’ member is located in the header file in any of the 

system libraries specified in this file, the ‘#include’ member is not handled as a related 

object within Implementer. 

Independent Auxiliary Storage Pools 

Implementer supports using Independent Auxiliary Storage Pools (IASPs) to manage objects. 

An IASP is a DASD grouping mechanism similar to a normal ASP in that it defines an 

individual storage device, but unlike a normal ASP, an IASP can be activated and deactivated 

on demand. An IASP can also be shared between multiple systems and logical partitions 

(LPARs) through high speed networking, allowing DASD utilization on a single system or 

shared between multiple systems.

Web-based Development for IFS Objects 

When used on a single system, the storage defined by the IASP can be activated and 

deactivated within a job; however, only one primary ASP can be active at a time. If a job 

switches from one IASP to another, the libraries that reside in the first IASP are no longer 

available. When used on multiple systems, the storage defined by the IASP can be accessed 

by all systems simultaneously, as if it was local. 

Implementer moves objects between IASPs similar to how it moves objects between standard 

ASPs. Although IASPs support multiple libraries with the same name in different IASPs, 

Implementer associates a named ASP device with the environment. 


This feature requires OS/400 V5R2 or later. 

Implementer on the host system and Implementer Receiver on a remote system must be 

in a normal system ASP, for example, ASP 1–32), to ensure each is available regardless of 

which IASP is active. 

The IASP that Implementer moves objects to or from must be active when each process 

starts. Use the VRYCFG command to start or end an IASP. Implementer does not 

manage, start, or end IASPs. 

When moving objects, all activity occurs to and from a single IASP. Implementer does 

not support moving objects from one IASP to another IASP. 

Before checking out or promoting to or from an IASP environment, you must issue the 

Set ASP Group (SETASPGRP) command. If your shop is already working with IASPs, 

this is likely already configured, for example, as part of the daily system startup routine 

or handled through a job scheduler (the administrator can confirm this). 

The SETASPGRP command syntax is as follows: 

SETASPGRP ASPGRP(xxxxxxx) 

Where xxxxxxx is the name of the ASP group. 


Implementer allows you to efficiently manage the software changes of all objects that reside 

on the iSeries system. This includes support for the development of your client/server and 

e-Business applications, as well as the check out and promotion deployment of IFS objects 

using a Web browser interface. 

This browser-based integration is built on the existing proven framework of Implementer 

technology and includes the latest support for IBM HTTP Web servers: the original Web 

Server for iSeries and the Apache Web Server for iSeries. It also supports using MKS Integrity 

issues or DesignTracker DRs when performing the change management functions. 

155


Requirements 

156 

The requirements for using Web-based development are as follows: 

Implementer 2006. 

The *PRD, *TST, and *QAC environments that manage IFS development must be 

defined in Implementer with the IFS directory path, path owner, and IFS object owner. 

In addition, the *PRD environment must have a standard application path. For details on 

environment setup, see page 81. 

Internet Explorer 4.0 or later, or Netscape 4.5 or later. 

Using the original Web Server for iSeries requires OS/400 V5R1 or later. 

Using the Apache Web Server for iSeries requires: 

O/S 400 V5R1 or later. 

Knowledge of the Apache Web Server for iSeries configuration and operations. 

Access to the httpd.conf configuration file for the Apache Web Server instance to 

configure. 

iSeries Web Server Setup 

The Implementer Web interface supports using either of the IBM HTTP Web servers: the 

original Web Server for iSeries or the Apache Web Server for iSeries. You must configure the 

Web interface to use one of these servers. If using the Apache Web Server for iSeries, see 

page 158 for further instructions. 

Original Web Server for iSeries Setup 

The OS/400 HTTP configuration file defines what a Web browser is able to access on your 

iSeries using the original Web Server for iSeries. The system administrator or a user that is 

authorized to and familiar with the following functions must modify the TCP/IP HTTP 

configuration file as follows: 

Define server-based security protection based on the OS/400 user profile and password. 

Enable three method directives. 

Define mapping directives for the location of the Implementer interface programs. 

Stop and restart the HTTP Server. 

IMPORTANT Only one server at a time can be listening on a specified port. You can 

simultaneously run more servers on a single system, but each server must listen on a 

unique port.

To access the HTTP configuration file 


Issue the Work with HTTP Configuration (WRKHTTPCFG) command as follows. You must 

have authority to the command to edit the file. 

WRKHTTPCFG CONFIG 

To implement server-based security protection 

Within the HTTP Configuration file, add the following server protection directives. MKS 

recommends you add the server directive entries near the beginning of the file. 

#Protect the Web interface program 

Protection IM { 

PasswdFile %%SYSTEM%% 

ACLOverride Off 

Mask All@* 

AuthType Basic 

ServerID Implementer 

UserID %%SERVER%% 

} 

Protect /cgi-bin/imweb IM 

To enable the method directives 

Within the configuration file, enable the GET, HEAD, and POST method directives as follows: 

# ***METHOD DIRECTIVES*** 

Enable GET 

Enable HEAD 

Enable POST 

To define the mapping directives 

The browser integration requires an entry in the configuration file to establish the directory 

location of your Implementer interface programs. If you installed the HTTP Server when you 

installed the iSeries system, IBM supplied a default and a sample HTTP configuration file 

already configured and enabled. In this case, you may need to change the default settings 

rather than add new ones. 

The default location is the Implementer product library MKSIM. Specify MKSIM unless the 

library name was changed when Implementer was installed. 

Add the following mapping directive to the configuration file: 

# ***MAPPING DIRECTIVES*** 

Exec/cgi-bin/* /QSYS.LIB/MKSIM.LIB/*.PGM %%EBCDIC%% 

157


158 

To stop and restart the TCP/IP server 

To display your page through the Web browser, the TCP/IP HTTP server must be active. 

You must stop and restart the server for it to recognize the Implementer CGI programs. 

1 Issue the End TCP/IP Server (ENDTCPSVR) command and change the parameters as 

required for your configuration. 

2 Once the server job ends, issue the Start TCP/IP Server (STRTCPSVR) command and 

change the parameters as required for your configuration. 

3 To verify the server is active, use the Work with Active Jobs (WRKACTJOB) command 

and press PAGE DOWN to access the QHTTPSVR Server subsystem job. 

There should be multiple instances of the server job running under user profile 

QTMHHTTP. The first instance is a batch job. The remaining instances are the batch 

immediate (BCI) jobs. 

The number of active jobs depends upon the HTTP attributes, a value set by the Change 

HTTP Attributes (CHGHTTPA) command. 

TIP You can automate this process by adding the job to an existing OS/400 start up 

routine, or by changing the HTTP attributes to start the server automatically. 

You can now use the Web interface for IFS development. For details, see the MKS Implementer 

2006 User Guide. The next section describes setting up the Apache Web Server configuration. 

Apache Web Server for iSeries Setup 

The httpd.conf configuration file defines what a Web browser is able to access on your 

iSeries using the Apache Web Server for iSeries. 

The system administrator or a user that is authorized to and familiar with the server’s 

configuration and operations must use the Edit File (EDTF) command to modify the 

httpd.conf configuration file for the Apache Web Server instance to be configured. 

NOTE For details on the Apache Web Server, refer to the IBM documentation 

located at http://httpd.apache.org/docs-2.0/. 

To edit the configuration file 

1 Issue the following command to access the configuration file: 

EDTF STMF(’/www/apachedft/conf/httpd.conf’) 

IMPORTANT If you are not using the default Apache Web Server configuration file, 

replace the STMF parameter with the appropriate configuration file name.

Mounted Drive Support for IFS Objects 

2 Add the following directives to the httpd.conf file in the main Web site or virtual host. 

TIP Use the cut-and-paste function to your 5250 emulation program instead of 

typing the following values. 

ScriptAlias /cgi-bin/imweb /qsys.lib/mksim.lib/imweb.pgm 

 

Options +ExecCGI 

CGIConvMode %%EBCDIC/MIXED%% 

AllowOverride None 

AuthType Basic 

ProfileToken off 

AuthName Implementer 

order allow,deny 

allow from all 

require valid-user 

UserID %%SERVER%% 

PasswdFile %%SYSTEM%% 

 

NOTE If the Implementer product is installed into a library other than MKSIM, 

replace MKSIM with that library name when defining this directive. 

3 Press F3=Save/Exit twice to save the file and return to the command line. 

4 Restart the server instance. 

The server must be active to display your page through the Web browser. You must stop 

and restart the server for it to recognize the new configuration directives. For details on 

this task, see page 158. 

Mounted Drive Support for IFS Objects 

Implementer provides mounted drive support for managing IFS objects on a system running 

Windows NT Server. 


Environments associated with an NT Server mounted drive must have a directory path 

entry that begins with \QNTC, for example, \QNTC\MKS\PRD\ACCOUNTS_PAYABLE. For 

details on defining the directory path, see “Directory Setup Field Descriptions” on 

page 94. 

To access an NT drive from the iSeries (for example, using WRKLNK) the user profile 

used to sign on to the iSeries must exist on the NT Server with the same password. 

159


160 

Implementer uses the profile defined in the SDMAUTUSR data area to access the 

NT Server. The default user profile name in the data area is SDMAUTUSR. The data area 

is located in the Implementer product library (MKSIM is the default library name). 

The user profile and password defined on the iSeries must be the same profile and 

password defined on the NT Server. The user profile and password combination must 

be identical to any remote systems that use directories on the mounted NT Server. 

Individual profiles are not required on the NT Server for those profiles to access 

Implementer and manage directories on the NT Server. 

Implementer user profile SDMAUTUSR is the object owner of IFS objects it promotes to 

the NT Server. In addition, the objects inherit the authorities of the target directory 

(authorities defined to the environment or existing on the from object are disregarded). 

NOTE The Reset Authorities function does not set or change object owners or change 

authorities of IFS objects. 

Establishing the Communication 

NetServer requires a security officer profile to connect to the iSeries. The minimum 

requirement is *IOSYSCFG authority to start NetServer. 

To establish communications 

1 On a PC connected to the host iSeries, select Start > Programs > IBM AS400 Client Access 

> AS400 Operations Navigator. 

2 In the Primary Environments list, double click the system where Implementer is installed. 

3 Double click the Network icon. 

4 Double click the Servers icon. 

5 Double click the TCP/IP icon. 

6 Verify the NetServer status is Started. If NetServer is not started, right click NetServer, 

and from the menu click Start.

C HAPTER FOUR 

Remote Distribution Concepts 

and Setup 

Configuring Implementer for Remote Deployment 

4 

The distribution features of Implementer allow you to deploy changes from one iSeries system to 

other iSeries systems, as well as to logical partitions (LPARs). 

A variety of options are available to control how to perform distribution. This chapter introduces you 

to the Implementer Receiver on a remote system, distribution methods and concepts, setting up 

communications for distribution, and submitting distribution jobs. 


“Implementer Receiver” on page 162 

“Distribution Methods” on page 164 

“Communications Considerations” on page 165 

“Network Configuration” on page 167 

“Setting Up Communications Entries” on page 169 

“Setting Up for TCP/IP Distribution” on page 173 

“Setting Up for SNADS Distribution” on page 179 

“Distribution Options” on page 180 

“Controlling Remote Job Schedules” on page 181 

“Distribution Steps” on page 189 

“Move Steps” on page 189 

“Multiple System Development” on page 189 

“Saving and Restoring Remote Tape Archives” on page 192 

“Problem Determination” on page 193 

161

Chapter 4: Remote Distribution Concepts and Setup 

Implementer Receiver 

162 

Implementer Receiver is a separately licensed product that runs on a remote iSeries system 

and receives software changes from Implementer on the host iSeries system. The Receiver is a 

subset of the host Implementer product. A separate license agreement and license keys are 

required for each Implementer Receiver to receive changes distributed from the Implementer 

host system. 

Implementer contains all objects needed to distribute changes to remote systems and LPARs. 

The primary activities initiated on the host system are: compile, distribution, and move of a 

promotion request, deletion of a promotion request, and the Reset Authorities and Build List 

functions. The Implementer Receiver allows you to accomplish both host and remote 

initiated activities. 

The Implementer Receiver menu provides access to: 

Work with Remote Request panel to inquire, print, and move promotion requests, and 

view target environments, related requests, and special commands 

Restore Remote Request (IRSTRMTRQS) command to restore distributions from tape 

(also accessible from a command line) 

Move Remote Request (IMOVRMTRQS) command to complete a remote promotion by 

moving the items into target environments (also accessible from a command line) 

release management functions 

administrative functions 

Installation of the Implementer Receiver includes steps on both the host and remote systems. 

The default Implementer Receiver library name is MKSIR. If you change this name, you must 

also change the RCVLIB data area in the corresponding host system. If you install the 

Implementer Receiver into a library other than MKSIR, you must manually add that library 

name to the top of the library list for the IMPJOBD job description. Implementer uses the 

IMPJOBD job description when submitting a remote initiated move request. 

To activate the Implementer Receiver for temporary or permanent use, you must use the 

MKS Security Reset (RESET) command on the remote system to enter the license keys sent 

with your contract or in a separate letter. If you do not have valid license keys, contact MKS 

Customer Care. 

NOTE For detailed information on installing or upgrading the Implementer 

Receiver, see the MKS Implementer 2006 Installation Guide.

Integration With Local Promotions 


A powerful feature in the architecture of Implementer is the seamless support for remote 

distributions. This means you define environments to Implementer and designate whether 

the environments are located on local or remote systems (a remote environment must have a 

remote system name specified in the environment definition). 

Promotions to local and remote systems occur for an environment based on the environment 

description; thus, Implementer’s distribution features are able to share features with the local 

promotions. For example, to distribute a change you create a promotion request, compile the 

request, and perform the Move Requests function to distribute the change. This is basically 

the same process used to promote to a local environment, meaning you only need to learn 

one mechanism for both local and remote promotions. The process supports a single 

promotion request promoting members/objects to both local and remote libraries, either by 

manually selecting multiple environments, or by using the environment group feature. 

Remote System Inventory 

Implementer maintains a complete inventory of the members and objects distributed to each 

remote environment. This information is available on many inquiry panels and reports on the 

host system, and includes the following information: 

date and time a member/object was promoted to the remote system 

assigned project (if using projects) 

promotion request details 

After initially setting up Implementer, you must run the Build List function to analyze the 

members/objects in remote environments and load the inventory into the Implementer 

repository on the host system. For details, see “Environment Repository Build” on page 117. 

If needed, the Reset Authorities function allows you to set the object owners and authorities 

on the remote system as defined for the environment. For details, see “Resetting Authorities” 

on page 372. 

Remote Source Members 

You can specify that source is stored on the remote system for an environment. For example, 

you can store source on the remote system for infrequently modified applications when you 

do not retain source on the development system, or use it to secure source on a different 

system. 

Remote source members can be checked out from the remote system and optionally compiled 

during promotion on the remote system. This applies to source members that have related 

objects, such as source members for files and programs. Implementer recognizes source-only 

163


164 

items such as OCL, sort specifications, and text members. This ensures you include and send 

source to the remote for environments that have local source, as some applications require 

the source members during execution. 

NOTE Storing source on the remote only can cause problems for developers when 

attempting to browse source members not checked out, and they have restricted 

access to the remote system. In this case you can check out the source from the 

remote system; Implementer creates a temporary DDM file and copies the source 

from it. 

Consideration for Database Files 

Implementer avoids problems associated with the distribution of database files to remote 

systems. For example, Implementer supports promoting logical files without the related 

physical file on a request, and ensures that all necessary physical files are duplicated into the 

work library so a logical file is never based on a physical file outside of the Implementer work 

library. The duplicated physical files are not promoted into production so you never have 

additional access paths over the production environment. This also ensures successful 

distribution and restoration of the logical files to the remote system. 

For complex database files, Implementer provides the same support on the remote system as 

that provided on the local system. 

Distribution Methods 

Implementer supports the distribution of source members and objects on tape or by using 

OS/400 communications with SDMCom, TCP/IP, or SNADS. Different distribution methods 

can be defined per environment. The following table provides an overview of each 

distribution method. 

Distribution 

Method 

Description 

SDMCom SDMCom is a feature of Implementer that improves performance by 20–35% over 

SNADS distribution. Its advanced features use compression algorithms and 

blocking specifically for remote distributions. 

SDMCom eliminates reliance on SNADS distribution queues, directory entries, and 

network files, which helps simplify setup and eliminate the number of potential areas 

of distribution failures. For example, SDMCom eliminates concerns of whether 

directory entries exist or distribution queues are started. Distribution with SDMCom 

is performed directly within the Implementer distribution job—it is not sent to a 

distribution queue like QSNADS uses.

Distribution 

Method 

Communications Considerations 

APPC Programs 

Description 

Communications Considerations 

TCP/IP TCP/IP is available for both FTP and tape distributions. 

You must define the TCP/IP address and port in Implementer’s Network 

Configuration. You must also define the TCP/IP communications subsystem and job 

queue. When you install Implementer, the TCP/IP communications subsystem 

IMCOM and the communications job queue IMCOM are both created. 

TCP/IP must be set up between the host and remote systems. You can add the 

Communications Control (ICOMCTL) command to your daily OS/400 startup routine 

(for example, the IPL procedure) or start it manually. 

SNADS Distribution with SNADS requires creating directory entries on both the local and 

remote systems. SNADS must be set up between the two systems. You must define 

a distribution queue with the Configure Distribution Services (CFGDSTSRV) 

command. You must configure the distribution queue used by Implementer to start 

distribution when an item is in the distribution queue. 

Tape Distribution on tape involves two steps: create the tape on the local system and 

restore the tape on the remote system. You can use any OS/400 tape media. To 

restore work libraries from a tape at the remote site, use the Restore Remote 

Request (IRSTRMTRQS) command, either from the Implementer Receiver menu 

option or the command line. 

DVD Valid only for release management environments. For details, see the 

MKS Implementer 2006 Release Management Guide. 

Before setting up communications for Implementer distributions, review the following 

information regarding the communication lines and programs supported by Implementer. 

Implementer uses APPC (Advanced Program to Program Communication) programs to start 

jobs on a remote system related to remote environments. APPC programs can be referred to 

as communications programs or ICF (Intersystem Communications Facility) files. You do not 

need this information to use Implementer, but it helps to understand how it works. 

Implementer uses APPC programs as follows: 

An APPC program is used during promotion for the distribution and move steps. The 

same APPC program is used during the compile step for the environment designated as 

having source on the remote system. For remote initiated moves, an APPC program is 

used if the remote environment is defined to update the host on remote initiated moves. 

In this case, the APPC program updates the host with information regarding the status 

of the promotion request, archive information, time stamping for each member and 

object and, if specified, job log information. 

165


166 

The Build List function uses an APPC program to retrieve source and object information 

from a remote system. Generally, you run a build when you define a new environment. 

The Reset Authorities function uses an APPC program to change the owners and 

authorities to objects for a remote environment. Generally, you reset authorities when 

you define a new environment. 

The delete request function (available from a number of different menu options) uses an 

APPC program to delete work libraries or SNADS network files that exist on the remote 

system. This ensures deleting a promotion request does not leave unwanted source, 

objects, work libraries, or network files on the remote system. 

Communication Lines 

APPN Lines 

Switched Lines 

Implementer’s distribution facilities use LU6.2 protocol, which is also known as APPC. 

Implementer is independent of the type of APPC line. This means changes can be distributed 

over SDLC lines or token ring lines. Changes are not distributed using asynchronous lines, 

since this type of line does not support the LU6.2 protocol. 

Implementer supports lines configured for APPN (Advanced Peer-to-Peer Network) reconnections. 

Whereas Implementer uses APPC programs, a situation that requires using 

APPN for distribution to the remote is when the host system is not directly connected to the 

remote. For example, system A connects directly to system B, and system B connects directly 

to system C—however, system A does not connect directly to system C. In this case, you 

must define the lines using APPN to distribute changes from system A to system C. 

The OS/400 operating system provides support for APPN. Use APPN when you define your 

network of iSeries systems and specify how remote systems that are not directly connected 

route to each other. 

Implementer supports switched (common carriers) or non switched (leased/dedicated) lines. 

If you use switched lines, Implementer has the option to vary on and vary off the 

communications configuration before and after a distribution to the system. This feature is 

particularly useful when you have one switched line shared by multiple systems. Without 

this support you would have to vary on and off the communications line, controller, and 

device before distributing to a different system sharing the same communications port. In the 

Network Configuration menu option, specify the communications line, controller, and device 

for Implementer to automatically vary on or off.

Network Control Programs 

Network Configuration 

Network Control Program (NCP) is a software product that runs on an IBM mainframe. NCP 

serves as a communications controller between two iSeries systems in a network. This is also 

described as using Virtual Telecommunications Access Method (VTAM), IBM’s application 

program interface. 

Implementer users that use NCP must set up communications differently because of certain 

communications parameters that are changed by NCP. These parameters are usually set to 

the OS/400 defaults by most iSeries users; however, if you use NCP, the following 

parameters do not usually use the OS/400 defaults: 

remote location name 

local location name 

mode name 

remote network identifier 

Find the values for these four parameters on your system by displaying the description of the 

APPC device description on the local system that connects to the remote system. Then, 

specify the same values for these fields for the remote system in Network Configuration. 


The system-wide communication parameters used by Implementer are defined in Network 

Configuration, option 46 on the Implementer Menu. Network Configuration allows you to 

define and maintain information about the remote systems you deploy software changes to 

using either SNA or TCP/IP distribution. Establishing a network configuration is only 

required if you distribute to remote systems—you must define each remote system you 

distribute to in Network Configuration. 

If you use TCP/IP for distribution between host and remote systems, you must define the 

TCP/IP address and port in Network Configuration. TCP/IP has additional setup 

requirements as described in “Setting Up for TCP/IP Distribution” on page 173. 

Implementer must be installed on the host system and the Implementer Receiver must be 

installed on each remote system before you establish communications between the systems. 

Once the systems are defined in Network Configuration, you can define the environments for 

each remote system. 

TIP If you have multiple remote environments, consider defining an environment 

group to target with all remote distributions. 

167


168 

To add or change a system in Network Configuration 

1 From the Implementer Menu, type option 46, or type STRIM *NETCFG at the command 

line and press ENTER. The Network Configuration Maintenance panel displays. 

2 To create a new system, press F6=Add, or to create a system by copying an existing 

system, type 3 in the Opt field and press ENTER. To change an existing system, select the 

system with option 2=Change and press ENTER. 

3 Specify the following fields: 

In the System field, type the name of the remote system to distribute to. This field 

allows entry only when initially creating the system. 

In the Description field, type a system description. 

In the Target Release field, specify if the remote system is at an older release of the 

operating system than the host system. Specify *CURRENT, *PRV, or the actual 

version name. 

4 Complete the remaining fields based on the distribution method (SNA or TCP/IP) as 

described in the following sections. 

NOTE The second and third Network Configuration Maintenance panels are for 

SNA distribution. If you intend to use both TCP/IP and SNA communications with 

this system, complete both the SNA and TCP/IP fields as required; otherwise leave 

one or the other blank. 

To configure Network Configuration for SNA distribution 

1 Follow the previous steps to create or change the system. 

2 On the second Network Configuration Maintenance panel, define the information as 

needed. The following steps describe where to find the necessary information: 

To determine the system name on the remote system, use the Display Network 

Attributes (DSPNETA) command. 

To determine the description of the device used to communicate with the remote, on 

the host system use the Display Device Description (DSPDEVD) command for: 

remote location name 

local location name 

mode 

remote network identifier

Setting Up Communications Entries 

3 Press ENTER to access the third Network Configuration Maintenance panel and continue 

entering the information. 

To determine the description of the communication lines, on the host system use the 

Display Line Description (DSPLIND) command for: 

attached non switched controllers for the control unit 

connection type for the line type 

4 Press ENTER to update the changes. 

To configure Network Configuration for TCP/IP distribution 

If you use TCP/IP for distribution between host and remote systems, complete these steps 

for each remote system you distribute to. In addition, if you use the Remote Initiated Move 

Update Host feature, you must complete these steps for the host system. 

1 Follow the previous steps to create or change the system. 

2 From the Network Configuration Maintenance panel, press ENTER twice to display the 

fourth Network Configuration Maintenance panel. 

3 Complete the fields on this panel as follows: 

In the TCP/IP Address field, specify an IP address, a system name in a DNS server, 

or a system name in a host table. The default value is blank. 

In the Port field, specify a valid number between 1 and 65535. The default number is 

30005. MKS recommends you use a number higher than 1024 to avoid conflict with 

standard services such Telnet, FTP, and Web servers. 

The port you define on the host system must match the port defined on the remote 

system. The port value must also match the port value you specify in the 

Communications Control (ICOMCTL) command you define on both the host and 

remote systems as described in “Setting Up for TCP/IP Distribution” on page 173. 

4 Press ENTER to update the system record. 


Implementer uses communications to distribute requests from the host system to one or more 

remote systems. You have three options for setting up Implementer for communications and 

distribution between systems: 

use pre-existing communications entries 

add communications entries using an existing mode description 

add communications entries using an Implementer-specific mode description 

169


170 

This section explains the setup procedures for each option. For a comparison of the options, 

see “Understanding Implementer” on page 9. 

Option 1: Using Existing Communication Entries 

This option requires no additional setup steps. MKS recommends you initially set up 

Implementer to use an existing communications mode description. When using this 

approach, the communications job runs using the Implementer user profile MWIPROD. 

Option 2: Using an Existing Mode Description 

This option requires you to create communications entries using an existing mode 

description. It has setup tasks on both the host and remote systems. 

Host System Setup 

Before starting this task, you must have the name of the communications subsystem on the 

host system. This is typically subsystem QCMN and is referred to as qcmn in the following 

instructions. 

To perform setup on the host system 

1 Add a communications entry by issuing the following command: 

ADDCMNE SBS(qcmn) 

DEV(APPC-device) 

JOBD(MKSIM/MWIJOBD) 

DFTUSR(MWIPROD) MODE(*ANY) 

2 Change the device description by issuing the following command: 

CHGDEVAPPC DEVD(APPC-device) MODE(existing-modes) 

For example, the command for APPC device RMTDEV using mode BLANK is: 

CHGDEVAPPC DEVD(RMTDEV) MODE(BLANK) 

3 On the host system, issue the following command to change the Implementer 

Communications User (IMCMNUSR) data area value to blanks, which allows using the 

communications entry defined next. 

CHGDTAARA DTAARA(MKSIM/IMCMNUSR)VALUE(' ') 

where VALUE is defined by a blank character enclosed in single quotes. 

4 In Implementer Menu option 46, Network Configuration, change the mode name of the 

remote system to the mode you are using. 

a) Select the remote system with option 2=Change and press ENTER to display the 

Network Configuration Maintenance panel.


b) In the Mode Name field, type the existing mode name and press ENTER. 

Remote System Setup 


remote system. This is normally subsystem QCMN and is referred to as qcmn in the following 

instructions. 

To perform setup on the remote system 






2 Change the APPC device description by issuing the following command: 

CHGDEVAPPC DEVD(APPC-device) MODE(existing-modes) 

For example, the command for existing APPC device RMTDEV using mode BLANK is: 

CHGDEVAPPC DEVD(RMTDEV) MODE(BLANK) 

Option 3: Using a Specific Mode Description 

This option requires creating an Implementer-specific communications entry on the host 

system. The setup tasks are performed on the host and each remote system. 

Host System Setup 

Before starting this task, you must have the following information available: 

The name of the communications subsystem on the host system. This is normally 

subsystem QCMN and is referred to as qcmn in the following instructions. 

The name of the APPC device on the host that is used to connect to the remote system. 

This is referred to as APPC-device in the following instructions. 

The system name of the remote systems you distribute changes to. This is referred to as 

remote-system-name in the following instructions. 

To perform setup on the host system 






171


172 

2 Change the Implementer Communications User (IMCMNUSR) data area to blanks by 

issuing the following command: 

CHGDTAARA DTAARA(MKSIM/IMCMNUSR) VALUE(' ') 

where VALUE is defined by a blank character enclosed in single quotes. This allows using 

the communications entry defined next. 

3 Create a mode description on the host system that corresponds to the mode description 

on the remote. This allows you to specify the amount of activity needed for 

Implementer-related activities. Issue the following command: 

CRTMODD MODD(IMPMODD) TEXT('Implementer Mode') 

4 Associate the mode description with the communications subsystem. The default user 

profile on the communications entry is the profile that all Implementer APPC jobs run 

under. You can specify any user profile—a common entry is QUSER. 

a) To display the device description and determine the current modes used by the 

device, issue the following command: 

DSPDEVD DEVD(APPC-device) 

b) Change the APPC device description by issuing the following command: 

CHGDEVAPPC DEVD(APPC-device) 

MODE(existing-modes IMPMODD) 

For example, the command for APPC device RMTDEV using mode BLANK is: 

CHGDEVAPPC DEVD(RMTDEV) MODE(BLANK IMPMODD) 

Remote System Setup 


remote system. This is normally subsystem QCMN and is referred to as qcmn in the following 

instructions. In addition, you must have the name of the APPC device that connects the 

remote system to the host. This is referred to as APPC-device in the following instructions. 

To perform setup on the remote system 


ADDCMNE SBSD(qcmn) 

DEV(*APPC) 

JOBD(IMPRCV/IMPJOBD) 

DFTUSR(MWIPROD) 

MODE(IMPMODD) 

2 Create a mode description on the remote system that corresponds to the mode 

description on the host system. This allows you to specify the amount of activity needed 

for Implementer-related activities. Issue the following command: 

CRTMODD MODD(IMPMODD) TEXT('Implementer Mode')

Setting Up for TCP/IP Distribution 

3 Associate the mode description with the communications subsystem. The default user 

profile on the communications entry is the profile that all Implementer APPC jobs run 

under. You can specify any user profile—a common entry is QUSER. 

a) To display the device description to determine the current modes used by the 

device, issue the following command: 

DSPDEVD DEVD(APPC-device) 

b) Change the APPC device description by issuing the following command: 

CHGDEVAPPC DEVD(APPC-device) 

MODE(existing-modes IMPMODD) 

For example, the command for APPC device RMTDEV using mode BLANK, is: 

CHGDEVAPPC DEVD(RMTDEV) MODE(BLANK IMPMODD) 

Defining the Host for Remote Initiated Moves 

You can configure remote environments set up for remote initiated moves to update the host 

with request processing information. This feature requires an additional communications 

entry on the host for the remote system to access with the update. 

The default user profile on the communications entry is the profile that all Implementer 

APPC jobs run under. You can specify any user profile—a common entry is QUSER. 

A variety of methods exist for defining the communications entry. The following instructions 

work for most organizations; however, if you use other APPC programs or pass-through 

sessions, MKS recommends you review the applicability of these instructions to your 

installation. 

To set up a host communication entry for remote initiated moves 

Add a communications entry by issuing the following command: 






Implementer supports TCP/IP (Transmission Control Protocol/Internet Protocol) 

communication as a method of communication between host and remote iSeries systems. 

This technology is available for both FTP (File Transfer Protocol) and tape distribution. 

173


174 

Current TCP/IP technology does not support automatic job initiation on a remote system; 

thus, Implementer provides the Communications Control (ICOMCTL) command that 

initiates a communications subsystem, and daemon and monitor communications programs. 

These programs monitor the remote TCP/IP port for Implementer-specific requests. The 

communications programs remain in an idle state until activity initiated from the host system 

activates request processing on the remote system. You can use an Implementer-supplied 

subsystem or an alternate subsystem. For details on the ICOMCTL command, see 

“Communications Control Command” on page 177. 

If your network configuration requires FTP transfers using non passive mode, Implementer 

provides the FTP Passive Mode (IMFTPPASV) data area to control how its FTP transfer uses 

passive mode when sending files using TCP/IP. Passive mode eliminates the requirement on 

the receiving system to open a dedicated port for the host to connect to. Most users do not 

need to change this data area. For details, see “FTP Passive Mode (IMFTPPASV)” on 

page 405. 


IMPORTANT TCP/IP communications must be set up and working successfully; 

other than what is required for Implementer, MKS does not assume responsibility 

for configuring or troubleshooting communications. 

To determine if a remote system is accessible (at the most basic level), from the host 

iSeries system issue the command PING . If you need 

assistance with configuring TCP/IP, see your network administrator. 

You must define a distribution method for each environment. For details, see 

“Distribution method” in the table on page 90. 

In Network Configuration, define the distribution method as TCP/IP. If you use 

Implementer’s remote initiated moves feature, you must also define specific host system 

information in the Network Configuration. For details, see “Network Configuration” on 

page 167. 

The Communications Control (ICOMCTL) command must be set up to run on the 

remote with information specific to your communication network. If you use the update 

host component of remote initiated moves, you must also define the command to run on 

the host system. For details on setting up the ICOMCTL command, see 

“Communications Control Command” on page 177. 

Implementer includes a TCP/IP communications subsystem and communications job 

queue, both named IMCOM, which Implementer creates in the default product library 

(MKSIM) during product installation. You can use an alternate subsystem; however, the 

benefit of using IMCOM is that it allows you to isolate Implementer’s host and remote 

processing jobs from all other TCP/IP jobs being processed. For details, see 

“Communication Subsystem and Job Queue IMCOM” on page 176.


MKS recommends you use Implementer’s default TCP/IP port, 30005, on both the host 

and remote systems; although this is not a requirement. 

MKS recommends you set all OS/400 TCP/IP attributes to the IBM recommended 

defaults. 

Firewall Considerations 

For TCP/IP to work successfully with Implementer, certain external conditions must be met. 

The following information on using TCP/IP with a firewall may be helpful to your Network 

Administrator, or any other person responsible for the setup and maintenance of your 

communications and network. 

When using Implementer on a system with a firewall, the firewall must be completely 

transparent to Implementer. Thus, when targeting external iSeries systems with remote 

promotions, configure the network firewall to allow traffic through a predefined, userconfigured 

TCP/IP port on the remote system. Specify the port in Implementer’s Network 

Configuration. Uncompromising to your security, Implementer ensures that the program 

monitoring the port only responds to Implementer-specific requests. If needed, you can 

restrict activity on the port to specific Internet addresses by establishing firewall rules. 

To avoid the possibility of remote system tampering, Implementer accepts only certain 

requests through TCP/IP. The request information is handled using a token passed from the 

host system. The remote system interprets the token to identify which remote function to 

invoke. Any requests that present an invalid token are ignored. 

For outbound communications of bulk files transfers, Implementer uses standard FTP 

services that process with the default user profile MWIPROD. This requires the standard FTP 

ports 20 and 21 enabled. In addition, for proper authorization and authority to perform the 

FTP operation, the MWIPROD user profile must have the Limit Capabilities parameter set to 

*NO, as well as have authority to use the following commands on the remote system: 

CLRSAVF (Clear Save File) 

CRTSAVF (Create Save File) 

CRTLIB (Create Library) 

DLTLIB (Delete Library) 

IMPORTANT Due to the variety of FTP proxy servers and their protocols, the use of 

proxy servers is not supported. 

OS/400 FTP Service 

You must start the standard OS/400 FTP service to use bulk file transfers. 

175


176 

To start the FTP server 

Issue the Start TCP/IP Server command as follows: 

STRTCPSVR *FTP 

Use the Change FTP Attributes (CHGFTPA) command to configure the FTP server to autostart, 

and to set other configuration values. 

Communication Subsystem and Job Queue IMCOM 

Implementer includes the TCP/IP communications subsystem IMCOM and a 

communications job queue of the same name (IMCOM). Both are created in the default 

product library (MKSIM) when you install Implementer. An alternate subsystem can be 

used, however the benefit of using IMCOM is that it allows you to isolate Implementer’s host 

and remote processing jobs from all other TCP/IP jobs being processed. 

You must reference the IMCOM subsystem and job queue, or another subsystem and job 

queue if used, in the ICOMCTL command as described in “Communications Control 

Command” on page 177. 

The IMCOM subsystem processes two types of jobs—daemon jobs and monitor jobs. The 

following table defines the characteristics of each job. 

Job Type Description 

Daemon job Job name defined with D, followed by the port number, for example D30005. There 

can be any number of active daemon jobs, the actual number defined by the 

number of daemon instances (default is five) you define for the Communications 

Control (ICOMCTL) program. When no active jobs exist in the subsystem, there is 

exactly this number of daemon jobs (never fewer). A remote process uses one 

daemon instance (or session) and dynamically creates a duplicate copy each time 

for the next process to use. 

Monitor job Job name defined with M, followed by the port number, for example M30005. There 

is always only one active monitor job. 

CAUTION You must end the IMCOM subsystem to perform a backup of the 

Implementer Receiver library. However, ending the IMCOM subsystem with active 

promotions can cause unpredictable results. Thus, before ending the subsystem 

issue the ICOMCTL command with shutdown processing enabled to ensure no 

active promotions or other active jobs exist. Use the End Subsystem (ENDSBS) 

command to end the IMCOM subsystem.

Communications Control Command 


The Communications Control (ICOMCTL) command is delivered with Implementer. The 

command installs on the host system when you install or upgrade Implementer. It installs on 

the remote system when you install or upgrade Implementer Receiver. 

To use TCP/IP with Implementer, the ICOMCTL command must be set up to run on the 

remote system with information specific to your communication network. If you use the 

“Update Host” component of remote initiated moves, the command and similar subsystem 

must also be defined to run on the host system to allow automatic updates to the host system. 

The ICOMCTL command manages the start and end of the Implementer TCP/IP 

communications subsystem IMCOM (or the subsystem you have specified). It also controls 

starting and ending the daemons and monitor job within the subsystem. The daemons 

monitor for Implementer-specific requests. 

You must start the remote subsystem and TCP/IP communications programs by either 

manually issuing the ICOMCTL command, or defining the command to run automatically. If 

the communications programs are not active in the remote subsystem during Implementer 

processing, any host system requests received on the remote fail with a time out error. 

To define the ICOMCTL command 

1 Define the ICOMCTL command parameters as described in the next section. 

2 Do either of the following: 

Add the ICOMCTL command to your OS/400 daily startup routine. 

Issue the command interactively by typing ICOMCTL at the command line and press 

F4 to prompt. Define the parameters as required and press ENTER. A message 

confirms the TCP/IP communications monitor started in the specified port. 

IMPORTANT Add the ICOMCTL command to your daily OS/400 startup routine, for 

example, the IPL procedure, or start it manually. The subsystem you specify in the 

command starts automatically if not active when the command processes. 

ICOMCTL Command Parameters 

TCP/IP Port 

Specify a valid TCP/IP port number between 1-65535. The default value is 30005. Specify the 

the same port number for this parameter on both the host and remote ICOMCTL commands. 

This port number must match the TCP/IP port value defined in Implementer’s Network 

Configuration. 

177


178 

Number of daemon instances 

Specify the number of simultaneous connections (or sessions) to initially invoke. Valid values 

are between 1 and 100. The default value is 5. 


Specify the name of the job queue to submit the communications program. The default value 

is IMCOM, the communications job queue delivered with Implementer. 

Specify a library name associated with the job queue. The value *LIBL searches the library list 

for the job queue library. This is the default value. 

Subsystem/Library 

Specify the name of the subsystem attached to the job queue. The default value is IMCOM, 

the communications subsystem delivered with Implementer. If you specify an alternate 

subsystem, set the maximum number of jobs parameter (Max Active) to *NOMAX. 

This parameter is provided for your convenience: The ICOMCTL command runs in the 

subsystem attached to the job queue regardless of the subsystem specified in the command. 

This is because the IMCOM subsystem does not automatically start, and if you use the 

command defaults, the subsystem must be active to process the jobs submitted to the queue. 

Specify the library name associated with the subsystem. The value *LIBL searches the library 

list for the subsystem name. This is the default value. 

User to run as 

Specify a user profile for the command to process with. 

Name Specify a valid user profile name. 

*CMNUSR Job runs under the user profile specified in the data area IMCMNUSR 

(default is MWIPROD). This is the default value. 

*CURRENT Job runs under the user profile of the person who submits the command. 

Shutdown Processing 

Specify whether Implementer automatically ends the daemon and monitor jobs in the 

IMCOM subsystem. Shutdown processing does not include ending the IMCOM subsystem. 

Y Jobs automatically end when processing completes. 

N Jobs remain active until manually ended. This is the default value.

Setting Up for SNADS Distribution 

Setting Up for SNADS Distribution 

Implementer works with SNA Distribution Services (SNADS) to distribute changes to remote 

iSeries systems. If you are not using SNADS for distribution (for example, you are using 

SDMCom) you can bypass this section. 

The host iSeries system requires SNADS directory entries for each user profile that sends and 

receives remote distributions using SNADS. Before starting the following task, you must 

have the remote location name of the iSeries system you distribute to. You must use the 

remote location name, not the system name. To determine the remote location name, use the 

DSPAPPNINF (Display APPN Information) command if you use APPN, or use the 

DSPDEVD (Display Device Description) command for the APPC device that connects to the 

remote. 

NOTE The remote location name is usually the same as the system name of the 

remote. To prevent errors, use the above commands to ensure you use the correct 

location name. 

Add Directory Entries for Sending User Profiles 

A SNADS directory entry must exist for each host user profile defined in Implementer that 

has authority to distribute changes to remote systems (these user profiles are often already 

enrolled). 

To create the directory entry for a user not currently enrolled in SNADS 

Issue the following command: 

ADDDIRE USRID(user-profile local-system-name) 

USRD('Text description for the user') 

USER(user-profile) 

Add Directory Entries for Receiving User Profiles 

A SNADS directory entry must exist for each iSeries you distribute changes to. You can 

create the directory entry for receiving user profiles in any of three ways: 

Use directory entry USER(*ANY *ANY) to allow distribution to any user on the iSeries 

system identified to SNADS. 

Use directory entry USER(*ANY remote-location-name) to allow distribution to any user 

on the iSeries that matches the remote-location-name. 

If neither of these directory entries exists, you can create the following Implementerspecific 

directory entry. Only one directory entry is required for the remote location. 

Specify this directory when defining the remote iSeries in Network Configuration. It is 

usually for user profile MWIPROD, as all network files are sent to that directory entry on 

the remote. 

179


180 

To create an Implementer-specific directory entry 


ADDDIRE USRID(MWIPROD remote-system-name) 

USRD('Implementer on remote-system-name') 

SYSNAME(remote-location-name) 

Add a Directory Entry for MWIPROD 

For remote distributions, you must include a directory entry for the MWIPROD user profile. 

Specify the user profile on the remote iSeries where the Implementer Receiver receives 

changes. 

To create the directory entry 


ADDDIRE USRID(MWIPROD remote-system-name) 

USRD('Implementer') 

USER(MWIPROD) 

Distribution Options 

This section describes some options you have for controlling the promotions to remote 

systems. 

Single Step Distribution 

Implementer can distribute and apply changes to one or more remote systems in a single step 

(on one request). You are not required to sign on to the remote system to apply the changes. 

After Implementer sends the changes to the remote system, it immediately executes an APPC 

program to apply the changes to the target libraries. If it is necessary to redistribute from the 

host, you can redistribute an existing promotion request without creating a new promotion 

request. From the Move Requests selection panel, use option 10=Redistribute. 

Two Step Distribution 

You can distribute objects to a remote system in one step and move the objects into the target 

libraries in a second step. The second step can be initiated from the host system or the remote 

system.

Controlling Remote Job Schedules 

The first step bundles the objects, distributes to the remote system, receives the objects on the 

remote system, and restores them into a temporary holding library. At an appropriate time, 

the second step quickly promotes the objects from the holding library to the target libraries. 

To minimize the time needed to move the objects into the target libraries, most of the work 

(receiving and restoring) is accomplished in the first step. 

Remote Initiated Moves 

You can initiate the second step of the two step distribution process from the remote system. 

Use this approach when you have changes that may take a long time to distribute. Once you 

distribute the changes into the holding libraries on the remote system, you can move the 

changes into the remote production libraries from the remote system during the second step. 

This feature is commonly used as the last step in a nightly job stream on the remote system. 

You can initiate remote initiated moves on the Implementer Receiver from a menu option, or 

by using the Move Remote Request (IMOVRMTRQS) command. 

If you use TCP/IP for distribution to remote systems and the update host functionality for 

remote initiated moves, additional subsystem requirements apply to processing the 

automatic updates to the host system. For details, see “Setting Up for TCP/IP Distribution” 

on page 173. 

CAUTION If promotion requests are dependent upon the completion of other 

requests, you must use a single-threaded job queue. 

Simultaneous Distribution to Multiple Remote Sites 

Implementer supports simultaneous distribution to an unlimited number of remote systems, 

while retaining clear visibility to what happens on each remote system. 

To perform simultaneous distribution, you must use the Move Request by System/ 

Environment function and submit the promotion for each system separately to enable the 

distribution of multiple jobs. You can use multiple job queues or multi-threaded job queues 

to simultaneously distribute to multiple remote systems. 


Implementer allows you to define standard move schedules on the local host development 

iSeries system, and then reschedule the move times of specific promotion requests to remote 

iSeries systems. 

181


182 

This feature allows you to distribute a promotion request from the host iSeries to multiple 

remote iSeries systems simultaneously, placing the remote move step under the control of a 

default schedule defined for each remote system. Additional flexibility on the host system 

allows you to reschedule the move for specific requests to manage the installation schedule of 

selected promotion requests without having to access the remote system. 

When scheduling a remote job, two options are available: Use the default job schedule 

settings for the target remote environment, or use the Change Remote Request 

(ICHGRMTRQS) command to override the default job schedule settings for a request, then 

issue the Move Remote Request (IMOVRMTRQS) command to reschedule the job. 

Using the Default Job Schedule 

To schedule a promotion request to a remote environment based on the default settings for 

that environment, use menu option 6, Move Requests by System/Environment to distribute 

the request. This option is available for any remote environment set up as defined in “Remote 

Job Scheduling” on page 183. 

The promotion scheduling defined for the environment appropriately schedules the job 

based on the default move time. Then, based on the frequency you define on the remote 

OS/400 auto job schedule for the Move Remote Request (IMOVRMTRQS) command, the 

move submits using the default schedule. 

IMPORTANT The move step must be separate from the distribution step because it 

must be a remote-initiated move. 

Overriding the Default Job Schedule 

The Change Remote Request (ICHGRMTRQS) command is used to enter schedule overrides 

to the default move schedule for promotion requests. The command evokes DDM to 

communicate the overrides to the schedule overrides file IMRQSO on the remote for each 

target remote system on a request. A log of the schedule overrides is maintained in file 

IMRQSO on the host and remote systems. 

The Move Remote Request (IMOVRMTRQS) command updates the Move job. The 

IMOVRMTRQS command reads the schedule overrides file IMRQSO on the remote and 

applies the processed overrides to the OS/400 auto job scheduler. Then, based on the 

frequency defined on the remote OS/400 auto job schedule for the IMOVRMTRQS 

command, the subsystem is polled for new jobs to submit and new overrides not yet applied. 

NOTE Only the IMOVRMTRQS command updates the Move job—the 

ICHGRMTRQS command does not.



The distribution step must be separate from the move step (from Implementer Menu 

option 6, Move Requests by System/Environment, use option 10=Distribute). 

The remote target environment must be set up to allow remote initiated moves (in Work 

with Environments). 

Remote Job Scheduling 

Complete the following setup tasks to use remote job scheduling: 

define remote environment to allow remote-initiated moves 

define remote environments with a default move time 

on each remote system, create a routine job that issues the Move Remote Request 

(IMOVRMTRQS) command for all requests 

To define a remote environment for remote initiated moves 

1 From the Implementer Menu, select option 42, Environments and press ENTER. The 

Work with Environments panel displays. 

2 Select the remote environment with option 2=Change. 

3 Press PAGE DOWN twice to display the third Change Environment panel. 

183


184 

4 Do the following: 

In the Remote initiated move field, type Y. 

In the Updates host field, type Y or N to indicate whether remote initiated moves 

update the host with information such as the request header status, request detail 

status, archive information, and job log. If set to N, the status is set to complete once 

the request is distributed. Otherwise, the status is not updated until the move 

actually occurs on the remote system. 

5 To save the change, press ENTER. 

To set up default scheduling for a remote environment 

1 From the Work with Environments panel, type 13=Promotion scheduling next to remote 

environment and press ENTER. 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 

and time. The right-most field represents the to date and time. 

In the Move submit date range fields, specify one of the following values: 

*CURRENT Dates default from the system. This is the default value. 

Actual Date Type a specific from and to date. 

*MONTHSTR From date is the start of the month. 

*MONTHEND To date is the end of the month. 

*MON 

Type an asterisk followed by the first three letters of any day 

through *SUN of the week to indicate the from date.


In the Time range fields, specify exact from and to times, or specify *CURRENT to 

default the time value of the system. 

To create a job that issues the move request 

1 Use the Add Job Schedule Entry (ADDJOBSCDE) command to add an entry to the 

OS/400 job scheduler. 

An example daily job schedule entry is: 

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 current list of job schedule entries, 

use the Work with Job Schedule Entry (WRKJOBSCDE) command. 

Change Remote Request (ICHGRMTRQS) Command 

The Change Remote Request (ICHGRMTRQS) command communicates schedule changes 

for each target remote system on a promotion request. The command can be issued at any 

point once the request is created (the request does not have to be at a Move-Pend status). 

To use the Change Remote Request (ICHGRMTRQS) command 

1 Use the Create Request function to submit a request to a remote environment, or select 

an existing request. 

2 Type the command ICHGRMTRQS on the command line and press F4=Prompt. 

3 Define the command parameters based on your environment and as described next in 

“ICHGRMTRQS Command Parameters”. 


ICHGRMTRQS Command Parameters 

Request number (RQSNUM) 

Specify the request number of the request you created or selected. 

185


186 

Target environment (TGTENV) 

Specify the target environment on the request. 

Name Specify the target environment names. 

Generic* Type a value to include all environments that match the value, for 

example, type ABC* to include all environments beginning with 

ABC. 

*ALL Targets all environments that requests are created for. 

From date (FROMDATE)/To date (TODATE) 

Specify the starting from date to schedule the move. 

*CURRENT From and to dates default from the system. 

Actual Date Type a specific from and to date. 

*MONTHSTR From date is the start of the month. 

*MONTHEND To date is the end of the month. 

*MON - *SUN Type an asterisk followed by the first three letters of any day of the 

week to indicate the from date. 

*REQUEST Dates and times do not change. This is the default value. 

From time (FROMTIME)/To time (TOTIME) 

Specify the starting from time to schedule the move. 

Actual time range Type a specific from and to time. 

*CURRENT Defaults the time range from the system. 

*REQUEST Dates and times do not change. This is the default value. 

NOTE The From date/To date and From time/To time fields, in combination, define a 

window of time; thus, if you specify a value in one field you must specify a value in 

both of the fields. 

Job Queue/Library (JOBQ) 

Specify the job queue library and name for the move. 

Name Type the name of a specific job queue and library. 

*SYSCTL Defaults the job queue specified in System Control Maintenance. 

*REQUEST Job queue and library do not change. This is the default value.

Hold on job queue (HOLD) 

Specify whether to submit the job on hold. 

Move Remote Request (IMOVRMTRQS) Command 


*YES Job submits on hold. 

*NO Job does not submit on hold. 

*REQUEST Promotion request determines whether the job submits on hold. 

The Move Remote Request (IMOVRMTRQS) command issues the move step for each target 

remote environment on the request. If schedule overrides were entered using the Change 

Remote Request (ICHGRMTRQS) command, you must issue the IMOVRMTRQS command 

to process the override updates to the OS/400 job scheduler. 

The IMOVRMTRQS command runs periodically on the remote system to control the move 

jobs. For new requests not previously submitted, the move job submits 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 received. The audit file IMRQSO is updated for 

all submitted requests. 

To use the Move Remote Request (IMOVRMTRQS) command 

1 Use the Create Requests function to submit a request to a remote environment or select 

an existing request. 

2 Use the Change Remote Request (ICHGRMTRQS) command to override the default 

move schedule. Follow the steps described on page 185. 

3 Type the command IMOVRMTRQS on the command line and press F4=Prompt. 

4 Define the command parameters based on your environment and as described next in 

“IMOVRMTRQS Command Parameters”. 


If schedule overrides cannot be applied, (such as attempting to schedule from a date in 

the past) an error message generates. All schedule updates of previously submitted jobs 

are attempted, even if an error is encountered on another request. 

187


188 

IMOVRMTRQS Command Parameters 

Request number 

Specify the request number of the request you created or selected. 

Character 

Value 

System name 

Specify the name of the target remote system. 

Job Queue/Library (JOBQ) 

Specify the job queue library and name for the move. 

Hold on job queue (HOLD) 

Specify whether to submit the job on hold. 

Specify the request number. Resubmits a request at a scheduled 

status. For example, resubmits 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 processed. 

*ALL For new requests not previously submitted, 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, updates the 

schedule to the last request schedule override received. This does not 

resubmit a request at a scheduled status. 

*FAILED Submits requests that previously failed and have a failed status. This 

does not resubmit a request at a scheduled status. 

Name Specify the remote system name. 

*NETATR System name is taken from the Network Configuration. This is the 


Name Specify the job queue and library name. 

*SYSCTL Uses the job queue specified in System Control Maintenance. 

*REQUEST Job queue and library do not change. This is the default value. 

*YES Job submits on hold. 

*NO Job does not submit on hold. 

*REQUEST Request determines whether the job submits on hold. This is the 

default value.

Distribution Steps 

Move Steps 

Distribution Steps 

Based on the distribution method selected, the steps vary slightly but basically consist of the 

following sub-steps: 

Save the Implementer work libraries. For tape distribution, the save is to tape. For other 

methods, the work libraries are saved to save files. 

Send the Implementer work libraries (occurs differently for SNADS and SDMCom). 

Receive the Implementer network file (occurs only for SNADS for distribution). 

Restore the work files from the save files (occurs for all distribution methods). Once this 

sub-step completes the distribution step is complete. The move step is next. 

You can initiate the move step from either the host or remote system. 

On the host system you can initiate the move step from: the Workbench, Work with Objects, 

Move Request menu option, Move Requests by System/Environment, or the Move Request 

(IMOVRQS) command. This invokes a communications program on the remote that 

performs the promotion on the remote. The promotion steps are the same as on the local 

system. When the move step completes, the time and date that the objects were placed into 

production is transmitted back to the host to update the Implementer database. 

On the remote system you can initiate the move step from the Work with Requests function, 

or the Move Remote Request (IMOVRMTRQS) command on the Implementer Receiver menu 

or the command line. Many users embed the command in an end of day job on the remote 

system. 

TIP Issue the IMOVRMTRQS command with the request number value *ALL to 

complete the promotion of all requests distributed since the last time the command 

was issued. 

Multiple System Development 

Implementer supports multiple system development, a feature that allows Implementer to 

run on multiple systems while sharing the same database. 

189


190 

This feature is useful when you have related development activities spread across multiple 

systems, or a development system and a distribution system centrally located with 

distribution to many remote systems. You accomplish this with DDM (Distributed Data 

Management). 

Before using this feature you need to decide which system has the primary version of 

Implementer. This should be the system Implementer is most heavily used on. 

You must set the default user profile on the communications entry to have *ALL rights to the 

Implementer database files on the primary system. By default, DDM jobs run from the 

remote system under user profile QUSER and require access to the Implementer files. For 

details on the communications entry, see the MKS Implementer 2006 Installation Guide. 

Starting and Ending Remote Database Support 

A secondary system is prepared for multiple system development by using the Start Remote 

Database (STRRMTDB) command. This command changes the Implementer database files 

(PFs and LFs) to DDM files. You can convert all files or functional subsets (for example, only 

lock and conflict processing). An example of the command is: 

STRRMTDB RMTLOCNAME(remote_location_name) 

RMTPRDLIB(remote Implementer library) 

MODE(IMPMODD) 

LCLLOCNAME(*LOC) 

RMTNETID(*LOC) 

FILESCVT(*ALL) JOBQ(*PRODUCT) 

Specify the location name of the remote system and the name of the Implementer library on 

that system. If the mode description, local location name, or remote network ID do not match 

the defaults, specify the correct values. Prompt the command to show valid values for these 

parameters. The default converts all Implementer files to remote databases. Alternatively, 

you can specify *LOCKS and/or *PROJECTS. For further information, see “Performance 

Considerations” on page 191. 

After you validate the connection to the remote system (for example, remote location name, 

mode, local location name, and remote net ID are valid), a batch job submits to the JOBQ 

specified to perform the conversion. The Implementer files on the local system should not be 

in use when this job runs. 

When you no longer need to use this feature, use the End Remote Database (ENDRMTDB) 

command to change the DDM files on the secondary system back to physical and logical files. 

Once you issue this command, the Implementer database files contain the original 

information as before the initial Start Remote Database command was issued. 

You must install Implementer on the host system and the Implementer Receiver on each 

remote system used for development or that receives changes from the host system.

Performance Considerations 

Multiple System Development 

You must analyze the performance impact of this feature on the secondary systems to 

determine its feasibility within your system setup. Some of the database files opened on the 

secondary system are DDM files. To effectively use this feature you need high-speed 

transmissions, such as that provided by a Gigabit Ethernet. The secondary systems using 

Implementer with DDM files do not significantly affect the primary system. 

Additionally, to enable the secondary system to use Implementer, the communications line to 

the primary system must be active and the Implementer database files on the primary system 

must be available. If the line to the primary system goes down, Implementer on the 

secondary system is unavailable for use until you re-establish the connection. 

If your communication line cannot provide adequate performance when you convert the 

Implementer files to remote databases, you may want only certain functional areas of the 

product to use this feature. On the Start Remote Database command, the default is to convert 

all files; however, you can specify to convert only the files related to lock and conflict 

processing [FILESCVT(*LOCKS)]. If you specify *LOCKS, each system operates with most 

Implementer files locally, yet maintains one set of files that enforce, lock, and allow 

concurrent development across all systems. 

Specify *PROJECTS to have one project tracking database. You can specify one or more of 

these values in the FILESCVT list. If you specify *ALL anywhere in the list, it overrides 

*LOCKS and/or *PROJECTS. 

Request Number Considerations 

If you use multiple system development and do not convert all database files, you should 

adjust the request number on each secondary system to avoid conflict with the request 

numbers on the primary system. For example, if the next request number (in System Control 

Maintenance) on the primary system is 500, set the next request number on a single 

secondary system to 5500. For multiple secondary systems, the next request numbers can be 

divided into equal groups depending on the number of secondary systems. In this way the 

likelihood of a duplicate request number generated by requests from the secondary systems 

is minimal, so audit records are less confusing. 

Each copy of Implementer and the Implementer Receiver should use a unique prefix for 

internal work libraries to ensure an overlap does not occur. Specify a unique two-character 

prefix in the data area IMPRFX in the product library of each copy of Implementer. For 

details, see “Implementer Data Areas and User Exit Programs” on page 401. 

You should also carefully consider the user profile names you use. To eliminate any 

confusion of where a check out occurs, MKS recommends you use different user profile 

names on the different systems. 

191


Saving and Restoring Remote Tape Archives 

192 

Implementer Receiver users who require access to the archives of every change made to an 

environment must often balance this requirement with the disk space required to store the 

archive copies. Archiving to tape provides a solution for off-line storage of archived 

member/objects in remote environments. 

You can save and remove all archives or specific archives, with access to archive information 

for each tape. You can also selectively restore archives back to the system. Once restored, you 

can browse the changes and/or recover the changes. 


Remote environments must be set up for archiving. For more information, see 

“Environments” on page 81. 

Tape archives include IFS and DLO files and directories, if archived. 

The archive to tape function uses two temporary libraries Implementer automatically 

creates at the beginning of the process and deletes at the end. Implementer provides the 

data area IMARCTAP to store the names of these temporary libraries. The default data 

are values are IMARCTAP1 and IMARCTAP2. 

CAUTION If you change the default library names in the IMARCTAP data area, you 

must specify library names that do not already exist on the system as Implementer 

creates and deletes the libraries as needed. For details, see “Implementer Data 

Areas” on page 402. 

You can initiate all archive to tape functions from the Archives to Tape menu. Access to 

archive menu options and commands requires signing on as QSECOFR or with a profile 

that has a group profile of QSECOFR or all QSECOFR capabilities. 

The archive to tape and restore from tape jobs can be run interactively or in batch. 

To save an archive to tape on the Implementer Receiver 

1 From the Implementer Receiver menu, select option 10, Archive to Tape. The Archives 

to Tape menu displays. 

2 Select option 1, Save Archives to Tape to prompt the Archives to Tape (ISAVARC) 

command. 

The ISAVARC command can also be prompted from the command line. The command 

can be processed interactively, submitted for batch processing, or added to a backup 

routine to automate the removal of new archives.

Problem Determination 

3 Specify the command parameters as described in “Save Archives to Tape (ISAVARC) 

Command Parameters” on page 381, and press ENTER. 

A good practice is to use a new tape for each save. The tape label is automatically set by 

Implementer and initialized with a tape volume of ARC###, where ### represents a 

number that starts at 001 and automatically increments for each save. This information is 

stored in the Implementer data area ITAPEVOLUM. If you need to specify a different 

tape. 

To restore an archive from tape on the Implementer Receiver 

1 From the Archives to Tape menu, select option 2, Restore Archives from Tape, or issue 

the IRSTARC command to display the Restore Archives from Tape (IRSTARC) command 

parameters. 

2 Specify the command parameters as described in “Restore Archives from Tape 

(IRSTARC) Command Parameters” on page 382, and press ENTER. 

Problem Determination 

TIP To easily locate the requests to restore, review the archive reports as described 

in “Archive Reports” on page 383. This feature is available on the host system only. 

If problems occur during distribution or when moving a promotion request, a message is sent 

to the user on the local system that initiated the job. The job log is sent to the host system 

where you can view it in Job Log Inquiry. 

Your initial distributions and/or moves can fail if you have Implementer or the remote 

communications incorrectly configured. The resulting system messages can be difficult to 

diagnose. You should contact your supplier for help in this case. For additional information 

on standard installation and communications, see “Understanding Implementer” on page 9 

and “Implementer Administration” on page 63. 

The remote diagnostic capabilities can be particularly important to users with multiple 

remote systems because it eliminates the need to sign on to the different remote sites to 

perform problem determination. In most cases, you can determine problems from the host 

system, rather than on each remote system. 

193


194

C HAPTER FIVE 

MKS Integrity Integration 

Setting Up the Integrated SCM Solution 

5 

Few industries in the world can compare to the rapidly changing realm of computing technology. 

Hardware, software, and the dot com eBusiness environment are evolving at an ever increasing rate of 

speed. In the explosive Internet and Web-based marketplace, many companies are rushing to take 

advantage of this area, creating Web sites, intranets, and online commercial software products. 

However the effort involved in managing change has taken its toll unnecessarily on many hardworking 

and dedicated people. You may relate to working in a rapid free-fire zone of software 

development where nightly builds, if that frequent, provide the only milestones in the process. Such 

inadequate measures for backup and security seriously jeopardize the effectiveness of enterprise-wide 

contributions. While this is only one scenario, it represents an important fact in this emerging Webbased 

marketplace: businesses desperately need solutions that move them from chaos to order. 

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. 


“Implementer and MKS Integrity Integration” on page 196 

“Converting From DesignTracker to MKS Integrity” on page 243 

“Emergency Update Mode” on page 255 

“Implementer and MKS Source Integration” on page 259 

“MKS Integrity Integrations Task Checklists” on page 295 

“Export to Implementer” on page 296 

“Troubleshooting” on page 302 

195

Chapter 5: MKS Integrity Integration 

Implementer and MKS Integrity Integration 

196 

MKS Integrity (formerly MKS Integrity Manager®) is a highly customizable, process and 

workflow management tool. 

Any simple defect tracking tool can record the status of a change request, but it does not 

monitor all the components that need to be modified, or the variety of tasks that need to be 

performed to resolve the issue. MKS Integrity 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. 

Change packages can also aid in the review of source code. By grouping together all changed 

members in a change package, developers can easily locate and retrieve the members they 

need to review. 

As part of the Implementer integration, MKS Integrity allows you to correlate issues with 

change packages that result from Implementer-managed development. 

A change package allows you to specify groups of member/objects that are affected by an 

issue, for example, a solution’s change package might contain programs that need to be 

changed in order to correct a problem. This helps to ensure that no hidden features or 

changes enter the product. 

The Implementer and MKS Integrity integration: 

helps your development team capture and track all of the 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 

member/object revisions 

automatically creates change packages to correlate issues with specific Implementer 

source members and objects 

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

Multitiered Architecture 

Your business problems are unique. Your specific concerns for managing the software 

development process in your environment requires a solution tailored to your workflow and 

information management process; you are looking for a seamless answer that works with the 

tools you prefer to use to get the job done.


MKS Integrity uses a multitiered architecture to provide improved security and cross-platform 

development features. Security is improved because all information related to your software 

development history can be kept on secure servers and accessed from a common client 

application. Cross-platform development is enhanced because any supported client can 

access members on any supported server. 

The MKS Integrity Server is responsible for all project work on the remote file system, while 

the client (MKS Integrity) manages all file work on the local user’s file system. Using a client, 

remote developers, managers, and Web developers can access MKS Integrity through a Web 

browser client, such as Internet Explorer or Mozilla. 


Client 

Issues and 

Change Packages 

Implementer 

iSeries 400 

Customer Browsers 

MKS 

Integrity 

Server 

IFS 

Development 

Verification Phase 

Testing 

Deployment Phase 

Production 

MKS Source 

Client 

Projects and 

Archives 

Sandboxes 

Using a multitiered architecture, the integration presents a beginning-to-end story for 

managing change 

197


The iSeries Component 

198 

The Implementer and MKS Integrity integration manages software applications across your 

enterprise with a streamlined process for the creation and approval of mission-critical 

business applications. Based on a unique, open, application server architecture, the solution 

includes: 

workflow (MKS Integrity) for collaboration, approval, and change management 

host based version control (Implementer) and configuration for software management 

client/server and Java version control (MKS Source, formerly Source Integrity® 

Enterprise) and configuration for software management 

promotion and deployment (Implementer) for the movement of software changes to QA 

and production 

Process and Workflow 

Managers have a window into the development process, allowing them to monitor the 

progress of issues and changes. Resolving issues is accomplished through an integrated 

change management process facilitated by a common software architecture between 

MKS products. 

Issues 

MKS Integrity uses issues to track changes during the software development cycle. Problems, 

solutions, and tasks are all examples of issues. Issues can be related to each other for 

reference, easy tracking, and monitoring. For example, a solution may be associated with a 

problem and the relationship allows you to capture the data on the problem resolution 

during different stages of the development process. Each issue has an audit trail, which may 

be used to evaluate internal processes for the effectiveness of the problem resolution process. 

Types 

Issue types describe different categories of issues, such as a change request, problem, solution, 

or task. For example, you can use one type for issues that record deficiencies in design. You 

can use another type for issues that request design changes to fix problems, or to propose 

enhancements or new functionality for your component. Similarly, you can use a type for 

issues that assign work tasks to address problems or to suggest and implement solutions. 

MKS Integrity is an extremely flexible issue management system. MKS Integrity allows any 

number of types. Each type can have its own defined workflow of allowed state transitions 

and its own user defined set of fields.

Workflow 


Every type follows a workflow, which is defined for every issue of that type. Workflow is the 

process established by an administrator to capture and track information and steps during 

your software development cycle. Each issue type has its own set of states to advance through 

the development cycles. For example, a change request might go through the states: new, 

approved, coding, testing, and deployed. States can also be shared across several workflows. 

Issues and their current states provide change management information necessary to support 

business decisions. 

MKS Integrity helps you manage issues by assigning them to responsible groups and by 

tracking and enforcing rules of your workflow. The ability to monitor the progress of issues 

at any time means they can be handled in a timely manner. By running reports on the issue 

data, you are able to identify problem areas that require attention and evaluate the 

effectiveness of improvements over time. 

As part of the integration with Implementer, you can track changes to members through an 

issue’s change package. An Implementer change package reflects the iSeries development done 

to resolve the issue. For example, a solution’s change package contains all members that were 

changed to fix a problem. 

The following rules apply when using issues and Implementer change packages: 

Each change package reflects the members effected for a single production environment. 

Multiple change packages are created for a single issue when multiple production 

environments are affected. For example, this is the case when making a software fix to an 

older version as well as to the new release. If an issue needs to be fixed in more than one 

application, a new change package is created for each application, keeping each fix 

separate. 

Development progress in Implementer optionally updates the state of an issue to reflect 

the development progress within Implementer. For example, when a member is checked 

out for an issue, the issue state could be automatically set to “Coding”. When all changes 

for an issue are promoted to quality assurance, the state could be automatically set to 

“Testing”. 

Implementer development activities are controlled by an issue’s workflow. 

An issues change packages close automatically by promoting the members forward to a 

production environment. 

The seamless integration between Implementer and MKS Integrity ensures that all iSeries 

development activity not only conforms to standard version control mechanisms within 

Implementer, but it extends these controls by ensuring that the corporate workflow for 

process management setup within MKS Integrity is never violated by a single development 

action. Then as a result of iSeries development, the enterprise wide issue tracking system is 

updated automatically to communicate the issue state change throughout the organization. 

Throughout the development process, each member being worked on is individually tracked 

on the MKS Integrity issue. 

199


200 

The following diagram illustrates this extensive integration. 

Implementer Actions M KS Integrity 

Path 

DEV 

new state 

“Coding” 

QAC 

new state 

“Testing” 

PRD 

new state 

“Deployed” 

Issue Created by Authorized User 

Issue created by authorized users using browser access 

Issue Approved by Issue Review Board 

Issue updated by an issue review board 

Implementer Checkout 

Verifies state change allowed from “Approved” to “Coding” 

V erifies current state has “checkout” capability 

Copies members to DEV environment library 

Creates change package for environment PRD 

Adds member with status of “checkout” 

Changes issue state to “Coding” 

Implementer Promotion to QAC 

Verifies state change allowed from “Coding” to “Testing” 

V erifies current state has “prom ote to Q AC 1” capability 

Moves members to environment QAC 

Updates status of change package entries to “In QA1” 

Updates change package status to “In QA1” 

Updates issue state to “Testing” 

Implementer Promotion to PRD 

Verifies state change allowed from “Testing” to “Deployed” 

Verifies current state has “promote to Production” capability 

Moves members to environment PRD 

Updates status of change package entries to “In Prod” 

Updates change package status to “In Prod” 

Closes the change package 

Updates issue state to “Deployed” 

The integration with MKS Integrity allows you to: 

create and close change packages 

add members/objects from Implementer to an issue’s change package 

track each member, how the member was changed, and where the member currently is 

within the development process 

view MKS Integrity change package information from Implementer 

view Implementer information from MKS Integrity 

Workflow State Capabilities 

Approved 

Deployed 

The change package provides the common thread through the integration. Implementer 

documents the changes made to your members, and also tracks who made them, when they 

were made, and the reasons why. 

New 

Coding 

Testing 

Not applicable 

Check out 

Check out 

Promote to QA 

Promote to Production 

Not applicable


The following illustrates how the integration between Implementer and MKS Integrity 

works: 

1 You create an issue in MKS Integrity. For example, the issue requests a bug fix for a 

software installation problem. 

2 The developer performs a check out within Implementer that automatically creates an 

Implementer change package. Likewise, developers can automatically create a change 

package from the Workbench, by assigning an issue to a lock in the Lock Detail panel, or 

by assigning an additional issue in the Multiple Issues panel. The change package is 

assigned an ID and is in an open state. 

3 Once the changes or additions necessary to satisfy the issue are complete, the developer 

promotes the members. 

4 The issue moves to the state in the workflow defined for the environment. For example, 

the issue is moved from the Test state to the QA1 state. 

Sample Workflow 

You can define this feature to any MKS Integrity state that is defined within the environment 

workflow. For the purpose of this document however, the setup steps and examples illustrate 

the generation of Implementer requests when an issue reaches a state of “Ready for QA”, 

based on the following workflow: 

Submitted 

In Development 

work is in progress 

work is in initial unit test state 

Ready for QA (manually set) 

work has passed initial unit test and is considered ready for promotion into QA 

environments 

an MKS Integrity user manually sets an issue to this state when the corresponding 

objects have passed initial unit testing and are ready for promotion to QA 

environments 

In QA1 

objects have successfully promoted into the first set of QA environments 

Promoting Implementer Requests From MKS Integrity 

You can create and submit promotion requests from within Implementer or from within 

MKS Integrity. When promotion activities are performed from Implementer, it is standard 

Implementer promotion processing. 

201


202 

A separate feature allows you to create and submit promotion requests from within 

MKS Integrity, without having to use a separate iSeries session. This functionality is 

accomplished through Implementer’s command processing capabilities, as well as the event 

trigger functionality of MKS Integrity, and Java scripting. 

When the state of an issue changes to a specific user-defined state within the workflow, an 

MKS Integrity event trigger runs the JavaScript that establishes a connection to the iSeries 

and issues the call to the Implementer Add Issue Objects to Clipboard (IADDCBDISS) 

command. The IADDCBDISS command adds to the Implementer Clipboard all objects 

locked to a specified issue. Once the objects are successfully copied to the Clipboard, the 

Implementer Create Request (ICRTRQS) command automatically creates and submits a 

request to promote the objects. 

All messaging related to promotion processing occurs on the iSeries. If problems occur with a 

promotion, e-mail notification is sent to the MKS Integrity user ID for problem analysis and 

resolution. This feature has setup requirements in addition to setting up the basic integration. 

For MKS Integrity setup, see page 212. For Implementer setup, see page 242. 

Assumptions and Requirements 

MKS assumes both Implementer and MKS Integrity are configured and working successfully 

independently. 

The standard requirements for promotion request processing apply to using this feature. For 

example, Implementer validates user authorities to ensure the MKS Integrity user who 

invokes the script has the capability to create and submit promotion requests in Implementer; 

thus, the MKS Integrity user responsible for issuing requests must be defined to an 

Implementer user profile. The Implementer user profile is subject to all standard capability 

checks, for example, environment authorities and authority to promote. 

Similarly, the rules and requirements applicable to each promotion related feature also apply, 

such as related object and related request processing. 

CAUTION By not associating the MKS Integrity user to an Implementer user profile, 

embedded commands in the script fail. 

The Implementer and MKS Integrity integration described in this guide requires: 

Implementer 2006, which requires an iSeries system running OS/400 V5R1 or later, or 

i5/OS V5R3 or later. This is assumed installed and configured. For details on installing 

Implementer, see the MKS Implementer 2006 Installation Guide. 

MKS Integrity 2005 or later. This is assumed installed and configured. However, for the 

latest features you must have MKS Integrity 2006 or later installed and configured. For 

details, see the MKS Integrity Server 2006 Installation Guide.


An active TCP/IP connection between the iSeries running Implementer and the system 

running MKS Integrity Server. 

You must configure the Implementer Server. For details, see “Configuring the 

Implementer Server” on page 217. For details on managing the Implementer Server, see 

page 223. 

Run the Implementer conversion that sets MKS Integrity as the default issue tracking 

system. For details, see “Converting From DesignTracker to MKS Integrity” on page 243. 

The Implementer and MKS Source integration has additional requirements. For details, 

see “Implementer and MKS Source Integration” on page 259. 

The following table summarizes the tasks required for the integration between Implementer 

and MKS Integrity. It also tells you where to find additional information related to setting up 

the integration. 

The table includes steps required specifically for installing and setting up the MKS Integrity 

Server. For complete details on installing and configuring the MKS Integrity Server, see the 

MKS Integrity Server 2006 Installation Guide. 

To Do This … See … 

Understand the system requirements before you 

start the installation. 

MKS Integrity Setup and Administration 

“Assumptions and Requirements” on 

page 202. 

Set up MKS Integrity for the integration. “MKS Integrity Setup and Administration” on 

page 203. 

Set up the Implementer Server. “Configuring the Implementer Server” on 

page 217 

Set up Implementer for the integration. “Implementer Setup and Administration” on 

page 216. 

Manage the Implementer Server. “Managing Implementer Server” on page 223. 

Convert from DesignTracker to MKS Integrity and 

perform a data conversion, if necessary. 

“Converting From DesignTracker to 

MKS Integrity” on page 243. 

Use the Implementer/MKS Integrity integration. See the MKS Implementer 2006 User Guide. 

Perform emergency operations, if required. “Emergency Update Mode” on page 255. 

MKS Integrity is flexible—you can customize it in any way that meets your business needs. 

Setting up MKS Integrity involves an assessment of your current product development 

process to allow you to effectively design an installation that reflects your business practices. 

203


204 

This assessment involves no direct interaction with the software. Instead, you need to spend 

some time evaluating the product development process currently followed in your 

organization and map it so you can customize your MKS Integrity project to suit your needs. 

This may take longer for some than for others. But the purpose of the assessment is to avoid 

the time-consuming task of redesigning a project that was not well-planned in the first place. 

When undertaking this assessment, you should focus on these areas: 

your workflow and project state transitions 

your current tracking mechanism 

the scope of implementation within your organization 

the relevant teams and user groups 

Once the assessment is complete, you can proceed to customizing your installation and refer 

to this assessment when setting up MKS Integrity. To set up MKS Integrity, you need to 

define users, groups, projects, states, types, and fields, as well as set up e-mail notification. 

For details on assessing your current product development process or setting up 

MKS Integrity, see the MKS Integrity Server 2006 Administration Guide. 

NOTE Administrative functions such as users, groups, projects, states, types, fields, 

and triggers are accessible only from the MKS Integrity Administration Client 

graphical user interface (not from the Web interface). 

When you have completed setting up MKS Integrity, refer to the following sections for 

information specific to setting up MKS Integrity for integration with Implementer: 

“Configure the MKS Integrity Server for Implementer Server” on page 204. 

“Manage States and State-based Capabilities” on page 208. 

(Optional) “Enable Promotions From MKS Integrity” on page 212. 

For a checklist of the tasks required to configure the Implementer and MKS Integrity 

integration, see “MKS Integrity Integration Setup: Task Checklist” on page 295. 

Configure the MKS Integrity Server for Implementer Server 

The tasks associated with configuring the MKS Integrity Server for the Implementer Server 

include the following: 

configure security ACLs (based on your version of MKS Integrity Server) 

set change package authorities 

modify the MKS Integrity Server configuration file IntegrityClientSite.rc 

The MKS Integrity administrator who has knowledge of working with the MKS Integrity 

administration functions typically performs these tasks.

Configuring MKS Integrity Server ACLs 


Implementer requires an MKS Integrity user ID to proxy all commands sent to 

MKS Integrity. MKS recommends you create a new user ID, for example, iSeries, with a 

password that does not expire specifically for this purpose. This should be a user ID you 

normally do not log in with. Be sure to create the user ID on both your network and in 

MKS Integrity. This is also the user ID you define in Implementer as described on page 230. 

In MKS Integrity, this user ID requires: 

set up in its own unique group, for example, implementer developer group (the 

group should include only users who create and modify Implementer change packages) 

special privileges set up through the Impersonation ACL to perform work on behalf of 

the actual Implementer user for certain commands 

On the MKS Integrity Server, user access is controlled by permissions on ACLs through the 

Authorization Administration system. The MKS Integrity administrator typically performs 

ACL configuration. For details, see the MKS Integrity Server 2006 Administration Guide. 

NOTE The following task uses the MKS Integrity Web interface to configure ACLs; 

however, you can also use the MKS Integrity Administration Client. If using the 

client interface, modify the steps as needed. 

To configure the security ACLs for Implementer Server 

1 On the MKS Integrity Server, click Start MKS Authorization Administration. 

2 Add the following required ACL entries: 

mks:impersonate:group: 

principle: 

Impersonate allowed 

mks:im 

Admin allowed 

IMPORTANT In this example, implementer developer group is the MKS Integrity 

group that all Implementer users are a member of. Change this variable to reflect the 

group name you created. To avoid compromising your security, use a group other 

than the everyone group; by default, all users are part of this group. 

Customizing Permissions for the Implementer Change Package Type 

This is a required task that restricts users from the ability to modify user defined change 

packages outside of Implementer. This is necessary to ensure Implementer change packages 

remain synchronous between Implementer and MKS Integrity. 

205


206 

The Super Administrator with Admin permission under the mks:im ACL is permitted to 

manage permissions for the Implementer change package type. 

You customize the permissions for Implementer change packages using the following 

command: 

im editcptype implementer 

Using the --permittedGroups option, the Super Administrator controls which groups are 

allowed to view Implementer change packages. By default, the everyone group is permitted 

to view Implementer change packages. 

IMPORTANT Once new permissions are set for the Implementer change package type, 

the default settings are overwritten. If you set new permissions where no 

parameters are specified, then no one can view Implementer change packages. 

You perform the following task using the command line interface (CLI) in MKS Integrity. For 

details, see the MKS Integrity 2006 CLI Reference Guide. 

To customize permissions for the Implementer change package type 

From the command line interface, issue the following command: 

im editcptype -permittedGroups=,:modi 

fy implementer 

for example, 

im editcptype -permittedGroups=implementerdevelopergroup,implementerintegrationgrou 

p:modify implementer 

Modifying the MKS Integrity Server Configuration File 

This task is required for the ability to execute MKS Integrity and MKS Source commands 

from within Implementer or WDSc. It also provides a comprehensive feature that allows 

Implementer users to invoke MKS Integrity and MKS Source GUI gestures from their 

workstation. 

NOTE The MKS Integrity Client must be available to use this feature. 

The following table lists the GUI interactions available for each respective Implementer user.


User 

To modify the MKS Integrity Server configuration file 


IMPORTANT The IntegrityClientSite.rc communications file is located in the 

default installation directory of the MKS Integrity Server and the default installation 

directory of each MKS Integrity Client. You must modify the file in each location. To 

allow a developer to update the communications file on their desktop, the 

instructions for updating the MKS Integrity Client are also included in the 


1 Using Notepad or a similar text editor, open file IntegrityClientSite.rc as follows: 

On the MKS Integrity Server, the file is located in the directory /config/client. 

On the MKS Integrity Client, the file is located in /MKS/IntegrityClient. 

2 Verify the following line is not commented out: 

daemon.connectionPolicy=mks.ic.common.policy.ICAllowSpecificConne 

ctionPolicy 

3 Add or update the following statement: 

daemon.validConnectionList=127.0.0.1,xxx.x.x.x 

where xxx.x.x.x is the IP address of Implementer Server. 

4 Save the file and exit. 

MKS Integrity GUI Gesture MKS Source GUI Gesture 

Administrator Perform initial setup. 

Activate integration and 

communications between 

Implementer and MKS Integrity. 

Developer Select issues. 

View and edit issues from the Select 

Issue or Multiple Issues panel. 

View the issue summary and URL 

location of an issue. 

Perform initial setup. 

Activate integration and 

communications between 

Implementer and MKS Source. 

Activate MKS Source archiving for 

Implementer products. 

Create development path in 

MKS Source. 

Populate MKS Source projects. 

Checkpoint projects. 

Check out a specific revision. 

Copy from specified environment and 

select highest revision. 

View member history and annotated 

views from within the Workbench, 

Work with Objects, and WDSc. 

207


208 

Manage States and State-based Capabilities 

Throughout the product development lifecycle, issues submitted in MKS Integrity follow a 

workflow. You can customize the workflow and the stage the issue is in. These stages are 

states in MKS Integrity. For example, your process may include resource allocation, research, 

coding, quality assurance testing, and production. Or your process can be more elaborate. 

Further, each issue type can follow a unique workflow. 

State Usage Within Implementer 

In Implementer, promotion path entries are used to designate the different development 

locations. They also correlate to states in MKS Integrity, and define the default mapping 

between Implementer environments and the state of issues for members in those 

environments. 

Implementer has three default promotion paths: *TST, *QAC1, and *PRD. You can create 

additional *QAC paths as needed, for example, *QAC2, *QAC3, *QAC4. Promotion path 

entries are defined in the MKS Integrity State setup, option 47 from the Implementer Menu. 

NOTE For details on MKS Integrity state setup in Implementer, see “State Setup in 

Implementer” on page 232. 

Implementer State-based Capabilities 

In MKS Integrity, you assign Implementer capabilities to the states used during Implementermanaged 

development. State-based capabilities correlate to the Implementer promotion path. 

They define the Implementer functions (check out, promotion, and rejection) that are allowed 

or not allowed for members while an issue is in a defined state. 

The following state based capabilities (state transitions) are created in MKS Integrity after 

you run F8=Configure MKS Integrity from Implementer’s MKS Integrity State Setup panel 

(as described on page 233). The capabilities are based on the default path entries in 


allows checkout to a development environment in Implementer 

allows promotion to QAC environment number 1 as defined in the development path in 


allows rejection of changes from a quality assurance environment back to a development 

environment in Implementer 

allows promotions to a production environment in Implementer 

The following example shows the state based capabilities that apply to the following 

workflow: 

Submitted > Checkout > QA1 > QA2 > In Production

State MKS Implementer State Based Capability 

To work with states and state based capabilities in the MKS Integrity 

Administration Client 


Submitted Allows check out to development environment in Implementer. 

Checkout Allows check out to development environment in Implementer. 

Allows promotion to QAC environment #1 as defined in the development path in 


QA1 Allows promotion to QAC2 environment #2 as defined in the development path 

in Implementer. 

Allows rejection of changes from quality assurance environment back to 

development environment in Implementer. 

QA2 Allows promotion to production environment in Implementer. 

Allows rejection of changes from quality assurance environment back to 

development environment in Implementer. 

For multiple QA environments, select additional promotion capabilities as 

needed. For details, see “Implementer State-based Capabilities” on page 208. 

In Production None. Once member object is promoted to production, all Implementer change 

packages automatically close. 

In the MKS Integrity Administration Client, under MKS Integrity, select States. The 

States view displays. 

Any changes you make in the States view have an immediate effect in your MKS Integrity 

database. Dialog boxes opened from the States view contain Cancel buttons for canceling 

operations. 

209


210 

Creating States 

You can create states for use in an issue type’s workflow. You can only create one state at a 

time. For details on creating states, see the MKS Integrity Server 2006 Administration Guide. 

To create a state in the graphical user interface 

1 From the States view, do one of the following to display the Create State dialog box: 

Select State > Create. 

Right click and select Create. 

Click 

2 In the Name field, enter a name for the state. This is the name the state is referred to in 

MKS Integrity. 

3 Under the Description tab, you can enter a more detailed textual description of the state, 

such as the state’s meaning in your workflow. To do this, click the Description tab. 

4 Under the Position tab, you can specify where the new state displays in the State list 

within an issue. Use the Move Up and Move Down buttons to change the position of the 

new state. 

5 Under the Image tab, you can associate a custom icon image with the state. To do this, 

select Use Custom Image, and click Select to browse for the image file. To have no image 

associated with the type, select No Image. 

If you choose to use your own custom icon image, the image must be in GIF or JPEG 

format, and no larger than 24 by 16 pixels.


6 Under the Capabilities tab, you can define state-based capabilities. State based capabilities 

allow the check out, promotion, or rejection of members in Implementer while an issue is 

in a given state. 

If the issue state does not allow open change packages, MKS Integrity prompts you to 

close the issue’s change package before you move any issue to that state. 

If an issue state does not allow open change packages, you cannot create new change 

packages for any issues in that state. 

To display all available state-based capabilities, from the Filter list select . 

To display only enabled state-based capabilities, from the Filter list select 

. 

To define Implementer state-based capabilities: 

a) From the Filter list, select MKS Implementer to display only the state-based 

capabilities related to this integration. 

b) From the list, select the development activities that are allowed while an issue is in 

this state. 

IMPORTANT If using the MKS Source integration as described in “Implementer and 

MKS Source Integration” on page 259, the development state (*TST) must have the 

capability Allows open SI change packages to exist. 

211


212 

7 When you are finished setting the new state’s properties, click OK. 

IMPORTANT The following setup tasks are required only to promote Implementer 

requests from within MKS Integrity. If you do not plan to use this alternate 

promotion feature, go to “Implementer Setup and Administration” on page 216 and 

complete the Implementer setup as described. 

Enable Promotions From MKS Integrity 

This is an optional feature that allows you to create and promote Implementer requests from 

within MKS Integrity. This feature has setup tasks in both MKS Integrity and Implementer. 

This section describes the setup tasks required in MKS Integrity. For details on the 

Implementer setup tasks, see “Enable Promotions From MKS Integrity” on page 242. For an 

overview of the feature, see “Promoting Implementer Requests From MKS Integrity” on 

page 201. 

Review and perform the following MKS Integrity setup requirements: 

Verify that the states applicable to your use of this feature exist within your 

MKS Integrity workflow. Add the states needed. 

Verify an e-mail server is defined in the MKS Integrity im.properties or 

is.properties file (for problem notification). 

Verify an e-mail address exists for the MKS Integrity user ID responsible for changing 

issue states that cause the creation of promotion requests (for problem notification). 

Modify a JavaScript file with user-defined values. 

Add a new trigger for the state change. 

Basic information on completing these tasks is described next. For detailed information, see 

the MKS Integrity Server 2006 Administration Guide. 

Modifying the JavaScript File 

The JavaScript file PromoteIssue.js. is located in the default directory: 


If the MKS Integrity Server is running with debug log enabled, the actual commands that are 

executed from the script display in the log. The debug log is enabled through the 

logger.properties file located in the directory /config/properties. 

TIP MKS recommends you have someone with JavaScript skills perform the script 

modifications. 

To modify the JavaScript File 

1 Open file PromoteIssue.js using any text editor. 

2 Set the following variables defined in the script. Use the comments embedded in the file 

to help determine how to set the values. Specify the following values: 

iSeriesName is the iSeries system to connect to where Implementer is installed. This 

can be the TCP/IP host name or the IP address. 

userProfile is the Implementer user profile on the iSeries that is used to connect to 

the system, for example MWIPROD. 

NOTE This user profile is for internal purposes—promotions are not submitted by 

this user profile. Promotions are submitted using the user profile that changed the 

issue state. 

userPassword is the password for the Implementer user profile defined in the 

userProfile variable. 

implementerLibraryList is the Implementer library list used to run Implementer 

commands. 

You can optionally change the following variables in the script: 

createRequestCommand is the command that creates and submits the Implementer 

promotion request. You can change any of the command parameters except 

FRMLIB, FRMENV, and MBROBJ, which require the value *CLIPBOARD. The 

OPTIMIZE parameter defaults to *YES. You can change the value to *NO if 

necessary. For details on this topic, see the MKS Implementer 2006 User Guide. 

fromEmail is the e-mail address that sends an e-mail to notify when a problem is 

detected on the iSeries. 

3 Save any changes to the file. The JavaScript does not require compiling. 

Creating an Event Trigger 

The event trigger you define in MKS Integrity must be rule based. It is used to call the 

supplied JavaScript code, which in turn establishes a connection to the specified iSeries 

system and issues several Implementer commands to create and submit the promotion 

requests on the iSeries. 

213


214 

The following tasks describe how to define the trigger for this feature. For details on event 

triggers, see the MKS Integrity Server 2006 Administration Guide. 

To define an event trigger 

1 Open an MKS Integrity Administration Client session and navigate to the Triggers view. 

2 Do one of the following to display the Type panel on the Create Trigger dialog box: 

Select Trigger > Create. 

Right click and select Create. 

Click . 

3 In the Name field, specify a name for the new trigger, for example, Promote Issue. 

4 Select Rule Based Change Trigger. 

5 (Optional). To enter a description for the event trigger, click the Description tab. 

6 On the Description panel, specify a description in the field. 

7 Click the Rule tab to define a rule for the trigger. The Rule panel displays.

a) Under Condition, select the prime field State' from the Field list. 


A prime field, indicated by a prime symbol ('), specifies a new value or condition 

for the selected field, and primarily captures a change from one condition to 

another. For example, in a workflow with the states Submitted > In 

Development > Ready for QA > In QA > Release, the rule based trigger 

performs the action whenever an issue is changed to the Ready for QA state 

(State'=Ready for QA). 

You can define the trigger to any state change that is defined to the MKS Integrity 

workflow. 

b) From the Operator list, select the equal to (=) operator. 

c) Select the Constant option. This allows you to select a state value for the field 

specified in the Field list, for example, Ready for QA. 

Be sure to select the state that corresponds to when you want the trigger to run. 

The trigger runs when the issue state changes to this value. 

d) Click Add to add the condition to the rule. 

8 To select the JavaScript for the new trigger, click the Trigger tab. The Trigger panel 

displays. 

215


216 

9 To specify the script file the event trigger runs, do one of the following: 

a) In the Script File field, type PromoteIssue.js (the name of the JavaScript file). 

a) Click Browse to select the file from the Select Trigger Scripts viewer. 

10 Enable the Post option to schedule the trigger to run after the state changes to the 

specified value. 

11 Click OK to create the trigger. 

You are ready to perform the Implementer setup and administration tasks as described next. 

Implementer Setup and Administration 

The Implementer Server is the foundation for many Java-based processes invoked by 

Implementer. It is the gateway to MKS Integrity integration. The Implementer Server 

significantly reduces the scope of effort involved with managing the integrations between 

Implementer, MKS Integrity, and MKS Source. Flexible by design, Implementer Server 

supports running one or more copies of Implementer on one iSeries system integrated with a 

single copy of MKS Integrity. It also allows MKS Integrity to remain active when 

Implementer is shut down for a backup. 

After converting from DesignTracker to MKS Integrity and completing the MKS Integrity 

setup and administration tasks, you are ready to perform the Implementer setup and 

administration tasks. These tasks include:

“Configuring the Implementer Server” on page 217. 

“Managing Implementer Server” on page 223. 

“Defining MKS Integrity Values in Implementer” on page 226. 

“State Setup in Implementer” on page 232. 

“User Profile Setup” on page 235. 

“Environment Setup” on page 237. 

“Enable Promotions From MKS Integrity” on page 242. 


If you use the release management features of Implementer, you must also compete the 

field mapping as described in the table beginning on page 231. 

Complete the setup tasks in the order listed. For a checklist of the tasks required to configure 

the Implementer and MKS Integrity integration, see “MKS Integrity Integration Setup: Task 

Checklist” on page 295. 

When performing these tasks, Implementer validates the supplied information with 

MKS Integrity. This requires active communications between the two products. For 

information on managing the Implementer Server, see page 223. 

Configuring the Implementer Server 

The Implementer Server runs on the iSeries. A single Implementer Server functions for a 

single installation of Implementer. 

The server automatically installs into the default IFS installation directory on the iSeries 

when you initially install or upgrade Implementer. The default installation directory is: 

/MKS/Implementer/MKSIM/server 

The Implementer Server can also run on the following platforms: 

PC running Windows 2000 Server, Windows 2003 Server, or Windows XP Professional, 

in close physical proximity (and a local Ethernet connection) to the iSeries. 

Integrated xSeries (IXS) running Windows 2000 Server, Windows 2003 Server, or 

Windows XP Professional. 

For details on installing and configuring Implementer Server to run on a PC, see “Install 

and Configure Implementer Server on a PC” on page 220. Follow the same instructions 

to run the server on an IXS. 

IMPORTANT When running Implementer Server on a PC, the tasks associated with 

installing, upgrading, and running the server are manual. 

UNIX variants. For information on installing and configuring Implementer Server to run 

on UNIX, see “Install and Configure Implementer Server on UNIX” on page 222. 

217


218 

If you have any third party exit program packages installed to augment system security, you 

must configure the programs to allow: 

ODBC/JDBC communication. 

Remote command execution (using client access/iSeries access server). 

You must define the exit programs to allow communication from the system Implementer 

runs on, which may be a localhost, and the user profile specified in the IMCMNUSR data 

area (MWIPROD is the default data area value). 

Configure Implementer Server on the iSeries 

The Implementer server requires Java Virtual Machine (JVM) 1.4 installed on the iSeries. JVM 

1.4 requires OS/400 V5R1 or later, or i5/OS V5R3 or later. 

This task allows you to define the control parameters for the Implementer Server. Your 

Implementer user profile must have authority to System Control Maintenance to perform the 

following setup tasks. 

To configure the Implementer Server 

1 From the Implementer Menu, type option 49, Implementer Server, and press ENTER. 

2 Complete the fields as described in the following table. When you have finished entering 

the information, press ENTER.

Field Name Description 

Implementer Server Setup Field Descriptions 

Current Status Current status of Implementer Server. 

Use Implementer 

Server 


Started: Communications between Implementer Server and Implementer 

are active. 

Starting: Communications between Implementer Server and Implementer 

are in the process of being activated. 

Stopped: Communications between Implementer Server and 

Implementer are currently not active. 

Suspended: Communications between Implementer Server and 

Implementer are on stand-by. 

Specify whether Implementer Server is configured to perform specific 

functionality within Implementer. 

Y: Implementer Server is configured. 

N: Implementer Server is not configured. 

Host address Specify the IP address or host name of the system running Implementer 

Server. This address is used for all communications between Implementer 

and Implementer Server. 

Valid characters are A–Z, a–z, 0–9, dash (-), underscore (_), and period (.). 

The default value is localhost. Case usage is not significant. The host 

address is not validated. 

Do not enclose the IP address in quotes. For example, 192.168.10 is a 

valid address; "192.168.10" is an invalid address. Do not specify a URL 

that begins with HTTP:// or HTTPS://. 

Server port Specify a unique number between 1 and 65535 for the HTTP port 

Implementer Server listens on. MKS recommends you use a number higher 

than 1024. The default value is 8080. 

Adapter port Specify a unique number between 1 and 65535 for the port Implementer 

uses to communicate with Implementer Server. MKS recommends you use 

a number higher than 1024. The default value is 54545. 

Logging level Specify the level of detail for Implementer Server to log. 

*INFO logs all informational and warning messages. This is the default 

value. 

*WARN logs warning messages only. 

*DEBUG logs all messages. This level should be used only when 

instructed by MKS Customer Care. 

Startup delay Specify the number of seconds Implementer waits between communication 

attempts once the start command is issued to start Implementer Server. 

The default value is 30. 

Startup retry count Specify the number of times to retry communications before ending the job 

with a communication failure. The default value is 5. 

Log files to retain Specify the number of days worth of log files to retain in the Implementer 

Server logs directory. The cleanup task runs every six (6) hours to remove 

old files. Specify zero (0) to retain all log files. The default value is 30 (days). 

219


220 

Field Name Description 

Time zone offset Specify the number of hours difference between this system and Greenwich 

Mean Time (GMT). For example, a system located in Central Standard Time 

(CST) has the offset value -6. Valid values are -12 through +12, or 

*SYSVAL, which allows you to use the Coordinated Universal Time Offset 

(QUTCOFFSET) system value. 

The time zone offset is required for Implementer and MKS Integrity to be 

relatively synchronized in time. For example, if Implementer is located in the 

Central time zone and MKS Integrity is in the Eastern time zone, there is 

one hour difference between the two servers. By defining the time zone 

offset, a change package’s date and time fields are correctly represented in 

the time zone where the server is located. 

IMPORTANT You must restart Implementer Server to effect changes to the time 

zone offset value. 

Install and Configure Implementer Server on a PC 

Implementer Server can run on a PC or an Integrated xSeries (IXS) running Windows 2000 

Server, Windows 2003 Server, or Windows XP Professional. When installed on a PC, 

Implementer Server runs as a service to ensure it starts automatically when the PC starts. 

Implementer Server can run from any location except the desktop. The desktop is regarded as 

a user’s private space, and as such, you should not run system processes and services from it. 

MKS recommends you install it in a directory near the root, for example, 

c:/Implementer_200x_Server. 

IMPORTANT 

MKS recommends you install the latest Database Group PTF, obtainable from 

IBM, before running the Implementer Server on a PC. 

When running Implementer Server as a service on a PC, you must manually 

perform the tasks associated with installing and upgrading the server, and the 

initial startup of the service. 

After initially installing Implementer and after each subsequent upgrade, you 

must manually copy the server directories to the PC and install the service. 

The tasks associated with setting up Implementer Server to run on a PC or IXS are as follows: 

Manually copy the server directory from the IFS installation location on the iSeries to the 

target PC. 

Configure the Implementer properties file with system-specific values. 

Install the NT service. 

Implementer Server Setup Field Descriptions

To copy Implementer Server from the iSeries to the target PC 


1 Sign on to the iSeries with a user profile that has authority to access the Implementer 

Server directory, for example, use a *SECOFR user profile. The default, IFS installation 

location of the Implementer Server is: 


2 Using a tool such as Windows Explorer or iSeries Navigator, copy the entire 

Implementer Server directory from the IFS on the iSeries to the target PC. You may need 

to map to the drive first. Be sure to include /ROOT in the directory path of the target 

location. 

To configure Implementer Server properties file 

1 In the root of the Implementer Server directory on the target PC, locate the 

ImplementerServer.properties file. 

2 Using a standard text editor, such as Notepad, open 

ImplementerServer.properties. 

3 Modify the following variables based on the system where Implementer is installed: 

IMPLEMENTER_HOST is the host name or IP address of the iSeries. 

IMPLEMENTER_LIBRARY is the Implementer product library. Implementer ships in 

library MKSIM. 

IMPLEMENTER_USER is the user ID authorized to the Implementer product library. 

It must correspond to the user ID defined in the IMCMNUSR data area in the 

Implementer product library on the iSeries. 

This user ID must have *CHANGE authority to all Implementer database files. 

MKS recommends you use the default user profile MWIPROD. 

IMPLEMENTER_PASSWORD is the password for the IMPLEMENTER_USER. It must 

correspond to the password defined in the IMCMNUSR data area. 

INTEGRITY_CLIENT_PORT is the port that all workstations running MKS Integrity 

Client Client listen on when invoking GUI functions from Implementer or WDSc, 

for example, issue display, annotated view, or member history. All workstations 

running MKS Integrity Client that invoke GUI functions from Implementer must be 

listening on the same port. The default value is 31000. This is an optional property. 

Once you configure these values in the properties file, delete the NOT_CONFIGURED 

line from the file. 

4 Save the changes and close the file. 

221


222 

To install the Implementer Server service 

1 Optionally modify the install-service.bat file as follows: 

The default service name of the server is MKS Implementer Server. Change the 

SERVICENAME environment variable to specify a different service name. This is only 

necessary if more than one Implementer server is running on a single PC. 

To explicitly define the directory where the server runs, change the SERVERDIR 

environment variable as needed. 

2 Execute the install-service.bat file. This removes the existing Implementer Server 

service if it is already set up and installs a new service with any new parameters you 

optionally defined. 

IMPORTANT After performing an upgrade to the Implementer Server, you must reinstall 

the Implementer Server service by running the install-service.bat file. 

If you previously modified the file, for example, changed the service name, you 

must re-enter the changes before executing the file. 

Install and Configure Implementer Server on UNIX 

Implementer Server includes the script runserver.sh that allows you to install and run the 

server on a variety of UNIX variants. This document assumes Solaris. 

Installing and configuring Implementer Server on UNIX requires the assistance of someone 

who is familiar with both the iSeries and UNIX, including basic shell operation. It also 

requires: 

Java Runtime Environment (JRE) 1.4, appropriate for the system, must be installed. 

To verify the JRE version, issue the ‘java -version’ command. You can download 

many JREs from http://java.com/en/download. 

A standard shell scripting language, for example, sh, ksh, bash. 

To install Implementer Server on UNIX 

1 Using your preferred copy method, copy the entire Implementer Server subdirectory 

from the IFS on the iSeries to the new directory on the UNIX system. The default, IFS 

installation location of Implementer Server is: 


If using FTP, you must use ASCII mode for all files that have .properties, .policy, 

.sh, and .xml extensions. 

2 Optional: Turn on the execute permission on the runserver.sh script using chmod. 

3 Optional: Delete the JRE subdirectory from the server directory (it applies to Windows 

systems only).


4 Configure Implementer Server as described in “Configuring the Implementer Server” on 

page 217. 

5 Configure the Implementer Server properties file as described on page 221. 

Managing Implementer Server 

The Implementer Server runs based on the values you have defined in Implementer Menu 

option 49, Implementer Server. To ensure sufficient access to the Implementer database, the 

server job runs under the Implementer user profile MWIPROD. 

The server must be active for successful communications with MKS Integrity and 

MKS Source. When you install the server on the iSeries, the Implementer Server Control 

(ICTLSVR) command allows you to start, stop, suspend, and resume the server. The reload 

option allows you to reload the server with current configuration and environment 

information if communications failed initially. The command also provides status and job 

information when the server is active. 

MKS recommend you add the ICTLSVR command to your normal daily startup routine to 

ensure it activates on IPL (Initial Program Load) by the QSTRTUP program. The user profile 

that issues the ICTLSVR command must have authority to System Control Maintenance. 

Whenever you make a change to the MKS Integrity Server, for example, changes to 

workflow, workflow authorities, or state capabilities, you must restart Implementer Server. 

For information on managing the Implementer server on a PC, see page 224. 

NOTE The Implementer data area IMSRVJVA provides the ability to customize 

certain aspects of Implementer Server. However, this is usually not necessary; 

therefore, MKS recommends you change the data area values only when instructed 

by MKS Customer Care. 

ICTLSVR Command Parameters 

Command 

Specify the command action to perform. 

*START Activates the server. The server job runs under the default user profile 

MWIPROD. This option is not available if the server is running on a PC. 

*STOP Shuts down the server. You must stop the server to upgrade or reinstall 


*SUSPEND Disconnects the JDBC connections from the Implementer database to 

release resources. Disables requests to Implementer by returning a soft 

error. This allows you to secure a backup of the Implementer product 

library. 

223


224 

*RESUME Reconnects the JDBC to the Implementer database. Re-enables requests 

to Implementer. 

*STATUS When Implementer server is active, reports the current status of the 

server and related job information. 

*RELOAD Reloads Implementer server with current information. Use manually to 

reload configuration information, or programmatically to reload 

environment information for MKS Source integration. 

Job Queue/Library 

Specify the name of the job queue and corresponding library that Implementer server runs in. 

The server job activates in this job queue. The default value is IMCOM, a job queue delivered 

in the Implementer product library MKSIM. These parameters are required for the *START 

command option. 

Managing Implementer Server on a PC 

The Implementer Server service starts automatically when the PC starts. If you need to 

manually start the server, from the Windows Control Panel in the System Administration 

group, use the Services application to start the MKS Implementer Server service (or the 

service name you specified if you changed the default value). 

Managing Implementer Server on UNIX 

You must perform the following steps when starting Implementer Server. You can optionally 

automate this task by including the steps in the system startup script. 

To execute Implementer Server on UNIX 

1 Set the JAVA_HOME environment variable to identify the root location of the JRE. 

a) If the Java executable is located in /usr/local/java/jre-1.4.1_02/bin/java, 

then set the JAVA_HOME environment variable to /usr/local/java/jre- 

1.4.1_02. 

b) Optional: You can update the runserver.sh script to include a hard coded 

reference to the JAVA_HOME variable. 


If you enabled the execute permission bit in setup, then invoke the runserver.sh 

script directly from the command line. 

If you did not enable the execute permission bit in setup, then invoke the 

runserver.sh script by invoking sh runserver.sh.

Implementer Server Patches and PTFs 


Implementer provides patches for Implementer Server in the standard Implementer PTF 

format. When a patch for Implementer Server is included with a PTF, the PTF installer 

automatically installs the patch into the server directory. 

The patches usually distribute as CLASS files (as opposed to JAR files) to allow applying 

incremental patches. The class files install into the IFS location: 

/mks/implementer//webapps/ROOT/WEB-INF/classes 

IMPORTANT If Implementer Server runs on a PC, after applying a patch you need to 

recopy the server from the IFS to the system where the server runs. Follow the same 

instructions as when initially installing the server. You do not need to reinstall the 

service. 

When you apply an Implementer Server patch, a marker file is created in the ‘info’ 

subdirectory. The marker file identifies which issue the patch applies to. If you apply 

multiple patches, then multiple marker files are created in the subdirectory. The marker file is 

in the form IMPTFnnnn, where nnnn is the issue number associated with the PTF. 

Troubleshooting Implementer Server 

If you encounter errors with Implementer Server, the Implementer Server log files register 

server activity based on the logging level you define in Implementer Menu option 49, 

Implementer Server. 

Server activity for the current date is stored in file implementer-server.log. When the 

current date changes, implementer-server.log renames to a date differentiated file name, 

and an empty implementer-server.log file is created. The server log files are purged 

based on the number of days you specify to retain on the Implementer Server Setup panel. 

When Implementer Server runs on the iSeries, the server log files are stored in the 

/logs sub-directory of the IFS. The Implementer Display Server Log (IDSPSVRLOG) 

command allows you to view history logs. The command has one parameter, DATE, 

which accepts the value *CURRENT, or a specific date you enter in YYYYMMDD 

format. 

IMPORTANT Your user profile must have authority to System Control Maintenance to 

issue the IDSPSVRLOG command. 

When Implementer Server runs on a PC, the log files are stored in the /logs subdirectory 

on the PC. You can view the history logs using any standard text editor, such 

as Notepad. 

225


226 

Implementer Server must be able to communicate with MKS Integrity Server for the 

integration to work successfully. 

A common diagnostic technique when resolving MKS Integrity connectivity issues is to 

ping the hostname (or IP address) of MKS Integrity Server. This technique is effective 

provided you ping the server from the correct host. 

When Implementer Server is installed on an iSeries, the iSeries must be able to 

communicate with MKS Integrity Server. 

When Implementer Server is installed on a PC, that PC must be able to 

communicate with MKS Integrity Server. In this case, the iSeries is not actually 

communicating with MKS Integrity Server, thus, it is meaningless if you can ping 

MKS Integrity Server from the iSeries. 

If you have Windows XP Service Pack 2 (SP2) installed on the system running 

Implementer Server, the firewall built into SP2 could interfere with server 

communications. You may need to adjust the firewall to allow connections on the Server 

and Adapter ports, or disable it entirely. 

For additional troubleshooting information, see the table on page 302. 

Defining MKS Integrity Values in Implementer 

The MKS Integrity communication parameters are defined in Implementer on the 

MKS Integrity Setup panel. 

Your Implementer user profile must have authority to maintain System Control (defined in 

Work with Users) to change the default values on the MKS Integrity Setup panel. Without 

this authority, changes are not allowed and the panel is protected. 

To define MKS Integrity values in Implementer 

1 From the Implementer Menu, type option 47, MKS Integrity, and press ENTER, or issue 

the STRIM *INTMGRSET command.


You can perform the following functions on the MKS Integrity Setup panel. 

F3=Exit returns to the Implementer Menu without processing any information. 

F6=State setup displays the MKS Integrity State Setup panel to create and modify 

MKS Integrity promotion path state information. For details, see “State Setup in 


F7=Test allows you to test the communications between Implementer Server and 

MKS Integrity Server. Sets the System Available field status based on the result. 

F8=Configure MKS Integrity updates MKS Integrity with the Implementer-related 

state based capabilities that control check out and promotion. You perform this 

function once as part of the initial setup. Thereafter, use it to add additional *QAC 

paths through F6=State Setup. There is no risk in running this function multiple 

times. For details on using this function, see page 234. For a list of the capabilities 

this function adds to MKS Integrity, see “Implementer State-based Capabilities” on 

page 208. 

F9=Apply Pending Changes synchronizes Implementer with MKS Integrity by 

applying any pending updates that were postponed when the MKS Integrity 

emergency update mode was active. For details on using this function, see 

“Applying Pending Changes” on page 257. 

F12=Cancel returns to the previous panel without processing any options. 

227


228 

F20=Convert to MKS Integrity converts the issue management system from 

DesignTracker to MKS Integrity. For details, see “Converting From DesignTracker 

to MKS Integrity” on page 243. 

IMPORTANT 

Other than completely restoring from a backup, you cannot reverse the results of 

invoking this function. Therefore, you must review all related documentation in 

this chapter before running a conversion. When you process the function, two 

confirmation panels display; the panels include important information on the 

function you are about to perform and require a reply. You can cancel the 

procedure from either of the panels. 

This function does not convert DesignTracker data. For details on converting 

data, see page 431. 

2 Complete this panel as described “MKS Integrity Setup Field Descriptions” on page 228. 

(Press PAGE DOWN to access the additional panels.) 

3 When you are finished adding the information, press ENTER. 

4 To ensure communications are active and the setup you have defined is usable by 

Implementer, press F7=Test. 

5 To configure MKS Integrity with the Implementer capabilities, press F8=Configure 


After completing this task, you are ready to perform “State Setup in Implementer” as 

described on page 232. 


MKS Integrity Setup Field Descriptions 

Issue Management System Identifies which product is configured to supply Implementer with 

issue tracking information and represents the current issue 

management system. The default value DesignTracker verifies that 

DesignTracker provides all issue information. The value 

MKS Integrity verifies that MKS Integrity provides all issue 

information. 

The field is input protected. The only way to change the value from 

DesignTracker to MKS Integrity is by running the conversion that sets 

MKS Integrity as the default system. Once, converted, there is no 

way to change the value back to DesignTracker. 

For the integration described in this chapter, the field value must be 

MKS Integrity. If this is not the value, see “Converting From 

DesignTracker to MKS Integrity” on page 243.




MKS Integrity Current Status Identifies the current status of MKS Integrity. Automatically updated 

through communication attempts (input is not allowed). 

System available indicates whether MKS Integrity was available on 

the last attempt to communicate. 

Yes: Communication between MKS Integrity and Implementer was 

successful. 

No: Communication between MKS Integrity and Implementer was 

unsuccessful. 

Pending changes indicates whether Implementer ran in emergency 

update mode when MKS Integrity was unavailable and if updates are 

pending that need to be applied to MKS Integrity. 

Yes: New changes exist that need to be sent to MKS Integrity for 

database synchronization. For details, see “Applying Pending 

Changes” on page 257. 

No: No new changes need to be sent to MKS Integrity. 

MKS Integrity Connection Setup 

The following fields define the communication parameters that allow Implementer to work with 

MKS Integrity and MKS Integrity Server. 

Communications timeout Number of seconds Implementer waits for a valid response after 

contacting the MKS Integrity Server. Only used when MKS Integrity 

is the issue management system. 

If communications between Implementer and MKS Integrity Server 

are slow, set this to a higher number to prevent time-outs during 

normal usage, such as if MKS Integrity Server is available but not 

responding in a timely manner due to heavy traffic or running a large 

query. 

Server Address of MKS Integrity Server. This server address must be 

reachable from the iSeries, as well as work within a clients Web 

browser. It is used to construct a URL. 

Specify either the IP address or a name that both the Domain Name 

Server (DNS) on the iSeries and each client’s Web browser can 

resolve. 

Valid characters are A–Z, a–z, 0–9, dash (-), underscore (_), and 

period (.). Case usage is not verified. 

Do not enclose the server address in quotes. For example, 

127.0.0.1 is a valid address, "127.0.0.1" is an invalid address. 

Server browser port Port number for the MKS Integrity Web interface; the port 

Implementer uses to access the MKS Integrity Web interface from 

Implementer panels. Commonly referred to as the Integrity Server 

Port. It must be different from the Server Implementer Port. 

If the Server field is defined, this is a required field and the value 

must be between 1 and 65535. The default value in the property file 

is 7001. 

229


230 


Server cleanup frequency Number of minutes Implementer waits between the end of an 

MKS Integrity transaction and when the transaction is cleared from 

the database. 

MKS Integrity user ID User ID used for all communication between Implementer Server and 

MKS Integrity Server. This must be the same user ID as described 

and specified in “Configuring MKS Integrity Server ACLs” on 

page 205. This user ID is also used by the IUPDCI command to post 

updates back to MKS Integrity Server. 

Field entry is case sensitive; the case specified in MKS Integrity must 

be specified here. 

Password Password of the MKS Integrity user ID specified in the previous field 

and required for all communications between Implementer Server 

and MKS Integrity Server. Non display field that displays as blank 

when typing the password value. 

Description field User-defined issue description field within MKS Integrity, for 

example, Summary. Contents of this field displays as the long 

description for an issue on Implementer panels. Entry in this field is 

optional. Case specified in MKS Integrity must be specified here. The 

field must be type Long Text. 

Implementer project field For Implementer project tracking in MKS Integrity, specify the name 

of the user defined field within MKS Integrity that contains the 

Implementer project field. The case usage specified here must match 

the case usage applied to the field in MKS Integrity. 

This field value must be defined in MKS Integrity as Short Text or 

Pick data type with a maximum length of seven characters (the field 

name can be longer). Any project values in MKS Integrity must be 

added manually to Implementer. 

After selecting an issue in Implementer using F4=Prompt, the 

appropriate project field populates with the value from MKS Integrity. 

The project reference displays on select Implementer panels, for 

example, the Workbench and Work with Objects. 

iSeries notify user The iSeries user profile to notify when the state of the connection to 

MKS Integrity changes to either available or unavailable. User is also 

notified with the results of the update process when you run a 

synchronization using F9=Apply pending changes. 

Allow co-existence with 

DesignTracker 


Indicates if co-existence with DesignTracker is enabled. The field is 

read only and only applicable if MKS Integrity is the default issue 

tracking system. For details on co-existence, see “Converting From 

DesignTracker to MKS Integrity” on page 243. 

Last allowed DR number Applicable only if DesignTracker co-existence is enabled. Specify the 

last valid design request number when DesignTracker co-existence is 

enabled. Any DR/Issue number higher than the specified number is 

considered an MKS Integrity issue.


Release Management Field Mapping 


Define the following fields to use MKS Integrity and the release management features of Implementer. 

For details, see the MKS Implementer 2006 Release Management Guide. 

Release Management 

Active? 


Specify Y to use the release management features of Implementer 

with MKS Integrity. Activation of this feature requires a value in each 

of the remaining fields. 

Issue type to create Type of issue to create in MKS Integrity for each release you create 

in release management. You must define this release type in 

MKS Integrity specifically for release management use. 

Deleted release state Issue state to assign to an issue when the corresponding release is 

deleted from Implementer (the issue is not deleted). 

Related issues field Type of relationship to add to the corresponding release issue in 

MKS Integrity when a new issue is added to a release management 

release. Leave the field blank to create a traditional relationship type. 

Product field Name of the user defined field within MKS Integrity that displays the 

product value in an issue. Field must be defined in MKS Integrity as 

type Long Text. 

Version field Name of the user defined field within MKS Integrity that displays the 

version in an issue. Field must be defined in MKS Integrity as type 

Long Text. 

Release field Name of the user defined field within MKS Integrity that displays the 

release value in an issue. Field must be defined in MKS Integrity as 


Release description Name of the user defined field within MKS Integrity that displays the 

release description in an issue. Field must be defined in 

MKS Integrity as type Long Text. 

Release type Name of the user defined field within MKS Integrity that displays the 

release type in an issue. Field must be defined in MKS Integrity as 


Release status field Name of the user defined field within MKS Integrity that displays the 

release status in an issue. Field must be defined in MKS Integrity as 


Open date field Name of the user defined field within MKS Integrity that displays the 

date a release was opened. Field must be defined in MKS Integrity 

as type Long Text. 

Open time field Name of the user defined field within MKS Integrity that displays the 

time a release was opened. Field must be defined in MKS Integrity 

as type Long Text. 

231


232 


State Setup in Implementer 


Close date field Name of the user defined field within MKS Integrity that displays the 

date a release was closed. Field must be defined in MKS Integrity as 


Close time field Name of the user defined field within MKS Integrity that displays the 

time a release was closed. Field must be defined in MKS Integrity as 


MKS Integrity is an extremely flexible tool that uses issues to manage development activities. 

While it allows for any number of user-defined issues, each issue is identified by a type, and 

each type has its own user-defined fields. 

MKS Integrity controls the Implementer development activities of check out and promotion 

through an issue’s state, and each issue type can have its own workflow of allowed state 

transitions. 

MKS Integrity associates every item that is changed with the issue it was changed for by way 

of an issue change package entry. Change package entries are added and updated only through 

Implementer’s check out and promotion activities. If checking out from multiple production 

environments, the changes for each environment are placed in a different change package. 

MKS Integrity shows the progress of a change package in Implementer development with a 

status. Through MKS Integrity, you are able to view the status of any member that is 

managed through Implementer. 

In Implementer, the default promotion path entries are globally defined in the MKS Integrity 

State Setup function. Implementer provides three default paths: *TST, *QAC1, and *PRD. 

You can optionally create an unlimited number of additional *QAC paths as needed, for 

example, *QAC2, *QAC3, *QAC4. Each promotion path entry corresponds to a user-defined, 

default state that is routinely assigned to an issue when all members of a change package 

progress through the development path, or when a member is rejected from a particular 

environment in the development path. 

If an application requires a unique status, you can override the global definitions at the 

environment level. When assigning issue states, Implementer processes existing environment 

overrides first, if none exist then it assigns the appropriate default global value based on 

where the environment is in the promotion path. The environment can override to a different 

state or can specify *NONE if no state change is desired. For information on overriding the 

default path, see “Environment Setup” on page 237.


Performing MKS Integrity State Setup requires a user profile that has authority to System 

Control Maintenance. The administrator typically performs this task when setting up the 

integration. Thereafter, you use it only to change a path’s issue state or to add or delete *QAC 

states. When you create a promotion path entry or change an issue state in Implementer, the 

issue state is validated in MKS Integrity. 

To configure promotion path entries with issue states 

1 From the Implementer Menu, type option 47, MKS Integrity, and press ENTER, or issue 

the command STRIM *INTMGRSET. The MKS Integrity Setup panel displays. 

2 Press F6=State setup. The MKS Integrity State Setup panel displays. 

The actions you can perform on this panel are as follows. 

Option 2=Change allows you to change the issue state to assign during the various 

stages of development. For each default promotion path entry you use, you must 

define the issue state to assign to an issue when the issue is in this state. To complete 

this task, proceed directly to step 3 page 234. 

Option 4=Delete allows to remove the last user-defined *QAC path entry. For 

example, if paths *QAC2, *QAC3, and *QAC4 exist, you must delete *QAC4 before 

deleting *QAC3 is allowed. Deleting any other promotion path type is not allowed. 

Option 5=Display allows you to view state detail for a path. 

233


234 

F6=State setup allows you to create a new promotion path entry on the 

MKS Integrity State Setup panel. It may be helpful to review “Manage States and 

State-based Capabilities” on page 208 before creating a new promotion path entry. 

IMPORTANT After adding a new *QAC path, you must update with the new state 

capabilities for Implementer to check for by running F8=Configure MKS Integrity. 

Then use MKS Integrity State Setup to assign the Implementer capabilities to the 

appropriate states. 

3 Type option 2=Change next to the promotion path, and press ENTER. The MKS Integrity 

State Detail panel displays. 

4 Complete this panel as described in the following table, and press ENTER. 


MKS Integrity State Detail Field Descriptions 

Promotion path entry Location on the promotion path the state is being set for. When adding a 

new path entry, the value defaults to the next *QAC environment and 

cannot be changed. 

Description Description about the path level. 

Issue state Issue state to assign when an item is in this promotion path location. 

Must be a valid state in MKS Integrity. 

For a *TST entry, the state is set in check out. For a *QAC or *PRD entry, 

the state is set after successful promotion. If the value is left blank, the 

issue state remains unchanged.


User Profile Setup 

MKS Integrity State Detail Field Descriptions 


Issue state when rejected Issue state to set when an item in this promotion path location is 

rejected. Must be a valid state in MKS Integrity. 

Applies to *QAC path entries only. If this value is left blank, the issue 

state remains unchanged when rejected. 

For each Implementer user that uses the integration, you must define an MKS Integrity user 

profile and specify whether the user has authority to activate MKS Integrity emergency 

mode. In addition, each user that performs an Implementer check out or promotion for items 

associated with an MKS Integrity issue must have a valid user profile in Implementer and a 

valid user ID in MKS Integrity. 

The user’s profile can be the same for both products or it can be different. By default, 

Implementer uses the iSeries user profile, which may or may not be the same as the 

MKS Integrity user ID. If the MKS Integrity user ID is different from the iSeries user profile, 

you can optionally define the appropriate MKS Integrity user ID to Implementer. This allows 

all integrations with MKS Integrity for a user to consistently use the value specified. There is 

no requirement that the password be the same. 

MKS Integrity Emergency Mode Authority 

In the event MKS Integrity temporarily cannot be contacted to perform the integrations, 

Implementer provides a facility that allows the check out and promotion functions to 

continue uninterrupted. This is accomplished by activating Implementer’s emergency update 

mode. 

For example, let’s say you have changes on an active request that must be promoted 

immediately to correct a level check problem in production, but a communication failure 

between Implementer and MKS Integrity has caused the promotion to fail. By activating the 

emergency update mode, you can continue with all required development activities, while 

storing the issue updates for subsequent posting once the communications are re-established. 

IMPORTANT When emergency update mode is active, Implementer is unable to 

validate MKS Integrity information. Thus, any issue number is accepted in check 

out, including invalid numbers, and every promotion is allowed even if the 

workflow or capabilities normally prohibit it. For this reason, operating in 

emergency mode is not intended as a normal disconnected mode—rather it is for 

emergency purposes only, such as when a production environment is down and 

must be updated to be active again. 

Users must be authorized to control the emergency update mode; for security reasons, no 

users are authorized by default. Typically, emergency mode authority is given to select 

development managers and senior developers. Once authorized, the user activates and 

235


236 

deactivates the emergency mode through the MKS Integrity Emergency Update Active field in 

Work with Users, by using option 20=User Defaults, or from the Workbench by using 

F18=User Defaults. For details on using this feature, see the MKS Implementer 2006 User Guide. 

Using the emergency update mode for remote initiated moves or remote compiles with host 

updates requires the Implementer user profile MWIPROD defined with the MKS Integrity 

emergency update field set to Y, and the MKS Integrity Emergency Update Active field set to Y 

(in User Defaults). For more information, see “Considerations for Remote Processing” on 

page 256. 

It is not necessary to have the emergency mode authority defined prior to a communication 

failure. When communications are down and a change must be made in Implementer, the 

Implementer administrator can authorize and activate the necessary user. 

The following task requires that the user profiles associated with this integration exist in 

Implementer and the user IDs are enrolled in MKS Integrity. 

NOTE For details on working with users, see “Users” on page 72. For MKS Integrity 

users, see the MKS Integrity Server 2006 Administration Guide. 

To define a user profile for MKS Integrity integration 

1 From the Implementer Menu, type option 41, Users, and press ENTER. The Work with 

User Profile panel displays. 

2 Select the user profile with option 2=Change, and press ENTER. The Change User Profile 

panel displays.


3 In the MKS Integrity User ID field, specify the name this user logs on with to access 

MKS Integrity. This user ID is also used for source archiving in MKS Source when 

MKS Source archiving is enabled. The user ID must be set up in MKS Integrity and/or 

MKS Source before defining it here. The field entry is case sensitive. Valid entries are as 

follows: 

*USRPRF: The iSeries user profile defaults as the MKS Integrity user. This is the 

default value. iSeries user profiles are specified in all upper case. If the name 

specified in MKS Integrity is not all upper case, retype the name using the exact case 

as that used in MKS Integrity. 

Name: Specify the valid MKS Integrity user ID. 

*NONE: The user is not authorized to access MKS Integrity. 

4 In the MKS Integrity emergency update field, specify if this user has authority to activate 

and de-activate the MKS Integrity emergency update mode and perform emergency 

updates. Allows the user to change the value of the MKS Integrity Emergency Update 

Active field on the Change User defaults panel, which is accessible from Work with 

Users using option 20=User Defaults and from the Workbench using F18=User Defaults. 

Y: The user has authority to activate the emergency update mode. 

N: The user does not have authority to activate the emergency update mode. 

5 Press ENTER to update the user profile. 

NOTE When activating emergency mode as described in “Emergency Update 

Mode” on page 255, the authorized user must sign off the iSeries and sign on again. 

When the authorized user accesses Implementer, a message displays at the bottom 

of the menu to confirm the emergency update mode is active. 

Environment Setup 

If the environments for this integration already exist and you have already configured the 

state setup, depending on your workflow you may not need to perform the following 

additional environment setup tasks. 

Implementer allows you to control whether an issue is required when checking out from 

a production environment. This allows you to enforce rules that define how a member 

that is checked out from the environment can subsequently be rejected and promoted 

throughout the development cycle. 

237


238 

Optional environment overrides to the default states to assign. The default states that are 

routinely assigned to an issue when all members of a change package are in a particular 

environment or when an item is rejected from a particular environment are defined in 

the MKS Integrity Setup. At the environment level, you can define overrides to the 

global default values. 

When assigning states in check out and promotion, environment overrides are assigned 

first. If overrides do not exist, the applicable global value is assigned. For details on 

global states, see “State Setup in Implementer” on page 232. 

The following task requires the environments and MKS Integrity states used with this 

integration exist in Implementer. For detailed information on working with environments, 

see “Environments” on page 81. 

To set an environment to require issues and override issue states 

1 From the Implementer Menu, type option 42, Environments, and press ENTER. The Work 

with Environments panel displays. 

2 Select the environment with option 2=Change, and press ENTER. The Change 


3 Press PAGE DOWN to display the second Change Environment panel. 

4 In the Issue Required for check out field, specify if an issue number is required to check 

out an item from the environment. Applies to *PRD environments only. 

N An issue number is not required. This is the default value. 

Y An issue number is required. 

5 Press PAGE DOWN to display the third Change Environment panel.


6 In the When arrives in this env field, optionally override the global issue states for the 

MKS Integrity state to assign to an item when it is checked out or promoted to this 

environment. 

NAME Specify a valid MKS Integrity state name to override the global 

value if defined. The name is case sensitive. 

*DEFAULT Assigns the default global value as defined in MKS Integrity State 

setup. If the default is not set, no updates occur. This is the default 

value for this field for all environment types. The state is set as 

follows: 

If checking out to this environment, assigns the *TST default 

state. 

If promoting to this environment and it is the first *QAC on 

the path, assigns the *QAC1 default state. If promoting to this 

environment and it is the second *QAC on the path, assigns 

the *QAC2 default state. This cycle continues for each *QAC 

environment. 

If promoting to this environment and it is type *PRD, assigns 

the *PRD default state. 

*NONE No updates occur to the issue state. 

239


240 

7 In the When rejected from this env field, specify the MKS Integrity state to assign to an 

item rejected from this environment. 

NAME Specify a valid MKS Integrity state name to override the global 

value if defined. Valid for *QAC environments only. The name is 

case sensitive. 

*DEFAULT Assigns the default global value defined in MKS Integrity State 

Setup. If the default is not set, no updates occur. This is the default 

value for all environment types. 

The state is set as follows: If rejecting from this environment and it 

is the first *QAC environment on the path (the path used to 

promote from the current location), assigns the *QAC1 default 

state. If rejecting from this environment and it is the second *QAC 

environment on the path (the path used to promote from the 

current location), assigns the *QAC2 default state. This cycle 

continues for each *QAC environment. 

*NONE No updates occur. 

8 Press ENTER to update the environment information. The Work with Environments 

panel displays. 

IMPORTANT The following setup tasks are required to promote Implementer 

requests from within MKS Integrity. If you do not intend to use this alternate 

promotion feature, go to “Converting From DesignTracker to MKS Integrity” on 

page 243. 

Updating Issues Based on Promotion Status 

The Update MKS Integrity (IUPDCI) command allows you to change the state of an issue 

based on the promotion status of objects in a change package. This process keeps 

MKS Integrity synchronous with the development cycle by triggering an issue state change 

based on promotion activity. For example, you may want to set the state to “Failed QA” 

when a move to QA fails. This is an optional feature. 

The IUPDCI command is invoked as an Implementer “After Move-OK” special command for 

each environment you want to trigger the state change. 

After connecting to the source iSeries and retrieving a list of all issues associated with the 

promotion request, the mass update of issues to the specified state occurs. The state change 

occurs only after all objects contained in the change package have reached the new location 

(QA or production). All issues in the change package must be promotable to the given state. 

MKS Integrity allows for an unlimited (and possibly recursive) number of relationships. The 

IUPDCI command uses a commit/rollback processing architecture, whereby the status 

update occurs only when all issues associated with the specified promotion request are at a 

state that allows the update. If any one of the issues do not update, then no issues update.

IUPDCI Command Requirements and Setup 


MKS Integrity uses a Java back end that resides on the iSeries to initiate a communication 

session with the MKS Integrity Server. The Update MKS Integrity (IUPDCI) command uses 

Java Runtime Environment 1.5 on the iSeries, which is provided in i5/OS release V5R3 and 

later. The IUPDCI command verifies Java is installed prior to running. 

In addition, you must change the IMJDKVER data area value to ‘1.5’ for the IUPDCI 

command to use Java 1.5. For details, see “Implementer Data Areas and User Exit Programs” 

on page 401. 

If the target MKS Integrity Server runs on an AIX system, Java Development Kit (JDK) 

version 1.4 is required on the client to communicate with MKS Integrity on the AIX system 

and use the IUPDCI command. Implementer provides the JDK Version (IMJDKVER) data 

area that allows you to store the JDK version to use with the Update MKS Integrity (IUPDCI) 

command. The default data area value is 1.2 (enclosed in single quotes (‘ ‘). You must install 

JDK version 1.4 on the iSeries, and change the IMJDKVER data area value to 1.4. On OS/400 

V5R2, you can install JDK version 1.4 from the IBM license product installation media. On 

OS/400 V5R1, you can install JDK version 1.4 by installing IBM PTF SI05336 and following 

the instructions included with the PTF. 

The setup requirements for the IUPDCI command are as follows: 

copy MKS Integrity files to the iSeries 

create a special command for the applicable environments 

To copy the MKS Integrity files to the iSeries 

1 Open Windows Explorer, and click Tools > Map Network Drive. The Map Network Drive 

dialog box displays prompting for a drive and path name. 

2 Select the drive name you want to use or accept the default value. 

3 For the path, type: 

//Your_System_Name/mks/Implementer/MKSIM/lib 

NOTE The default product library is MKSIM. If you changed the product library to 

another name, substitute the changed name for MKSIM. 

4 Make sure the Reconnect at Logon box is not enabled, and click OK. You may be 

prompted for a user ID and password to connect to the system. 

5 From Windows Explorer, select and expand the drive you just mapped. 

6 Navigate to your MKS Integrity Client install location. If you accepted the default 

location at the time of installation, the default location is: 

C:/Program Files/MKS/Integrity Client 

241


242 

7 From your MKS Integrity Client install location, copy file mksclient.jar from the 

/lib directory to the iSeries you mapped to in steps 1–5. 

To create the special command 

Define the special command for each applicable *QAC and *PRD environment. For detailed 

information on special commands, see “Special Command Processing” on page 255. 

When promoting changes from development to QA or from QA to production, the issue 

updates to reflect the current location and status. The update runs each time a promotion 

request targets an environment that has the IUPDCI command defined as a special 

command. The actual update occurs after the move portion of the promotion request 

successfully completes. When the promotion request is at a status of completed, you can 

access MKS Integrity to view the updates. 

In the following example, the special command is defined for a QA environment: 

IUPDCI RQS(#RQSNBR) NEWSTATE('"In QA"') 

IMPORTANT The value for NEWSTATE has embedded blanks; therefore, you must 

enclose it first in single quotes (' ') and then in double quotes (" ") as illustrated. 

IUPDCI Command Parameters 

Request Number 

Specify the promotion request number to process the special command for. The substitution 

variable #RQSNBR processes the command for all promotion requests that target the 

environment. This is a seven character alphanumeric field. 

New issue state 

Specify the new state value to assign to the issue. This is 20 character alphanumeric field. 

Mixed-case entry is supported. 

Enable Promotions From MKS Integrity 

This section describes the additional set up required in Implementer to create and promote 

Implementer requests from within MKS Integrity. This is an optional feature. 

The setup involves tasks in both MKS Integrity and Implementer. For information on the 

MKS Integrity tasks, see “Enable Promotions From MKS Integrity” on page 212. For an 

overview of the feature, see “Promoting Implementer Requests From MKS Integrity” on 

page 201. 

Review and perform the following Implementer setup requirements as needed:

Converting From DesignTracker to MKS Integrity 

Verify the MKS Integrity user responsible for creating promotion requests in 

MKS Integrity is defined in Implementer and has the required capabilities, for example, 

the capability to create and submit promotion requests for the applicable environments. 

Define the IEXCCMDUSR data area as described next. 

Change the IEXCCMDUSR Data Area 

The Command Capability Check Profile (IEXCCMDUSR) data area is used for capability 

checking. The data area stores the name of the single user profile that is allowed to issue the 

Run MKS Integrity Server (IEXCCMDIS) command that is embedded in the JavaScript file. 

The user profile you specify in this data area must be the same user profile specified in the 

JavaScript file for the userProfile variable (for details, see page 213). This user profile is used 

only for this feature; thus, it is not necessary to define the profile in Implementer or 

MKS Integrity. For this reason, consider creating a new profile for this specific purpose, for 

example, iSeries. 

CAUTION Embedded commands in the script fail if you do not associate the 

MKS Integrity user ID to an Implementer user profile. 

To change the IEXCCMDUSR data area value 

1 Type the following command: 

CHGDTAARA DTAARA(IEXCCMDUSR) VALUE(user_profile_name) 

where user_profile_name is the user specified in the script. 

2 Press ENTER to update the data area. 

You are now ready to convert from DesignTracker to MKS Integrity as described next. 


When you initially install Implementer or upgrade from a release prior to release 5.3, 

DesignTracker is the default issue management system. To use Implementer with 

MKS Integrity as described in this chapter, you must convert issue management systems and 

activate MKS Integrity to establish it as the default system. 

When you convert from DesignTracker to MKS Integrity, you have the option to use 

MKS Integrity only, or to use MKS Integrity and DesignTracker concurrently on a transitional 

basis. With either option, the eventual result is the elimination of DesignTracker as a 

production application. 

243


244 

Once MKS Integrity is active system-wide, you cannot convert back to DesignTracker. 

However, for existing DesignTracker users, provisions are available for enabling select users 

to use DesignTracker temporarily. Future upgrades of Implementer automatically consider 

and retain the settings you define. 

Conversion Methods 

Implementer provides two methods for converting issue management systems from 

DesignTracker to MKS Integrity: system conversion without data retention or system 

conversion with data retention. The latter method includes a feature that, after converting to 

MKS Integrity, allows you to convert DesignTracker design requests (DRs) and service 

requests (SRs) to MKS Integrity issues. 

To determine which conversion method fits your business requirements, you need to answer 

the following question: 

Is DesignTracker in use with any DRs you want to keep? 

If no, simply convert to MKS Integrity as described in “Converting Without Data 

Retention” on page 244. This is the case for new installations of Implementer. 

If yes, convert to MKS Integrity as described in “Converting With Data Retention” on 

page 247, and optionally convert DRs and SRs to MKS Integrity issues as described in 

“Converting DesignTracker Data to MKS Integrity” on page 431. 

NOTE Prior installations of Implementer automatically installed demonstration DRs 

and SRs. If these are the only requests present, you can delete them. You can also 

delete any requests from a pilot project. 

Converting Without Data Retention 

The tasks described in this section perform a conversion that allows you to convert issue 

management systems—that is, switch from using DesignTracker to using MKS Integrity, 

without retaining any existing DesignTracker data. Converting to MKS Integrity without 

regard for existing data is straightforward and allows you to quickly begin using 


This conversion method is applicable when DesignTracker is not used for issue management, 

or if it has been used but you do not need to preserve any DRs or SRs that may exist from the 

prior use. This conversion method deletes all existing DRs, SRs, DR entity lists, and any DR 

references on current locks and lock history. It does not delete the actual locks or lock history. 

This is a one time task. Once the conversion successfully completes, you can begin using the 

integration. 

Your user profile must have authority to System Control Maintenance to perform this task.

CAUTION 


This task deletes DesignTracker data. If you need to retain DesignTracker data, 

do not perform this task; instead, see “Converting With Data Retention” on 

page 247. 

MKS recommends you perform a backup of the DesignTracker database by 

saving the Implementer library prior to running this conversion function. 

To convert to MKS Integrity without retaining data 

1 Sign on to the iSeries with a user profile that has authority to System Control 

Maintenance and access the Implementer Menu. 

2 Type option 47, MKS Integrity, and press ENTER. Alternatively, on the command line 

issue the command STRIM *INTMGRSET. The MKS Integrity Setup panel displays. 

3 Press F20=Convert to MKS Integrity. (Press F24=More keys to view function key F20 in 

the list.) The first of three Convert to MKS Integrity confirmation windows display. 

4 In the Reply field, type N to disallow co-existence, and press ENTER. The second Convert 

to MKS Integrity panel displays. 

CAUTION The function you are about to perform deletes existing DesignTracker 

data. If you do not want to delete DesignTracker data, do not perform this step. 

However, if this step is not performed or a system conversion is not performed, you 

cannot use MKS Integrity as described in this chapter. 

245


246 

NOTE There are two Convert to MKS Integrity panels. Both panels allow you to 

display additional information before converting. Press F2=Display 2nd Level Text. 

5 In the Reply field, type Y, and press ENTER. 

To cancel the conversion and return to the MKS Integrity Setup panel, either: type N in 

the Reply field, and press ENTER, press F3=Exit, or F12=Cancel. 

After pressing ENTER to continue, the second confirmation window displays. A message 

confirms you selected to convert from DesignTracker to MKS Integrity.


6 To proceed with the conversion, in the Reply field type G, and press ENTER to perform 

the conversion. 

To cancel the conversion and return to the MKS Integrity Setup panel either: type N in 

the Reply field, and press ENTER, press F3=Exit, or F12=Cancel. 

After pressing ENTER to continue, the following message displays at the bottom of the 

MKS Integrity Setup panel: “Successful conversion to MKS Integrity.” 

The system conversion from DesignTracker to MKS Integrity is complete. You are ready to 

begin using the new features, as described in the MKS Implementer 2006 User Guide. 

Converting With Data Retention 

For MKS customers that currently use DesignTracker for issue management, the tasks 

described in this section perform a conversion that allows you to convert issue management 

systems—that is, switch from using DesignTracker to using MKS Integrity, and retain 

existing DesignTracker data. This conversion method enables the Implementer feature 

co-existence, which is required when converting DesignTracker data to MKS Integrity. 

The purpose of co-existence is twofold: It avoids application downtime during the 

application conversion project by allowing you to simultaneously use both MKS Integrity 

and DesignTracker, and it allows you to convert DesignTracker DRs, SRs, and related entity 

information to MKS Integrity issues using the Convert DT to MKS Integrity (ICVTDT) 

command. By design, it allows some users to use MKS Integrity issues without requiring all 

users to switch at the same time. This allows for a gradual transition of development teams 

when multiple teams share the same Implementer installation. 

NOTE For details on the ICVTDT command, see “Converting DesignTracker Data to 

MKS Integrity” on page 431. 

Converting to MKS Integrity when you need to retain and convert existing data can be an 

involved undertaking simply due to the inherent complexities associated with performing 

data conversions. For example, a typical data conversion requires mapping existing files and 

fields to new values in the new database. Detailed information on performing a data 

conversion begins on page 431. 

TIP MKS can assist with converting your DesignTracker data to MKS Integrity, as 

well as assist in defining your business processes and workflow for MKS Integrity. 

For details, contact MKS Customer Care. 

Before you perform the actual data conversion, however, you need to determine how the 

data conversion will occur. In other words, will you perform a one-time conversion of all 

applicable data and users, or will you perform a gradual conversion on subsets of data and 

users? 

247


248 

The need for this decision—beyond having control of the overall scope of your conversion 

project—is that with co-existence you can designate on a user basis which issue tracking 

system a user works with. It allows you to have groups of users still using DesignTracker 

while other users use MKS Integrity. This approach is beneficial to larger organizations with 

many end users, as it allows you to train and migrate groups of individuals rather than all 

users at once. For information on setting the issue management system for a user, see 

page 253. 

To simplify working with two issue management systems, while co-existence is active you 

configure each issue management system to manage a different range of numbers, where 

issues and DRs each have a specific number range that is unique to each type, and numbers 

outside of the specified ranges are not allowed. DRs always have the lowest numbers and 

MKS Integrity issues have the higher numbers. 

Everyone is able to view all IDs and some basic information, but the check out and promotion 

functions require users to only use the issue management system they are set up for. This 

methodology allows DesignTracker to use numbers up to the last allowed DR number you 

specify. Information on setting the last DR number begins on page 250. 

You achieve a successful conversion when all Implementer user profiles that perform check 

out or promotion functions are set to use MKS Integrity for issue management. Although, it 

may be desirable to keep a few users with a second user profile set to use DesignTracker so 

they can fully navigate the DesignTracker audit trail. 

Once the conversion finishes, the DesignTracker transactions can remain online and visible to 

the select DesignTracker users for historical purposes. There is no need to disable coexistence 

after you finish the conversion. 

IMPORTANT MKS recommends you convert to a pilot copy of MKS Integrity to verify 

the results before going “live” with converted data. MKS also recommends you 

perform a backup of the DesignTracker database by saving the Implementer library 

prior to running this conversion program. 

Promotion Considerations With Co-existence 

The following promotion-related considerations apply to working in the co-existent mode: 

All issues for a single promotion request must be in the same issue management system. 

In other words, you cannot assign both DRs and issues to the same promotion request. 

If using concurrent development, do not allow the same member to have locks 

associated with a DR and issue in the same environment, as this will make it non 

promotable. 

The user that submits a move request must use the same issue management system as 

the user who created the request. For example, on a request that contains DRs, both the 

requestor and the user submitting the move must be set up to use DesignTracker. On a 

request that contains issues, the respective users must be set up to use MKS Integrity.

Run the Conversion 


This is a one time task. Perform this conversion task only if DesignTracker is, or was, used for 

issue management and you need to retain and/or convert any data that may exist from the 

prior use. 

Your user profile must have authority to System Control Maintenance to perform the task. 

IMPORTANT This task allows you to establish MKS Integrity as the system-wide issue 

tracking system and enable DesignTracker co-existence. While you must perform 

this task to later convert DesignTracker data to MKS Integrity, it does not actually 

convert or delete any data. To convert DesignTracker data to MKS Integrity, see 

“Converting DesignTracker Data to MKS Integrity” on page 431. To completely 

remove DesignTracker data without co-existing or converting data, see “Converting 

Without Data Retention” on page 244. 

To convert to MKS Integrity and retain existing data 

1 Sign on to the iSeries with a user profile that has authority to System Control 

Maintenance and access the Implementer Menu. 

2 Type option 47, MKS Integrity, and press ENTER. Alternatively, on the command line 

issue the command STRIM *INTMGRSET. The MKS Integrity Setup panel displays. 

3 Press F20=Convert to MKS Integrity. (Press F24=More keys to view function key F20 in 

the list.) The Convert to MKS Integrity window displays. 

4 In the Reply field, type Y, and press ENTER. Alternatively, press F2 to display additional 

information on the function you are about to perform as illustrated next. 

249


250 

5 To continue with the conversion, in the Reply field type Y, and press ENTER. 

NOTE If you need to cancel the conversion, either type N in the Reply field, and press 

ENTER, press F3=Exit, or F12=Cancel. 

When the conversion completes, the following values are set in the MKS Integrity Setup 

panel: 

Issue Management System field value is MKS Integrity. 

Allow co-existence with DesignTracker field value is Y. 

Last allowed DR number field value is 99999. 

IMPORTANT For any users that will continue to use DesignTracker, it is necessary to 

override the system default of MKS Integrity. For details, see “Set a User’s Default 

Issue Management System” on page 253. 

Set the Last Allowed DR Number 

With co-existence, each issue management system uses a different range of ID numbers. 

Each Implementer function that allows specifying an issue or DR number, or associates an 

issue or DR with a lock, ensures the number being used is appropriate for the user’s issue 

management system. An error displays if the number specified is outside the range of their 

issue management system.


For example, a user who is set up to use DesignTracker tries to check out or promote using 

number 12345—by range, an MKS Integrity issue number—receives an error. Likewise, if a 

user attempts to create a new DR by using either the menu option or the Create Design 

Request (DTCRTDR) command, Implementer verifies the new DR number is within the valid 

DR number range—if the number is not valid, then creating the DR is not allowed. 

Displaying the basic description or details of an issue or DR does not require enrollment in 

the specific issue management system. 

Changing the last allowed DR number value is allowed only if MKS Integrity is the default 

issue tracking system and DesignTracker co-existence is enabled. The value automatically 

sets to 99999—the highest possible DR number—when you convert to MKS Integrity and 

enable co-existence. Before processing any DRs or issues, you must change this number to 

another value based on your data. Thereafter, avoid changing it to eliminate a possible 

conflict with existing issues, or DRs that you may subsequently convert to issues. 

IMPORTANT You must specify a Last allowed DR number value that allows for all 

expected growth in DR usage until DesignTracker is retired, as there is no way to 

change this number once you use an MKS Integrity issue. 

The following task requires you have successfully completed the conversion to 

MKS Integrity and enabled the option to co-exist with DesignTracker. 

To change the last allowed DR number 

1 From the Implementer Menu, type option 47, MKS Integrity, and press ENTER. 

Alternatively, on the command line issue the command STRIM *INTMGRSET. The 

MKS Integrity Setup panel displays. 

2 Press PAGE DOWN to display the second MKS Integrity Setup panel. 

251


252 

3 In the Allow co-existence with DesignTracker field, verify the value is Y, indicating 

DesignTracker and MKS Integrity are able to co-exist. This value is required to enable 

changing the last allowed DR number. If the value on your system is not Y, see 

“Converting With Data Retention” on page 247. 

4 In the Last allowed DR number field, type the value of the last valid DR number allowed 

in DesignTracker. The default value is 4999. 

IMPORTANT Be sure to specify a value that allows for all expected growth in DR 

usage until DesignTracker is retired. The value cannot be set below the current 

highest DR number created. Any DR number higher than the number specified here 

is considered an MKS Integrity issue. 

5 Press ENTER to update the information. 

Set the Next Issue Number in MKS Integrity 

When using co-existing issue management systems, you must configure each issue 

management system to manage a different range of numbers, where issues and DRs each 

have a specified number range that is unique to each type, and numbers outside of the 

specified ranges are not allowed for either type. DRs always have the lowest range of 

numbers and MKS Integrity issues have a higher range of numbers. 

This is an MKS Integrity function, accomplished by adding a new property to the 

im.properties file on the MKS Integrity Server. For details on configuring properties for 

the MKS Integrity Server, see the MKS Integrity Server 2006 Administration Guide. 

IMPORTANT Make changes to the Integrity Server property files using a text editor, 

such as Notepad, and then save as plain text. You must restart the server to effect the 

changes. 

To set the next issue number in MKS Integrity 

1 Navigate to the im.properties file located in: 

/config/properties 

2 Open the file and add the following line to the im.properties file: 

mksis.im.minimumIssueNumber= 

for example, mksis.im.minimumIssueNumber=70000 

NOTE You can increase the next issue number value, you cannot decrease it.

Set a User’s Default Issue Management System 


Setting a user’s default issue management system is required only when the conversion of 

DesignTracker data is gradual, rather than a one-time conversion. 

Each user enrolled in Implementer is set automatically to use the default issue tracking 

system as defined in the MKS Integrity setup, option 47 on the Implementer Menu. Once you 

convert to MKS Integrity and enable co-existence, all users are set to use MKS Integrity. If 

some users will continue transitional use of DesignTracker, after converting to MKS Integrity 

you can re-enable each user that will continue to use DesignTracker. 

Generally, whichever system a user is set up for determines the text that displays on all 

Implementer panels and reports. Thus, when using MKS Integrity the term “issue” is used. 

When using DesignTracker the term “design request” is used. For example, when a user set 

up to use MKS Integrity displays the Workbench, the field name is Issue, when the field 

value may actually contain DR numbers if they are filtered to a lock associated with a user set 

up to use DesignTracker. Although the MKS Integrity user is able to view the DR number, 

they are restricted from using or changing the lock detail because they cannot manipulate 

DRs through Implementer. The exception to this rule is when displaying activity—each user, 

regardless of their default issue management system, can view the activity of other users. 

By design, Implementer does not allow a single user to use both MKS Integrity and 

DesignTracker under the same Implementer user profile. However, you can work around 

this and permit the ability to work in both systems by issuing two different iSeries user 

profiles. For example, this might be useful for some administrators or team leaders during 

transition to the new system. You can simplify this step by copying existing user profiles. 

When changing the user profile or environment values, the applicable MKS Integrity fields 

are changeable based on the default issue management system as defined in the 

MKS Integrity Setup, not the current users override. 

To set the issue management system for a user in Implementer 

1 From the Implementer Menu, type option 41, Users, and press ENTER. The Work with 

User Profiles panel displays. 

2 Type option 2=Select next to the user profile, and press ENTER. The Change User Profile 

panel displays. 

3 Press PAGE DOWN to display the second Change User Profile panel. 

253


254 

4 In the Issue Management System field, specify the current issue management system for 

this user. This field is only used when co-existing to allow certain users to use 

MKS Integrity while others use DesignTracker; otherwise, input is protected. 

When you activate MKS Integrity, all users are set to use MKS Integrity. Change this 

value only to set the user’s default to DesignTracker and to change it back to 

MKS Integrity (1=Default) when DesignTracker is no longer used by the user. 

1=Default: The user is using the default issue management system as defined on the 

MKS Integrity Setup panel. This is the default value. 

2=DesignTracker: The user is using DesignTracker, even if MKS Integrity is the 

default issue management system as defined on the MKS Integrity Setup panel. 

5 Press ENTER to update the information. 

IMPORTANT 

After changing this value for a user, the user must sign off the iSeries and sign 

back on for the change to take effect. 

If this user checks out or promotes using Implementer’s Web interface, you must 

restart the Web server to recognize the new issue management system. For 

information on the Web interface, see “Web-based Development for IFS Objects” 

on page 155. 

The conversion from DesignTracker to MKS Integrity is complete. If you need to convert 

existing DesignTracker data, see “Converting DesignTracker Data to MKS Integrity” on 

page 431. If you do not need to convert DesignTracker data, you can begin using the 

integration as described in the MKS Implementer 2006 User Guide.

Emergency Update Mode 


If communications between Implementer and MKS Integrity become temporarily 

unavailable and thereby cause MKS Integrity inaccessible to perform updates, Implementer 

provides the Emergency Update Mode facility. When activated, emergency update mode 

allows for the uninterrupted continuation of all iSeries development activities, including 

check out and promotion. 

For example, you have changes on an active request that require immediate promotion to 

correct a level check problem in production, but a communication failure between 

Implementer and MKS Integrity has caused the promotion to fail. By activating the 

emergency update mode, you can continue with all required development activities while 

storing the issue updates for subsequent posting once the communications are re-established. 

Users must have authority to work in emergency update mode and perform emergency 

updates. Typically, this authority is given to a few development managers and senior 

developers. When authorized, you can activate and deactivate the emergency mode by 

changing the value of the MKS Integrity emergency update active field, accessible from Work 

with Users by using option 20=User Defaults, or from the Workbench by using F18=User 

Defaults. For details on the setup requirements, see “MKS Integrity Emergency Mode 

Authority” on page 235. 

TIP To maintain a record of communication failures, you can journal the 

Implementer file IMCICT and monitor any changes to the file. 

Changing the Emergency Update Mode 

When the status of communications between Implementer and MKS Integrity changes, the 

user defined as the iSeries Notify User is notified of the change by a message in the user’s 

OS/400 message queue. (The iSeries Notify User is defined in MKS Integrity setup, option 47 

from the Implementer Menu.) The user is notified when communications become either 

unavailable or available. At the same time, in the MKS Integrity Setup, the System Available 

field reflects the current status. 

When a communication failure occurs, a common practice is to perform problem 

determination to assess the magnitude of the failure and its potential impact on 

development. Based on these results, and perhaps additional variables such as your current 

development activities and the time of day, you can decide whether to activate the 

emergency update mode. 

For example, if a communication failure occurs that you expect to last for only a brief time 

and it does not hinder current development activities, you may decide not to activate the 

emergency update mode. In this case, developers can continue with Workbench activities 

such as editing and compiling, but they are not allowed to check out or promote. On the 

other hand, if a failure occurs during the night that could interrupt the processing of 

255


256 

scheduled promotions that you do not want to end in a failed status, activating the 

emergency update mode is necessary to allow Implementer to proceed with promotion 

request processing. 

To allow promotions to complete without an active connection, this feature requires each 

user who submits promotions to have their user profile MKS Integrity emergency update 

active field set to Y in Work with Users. 

Emergency Mode Active 

When the emergency update mode is active for a user and that user signs on to Implementer, 

the following message displays at the bottom of the menu to confirm the operating mode: 

“MKS Integrity emergency update mode is ACTIVE!”. 

In active mode, Implementer bypasses all capability and validity checking, and postpones all 

updates to MKS Integrity. This allows the authorized user to continue with the development 

activities, such as editing, checking out, and promoting. Move requests continue as normal, 

however the MKS Integrity status change does not occur until you apply pending changes. 

Once you restore communications, you can synchronize the Implementer and MKS Integrity 

databases with pending changes as described in “Applying Pending Changes” on page 257. 

Considerations for Remote Processing 

When using emergency update mode with remote initiated moves or remote compiles with 

host updates, to avoid problems with the host update job failing and the request ending with 

a status of Move-fail, you must change the user profile of the user that runs the host update 

program (this is usually the Implementer user profile MWIPROD). 

In Work with Users, set the MKS Integrity emergency update field to Y, and in User Defaults 

set the MKS Integrity emergency update active field to Y. Once communications are back 

online, change the user defaults back to N. 

Emergency Mode Inactive 

When a disruption in communications causes a user not to have emergency update mode 

active, Implementer sends the user a communications failure message to notify of the 

operating mode. 

Developers are able to perform some development activities, but the permitted tasks are 

limited in scope. For example, working in emergency mode allows editing and compiling, 

but check out, promotion, and any tasks that require the use of an issue or validation to 

MKS Integrity are not allowed.

To activate or deactivate the emergency update mode 

1 Use one of the following options to access the Change User Defaults panel: 

From the Workbench, press F18=User Defaults. 


From the Implementer Menu, type option 41, Users, and press ENTER. Select the 

user profile with option 20=User Defaults, and press ENTER. 

2 In the MKS Integrity emergency update active field, specify Y to activate emergency 

update mode, or N to deactivate emergency update mode for the user. 


4 To activate the change, sign off the iSeries and sign on again. 

When emergency update mode is active and the authorized user accesses Implementer, 

the following message displays at the bottom of the menu to confirm the operating 

mode: “MKS Integrity emergency update mode is ACTIVE!”. 

Applying Pending Changes 

Once you restore the communications between Implementer and MKS Integrity, you need to 

apply any pending changes that occurred while the emergency update mode was active. 

This function updates any issues that were changed while communications between 

Implementer and MKS Integrity were unavailable. It updates MKS Integrity with the current 

state of the issues change packages and change package entries, and sets the state of the 

issues to reflect the current status of the change packages. 

257


258 

In the event an issue being processed does not exist, the change package entry log is updated 

to indicate that no updates were performed for the issue and no future updates will occur for 

the issue. Although no updates occur, the change package entry log is updated to reflect the 

issue posted to ensure further updates are not attempted. 

If an invalid action or workflow conflict occurred while the emergency update mode was 

active, for example, a promotion that would not normally be allowed based on the current 

state of an issue, the update to MKS Integrity does not occur during the update because it 

will only fail. This is a warning condition; as such, it is left for the administrator to ensure the 

issue is set to the proper state. 

After successfully applying the pending updates, a message of the update results is sent to 

the user defined as the iSeries Notify User. If no pending updates exist, a message at the 

bottom of the panel confirms this. 

Apply Pending Changes Command Option 

You can apply pending changes by using a menu interface or by using the Apply Pending 

Changes (IAPYPNDCHG) command. You can issue the command from the command line or 

embed into a user-defined program. The command has no parameters. 

IMPORTANT Before applying pending changes, you must ensure the emergency 

update mode is not active. 

To apply pending changes, use one of the following options 

From a command line, issue the following command: 

APYPNDCHG 

From the Implementer Menu, type option 47, MKS Integrity, and press ENTER or issue 

the command STRIM *INTMGRSET. The MKS Integrity Setup panel displays. 

a) Determine whether MKS Integrity is available by the value in the System Available 

field. 

b) Determine if pending changes exist by the value in the Pending Changes field. If 

pending changes exist, press F9=Apply Pending Changes. 

Apply Pending MKS Integrity Changes Report 

The Apply Pending MKS Integrity Changes report generates automatically when you apply 

pending changes by using the menu interface or the command interface. The report generates 

to the spool file of the user profile who ran the apply pending changes job. The spool file 

name is IMPNDCHG. 

The report includes the following information: 

date and time the update ran

issue and issue summary 

update result 

change package ID 

environment 

change package state 

change package status 

member and object code 

member status 

Implementer and MKS Source Integration 


Implementer and MKS Integrity integrate with MKS Source to give you detailed visibility of 

your iSeries source changes using MKS Source and MKS Integrity. 

With this integration, MKS Source can be used as a primary repository or a supplemental 

archive for native iSeries source members. MKS Source is the source code repository for 

detail iSeries source changes and updates, and MKS Integrity tracks the source members 

changed and promoted at the issue level. Implementer’s repository tracks the MKS Source 

revision—the result of promoting the member into an environment set up for MKS Source 

archiving. MKS Source and MKS Integrity handle all other tracking and auditing. 

The Implementer and MKS Source integration allows you to: 

Check out iSeries source code from Implementer or MKS Source. 

Promote Implementer locks, which automatically updates the MKS Source repository 

and records the MKS Source revisions in Implementer. 

View iSeries source member change history in the MKS Source Member History, 

including previous release development branches. You can also compare two member 

revisions by using the View Differences option. 

View changed iSeries source code lines by revision in the MKS Source Annotated View. 

Review Implementer product/release source revisions shown in release checkpoints and 

created on MKS Source projects that track Implementer products. 

Use the MKS Source iSeries Developer ViewSet to inquire on functions applicable to 

iSeries source information. 

Initiate the graphical Annotated View and Member History in MKS Source using 

Implementer green screen or WDSc interfaces. 

Use MKS Source in addition to Implementer for iSeries source archiving. 

259


Process and Workflow 

260 

Managers have a graphical window into the development process, allowing them to monitor 

the progress of issues and changes. The resolution of issues is accomplished through an 

integrated change management process facilitated by a common software architecture shared 

between MKS products. 

At the core of the integration, Implementer’s release control features have a direct correlation 

to change management functions in MKS Source as described in the following table. 

This release control feature in Implementer... ... Correlates to this feature in MKS Source 

product subproject of base product project 

product/version development path 

product/version/environment subproject of base environment project 

product/version/release release checkpoint 

The integration uses two MKS Source projects, defined as a base product project and a base 

environment project, to store all Implementer source archive information. 

Product Subproject in Base Product Project 

A product subproject is automatically created in the MKS Source base product project 

for each product when you set the Archived by MKS Source field to Y in Implementer’s 

Product Maintenance panel. Product subprojects are located in the Base Product project 

you reference in the MKS Source Setup panel in Implementer. 

Permissions for each product subproject are inherited from the base product project. 

All source members associated with the Implementer product are stored in the product’s 

subproject. When you add or update a member, it is added or checked in to this 

subproject. The product subproject contains all versioned contents for all members 

checked in for the product, including members that are later dropped. Users should not 

be given visibility to the product subproject; they can view the contents through 

environment subprojects within the product’s versions. 

Before creating a new version of the product in Implementer, you redefine the current 

version with a development path of *VERSION. A function in Implementer allows you 

to create an MKS Source development path, which assigns branched MKS Source 

revisions to subsequent promotions into the archived product/version/environments. 

This allows you to create a new version with a development path of *HEADREV, and 

continue with promotions to the *HEADREV version assigned trunk revisions. 

IMPORTANT The base projects referenced in this document are standard MKS Source 

projects. They act as parent projects to various subprojects. It is not required to 

register the base projects as top level projects in MKS Source.

Environment Subprojects in Base Environment Project 


An environment subproject represents the current state of an Implementer environment. 

Environment subprojects are subprojects of the Base Environment project you reference 

on the MKS Source Setup panel in Implementer. Implementer automatically creates an 

environment subproject when you set a product/version/environment’s Archived by 

MKS Source field to Y on the Product Version Environment Maintenance panel. 

Permissions for each environment subproject are inherited from the base environment 

project. 

Environment subprojects allow imports and revision updates only; they do not allow 

adds or check in. When you promote a member, it is added or checked in to the product 

subproject and then imported to update the revision in the environment subproject. 

When you close a release, a function in Implementer allows you to create a checkpoint 

for associated production environment subprojects. This allows you to review the 

project in its current form at any point by viewing the project history using the 

checkpoint. 

Within each product and environment subproject, the first level subproject is the source 

physical file name, the base name of the file is the item name, and the file extension is the 

source member type. For example, member MWI0110, member type RPGLE, in source 

physical file QALLSRC appears as /MWI0110.RPGLE in subproject QALLSRC. IFS items are 

stored in a subproject named ifs. 

Assumptions and Requirements 

The Implementer and MKS Source integration requires: 

Implementer 2006, which requires an iSeries system running OS/400 V5R1 or later, or 

i5/OS V5R3 or later. This is assumed installed and configured. For information on 

installing Implementer, see the MKS Implementer 2006 Installation Guide. 

MKS Integrity Server 2006 or later, and MKS Source 2006 or later. This is assumed 

installed and configured. For information on installing MKS Integrity products, see the 

MKS Integrity Server 2006 Installation Guide. 

The Implementer Server must be configured and active. For details, see “Configuring the 

Implementer Server” on page 217. For information on managing Implementer Server, 

see page 223. 

TCP/IP connectivity between the iSeries running Implementer and the system running 

MKS Integrity Server. 

NOTE Using MKS Integrity is optional with the Implementer and MKS Source 

integration. If using MKS Integrity, you must have MKS Integrity 2005 or later 

installed and configured. 

261


MKS Source Setup and Administration 

262 

The integration configuration steps you perform in MKS Source are one-time tasks. Once you 

complete these setup tasks, no ongoing tasks are required in MKS Source. 

NOTE The integration can run on the same or a separate server as the MKS Integrity 

integration and Implementer Server. 

The setup tasks in MKS Source require the assistance of your MKS Integrity administrator. 

Overall, the Implementer and MKS Source integration requires the skill sets of both your 

MKS Integrity administrator and Implementer administrator. MKS recommends you 

coordinate the configuration of this integration with the applicable administrators in your 

organization to ensure a successful and smooth process. 

The setup tasks in MKS Source include the following: 

Create two base projects in MKS Source to act as parent projects for the product and 

environment subprojects. This task begins on page 263. 

Create an MKS Source integration user, or use the existing MKS Integrity integration 

user. This task begins on page 264. 

Create an Implementer Developer group to manage users (developers) of the 

integration. This task begins on page 264. 

Assign MKS Source policies. This task begins on page 265. 

Assign ACL permissions to the integration user and Implementer Developer group. This 

task begins on page 268. 

Modify the MKS Integrity Client Client configuration file IntegrityClientSite.rc to 

enable developers to invoke MKS Source GUI gestures from their workstation. This 

allows launching annotated views and member history in MKS Source from the 

Implementer Workbench and Work with Objects, as well as WDSc. For details on this 

task, see “Modifying the MKS Integrity Server Configuration File” on page 206. 

When using MKS Integrity, the workflow State prior to the first environment enabled for 

MKS Source archiving (Version Environment, Archived by MKS Source = Y) must have 

the capability Allows open SI change packages to exist. MKS recommends you 

enable the first QA environment for MKS Source archiving to ensure that all source 

member changes promoted from development are captured in MKS Source. In this case, 

the workflow State In development (or the equivalent value you have defined) must 

have this capability. If you use MKS Integrity issues and require more information, see 

“Implementer State-based Capabilities” on page 208. 

Detailed information on how to perform each of these tasks is located in the MKS Integrity 

2006 Administration Guide. In collaboration with that guide, the following sections contain 

important supplemental information you need to know when setting up MKS Source 

specifically for the integration with Implementer as described in this chapter.


A chronological checklist of the tasks required to configure the Implementer and MKS Source 

integration is provided page 296. MKS recommends you use the checklist to ensure you 

complete each required task in the order described. 

Creating Base Projects in MKS Source 

The base projects you create in MKS Source are specific to each copy of Implementer you 

integrate with MKS Source. Thus, if you have multiple copies of Implementer integrated with 

a single copy of MKS Source, each copy must reference a different set of base projects. 

MKS suggests you use a naming convention that is universally common, for example, 

BaseProductProject and BaseEnvironmentProject are the project names used 

throughout this documentation. Once you create the base projects, the necessary subprojects 

are created automatically within each base project based on the values you specify and 

functions you perform on Implementer’s release control panels. 

NOTE Parent projects in MKS Source are base projects in Implementer. 

Under the base product project, MKS Source automatically creates a product subproject for 

each application product you define in Implementer’s release control setup as archived by 

MKS Source. All source members are stored in these subprojects. When you add or update a 

member, the member is added or checked in to this subproject. 

NOTE The following task describes how to create a base product project and a base 

environment project. MKS Source automatically creates product and environment 

subprojects when you define the products and product/version/environments in 

Implementer and activate MKS Source archiving by setting the Archived by 

MKS Source field to Y for each. For details on creating projects in MKS Source, see 

the MKS Source 2006 User Guide. 

To create the base projects in the MKS Source GUI 

1 From the MKS Window, open the MKS Source ViewSet. 

2 Select Project > Create. The Specify the Project to Create dialog box displays. 

3 If your administrator has specified multiple server roots, from the Look in list select a 

location where you want to create the project. Otherwise, go to the next step. 

4 Enter the path and file name, or browse to a location on the MKS Integrity Server where 

you want to create the project, for example, C:/BaseProductProject. If the project 

path does not exist on the MKS Integrity Server, the new path is created. 

5 Enter a name for the project. The default project name is project.pj. The project is 

identified by the directory. 

6 Click OK. The project displays in a Project view. 

7 Repeat steps 1–6 to create the base environment project. Be sure to specify a different 

directory for this project. 

263


264 

Creating the Integration User 

You have the option to create a specific integration user, or designate an existing MKS Source 

user profile as the integration user. If you currently use MKS Integrity with Implementer, 

you probably already have a designated profile. 

TIP To identify your existing MKS Integrity integration user, from the Implementer 

Menu select option 47, MKS Integrity Setup, to view the MKS Integrity User ID field 

value. 

Because of certain authorities the integration user must have, the integration user should be a 

user that does not usually sign on to the system or use the product. The primary functions of 

the integration user are: 

connect to the MKS Integrity Server from the Implementer Server 

execute certain commands that a typical user does not have authority to perform 

impersonate users to perform work on behalf of the impersonated user 

The integration user requires setup in MKS Source and Implementer. In a later task when you 

configure Implementer for the integration, you specify this user ID in the MKS Source User ID 

field on the MKS Source Setup panel. For details, see “Defining MKS Source Values in 


Information on setting permissions for the integration user begins on page 268. For details on 

creating users in MKS Integrity, see the MKS Integrity Server 2006 Administration Guide. 

Creating the Implementer Developer Group 

MKS recommends you create a group and add the iSeries users to the group, for example, 

implementer developer group is used throughout this documentation. This allows you to 

set ACLs and permissions for the group rather than for each individual user. If you use 

MKS Integrity with Implementer and you are using the same server for MKS Source 

integration, the group profile may already exist. 

IMPORTANT During a remote initiated move that updates the host, Implementer uses 

the profile MWIPROD to update the host. If you use remote initiated moves with 

host updates (remote environment defined with the Remote initiated move and 

Updates host fields set to Y) for promotions with MKS Source integration, the 

MWIPROD user profile must have an MKS Integrity user ID that is part of the 

group to work with MKS Source. 

Information on setting permissions for the Implementer Developer group or users begins on 

page 268. For details on creating groups or users, see the MKS Integrity Server 2006 

Administration Guide.

Setting MKS Source Policies 


MKS Source policies at the global level. You can set the policies by using the MKS Integrity 

Administration Client as illustrated in the following task, or by editing the si.policy file 

located in the default installation directory C:/Program Files/MKS IntegrityServer/ 

config/policies. 

For details on creating or editing MKS Source policies, see the MKS Integrity Server 2006 

Administration Guide. 

To edit MKS Source policies using the MKS Integrity Administration Client 

1 Open the MKS Integrity Administration Client. 

2 Click to expand the MKS Source node. 

3 Click to highlight the Policies section. The Global Policies section displays in the right 

pane. 

4 Highlight Global Policies in the right display pane. 

5 Select Policies > Edit. The policy editor displays the policy section you selected. 

TIP To edit global policies, you can also open the shortcut menu by highlighting Global 

Policies in the right pane, right clicking, and selecting Edit. To edit project policies, 

choose the project in the right pane, right click, and select Edit. If the projects are not 

listed, right click and select Create, and then select the appropriate project. 

To display the global policies that are set for the MKS Integrity Server, double click 

to expand the Global Policies section in the right pane. 

265


266 

NOTE To enable a policy option, select that option. For example, to require a 

revision description each time a member is checked in, select the Revision 

Description Required option. To lock any policy, click the lock box (on the left side) 

beside that policy. Locking a policy at the global level prevents any other project 

policy or client preference from overriding that policy. A check mark displays for all 

enabled policies. A lock symbol displays for all policies that are locked. 

Options that have been explicitly set display in a bold typeface. 

a) Click the General tab and set the mandatory policies as described in the following 

table. 

Global Policies: General 

Global Policy Policy Value 

Revision Description Required Disabled 

Archive Description Required Disabled 

Deferred Operations Mandatory Disabled 

b) Click the Change Packages tab and set the mandatory policies as described in the 

following table. 

Global Policies: Change Packages 

Global Policy Policy Value 

Change Packages Enabled Enabled 

Track Locks In Change Package Disabled 

Use Change Package Tracking Label Disabled 

Change Packages Mandatory Disabled 

Integrity Manager Issue Mandatory Disableda a While it is not a requirement to use MKS Integrity with the Implementer and MKS Source integration, if 

you are using MKS Integrity, this policy must be disabled. 

NOTE At any time after changing the policy settings, you can restore all default 

settings by clicking Reset to Defaults. Clicking the reset button resets only the 

options displayed on the current active tab. 

6 To accept the changes after editing the policies, click OK. 

7 Under the MKS Source node, click to expand the Permissions section. 

8 Under Permissions, click to highlight Global. A list of users and/or groups displays 

in the right pane.


9 From the menu, select ACL > Dev Path Inheritance to set the permission to enabled. 

When you have finished setting the policies, the expanded Global Policies should look 

similar to the following illustration (depending on other policies you may have defined). 

Creating and Setting an MKS Integrity ACL and Permission 

The integration with MKS Source requires the integration user configured in an integration 

group. MKS Source requires an ACL entry for internal processing. 

To configure the required MKS Integrity ACL 

1 On the MKS Integrity Server, click Start MKS Authorization Administration. 

2 Add the following required ACL entry: 

mks:impersonate:group: 

principle: 

Impersonate allowed 

IMPORTANT In this example, is a group that contains the 

integration user. Change this value to reflect the group name you created. To avoid 

compromising your security, use a group other than the everyone group; by default, 

all users are part of this group. 

267


268 

Creating and Setting MKS Source ACLs and Permissions 

You can set MKS Source ACL permissions at the global level or you can make them project 

specific. If you use MKS Source for multiple platform development in addition to 

Implementer iSeries projects, MKS recommends you define the permissions for this 

integration at the project level to avoid possible conflict with other projects that may require 

different ACL values. 

Once you have added the integration user and implementer developer group and/or 

users to MKS Integrity, you must set the ACL permissions that control user access to global 

functions, product projects, and environment projects. 

The integration user and implementer developer group require different global ACL 

permissions and different ACL permissions for projects. 

NOTE The following tasks are described using the MKS Integrity Administration 

Client. For information on performing these tasks using the MKS Integrity Client 

GUI, see the MKS Integrity Server 2006 Administration Guide. 

The following tasks assume the principals exist. If the principals have not been 

created on your system, you must add or import them before you can assign the 

permissions. 

To set global ACL permissions for the integration user and Implementer developer 

group 

1 From the MKS Integrity Administration Client, open the MKS Source view, click to 

expand the Permission section, and then highlight Global. The display pane shows any 

existing permission information for the mks:si ACL. 

2 Right click to add the principal, or from the Principal list, select the 

user. 

3 From the menu, select ACL > Change Permissions. The Change Permissions dialog box 

displays.


4 In the Permissions area, change the condition of the following permissions by clicking 

the indicator box and toggling through the condition indicators until the box displays a 

green plus sign, indicating the allowed condition. 

Set permissions for the user as described in the following table. 

5 To accept the changes, click OK. 

6 Right click to add the principal, or from the Principal list, select the group. 

7 From the menu, select ACL > Change Permissions. The Change Permissions dialog box 

displays. 

8 In the Permissions area, change the condition of the following permissions by clicking 

the indicator box and toggling through the condition indicators until the box displays a 

green plus sign, indicating the allowed condition. 

Set permissions for the implementer developer group as described in the following 

table. 


Global ACL Permissions: Integration User 

ACL Permission Permission Value 

AddMember Allowed 

ChangePackageAdmin Allowed 

CreateChangePackage Allowed 

Login Allowed 

ShareArchive Allowed 

Global ACL Permissions: Implementer Developer Group 



CreateChangePackage Allowed 

Login Allowed 

ShareArchive Allowed 

To set base product project ACL permissions for the integration user and Implementer 

developer group 

1 From the MKS Integrity Administration Client, open the MKS Source view, click to 

expand the Permissions section, and highlight Projects. The display pane shows any 

existing project permission information for the mks:si ACL. 

269


270 

2 To create a project ACL, select ACL > Create Project ACL from the main menu. The Select 

a Project dialog box displays. 

NOTE The following illustration shows an existing project ACL. 

3 Select the registered MKS Source project to create the ACL for, 

and click OK. The Confirm ACL Creation dialog box displays. 

4 To create the new project ACL, click Yes. The Select ACL Entries to Add dialog box 

displays the project ACL name. For example, for the BaseProductProject project, the 

project ACL name is mks:si:project:id:BaseProductProject.

5 From the Principal list, select the user. 


6 In the Permissions area, change the condition of the following required permissions as 

described by clicking the indicator box and toggling through the condition indicators 

until the box displays a green plus sign, indicating the allowed condition. 

Set permissions for the user as described in the following table. 

ACL Permissions: Base Product Project: Integration User 


AddSubproject Allowed 

ApplyProjectLabel Allowed 

Checkpoint Allowed 

CreateDevpath Allowed 

CreateSubproject Allowed 

DeleteProjectLabel Allowed 

FetchRevision Allowed 

ModifyProjectAttribute Allowed 

MoveProjectLabel Allowed 

OpenProject Allowed 

NOTE You can set all other permissions to allowed or denied as needed. 


8 From the menu, select ACL > View ACL. An ACL mks:si:project view displays. 

271


272 

9 Right click the group, and select Change Permissions. The 

Change Permissions dialog box displays. 

10 Click Deny All to deny all permissions. 

11 Set the ACL permissions for implementer developer group for the 

as described in the following table. 

ACL Permissions: Base Product Project: Implementer Developer Group 



CheckIn Allowed 


Lock Allowed 

ModifyAuthor Allowed 

ModifyMember Rev Allowed 


12 To accept the changes, click OK. An ACL mks:si:project view displays. 

13 Click Close. 

To set base environment project ACL permissions for the integration user and 

implementer developer group 

1 From the MKS Integrity Administration Client, open the MKS Source view, expand the 

Permission section, and then highlight Projects. The display pane shows any existing 

MKS Source projects. 

2 Select the registered MKS Source project to create the 

ACL for, and click OK. The Confirm ACL Creation dialog box displays.


3 To create the new project ACL, click Yes. The Select ACL Entries to Add dialog box 

displays the project ACL name. For example, for the BaseEnvironmentProject 

project, the project ACL name is mks:si:project:id:BaseEnvironmentProject. 

4 From the Principal list, select the user. 

5 Set permissions for the user as described in the following table. 

ACL Permissions: Base Environment Project: Integration User 


AddSubproject Allowed 

ApplyProjectLabel Allowed 

Checkpoint Allowed 

CreateDevpath Allowed 

CreateSubproject Allowed 

DeleteProjectLabel Allowed 


ModifyProjectAttribute Allowed 

MoveProjectLabel Allowed 


NOTE You can set all other permissions to allowed or denied as needed. 


7 From the menu, select ACL > View ACL. An ACL mks:si:project view displays. 

8 Right click group and select Change Permissions. The 

Change Permissions dialog box displays. 

9 Click Deny All to deny all permissions. 

10 Set the ACL permissions for the implementer developer group for the 

as described in the following table. 

273


274 

ACL Permissions: Base Environment Project: Implementer Developer Group 



DropMember Allowed 


ModifyMemberRev Allowed 


11 To accept the changes, click OK. An ACL mks:si:project view displays. 

12 Click Close. 

This concludes the setup tasks in MKS Source. The Implementer administrator must perform 

the following setup tasks in Implementer. 

Implementer Setup and Administration 

The setup and administration steps in Implementer are primarily one-time tasks; however, 

the MKS Source integration adds a few steps to the standard Implementer release control 

activities, which are periodic ongoing tasks. Once you complete the initial tasks to configure 

the MKS Source integration, the ongoing tasks are standard functions that apply to using 

release control within the development cycle and using MKS Source as an additional 

repository for Implementer source. 

The setup tasks in Implementer require the assistance of your Implementer administrator. 

Overall, the Implementer and MKS Source integration requires the skill sets of both your 

MKS Integrity administrator and Implementer administrator. MKS recommends you 

coordinate the configuration of this integration with the applicable administrators in your 

organization to ensure a successful and smooth process. 

The one-time setup tasks in Implementer include the following: 

Define MKS Source values in Implementer. This task begins on page 275. 

Verify object codes for archiving in MKS Source. This task begins on page 278. 

Verify Implementer user profiles have a valid MKS Integrity user ID. This task is 

described on page 235. 

Perform product maintenance (create an initial product or use an existing product) and 

activate product source archiving in MKS Source to create a product subproject. This 

task begins on page 280. 

Perform product version maintenance (create a new version or use an existing version) 

and set the development path for the current version to *HEADREV (or *VERSION if not 

the current release). This task begins on page 283.


Starting with production and moving toward QA1, perform product/version/ 

environment maintenance (use an existing or create a new product/version/ 

environment) and activate MKS Source archiving for the environment, which creates 

and populates an environment subproject in MKS Source. This task begins on page 286. 

A chronological checklist of the tasks required to configure the Implementer and MKS Source 

integration is provided page 296. MKS recommends you use the checklist to ensure you 

complete each required task in the order described. 

NOTE The Implementer Server must be active for successful communications with 

MKS Source. For information on reloading the server with current configuration 

and environment information if communications fail, see “Managing Implementer 


Defining MKS Source Values in Implementer 

You activate the integration and define the MKS Source communication parameters in 

Implementer on the MKS Source Setup panel. 

Your Implementer user profile must have authority to maintain System Control Maintenance 

(defined in Work with Users) to change the default values on the MKS Source Setup panel. 

Without this authority, changes to the panel are not allowed. 

To define MKS Source values in Implementer and activate the integration 

1 From the MKS Implementer Menu, type 48, MKS Source Setup, and press ENTER, or 

issue the STRIM *SRCMGT command. The MKS Source Setup panel displays. 

275


276 

2 In the Integration enabled field, type Y. 

NOTE Once the integration is active, if you later decide to disable it after using 

MKS Source archiving, a message notifies you that all products configured for the 

integration must have the Archived by MKS Source set to N before you can disable 

the integration on this panel. 

3 In the Communications timeout, Server, Server browser port, MKS Source User ID, and 

Password fields, do either of the following: 

Press F16=Copy MKS Integrity Setup to import the values defined on the 

MKS Integrity Setup panel. Use this option when MKS Source and MKS Integrity 

are located on the same server. 

Complete the fields as described in the following table. Use this option when 

MKS Source and MKS Integrity are located on different servers and/or use different 

user IDs. 

4 In the Base Product project and Base Environment project fields, specify the values as 

described in the table on page 277. 

5 Press F7=Test to ensure communications are active and a connection can be established. 

If communications are successful, the System available field value changes to Y, and 

a message at the bottom of the panel confirms the status. Continue with the next 

step. 

If communications are not successful, you must resolve the communication problem 

before continuing. Once resolved, continue with the next step. 

6 Press ENTER. The two base projects you specified validate in MKS Source. An error 

displays if problems occur attempting to access the information. After resolving the 

error, press ENTER to update the information. 


MKS Source current status 

System available 

MKS Source Setup Field Descriptions 

Indicates if communications are active and the integration between 

Implementer and MKS Source is enabled at the system level. 

Yes: Communications are active and the integration is 

functioning. Required value to receive edit checks on the 

remaining fields on this panel. 

No: Communications are inactive and the integration is not 

functional.




MKS Source connection setup 

The following fields define the communication parameters that allow Implementer to integrate with 


Integration enabled Specify whether the integration between Implementer and 

MKS Source is active. 

Yes: The integration is active. Specify Y to activate the 

integration. 

No: The integration is not active. Specify N to deactivate the 

integration. You can also use this setting to save current values 

not yet finalized while troubleshooting communication problems. 

Communications timeout Number of seconds Implementer waits for a valid response after 

contacting MKS Integrity Server running MKS Source. Only used 

when MKS Source is used for source archiving. 

If communications between Implementer and MKS Integrity Server 

are slow, set this to a higher number to prevent time outs during 

normal usage, such as if the MKS Integrity Server is available but 

not responding in a timely manner due to heavy traffic. 

Server IP address or host name of MKS Integrity Server running 

MKS Source. Used for all communications between Implementer 

and MKS Integrity Server. Must be a host name or IP address, not 

a URL that begins with http:// or https://. Can be the same 

server or a different server than that specified in the MKS Integrity 

Setup panel. Do not enclose the value in quotes. 

Server browser port The port number used to communicate to MKS Integrity Server 

running MKS Source. Specify a value between 1–65535. 

MKS Source User ID User profile that has administrative rights in MKS Source. This 

user ID is used to test the connection to MKS Integrity Server, and 

is the impersonation user ID used to proxy all commands between 

Implementer and MKS Source. Must be the same user ID as 

described in “Creating the Integration User” on page 264. Casesensitive 

field—the case specified in MKS Source must be 

specified here. 

Password Password of the MKS Source user ID specified in the previous 

field. Non display field that displays as blank when typing the 

password value. Case-sensitive field—the case specified in 

MKS Source must be specified here. 

Base Product project Specify the base product project in MKS Source that all product 

subprojects are created under. The project is validated in 

MKS Source; thus, it must exist in MKS Source prior to referencing 

here. Type the value exactly as it exists in the MKS Source project 

directory (including the directory, file name, and file extension), for 

example, c:/BaseProductProject/project.pj. a 

277


278 



Base Environment project Specify the base environment project in MKS Source that all 

environment subprojects are created under. The project is 

validated to MKS Source; thus, it must exist in MKS Source prior to 

referencing here. Type the value exactly as it exists in the 

MKS Source project directory (including the directory, file name, 

and file extension), for example, c:/ 

BaseEnvironmentProject/project.pj. a 

a The BaseProductProject and BaseEnvironmentProject do not have to be top level projects in 

MKS Source. The format of your projects may be different from the examples based on your 

MKS Source platform and configuration options. Ask your MKS Source administrator for the exact 

entries. 

Controlling Archiving in MKS Source by Object Code 

You can activate and deactivate MKS Source archiving at the object code level in 

Implementer. The archive value set for an object code applies to all environments configured 

for MKS Source archiving. 

When the Implementer and MKS Source integration is enabled, an object codes’s Archived by 

MKS Source value defaults based on the following rules: 

Source-based object codes and those with a special characteristic of PCFILE are set to 

automatically archive in MKS Source. 

Non source-based object codes and those with a special characteristic of PCDIR are not 

eligible for archiving in MKS Source; thus, they are set to a value that does not allow 

MKS Source archiving and cannot be changed. 

Before allowing check out and promotion activities using the MKS Source integration, you 

can optionally deactivate MKS Source archiving for other object codes you may not want 

archived, for example, IFS object codes for .jar files or Lotus Notes database files. 

IMPORTANT Before allowing Implementer check out and promotion activity with 

MKS Source archiving enabled, review the object code Archived by MKS Source 

values and make any necessary changes. After check out and promotion activity 

begins with MKS Source archiving enabled, you must only change the Archived by 

MKS Source value when Implementer check out and promotions are not active. 

If you change the Archived by MKS Source value to Y, to establish accurate 

MKS Source revisions for existing items with the new object code value, you must 

disable and repopulate all archived product/version/environments. To do this, 

change the Archived by MKS Source value from Y to N for all archived product/ 

version/environments, then in Product Version Maintenance use F6=Enable 

MKS Source Archiving, starting with the oldest *VERSION ending with the 

*HEADREV version. For more information, see “To create archives for existing 

previous versions of iSeries source” on page 285.

To set object codes for archiving in MKS Source 


1 From the Implementer Menu, type option 44, Object Codes, and press ENTER. The Work 

with Object Codes panel displays. 

2 To change an existing object code, type 2=Change next to an object code, and press 

ENTER. The Change Object Code panel displays. 

3 Complete the panel as needed. For details on completing this panel, see “Object Codes” 

on page 127. 

In the Archive in MKS Source field, specify one of the following: 

Y=Yes Archives source for the object code in MKS Source if the target 

environment is eligible. This is the default value and valid only for 

source-based object codes and those with the special characteristic 

PCFILE. 

N=No Does not archive source for the object code in MKS Source. This is the 

default value and required value for non source-based object codes 

and those with the special characteristic PCDIR. 

After changing the field value, a dialog window requires you confirm the action. Type Y, 

and press ENTER. Implementer searches the repository for objects with this object code. If 

an item with this object code has association with an environment archived in 

MKS Source, existing revisions are removed from all repository items and locks for the 

object code/environment. 


279


280 

Product Setup and Source Archiving 

Products are a component of Implementer’s release control feature. Release control allows 

you to internally manage your software release process as a fundamental part of your daily 

change management operation that includes software versioning at the product, version, 

release and environment level. It provides for additional management, control, and 

orientation by release name or release number, allowing you to effectively manage 

production environments. 

With release control you can name each release of software before rolling out to production. 

While preparing a release for rollout, you automatically “freeze” the environments that 

manage the release to ensure unplanned changes are not subsequently promoted beyond a 

user-specified cutoff period. After rollout you can view the release history for that release 

and other releases as part of the post-project assessment. 

In Implementer Menu option 51, Products, you must define each product associated with 

MKS Source archiving. You have the option to use existing products or create new products. 

You then activate MKS Source archiving for the product, which automatically creates the 

product’s subproject in MKS Source. Implementer’s Product Maintenance panel allows you 

to establish product archiving in MKS Source. When the Archived by MKS Source field value 

is N, field entry is not allowed. To change the value to Y and create the product subproject in 

MKS Source, you use the function F6=Enable MKS Source Archiving. 

NOTE For details on release management and deployment, see the MKS Implementer 

2006 Release Management Guide. 

Requirements and Considerations 

Each product corresponds to the product subproject directory in MKS Source. For this 

reason, the product names you use must conform to a naming convention that is 

representable on the file system of the operating system that hosts the server for 

MKS Source. Generally, the product name must start with a letter A–Z and continue 

with a contiguous sequence of letters A–Z, numbers 0–9, or underscores ‘_’. The product 

name allows 10 characters consisting of letters and numbers only (no special characters), 

for example, ACCTRVCV06 is allowed, ACCTRCV-06 is not allowed. (This requirement 

also applies to the names of versions, releases, and environments.) 

Multiple products cannot archive the same environment—only one product can archive 

an environment in MKS Source. 

The base product project must exist in MKS Source before performing the following task. 

To work with products and enable MKS Source archiving to create product subprojects 

1 From the Implementer Menu, type option 51, Products, and press ENTER. The Work with 

Products panel displays.

2 Do one of the following to display the Product Maintenance window: 

Type 1=Create on the first option line, and press ENTER. 


Select an existing product with option 2=Change, and press ENTER. 

Select an existing product with option 3=Copy, and press ENTER. 

3 Complete the fields as required. For detailed information on this panel, see the 


4 The Archived by MKS Source field defaults to N. To activate source archiving for this 

product in MKS Source, press F6=Enable MKS Source Archiving. 

NOTE If the MKS Source integration is not active on the MKS Source Setup panel in 

Implementer, the Archived by MKS Source field is view-only and function key 

F6=Enable MKS Source archiving does not display. For details, see “Defining 

MKS Source Values in Implementer” on page 275. 

A message displays requiring you to confirm your request to create an MKS Source 

product project for the selected Implementer product. 

281


282 

5 To continue, type Y, and press ENTER. 

A series of validations ensure you have the required permissions. A message notifies of 

problems trying to create the product project, or if the product or subproject already 

exist in MKS Source. 

IMPORTANT Once you archive a product in MKS Source, the Archived by 

MKS Source field is editable and can be changed to N if needed. If you change the 

value to N to deactivate archiving, a message notifies you that interim development 

activity performed while environment archiving is not active causes gaps in the 

version history if you later reactivate archiving. Interim source changes are not 

captured separately in the archives while archiving is off; however, the next 

promoted version captures any changes made since the last archived promotion. 

You must confirm your request to deactivate archiving. To re-establish the 

integration, additional setup work is required. Any change to the Archived by 

MKS Source field value causes a source reload in MKS Source to ensure the server is 

refreshed with current data. 

Once all edits are passed, a confirmation panel confirms creation of the subproject. On 

the Product Maintenance panel, the Archived by MKS Source field updates to Y. 

MKS Source creates the product subproject, for example, the product Inventory has the 

subproject INVENTORY/project.pj under the base product project c:/ 

BaseProductProject/project.pj as illustrated next. 

6 Repeat steps 2–5 for each product to archive in MKS Source. 

NOTE Permissions for each product subproject are inherited from the base product 

project.

Product Version Setup and Development Paths 


Each product you define in Implementer and associate with MKS Source archiving has one or 

more versions that represent different stages of the software. You have the option to use 

existing versions or create new versions. 

Each product version is associated with a development path in MKS Source. The 

development path is an identifier that specifies a branch of software development. Changes 

made through a new *VERSION development path are assigned suffixed revisions, for 

example, 1.4.1.2, which distinguishes them from the unsuffixed revisions assigned to the 

main *HEADREV development trunk, for example, 1.5. This allows you to track logical 

revisions for multiple versions of a product in simultaneous development. 

Implementer’s Product Version Maintenance panel allows you to establish the development 

path for a product version. Once established, you can process the update that creates the 

development path in MKS Source. 

The valid development path values are as follows: 

*NONE: Versions set to development path *NONE are not archived. This is the default 

value Implementer assigns to the development path for a product version. It is also used 

for older releases that are not archived in MKS Source. 

*HEADREV: This is the starting point for a new version and represents the current 

version in development. It is the main trunk on a version tree. The head revision uses the 

main trunk development path in the project. The main trunk development path is 

always present (you cannot create it). 

Only one version of a product can have the development path value *HEADREV 

specified at a time. All prior versions must be set to *VERSION before assigning the 

value *HEADREV to a new version. 

*VERSION: This is a branch on a trunk. You manually set an outgoing *HEADREV 

product version’s development path from *HEADREV to *VERSION before you create a 

new version, which becomes the new *HEADREV trunk version. 


The version name corresponds to the project checkpoint and development path in 

MKS Source. For this reason, the version names you use must be representable on the file 

system of the operating system hosting the server for MKS Source. The version name 

must start with a letter A–Z and continue with a contiguous sequence of letters A–Z, 

numbers 0–9, or underscores ‘_’. 

When a product version has a based on product/version/release specified, the based on 

product/version/release must be checkpointed in MKS Source. For details, see 

“Product/Version/Release Setup and Checkpointing in MKS Source” on page 291. 

283


284 

Only one version per product can be set to *HEADREV. When multiple versions exist, 

you must set all previous versions to *VERSION before you can set a new version to 

*HEADREV. 

The product version must not have open releases when creating the development path. 

A message notifies you if open releases exist. 

Before creating a new release of a product, you must close the current release. 

To work with product versions and set the MKS Source development path for a version 


Products panel displays. 

2 Select the product with option 10=Work with Versions, and press ENTER. The Work with 

Product Versions panel displays. 

3 Do one of the following to display the Product Version Maintenance window: 


Select an existing version with option 2=Change, and press ENTER. 

Select an existing version with option 3=Copy, and press ENTER. 

NOTE If Implementer or the product are not set up for MKS Source archiving, the 

MKS Source Devpath field is view-only, and function key F6=Create Development 

Path does not display. For details, see “Product Setup and Source Archiving” on 

page 280, and “Defining MKS Source Values in Implementer” on page 275.


4 Complete the fields as required. For MKS Source integration, the relevant fields are 

Version, Version Description, Based on Product, Based on Version, Based on Release, 

and MKS Source Devpath. For details on this panel, see the MKS Implementer 2006 Release 


Do one of the following: 

a) If this is the current version, in the MKS Source Devpath field, type *HEADREV (this is 

the starting point for the version, which is used to create the next current release), 

and press ENTER. 

b) If this is a previous version (not the current version) in the MKS Source Devpath 

field type *VERSION. 

NOTE The next two steps only apply to the *VERSION development path. The 

*HEADREV development path automatically assigns revisions from the main trunk; 

therefore, it does not require a development path assigned. 

5 To create the *VERSION development path in MKS Source, press F6=Create 

Development Path in MKS Source. A message displays requiring you to confirm your 

request to create the MKS Source development path for the selected Implementer 

product version. 

6 To continue, type Y, and press ENTER. 

A series of validations ensure you have the required permissions and the development 

path can be created. A message displays if the product development path already exists 

or if the product version has an open release. Once all validations successfully pass, the 

product project is checkpointed in MKS Source with a checkpoint name equal to the 

version name, and a development path is created on the checkpoint. 

7 Repeat steps 2–6 for each version of the product that requires a development path in 


To create archives for existing previous versions of iSeries source 

1 Activate archiving for the product. 

2 Activate archiving for the oldest version you want to archive in MKS Source. Specify the 

development path *HEADREV. 

3 Activate archiving for each environment within the version. 

4 Change the version to use development path *VERSION, and create the development 

path. 

5 Activate archiving for the next oldest version you want to archive in MKS Source. 

Specify the development path *HEADREV. 

6 Activate archiving for each environment within that version. 

285


286 

7 Repeat steps 4–6 for each of the remaining versions, from the oldest version to the most 

current version. 

8 Activate archiving for the current version. Specify the development path *HEADREV. 

9 Activate archiving for each environment within the current version. 

IMPORTANT Once you archive a product version in MKS Source, if you change the 

MKS Source Devpath back to *NONE a dialog window notifies you that the action 

results in disabling the integration. Thus, any interim development activity 

performed while environment archiving is inactive causes gaps in the version 

archive if you later reactivate the integration and archiving. 

Product/Version Environments Setup and Environment Population 

Implementer’s Product Version Environment Maintenance panel allows you to activate 

source archiving for the environment, which automatically populates the environment 

project in MKS Source. This process performs the initial import of environment source by 

copying all eligible source items in the Implementer environment on the iSeries, performs a 

mass check in to the product subproject, imports into the environment subproject, and 

updates the Implementer repository and locks with the new revisions provided by 



This function applies to production and QA environments only. 

Environment names correspond to the environment subproject directory in MKS Source. 

For this reason, the environment names you use must be representable on the file system 

of the operating system hosting the server for MKS Source. The environment name must 

start with a letter A–Z and continue with a contiguous sequence of letters A–Z, numbers 

0–9, or underscores ‘_’. 

Running simultaneous environment population jobs can result in invalid revisions in 

MKS Source and invalid revision references in Implementer. Therefore, you must 

process the environment population job in a single threaded job queue, or verify the 

results of each environment population are correct before enabling the next environment 

population. 

You must run a Build List for each applicable environment before performing this step. 

For details, see page 117. 

The environment can be associated with multiple product/versions, but can only be 

archived in one product/version. 

If a based on product/version/release is specified in the product/version, it must exist 

in Implementer.


If a based on environment is specified, the based on product/version/release specified 

in the associated product/version must have a product/version/environment with the 

same environment name as the based on environment specified in the target 

environment. 

The based on product version environment must be archived in MKS Source to provide 

the starting revisions for the new environment’s population. 

You must enable environments in a specific order to ensure the production environment 

is assigned lower revisions than those assigned to items in QA environments. First, 

enable the production (*PRD) environment and then enable the quality assurance 

environments (*QAC). If you have multiple *QAC environments, enable them in order 

from production toward QA1, for example, QA4, QA3, QA2, QA1, where QA4 is the 

environment closest to “going into” production. 

The environment population uses Implementer’s repository entries and locks to control 

when it assigns new revisions as follows: 

When processing a production member, if a based on environment is not specified 

or the member does not exist in the based on environment, Implementer performs 

an MKS Source check in to assign the initial revision ID. 

When a member exists in a based on environment, Implementer uses the based on 

member’s revision to assign the new environment member revision. 

When processing a member from QA and a lock does not exist, Implementer 

searches the product/version environment list toward production and uses the 

revision from the first environment where the member exists. 

When processing a member from QA and a lock exists, Implementer performs an 

MKS Source check in to generate a new revision ID. 

The following table illustrates the results of processing a member. 

Environment Sequence Number Lock Assigned Revision Assigned 

PRD 10 N 1.1 

QA4 20 N 1.1 

QA3 30 Y 1.2 

QA2 40 N 1.2 

QA1 50 Y 1.3 

287


288 

NOTE 

When enabling an environment, Implementer verifies the sequence you have 

defined on the Product Version Environment Maintenance panel to ensure the 

environments process in sequential order from production to QA1. 

It is not necessary to enable all environments for a product/version. The revision 

advances when the lock moves into the first MKS Source archive-enabled 

environment encountered. 

To work with product/version environments and perform the initial environment 

population 





3 Do one of the following to display the Product Version Environment Maintenance 

window: 


Select an existing version with option 2=Change, and press ENTER. 

Select an existing version with option 3=Copy, and press ENTER.


4 Complete the fields as required. For detailed information on this panel, see the 


In the Based on environment field, type the environment name, or position the 

cursor in the field, and press F4=Select Environment and use option 1=Select to 

select an environment on the Environment Selection window. 

In the Always checkout from MKS Source field, specify Y to always check out source 

from MKS Source. With this option, native source member sequence numbers and 

source change dates are not maintained when a member is checked out. 

The default value N allows you to specify the source check out location as either 

MKS Source or as a local repository, which maintains native source member line 

sequence numbers and source change dates. 

The Archived by MKS Source field is view-only when the field value is N. This the 

required value to change the Based on environment field value as described in the next 

step. The value automatically changes to Y after successfully completing the 

environment population. Performing an environment population is the only way to set 

the field value to Y (you cannot manually change the value to Y). If the job no longer 

exists, for example, it was deleted from queue, you can change the value to N, and then 

rerun the environment population. If the job fails, you must first resolve the cause of the 

failure before rerunning the job. 

IMPORTANT Once the environment population successfully completes and the 

Archived by MKS Source field is set to Y, you can change the value back to N to stop 

archiving. This action displays a message to inform you that any development 

activity performed while environment archiving is not active causes interim gaps in 

the archived versions if you later reactivate archiving. 

5 To perform the environment population, press F6=Enable MKS Source Archiving. 

NOTE Function F6=Enable MKS Source Archiving is available only when: The 

integration is enabled in MKS Source Setup, the product is archived in MKS Source, 

the product/version is either *HEADREV or *VERSION, and the Archived by 

MKS Source value is N. 

If the product/version has the MKS Source Devpath value *VERSION, Implementer 

verifies the development path exists in MKS Source. If it does not exist, a message 

confirms that you must create the development path in MKS Source before performing 

the environment population. For details, see “Product Version Setup and Development 

Paths” on page 283. 

Once all validations pass, a confirmation window displays. 

289


290 

6 Proceed as follows: 

a) Optionally specify an existing MKS Integrity issue or press F4 to prompt the Select 

Issue panel. Implementer applies this issue to the items checked in during the 

population process. 

b) Specify the job queue parameters as needed, and press ENTER. This creates the 

environment project in MKS Source and submits a job to populate the environment 

based on the values you specify. 

If you are performing this step to re-enable an environment project that was previously 

archived, a message confirms the action and explains that any interim development 

performed while archiving was off causes interim gaps in the MKS Source archives. 

Because of this, the first revision of an item checked in to MKS Source after re-enabling 

may have changes that occurred in multiple promotions when the environment was not 

enabled, appearing as though they all occurred during the last promotion. 

During the environment population, on the Work with Product Version Environments 

panel, the Archived by MKS Source field shows the interim value I to indicate the 

environment population is in process. If you attempt to change the field value from I to 

N while the process is active, an error message notifies you of the active job and advises 

you wait for the job to complete. You also cannot change the field value from I to 

If the job does not complete successfully, for example, due to communication problems 

between Implementer and MKS Source, a message informs you of the problem and the 

job fails. After resolving the problem, on the Product Version Environment Maintenance


panel set the Archived by MKS Source field value to N, and resubmit the environment 

population by pressing F6 (for details, see step 5 on page 289). 

NOTE To assist with error resolution, the submitted job information displays in the 

second level text of messages related to the environment population. 

Product/Version/Release Setup and Checkpointing in MKS Source 

Just as you can check in a source file to preserve its changes from one revision to another, you 

can also track changes to the configuration of a project and source changes related to a 

product release. In MKS Source, this is called checkpointing. 

Checkpointing saves a copy of the project as a baseline revision in the project’s history. The 

checkpoint includes the list of members along with their revision numbers and locations, as 

well as subproject revisions and locations, and project and member attributes. 

You can use the project’s revision number to keep track of your projects, but to simplify postrelease 

maintenance, you can also use a release name label to identify significant project 

development milestones when you checkpoint a project. 

When you checkpoint a project, MKS Source checkpoints the product and environment 

subprojects. Using checkpointed projects, MKS Source also allows you to view a summary of 

the changes that occurred between two versions of a project. 


Release names correspond to the release checkpoint name in MKS Source. For this 

reason, the release names you use must be representable on the file system of the 

operating system hosting the server for MKS Source. The release name must start with a 

letter A–Z and continue with a contiguous sequence of letters A–Z, numbers 0–9, or 

underscores ‘_’. 

You must close and checkpoint the current release before you can open a new release in 

the same product/version. 

Checkpointing a release is a one-time action. Once you checkpoint a release, you cannot 

checkpoint it again. You can confirm the checkpoint status on the Product Version 

Release Maintenance panel. 

The release must be in a closed state. You can confirm the release state on the Product 

Version Release Maintenance panel. In the Date closed field, a valid date confirms the 

release is closed. If you attempt to checkpoint an open release, a message confirms you 

must close the release before checkpointing is allowed. 

NOTE To close a release, from the Work with Releases for a Product/Version panel, 

select the release with option 12=Change Status, and press ENTER. Select the 

appropriate close status with option 1=Select, and press ENTER. 

291


292 

To work with product/version/releases and checkpoint a release 





3 Select the version with option 10=Work with Releases, and press ENTER. The Work with 

Releases for a Product/Version panel displays. 

4 Do one of the following to display the Product Version Release Maintenance window: 


Select an existing release with option 2=Change, and press ENTER. 

Select an existing release with option 3=Copy, and press ENTER. 

5 Press F6=Checkpoint in MKS Source. The function key displays only when the product 

version is archived in MKS Source and the release is closed. A confirmation window 

displays. 

6 In the Reply field type Y to confirm your request to checkpoint the specified product/ 

version/release.

Preparing for the Next Release 


As the development cycle progresses and work on the current release comes to completion, 

minimal administration is required to prepare for creating a new release. The basic tasks 

consist of closing the current version/release and opening the new version/release. 

NOTE The ongoing administration tasks are functions you perform in Implementer. 

MKS Source does not require ongoing administration. 

To prepare for a new release 

1 Close the current release of the product/version. 

a) In the Work with Releases for a Product/Version panel, select the current release 

with option 12=Change status, and press ENTER. In the Change Release Status 

window, select the appropriate closed status with option 1=Select, and press 

ENTER. 

b) In the Product Version Release Maintenance panel, checkpoint the release by 

pressing F6=Checkpoint in MKS Source. 

2 Create and open a new release of the product/version. 

3 Begin development on the new release. 

You can perform patch and PTF release activity with environments in previous versions 

of the product now set to development path *VERSION. These changes are tracked on 

branch revisions with suffixes after the departure point, for example, 1.4.1.2 for a 

change to an item that was at revision 1.4, while the trunk revision, for example, 1.5, is 

assigned the next revision of the item promoted into the *HEADREV version. 

Preparing for the Next Version 

NOTE You must perform these steps for each new release. 

As the development cycle progresses and work on the current version comes to completion, 

minimal administration is required to prepare for creating a new version. The basic tasks 

consist of closing the current version/release and opening the new version/release. 

NOTE The ongoing administration tasks are functions you perform in Implementer. 

MKS Source does not require ongoing administration. 

293


294 

To prepare for a new version 

1 From the Product Version Maintenance panel, set the current *HEADREV version of the 

product to *VERSION to designate it as a previous version, and press F6=Create 

Development Path in MKS Source. 

This forces any further development onto the *VERSION development path, and assigns 

suffixed *VERSION branch revisions to items subsequently promoted, rather than 

*HEADREV trunk revisions that are assigned to items promoted in the new *HEADREV 

version you create in step 5. 

IMPORTANT When you create a new version, you must enable the version’s 

environments for MKS Source archiving before development starts on the new 

version. This ensures that all new development performed for the new version is 

reflected in the source archives. It also ensures the revision numbers in the previous 

version correctly initialize into the new version (using the “based-on” references 

when you define the new version/environments). 

2 Duplicate the existing environment libraries for the new version. Use new library names 

to differentiate between the versions. 

3 Create environments for the new version. For details, see “Environments” on page 81. 

4 Run the Build List for the new environments. For details, see “Environment Repository 

Build” on page 117. 

5 Create a new version of the product in Work with Product Versions and set the 

development path value to *HEADREV. 

6 In Work with Product Version Environments, add environments to the version. For the 

based on environment, specify the corresponding environment from the previous 

release. 

7 Create the environment project. In Product Version Environment Maintenance, press 

F6=Enable MKS Source Archiving. This creates the environment subproject in 

MKS Source under the base environment project, and performs the initial import 

(synchronization) of the environment source. For details, see “Product/Version 

Environments Setup and Environment Population” on page 286. 

8 Create and open a new release of the product/release. 

NOTE You must perform steps 1–9 for each new version/release. 

9 Begin development on the new release. 

You can also perform patch and PTF release activity with environments in previous 

versions of the product now set to development path *VERSION. These changes are 

tracked on branch revisions with suffixes after the departure point, for example,

MKS Integrity Integrations Task Checklists 

1.4.1.2 for a change to an item that was at revision 1.4, while the trunk revision, for 

example, 1.5, is assigned the next revision of the item promoted into the *HEADREV 

version. 

MKS Integrity Integrations Task Checklists 

The following task checklists apply to the steps required to set up the integrations between 

Implementer and MKS Integrity, and Implementer and MKS Source. The checklists are 

helpful aids to use when setting up the integrations, and if you encounter problems with the 

integrations. MKS recommends you verify the completion of each required task prior to 

calling Customer Care. 

Step 

Number 

NOTE The setup tasks in MKS Integrity and MKS Source require the assistance of 

your MKS Integrity administrator. Likewise, the setup tasks in Implementer require 

the assistance of your Implementer administrator. MKS recommends you 

coordinate the configuration of this integration with the applicable administrators in 

your organization to ensure a successful and smooth process. 

Task Description 

MKS Integrity Integration Setup: Task Checklist 

1 Configure MKS Integrity Server ACLs on page 205. 

2 Customize permissions for Implementer change package type on 

page 205. 

3 Modify the MKS Integrity Server communications file on page 206. 

4 Create states on page 210. 

5 Enable promotions from MKS Integrity (optional) on page 212. 

6 Define MKS Integrity values in Implementer on page 226. 

7 State setup in Implementer on page 232. 

8 User profile setup on page 235. 

9 Environment setup on page 237. 

10 (Optional) Enable updating issues based on promotion status on page 240. 

11 (Optional) Enable promotions from MKS Integrity on page 242. 

12 Convert from DesignTracker to MKS Integrity on page 243. 

Task 

Complete 

295


Export to Implementer 

296 

Step 

Number 

Task Description 

MKS Source Integration Setup: Task Checklist 

1 Modify the MKS Integrity Server configuration file on page 206. 

2 Define Implementer state-based capabilities if using MKS Integrity with 

MKS Source and Implementer on page 208. 

3 Create base projects in MKS Source on page 263. 

4 Create the integration user on page 264. 

5 Create the Implementer Developer group on page 264. 

6 Set MKS Source policies on page 265. 

7 Create and set an MKS Integrity ACL and permission on page 267. 

8 Create and set MKS Source ACLs and permissions on page 268. 

9 Define MKS Source values in Implementer on page 275. 

10 Define or modify object codes for archiving in MKS Source on page 278. 

11 Product setup and source archiving on page 280. 

12 Product version setup and development paths on page 283. 

13 Product/version environment setup and environment population on 

page 286. 

14 Product/version/release setup and checkpoint in MKS Source on page 291. 

Check 

Complete 

The Implementer and MKS Source integration provides Export to Implementer, a Java 

application that runs on Windows. The export function allows you to check out and 

optionally deploy PC-based software changes, initiated by an MKS Integrity issue and 

modified under MKS Source control, to an IFS location under Implementer change 

management control on the iSeries. 

The export runs using DTBridge, a client application delivered with Implementer. When 

activated, the export retrieves a list of MKS Integrity issues for a single or group of issues 

based upon the entry of either an issue number or a build number. The bi-directional updates 

occur automatically and include the creation of an Implementer change package for each 

selected issue. The status of the change packages reflect the current development progress 

within Implementer.

Requirements 

The following is required to use this feature: 


Complete the setup tasks described in “Implementer and MKS Integrity Integration” on 

page 196. 

Download, install, and configure DTBridge. DT Bridge requires: 

TCP/IP connection to the iSeries system where Implementer is installed. 

Implementer 2006 or later. 

Windows 2000 Professional or later. 

For product and component compatibility, the DTBridge version must match the 

MKS Integrity version requirements as described in the following table. 

DTBridge is delivered with Implementer; however, the DTBridge version does not need 

to match the Implementer version. If DTBridge is currently installed, you can verify the 

current version by starting the DTBridge Console, and from the DTBridge toolbar click 

Help > About. 

Installing DTBridge 

The tasks involved with downloading and installing DTBridge are as follows: 

Verify the TCP/IP connection. 

MKS Integrity Version DTBridge Release 

2006 2006 

2005 2005 

Download and install the self-extracting installation program dtbridge.exe. 

DTBridge requires an active TCP/IP connection to the iSeries where Implementer is installed. 

If you cannot communicate with the iSeries server successfully, DTBridge will not properly 

connect to process the database changes. 

PING is an MS-DOS program that allows you to verify that a particular Internet Protocol (IP) 

address exists and can accept requests. PING is used diagnostically to verify that a host 

computer you are trying to reach has communications enabled and operational. To verify 

your TCP/IP connection, you can either ping the system or ping the iSeries servers (requires 

ClientAccess installed on the local PC), as described next. If ping is unsuccessful, contact your 

system administrator. 

To ping the system to verify the TCP/IP connection 

1 At a command prompt, type CD.., and press ENTER to return to the root directory C:/. 

297


298 

2 Type PING (system name), and press ENTER. 

A message confirms that either ping was successful, or a time out occurred and the 

system was not located. 

To ping the iSeries servers 

1 At a command prompt, type CD.., and press ENTER to return to the root directory C:/. 

2 Type CWBPING (system name), and press ENTER. 

After polling the iSeries servers, a message confirms the status—either ping of the server 

was successful, or a time-out occurred and the server was not located. 

Use either of the following methods to download DTBridge from the iSeries and install onto 

your desktop. 

Map Network Drive allows you to copy data by sector. Depending on the speed of your 

PC, this method may take longer than File Transfer Protocol (FTP). 

FTP allows you to perform a bulk data transfer. This method is generally quicker than 

mapping a drive, but involves more steps. 

To download and install DTBridge using a mapped network drive 

1 Open Windows Explorer, and click Tools > Map Network Drive. The Map Network Drive 

dialog box displays prompting for a Drive and Path name. 

2 Select the drive name to use or accept the default value. 

3 For Path, type //Your_System_Name/mks/Implementer/MKSIM 

NOTE The default, product library name is MKSIM. If you changed the product 

library to another name, substitute the changed name for MKSIM. 

4 Make sure the Reconnect at Logon box is not enabled, and click OK. You may be 

prompted for a user ID and password to connect to the system. 


6 Double click dtbridge.exe and follow the installation wizard. The default installation 

directory is: 

C:/Program Files/MKS/Implementer/DTBridge 

You can change the destination directory during the install if required. 

To download and install DTBridge using FTP 

1 At a command prompt, type FTP, and press ENTER. The ftp> prompt displays. 

2 Type OPEN your_system_name, and press ENTER. A message confirms the connection is 

in progress, and a prompt displays requesting a user ID.


3 Specify a valid user ID for the system you opened in step 2, and press ENTER. A prompt 

displays requesting the password for the specified user ID. 

4 Type the password, and press ENTER. 

5 Type bin, and press ENTER. A message confirms the representation type is binary image. 

6 Type quote site namefmt 1, and press ENTER. A message confirms that naming 

format 1 is enabled. 

7 Type cd /mks/Implementer/MKSIM, and press ENTER. A message confirms the current 

directory changed, for example, /mks/Implementer/MKSIM. 

NOTE The default, product library name is MKSIM. If you changed the product 


8 Type lcd C:/temp, and press ENTER. A message confirms the local directory is C:/ 

temp. (You may need to create this directory if it does not exist.) 

9 Type get dtbridge.exe, and press ENTER. The self-extracting installation executable 

transfers into directory C:/temp on your PC. 

10 Type quit, and press ENTER. The C:/ prompt displays. 

11 Type cd C:/temp, and press ENTER. 

12 Type dtbridge.exe, and press ENTER. The default installation directory is: 

C:/Program Files/MKS/Implementer/DTBridge 

You can change the destination directory during the installation if required. 

13 Follow the installation wizard to complete the installation. 

Configuring DTBridge Components and Properties 

This section explains how to configure the DTBridge components required for the 

Implementer and MKS Source integration described in this chapter, as well as the help desk 

integration described in “Help Desk Integration” on page 324. The setup involves: 

granting authority to an Implementer file 

defining DTBridge properties file 

The DTBridge properties file contains the application control parameters for several 

integrations. Based on the integration you are configuring, the applicable properties must be 

defined prior to using DTBridge. 

The export feature described in this chapter uses the DTSystemName, DTUser, and 

DTPassword properties to connect to the iSeries and perform the required processing on the 

iSeries system specified in the DTSystemName property. The CIBuildNumberField is used 

299


300 

to identify the name of the custom field you created in MKS Integrity that will contain the 

build number (the field used to find all related issues for the export process). This is a 

required property if you are using MKS Integrity with the Export to Implementer feature. 

NOTE 

The IUPDCI command feature requires additional configuration. For details, see 

“Updating Issues Based on Promotion Status” on page 240. 

The DT Call Association Properties are used for the features described in “Help 

Desk Integration” on page 324. 

Some DesignTracker properties relate to obsolete functionality that is in the 

process of deprecation. Thus, the only DesignTracker properties you need to 

configure are those described in this guide. 

To authorize the user profile to the Implementer file 

Issue the following OS/400 command: 

GRTOBJAUT OBJ(MKSIM/IMCICT) 

OBJTYPE(*FILE) 

USER(DTUSER) 

AUT(*CHANGE) 

To start DTBridge Console and configure the DTBridge properties file 

1 Click Start > Programs > MKS Implementer > DTBridge Console. The DTBridge Console 

window displays. Notice the Status bar indicates DTBridge is currently not active. 

2 Click File > Setup from the menu. The Edit DTBridge Setup properties file displays. 

Instructions and example properties are included within the file. The properties file is 

organized by functional area. The beginning of each section lists the properties with a 

brief description and an example. At the end of each section, the property displays again 

as property name=x. 

When defining the property value, type the value as follows: 

property name=property value 

3 Use the following tables to define the properties respective to the functionality you are 

setting up. 

4 When you are finished, click File > Save Setup. 

IMPORTANT The following tables define the applicable properties in the DTBridge 

file. When defining the OS/400 values, you must use upper case syntax.

General Properties Description 

Logging level to use 

when application is run 

DTBridge General Properties 


0 = Basic logging only. Messages include the DR number and MKS Integrity 

issue number relationship, and verification that the DR was created. 

1 = Detailed Logging. Messages include the DR number, related text and 

description information, and the DR and MKS Integrity issue number relationship. 

This information is useful for diagnostic and support purposes. 

Log JDBC 0 = No. No logging. This is the default value. 

1 = Yes. Generates a detailed log of all JDBC connection messages. (JDBC is the 

Java form of ODBC, and is the communication method between DTBridge and 

multi-platform databases.) This information is useful for diagnostic and support 

purposes, for example, if you have a problem connecting to DTBridge. 

Issue Source Product to derive issues from. Specify CI if you are using MKS Integrity. 

DesignTracker Properties Description 

DesignTracker Properties 

DTSystemName Name of the iSeries system where DesignTracker is installed. 

DTLibrary Name of the DesignTracker installed library. The default product library is MKSIM. 

DTUser Name of the DesignTracker user that has authority to the library defined in the 

DTLibrary property. 

DTPassword Password associated with the DTUser property. 

MKS Integrity Properties Description 

MKS Integrity Properties 

CIServerName Full name of the server that is running the Integrity Server to connect with. A 

value is required. 

CIPort Port number to use to communicate with the Integrity Server defined in the 

CIServerName property. The default is 9001. A value is required. 

CIUserName Name of the user to connect to the Integrity Server. A value is required. 

CIUserPassword Password associated with the CIUserName property. A value is required. 

CIBuildNumberField Name of a custom MKS Integrity field to contain the Build Number. A value is 

required if using the Export to Implementer feature. Create the custom field as a 

Short Text field with a maximum length of 30. 

301


MKS Source/MKS Integrity 

Integration Properties 

Troubleshooting 

302 

MKS Source/MKS Integrity Integration Properties 

Description 

DefaultIMEnvironment Default Implementer *TST environment on the iSeries to check out to in the 

Export to Implementer function. This is an optional property. 

DefaultProject Default Implementer project to use in the Export to Implementer function. 

DefaultStagingLocation Default IFS location on the iSeries where to pull objects from. 

For each slash in the actual name, define the property with two slashes (//). 

For example, if the default IFS location is /home/mydirectory, specify 

//home//mydirectory. This is an optional property. 

The following information can help you resolve common problems with Implementer Server. 

Symptom Possible Cause Resolution 

Using ICTLSVR 

*START, F7=Test in 

MKS Integrity Setup 

panel, or F7=Test in 

MKS Source Setup 

panel results in error 

VIM8598 “Unable 

to communicate 

with the MKS 

Integrity 

Server”. 

#1: IP address for system running Implementer 

Server is not in MKS Integrity config file 

IntegrityClientSite.rc. 

Also see MKS Integrity weblogic.log for error 

message with missing IP, for example: 

Thu Feb 9 14:32:25 CDT 2006: 

 

* * * * ERROR * * * * (0): 

ICAllowSpecificConnectionPolicy failed 

the connection. Connection: 10.17.4.6: 

is not on the list of acceptable 

machines. 

#2: Network may not be configured to communicate 

between the system running Implementer server 

and system running MKS Integrity. 

From system running Implementer Server, ping 

system where MKS Integrity Server is located (see 

MKS Integrity Setup panel, Server port field). 

Implementer Server running on iSeries, from 

command line issue 

ping 

(IP address must be in single quotes . 

Implementer server running on a PC, from 

command prompt run ping . 

In the IntegrityClientSite.rc 

file, specify the IP addresses for the 

system running Implementer Server 

and the localhost (127.0.0.1) in 

daemon.validConnectionList= 

For details, see “Modifying the 

MKS Integrity Server Configuration 

File” on page 206. 

Verify and correct network 

configuration. 

Specify correct system running 

MKS Integrity Server in Server port 

field on Implementer’s MKS Integrity 

Setup panel and/or MKS Source 

Setup panel. For details, see 

“Defining MKS Integrity Values in 

Implementer” on page 226, and 

“Defining MKS Source Values in 

Implementer” on page 275.

C HAPTER SIX 

Third Party Integrations 

Configuring Implementer for Integrated Development Environments 

6 

MKS is committed to the continuous development and growth of Implementer’s integrations with 

third party software tools and applications. 


“ABSTRACT Integration” on page 304 

“AllFusion 2E Change Management Integration” on page 304 

“American Software Integration” on page 313 

“AOS Message Manager Integration” on page 315 

“AS/SET Integration” on page 316 

“BPCS Integration” on page 320 

“BRMS/400 Integration” on page 322 

“Code/400 Integration” on page 323 

“Help Desk Integration” on page 324 

“LANSA Integration” on page 328 

“Lawson Software Integration” on page 333 

“Lotus Domino Integration” on page 336 

“PathFinder Integration” on page 354 

“PeopleSoft World Integration” on page 355 

“Powerhouse (Cognos) Integration” on page 362 

“ROBOT Integration” on page 364 

“WebSphere Development Studio Client for iSeries Integration” on page 365 

303

Chapter 6: Third Party Integrations 

ABSTRACT Integration 

304 

Implementer’s integration with ABSTRACT does not require additional setup. For 

information on using the integration, see the MKS Implementer 2006 User Guide. 

AllFusion 2E Change Management Integration 

The Implementer Adapter for AllFusion 2E Change Management (CM) is a separately 

licensed product that provides change control for AllFusion 2E developed applications and 

traditionally developed (3GL) applications. Implementer is compatible with AllFusion 2E 

release 8.1 and earlier. The integration requires a specific license key to activate. 

The procedures required for setting up the integration, including: 

considerations for libraries and commands 

understanding basic concepts 

considerations for EXCUSRPGM and EXCUSRSRC 

support for SQL 

Considerations for Libraries and Commands 

Basic Concepts 

While following the setup steps described in this chapter, keep in mind the following product 

and library considerations. If you received the Implementer product from Computer 

Associates and it is enabled for AllFusion 2E change management: 

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

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

Use the STRCM command in place of the Start Implementer (STRIM) command. 

Use the STRCR command in place of the Start Implementer Receiver (STRIR) command. 

You must know a few basic concepts to understand how change management occurs for 

AllFusion 2E developed applications. These concepts are described briefly next and 

expanded upon later.

Change Controlled Models 


The process for enabling a model for change control differs 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 (MKSIM or Y2SYCM) in the change control parameter 

(CHGCTL). For established AllFusion 2E models, you have to initialize the version type of all 

of the 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. You must also define the model to Implementer as an AllFusion 2E environment. 

Type a model library name on the AllFusion 2E options panel, accessible using option 10 

from the Work with Environments panel. 

The following examples help to clarify these concepts. 

Example 1 

You have 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 possible 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/Copy name in the development (source) model with the 

Owner name/Object type/Object name in the target model. If a match is found, the 

object in the development model is set as a production version. 

The production model provided to the YASCPRDMDL command should ideally be the 

related production environment you define in the CM 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 the functions, a more arbitrary pairing method could cause 

some unexpected results. The program reads the development model objects in Owner/ 

305


306 

Type/Name order. If a match is found in the target model, the program tries to make the 

object PRD (if it is not already). If any other version in the group is PRD, the attempt 

fails, the information is written to a report, and processing continues. The result is the 

first version in a group, alphabetically, set to PRD. 

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 to correct. 

For each object, change the version that was set by the YASCPRDMDL command to 

DEV, and set the version to production. The Work with Versions (YWRKVSN) and 

Change Model Object (YCHGMDLOBJ) commands can be useful for this. 

Example 2 

You have 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 works, but the first 

solution has overhead of both extra promotion steps and extra disk space requirements. 

2 For either situation, you must 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 are already 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). 

Alternately, follow these steps if the production flags have not been established: 

Issue the YBLDMDLLST command to create a model list of all the non 

versionable objects in the model, in other words, exclude functions and 

messages. Do not include Implementer-supplied objects. 

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). 

Create a model list of all functions and messages, excluding those supplied by 

AllFusion 2E (versionable objects). For each object, include only the version in 

production. Do not include more than one version for a group, as it causes an 

error in the next step. 

Generate the YEXCMDLLST command as before for the non versionable 

objects. An error occurs if you attempt to set more than one version in a group 

to production.


3 Establish that all 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 have 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: 

YEXCMDLLST MDLLST(PRDLST) 

RQSDTA('YRDRMDLOBJ 

FRMOBJNAM(*CURRENT) 

TOOBJSGT(&Y@) 

TOOBJSGT(&Y@) 

TFRNAM(*NO)') 

FLAGVAL(*SELECTED) 

4 With the production objects in your development model correctly established, you are 

ready for the final step⎯creation of the production model objects. 

a) 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. 

b) 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. 

c) Re-establish Implementer by setting the YCHGCTL model value to the name of 

your Implementer product library specified in the development and production 

models. 

Versioning 2E Messages 

AllFusion 2E message versions are typically always recreated except when translating 

terminology to another language. However, Implementer allows you to control whether to 

create a new message version when checking out 2E messages. In Work with Environments, 

select the 2E environment with option 10=AllFusion 2E. On the Change Environment panel, 

in the Crt new version of MSG objects field, the default value Y automatically creates a new 

message version. Change the value to N to retain the original version of 2E messages. 

307


Support for EXCUSRSRC and EXCUSRPGM 

308 

By default, Implementer allows you to promote the AllFusion 2E EXCUSRSRC and 

EXCUSRPGM functions separately from their associated implementation 3GL source and 

objects. This is called “Independent EXCUSRSRC and EXCUSRPGM”. 

You can also 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 

“Dependant EXCUSRSRC and EXCUSRPGM”. 

This feature is controlled by the User source and user program promotion method field in 

Work with Environments. When upgrading AllFusion 2E CM, the existing default method of 

independent EXCUSRSRC and EXCUSRPGM is retained. Enabling this feature provides 

capabilities that were available prior to AllFusion 2E CM release 6.0. 

Considerations for EXCUSRSRC and EXCUSRPGM 

When promoting EXCUSRSRC and EXCUSRPGM, even though the Remove source field is 

set to Y, the source for the user programs is not removed. 

Storing Source and Object Outside the Generation Library 

There are three common ways to store EXCUSRPGM source and objects outside the test 

model generation library. The following paragraphs briefly describe the scenarios and 

implementation steps. Each scenario uses the XCB target HLL object attribute in AllFusion 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, and change its source file value to YXCBLSRC. 

1 Source in an alternate source file in the generation library with object in the generation 

library. 

Create an XCB object code. 

2 Source in an alternate source file in the generation library with objects in a library other 

than the generation library. 


On the Environment Object Code Override panel, change the object library to the 

library you want to store the EXCUSRPGM object in.

Support for SQL 


3 Source in an alternate source file in a library other than the generation library. 


On the Environment Object Code Override panel, change the object library value to 

the library you want to store the EXCUSRPGM object in. (Use the F8=Object code 

override on the Change Environment panel.) 

Change the Environment Object Code Override source location library to the library 

to store the EXCUSRPGM source in. 

Regardless of the scenario, perform the following steps in AllFusion 2E for each 

EXCUSRPGM or EXCUSRSRC. 

4 When editing the function in AllFusion 2E, change the language from CLP, RPG, or CBL 

to XCB. 

5 Display the AllFusion 2E Edit Generation Types panel, and change the name of the SCB 

source types source file to the source file name used on the XCB object code definition in 


To define an environment for 3GL source and object processing associated with 

EXCUSRSRC and EXCUSRPGM functions 

1 From the Implementer Menu, type option 42, Environments, to display the Work with 

Environments panel. 

2 Select the AllFusion 2E environment with option 10=AllFusion 2E and press ENTER. 

3 In the User source and user program promotion method field, specify one of the 

following values: 

1=Dependent Automatically adds associated implementation source and 

objects to the promotion request. 

2=Independent Does not add the associated implementation source and 

objects. This is the default value. 

IMPORTANT If you change the environment to add dependent objects, do not have 

any 3GL source and objects checked out that are associated with a model object. 

Implementer supports the SQL-related generation options available in earlier releases of 

AllFusion 2E. This includes the creation of SQL tables, indices, and views, and the 

corresponding functions that create RPG SQL and COBOL programs. 

309


310 

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 the SQL-specific object codes delivered with Implementer. Verify 

your setup with the YSQLPF (tables), YSQLLF (indices and views), and SQL program types 

(RPGSQL and CBLSQL) as described in the following sections. 

Managing SQL Files, Indices, and Views 

Implementer provides the YSQLPF and YSQLLF objects codes to manage AllFusion 2E SQL 

files, indices, and views. In an AllFusion 2E model, these items have different model object 

attributes, but share the same: 

source member type (YSQL) 

source file (QSQLSRC) 

creation command (YEXCSQL) 

When generating YFIL model objects as SQL, Implementer uses the object code YSQLPF for 

the associated implementation object. When generating YACP model objects as SQL, 

Implementer uses the object code YSQLLF for the associated implementation object. Thus, 

verify the YSQLPF and YSQLLF object codes are defined as follows, and that they are active 

to each applicable AllFusion 2E environment. 

NOTE You must define the parameter sequences of the creation commands as 

shown to avoid extraneous messages in your job log. 

Field Required Value 

Object code/Description YSQLPF (AllFusion 2E SQL physical file) 

Activity flag 1 

Object type *FILE 

Object attribute PF 

Source member type YSQL 

Default source file QSQLSRC 

Object authority *KEEP 

Creation process C 

Creation command YEXCSQL MBR(#SRCMBR) 

OBJLIB(#FILLIB) 

SRCFILE(#SRCLIB/#SRCFIL)


Managing SQL Functions 


Object code/Description YSQLLF (AllFusion 2E SQL indices/views) 


Object type *FILE 

Object attribute LF 

Source member type YSQL 




Creation command YEXCSQL MBR(#SRCMBR) 

OBJLIB(#FILLIB) 

SRCFILE(#SRCLIB/#SRCFIL) 

In an AllFusion 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 also has: 

source member type of SQLRPG or SQLCBL 

source file of QRPGSRC or QCBLSRC 

creation command of CRTSQLRPG or CRTSQLCBL 

For managing AllFusion 2E SQL functions, Implementer provides the RPGSQL and RPGCBL 

object codes. By using these SQL-specific object codes to check out SQL functions, 

Implementer assigns the appropriate program type object code to the lock. 

When you create a promotion request, Implementer adds the model objects to the 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. 

Verify the RPGSQL and CBLSQL object codes are defined as follows, and that they are active 

to each applicable AllFusion 2E environment. 


Object code/Description RPGSQL (AllFusion 2E RPG SQL function) 


Object type *PGM 

Object attribute RPG 

Source member type SQLRPG 

Default source file QRPGSRC 

311


Object Code Setup for Parallel Installation 

312 




Creation command CRTSQLRPG PGM(#PGMLIB/#OBJECT) 


COMMIT(*NONE) 

SRCMBR(#SRCMBR) 


Object code/Description CBLSQL (AllFusion 2E CBL SQL function) 


Object type *PGM 

Object attribute CBL 

Source member type SQLCBL 




Creation command CRTSQLCBL PGM(#PGMLIB/#OBJECT) 


COMMIT(*NONE) 

SRCMBR(#SRCMBR) 

If you have upgraded from an Implementer release prior to release 5.0 and you performed a 

parallel installation as explained in the MKS Implementer 2006 Installation Guide, before using 

the software you must add certain AllFusion 2E-specific object codes to Implementer. 

The following table defines the object codes to add. 

Object Code Description 

Creation 

Sequence 

YACP AllFusion 2E access path 9120 YACP 

YAPP AllFusion 2E application 9120 YAPP 

YARR AllFusion 2E array 9120 YARR 

YCND AllFusion 2E condition 9120 YCND 

YFIL AllFusion 2E file 9120 YFIL 

Special 

Characteristics


NOTE 

The creation sequences are suggested values you may change. 

Set the Object authority field to *KEEP, and the Creation process field to C. 

For details on adding or changing objects codes, see page 127. 

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 following 

information explains how to use Implementer with the (ASI) application software. 

Object Code Requirements 

American Software uses a special command for compiling, which, among other things, 

merges both a base version of a source member, ASI PTFs, and customer changes into a 

temporary source member and then compiles the source member. The ASI change 

management process is automated using ASI-specific objects. 

To perform ASI compiles within Implementer, you need to create new object codes similar to 

the following standard object codes. 

CBL (Cobol Programs) 

CLP (Control Language Programs) 

DSPF (Display Files) 

PRTF (External Printer Files) 

LF (Logical Files) 

PF (Physical Files) 

Creation 

Sequence 

YFLD AllFusion 2E field 9120 YFLD 

YFUN AllFusion 2E function 9120 YFUN 

YMSG AllFusion 2E message 9120 YMSG 

Special 

Characteristics 

Object codes are maintained using Implementer Menu option 44, Object Codes. For details, 

see “Object Codes” on page 127. 

313


314 

To perform an ASI Cobol compile with Implementer, create a new object code as shown next 

(illustrates an object code named CBLASI, but any naming convention can be used). 

Field Value 

Object Code/Description CBLASI (ASI COBOL Program) 

Object type PGM 

Object attribute CBL 

Source member type TXT 

Default source file UCBLSRC 

Special characteristics ASICBL 



Creation command ASIUTILIB/PUTCRTOBJ OBJ(#PGMLIB/#OBJECT) 

SRCMBR(#OBJECT) 

SRCFL(#SRCLIB/QCBLSRC) 

OBJTYPE(CBL) 

PRMSRCFL(QCBLSRC) 

Change the other object codes in the same way. The object code controls, among other things, 

how objects are compiled. Instead of calling the standard IBM Create Cobol Program 

(CRTCBLPGM) command, the CBLASI object code calls the ASI command that merges and 

compiles Cobol source code. You can deactivate the standard object codes (such as CBL and 

RPG) in each environment. 

You must make the following two changes prior to running the Implementer Build List. For 

details, see “Environment Repository Build” on page 117. 

1 In the environment’s object code overrides, change the source file to the actual “Q” 

libraries (QCBLSRC). 

2 Change the object codes to a source member type of the actual source file (CBL) instead 

of TXT. 

After the build completes, you can change the source file back to the “U” libraries 

(UCBLSRC), and change the object codes back to TXT. 

Library and Library List Requirements 

The PUTCRTOBJ command requires the three source files located within the same library. In 

other words, the library you are making changes in (in source file UCBLSRC members) must 

have a copy of the TCBLSRC source file and QCBLSRC source file in the same library as 

UCBLSRC.

Typically, these source files are: 

QCBLSRC (unmodified current release) 

TCBLSRC (PTFs to current release) 

UCBLSRC (customer changes to current release) 

AOS Message Manager Integration 

In addition, the environment library list must match the library list of the ASICOMPILE job 

description, with the libraries listed in the same order. 

Troubleshooting Problems 

The following information may be helpful with resolving typical problems related to 

message files. 

Problem Resolution 

Source mismatch Change the Source member type to TXT. 

Checked out QSRC instead of USRC The default source file must be USRCxxx. 

TSRC and USRC not copied Special characteristics not entered for object type. 

AOS Message Manager Integration 

AOS Message Manager interfaces with Implementer to allow you to monitor the status of 

promotion requests. The messages can be set up to automatically create an OS/400 message 

to one or more user profiles. In addition, you can send Implementer messages directly to a 

pager to notify someone not signed on to the iSeries that a situation requires attention. 

To set up the AOS Message Manager integration 

1 From the Implementer Menu, select option 45, System Control Maintenance. The System 

Control Maintenance panel displays. 

2 Press PAGE UP to display the second panel. 

3 In the Secondary message queue field, type the name of the AOS Message Manager 

message queue. This points AOS Message Manager to the message queue where all 

messages in Implementer are sent, and to the appropriate Implementer users. 

You can also page a user when specific messages are received. For more information, see 

the AOS Pager Manager Users Guide. 

315



316 

The Implementer Adapter for AS/SET is a separately licensed product that manages AS/SET 

definitions and generated traditional objects independently. 

You can check out AS/SET definitions, make modifications, and promote to QA and 

production to complete the cycle. Implementer automatically handles locking the definitions 

and ensures proper check in by promoting in a controlled fashion. An audit trail is 

maintained of all activities to the definitions. Implementer’s inquiries and reports include the 

AS/SET definitions and generated objects you manage. 

There are specific commands to copy, delete, and verify existence of AS/SET definitions from 

within Implementer. These functions are used to manage definitions and as standalone 

commands. 

Setting Up the Integration 

The setup activities necessary to handle AS/SET applications are as follows: 

Install AS/SET on the system. 

Change the library list in the job description (MWIJOBD) to include the AS/SET product 

libraries. 

IMPORTANT You must include the AS/SET libraries in the job description to ensure 

the promotion of AS/SET definitions does not abnormally end. 

Include the AS/SET product libraries ASSETO, ASSETF, and ASSETGPL on your 

interactive library list to manage an AS/SET definition. 

In System Control Maintenance, set the AS/SET installed field to Y. 

Set up standard environments to manage AS/SET applications. 

Set the Compile required field to N if you use this environment only for AS/SET 

definitions. 

Enable the “Remove member in from library/environment” feature in Work with 

Environments for AS/SET definitions. 

Associate the standard environment with an application set where the definitions for the 

environment reside. Once the existing environment is associated with an application set, 

it becomes a special AS/SET environment. The indication of this special environment 

displays on the second detailed Change Environments panel. The application set name 

you specify must exist (Implementer does not create application sets). If the application 

set name is blank, the environment type reverts to Standard on the Change 

Environment panel.


Use object codes with the following special characteristics for AS/SET definitions. 


If you need different object codes, they must have special characteristics beginning with 

ADK. Create the object codes as non source and non object based. 

NOTE 

Setting Up for Archiving 

ADKDSP AS/SET display program definition. 

ADKBAT AS/SET batch program definition. 

ADKRPT AS/SET report program definition. 

ADKMDL AS/SET data model. 

ADKLLD AS/SET field definition. 

ADKFIL AS/SET file definition. 

ADKAUD AS/SET audit trail definition. 

ADKSUB AS/SET action subroutine definition. 

You can promote AS/SET definitions to an environment group. You must define 

the primary environment as an AS/SET environment. If non AS/SET 

environments exist in the group, the AS/SET definitions are not promoted to 

these environments, although the promotion of both AS/SET definitions and the 

generated objects occurs to the AS/SET environments in the group. 

When you run the Build List for AS/SET environments, the member/object list 

includes both traditional objects and AS/SET definitions that exist in the 

application set specified for the environment. 

After defining an AS/SET environment (a standard environment associated with an AS/SET 

application set) perform the following task to enable archiving for AS/SET definitions. 

To set up for AS/SET archiving 

1 In the Archive version fields on the Change Environment panel, specify the number of 

levels (versions) to retain for archiving. You must also specify the archive library name 

and number of versions for traditional objects. 

2 In the Work with Environments panel, type 11=AS/SET, and press ENTER. The Create 


3 In the Archive application set field, type the name of the archive application set, and 

press ENTER. 

317


Setting Capabilities for Checked Out Generated Objects 

318 

You can configure Implementer to automatically allow modifying either all AS/SETgenerated 

objects or CL programs only. 

To enable modifying AS/SET-generated objects or CL programs 

1 From the Implementer Menu, select option 42, Environments, and press ENTER. The 


2 Type 11=AS/SET to select the AS/SET environment and press ENTER. The Create 


3 In the Allow C/O of generated objects field and the Allow C/O of generated CL field, type 

Y or N to indicate whether the specified AS/SET-generated items allow modification. 

These objects are identified with an associated object code, for example, CLPOBJ, 

RPGOBJ, and PFOBJ. You can enter any of the following combinations in these fields. 

Field Entry Combinations 

Allow C/O of generated objects (Y/N) N N Y 

Allow C/O of generated CL (Y/N) Y N Y

Setting Up for Generated Object Promotions 


You can configure Implementer to automatically promote all AS/SET-generated objects with 

other promotion items. 

NOTE When creating a promotion request, AS/SET is required in your library list. 

However, to avoid generated object not being added to the request when promoting 

from an application set other than the one you are currently in, you should not be 

within the AS/SET product. 

To enable the automatic promotion of AS/SET generated objects 

1 From the Implementer Menu, select option 42, Environments, and press ENTER. The 


2 Type 11=AS/SET to select the AS/SET environment and press ENTER. The Create 

Environment panel displays the AS/SET details as illustrated on page 318. 

3 In the Promote generated objects field, specify one of the following values. 

0: Does not add generated objects to the promotion request. 

1: Adds only generated objects to the promotion request. 

2: Adds generated source and objects to the promotion request. 


You have the option to override these default settings at promotion time as explained next. 

AS/SET Dependency Check 

The Check ADK Dependencies (ICHKADKDEP) command checks for AS/SET object 

dependencies of any ADK items during check out. 

This feature requires setting up the Implementer Job Description (MWIJOBD) library list and 

a special command at the environment level. There are no special setup requirements within 

AS/SET. 

To change the job description 

1 On the OS/400 command line, type the following command and press F4=Prompt. 

CHGJOBD JOBD(MWIJOBD) 

2 Define the Library parameter (this is the library where the job description exists; MKSIM 

is the default). 

319


320 

3 Define the Initial Library List parameter as follows, and press ENTER. 

Add the AS/SET object library (ASSETO is the default) before the AS/SET file 

library (ASETF is the default). 

Add the AS/SET object library and AS/SET file library before the Implementer 

library. 

Add the QTEMP library in any position on the library list. 

Special Command Setup 

You must define the AS/SET Dependency Check as a special command attached to the *TST 

environment to run automatically after check out. 

To define the special command 

1 From Work with Environments, select the *TST environment with option 19=Special 

commands. The Work with Environment Special Commands panel displays (the panel 

may display existing commands). 

2 Press F6=Add. The Expanded Command Display panel displays. 

3 Define the special command as follows: 

In the For Action field, type 6 (Checkout). 

In the When to do field, type 2 (After-OK). 

In the Command field, type: 

ICHKADKDEP MBROBJ(#OBJECT) 

OBJCODE(#OBJCOD) 

FRMENV(#FRMENV) 

TOENV(#TRGENV) 


BPCS Integration 

To use Implementer with SSA/BPCS software, you must make special compile changes. 

These changes involve setting up required object codes within Implementer, and possibly 

making changes to your environment setup. These setup tasks are explained next. 

Compile Considerations 

The first consideration for performing BPCS compiles within Implementer is to determine 

whether all compiles are BPCS compiles, or whether some compiles are BPCS compiles and 

others are not performed through BPCS commands or programs (for example, DSPF).

BPCS Integration 

If all compiles use BPCS commands or programs, you must change the standard object 

codes delivered with Implementer. 

If some compiles do not use BPCS commands or programs, you must create new object 

codes for the BPCS compiles and retain the standard object codes for the non BPCS 

compiles. 

For information on making these changes, see “Setting Up Object Codes” on page 321. 

BPCS provides programs for compiling, rather than using the standard IBM creation 

commands like CRTCLPGM. The BPCS compilation commands, such as CLCRTCLP, cannot 

be called directly because these commands submit the compile. The Implementer compile 

step requires the program or command used for compilation running within the 

Implementer submitted compile job (the command cannot submit a different job). For this 

reason, BPCS compiles within Implementer are performed using the BPCS programs 

submitted by the BPCS compile commands, not by the command itself. 

BPCS supports compiling the following source types. 

Source Type BPCS Programs Existing New 

CLP CLCRTCLP CLP CLPB 

DSPF CRTDSPLY2 DSPF DSPFB 

LF CLCRTLFILE LF LFB 

PF CLCRTPFILE PF PFB 

PRTF CLCRTPRTF PRTF PRTFB 

RPG CLRPG RPG RPGB 

The BPCS programs have the same first four parameters as follows: 

object-name (#OBJECT) 

to-library (#PGMLIB or #FILLIB) 

source-file-name (#SRCFIL) 

source-library (#SRCLIB) 

Setting Up Object Codes 

Change the object codes as follows. For details, see “Object Codes” on page 127. 

321


Setting Up Environments 

322 

Existing 

Object Code 

New Object 

Code 

If you create new object codes to support BPCS compiles, any environments you define 

automatically allow the BPCS object codes that call the BPCS compiler and the standard 

object codes that call the OS/400 compiler. Thus, you may want to deactivate the standard 

object codes for BPCS environments. 

To deactivate standard object codes for BPCS environments 

1 From the Implementer Menu, type option 42, Environments and press ENTER. 

2 Type 2=Change to select a BPCS environment. The Change Environment panel displays. 

3 Press F8=Object Codes. The Change Environment Object Code Overrides panel displays. 

4 In the Allow field, type N next to the object code to deactivate it. 

5 Press ENTER to save the change. 

BRMS/400 Integration 

Command or String to Use 

CLP CLPB CALL PGM(CLCRTCLP) PARM(#OBJECT #PGMLIB #SRCFIL 

#SRCLIB '*YES') 

DSP DSPFB CALL PGM(CRTDSPLY2) PARM(#OBJECT #PGMLIB #SRCFIL 

#SRCLIB '*YES' 'BPCS' '*YES') 

LF LFB CALL PGM(CLCRTLFILE) PARM(#OBJECT #FILLIB #SRCFIL 

#SRCLIB '*YES' '*YES') 

PF PFB CALL PGM(CLCRTPFILE) PARM(#OBJECT #FILLIB 

#SRCFIL#SRCLIB '*YES' *NO' '*YES' '*YES' 'BPCS' 

'PGMMSGQ') 

PRTF PRTFB CALL PGM(CLCRTPRTF) PARM(#OBJECT #PGMLIB #SRCFIL 


RPG RPGB CALL PGM(CLRPG) PARM(#OBJECT #PGMLIB #SRCFIL 


Implementer supports using a third party save/restore utility for saving archives to tape. For 

example, you can use IBM’s Backup Restore Management System (BRMS/400), or an 

internally developed program. In this scenario, all Archive to Tape menu options are 

available except for menu option 2, Restore Archives from Tape. When you need to restore a 

tape archive created by a third party utility, you must restore the tape using that utility.

Code/400 Integration 

Using a third party utility requires you activate the Implementer data area IMSVPGM, as 

well as activate a skeleton CL program provided in the Implementer source file QSAMPLE. 

Once set up, you can use the Save Archives to Tape option on the Archive to Tape Menu to 

call your internally defined command (rather than the standard IBM Save Library (SAVLIB) 

command). 

NOTE QSAMPLE is a source file delivered in the Implementer product library 

(MKSIM is the default product library). QSAMPLE provides technical information 

and programs that help you to customize certain features of Implementer. 

To set up archiving to tape for a third party save/restore utility 

1 Perform the environment archive setup as described in “Environments” on page 81. 

2 In the Implementer source file QSAMPLE, modify the CL program IMSVLB2 to call your 

third party save command. 

For details on using QSAMPLE, refer to the source contained within the file. 

3 Activate the IMSVPGM data area by issuing the Change Data Area (CHGDTAARA) 

command as follows: 

CHGDTAARA DTAARA(IMSVPGM (1 10)) VALUE(LIBRARY) 

CHGDTAARA DTAARA(IMSVPGM (11 10)) VALUE(PROGRAM) 

Where the value in positions 1 through 10 is the library name associated with your 

internal program, and the value in positions 11 through 20 is the name of the internal 

program defined in program IMSVLB2 in QSAMPLE. For details on the IMSVPGM data 

area, see “Save Program Name (IMSVPGM)” on page 411. 

Code/400 Integration 

CODE/400 (CoOperative Development Environment/400) is a workstation-based, client/ 

server development environment that is available with IBM’s WebSphere Development 

Tools for the iSeries. With CODE/400, you can edit, compile, and debug client/server 

applications, as well as applications written in many other OS/400 languages. For details on 

using Code/400, see the MKS Implementer 2006 User Guide. 

Requirements and Setting Up 

This guide assumes CODE/400 and Implementer are set up and running successfully within 

your organization. 

323


324 

To create the user-defined options 

Access PDM to create the user-defined options that access CODE/400 from the Implementer 

Workbench. 

For example, to invoke CODE/400 to edit a source member, create an option defined with the 

following command syntax: 

where: 

Call qcode/evfcfdbk parm('37' 'Y' 'OS400' ' CODEEDIT 

"&L/&F (&N)"') 

Value Description 

37 Coded character set identifier (CCSID) used to send information to the 

desktop. 

Y Specify Y to display a message, or N to bypass messages. 

OS400 Specify the type of server to log messages in the command shell. If the OS/400 

server is not defined, you may get an error in the command shell. 

Specify the CODE/400 server location, or (empty brackets) to use the first 

active CODE/400 server. 

CODEEDIT Specify the command to run on the desktop (indicated by ). You must 

enclose the command 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. 

Must have a blank space between &F and (&N) to correctly substitute the 

source file. 

Help Desk Integration 

Implementer integrates with open help desk and Customer Relationship Management 

(CRM) applications, providing the ability to associate calls that are logged in a help desk 

software package with DesignTracker design requests (DR) and service requests (SR). 

You can use MKS SupportCenter or any other help desk software that has an ODBC (Open 

Database Connectivity) or JDBC (Java Database Connectivity) accessible database.

Requirements 

This help desk integration requires the following: 

DTBridge is installed and configured. DTBridge is delivered with Implementer 


DesignTracker is installed and configured as your issue management application (you 

must not be using MKS Integrity for issue tracking). DesignTracker is delivered with 


SupportCenter 3.2 is installed; however this requirement does not force you to use 

SupportCenter as your help desk application. SupportCenter is required for the use of 

the call header file, which is populated with the data extracted from your help desk 

database when the update runs. SupportCenter is delivered with Implementer. If 

SupportCenter is your help desk application, this guide assumes it is configured. If 

SupportCenter is not your help desk solution, this guide assumes that a different help 

desk product is configured. 

Setting Up the Help Desk Integration 

These instructions assume that Implementer, DesignTracker, DTBridge, and SupportCenter 

are installed and configured. In addition, you must perform the following setup in the 

DTBridge properties file prior to running the Associate Calls Update program. 

DTBridge Properties Setup 

The DTBridge properties file (DTBridge.properties) contains the application control 

properties for the Associate Calls functionality and a few other integrations. The DT Call 

Association properties relate to the Associate Calls Update program. For details on 

DTBridge, see “Installing DTBridge” on page 135. 

To start DTBridge Console and configure the DTBridge properties file 

1 Click Start > Programs > MKS Implementer > DTBridge Console. The DTBridge Console 

window displays. Notice the Status bar indicates DTBridge is not active. 

2 Click File > Setup from the menu. The Edit DTBridge Setup properties file displays. 

The properties file is organized by functional area. The help desk integration requires 

input in the DT Call Association Properties only. 

At the beginning of each section the properties are listed with a brief description and 

example. At the end of each section, the property displays again as property name=x. 

Instructions and examples are also included within the DTBridge properties file. 

3 Configure the properties as described in the following table. Define OS/400 values using 

upper case syntax. When defining the property value, type the value as follows: 

property name=property value 

325


DT Call Association 

Properties 

326 

4 When you are finished, click File > Save Setup. 

Description 

DT Call Association Properties 

SCLibrary Name of your SupportCenter library or the library that contains the HDPHDRP file. 

SCUser User profile that has authority to the library defined for SCLibrary. 

SCPassword Password associated with the SCUser property. 

HDDSN Name of the ODBC data source that points to the help desk database to extract call 

information from. 

HDUser User ID to access the help desk database defined for the HDDSN property. 

HDPassword Password associated with the HDUser property. 

HDDRSelectSQL SQL statement that retrieves call information to generate SupportCenter call header 

records associated with DesignTracker DRs. The SQL select statement must include 

the following fields in the order listed. 

Call ID, 10a 

Customer Number, 10a 

Customer Name, 30a 

Product Name, 10a 

Allocated to, 10a 

Waiting on, 10a 

Call Status, 1a 

Design Request #, 5,0 

HDSRSelectSQL SQL statement that retrieves call information to generate SupportCenter call header 

records associated with DesignTracker SRs. The SQL select statement must include 

the following fields in the order listed. 

Call ID, 10a 

Customer Number, 10a 

Customer Name, 30a 

Product Name, 10a 

Allocated to, 10a 

Waiting on, 10a 

Call Status, 1a 

Service Request #, 5,0 

NOTE For details on SQL statements, see “Defining the Structured Query Language 

Statements” in the next section.

Updating Calls 

Defining the Structured Query Language Statements 


When defining the Structured Query Language (SQL) statements for the HDDRSelectSQL 

and HDSRSelectSQL properties, specify the selected fields in the following order: 

Call ID (10a) 

Customer Number (10a) 

Customer Name (30a) 

Product (10a) 

Allocated to (10a) 

Waiting on (10a) 

Call Status (1a) 

DR or SR number (5,0) 

The size of the original field in your help desk software is not important because the field 

truncates to the size indicated when updating the SupportCenter call header file. 

The following is an example SQL statement: 

SELECT SUBSTR(S_SRV_REQ.SR_NUM,1,10), 

SUBSTR(S_SRV_REQ.CST_OU_ID,1,10), SUBSTR(S_ORG_EXT.NAME,1,30), 

SUBSTR(S_PROD_INT.NAME,1,10), SUBSTR(S_EMPLOYEE.LOGIN,1,10), 

SUBSTR(S_SRV_REQ.SR_SUB_STAT_ID,1,10), 

SUBSTR(S_SRV_REQ.SR_STAT_ID,1,1), SUBSTR(S_SRV_REQ.SR_CST_NUM,3,5) 

FROM SIEBEL.S_EMPLOYEE S_EMPLOYEE, SIEBEL.S_ORG_EXT S_ORG_EXT, 

SIEBEL.S_PROD_INT S_PROD_INT, SIEBEL.S_PROD_LN S_PROD_LN, 

SIEBEL.S_SRV_REQ S_SRV_REQ WHERE S_SRV_REQ.CST_OU_ID = 

S_ORG_EXT.ROW_ID AND S_SRV_REQ.PRDINT_ID = S_PROD_INT.ROW_ID AND 

S_PROD_INT.PR_PROD_LN_ID = S_PROD_LN.ROW_ID AND 

S_SRV_REQ.OWNER_EMP_ID = S_EMPLOYEE.ROW_ID AND ((S_SRV_REQ.SR_CST_NUM 

Like 'DR%') AND (S_PROD_LN.NAME Like '%MKS%')) 

You run the Associate Calls Update program from the DTBridge Console. A Java class 

executes your defined SQL statements, which associates calls with the appropriate DR or SR 

and generates a history log of the associated calls. For example, any records containing data 

that maps incorrectly (such as alpha data in the numeric DR/SR number field) causes a 

warning message in the history log. The invalid records are skipped, and the process 

continues with the next record. A total count of all warnings posted (resulting in records not 

updated) prints at the end of the log. To view the latest history log, from the DTBridge 

Console, click File > View History. 

327


328 

You can view prior history logs through Windows Explorer. The default location is C:/ 

Program Files/MKS/Implementer/DTBridge. History log names consist of the date and 

time created, and the file extension .log, for example, DTHD20060115134216.log. 

Once the update successfully completes, access DesignTracker and view the updated DRs 

and SRs with option 17=Display calls. 

DTBridge Silent Update 

Updating calls using the silent method allows you to quickly process the updates without 

interactively viewing the updates or subsequent messages that occur. The updates and 

corresponding status are recorded to a log file in the same directory. 

To update calls using DTBridge silent method 

From your Windows desktop, click Start > Programs > MKS Implementer > Associate Help 

Desk Calls. 

The update processes during a brief pause. When it completes, you can review the history log 

file for detailed job information. 

DTBridge Console Update 

Updating calls using the DTBridge console provides a GUI interface that allows you to 

interactively view the updates and subsequent messages as they occur. 

To update calls using DTBridge Console 

1 From your Windows desktop, click Start > Programs > MKS Implementer > DTBridge 

Console. The DTBridge window displays. 

2 Click Tools > Associate Calls. Status messages display to indicate each process that 

occurs and the subsequent results. 


The Implementer Adapter for LANSA is a separately licensed product that provides 

integration with the following LANSA products: 

LANSA for iSeries 

LANSA for the Web 

Visual LANSA 

The integration provides for the controlled check out and promotion of LANSA objects, 

allowing you to manage the development of LANSA files, fields, processes, and functions, as 

well as Web and Extensible Markup Language (XML) components and system variables.


You manage LANSA objects with LANSA environments. A LANSA environment type is 

established by associating an Implementer environment with a valid LANSA partition. This 

ensures any changes to objects in a partition are managed using the associated environment. 

Specific object codes accomplish the check out and promotion of LANSA objects to and from 

the LANSA environments. The Check Out function locks the name of the LANSA object 

and—depending on the environment definition—copies (export and import) the LANSA 

objects to the development environment. 

Promotion prepares the LANSA objects for export and moves (imports) the objects into the 

target environment. Distribution of LANSA objects to remote locations is supported. 

LANSA objects are archived in the archive library specified for the target environment. 

Implementer supports using LANSA task tracking to manage the development of LANSA 

objects and related issues. 

All reports and inquiries track the LANSA objects managed by Implementer. 

Setting Up the Interface 

The following information applies to setting up the integration. For more information, see 

“LANSA Prerequisites” on page 107. 

In System Control Maintenance, verify the LANSA installed field is set to Y. 

Change the Implementer job description (MWIJOBD) to include the LANSA product 

libraries in the library list. 

IMPORTANT The job description must include the LANSA libraries to avoid the 

promotion of LANSA definitions ending abnormally. 

Verify the Implementer user profile MWIPROD has authority to modify and delete the 

definitions for all LANSA objects managed with Implementer. 

Implementer provides the IMLNPSO data area that allows you to store the name of the 

LANSA partition security officer. Implementer runs the LANSA command for export/ 

import using the partition security officer profile to prevent migration failures caused by 

insufficient authority to the LANSA command and the items being exported. For details 

on the data area, see “LANSA Partition Security Officer (IMLNPSO)” on page 408. 

If distributing LANSA objects to remote locations using the Implementer Receiver, 

Implementer uses the IMPJOBD job description (in library MKSIR) on the remote system 

to set the library list for remote jobs. This requires you add the LANSA product libraries 

DC@PGMLIB, DC@DTALIB, and DC@DEMOLIB to the IMPJOBD library list. If you 

renamed the LANSA product libraries, add the renamed libraries to the initial library list 

of the IMPJOBD job description. 

329


330 

Implementer supports only one copy of LANSA product libraries per installation. If you 

use separate copies of LANSA on a single system where each copy has its own data and 

program libraries, for example, one copy for development and/or QA and another copy 

for production, each LANSA copy must point to a different copy of Implementer. For 

information on troubleshooting problems with this usage, see the related messages in job 

MON_BK0516. For information on installing parallel versions of Implementer, see the 

MKS Implementer 2006 Installation Guide. 

Defining Environments and Loading the Repository 

The set up activities associated with managing LANSA applications include setting up the 

environments that manage LANSA objects. You must associate each of these environments 

with a partition where the LANSA applications reside. 

In Work with Environments, establish the environment as a LANSA environment by 

specifying an existing LANSA partition in the LANSA partition name field. 

In the Copy LANSA object in check out field, specify whether to copy LANSA objects to 

this environment during check out. 

Do not specify the same partition for a From environment and target environment if the 

environments are used for the same check out or promotion session. The special 

environment type displays on the second Change Environments panel. If you remove 

the partition name, the environment type reverts to a standard environment. 

If you use a LANSA environment only for LANSA definitions, set the Compile required 

field to N. 

The export step exports LANSA objects on the request to a save file. You can set 

promotion processing to automatically submit through the export step only. In the 

Change Environment panel, specify Y in the Auto submit in create rqs field, and type 

1=Expt in the Through step field. 

To verify successful completion of the export, review the export reports generated by 

LANSA, or use data area IMLNMSG as described in “Ending Promotions Based on 

Message ID” on page 331. 

To use an environment group for LANSA objects, the primary environment must be a 

LANSA environment. LANSA objects are moved to other environments in the group 

only if they have a special environment type of LANSA. 

To archive LANSA objects, each LANSA environment must specify the archive library 

and the number of archive versions to retain. For information on how to archive and 

recover LANSA requests, see the MKS Implementer 2006 User Guide. 

Run the Build List to create the list of LANSA objects in the partition associated with the 

LANSA environment. Implementer analyzes the LANSA repository and retrieves the list 

of LANSA objects.

Ending Promotions Based on Message ID 


Implementer provides the IMLNMSG data area that allows you to store the message IDs of 

errors you want to force a promotion to fail on if the error is encountered. Fatal messages 

automatically cause the promotion to fail. 

During promotion processing, Implementer compares the message IDs written in the export 

list spool file to the message IDs recorded in the IMLNMSG data area. When a match is 

found, it ends the processing of the promotion job. 

This data area is blank by default. When adding multiple message IDs, separate the message 

ID values with one blank space. 

LANSA Object Codes 

Implementer provides the following object codes for checking out and promoting LANSA 

definitions. Before using the object codes for the first time, you must run the Build List for 

each LANSA environment to update the repository. 

Implementer uses the object code’s special characteristic to derive logic. The special 

characteristic matches the object code name and assigns the object authority *KEEP. You can 

change the name of an object code, but you cannot change the special characteristic. 


LANFLD LANSA fields. 

LANFIL LANSA files. 

LANFLDT LANSA files with data. 

LANPROC LANSA process. 

LANFNC LANSA functions. 

LANWEBC LANSA Web components. 

LANXMLC LANSA XML components. 

LANSVAR LANSA system variables. 

LANMVAR LANSA multi-lingual system variables. 

Implementer supports having the same file name in a single partition that exists in two 

different libraries. This feature requires using separate object codes for each file library. In 

addition, each separate object code must have the object library specified at the environment 

level. For information on setting up object codes, see page 127. For information on overriding 

a default library for an object code and environment, see “Environment Overrides” on 

page 133. 

331


LANSA Task Tracking 

Visual LANSA 

332 

Implementer supports using LANSA task tracking to manage your LANSA development 

and related issues. 

Task tracking replaces the use of Implementer projects. With task tracking enabled, 

Implementer processes LANSA tasks as projects by creating a project record from the 

specified task number, if one does not already exist. To support the LANSA task number 

format of 8 characters and Implementer’s project number format of 7 characters, the LANSA 

task number right-truncates when converted to the Implementer project ID. 

Implementer creates a project record for any task number that exists in the LANSA task 

definition log file with a status of Open or Work. Implementer also creates a project record if 

the task exists in the LANSA TTS object register file and the task number does not exist in the 

Implementer project file. If the task does not exist in the TTS object register file, any value 

specified in the Project Reference field is processed as a project number by Implementer. 

When creating a request, the locked project number defaults in the Project Reference field on 

the Create Request panel. During the move, the project number defaults in the TASK_ ID 

parameter on the LANSA command for exporting and importing. 

The LANSA command allows only one task number; thus, only one task number is allowed 

per promotion request. Using project filters guarantees only one task number per request. If 

you select records for more than one task number, exit the Create Request panel and clear the 

selected objects to omit. 

LANSA task tracking is controlled in Implementer by the LANSA Task Usage (IMLNTSK) 

data area. The data area value must be *YES to enable task tracking (the default value is 

*NO). 

To enable LANSA task tracking 

Issue the CHGDTAARA command as follows: 

CHGDTAARA DTAARA(IMLNTSK) VALUE(*YES) 

Implementer provides integration with Visual LANSA for the development of your graphical 

and client/server applications in a Windows-based development environment. 


The following information applies to setting up and using Visual LANSA with Implementer. 

Environment pathing must be set up for LANSA environments. The test partition is 

allowed on only one path.

Lawson Software Integration 

Emergency development requires a separate emergency development partition. The 

emergency partition is allowed on only one path. 

All environments on the path require the Copy LANSA objects in check out field set to N. 

Visual LANSA requires the use of task tracking within your development model. For 

details, see “LANSA Task Tracking” on page 332. 

The MWIPROD user profile must have data read authority to the following LANSA files 

used by Implementer programs: 

DC@F76V1 (TTS Object Event Log) 

DC@F75V2 (TTS Task Definition Log) 

DC@F74V1 (TTS Object Register) 

Change the DC@A07 data area in LANSA to set an Implementer exit program that 

executes the LANSA APIs to run a command. This task is described next. 

To change the DC@A07 data area in LANSA 


CHGDTAARA DTAARA(DC@PGMLIB/DC@A07 (689 20)) VALUE('MKSIM 

IMLNUSEX') 

IMPORTANT Previous releases of the Implementer and Visual LANSA integration 

required adding a trigger to LANSA file DC@F76 in library DC@DTALIB. The 

DC@A07 data area replaces the need for the trigger; thus, you must remove the 

trigger if it exists. Use the following command to remove the trigger: 

RMVPFTRG FILE(DC@DTALIB/DC@76) TRGTIME(*ALL) TRGEVENT(*ALL) 


Lawson Software provides a comprehensive and customizable solution that includes 

applications for enterprise performance management, distribution, financial statements, 

human resources, procurement, retail operations, and service process optimization. 

Implementer is compatible with all releases of Lawson Software. 

When configuring Implementer for integration with Lawson, two features of the Lawson 

modules require additional setup considerations: 

Source and object library structure. 

LID method of screen and report generation in Lawson 7. 

333


Source and Object Library Structure 

334 

In a typical Lawson environment, source is delivered in a single source library and source 

members are stored in application-specific source files. For example, the accounts payable 

source file QAPRPGSRC contains all source members for the Accounts Payable module. 

The recommended approach for configuring Implementer is to define one set of 

environments that encompasses all Lawson applications, rather than a set of environments 

for each application. The Lawson source is contained in one library with many source files 

that differentiate the application modules. The source types specified on each source member 

allows Implementer to assign object codes when you run the Build List. 

LID Method of Screen and Report Generation 

Lawson 7 provides a Graphical User Interface (GUI) for viewing the application’s screens and 

reports. Another feature provides greater control of report printing. This method of creating 

screens and reports is referred to as “LID method of screen and report generation”. 

Implementer supports the management of screen and report generation by using specific 

object codes you create for each Lawson application module. The object codes have userdefined 

commands and programs. To assist with the minimal setup, Implementer provides 

sample programs in source file QSAMPLE (in the Implementer product library MKSIM) that 

describe how to create the command and CL program for each object code. Refer to the 

following Lawson-related items in QSAMPLE: 

Member/Object Type Description 

PCRTPRNT7 CMD Lawson create print command. 

PCRTPRNT7C CLP Lawson create print command CPP for LID method of screen and 

report generation. 

PCRTSCRN7 CMD Lawson create screen command. 

PCRTSCRN7C CLP Lawson create screen command CPP. 

See the instructions included in source member PCRTPRNT7 for creating the printer related 

object code. See the instructions included in source member PCRTSCRN7 for creating the 

screen related object code. These commands execute the Lawson LAWENV program to set 

library lists and environment variables, and execute the Lawson command to create GUI 

information for the screens and reports. 

NOTE For details on QSAMPLE, see “Customizing Implementer” on page 414.

The object code values required for a Lawson screen generation are as follows: 


Object Code SCRNAP7 

Source member type SCRN 

Default source file APRPGSRC7 


Creation process M 

The object code values required for a Lawson report source are as follows: 


Creation command PCRTSCRN7 LAWENV(#ENV) LAWAPP(application_name) 

SOURCE(#SRCFIL) MEMBER(#OBJECT) 


Object Code PRNTAP7 

Source member type PRNT 

Default source file APRPGSRC7 


Creation process M 

Creation command PCRTPRNT7 LAWENV(#ENV) LAWAPP(application_name) 

SOURCE(#SRCFIL) MEMBER(#OBJECT) 

NOTE The instructions in QSAMPLE explain that the object code uses the creation 

command with the default parameters defined for the CL program, and instruct you 

to modify the CL using the default values for the LAWENV and LAWAPP 

parameters. Thus, if you modify the default value of either of these parameters, you 

must include the parameters and new values on the object code creation command. 


If you deploy Lawson applications to a remote environment defined with local source and 

local compiles (in Work with Environments), an additional configuration step is required to 

create the LID information during promotion. 

For each remote environment defined with local source and local compile location, create a 

special command to run on the remote system as described next. 

335


336 

To create the special command for a remote environment 

1 From Work with Environments, select the remote Lawson environment with option 

19=Special commands and press ENTER. The Work with Special Commands panel 

displays. 

2 Press F6=Create. The Expanded Command Display panel displays. 

3 Define the fields as follows: 

In the For Action field, type 4=Move. 

In the When to do field, type 2=After-OK. 

In the Sequence number field, type 1.0. If the environment has other special 

commands, specify the number in relation to the other special commands. 

In the Command field, type the following command syntax: 

IEXCRQSDTL OBJCODE(*ALL) 

RQSNBR(#RQSNBR) 

TARGET(ENV_NAME) 

COMMAND(PCRTPRNT7 LAWENV(#TRGENV) LAWAPP(AP) 

SOURCE(#SRCFIL) MEMBER(#SRCMBR)) 

4 Press ENTER to add the command. 

Frequently Asked Questions 

Do I need to define the CALL LAWENV command in a special command? 

No. The CL program delivered in QSAMPLE executes the LAWENV command to set the 

library list and Lawson environment variables to ensure the LID-created objects are created 

successfully. 

How are you able to run the LAWENV program in a submitted program? 

Passing blanks as the second parameter allows the LAWENV program to run in batch. 

Do I need to change the Implementer job description to include Lawson libraries? 

No. During check out and promotion Implementer uses the environment library list to 

perform the required library manipulation. 

Lotus Domino Integration 

Implementer provides integration with Lotus Domino to offer change management support 

for iSeries-based Lotus Notes and your internally developed Domino software applications.


This separately licensed feature provides browser-based check out, promotion, and 

deployment of Lotus Notes Storage Files (NSF) and Notes Template Files (NTF) from 

Domino Designer. To ensure the Notes databases you deploy have the correct authority, 

Implementer allows you to set the Domino Access Control List (ACL) during check out and 

promotion. 

The integration supports using MKS Integrity issues or DesignTracker design requests when 

checking out and promoting NSFs and NTFs. The integration builds on the framework of the 

existing Implementer technology that includes the latest support for IFS technology and 

change management of client/server applications. The integration capitalizes on the 

browser-based support Implementer provides for IFS objects. 

With this solution, the Implementer for Domino interface incorporates Domino development 

in tandem with your iSeries development. From within Domino, developers can check out 

the Notes databases using a browser interface. After completing the work, objects can be 

promoted through a browser interface to a *QAC or *PRD environment back on the iSeries. 

After promotion, the objects reside in a staging repository where they are subsequently 

deployed to a Domino server or Domino clients. The server updates are accomplished by 

either another iSeries under the control of Implementer, or an NT mounted drive. Domino 

client updates are under the control of Tivoli. 

To facilitate ease of use, developers can use Implementer without familiarity of the iSeries, by 

using a browser interface that supplies functionality to the desktop. For access to the iSeries, 

the interface construct uses CGI (Common Gateway Interface) technology. 

Implementer enables you to track all software changes made to Lotus Domino objects that 

reside on the iSeries, with the following benefits: 

Centralized Registry of Objects in iSeries Folders 

The Implementer repository maintains objects that reside in the IFS directory, as well as 

traditional OS/400 member/objects. Use the Implementer Work with Objects function to 

view repository items. 

Promotion Transaction History 

The Request Inquiry panel maintains a current list of all items promoted into a particular 

environment by Implementer. For IFS objects, historical data provides vital information 

such as object author, object authorities, and time/date stamps for each step of a 

promotion. 

Synchronized With Legacy Applications 

Implementer for Domino supports controlled deployment of multiple applications 

during a single promotion. You can install traditional OS/400 objects along with IFS 

objects, without having to maintain multiple software packages for tracking and 

maintaining objects on the iSeries and Domino server. This deployment architecture 

ensures minimum downtime during your application programming. 

337


Requirements 

338 

Deployment Packaging 

Easily create change packages of Notes databases to deploy using the menu or from 

command line interfaces in Implementer. Initiate package deployment using the 

deployment server—configurable to automatically install change packages on each 

target server—with no intervention required on your part. 

Customizable scheduling of change packages allows you to install changes when you 

need them. For change packages deployed to multiple servers, you can schedule each 

package to run at a specific time based on the local needs of each server. Upon 

completion, status information posts back to the deployment server. 

Synchronized With Back Office Development 

Implementer for Domino allows you to deploy changes consisting of both Lotus Notes 

content and integrated back office changes. This ensures synchronous deployment of 

your RPG or COBOL based business logic and DB2/400 databases (integrated with 

Notes applications) to your testing or production servers. This deployment architecture 

ensures a minimum of downtime for your applications. 

Synchronized With Other e-Business Initiatives 

Implementer for Domino manages your e-Business development needs when they 

expand beyond Notes applications. As with back office development, it also allows for 

management of your Java executables; static HTML, XML, and XSL; and graphics (such 

as JPEG and GIF files), along with your Notes development. 

This Implementer release is certified to work with Domino release 6.0. The requirements for 

these integrated features are as follows: 

Implementer 2006 for deployment of Lotus NSFs and NTFs. Implementer requires 

OS/400 V5R1 or later, or i5/OS V5R3 or later. 

Lotus Notes R4.6 or later (including Notes Client, Domino Designer, and Domino 

Administrator). 

Domino Server R4.6 or later for deployment. The Domino Server provides the easiest 

and most flexible use of the Lotus Notes database and the Implementer change 

management software by using the same platform to create, change, move, and deploy 

the Lotus NSFs and NTFs. 

This integration expands to Domino Servers on platforms other than the iSeries. For 

example, you can run a Domino Server on a Windows NT platform to create Lotus NSFs 

and NTFs, which you can place under Implementer change management control using a 

mapped network drive or shared network folder. 

Internet Explorer 4.0 or later, or Netscape 4.5 or later.

iSeries Setup and Configuration 


This integration supports using either of the IBM HTTP Web servers: the original Web Server 

for iSeries or the Apache Web Server for iSeries. Before using the integration, your system 

administrator or a user who is authorized and familiar with server setup functions needs to 

configure the Web interface to use one of these servers. For detailed information on setting 

up the servers, see “iSeries Web Server Setup” on page 156. When you have finished that 

task, continue with “Implementer Setup and Configuration” in the next section. 

NOTE The following sections describe how to set up the basic Lotus Domino 

integration. For details on setting up ACL management, see “Managing the Domino 

Access Control List” on page 343. For details on setting up database signing, see 

“Database and Template Signing” on page 351. 

Implementer Setup and Configuration 

The following tasks assume the *PRD, *TST, and *QAC environments that manage Lotus 

development and IFS objects are set up in Implementer with the IFS directory path and path 

owner, IFS object owner, and archive information (if archiving). When defining the Domino 

environments, define the *PRD environment with a standard application path. In addition, to 

ensure the correct ownership of Domino database archives, specify an archive directory that 

is outside of the standard Domino data directory. For details on environment setup, see 

“Environments” on page 81. 

Implementer provides the Domino Server Data Directory (IMDOMDATA) data area that 

allows you to record the server data directory for Implementer to use to call the Domino API. 

This is only required if you are using Domino 6.0 and the Domino server does not use the 

Domino 5 default data directory /notes/data. 

In the IMDOMDATA data area (located in the Implementer product library MKSIM) you 

must specify the actual data directory used by the Domino sever. The data area is delivered 

with a blank default value. 

To change the IMDOMDATA data area 

1 Issue the CHGDTAARA command and press F4 to prompt. 

2 In the New value field, specify the data directory for the Domino server. 


339


Domino Designer Setup and Configuration 

340 

The Implementer for Domino integration uses Uniform Resource Locator (URL) technology 

to access the iSeries and run the check out and promotion programs. This allows you to run 

the Implementer Software Adapter for Domino programs by using any viable method for 

accessing Internet addresses, such as: 

type the URL in the browser Address bar 

add the URL to the browser Favorites list 

create custom tools in Domino Designer 6.0 (SmartIcons in Domino Designer 5.0) 

Using Domino tools or SmartIcons allows you to customize the Implementer for Domino 

programs and run the browser-based functions from the desktop. These methods require you 

create either tools or icons defined with the URL path on the iSeries that points to the Web 

check out program and the Web promotion program. 

If you use MKS Integrity for issue management within Implementer, you can automate the 

integration by creating tools or SmartIcons to run MKS Integrity from within Domino 

Designer. For details on this feature, see “Implementer and Integrity Manager Integration” 

on page 21. 

To run the Implementer for Domino Web programs from an Internet Explorer or 

Netscape browser 

Open your browser, and in the Address bar type the URL for the iSeries (include the bin 

directive), for example: 

http://your-iSeries-name/cgi-bin/imweb?cmd=chkout 

where, 

//your_iSeries_name defines the iSeries host name 

/cgi-bin defines the reference within the HTTP configuration that points to the 

Implementer library 

/imweb?cmd=chkout defines the Implementer program to run 

To create custom tools in Domino Designer 6.0 

1 From Domino Designer, click Tools > Add Tool. The Add Tool dialog box displays.

2 Follow the Domino Designer instructions for creating custom tools. 


In the Tool Name field, specify a text description to identify the menu item, for 

example, Implementer Check Out. 

In the Tool Action field, enable Run program. 

In the Tool Action text box, type the HTTP address location to access the 

Implementer Web function, for example: 

address for Web check out: 

http://system_name/cgi-bin/imweb?cmd=chkout 

address for Web reject: 

http://system_name/cgi-bin/imweb?cmd=reject 

address for Web promotion: 

http://system_name/cgi-bin/imweb?cmd=crtrqs 

From the Tool Context list, click the options that control when the tool is available. 

3 Click OK to create the tool and add the tool to the Tools menu. 

4 Repeat steps 1–3 for each Implementer Web function: check out, reject, and promotion. 

Once you complete this task, the Implementer Web functions are accessible from the 

Tools menu as illustrated next. 

341


342 

To add SmartIcons to Domino Designer 5.0 

1 From Domino Designer, click File > Preferences > SmartIcon Settings. 

2 Follow the Domino Designer instructions for adding SmartIcons. 

Add an icon for each Implementer Web function: check out, reject, and create request. 

For each icon, specify the @URLOpen formula statement that starts the each respective 

program, for example:

formula for Web check out: 

@URLOpen ("http://system_name/cgi-bin/imweb?cmd=chkout") 

formula for Web reject: 

@URLOpen ("http://system_name/cgi-bin/imweb?cmd=reject") 

formula for Web promotion: 

@URLOpen ("http://system_name/cgi-bin/imweb?cmd=crtrqs") 


where, system_name/cgi-bin defines the iSeries host name (virtual location the iSeries 

server maps to) and imweb?cmd=(value) defines the Implementer program to run. 

To add an icon for MKS Integrity, define the URL by specifying the installation location 

of MKS Integrity. This may be a file location on your desktop, or a server name and IP 

address if located on another server, for example: 

or 

@URLOpen ("http://server_name:7001") 

D:/Program Files/MKS/Integrity Client/bin/MKS Integrity.exe 

Once added, the icons display on the Domino Designer toolbar. 

Managing the Domino Access Control List 

A Domino Access Control List (ACL) is a collection of entries in a table that define which 

access rights a user has to the database. 

343


344 

Every database has an ACL that specifies the level of access that users and servers have to the 

database. Although the names of access levels are the same for users and servers, those 

assigned to users determine the tasks that users can perform in a database, while those 

assigned to servers determine what information within the database the servers can replicate. 

The ACL allows a manager to control user access by requiring authentication of the user’s 

identity or membership in a predefined group. Access is then granted according to the 

assigned rights. 

For each user, server, or group in an ACL you can specify: 

Access levels that control which tasks a user can perform in a database, or control what 

information within a database a server can replicate. 

Access level privileges that enhance or restrict the access level assigned to each name in the 

ACL. 

User types that identify whether a name in the ACL is for a person, server, or group. 

User types provide additional security for a database. 

Roles that allow a database designer to define a subset of users, servers, or both to 

provide controlled access to database design elements, or to some database functions. 

The MKS Implementer Adapter for Lotus Domino supports the management of Domino 

database ACLs by allowing you to set the ACL at various stages in the development cycle. 

The following setup tasks assume the Implementer environments used for the Lotus Domino 

integration exist. For more information, see “Implementer Setup and Configuration” on 

page 339. In addition, this feature requires: 

authorizing a user profile to the IFS directories 

defining the ACL directives 

creating a special command that sets the ACL 

Defining QNOTES Authority to IFS Directories 

The user profile QNOTES must have authority to all IFS files and directories in the 

environment paths of the *PRD, *TST, and *QAC environments. This is established in 

Implementer by defining the user profile value QNOTES as the directory path owner and IFS 

file owner for native IFS directories. 

To authorize user profile QNOTES to the IFS directories 



2 Select the environment with option 20=Directory setup and press ENTER. The Work with 

Environments - Directory Setup panel displays. 

In the Directory path owner field, type QNOTES.

In the IFS file owner field, type QNOTES. 



4 Repeat these steps for each *PRD, *TST, and *QAC environment defined for this feature. 

Defining ACL Directives 

You define the ACL directives as a series of commands, either in a source physical file 

(maintainable with SEU) or in the Implementer promotion request comments. You should 

use a source physical file when the directives are static or unchanging and apply to one or 

more Notes databases in an environment. This recommended method provides maximum 

control when assigning ACL access rights. For examples of this method, see page 346. 

When the directives are more dynamic and varying in nature, you can use the Implementer 

promotion request comments; however, this method renders less control due to its free-form 

structure. 

For setting an ACL in check out, you must define the directives in a source physical file 

member. The format of the directives is as follows: 

where: 

**STRDOMACL 

addrole 

removerole 

removeallrole 

addacl ::: 

removeacl 

removeallacl 

**ENDDOMACL 

NOTE The **STRDOMACL and **ENDDOMACL markers are only used when the ACL 

directives are embedded in the promotion request comments. 

Value Description 

Domino access identifier the ACL applies to. 

= Domino access identifier type being set. Valid values are mixedgroup, person, 

persongroup, server, servergroup, and unspecified. This value is validated. 

Access level to grant. Valid values are noaccess, depositor, reader, author, editor, 

designer, and manager. This value is validated. 

Comma-delimited list of roles to assign to the ACL entry. If the role does not exist 

for the ACL it is added automatically. 

345


346 

Example ACL Directive 

removeallacl 

removeallrole 

addrole user 

addrole developer 

addacl findept:persongroup:reader:developer,user 

addacl misdept:persongroup:noaccess:developer 

addacl vpfinance:person:manager:user 

Defining Special Commands 

The following Implementer special commands allow you to set the Domino ACL: 

Set Domino ACL (ISETDOMACL) command 

Execute Checkout (IEXCCKOCMD) command 

Execute Request Detail (IEXCRQSDTL) command 

The ISETDOMACL command establishes and maintains an ACL for a specified Domino 

database file. The ISETDOMACL command is described in detail in this section. 

The IEXCCKOCMD and IEXCRQSDTL commands are command processors. Independent of 

one anther, they allow you to distinguish certain items during check out and promotion 

(respectively) for additional special command processing. The IEXCCKOCMD and 

IEXCRQSDTL commands actually condition the processing of any command you specify. 

Based on criteria you define for the special command, the selected items checked out or 

promoted are identified, and the commands you specify execute for the objects that meet the 

conditional criteria. 

You use the ISETDOMACL command in conjunction with either the IEXCCKOCMD 

command or the IEXCRQSDTL command. Together, they allow for setting a Domino ACL at 

your choice of two stages in the development cycle: check out or promotion. This architecture 

eliminates potential mis-use of the command by only allowing the command processing, and 

thus, controlled ACL management, within the specified job stream. 

The IEXCCKOCMD and IEXCRQSDTL commands are explained at a high level in this 

section as they pertain to ACL management with the ISETDOMACL command. Command 

examples are included. For details on special command processors and valid substitution 

variables, see the MKS Implementer 2006 User Guide. 

To define a special command to set an ACL 



2 Select the appropriate environment with option 19=Special commands, and press 

ENTER. The Work with Environments Special Commands panel displays. 

3 Press F6=Create.


4 Complete this panel based on your requirements. The ISETDOMACL command syntax 

and command parameters are described next. For a description of the fields on this 

panel, see the MKS Implementer 2006 User Guide. 

5 When you have finished, press ENTER to create the special command. 

6 Repeat these steps for each applicable environment. 

ISETDOMACL Command Syntax 

ISETDOMACL DB(NAME) 

ACLDIR(*FILE or *COMMENT) 

ACLFILE(FILE_NAME) 

ACLMBR(MEMBER_NAME) 

RQSNBR(Implementer request number) 

ISETDOMACL Command Parameters 

Database (DB) 

Specify the name of the Domino database to process. 

ACL directive source (ACLDIR) 

Specify where to retrieve the ACL control directives. 

*FILE Sets the ACL in check out or promotion. Retrieves the ACL control 

directives from an existing source physical file. You must also qualify 

the ACLFILE, Library, and ACLMBR parameters. 

*COMMENT Sets the ACL during promotion. Retrieves the ACL control directives 

from the promotion request comments you define when creating the 

promotion request. You must also qualify the RSQNBR parameter. 

ACL directive source file (ACLFILE) 

If you specified *FILE for the ACL directive source (ACLDIR) parameter, specify the name of 

the file to read the ACL directives from. 

Library 

If you specified an ACL directive source file name, specify the name of the library associated 

with the file referenced. 

347


348 

Member (ACLMBR) 

If you specified an ACL directive source file name, specify the file member to read. 

IMPORTANT Due to OS/400 limitations, the short member name generated by 

Implementer is not a valid ACLMBR name due to the tilde (~) character. Thus, if you 

are using the #SHORTNM substitution variable for the ACLMBR parameter in a 

special command in check out or promotion, each tilde character in the substituted 

value automatically translates to the number sign (#) character. 

For example, you specify the long file name databasefile.nsf, Implementer 

generates the name database~1, and creates the directive source member name 

database#1. 

Request number (RQSNBR) 

If you specified *COMMENT in the ACL directive source (ACLDIR) parameter, specify the 

Implementer request number that contains the request comments. 

Setting ACLs in Check Out 

The IEXCCKOCMD and ISETDOMACL commands are used together to set a Domino ACL 

for development use when checking out to a *TST environment. After defining the 

ISETDOMACL command within the IEXCCKOCMD command as an environment level 

special command for the target environment, the command processes for all appropriate 

objects checked out to the environment. If a special command fails during check out, the 

process halts and the error displays. After correcting the problem you can retry the check out. 

This method requires defining the ACL directives in an existing source physical file. 

NOTE 

When defining the IEXCCKOCMD command to run the ISETDOMACL 

command, to avoid possible errors in the browser if an object does not exist in the 

target directory, set the ACTION parameter value to *CHANGE (rather than 

*CREATE). This issues the command for only items that are checked out for 

change. 

The ISETDOMACL command is applicable for setting an ACL on the iSeries 

server; however, do no use it in check out if the development (*TST) environment 

is on a local PC, for example, \QNTC\DEVDEMO\HOME\TST1. 

IEXCCKOCMD and ISETDOMACL Example 

In the following example, the special command is set to run after a successful check out.


The IEXCCKOCMD command is defined to process the ISETDOMACL command for all 

NSF objects checked out for change to the LOTUS_TST environment. 

Within the ISETDOMACL command, the substitution variable #PATHOBJ ensures the 

specified ACL processing occurs in the directory of the target environment. 

The ACL directives are defined in a source file, which you define by the use of 

ACLDIR(*FILE). 

Setting ACLs in Promotion 

The IEXCRQSDTL and ISETDOMACL commands are used together to set a Domino ACL in 

a target environment during promotion. After defining the ISETDOMACL command within 

the IEXCRQSDTL command as an environment-level special command for the target 

environment, the command processes for all appropriate objects on the promotion request. 

With this method, you have the option to place the ACL directives in either an existing source 

physical file or the Implementer promotion request comments. When setting a standard 

ACL, MKS recommends you retrieve the ACL directives from a source physical file. When 

setting a specific ACL for a specific database, MKS recommends you retrieve the directives 

from the promotion request comments. 

IEXCRQSDTL and ISETDOMACL Examples 

In the following example, the special command is set to run before the move occurs. 

349


350 

The IEXCRQSDTL command is defined to process the ISETDOMACL command for all 

NSF objects on a promotion request. 

Within the ISETDOMACL command, note the use of #FRMDIR/#OBJECT instead of 

#PATHOBJ. This ensures the specified ACL processing occurs in the work library rather 

than the target directory—if for any reason the ACL manipulation fails or the promotion 

fails, the production database is not effected. 

The ACL directives are defined in the request comments, which you set by the use of 

ACLDIR(*COMMENT). 

The following are additional examples of using the IEXCRQSDTL command to process the 

ISETDOMACL command in promotion. 

This example sets an ACL for a database from a file named ACLMASTER in the 

MKSIMUSR library, using a member name based on the short object code (derived by 

Implementer). This allows you to specify the ACL on a database basis. 

ISETDOMACL DB('#FRMDIR/#OBJECT') 

ACLDIR(*FILE) 

ACLFILE(MKSIMUSR/ACLMASTER) 

ACLMBR('#SHORTNM') 

NOTE Due to OS/400 limitations, if the #SHORTNM substitution variable for the 

ACLMBR parameter contains any tilde characters, the substituted value 

automatically translates to the number sign (#) character. For details, see 

“MEMBER” in “ISETDOMACL Command Parameters” on page 347.


This example sets an ACL the same for all databases promoted in the environment. 


ACLDIR(*FILE) 


ACLMBR('ACLMASTER') 

This example sets an ACL based on the target environment. The ACL is specified by 

creating a member in file MKSIMUSR/ACLMASTER using the target environment 

name as the member name. 


ACLDIR(*FILE) 


ACLMBR('#TRGENV') 

Database and Template Signing 

Implementer provides the ability to sign Domino databases (NSF) and template files (NTF) 

during promotion to QA and production environments. The signed databases and templates 

can be promoted to one or more host and remote iSeries systems. If signing fails for any 

reason, the promotion request is set to a move fail status, and messages related to the failure 

are sent to the iSeries job log. 


This feature requires Lotus Domino 6.0 or later running on the iSeries. 

Setup of this feature in Domino requires the assistance of a Domino database 

administrator who is familiar with how Lotus Domino is configured in your shop. 

All signing is performed by a single Domino agent application running in a Domino 

Web server. 

Signing is performed on the source system prior to moving the database and template to 

the target system/environment. 

The user that performs signing must be either the administrator or full administrator 

and have manager rights to the database being signed. 

Each user who has rights to sign databases for the target system must be set up in 

Implementer on the source system. 

Lotus Domino Setup 

The setup tasks in Lotus Domino require a database administrator to do the following: 

351


352 

Install the MKSUtility.nsf database (provided with Implementer) into the Domino 

Server directory of your choice (based on your Lotus Domino configuration). This is the 

Domino agent signing application. 

The utility database installs into the standard root IFS space on your iSeries when you 

install or upgrade Implementer. The default installation location is: 

/MKS/Implementer/product_library/Domino/MKSUtility.nsf 

Ensure the MKSUtility.nsf database is signed by a user that has privileges to Run 

Unrestricted Methods and Operations on the server where database signing occurs. 

Apply any necessary ACLs to the database as needed. 

CAUTION Future upgrades of Implementer require you recopy the database, re-sign 

the database, and re-apply any other changes, for example, ACLs. 

Configure the Domino Server to have the Domino Web Engine use Session 

Authentication with either Single Server or Multiple Servers. 

Implementer Setup 

The setup tasks in Implementer include the following: 

Define the Domino server URL and Domino users in Implementer. 

Define a special command for each Lotus Domino environment that manages the 

databases and templates to be signed. Define the ISGNDOMDB command within the 

Implementer special command processor IEXCRQSDTL at the environment level, to run 

for any promotion action except the delete action. 

To define the Domino Server URL and Domino users 

NOTE This task requires an Implementer user profile that has authority to maintain 

System Control Maintenance. 

1 From the Implementer Menu, type 45, System Control Maintenance, and press ENTER. 

2 Press PAGE DOWN twice to access the third System Control Maintenance panel.


3 In the Domino server URL field, specify the Lotus Domino server URL location that 

points to the Domino database signing application MKSUtility.nsf. 

This must be a valid URL that includes any subdirectories necessary to find the 

Implementer utility database MKSUtility.nsf, for example, 

http://servername.domain:port/subdir. 

4 Press F13=Domino Credentials to display the Work with Domino Users panel. 

5 Press F6=Add. 

6 In the Domino user-id field, specify the Domino user ID that has authority to sign 

databases and templates. 

7 In the Password field, specify the corresponding password for the Domino user ID. (The 

password does not display on this panel.) 

8 Press ENTER to return to the Work with Domino Users panel. Continue adding Domino 

users, or press F3=Exit. 


1 From the Implementer Menu, type option 42, Work with Environments, and press 

ENTER. 

2 Select the Lotus Domino environment with option 19=Special Commands, and press 

ENTER. The Work with Environment Special Commands panel displays. 

3 Press F6=Create. The Expanded Command Display panel displays. 

4 In the For Action field, type 4=Move. (Valid to run only on the host system.) 

5 In the When to do field, type 1=Before. 

353


354 

6 In the Sequence number field, specify when to issue the command in relation to any 

other special commands defined for the environment. 

7 In the Command field, type IEXCRQSDTL and press F4=Prompt. 

8 Complete the remaining field parameters as described in the next section. For details on 

the IEXCRQSDTL special command and special command processing, see the 


9 Press ENTER to add the command. 

10 Repeat these steps for each applicable environment and object code as needed. 

Sign Domino Database (ISGNDOMDB) Command Parameters 

Domino database (DB) 

Specify the name of the database to sign. Enclose the value in quotes as illustrated in 

“ISGNDOMD Command Syntax”. 

Domino userid (USER) 

Specify the Domino user ID that has a authority to sign the database. 

ISGNDOMD Command Syntax 

ISGNDOMDB DB('database_name') USER(authorized_user_ID) 

Example of IEXCRQSDTL and ISGNDOMDB Command 

IEXCRQSDTL OBJCODE(.NSF) 

NAME(*ALL) 

ACTION(*CHANGE) 


TARGET(#TRGENV) 

COMMAND(ISGNDOMDB DB('#FRMDIR/#OBJECT') USER('user_ID') 

PathFinder Integration 

TIP If the environment manages only .NSF and .NTF objects codes, you can specify 

OBJCODE (*ALL) to allow signing both object types with one special command. 

Implementer interfaces with PathFinder, a documentation utility product from Hawkeye 

Systems, Inc. Implementer works with PathFinder Versions 5.1 or later. 

Implementer supports all cross-environment related objects defined within the primary 

Hawkeye database library. Implementer uses PathFinder information for related object 

processing during check out and create request.


Before using PathFinder information with Implementer, in Work with Environments you 

must define each environment that PathFinder documents. In addition, you must run the 

PathFinder “Build Object Cross Reference” for each library defined within the environments. 

For more information on this function, see the PathFinder User Manual and online help. 

Once PathFinder is enabled, related object information is available in check out to help 

determine the members/objects impacted by a planned change. When items are checked 

back into the environments documented by PathFinder, you can specify to add related 

objects to the request. This analysis is done using the information previously loaded into 

PathFinder. 

NOTE Hawkeye does not currently support cross-environment related object 

processing for objects that exist in *QAC environments. 

To define Pathfinder for an environment 



2 Select the environment with option 2=Change and press ENTER. 

3 Press PAGE DOWN to access the second panel. 

4 In the Maintain related obj info field, type Y. 

5 In the Source of information field, type 2 for PathFinder. 

IMPORTANT PathFinder does not currently support ILE programs in the Real Time 

X-Ref Update (REALUPD) command. However, 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, change the value of this data area to Y. When the data area is set to N, 

Implementer does not update the PathFinder database for ILE programs; thus, run 

normal PathFinder updates regularly to keep your data current. 


The Implementer Adapter for PeopleSoft World (formerly J.D. Edwards) manages PeopleSoft 

World applications. The interface is available by purchasing and installing the separately 

licensed Implementer Adapter for PeopleSoft World software. The integration requires a 

specific license key for activation. 

355


356 

Implementer supports the management of PeopleSoft World soft coding items such as User 

Defined Code, DreamWriters, Member Master, Data Dictionary, Vocabulary Override, 

WorldWriter, FASTR, and Processing Option. Implementer also manages PeopleSoft World 

traditional objects, such as RPG and CLP, and includes updating the Software Version 

Repository (SVR). 

Implementer provides object codes specifically for checking out and promoting PeopleSoft 

World soft coding items to and from PeopleSoft World special environments. The check out 

function locks the name of the PeopleSoft World soft coding item, allowing you to develop 

and promote PeopleSoft World items in a controlled method. Distribution of PeopleSoft 

World soft coding items to remote locations is supported. Implementer’s reports and 

inquiries track the PeopleSoft World items it manages. 

This release of Implementer provides support for any PeopleSoft World 8.X version. After 

following the initial instructions in the MKS Implementer 2006 Installation Guide, perform the 

following tasks to configure the host system. 

Configuring the Interface 

The interface objects are shipped in the Implementer product library in save file IMJDESAVF. 

You must restore the save file to the PeopleSoft World interface library IMJDE. This library is 

referred to as IMJDE or the interface library throughout this chapter. 

The setup instructions assume both Implementer and PeopleSoft World are installed on the 

system. The additional set up activities include the following: 

Restore the interface save file objects. 

Apply license keys. 

Define the MWIJOBD job description. 

Enable PeopleSoft World support in Implementer. 

Set up environments to handle PeopleSoft World soft coding items and associate each 

environment with the common library where PeopleSoft World applications are located. 

Set up archiving. 

Activate object codes. 

Set up environment groups (optional). 

Configure remote systems, if applicable. 

IMPORTANT To manage PeopleSoft World soft coding items, you must add the PeopleSoft 

World product libraries JDFSRC, JDFDATA, and JDFOBC to your interactive library list. 

For more information, see the MKS Implementer 2006 User Guide.

To restore the interface save file objects 


After installing Implementer, sign on to the system as the security officer and issue the 

following command: 

RSTOBJ OBJ(*ALL) 

SAVLIB(DSSII) 

DEV(*SAVF) 

SAVF(MKSIM/IMJDESAVF) 

RSTLIB(IMJDE) 

IMPORTANT The IMJDE library must be on the system prior to restoring the save file 

objects. If it does not exist, use the Create Library (CRTLIB) command to create it, 

and then issue the Restore Object (RSTOBJ) command as indicated. 

To apply the security codes for the host system 

1 Add the Implementer PeopleSoft World interface library to your library list by issuing 

the following command: 

ADDLIBLE (IMJDE) 

2 Type the RESETCOD command, and press F4 to prompt. The Reset Security Codes panel 

displays. 

In the Implementer library field, type the interface library name, IMJDE. 

In the next four fields (Security Code #1 through Security Code #4) specify the 

security codes for up to four iSeries systems. Type each code (provided with the 

product media) in the appropriate field. 


To define the MWIJOBD job description 

Verify the following libraries exist in the MWIJOBD library list: 

Implementer PeopleSoft World Interface library (IMJDE). 

PeopleSoft World product libraries (JDFDATA and JDFOBJ). 

IMPORTANT Your interactive library list must have the IMJDE library above the 

PeopleSoft World product libraries. 

To enable PeopleSoft World support in Implementer 

In System Control Maintenance, set the PeopleSoft installed field to Y. 

357



358 

Once you define environments for PeopleSoft World integration, any new object codes you 

create support the PeopleSoft World compiles. The environments include both PeopleSoft 

World object codes (that call the PeopleSoft World compiler) and standard object codes (that 

call the OS/400 compiler). You can optionally deactivate the standard object codes if they are 

not used. For details, see “Deactivating Standard Object Codes” on page 361. 

NOTE If you create an environment group for PeopleSoft World soft coding items, 

the primary environment must be a PeopleSoft World environment. 

To set up PeopleSoft World special environments 

1 Set up standard environments to manage PeopleSoft World applications. 

2 To associate the standard environment with a PeopleSoft World common library, use 

option 16 in the Work with Environments panel. Once the existing environment is 

associated with a PeopleSoft World common library, it becomes a special PeopleSoft 

World special environment. The common library name you specify must exist 

(Implementer does not create a common library). 

To identify this as a special environment, PeopleSoft displays in the Special 

Environment field on the second detailed Change Environment panel. If you remove the 

common library name, the environment type reverts to Standard. 

3 From the Change Environment panel, press F13=Library List to change the compile 

library list in the environment definition to include the following libraries: 

Implementer PeopleSoft World Interface library (IMJDE). 

PeopleSoft World product libraries (JDFSRC, JDFDATA, and JDFOBJ). 

IMPORTANT Your interactive library list must have library IMJDE above the 

PeopleSoft World product libraries. The PeopleSoft World common library does not 

need to be on the environment library list; when it is defined on the PeopleSoft 

World setup panel, Implementer adds it when needed. 

Setting Up for Archiving Soft Coding Items 

You can archive PeopleSoft World soft coding items such as DreamWriters and Data 

Dictionaries into an archive common library you specify for the environment. Implementer 

also supports selective rollback of the archived soft coding items. 

An archive environment must be a PeopleSoft World special environment that has an 

associated archive common library.

To set up for archiving 


1 From the Implementer Menu, type 42, Environments, and press ENTER. The Work with 

Environments panel displays. 

2 Select the environment to set up with option 16=PeopleSoft, and press ENTER. The 

Change Environment panel displays. 

3 In the PeopleSoft archive library field, specify a valid archive library name for archiving 

the soft coding items. The library should be the same name as the Implementer archive 

library assigned to the environment. 

4 Press ENTER to save the entry. 

5 Press F12 to return to the Work with Environments panel. 

6 Type option 2=Change and press ENTER. The Change Environment panel displays. 

7 Specify a value in the Source library field. In the Archive Versions field, specify the 

number of archive versions to retain for PeopleSoft World soft coding items. These fields 

establish the archiving of PeopleSoft World soft coding items. 


Object Codes for Soft Coding Items 

Use the following object codes and matching special characteristics delivered with 

Implementer to manage PeopleSoft World soft coding items. You must first activate the 

object codes (in Work with Object Codes) for all applicable environments. 

NOTE For information on activating and deactivating object codes, see “Object 

Codes” on page 127. 

If needed you can override the common library for all PeopleSoft World soft coding items. 

On the object code overrides panel, select the PeopleSoft World environment with option 

2=Change, and press F8=Object Codes. 


JDEUDE User Defined Code (UDC). 

JDEUDS User Defined Code tables, to set up or change update authorization for specific 

users, PeopleSoft World user class/group, or *PUBLIC. Allows you to control 

which users are authorized to change certain UDC tables. 

JDEDWR DreamWriters. 

JDEMBM Member Masters. 

JDEDDC Data Dictionaries. 

359


Object Codes for Traditional Objects 

360 


JDEVOV Vocabulary overrides. 

JDEMNU Menus. 

JDEWWR WorldWriters. 

JDEFST FASTR. 

JDEPRO Processing Options. 

JDEWCS World Case. 

JDNSPC For traditional objects (like RPG, CLP), required to update the Software Version 

Repository in PeopleSoft World for traditional objects. 

Use the following object codes delivered with Implementer to manage PeopleSoft World 

traditional objects. You must first activate the object codes (in Work with Object Codes) for all 

applicable environments. 

Object Code/ Description 

JDEDSPF Display file. 

JDEPF Physical file. 

JDELF Logical file. 

JDECLP CL program. 

JDERPG RPG program. 

JDEPRTF Generates printer file overrides during promotion (valid for local compiles only). 

With the exception of the JDEPRTF object code, each object code has the special characteristic 

JDNSPN. The JDEPRTF object code has the special characteristic JDNPRTF, which adopts the 

same functionality as the JDNSPC special characteristic. All traditional objects managed by 

Implementer with these object codes/special characteristics update the Software Version 

Repository (SVR) in PeopleSoft World during check out and promotion. The objects must 

exist as member IDs in the SVR file. When working with a new object, you must first create 

the member ID in the SVR file to enable Implementer updates. 

IMPORTANT Only one copy of JDE files F9801 and F9802 can exist across your 

environments. In other words, the production, QA, and development environments 

share these two files; multiple copies of these files cause incorrect SVR updates.

Deactivating Standard Object Codes 


You can deactivate any standard object codes not needed for PeopleSoft World special 

environments. 

To deactivate standard object codes for PeopleSoft World environments 


2 In the Opt field, type 2=Change, and press ENTER. The Change Environment panel 

displays. 

3 Press F8=Object Codes. The Change Environment Object Code Overrides panel displays. 

4 In the Act Flg field, type N next to each object code to deactivate in the environment. 

5 Press ENTER to save the changes. 

Installing the Interface on Remote Systems 

Implementer supports the distribution of PeopleSoft World soft coding items such as User 

Defined Code, DreamWriters, and Member Masters to remote systems. This section pertains 

to sending PeopleSoft World soft coding items to remote systems using the Implementer 

Receiver. 

The interface objects are shipped with Implementer in save file IMJDESAVF, which is 

automatically installed when you install the Implementer Receiver. You must restore the 

save file to the Implementer Receiver product library, MKSIR. After installing the 

Implementer Receiver, perform the following tasks to configure the remote system. 

To restore interface save file objects on a remote system 

1 Sign on to the remote system as the system security officer. 

2 Issue the following command: 

RSTOBJ OBJ(*ALL) 

SAVLIB(DSSII) 

DEV(*SAVF) 

SAVF(MKSIR/IMJDESAVF) 

RSTLIB(MKSIR) 

IMPORTANT On the Implementer Receiver, restore the interface objects into the 

Implementer Receiver library MKSIR. If you changed the name of the Implementer 

Receiver library, replace MKSIR with the new name. 

Because any subsequent upgrades to the MKSIR library overwrite the restored save 

file objects, when upgrading the Implementer Receiver you must perform these 

tasks again to reinstall the interface objects. 

361


362 

To apply security codes to the remote system 

1 Add the Implementer Receiver library to your library list by issuing the following 

command: 

ADDLIBLE MKSIR 

2 Type the RESETCOD command, and press F4 to prompt the command. The Reset Security 

Codes panel displays. 

In the Remote Implementer library field, specify the remote Implementer Receiver 

library name (MKSIR is the default library name). 

In the Security Code #1 through Security Code #4 fields, specify the security code 

(provided with the product media) for up to four iSeries systems. 


4 To reset authority on the restored objects, ensure the Implementer libraries are on the 

library list, and issue the following command. 

IGRTAUT LIBNAM(MKSIR)OBJNAME(*ALL) 

Ignore any error messages after issuing this command. 

5 Change the library list in the job description of the communications entry to include the 

PeopleSoft World product libraries. 

IMPORTANT The job description must include the PeopleSoft World libraries to avoid 

the abnormal end of promotions with PeopleSoft World soft coding items. 

Ensure the user profile MWIPROD has data management authority to all files in all 

PeopleSoft World libraries on the host and remote systems. In addition, enroll 

MWIPROD as part of “GROUP” within PeopleSoft World. 

Powerhouse (Cognos) Integration 

Using Implementer with Powerhouse (Cognos) requires creating an object code for each of 

the Cognos creation commands: QTP, QUIZ, QUICK, and QDESIGN. 

To create the object codes 

1 From the Implementer Menu, type option 44, Object Codes, and press ENTER. The Work 

with Object Codes panel displays. 

2 Press F6=Add to display the Create Object Code panel.

3 Complete the fields using the values described in the following tables. 

Powerhouse (Cognos) Integration 

The examples illustrate each object code having the same name as the creation command 

it is created for. However, this is merely a suggestion; you can assign any object code 

name to the object code. 

4 When finished, press ENTER to save the information. 

QTP Object Code 

Field Value 

Object code/Description QTP (QTP Program (PowerHouse)) 


Object type *USRSPC 

Object attribute QTP 

Source member type QTP 

Default source file PHZTSRC 

Creation sequence 519 

Special characteristics COGPT 



Creation command QTP DICTIONARY(*LIBL/COGNOSSLS) 

AUTO(#SRCLIB/SRCFIL #OBJECT) 

QUIZ Object Code 

Field Value 

Object code/Description QUIZ (QUIZ program) 



Object attribute QUIZ 

Source member type QUIZ 

Default source file PHQZSRC 


Special characteristics COGPZ 



Creation command QUIZ DICTIONARY(*LIBL/COGNOSSLS) 

AUTO(#SRCLIB/#SRCFIL #OBJECT) 

363


ROBOT Integration 

364 

Field Value 

QUICK Object Code 

Object code/Description QUICK (QUICK Program (PowerHouse)) 



Object attribute QUICK 

Source member type QUICK 

Default source file PHQKSRC 


Special characteristics COGPK 



Creation command QUICK DICTIONARY(*LIBL/COGNOSSLS) 


Field Value 

QDESIGN Object Code 

Object code QDESIGN (QDESIGN Program (PowerHouse)) 



Object attribute QDESIGN 

Source member type QDESIGN 

Default source file PHQZSRC 


Special characteristics COGPZ 



Creation command QDESIGN DICTIONARY(*LIBL/COGNOSSLS) 


Implementer supports using ROBOT for job scheduling. With this integration, you can 

identify one or more target environments for ROBOT to use when submitting promotion jobs 

such as compiles and moves. You can also use ROBOT for other Implementer jobs unrelated 

to promotions, such as submitting reports.

Setting Up Non Promotion Jobs 

WebSphere Development Studio Client for iSeries Integration 

The following task describes how to set up Implementer to use ROBOT for scheduling non 

promotion jobs. 

To enable ROBOT scheduling 

1 From the Implementer Menu, type option 45, System Control Maintenance, and press 

ENTER. 

2 Press PAGE DOWN to display the second panel. 

3 In the Submission method for non-promotion functions field, type 2. This enables the use 

of ROBOT for scheduling in place of standard OS/400 scheduling. 

4 Press ENTER to save the change. 

Setting Up Promotion Jobs 

The following task describes how to set up a target environment for job scheduling with 

ROBOT. For promotion requests that target multiple environments, the primary environment 

controls whether ROBOT is used. 

To setup target environments for ROBOT 



2 Use option 13=Promotion scheduling to select an environment. The Change 


3 In the Job submitted by field, type 2 to specify ROBOT is used to schedule promotions to 

the selected environment. 


WebSphere Development Studio Client for 

iSeries Integration 

The IBM WebSphere® Development Studio Client for iSeries (WDSc) plug-in for 

Implementer allows users to access Implementer’s version control functions from within 

Implementer-specific, context-sensitive menu options on the WDSc Remote System Explorer 

(RSE) menu. 

365


Overview 

366 

This fully integrated solution provides support for your Integrated Development 

Environment (IDE) native and client/server software development targeted for an iSeries, 

allowing you to access the functionality of Implementer while working within IBM’s Eclipsebased 

technology in the following iSeries-focused offerings: 

WebSphere Development Studio Client for iSeries (includes WebSphere Studio Site 

Developer (WSSD)). 

WebSphere® Development Studio Client Advanced Edition for iSeries (includes 

WebSphere Studio Application Developer (WSAD)). 

For the purpose of this guide, both offerings are referenced as WDSc. 

The plug-in blends transparently into the IDE, allowing you to work within the framework of 

your existing Implementer software configuration management (SCM) structure. The 

integration additionally supports using MKS Integrity for issue management, and 

MKS Source for your PC-based development. 

NOTE The setup tasks related to this integration are typically performed by each 

developer (rather than an administrator) on individual clients; therefore, the setup 

tasks are described in the MKS Implementer 2006 User Guide rather than this guide. 

WDSc is an IBM development tool used for developing multiple types of applications for an 

iSeries. It is the iSeries offering of IBM’s Eclipse-based WebSphere Studio Workbench 

(WSW). It includes the full functionality of WebSphere Studio Site Developer Advanced 

(WSSDA) and additional major components specific to the iSeries. 

In WDSc, perspectives are used to manage the iSeries development. A perspective is a group of 

views that show various aspects of the resources on the workbench. A user can switch 

perspectives, depending on the current task, and customize the layout of the views and 

editors within each perspective. 

WDSc has three perspectives for iSeries development. This document describes the use of the 

iSeries Projects and Remote Systems Explorer (RSE) perspectives as they relate to using the 

fully integrated WDSc plug-in for Implementer. 

The following shows a graphical view of the plug-in from within the RSE perspective.


After performing an Implementer check out, the member is opened in the default LPEX editor 

for modification. Once the changes are complete, the member is ready for compiling and 

promotion—all from within WDSc. 

The types of users that benefit from using this integration include native iSeries developers 

who use RSE, and native iSeries developers who use iSeries Projects. 

To highlight some of the integration features, developers have: 

Implementer-specific, context-sensitive menu options on the Remote System Explorer 

menu in WDSc that provide direct access to the Implementer SCM functions of check 

out, reject, promotion, and processing. This includes access to the Implementer compile 

function from within WDSc, ensuring compiles retain all existing attributes like when 

run from the Implementer Workbench. 

Flexibility with process changes, where any SCM process can be performed on the 

Implementer Workbench or from within WDSc. Team members can use their interface of 

choice, regardless of which interface other team members use or which interface was 

used for a prior process. For example, you can check out through the Implementer 

Workbench, and then edit and compile through WDSc. 

367


368 

An Implementer properties page provides clear visibility to current member and object 

information for all items under the control of Implementer. For example, it shows the 

current status and environment, as well as the lock details for all active locks on a 

specific item. 

For diagnostic purposes, a log generates for all Implementer actions performed within 

WDSc. A preferences facility allows you to set the message logging level to record 

specific types of messages, for example, error messages, warning messages, or 

informational messages. 

For MKS Integrity customers, the integration supports tracking your iSeries 

development with issues, and further integrates with the MKS Integrity® Worktray 

Plug-in for Eclipse. The worktray plug-in allows a developer to view MKS Integrity 

issues, MKS Source change packages, and Implementer change packages without exiting 

from the WDSc environment. 

For MKS Source customers, MKS provides additional support for WDSc. MKS’s 

integration with WebSphere Studio Workbench (WSW) allows users to access 

MKS Source version control commands when using the WSSDa component of WDSc to 

perform Web and client/server development. 

For more information on WebSphere Studio Workbench, browse to: 

www.ibm.com/software/ad/workbench 

WDSc for iSeries Requirements 

IMPORTANT For additional information related to requirements and assumptions, 

see the Readme file included with the Implementer plug-in. 

To configure and use the Implementer and WDSc integration, in RSE you need to define 

a connection to the iSeries system where Implementer is installed. For more information 

on creating a new system connection or connecting to the system, refer to the 

appropriate WDSc documentation or online help. 

Install and configure WDSc 6 or WDSc 5 on each client. If using WDSc 5, MKS 

recommends you use WDSc 5.1.2. 

You must install and configure any required client service packs. 

You must install and configure the required host components. For details browse to: 

http://www-306.ibm.com/software/awdtools/wdt400/sysreq/index.html 

OS/400 V5R1 or later is required on the iSeries that hosts Implementer. MKS 

recommends you check with IBM for PTFs required for WDSc.


This guide assumes you know how to use WebSphere Studio Site Developer and 

WebSphere Development Studio Client for iSeries. For information on using either 

product, refer to the appropriate IBM product documentation or online help. 

Implementer Requirements 

Install and configure Implementer 2006. For information on installing Implementer, see 

the MKS Implementer 2006 Installation Guide. 

Install Implementer plug-in version 5.7.x or later for use with WDSc 6. 

Implementer also provides plug-in version 5.6.x for use with WDSc 5. Integration with 

the MKS Integrity worktray plug-in requires Implementer plug-in version 5.6.1 or later. 

For more information, see the MKS Implementer 2006 User Guide. 

Each Implementer production environment used for check out or promotion must have 

a development path defined. The paths may have been set up when Implementer was 

initially configured, verify they exist. Environment paths are defined in Implementer 

Menu option 42, Environments. For details, see “Environments” on page 81. 

To ensure check out occurs to a development library when using personal development 

libraries, any applicable environments must have *USRPRF as the development location 

in the environment path. For more information, see the MKS Implementer 2006 User 

Guide. 

Integration with MKS Integrity and the MKS Integrity® Worktray Plug-in for Eclipse 

requires installing and configuring MKS Integrity 2006 or later. 

369


370

C HAPTER SEVEN 

Administrative Utilities 

Maintaining Implementer 

7 

This chapter describes the various utilities and tools Implementer provides to assist 

you with setting up and maintaining Implementer. 


“Submitting Job Overrides” on page 372 

“Resetting Authorities” on page 372 

“Purging Environment History” on page 374 

“Repository Maintenance” on page 376 

“Saving and Restoring Tape Archives” on page 379 

“Clearing Remote QA Environments” on page 384 

“User Capability Wizard” on page 385 

“Deleting Tutorial Information” on page 396 

“Function Key Administration” on page 397 

371

Chapter 7: Administrative Utilities 

Submitting Job Overrides 

372 

System Control Maintenance allows you to define a standard default job queue and library 

where all environment-related submitted jobs run. In Work with Environments, the 

F18=Submit Overrides function allows you to override the global defaults for the job queue 

and library. If you use the OS/400 job scheduler or ROBOT job scheduling, you can also 

schedule jobs to run for a specific date and time. The overrides remain in effect for any jobs 

submitted during the current session⎯in other words, until you exit from Work with 

Environments. This feature applies to submitting job overrides for promotion requests, as 

well as for the Build List, Reset Authorities, and Purge History functions. 

To submit job overrides 

1 From the Work with Environments panel, press F18=Submit Overrides. The Job 

Submission Overrides window displays. 

2 Complete the following fields as described. 

In the Job queue, Library, and Hold on job queue fields, specify the standard OS/400 

submit job parameters as required. 

In the Schedule date field, specify a date for the job to run. The default value is 

*CURRENT. You can change the value to any value valid for the Submit Job 

(SBMJOB) command. 

NOTE *MONTHSTR (start of the month) and *MONTHEND (end of the month) are 

not applicable when using ROBOT to submit promotion requests. 

In the Schedule time field, specify a time for the job to start. The default value is 

*CURRENT. You can change the value to any value valid for the Submit Job 

(SBMJOB) command. Specify Time Range fields in HH:MM:SS format. 

3 Press ENTER to process the overrides and return to the Work with Environments panel. 

Resetting Authorities 

Each environment has specific authorities as defined in Work with Environments. The 

Change Environment Object Authorities function allows you to define the user profiles that 

have authority to reference objects within the environment. The Reset Authorities function 

allows you to grant or revoke authorities for all objects in the libraries of any environment 

you have move capabilities for. 

The object ownership and authorities are reset based on how the authorities are defined for 

the environment. To ensure authorities reset for all objects, run the environment Build List 

prior to submitting the Reset Authorities.

Resetting Authorities 

Use this function for production environments when you initially set up Implementer, and 

when you need to: 

revoke all authorities from objects or libraries 

change owners of environment libraries 

change owners of all objects 

grant authorities for all objects 

Implementer sets authorities during promotion. If you need to change individual member/ 

objects, in Create Request use option 2=Toggle Authority Method to toggle the authorities on 

specific members/objects from *KEEP (keeps the authority of the original object in the target 

environment) or *GRANT (grants authority based on the target environment). 


CAUTION If you set the environment authorities incorrectly, it could render the 

application software unusable by users due to insufficient authority to use the 

objects. Alternatively, it could also allow unauthorized access to the application and 

associated database files by granting too much authority. 

Use this function to establish the proper authorities for all objects within an 

environment, when authorities have changed in create request, or when you need to 

change them for a specific reason. 

You must have authority to host environment maintenance and move authority to reset 

authorities for a host environment. You must have authority to remote environment 

maintenance and move authority to reset authorities for a remote environment. 

Authority to host and remote environment maintenance is defined at the user level, in 

Work with Users. Move authority is defined at the environment level, in Work with 

Environments, User Capabilities. 

This job submits with the defaults defined in System Control. For information on 

overriding the job submission defaults, see “Submitting Job Overrides” on page 372. 

Implementer sets the authorities of IFS files within an environment’s directory the same 

as it sets the authorities on traditional objects and libraries. You must set the authorities 

when defining the environment. 

For new environments with no source library or source files, Implementer automatically 

creates the source library and source files during promotion, and sets the authorities 

based on the object authorities defined for the environment. 

373


374 

When promoting to a Windows NT Server, IFS objects inherit the authorities of the 

target directory, regardless of authorities defined to the environment or existing on the 

from object. The object owner is user SDMAUTUSR (or the user profile defined to 

Implementer data area SDMAUTUSR). Unlike traditional objects, the object owner is not 

set by the Reset Authorities function. 

NOTE The Reset Authorities function does not change the authorities or owners of 

IFS objects in environments on a mounted drive. 

To reset authorities 


1 From Work with Environments, select the environment with option 31, Reset 

Authorities, and press ENTER. A message displays confirming the action you are about to 

perform. (If you need to cancel without running the job, press F3=Exit or F12=Cancel.) 

2 Press F9=Submit to submit the reset authority job. The Work with Environments panel 

redisplays. 

What conditions warrant running Reset Authorities (other than when initially setting up the 

environment)? 

It may be necessary to run this function after initial setup if the libraries within the 

environments become corrupt external to Implementer use. You should restrict external 

access to the libraries you have under Implementer’s controlled. 

When is it necessary to rerun Reset Authorities and overwrite the authorities that exist? 

Use this function if users have either too much or not enough authority to an environment. 

Purging Environment History 

The Purge History function purges the Implementer database of completed promotion 

requests for a specific environment or globally for all environments. The function is available 

on both the host and remote system. On the host system, you can optionally purge lock status 

and history, object status history, and concurrent development activity. 

The function purges information from the Implementer database. It does not delete system 

objects or information. After purging, you can delete the environment if necessary. 

For details on deleting environments, see page 96.


Purging Environment History 

To purge host environments, you must have authority to environment maintenance and 

move authority for the environment. To purge remote environments, you must have 

authority to remote environment maintenance and move authority for the environment. 

Authority to host and remote environment maintenance is defined in Work with Users. 

Move authority is defined in Work with Environments, User Capabilities. 

When purging history for all environments (F19=Purge All History), users cannot access 

or use Implementer while the purge is running (requires a dedicated database). When 

purging specific environments, users cannot access the selected environment while the 

purge is running. 

Purging completed requests removes requests that completed on or before the purge 

date you specify. It removes the entire promotion request if the request is from the 

purged environment, or if the request targets a single environment and that 

environment is purged. If a request targets multiple environments and the secondary 

target environment is purged, it removes the purged primary environment from the 

request and the second environment becomes the primary environment on the request. 

In addition, Implementer adds a comment to the request, for example, “The primary 

target environment ‘name’ was purged on date by ‘user’.” When removing 

a purged secondary environment from the request, Implementer also adds a comment to 

the request, for example, “The target environment ‘name’ was purged on date 

by ‘user’.” 

You can optionally purge closed locks and object status history for production 

environments by specifying *ALL for the purge to date. If a lock is from or to the purged 

environment, it removes the lock and all related history. If a lock was copied from a 

purged environment, it removes any references to the environment from the lock and 

related history. If the history of a lock includes passing through a purged environment, 

the portion of history related to the purged environment. 

CAUTION Use this option cautiously—it purges the Implementer database of 

historical data, thereby removing audit trail information from production 

environments. 

Only requests that are non-release management packages can be removed. For details on 

purging release management environments, see the MKS Implementer 2006 Release 


MKS recommends you print the Activity Report, option 31 on the Implementer Menu, 

prior to running Purge History. This report is useful for analyzing the status of all 

environments and projects. 

375


376 

To purge environment history 


From the Implementer Receiver menu, type option 8, Environments, and press ENTER. 

On the remote system you also have the option to use the Purge History (IDBPRG) 

command. Type IDBPRG and press ENTER to display the Purge History window. The 

Purge History command is valid only on the Implementer Receiver. 

2 Select the environment to purge with option 32, Purge History. To purge history for all 

environments, press F19=Purge All History. The Purge History panel displays. 

3 Complete the fields as described in the following table of “Purge History Field 

Descriptions”. 

4 Press F9=Submit to submit the job (or press F3=Exit to cancel the purge function). 

NOTE For information on overriding the default job queue and submission method 

on the host system, see “Submitting Job Overrides” on page 372. On the remote 

system, data area IRJOBQ stores the remote job queue, and data area IRSBMMTD 

stores the submission method. For details, see “Implementer Data Areas” on 

page 402. 


Repository Maintenance 

Purge History Field Descriptions 

Environment Name If purging a single environment, this field defaults to the 

environment selected on the Work with Environments panel. If you 

selected to purge all environments, the field defaults to *ALL. 

Purge to date Specify the ending date to purge all completed requests. For 

promotion requests, this is the completion date of each request. For 

locks and object history, it is the date the lock was released on the 

host system. Specify *ALL to purge up to the current date. 

Purge lock/obj status history Specify whether to purge lock and object status history. This option 

is valid only for host production environments. Status history is not 

purged for locks released on the specified purge to date, or for 

existing locks with active concurrent development. 

Y: Purges lock and object status history. 

N: Does not purge lock and object status history. This is the 


Implementer’s member/object repository is the source for items that display in Object 

Inquiry and Work with Objects. Repository Maintenance allows you to modify the object 

codes associated with traditional member/objects and IFS objects within the repository for an 

environment.

Repository Maintenance 

This is useful, for example, if unexpected results occur after running the Build List for an 

environment. You can modify an existing object code, such as change PFOBJ to PF after 

locating the source, without having to rerun the Build List. The IFS command is useful for 

loading IFS objects into the Implementer database. 


The Change Repository (ICHGREP) command allows you to add, change, or delete 

object codes for traditional member/objects. 

The Change Repository IFS (ICHGREPIFS) command allows you to add or delete object 

codes for IFS objects. You cannot change IFS object codes, because the object code is 

always the IFS extension (for example, .EXE) or the object short name. 

You must have standard move authority for the environment being maintained to issue 

the ICHGREP and ICHREPIFS commands. 

To maintain the repository for traditional member/objects 

At the command line, issue the following: 

ICHGREP FUNCTION(*ADD, *CHG, *DLT) 

NAME(MEMBER/OBJECT_NAME) 

ENV(ENVIRONMENT_NAME) 

OBJCODE(OBJECT_CODE_NAME) 

NEWOBJCODE(NEW_OBJECT_CODE_NAME) 

DLTDTA(Y, N) 

NOTE The parameter NEWTYPE is valid only for the *CHG function. 

To maintain the repository for IFS objects 

At the command line, issue the following: 

ICHGREPIFS FUNCTION(*ADD, *DLT) 

OBJ(IFS_OBJECT_NAME) 

ENV(ENVIRONMENT_NAME) 

DLTDTA(Y, N) 

377


378 

Change Repository Command Parameters 

Function 

Specify the action to perform. 

*ADD Adds an item to the repository for the specified environment. This is the 


*CHG Changes an item in the repository for the specified environment. Valid for 

traditional member/objects only. 

*DLT Deletes an item from the repository for the specified environment. 

Member or Object 

Specify the name of the member or object to add, change or delete. 

Environment 

Specify the environment location of the member or object (the environment you are adding to 

or deleting from). 

Object code 

Specify the object code currently assigned to the item. Valid for traditional member/objects 

when the Function is *CHG. 

New object code 

Specify the new object code to assign to the item. Valid for traditional member/objects when 

the Function is *CHG. 

Delete from the database 

This parameter is valid for IFS objects when the Function is *DLT. The *DLT function allows 

you to delete the object from the database. The default value is blank. 

Y Deletes the member or object from the database. 

N Deletes the member or object from the environment repository only (does 

not delete from the database). 

Development Library Maintenance 

The Delete Library Reference (IDLTLIBREF) command allows you to delete obsolete records 

from the Implementer repository for development libraries. The command removes all 

references to member/objects within the library, including current locks. Use this command 

when few to no open locks exist.

To issue the IDLTLIBREF command 

From an Implementer command line, issue the following command: 

IDLTLIBREF LIB(LIBRARY_NAME or *ALL) 

Saving and Restoring Tape Archives 


Implementer users who require access to the archives of every change made to an 

environment must often balance this requirement with the disk space required to store the 

archive copies. Archiving to tape minimizes the impact of large archives by allowing you to 

store the archives off line. 

You can save and remove all archives or specific archives. You have access to the archive 

information for each tape. You can selectively restore archives back to the system. Once 

restored, you can browse the changes and/or recover the changes back into production. 

This feature is also available on the Implementer Receiver. For details, see “Saving and 

Restoring Remote Tape Archives” on page 192. 

NOTE For information on archiving and archive recovery, see the MKS Implementer 



Tape archives include IFS and DLO files and directories, if archived. 

The archive to tape function uses two temporary libraries that Implementer 

automatically creates at the beginning of the process and deletes at the end. Implementer 

provides the data area IMARCTAP to store the names of these temporary libraries. The 

default data are values are IMARCTAP1 and IMARCTAP2. 

CAUTION If you change the default library names in the IMARCTAP data area, you 

must specify library names that do not exist on the system, as Implementer creates 

and deletes the libraries as needed. For details, see “Implementer Data Areas” on 

page 402. 

You can initiate all archive to tape functions from the Archives to Tape menu. Access to 

the menu options and commands requires you sign on as QSECOFR or with a profile 

that has a group profile of QSECOFR or QSECOFR capabilities. 

A good practice is to use a new tape for each save. Implementer automatically sets the 

tape label and initializes the tape with volume ARC###, where ### represents a number 

that starts at 001 and automatically increments for each save. Implementer data area 

ITAPEVOLUM store this information. 

379


380 

Implementer provides query reports on the host system that allow you to locate and list 

all archives saved to tape. You can view the reports online or select to print. 

To restore a tape archive, you can use the menu option or a command option to restore 

the archives for any environment archive on a request you need to back out. 

To perform recovery, use Implementer Menu option 23, Archive Recovery, to select the 

request to recover. Implementer automatically creates and promotes a standard archive 

recovery request. You can browse the source through Archive Recovery or Object 

Inquiry. For details, see the MKS Implementer 2006 User Guide. 

Implementer supports using a third party save/restore utility to save archives to tape. 

For example, you can use IBM’s Backup Restore Management System (BRMS/400), or an 

internal program. For details, see “BRMS/400 Integration” on page 322. 

The archive to tape and restore from tape functions are available on the host and 

Implementer Receiver. You can run the jobs interactively or in batch. For details on the 

remote system functions, see “Saving and Restoring Remote Tape Archives” on 

page 192. 

Working With Tape Archives 

The Archives to Tape menu provides access to the functions and reports associated with tape 

archives. Access to these functions requires signing on to the system with the QSECOFR user 

profile, or a user profile that has a group profile of QSECOFR or QSECOFR capabilities. 

To access the Archives to Tape menu 


From the Implementer Menu, type option 24, Archive to Tape, and press ENTER. 

From a command line, issue the STRIM *ARCTAP command, or the GO IMARCTAP 

command (library MKSIM must be in your library list). 

CAUTION The next task initializes a tape and optionally clears the tape contents. To 

avoid the loss of saved data, verify you have the correct tape before continuing. 

To save an archive to tape 

1 From the Archive to Tape menu, select option 1, Save Archives to Tape to prompt the 

Archives to Tape (ISAVARC) command. You can also prompt the ISAVARC command 

from the command line.

2 Complete the command parameters as described next and press ENTER. 


Process the command interactively, submit for batch processing, or add it to a backup 

routine to automate the removal of new archives. 

NOTE When using a third party save/restore utility and you select option 1, the 

Save Archives to Tape panel is replaced as instructed by your internally described 

program in IMSVLB2 in QSAMPLE. As such, the remaining steps in this task do not 

apply; follow the steps applicable to the utility you are using. For more information, 

see “BRMS/400 Integration” on page 322. 

Save Archives to Tape (ISAVARC) Command Parameters 

Tape Device 

Specify the name of the tape device to use for the save operation. 

Archive library 


Specify the name of the library that contains the archived objects. If multiple 

environments share an archive library, this allows you to save in a single operation all 

objects for all environments that use the library. 

Specify *ALL to save the objects from all archive libraries. This option allows you to save 

all objects in all archive libraries for all environments. 

Specify *ENV to save the objects for a particular environment. If multiple environments 

share an archive library, it saves only the objects for that environment rather than the 

entire contents of the library. This option requires a value in the following Archive 

environment field. 

Archive environment 

Specify the name of the environment associated with the archived objects. This saves the 

archived objects only, not the entire archive library. 

From date 

Specify a date (in YY/MM/DD format) to include all objects archived on or after the date. 

To date 

Specify a date (in YY/MM/DD format) to include all objects archived on or before the date. 

NOTE The From date and To date fields allow you to include objects that were 

changed on, before, after, or within the dates specified. Use the fields separately, or 

in combination to process a date range selection. The default value for each field is 

blank, which bypasses date filtering. 

381


382 

Density 

Specify the density of the tape. The default value is *DEVTYPE. 

Target release 

Specify the release level of the operating system for the saved objects. The default value is 

*CURRENT. 

Initialize tape 

Specify whether to initialize the tape before the save operation. If you specify *NO and the 

tape has the wrong volume ID, a message notifies you that the volume ID does not match. 

You must correct the error before continuing. 

Submit 

The default value *YES submits the job to batch processing. Specify *NO to process the job 

interactively. 


The default values *PRODUCT/*LIBL assign the default job queue defined in System 

Control Maintenance. Change the values as needed. 


Specify the standard OS/400 submit job value as needed. 

To restore an archive from tape 

1 From the Archives to Tape menu, select option 2, Restore Archives from Tape, or issue 

the IRSTARC command to display the Restore Archives from Tape (IRSTARC) command 

parameters. 

2 Specify the IRSTARC command parameters as described next, and press ENTER. 

TIP Review the archive reports described in the next section to easily locate the 

requests to restore. 

Restore Archives from Tape (IRSTARC) Command Parameters 

Request Number 

Specify the request number to restore, or specify *ALL to restore all requests on the tape for 

the specified environment.

Environment 


Specify an environment to restore the recovered members/objects into. Archives restore into 

the same archive library they were saved from. 

Tape Device 

Specify the name of the device you are using to restore the tape. 

Submit 

Archive Reports 

The default value *YES submits the job to batch processing. Specify *NO to process the job 

interactively. 


The default values *PRODUCT/*LIBL uses the default job queue defined in System Control 

Maintenance. Change the values as needed. 


Specify the standard OS/400 submit job value as needed. 

IMPORTANT If you previously saved and cleared archive libraries, the Implementer 

files that manage the archives still reflect the object in the archive library, when 

actually, it is not. For this reason, a cleared object may still appear on the archive 

report, but any attempt to recover the cleared object fails since the object is not 

actually on the tape. To recover the remaining items on the request, use the IBM 

Data File Utility (DFU) command to remove the record that refers to the archive that 

was deleted from the Implementer archive file (IMARTP). 

Implementer provides report queries to help you manage tape archives. The following 

reports are available on the Archives to Tape menu: 

Archives per Tape Report 

Archives by Request Report 

Archives by Environment Report 

Select any of the respective menu options to prompt the query. Standard query record 

selection allows you to limit the reports to a specific tape, promotion request, or environment 

of interest. You have the option to view information online or print the report. 

383


Clearing Remote QA Environments 

384 

When you promote from a host and a remote QA environment to a production environment 

on a single request, Implementer retains a copy of the source and objects in the remote QA 

environment. By default, Implementer does not delete items from remote environments. 

For situations when this is not the desired result, Implementer provides a feature that allows 

you to delete the items in a remote QA environment after successful promotion from the 

environment. This is beneficial when QA and production environments exist on both the host 

and remote systems, and you want to automatically delete source and objects from the 

remote QA environments. For example, a promotion request created on a host system targets 

both local and remote QA environments. After successful QA testing, a new request created 

from the host QA environment targets both host and remote production. As part of the final 

move processing for the request, a special command you define runs based on your 

specifications and deletes the source and objects from the remote QA environment. 

NOTE This feature is available for AllFusion 2E environments by setting up the 

special command as described in this section. You must also set the Implementer 

data area values for IMDLTFRMUP and IMDLTFRMUS to ‘YES’. For details, see 

“Implementer Data Areas” on page 402. 


Define the remote QAC environment with the Remove obj in from lib/env field and the 

Remove src in from lib/env field set to 1 (Always). For details, see the environment field 

descriptions on page 131. 

Define a special command for the remote environment to run for all promotion requests 

that target the environment. The special command automatically runs after the move 

completes, when the source and objects are in the target libraries. 

Add the Implementer Receiver library to the library list of the remote environment to 

support processing the special command. 

Define the object codes, or enable environment object code overrides for the remote QA 

environments. For details, see “Removing Source and Objects After Promotion” on 

page 92. 


1 From the Work with Environments panel, select the remote production environment 

with option 19=Special commands, and press ENTER. 

2 Press F6=Add.

3 Complete the following fields and press ENTER. 

To modify the remote production environment library list 

User Capability Wizard 

1 From the Work with Environments panel, select the remote environment with option 

2=Change and press ENTER. 

2 Press F13=Library List to display the Edit Environment Library List - Remote panel. 


In the Sequence Number field, specify the next sequence number. 

In the Library field, specify the name of the Implementer Receiver library. The 

default product library for the Implementer Receiver is MKSIR. If you changed the 

library name when you installed the Implementer Receiver, substitute your changed 

name for the default name. 

4 Press ENTER to update the list. 


Environment (remote environment name) 

For Action 4 (Move) 

When to do 5 (After move-ok) 

Command IRMVFRMOBJ 


TRGENV(#TRGENV) 

FRMENV(REMOTE_QA_ENVIRONMENT) 

The Capability Wizard is a graphical user interface (GUI) tool designed to minimize the setup 

and maintenance of user authorities in Implementer. It allows you to rapidly reflect new 

business rules quickly, by changing the capabilities of multiple users or environments with a 

single action. 

The administrator, or anyone responsible for working with user authorities in Implementer, 

can benefit from using this time saving application tool. The major advantage to using the 

Capability Wizard over the Work with Users function is that it allows you to process 

concurrent changes to the capabilities for multiple users and environments. 

The Capability Wizard requires adding new users through the Work with Users function, as 

well as adding new environments through Work with Environments function, both 

accessible from the Implementer Menu. You can create the initial records with the minimum 

requirements, and use the time-efficient Capability Wizard to complete the setup and 

perform ongoing maintenance. 

385


386 

The Capability Wizard is delivered with Implementer. In addition to the requirements for 

Implementer, this feature requires: 

Windows 

Java Virtual Machine 1.1 (provided) 

TCP/IP connection to the iSeries 

Installing on Windows 

The Capability Wizard requires Java Runtime Environment (JRE) 1.1.5, or later. This is 

included with the installation program. The installation process searches for the existing JRE 

on the target PC and if it is not located, installation of the JRE is performed before the 

Capability Wizard installation. The installation requires you: 

Verify TCP/IP connectivity. 

Download the self-extracting executable capwiz.exe. 

Run the Capability Wizard install program capwiz.exe and follow the instructions that 

display in the setup procedure. 

Verify the user profile. The user profile you use must have *CHANGE rights to the 

Implementer file IMUSEN, and *USE rights to files MWIPF200 and MWIPF300. By 

default, only QSECOFR and MWIPROD profiles have these rights. 

Verifying TCP/IP Connectivity 

The Capability Wizard requires an active TCP/IP connection to the iSeries system where the 

Implementer database is located. If you cannot communicate with the OS/400 server 

successfully, the Capability Wizard cannot properly connect to the iSeries to perform the 

database updates. 

Ping is an MS-DOS program that allows you to verify that a particular Internet Protocol (IP) 

address exists and can accept requests. Ping is used diagnostically to verify that the host 

computer you are trying to reach has communications enabled and is operating. To verify 

your TCP/IP connection, you can either ping the system or ping the iSeries servers (requires 

ClientAccess installed on the local PC) as described next. If ping is unsuccessful, contact your 

system administrator. 

To ping the OS/400 servers 

1 From a command prompt, type cd.. and press ENTER to display the root directory c:/.

2 Type CWBPING (system_name) and press ENTER. 

where system name is the name of the system you are attempting to ping. 


You may see polling of multiple OS/400 servers. A message confirms the status: Either 

ping of the specified server was successful, or a time out occurred without locating the 

server. 

To ping the system 

1 At a command prompt, type cd.. and press ENTER to display the root directory c:/. 

2 Type PING (system_name) and press ENTER. 

A message confirms the status: Either ping of the specified server was successful, or a 

time out occurred without locating the server. 

Installing on the Desktop 

You have two options for downloading and installing the JRE and Capability Wizard from 

the iSeries onto your PC. The method you choose is simply a matter of preference. 

Map Network Drive copies data by sector and may take longer than the FTP method, 

depending on the speed of your PC. 

FTP (File Transfer Protocol) performs a bulk data transfer. It is quicker than the map 

drive method, but involves more steps. 

The default installation directory is C:/MKS/Implementer/Capability Wizard. You can 

select a different directory if necessary. 

During installation of the Capability Wizard, you may be prompted to install the Java 

Runtime Environment if not already installed. 

To install the Capability Wizard using the Map Network Drive method 

1 Open Windows Explorer and click Tools > Map Network Drive. A Map Network Drive 

dialog box displays prompting for a drive and path name. 

2 Select the drive name to use or accept the default value. 

3 For the path, type: 

//Your_System_Name/MKS/Implementer/MKSIM 

NOTE The default product library name is MKSIM. If you changed the product 


4 Make sure the Reconnect at Logon box is disabled and click OK. You may be prompted 

for a user ID and password to connect to the system. 

387


388 


6 Double click capwiz.exe. 

7 Follow the installation instructions presented on the screens. When you complete the 

installation, you can begin using the Capability Wizard. 

To install the Capability Wizard using the FTP method 

1 At a command prompt, type FTP and press ENTER to display an ftp> prompt. 

2 Type OPEN your_system_name and press ENTER. A message confirms, "Connected to 

your_system_name". 

3 A prompt displays requesting a user. Type a valid user ID for the system you opened in 

step 2, and press ENTER. 

4 A prompt displays requesting the password for the user ID specified in step 3. Type the 

password and press ENTER. 

5 Type bin and press ENTER. A message confirms "Representation type is binary 

IMAGE". 

6 Type quote site namefmt 1 and press ENTER. A message confirms you are using 

naming format "1". 

7 Type cd /MKS/Implementer/MKSIM and press ENTER. A message confirms, "Current 

directory changed to /mks/Implementer/MKSIM". 

NOTE The default product library name is MKSIM. If you changed the product 


8 Type lcd c:/temp and press ENTER. A message confirms, "Local directory now 

c:/temp". (You may need to create this directory if it does not exist.) 

9 Type get capwiz.exe and press ENTER. The self-extracting installation executable 

transfers to your PC into directory c:/temp. 

10 Type quit and press ENTER to display the c:/ prompt. 

11 Type cd c:/temp and press ENTER. 

12 Type capwiz.exe and press ENTER. 

13 Follow the installation instructions presented on the screens. When you complete the 

installation, you can begin using the Capability Wizard. 

Using the Capability Wizard 

The Capability Wizard allows you to authorize Implementer users to perform specific 

functions in the environments they work with.


The Capability Wizard prompts you to sign on to the iSeries. Your user profile must be set up 

in Implementer and have authority to user profile maintenance and environment 

maintenance. 

NOTE Instructions on using this utility are also in file Readme.txt installed with 

the Capability Wizard. 

To start the Capability Wizard 

1 From your Windows desktop, click 

Start > Programs > MKS Implementer > Capability Wizard. 

A command prompt window displays to inform you the program is starting, followed 

by the User Capability Wizard Welcome dialog box. Click the following command 

buttons to perform an action: 

Previous allows you to return to the previous panel. 

Next allows you to process current selections and display the next window. 

Cancel allows you to close the Capability Wizard. 

2 Follow the steps on the Welcome dialog box and click Next. The System Configuration 

dialog box displays. 

389


390 

The status bar currently indicates you are not connected. 

IMPORTANT The user profile you sign on with must have *CHANGE rights to the 

Implementer file IMUSEN, and *USE rights to files MWIPF200 and MWIPF300. By 

default, only QSECOFR and MWIPROD profiles have these rights. For more 

information, see “Verifying TCP/IP Connectivity” on page 386. 

3 In the System name field, type the name of the iSeries or the IP address of the system you 

are connecting to. 

4 In the User ID, Password, and Library fields, specify the user ID, password, and installed 

Implementer library name (if other than the default product library name MKSIM). 

5 Click Next. The Enrolled Users list displays. 

If the Wizard is unable to connect to the specified system, the status indicates that an 

error has occurred. You can review the error details in the files CapWiz Output.txt 

and Error Log.txt. 

If this process locks up, press CTRL + ALT + DEL and use the Task Manager to end the 

Capability Wizard function. If the first attempt to connect fails, it may be necessary to 

close and restart the Wizard. 

Selecting Enrolled Users 

The Enrolled Users list displays all enrolled users. You can select all users, a combination of 

multiple users, or a specific user. 

NOTE To enroll new users you must use the Work with Users function. For details, 

see “Users” on page 72.

To select users 

1 In the Enrolled Users list, click a user. 


To select a block of users, click the first user and while pressing SHIFT, click the last 

user. To omit selective users, press CTRL and click the user. 

To select multiple users, press CTRL and click each user. 

To select all enrolled users, enable the Select ALL users option. To omit selective 

users, press CTRL and click the user. 

2 Click Next. The Environment list displays. 

Selecting Environments 

The Environment list displays the environments that users work in. 

You can use a variety of selection criteria to limit the view of environments. For example, you 

can select all environments, or any combination of development, QA, and production 

environments. 

You may want to filter by environment type. For example, you can select just development or 

production environments, or all development and all QA environments. 

391


392 

To select an environment 

1 In the Environment list, click an environment. To select by environment type, enable the 

Environment types check box for the type of environments you want to view. 

To select a block of environments, click the first environment, and while pressing 

SHIFT, click the last environment. To omit selective environments, press CTRL and 

click the environments. 

To select multiple environments, press CTRL and click each environment. 

To select all environments, enable the Select ALL Environments option. To omit 

selective environments, press CTRL and click the environment. 

2 Click Next. The Authority list displays, filtered by the specified environment type.

User Capability Details 


The authority types that display in the list are based on predefined templates that define 

the typical user groups associated with Implementer. You cannot change the standard 

authorities of these templates. To modify the standard values, see the Readme.txt in the 

installation directory. For information on authority types, see “Understanding 


The Custom authority allows you to override the standard defaults for any user. For 

information on this option, see “Customizing User Capabilities” on page 394. 

Click Detail to display the Capability Details list to view the authorities and options 

defined for each authority type. For details, see “User Capability Details” in the next 

section. 

Click Next to define this user with the standard rights and authorities associated 

with the selected authority type. 

The Confirm Selections dialog box displays. Proceed with “Updating the 

Implementer Database” on page 395. 

The Authority list allows you to define the functions a user type is allowed to access. You can 

view the authority details for any enrolled user. For a description of each capability, see 

“Environments and User Capabilities” on page 109. 

To view capability details for a user 

1 Click an authority and then click Detail. 

The Capability Details list displays the standard capabilities for a specified authority 

type, by environment type. Use the scroll bar to view the capabilities settings. The only 

authority type you can modify is Custom Capability Group. 

393


394 

2 Click OK. The Authority Templates list displays. 

You can work with additional authority types or proceed with updating the 

Implementer database. 

To update the Implementer database 

1 Click OK. The Confirm Selections dialog box displays. 

2 Proceed with “Updating the Implementer Database” on page 395. 

Customizing User Capabilities 

You can use the custom capability group to modify a user’s standard capabilities and 

authorities. This is the only capability group that allows changes. The value in the Allowed 

field controls the allowed capabilities. 

To customize user capabilities 

1 Select the CUSTOM Authority type. 

2 Click Details. 

3 For the environment type and capability you are changing, double click the value in the 

Allowed field to display the list of allowed values. 

4 Click the value you want to define. Valid options are: 

Y (allowed) 

N (not allowed) 

(this is the default value)

5 Click OK. The Authority list displays. 

6 Click Next. The Confirm Selections dialog box displays. 

Updating the Implementer Database 


The Capability Wizard uses TCP/IP to perform SQL updates to Implementer. When you are 

ready to update the Implementer database, you can either process the update and return to 

continue processing additional updates, or process the update and exit the Capability 

Wizard. 

On the Confirm Selections dialog box, the Status bar indicates pending Implementer updates 

exist. The Status bar confirms either the number of records selected for production 

environment update, or that no production environments were selected to update. 

395


396 

To confirm your selections and update the Implementer database 

1 (Optional) Enable the Repeat option to continue with additional updates without exiting 

the application. 

2 Click Finish. The Successful Update message box displays. 

3 Click OK. 

If you enabled the Repeat option, the Enrolled Users list displays; otherwise, the 

application closes. 

Deleting Tutorial Information 

Implementer includes demonstration data to help new users learn to use the software and 

help experienced users to use new features. If you selected to install demonstration data 

when you installed Implementer, you can delete the tutorial data when it is no longer 

needed. 

To delete tutorial information 

1 Delete the tutorial libraries. For a list of these libraries, see Appendix A of the 

MKS Implementer 2006 Installation Guide. 

2 From the Workbench, delete the locks for the member/objects associated with tutorial 

environments. For details, see “Deleting a Lock” in the MKS Implementer 2006 User Guide. 

3 To remove the historical data, from Work with Environments, use option 32, Purge 

History. 

CAUTION Purge history removes the history of completed requests and locks for an 

environment based on dates you specify. If you are using Implementer for change 

management in production (not just for training), performing this function may 

result in the removal of that data. For details, see “Purging Environment History” on 

page 374. 

4 Delete the demonstration environments by using Implementer Menu option 42, 

Environments. For details, see “Deleting an Environment” on page 96.

Function Key Administration 


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 Menu or Implementer Receiver 

Menu, or add commonly used commands to a function key. 

To work with function keys 

1 From the Implementer Menu, select option 50, Function Keys, and press ENTER. The 

Work with Function Keys Panel Select panel displays. 

From the Implementer Receiver menu, select option 9, Function Keys, and press ENTER. 

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. For a description of the fields 

on this panel, see “Key Select Maintenance Field Descriptions”. 

Use option 1=Change to change function keys, or option 8=Refresh overridden global 

function keys. If the global column displays O (indicating a global function key with 

specific overrides for the panel), option 8 resets the function key to its original global 

values and causes Y to display in the global column. This option is available on all panels 

except the *ALL (global) panel. Use option 9=Delete to delete function keys. 

To change a function key 

1 From the Work with Function Keys - Key Select panel, select the key to change with 

option 1=Change, and press ENTER. The Work with Function Keys - Key Maint panel 

displays. 

2 Complete the fields on this panel as defined in the following table, and press ENTER to 

process the changes. 

397


398 


Key Select Maintenance Field Descriptions 

Panel ID Identifies the panel that function keys are defined for. This value displays in 

the upper left-hand corner of the product panels. 

Panel width Specifies the width of the panel. 

Nbr of lines Specifies how many lines display on the panel. 

Key Number assigned to the function key. 

0: ENTER 

1–24: Function keys 1 through 24 

25: ROLL UP 

26: ROLL DOWN 

27: HELP 

28: HOME 

29: CLEAR 

100+: Document-only function keys. Allows you to document and display 

on panels some of the commonly used keys on your keyboard. You can 

number document-only function keys from 100–999. These keys do not 

process, rather they document available keys that process 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. 

Key name Derived from the function key prefix and number (not maintainable 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 Text to display on the panel, following the separator for the function key. For 

example, for F8=Spool Files the function key text is Spool Files. 

Valid Indicates whether the function key is valid on this panel. 

Y: The function key is valid. 

N: The function key is not valid. Invalid function keys do not display, for 

example, ROLL UP on a panel with only one page. 

Display Defines whether the function key displays on the panel, if valid. The value 

for this entry is used only if the function key is valid. 

Y: The function key displays. 

N: The function key does not display. If the Valid field is set to Y, the 

function key remains valid, for example, the ENTER key.



Global Defines whether the function key is a global key (defined to the *ALL panel) 

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. The function key is defined globally, but 

one of the attributes is redefined on this panel. 

Action/Command This entry can be an action or a command as follows: 

Actions are prefaced by an asterisk (*); commands are not. 

If the entry contains an action, the action returns to the program processing 

the panel. You cannot maintain actions. 

If the entry contains a command, the command runs when you press the 

function key. You can maintain a command by typing 1 in the selection entry 

and pressing ENTER. 

399


400

A PPENDIX A 

Implementer Data Areas and 

User Exit Programs 

Customizing Implementer 

A 

The additional features described in this appendix allow you to further customize your 

Implementer database. 

This appendix covers the following topics: 

“Implementer Data Areas” on page 402 

“Customizing Implementer” on page 414 

401

Appendix A: Implementer Data Areas and User Exit Programs 

Implementer Data Areas 

402 

Implementer has numerous data areas that control various features and functions within the 

product. You can modify the data area values to further customize your Implementer 

database. 

The data areas are located on either the host system or the remote system, although some 

data areas exist on both systems as noted. On the Implementer host system the data areas are 

located in the default product library MKSIM. On the Implementer Receiver the data areas 

are located in the default product library MKSIR. 

To change the data areas, sign on to the iSeries with the Implementer user profile MWIPROD, 

or a user profile with *ALLOBJ special rights, and use the standard OS/400 Change Data 

Area (CHGDTAARA) command. 

IMPORTANT The data areas described are those that you can safely change. You 

should not change other data areas in the Implementer library. 

Add Related Objects for Service Programs (IMADDOBJ) 

The IMADDOBJ data area allows you to control how Implementer handles objects related to 

service programs during related object processing. This prevents the unnecessary recompile 

of objects that use service programs when modules are changed but the signature does not 

change. 

Valid values for the data area are *YES (default value) and *NO. Set the value to *NO to 

activate this feature and bypass recompiling objects related to service programs. 

Archive to Tape Libraries (IMARCTAP) 

The IMARCTAP data area contains the name of two temporary libraries used by the archive 

to tape function. The default data area value is IMARCTAP1 in positions 1 through 10, and 

IMARCTAP2 in positions 11 through 20, enclosed in single quotes, for example, ‘IMARCTAP1 

IMARCTAP2’. 

CAUTION Implementer deletes and recreates the libraries in this data area as needed, 

for example, when submitting the archive to tape. Thus, if you change the default 

library names stored in IMARCTAP, you must specify libraries that do not exist or 

are not needed elsewhere on your system. 

Bind Update (IMBNDUPD) 

The IMBNDUPD data area allows you to bypass the PathFinder update for ILE programs. 

Valid values are *YES or *NO (default value) enclosed in single quotes. Set the value to 

‘*YES’ to activate this feature.

Communications User Profile (IMCMNUSR) 


The IMCMNUSR data area contains the user profile and password Implementer uses to 

initiate communications to a remote system when distributing changes to the remote system. 

The data area is located on both the host system and the Implementer Receiver. 

The default value is MWIPROD in positions 1 through 10 (user profile name), and MWIPROD 

(password) in positions 11 through 20. You must enclose the values in single quotes that 

encompass the entire 20-character field, for example, ‘MWIPROD MWIPROD ’. 

If the data area value is blank, a user profile is not available for Implementer to initiate 

communications with the remote. In this case the user profile is derived by retrieving the 

communication entries defined in the communication subsystem on the remote system. 

Check Out/Reject Options (IMCOREJ) 

The IMCOREJ data area pertains to checking out and rejecting changes from QA, when the 

member/object being checked out already exists in the target check out location. By default, a 

message window displays to notify you the member/object exists in the target location, and 

you are required to select a copy option to proceed. The data area allows you to bypass the 

display of the message window and automatically default the copy option. 

The data area value allows four character positions. Positions 1 and 2 relate to checking out. 

Positions 3 and 4 relate to rejecting from QA. The default value is NSNS, which prompts the 

display of the window and requires selecting a copy from option. The data area layout and 

allowed values are as follows. 

Position Description Valid Values 

1 Controls display of the “Mbr/Obj 

Already Exists” window in check out. 

2 Allows you to set the default copy 

option when position 1 is set to Y. 

3 Controls display of the “Mbr/Obj 

Already Exists” window when 

rejecting from QA. 

4 Allows you to set the default copy 

option when position 3 is set to Y. 

Y = Does not display the window. 

N = Displays the window to allow selection of a 

copy option. 

S = Skip. 

R = Replace. 

X = Replace All. 

K = Keep Existing. 

A = Keep All Existing. 

Y = Does not display the window. 

N = Displays the window to allow selection of a 

copy option. 

S = Skip. 

R = Replace. 

X = Replace All. 

K = Keep Existing. 

A = Keep All Existing. 

403


404 

Delete User Programs and User Source During Promotion 

(IMDLTFRMUP and IMDLTFRMUS) 

For AllFusion 2E CM users, the IMDLTFRMUP and IMDLTFRMUS data areas allow you to 

control whether to remove user programs (IMDLTFRMUP) and user source (IMDLTFRMUS) 

in the from library after successful promotion. You can delete programs and display files 

without removing database files from development or test libraries to retain test data. 

The data areas exist on both the host and remote system. On the remote, the data areas 

control whether user programs and user source are removed from the remote QA 

environment during promotion to the remote. This is beneficial when both QA and 

production environments exist on both the host and remote systems. 

Valid values for the data areas are *YES or *NO enclosed in single quotes. The default value is 

‘*YES’. The value *NO overrides the value specified on a promotion request. 

NOTE 

If using these data areas to enable Implementer’s remote QA environment 

cleanup feature, you must also set up a special command to run as part of the 

promotion. For details, see “Clearing Remote QA Environments” on page 384. 

For traditional member/objects and IFS objects, this functionality is available 

using object code overrides. For details, see “Object Code Overrides” on page 91. 

Delete Locks (IMDLTLOCK) 

The IMDLTLOCK data area allows you to set default values on the Confirm Delete of Locks 

panel that displays when you select a member/object with option 4=Delete from the 

Workbench. 

You can specify different values for the deletion of locks, source, and objects. The valid data 

area values are *YES or *NO. The default value *YES sets the value to Y for all options. The 

value *NO sets the value to N for all options. 

You can also specify a three-character string consisting of a combination of Y and N to 

individually set each value. For example, if IMDLTLOCK is set to YYN, the result is Delete 

locks = Y, Delete sources = Y, Delete objects = N. If IMDLTLOCK is set to NYN, the result is 

Delete locks = N, Delete sources = Y, Delete objects = N. 

NOTE Users must have lock maintenance rights set to Y in the environment for 

authority to override these defaults. This is defined in Work with Environments, 

User Capabilities. 

Delay Evoked Jobs (IMDLYJOB) 

The IMDLYJOB data area allows you to place an evoked job into a delay state once the job 

becomes active. Working with remote jobs can be difficult, as a batch job on one machine 

initiates the job on another machine. Developers typically use this feature to capture specific


diagnostic information at a customer site for debugging or tracing a job. It is also used when 

changes are required to a remote job, or to examine characteristics of a job before it begins to 

implement changes. 

The data area is located on both the host system and the remote system.Valid values are *YES 

or *NO enclosed in single quotes. The default value ‘*NO’ allows the job to continue 

normally without delay. The value *YES immediately places the evoked job into a delay state 

upon going active and sends a message to the QSYSOPR message queue stating that the job is 

in delay status. The job delays for one minute before going active again. It delays another 

minute and repeats indefinitely until you change the data area value to *NO. 

Domino Server Data Directory (IMDOMDATA) 

The IMDOMDATA data area allows you to record the server data directory that Implementer 

uses to call the Domino API. This is only required when using Domino 6.0 and the Domino 

server does not use the Domino 5 default data directory /notes/data. 

The data area value is blank by default. If necessary, change the value to the actual Domino 

data directory being used. 

NOTE For details on the Implementer and Lotus Domino integration, see “Lotus 

Domino Integration” on page 336. 

Display Message Panel (IMDSPMSG) 

The IMDSPMSG data area is used in Work with Objects to control the display of a message 

when filtering the subfile using only the Object Status field. 

The valid data area values are *YES or *NO enclosed in single quotes. The default value 

‘*YES’ displays a message explaining that filtering on object status only can be time 

consuming. The message allows you to continue with the selected filter, or return to specify 

additional filters. The value *NO bypasses the message altogether. 

Emergency Request Submit Through Step (IMEMGSTP) 

The IMEMGSTP data area allows you to redefine the default auto submit through step for 

emergency promotion requests. 

The valid numeric values for IMEMGSTP are 2 (compile), 3 (distribute), or 4 (move), enclosed 

in single quotes. The default value is ‘4’. 

FTP Passive Mode (IMFTPPASV) 

The IMFTPPASV data area allows you to control how Implementer’s FTP transfer uses 

passive mode when sending files using TCP/IP. Passive mode eliminates the requirement on 

the receiving system to open a dedicated port for the host to connect to. 

405


406 

The data area is located on both the host system and the remote system. Valid values are 

*YES or *NO enclosed in quotes. The default value “*YES” uses passive mode. Set the value 

to “*NO” to use non passive mode. 

IMPORTANT Most users do not change this data area. You should change the value 

only if your network configuration requires FTP transfers using non passive mode. 

JDK Version (IMJDKVER) 

The IMJDKVER data area relates to using MKS Integrity for issue management with 

Implementer. The data area allows you to store the Java Development Kit (JDK) version to 

use when using the Update MKS Integrity (IUPDCI) command to update MKS Integrity on 

an AIX system. This is required only if the target MKS Integrity Server runs on an AIX system 

(JDK version 1.4 is required on the client for communications). 

The default data area value is ‘1.2’ enclosed in single quotes. To use the IUPDCI command 

on an AIX system, you must install JDK version 1.4 on the iSeries, and change the IMJDKVER 

data area value to ‘1.4’. On OS/400 V5R2, you can install JDK version 1.4 from the IBM 

license product installation CD. On OS/400 V5R1, install JDK version 1.4 by ordering the 

required PTFs from IBM. 

NOTE For details on using MKS Integrity with Implementer, see “Implementer and 

MKS Integrity Integration” on page 196. 

Implementer Library Name (IMLIBRARY) 

The IMLIBRARY data area contains the name of the Implementer product library. It is a 10character 

data area. You must enclose the value in single quotes. The default value is 

‘MKSIM’. 

Change the data area value if you rename the Implementer library after initial installation, or 

if you require a parallel installation of the product (two versions of Implementer on the same 

system). When you install Implementer with a name other than MKSIM, the data area value 

is appropriately set by the installation procedure. 

NOTE If you have Implementer enabled for AllFusion 2E, (you received the 

Implementer product from Computer Associates), the default product library is 

Y2SYCM. When Implementer is installed with a name other thanY2SYCM, the 

installation procedure appropriately sets the data area value. 

Log Evoked Programs (IMLOGCL) 

The IMLOGCL data area allows you to change the logging level on Implementer-evoked 

jobs. The data area is located on both the host system and the remote system. It is useful 

when a unique job description is not available for Implementer on the remote system, and 

changing the logging level is not possible without impacting other users on the system.


This value affects jobs evoked on the host after a remote initiated move is submitted on the 

remote. The valid data area values are *YES or *NO enclosed in single quotes. The default 

value ‘*NO’ allows logging as currently defined. The value *YES changes the job to log CL 

instructions with the maximum message logging level 4 0 *SECLVL. This ensures logging of 

all messages and retains the job log upon job termination. 

Submit Multiple Jobs (IMMULTJOB) 

The IMMULTJOB data area allows you to submit multiple jobs when submitting promotion 

requests. Valid values for the data area are *YES or *NO enclosed in single quotes. The 

default value ‘*YES’ allows the submission of multiple jobs. The value *NO does not submit 

multiple jobs. 

Once a promotion request is submitted Implementer determines whether the request was 

submitted to multiple jobs or a single job. This requires: 

The Add related objs to request field set to N (in Work with Environments) for all target 

environments on the request. 

The Compile required field set to N (in Work with Environments) for all target 

environments on the request. If Compile required=Y, the compile phase must be 

complete. 

For requests that target multiple environments or an environment group, you cannot use 

the Move Request by System/Environment option to override the request and submit 

the move on a per-environment basis. 

For requests that target a specific system, you cannot use the Move Request by System/ 

Environment options 10=Distribute all, 11=Move all, or 12=Distribute and move all, to 

submit the distribution or move. 

Multiple Object Single Source Check Out (IMMULTOBJ) 

The IMMULTOBJ data area allows you to check out multiple objects that have single source 

members, allowing the single source member to create multiple objects. This practice, most 

common with physical files, works for all source-based objects. 

The valid values for the data area are *YES or *NO enclosed in single quotes. The default 

value ‘*NO’ does not allow checking out an object that has multiple objects with the same 

source member. Set the value to *YES to allow checking out an object that has multiple objects 

with a single source member. 

IMPORTANT Checking out a single source member with multiple objects is not 

considered a concurrent development condition. Therefore, if you enable 

IMMULTOBJ, be aware you could easily overwrite changes to work in process— 

that is, objects checked out and changed but not promoted through to production. 

407


408 

Allow Member/Object on Multiple Requests (IMMULTRQS) 

The IMMULTRQS data area controls whether a member/object is allowed on multiple open 

promotion requests concurrently. 

Valid values for the data area are *NO or *YES enclosed in single quotes. The default value 

‘*NO’ does not allow an item on multiple promotion requests. Set the value to *YES to allow 

an item on multiple promotion requests. 

LANSA Error Messages (IMLNMSG) 

The IMLNMSG data area allows you to store the message IDs of LANSA errors you want to 

force a request to fail on when the error occurs during promotion processing. Fatal messages 

automatically cause the promotion to fail. During promotion, Implementer compares the 

message IDs written in the spool file of the export list to the message IDs recorded in the 

IMLNMSG data area. When a match is established, processing of the promotion job ends. 

This default data area value is blank. To store multiple messages IDs, separate the message 

IDs with a blank space. 

LANSA Partition Security Officer (IMLNPSO) 

The IMLNPSO data area allows you to store the name of the LANSA partition security 

officer. Implementer runs the LANSA command for export/import using the partition 

security officer profile to prevent migration failures caused by insufficient authority to the 

LANSA command and the items being exported. 

The data area is located on both the host system and the remote system and must be set on 

each system. The default data area value is blank. To change the data area, specify the 

partition security officer name in positions 1 through 10. 

LANSA Task Usage (IMLNTSK) 

The IMLNTSK data area allows you to enable LANSA task tracking in Implementer. Task 

tracking allows Implementer to process LANSA tasks as project numbers by creating an 

Implementer project record from the specified task number (if it does not already exist). 

The default data area value is *NO. Set the value to *YES to enable task tracking and for 

integration with Visual LANSA. For details, see “LANSA Task Tracking” on page 332 and 

“Visual LANSA” on page 332. 

Creation Commands That Allow the TGTRLS Parameter (IMPRVCMDS) 

The IMPRVCMDS data area allows you to store a list of creation commands that accept the 

Target Release (TGTRLS) parameter to perform local compiles for a remote environment. 

You can add other creation commands to the data area, although you do not need to change 

it often. For example, adding a command can be required if a new object is created by an 

upgrade to the operating system and you do not have the required version of Implementer.

Path Slash (IMPATHSLSH) 


The IMPATHSLSH data area is used for the development of IFS and DLO objects on a non 

English system. IFS and DLO objects have a backward slash (\) in the object path; however, 

the actual backward slash character is not the same character for all languages. The data area 

allows you to specify the translated character to substitute for the backward slash. The 

default data area value is ‘\’. 

Process Package (IMPKGPRC) 

The IMPKGPRC data area is used with the release management features of Implementer. It 

allows you to define how to handle a package creation job if an error occurs with member/ 

objects when creating the package. Valid values are as follows: 

Blank Terminates the package creation job and deletes the package. 

*FAILEND Processes the job through to the end, ends in failure, and deletes 

package. Messages are sent of member/object errors. 

*PROCESS Processes all member/objects but does not add member/objects with 

errors. Messages are sent of skipped members/objects. 

Work Library Prefix (IMPRFX) 

The IMPRFX data area contains the prefix assigned to the name of all Implementer work 

libraries. The data area is located on both the host system and the remote systems. It is three 

characters in length. Most work libraries use all three characters, but some use only the first 

two characters. You must enclose the value in single quotes. The default value is ‘IM’. 

When using two parallel versions of Implementer, you must change the data area so that one 

version of Implementer uses a different prefix of work libraries. You can also change the 

prefix to set the work libraries to follow internal naming conventions. 

Remove Member/Object From QA on Reject (IMREJECT) 

The IMREJECT data area controls how Implementer handles source and objects when 

checking out for reject from a *QAC environment. It allows you to reject member/objects 

from QA and check them back into development on the original lock. The source (for source 

based objects) or object (for non source based objects) is copied back into development from 

QA. The lock is redirected to development for continued programming effort. By requiring 

locks on promotion requests, the items in QA remain for further testing and not promoted to 

the next QA or production environment, while development continues. 

The data area also controls the default value that displays in the Delete Member/Objects field 

on the Delete Member/Objects While Rejecting window when an item is selected for reject. 

The valid data area values area *YES or *NO enclosed in single quotes. The default value 

‘*NO’ sets the field defaults to N and retains member/objects in QA. Set the value to *YES to 

set the field defaults to Y and delete member/objects from QA. 

409


410 

Regardless of the data area value the field values can be overridden during check out. You 

can also set Implementer to bypass the display of the Delete Member/Objects While 

Rejecting window and enforce the rules set by the IMREJECT data area. For details, see 

“Bypass Window on Reject From QA (IMBYPSRJW)” described next. 

Bypass Window on Reject From QA (IMBYPSRJW) 

The IMBYPSRJW data area allows you to control the display of the Delete Member/Objects 

While Rejecting window when rejecting items from a *QAC environment. 

The default data area value *NO enables the window display. Set the value to *YES to bypass 

the window display. For example, if source and object always remains in QA when rejecting 

and developers are not allowed to override the rule, set the IMREJECT data area to *NO, and 

set the IMBYPSRJW data area to *YES. 

Reclaim Group (IMRCLAGRP) 

When exiting the Implementer main menu, the Reclaim Activation Group (RCLACTGRP) 

command automatically executes. If you use activation groups or ASC Sequel, the command 

causes user programs that use activation groups to fail, and causes ASC Sequel to fail after 

Implementer runs and ends in an iSeries session. 

The IMRCLAGRP data area allows you to control execution of the RCLACTGRP command 

when exiting the Implementer main menu. The default data area value is ‘*YES’. Change 

the value to ‘*NO’ to bypass execution of the RCLACTGRP command. 

Return File and Member ID After Promotion (IMRETFILID) 

The IMRETFILID data area allows you to retain existing file and member IDs when 

promoting physical files and logical files. The data area is located on both the host system 

and the remote systems. 

The default value *NO deactivates the feature. Set the value to *YES on both the host and 

remote to retain the file and member IDs on both systems. The file and member IDs are taken 

out of the from file and applied to all target files. If the file exists in the From environment, 

the file and member IDs are derived from that file. If the file does not exist in the From 

environment, the file and member IDs are derived from the object created in the Implementer 

work library. Exceptions to this general rule are: 

When a PF and related LFs do not exist in the From environment and a request is created 

for the PF with the LFs added as related objects, the file and member IDs for the PF come 

from the object created in the Implementer work library, and the file and member IDs for 

the LFs come from the target logical files. 

When targeting a remote environment that has the source library/compile location set to 

R (remote), the compile option must be set to N to retain the file and member IDs.

Sequential Request (IMSEQRQS) 


The IMSEQRQS data area pertains to the processing sequence of promotion requests for 

environments that are not compiled. This does not apply to emergency promotions. By 

default, Implementer processes all compile requests based on a compile date edit. For 

environments with the Compiled Required field set to N, this data area allows you to bypass 

the date edit and process requests sequentially by request number. 

The default data area value *NO allows all requests to process based on the date edit. Change 

the value to *YES to bypass the date edit when not compiling and allow promotions to 

process in request number sequence. 

Special Commands (IMSPCCMD) 

The IMSPCCMD data area contains a list of Implementer commands that are available as 

special commands. The commands can be used as special commands without having the 

Implementer library in the library list of the target environment. All other special commands 

require the Implementer library in the target library list or a qualified library name. Users do 

not maintain this data area. 

NOTE To issue Implementer commands as special commands, the product library 

(MKSIM is the default) must be on the environment library list. For AllFusion 2E, 

the product library (Y2SYCM is the default) must be on the environment library list. 

Save Program Name (IMSVPGM) 

The IMSVPGM data area pertains to the Archive to Tape feature. It allows you to identify a 

third party save/restore utility to a create off-line storage of archived information. For 

example, you can use IBM’s Backup Restore Management System (BRMS) or your own 

version of a save/restore utility. 

This is a 20 character data area: Positions 1 through 10 store the library name associated with 

internal program, and positions 11 through 20 store the name of the internal program. 

This feature also requires defining values to a skeleton program named IMSVLB2 located in 

the Implementer source file QSAMPLE. For detailed information on setting up to use a third 

party save/restore utility, see “BRMS/400 Integration” on page 322. 

Promotion Batch Step Test Mode (IMTSTMOD) 

The IMTSTMOD data area controls when promotion batch steps are performed, and whether 

they run in test mode or real mode. This feature is only useful for testing purposes and used 

under the direction of MKS Customer Care. The data area values are as follows. 

*NO The job continues as normal. This is the default value. 

411


412 

*MSG Activates additional messaging during the batch promotion of a request 

and allows it to run without actually compiling or moving items. Each 

internal phase of the request receives a cryptic start/end message to 

accurately determine the internal phase being processed, helping to 

identify which part of the promotion completed and which part is 

processing when an error occurs. This is useful to identify some 

promotion problems. Customer Care may request you change the setting 

if additional information in needed. 

*YES Do not use without direction from Customer Care. Causes all promotion 

requests to appear as though related processing is complete, but does not 

actually compile or move objects. The job completes successfully and the 

request is set to completed status. When active, there are no messages 

about individual items on the request being compiled or moved, and 

instead of calling the compile or move programs, the program names are 

listed in the job log to show when they would be called. 

Invalid Logical File Control (IMWRNTRGLF) 

The IMWRNTRGLF data area controls how Implementer handles the recompile of logical 

files implicitly added to a promotion request that results in compile fail status, for example, 

due to missing or invalid source. 

The data area is located on both the host and remote systems, but currently only used on the 

remote system. Valid values are as follows. 

*ABT The promotion aborts. This is the default value. 

*DLT Deletes the invalid logical files and generates the Display File Description 

(DSPFD) and Display File Field Description (DSPFFD) reports to allow 

manually recreating the logical files. 

*INQ The promotion pauses and prompts for an action to continue. Valid replies 

are D to delete the logical file and C to cancel the request. 

Next Tape Label (ITAPEVOLUM) 

The ITAPEVOLUM data area controls the next volume ID for archives saved to tape. 

Implementer automatically initializes a tape with volume ID ARC###, where ### is a number 

starting with 001 that increments for each archive saved. The data area does not usually 

require a manual change. 

Reference File to Set Authority (LFREFOBJ, PFREFOBJ) 

The LFREFOBJ and PFREFOBJ data areas control the authority used to promote physical and 

logical files. It is a 20-character data area. Positions 1 through 10 store a file name, and 

positions 11 through 20 store a library name. The file specified is used as the reference object 

when setting authority to PFs and LFs on a promotion. If the data area value is blank, the 

authority to promote PFs and LFs is based on the value specified in the environment 

definition.

Receiver Library Name (RCVLIB) 


The RCVLIB data area on the host system contains the name of the Implementer Receiver 

library for the remote system. It is a 10-character data area enclosed in single quotes. The 

default value is ‘MKSIR’. 

Change the data area value only if you use an Implementer Receiver library name other than 

MKSIR on the remote system, or if you are running two parallel versions of Implementer, 

and Implementer is used to send changes to remote systems. 

NOTE If you have Implementer enabled for AllFusion 2E CM, this data area is in the 

AllFusion 2E host library Y2SYCM and contains the name of the AllFusion 2E CM 

Receiver library on the remote system (the default is Y2SYCR). 

Authorized User of IFS Objects (SDMAUTUSR) 

The SDMAUTUSR data area stores the user profile Implementer uses to manage all objects 

that exist outside of the QSYS library, for example, IFS files and directories. 

The default value is ‘SDMAUTUSR’ (enclosed in single quotes). The user profile is created 

with a random password and the following characteristics: all object special authority, 

enabled status, a current (non expired) password. 

To use a different profile, specify a user profile that has the same characteristics to enable 

Implementer to properly manage objects outside of the QSYS library. Use the Change User 

Profile (CHGUSRPRF) command to set the characteristics as follows: 

CHGUSRPRF USRPRF(name) 

PASSWORD(password) 

STATUS(*ENABLED) 

SPCAUT(*ALLOBJ) 

PWDEXPITV(*NOMAX) 

In addition, the user profile must be enrolled in the system distribution directory by using the 

Work with Directory Entries (WRKDIRE) command. A user ID entry of *ALL is not sufficient. 

IMPORTANT Implementer uses the SDMAUTUSR user profile and password to 

access an NT Server for IFS object management on a mounted drive. For this 

purpose the user profile and password must be identical and the values defined on 

the iSeries must be the same user profile and password defined on the NT Server. 

For details, see “Mounted Drive Support for IFS Objects” on page 159. 

Remote Job Queue (IRJOBQ) 

The IRJOBQ data area contains the name of the remote job queue. It is used along with data 

area IRSBMMTD, which stores the job submission method. The data area is located on the 

remote system in the Implementer Receiver library (default is MKSIR). 

413


414 

This is a 20 character data area. Positions 1 through 10 store the job queue name, and 

positions 11 through 20 store the library name. You must enclose the values in single quotes, 

for example, ‘QBATCH *LIBL ‘. 

Remote Job Submission Method (IRSBMMTD) 

The IRSBMMTD data area contains the submission method for remote jobs. The data area is 

located on the remote system in the Implementer Receiver product library. 

This is a one character data area. Valid values are 0 or 1, enclosed in single quotes, for 

example, ‘1’. 

Work Library Cleanup (IMWLCLNUP) 

The IMWLCLNUP data area is used with the release management features of Implementer 

when using multiple Implementer Receivers on the same iSeries. The data area allows you to 

install the same delivery on each remote system by controlling the deletion of the 

Implementer work libraries used during delivery installation. 

The data area is located on the remote system in the Implementer Receiver library MKSIR. 

The default data area value *YES deletes the work libraries. Set the value to *NO to retain the 

work libraries. Set the value to *NO on each Implementer Receiver, and then change it to 

*YES before installing the last delivery. For more information, see the MKS Implementer 2006 

Release Management Guide. 


Implementer provides the source file QSAMPLE, which is an ever-growing source of 

technical information that helps you to further customize Implementer. The source file is 

located in the Implementer product library MKSIM. 

User Exit Programs 

IMPORTANT Check the latest MKS Implementer Release Notes for release-related 

changes to QSAMPLE that may require recompiling your modified source 

programs. 

The following is a partial list of the user exit programs provided in QSAMPLE. Refer to the 

source in QSAMPLE for more details on these and other user exit programs.

Program Name Description 


IMPRMV3 Allows you to customize the setting of authorities on objects promoted through 


IMCODF Allows you to customize path defaults during check out. 

IMCRDF Allows you to customize path defaults during create request. 

IMCOMO8 Allows you to customize concurrent development processing. To set concurrent 

development to include only the items checked out from the same environment, 

see “Concurrent Development Scope” on page 71. 

IMUPDLCK Allows you to bypass updating the source/object locks on a request after the 

successful move of source/objects to the specified environment. 

When using programs from QSAMPLE, MKS recommends you place them in a library other 

than the Implementer product library, for example, MKSIMMOD, so they are not affected by 

product upgrades. You must add the modified library to the interactive library lists for all 

users, as well as the library list of any batch programs that use the commands. In addition, 

when using a modification library you must change the Implementer commands to remove 

the default product library parameter from all commands (the default product library name 

is MKSIM). 

Edit Library List Command 

The Edit Library List (IEDTLIBL) command allows you to modify the library list of an 

Implementer environment. You must have authority to the environment and standard move 

capabilities for the environment library list you want to modify. 

The command is located in the Implementer product library in source file QSAMPLE. For 

detailed instructions on creating the command, refer to the comments in the IEDTLIBL 

command source in QSAMPLE. 

You prompt the command from a command line, specify the Environment name and 

Implementer library parameters, and press ENTER to retrieve the current library list of the 

specified environment. Libraries can be added to the end or middle of the list (they are added 

in the order entered). 

To add a library to an environment’s library list, type the greater-than character (>) in the 

Control field. 

To remove a library from an environment’s library list, type the less-than character (


416 

IEDTLIBL Command Parameters 

Environment Name 

Specify the name of the environment associated with the library list to modify. 

Implementer Library 

Specify the name of the Implementer product library (default product library is MKSIM). 

Specify another name if you changed the product library name when you installed 


Library List Type 

Specify the system location of the library. Valid values are (L) Local or (R) Remote. The 

default value is L. When setting a local and remote library list for an environment, you must 

create two separate lists. The command does not support both local and remote libraries in 

the same list. 

Library 

Specify the name of the library to add or remove from the list.

A PPENDIX B 

Environment Examples 

A Guide to Setting Up Environments 

B 

This appendix provides setup examples of typical environments for the most common 

development scenarios. Although the examples do not describe all possible settings, they 

may be helpful when initially setting up Implementer. 

The examples illustrate specific environment settings for the following environment 

types: 

“Local Production” on page 418 

“Local Development” on page 419 

“Local Quality Assurance” on page 420 

“Local User Acceptance” on page 422 

“Remote Production” on page 423 

417

Appendix B: Environment Examples 

Local Production 

418 

The following table describes how to define an environment for local production. 


Environment Specify the environment name. It is helpful to design a recognizable 

naming convention, for example, AR_PRD. 

Description Specify a brief description of the environment, for example, Demo 1 

Production. 

Administrator Specify the Implementer administrator profile. 

Env type Specify the type of environment. Valid options are *PRD (production), 

*QAC (quality assurance), and *TST (development). 

Library defaults 

Specify the program library, files library, source library, and archive library names. If the libraries do not 

exist, Implementer automatically creates them when promoting a request to the environment. The 

library owner is the user profile defined in the Lib owner fields. 

Library Owner, 

Object Owner 

Applies to new objects created in Implementer, when you run Reset 

Authorities for an environment. 

Archive Versions Specify the number of archive versions to keep (up to 99 versions). 

Create request defaults: CHG fields 

The Chg field, parallel to the next four fields, controls whether you can change (override) these values 

when creating a promotion request that targets this environment. Specify Y to allow overrides. 

Compile required Yes. Allows auto submit in create request.


Local Development 

The following table describes how to define an environment for local development. 

Local Development 

Auto submit in create rqs Yes. Allows automatic promotion within a request to one of four levels: 

compile, distribute and move, or export (if a LANSA environment). 

Through step 2 (automatically promotes through the compile step). 

Add related objects to rqs Yes (automatically adds related objects to a promotion request) for 

compile purposes. Related environments include all programs related 

to a file, as well as all related ILE components. 

Check out required Yes. Members/objects require check out before adding them to a 

promotion request. You must also check out newly created members/ 

objects, or have the name reserved. 

Allow authority overrides Yes. Allows changing object authority on a promotion request from 

*KEEP to *GRANT. 



naming convention, for example, AR_TST. 

Description Specify a brief description of the environment, for example, 

Developer’s Development Env. 

Administrator Specify the Implementer administrator profile. 

419


Local Quality Assurance 

420 


Env type Specify the type of environment *TST (development), *QAC (quality 

assurance), or *PRD (production). 


Specify the program library, files library, source library, and archive library names. 


Object Owner 



Archive Versions Development usually does not archive versions. 

Create request defaults: CHG field 

Yes. The Chg field, parallel to the next four fields, controls whether you can change the corresponding 

field values when working with this environment. 

Compile required No. 

Auto submit in create rqs No. Does not allow automatic promotion of a request. 

Submit through step Specify a value (1–4) even if the previous step is set to N. 

Add related objects to rqs Yes. Automatically adds related objects to a promotion request. 

Check out required No. Member/objects do not require check out before adding them to a 


Allow authority overrides No. Not allowed to change object authority on a promotion request.

Local Quality Assurance 

The following table describes how to define an environment for local quality assurance. 



naming convention, for example, AR_QAC. 

Description Specify a brief description of the environment, for example, Quality 

Assurance Env. 

Administrator Specify the Implementer administrator user profile. 

Env type Specify the type of environment, *TST (development), *QAC (quality 





Object Owner 






field values when working in this environment. 

Compile required Yes. Members are usually compiled before promoting to a test 

environment. 

Auto submit in create rqs Yes. Allows automatic promotion of a request to 1 of 4 levels: compile, 

distribute and move, or export (if a LANSA environment). 

Submit through step 2 (automatically promotes through the compile step). 




objects. 

Allow authority overrides No. Not allowed to change object authority on a promotion request. 

421


Local User Acceptance 

422 

The following table describes how to define an environment for local user acceptance. 



naming convention, for example, USRACPT. 

Description Specify a description of the environment, for example, User 

Acceptance Env. 

Administrator Specify the Implementer administrator user profile. 

Env type Specify the type of environment, *TST (development), *QAC (quality 





Object Owner 



Archive Versions Specify the number of archive versions to keep (up to 99 versions).


Remote Production 




field values when working with this environment. 


Auto submit in create rqs Yes. Allows automatic promotion of a request to 1 of 4 levels: compile, 

distribute and move, or export (if a LANSA environment). 

Submit through step 2 (automatically promotes through the compile step). 




objects. 


Defining an environment for remote production requires the entry of information in various 

fields across three Work with Environments panels. Press PAGE DOWN to access each panel. 

423


424 

The following table describes how to define an environment for remote production. 



naming convention, for example, RMTSYS1. 

Description Specify a brief description of the environment, for example, Remote 

Production # 1. 

Administrator Specify the Implementer administrator. 

Env type Specify the type of environment, *PRD (production), *QAC (quality 

assurance), or *TST (development). 




Object Owner 





Yes. The Chg field parallel to the next four fields controls whether you can change the corresponding 

field values when working in this environment. 


Auto submit in create rqs Yes. Allows automatic promotion of a promotion request to 1 of 4 

levels: compile, distribute and move, or export if a LANSA 

environment. 

Submit through step 4 (automatically promotes through the Move step). 

Add related objects to rqs Yes. Automatically adds related objects to a promotion request.

Press PAGE DOWN to access the second Create Environment panel. 



Check out required No. Members/objects do not require check out before adding them 

to a promotion request. 


Special environment For a remote environment, this must be a standard LANSA or 

PeopleSoft World environment, not an AllFusion 2E or AS/SET 

environment. 

Issue required for check out Specify whether you require an issue for all check out activity 

(requires MKS Integrity installed for issue tracking). 

When DesignTracker is used for issue management, this field name 

is Design Request required for check out. 

Project reference required Specify whether you require a project for check out. 

Retain error-free job logs Specify Y or N to indicate whether to maintain error-free job logs in 

an Implementer database file. 

Remove obj in from lib/env Specify 2=Never (Implementer never deletes items from remote 

production environments). 

Remove src in from lib/env Specify 2=Never (Implementer never deletes items from remote 

production environments). 

Maintain related object info Specify Y or N, as needed. If Y, complete the next four fields as 

needed based on the source of related object information. 

Source of information Specify the source of related object information. Valid options are 

1=Implementer or 2=Hawkeye PathFinder. 

PathFinder X-ref library Specify the PathFinder x-ref library where related object information 

is stored if PathFinder maintains related objects. 

Update PathFinder X-ref Specify whether to automatically update PathFinder information 

during request promotion. 

DOCLIBL for X-ref updates Specify the documentation library list name in PathFinder that 

contains the library names of cross-referenced objects. 

425


426 

Press PAGE DOWN to access the third Create Environment panel. 


When arrives in 

this env 

Specify the MKS Integrity issue state to set for an item when checked 

out or promoted to this environment. Required only if MKS Integrity is 

the issue tracking system. 

Name: Specify the name of a valid MKS Integrity status to assign. 

*DEFAULT: Assigns the appropriate MKS Integrity default value. 

For example, when an item is checked out to *TST environment, 

the default issue status for *TST is set. When promoted to *PRD 

environment, the default issue status for *PRD is set. If promoted 

to this environment and it is the first *QAC on the path, the issue 

status for *QAC1 is set; if second *QAC on the path, the issue 

status *QAC2 is set. 

*NONE: Status is not assigned or updated. 

For information on using MKS Integrity, see page 196. 

When rejected from this env Specify the MKS Integrity issue state to set for an item when rejected 

from this environment. Required only if MKS Integrity is the issue 

tracking system. 

Name: Specify the name of a valid MKS Integrity status to assign. 

*DEFAULT: Assigns the appropriate MKS Integrity default value. 

For example, when an item is rejected from this environment to the 

first *QAC environment on the path, the default status for *QAC1 is 

assigned; for the second *QAC environment on the path, the 

default status for *QAC2 is assigned. 

*NONE: Status is not assigned or updated. 

System Specify the system name defined in Network Configuration. 

Source library location L=Local (compile runs on host system, objects sent to remote).




Compile location L=Local (compile runs on host system, objects sent to remote). 

Values for Source Library Location and Compile Location must be 

the same. 

Distribution method 4=SDMCom. SDM-Com is a feature of Implementer that improves 

performance 20–35% over SNADS distribution. Its advanced 

features use compression algorithms and blocking specifically for 

remote distributions. 

Remote initiated move Specify Yes or No for a remote operator to initiate moves. 

Updates host No. If Remote initiated move is set to Y, this field allows you to update 

the host with information such as job logs and messages. 

Retain requests on remote Specify whether to retain requests on the remote system. 

Promotion notification queue Specify the promotion notification queue on remote system. 

Target release Specify if the remote system is at a different release of the operating 

system than the host system. Useful when you have multiple 

environments that target a single remote, to specify different target 

release values for each environment. 

*NETCONFIG: Retrieves the value defined for Target Release 

parameter in menu option 46, Network Configuration. This is the 


*CURRENT: Remote system is at same operating system level as 

host system. 

*PRV: Remote system is at an earlier release of the operating 

system. 

Name: Specify actual version name, for example, V5R2M0. 

This example describes the required fields and suggested values in Network Configuration 

for remote environments. 

427


428 

This is the first Network Configuration Maintenance panel 


System Specify the system name to send changes to (can only be defined when 

you define a new system). 

Description Specify a brief description of the system. 

Target release Specify the OS/400 release level of the remote (target) system. 

*CURRENT: Remote system is at same operating system level as host 

system. 

*PRV: Remote system is at an earlier release of the operating system. 

Name: Specify the version name, for example, V5R2M0. 

SNA Communications options 

The following options allow you to define how to distribute to the remote system. 

Remote location name Specify the name of the remote location that changes are sent to. If you 

use Network Control Program (NCP), this is the NCP system name. It is 

not the name displayed in Display Network Attributes (DPSNETA). The 

value *SYSTEM uses the current system name. 

Local location name Specify the name of the local location where changes are sent from. 

Mode name Specify the name of the system object that contains controlling information 

for an APPC session. Enter a specific mode name, or *NETATR to use the 

default identifier in the network attributes. If you created a communication 

mode for Implementer, use IMPMODD.


Remote network 

identifier 

Press PAGE DOWN to access the second Network Configuration Maintenance panel. 


Specify the name of the remote network where the location resides 

(usually *NETATR). 

Name: Enter the specific name of the remote network. 

*NETATR: Name is taken from the network attributes. 

*LOC: System automatically selects the remote network ID. 

*NONE: Non remote network ID is used. 

SNADS user ID Specify the SNADS user ID used to send network files to the specified 

system. This is typically user profile MWIPROD. Use this ID only if you 

distribute to the remote via SNADS (determined by the distribution method 

defined for the environment in Work with Environments). 

SNADS user address Specify the SNADS user address used to send network files to the 

specified system. This is the remote system name. 

Name: Address used when enrolling user in SNADS directory entry. 

*SYSTEM: System name used for the address listed above (current 

system name). 


Switched line Specify Y or N whether the communications line is a switched line. 

Switched line name Specify the name of the switched line (required to auto vary on and auto 

vary off the line). 

Control unit name Specify the name of the control unit associated with the line to this 

system. 

429


430 


Auto vary on Specify whether to vary on the communications line, controller, and 

device before remote processing begins. 

Auto vary off Specify whether to vary off the communications line, controller, and 

device after remote processing completes. 

Remote wait time Specify the number of minutes the remote program waits before 

attempting to receive a network file (promotion request). 

Remote no. of retries Specify the number of times the remote program attempts to receive a 

network file. Each retry attempt waits for the number of minutes specified 

in the Remote Wait Time field. If the network file is not received after this 

number of retries, request processing ends and the request status is set 

to the appropriate failed status: Comp-fail, Dist-fail, or Move-fail.

A PPENDIX C 

Converting DesignTracker 

Data to MKS Integrity 

Migrating Legacy Data to MKS Integrity 

C 

This appendix is for DesignTracker customers who are converting to MKS Integrity for 

issue management and have a requirement to convert existing DesignTracker data to 

MKS Integrity issues. This allows you to make history visible in MKS Integrity and bring 

future work into MKS Integrity. 

The tasks in this chapter explain how to convert existing DesignTracker design requests 

(DRs), service requests (SRs), and DR entity information to MKS Integrity issues, by 

using the Implementer conversion tool. 

MKS can assist with converting your DesignTracker data to MKS Integrity by providing 

conversion assistance, as well as assist in defining your business processes and workflow 

to MKS Integrity. For more information on this option, contact MKS Customer Care. 

This appendix covers the following topics: 

“Requirements” on page 432 

“Overview” on page 432 

“Rules and Actions” on page 433 

“Generating and Configuring the Conversion Properties File” on page 441 

“Post Conversion Considerations” on page 454 

431

Appendix C: Converting DesignTracker Data to MKS Integrity 

Requirements 

Overview 

432 

The following requirements apply to using this data conversion: 

Install or upgrade to Implementer 2006, including configuring the Implementer Server. 

Install or upgrade to MKS Integrity 2006. 

In addition, you must define you development process and workflow MKS Integrity, 

and any fields and field values you map must exist in MKS Integrity. For details on this 

topic, see the MKS Integrity Server 2006 Administration Guide. 

MKS Integrity is set as the default issue tracking system within Implementer, with 

DesignTracker co-existence enabled. These tasks are described in “Converting With Data 

Retention” on page 247. 

If you have already converted to MKS Integrity, you may have already completed the 

following requirements that are described in Chapter 5. To verify this: 

Review “Set the Last Allowed DR Number” on page 250 and make any necessary 

changes. 

Review “Set the Next Issue Number in MKS Integrity” on page 252 and make any 

necessary changes. 

Review “Set a User’s Default Issue Management System” on page 253 and make any 

necessary changes. 

The conversion tool uses the MKS Integrity Setup information defined in Implementer to 

communicate with MKS Integrity and create issues, as such, communications between 

Implementer and MKS Integrity must be active to use the conversion tool. For details on 

this topic, see “Defining MKS Integrity Values in Implementer” on page 226. 

MKS Integrity, unlike DesignTracker, has an enterprise focus that uses different process 

control mechanisms and field types than DesignTracker. As such, converting data to 

MKS Integrity using Implementer’s automated conversion tool requires that the controls, 

workflow, issue types, fields, field values, and users, which are essential to operating your 

business, are set up in MKS Integrity prior to running the data conversion. These items are 

not created by the conversion. 

Once MKS Integrity is set up and Implementer is converted to use MKS Integrity for issue 

management in co-existence with DesignTracker, you can focus on the data conversion 

aspect of your project.

Rules and Actions 

You have the option to convert all data at the same time, or gradually convert subsets of data, 

for example, by product, user, department, or project. Perhaps your business model requires 

only the conversion of DRs (not SRs)—the conversion tool has the flexibility to accommodate 

each of these scenarios, and more. The Work with Design Requests and Work with Service 

Requests subsetting functions are used to select the DRs or SRs for conversion. 

As explained in “Set a User’s Default Issue Management System” on page 253, Implementer 

allows you to designate on a user basis which issue tracking system a user is working with. In 

other words, you can temporarily have groups of users using DesignTracker, while other 

users are using MKS Integrity. This approach is beneficial to larger organizations with many 

end users, as it allows you to train and migrate groups of individuals rather than all users at 

once. 

Implementer provides a conversion tool that is delivered in the form of the Convert DT to 

MKS Integrity (ICVTDT) command. Unlike most Implementer commands, this command 

works together with a conversion property file that resides on the Implementer Server. The 

conversion results post to a conversion log on the same system. Using the conversion tool, 

you are able to generate the conversion properties file you use to map existing DesignTracker 

data and fields to corresponding values already defined in MKS Integrity. Details on the 

ICVTDT command begin on page 438. Information on mapping data begins on page 441. 

Once the conversion properties are properly set up and you have all the required data 

mapped, the conversion tool is used to convert the DesignTracker data to MKS Integrity 

issues. Information on using the conversion tool begins on page 433. 

The data conversion is complete when all applicable data is converted to MKS Integrity 

issues and no users are set to use DesignTracker for issue management. Information on post 

data conversion activities begins on page 454. 


The conversion tool allows you to convert existing DesignTracker DRs, SRs, and DR entity 

information to MKS Integrity issues and related change packages. You can convert subsets of 

DRs and/or SRs, making it possible to have groups of DRs or SRs convert differently 

depending on the values specified in the conversion properties file when the conversion 

runs. 

DRs must have no open locks to convert. Once converted, a DR cannot be associated with a 

lock, for example, a converted DR cannot be used in check out. Editing a converted DR or SR 

is allowed; however, any changes made to a converted DR or SR are not updated to the 

corresponding MKS Integrity issue. Thus, a good business practice is to only make changes to 

the new issue. 

433


434 

Each DesignTracker DR and SR field is optionally mapped to an MKS Integrity field as 

defined by you. DR entities and corresponding fields automatically convert to Implementer 

change packages in MKS Integrity. Fields can either be omitted, or they can have the name of 

an existing MKS Integrity field to populate with the data. The “Logged by User” and 

“Logged Date” always convert to internal fields. 

For each field you convert, if there is a master file in DesignTracker setup, the DesignTracker 

field value is assigned to the corresponding MKS Integrity field value as defined in the 

conversion properties file. This allows replacing the shorter abbreviated values common in 

DesignTracker, with the longer, more descriptive values common to MKS Integrity. For 

example, DesignTracker status values can be set to existing MKS Integrity state values. 

After the data conversion, the DRs and related lock history remain in DesignTracker, 

unchanged and available online to select DesignTracker users for historical and auditing 

purposes. 

TIP MKS recommends you assign the new MKS Integrity issue number to one of the 

user defined fields on DRs and SRs so it is visible when displaying a DR or SR. This 

also makes it available to include in reports and queries.However, this has no 

impact on the fact that once a DR or SR is converted, it will not convert again even if 

included in selection criteria. 

User Profile and Resource Fields 

Implementer attempts to convert all user profile and resource fields to the MKS Integrity user 

values defined for Project Leader and Developer Resource. 

Implementer retrieves the user ID that corresponds to the resource ID in the DesignTracker 

Resource master file. From the user ID, the OS/400 user profile is retrieved from the 

Implementer Work with Users function to verify if an MKS Integrity user ID is specified. If 

any of these values are invalid or not specified, the alternate value is used. 

In the event a name cannot convert, when defining the ICVTDT command parameters you 

must specify a valid default user to assign to the issue if there is no conversion for the user or 

available resource in DesignTracker. 

NOTE This rule applies when mapping to an MKS Integrity user field. If mapping to 

a text field, the original text maps to the new field. 

Entities Added as Change Package Entries 

When a converted DR is associated with a DesignTracker entity, an Implementer change 

package is created based on the standard MKS Integrity change package creation rules.

The Create User ID for a change package is determined in the following order: 


assigns the user associated with the DR entity, if the user is enrolled in MKS Integrity 

assigns the development resource initials associated with the DR entity, if the user is a 

valid Implementer user and enrolled in MKS Integrity 

assigns the DRs Logged By user, if the user is a valid Implementer user and enrolled in 


assigns the default create user as specified in the ICVTDT command (see “Default create 

user” on page 440) 

The change package status is set after the members are added. Because a converted DR 

cannot be associated with open locks, the change packages automatically close once 

converted. 

Conversion Log File 

Processing of the Convert DT to MKS Integrity (ICVTDT) command generates a conversion 

log file that lists any errors found in the setup and any problems detected during the actual 

conversion. MKS recommends you review the log file each time the ICVTDT command is 

processed, as it is the only place truncation warnings appear. 

The log is located on the Implementer Server. The log name is: 

implementer-conversion-YYYYMMDDHHMMSS.log 

Where YYYYMMDDHHMMSS is the date and time the log was created (the time stamp is based on 

a 24-hour clock), for example, implementer-conversion-200604213124701.log. 

Message and Error Handling 

For every 50 items converted, a status message displays at the bottom of the display to 

indicate the actual number of converted items, for example, “Converted 50 items” and 

“Converted 2,500 items”. When the conversion ends, the total number of converted DRs 

and SRs display. 

If the conversion properties are incorrectly defined or problems occur when adding 

Implementer change packages for the DR entities, the conversion halts and the problems are 

logged to the conversion log file. You must resolve these problems before restarting the 

conversion. 

If a specific DR or SR does not convert, the problems are logged to the conversion log file and 

the conversion continues processing. After resolving the problem, you can restart the 

conversion without modifying the parameter selection (previously converted issues are 

excluded). 

435


436 

Conversion Considerations 

DRs that are currently linked to SRs in DesignTracker will not have a relationship 

automatically added between the new issues in MKS Integrity—this requires a manual 

change. In addition, because the following data (if used) is not applicable to MKS Integrity, it 

does not convert: 

DR and SR approval related information 

process control information, for example, field display and validation controls, and 

Implementer state controls 

release management information 

ProjectMaster information 

SupportCenter attached calls 

Organizational Activities 

The organizational activities required to perform the data conversion include the following: 

1 Pilot the integration. 

a) In Implementer, run the system conversion that allows DesignTracker and 

MKS Integrity to co-exist. 

b) Configure MKS Integrity, which includes: 

Types, workflow, fields, and field values. The workflow must allow any state 

transition to any other state. In addition, no mandatory fields can be specified 

in the workflow. The fields cannot have editability rules; remove any existing 

editability rules. You can modify this open workflow to be more restrictive 

once the conversion has finished. 

Enroll users. 

c) Configure Implementer to use MKS Integrity. 

d) Map your existing data to MKS Integrity by completing the conversion properties 

file. 

e) Run the Convert DT to MKS Integrity (ICVTDT) command to convert a sampling of 

DRs (for testing purposes, these DRs can be copied from other DRs). 

f) Verify the setup by using the Implementer and MKS Integrity functions to check out 

and promote back to production. 

g) Document all Implementer and MKS Integrity set up steps. 

h) Apply the set up changes to the production copies if piloting the conversion in 

separate installations.


2 Plan and perform any required training (pilot installations can be used for this purpose). 

3 Configure MKS Integrity for any remaining changes: 

a) Workflow, fields, and types. 

b) Enroll users (non pilot users). 

4 Perform the conversion. 

a) Secure a backup of the Implementer and MKS Integrity databases. 

b) Issue the Convert DT to MKS Integrity (ICVTDT) command for each group of DRs 

and SRs requiring conversion. 

c) Perform any additional MKS Integrity setup changes. 

d) Verify the set up by using the Implementer and MKS Integrity functions for check 

out and promotion. 

e) Begin using the new features. 

Example of a Basic Conversion 

The following tasks illustrate the steps required to perform and complete a typical data 

conversion. 

1 Issue the following command to run the conversion and generate the initial conversion 

properties file: 

ICVTDT MODE(*EDIT) TYPE(*BOTH) DFTCRTUSR(CVTUSER) 

A message confirms the file was generated and the location of the file. 

NOTE To generate a new conversion properties file, delete or rename the existing file. 

2 Define the mappings from DesignTracker values to MKS Integrity fields and values. 

In the conversion properties file, modify the field and value settings using any 

desktop ASCII editor, such as Notepad. For details, see “Generating and Configuring the 

Conversion Properties File” on page 441. 

3 In MKS Integrity, set up any new types, fields, or field values that will be used for 

DesignTracker DRs or SRs. 

4 From the Work with Design Requests and/or Work with Service Requests functions, use 

F17 to subset the list of requests to convert. 

5 Edit the conversion settings by issuing the following command: 


437


438 

6 Resolve all errors reported in the conversion log file. For details, see “Conversion Log 

File” on page 435. 

7 Run the conversion by issuing the following command: 

ICVTDT MODE(*CONVERT) TYPE(*BOTH) DFTCRTUSR(CVTUSER) 

8 Review the conversion log file for errors and warnings. For details, see “Message and 

Error Handling” on page 435. 

9 If the alternate was used to handle undefined values, in MKS Integrity, query for issues 

that use the alternate values for fields and modify the values as needed. 

Convert DT to MKS Integrity (ICVTDT) Command 

The Convert DT to MKS Integrity (ICVTDT) command is the tool that allows you to generate 

an initial Implementer conversion properties file, validate the entries in the file, and convert 

existing DRs and SRs into MKS Integrity issues. 

The command uses the current DR and SR selection criteria that are applied when subsetting 

the Work with Design Requests or Work with Service Requests functions for the user that 

issues the command, or the selection criteria of the last report generated by the user 

(whichever is most current). This allows you to view and report on the information to 

convert. The conversion automatically excludes any items already converted. 

The command converts DRs and SRs based on the values defined in the implementerconversion.properties 

file that installs in the root directory where the Implementer 

server is installed. Records convert based on the sort order determined by using the DR and 

SR summary report criteria. For information on the conversion properties file, see 

“Generating and Configuring the Conversion Properties File” on page 441. 

The command provides three operational modes, depending on the Conversion Mode 

parameter value specified. 

Command parameter Conversion properties file status / command action 

*EDIT or *CONVERT Creates file if it does not exist. 

*EDIT Edits existing file. 

*CONVERT Edits existing file. If no errors, converts data. 

Create an initial prototype of the conversion properties file by issuing the command with the 

*EDIT parameter value, which populates the file based on the data currently defined to 

DesignTracker. The property file can be edited using any ASCII text editor. You can issue the 

ICVTDT command with the *EDIT parameter value as often as needed to validate the 

conversion property file until no errors are reported. When you are ready to convert data, 

issue the command with the *CONVERT parameter value.


The command generates a conversion log file that lists any errors found in the setup, as well 

as any errors that occur during the data conversion. For details, see “Conversion Log File” on 

page 435. 

The command performs the following edits that must pass validation: 

The user running the conversion is enrolled in MKS Integrity and set up in Implementer 

as a DesignTracker user. 

The default MKS Integrity user is valid. 

If converting DRs, a valid DR issue type is specified. 

If converting SRs, a valid SR issue type is specified. 

Each field is mapped to an existing MKS Integrity field (unmapped fields are omitted). 

Each field is mapped to a field of the proper type. 

For each field that has a restricted list of entries, each valid DesignTracker field value is 

mapped to a valid MKS Integrity field value. 

NOTE This requires all new field values defined in MKS Integrity. MKS professional 

services provides tools to help with this task if you have a lot of values to define. 

The alternate value, if specified, is a valid MKS Integrity value for the field. 

Each MKS Integrity field is assigned to only one DesignTracker field within DRs and 

SRs. For example, the State field can be assigned to both DRs and SRs as separate 

entities, but it cannot be assigned more than once within DRs or SRs alone. 

No open locks exist for DRs. If DRs with open locks are found, a message is sent to the 

conversion log and the edit or conversion does not occur. 

To use the ICVTDT command, DesignTracker and MKS Integrity must be set up as coexisting 

issue management systems as described in “Converting With Data Retention” on 

page 247. 

NOTE The ICVTDT command converts data only. For information on converting the 

issue management system, see “Converting From DesignTracker to MKS Integrity” 

on page 243. 

439


440 

Convert DT to MKS Integrity (ICVTDT) Command Parameters 

Conversion mode 

Specify whether to run the conversion in edit mode or conversion mode as follows: 

*EDIT Validates the conversion setup as defined in the implementerconversion.properties 

file. Does not convert DRs or SRs. 

Creates initial prototype implementer-conversion.properties file 

populated with the default values of all master data currently defined in 

the DesignTracker setup. The resulting file may be large depending on 

the volume of data. Use this file to map existing DesignTracker fields to 

the corresponding MKS Integrity fields. 

If you have made significant changes to your setup since creating the 

initial conversion properties file, delete or rename the file and generate a 

new one. 

*CONVERT Validates the conversion setup as with the *EDIT parameter, and if the 

configuration file is valid, converts DRs and SRs to issues. 

Type to convert 

Specify the type of DesignTracker requests to convert. 

Default create user 

IMPORTANT The first time you issue this command, specify the *EDIT 

parameter value to generate an initial conversion properties file. This file 

contains data from your existing setup and must be generated to validate your 

conversion setup and data mapping. You may have to do this multiple times 

until the expected results are achieved. Rerun the ICVTDT command with the 

*EDIT value until the log file is error free. When you are satisfied with the edit 

results, you are ready to convert DRs and SRs by issuing the command using 

the *CONVERT parameter value. 

*BOTH Converts both DRs and SRs. 

*DR Converts DRs only. 

*SR Converts SRs only. 

Specify an Implementer user profile name to assign as the Created by user for issues and 

change packages when a user associated with a DR, SR, or DR entity cannot be assigned, for 

example, if a user profile no longer exists or a user is not enrolled in MKS Integrity. 

The default name specified here must be set up in Implementer as an MKS Integrity user and 

enrolled in MKS Integrity. 

Based on the type, the Created by user is assigned in the following order:

Type Order of assignment 

Command Usage Examples 

Generating and Configuring the Conversion Properties File 

Issues Logged by user. 

Default create user specified in the ICVTDT command. 

Change Packages User associated with the DR entity, if the user is enrolled in MKS Integrity. 

Development resource initials associated with the DR entity, if the user is a 

valid Implementer user and enrolled in MKS Integrity. 

DRs Logged By user, if the user is a valid Implementer user and enrolled in 


Default create user specified in the ICVTDT command. 

First, the ICVTDT command is used to generate and validate the setup defined in the 

conversion properties file for DRs and SRs. Data is not converted. An example of this 

command is: 


Next, the ICVTDT command is used to convert a subset of DRs to MKS Integrity issues. 

This example assumes that any errors reported in the conversion properties file as a 

result of issuing the command in the first example are resolved. If any DRs are 

associated with an invalid user profile, Implementer assigns the MKS Integrity user 

defined for the default user profile CVTUSER. An example of this command is: 

ICVTDT MODE(*CONVERT) TYPE(*DR) DFTCRTUSR(CVTUSER) 

Last, the ICVTDT command is used to convert the user’s defined subset of DRs and SRs 

to MKS Integrity issues. An example of this command is: 

ICVTDT MODE(*CONVERT) TYPE(*BOTH) DFTCRTUSR(CVTUSER) 

Generating and Configuring the Conversion 

Properties File 

Before converting DesignTracker data, you must map the existing data to corresponding 

values in MKS Integrity. This is accomplished by fist generating the Implementer conversion 

properties file. After generating the file, you must map the DesignTracker fields to the 

MKS Integrity fields. 

If your DesignTracker setup changes you can edit the conversion properties file, or if you 

want to completely recreate the conversion property file from scratch, either delete or rename 

the existing file on the Implementer Server and then rerun the edit process. 

After reviewing the following information, you can perform the task on page 446 that 

explains how to generate, edit, update, and save the file as needed for the data conversion. 

441


Data Mapping Considerations 

442 

The overall success of your data conversion is contingent upon two criteria: the accuracy of 

workflow and values you define in MKS Integrity, and the accuracy with which you map 

existing DesignTracker data values to the new values. To support this objective, this section 

contains specific information you need to know in preparation for mapping data and 

configuring the conversion properties file. 

Field Mapping 

You must map all applicable DesignTracker fields to a corresponding valid field in 

MKS Integrity. You accomplish this by configuring the Implementer conversion properties 

file. An example of the conversion properties file is illustrated in the table on page 446. You 

may find it helpful to use this table as a template when mapping your data. 

Prior to running the conversion, you must define any new fields in MKS Integrity (the 

conversion does not create fields). An error occurs if a specified field is not of the required 

type. 

Field Values 

Several fields in DesignTracker contain data that you can prompt or that is validated to 

master file data. To allow for a parallel structure in MKS Integrity, you can convert these 

fields to either a Pick or Short Text data type in MKS Integrity. The DesignTracker fields are: 

Product 

Product/component 

Product/version 

Priority 

Company/division 

Company/division/department 

Cost center 

System 

Request type 

Request status 

Review the following table to determine whether to use a Pick or Short Text data type.

Data Type Description 


Pick Allows selection of predefined values only. If values exist in the DesignTracker 

database that do not match the current master files, it causes an error. This could 

occur by entering data when the System Control value was set to bypass entry 

validation. 

After the conversion, you can rename the Pick entry to rename all references to it. 

Short Text Allows any text and also provides a list of standard options. All values defined in 

DesignTracker for this field are added as suggestions. If values exist in DRs or SRs 

that are not in the master files, they are set for the issue (unlike the Pick data type). 

After the conversion, you can rename a suggestion without impact to any other 

issues that contain the suggestion. To change an issue you must edit and change 

the new value. 

Users and resources do not require mapping because the conversion uses the Implementer 

user’s profile for MKS Integrity as specified in Work with Users. These values convert to the 

corresponding MKS Integrity user profile. If a user is not defined, the default user specified 

on the ICVTDT command is used. 

However, the MKS Integrity Log by User, although set using the same logic, is handled 

differently to handle cases when the DesignTracker user that originally logged the DR or SR 

is no longer an active user, and therefore, not enrolled in MKS Integrity. To account for this, 

you should set the Logged by User to convert to a string field to allow the Logged by User 

name, as it appears in DesignTracker, to map to this field. Any DesignTracker fields that 

convert to an MKS Integrity user can be placed in a User field type. 

NOTE Blank spaces in DesignTracker values automatically translate to an 

underscore “_” in the value entry. This file is built from master files; thus, if any 

values used in the DesignTracker database are not listed in the master file, you must 

add those values. If the values contain blanks, you must substitute an underscore for 

the blanks. Underscore values are not required when specifying the new 

MKS Integrity value. 

Alternate Values 

The conversion allows each field to have an alternate value specified. The alternate value is 

automatically used when a map entry is not specified for the corresponding field value for a 

DR or SR. The alternate value serves a dual purpose: 

If multiple values are specified for a field in DesignTracker and you want most of them 

to use the same value in MKS Integrity, you can set the alternate value for those fields, 

and set the other values to a value other than the alternate. 

If existing DesignTracker data is not defined in the setup lists for the data type in 

MKS Integrity and you specify a Pick data type, an error occurs during the conversion if 

an alternate value is not specified. If this occurs, either rerun the conversion after the 

443


444 

conversion of mapped values is finishes, or create the issues by using the value specified 

as the alternate value, and then query the issues in MKS Integrity and change them as 

needed. 

Long Text Fields and Descriptions 

In DesignTracker, all text information displays using a fixed font size, whereas MKS Integrity 

uses a variable font size. Similarly, the long descriptions in DesignTracker allow for a 

limitless amount of data, whereas the long text fields in MKS Integrity have a size limit. The 

conversion tool handles these database variances as follows: 

When converting long text fields in DesignTracker, each line of text is separated with a 

“new line” character in MKS Integrity (paragraphs are not created). If existing text is 

spaced to form columns of information, this format is not replicated in MKS Integrity. 

If the data for a long description exceeds the limit of the MKS Integrity field, during the 

conversion the extra text and corresponding message are written to the error log. This 

allows you to manually enter the data into another field, for example, using cut and 

paste, or edit the text to a size that fits in the field. When this occurs the text in the issue 

field indicates a truncated value. 

Hierarchical Field Considerations 

DesignTracker allows for parent/child data relationships, where some fields are sub-fields of 

other fields, resulting in a hierarchical data structure. The hierarchical field considerations 

apply to the following DesignTracker fields: 

Product/component 



Company/division/department 

MKS Integrity does not support user defined hierarchical data; thus, you can place this type 

of data into a Pick or Short Text data type, as explained in “Field Values” on page 442. When 

you generate the property file, the description for all hierarchical entries is built based on the 

hierarchical field values. Once converted, the data in MKS Integrity is separated by a forward 

slash “/” to indicate the different data levels. 

For example, in the company/division/department field: 

ACME Mfg is the company description for ACME Manufacturing 

Widgets is the division description for WID 

Accounting is the department description for ACCT 

The generated key is: 

ACME/WID/ACCT=ACME Mfg/Widgets/Accounting

Mapping to the Project Field 


Some fields in the conversion property file can be mapped into the Project field. Fields that 

are mapped into this field automatically parse using a forward slash “/” as the project 

hierarchy delimiter. All project levels must be created with the appropriate hierarchy. For 

example, the company/division/department value of Acme/Widgets/Accounting has the 

project hierarchy: 

Acme 

Widgets 

Accounting 

If you are mapping to a project field data type, the Implementer conversion properties value 

must have a forward slash (/) at the beginning of the new field name, for example, /Acme/ 

Widgets/Accounting. 

NOTE This option is valid only if you are not using Implementer projects with 

MKS Integrity issues for project tracking as described in the “Implementer project 

field” description on page 230. 

New Issue Number 

MKS recommends you assign the MKS Integrity new issue number to one of the user defined 

fields in DesignTracker so it is included in reports and queries. If a previously converted DR 

or SR is included in a query used for conversion, it is excluded even if the new issue number 

is not stored in a user defined field. 

Generating the Conversion File 

The following tasks allow you to generate an initial conversion properties file. The values 

listed in the initial file are based on your existing DesignTracker data. For each applicable 

DesignTracker field value, you need to define the corresponding conversion value to assign 

in MKS Integrity. 

The overall success of your data conversion relies upon the accuracy of your data mapping. 

For assistance with completing this task, see the table of the Implementer conversion 

properties on page 446. 

445


446 

To generate and configure the conversion properties file 

1 Generate an initial conversion properties file by issuing the following command. Change 

the parameter values as needed based on your requirements: 

ICVTDT MODE(*EDIT) 

TYPE(*BOTH) 

DFTCRTUSR(default_user_name) 

A message confirms the conversion property file generated and the location of the file. 

For detailed information on this command, see “Convert DT to MKS Integrity (ICVTDT) 

Command Parameters” on page 440. 

2 Open the file using a standard text editor and modify the conversion properties to 

correspond with the information applicable to your database. 

3 To retain the changes, save the implementer-conversion.properties file as a plain 

text file. 

4 Once the conversion properties file is populated with valid values, re-issue the 

command to verify no errors exist. When you are satisfied with your results, you are 

ready to convert the data. 

Implementer Conversion Properties 

The tables in this section describe the Implementer conversion properties file. There are two 

sections to the conversion properties file: general conversion control properties, and DR and 

SR field conversion properties. You may find it helpful to use the tables as a template when 

mapping your data. 

Implementer Conversion 

Control Properties 

Description 

mks.implementer.dr.ud_field=0 Controls which user defined field holds the issue number for a converted 

DR. Valid values are: 

0 (none—default value) 

1 (user defined field #1) 

2 (user defined field #2). 

Note that any data in the specified user defined field will be overwritten. 

mks.implementer.sr.ud_field=0 Controls which user defined field holds the issue number for a converted 

SR. Valid values are: 

0 (none—default value) 



Note that any data in the specified user defined field will be overwritten.

Implementer Conversion 

Control Properties 

Description 


mks.implementer.dr.issue_type Defines the MKS Integrity issue type to use for DRs, for example, 

Defects. 

mks.implementer.sr.issue_type Defines the MKS Integrity issue type to use for SRs, for example, 

Features. 

Design Request and Service Request Field Conversion 

Properties and Definitions 

Referring to the table on page 448, the field definitions for the design request and service 

request conversion properties are as follows: 

mks.implementer.dr and mks.implementer.sr indicate whether this field is part of 

a design request or service request. 

intmgrfield is the MKS Integrity field to contain the converted DesignTracker data for 

a specific DesignTracker field. 

In the following example, the MKS Integrity field Priority contains the converted 

requester priority for a DR 

mks.implementer.dr.intmgrfield.requester_priority=Priority 

value is the value to assign in MKS Integrity that replaces the value in DesignTracker 

In the following example, the MKS Integrity field Priority uses the new values of High 

for A, Medium for B, and Low for C: 

mks.implementer.dr.value.requester_priority.A=High 

mks.implementer.dr.value.requester_priority.B=Medium 

mks.implementer.dr.value.requester_priority.C=Low 

NOTE 

The initial MKS Integrity field values specified in the conversion properties file 

come from the description of the value in DesignTracker. Alternately, you can 

edit the description in DesignTracker and recreate the conversion properties file. 

For more information, see the table on page 438. 

Any spaces in DesignTracker values automatically translate to an underscore “_” 

in the value entry. Because this file is built from master files, if any values used in 

the DesignTracker database are not listed in the master file, you need to add 

those values. If the values contain blanks, you must substitute an underscore for 

the blanks. Underscore values are not required when specifying the new 

MKS Integrity value. 

447


448 

alternate is the default value to automatically assign in MKS Integrity if a specific 

replacement for the value is not in DesignTracker. If left blank and no replacement value 

is found, the conversion reports an error. 

In the following example, if the DR priority is set and the value is not A, B, or C, then the 

MKS Integrity field Priority is set to unknown. 

mks.implementer.dr.value.requester_priority.alternate=unknown 

Design Request and Service Request Field Conversion Properties 

DesignTracker 

Description/Field 

Name 

mks.implementer.dr.intmgrfield.number= DR number 

DRDRNB 

mks.implementer.dr.intmgrfield.logged_by_user_id= 

mks.implementer.dr.value.logged_by_user_ 

id.alternate= 

Recommended 


Field Data Type 

Integer 

Logged by user User or Short Text 

DRLGUI 

This field is not used as the actual issue 

Created By userid; it can be assigned to 

any field. If assigned to a Short Text field, 

it can be used to store the user who 

created the DR, even if the user is not 


When assigning to a Short Text field, do 

not specify an alternate value as the 

system verifies the user is defined in 

Implementer with an MKS Integrity 

user ID. 

mks.implementer.dr.intmgrfield.logged_date= Logged date Date 

DRLGDT 

This field is not used as the issue 

Created Date field. It can be assigned to 

any field. 

mks.implementer.dr.intmgrfield.closed_date= Closed date 

DRCLDT 

mks.implementer.dr.intmgrfield.closed_flag= Closed flag 

DRCLFG 

mks.implementer.dr.intmgrfield.title= Title 

DRDRTT 

mks.implementer.dr.intmgrfield.type= 

mks.implementer.dr.value.type.alternate= 

mks.implementer.dr.intmgrfield.system= 

mks.implementer.dr.value.system.alternate= 

mks.implementer.dr.intmgrfield.product= 

mks.implementer.dr.value.product.alternate= 

DR type 

DRDRTB 

System 

DRSYSY 

Product 

DRPDPD 

Date 

Boolean 

Short Text or 

Summary 

Pick or Short Text 

Pick, Project, or 

Short Text 


Short Text


mks.implementer.dr.intmgrfield.product_component= 

mks.implementer.dr.value.product_component. 

alternate= 

mks.implementer.dr.intmgrfield.product_version= 

mks.implementer.dr.value.product_version. 

alternate= 


Product/ 

component 

DRPDPD/ 

DRCPCP 


DRPDPD/ 

DRVRVR 

mks.implementer.dr.intmgrfield.expected_date= Expected date 

DREXDT 

mks.implementer.dr.intmgrfield.requested_date= Requested date 

DRRQDT 

mks.implementer.dr.intmgrfield.requester_ 

priority= 

mks.implementer.dr.value.requester_priority.alternat 

e= 

mks.implementer.dr.intmgrfield.benefits_priority= 

mks.implementer.dr.value.benefits_priority. 

alternate= 

mks.implementer.dr.intmgrfield.development_ 

priority= 

mks.implementer.dr.value.development_priority. 

alternate= 

mks.implementer.dr.intmgrfield.status= 

mks.implementer.dr.value.status.alternate= 

mks.implementer.dr.intmgrfield.project_leader_ 

initials= 

mks.implementer.dr.value.project_leader_initials.alt 

ernate= 

mks.implementer.dr.intmgrfield.development_ 

resource_initials= 

mks.implementer.dr.value.development_resource_ 

initials.alternate= 

Requester priority 

DRRQPR 

Benefits priority 

DRBNPR 

Development 

priority 

DRDVPR 

Status 

DRSTST 

Project leader 

initials 

DRPLIN 

Developer initials 

DRDRIN 

mks.implementer.dr.intmgrfield.estimated_effort= Estimated effort 

DRENEF 

mks.implementer.dr.intmgrfield.estimated_cost= Estimated cost 

DRENCS 

mks.implementer.dr.intmgrfield.estimated_ 

completion_date= 

DesignTracker 


Name 

Estimated 

completion date 

DRECDT 

Recommended 




Short Text 


Short Text 

Date 

Date 





Short Text 

User or Short Text 

(converts to 


user) 

User or Short Text 

(converts to 


user) 

Float 

Float 

Date 

449



mks.implementer.dr.intmgrfield.implementer_ 

project_reference= 

mks.implementer.dr.value.implementer_project_ 

reference.alternate= 

mks.implementer.dr.intmgrfield.estimated_effort_ 

remaining= 

mks.implementer.dr.intmgrfield.estimated_cost_ 

remaining= 

mks.implementer.dr.intmgrfield.total_actual_ 

effort= 

450 


project reference 

DRIMPJ 

Estimated effort 

remaining 

DRTEEF 

Estimated cost 

remaining 

DRTECS 

Total actual effort 

DRTAEF 

mks.implementer.dr.intmgrfield.total_actual_cost= Total actual cost 

DRTACS 

mks.implementer.dr.intmgrfield.company= 

mks.implementer.dr.value.company.alternate= 

mks.implementer.dr.intmgrfield.company_division= 

mks.implementer.dr.value.company_division. 

alternate= 

mks.implementer.dr.intmgrfield.company_division_ 

department= 

mks.implementer.dr.value.company_division_ 

department.alternate= 

mks.implementer.dr.intmgrfield.cost_center= 

mks.implementer.dr.value.cost_center.alternate= 

Company 

DRCOCO 


DRCOCO/ 

DRDVDV 

Company/division/ 

department 

DRCOCO/ 

DRDVDV/DRDPD 

Cost center 

DRCECE 

mks.implementer.dr.intmgrfield.contact= Contact 

DRCTCT 

mks.implementer.dr.intmgrfield.production_ 

environment= 

mks.implementer.dr.value.production_environment. 

alternate= 

DesignTracker 


Name 

Production 

environment 

DRPREV 

mks.implementer.dr.intmgrfield.duplicate_number= Duplicate request 

number 

DRDDNB 

mks.implementer.dr.intmgrfield.user_defined_field_1= User defined 

field #1 

DRU1UD 

Recommended 




for Implementer 

projects or Project 

type for other 

projects 

Float 

Float 

Float 

Float 


Short Text 


Short Text 


Short Text 


Short Text 

Short Text 


Short Text 

Short Text or 

Integer 

Pick or Short Text


mks.implementer.dr.intmgrfield.user_defined_field_2= User defined 

field #2 

DRU2UD 


mks.implementer.dr.intmgrfield.last_date_updated= Last date updated 

DRRUDT 

Design Request Long Text Fields 

mks.implementer.dr.intmgrfield.alternative_text= Alternatives text 

DRNRTB 

mks.implementer.dr.intmgrfield.long_description= Description 

DRNRTB 

mks.implementer.dr.intmgrfield.bulletin_board= Bulletin board 

DRNRTB 

mks.implementer.dr.intmgrfield.benefits_text= Benefits text 

DRNRTB 

mks.implementer.dr.intmgrfield.development_info= Development 

information 

DRNRTB 

mks.implementer.dr.intmgrfield.user_defined= User defined text 

DRNRTB 

mks.implementer.sr.intmgrfield.number= SR Number 

SRSRNB 

mks.implementer.sr.intmgrfield.logged_by_user_id= 

mks.implementer.sr.value.logged_by_user_id. 

alternate= 

DesignTracker 


Name 

Recommended 




Date 

Long Text 

Long Text 

Long Text 

Long Text 

Long Text 

Long Text 

Integer 

Logged by user User or Short Text 

SRLGUI 

This field is not used as the actual issue 

Created By userid; it can be assigned to 

any field. If assigned to a Short Text field, 

it can be used to store the user who 

created the DR, even if the user is not 


When assigning to a Short Text field, do 

not specify an alternate value, as the 

system verifies the user is defined in 

Implementer with an MKS Integrity 

user ID. 

mks.implementer.sr.intmgrfield.logged_date= Logged date Date 

SRLGDT 

This field is not used as the issue 

Created Date; it can be assigned to any 

field. 

451



mks.implementer.sr.intmgrfield.closed_date= Closed date 

SRCLDT 

mks.implementer.sr.intmgrfield.closed_flag= Closed flag 

SRCLFG 

mks.implementer.sr.intmgrfield.title= Title 

SRSRTT 

mks.implementer.sr.intmgrfield.type= 

mks.implementer.sr.value.type.alternate= 

mks.implementer.sr.intmgrfield.system= 

mks.implementer.sr.value.system.alternate= 

mks.implementer.sr.intmgrfield.product= 

mks.implementer.sr.value.product.alternate= 

mks.implementer.sr.intmgrfield.product_component= 

mks.implementer.sr.value.product_component. 

alternate= 

mks.implementer.sr.intmgrfield.product_version= 

mks.implementer.sr.value.product_version. 

alternate= 

452 

SR type 

SRSRTB 

System 

SRSYSY 

Product 

SRPDPD 

Product/ 

component 

SRPDPD/ 

SRCPCP 

Product/ version 

SRPDPD/ 

SRVRVR 

mks.implementer.sr.intmgrfield.expected_date= Expected date 

SREXDT 

mks.implementer.sr.intmgrfield.requested_date= Requested date 

SRRQDT 

mks.implementer.sr.intmgrfield.requester_ 

priority 

mks.implementer.sr.value.requester_priority. 

alternate= 

mks.implementer.sr.intmgrfield.benefits_priority= 

mks.implementer.sr.value.benefits_priority. 

alternate= 

mks.implementer.sr.intmgrfield.status= 

mks.implementer.sr.value.status.alternate= 

Requested priority 

SRRQPR 

Benefits priority 

SRBNPR 

Status 

SRSTST 

mks.implementer.sr.intmgrfield.estimated_effort= Estimated effort 

SRESEF 

mks.implementer.sr.intmgrfield.estimated_cost= Estimated cost 

SRESCS 

mks.implementer.sr.intmgrfield.company= 

mks.implementer.sr.value.company.alternate= 

DesignTracker 


Name 

Company 

SRCOCO 

Recommended 



Date 

Boolean 

Short Text or 

Synopsis 



Short Text 


Short Text 


Short Text 


Short Text 

Date 

Date 



State, Pick, or 

Short Text 

Float 

Float 


Short Text


mks.implementer.sr.intmgrfield.company_division= 

mks.implementer.sr.value.company_division. 

alternate= 

mks.implementer.sr.intmgrfield.company_division_ 

department= 

mks.implementer.sr.value.company_division_ 

department.alternate= 

mks.implementer.sr.intmgrfield.cost_center= 

mks.implementer.sr.value.cost_center.alternate= 



SRCOCO/ 

SRDVDV 

Company/division/ 

department 

SRCOCO/ 

SRDVDV/ 

SRDPDP 

Cost center 

SRCECE 

mks.implementer.sr.intmgrfield.contact= Contact 

SRCTCT 

mks.implementer.sr.intmgrfield.duplicate_number= Duplicate SR 

number 

SRDSNB 

mks.implementer.sr.intmgrfield.user_defined_field_1= User defined 

field #1 

SRU1UD 

mks.implementer.sr.intmgrfield.user_defined_field_2= User defined 

field #2 

SRU2UD 

mks.implementer.sr.intmgrfield.last_date_updated= Date last updated 

SRRUDT 

Service Request Long Text Fields 

DesignTracker 


Name 

mks.implementer.sr.intmgrfield.alternative_text= Alternatives text 

SXNRT 

mks.implementer.sr.intmgrfield.long_description= Description 

SXNRTB 

mks.implementer.sr.intmgrfield.benefits_text= Benefits text 

SXNRTB 

mks.implementer.sr.intmgrfield.user_defined= User defined text 

SXNRTB 

Recommended 




Short Text 


Short Text 


Short Text 

Short Text 

Short Text or 

Integer 

Short Text 

Short Text 

Date 

Long Text 

Long Text 

Long Text 

Long Text 

453


Post Conversion Considerations 

454 

Review and perform the following tasks after you have finished converting all DesignTracker 

data to MKS Integrity: 

Modify converted values 

If the alternate value was used to handle undefined values, in MKS Integrity, query for 

issues that used the alternate values for fields and modify the values as needed. For 

details, see the MKS Integrity Server 2006 Administration Guide. 

Set all users to use MKS Integrity 

In Implementer, verify the appropriate users are set to use MKS Integrity for issue 

management. For details, see “Set a User’s Default Issue Management System” on 

page 253. 

Start using the new features 

When you have successfully completed the data conversion, you can begin using the 

new features as described in the MKS Implementer 2006 User Guide. 

Each converted DR and SR retains a permanent record of the MKS Integrity location and 

issue number it converted to. Likewise, displaying a converted issue in MKS Integrity 

identifies the DR it was created from, if that field is set as recommended. This information 

provides an audit trail that is useful for cross-referencing a converted DR or SR with its 

corresponding issue in MKS Integrity, and vice versa. 

This feature requires the Issue Management System field for your Implementer user profile 

set to 2=DesignTracker. For this purpose it may be helpful to create a secondary user profile 

for a few users—one profile set to MKS Integrity and the second profile set to DesignTracker. 

Or, you can create a single default profile for DesignTracker users to use. For details, see “Set 

a User’s Default Issue Management System” on page 253. 

To display the MKS Integrity URL for a converted DR or SR 

1 From the DesignTracker Menu, use option 1, Design Requests, or option 3, Service 

Requests, to display the respective Work with panel. 

2 Select the DR or SR with option 5=Display, and press ENTER to display the request. 

The MKS Integrity URL field displays up to 120 characters of text that wraps to the next 

line as needed. As shown in the next illustration, the URL indicates the location and 

issue number the converted request mapped to. (A non converted DR or SR displays the 

text Not converted.)

Post Conversion Considerations 

455


456

A PPENDIX D 

Glossary 

Definitions of Common Implementer Terms 

D 

This appendix provides a description of the many terms used in software change 

management and throughout Implementer. Review this appendix to learn these terms 

and definitions, and understand how they relate to Implementer. 

NOTE For a description of MKS Integrity terms, see the MKS Integrity Server 

2006 Administration Guide. For a description of MKS Source terms, see the 

MKS Source 2006 User Guide. 

action An action is used to indicate the process to perform to 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 creating a 

promotion request: 

1 = Change 

2 = Create 

3 = Delete 

8 = Regen (only valid for AllFusion 2E model objects) 

9 = Recompile 

administrator The administrator sets up and configures Implementer. The 

administrator defines users, environments, environment capabilities. The administrator 

also defines the MKS Integrity parameters required in Implementer for integration. 

application path An application path refers to the standard and emergency paths 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 also 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. 

The two basic types of application paths are: 

Project path 

This term refers to the standard and emergency paths set up in Work with Projects. 

A path can be defined for each project to represent the development flow of 

member/objects associated with the project. This type of path is beneficial when 

457

Appendix D: Glossary 

458 

routinely using multiple testing environments, especially when the test environments 

are determined on a project by project basis. 

Environment path 

This term refers to the standard and emergency paths set up in Work with 

Environments. A path can be defined for each production environment, representing the 

development flow of member/objects associated with the environment. Environment 

paths provide control, while eliminating redundancy when checking out and promoting, 

by restricting access so members/objects cannot move outside of the defined flow. It also 

allows defaulting the From environment and target environment values when checking 

out and creating a promotion request. 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. 

If you use both environment paths and project paths, the project path is the default path in 

check out and create request when a project with a defined path is specified. 

NOTE Do not confuse the term application path with the term path, which refers to 

support provided by for IFS objects. 

application set Application set refers to AS/SET application sets, 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 the Implementer function that recovers members/ 

objects or backs them out of a promotion request. It is also called rollback. 

archiving Archiving refers to the duplication of an existing production source member, 

object, or file (without data) into a designated library before the to-be-implemented object is 

moved into production. You use the archive to store members and/or objects or file 

information. Members/objects are placed in the archive during the Move Request function. 

Archiving is optional. It is defined by the environment definition. You can archive up to 99 

versions of files, objects, or source. 

The archive serves two purposes. First, it supports archive recovery or the 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 AS/SET is an ADK program type designed 

to perform file-processing functions. No online display panels are involved in batch 

programs. 

binding directory A binding directory is a list of modules and service programs 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 referencing by name and type.

change controlled model A change controlled model is an AllFusion 2E model set up to 

work with Implementer. It’s model value *CHGCTL is set to that of the product library, 

MKSIM or Y2SYCM. 

Glossary 

change list A change list is an AllFusion 2E model object list defined in Implementer. You 

can explicitly create a model object list for an AllFusion 2E environment, or create one when 

you check out an AllFusion 2E model object during an editing session. This is referred to as a 

model object list in Implementer. 

check in Check in describes the process of promoting a member/object back into 

production after it is checked out. Check in removes the lock. 

check out Check out is the Implementer function that 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 work space for member/objects. After adding an item on the 

Clipboard, you can display, remove, or add more items to the Clipboard. The Clipboard 

holds the selected items until they are processed. At least one item must exist on the 

Clipboard before you can run a Clipboard function. You can select a list of items and process 

the list by another function. Once you run the function for the items, the items are listed 

within that function and removed from the Clipboard. 

co-existence Co-existence is an Implementer feature that allows you to convert 

DesignTracker DRs and SRs to MKS Integrity issues. 

compile request Compile request is an Implementer function that compiles source members 

into the work libraries and moves non source-based objects into work libraries, according to 

the migration request instructions. Developers typically perform this task. 

concurrent development Concurrent development is when two or more versions of a 

member/object exist at the same time. It is the result of checking out a member/object that is 

already checked out. 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. See also, non 

sequential development and sequential development. 

conflict When concurrent development is started, a conflict is created for that specific 

member/object. You must resolve a conflict 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 also, trigger. 

create request Create request is the Implementer function of initiating a promotion request 

for the purpose of migrating source and/or objects to production or quality assurance 

environments. Developers typically perform this task. 

459


460 

currency Currency is an AllFusion 2E model object that all other related model objects point 

to. It is an object that has usage. A non current object has no usage in the model. 

current model object The current model object is what the user can view or edit in an 

AllFusion 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 the ADK repository that refers to one or 

more files, associated fields, and associated relationships. 

design request A design request is a feature of DesignTracker used to indicate what work 

needs to be done. DesignTracker automatically installs when you install Implementer. 

NOTE If you use MKS Integrity for issue tracking with Implementer, you do not use 

DesignTracker. 

design request approval A design request approval can be: 

0 = No 

1 = Yes 

2 = Pending 

For an approval type of: 

1 = Development 

2 = Test 

3 = Production environment 

design request disposition The design request disposition can be: 

0 = Not Ready (always set to 0 when entity is added to the list) 

1 = Ready for checkout (entity is ready to be checked out) 

2 = In development (entity is checked out to development) 

3 = In quality assurance (entity is checked out and in quality assurance for testing) 

4 = Completed (entity 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. 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.

Glossary 

DLO Document Library Object (DLO) refers to a file or folder that exists in the QDLS file 

system on an iSeries. These objects, referred to in Implementer as IFS objects, are supported 

for change management. See also IFS object, IFS file, and IFS directory. 

document 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. Within Implementer, the term 

IFS object is used. 

environment An environment identifies a collection of libraries, object owners, authorized 

users, and rules about how the libraries are controlled by Implementer. See also related 

environment. 

environment ID An environment ID is a sequential number assigned to each target 

environment on a promotion request. The 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 


environment library list Environment library list is a list of up to 250 libraries used for 

compilation in the environment. Of these, 248 entries are available for your use. The last two 

entries are reserved for QTEMP and the Implementer work library on the promotion request. 

The environment library list is used also when processing special commands for a request. 

environment type An environment type defines whether an environment is for production 

(*PRD), quality assurance (*QAC), or development (*TST). It enforces check out an 

promotion restrictions and ensures the developers do 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 system. 

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 vendors. Implementer creates an export list whenever it 

copies LANSA objects from one partition to another partition. 

file A file refers to the support Implementer provides for traditional OS/400 files and 

objects in the IFS (referred to as IFS files). To avoid confusion, whenever an IFS file object is 

referenced in Implementer, the term IFS file is used. 

Implementer supports all traditional OS/400 files, for example, physical files, logical files, 

display files, message files, printer files, SQL tables, and SQL indices and views. See also IFS 

file. 

folder A folder represents the OS/400 term for a collection of documents in a single 

location. The term is used as part of support Implementer provides for IFS objects. It 

corresponds to IFS directory. See also IFS directory. 

461


462 

function A function describes a particular Implementer 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 AllFusion 2E model object you can promote (FUN); an 

executable program or collection of programs. 

function redirection Function redirection relates to when an AllFusion 2E function is 

checked out and a new version of that function is created. Function redirection occurs to 

ensure the selected version of the model object is current and has its internal references 

directed towards the other object in the model. See also, currency. 

IFS directory IFS directory is the location of an IFS file. When used in this capacity, the 

directory usually refers to the full directory path. See also path. 

This term is used as part of support Implementer provides for IFS objects. The term 

corresponds to the OS/400 term, folder. In Implementer, it is referred to as a directory. 

IFS file IFS file refers to the contents of IFS directories on the iSeries. 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 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 

represented by a dot (.). Any name longer than eight characters and any extension longer 

than six characters is converted (allowing one position for the “.”), for example: 

IFS File Name Member/Object Name Object Code 

HelloiSeriesWorld.class HELLOiSe~1 .CLASS 

HelloiSeriesWorld HELLOiSe~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. Environment relative 

names greater than 100 characters require setting up an environment with a deeper 

development path structure. See also IFS directory. 

IFS object IFS object refers to the objects (IFS files and directories) stored in the IFS space on 

the iSeries (IFS objects are not stored in libraries). It represents the IFS file names, directory 

names, or complete directory contents specified in check out and create request. IFS files and 

directories appear on reports and in audits. Implementer supports the following IFS objects: 

IFS Files 

You can check out or promote individual IFS files by using the object name and object 

code. Each file checked out or promoted is listed on reports and audits. 

IFS Directories 

You can check out or promote the contents of a subdirectory (including subdirectory 

contents) by using the backward slash (\) object code. For example, if you check out or

Glossary 

promote \dir2, all files and directories listed in subdirectory 2 are included. On reports 

and audits only the directory name (dir2) is listed. 

*.* 

You can check out or promote the contents of an environment’s directory (including 

files, subdirectories, and contents) by specifying *.* for the object name, and a 

backward slash (\) for the object code. For example, if you check out or promote 

IFS\dir using *.*, all IFS files and directories in IFS\dir are included. Reports and 

audits show member/object *.* to indicate that all contents were affected. 

implementation object An implementation object is the resulting OS/400 source and objects 

created from the generation of an AllFusion 2E model object. For example, a function usually 

creates 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 a remote system. Software can be distributed to the Implementer Receiver. 

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. 

JDE JDE is the abbreviation for J.D. Edwards (now PeopleSoft World). 

keyword restriction A keyword restriction is a facility that restricts access to object code 

command keywords. 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 OS/400 executable program created by LANSA 

and user-defined. 

LANSA objects LANSA objects are objects created in LANSA, such as files, fields, processes, 

and functions. They are not necessarily OS/400 objects. 

lock A lock is applied to a member/object when it is checked out. The lock 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. 

An Emergency lock is the user action that created the lock through an emergency check 

out. 

member/object A member/object is a member and/or object under Implementer control. 

It can be an object or source stored in a library, an element managed by a CASE tool (such as 

AllFusion 2E), or an IFS file. For example, it refers to an object for a data area, but for an RPG 

program it refers to the member and object. 

model object A model object is an AllFusion 2E object you can check out. AllFusion 2E has 

eight object types you can check out: access paths (ACP), applications (APP), arrays (ARR), 

conditions (CND), field (FLD), files (FIL), functions (FUN), and messages (MSG). 

463


464 

model object list Model object list is an AllFusion 2E feature that allows grouping some of 

the objects in a model into a named list. For change control purposes, model objects are 

checked out to lists to indicate changes were made or are planned. The model object lists are 

attached to the AllFusion 2E model and can be selected for AllFusion 2E promotions. Once 

you use a model object list for check out, it becomes a change list. 

model object name Model object name is the 25-character name given to an AllFusion 2E 

model object. 

move request Move request is an Implementer task that moves all object/source from the 

environments or libraries to the target environments. It performs any request instructions 

that impact production data, for example, MRGMSGF. In addition, it moves previous 

versions of source and objects to the archive libraries before the move, if specified. 

My Workbench My Workbench is a panel that allows developers to perform all necessary 

development work. The panel contains the items to be worked on and provides access to all 

tools needed 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. 

non sequential development Non sequential development is the term used when the lock 

for a member/object does not follow the defined, standard development path. Any deviation 

from the defined workflow for a specific member is non sequential development. See also, 

sequential development and concurrent development. 

object code An object code defines a type of object and/or member to be promoted. The 

object code in Implementer combines information from the OS/400 object type and source 

type. Many object codes are shipped with Implementer and others can be user-defined. 

SQL-based objects use specific SQL object codes. For IFS files, the object code is the file 

extension. 

owning model object The owning model object is the name of a model object that owns 

another model object. For example, an access path (ACP) model object is always owned by a 

file (FIL) object. Not all model objects have an owning model object. 

partition A partition is a division of a LANSA system that has its own field reference 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 


path A path 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 backward slash (\). For 

example, to identify the path of the SYSTEM directory nested in the WINDOWS directory that 

stems from the root directory, the notation is \WINDOWS\SYSTEM. See also 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. 

Glossary 

Environment path is the path specified at the environment level and 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 Avoid confusing the term path with the term application path, which refers to 

both standard and emergency paths for projects and environments. 

PeopleSoft World data dictionary element A data dictionary element refers to records in a 

dictionary for every field used in the system. This file controls how a field performs and edits 

on the screen and report. It also controls the edit processes of the field for validation. 

PeopleSoft World DREAM Writer A DREAM Writer has two parts that break down as 

follows: data selection that is translated to OPNQRYF or logical, and processing options that 

are user-controlled, program passed parameters. 

PeopleSoft World menu Menus are data records keyed to a menu name. This allows changes 

to menus without the need for programming. 

PeopleSoft World soft coding or vocabulary override Soft coding or vocabulary override 

refers to literals on screens that are not constants in the DDS of a screen object, but are 

retrieved from a file that is keyed to a program name. This allows changes to literals without 

the need for programming. 

PeopleSoft World software inventory or member master Software inventory or member 

master is a file that records each object in PeopleSoft World. This file contains the general 

severity level for compilation and other details for PeopleSoft World integration. 

PeopleSoft World soft coding items These are soft coding items supported by PeopleSoft 

World, such as user-defined codes, DREAM Writers, Member Master, Data Dictionary, Soft 

Coding, and Menus. 

PeopleSoft World traditional object These are traditional objects that require PeopleSoft 

World compiling, such as RPG programs, CL programs, and Assemblers (ASM). 

PeopleSoft World user-defined code (UDC) User-defined code is a generic table system for 

data field validation. The table system is controlled by three keys: System number, Table 

name, Element. 

primary target environment A primary target environment is the first target environment in 

a series of multiple target environments. The primary target environment is used in create 

request to check the existence of the target members/objects, to determine if the action for a 

member/object is create or change. 

465


466 

process A process is a logical grouping of related functions, for example, a process called 

ORDERENTRY consists of a number of 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. The term also refers to the entire process of returning 

a member/object back into production after it is checked out (compile and promote from 

development to QA, and promote from QA to production). 

promotion request A promotion request is a collection of related source members, sourcebased 

objects, non source based objects, or non OS/400 objects to be promoted to production 

libraries or quality assurance. 

qualified name A qualified name refers to a path and file name. This term is used as part of 

the support Implementer provides for IFS objects. For example, the qualified name of file 

SYSEDIT.EXE stored in the directory WINDOWS\SYSTEM is 

\WINDOWS\SYSTEM\SYSEDIT.EXE. 

related environment A related environment is the relationship of one environment to other 

environments in the format of an ordered list. The 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 A 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 individual who creates a promotion request. 

request number A request number is the unique, four-character alphanumeric value 

assigned by Implementer when a new promotion request is created. It is used to identify the 

promotion request. Beginning with number 0001, the number increments by one for each 

new promotion request until number 9999 is reached. When this occurs, the left most position 

changes to an alpha character and the other positions reset to 0 (zero). Reading from right to 

left, this cycle continues until each position goes through the range 0–9, and A–Z. When 

number ZZZZ is reached, the number scheme automatically resets to number 0001. 

request status The request status defines where a promotion request is in the promotion 

cycle. It describes what steps were performed for the request and what remains to be done. 

For a complete listing of status codes, see “Request Inquiry” in the MKS Implementer 2006 

User Guide. 

required object Required objects are traditional source and executable objects generated 

from AS/SET program definitions. It contrasts the related object concept used in 

Implementer for traditional objects, which relates logical files to physicals and the programs 

that refer to them.

Glossary 

reset authorities Reset authorities is an Implementer function that revokes all object 

authorities for the libraries as specified in the environment, and then grants object authorities 

based on the authorities from the environment authority table. 

sequential development Sequential development is the term used when all locks for a 

member/object follow the defined standard development path and never deviate from the 

defined workflow. See also, non sequential development and concurrent development. 

session model list A session model list is the default model object list assigned when you 

begin an AllFusion 2E editing session. The 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 *DSNR on the Change AllFusion 2E User Capabilities panel or the AllFusion 2E 

Designer (*DSNR) menu. You can also have model users create and use their own object 

model list. 

stage library A stage library is a 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 physical 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. In order, 

the steps are as follows: 

Model copy, only applies to AllFusion 2E special environments. 

Export, only applies to LANSA special environments. 

Compile, the compile step is optional. 

Distribute, only applies to requests that contain remote target environments. 

Move, required for every request. 

subdirectory A subdirectory refers to a directory and its contents that are stored within 

another directory. Subdirectories are included in the support Implementer provides for IFS 

objects. The term corresponds to the OS/400 term, folder. In Implementer, this is referred to 

as a directory. See also IFS directory. 

surrogate A surrogate is the internal identifier assigned to each AllFusion 2E model object. 

target environment group A target environment group is a group of environments 

promoted to at the same time. A target environment group is used when you create a 

promotion request to promote to more than one environment, eliminating the need to select 

each environment separately 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 

467


468 

preserve program to table integrity by checking on or changing data in a consistent manner. 

They help maintain the integrity of a database by preventing incorrect, unauthorized, or 

inconsistent changes to data. See also, constraint. 

version For AllFusion 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 Implementer when you check out a model object that 

is previously checked out, and when archiving 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 is the current version. 

workbench See My Workbench. 

work library A work library is a temporary library used during promotion to ensure the 

orderly movement of source and objects into the correct target libraries. The work libraries 

only exist while a promotion request is open (the status is not complete).

Index 

*GRANT authority method 96, 373 

*KEEP authority method 96, 373 

A 

ABSTRACT integration 

setup 304 

ACLs (Access Control Lists) 

Domino ACLs 

set in check out 348 

set in promotion 349 

Lotus Domino integration 345 

QNOTES directory authority 344 

action 

defined 457 

Activity Report 375, 396 

administrator 

Implementer, defined 457 

AllFusion 2E integration 

command considerations 304 

environment cleanup 404 

library considerations 304 

message versioning 307 

model check out considerations 307 

model value YSYSCHG 307 

object codes for model objects 464 

product library 406 

receiver library 413 

remote QA environment cleanup 384 

setup for EXCUSRSRC and EXCUSRPGM 

308 

American Software integration 

setup considerations 313 

AOS Message Manager integration 

setup 315 

Apache Web Server 

browser based development 

server requirements 156 

server setup 158 

APPC programs 165 

application path 

defined 457 

environment path setup 102 

project path setup 142 

using environment groups 125 

application set 

defined 458 

apply pending changes 

IAPYPNDCHG command 258 

MKS Integrity changes report 258 

to MKS Integrity 258 

architecture 

client/server 196 

multi tiered 196 

server 198 

software 198 

archive recovery 

defined 458 

archive reports 

Archives by Environment 383 

Archives by Request 383 

Archives per Tape 383 

archive to tape 379 

change volume ID 193, 379 

menu (IMARCTAP) 380 

reports 383 

restoring 193, 382 

saving 381 

submit to batch 381, 382, 383 

with third party utility 322 

Archive to Tape menu (IMARCTAP) 192, 379 

archiving 

defined 458 

LANSA requests 330 


to tape 

IMARCTAP data area 192, 379 

setting up for 379 

third-party utility support 411 

AS/SET integration 

ADK object code setup 317 

application sets setup 316 

archiving setup 317 

capabilities for generated objects 318 

environment group setup 317 

469

Index 

environment setup 107 

promoting generated objects 319 

setup overview 316 

special characteristics 317 

system control maintenance setup 316 

assessing development process 204 

associate calls update 

console method 328 

history logs 327 

setup 325 

silent method 328 

authority 

Capability Wizard for setup 80 

MWIPROD 117 

QSECOFR 117 

restricting OS/400 security 79 

security data areas 412 

authority method 

*GRANT 96, 373 

*KEEP 96, 373 

B 

batch programs for AS/SET 

defined 458 

binding directory 

defined 458 

BPCS integration 

deactivate standard object codes 322 

setup 320 

BRMS integration 322, 380 

build list 118 

different source and object names 118 

Environment Repository Report 122 

for IFS objects 119 

IBLDMBOLST command option 119 

running a build 119 


stamping object revision numbers 118 

build member/object list, see build list 

C 

capabilities, state based 208 

Capability Wizard 

command buttons 389 

customizing user capabilities 394 

feature overview 385 

installing 

on desktop 387 

on Windows 386 

470 

verifying TCP/IP connectivity 386 

requirements 386 

selecting environments 391 

selecting users 390 

starting and using 389 

updating Implementer 395 

working with capability details 393 

change 

applying pending changes 258 

managing and tracking 198–199 

pending 257 

change controlled model 

defined 459 

change list 

defined 459 

change repository 


for traditional objects 376 

change request 

managing, overview 57 

process overview 59 

changes report 

MKS Integrity 258 

check in 

defined 459 

check out 

defined 459 

enable one step checkout 77 

set Domino ACLs 348 

client/server architecture 196 

clipboard 

defined 459 

CODE/400 integration 

setup 323 

co-existing issue management systems 

convert DesignTracker data to issues 431 

enable co-existence 249 


promotion considerations 248 

set last DR number 250 

set next issue number 252 

set user’s default system 253 

Cognos integration 

setup 362–364 

commands 

IAPYPNDCHG, Apply Pending Changes 

258 

IBLDMBOLST, Build List 119 

ICGHREP, Change Repository 376 

ICHGREPIFS, Change Repository IFS 377 

ICHGRMTRQS, Change Remote Request 

185

ICRTRQS, Create Request 36 

ICVTDT, Convert DT to MKS Integrity 438 

IDBPRG, Purge History 376 

IDLTLIBREF, Delete Library References 

378 

IDSPSVRLOG, Display Server Log 225 

IEDTLIBL, Edit Library List 415 

IEXCCKOCMD, Execute Checkout 349 

IEXCRQSDTL, Execute Request Detail 349 

IMARCTAP Archive to Tape 380 

IMARCTAP, Archive to Tape 192, 379 

IPRTREPRPT, Repository Report 123 

ISETDOMACL, Set Domino ACL 347 

IUPDCI, Update MKS Integrity 240 

IVFYRPT, Verification Report 124 

special commands by environment 103 

STRCM Start AllFusion 2E CM 10 

STRCR Start AllFusion 2E CM Receiver 10 

STRIM Start Implementer 10 

STRIM Start Implementer, keywords 11 

STRIR Start Implementer Receiver 10 

STRTCPSVR, Start TCP/IP Server 158 

WRKHTTPCFG, Work with HTTP 

Configuration 157 

comments 

in create request 69 

communications 

emergency update mode 255–259 

mode name 428 

options 428 

remote network identifier 429 

*LOC 429 

*NETATR 429 

*NONE 429 

name 429 

SNADS configuration 179 

TCP/IP configuration 173 

communications user profile data area 403 

compile listing 

delete after promotion 66 

compile request 

defined 459 

concurrent development 

concurrent development scope 71 

defined 459 

resolve conflicts capability 111 

user capability 111 

configuring property files 

conversion properties file 441 

DTBridge properties file 300, 325 

conflict request 

defined 459 

constraint 

defined 459 

controlling remote job schedules 181 

conventions 4 

conversion properties file 445–453 

convert to MKS Integrity 

conversion methods 244 

prerequisites 248 

with data retention 

basic conversion example 437 


data conversion rules 433 


generate the conversion file 445 

ICVTDT command 438 

mapping data 441 

MKS assistance options 431 

organizational activities 436 

overview of data conversion 432 

run the conversion 249 

see also, co-existing 

set last DR number 250 



without data retention 

overview 244 

run the conversion 244 

Convert to MKS Integrity (ICVTDT) command 

438 

create request 

create in batch 69 

default promotion method 69 

defined 459 

optimize PF promotions 69 

require comments feature 69 

currency 

defined 460 

current model object 

defined 460 

customer care options 5 

customizing Implementer 414 

D 

data area 

changing 402 

for AllFusion 2E 402 

IMADDOBJ, add related for service 

programs 402 

IMARCTAP, archive to tape libraries 402 

IMBNDUPD, Pathfinder update 402 

Index 

471

Index 

472 

IMBYPSRJW, bypass window on reject 

410 

IMCMNUSR, communications user 

profile 172, 403 

IMCOREJ, check out/reject options 403 

IMDLTFRMUP, delete user programs 404 

IMDLTFRMUS, delete user source 404 

IMDLTLOCK, delete locks 404 

IMDLYJOB, delay evoked jobs 404 

IMDOMDATA, Domino server data 

directory 339, 405 

IMDSPMSG, display message panel 405 

IMEMGSTP, emergency through step 405 

IMFTPPASV, FTP Passive Mode 174, 405 

IMJDKVER, JDK Version 241 

IMJDKVER, JDK version 406 

IMLIBRARY, Implementer library name 

406 

IMLNMSG, LANSA error messages 408 

IMLNPSO, LANSA partition security 

officer 408 

IMLNTSK, LANSA task usage 332, 408 

IMLOGCL, change logging level 407 

IMMULTJOB, submit multiple jobs 407 

IMMULTOBJ, multiple object single 

source check out 407 

IMMULTRQS, same item on multiple 

requests 408 

IMPATHSLSH, path slash 409 

IMPKGPRC, process package 409 

IMPRFX, work library prefix 409 

IMPRVCMDS, create commands and 

TGTRLS parameter 408 

IMRCLAGRP, reclaim activation group 

410 

IMREJECT, remove objects on QA reject 

409 

IMRETFILID, return file and member ID 

after promotion 410 

IMSEQRQS, sequential request 411 

IMSPCCMD, special commands 411 

IMSVPGM, save program name 323, 411 

IMTSTMOD, promotion batch steps test 

mode 411 

IMWLCLNUP, Work Library Cleanup 414 

IMWRNTRGLF, invalid logical file control 

412 

IRJOBQ, remote job queue 376, 413 

IRSBMMTD, remote job submission 

method 376, 413, 414 

ITAPEVOLUM next tape label for 

archives 193, 379 

ITAPEVOLUM, next tape label for 

archives 412 

LFREFOBJ, reference file to set LF 

authority 412 

object codes for promotion 137 

PFREFOBJ, reference file to set PF 

authority 412 

RCVLIB, Receiver library name 413 

retain values when promoting 136 

SDMAUTUSR, authorized user profile for 

IFS objects 413 

data model 

defined 460 

database purge, see purge history 

deleting tutorial data 396 

design request 

approvals, defined 460 

convert to issue 431 

defined 460 

disposition, defined 460 

object stamping 

overview 146 

setup 146, 147 

require for check out 87 

status, defined 460 

DesignTracker 

convert to MKS Integrity 

overview 243 

with data retention 247 

without data retention 244 

development process, assessing 204 

directory 

defined 462 

distribution 

APPC programs 165 

communication line considerations 166 

APPN 166 

network control program (NCP) 167 

switched line 166 

concepts 161 

database file considerations 164 

Implementer Receiver 162 

integration with local promotions 163 

LPAR support 162 

move step considerations 189 

multiple system development 189 

performance 191 

request number consideration 191 

options 

single step 180 

two step 180 

problem determination 193

emote initiated moves 181 

remote source members 163 

simultaneous to multiple remotes 181 

substeps described 

receive network file 189 

restore from save files 189 

save work libraries 189 

send work libraries 189 

distribution methods 164 

SDMCom 164, 427 

SNADS 165 

tape 165 

TCP/IP 165, 173 

DLO 

defined 461 

document 

defined 461 

Domino Designer, see Lotus Domino 

integration 

DTBridge 

installing on desktop 298 

installing on Windows 297 

properties file 299–300 

accessing and updating 299 

general properties 301 

MKS Integrity properties 300 

SQL for help desk integration 327 

SupportCenter properties 326 

requirements for using 297 

verifying TCP/IP connectivity 297 

E 

e-mail messaging 72 


activate/deactivate 257 

active mode 256 

apply pending changes 257 

changing modes 255 

development considerations 256 

inactive mode 256 

MWIPROD requirement 236, 256 

environment 

add dependencies to request 86 

add related objects to request 86 

source of information 88 

application development path 102 

build repository list 117–121 

clearing remote QA 384 

delete an environment 96 

delete objects after promotion 92 

distinguish local and remote 89 

environment group 126 

environment special commands 103 


library authority setup 68 

library list 

considerations 97 

defined 461 

how used 96 

setup 97 

name consideration for MKS Source 82 

object code 

deactivate for BPCS 322 

overrides 91 

overrides setup 92 

object name rules 138 

related environment 100 

defined 466 

remove object in from lib/env 87 

remove source in from lib/env 87 

require issue or design request 87 

retain request on remote 90 

setup 

AS/SET requirements 107 

basic setup 82–91 


LANSA requirements 107 

local development 419–420 

local production 418–419 

local quality assurance 420–421 

local user acceptance 422–423 

PeopleSoft World requirements 108 

remote production 423–430 

TCP/IP setup 174 

types 

defined 461 

user capabilities 109–112 

environment authorities 

Capability Wizard 80 

establish or reset 372 

environment group 


on application path 125 

environment ID 

defined 461 

environment path 

defined 458 

Environment Report 106 


Environment Verification Report 123 

Execute Checkout (IEXCCKOCMD) command 

349 

Index 

473

Index 

Execute Request Detail (IEXCRQSDTL) 

command 349 

export 

defined 461 

export list 

defined 461 

export to Implementer from MKS Source 


property file setup 302 

F 

file 

defined 461 

File Transfer Protocol, see FTP 

firewall configuration for TCP/IP 175 

folder 

defined 461 

FTP 

for TCP/IP distribution 175 

function 

defined 463 

function keys 

changing, menu option 397 

function redirection 

defined 462 

G 

getting help 5 

getting started with Implementer 1 

glossary of terms 457 

H 

Hawkeye integration 


setup 354–355 

help desk integration 324–328 



setup 

DTBridge properties file 325 

SQL statements for properties 327 

transaction history logs 327 

using the integration 

overview 327 

update calls console method 328 

update calls silent method 328 

HTTP server 

browser based development 

474 

I 

configuring 157 

server port requirements 156 

server security requirements 156 

IAPYPNDCHG, Apply Pending Changes 

command 258 

IASP 

requirements for using 154 

IBLDMBOLST Build List command 119 

IBM Backup Restore Management System, see 

BRMS integration 

IBM WebSphere Development Studio Client for 

iSeries, see WDSc integration 

ICHGREP Change Repository command 376 

ICHGREPIFS Change Repository IFS command 

377 

ICHGRMTRQS Change Remote Request 

command 185 

IDBPRG Purge History command 376 

IDLTLIBREF Delete Library References 

command 378 

IEDTLIBL Edit Library List command 415 

upgrade considerations 415 

IEXCCKOCMD, Execute Checkout command 

349 

IEXCRQSDTL, Execute Request Detail 

command 346, 349 

IFS directory 

defined 462 

IFS object 

defined 462 

IFS object management 

automatic object code setup 68 

browser-based development 

HTTP configuration 157 

HTTP mapping directives 157 

HTTP method directives 157 

HTTP server security 157 

iSeries setup 156 

starting the TCP/IP server 158 


mounted drive setup 159 

IMADDOBJ data area 402 

IMARCTAP command 380 

IMARCTAP data area 402 

IMBNDUPD data area 402 

IMBYPSRJW data area 410 

IMCMNUSR data area 172, 403 

IMCOM

end before backup 176 

TCP/IP job queue 176 

TCP/IP subsystem 176 

IMCOMCTL 

command parameters 177 

IMCOREJ data area 403 

IMDLTFRMUP data area 404 

IMDLTFRMUS data area 404 

IMDLTLOCK data area 404 

IMDLYJOB data area 404 

IMDOMDATA data area 339, 405 

IMDSPMSG data area 405 

IMEMGSTP data area 405 

IMFTPPASV data area 405 

IMJDKVER data area 241, 406 

IMLIBRARY data area 406 

IMLNMSG data area 408 

IMLNPSO data area 408 

IMLNTSK data area 332, 408 

IMLOGCL data area 407 

IMMULTJOB data area 407 

IMMULTOBJ data area 407 

IMMULTRQS data area 408 

IMPATHSLSH data area 409 

IMPKGPRC, data area 409 

implementation object 

defined 463 


defined 463 

local partitioning (LPAR) 162 

see also, remote 

Implementer Server 

configuring the server 217–219 

IDSPSVRLOG command 225 

install and configure on iSeries 218 

install and configure on PC 220 

install and configure on UNIX 222 

log files to retain 219 

managing the server 223–225 

patches and PTFs 225 

purge server log files 225 

server log file 225 

status descriptions 219 

time zone offset 220 

troubleshooting 225 

import 

defined 463 

IMPRFX data area 409 

IMPRVCMDS data area 408 

IMRCLAGRP data area 410 

IMREJECT data area 409 

IMRETFILID data area 410 

IMSEQRQS data area 411 

IMSPCCMD data area 411 

IMSVPGM data area 411 

IMSYSLIB considerations 154 

IMTSTMOD data area 411 

IMWLCLNUP data area 414 

IMWRNTRGLF data area 412 

Independent Auxiliary Storage Pool, see IASP 

installing Implementer 2 

Integrated File System, see IFS 

integrated solutions 

change management 50 

change request process overview 58 

development lifecycle overview 52 

iSeries component overview 198 

iSeries management 50 

managing change requests overview 53 

multi tiered architecture 197 

overview 196 

process and workflow 198 

software configuration management 50 

IPRTREPRPT, Repository Report 123 

IRJOBQ, remote job queue data area 376, 413 

IRSBMMTD, remote job submission data area 

376, 414 

ISAVARC Save Archives to Tape command 

192, 379 

ISETDOMACL, Set Domino ACL command 

347 

ISGNDOMDB, Sign Domino Database 

command 354 

ISNDMAIL command 72 

issue 

convert DesignTracker data to 431 

environment issue state 89 

manage, overview 198 

object stamping setup 146, 147 

require for check out 87 

issue types 

defined 198 

relationships 199 

ITAPEVOLUM data area 193, 379, 412 

IUPDCI, Update MKS Integrity command 240 

IVFYRPT, Environment Verification Report 124 

J 

J.D. Edwards, see PeopleSoft World integration 

JDE 

defined 463 

see also, PeopleSoft World integration 

Index 

475

Index 

job description 

MWIJOBD 

AS/SET 316 

LANSA 329 

library list considerations 97 

job overrides 

for purge history 376 

submitting 372 

K 

keyword restriction 

defined 463 

L 

LANSA integration 

archiving 330 

data areas 

IMLNMSG, error messaging 408 

IMLNPSO, partition security officer 

408 

IMLNTSK, task tracking and Visual 

LANSA 332, 408 


integration overview 328 

MWIJOBD job description 329 

object codes 

for LANSA objects 331 

same file and partition 331 

setting up 134 

objects 

defined 463 

partition security officer 408 

stop promotion by message ID 331 

task tracking 


setting up 332 

Visual LANSA 332–333 

IMLNTSK data area 408 

requirements and setting up 332 

Web interface setup 328 

Lawson Software integration 333 

level check 

incorrect library list 97 

LFREFOBJ data area 412 

library 

establish authorities 

after changing 374 

disallow unauthorized access 374 

incorrect authority set 374 

476 

restrict external access 374 

library authority setup 68 

library list 

considerations for MWIJOBD job 

description 97 

Edit Library List (IEDTLIBL) command 

415 

environment library list 96 

for special commands 96 

level check if incorrect 97 

system library list requirements 154 

third party integration considerations 97 

local partitioning (LPAR) support 161 

lock 

defined 463 

logging CL statements 407 

Lotus Domino integration 336 

ACLs 

set in check out 348 

set in promotion 349 

adding custom tools 340 

adding SmartIcons 342 

database signing 

agent signing application 352 

Domino setup 351–352 

Implementer setup 352–354 

ISGNDOMDB command 354 

key considerations 351 

upgrade considerations 352 

Domino server URL 72 

IMDOMDATA data area 339 

integration requirements 338 

managing NSF and NTF objects 337 

setup 

adding custom tools 340 

adding SmartIcons 342 

defining ACL directives 345 

Domino Designer setup 340 

Implementer setup 339 

iSeries setup and configuration 339 

QNOTES directory authority for 

ACLs 344 

M 

managing 

issues 198, 199 

states 208–212 

member/object 

defined 463 

member/object list

for different source/object names 118 

menus 

command options, see Start Implementer 

(STRIM) command 

Implementer Menu 11 

messages 

logging level 408 

MKS Integrity integration 

assessing process 204 

changes report 258 

convert to MKS Integrity 243–254 

conversion methods 244 

converting data 431–453 

set last allowed DR number 250 



with data retention 247 

without data retention 244 

current status 229 

default issue management system 228 

development scenario 60 

DTBridge 

IUPDCI special command setup 242 

update from Implementer 241 


activate/deactivate 257 

active mode 256 

apply pending changes 257 

changing modes 255 

development considerations 256 

inactive mode 256 

environments 

issue state 89 

require issue in checkout 87 

setting up 203–240 

communication parameters 229 

emergency mode authority 235 

environments 237 

Implementer setup 216 

issue management system 228 

managing states 208 

MKS Integrity parameters in 

Implementer 226 

overriding issue states 238 

promote from MKS Integrity 212– 

216, 242–243 

promotion path status entries 233 

require issues in check out 237 

state based capabilities 208 

states in Implementer 233–235 

updating state changes 234 

user profiles 235 


system requirements 202, 261 

user for MKS Integrity Server 74 

MKS Source integration 

archive source for object code 132 

export to Implementer 


property file setup 302 

Implementer setup and administration 

274–295 

define MKS Source in Implementer 

275 

define object codes 278 

product/version and development 

path 283 

product/version environments and 

population 286 

product/version/release and 

checkpointing 286 

products and source archiving 280 

MKS Source setup 262–274 

create base projects 263 

create Implementer group 264 

create integration user 264 

modify Integrity Server 

communication file 206 

set MKS Source policies 265 

prepare for next release 293 

prepare for next version 293 

process and workflow 260 


MKSIM library data area 406 

MKSIM product library 


system library list 154 

MKSIR product library 

RCVLIB data area 413 

system library list 154 

model object 

defined 463 

model object list 

defined 464 

model object name 

defined 464 

model value YSYSCHG 307 

mounted drive setup for IFS 159 

move request 

defined 464 

multi tiered architecture 196, 197 

multi-platform scenarios 49–61 

change management 50 

change request process overview 58 

Index 

477

Index 

development lifecycle 52 

iSeries management 50 

managing change requests overview 53 

software configuration management 50 

MWIJOBD job description 


MWIPROD user profile 

authority and object owner 117 

SNADS user ID 429 

My Workbench 

defined 464 

N 

network configuration 

environment examples 

local location name 428 

remote location name 428 

system name 428 

target release 428 


setup for remote deployment 168 

SNA distribution setup 168 

TCP/IP distribution setup 169 

NewVersion 

applying new vendor release 35 

non-sequential development 

defined 464 

O 

object code 

AllFusion 2E model objects 133 

archive source in MKS Source 132 

auto-create for IFS objects 68 

changing 129 

deactivating 128 

deleting IFS object codes 135 

DTAARA to copy from library 137 

DTAARAR to retain existing value 137 

environment build list 119 

environment overrides 91, 92, 133 

for AS/SET special characteristics 134 

for DDM support 135 


for LANSA 133, 134, 331 

Web interface setup 331 

for PeopleSoft World 133, 134 

functional purpose 137 

object name rules 137 

reactivating 129 

478 

repository maintenance 376 

set data area value in promotion 137 

user profile overrides 80 

object name rules 

all object codes/specific environment 141 


name validation 137 

rule maintenance 137 

specific object code/all environments 141 

specific object code/environment 138 

object version stamping 

activate issue or DR stamping 70 

activate object version stamping 70 

build repository to set version 118 


initialize version numbers 146 

setup 147 

version methods 147 

MKS Source integration 147 

user defined program 71 

version number methodology 70 


OS/400 

changing the system name 154 

commands 

DSPNETA 154 

RSTLIB 35 

IMSYSLIB for C development 154 

new releases 153 

previous release support 408 

restricting user authority 79 

owning model object 

defined 464 

P 

partition 

defined 464 

path 

defined 464 

see also, application path or project path 

PathFinder integration 

see Hawkeye integration 

PDM 

defining options 144 

option for ICHKOUT command 145 

option for ICRTRQS command 145 

pending changes 

applying 257, 258 

PeopleSoft World integration 

common library setup 108

data dictionary 

defined 465 

DREAM Writer 

defined 465 


installing on host 356 


menu 

defined 465 

object code setup 134 

printer file overrides 360 

soft coding item 

archiving setup 358 

defined 465 

software inventory or member master 

defined 465 

traditional object 

defined 465 

traditional object codes 360 

user defined code (UDC) 

defined 465 

security for 359 

PFREFOBJ data area 412 

Powerhouse integration 

setup 362 

prerequisites to using this guide 4 

previous OS/400 release support 408 

primary target environment 

defined 465 

problem determination 

logging CL statements 407 

process 

assessing product development 204 

defined 466 

project 

create a project path 142 

defined 466 


project path 

defined 458 

project tracking 

with an issue 230 

promotion 

defined 466 

enable one step promotion 77 

from Domino Designer 

set Domino ACLs 349 

from within MKS Integrity 201 

Implementer setup 242–243 

MKS Integrity setup 212–216 

one step, in batch 69 

request comments feature 69 

promotion request 

defined 466 

properties files 


DTBridge properties file 300, 325 

purge history 

function overview 374 

object status 374 

on remote system 376 

submitting job overrides 376 

Q 

QSAMPLE 

Edit Library List (IEDTLIBL) command 

415 

IMCODF user exit 415 

IMCRDF user exit 415 

IMPRMV3 user exit 415 

IMUPDLCK user exit 415 

overview of user exit programs 414 

QSECOFR user profile 

authority 117 

qualified name 

defined 466 

R 

RCVLIB data area 413 

receiver, see Implementer Receiver 

related documentation 3 

related environment 

defined 466 

related object processing 

add from path without locks 72 


maintain across environments 69 

related objects 

IMSYSLIB considerations 154 

IMSYSLIB for C development 154 

related request setup 69 

remote 

change remote request command 185 

communications options 428 

controlling remote job schedules 181 

environment, vs. local environment 89 

job queue data area (IRJOBQ) 413 

job submission method data area 

(IRSBMMTD) 414 

see also Implementer Receiver 185 

reports 

Index 

479

Index 

Activity Report 375, 396 

Archives by Environment 383 

Archives by Request Report 383 

Archives Per Tape Report 383 

Environment Report 106 


Environment Verification Report 123 

repository 

defined 466 

environment build 117–121 

report of environment status 122 

repository maintenance 


IDLTLIBREF command 378 

request number 

defined 466 

next number assigned 66 

requester 

defined 466 

required objects 

defined 466 

reset authorities 

defined 467 


IFS considerations 373 


Restore Library (RSTLIB) command 35 

restoring 

archive from tape 193, 382 

ROBOT integration 

scheduling 68 

setup 364 

S 

scenarios 

host system, overview 15 

local 25, 27, 29, 33 

modification to vendor software 33 

multiple database libraries, same 

structure 25 

multiple software releases 29 

separate production modifications 27 

multi-platform development and 

deployment 60 

release control 37 

remote 41, 43, 45, 46, 48 

check out from remote 48 

multiple remote production, same 

changes 45 

multiple remotes 46 

480 

remote production, different request 

41 

testing on remote 43 

remote production same request 39 

remote system, overview 16 

scheduling 

promotion steps 99 

setup for ROBOT 68 

SDMAUTUSR data area 

for IFS mounted drive 159 

IFS authorized user 413 

SDMCom 

distribution 165 

security officer 

authority 117 

Send eMail Message command 72 

sequential development 

defined 467 

server 

Apache Web Server for iSeries 155 

Implementer server 

setup and administration 216–225 

QHTTPSVR 158 

TCP/IP HTTP 158 

Set Domino ACL (ISETDOMACL) command 

347 

setup 

ABSTRACT integration 304 

American Software integration 313 

archive considerations 14 

archive to tape 379 

AS/SET integration 316 

BPCS integration 320 

CODE/400 integration 323 

Cognos integration 362 

environments 81–91 

general considerations 13 

Hawkeye integration 354 

LANSA integration 328 

PeopleSoft World integration 355 

Powerhouse integration 362 

projects, considerations 13 

ROBOT integration 364 

system control maintenance 65–72 

user profiles 72–80 

Sign Domino Database (ISGNDOMDB) 

command 354 

SNADS 

communication setup 179 


user address 429 

*SYSTEM 429

name 429 

user ID 429 

software architecture, common 198 

software development lifecycle 

change request process 59 

managing change requests 57 

overview 52 

source and object name 

when different 118 

special commands 

for Domino ACL support 346 

for MKS Integrity integration 242 

special commands by environment 

apply to all environments 104 


library list 96 

Start AllFusion 2E CM (STRCM) command 11 

Start AllFusion 2E CM Receiver (STRCR) 

command 10 

Start Implementer (STRIM) command 

keywords and options 11 

menu options 10 

Start Implementer Receiver (STRIR) command 

10 

Start TCP/IP Server (STRTCPSVR) command 

158 

state 208–212 


state setup 232–235 

detail field descriptions 234 

promotion path status entries 233 

updating state changes 234 

step 

defined 467 

Structured Query Language (SQL) 

for help desk integration 327 

submitting 

job overrides 372 

multiple jobs 407 

support options 5 

surrogate 

defined 467 


add related objects from path 72 

assign version number method 70 

cross environment related objects 69 

default SMTP server 72 


next request number 66 

object version stamping 70 

one step promotion in batch 69 


promotion request comments 69 

require issue or DR stamping 70 


unique versioning programs 71 

system library list 

MKSIM library 154 

MKSIR library 154 

system name 

change OS/400 name 154 

T 

tape 


tape archiving 379 

target environment group 

defined 467 

TCP/IP 

adding server security 157 


distribution method 173 


firewall configuration 175 

FTP passive mode 174, 405 

HTTP server port requirements 156 

HTTP server security requirements 156 

IMCOM job queue 176 

IMCOM subsystem 176 

network configuration setup 169 

OS/400 FTP service 175 

overview 173 

set up considerations, additional 175 

starting the server 158 

STRTCPSVR, Start TCP/IP Server 

command 158 

verifying DTBridge connection 297 

TGTRLS parameter 408 

third party integrations 

BRMS 322, 380 

deactivate object codes 127 

Lawson Software 333 

WDSc 365 

tracking change 198–199 

trigger 

defined 467 

tutorial data, deleting 396 

types 

defined 198 

typographical conventions 4 

Index 

481

Index 

U 

Uniform Resource Locator, see URL 

Update MKS Integrity (IUPDCI) command 240 

upgrading Implementer 2 

IEDTLIBL command considerations 415 

URL 

for Domino Designer integration 340 

user authority 

Capability Wizard 385 

to environment 109–112 

User Capability Wizard, see Capability Wizard 

385 

user environment capabilities 80 

user exit program 

customizing Implementer 414 

IMCODF 415 

IMCOMO8 415 

IMCRDF 415 

IMPRMV3 415 

IMUPDLCK 415 

user profile 

enrolling in Implementer 72 

environment capabilities 80 

for communications 403 


maintain customer setup 78 

maintain product versions setup 78 

maintain products setup 78 

MKS Integrity user 74 

MWIPROD user profile 429 

object code overrides 80 

one step checkout setup 77 

one step promotion setup 77 

override remove from src/obj 75 

QSECOFR user profile 117 

remove src/obj in from library 76 

user program and source 

remove during promotion 404 

utilities 

clear remote environment 384 

purge host environment history 374 

purge remote environment history 376 

repository maintenance 376 

System Control Maintenance 65 

V 

version 

AllFusion 2E, defined 468 

482 

version group 

AllFusion 2E, defined 468 

versioning 

build list to set object version 118 

initializing version numbers 146 

issue or DR object stamping 


setup 146, 147 

object stamping overview 146 

object version stamping setup 147 

versioning methods 147 

Visual LANSA, see LANSA integration 

W 

WDSc integration 365 

benefits and features 367 


requirements 

Implementer requirements 369 

WDSc requirements 368 

Web based development 

Apache Web Server for iSeries setup 158– 

159 


HTTP server setup 156–158 

accessing HTTP configuration 157 

adding security directives 157 

enabling method directives 157 

mapping location directives 157 

overview 156 

starting and stopping server 158 

WebSphere Development Studio Client for 

iSeries, see WDSc 

where to go next 203 

work library 

defined 468 

prefix 409 

Workbench 

defined 464 

WRKHTTPCFG, Work with HTTP 

Configuration command 157 

Y 

Y2SYCM library 406 

Y2SYCR library 413 

YSYSCHG model value 307

MKS Implementer 2006 Administration Guide

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?