MKS Implementer 2006 Administration Guide
MKS Implementer 2006 Administration Guide
MKS Implementer 2006 Administration Guide
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
®<br />
Integrity<br />
<strong>MKS</strong> <strong>Implementer</strong>®<br />
<strong>2006</strong><br />
<strong>Administration</strong> <strong>Guide</strong>
<strong>MKS</strong> <strong>Implementer</strong>® <strong>2006</strong><br />
<strong>Administration</strong> <strong>Guide</strong><br />
Copyright © 1988-<strong>2006</strong> <strong>MKS</strong> Software Inc.; in Canada copyright owned by <strong>MKS</strong> Inc. All rights reserved.<br />
<strong>MKS</strong> makes no warranty of any kind with regard to this material, including, but not limited to the implied warranties of merchantability,<br />
performance, or fitness for a particular purpose. <strong>MKS</strong> shall not be liable for errors contained herein, or for any direct, indirect, incidental,<br />
or consequential damages resulting from the use of this material.<br />
No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in<br />
any form by any means, without written permission from <strong>MKS</strong>.<br />
<strong>MKS</strong> Source Integrity, <strong>MKS</strong> Integrity Manager, <strong>Implementer</strong>, <strong>MKS</strong> Toolkit, Nutcracker, <strong>MKS</strong> Integrity Solution, <strong>MKS</strong> Integrity Suite,<br />
Alertcentre, and <strong>MKS</strong> Federated Server are trademarks or registered trademarks of <strong>MKS</strong> Inc. in Canada, the United States and other<br />
countries. All other trademarks or registered trademarks are the property of their respective holders.<br />
U.S. Government Restricted Rights. The software and documentation provided to you (the "Software and Documentation") are<br />
"commercial items," developed exclusively at private expense, consisting of "commercial computer software" and "commercial computer<br />
software documentation" as such terms are defined in the applicable acquisition regulations. If you are the U.S. Government or any<br />
agency or department thereof (collectively referred to as the "Government"), the Software and Documentation are licensed hereunder (i)<br />
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<br />
with this paragraph. If you are any agency of the Department of Defense of the Government, the following notice is given: The Software<br />
and Documentation are provided with RESTRICTED RIGHTS. You shall not use, duplicate or disclose the Software or Documentation in<br />
any way not specifically permitted by <strong>MKS</strong> Software Inc. or mandated by U.S. law. Manufacturer is <strong>MKS</strong> Software Inc., 410 Albert Street,<br />
Waterloo, Ontario Canada N2L 3V3.<br />
This product contains the edtFTPj java library. Copyright © 2003 Enterprise Distributed Technologies Ltd. All Rights Reserved http://<br />
www.enterprisedt.com. THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT<br />
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE<br />
DISCLAIMED. IN NO EVENT SHALL ANY PERSON WHO HAS CONTRIBUTED TO OR IS THE OWNER OF ANY PART OF THIS<br />
SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES<br />
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;<br />
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT<br />
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS<br />
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.<br />
This product contains Java software developed by Sun Microsystems, Inc. © Copyright Sun Microsystems, Inc. All Rights Reserved.<br />
Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.<br />
This product includes Apache Tomcat v. 4.1.27 developed by The Apache Software Foundation (http://www.apache.org/). Licensed<br />
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<br />
copy of the License at http://www.apache.org/licenses/LICENSE-2.0. Unless required by applicable law or agreed to in writing,<br />
software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,<br />
either express or implied. See the License for the specific language governing permissions and limitations under the License.<br />
Copyright © up to and including <strong>2006</strong> International Business Machines Corporation ("IBM") and others. All Rights Reserved. This<br />
product contains IBM Toolbox for Java software developed by IBM and is licensed under the IBM Public License Version 1.0 (the<br />
"License"); you may not use this file except in compliance with the License. See the License at http://www-128.ibm.com/<br />
developerworks/library/os-ipl.html for the specific language governing permissions and limitations under the License. THE<br />
SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED<br />
TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO<br />
EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,<br />
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE<br />
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. IN NO EVENT SHALL THE CONTRIBUTORS BE LIABLE FOR<br />
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT<br />
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS<br />
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR<br />
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF<br />
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.<br />
This product contains JBoss version 4.0.0. Copyright © 2004-<strong>2006</strong> JBoss, Inc. This library is free software; you can redistribute it and/or<br />
modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of<br />
the License, or (at your option) any later version. Copyright © 1991, 1999 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,<br />
Boston, MA 02110-1301 USA. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without<br />
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public<br />
License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write<br />
to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.<br />
This product contains jMimeMagic software. Copyright (C) 2003-2004, David Castro. This library is free software; you can redistribute it<br />
and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version<br />
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;<br />
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General<br />
Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not,<br />
write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.<br />
This product contains Jakarta Oro developed by The Apache Software Foundation (http://www.apache.org/) licensed under the Apache<br />
License, Version 1.1. Copyright (c) 2000-2002 The Apache Software Foundation. All rights reserved. Redistribution and use in source and<br />
binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source<br />
code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must<br />
reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials<br />
provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following<br />
acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."; 4. The<br />
names "Apache" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software<br />
without prior written permission. For written permission, please contact apache@apache.org. 5. Products derived from this software may<br />
not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation.<br />
THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,<br />
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO<br />
EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,<br />
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT<br />
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED<br />
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR<br />
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH<br />
DAMAGE.<br />
This product contains Log4J software licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in<br />
compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0. Unless<br />
required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT<br />
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing<br />
permissions and limitations under the License.<br />
This product contains Xerces 2.6.0 developed by The Apache Software Foundation (http://www.apache.org/) licensed under the Apache<br />
License, Version 1.1. Copyright (c) 2000-2002 The Apache Software Foundation. All rights reserved. Redistribution and use in source and<br />
binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source<br />
code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must<br />
reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials<br />
provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following<br />
acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/). 4. The<br />
names "Xerces", "Apache" and "Apache Software Foundation" must not be used to endorse or promote products derived from this<br />
software without prior written permission. For written permission, please contact apache@apache.org. 5. Products derived from this<br />
software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software<br />
Foundation. THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT<br />
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE<br />
DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY<br />
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED<br />
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)<br />
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT<br />
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED<br />
OF THE POSSIBILITY OF SUCH DAMAGE.
Corporate Headquarters Worldwide Offices<br />
410 Albert Street<br />
Waterloo, ON N2L 3V3<br />
Canada<br />
tel: 519 884 2251<br />
fax: 519 884 8861<br />
sales (toll free): 800 265 2797<br />
www.mks.com<br />
This document is uncontrolled when printed or copied.<br />
1815 South Meyers Rd.<br />
Suite 220<br />
Oakbrook Terrace, IL USA<br />
60181<br />
tel: 630 827 4900<br />
fax: 630 629 9167<br />
sales (toll free): 800 633 1235<br />
12701 Fair Lakes Circle<br />
Suite 350<br />
Fairfax, VA USA<br />
22033<br />
tel: 703 803 3343<br />
fax: 703 803 3344<br />
sales (toll free): 800 637 8034<br />
Martinstraße 42-44<br />
73728 Esslingen<br />
Germany<br />
tel: +49 711 351775 0<br />
fax: +49 711 351775 7555<br />
Third Floor, Duke’s Court<br />
Duke Street, Woking<br />
Surrey<br />
GU21 5BH<br />
United Kingdom<br />
tel: +44 (0)1483 733900<br />
fax: +44 (0)1483 733901<br />
sales: +44 (0)1483 733919
Table of Contents<br />
Chapters 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
About This <strong>Guide</strong>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
Related <strong>Implementer</strong> Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 3<br />
What You Need to Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
Typographical Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
Your Feedback Is Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
2 Understanding <strong>Implementer</strong> . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
Terms You Should Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
Starting <strong>Implementer</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
Overview of Setup Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
Scenario Summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
Host System Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
Basic Host: Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
One Test Environment: Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
Multiple Test Environments: Scenario 3. . . . . . . . . . . . . . . . . . . . 19<br />
Concurrent Development: Scenario 4 . . . . . . . . . . . . . . . . . . . . . . 21<br />
Emergency Development: Scenario 5 . . . . . . . . . . . . . . . . . . . . . . 23<br />
Multiple Data Libraries, Identical Structures: Scenario 6 . . . . . 25<br />
Separate Production Modifications: Scenario 7. . . . . . . . . . . . . . 27<br />
Multiple Software Releases: Scenario 8 . . . . . . . . . . . . . . . . . . . . 29<br />
Modifications to Vendor Software: Scenario 9 . . . . . . . . . . . . . . 33<br />
Release Control: Scenario 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
Remote System Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
Remote Production on Same Request: Scenario 11. . . . . . . . . . . 40<br />
Remote Production on Different Request: Scenario 12 . . . . . . . 41<br />
Testing on Remote: Scenario 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
Multiple Remote Productions Same Changes: Scenario 14 . . . . 45<br />
Multiple Remote Systems: Scenario 15. . . . . . . . . . . . . . . . . . . . . 46<br />
Check Out From Remote: Scenario 16 . . . . . . . . . . . . . . . . . . . . . 48<br />
i
Table of Contents<br />
ii<br />
Multi-Platform Development and Deployment Scenarios . . . . . . . . 49<br />
Integrated Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50<br />
Software Development Lifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . 52<br />
Managing Change Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53<br />
Change Request Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration: Scenario 17. . . . . 60<br />
Communications Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
Distribution Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
3 <strong>Implementer</strong> <strong>Administration</strong> . . . . . . . . . . . . . . . . . . . . . . . 63<br />
Overview of Administrative Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64<br />
System Control Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65<br />
Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72<br />
Typical Values for Different User Roles . . . . . . . . . . . . . . . . . . . . 78<br />
User Profile Object Code Overrides . . . . . . . . . . . . . . . . . . . . . . . 80<br />
User Profile Environment Capabilities. . . . . . . . . . . . . . . . . . . . . 80<br />
Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81<br />
Object Code Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91<br />
Establishing Object Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . 95<br />
Deleting an Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96<br />
Environment Library List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96<br />
Promotion Job Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98<br />
Related Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100<br />
Environment Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101<br />
Special Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 103<br />
Environment Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106<br />
Third Party Integration Prerequisites . . . . . . . . . . . . . . . . . . . . . 107<br />
Environments and User Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . 109<br />
Environment Repository Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117<br />
Environment Build Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121<br />
Environment Repository Report . . . . . . . . . . . . . . . . . . . . . . . . . 122<br />
Environment Verification Report . . . . . . . . . . . . . . . . . . . . . . . . 123<br />
Environment Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125<br />
Object Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127<br />
Environment Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133<br />
Object Codes for Third Party Integrations . . . . . . . . . . . . . . . . . 133<br />
Object Codes for DDM Support. . . . . . . . . . . . . . . . . . . . . . . . . . 135<br />
Object Codes for IFS Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135<br />
Object Codes for Setting a Data Area Value . . . . . . . . . . . . . . . 136<br />
Object Name Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137<br />
Option 1: Specific Object Code for Specific Environment . . . . 138<br />
Option 2: All Object Codes for a Specific Environment. . . . . . 141<br />
Option 3: Specific Object Code for All Environments . . . . . . . 141<br />
Project-based Application Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142<br />
User-Defined PDM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Table of Contents<br />
Issue or Design Request Stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . 145<br />
Object Version Stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146<br />
Versioning Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147<br />
Considerations With OS/400 and <strong>Implementer</strong> . . . . . . . . . . . . . . . . 153<br />
Operating System Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153<br />
Changing the System Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154<br />
System Library List Requirements . . . . . . . . . . . . . . . . . . . . . . . 154<br />
Independent Auxiliary Storage Pools. . . . . . . . . . . . . . . . . . . . . 154<br />
Web-based Development for IFS Objects. . . . . . . . . . . . . . . . . . . . . . 155<br />
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156<br />
iSeries Web Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156<br />
Mounted Drive Support for IFS Objects. . . . . . . . . . . . . . . . . . . . . . . 159<br />
4 Remote Distribution Concepts and Setup . . . . . . . . . . . 161<br />
<strong>Implementer</strong> Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162<br />
Integration With Local Promotions. . . . . . . . . . . . . . . . . . . . . . . 163<br />
Remote System Inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163<br />
Remote Source Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163<br />
Consideration for Database Files. . . . . . . . . . . . . . . . . . . . . . . . . 164<br />
Distribution Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164<br />
Communications Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165<br />
APPC Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165<br />
Communication Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166<br />
APPN Lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166<br />
Switched Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166<br />
Network Control Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167<br />
Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167<br />
Setting Up Communications Entries. . . . . . . . . . . . . . . . . . . . . . . . . . 169<br />
Option 1: Using Existing Communication Entries . . . . . . . . . . 170<br />
Option 2: Using an Existing Mode Description. . . . . . . . . . . . . 170<br />
Option 3: Using a Specific Mode Description . . . . . . . . . . . . . . 171<br />
Defining the Host for Remote Initiated Moves . . . . . . . . . . . . . 173<br />
Setting Up for TCP/IP Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 173<br />
Key Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174<br />
Communication Subsystem and Job Queue IMCOM . . . . . . . 176<br />
Communications Control Command . . . . . . . . . . . . . . . . . . . . . 177<br />
Setting Up for SNADS Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 179<br />
Distribution Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180<br />
Single Step Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180<br />
Two Step Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180<br />
Remote Initiated Moves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181<br />
Simultaneous Distribution to Multiple Remote Sites . . . . . . . . 181<br />
iii
Table of Contents<br />
iv<br />
Controlling Remote Job Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . 181<br />
Using the Default Job Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 182<br />
Overriding the Default Job Schedule . . . . . . . . . . . . . . . . . . . . . 182<br />
Remote Job Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183<br />
Change Remote Request (ICHGRMTRQS) Command . . . . . . 185<br />
Move Remote Request (IMOVRMTRQS) Command . . . . . . . . 187<br />
Distribution Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189<br />
Move Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189<br />
Multiple System Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189<br />
Starting and Ending Remote Database Support . . . . . . . . . . . . 190<br />
Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191<br />
Request Number Considerations . . . . . . . . . . . . . . . . . . . . . . . . 191<br />
Saving and Restoring Remote Tape Archives . . . . . . . . . . . . . . . . . . 192<br />
Problem Determination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193<br />
5 <strong>MKS</strong> Integrity Integration. . . . . . . . . . . . . . . . . . . . . . . . . 195<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration. . . . . . . . . . . . . . . . . . . 196<br />
Multitiered Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196<br />
The iSeries Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198<br />
Process and Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198<br />
Assumptions and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 202<br />
<strong>MKS</strong> Integrity Setup and <strong>Administration</strong> . . . . . . . . . . . . . . . . . 203<br />
<strong>Implementer</strong> Setup and <strong>Administration</strong> . . . . . . . . . . . . . . . . . . 216<br />
Managing <strong>Implementer</strong> Server . . . . . . . . . . . . . . . . . . . . . . . . . . 223<br />
Converting From DesignTracker to <strong>MKS</strong> Integrity . . . . . . . . . . . . . 243<br />
Conversion Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244<br />
Converting Without Data Retention . . . . . . . . . . . . . . . . . . . . . . 244<br />
Converting With Data Retention. . . . . . . . . . . . . . . . . . . . . . . . . 247<br />
Emergency Update Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255<br />
Changing the Emergency Update Mode . . . . . . . . . . . . . . . . . . 255<br />
Applying Pending Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration . . . . . . . . . . . . . . . . . . . . 259<br />
Process and Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260<br />
Assumptions and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 261<br />
<strong>MKS</strong> Source Setup and <strong>Administration</strong> . . . . . . . . . . . . . . . . . . . 262<br />
<strong>Implementer</strong> Setup and <strong>Administration</strong> . . . . . . . . . . . . . . . . . . 274<br />
Preparing for the Next Release . . . . . . . . . . . . . . . . . . . . . . . . . . 293<br />
Preparing for the Next Version . . . . . . . . . . . . . . . . . . . . . . . . . . 293<br />
<strong>MKS</strong> Integrity Integrations Task Checklists . . . . . . . . . . . . . . . . . . . 295<br />
Export to <strong>Implementer</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296<br />
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Table of Contents<br />
6 Third Party Integrations . . . . . . . . . . . . . . . . . . . . . . . . . . 303<br />
ABSTRACT Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304<br />
AllFusion 2E Change Management Integration . . . . . . . . . . . . . . . . 304<br />
Considerations for Libraries and Commands . . . . . . . . . . . . . . 304<br />
Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304<br />
Support for EXCUSRSRC and EXCUSRPGM . . . . . . . . . . . . . . 308<br />
Support for SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309<br />
Object Code Setup for Parallel Installation . . . . . . . . . . . . . . . . 312<br />
American Software Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313<br />
Object Code Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313<br />
Library and Library List Requirements . . . . . . . . . . . . . . . . . . . 314<br />
Troubleshooting Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315<br />
AOS Message Manager Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 315<br />
AS/SET Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316<br />
Setting Up the Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316<br />
Setting Up for Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317<br />
Setting Capabilities for Checked Out Generated Objects . . . . 318<br />
Setting Up for Generated Object Promotions . . . . . . . . . . . . . . 319<br />
AS/SET Dependency Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319<br />
BPCS Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320<br />
Compile Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320<br />
Setting Up Object Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321<br />
Setting Up Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322<br />
BRMS/400 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322<br />
Code/400 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323<br />
Requirements and Setting Up . . . . . . . . . . . . . . . . . . . . . . . . . . . 323<br />
Help Desk Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324<br />
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325<br />
Setting Up the Help Desk Integration. . . . . . . . . . . . . . . . . . . . . 325<br />
Updating Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327<br />
LANSA Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328<br />
Setting Up the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329<br />
Defining Environments and Loading the Repository . . . . . . . 330<br />
Ending Promotions Based on Message ID . . . . . . . . . . . . . . . . . 331<br />
LANSA Object Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331<br />
LANSA Task Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332<br />
Visual LANSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332<br />
Lawson Software Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333<br />
Source and Object Library Structure. . . . . . . . . . . . . . . . . . . . . . 334<br />
LID Method of Screen and Report Generation . . . . . . . . . . . . . 334<br />
v
Table of Contents<br />
vi<br />
Lotus Domino Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336<br />
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338<br />
iSeries Setup and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 339<br />
<strong>Implementer</strong> Setup and Configuration . . . . . . . . . . . . . . . . . . . 339<br />
Domino Designer Setup and Configuration . . . . . . . . . . . . . . . 340<br />
Managing the Domino Access Control List . . . . . . . . . . . . . . . . 343<br />
Setting ACLs in Check Out. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348<br />
Setting ACLs in Promotion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349<br />
Database and Template Signing . . . . . . . . . . . . . . . . . . . . . . . . . 351<br />
PathFinder Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354<br />
PeopleSoft World Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355<br />
Configuring the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356<br />
Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358<br />
Object Codes for Soft Coding Items . . . . . . . . . . . . . . . . . . . . . . 359<br />
Object Codes for Traditional Objects . . . . . . . . . . . . . . . . . . . . . 360<br />
Deactivating Standard Object Codes . . . . . . . . . . . . . . . . . . . . . 361<br />
Installing the Interface on Remote Systems . . . . . . . . . . . . . . . . 361<br />
Powerhouse (Cognos) Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 362<br />
ROBOT Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364<br />
Setting Up Non Promotion Jobs . . . . . . . . . . . . . . . . . . . . . . . . . 365<br />
Setting Up Promotion Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365<br />
WebSphere Development Studio Client for iSeries Integration . . . 365<br />
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366<br />
WDSc for iSeries Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 368<br />
<strong>Implementer</strong> Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369<br />
7 Administrative Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . 371<br />
Submitting Job Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372<br />
Resetting Authorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372<br />
Key Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373<br />
Common Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374<br />
Purging Environment History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374<br />
Repository Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376<br />
Key Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377<br />
Development Library Maintenance . . . . . . . . . . . . . . . . . . . . . . 378<br />
Saving and Restoring Tape Archives . . . . . . . . . . . . . . . . . . . . . . . . . 379<br />
Working With Tape Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . 380<br />
Archive Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383<br />
Clearing Remote QA Environments . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Table of Contents<br />
User Capability Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385<br />
Installing on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386<br />
Installing on the Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387<br />
Using the Capability Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388<br />
Selecting Enrolled Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390<br />
Selecting Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391<br />
User Capability Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393<br />
Customizing User Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 394<br />
Updating the <strong>Implementer</strong> Database . . . . . . . . . . . . . . . . . . . . . 395<br />
Deleting Tutorial Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396<br />
Function Key <strong>Administration</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397<br />
vii
Table of Contents<br />
Appendixes A <strong>Implementer</strong> Data Areas and User Exit Programs. . . . . 401<br />
<strong>Implementer</strong> Data Areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402<br />
Customizing <strong>Implementer</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414<br />
User Exit Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414<br />
Edit Library List Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415<br />
vii<br />
B Environment Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 417<br />
Local Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418<br />
Local Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419<br />
Local Quality Assurance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420<br />
Local User Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422<br />
Remote Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423<br />
C Converting DesignTracker Data to <strong>MKS</strong> Integrity . . . . . 431<br />
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432<br />
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432<br />
Rules and Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433<br />
User Profile and Resource Fields. . . . . . . . . . . . . . . . . . . . . . . . . 434<br />
Entities Added as Change Package Entries . . . . . . . . . . . . . . . . 434<br />
Conversion Log File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435<br />
Message and Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435<br />
Organizational Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436<br />
Example of a Basic Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . 437<br />
Convert DT to <strong>MKS</strong> Integrity (ICVTDT) Command . . . . . . . . 438<br />
Generating and Configuring the Conversion Properties File . . . . . 441<br />
Data Mapping Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . 442<br />
Generating the Conversion File . . . . . . . . . . . . . . . . . . . . . . . . . . 445<br />
<strong>Implementer</strong> Conversion Properties. . . . . . . . . . . . . . . . . . . . . . 446<br />
Post Conversion Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454<br />
D Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457<br />
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
C HAPTER ONE<br />
Introduction<br />
Understanding and Using This <strong>Guide</strong><br />
1<br />
<strong>MKS</strong> <strong>Implementer</strong>® is the premier software configuration management and<br />
deployment solution for the IBM iSeries. Utilizing host-based and graphical user<br />
interfaces, <strong>Implementer</strong> provides the simplicity necessary for first time users, and the<br />
breadth and depth for more advanced users. In addition to simplifying development and<br />
software change management, including full traceability and auditability of all software<br />
changes, <strong>Implementer</strong> ensures the integrity of software installations in production,<br />
development, and testing environments on iSeries servers. <strong>Implementer</strong> integrates with<br />
traditional OS/400 development environments and is leading the way with integrations<br />
into new development environments.<br />
<strong>Implementer</strong> integrates with <strong>MKS</strong> Integrity (formerly <strong>MKS</strong> Integrity Manager®) and<br />
<strong>MKS</strong> Source (formerly <strong>MKS</strong> Source Integrity® Enterprise). <strong>MKS</strong> Integrity is the<br />
enterprise choice for flexible process and workflow management, helping create<br />
repeatable processes for managing software development. <strong>MKS</strong> Integrity’s platform<br />
transparent, advanced, multi-tier architecture is scalable across the enterprise to support<br />
distributed developers and other constituents in the change process. <strong>MKS</strong> Source is the<br />
enterprise choice for comprehensive, cross-platform software configuration<br />
management. It is the most technologically advanced SCM solution on the market today,<br />
enabling secure and flexible process-centric management for local and distributed<br />
software development teams in the enterprise. These products and solutions seamlessly<br />
marry for full enterprise software configuration management and workflow.<br />
The <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong> provides you with the information you<br />
need to build a basic understanding of <strong>Implementer</strong>. The guide explains how to<br />
configure and maintain <strong>Implementer</strong> within your organization.<br />
This chapter covers the following topics:<br />
“About This <strong>Guide</strong>” on page 2<br />
“Related <strong>Implementer</strong> Documentation” on page 3<br />
“What You Need to Know” on page 4<br />
“Typographical Conventions” on page 4<br />
“Getting Help” on page 5<br />
“Professional Services” on page 6<br />
“Your Feedback Is Welcome” on page 7<br />
1
Chapter 1: Introduction<br />
About This <strong>Guide</strong><br />
2<br />
The person responsible for setting up <strong>Implementer</strong> is referred to as the administrator<br />
throughout this guide. This guide provides the administrator with all the information needed<br />
to configure and maintain <strong>Implementer</strong>. The guide also provides information on configuring<br />
and maintaining the <strong>Implementer</strong> Receiver.<br />
NOTE For information on installing or upgrading <strong>Implementer</strong>, see the <strong>MKS</strong><br />
<strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>.<br />
The guide is organized as follows:<br />
Chapter 2: “Understanding <strong>Implementer</strong>” on page 9<br />
Explains important things you need to know and consider before setting up and<br />
configuring <strong>Implementer</strong>. Describes an overview of the change management process in a<br />
multi-platform environment.<br />
Chapter 3: “<strong>Implementer</strong> <strong>Administration</strong>” on page 63<br />
Explains how to configure the <strong>Implementer</strong> host system to suit the development<br />
activities of your organization. Explains important information related to <strong>Implementer</strong><br />
when making changes to the operating system or other system related changes.<br />
Chapter 4: “Remote Distribution Concepts and Setup” on page 161<br />
Explains the role of the <strong>Implementer</strong> Receiver and the various distribution options and<br />
concepts. Explains how to set up communications within <strong>Implementer</strong> to distribute<br />
software to remote iSeries systems.<br />
Chapter 5: “<strong>MKS</strong> Integrity Integration” on page 195<br />
Describes the integration between <strong>Implementer</strong> and <strong>MKS</strong> Integrity that provides an<br />
enterprise-wide solution for tracking issues correlated with <strong>Implementer</strong> managed<br />
development. Explains how to set up the integration and convert from DesignTracker to<br />
<strong>MKS</strong> Integrity. Additionally describes the <strong>Implementer</strong> and <strong>MKS</strong> Source integration, an<br />
export feature that enables client-based software changes initiated by an <strong>MKS</strong> Integrity<br />
issue and modified under <strong>MKS</strong> Source control, to be checked out and optionally<br />
deployed to an IFS location under <strong>Implementer</strong> change management control.<br />
Chapter 6: “Third Party Integrations” on page 303<br />
Explains special setup considerations for organizations that use any of the third party<br />
integrations supported by <strong>Implementer</strong>, such as Computer Aided Software Engineering<br />
(CASE), utility, application, cross-referencing, communications, and other tools.<br />
Chapter 7: “Administrative Utilities” on page 371<br />
Explains the various utilities and tools <strong>Implementer</strong> provides to assist with setting up<br />
and using the product, and maintaining the integrity of your <strong>Implementer</strong><br />
environments.
Related <strong>Implementer</strong> Documentation<br />
Appendix A: “<strong>Implementer</strong> Data Areas and User Exit Programs” on page 401<br />
Describes the <strong>Implementer</strong> data areas that control many aspects of <strong>Implementer</strong><br />
processing. An additional topic is QSAMPLE, a source file shipped with <strong>Implementer</strong><br />
that provides source of technical information for customizing <strong>Implementer</strong>.<br />
Appendix B: “Environment Examples” on page 417<br />
Describes typical environment setup examples for the most common environment<br />
scenarios.<br />
Chapter : “Converting DesignTracker Data to <strong>MKS</strong> Integrity” on page 431<br />
Describes how to convert DesignTracker data to <strong>MKS</strong> Integrity issues. This chapter is for<br />
customers who are converting to <strong>MKS</strong> Integrity for issue management (as described in<br />
Chapter 5) and have a requirement to convert existing DesignTracker data.<br />
Appendix D: “Glossary” on page 457<br />
Defines common terms related to <strong>Implementer</strong> and the <strong>MKS</strong> Integrity integration.<br />
Related <strong>Implementer</strong> Documentation<br />
To provide you with the most convenient means of retrieving information, product<br />
documentation is available in print and in Adobe Acrobat’s Portable Document Format<br />
(PDF). Online help is also included with the product.<br />
Documentation Print PDF<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong> Yes Yes<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong> Yes Yes<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release Management <strong>Guide</strong> No Yes<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release Notes No Yes<br />
<strong>MKS</strong> DesignTracker User <strong>Guide</strong> No Yes<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong> Yes Yes<br />
Additional copies of the printed guides are available for a nominal fee. For further information, send your<br />
request to pubs-mgr@mks.com.<br />
3
Chapter 1: Introduction<br />
What You Need to Know<br />
4<br />
Before installing or configuring <strong>Implementer</strong>, you should be familiar with the software<br />
development policies and procedures for your organization, as well as:<br />
OS/400 operating system and command line.<br />
OS/400 security.<br />
OS/400 communications.<br />
Typographical Conventions<br />
Throughout this guide, the following typographical conventions identify the features,<br />
functions, and components of <strong>Implementer</strong>.<br />
Items in documentation... Appear as...<br />
New terms, variables to_env<br />
Keyboard keys, programs, files, directory names, and<br />
drive letters<br />
Code-based information, such as system messages,<br />
field syntax, macros, and commands, and information<br />
you type on menus and panels<br />
appear in capitals, for example: ENTER, F6<br />
ADDLIBLE<br />
Graphical menus, commands New > Problem<br />
Graphical user interface commands the Session command<br />
Dialog boxes, features, field names Edit Options, Cancel, OK<br />
Path names c:/mks/demo<br />
NOTE A note provides you with information that supplements the key points of the<br />
subject. A note may also supply information that applies only in particular cases.<br />
TIP A tip provides you with information for using the product effectively.<br />
IMPORTANT An important note provides you with information that is essential for<br />
completing a task.<br />
CAUTION A caution note advises you about situations that have the potential to<br />
result in a loss of data.
Getting Help<br />
Getting Help<br />
<strong>MKS</strong> Customer Care is focused on delivering the right solutions to issues as they arise. For<br />
assistance, you can choose online support or telephone a technical support representative.<br />
For online support, browse to www.mks.com/support. There you will find easy access to<br />
e–mail, Web request services, automatic product notifications, and the <strong>MKS</strong> Customer<br />
Community—a secure database that provides helpful resources such as product<br />
documentation, knowledge base articles, product downloads, user forums, presentations,<br />
and more.<br />
<strong>MKS</strong>’s global support professionals comprise a tightly knit team of problem solvers, sharing<br />
critical information to help you resolve issues in the shortest possible time with optimal<br />
results. Support representatives can provide you with a variety of product related tips and<br />
innovative solutions to your unique requirements.<br />
Online Web www.mks.com<br />
E-mail support@mks.com<br />
Telephone Toll Free North America 800 219 4842<br />
Outside North America 800 219 48424<br />
India 000 800 100 6273<br />
Direct North America 519 884 2270<br />
UK +44 (0) 1483 733910<br />
Germany +49 711 351775 7575<br />
Fax North America 519 884 8861<br />
UK +44 (0) 1483 733901<br />
Germany +49 711 351775 7555<br />
The hours of operation for Customer Care in your region are as follows:<br />
North America: 8:00 A.M. to 8:00 P.M., Monday to Friday, Eastern Standard Time<br />
(GMT-5)<br />
United Kingdom: 9:00 A.M. to 5:30 P.M., Monday to Friday, British Standard Time<br />
(GMT)<br />
Germany: 9:00 A.M. to 5:30 P.M., Monday to Friday, West Europe Standard Time<br />
(GMT+1)<br />
India: 8:30 A.M. to 5:30 P.M., Monday to Friday, India Standard Time (GMT+5.5)<br />
5
Chapter 1: Introduction<br />
Professional Services<br />
6<br />
A successful configuration management system is not built on software alone. At <strong>MKS</strong>, our<br />
professional services team is committed to understanding the ever changing development<br />
environments of our clients. The professional services team can provide training, upgrade,<br />
migration, implementation, and installation services that meet your unique requirements.<br />
<strong>MKS</strong> professional services can help guide you through process analysis, software<br />
installation, source code archive migration, and product and process training. This ensures<br />
that the implementation of your new solution goes smoothly, while allowing your<br />
developers to make progress on critical projects.<br />
The professional services team can truly add value to your <strong>MKS</strong> technology investment by<br />
providing the following services:<br />
process assessment<br />
best practice consultation<br />
migration services<br />
upgrade services<br />
implementation services<br />
education and training<br />
For more information on <strong>MKS</strong> professional services:<br />
Online Web Global www.mks.com/services<br />
E-mail North America consulting@mks.com<br />
Europe europe@mks.com<br />
Telephone North America 800 633 1235<br />
UK +44 (0) 1483 733904<br />
Germany +49 711 351775 0
Your Feedback Is Welcome<br />
Your Feedback Is Welcome<br />
<strong>MKS</strong> welcomes your feedback on the documentation included with these products. If you<br />
have comments or suggestions about any of the guides or the online help, send them to:<br />
pubs-mgr@mks.com<br />
Include the following information with your feedback:<br />
product name and version number<br />
title of manual or online help topic<br />
page number (for manuals only)<br />
your suggested correction or improvement<br />
NOTE The e-mail address is provided for comments on the <strong>MKS</strong> documentation<br />
only. For technical questions or for software support, contact <strong>MKS</strong> Customer Care<br />
(support@mks.com).<br />
7
Chapter 1: Introduction<br />
8
C HAPTER TWO<br />
Understanding <strong>Implementer</strong><br />
Getting Prepared for Setup<br />
This chapter helps you to prepare for setting up <strong>Implementer</strong> by providing an<br />
overview of the tasks and scenarios that describe different approaches to using the<br />
product based on various development models.<br />
2<br />
It is possible that a scenario fits the needs of one business application while a different<br />
scenario fits another. You can blend characteristics of multiple scenarios to meet the<br />
needs of your applications. The scenarios focus on the major decisions involved in<br />
setting up <strong>Implementer</strong> for your use; they do not list every set up option available in<br />
<strong>Implementer</strong>.<br />
This chapter covers the following topics:<br />
“System Requirements” on page 10<br />
“Terms You Should Know” on page 10<br />
“Starting <strong>Implementer</strong>” on page 10<br />
“Overview of Setup Tasks” on page 12<br />
“Scenario Summaries” on page 14<br />
“Host System Scenarios” on page 17<br />
“Remote System Scenarios” on page 39<br />
“Multi-Platform Development and Deployment Scenarios” on page 49<br />
“Communications Options” on page 61<br />
“Distribution Methods” on page 61<br />
9
Chapter 2: Understanding <strong>Implementer</strong><br />
System Requirements<br />
10<br />
The system requirement for this <strong>Implementer</strong> release is OS/400 V5R1 or later, or i5/OS V5R3<br />
or later. Additional requirements may apply to using certain features or functions of<br />
<strong>Implementer</strong>. For detailed information, see the requirements described with the respective<br />
feature or function.<br />
Terms You Should Know<br />
Before you begin setting up <strong>Implementer</strong>, it is important to understand several basic terms<br />
used within the software:<br />
environment<br />
object code<br />
check out<br />
promotion<br />
For a definition of these terms and many other terms, see “Glossary” on page 457.<br />
Starting <strong>Implementer</strong><br />
To start <strong>Implementer</strong>, use the Start <strong>Implementer</strong> (STRIM) command. To start the standard<br />
<strong>Implementer</strong> Receiver, use the Start <strong>Implementer</strong> Receiver (STRIR) command. To start the<br />
<strong>Implementer</strong> Receiver for Release Management, use the (STRIRM) command.<br />
To access a specific <strong>Implementer</strong> panel, issue any of the start commands followed by the<br />
respective keyword or menu option number. For example, to access <strong>Implementer</strong> Menu<br />
option 45, System Control Maintenance, issue the command STRIM *SYSCTLMNT or STRIM<br />
45. For a list of valid keywords, see the table page 11. You can also prompt the commands<br />
and use F4=Prompt on the OPTIONS parameter to view and select a valid keyword.<br />
If you received the <strong>Implementer</strong> product from Computer Associates and have <strong>Implementer</strong><br />
enabled for AllFusion 2E change management, the following substitutions apply:<br />
STRCM command replaces the STRIM command.<br />
STRCR command replaces the STRIR command.<br />
Library Y2SYCM replaces the default host system library name <strong>MKS</strong>IM.<br />
Library Y2SYCR replaces the default remote system library name <strong>MKS</strong>IR.
Starting <strong>Implementer</strong><br />
The <strong>Implementer</strong> menus allow access to all capabilities and functions of <strong>Implementer</strong> and<br />
<strong>Implementer</strong> Receiver. Menu access options are described in this guide when they are used<br />
for specific tasks.<br />
The <strong>Implementer</strong> Menu contains the following sections across multiple panels:<br />
implementation<br />
other common tasks<br />
emergency handling<br />
reports<br />
administration<br />
release control<br />
commands<br />
The following table describes the command parameters you can use with the STRIM and<br />
STRCM commands.<br />
Start <strong>Implementer</strong> Command Keywords<br />
Menu Option STRIM Command Value<br />
Activity Report *ACTRPT<br />
Archive History Report *ARCHRPT<br />
Archive Recovery *ARCRCV<br />
Archive to Tape Menu *ARCTAP<br />
Check Out *CHKOUT<br />
Compile Promotion Request *CMPRQS<br />
Concurrent Development Report *CONDEVRPT<br />
Create Promotion Request *CRTRQS<br />
Move Promotion Request by System/Environment *MOVRQSSYS<br />
Environments *WRKENV<br />
Environment Groups *WRKENVGRP<br />
Environment Report *ENVRPT<br />
Function Keys *WRKFNCKEY<br />
Job Log Inquiry *JOBLOGINQ<br />
Lock Report *LCKRPT<br />
Menu—Panel 1 *M1 or *MENU1<br />
Menu—Panel 2 *M2 or *MENU2<br />
11
Chapter 2: Understanding <strong>Implementer</strong><br />
Overview of Setup Tasks<br />
12<br />
Start <strong>Implementer</strong> Command Keywords<br />
Menu Option STRIM Command Value<br />
Menu—Panel 3 *M3 or *MENU3<br />
Menu—Panel 4 *M4 or *MENU4<br />
Manage All Concurrent Development *MNGCONDEV<br />
<strong>MKS</strong> Integrity Setup *INTMGRSET<br />
<strong>MKS</strong> Source Setup *SRCMGT<br />
Move Promotion Request *MOVRQS<br />
My Workbench *WRKBCH<br />
Network Configuration *NETCFG<br />
Objects *WRKOBJ<br />
Object Codes *WRKOBJCDE<br />
Object Code Report *OBJCDERPT<br />
Release Deployment Menu *WRKRLSDPL<br />
Request Inquiry *RQSINQ<br />
Request Maintenance *RQSMNT<br />
Request Report *RQSRPT<br />
System Control Maintenance *SYSCTLMNT<br />
Users *WRKUSR<br />
User Report *USRRPT<br />
Work with Projects *WRKPRJ<br />
This section describes an overview of the basic tasks you need to complete to configure<br />
<strong>Implementer</strong> for your specific needs. Used in conjunction with the scenarios provided later in<br />
the chapter, this information helps you to organize <strong>Implementer</strong>.<br />
NOTE This list is not all-inclusive of the setup required to gain full advantage of all<br />
<strong>Implementer</strong>’s robust features and functions. For more information, see the<br />
requirements listed for each specific feature.
The following list identifies the basic functions you use to set up <strong>Implementer</strong>:<br />
Overview of Setup Tasks<br />
System Control Maintenance allows you to define your company name, default job<br />
queue, and numerous other system-wide defaults.<br />
Create User Profile allows you to define the rights and characteristics of each<br />
<strong>Implementer</strong> user.<br />
Create Environment allows you to define the characteristics of the different types of<br />
environments and related environments for your applications, and establish default<br />
development paths for production environments.<br />
Work with Object Codes allows you to define the specific types of objects used for<br />
promotion.<br />
Reset Authorities allows you to change the OS/400 owners and authorities to objects in<br />
the environment libraries.<br />
Build List allows you to load members and objects into <strong>Implementer</strong>’s environment<br />
repository.<br />
Create Environment Groups allows you to define environment groups for promotion or<br />
distribution purposes.<br />
Set up User-defined Programming Development Manager allows you set up PDM to<br />
perform <strong>Implementer</strong> functions for environments.<br />
<strong>Implementer</strong> Server allows you to configure the <strong>Implementer</strong> Server, which is the<br />
gateway to <strong>MKS</strong> Integrity integrations, as well as the primary contact point for many<br />
external and third party integrations. For details, see “Configuring the <strong>Implementer</strong><br />
Server” on page 217.<br />
<strong>MKS</strong> Integrity Setup allows you to configure the communications and other variables<br />
required to use <strong>MKS</strong> Integrity for issue management with <strong>Implementer</strong>. For details, see<br />
“<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration” on page 196.<br />
<strong>MKS</strong> Source Setup allows you to configure the communications and other variables<br />
required to use <strong>MKS</strong> Source for source archiving with <strong>Implementer</strong>. For details, see<br />
“<strong>Implementer</strong> and <strong>MKS</strong> Source Integration” on page 259.<br />
Before setting up <strong>Implementer</strong>, it is necessary to conceptually understand two features that<br />
apply to all development scenarios: projects and archiving.<br />
Projects are a common element of the development cycle. The primary decisions regarding<br />
projects are whether you use projects, and how you use them. The following options are<br />
available for managing projects in <strong>Implementer</strong>:<br />
<strong>Implementer</strong> projects<br />
<strong>MKS</strong> Integrity projects (requires using <strong>MKS</strong> Integrity for issue management); for more<br />
information, see “<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration” on page 196<br />
DesignTracker projects (requires using DesignTracker for issue management)<br />
13
Chapter 2: Understanding <strong>Implementer</strong><br />
14<br />
ProjectMaster projects (requires using ProjectMaster for project management)<br />
You create <strong>Implementer</strong> projects in <strong>Implementer</strong>. If using DesignTracker, you can create<br />
projects from the Work with Entity List Members panel by using F20=Create IM Project<br />
(creates one project or group of projects for each design request). <strong>Implementer</strong> projects allow<br />
for project paths (similar to environment paths) that control the development flow of<br />
members/objects associated with a project. The project path can be defined on a project-byproject<br />
basis. For details, see “Project-based Application Paths” on page 142.<br />
When DesignTracker is not used, for example, when using <strong>MKS</strong> Integrity, you must<br />
determine a method of naming your projects and determine when to create them. For<br />
example, you might create a project for every fix or minor change needed, or create a single<br />
project for fixes this month or this year, or a continuous project for all fixes. You may already<br />
have a system in place for logging user requests that match <strong>Implementer</strong> project references.<br />
Archiving serves two main purposes: The main purpose is to recover original source and/or<br />
objects when the promoted source and/or objects do not function appropriately in<br />
production. Secondly, it provides access to the initial source of a specific program to review<br />
before promoting the current changes.<br />
You should determine the value of being able to rollback a change, and the ability to view<br />
historical versions of source. <strong>MKS</strong> recommends you archive production environments but<br />
not archiving test environments.<br />
If you have remote systems, you can archive on the remote system or the local system.<br />
However, archiving on the remote allows you to rollback more quickly because it does not<br />
require redistributing the objects to the remote system.<br />
Scenario Summaries<br />
The following tables list each scenario with a description of the important characteristics of<br />
each scenario. This information is helpful to understand why a specific scenario might be<br />
useful. The detailed description for each scenario includes:<br />
illustration of the development cycle<br />
brief scenario description<br />
description of development steps<br />
setup tasks for the scenario
Host System Scenarios<br />
Scenario Important Characteristics<br />
Scenario Summaries<br />
1. Basic (page 17) developers check out from production to development<br />
developers initiate promotion back to production<br />
project leader promotes back to production<br />
does not use separate test environments<br />
2. One test environment (page 18) developers check out from production to development<br />
developers initiate promotion to a test environment<br />
project leader promotes back to production<br />
test administrator promotes to production<br />
3. Multiple test environments (page 19) similar to Scenario 2, with more testing areas<br />
testers promote to other test environments and<br />
production<br />
4. Concurrent development (page 21) allows checking out multiple versions of same member<br />
by same or different developers<br />
uses two development environments<br />
5. Emergency (page 23) allows checking out multiple versions of same member<br />
by same or different developers<br />
uses two development environments<br />
6. Multiple database libraries (page 25) testing or production environments have multiple<br />
copies of database files<br />
7. Separate production modifications<br />
(page 27)<br />
multiple related production environments<br />
automatic check out from most current version<br />
8. Multiple software releases (page 29) multiple related production environments<br />
automatic check out from either release<br />
9. Modifications to vendor software<br />
(page 33)<br />
can be used with any scenario previously listed<br />
searches multiple environments at check out<br />
does not update unmodified vendor libraries<br />
10. Release control (page 37) can be used with any scenario previously listed<br />
supports both single version and multiple version<br />
development models<br />
15
Chapter 2: Understanding <strong>Implementer</strong><br />
16<br />
Remote System Scenarios<br />
Scenario Important Characteristics<br />
11. Remote host and remote production<br />
on same promotion request (page 40)<br />
12. Host and a single remote on different<br />
promotion request (page 41)<br />
production on a single remote system<br />
remote production and local image distributed to in<br />
one step<br />
testing is not performed on remote system<br />
production on a single remote system<br />
distribute to remote production and local system in two<br />
separate steps<br />
testing is not performed on remote system<br />
13. Perform testing on remote (page 43) testing occurs on remote system<br />
distribute to remote production and local system in one<br />
step<br />
14. Multiple remote systems with same<br />
changes (page 45)<br />
production on multiple remote systems with same<br />
changes on each system<br />
15. Multiple remote sites (page 46) production on multiple remote systems with different<br />
changes on each system<br />
16. Remote source check out (page 48) production source on remote system<br />
source checked out from remote to host development<br />
Multi-Platform Scenarios<br />
Scenario Important Characteristics<br />
17. Multi-platform development and<br />
deployment (page 60)<br />
can be used with any scenario previously listed<br />
<strong>Implementer</strong> users log new issues using <strong>MKS</strong> Integrity<br />
<strong>MKS</strong> Integrity eliminates the need to sign on to the<br />
iSeries to log issues<br />
a single issue ID is used to manage a change across<br />
multiple platforms
Host System Scenarios<br />
Basic Host: Scenario 1<br />
Overview<br />
Host System Scenarios<br />
Each developer checks out to a personal environment, a project environment, a shared<br />
development environment, or a personal library. The developer checks in directly to the<br />
production environment. Contrast this scenario with the next scenario, which includes a test<br />
environment.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out. Developer checks out to a personal environment, project environment, or<br />
shared development environment.<br />
2 Develop and test. Developer codes, compiles, and tests programs.<br />
3 Promote to production. Developer creates the promotion request.<br />
Developer can compile the request into the work library as a separate task or when<br />
creating the request.<br />
User who has move capabilities moves the members/objects into production.<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Production, one production environment.<br />
Development, one development environment for all developers, or specific<br />
environments per developer or project.<br />
17
Chapter 2: Understanding <strong>Implementer</strong><br />
18<br />
2 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer, checks out members/objects, performs development, and creates a<br />
promotion request that targets production. Additionally compiles the promotion<br />
request to the work library.<br />
Administrator or project leader, creates projects and moves the promotion request to<br />
production.<br />
One Test Environment: Scenario 2<br />
Overview<br />
Each developer checks out to a personal library, a project library, or a shared development<br />
library. The developer promotes to a quality assurance environment. Testers test in this<br />
environment and then promote to production.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out. Developer checks out to a personal library, project library, or shared<br />
development library.<br />
2 Develop and test. Developer codes, compiles, and tests programs.<br />
3 Promote to test. Developer creates the promotion request.<br />
Developer compiles the promotion request into the work library, as a separate task<br />
or when creating the request.<br />
Authorized user moves the members/objects into quality assurance.<br />
4 Quality assurance testing. Tester tests the change for functional consistency and<br />
accuracy.<br />
5 Promote to production.<br />
Tester creates the promotion request.<br />
The promotion request can be compiled into the work library, as a separate task or<br />
when creating the request.<br />
Administrator moves the members/objects into production.
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Production, one production environment.<br />
Quality Assurance, one QA environment.<br />
Development, one development environment for all developers, or specific<br />
environments per developer or project.<br />
2 Create a User Profile task. Define user profiles for the following user roles:<br />
Host System Scenarios<br />
Developer checks out members/objects, performs development, and creates a<br />
promotion request that targets quality assurance environments. The developer<br />
compiles the promotion request in the work library.<br />
Tester performs the tests in the test environment with their own copy of the changes.<br />
Administrator promotes changes into the QA environment to allow the tester to start<br />
testing a change.<br />
Administrator or project leader creates projects and moves the promotion request to<br />
production.<br />
Multiple Test Environments: Scenario 3<br />
Overview<br />
Each developer checks out to a personal library, a project library, or a shared development<br />
library. The developer completes the necessary changes and checks in to a quality assurance<br />
environment. The testers in this environment perform the necessary testing, and then<br />
promote from quality assurance to another test environment for user acceptance. This is<br />
accomplished by copying the request that initially promoted the changes into the quality<br />
assurance environment. After user acceptance testing, you promote the change to<br />
production.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out. Developer checks out to a personal library, project library, or shared<br />
development library.<br />
19
Chapter 2: Understanding <strong>Implementer</strong><br />
20<br />
2 Develop and test. Developer codes, compiles, and tests programs.<br />
3 Promote to test. Developer creates the promotion request.<br />
Developer can compile the promotion request into the work library, as a separate<br />
task or when creating the request.<br />
Administrator moves the members/objects into quality assurance.<br />
4 Quality assurance testing. Tester tests the change for functional consistency and<br />
accuracy.<br />
5 Promote to test.<br />
Tester creates the request for promotion by copying the original promotion request.<br />
Administrator moves the members/objects into user acceptance testing.<br />
6 User acceptance testing. End users test the change for functional consistency and<br />
accuracy.<br />
7 Promote to production.<br />
Authorized user creates the request for promotion by copying the original<br />
promotion request.<br />
Administrator moves the members/objects into production.<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Production, one production environment.<br />
Quality Assurance, the first QA environment.<br />
User Acceptance testing, the second QA environment.<br />
Development, one development environment for all developers, or specific<br />
environments per developer or project.<br />
2 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, and creates a<br />
promotion request that targets quality assurance environments. Additionally<br />
compiles the promotion request in the work library.<br />
Tester performs the test in this environment with their own copy of the changes.<br />
Administrator promotes changes into the QA environment to allow the tester to start<br />
testing a change.<br />
Administrator or project leader creates projects and moves the promotion request to<br />
production.
Concurrent Development: Scenario 4<br />
Overview<br />
This scenario allows checking out multiple versions of one member.<br />
Host System Scenarios<br />
The first developer checks out to a personal library, a project library, or a shared<br />
development library. The second developer checks out to a personal library, a project library,<br />
or a shared development library by selecting from existing versions.<br />
The developer must have concurrent development capabilities, unless the activity involves<br />
emergency check out, in which case the user’s emergency check out and promotion rights<br />
override the concurrent development capabilities. For more information, see the definitions<br />
for “concurrent development” on page 459, and “conflict” on page 459.<br />
To complete the necessary changes, the first developer notifies the administrator or project<br />
leader to resolve a conflict. Once the conflict is resolved, the developer or administrator<br />
promotes the request back into production. The next program completes the same action.<br />
To focus on the concurrent development features, this scenario has only one quality<br />
assurance environment.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out the first version of a member. Developer checks out to a personal library,<br />
project library, or shared development library.<br />
2 Develop and test. Developer begins a programming change.<br />
3 Check out second version for a concurrent development. Developer checks out a second<br />
copy for another change to a different environment. Concurrent check out requires you<br />
have concurrent development rights. Depending on the situation, you may want to start<br />
with a current development copy or the production version. The developer working on<br />
the first version receives a message that a different developer is doing concurrent<br />
development.<br />
21
Chapter 2: Understanding <strong>Implementer</strong><br />
22<br />
4 Make the development change to the second version. Developer codes, compiles, and<br />
tests.<br />
5 Resolve the conflict for the first version of the member.<br />
Developer notifies the administrator that conflict resolution is necessary or, if<br />
allowed, resolves the conflict himself.<br />
Administrator resolves all conflicts of the first completed version of the member.<br />
Promoting a request often includes conflict resolution, as described in the next task.<br />
6 Promote the first version to testing.<br />
Developer or administrator creates the promotion request.<br />
Developer can compile the promotion request into the work library, as a separate<br />
task or when creating the request.<br />
Administrator moves the members/objects into quality assurance.<br />
7 Complete the second change. Developer codes, compiles, and tests.<br />
8 Resolve the conflict for the second change.<br />
Developer notifies the administrator that conflict resolution is necessary.<br />
Administrator resolves all conflicts of the second completed version of the member.<br />
Promoting a request often includes conflict resolution, as described in the next task.<br />
This step could include reviewing the source code of the emergency version, or even<br />
performing a merge or compare of the version.<br />
9 Promote the second version to testing.<br />
Developer creates the promotion request.<br />
Developer can compile the promotion request into the work library, either as a<br />
separate task or when creating the request.<br />
Administrator moves the members/objects into quality assurance.<br />
10 Quality assurance testing. Tester tests the change for functional consistency and<br />
accuracy.<br />
11 Promote to production.<br />
Tester creates the promotion request.<br />
Administrator moves the members/objects into production.
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Production, one production environment with a standard path.<br />
Quality Assurance, the first QA environment.<br />
Host System Scenarios<br />
Development environment, one development environment for all developers, or<br />
specific environments per developer or project.<br />
2 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, creates a promotion<br />
request that targets production, and is allowed to perform concurrent development.<br />
The developer compiles the promotion request in the work library.<br />
Tester performs the tests in the test environment with their own copy of the changes.<br />
Administrator promotes changes into the QA environment to allow the tester to start<br />
testing a change.<br />
Administrator or project leader creates projects and moves the promotion request to<br />
production. This user also has conflict resolution capabilities.<br />
Emergency Development: Scenario 5<br />
Overview<br />
This scenario allows checking out multiple versions of one member. The second check out is<br />
for emergency purposes.<br />
The first developer checks out to a personal library, a project library, or a shared<br />
development library. The second developer checks out to a personal library, a project library,<br />
or a shared development library by selecting from an existing version. To do this, the<br />
23
Chapter 2: Understanding <strong>Implementer</strong><br />
24<br />
developer must have emergency capabilities. The developer completing the emergency<br />
development resolves the conflict and promotes the request back into production. The next<br />
programmer and/or administrator completes the same actions.<br />
To focus on the emergency features, this scenario includes only one quality assurance<br />
environment.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out the first version of a member. Developer checks out to a personal library,<br />
project library, or shared development library.<br />
2 Develop and test. Developer begins a programming change.<br />
3 Check out second version for an emergency. Developer checks out a second copy for an<br />
emergency change to a different environment. This is often an emergency check out. You<br />
must also select a specific version of the member to start with. For emergency<br />
development, this is probably the original production member/object. This is normally<br />
considered concurrent development that requires specific authority, however, in this<br />
case the emergency check out rights override the concurrent development requirement.<br />
4 Make the emergency change. Developer codes, compiles, and tests.<br />
5 Resolve the conflict for emergency version. This resolves all conflicts of the emergency<br />
version of the member. Promoting a request often includes conflict resolution as<br />
described in the next task. Usually, the user who has emergency capabilities to resolve<br />
conflicts and complete moves has this authority.<br />
6 Promote the emergency version to production. Developer creates the promotion request.<br />
You normally promote this request directly into production using the Auto Submit<br />
Through Step in the move function.<br />
7 Complete the first change. Developer codes, compiles, and tests.<br />
8 Resolve the conflict for first change.<br />
Developer notifies the administrator that conflict resolution is necessary.<br />
Administrator resolves all conflicts of the first completed version of the member.<br />
Promoting a request often includes conflict resolution as described in the next task.<br />
This step could include reviewing the source code of the emergency version, or even<br />
performing a merge or compare of the version.<br />
9 Promote the first version to production.<br />
Developer creates the promotion request.<br />
Developer can compile the promotion request into the work library, either as a<br />
separate task or when creating the request.<br />
Administrator moves the members/objects into production.
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Production, one production environment.<br />
Host System Scenarios<br />
Development environment, one development environment for all developers, or<br />
specific environments per developer or project.<br />
Emergency development environment, one development environment for all<br />
developers, or specific environments per developer or project.<br />
2 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, creates a promotion<br />
request that targets production. Additionally compiles the promotion request in the<br />
work library.<br />
Developer with emergency capabilities checks out members/objects using Emergency<br />
Check Out, performs development, and creates an emergency promotion request<br />
that targets production. This developer compiles and moves the promotion request<br />
into the production environment and has conflict resolution capabilities.<br />
Administrator creates projects and moves the promotion request to production.<br />
Multiple Data Libraries, Identical Structures: Scenario 6<br />
Overview<br />
In this scenario, the production application has two database libraries. Both libraries have<br />
identical structures containing the same file objects, however, the data may differ between<br />
one set and the other. <strong>Implementer</strong> supports this scenario by creating two environments and<br />
25
Chapter 2: Understanding <strong>Implementer</strong><br />
26<br />
combining them in an environment group. These extra database libraries are either for<br />
training and testing, or for a second division of the organization that uses the same program<br />
libraries but requires separate data.<br />
The example given is for multiple production database libraries, but you could also use this<br />
for multiple database environments for a quality assurance environment. In this case, the<br />
extra database files libraries are usually for different test databases.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out. Developer checks out to a personal library, project library, or shared<br />
development library. The developer checks out from the full production environment.<br />
2 Develop and test. Developer codes, compiles, and tests programs.<br />
3 Promote to production.<br />
Developer creates the promotion request targeting an environment group. The<br />
environment group has the check out From environment as the first environment.<br />
The database environments are also part of this environment group.<br />
Developer can compile the promotion request into the work library.<br />
Administrator moves the members/objects into the production environments. You<br />
can perform the moves to the different environments at different times.<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Production, one production environment for the complete application.<br />
Database files environment (for production), one production environment for each<br />
database files library.<br />
Development environment, one development environment for all developers, or<br />
specific environments per developer or project.<br />
2 Create an Environment Group task. Define the following environment group:<br />
Production, one environment group that combines the full production environment<br />
with the database files environments.<br />
3 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, and creates a<br />
promotion request targeting the quality assurance environments. The developer<br />
compiles the promotion request in the work library.<br />
Administrator creates projects and moves the promotion request to production.
Separate Production Modifications: Scenario 7<br />
Overview<br />
Host System Scenarios<br />
This scenario allows for managing modifications to production in a separate environment<br />
from the base production application. This method is commonly used when making<br />
modifications to a standard packaged application, and when you are not making the<br />
modifications directly to the application.<br />
You define the base production and modified production libraries as two separate<br />
environments so you can control them separately. You can add additional modification levels<br />
to this scenario. In many cases there is only one copy of the database in a separate library, and<br />
since both reference it, it is defined as part of both the modified and base production<br />
environments.<br />
After checking out from the modified production environment, you bring all development<br />
changes back to the modified production environment. You always check out the member<br />
from the modified environment to development, regardless of whether the item to be<br />
changed is already in the modification library. If you have not modified the item, it is<br />
automatically copied from the base production environment.<br />
This scenario is similar to the scenario for Modifications to Vendor Software, except there are<br />
no external changes from a vendor (or a common development group) that you must<br />
periodically incorporate into the application.<br />
Development Tasks<br />
This is the typical sequence from the start of a programming change to completion.<br />
1 Check out the member/object from the Mods environment. Developer selects the<br />
member/object from a list of all items in modified production and/or base production.<br />
Check out automatically determines to take the version from modified or base<br />
production for new development.<br />
2 Develop and test. Developer begins the programming change and tests the member/<br />
object in their development environment.<br />
27
Chapter 2: Understanding <strong>Implementer</strong><br />
28<br />
3 Promote the member/object to quality assurance.<br />
Developer or administrator creates the promotion request.<br />
Developer can compile the promotion request into the work library, either as a<br />
separate task or when creating the request.<br />
Administrator moves the members/objects into quality assurance.<br />
4 Quality assurance testing. Tester tests the change for functional consistency and<br />
accuracy.<br />
5 Promote the member/object to Mods production.<br />
Tester copies the original promotion request and changes the target environment (or<br />
environment group) to the Mods environment.<br />
Administrator moves the members/objects into modified production.<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Base Production, one production environment for the base version of the application.<br />
If all files are in a single library, define that library as the file library for this<br />
environment, as well as for the modified production environment.<br />
Mods Production, one production environment for the modifications of a particular<br />
application. Set up the related environments with modified production above the<br />
base production environment to allow automatic selection of the correct version<br />
during check out. If all files are in a single library, define that library as the file<br />
library for this environment, as well as for the modified production environment.<br />
Quality Assurance, one QA environment for each release of a particular application.<br />
Development environment, one development environment for all developers for each<br />
release, or specific environments per developer or project.<br />
NOTE Related environments are always connected to the modification environment,<br />
never to the base environment.<br />
2 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, creates a promotion<br />
request targeting quality assurance, and is allowed to perform concurrent<br />
development. The developer compiles the promotion request in the work library.<br />
This user only has authority to check out from the modified production<br />
environments and promote to the quality assurance environments being supported.<br />
Tester performs the tests in the test environment with his own copy of the changes.
Multiple Software Releases: Scenario 8<br />
Overview<br />
Host System Scenarios<br />
This scenario allows you to manage multiple software releases for a given application.<br />
You can create a new release that contains only the changes to the prior release(s).<br />
NOTE This illustrates a delta scenario, where the new release contains only the<br />
objects that are different from the original release. It is also possible to set up a non<br />
delta scenario, where both libraries contain the entire product. The differences in<br />
setting up these two variations are described in “Differences Between Delta and<br />
Non Delta Variations” on page 32.<br />
During check out for development on the new release, <strong>Implementer</strong> searches each release<br />
and copies the item from the most recent release. A list of all items logically a part of the new<br />
release is available, whether they are physically in the new release or only in the old release.<br />
Development on the previous (1.0) release can continue using the basic development<br />
scenario. You may need ongoing support for this release, since it is in production while you<br />
are developing the newer release. You can add unlimited additional releases—allowing for<br />
the support of multiple prior releases—while developing the newest release.<br />
You frequently use concurrent development with this scenario to manage concurrent<br />
changes to the same object in multiple releases.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
Separate development activities occur for both releases.<br />
29
Chapter 2: Understanding <strong>Implementer</strong><br />
30<br />
Changes to Release 2.0<br />
1 Check out the member/object from Production 2.0 environment. Developer for release<br />
2.0 selects the member/object from a list of all items in release 2.0 production and/or<br />
release 1.0 production. Check out automatically determines to copy the version from<br />
release 2.0 or release 1.0 production for new development.<br />
2 Develop and test Release 2.0. Developer begins the programming changes and tests the<br />
member/object in his development environment for release 2.0.<br />
3 Promote the member/object to quality assurance 2.0.<br />
Developer or administrator creates the promotion request.<br />
Developer can compile the promotion request into the work library, either as a<br />
separate task or when creating the request.<br />
Administrator moves the members/objects into quality assurance 2.0.<br />
4 Quality assurance testing release 2.0. Tester tests the change for functional consistency<br />
and accuracy.<br />
5 Promote the member/object to Production 2.0.<br />
Tester copies the original promotion request and changes the target environment (or<br />
environment group) to Production 2.0.<br />
Administrator moves the members/object into Production 2.0.<br />
Changes to Release 1.0<br />
1 Check out the member/object from Production 1.0 environment. Developer for release<br />
1.0 selects the member/object from a list of all items in release 1.0 production.<br />
2 Develop and test Release 1.0. Developer begins the programming change and tests the<br />
member/object in his development environment for release 1.0.<br />
3 Promote the member/object to quality assurance 1.0.<br />
Developer or administrator creates the promotion request.<br />
Developer can compile the promotion request into the work library, either as a<br />
separate task or when creating the request.<br />
Administrator moves the members/objects into quality assurance 1.0.<br />
4 Quality assurance testing release 1.0. Tester tests the change for functional consistency<br />
and accuracy.<br />
5 Promote the member/object to Production 1.0.<br />
Tester copies the original promotion request and changes the target environment (or<br />
environment group) to Production 1.0.<br />
Administrator moves the members/objects into Production 1.0.
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
Host System Scenarios<br />
1 Create an Environment task. Define the following environments for Release 2.0:<br />
Production 2.0, one production environment for release 2.0 of a particular<br />
application. Define related environments and place production 2.0 above<br />
production 1.0 to allow the automatic selection of the correct version during check<br />
out.<br />
Quality Assurance 2.0, one QA environment for release 2.0 of a particular application.<br />
Development environment 2.0, one development environment for all developers for<br />
each release, or specific environments per developer or project.<br />
Define the following environments for Release 1.0:<br />
Production 1.0, one production environment for release 1.0 of a particular<br />
application.<br />
Quality Assurance 1.0, one QA environment for release 1.0 of a particular application.<br />
Development environment 1.0, one development environment for all developers for<br />
each release, or specific environments per developer or project.<br />
2 Create a User Profile task.<br />
Define user profiles for the following user roles for Release 2.0.<br />
Developer 2.0 checks out members/objects, performs development, creates a<br />
promotion request targeting release 2.0 quality assurance, and is allowed to perform<br />
concurrent development. The developer compiles the promotion request in the<br />
work library. This user only has authority to check out or promote to the most<br />
current release supported.<br />
Tester 2.0 performs the tests in the test environment with their own copy of the<br />
changes.<br />
Administrator 2.0 promotes changes into the test environment to allow the tester to<br />
start testing a change.<br />
Administrator 2.0 creates projects and moves the promotion request to release 2.0<br />
production. This user also has conflict resolution capabilities.<br />
Define user profiles for the following user roles for Release 1.0.<br />
Developer 1.0 checks out members/objects, performs development, creates a<br />
promotion request targeting release 1.0 quality assurance, and is allowed to perform<br />
concurrent development. The developer compiles the promotion request in the<br />
work library. This user only has authority to check out or promote to releases other<br />
than the new one in development.<br />
31
Chapter 2: Understanding <strong>Implementer</strong><br />
32<br />
Tester 1.0 performs the tests in the test environment with their own copy of the<br />
changes.<br />
Administrator 1.0 promotes changes into the test environment to allow the tester to<br />
start testing a change.<br />
Administrator 1.0 creates projects and moves the promotion request to release 1.0<br />
production. This user also has conflict resolution capabilities.<br />
Differences Between Delta and Non Delta Variations<br />
The previous tasks described how to set up a delta scenario, where the new release library<br />
contains only the objects that are different from the original release. You can also set up for<br />
multiple releases using a non delta scenario, where both libraries contain the entire<br />
application.<br />
TIP The delta scenario is recommended when disk space is an overriding concern<br />
and you have limited changes. The non delta scenario, which is easy to use, is<br />
recommended when disk space is not a consideration and when frequent changes<br />
are made to the database.<br />
The following table describes the differences in setting up delta and non delta scenarios.<br />
Delta Scenario Non Delta Scenario<br />
Description Release 2.0 library contains only<br />
objects that are different from<br />
release 1.0. If some changed<br />
programs use additional files, those<br />
files may also need to be copied.<br />
Release 2.0 and release 1.0 both<br />
contain the entire application.<br />
Related environments Requires set up. Does not require set up.<br />
Related objects Requires set up. Does not require set up.<br />
Library lists Requires release 1.0 libraries in<br />
release 2.0 library list.<br />
Should not have release 1.0<br />
libraries in release 2.0 library list.
Modifications to Vendor Software: Scenario 9<br />
Overview<br />
Host System Scenarios<br />
This scenario is for users who have modified vendor-supplied software and at the same time<br />
need to receive PTFs and new releases from the vendor. Several types of development<br />
activities exist in this scenario: modifying the application, applying vendor PTFs, and<br />
applying an entire new release from the vendor. You define each of these activities in detail.<br />
Applying a new release for a large application that has been heavily modified can be a very<br />
large project; however, it can be greatly simplified by using <strong>MKS</strong> NewVersion with<br />
<strong>Implementer</strong>.<br />
To receive support from the vendor for the original application, all modifications to the<br />
package reside in separate libraries. This allows duplicating any problems using just the basic<br />
application from the vendor to determine if an issue occurred with a custom modification, or<br />
is part of the base application.<br />
For simplicity, this scenario illustrates making the changes directly to the base, although it is<br />
not required. You can keep modified vendor changes in a separate environment.<br />
This scenario is similar to the scenario for Separate Production Modifications, except there<br />
are external changes received from a vendor or from a common development group that you<br />
must periodically incorporate into the application.<br />
This scenario capitalizes on the concurrent development features of <strong>Implementer</strong>, and the<br />
source merging capabilities of NewVersion.<br />
Development Tasks<br />
There are multiple development tasks for this scenario:<br />
change a vendor-delivered member/object or create a new member/object<br />
apply vendor PTFs<br />
33
Chapter 2: Understanding <strong>Implementer</strong><br />
34<br />
apply a new release from the vendor<br />
Change a Vendor-Supplied Member/Object or Create a New One<br />
1 Check Out from custom Mods production. Developer selects the member/object from a<br />
list of all items in custom Mods production and/or the vendor base production. Check<br />
out automatically determines whether to use the version from custom Mods production<br />
or the vendor base production for each change. <strong>Implementer</strong> copies the correct source<br />
into development for custom modifications.<br />
2 Develop and test. Developer codes, compiles, and tests the members/objects.<br />
3 Promote the member/object to Mods quality assurance.<br />
Developer promotes the member/object from Mods development to Mods quality<br />
assurance.<br />
Developer can compile the promotion request into the work library, either as a<br />
separate task or when creating the request.<br />
4 Quality assurance.<br />
Tester tests programs.<br />
Tester copies the original promotion request for promotion.<br />
5 Promote to custom Mods production. Administrator for custom Mods production<br />
promotes the members/objects to customer Mods production.<br />
Apply Vendor PTFs<br />
1 Restore the PTF. Use the instructions supplied by the application software vendor to<br />
restore the PTF into a new library (referred to as the PTF library).<br />
2 Check out all items on the PTF and compile. Check out all items on the PTF, from the<br />
vendor base production environment to the vendor PTF development environment.<br />
Replace the entire source and objects with those from the PTF library and compile all<br />
source. Test the PTF using the development environment and the vendor base<br />
application.<br />
3 Check out any modified items included in the PTF. You can identify custom<br />
modifications to any item included with the PTF using Work with Objects. You must<br />
check out each modified item that is part of the PTF as if making another custom<br />
modification. You must have concurrent development capabilities to perform this check<br />
out since the object was previously checked out to the PTF environment. The next step<br />
applies the PTF to the customized version.<br />
4 Merge the PTF into the customized version. Using the Workbench, merge the PTF<br />
changes into the customized member in development. Specify modified development as<br />
the target library, modified production as production, the PTF development library as<br />
enhanced, and the base application library as base. This applies all vendor-supplied PTF
Host System Scenarios<br />
changes to the modified member. Review the Merge report and respond to any<br />
messages. Compile the member and perform testing. Ensure the PTF development<br />
library is on the library list for testing.<br />
5 Promote any modified items to testing. Promote any modified items that now contain<br />
the PTF to Mods quality assurance.<br />
6 Promote all PTF items to testing. Promote all items changed from the vendor PTF<br />
development environment to the vendor quality assurance environment.<br />
7 Promote modified items to modified custom Mods production. After testing, promote<br />
any modified items from Mods quality assurance to custom Mods production.<br />
8 Promote PTF objects to base application. After testing, promote all vendor objects from<br />
vendor testing to the vendor base production.<br />
Apply the New Release From the Vendor<br />
These tasks require the use of NewVersion, a separately-licensed <strong>MKS</strong> product.<br />
1 Load the new release from the application vendor. Use the instructions supplied by the<br />
application software vendor. The vendor should supply instructions to install the<br />
changes into test libraries, rather than directly into your custom Mods production<br />
version of that software. The directions from the vendor may be as simple as telling you<br />
which libraries to restore from tape, using the Restore Object (RSTOBJ) or Restore<br />
Library (RSTLIB) command. The vendor may provide installation utilities that you must<br />
run as described by the vendor.<br />
2 Analyze the new release libraries. Complete this step using the NewVersion functions<br />
“Define Target Libraries” and “Build Target Object Entries” to analyze the libraries. Use<br />
the “Print Action Messages” function to print a list of action or exception messages to<br />
review or resolve. Use the “Print Object Report” function to determine which objects<br />
require merging.<br />
3 Check out the objects that NewVersion has determined require merging. This checks out<br />
from the custom modifications production environment (with an automatic copy from<br />
the vendor base production, if needed) to a development environment. At this point, you<br />
might encounter members/objects that are already checked out. If you have some of<br />
these members/objects checked out already, check them out to a different development<br />
environment or library. <strong>Implementer</strong> considers this concurrent development.<br />
Concurrent development requires you to resolve conflicts before or during creation of<br />
the promotion request. The library you check out to must be the same library as the<br />
target library defined to NewVersion.<br />
The check out being performed is simply securing a lock on each of the members/<br />
objects. The source that is copied as part of this check out is replaced with the source<br />
merged in the next step.<br />
35
Chapter 2: Understanding <strong>Implementer</strong><br />
36<br />
4 Merge the source members and analyze the results. In NewVersion, use the “Create<br />
Target Source” function to create the new source members. Use the “Merge Reports”<br />
function to verify correct results and resolve object differences.<br />
5 Compile the new source members. In NewVersion, use the “Create Objects” function to<br />
compile the new source members.<br />
6 Test the changes. Use a library list that has the NewVersion target library at the top, with<br />
libraries containing the unmodified version of the objects below it.<br />
7 Promote to the custom modifications environment. The promotion request promotes<br />
from the NewVersion Target library to the custom modification environment. This<br />
promotion request can require resolving conflicts caused by the concurrent<br />
development. For details on concurrent development, see “Concurrent Development:<br />
Scenario 4” on page 21.<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following custom Mods environments for this<br />
scenario:<br />
Custom Mods Production, define a production environment. Related environments<br />
set up with modified production above the base production environment allow<br />
automatic selection of the correct version in check out. If all files reside in a single<br />
library, that library is defined as the file library for this environment, as well as for<br />
the vendor base production environment.<br />
Mods Development, define a development environment.<br />
Mods Quality Assurance, define a quality assurance environment.<br />
Define the following Vendor environments for this scenario:<br />
Vendor Base Production, define a production environment. If all files are in a single<br />
library, define that library as the file library for this environment, as well as for the<br />
modified production environment.<br />
Vendor PTF Development, define a development environment.<br />
Vendor Quality Assurance, define a quality assurance environment.<br />
2 Create a User Profile task. The same group of developers and testers are commonly<br />
responsible for custom changes, as well as applying vendor PTFs and new releases.<br />
Developer checks out members/objects, performs development, creates a promotion<br />
request targeting quality assurance, and is allowed to perform concurrent<br />
development. The developer compiles the promotion request in the work library.
Host System Scenarios<br />
This user has authority to check out from the modified and base production<br />
environments and promote to the modified and vendor PTF quality assurance<br />
environments.<br />
Tester performs the tests either in the modified quality assurance or vendor PTF<br />
environments using their own copy of the changes.<br />
Administrator promotes changes into the test environments to allow the tester to<br />
start testing a change.<br />
Administrator creates projects and moves the promotion requests to modified<br />
production or to the vendor base production environments. This user also has<br />
conflict resolution capabilities.<br />
Release Control: Scenario 10<br />
Overview<br />
A typical release control development scenario starts with setting up your products and<br />
versions, and attaching the environments associated with each product at the version level.<br />
You then create an open release (the release must be at a status that allows software changes<br />
to occur, for example, ENV-OPEN). Any issues or design requests that have at least one<br />
entity promoted to production while the release is open are attached to that release.<br />
Follow your normal change management procedures for checking out and promoting<br />
member/objects. When you are ready to close a release (for example, for system test or to<br />
target production) set the release to a status that does not allow software changes (for<br />
example, ENV-CLOSED). This prevents promotions from targeting the environments<br />
defined for the version that allow creating standard releases from it (defined when you attach<br />
an environment to a version). Changing the status from one that allows software changes to<br />
one that does not allows you to capture an image of the <strong>Implementer</strong> repository so you know<br />
exactly which objects were in the release when it closed.<br />
37
Chapter 2: Understanding <strong>Implementer</strong><br />
38<br />
When you are finished with the release, set it to a status where all four status fields, Allow<br />
software change, Allow packaging, Allow controlled distribution, and Allow distribute changes<br />
are set to N (for example, NOT SUPPORTED). Changing the release status allows you to<br />
control movement into production environments. You can now create a new open release,<br />
allowing the change management cycle to begin again.<br />
Setup Tasks<br />
In most cases the implementation of this feature requires minimal setup to your existing<br />
configuration, allowing you to quickly append release control into your existing change<br />
management operation.<br />
The setup tasks required for this scenario are as follows:<br />
1 Create environments. No special considerations are required when defining<br />
environments for release control. Follow the environment setup steps described in a<br />
previous scenario, or see “<strong>Implementer</strong> <strong>Administration</strong>” on page 63 for information on<br />
creating environments.<br />
2 Define user authorities. Users must have authority to work with products and versions.<br />
This is defined in the Work with Users function. Set the Maintain Products and Maintain<br />
Versions fields to Y for each user who maintains product versions.<br />
3 Define products, versions, and releases. For details, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release<br />
Management <strong>Guide</strong>.<br />
4 Verify the software release process configuration. This consists of release types and the<br />
release status; together, they determine the development path that each release must<br />
follow.<br />
Release types are user-defined values that identify the types of releases you manage<br />
within the release control process. Release types are classified as either standard<br />
(STD) or program temporary fix (PTF).<br />
Release status defines the path a release must follow before you can changed it to<br />
the next available status. It also defines the functions you can perform to the release<br />
during each phase of the development cycle. A person with product management<br />
responsibility typically controls this stage progression.<br />
The release status controls four functions:<br />
Allow software changes controls whether software can be promoted into the<br />
environments attached to the product version.<br />
Allow create package controls whether packages can be created.<br />
Allow controlled distribution controls whether the release is available for<br />
selection to distribute to a customer system, but does not make it a default<br />
release. This is also used for release deployment.
Remote System Scenarios<br />
Allow distribute changes controls whether the release can be the default release<br />
to distribute to a customer system as the most current release available. This is<br />
also used for release deployment.<br />
The release category and the release status together determine the development path<br />
that a release must follow, and the dependency automatically associated between a<br />
current release and a previous release.<br />
Release Control Development Cycle<br />
The development cycle associated with release control effectively handles when objects are<br />
promoted back to production, without hindering the start of new development. Release<br />
control supports both single version and multiple version development models, as illustrated<br />
in the following chart.<br />
Remote System Scenarios<br />
The next six scenarios pertain to promotions that target remote iSeries systems using the<br />
<strong>Implementer</strong> Receiver.<br />
39
Chapter 2: Understanding <strong>Implementer</strong><br />
Remote Production on Same Request: Scenario 11<br />
40<br />
Overview<br />
In this scenario you distribute changes to a single remote system on the same promotion<br />
request as a local version of production environment. This scenario ensures the production<br />
system remains synchronous with the development system.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out. Developer checks out to a personal library, project library, or shared<br />
development library. The developer checks out from the local production version.<br />
2 Develop and test. Developer codes, compiles, and tests programs.<br />
3 Promote and distribute to production.<br />
Developer creates the promotion request targeting an environment group. The<br />
environment group has the check out From environment listed as the first<br />
environment, and the remote environment as the second environment.<br />
Developer can compile the promotion request into the work library. Typically, you<br />
compile just for the first environment.<br />
Administrator moves the members/objects into the production environments. You<br />
can perform the moves to different environments at different times, if needed. Many<br />
options exist for distributing changes to the remote system.
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Remote System Scenarios<br />
Local Production, one production environment for the local development system.<br />
Remote Production, one production environment for the remote production system.<br />
Development, one development environment for all developers, or specific<br />
environments per developer or project.<br />
2 Create an Environment Group task. Define the following environment group:<br />
Production, create an environment group that combines the local production<br />
environment with the remote production environment.<br />
3 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, and creates a<br />
promotion request targeting the quality assurance environments. The developer<br />
compiles the promotion request in the work library.<br />
Administrator or project leader creates projects and moves the promotion request to<br />
production.<br />
Remote Production on Different Request: Scenario 12<br />
Overview<br />
In this scenario you distribute changes to a single remote system on a different promotion<br />
request than the local promotion, to the production environment. This scenario ensures the<br />
production system remains synchronous with the development system.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out. Developer checks out to a personal library, project library, or shared<br />
development library. The developer checks out from the local production version.<br />
2 Develop and test. Developer codes, compiles, and tests programs.<br />
41
Chapter 2: Understanding <strong>Implementer</strong><br />
42<br />
3 Promote to production.<br />
Developer creates the promotion request targeting an environment.<br />
Developer can compile the promotion request into the work library. Typically, you<br />
compile just for the first environment.<br />
Administrator moves the members/objects into the production environment. You<br />
can perform the moves to the different environments at different times, if needed.<br />
Many options exist for distributing the changes to the remote system.<br />
4 Promote and distribute to remote production.<br />
Developer creates the promotion request targeting a remote environment. You can<br />
create the request by copying the original request.<br />
Administrator moves the members/objects into the production environments. You<br />
can perform the moves to the different environments at different times, if needed.<br />
Many options exist for distributing the changes to the remote system.<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Local Production, one production environment for the local development system.<br />
Remote Production, one production environment for the remote production system.<br />
Development, one development environment for all developers, or specific<br />
environments per developer or project.<br />
2 Create an Environment Group task. Define the following environment group:<br />
Production, one environment group that combines the local production environment<br />
with the remote production environment.<br />
3 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, and creates a<br />
promotion request targeting the quality assurance environments. The developer<br />
compiles the promotion request in the work library.<br />
Administrator or project leader creates projects and moves the promotion request to<br />
production.
Testing on Remote: Scenario 13<br />
Overview<br />
In this scenario, you distribute changes to a single remote system in two phases:<br />
1 To test environments on the host and remote.<br />
Remote System Scenarios<br />
2 From test environment on the host to both the local and remote production. You<br />
distribute the changes for testing on the same promotion request as a local version of the<br />
quality assurance environment. You distribute the changes for production on the same<br />
promotion request as a local version of production environment.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out. Developer checks out to a personal library, project library, or shared<br />
development library. The developer checks out from the local production version.<br />
2 Develop and test. Developer codes, compiles, and tests programs.<br />
3 Promote and distribute to local and remote test environments.<br />
Developer creates the promotion request targeting an environment group. The<br />
environment group has the environment you checked out from listed as the first<br />
environment, and the remote environment as the second environment.<br />
Developer can compile the promotion request into the work library. Typically, you<br />
compile just for the first environment.<br />
Administrator moves the members/objects into the test environments. You can<br />
perform the moves to the different environments at different times, if needed. Many<br />
options exist for distributing changes to the remote system.<br />
43
Chapter 2: Understanding <strong>Implementer</strong><br />
44<br />
4 Quality assurance testing. Testers (on both the local and remote systems) test the change<br />
for functional consistency and accuracy.<br />
5 Promote and distribute to local and remote production environments.<br />
Tester on the local system creates the promotion request targeting an environment<br />
group. The environment group has the environment you checked out from listed as<br />
the first environment, and the remote environment as the second environment.<br />
Developer can compile the promotion request into the work library. Typically, you<br />
compile just for the first environment.<br />
Administrator moves the members/objects into the production environments. You<br />
can perform the moves to the different environments at different times, if needed.<br />
Many options exist for distributing the changes to the remote system.<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Local Production, one production environment for the local development system.<br />
Remote Production, one production environment for the remote production system.<br />
Local Quality Assurance, the local QA environment.<br />
Remote Quality Assurance, the remote QA environment.<br />
Development, one development environment for all developers, or specific<br />
environments per developer or project.<br />
2 Create an Environment Group task. Define the following environment groups:<br />
Production, one environment group that combines the local production environment<br />
with the remote production environment.<br />
Testing, one environment group that combines the local test environment with the<br />
remote test environment.<br />
3 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, and creates a<br />
promotion request targeting the quality assurance environments. The developer<br />
compiles the promotion request in the work library.<br />
Tester performs the test in this environment with their own copy of the changes.<br />
Administrators promotes changes into the QA environment to allow the tester to<br />
start testing a change.<br />
Administrator or project leader creates projects and moves the promotion request to<br />
production.
Multiple Remote Productions Same Changes: Scenario 14<br />
Overview<br />
Remote System Scenarios<br />
In this scenario, you distribute the same changes to multiple remote systems on a different<br />
promotion request than the local version of production environment. This scenario ensures<br />
the production system remains synchronous with the development system.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out. Developer checks out to a personal library, project library, or shared<br />
development library. The developer checks out from the local production version.<br />
2 Develop and test. Developer codes, compiles, and tests programs.<br />
3 Promote to local production.<br />
Developer creates the promotion request targeting an environment.<br />
Developer can compile the promotion request into the work library. Typically, you<br />
compile just for the first environment.<br />
Administrator moves the members/objects into the production environment.<br />
4 Promote and distribute to remote production.<br />
Developer creates the promotion request targeting an environment group.<br />
Administrator moves the members/objects into the remote production<br />
environments. You can perform the moves to the different environments at different<br />
times, if needed. Many options exist for distributing the changes to the remote<br />
system.<br />
45
Chapter 2: Understanding <strong>Implementer</strong><br />
46<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Local Production, one production environment for the local development system.<br />
Remote Production, one production environment for the remote production system.<br />
Development, one development environment for all developers, or specific<br />
environments per developer or project.<br />
2 Create an Environment Group task. Define the following environment group:<br />
Production, one environment group that combines the local production environment<br />
with the remote production environments.<br />
3 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, and creates a<br />
promotion request targeting the quality assurance environments. The developer<br />
compiles the promotion request in the work library.<br />
Administrator or project leader creates projects and moves the promotion request to<br />
production.<br />
Multiple Remote Systems: Scenario 15<br />
Overview<br />
In this scenario, you distribute base changes to multiple remote systems and a specific<br />
promotion request to remote systems.This scenario ensures the production system remains<br />
synchronous with the development system.
Development Tasks<br />
Remote System Scenarios<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out from base production. Developer checks out to a personal library, project<br />
library, or shared development library. The developer checks out from the local<br />
production version.<br />
2 Develop and test. Developer codes, compiles, and tests programs.<br />
3 Promote and distribute to base production and multiple remote sites.<br />
Developer creates the promotion request targeting an environment group. The<br />
environment group has the environment you checked out from listed as the first<br />
environment, and the remote environment as the second environment.<br />
Developer can compile the promotion request into the work library. Typically, you<br />
compile just for the first environment.<br />
Administrator moves the members/objects into the production environments. You<br />
can perform the moves to the different environments at different times, if needed.<br />
Many options exist for distributing the changes to the remote system.<br />
4 Check out from Site N Mods on local system. Developer checks out to a personal library,<br />
project library, or shared development library. The developer checks out from the Local<br />
Site N version.<br />
5 Develop and test. Developer codes, compiles, and tests programs.<br />
6 Promote and distribute to remote site N production.<br />
Developer creates the promotion request targeting an environment.<br />
Developer can compile the promotion request into the work library. Typically, you<br />
compile just for the first environment.<br />
Administrator moves the members/objects into the production environments. You<br />
can perform the moves to the different environments at different times, if needed.<br />
Many options exist for distributing the changes to the remote system.<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Local Production, one production environment for the local development system.<br />
Remote Production, one production environment for the remote production system.<br />
Development, one development environment for all developers, or specific<br />
environments per developer, project, or site.<br />
47
Chapter 2: Understanding <strong>Implementer</strong><br />
48<br />
2 Create an Environment Group task. Define the following environment group:<br />
Production, one environment group that combines the local production environment<br />
with the remote production environment.<br />
3 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, and creates a<br />
promotion request targeting the quality assurance environments. The developer<br />
compiles the promotion request in the work library.<br />
Administrator or project leader creates projects and moves the promotion request to<br />
production.<br />
Check Out From Remote: Scenario 16<br />
Overview<br />
In this scenario you check out the source from a remote system to development on the host<br />
system. You promote the changes to the production environment on the host and distribute<br />
the changes to the remote system where the original check out occurred. You distribute these<br />
changes on a different promotion request than the local version to the production<br />
environment.<br />
Development Tasks<br />
This is the typical task sequence from the start of a programming change to completion.<br />
1 Check out. Developer checks out source from the remote system to a personal library,<br />
project library, or shared development library. The developer checks out to the local<br />
development environment.<br />
2 Develop and test. Developer codes, compiles, and tests programs.<br />
3 Promote to local production.<br />
Developer creates the promotion request targeting the local production environment.<br />
Developer can compile the promotion request into the work library. Typically, you<br />
compile just for the first environment.<br />
Administrator moves the members/objects into the production environment.
4 Promote and distribute to remote production.<br />
Multi-Platform Development and Deployment Scenarios<br />
Developer creates the promotion request targeting by system/environment. In this<br />
case, you would probably distribute only the source.<br />
Administrator compiles the members/objects into work libraries on the remote<br />
system.<br />
Administrator moves the members/objects into the remote production<br />
environments.<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Create an Environment task. Define the following environments:<br />
Local Production, one production environment for the local development system.<br />
Remote Production, one production environment for the remote production system.<br />
Development, one development environment for all developers, or specific<br />
environments per developer or project.<br />
2 Create a User Profile task. Define user profiles for the following user roles:<br />
Developer checks out members/objects, performs development, and creates a<br />
promotion request targeting the quality assurance environments. The developer<br />
compiles the promotion request in the work library.<br />
Administrator or project leader creates projects and moves the promotion request to<br />
production.<br />
Multi-Platform Development and Deployment<br />
Scenarios<br />
Change is always certain. In every industry, companies face the difficult task of trying to<br />
manage a multitude of changes. The companies that handle changes best are the ones that<br />
excel and rise above their competition.<br />
With the rapid migration towards e-Business solutions, the rate at which you need to turn<br />
around system solutions has increased dramatically. There is no buffer for backtracking and<br />
reworking when things are missed or overlooked.<br />
There is also a much greater need to integrate many different system components from<br />
various teams. The days of long release cycles are disappearing, and this changing business<br />
model demands tighter management and coordination. Now, more than ever, development<br />
teams need support for Software Configuration Management (SCM) and for handling change<br />
requests quickly and efficiently, especially across multiple platforms.<br />
49
Chapter 2: Understanding <strong>Implementer</strong><br />
50<br />
<strong>MKS</strong> Integrity enables collaboration across the enterprise, connecting technical and non<br />
technical teams—even partners and customers—in rapidly building, sustaining, and<br />
evolving e-Business processes, Web content, and software applications. <strong>MKS</strong> Integrity can be<br />
used to manage your development work on the iSeries, as well as your Java and C++<br />
development.<br />
Integrated Solution<br />
In a rapidly evolving organization, change happens at Web speed. Rapid business evolution<br />
means rapid customer growth, requiring new forms of collaboration, rapid content<br />
expansion, and application adaptation leading to rapid system instability. The result is<br />
evolution shock. <strong>MKS</strong> Integrity can prevent evolution shock, providing you with content<br />
management, software management, and collaboration in one built-for-e-Business integrated<br />
package.<br />
Software Configuration Management<br />
Rapid business evolution means rapid software adaptation to truly evolve to e-Business.<br />
Organizations now must rapidly integrate and evolve back end systems for maximum<br />
competitive advantage.<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source allow team members to effectively manage multiple<br />
development projects, secure software assets, meet deadlines, and contribute throughout the<br />
application and development lifecycle. Using <strong>MKS</strong>’s SCM solutions, organizations can track<br />
their e-Business evolution with precision and avoid the pitfalls of evolution shock.<br />
Change Management<br />
Rapid business evolution means new forms of collaboration. In an e-Business, virtual teams<br />
of people from inside and outside of the organization create a powerful chain of actions that<br />
join together to continually evolve content, software, and business processes.<br />
<strong>MKS</strong> Integrity automates and synchronizes your business and IT processes so that only<br />
authorized content and application changes are delivered with accuracy at the right time.<br />
Organizations using <strong>MKS</strong> Integrity will strengthen their chain-of-action, particularly when<br />
faced with constant business pressure to respond to changes.<br />
iSeries Design and Implementation Management<br />
The <strong>MKS</strong> iSeries products offers both functionally and technically advanced tools that protect<br />
your company’s corporate investment in application systems on the iSeries, while ensuring<br />
production software integrity and quality. It is designed to fulfill the short- and long-term<br />
requirements of your application development lifecycle.
Multi-Platform Development and Deployment Scenarios<br />
<strong>Implementer</strong> provides implementation management controls for the check out and<br />
promotion of traditional and non traditional members and objects as they move from<br />
production to development, from development to QA, and from QA to production. During<br />
these processes, status information is fed back to <strong>MKS</strong> Integrity that, in turn, serves to inform<br />
anyone interested in the issue of the project’s status.<br />
<strong>Implementer</strong> supports Windows and Web-based applications being developed on a<br />
Windows desktop, using <strong>MKS</strong> Source to manage the desktop. With <strong>Implementer</strong>, you can<br />
automatically pull the files needed for execution (or in the case of HTML, the content to be<br />
deployed) from the <strong>MKS</strong> Source build Sandbox®, and deploy these items using the<br />
<strong>Implementer</strong> Receiver.<br />
<strong>MKS</strong> Integrity provides issue tracking using a Windows or Web interface. <strong>MKS</strong> Integrity is<br />
completely customizable and eliminates the need for a user to sign on to the iSeries to log<br />
issues.<br />
A single issue ID is used to manage a change across multiple platforms with <strong>MKS</strong> Integrity,<br />
when using <strong>Implementer</strong> and <strong>MKS</strong> Source to manage your IFS multiple platform<br />
development on the iSeries.<br />
Working in a multi-platform environment places additional requirements on the<br />
development process. Dealing with problems and issues is part of the normal development<br />
lifecycle, and during multi-platform development and deployment, the need to deal with<br />
them becomes particularly acute. Consequently, there is a critical need to:<br />
manage change requests in the software development lifecycle, including across<br />
platforms and during deployment<br />
manage the physical movement of source and objects<br />
ensure the context for deployment is appropriate for the:<br />
platform<br />
file type (HTML, client Java, server Java, native objects, databases)<br />
target technology environment (such as, Web server and database server)<br />
Multi-platform development and deployment is defined as software development where:<br />
objects are built on one platform and deployed on another, or<br />
objects deployed on multiple platforms inter-operate to form a single solution and are<br />
managed together<br />
A platform in this case does not just refer to hardware—it can also be a logical platform. For<br />
example, Java provides a target platform no matter what hardware it is run on, and the<br />
iSeries, NT, and UNIX operating systems also provide platforms.<br />
51
Chapter 2: Understanding <strong>Implementer</strong><br />
Software Development Lifecycle<br />
52<br />
The software development lifecycle is highly involved and has many variables. Accordingly,<br />
only the steps in the software development lifecycle applicable to problems encountered in<br />
multi-platform development and deployment are discussed herein. The software<br />
development lifecycle is described in more detail in “Managing the Physical Movement of<br />
Objects” on page 54.<br />
Many multi-platform development models are possible. Some examples of the types of<br />
development and deployment are as follows:<br />
development object (such as static Web content (HTML, GIF)) is deployed using the<br />
iSeries as the target Web server<br />
development object is one-to-one with the release object, such as for server Java<br />
development<br />
client Java development, for example, <strong>Implementer</strong> Capability Wizard<br />
client Visual Basic development (an application, such as <strong>MKS</strong> Integrity, accesses an<br />
OS/400 database)<br />
client C/C ++ development<br />
any application using a SETUP.EXE executable<br />
a proprietary development and deployment model (for example, PeopleSoft World)<br />
Another way to look at the various development environments is to look at several of the<br />
metrics that apply to all development types. Each environment has varying degrees of<br />
change being made during development through to the final object being placed in<br />
production. The metrics to consider are as follows:<br />
Degree of Transformation<br />
Between Development and<br />
Production<br />
Same (HTML, OCL)<br />
One to one (RPG, Java)<br />
One to many (C, dll, JAR<br />
(Java Archive), *SRVPGM<br />
One to many several times<br />
(SETUP.EXE)<br />
The development process can involve many users and many roles. The major roles of interest<br />
in multi-platform development and deployment are:<br />
developer<br />
builder (the buildmaster) of the release object<br />
Deployment Environments Execution Locations<br />
Native RPG<br />
Java programs<br />
Application server<br />
Web server<br />
Visual Basic applications<br />
Open environment (servlets)<br />
Proprietary environments<br />
Server<br />
Client<br />
Client (served from server)
deployer<br />
tester<br />
development manager/project leader<br />
Multi-Platform Development and Deployment Scenarios<br />
Additional roles may be added at each point in the process; however, adding roles changes<br />
the process, but it does not alter the change management activities.<br />
Managing Change Requests<br />
Software systems require change. Change is identified by a change request. A change goes<br />
through the appropriate software development lifecycle based on the technology and the<br />
platform. By using change requests, two classes of management information must be<br />
available at all times. These can be represented by the following questions:<br />
Where in the software development lifecycle and deployment is the change request?<br />
What change requests are resolved in this new version of an object?<br />
In addition to tracking by change request, it is also important to be able to work based on<br />
change requests. This allows work to be done on a change request and at the same time to<br />
affect all of the related objects.<br />
The General Process<br />
Typically, change requests flow through the following stages:<br />
Does an issue<br />
exist?<br />
Customer<br />
Deliver<br />
Analyze<br />
Change<br />
Requests<br />
Design<br />
Implement<br />
Test<br />
53
Chapter 2: Understanding <strong>Implementer</strong><br />
54<br />
Identifying an Issue<br />
A user submits a change request to report a bug, enhance functionality, or add new<br />
features.<br />
Analyze<br />
Once you decide to accept the change request, you analyze the problem and identify<br />
what needs to be created or changed to provide a suitable solution. This may include<br />
things other than software, such as technical publications or training materials.<br />
Design<br />
You define the solution, establish a schedule for completion, and assign the tasks to<br />
individuals.<br />
Implement<br />
You develop each solution component, which may include coding or documenting the<br />
changes to the product, system, or application.<br />
Test<br />
You test the solution to ensure it performs as designed and meets the customer’s original<br />
need.<br />
Deliver<br />
The cycle is completed once you deliver the requested change back to the customer,<br />
ensuring their satisfaction. This corresponds to delivering a new release of a product or<br />
releasing the changes to the production systems.<br />
“Identifying an issue” and “Analyze” represent the Decision Phase, which addresses the<br />
assessment and negotiation steps that are required to ensure that changes are prioritized<br />
and scheduled for a timely resolution. “Design” and “Implement” are referred to as the<br />
Development Phase. “Test” is referred to as the Verification Phase, and “Deliver” as the<br />
Deployment Phase.<br />
Sometimes, for small changes, a person may quickly go through the thought process for<br />
the first four steps in one step (for example, correcting a typographical error). For more<br />
complicated cases, these steps may be handled by different roles such as a review board,<br />
developer, or QA manager. It is important, therefore, to structure your process to<br />
incorporate the ability to hand off the issue to the responsible parties. Whatever process<br />
you enforce, you want to verify that it supports these four basic phases.<br />
Managing the Physical Movement of Objects<br />
The purpose of a change management system is to manage the movement of software objects.<br />
Yo must accomplish this in an appropriate way for the platform containing the objects. This<br />
includes, for example, honoring and enforcing the security and integrity of the platform.<br />
<strong>MKS</strong> Integrity provides an effective means of dealing with the problems and issues<br />
surrounding multi-platform development and deployment.
Multi-Platform Development and Deployment Scenarios<br />
<strong>MKS</strong> Integrity provides a complete SCM solution. It helps development, QA, and<br />
geographically distributed team members to easily organize, manage, and contribute to the<br />
software development lifecycle. This system provides Web-based access to software<br />
configuration management, defect tracking and task management (<strong>MKS</strong> Integrity)—all the<br />
tools a team needs to move projects from code to release.<br />
<strong>MKS</strong> Source and <strong>MKS</strong> Integrity introduce some new terms you may not be familiar with. The<br />
glossary provides brief descriptions of some of the common terms this guide uses when<br />
discussing change management.<br />
The following diagram shows the typical object flow during the Development, Verification,<br />
and Deployment Phases of the software development lifecycle.<br />
55
Chapter 2: Understanding <strong>Implementer</strong><br />
56<br />
The Change Request Process Desktop iSeries 400<br />
Step One: Log Change Request<br />
Step Two: Initiate and Complete<br />
Development<br />
Step Three: Create Release Object for<br />
Production (Build)<br />
Step Four: Move Release Object to Testing<br />
Step Five: Move Release Object to<br />
Production<br />
Development<br />
Sandbox<br />
<strong>MKS</strong> Source<br />
Archives<br />
(Source, Objects)<br />
Build Sandbox<br />
Source<br />
Objects<br />
Verification<br />
Phase<br />
Deployment<br />
Phase<br />
Promotion<br />
Request<br />
Development<br />
Phase<br />
Development<br />
Testing<br />
Details of this flow are described in the following sections. The process describes typical new<br />
product (released-based) desktop development. Another form of similar software<br />
development is continuous desktop development. The next table characterizes each type.<br />
IFS<br />
Production<br />
Production<br />
Archive<br />
Production<br />
Production n<br />
Archive
Release-based<br />
Development<br />
Continuous<br />
Development<br />
Multi-Platform Development and Deployment Scenarios<br />
Characteristics Significance of Characteristics<br />
Problems typically represent requirements or<br />
new features and functions as specified by<br />
product management or business analysis.<br />
The initial development process requires the<br />
coordination of the analysis, design, and<br />
development tasks across various team<br />
members. This model supports the iterative<br />
steps of the development process.<br />
There is a clear distinction between the<br />
various components that need to be<br />
developed, and the testing process that<br />
focuses on black box functionality.<br />
Need to track all tasks being done according<br />
to relevant components.<br />
With larger development tasks, multiple<br />
people may need to work on the same<br />
proposal and their work status needs to be<br />
coordinated.<br />
Need to separate the problem process from<br />
the proposal and work instruction processes<br />
to allow for separate levels of monitoring.<br />
Certification and acceptance testing are<br />
typically handled by a Quality Assurance<br />
(QA) team.<br />
Decisions to release the product are based<br />
on the results of the system testing phase.<br />
Initial development phase has passed and<br />
software has been released to the customer.<br />
Maintenance cycle has begun.<br />
All work is generated by issues or problems<br />
raised against the released product.<br />
Changes are typically bugs or small<br />
enhancements.<br />
Several problems are gathered together to<br />
be fixed in a particular release.<br />
Development and product managers work<br />
together to negotiate priorities and decide<br />
what will be fixed in a release.<br />
Requirements analysis and design are<br />
minimal and it is not necessary to track them<br />
with separate states.<br />
Need to ensure all code changes are tracked<br />
along with the original problem.<br />
Functional testing is handled within the<br />
development team.<br />
Proposals and work instructions may be used<br />
but are not tracked with a process.<br />
Work is planned and monitored closely to<br />
distribute work evenly across resources and<br />
synchronize parallel tasks.<br />
When various groups within an organization<br />
are monitoring the progress of problems,<br />
they may not be interested in the detailed<br />
development status. By separating the<br />
process from development tracking, it is<br />
possible for various managers to monitor the<br />
status of the problems they are interested in<br />
at a high level.<br />
Separate process flows for proposals and<br />
work instructions help to focus the process<br />
details as needed rather than having one<br />
long overwhelming process on a problem.<br />
Supports parallel development tasks and<br />
allows for independent tracking of each task.<br />
Process focused on the problem only, since<br />
the goal is to manage a high volume of<br />
issues rapidly.<br />
It is important to record changes with a<br />
proposal change package, but the process<br />
flow for the proposal is not significant.<br />
Simplified process facilitates the rapid handoff<br />
of responsibility among the developer,<br />
build coordinator, and QA team.<br />
Able to handle a high volume of problems<br />
and ensure they do not fall through the<br />
cracks or get lost along the way.<br />
57
Chapter 2: Understanding <strong>Implementer</strong><br />
Change Request Process<br />
58<br />
Step One: Log Change Request<br />
Enter change requests (problems or program modification requests) as <strong>MKS</strong> Integrity issues.<br />
Step Two: Initiate and Complete Development<br />
Using <strong>MKS</strong> Integrity issues, assign work to developers.<br />
The developer checks out the required source in either <strong>Implementer</strong> or <strong>MKS</strong> Source,<br />
depending on the platform location and tool appropriateness of the objects needing to be<br />
changed.<br />
An example of mixed development is a client/server application where the iSeries is used as<br />
the server. The server programs are written in RPG and the client side is written in C, Visual<br />
Basic, or Java. In this scenario, a single issue could result in a development effort on both<br />
platforms, with <strong>Implementer</strong> supporting the OS/400 side and <strong>MKS</strong> Source supporting the<br />
rest.<br />
The developers finish the work. <strong>MKS</strong> Source-side developers check in a change package to<br />
the appropriate source project, and specify the proposal number associated with the issue<br />
they have fixed. OS/400 developers promote their changes to the appropriate QA<br />
environment on the iSeries. If these changes rely on the client-based changes also being<br />
made, the changes are left in the development environment on the iSeries pending receipt<br />
and deployment of the client objects from <strong>MKS</strong> Source. Once the client objects are deployed<br />
to the OS/400 development environment, all objects are then promoted on a single<br />
<strong>Implementer</strong> promotion request to the QA environment.<br />
Step Three: Create Release Object for Production (Build)<br />
Two types of desktop development need to be considered here: release-based and continuous.<br />
The following describes released-based development. Continuous development is essentially<br />
the same, except there is no build reference.<br />
The buildmaster updates all proposals associated with the issues addressed by the current<br />
build. That way all the issues can be tied back to the build using a build number (custom field<br />
on a proposal). This build number field can either be entered manually to the proposals in<br />
cases where few issues are involved, or it can be set using the <strong>MKS</strong> Integrity batch operation<br />
function in larger impact changes.<br />
NOTE In continuous development, the buildmaster uses the Export to <strong>Implementer</strong><br />
command to export by issue number.<br />
The buildmaster builds the code that includes the set of issue fixes. The buildmaster also<br />
gathers the source code version information from the change packages attached to the<br />
proposals that address the issues, either using the <strong>MKS</strong> Integrity Change Package feature or<br />
by manually determining what source items are required based on the level of complexity
Multi-Platform Development and Deployment Scenarios<br />
and type of work. After resolving any conflicts (manually), the buildmaster checks out all<br />
required source objects to a build sandbox and generates the required binaries. When the<br />
buildmaster is satisfied the built objects are correct, they have the option to check in the<br />
objects to a project to archive the release objects themselves.<br />
After the binaries (or non binaries that should be deployed) are ready and all proposals<br />
addressed by this build are flagged with a build number identifier, the buildmaster manually<br />
moves the objects to be deployed to an IFS location on the iSeries to stage the objects for<br />
deployment.<br />
NOTE This location should be a non cumulative location that only contains objects<br />
specifically related to this build.<br />
At this point, you issue the Export to <strong>Implementer</strong> command. For details on running the<br />
export, see “Exporting to <strong>Implementer</strong>” on page 140.<br />
Step Four: Move Release Object to Quality Assurance<br />
At this point, the build is ready for system testing. Depending on the circumstances, the QA<br />
group may do either of the following from <strong>Implementer</strong>:<br />
process the promotion request from step 4, if created<br />
access the Workbench, filter the issue, and then create a promotion request<br />
If user acceptance tests fail, the issues must go back to development for investigation and<br />
resolution. Once the build is accepted and released, all the issues addressed by that release<br />
are marked as closed.<br />
Step Five: Move Release Object to Production<br />
Once the objects are promoted to a production environment using <strong>Implementer</strong>, the status of<br />
all the appropriate <strong>MKS</strong> Integrity issues are updated.<br />
Appropriate Deployment<br />
Objects for deployment are being installed into a production system. In the simplest case, just<br />
placing an object in the proper location updates the production system, as required. At the<br />
other end of the scale, significant pre- and post-processing may be required to update the<br />
production system properly. For example, you must stop and restart the Weblogic<br />
Application Server before the server can recognize changed classes, because the classes were<br />
cached earlier by the server. These functions can be performed using promotion request<br />
special commands. For more information on special commands, see the <strong>MKS</strong> <strong>Implementer</strong><br />
<strong>2006</strong> User <strong>Guide</strong>.<br />
59
Chapter 2: Understanding <strong>Implementer</strong><br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration: Scenario 17<br />
60<br />
In this scenario, <strong>Implementer</strong> users log new issues using <strong>MKS</strong> Integrity, which provides<br />
workflow management and issue tracking using a Windows or Web interface, eliminating<br />
the need for you to sign on to the iSeries to log issues.<br />
<strong>MKS</strong> Integrity is the best of breed enterprise choice for highly customizing process and<br />
workflow management. Any simple defect tracking tool can record the status of a change<br />
request, but it does not monitor all the components that need to be modified, or the variety of<br />
tasks that need to be performed to resolve the issue. <strong>MKS</strong> Integrity extends the concept of<br />
defect tracking to include support for managing components, tasks, and workflow. This is<br />
particularly important when your organization has implemented a Software Configuration<br />
Management (SCM) process for the proposal, review, and approval of all software changes.<br />
With this solution, <strong>MKS</strong> Integrity is the enterprise-wide issue management system.<br />
<strong>MKS</strong> Integrity integrates with other developer productivity tools—including <strong>Implementer</strong>, to<br />
control and track development activity in <strong>Implementer</strong>, and Microsoft Project. This leverages<br />
your software investments and enhances the coverage of your application development<br />
lifecycle. <strong>MKS</strong> Integrity allows you to manage your Integrated File System (IFS) development<br />
on the iSeries and PC platforms with a single issue ID that tracks a software change across<br />
multiple platforms.<br />
Development Tasks<br />
1 Log change request. Enter change requests (problems or program modification requests)<br />
as <strong>MKS</strong> Integrity issues.<br />
2 Initiate and complete development. Using <strong>MKS</strong> Integrity issues, assign work to<br />
developers.<br />
3 Create release object for production (build). Two types of desktop development need to<br />
be considered here: release-based and continuous. Continuous development is<br />
essentially the same as released-based development, except there is no build reference.<br />
4 Move release object to quality assurance. The build is ready for system testing.<br />
5 Move release object to production. Once the objects are promoted to a production<br />
environment on the iSeries, the status of all appropriate <strong>MKS</strong> Integrity issues is updated<br />
and the related <strong>Implementer</strong> change packages are closed.<br />
Setup Tasks<br />
The setup tasks required for this scenario are as follows:<br />
1 Install and configure <strong>Implementer</strong> Server. For details, see “Configuring the <strong>Implementer</strong><br />
Server” on page 217.<br />
1 Install and configure <strong>MKS</strong> Integrity Server and <strong>MKS</strong> Integrity. For details, see the<br />
<strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.
Communications Options<br />
2 Configure <strong>Implementer</strong> to use <strong>MKS</strong> Integrity for issue tracking. For details, see<br />
“<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration” on page 196.<br />
3 (Optional) Configure <strong>Implementer</strong> to use <strong>MKS</strong> Source archiving. For details, see<br />
“<strong>Implementer</strong> and <strong>MKS</strong> Source Integration” on page 259.<br />
Communications Options<br />
<strong>Implementer</strong> provides three options for communications entries between host and remote<br />
systems:<br />
Use existing communication entries. This is the recommended method, and no<br />
additional set up is required.<br />
Add communication entries to a generic mode description. Using a generic<br />
communications entry provides some additional control over your communication, and<br />
must be specifically set up.<br />
Add communication entries to a specific mode description. You can create an<br />
<strong>Implementer</strong>-specific mode description that reserves the communication sessions<br />
exclusively for <strong>Implementer</strong> use. This ensures a session is available to <strong>Implementer</strong><br />
when it attempts to communicate with the remote system (unless the maximum<br />
numbers of sessions for the mode are already in use by other <strong>Implementer</strong> jobs). This<br />
option provides the greatest control over your communications. It requires setup on both<br />
the host and remote systems.<br />
For details on this topic, see “Setting Up Communications Entries” on page 169.<br />
Distribution Methods<br />
<strong>Implementer</strong> supports software distribution on tape and DVD, as well as the following<br />
distribution methods:<br />
SDMCom. Distributions using <strong>Implementer</strong>’s own object distribution facility, SDMCom,<br />
provides between 20–35 percent better performance over SNADS distribution. Its<br />
advanced features use compression algorithms and blocking specifically for remote<br />
distributions.<br />
TCP/IP (FTP or tape). Requires additional setup as described in “Setting Up for TCP/IP<br />
Distribution” on page 173.<br />
SNADS. Requires additional setup as described in “Setting Up for SNADS Distribution”<br />
on page 179.<br />
For details on this topic, see “Distribution Methods” on page 164.<br />
61
Chapter 2: Understanding <strong>Implementer</strong><br />
62
C HAPTER THREE<br />
<strong>Implementer</strong> <strong>Administration</strong><br />
Configuring <strong>Implementer</strong> on the Host System<br />
3<br />
This chapter describes the administrative tasks you must complete to configure<br />
<strong>Implementer</strong> on the host system. Use this chapter, along with the previous chapter that<br />
describes the various scenarios, to help organize and perform the setup requirements.<br />
This chapter covers the following topics:<br />
“Overview of Administrative Tasks” on page 64<br />
“System Control Maintenance” on page 65<br />
“Users” on page 72<br />
“Environments” on page 81<br />
“Environments and User Capabilities” on page 109<br />
“Environment Repository Build” on page 117<br />
“Environment Groups” on page 125<br />
“Object Codes” on page 127<br />
“Object Name Rules” on page 137<br />
“Project-based Application Paths” on page 142<br />
“User-Defined PDM Options” on page 144<br />
“Issue or Design Request Stamping” on page 145<br />
“Object Version Stamping” on page 146<br />
“Considerations With OS/400 and <strong>Implementer</strong>” on page 153<br />
“Web-based Development for IFS Objects” on page 155<br />
“Mounted Drive Support for IFS Objects” on page 159<br />
63
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
Overview of Administrative Tasks<br />
64<br />
The tasks in this chapter explain how to define the system wide control parameters within<br />
<strong>Implementer</strong>. The tasks also explain how to create and maintain the different types of users,<br />
environments, and object codes.<br />
If you distribute software to remote systems using the <strong>Implementer</strong> Receiver, you must also<br />
complete the setup tasks described in “Remote Distribution Concepts and Setup” on<br />
page 161.<br />
The user who performs these tasks must have authority to the Setup options in Work with<br />
Users (see page 74). Initially, the iSeries user profile QSECOFR and the <strong>Implementer</strong> user<br />
profile MWIPROD have these rights. <strong>MKS</strong> recommends you designate a different user profile<br />
with these authorities to use for ongoing administrative tasks.<br />
Perform the administrative tasks in the following order:<br />
1 System control maintenance: Set up your company name, default job queue, and many<br />
other system-wide defaults. Task information begins on page 65.<br />
2 Create user profile: Define the characteristics and authorities of each <strong>Implementer</strong> user.<br />
Task information begins on page 72.<br />
3 Create environment: Define the characteristics of the different types of environments for<br />
your applications, related environments, and establish application paths for production<br />
environments. Task information begins on page 81.<br />
4 Work with user capabilities: Define the authorities each user has to environments. Task<br />
information begins on page 109.<br />
5 Work with object codes: Define each type of object used for promotion. Task information<br />
begins on page 127.<br />
6 Reset authorities: Change the OS/400 owners and authorities of objects in the<br />
environment libraries. Task information begins on page 372.<br />
7 Build list: Load members/objects into the <strong>Implementer</strong> environment repository. Task<br />
information begins on page 117.<br />
8 Create environment groups: Define environment groups for promotion or distribution<br />
purposes. Task information begins on page 125.<br />
9 Set up user-defined PDM: Enable PDM to perform <strong>Implementer</strong> check out for traditional<br />
environments. Task information begins on page 144.<br />
10 Issue management: Set up the integration with <strong>MKS</strong> Integrity, if applicable. Task<br />
information is described in “<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration” beginning on<br />
page 63.<br />
When you have completed the administrative tasks, you can start using <strong>Implementer</strong> to<br />
control your application development.
System Control Maintenance<br />
System Control Maintenance<br />
This task allows you to set up and maintain the system-wide parameters used throughout<br />
<strong>Implementer</strong>. System Control Maintenance also controls the activation of many optional<br />
features in <strong>Implementer</strong>.<br />
Most users change the company name, job queue, CASE tool installation (if applicable), and<br />
any other values as needed. You can define the system parameters at the time of initial setup,<br />
once you have completed installation, or when you need to change the configuration.<br />
<strong>Implementer</strong> also provides many data areas that allow you to further customize your<br />
implementation. For details, see “<strong>Implementer</strong> Data Areas” on page 402.<br />
Your user profile must have authority to this function.<br />
To perform System Control Maintenance<br />
1 From the <strong>Implementer</strong> Menu, type 45, or type STRIM (*SYSCTLMNT) at the command<br />
line and press ENTER to display the first of four System Control Maintenance panels.<br />
The actions you can perform on this panel are:<br />
F3=Exit returns to the previous panel without updating changes.<br />
F10=*ALL Special commands allows you to work with global special commands.<br />
For details, see “Special Command Processing” on page 103.<br />
F18=Name Rules allows you to work with global object naming rules. For details,<br />
see “Object Name Rules” on page 137.<br />
2 Complete the required fields as defined in the following tables beginning. Press<br />
PAGE DOWN to display the additional panels.<br />
65
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
66<br />
3 When you have finished entering the information, press ENTER to update the<br />
information and return to the <strong>Implementer</strong> Menu.<br />
System Control Maintenance Field Descriptions: Panel 1<br />
Field Description<br />
Company name Specify the name to display on the <strong>Implementer</strong> Menu and on <strong>Implementer</strong><br />
reports (usually the <strong>Implementer</strong> licensee name).<br />
Next request number Specify the next request number to issue. A request number is the unique,<br />
four-character alphanumeric identifier assigned by <strong>Implementer</strong> when you<br />
create a new promotion request.<br />
Beginning with number 0001, the number increments by one for each new<br />
promotion request. When 9999 is reached, the left most position changes<br />
to an alpha character and the other positions reset to 0 (zero). Reading<br />
from right to left, the cycle continues until each position goes through the<br />
range 0–9, and A–Z. When number ZZZZ is reached, the number scheme<br />
automatically resets to number 0001. The maximum number of available<br />
request numbers before resetting is 1,200,000.<br />
Delete compile<br />
listings<br />
Message queue<br />
delivery<br />
CAUTION You usually do not change this value. If you change it, you must<br />
specify a number that does not overwrite existing request numbers.<br />
Specify whether to delete compile listings after successful promotions.<br />
Compile listings are located in the output queue specified by the interactive<br />
job when a request is submitted to compile.<br />
Y: Cancels all successful compile listings and retains all unsuccessful<br />
compile listings. Eliminates the disk space requirements of retaining all<br />
compile listings. Successful compiles ensure source-to-object integrity;<br />
typically, you do not need to retain these job logs.<br />
N: Retains all successful and unsuccessful compile listings. Use with<br />
caution; can cause excessive spool files.<br />
Specify how to deliver messages to the user workstation.<br />
*BREAK: Displays messages immediately.<br />
*NOTIFY: Notifies the user of pending messages. Includes turning on a<br />
message light and sounding a buzzer (if available).<br />
*HOLD: Retains messages in the message queue for the user to display.<br />
*SAME: Uses the same message notification as the previous message.<br />
*DFT: Answers messages requiring a reply with the default message<br />
reply. Does not add messages to the message queue.
Job log message<br />
logging<br />
Number of job logs to<br />
retain<br />
Default job queue/<br />
Library<br />
System Control Maintenance<br />
Specify the data to record in the OS/400 job log for <strong>Implementer</strong><br />
processing.<br />
Level: Corresponds to the first value of the OS/400 job logging level.<br />
Valid options are 0–4.<br />
Severity: Severity level used during create request. Corresponds to the<br />
second value of the OS/400 job logging level. Valid options are 00–99.<br />
Text: Message text recorded in the job log. Corresponds to the third<br />
value of the OS/400 job logging level. Valid options are *MSG, *SECLVL,<br />
and *NOLIST.<br />
Specify the number of job logs to save before deleting. Determine a number<br />
that is large enough to keep job logs for a reasonable number of requests.<br />
For example, 50 job logs may not represent 50 promotion requests, as a job<br />
log generates for each target environment on the request. Thus, if you<br />
regularly promote to two environments at a time, specify 100 job logs to<br />
retain 50 requests.<br />
Specify the default job queue and library for <strong>Implementer</strong>-submitted jobs.<br />
You can change the job queue at job execution for most jobs.<br />
Initialize tape Specify Y to automatically initialize a tape before saving objects for<br />
distribution on tape media to remote systems. The default value N does not<br />
initialize tapes.<br />
Default tape device Specify the name of the tape device used to save objects on tape media for<br />
distribution to remote systems.<br />
Default volume<br />
identifier<br />
System Control Maintenance Field Descriptions: Panel 1<br />
Field Description<br />
Specify the volume identifier to use for tape initialization. Required only to<br />
distribute to remote systems on tape media when the Initialize tape field is<br />
set to Y.<br />
Volume: Specify a a six-character value for the volume ID.<br />
*NONE: Initializes the tape without a volume ID.<br />
67
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
68<br />
System Control Maintenance Field Descriptions: Panel 2<br />
Field Description<br />
Submission method for<br />
non promotion<br />
functions<br />
Lib authority to include<br />
on env<br />
Specify which utility controls the submission of non promotion type jobs<br />
such as the Build List, Reset Authorities, and Purge History functions.<br />
1=OS/400: OS/400 operating system controls job submission. This is<br />
the default value.<br />
2=ROBOT: ROBOT controls job submission.<br />
Specify a user’s ability to include libraries in an environment definition,<br />
based on the user’s OS/400 authority to the library.<br />
*ALL: Only users with *ALL authority to a library can include the library<br />
in an environment definition.<br />
*CHANGE: Only users with *CHANGE authority to a library can include<br />
the library in an environment definition.<br />
*USE: Only users with *USE authority to a library can include the<br />
library in an environment definition.<br />
*BLANK: Authority to the library is not verified.<br />
AllFusion 2E installed Specify Y if AllFusion 2E is installed to manage 2E through <strong>Implementer</strong>.<br />
Required to create special environments for AllFusion 2E, and to display<br />
related fields and function keys for AllFusion 2E. The default value is N.<br />
AS/SET installed Specify Y if AS/SET is installed to manage AS/SET through <strong>Implementer</strong>.<br />
Required to create special environments for AS/SET, and to display<br />
related fields and function keys for AS/SET. The default value is N.<br />
LANSA installed Specify Y if LANSA is installed to manage LANSA through <strong>Implementer</strong>.<br />
Required to create special environments for LANSA, and to display<br />
related fields and function keys for LANSA. The default value is N.<br />
PeopleSoft World<br />
installed<br />
Secondary message<br />
queue<br />
Allow IFS object code<br />
creation from Check<br />
Out and Create Rqs<br />
Specify Y if PeopleSoft World is installed to manage PeopleSoft World<br />
applications through <strong>Implementer</strong>. Required to create special<br />
environments for PeopleSoft World, and to display related fields and<br />
function keys for PeopleSoft World. The default value is N.<br />
If using a third party messaging product such as AOS Message Manager,<br />
specify an additional message queue to send <strong>Implementer</strong> messages.<br />
Applies to messages regarding the status of promotion steps: start, end,<br />
and abnormal end of compile, distribution, move, and final processing.<br />
Specify Y to allow the automatic creation of an IFS object code when<br />
checking out or creating a promotion request using an IFS object code<br />
that does not exist. This is useful due to the abundant number of possible<br />
extensions of IFS files. Valid for IFS objects only (create traditional object<br />
codes through Work with Object Codes).<br />
IFS object codes are created based on the extension of the object being<br />
checked out or promoted. Applies to any IFS file or directory object code<br />
that does not already exist.
Display Comments<br />
panel when performing<br />
Create Request<br />
Perform create request<br />
in batch<br />
System Control Maintenance<br />
Specify whether to display the Comments panel when creating a<br />
promotion request and enforce the entry of a descriptive comment.<br />
Y: Enables the Comments panel and requires entry of a comment. This<br />
is the default value.<br />
N: Disables the Comments panel.<br />
This feature is mutually exclusive of promoting objects associated with an<br />
issue or design request, whereby the comments associated with the<br />
primary issue or DR are added to the promotion request.<br />
Specify whether to create promotion requests interactively or in batch.<br />
Causes less interactive edit processing and expedites the create request<br />
process by placing most edit checks, validation, and processing in the<br />
submitted job. Useful when promoting multiple items on a request or<br />
when issuing multiple requests.<br />
Y: Request processing occurs in batch. This is the default value.<br />
N: Request processing occurs interactively.<br />
Optimize PFs promotion Specify whether to optimize the promotion of physical files. For details on<br />
this feature, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Y: Optimizes physical file promotions to reduce processing time.<br />
N: Does not optimize physical file promotions (uses traditional file<br />
promotion).<br />
Maintain X-env related<br />
objects<br />
Specify whether to maintain related objects across environments and<br />
allow <strong>Implementer</strong> to automatically generate secondary requests for each<br />
environment related objects are found in.<br />
Y: Enables cross-environment related object processing and<br />
secondary requests for cross-environment related objects.<br />
N: Disables cross-environment related object processing and<br />
automatic secondary requests. This is the default value.<br />
After you change this value from N to Y and press ENTER to update your<br />
selection, a message instructs you to run the Build List function. Type Y to<br />
activate the feature, or N to return without activating the feature. For<br />
details, see “Maintain X-env related objects” on page 69.<br />
NOTE For details on related object processing based on the development path for<br />
QA environments, see “Add related objects from path” on page 72.<br />
Continue rqs if X-env<br />
error<br />
System Control Maintenance Field Descriptions: Panel 2<br />
Field Description<br />
When maintaining cross-environment related objects, specify how<br />
<strong>Implementer</strong> handles a primary request if an error occurs while<br />
generating secondary requests for cross-environment related objects.<br />
Requires the Maintain X-env related objects field set to Y.<br />
Y: Primary request continues processing if errors occur while<br />
generating secondary requests.<br />
N: Primary request ends in failure if an error occurs while generating<br />
secondary requests.<br />
69
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
70<br />
System Control Maintenance Field Descriptions: Panel 3<br />
Field Description<br />
Activate issue object<br />
stamping<br />
Specify whether <strong>Implementer</strong> automatically stamps each object with the<br />
issue or DR number the object is checked out with. To ensure stamping<br />
of both new and existing objects, stamping occurs in the three stages<br />
that allow object creation: check out, compile from the Workbench, and<br />
promotion. For details, see page 145.<br />
Y: Enables object stamping. When multiple locks exist with multiple<br />
issues or DRs, the object is stamped with the primary number<br />
associated with the initial lock.<br />
N: Disables object stamping. This is the default value.<br />
NOTE When <strong>MKS</strong> Integrity is the issue management system, this field name is<br />
Activate issue object stamping. When DesignTracker is the issue management<br />
system, the field name is Activate DR object stamping.<br />
Activate object version<br />
stamping<br />
Assign native version<br />
number at<br />
Specify if <strong>Implementer</strong> automatically stamps each object, lock, and<br />
repository record with a unique version number at defined stages within<br />
the development cycle. For details, see page 146.<br />
Y: Enables object version stamping. You must define the remaining<br />
fields on this panel as described. This is the required value for the<br />
Build List function to assign revision numbers to unstamped objects.<br />
For details, see “Environment Repository Build” on page 117.<br />
N: Disables object version stamping. This is the default value.<br />
If the Activate object version stamping field is set to Y (active), specify<br />
the versioning method.<br />
1=checkout only:<br />
Assigns the version number during check out. Implements a wholenumber<br />
versioning scheme (no decimal). For example, checking out<br />
version 2 of an object in production to a *TST environment increments<br />
the version number to 3. Each new concurrent development lock<br />
increments the version by 1 (for example, 4, 5, 6). When promoted<br />
back to production, the version is set to that of the last *QAC object<br />
version.<br />
2=checkout and promotion to *PRD environments:<br />
Assigns the version number in check out and promotion to *PRD<br />
environments. Implements a decimal number versioning scheme<br />
using both the left and right side of the decimal. For example, checking<br />
out version 2.0 of an object in production to a *TST environment<br />
increments the version number to 2.1. Each new concurrent<br />
development lock increments the right side of the decimal by 1 (for<br />
example, 2.2, 2.3, 2.4). When promoted back to production, the<br />
version is set to 3.0 (the left side of the decimal is updated only when<br />
promoted to production).<br />
3=user defined:<br />
Assigns the version number based on a custom, user-defined<br />
versioning method. Requires a Versioning program name and Library<br />
name as described next.
System Control Maintenance<br />
NOTE If <strong>MKS</strong> Source integration is enabled, the native revision number scheme<br />
applies only to objects and items not archived in <strong>MKS</strong> Source. If <strong>MKS</strong> Source<br />
integration is not enabled, the native revision number scheme applies to all items.<br />
Versioning program Specify the name of a custom versioning program to call to perform<br />
object version stamping. Required if versioning is active and the Assign<br />
native version number at field is set to 3=user defined.<br />
IMPORTANT If the custom program references objects, for example, files or data<br />
areas, the library list for the <strong>Implementer</strong> job description MWIJOBD and each<br />
user’s interactive library list must include the library containing those objects.<br />
Library Specify the library location of the custom versioning program. Required if<br />
versioning is active and the Assign native version number at field value<br />
is 3=user defined. Valid options are a specific library name, *LIBL, or<br />
*CURLIB.<br />
Concurrent<br />
Development Scope<br />
System Control Maintenance Field Descriptions: Panel 3<br />
Field Description<br />
Specify which locks establish concurrent development—either all locks<br />
from all production environments, or only those locks from the same<br />
production environment as the current check out From environment.<br />
1=All Production Env:<br />
Concurrent development is based on locks from all production<br />
environments. Activates concurrent development for the current check<br />
out, if, among all existing locks, a lock exists for the same member/<br />
object and object code.<br />
2=Per Production Env:<br />
Concurrent development is based only on locks from the same<br />
production environment as the check out From environment. Activates<br />
concurrent development for the current check out if a lock exists for the<br />
same member/object and object code and the same production<br />
environment as the current check out From environment. This is the<br />
default value.<br />
To define a user’s environment capabilities for concurrent development,<br />
see “Locks” on page 110. To further customize concurrent development<br />
processing, see “Customizing <strong>Implementer</strong>” on page 414.<br />
71
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
Users<br />
72<br />
Add related objects<br />
from path<br />
System Control Maintenance Field Descriptions: Panel 3<br />
Field Description<br />
For requests that target a *QAC environment, specify whether to<br />
automatically add related objects that exist in environments higher on the<br />
promotion path. Allows you to recompile related objects that exist in<br />
production without creating locks for the objects.<br />
Y: Searches the current promotion path to locate related objects not in<br />
the target *QAC environment or on the current promotion request.<br />
Related objects are added to the request and recompiled in the QA<br />
environment (locks are not created for these objects). Requires the<br />
production environment’s Add related objects to rqs field set to Y. For<br />
details, see page 86.<br />
N: Does not search forward on the path to locate related objects. This<br />
is the default value.<br />
Domino server URL For Lotus Domino integration and database signing, specify the Lotus<br />
Domino server URL that <strong>Implementer</strong> uses when invoking actions that<br />
can only be performed within Domino. Must be a valid URL notation that<br />
includes subdirectories required to find the <strong>Implementer</strong> utility database,<br />
for example, http://servername.domain:port/subdir.<br />
For details on setting up Domino, see “Lotus Domino Integration” on<br />
page 336.<br />
Default SMTP Server For notifying users of promotion request status through e-mail sent as<br />
request special command. Specify the default SMTP server used by the<br />
ISNDMAIL command. The value must be an IP address or host name,<br />
for example, 127.1.1.1 or localhost. Requires Java 1.3 or later<br />
installed on your iSeries.<br />
Requires the Send eMail Message (ISNDMAIL) command set up as an<br />
<strong>Implementer</strong> special command. For details, see the <strong>MKS</strong> <strong>Implementer</strong><br />
<strong>2006</strong> User <strong>Guide</strong>.<br />
This task allows you to enroll OS/400 user profiles into <strong>Implementer</strong>. You must enroll each<br />
user of <strong>Implementer</strong> before they can access and use the features. When enrolling a user, you<br />
also define the <strong>Implementer</strong> user authorities that control the features and functions the user<br />
is allowed to perform. For a table of suggested field values for the different roles each type of<br />
user performs, see “Typical Values for Different User Roles” on page 78.<br />
You can enroll users individually or under a group profile. Perform this task during the<br />
initial setup of <strong>Implementer</strong> or any time after installation when you need to add, change, or<br />
delete a user profile.<br />
NOTE Some user profile fields, as noted, apply to using <strong>Implementer</strong> with<br />
<strong>MKS</strong> Integrity for issue tracking. For details, see “User Profile Setup” on page 235.
To create or work with users<br />
1 From the <strong>Implementer</strong> Menu, type 41, or type STRIM (*WRKUSR) at the command line<br />
and press ENTER to display the Work with User Profiles panel.<br />
2 To change an existing profile, type option 2 and press ENTER.<br />
To create a new user profile, press F6=Create, or type 3 in the Opt field of an existing<br />
user and press ENTER to copy the user profile information into a new user profile.<br />
The Create User Profile panel displays. The following example illustrates the default<br />
field values when creating a new user profile.<br />
Users<br />
3 Complete the required fields as defined in the following tables of Create User Profile<br />
Field Descriptions. When you reach the end of a panel, press PAGE DOWN to display the<br />
additional panels.<br />
4 When finished, press ENTER to add or update the record. The initial Work with User<br />
Profiles panel displays.<br />
73
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
74<br />
Field Description<br />
Create User Profile Field Descriptions: Panel 1<br />
User Profile Specify the name and a description for the user profile. You can edit a<br />
name only when enrolling a new profile. You cannot rename existing user<br />
profiles.<br />
<strong>MKS</strong> Integrity User ID Specify the name this user logs on with to access the <strong>MKS</strong> Integrity<br />
Server. Field is valid only when <strong>MKS</strong> Integrity is used for issue tracking or<br />
<strong>MKS</strong> Source is used for source archiving. For details, see “User Profile<br />
Setup” on page 235, and “<strong>Implementer</strong> and <strong>MKS</strong> Source Integration” on<br />
page 259.<br />
*USRPRF: The <strong>MKS</strong> Integrity user ID defaults from the user’s iSeries<br />
user profile. This is the default value.<br />
Name: Specify the valid <strong>MKS</strong> Integrity user ID. The value *NONE is not<br />
authorized to access <strong>MKS</strong> Integrity.<br />
Programmer/env admin options<br />
The following fields, in conjunction with user capabilities by environment on page 109, define the<br />
user’s access to functions used on a daily and emergency basis.<br />
Check out Specify if this user has authority to use the Check Out option on the menu<br />
or command interface. Developers usually use the Check Out function.<br />
The default value is Y.<br />
Create request Specify if this user has authority to use the Create Request option on the<br />
menu or command interface. Developers usually use the Create Request<br />
function. The default value is Y.<br />
Compile requests Specify if this user has authority to use the Compile Requests option on<br />
the menu or command interface. Developers usually use the Compile<br />
Requests function. The default value is Y.<br />
Project maintenance Specify if this user has authority to use the Projects option on the menu.<br />
Project leaders usually use this function. The default value is N.<br />
Emergency check out Specify if this user has authority to use the Emergency Check Out<br />
function on the menu. The default value is N.<br />
Emergency create<br />
request<br />
Specify if this user has authority to use the Emergency Create Request<br />
function on the menu. The default value is N.<br />
Move requests Specify if this user has authority to use the Move Requests option on the<br />
menu or command interface. Project leaders usually use this function.<br />
The default value is N.<br />
Setup options<br />
The following fields define the user’s access to functions such as data maintenance and system and<br />
environment configuration defaults. The default value for each of these options is N (not allowed).<br />
User profile<br />
maintenance<br />
Specify if this user has authority to change user profile information in<br />
Work with Users.<br />
Host env maintenance Specify if this user has authority to change environment information in<br />
Work with Environments.
Field Description<br />
Network configuration Specify if this user has authority to use the Network Configuration menu<br />
option.<br />
Object code<br />
maintenance<br />
System control<br />
maintenance<br />
Remote env<br />
maintenance<br />
Specify if this user has authority to change object code information in<br />
Work with Object Codes.<br />
Specify if this user has authority to use the System Control menu option.<br />
Specify if this user has authority to change the system name on an<br />
existing environment.<br />
User controls<br />
The following fields define whether the user is authorized to override certain default values when<br />
promoting. The default value for each of these options is N (not allowed).<br />
Override standard paths Specify if this user has authority to change the standard path option on<br />
the menu or command interface. An application path (standard or<br />
emergency) automatically determines the from and target promotion<br />
locations based on the current location of an object. For a description of<br />
path setup, see page 102.<br />
Override emergency<br />
paths<br />
<strong>MKS</strong> Integrity<br />
emergency update<br />
Override<br />
remove from objs<br />
Override<br />
remove from src<br />
Create User Profile Field Descriptions: Panel 1<br />
Specify if this user has authority to change the emergency path option on<br />
the menu or command interface.<br />
Users<br />
Specify if this user has authority to activate and de-activate the<br />
<strong>MKS</strong> Integrity emergency update mode. This allows the user to change<br />
the value of the <strong>MKS</strong> Integrity Emergency Update Active field on the<br />
Change User defaults panel accessed from either Work with Users using<br />
option 20=User Defaults or the Workbench using F18=User Defaults.<br />
Y: User has authority to activate and de-activate emergency update<br />
mode.<br />
N: User does not have authority to emergency update mode.<br />
Specify if this user has authority to change the Remove obj in from lib/<br />
env field when creating a promotion request. a<br />
Specify if this user has authority to change the Remove src in from lib/<br />
env field when creating a promotion request. a<br />
a Pertains to deleting members/objects in a From library or environment after promotion (user profile<br />
defaults are defined on the second Work with User Profile panel). For details, see “Removing Source<br />
and Objects After Promotion” on page 92.<br />
75
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
76<br />
Field Description<br />
Create User Profile Field Descriptions: Panel 2<br />
Defaults for check out and create request<br />
The following fields define the check out and promotion defaults for the user. The Chg field allows you<br />
to define whether the user can override the default value in the corresponding function. For example,<br />
specify a default target environment for promotion and specify Y in the Chg field allows the user to<br />
change the target environment when creating a request.<br />
NOTE When using a standard or emergency path to identify the check out or<br />
promotion location, the path values have precedence. The path value *USRPRF<br />
defaults the development environment or library from the user profile. This<br />
provides user-specific development locations, allowing you to control the default<br />
promotion locations.<br />
Check out from env Specify the default environment this user checks out from (usually a<br />
production environment).<br />
Development library Specify the default development library this user checks out to and<br />
promotes from. The library must not be defined to an <strong>Implementer</strong><br />
environment. Development library and development environment are<br />
mutually exclusive (personal development libraries are used when<br />
environments are not). <strong>MKS</strong> suggests using environments in place of<br />
personal libraries.<br />
Development env Specify the default development environment this user checks out to and<br />
promotes from. The development library and development environment<br />
are mutually exclusive.<br />
Crt rqs target env Specify the default primary environment this user promotes to (usually<br />
production or QA environment.) Mutually exclusive of Crt rqs tgt env grp<br />
field.<br />
Crt rqs tgt env grp Specify the existing default target environment group when this user<br />
creates a promotion request. Mutually exclusive of Crt rqs target env field.<br />
Project reference Specify the name of the default project when checking out or creating a<br />
promotion request. For example, when a developer is assigned to a<br />
general project or a single project for a long period, the developer does<br />
not have to repeatedly specify the project value.<br />
If the project has a defined application path, that path is the default when<br />
this user performs check out and create request. For details, see “Projectbased<br />
Application Paths” on page 142.<br />
Remove obj in from<br />
library<br />
Specify whether to automatically delete or retain objects in the from library<br />
after successful promotion.<br />
Y: Deletes objects after promotion. This is the default value.<br />
N: Retains objects after promotion. Authority to override this default<br />
when creating a request is defined in the User Controls fields on the<br />
previous panel.
Field Description<br />
Remove src in from<br />
library<br />
Enable one step<br />
checkout<br />
Enable one step<br />
promotion<br />
Specify whether to automatically delete source in the from library after<br />
successful promotion.<br />
Y: Deletes source after promotion. This is the default value.<br />
N: Retains source after promotion. Authority to override this default<br />
when creating a request is defined in the User Controls fields on the<br />
previous panel.<br />
Users<br />
Specify the default check out method: one step or traditional. The one<br />
step method processes the check out transparent to the user. The<br />
traditional method requires more steps and processing of the Check Out<br />
panel. For details, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Y: Enables one step checkout. This is the default value.<br />
N: Enables traditional checkout.<br />
Specify the default promotion method: one step or traditional. The one<br />
step method performs promotion processing transparent to the user. The<br />
traditional method requires more steps and processing of the Create<br />
Request panel. For details, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Y: Enables one step promotion. This is the default value.<br />
N: Enables traditional promotion.<br />
Conflict msg queue Specify a message queue to receive a message notify when a check out<br />
causes a conflict with a lock for this user (when a member/object checked<br />
out by this user is concurrently checked out by another user). The<br />
developer is notified that concurrent development is in process—a conflict<br />
with their lock now exists and must be resolved before promoting the lock.<br />
Useful for a group profile to ensure all messages are observed.<br />
Specify *USRPRF to default the message queue from the users OS/400<br />
user profile, or specify the name of an existing message queue.<br />
Library Specify the library containing the user’s message queue.<br />
Issue Management<br />
System<br />
Create User Profile Field Descriptions: Panel 2<br />
Specify the current issue management system for this user. Only used<br />
when co-existing to allow certain users to use <strong>MKS</strong> Integrity while others<br />
use DesignTracker.<br />
1=Default: The user uses the default issue management system.<br />
2=DesignTracker: When the default issue management system is<br />
<strong>MKS</strong> Integrity, allows the user to temporarily use DesignTracker.<br />
For details, see “<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration” on page 196.<br />
77
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
Typical Values for Different User Roles<br />
78<br />
Field Description<br />
Create User Profile Field Descriptions: Panel 3<br />
Product / Customer Options<br />
Specify Y to authorize this user profile to maintain the following product and customer records used<br />
for release management and <strong>MKS</strong> Source archiving (if enabled). The default value is N. For details,<br />
see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release Management <strong>Guide</strong>.<br />
Maintain products Authority to maintain products.<br />
Maintain product versions Authority to maintain product versions.<br />
Maintain customers Authority to maintain customer records.<br />
The following table describes the most common users involved with <strong>Implementer</strong>, and the<br />
suggested options to define for each type of user. You can change these suggested values to<br />
meet your specific needs.<br />
Capability Option Administrator<br />
Programmer/env admin options<br />
Project<br />
Leader<br />
Developer QA<br />
Check out Y Y Y N<br />
Emergency check out Y Y N N<br />
Create request Y Y Y Y<br />
Emergency create request Y Y N N<br />
Compile requests Y Y Y N<br />
Move requests Y Y N N<br />
Project maintenance Y Y N N<br />
Setup options<br />
User profile maintenance Y N N N<br />
Object code maintenance Y N N N<br />
Host env maintenance Y N N N<br />
System control maintenance Y N N N<br />
Network configuration Y N N N<br />
Remote env maintenance Y N N N<br />
User controls<br />
Override standard paths Y Y N N
Capability Option Administrator<br />
Override emergency paths Y Y N N<br />
Override remove from obj Y Y N N<br />
Override remove from src Y Y N N<br />
Defaults for check out and create request<br />
Check out from env Y Y Y N<br />
Develop lib. (or Env. below) Y Y Y N<br />
Develop env. (or Library above) Y Y Y N<br />
Crt rqs target env (or Env Group below) Y Y Y Y<br />
Crt rqs target env grp (or Env above) Y Y Y Y<br />
Project reference Y Y Y Y<br />
Remove obj in from library Y Y Y Y<br />
Remove src in from library Y Y Y Y<br />
Enable one step checkout Y Y Y Y<br />
Enable one step promotion Y Y Y Y<br />
Products / Customer Options<br />
Common Questions<br />
How much authority should be given to developers?<br />
Developers should be able to check out, create a request, compile a request, and access the<br />
Workbench. Usually, you do not allow developers to move a request or perform setup<br />
functions.<br />
If users are restricted through <strong>Implementer</strong> to specific environments, is it possible for them to access<br />
libraries outside of the product?<br />
Yes. To restrict a user from a specific library outside of <strong>Implementer</strong>, use standard OS/400<br />
security by using the Edit Object Authority (EDTOBJAUT) command to specify the user’s<br />
authority to the library.<br />
Should a developer be allowed to change the default path?<br />
Project<br />
Leader<br />
Developer QA<br />
Maintain Products Y Y Y Y<br />
Maintain Product Versions Y Y Y Y<br />
Maintain Customers Y Y Y Y<br />
Users<br />
This depends on how strictly your company wants to control member/object location along a<br />
predefined path during development.<br />
79
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
User Profile Object Code Overrides<br />
80<br />
Users have access to all object codes defined to an environment, as well as rights to promote<br />
any type of object. This is an optional task that allows you to place restrictions on a user’s<br />
access rights. For example, you may want to restrict the PF object code, as, typically, only a<br />
Database Administrator (DBA) has authority to promote physical files. To limit the number<br />
of users who can act as a DBA, you can disallow a user’s access to the PF object code.<br />
To change object code overrides for a user<br />
1 From the Work with User Profiles panel, type 8=Object code overrides next to the user<br />
profile and press ENTER. The Change User Profile - Object Codes panel displays.<br />
2 In the Allow Code field, type N for each object code you do not want this user to access,<br />
and press ENTER. The Work with User Profiles panel displays.<br />
User Profile Environment Capabilities<br />
Environment capabilities allow you to tailor each user’s authorities to specific environments.<br />
For example, you can enable multiple users to have move capabilities for an environment, or<br />
enable select users to perform emergency functions for an environment.<br />
You typically perform this task when you initially install and configure <strong>Implementer</strong>, after<br />
setting up the environment (not when you set up the user profile). The task is mentioned here<br />
within the Work with Users topic because you need to complete it after you create an<br />
environment. You also perform this task for a new user for existing environments. The<br />
functionality and setup are the same in both Work with Users and Work with Environments.<br />
<strong>Implementer</strong> provides two options for defining user environment capabilities:<br />
The <strong>Implementer</strong> Menu options provide standard iSeries entry screens. For details on<br />
this option and the environment capabilities task, see “Environments and User<br />
Capabilities” on page 109.<br />
The Capability Wizard is a graphical user interface (GUI) tool designed to minimize the<br />
maintenance of user authorities in <strong>Implementer</strong>. Administrators or anyone responsible<br />
for working with user authorities in <strong>Implementer</strong> can benefit from using this time saving<br />
tool. You must add new users through the <strong>Implementer</strong> Menu option. Once added, you<br />
can maintain the profiles with the Capability Wizard. The major advantage to using the<br />
Capability Wizard over the Work with Users function is that it allows you to set<br />
capabilities for multiple users and environments concurrently. For details, see “User<br />
Capability Wizard” on page 385.
Environments<br />
Environments<br />
An environment identifies a collection of libraries, object owners, authorized users, and rules<br />
of the libraries that make up one or more applications controlled by <strong>Implementer</strong>.<br />
Environments are an important concept in <strong>Implementer</strong>, as they automate many common<br />
tasks and the organization of your system.<br />
<strong>Implementer</strong> supports the following three environment types:<br />
Production (*PRD)<br />
Quality Assurance (*QAC)<br />
Test (development) (*TST)<br />
The *PRD environment is under tight control in <strong>Implementer</strong>. It is the final production<br />
version. You cannot check out to a *PRD environment or to a library defined to a *PRD<br />
environment. *PRD environments usually use program and/or database libraries that are in<br />
the end user’s library list. The major difference between a *PRD and *QAC environment<br />
relates to the move; when the move to a *PRD environment is complete, member/object locks<br />
are released—this is not the case for a *QAC environment.<br />
A *QAC environment is also under tight control in <strong>Implementer</strong>. It is not the final production<br />
version. You cannot check out to a *QAC environment or to a library that is defined in a<br />
*QAC environment. Examples of *QAC environments are: libraries used for system testing<br />
by developers, libraries used by a separate quality assurance group, and libraries used for<br />
user acceptance testing.<br />
A *TST environment is considered a developer’s set of libraries. <strong>Implementer</strong> does not<br />
control these libraries as tightly as *PRD or *QAC. For example, you can check out to a *TST<br />
environment or to a library not defined to any environment, whereas you cannot check out to<br />
libraries that are defined in *PRD or *QAC environments. This is typically considered a<br />
development environment.<br />
<strong>MKS</strong> recommends you define production environments. However, to fully capitalize on<br />
<strong>Implementer</strong>’s robust features and benefits, you should define environments for all<br />
application libraries.<br />
Key Considerations<br />
At a minimum, define a production environment that is used to manage the related<br />
application libraries. For the basic setup of common environment scenarios, see<br />
“Environment Examples” on page 417.<br />
Define all environments for an application before using any environment for that<br />
application.<br />
Define an environment before adding it to an environment group.<br />
81
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
82<br />
Define an environment before defining related environments, paths, CASE applications,<br />
or scheduling.<br />
Define from and target environments for check out. <strong>Implementer</strong> also supports checking<br />
out from an environment to a library.<br />
Authorize the user profiles that may access the new environment. Change the user<br />
profile in Change User Capabilities, accessed through Work with Environments, Work<br />
with Users, or the Capability Wizard.<br />
When setting up to archive, set the number of archive versions to 99 for each applicable<br />
environment to ensure every change to an object is always available in an archive. This<br />
enables the retention of 99 changes for a single object in an environment, without having<br />
to save them to tape in between, and ensures an older archive in the archive library is not<br />
replaced with a new copy. Normally, however, archives on the system would not be<br />
allowed to grow that large, and, would be saved off more regularly to make the archive<br />
disk space available.<br />
If using the <strong>MKS</strong> Source integration, conventions apply to environment names you use.<br />
The environment name must be representable on the file system of the operating system<br />
hosting the server for <strong>MKS</strong> Source. The environment name must start with a letter A–Z<br />
and continue with a contiguous sequence of letters A–Z, numbers 0–9, or underscores<br />
‘_’.<br />
In System Control Maintenance, review the library authority parameter for a user’s<br />
ability to include libraries in environment definitions. For more information, see the<br />
table of field descriptions on page 68.<br />
To create or change an environment<br />
1 From the <strong>Implementer</strong> Menu, type option 42, or type STRIM (*WRKENV) at the<br />
command line and press ENTER to display the Work with Environments panel.<br />
2 From the Work with Environments panel, do one of the following:<br />
Press F6=Add to create a new environment on the Create Environment panel.<br />
Type 2 in the Option field next to an existing environment and press ENTER to<br />
display the Change Environment panel.<br />
Type 3 in the Option field of an existing environment and press ENTER to create a<br />
new environment by copying the selected environment.
Environments<br />
3 Complete the fields as described in the following tables of Create Environment Field<br />
Descriptions. Press PAGE DOWN to access the additional panels.<br />
4 When finished, press ENTER to add or update the environment.<br />
Field Description<br />
Create Environment Field Descriptions: Panel 1<br />
Environment Specify the name of the environment. You can enter a name only when<br />
creating a new environment. You cannot change the name of an existing<br />
environment.<br />
Description Type a brief description for the environment.<br />
Administrator Specify a user profile that has authority to Move Requests for this<br />
environment. To the right of this field is the description of the administrator.<br />
Env type Specify whether the environment is Production (*PRD), Quality Assurance<br />
(*QAC), or Test (*TST) environment.<br />
*PRD: You can check out from and promote to a *PRD environment. You<br />
cannot check out to a *PRD environment or to a library defined to a<br />
*PRD environment, or promote from a *PRD environment.<br />
*QAC: You can promote to and from a *QAC environment. You cannot<br />
check out to a *QAC environment or to a library defined to a *QAC<br />
environment.<br />
*TST: You can check out to a *TST environment or to a library not<br />
defined to any environment. You can promote from a *TST environment.<br />
You cannot check out to libraries that are defined in *PRD or *QAC<br />
environments, or promote to *TST environments. A *TST environment is<br />
considered a developer’s set of libraries.<br />
83
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
84<br />
Field Description<br />
Library Defaults<br />
The following fields define the default values <strong>Implementer</strong> uses when you create a promotion request<br />
and specify this environment as the primary target environment.<br />
Name Specify the name of the corresponding library on the system.<br />
Library owner Specify the user profile who owns the corresponding library. This field must<br />
be blank if the Library field is *NONE. The Reset Authorities function uses<br />
this value to change the library owner. If environment libraries do not exist<br />
when targeted in promotion, <strong>Implementer</strong> creates the libraries and assigns<br />
this value as the library owner.<br />
Obj owner Specify the user profile who owns the objects in the corresponding library.<br />
The field must be blank if the Library field is *NONE. The Reset Authorities<br />
function uses this value to assign the object owner. If source files do not<br />
exist in promotion, <strong>Implementer</strong> creates the source files and assigns this<br />
value as the object owner. If an object being moved has *GRANT authority,<br />
<strong>Implementer</strong> uses this value when moving objects into the environment.<br />
Typically, the default value is *KEEP.<br />
Archive Versions/<br />
Archive Category<br />
Create Environment Field Descriptions: Panel 1<br />
The field name is Archive Versions for all environments, except for release<br />
management environments the field name is Archive Category.<br />
Archive Versions is the number of archive versions to save for this type of<br />
object or member. Supports up to 99 archive versions of each. You can<br />
archive for the program library, files library, and source library.<br />
To archive PeopleSoft World soft coding items, specify a value in this field<br />
and complete the Source library fields. To archive AS/SET definitions to an<br />
AS/SET archive application set, specify the number of levels in the Archive<br />
versions field for the source library.<br />
Archive Category allows any of the following values:<br />
0=None: Does not archive.<br />
1=Standard Only: Archives the standard release category only.<br />
2=PTF: Archives the PTF release category only.<br />
3=Standard and PTF: Archives both standard and PTF releases.<br />
Program library Specify the library that contains the programs and device files, such as<br />
display and printer files. Often referred to as the program or object library.<br />
If the environment contains only database objects, specify *NONE.<br />
Files library Specify the library that contains the physical and logical files. If the<br />
environment does not contain database objects, specify *NONE.<br />
Source library Specify the library that contains the source members for the objects in the<br />
two preceding environment libraries.<br />
To archive PeopleSoft World soft coding items, define values in the Source<br />
library fields and the Archive Versions field.
Field Description<br />
Environments<br />
Archive library Specify the library to contain the archived versions of source/objects. Only<br />
required when archiving objects. You must specify a library name to add<br />
the number of versions in the Archive versions field.<br />
AS/SET definitions and generated traditional objects are managed<br />
independently and require separate archive locations for traditional objects<br />
and definitions.<br />
The value *CALC applies to primary release management environments.<br />
For details, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release Management <strong>Guide</strong>.<br />
Create Request defaults<br />
The following fields define the default values when creating a promotion request for this environment.<br />
The Chg field defines whether the user can override the default value when creating a request.<br />
Compile required Specify whether to compile all source-based objects using the Compile<br />
Requests function before moving the objects into this environment. Ensure<br />
the objects compile with the correct library list.<br />
Y: Objects compile before the move.<br />
N: Bypasses the Compile Request function. After creating a request,<br />
you can move the objects into this environment using the Move<br />
Requests function. Use this option for AS/SET definitions and LANSA<br />
objects.<br />
Auto submit in<br />
create rqs<br />
Create Environment Field Descriptions: Panel 1<br />
Specify whether to automatically submit the promotion when creating a<br />
request.<br />
Y: Promotions automatically submit.<br />
N: Promotions are held. To promote the request use: Compile Request,<br />
Move Request, or Move Requests by System/Environment.<br />
Through step Specify how many steps of the promotion to perform when auto-submitted<br />
from Create Request. Each subsequent step includes the prior step, for<br />
example, compile includes model copy, distribute includes model copy and<br />
compile, and move includes model copy, compile, and distribute. If using<br />
promotion scheduling, it is performed for the last step specified as the<br />
submit through step.<br />
1=Export: Valid only for LANSA environments. Exports LANSA objects<br />
on the request to a save file. Verify successful completion of the process<br />
by manually reviewing the export reports generated by LANSA.<br />
2=Compile: Valid only when Compile required = Y.<br />
3=Distribute: Valid only for remote environments.<br />
4=Move: No special edits.<br />
85
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
86<br />
Field Description<br />
Add related objects<br />
to rqs<br />
Field Description<br />
Specify whether to add related objects to a request before promotion.<br />
Ensures objects are promoted without level checks in production. For<br />
example, when promoting a physical file or display file, all programs that<br />
reference the PF or any related LFs are added to the request before the<br />
compile step with an action of 9 for Recompile. <strong>Implementer</strong> uses the<br />
source in this environment to recompile the program against the changed<br />
physical file, thus avoiding the possibility of a level check.<br />
When a request targets multiple environments, the derived related objects<br />
are based on the primary environment. If this environment is a secondary<br />
environment for a request, the related objects are added based on the<br />
value of this field in the primary environment, not this environment.<br />
Y: Adds all related objects to the request. This is required to add related<br />
objects from the development path without locking the objects. For<br />
details, see page 72.<br />
N: Bypasses related object processing. For physical files, <strong>Implementer</strong><br />
adds the logicals to the request even when N is specified.<br />
Create Environment Field Descriptions: Panel 2<br />
Create Request options<br />
The following fields define additional defaults for the environment.<br />
Check out required Specify if users must check out a member/object in this environment before<br />
it can be placed on a promotion request.<br />
Y: Check out is required.<br />
N: Check out is not required.<br />
Allow authority<br />
overrides<br />
Create Environment Field Descriptions: Panel 1<br />
Specify if users can change the authority method of this environment when<br />
creating a promotion request.<br />
Y: Authority method can be changed.<br />
N: Authority method cannot be changed. All moves into the environment<br />
use the default authority method defined for the object code.
Field Description<br />
Environment information<br />
Specify the following default information for the environment.<br />
Environments<br />
Special environment Displays the special environment type for the environment. Pertains to the<br />
installed CASE tools specified in System Control. The value updates<br />
based on the third party product details in Work with Environments options<br />
10=AllFusion 2E, 11=AS/SET, 12=LANSA, or 16=PeopleSoft World.<br />
Standard: Not a special environment. This is the default value.<br />
ALLFusion: AllFusion 2E special environment.<br />
AS/SET: AS/SET special environment.<br />
LANSA: LANSA special environment.<br />
PeopleSoft: PeopleSoft World special environment.<br />
You can change a special environment to different special environment<br />
type by first removing the special environment details to establish it as a<br />
standard environment. For details, see “Third Party Integration<br />
Prerequisites” on page 107, and “Third Party Integrations” on page 303.<br />
Issue or Design rqs<br />
rqd in check out<br />
Project reference<br />
required<br />
Retain error-free<br />
joblogs<br />
Remove obj in from<br />
lib/env<br />
and<br />
Remove src in from<br />
lib/env<br />
Create Environment Field Descriptions: Panel 2<br />
Specify if an issue (<strong>MKS</strong> Integrity installed) or a design request<br />
(DesignTracker installed) is required to check out an item from this<br />
environment. Applies only to traditional *PRD environments and<br />
AllFusion 2E *TST environments.<br />
Y: Issue (or DR) is required.<br />
N: Issue (or DR) is not required. This is the default value.<br />
Specify if a project reference is required to check out a member/object from<br />
this environment.<br />
Y: Project reference is required.<br />
N: Project reference is not required. This is the default value. It is the<br />
required value for *TST environments.<br />
Specify whether to retain the job log in the <strong>Implementer</strong> database for any<br />
job processed for this environment.<br />
Y: Retains job logs.<br />
N: Deletes job logs when the related job completes normally. Retains<br />
the job log if a job terminates abnormally to assist with resolution<br />
Specify whether to delete objects and source from the environment<br />
libraries after successful promotion from this environment (must be a local<br />
*TST or *QAC environment). The value defined here is the default value for<br />
the corresponding fields in Create Request. For details, see “Removing<br />
Source and Objects After Promotion” on page 92.<br />
1=always: Automatically deletes objects and/or source. This is the<br />
default value.<br />
2=never: Retains objects and/or source.<br />
3=per obj code: Validates each object code to the environment’s object<br />
code overrides.<br />
87
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
88<br />
Field Description<br />
Maintain related<br />
object info<br />
Specify whether to maintain related object information for the environment.<br />
Y: Maintains related object information. Required value to check out<br />
related objects and add related objects to a request.<br />
N: Bypasses related object information.<br />
Source of information Specify which product maintains related object information for the<br />
environment.<br />
1=<strong>Implementer</strong>: <strong>Implementer</strong> uses the Display Program Reference<br />
(DSPPGMREF) command to generate and maintain related object<br />
information. Initially, the related information for an environment is<br />
processed by the Build List function; thereafter, it automatically updates<br />
during the move step. Displays related objects for file (*FILE) and data<br />
area (*DTAARA) object types. When activating this feature for the first<br />
time, you must run the Build List for the environment to establish the<br />
initial related object information (or use PathFinder).<br />
2=Pathfinder: PathFinder generated information is used. Automatically<br />
updates PathFinder as objects move in and out of libraries documented<br />
by PathFinder. Displays related objects for any object type. Define the<br />
remaining fields for PathFinder to maintain related object information.<br />
Pathfinder X-ref library Specify the PathFinder x-ref library to store related object information if<br />
related objects are maintained by PathFinder.<br />
Name: Specify the PathFinder x-reference library. You must run the build<br />
within PathFinder for the library before defining it here.<br />
*DEFAULTS: Uses the object x-ref files for the library specified in the<br />
PathFinder Object X-ref library field in the PathFinder user defaults.<br />
Update Pathfinder X-ref Specify whether <strong>Implementer</strong> automatically updates PathFinder<br />
information during request promotion.<br />
Y: Automatically updates PathFinder. Specify a value in the DOCLIBL for<br />
X-ref updates field.<br />
N: Bypasses PathFinder updates.<br />
DOCLIBL for X-ref<br />
updates<br />
Create Environment Field Descriptions: Panel 2<br />
Specify the documentation library list defined in PathFinder that contains<br />
the names of the libraries with object cross references.<br />
Name: Specify the name of an alternate documentation library list.<br />
*DEFAULTS: Uses the DOCLIBL specified in user defaults for one of the<br />
following: alternate name, *USER, *STANDARD, or *ALL parameters.<br />
*USER: Uses the DOCLIBL defined in the user profile.<br />
*STANDARD: Uses the DOCLIBL for the standard values.
Field Description<br />
<strong>MKS</strong> Integrity issue state<br />
Create Environment Field Descriptions: Panel 3<br />
Environments<br />
The following fields are valid for entry when you use <strong>MKS</strong> Integrity for issue tracking. For details, see<br />
“<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration” on page 196.<br />
When arrives in<br />
this env<br />
When rejected from<br />
this env<br />
Specify the <strong>MKS</strong> Integrity state to assign to a member/object checked out<br />
or promoted to this environment.<br />
NAME: Specify the name of a valid <strong>MKS</strong> Integrity status. This value<br />
overrides the global value if defined.<br />
*DEFAULT: Assigns the default value as defined in <strong>MKS</strong> Integrity setup.<br />
If the <strong>MKS</strong> Integrity default is blank or not set, no updates occur. This is<br />
the default value for this field. The status is set as follows:<br />
If checking out to this environment, assigns the default status *TST.<br />
If promoting to this environment and it is type *PRD, assigns the default<br />
status *PRD.<br />
If promoting to this environment and it is the first *QAC on the path,<br />
assigns the default status *QAC1.<br />
If promoting to this environment and it is the second *QAC on the path,<br />
assigns the default status *QAC2. Cycle continues for each *QAC<br />
environment.<br />
*NONE: No updates occur.<br />
Specify the <strong>MKS</strong> Integrity state to assign to a member/object rejected from<br />
this environment.<br />
*NAME: Specify the name of a valid <strong>MKS</strong> Integrity status. This value<br />
overrides the global value if defined. Valid for *QAC environments only.<br />
*DEFAULT: Assigns the default value as defined in <strong>MKS</strong> Integrity setup.<br />
If the <strong>MKS</strong> Integrity default is blank or not set, no updates occur. This is<br />
the default value for this field for all environment types. The status is set<br />
as follows:<br />
If rejecting from this environment and it is the first *QAC environment on<br />
the path (the path used to promote from the current location), assigns<br />
the *QAC1 default status.<br />
If rejecting from this environment and it is the second *QAC environment<br />
on the path (the path used to promote from the current location) assigns<br />
the *QAC2 default status. Cycle continues for each *QAC environment.<br />
*NONE: No updates occur.<br />
Remote information<br />
The following options allow you to define and control the remote systems.<br />
System name Specify the name of the system where this environment is located. You<br />
must first define the system in Network Configuration. Specify a local<br />
system name for a local environment, or a remote system name for a<br />
remote environment.<br />
Source library location Specify the location of the environment’s source library.<br />
L: Source library is on the local system.<br />
R: Source library is on a remote system.<br />
89
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
90<br />
Field Description<br />
Compile location Specify where to compile for this environment.<br />
L: Compile on local system.<br />
R: Compile on remote system.<br />
Distribution method Specify the distribution method when deploying to the remote system.<br />
1=SNADS (SNA Distribution Services).<br />
2=Tape.<br />
3=DVD (release management environments only; for details, see the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release Management <strong>Guide</strong>).<br />
4=SDMCom.<br />
7=TCP/IP-FTP (default value when creating a new environment).<br />
8=TCP/IP-Tape.<br />
NOTE TCP/IP-FTP is for bulk file transfers. TCP/IP-Tape is for distribution on<br />
tape media. Both options allow you to use the “Remote Initiated Move Update<br />
Host” functionality. To alternate between TCP/IP and SNADS distributions,<br />
change the value in this field as needed.<br />
If you use SNA or TCP/IP to distribute to remote systems, additional setup is<br />
required. For details, see “Setting Up for SNADS Distribution” on page 179, or<br />
“Setting Up for TCP/IP Distribution” on page 173.<br />
Remote initiated move Specify whether to initiate the move step on the host system or the remote<br />
system. Allows users on a remote system to control when to move a<br />
request into this environment and allows initiating the move on the remote.<br />
Y: Initiates the move on the remote system by a remote user.<br />
N: Initiates the move on the host system by a host user.<br />
Updates host Specify whether to update the host with remote initiated move information<br />
that includes: request header status, request detail status and information,<br />
archive information, and job log. Sets the request status to complete after<br />
request distribution.<br />
Y: Updates the host with the remote move data. Requires the Remote<br />
initiated move field set to Y.<br />
N: Bypasses the host update.<br />
Retain requests on<br />
remote<br />
Create Environment Field Descriptions: Panel 3<br />
NOTE If you use <strong>MKS</strong> Source archiving and promote using remote initiated<br />
moves with host updates, the MWIPROD user profile must have an<br />
<strong>MKS</strong> Integrity user ID that is part of the group to ensure it is<br />
configured to work with <strong>MKS</strong> Source. For details, see “Creating the <strong>Implementer</strong><br />
Developer Group” on page 264.<br />
Specify whether to retain requests on the remote system after promotions<br />
complete successfully.<br />
Y: Retains requests on remote system.<br />
N: Deletes requests on remote system. This is the default value.
Field Description<br />
Promotion notification<br />
queue<br />
Object Code Overrides<br />
Create Environment Field Descriptions: Panel 3<br />
Environments<br />
Specify the name and library of the promotion notification queue for<br />
<strong>Implementer</strong> on the remote system. The queue holds messages that notify<br />
remote users of completed promotion steps. The value *NETA uses the<br />
queue defined in the network attributes.<br />
Target release Specify the OS/400 target release for the environment. The value<br />
*NETCONFIG retrieves the value from the network configuration.<br />
<strong>Implementer</strong> uses object codes to define the various types of members/objects you check out<br />
and promote. An object code combines information from the OS/400 object type and source<br />
type. Global object codes are defined in <strong>Implementer</strong> Menu option 44, Object Codes. This<br />
function allows you to override the global values and establish different values at the<br />
environment level.<br />
You can maintain object code overrides in Work with Environments using F8=Object codes,<br />
and in Work with Object Codes using option 7=Environment Overrides. Both panels look the<br />
same and provide the same functionality, with variation only in how the data is structured:<br />
In Work with Environments, view by environment to work with overrides at the global<br />
level. This option displays the object code defaults and overrides for a specific<br />
environment.<br />
In Work with Object Codes, view by object code to work with overrides at the<br />
environment level. This option displays the defaults and overrides for all environments<br />
for a specified object code. For details on this option, see “Environment Overrides” on<br />
page 133.<br />
Object code overrides applied to an environment affect the environment default values only.<br />
When creating a new environment, the values specified at the global level are the default<br />
values assigned to the object code overrides for the new environment.<br />
You can override the default source file for source-based objects, as well as the default object<br />
library and source library. Through overrides, you can activate or deactivate particular object<br />
codes for specific environments without impact to other environments. For example, you can<br />
deactivate certain object codes if you use database-only environments, and ensure that<br />
certain types of programming languages are not used for specific environments, such as<br />
System/38 or System/36 environment languages.<br />
You can apply overrides at any time. When you change an object code, it applies the latest<br />
overrides created from that point forward; it does not change existing active overrides.<br />
Inactive overrides reflect the object code level changes.<br />
91
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
92<br />
Removing Source and Objects After Promotion<br />
<strong>Implementer</strong> allows you to control how source and objects are handled in the From<br />
environment by allowing you to retain or automatically delete the items after successful<br />
promotion from a local *TST or *QAC environment.<br />
This feature is controlled by the defaults you establish for the environment and the<br />
environment’s object code overrides as defined in the fields Remove obj in from lib/env and<br />
Remove src in from lib/env as follows:<br />
Option 1=always automatically deletes objects and/or source.<br />
Option 2=never automatically retains objects and/or source.<br />
Option 3=per obj code validates to the environment’s object code overrides. An override<br />
is validated only if the promotion request is defined to delete objects per object code.<br />
When you create a promotion request, the Remove fields on the request default to the values<br />
defined for the same fields as the From environment. When promoting from a library, the<br />
Remove fields on the request are set to the default values defined for the user profile creating<br />
the request as follows:<br />
If the user profile Remove fields are set to Y, then the Remove fields on the request<br />
default to 1 (always).<br />
If the user profile Remove fields are set to N, then the Remove fields on the request<br />
default to 2 (never).<br />
The value 3 (per object code) is not allowed when promoting from a library.<br />
You must have authority to perform overrides to change the request defaults. For details on<br />
user profile defaults and overrides, see the table on page 78.<br />
NOTE<br />
The global object code values are only used to supply the initial defaults when<br />
creating new object code overrides for an environment.<br />
<strong>Implementer</strong> does not delete from *PRD or remote environments. For details on<br />
how to delete items from a remote QA environment after successful promotion<br />
from the environment. For details, see “Clearing Remote QA Environments” on<br />
page 384.<br />
To define object code overrides for an environment<br />
1 From the Change Environment panel or Create Environment panel, press F8=Object<br />
Codes. The Change Environment Object Code Overrides panel displays.<br />
2 Press F7=Fold to toggle the view to include the object code description.<br />
NOTE For details on option 7=Work with Object Name Rules, see “Object Name<br />
Rules” on page 137.
Environments<br />
3 The values that display for each code default from the corresponding global object code<br />
definition. Establish the overrides for this environment as follows:<br />
In the Object Library, Source File, and Source Library fields, type the new value in<br />
the appropriate field. The default value *NONE in any of these fields indicates the<br />
field does not allow entry and must first be changed at the global level.<br />
In the Act Flg field, type Y to activate the object code for the environment. The object<br />
code must be active to check out or promote using the object code. Type N to<br />
deactivate the object code.<br />
In the Rmv Obj and Rmv Src fields, specify whether to delete the corresponding<br />
object and/or source upon successful completion of a promotion request from this<br />
environment. Specify Y to delete the item. Specify N to retain the item.<br />
4 Press ENTER to process your changes. The Change Environment panel (or Create<br />
Environment panel) displays.<br />
To set up IFS directories for an environment<br />
1 From the Work with Environments panel, type option 20=Directory setup next to the<br />
environment and press ENTER. The Work with Environments Directory Setup panel<br />
displays.<br />
93
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
94<br />
2 Complete this panel as defined in following table and press ENTER.<br />
Field Description<br />
Directory Setup Field Descriptions<br />
Directory path Specify the full IFS directory path covered by the environment.<br />
<strong>Implementer</strong> automatically creates the directory path for a *QAC<br />
environment if it does not exist when a promotion targets the environment.<br />
You must manually create directory paths for *PRD and *TST<br />
environments.<br />
For IFS objects located on a system running Windows NT Server, the<br />
directory path of environments associated with the NT Server mounted<br />
drive must begin with \QNTC, for example,<br />
\QNTC\<strong>MKS</strong>\PRD\ACCOUNTS_PAYABLE.<br />
Directory path owner Specify the owner of the directory. Directories managed in this environment<br />
are owned by the user profile defined as the directory path owner.<br />
IFS file owner Specify the owner of IFS files managed within the environment directory.<br />
The user defined as the IFS file owner owns all objects created in the<br />
environment directory path, including all sub-folders.<br />
IFS objects promoted to a Windows NT Server are owned by user<br />
SDMAUTUSR (or the user profile defined to <strong>Implementer</strong> data area<br />
SDMAUTUSR). For details, see “Mounted Drive Support for IFS Objects”<br />
on page 159.<br />
IFS file archive<br />
versions<br />
Specify a value from 0–99 to indicate the number of archive versions to<br />
retain when promoting objects into production.<br />
Archive directory path Specify the full IFS path name for storing archive versions. <strong>Implementer</strong><br />
automatically creates the directory if it does not exist when a promotion<br />
request targets the directory for archiving.
Establishing Object Authorities<br />
Environments<br />
An environment has specific authorities that control access to the objects in the environment.<br />
The Change Environment - Object Authorities panel allows you to add and change the<br />
OS/400 user profiles or OS/400 authorization list that have authority to reference objects<br />
within the environment.<br />
Key Considerations for IFS Objects<br />
<strong>Implementer</strong> sets authorities to IFS files in an environment directory the same as it sets<br />
authorities on libraries and objects. You must set the authorities when defining the<br />
environment to enable this feature.<br />
When promoting IFS objects to a Windows NT Server, the objects are owned by user<br />
SDMAUTUSR (or the user profile defined to <strong>Implementer</strong> data area SDMAUTUSR).<br />
Unlike traditional objects, the Reset Authorities function does not set the object owner. In<br />
addition, IFS objects inherit the authorities of the target directory; authorities defined to<br />
the environment or existing on the from object are disregarded.<br />
NOTE The Resent Authorities function allows you to grant or revoke object<br />
authorities for an environment based on how the authorities are defined for the<br />
environment. For details, see “Resetting Authorities” on page 372.<br />
To establish object authorities for an environment<br />
1 From the Change Environment panel or Create Environment panel, press<br />
F11=Authorities to display the Change Environment Object Authorities panel.<br />
95
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
96<br />
2 Do one of the following:<br />
In the Authorization list field, type the name of an existing OS/400 authorization list.<br />
In the User field, type the name of an existing OS/400 user profile.<br />
3 In the Authority field, type the authority *CHANGE, *ALL, *USE, *EXCLUDE, or *AUTL.<br />
4 Press ENTER.<br />
Deleting an Environment<br />
Deleting an environment removes the environment from the <strong>Implementer</strong> database. It also<br />
removes the environment from the related environment list for other environments. It does<br />
not delete the system libraries or source files associated with the environment.<br />
Key Considerations<br />
You must have authority to maintain environments to delete an environment.<br />
If an environment has closed locks or an attached promotion request, you must use<br />
option 32=Purge history or F19=Purge All History before you can delete the<br />
environment. For details, see “Purging Environment History” on page 374.<br />
You cannot delete an environment that is part of a development path, project path,<br />
related environment, or a From environment for a product version.<br />
You cannot delete an environment that is a From environment or target environment for<br />
a release management package. You must first use Work with Packages to manually<br />
purge the packages. For details, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release Management <strong>Guide</strong>.<br />
To delete an environment<br />
1 From the <strong>Implementer</strong> Menu, type option 42, or type STRIM (*WRKENV) at the<br />
command line and press ENTER to display the Work with Environments panel.<br />
2 From the Work with Environments panel, select each environment with option 4=Delete<br />
and press ENTER. The Confirm Delete of Environments panel displays.<br />
3 Press ENTER to delete the selected environment.<br />
Environment Library List<br />
<strong>Implementer</strong> uses the environment library list to compile source members during promotion.<br />
It is also used during development from the Workbench and to issue special commands on a<br />
promotion request.<br />
IMPORTANT You cannot use special commands to change the environment library list.
Key Considerations<br />
Environments<br />
You can specify a list of up to 250 libraries for compilation in the environment. Of these,<br />
248 entries are available for your use. The last two are reserved for QTEMP and the<br />
<strong>Implementer</strong> work library on the promotion request.<br />
IMPORTANT An incorrectly defined library list can cause the compile step to fail, or<br />
worse yet, compile using the wrong objects, and thus, result in level checks. You<br />
must ensure the library list has the correct libraries needed for compilation. This is a<br />
common error during the initial use of a new environment.<br />
The task of copying an environment includes copying associated library lists.<br />
Define local environments with a local library list and libraries that exist on the local<br />
system. You cannot define a remote library list for a local environment.<br />
Define remote environments with a remote library list and libraries that exist on the<br />
remote system. When a required library exists on both systems, you must also define a<br />
local library list for the remote environment. This allows you to establish an<br />
environment library list for local compiles, set up for move related special commands on<br />
the remote system, and locate database files related to the promoted files when explicitly<br />
added to the request.<br />
When initially defining the library list for a remote environment, the entries in the<br />
remote library list are also added to the local library list. Pressing F7 to access the local<br />
library list automatically loads the remote library list entries. You can modify the local<br />
library list as needed.<br />
If a remote environment has both remote and local library lists defined and you later<br />
change the environment to a local environment, the remote library list is no longer<br />
accessible because the environment is now local. However, <strong>Implementer</strong> retains the<br />
remote library list record, avoiding the need to recreate the library list if you later change<br />
the environment back to a remote environment.<br />
If you use special compile procedures such as those required by some third party<br />
software packages, you must add any applicable libraries to the compile library list.<br />
NOTE Prior to compiling a source member, <strong>Implementer</strong> replaces the library list of<br />
the current job with the environment library list; thus, do not put the libraries in the<br />
<strong>Implementer</strong> job description MWIJOBD.<br />
To edit an environment library list<br />
1 From the Change Environment panel or Create Environment panel, press F13=Library<br />
List.<br />
For a local environment, the Edit Environment Library List - Local panel displays. For a<br />
remote environment, the Edit Environment Library List - Remote panel displays. These<br />
panels are like the OS/400 Edit Library List (EDTLIBL) command panel.<br />
97
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
98<br />
2 In the Sequence Number field, specify the number to order the library in relation to other<br />
libraries. For traditional (non AllFusion 2E) environments, use the sequence number to<br />
order the libraries in the sequence required for compilation when promoting to the<br />
environment.<br />
3 In the Library field, specify the required library name.<br />
4 Press ENTER. The Edit Environment Library List panel displays the current libraries in<br />
sequential increments of 10.<br />
On the Edit Environment Library List - Remote panel, you can press F7 to save the<br />
remote library list and display the Edit Environment Library List - Local panel. Press F7<br />
again to save any local library list changes and return to the Edit Environment Library<br />
List - Remote panel.<br />
If you press ENTER without making any changes to the library list, the previous library<br />
list is saved and the Edit Environment Library List panel displays.<br />
Promotion Job Scheduling<br />
This task allows you to set up automatic job scheduling for the promotion steps: compile,<br />
move, and distribution for traditional environments, model copy step for AllFusion 2E<br />
environments, and export for LANSA environments. Job scheduling gives you control over<br />
the management of production environments and optimizes the utilization of your OS/400<br />
resources.<br />
Job scheduling is typically used to process jobs during non business hours, for example,<br />
nights or weekends, or to run jobs in a specific job queue.
To change promotion scheduling defaults<br />
1 From the Work with Environments panel, select the environment with option<br />
13=Promotion Scheduling and press ENTER. The Change Environment Promotion<br />
Scheduling panel displays.<br />
Environments<br />
2 Specify the Request Submission Defaults for the following stages of promotion:<br />
Model copy fields (for AllFusion 2E environments), or Compile fields for traditional<br />
environments.<br />
It is not necessary to change the scheduling defaults from *CURRENT, *SYSCTL, and N<br />
for Hold on job queue. Override options are available for each promotion step, (for<br />
example, export if a LANSA environment, compile, move, and distribute) and archiving.<br />
If the to and from time settings cross over into the next day, for example, from Day 1 at<br />
8:00 p.m. to Day 2 at 4:00 a.m., it uses the *CURRENT default that the second time period<br />
falls on in the second day and schedules accordingly.<br />
3 Press PAGE DOWN to display the second Promotion Scheduling panel and specify the<br />
Request Submission Defaults for the distribute (or export if a LANSA environment) and<br />
move stages of the promotion.<br />
4 Press ENTER to process the update.<br />
99
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
Related Environments<br />
100<br />
This function allows you to define the relationship of an environment with other<br />
environments in the form of an ordered list. <strong>Implementer</strong> uses this list in check out to display<br />
the member/object lists and related objects in an environment. For this reason, related<br />
environment lists are only used by <strong>Implementer</strong> for production environments, although you<br />
can define them for development and test environments for reference purposes.<br />
The two common uses of related environments are when:<br />
developing one release of an application as changes to an earlier release (release 2.0<br />
based on release 1.0)<br />
modifications to production are in a separate environment from the base production<br />
In either scenario, the related environment list must include all the environments, in order,<br />
that are logically included in the environment being defined. You must also include the<br />
necessary libraries on the environment library list for proper compilation when you define<br />
the environment.<br />
An environment always has at least one environment on the related environment list, the<br />
environment itself. You add additional related environments in sequence number order,<br />
which is the search order you want <strong>Implementer</strong> to follow to locate a member/object in the<br />
list.<br />
To define related environments<br />
1 From the Work with Environments panel, select the environment with option<br />
14=Related environments, and press ENTER. The Work with Related Environments<br />
panel displays.
Environment Path<br />
2 Press F6=Add. The Add Related Environment panel displays.<br />
3 Complete the following fields:<br />
Environments<br />
In the Sequence number field, specify the number to order the environment in<br />
relation to other related environments.<br />
In the Related environment field, type the name of the related environment, or press<br />
F4=List to select from a list of environments.<br />
The Display as locked field allows you to define, when an item in the specified<br />
related environment is locked, if the item in the related environment displays as<br />
locked in Work with Objects (the actual object in the related environment is locked).<br />
This pertains to the mods and base environment models, when the item in base<br />
shows as locked but the actual lock is from the mods environment.<br />
Specify Y to show lock history as locked for the base environment. This is the<br />
required value when the related environment is on the related environment list<br />
of multiple environments, for example, multiple releases of an application, and<br />
when the Environment and Related environment fields have the same<br />
environment name.<br />
Specify N to show lock history as not locked for the base environment.<br />
4 Press ENTER to add the related environment.<br />
This function allows you to add additional controls that define a standard and emergency<br />
development path for production environments. The path defines the exact flow of<br />
members/objects through the development, testing, and production environments, and<br />
restricts access so they cannot move outside this flow. It also allows defaulting the From<br />
environment and target environment in check out and promotion. You can restrict users to<br />
the defined paths, preventing any circumvention of the predefined flow of work back into<br />
production.<br />
You can define a path for each production environment, representing the flow from the<br />
development environment, quality assurance, environment group, and original production<br />
environment (the first *PRD environment on the path). If an environment is on more than one<br />
path, <strong>Implementer</strong> uses the path designated by the original check out From environment<br />
(lock). If no lock exists, <strong>Implementer</strong> uses the first path found, including the environment, as<br />
the first production environment in the path.<br />
NOTE The terms environment path and application path are also referred to as a<br />
development path.<br />
101
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
102<br />
Key Considerations<br />
You can define application paths at the environment level and at the project level. If you<br />
use both environment paths and project paths, the project path is the default path in<br />
check out and create request when a project with a defined path is specified. For details,<br />
see “Project-based Application Paths” on page 142.<br />
Each application path can have a standard path and an emergency path that represents<br />
the flow member/objects follow from the initial check out to the final promotion into<br />
production.<br />
A standard path typically has a development environment (*TST) or library in the first<br />
sequence. The next sequence can be optional QA environments or environment groups<br />
(*QAC). The first production environment (*PRD) on the path must be the environment<br />
you check out from. For an environment group, the primary environment in the group<br />
must be the environment you check out from. Subsequent production environments or<br />
environment groups are allowed depending on your development model.<br />
An emergency path typically allows check out from production to development, and<br />
promotion directly from development back to production. You can modify this flow as<br />
needed.<br />
To define a standard or emergency path for an environment<br />
1 From the Work with Environments panel, type option 17=Standard path, or option<br />
18=Emergency path, and press ENTER to display the respective Environment Path panel.<br />
This panel allows you to create, change, delete, and display paths. The top environment<br />
or library represents development. The first production environment on the path is the<br />
check out from environment.
2 Press F6=Add. The Add Standard Path Entry panel displays.<br />
3 Complete the following fields:<br />
In the Sequence number field, type the appropriate number.<br />
Environments<br />
In the Entry field, type the environment name or press F4=Prompt to select from a<br />
list of environments.<br />
The value *USRPRF allows each developer to define a different development<br />
environment or library in the user profile entry (defined in Work with Users). The<br />
development environment or library must be the first sequence.<br />
4 Press ENTER to add the new path entries.<br />
Special Command Processing<br />
<strong>Implementer</strong>’s special commands feature allows you to define commands or programs that<br />
process each time a promotion targets a specified environment. You can define special<br />
commands to run on an environment basis, or globally for all environments.<br />
<strong>Implementer</strong> uses the environment library list when issuing the special commands.<br />
Therefore, if you have any unqualified object references in the command, you must include<br />
in the environment library list each library where the objects are located. The special<br />
command must exist in the environment library list (defined in Work with Environments) for<br />
each environment.<br />
NOTE You can use substitution variables within your command, and add comments<br />
to the special commands to make them self-documenting. Comments can display<br />
either before or after the command, and they must be in brackets, for example,<br />
/* This is a comment */<br />
For details on special commands and substitution variables, see the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
To define special commands for an environment<br />
1 From the Work with Environments panel, type option 19=Special commands next to the<br />
environment and press ENTER. The Work with Environment Special Commands panel<br />
displays. Any existing special commands display on this panel.<br />
103
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
104<br />
2 Press F6=Create to display the Expanded Command Display panel.<br />
3 Complete the fields as described in “Expanded Command Display Field Descriptions”<br />
on page 105.<br />
4 Press ENTER to save the special command. The Expanded Command Display panel<br />
displays blank. Create additional special commands, or press F12 to display the Work<br />
with Environments panel. The panel displays the special command you created.<br />
5 Press ENTER again to permanently save the new special command. The Work with<br />
Environments panel displays.<br />
Global Special Commands<br />
You define global special commands for environments by using the *ALL option. This option<br />
applies to all environments currently defined, as well as new environments you may add<br />
later.<br />
To create a special command for all environments<br />
1 From Work with Environments, press F10=*ALL Special Commands. The Work with<br />
Environment Special Commands panel displays.<br />
Any existing special commands display on this panel. Notice the Environment field<br />
defaults to *ALL.
2 Press F6=Create to display the Expanded Command Display panel.<br />
Environments<br />
3 Complete the fields as described in the following table, and press ENTER to add the<br />
command.<br />
Field Description<br />
Expanded Command Display Field Descriptions<br />
For Action Specify which promotion step processes the special command. The default<br />
value is blank.<br />
1=Compile: Special command runs in the compile stage.<br />
2=Dist-Host: Special command runs in the distribution stage on the host<br />
system.<br />
3=Dist-Rcvr: Special command runs in the distribution stage on the remote<br />
system.<br />
4=Move: Special command runs in the move stage. For promotions that<br />
target a remote system, the special command occurs where the move<br />
occurs.<br />
5=Move-Host: Special command runs on the system where the request<br />
originated, after successful distribution. This option is meaningful for<br />
promotions that target a remote system.<br />
6=Checkout: Special command runs in check out.<br />
When to do Specify when, during the selected For Action, to issue the special command.<br />
1=Before: Special command runs before the specified For Action.<br />
2=After-OK: Special command runs after the specified For Action<br />
successfully completes.<br />
3=After Fail: Special command runs after the specified For Action fails.<br />
105
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
Environment Report<br />
106<br />
Field Description<br />
The Environment Report lists the information defined for an environment. You can select to<br />
print summary level or detail information.<br />
The information includes: library type and defaults; host and remote library list; environment<br />
groups that contain the environment; related environments; standard and emergency paths;<br />
create request defaults; model copy details for AllFusion 2E environments; and promotion<br />
scheduling and submission overrides.<br />
The report also includes the setup defaults for AllFusion 2E, AS/SET, LANSA, and<br />
PeopleSoft World if installed.<br />
You can include information on the products and versions built from an environment, and<br />
the product versions that define an environment as a default customer environment.<br />
For environments that manage IFS objects, the report includes directory setup and archive<br />
information. The summary report can include object code information for both active and<br />
inactive object codes, object authorities, and object name rules. For environments that<br />
manage IFS objects, the IFS file extension prints for each object code that has a special<br />
characteristic of PCFILE (when the object code and extension are not the same).<br />
To print a detailed Environment Report for a specific environment<br />
From Work with Environments, select the environment with option 6=Print, and press<br />
ENTER. A message at the lower-left of the panel confirms the report printed.<br />
To print a summary or detailed Environment Report for all environments<br />
1 From the <strong>Implementer</strong> Menu, type 37, Environment Report, and press ENTER.<br />
2 Complete the fields as follows:<br />
Expanded Command Display Field Descriptions<br />
Sequence number Specify when to issue the command relative to other special commands. The<br />
number must be unique from other special commands for the environment.<br />
Command Specify the standard OS/400 command syntax of the command to run, or<br />
press F4 to prompt the command.<br />
In the Print object codes field, specify whether to include object codes for the<br />
environment. Type Y to print object codes. The default value N omits object codes.<br />
In the Print object authorities field, specify whether to include object authorities for<br />
the environment. Type Y to print object authorities. The default value N omits object<br />
authorities.
Environments<br />
In the Print object codes rules field, specify whether to include object name rules if<br />
defined for the environment. Type Y to print object name rules. The default value N<br />
omits object name rules.<br />
In the Output Queue and Library fields, specify the standard OS/400 submit job<br />
parameters as required.<br />
3 Press ENTER. A message at the lower-left of the panel confirms the report submitted.<br />
Third Party Integration Prerequisites<br />
The following information pertains to working with environments when using <strong>Implementer</strong><br />
with certain third party integrations.<br />
AS/SET Prerequisites<br />
To perform the initial setup for an AS/SET environment<br />
1 In System Control Maintenance, type Y in the AS/SET installed field and press ENTER.<br />
This allows you to define a standard environment with AS/SET information.<br />
2 In the Work with Environments panel, select the environment with option 11=AS/SET<br />
and press ENTER to display the Change Environment panel.<br />
3 In the AS/SET application set field, type the name of an existing application set.<br />
4 In the Archive application set field, type the name of the archive application set to<br />
archive AS/SET definitions.<br />
5 On the Change Environment panel, specify the number of archive versions in the<br />
Archive Versions field. In addition, specify the source library and archive library for<br />
traditional objects, and the required number of versions.<br />
6 Press ENTER. The Work with Environments panel displays.<br />
After completing this step, the Special environment field in the second Change<br />
Environment panel displays AS/SET. For details on configuring AS/SET integration, see<br />
page 316.<br />
LANSA Prerequisites<br />
To perform the initial setup for a LANSA environment<br />
1 In System Control Maintenance, type Y in the LANSA installed field and press ENTER.<br />
This allows you to define a standard environment with LANSA information.<br />
2 In the Work with Environments panel, select the environment with option 12=LANSA,<br />
and press ENTER to display the Change Environment panel.<br />
3 In the LANSA partition name field, type the name of the partition.<br />
107
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
108<br />
4 In the Copy LANSA object in check out field, specify whether to copy LANSA objects<br />
during check out.<br />
If the environment definition specifies to copy LANSA objects during check out, the<br />
copy runs in batch. The LANSA objects are exported out of the From environment and<br />
imported into the target environment. <strong>MKS</strong> recommends you manually verify the<br />
LANSA export and import reports.<br />
When checking out or promoting LANSA objects, the partition of the From environment<br />
should not be the same as the partition of the target environment.<br />
5 Press ENTER. The Work with Environments panel displays.<br />
After completing this step, the Special environment field in the second Change<br />
Environment panel displays LANSA. For details on configuring LANSA integration, see<br />
page 328.<br />
PeopleSoft World Prerequisites<br />
To complete the initial setup for a PeopleSoft World environment<br />
1 In System Control Maintenance, type Y in the PeopleSoft World installed field and press<br />
ENTER. This allows you to define a standard environment with PeopleSoft World<br />
information.<br />
2 In the Work with Environments panel, select the environment with option<br />
16=PeopleSoft World, and press ENTER to display the Change Environment panel.<br />
3 In the PeopleSoft World common library field, type the name of the PeopleSoft World<br />
common library.<br />
4 In the PeopleSoft World archive library field, type the name of the archive library for<br />
archiving.<br />
5 On the Change Environment panel, define the number of archive versions in the Archive<br />
Versions field. In addition, specify the source library and archive library for traditional<br />
objects, and the required number of versions.<br />
6 Press ENTER. The Work with Environments panel displays.<br />
After completing this task, the Special environment field in the second Change<br />
Environment panel displays PeopleSoft. For details on configuring PeopleSoft World<br />
integration, see page 355.
Common Questions<br />
Why is it necessary to use environments rather than just libraries?<br />
Environments and User Capabilities<br />
Two reasons are: <strong>Implementer</strong> only allows promotion into an environment to ensure positive<br />
tracking of all members/objects at each step of the development process, and, environments<br />
are an organizational aid for libraries and members/objects. Because environments are<br />
usually set up by application, it allows strict organization of all objects within the libraries.<br />
Environments automate many manual tasks, a primary advantage for the developer.<br />
What are the most common user errors that occur during environment setup?<br />
The necessary libraries are not included in the environment definition, and an incorrect<br />
library compilation order (compile library list).<br />
Environments and User Capabilities<br />
An environment has user capability flags that allow you to control the authority each user<br />
has to the environment for check out and promotion, as well as the authority to lock activities<br />
related to concurrent development and lock maintenance. This task allows you to grant each<br />
user specific rights that reflect the development activities the user is allowed to perform to an<br />
environment. This task is necessary for each user enrolled in <strong>Implementer</strong> for each<br />
environment they need to work in.<br />
The default rights you define in <strong>Implementer</strong> restrict rather than enable free access to the<br />
functions in <strong>Implementer</strong>. Thus, it is necessary to establish user authorities in two functional<br />
areas:<br />
Work with Users for basic authorities<br />
Work with Environments User Capabilities or Work with User - Environment<br />
Capabilities for environment-specific capabilities<br />
When initially setting up or changing environments, you can establish user capabilities while<br />
working with the environment—for this purpose, access the Change User Environment<br />
Capabilities panel through Work with Environments as described in the following task.<br />
When setting up or changing user profiles, access the panel from Work with Users. To set up<br />
required default libraries, environments, projects, or other user defaults, see “Users” on<br />
page 72.<br />
To assign user capabilities for an environment<br />
1 From the <strong>Implementer</strong> Menu, type option 42 or type STRIM (*WRKENV) at the<br />
command line and press ENTER. The Work with Environments panel displays.<br />
2 Select the environment with option 15=User capabilities and press ENTER. The Work<br />
with User Capabilities panel displays for the selected environment.<br />
109
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
110<br />
3 Select the user profile with option 2=Change and press ENTER. The first of two Change<br />
User Environment Capabilities panels displays.<br />
4 Establish the basic authorities for check out, locks and concurrent development, and<br />
promotion (press PAGE DOWN) as described in the following tables, and press ENTER to<br />
process the changes.<br />
Change User Environment Capabilities Field Descriptions: Panel 1<br />
Field Description<br />
Check out<br />
The following fields define the user’s authority to the environment for check out related tasks.<br />
Standard<br />
check out to<br />
Standard<br />
check out from<br />
Emergency<br />
check out to<br />
Emergency<br />
check out from<br />
Specify if the user has authority to perform standard check out to the<br />
environment.<br />
Specify if the user has authority to perform standard check out from the<br />
environment.<br />
Specify if the user has authority to perform emergency check out to the<br />
environment. a<br />
Specify if the user has authority to perform emergency check out from the<br />
environment.<br />
Locks<br />
The following fields define the user’s authority to the environment for tasks related to locks and<br />
concurrent development.
Environments and User Capabilities<br />
Change User Environment Capabilities Field Descriptions: Panel 1<br />
Field Description<br />
Allow concurrent dev Specify if the user has authority to perform concurrent development and<br />
check out a member/object from this environment when the item is checked<br />
out by another user. b,c Does not apply to emergency check out or promotion.<br />
1=No: User does not have authority to perform concurrent development.<br />
2=Seq Only: User has authority to perform concurrent development only<br />
for items under sequential development. User is not allowed to override<br />
the default copy From environment in check out.<br />
3=All-Auto: User has authority to perform concurrent development and<br />
override the copy From environment in check out. In sequential<br />
development, the copy From environment value defaults automatically. In<br />
non sequential development, user must manually select the copy From<br />
environment. This is the default value when <strong>Implementer</strong> is installed.<br />
4=All-Manual: User has authority to perform concurrent development and<br />
select the copy From environment in check out. In both sequential and non<br />
sequential development, the copy From environment defaults to blank and<br />
user must select it manually.<br />
Resolve conflicts Specify if the user has authority to resolve concurrent development conflicts<br />
on the Manage Concurrent Development - Work with Conflict Resolution<br />
panel. b,c<br />
For a production environment, applies to resolving conflicts for locks from the<br />
environment. For a development or test environment, applies to resolving<br />
conflicts for locks to the environment. Does not apply to emergency<br />
promotion.<br />
1=No: User does not have authority to resolve conflicts.<br />
2=Seq Only: User has authority to resolve conflicts only for items under<br />
sequential development (allows automatic conflict resolution).<br />
3=All-Auto: User has authority to resolve conflicts. In sequential<br />
development, conflicts resolve automatically. In non sequential<br />
development, user must resolve conflicts manually. This is the default<br />
value when <strong>Implementer</strong> is installed.<br />
4=All-Manual: User has authority to resolve conflicts. In both sequential<br />
and non sequential development, user must resolve conflicts manually.<br />
Lock maintenance Specify if the user has authority to maintain or delete locks on the<br />
Workbench. A project leader or another user that has move capabilities<br />
generally performs this function.<br />
a Emergency check out of a locked member/object causes concurrent development that requires users<br />
have authority to perform concurrent development for the From environment. In the case of an<br />
emergency, however, the authorities required to perform emergency check out override the authorities<br />
required to perform concurrent development. This allows a user who does not have authority to<br />
concurrent development to perform an emergency check out.<br />
b When using the <strong>Implementer</strong> Web interface for check out and promotion, the values 3=All-Auto and<br />
4=All-Manual function like the value 2=Seq Only. This is because the Web interface does not allow the<br />
manual entry of a copy From environment.<br />
c For details on how concurrent development is globally activated, see “Concurrent Development Scope”<br />
on page 71. For a description of sequential and non sequential development, see “Glossary” on<br />
page 457. For details on how the default copy From environment is determined, see the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
111
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
112<br />
Typical Environment Capabilities by User Type<br />
<strong>Implementer</strong> has the following types of users:<br />
administrator<br />
project leader (*PRD, *TST, or *QAC environments)<br />
senior developer (*PRD, *TST, or *QAC environments)<br />
user acceptance tester (*QAC environments)<br />
<strong>Implementer</strong> software owner<br />
security officer<br />
Change User Environment Capabilities Field Descriptions: Panel 2<br />
Field Description<br />
Request Promotion<br />
The following fields define the user’s authority to the environment for tasks related to promotion.<br />
Standard<br />
create request to<br />
Standard<br />
create request from<br />
Emergency<br />
create request to<br />
Emergency<br />
create request frm<br />
Distribute<br />
standard request<br />
Distribute<br />
emergency request<br />
Move<br />
standard request<br />
Move<br />
emergency request<br />
Specify if the user has authority to create a standard promotion request to<br />
this environment.<br />
Specify if the user has authority to create a standard promotion request from<br />
this environment.<br />
Specify if the user has authority to create an emergency promotion request<br />
to this environment.<br />
Specify if the user has authority to create an emergency promotion request<br />
from this environment.<br />
Specify if the user has authority to distribute a standard promotion request to<br />
this environment.<br />
Specify if the user has authority to distribute an emergency promotion<br />
request to this environment.<br />
Specify if the user has authority to move a standard promotion request to this<br />
environment.<br />
Specify if the user has authority to move an emergency promotion request to<br />
this environment.<br />
Maintain request Specify if the user has authority to maintain promotion requests for the<br />
environment.<br />
Recover request Specify if the user has authority to recover archived requests for the<br />
environment.<br />
Override<br />
obj attribute sourc<br />
Specify if the user has authority to change the source of object attributes at<br />
for the environment.
Environments and User Capabilities<br />
The following sections define the overall role of each type of user with. The tables identify the<br />
typical capabilities assigned to each type of user based on the environment type. You must<br />
determine how to assign capabilities based on your organization’s operations.<br />
Administrator<br />
The administrator has the highest level of authority within <strong>Implementer</strong> to maintain the<br />
<strong>Implementer</strong> control parameters. Use this role for initial set up, to install new applications,<br />
and to change environments and users’ capabilities. The following table lists the typical<br />
settings for administrators for production environments.<br />
Capabilities Production<br />
Check Out<br />
Standard check out to -<br />
Standard check out from Y<br />
Emergency check out to -<br />
Emergency check out from Y<br />
Locks<br />
Allow concurrent dev 2, 3 or 4 (Yes) a<br />
Resolve conflicts 2, 3, or 4 (Yes) a<br />
Lock maintenance Y<br />
Request promotion<br />
Standard create request to Y<br />
Standard create request from Y<br />
Emergency create request to Y<br />
Emergency create request from Y<br />
Distribute standard request Y<br />
Distribute emergency request Y<br />
Move standard request Y<br />
Move emergency request Y<br />
Maintain requests Y<br />
Recover requests Y<br />
Override obj attribute source Y<br />
a Based on how concurrent development is defined within your organization: 2=Sequential only,<br />
3=All-Auto, 4=All-Manual. For details, see page 110.<br />
113
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
114<br />
Project Leader: Any Environment Type<br />
The project leader or a user profile that has move capabilities has the next ascending level of<br />
authority to maintain and monitor change activity. This person might be a senior developer,<br />
analyst, project leader, or manager. This user typically creates projects, manages concurrent<br />
development, and moves developer-created promotion requests into the environments the<br />
administrator controls. The following table lists the typical settings for environment<br />
administrators for production, development, and quality assurance environments.<br />
Capabilities Development QA Production<br />
Check Out<br />
Standard check out to Y - -<br />
Standard check out from - Y Y<br />
Emergency check out to N - -<br />
Emergency check out from - N Y<br />
Locks<br />
Allow concurrent dev 1 (No) 1 (No) 2, 3 or 4 (Yes) a<br />
Resolve conflicts 1 (No) 1 (No) 2, 3, or 4 (Yes) a<br />
Lock maintenance Y Y Y<br />
Request promotion<br />
Standard create request to - - Y<br />
Standard create request frm Y Y Y<br />
Emergency create request to - - Y<br />
Emergency create request frm Y Y Y<br />
Distribute standard request Y Y Y<br />
Distribute emergency request N N Y<br />
Move standard request Y Y Y<br />
Move emergency request N N Y<br />
Maintain requests Y Y Y<br />
Recover requests - - Y<br />
Override obj attribute source Y Y Y<br />
a Based on how concurrent development is defined within your organization: 2=Sequential only,<br />
3=All-Auto, 4=All-Manual. For details, see page 110.
Senior Developer: Any Environment Type<br />
Environments and User Capabilities<br />
The senior developer checks out source members, performs programming changes, and<br />
creates promotion requests. A senior developer is often given emergency capabilities. The<br />
following table lists the typical settings for senior developers for development, quality<br />
assurance, and development environments.<br />
Capabilities Development QA Production<br />
Check Out<br />
Standard check out to Y - -<br />
Standard check out from - Y Y<br />
Emergency check out to N - -<br />
Emergency check out from - N Y<br />
Locks<br />
Allow concurrent dev 1 (No) 1 (No) 2, 3 or 4 (Yes) a<br />
Resolve conflicts 1 (No) 1 (No) 2, 3, or 4 (Yes) a<br />
Lock maintenance N N Y<br />
Request promotion<br />
Standard create request to - Y Y<br />
Standard create request frm Y Y Y<br />
Emergency create request to - N Y<br />
Emergency create request frm N N N<br />
Distribute standard request N N Y<br />
Distribute emergency request N N Y<br />
Move standard request N N Y<br />
Move emergency request N N Y<br />
Maintain requests N N Y<br />
Recover requests N - N<br />
Override obj attribute source - Y N<br />
a Based on how concurrent development is defined within your organization: 2=Sequential only,<br />
3=All-Auto, 4=All-Manual. For details, see page 110.<br />
115
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
116<br />
User Acceptance Tester: QA Environment<br />
This user typically accepts promotion requests into their test environments, tests the changes<br />
in a controlled test environment, and creates promotion requests to production or the next<br />
test environment. The following table lists the typical settings for user acceptance testers for<br />
quality assurance environments.<br />
Capabilities QA<br />
Check Out<br />
Standard check out to -<br />
Standard check out from N<br />
Emergency check out to -<br />
Emergency check out from N<br />
Locks<br />
Allow concurrent dev 1 (No)<br />
Resolve conflicts 1 (No)<br />
Lock maintenance N<br />
Request promotion<br />
Standard create request to N<br />
Standard create request frm Y<br />
Emergency create request to N<br />
Emergency create request frm N<br />
Distribute standard request N<br />
Distribute emergency request N<br />
Move standard request N<br />
Move emergency request N<br />
Maintain requests N<br />
Recover requests N<br />
Override obj attribute source N
<strong>Implementer</strong> Software Owner MWIPROD<br />
Environment Repository Build<br />
<strong>Implementer</strong> includes the user profile MWIPROD. This user profile has security<br />
administrator rights to set up <strong>Implementer</strong> and owns most of the objects in <strong>Implementer</strong>.<br />
MWIPROD typically does not have capabilities to the environments in <strong>Implementer</strong>. <strong>MKS</strong><br />
recommends you define a user profile other than MWIPROD to serve as the administrator;<br />
however, this profile should not have specific authorities to the environments.<br />
NOTE <strong>MKS</strong> recommends you set the MWIPROD profile to bypass expiring the<br />
password. To do this, issue the CHGUSRPRF command with parameter value<br />
PWDEXPITV(*NOMAX).<br />
Security Officer<br />
<strong>MKS</strong> recommends you use the default user profile in the event that access is accidentally<br />
denied to other users in the system. The IBM-shipped security officer user profile QSECOFR<br />
has security administrator rights to administer <strong>Implementer</strong>.<br />
The security officer typically does not have capabilities to the environments in <strong>Implementer</strong>.<br />
<strong>MKS</strong> recommends you define a user profile other than QSECOFR to serve as the<br />
administrator. Again, this profile should not have specific authorities to the environments.<br />
NOTE Any of these user profiles can be group profiles; however, if a specific user is<br />
a member of a group but not enrolled under a separate OS/400 profile, the user has<br />
the same rights as those defined for the group profile.<br />
Environment Repository Build<br />
The Build List function, also called the “build”, loads source and object, and object code<br />
information from an environment’s set of libraries into <strong>Implementer</strong>’s environment<br />
repository. The repository provides a productivity aid that allows you to select members and<br />
objects from lists rather than having to manually type each name in the check out and create<br />
request functions. In addition, <strong>Implementer</strong> uses the repository for impact analysis to<br />
determine the source of related objects across environments.<br />
You can create the environment repository by using any of the following build types:<br />
*ALL processes all member/object types including related objects. By using additional<br />
parameters you can control whether to show build objects in the report, retain existing<br />
valid object codes, add new member/objects, remove records for items that no longer<br />
exist in the environment libraries, or completely clear the repository and rebuild it from<br />
start.<br />
*IFS processes IFS object only. This is useful when an environment has been actively<br />
managing traditional member/objects, and you add new IFS objects.<br />
117
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
118<br />
*REL processes related objects only. It updates the repository to show the environments<br />
where related objects exist.<br />
For more information on build types, see “Build List (IBLDMBOLST) Command Parameters”<br />
on page 119.<br />
The build generates the Environment Build Report, which provides member/object status<br />
and information on errors and warnings that occurred during the build. You can use this<br />
report in place of the job log or user message queue for troubleshooting errors with the build.<br />
For details, see “Environment Build Report” on page 121.<br />
Key Considerations<br />
You must have authority to host environment maintenance to run the build for a host<br />
environment, and authority to remote environment maintenance to run the build for a<br />
remote environment. These authorities are defined in Work with Users.<br />
The environment’s program library, file library, and source library must exist or the<br />
build ends in error.<br />
You can run the build from an option in Work with Environments or by using a<br />
command interface.<br />
In Work with Environments, the Build List field confirms the repository status for an<br />
environment.<br />
For each *PRD and *QAC environment in Work with Environments, specify to maintain<br />
related object information and specify the source of information. This is not required for<br />
development environments.<br />
If you use related objects in check out or create request, you must run the build for each<br />
new *PRD and *QAC environment to create the initial list of member/objects in the<br />
environment.<br />
Once you create the member/object list and the environment/libraries are handled by<br />
<strong>Implementer</strong>, the member/object list is maintained dynamically. You can rebuild the list<br />
for maintenance purposes at any time, for example, if you edit object codes that support<br />
source and object with different names.<br />
If multiple object codes exist with the same characteristics, the object code with the<br />
lowest sequence number is selected by the build when the Retain Object Codes value is<br />
set to *NO. This gives better control over which object code is selected for the<br />
environment.<br />
Changing the sequence number of an object code may change the compile sequence of<br />
members/objects in Compile Request.<br />
The build does not assign object codes used to change the characteristics or data of an<br />
existing object. This applies to any object code defined with creation process M or a<br />
special characteristic beginning with “*”. For example, the build does not assign the<br />
object codes PFDTA, PFCHG, and MRGMSGF.
Environment Repository Build<br />
For AS/SET environments, the build includes both traditional objects and AS/SET<br />
definitions that exist in the application set specified for the environment.<br />
Object Version Stamping<br />
During the build for production environments, <strong>Implementer</strong> if object version stamping is<br />
active in System Control Maintenance. If active, and the actual object is stamped with a<br />
version number, <strong>Implementer</strong> processes the corresponding repository record as follows:<br />
If the object version is valid, the build assigns that version number to the repository<br />
record.<br />
If the object is not stamped or stamped with an invalid version number, the build assigns<br />
the repository record with version number 1 or 1.0 based on the specified versioning<br />
method. If a user-defined versioning method is specified, a user exit allows you to set the<br />
version number.<br />
The repository records for *TST and *QAC environments are built with a blank version<br />
number, and source-only objects built by <strong>Implementer</strong> are disregarded (they are not assigned<br />
a version number). For more information on object version stamping, see page 146.<br />
NOTE The build updates the repository record with the object version, not the actual<br />
object. The build also does not stamp objects with issue or DR numbers.<br />
To run the build list<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Environments, and press ENTER.<br />
2 Select the environment with option 30=Build List, and press ENTER. The Build Member/<br />
Object Lists (IBLDMBOLST) command panel displays.<br />
3 Complete the command parameters as described in “Build List (IBLDMBOLST)<br />
Command Parameters” on page 119.<br />
Upon successful completion a message confirms the job completed normally. In Work<br />
with Environments, the Build List field reflects the repository status for each<br />
environment.<br />
TIP You can run the environment build list for IFS objects only from Work with<br />
Objects option F21=Build IFS Object List.<br />
Build List (IBLDMBOLST) Command Parameters<br />
The Build List (IBLDMBOLST) command is the command interface to Work with<br />
Environments option 30=Build List.<br />
119
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
120<br />
Environment<br />
Specify the environment to build the repository for.<br />
Build type<br />
Specify the objects to include in the repository.<br />
*ALL Builds the repository for all objects in the environment libraries, including<br />
IFS objects. Generates the Environment Build Report.<br />
*IFS Builds the repository for IFS objects only. Generates the Environment Build<br />
Report. Requires the following Retain object codes parameter value set to<br />
*NO.<br />
*REL Builds the repository for related objects only. Does not generate the<br />
Environment Build Report. Requires the following Retain object codes<br />
parameter value set to *YES.<br />
Retain object codes<br />
The build validates each repository record in the environment’s libraries to ensure the<br />
associated object code is valid. If valid, the record remains as is. If not valid, derives a new<br />
object code and recreates the repository record.<br />
Specify how to build the repository.<br />
*YES Validates the object code, object and/or source, and retains the existing<br />
object code for valid items. Builds the repository with new source/objects<br />
added to the environment’s libraries. Removes source/objects that no<br />
longer exist in the environment’s libraries. This is useful for environments<br />
with object codes modified after the initial repository build, for example,<br />
changes to sequence numbers, compile parameters, or compile commands,<br />
as it retains valid records you otherwise have to recreate.<br />
This is the default value and requires the Build Type value *ALL.<br />
*NO Clears the repository of existing records and rebuilds it based on current<br />
information in the environment’s libraries.<br />
Show built objects in report<br />
Specify whether to include built objects in the Environment Build Report.<br />
*YES The report includes a list of all member/objects in the environment<br />
repository.<br />
*NO The report excludes the environment repository section.<br />
Output queue/Library<br />
Specify the output queue and library for the Environment Build Report. The value *JOB uses<br />
the output queue and library of the user submitting the job.
Submit<br />
Specify *YES to submit the job to batch processing, or *NO to run interactively.<br />
Job queue/Library<br />
Environment Repository Build<br />
Specify the job queue and library for the build list. The value *PRODUCT uses the default<br />
output queue and library specified in System Control Maintenance.<br />
Hold on job queue<br />
Specify whether to hold the build list job on the job queue.<br />
*JOBD Uses the value specified in the job description of the user submitting the<br />
job. This is the default value.<br />
*NO The job is not held on the job queue.<br />
*YES The job is held on the job queue.<br />
Common Questions<br />
When do you need to run the build list?<br />
Run the build list for each newly created environment, or if you add source or objects to the<br />
environment library outside of <strong>Implementer</strong>.<br />
If you create a new member using <strong>Implementer</strong>, is it necessary to rerun the build list?<br />
No. <strong>Implementer</strong> automatically updates the list. When you check out a new member with an<br />
action code of 2, <strong>Implementer</strong> creates a new member.<br />
Environment Build Report<br />
The Environment Build Report generates automatically for the build types *ALL and *IFS.<br />
The report does not generate for the build type *REL. This report is helpful for problem<br />
resolution if errors or unexpected results occur during a build, as it replaces having to use the<br />
job log or user message queue for troubleshooting errors with the build.<br />
The report includes the following information:<br />
general environment information<br />
list of all source members and objects in the environment libraries not added to the<br />
repository, with specific messages for each source member and object<br />
optionally, a list of all source, objects, and object codes loaded into the repository<br />
list of objects in the environment libraries not added to the repository<br />
list of source members in the environment libraries not added to the repository<br />
warnings that occurred during the build for specific related objects<br />
121
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
122<br />
message legend that guides you to specific actions to resolve the errors<br />
NOTE Although rare, the job log may also include unique problems not detectable<br />
by <strong>Implementer</strong>.<br />
Environment Repository Report<br />
The Environment Repository Report provides a listing of all source members and objects<br />
currently in the repository. The report is a print snapshot of the environment information<br />
that displays when filtering by environment and viewing detail in Work with Objects.<br />
The report includes general environment information and a list of all objects and object codes<br />
currently in the repository. You can optionally include related objects. You can sort the report<br />
by object name or object code.<br />
When both traditional and IFS objects exist for an environment, the report is divided into two<br />
sections; one for traditional objects and the other for IFS objects. IFS object names include the<br />
full object name and relative path. If the long name and path are longer than 100 characters,<br />
the field truncates at the end.<br />
The values stored in the Chg Date/Time fields are the latter of the date and time of the last<br />
environment build or the last promotion.<br />
The report is available by using Work with Environments option 27=Repository Report.<br />
When selected, it prompts the Repository Report (IPRTREPRPT) command. You can also<br />
issue the command from a command line. This is a host-only feature (not available on remote<br />
systems).<br />
To generate the Environment Repository Report<br />
1 Do either of the following to prompt the Repository Report (IPRTREPRPT) command:<br />
From Work with Environments, type option 27=Repository Report next to the<br />
environment, and press ENTER.<br />
On a command line, type IPRTREPRPT and press F4=Prompt.<br />
2 Complete the parameters as defined next in “Repository Report (IPRTREPRPT)<br />
Command Parameters” and press ENTER. The report generates to the user’s default spool<br />
file based on the command parameters.<br />
NOTE Running the Environment Repository Report for an environment when the<br />
build list has not been run causes an empty report. In Work with Environments,<br />
check the Build List field to verify the environment’s build status.
Repository Report (IPRTREPRPT) Command Parameters<br />
Environment<br />
Environment Repository Build<br />
Specify the environment name. If using Work with Environments option 27=Repository<br />
Report, this value defaults to the environment selected.<br />
Show related objects<br />
Specify *YES to include related objects, or *NO to omit related objects.<br />
Member/object sort method<br />
Specify the report sort order.<br />
*OBJECT The report sorts in member/object order. This is the default value.<br />
*OBJCODE The report sorts in object code order.<br />
Output queue/Library<br />
Specify the output queue and library for the report output. The default value *JOB uses the<br />
output queue and library associated with the user generating the report.<br />
Submit<br />
Specify whether to submit the job for batch processing or run interactively. The default value<br />
*YES submits the job.<br />
Job queue/Library<br />
Specify the job queue and library for job processing. The default value *PRODUCT uses the<br />
default job queue and library defined in System Control Maintenance.<br />
Hold on job queue<br />
Specify whether to hold the report job on the job queue.<br />
*JOBD Uses the value specified in the job description of the user submitting the<br />
job. This is the default value.<br />
*NO Does not hold the job.<br />
*YES Holds the job.<br />
Environment Verification Report<br />
The Environment Verification Report is an audit tool that allows you to compare the actual<br />
source and objects in an environment’s set of libraries to the source and object definitions<br />
recorded in the <strong>Implementer</strong> repository for the environment. It is useful to run after using<br />
<strong>Implementer</strong> to manage member/objects, to verify the accuracy or validity of the<br />
environment’s contents and to identify potential problems.<br />
123
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
124<br />
The verification identifies: compile dates, source location, authorities, unexpected source and<br />
objects in the environment libraries—and vice versa—expected source or objects not located,<br />
and changes made outside of <strong>Implementer</strong>.<br />
The report lists items by section ID according to the potential issue identified, as follows:<br />
objects in the environment libraries that do not exist in the repository<br />
source members in the environment libraries that do not exist in the repository<br />
objects in the repository that do not exist in the environment libraries<br />
source members in the repository that do not exist in the environment libraries<br />
source-based objects in environment libraries that were created from source other than<br />
that defined to the environment<br />
source members in the repository where the change date/time stamp on the actual<br />
source member does not match that of the repository record<br />
objects in the repository where the change date/time stamp on the actual object does not<br />
match that of the repository record<br />
IFS files in a directory but not in the repository<br />
IFS files in the repository but not in a directory<br />
This feature is available for both host and remote environments by using Work with<br />
Environments option 26=Verification Report. When selected, it prompts the Verification<br />
Report (IVFYRPT) command. You can also issue the command from the command line.<br />
To generate the analysis and print the Environment Verification Report<br />
1 Do either of the following to prompt the Verification Report (IVFYRPT) command:<br />
From Work with Environments, type option 26=Verification Report next to the<br />
environment, and press ENTER.<br />
On a command line, type IVFYRPT and press F4=Prompt.<br />
2 Complete the parameters as defined next in “Verification Report (IVFYRPT) Command<br />
Parameters” and press ENTER. The report generates to the user’s default spool file based<br />
on the command parameters.<br />
Verification Report (IVFYRPT) Command Parameters<br />
Environment<br />
Specify the environment name to process. If using Work with Environments option<br />
26=Verification Report, the value defaults to the environment selected.
Output queue/Library<br />
Environment Groups<br />
Specify the output queue and library to place the report. The default value *JOB uses the<br />
output queue and library of the user submitting the job.<br />
Submit<br />
Specify whether to submit the job or process interactively. The default value *YES submits<br />
the job. Specify *NO to process interactively.<br />
Job queue/Library<br />
Specify a job queue and library name, or use the default value *PRODUCT to use the job<br />
queue and library defined in System Control Maintenance.<br />
Hold on job queue<br />
Specify whether to hold the report job on the job queue.<br />
*JOBD Uses the value specified in the job description of the user submitting the<br />
job. This is the default value.<br />
*NO Does not hold the job.<br />
*YES Holds the job.<br />
Environment Groups<br />
An environment group is a collection of two or more environments, called a target<br />
environment group. You can use a target environment group to promote a request containing<br />
one or more objects to more than one environment. The target environment group function<br />
eliminates the need to select a list of environments every time you create a promotion request<br />
to multiple target environments.<br />
Key Considerations<br />
You can specify an environment group on an application path. For details on path setup,<br />
see “Environment Path” on page 101, and “Project-based Application Paths” on<br />
page 142.<br />
If the environment group’s primary environment is the first production environment on<br />
the path, it is the check out From environment.<br />
If a production environment precedes the environment group on the path, the first<br />
production environment is the check out From environment.<br />
If the environment group targets AS/SET environments, the first environment in the<br />
environment group must be an AS/SET environment. You can include other AS/SET<br />
environments in the environment group.<br />
125
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
126<br />
When using environment groups for promotion, AS/SET information is promoted only<br />
to the environments defined as AS/SET environments.<br />
To minimize potential errors with promoting to incorrect environments, you cannot<br />
modify an environment group using the Target Environments function in Create<br />
Request, Compile Request, Move Request, or Request Maintenance.<br />
If you use <strong>MKS</strong> Source archiving, when a promotion targets an environment group that<br />
has both local and remote environments, only the local environment has the revision<br />
update (you cannot archive remote environments in <strong>MKS</strong> Source). If you later promote<br />
the items to a group, either QA environments further on the path or production, both the<br />
host and remote repository entries for the items reference the associated revision IDs.<br />
To create or change an environment group<br />
1 From the <strong>Implementer</strong> Menu, type option 43, or type STRIM (*WRKENVGRP) on the<br />
command line and press ENTER. The Work with Environment Groups selection panel<br />
displays.<br />
2 Do one of the following:<br />
To add an environment group, press F6=Add.<br />
To copy an existing environment group, type 3 in the Opt field and press ENTER.<br />
To change an environment group, type 2 in the Opt field and press ENTER.<br />
3 On the Work with Environment Groups detail panel, complete the following fields:<br />
In the Environment group field, type the group name. The value must begin with an<br />
asterisk (*) and include a description.<br />
In the Opt field, type 1 to select the environments to include.<br />
For each selected environment, in the Seq field type the sequence for promotion.<br />
The primary environment must be sequence 1. Additional environments must have<br />
a sequence greater than 1.<br />
In the Cmp field, specify Y or N to indicate whether to compile for this environment.<br />
4 Press ENTER. The Work with Environment Groups selection panel displays.<br />
TIP To work with an environment, press F20 to display the Work with<br />
Environments panel.<br />
Common Questions<br />
Can you target multiple environments if an environment group is not defined?<br />
Yes. During Create Request, press F14=Target environments and select the additional<br />
environments.
Object Codes<br />
What signifies an environment group name?<br />
Environment group names must begin with an asterisk (*).<br />
How is a primary environment identified from other environments in an environment group?<br />
A primary environment must be sequence 1. Typically, this is a host production<br />
environment. Additional environments must be a sequence greater than 1.<br />
Can a target environment group be used on a path?<br />
Object Codes<br />
Yes. You can use an environment group on a path. If the environment group’s primary<br />
environment is the first production environment on the path, it is the check out From<br />
environment. If a production environment precedes the environment group on the path, the<br />
first production environment is the check out From environment.<br />
<strong>Implementer</strong> uses object codes to define the various types of members/objects you check out<br />
and promote. They also enable automatic functions when you associate an object with an<br />
object code.<br />
An object code combines information from the OS/400 object type and source type and<br />
directly associates the following to an object: OS/400 object type, object attribute, source<br />
member type, default source file, and default authority. You can manually override the<br />
default creation command and authority when you create the promotion request.<br />
The Work with Object Codes function allows you to create, change, delete, activate, and<br />
deactivate object codes. Most users do not need to change the default values; however, this<br />
parameter-driven approach allows you to:<br />
Create new object codes for object types not shipped in <strong>Implementer</strong> (for example, other<br />
programming languages).<br />
Change the standard source file for existing objects codes. For example, you can specify<br />
that COBOL programs default to using the source file name QCBLSRC instead of the<br />
standard OS/400 default name QLBLSRC. Changes you make to global object codes in<br />
Work with Object Codes do not overwrite overrides defined at the environment level.<br />
Change the compile options. For example, you can optimize all RPG programs during<br />
compilation without changing the actual CRTRPGPGM command.<br />
Call your own compile procedures by changing the commands used for compiling. For<br />
example, many third-party application software packages have their own compile<br />
commands.<br />
Deactivate object codes you do not use, for example, System/36 and System/38<br />
environment object codes.<br />
127
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
128<br />
Control source archiving in <strong>MKS</strong> Source (requires active integration between<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source). For details, see “<strong>Implementer</strong> and <strong>MKS</strong> Source<br />
Integration” on page 259.<br />
Key Considerations<br />
You can define object codes at three levels: object code, environment, and system. Object<br />
codes defined at the object code level and environment level can be activated or<br />
deactivated for one or all environments. Object codes defined at the system level can be<br />
activated or deactivated at the system or environment level.<br />
Object codes must be active and enabled to the specific environment before you can use<br />
them. Inactive object codes cannot be used within <strong>Implementer</strong>.<br />
When you make an object code inactive, <strong>Implementer</strong> retains any existing environment<br />
overrides. To reactivate, simply change the value of the Activity flag field. Reactivating<br />
the object code also reactivates the environment overrides.<br />
When defining object codes for source members and corresponding objects with<br />
different names, object codes that use a creation command with the SRCMBR parameter<br />
(for example, CRTPLIPGM) must specify the keyword #SRCMBR in the Source Member<br />
Name parameter. In the Creation command field, add SRCMBR(#SRCMBR.<br />
After editing object codes for an environment that has source and object with different<br />
names, run the Build List, option 30 in Work with Environments. For details, see<br />
“Environment Repository Build” on page 117.<br />
When using the SQLTABL (for physical files) and SQLINDX (for logical files) object<br />
codes, you must check out all related PFs and LFs together—implicit LF processing does<br />
not occur.<br />
To create or change an object code<br />
1 From the <strong>Implementer</strong> Menu, select option 44, Object Codes, or type STRIM<br />
(*WRKOBJCDE) at the command line, and press ENTER.<br />
2 Do one of the following:<br />
To add a new object code, press F6=Add. The Create Object Code panel displays.<br />
To copy an existing object code, type 3 in the Opt field and press ENTER. The Create<br />
Object Code panel displays.<br />
To change an existing object code, type 2 in the Opt field and press ENTER. The<br />
Change Object Code panel displays.
Object Codes<br />
3 Complete the fields as described in “Object Code Field Descriptions” on page 129 and<br />
press ENTER.<br />
4 On the Object Code Override Defaults window, the activation reply options pertain to<br />
the action you performed: create, change, or reactivate. Select one of the following values<br />
and press ENTER.<br />
A=All: Activates to all environments. Use this when the object code is valid for all or<br />
most environments. You can selectively deactivate it for any environment as<br />
needed. Valid for actions create, change, and delete.<br />
N=None: Does not activate to any environment. Use this when few environments<br />
use the object code. You can selectively activate it for any environment as needed.<br />
Valid for actions create and reactivate.<br />
K=Keep: Activates the object code to the environments it was previously active to.<br />
Use this when reactivating an object code and the environments it was previously<br />
active to has not significantly changed. Valid for actions change and reactivate.<br />
Field Description<br />
Object Code Field Descriptions<br />
Object code Specify the name of the object code. The code relates to the source<br />
member type, not the OS/400 object type.<br />
Object codes for IFS files must begin with a dot (.) and can be followed<br />
by a character string. Object codes for IFS directories must begin with a<br />
backward slash (\). If the directory name has an extension, define the<br />
object code with a backward slash followed by a dot and the extension.<br />
For example, the object code for directory DIR.ONE is \.ONE.<br />
129
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
130<br />
Field Description<br />
Object Code Field Descriptions<br />
Activity flag Specify the status of the object code. You cannot check out or create a<br />
request for a member/object using an inactive object code. You can use<br />
an inactive object code for inquiry purposes.<br />
1=Active: Object code is active. This is the default value for most object<br />
codes.<br />
0=Inactive: Object code is inactive. Some infrequently used object<br />
codes are delivered inactive with <strong>Implementer</strong>.<br />
Object type Specify the type of object associated with this object code.<br />
When this field blank, the object code is referred to as non object based.<br />
This occurs, for example, when you use <strong>Implementer</strong> to check out non<br />
OS/400 objects such as printed user manuals or source-based items that<br />
only have a source member, such as OCL36 source members.<br />
Object attribute Specify the system attribute of the object associated with this object<br />
code.<br />
Source member type For object codes related to source members or source-based objects,<br />
specify the system source member type. When this field is blank, the<br />
object code is referred to as non source-based.<br />
Match the source member type code of the actual object to what is<br />
defined in <strong>Implementer</strong>. For example, the source member type for a<br />
reference file defaults to PF (like a standard physical file). To compile the<br />
reference file before the physical file, change this type to PFREF and<br />
specify a lower sequence number.<br />
Default source file For object codes related to source-based objects, specify the name of the<br />
source file. You can override the source file name in Work with<br />
Environments when you define object codes for an environment, or in<br />
Work with User Profiles by specifying the development source files of the<br />
developer.<br />
Creation sequence Specify the sequence to compile members and objects. The value must<br />
be a unique number between 1–ZZZZ. Certain object types require<br />
compiling before others. In general, the logical order is as follows: field<br />
reference files, physical files, logical files, device files (such as display<br />
and printer files), commands, and programs. The object codes delivered<br />
with <strong>Implementer</strong> use this order.<br />
When automatically assigning object codes in check out or promotion,<br />
<strong>Implementer</strong> assigns sequence 8000 to IFS directory object codes, and<br />
sequence 8010 to IFS files.<br />
Special characteristics Specify any special characteristics for the object code, such as copy data<br />
only rather than a file, merge messages in message files, or any CASE<br />
related characteristics. <strong>Implementer</strong> considers these characteristics when<br />
processing the object code.<br />
For IFS files, specify PCFILE. For IFS directories, specify PCDIR.
Field Description<br />
Object Code Field Descriptions<br />
Object authority Specify whether to keep object authority of existing object or assign<br />
based on the target environment definition.<br />
Object Codes<br />
*KEEP: Retains authority of the object in the target environment. If the<br />
object does not exist in the target environment, then *GRANT is<br />
assigned. This is the default value.<br />
*GRANT: Grants authority to the object based on the target<br />
environment. Assigns the object owner as defined in the Obj Owner<br />
field on the Change Environment panel. Assigns object authorities<br />
based on the list of authorities on the Work with Environments - Object<br />
Authorities panel. Ignores existing authorities if object exists in the<br />
target environment library.<br />
Remove obj in from env Specify whether to delete objects of this type in the From environment<br />
after successful promotion. a<br />
Remove src in from env Specify whether to delete the source for objects of this type in the From<br />
environment after successful promotion. a<br />
Creation process Specify when to issue the creation command:<br />
C=Compile: Creation command runs during the Compile Requests<br />
function. Most object codes delivered with <strong>Implementer</strong> have this<br />
creation process.<br />
Use this for: objects requiring compilation, duplicating or moving<br />
objects into production, creating a new object, replacing an existing<br />
object. <strong>Implementer</strong> places the object/source member into a work<br />
library before the move. Move Requests function replaces the existing<br />
object and/or source member. During the move, <strong>Implementer</strong> executes<br />
the commands required to move the object or source member into the<br />
environment library. This is the default value.<br />
M=Move: Creation command runs during the Move Requests function.<br />
Use this only to copy source members and execute commands that<br />
directly change production database files, such as conversion<br />
programs or copying data. During the compile step, <strong>Implementer</strong> does<br />
not perform any action on items with this object code. Use this process<br />
only for object codes that leave the existing object and/or source<br />
member in place and simply change or affect the object or member, for<br />
example, object codes CHGPGM or CHGPRTF, or CPYF command<br />
when promoting data in a file.<br />
131
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
132<br />
Field Description<br />
Object Code Field Descriptions<br />
Archive in <strong>MKS</strong> Source Specify whether to archive the source for this object code in <strong>MKS</strong> Source.<br />
Requires active integration between <strong>Implementer</strong> and <strong>MKS</strong> Source. By<br />
default, source-based object codes and those with a special<br />
characteristic of PCFILE are set for archiving in <strong>MKS</strong> Source. Non<br />
source-based object codes and those with a special characteristic of<br />
PCDIR are not eligible for archiving in <strong>MKS</strong> Source.<br />
Y=Yes: Archives source for the object code if the target environment is<br />
eligible. Valid only for source-based object codes and those with<br />
special characteristic PCFILE. This is the default value.<br />
N=No: Does not archive source for the object code. Required value for<br />
non source-based object codes and those with special characteristic<br />
PCDIR.<br />
For details, see “<strong>Implementer</strong> and <strong>MKS</strong> Source Integration” on page 259.<br />
Creation command Specify the OS/400 command required to create an object or perform the<br />
migration task for the object code. <strong>Implementer</strong> replaces any substitution<br />
variables (references to objects within the creation command) with the<br />
actual names and libraries associated with the implementation request.<br />
The valid substitution variables are as follows:<br />
#FILLIB: For creation process C, substitutes the temporary work library<br />
where the request’s files and program objects are moved or compiled<br />
into. For compile=Y requests, objects do not exist until successfully<br />
compiled. Changing the authorities of objects in this library does not<br />
affect the authority of the object in the target environment. For creation<br />
process M, substitutes the target library.<br />
#FRMLIB: For creation process C, substitutes the temporary work<br />
library where the request’s files and program objects are moved or<br />
compiled into. For compile=Y requests, the objects do not exist until<br />
successfully compiled. For creation process M, substitutes the work<br />
library created for the request. Changing authorities of objects in this<br />
library does not affect authority of objects in the target environment.<br />
#OBJECT: Substitutes the current member/object name at the time of<br />
promotion.<br />
#OBJNM9: Substitutes the current, short object name at the time of<br />
promotion.<br />
#PGMLIB: Same as #FRMLIB.<br />
#SRCFIL: Substitutes the source file name of the promoted item. For<br />
creation process C, it is the same as #WRKSRCFIL. For creation<br />
process M, it is the target source file.<br />
#SRCLIB: Substitutes the target source library of the promoted item.<br />
For creation process C, it is the work source library. For creation<br />
process M, it is the target source library.<br />
#SRCMBR: Substitutes the source member name of the promoted<br />
item.<br />
a The value specified here is only used as the default value when creating new environment object code<br />
overrides. You can override it at the environment level. Changing this value affects overrides created<br />
from this point forward, it does not affect existing overrides. For details, see “Removing Source and<br />
Objects After Promotion” on page 92.
Environment Overrides<br />
Object Codes<br />
This function allows you to work with specific object codes by environment. You can<br />
override the object library, source file, or source library for an environment, and activate or<br />
deactivate specific object codes. You can also override the default values that determine<br />
whether <strong>Implementer</strong> automatically deletes source and objects when promoting from the<br />
environment.<br />
To work with object code overrides for environments<br />
From Work with Object Codes, select an object code with option 7=Environment Overrides<br />
and press ENTER. The Work with Object Code/Environment panel displays.<br />
This panel is similar to the Change Environment Object Code Overrides panel you access<br />
from Work with Environments—the only difference is the data sort order. This view allows<br />
you to work with all environments for a specific object code. For information on defining this<br />
panel, or to view all object codes for a specific environment, see “Object Code Overrides” on<br />
page 91.<br />
Object Codes for Third Party Integrations<br />
<strong>Implementer</strong> supports integrations with a variety of other software vendors. For this<br />
purpose, <strong>Implementer</strong> reserves the following object code special characteristics: ADK for<br />
AS/SET definitions, LAN for LANSA objects, and JDE for PeopleSoft World soft coding<br />
items.<br />
133
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
134<br />
AS/SET Integration<br />
The following special characteristic codes are for managing AS/SET definitions.<br />
ADKDSP ADKMDL<br />
ADKDSP ADKFLD<br />
ADKHLP ADKFIL<br />
ADKBAT ADKAUD<br />
ADKRPT ADKSUB<br />
Create object codes that have special characteristics beginning with ADK as non source and<br />
non object based object codes. Create object codes using special characteristics beginning<br />
with ADK as non source and non object based object codes. For more information, see<br />
“AS/SET Integration” on page 316.<br />
PeopleSoft World Integration<br />
The following special characteristic codes are for managing PeopleSoft World applications.<br />
JDEUDE JDEDDC JDEWCS<br />
JDEUDS JDEVOV JDNSPC<br />
JDEDWR JDEMNU JDNPRTF<br />
JDEMBM JDEFST<br />
JDEWWR JDEPRO<br />
If you use <strong>Implementer</strong> to manage the PeopleSoft World User Defined Code, see the<br />
instructions for constructing the member/object name of this soft coding item in “PeopleSoft<br />
World Integration” on page 355.<br />
LANSA Integration<br />
The following special characteristic codes are used for managing LANSA objects.<br />
LANFLD LANXMLC<br />
LANFIL LANSVAR<br />
LANFLDT LANMVAR<br />
LANPROC LANWEBC<br />
LANFNC LANXMLC<br />
For more information, see “LANSA Integration” on page 328.
Object Codes for DDM Support<br />
Object Codes<br />
<strong>Implementer</strong> supports the management of Distributed Data Management (DDM) software.<br />
For this purpose, you must create three new object codes: DDMDTAA, DDMDTAQ, and<br />
following table.<br />
To create this object code ... copy this object code ... and specify this Object Attribute<br />
DDMDTAA DTAARA DDMDTAARA<br />
DDMDTAQ DTAQ DDMDTAQUE<br />
DDMF PF DDMF<br />
For more information on managing DDM software, see “Using Special Commands to<br />
Manage DDM Software” in the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Object Codes for IFS Objects<br />
<strong>Implementer</strong> provides a variety of default object codes for managing IFS directories and files.<br />
When you need to use an object code that does not exist, you can create an IFS object code the<br />
same as a traditional object code in Work with Object Codes, or you can define <strong>Implementer</strong><br />
to automatically create them when you check out or create a promotion request. The latter<br />
option requires activation in System Control Maintenance as described in “Allow IFS object<br />
code creation from Check Out and Create Rqs” on page 68.<br />
Object codes defined with a special characteristic of PCFILE display the PC file extension<br />
name in the Creation command field. When you display a PCFILE or PCDIR object code, the<br />
Creation command field name changes to IFS Object Extension. When you edit or copy an IFS<br />
object code the field name is Creation command.<br />
Due to the way that <strong>Implementer</strong> matches the object code for files with long extensions to the<br />
short form in the object code, <strong>MKS</strong> recommends you deactivate (rather than delete) obsolete<br />
object codes to ensure the retention of accurate history.<br />
NOTE <strong>Implementer</strong> supports Document Library Objects (DLO) within the IFS and<br />
automatically retains all DLO attributes and characteristics during promotion.<br />
However, because the Move Object (MOV) command used to move QDLS and IFS<br />
objects from the staging directory to the target directory does not support spanning<br />
ASPs, the promotion of QDLS and DLO objects must run in the system Auxiliary<br />
Store Pool (ASP) ASP1.<br />
To define object codes for IFS files and directories<br />
1 Access the Create Object Code panel as described in “Object Codes” on page 127.<br />
An example object code displays next.<br />
135
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
136<br />
2 Define the required fields as follows:<br />
In the Object code field, object codes for files must begin with a dot (.), and can<br />
have a trailing character string. An object code for a directory must have a unique<br />
object code that begins with a backward slash (\). If the directory name has an<br />
extension, define the object code with a backward slash followed by a dot and the<br />
extension, for example, the object code for directory DIR.ONE is \.ONE.<br />
In the Description field, type a description for the object code.<br />
In the Activity flag field, type 1 to activate the object code. Use option 2 to deactivate<br />
the object code. Object codes must be active to use them in <strong>Implementer</strong>.<br />
In the Creation sequence field, specify a number from 1–9999 to identify the order of<br />
creation for this type of object (does not have to be unique per object code). IFS<br />
object codes created by <strong>Implementer</strong> during check out or create request have<br />
creation sequence 8000. IFS files have creation sequence 8010.<br />
In the Special characteristics field, type PCFILE for a file or PCDIR for a directory.<br />
NOTE The Archive in <strong>MKS</strong> Source field defaults to Y for PCFILE or N for PCDIR.<br />
3 Press ENTER to save the changes.<br />
Object Codes for Setting a Data Area Value<br />
<strong>Implementer</strong> provides two object codes that allow you to populate a target data area value<br />
upon promotion of the data area to the target library.
Object Name Rules<br />
The object codes allow you to use a single request to promote to one or more libraries or<br />
systems and retain or replace specific data area values as needed. This is useful, for example,<br />
for a data area that controls the next order number when a new customer needs the data area<br />
value set to a newly distributed value, and an existing customer needs to retain the existing<br />
value.<br />
The object codes for setting a data area value are as follows:<br />
Use object code DTAARA to copy data in the From library to the target library. It has no<br />
special requirements.<br />
Use object code DTAARAR to retain the existing value of a data area in the target library.<br />
It has an the object type *DTAARA and the special characteristic *DTA. The special<br />
characteristic is significant—it controls whether the existing data area value is retained.<br />
You must define the DTAARAR object code with the *DTA special characteristic to<br />
function as described.<br />
Common Questions<br />
Why are object codes necessary? Can’t objects just be compiled into production libraries?<br />
Object codes allow you to consistently and accurately control how <strong>Implementer</strong> creates<br />
objects and updates your production libraries.<br />
Is the creation sequence critical?<br />
Yes. The creation sequence determines the compilation order. For example, the PF object code<br />
should have a lower sequence than the LF object code to allow compiling the physical file<br />
before the logical file.<br />
Object Name Rules<br />
<strong>Implementer</strong> supports the use of rules to control the naming construct of new member/<br />
objects. This allows an administrator to enforce a standard set of naming rules that<br />
developers must follow when creating member/objects in check out.<br />
Object name rules allow for flexibility in member/object naming, and provide for multiple<br />
true conditions using standard Boolean logic. This feature also supports the ability to call<br />
user exit programs.<br />
Name validation is performed on an environment and object code basis, where each<br />
positional group of the object name validates to a position and sequence in the rules<br />
database. If more than one rule exists for a specific position, each rule must have a unique<br />
sequence number. Any additional rules defined after the first rule for a specific position must<br />
specify *AND or *OR to indicate a complex condition.<br />
137
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
138<br />
When you check out a member/object with Action 2=Create, the rules are validated and<br />
enforced. Rule validation occurs in the following order:<br />
1 If the specific object code is not found, then the global object code *ALL is used.<br />
2 If the specific environment is not found, then the global environment *ALL is used.<br />
3 If the object code and environment are not found, then the global rule *ALL/*ALL is<br />
used.<br />
4 If no rules are found, then name validation is bypassed.<br />
If the member/object name breaches the rule, the check out is not allowed and a message<br />
confirms the environment, object code, position, length, and rule used. Additional message<br />
information is available for problem resolution. After correcting any errors, continue with the<br />
check out.<br />
You create and maintain name rules in the Work with Object Name Rules panel. You have<br />
three options for accessing this panel based on how you implement name rules as follows:<br />
specific object codes for specific environments<br />
all object codes for a specific environment<br />
specific object codes for all environments<br />
When maintaining a rule set on the Work with Object Name Rules panel, each current rule is<br />
graphically represented by a value in the Mask field. This represents which rule applies to<br />
each position of the object name.<br />
CAUTION Due to the inherent flexibility within the name rule structure, it is possible<br />
to define a rule that blocks compliance and thereby causes unpredictable results. Be<br />
sure to test all rules before using in production.<br />
Option 1: Specific Object Code for Specific Environment<br />
This option allows you to define name rules that enforce validation of a specific object code<br />
for a specific environment.<br />
To work with name rules for a specific object code and environment<br />
1 From the <strong>Implementer</strong> Menu, select option 42 to access Work with Environments.<br />
2 Select an environment with option 2=Change and press ENTER.<br />
3 Press F8=Object Codes.
Object Name Rules<br />
4 Select an object code with option 7=Work with Object Name Rules, and press ENTER. The<br />
Work with Object Name Rules panel displays.<br />
Use option 2 to edit an existing rule.<br />
Use option 3 to copy a rule.<br />
Use option 4 to delete a rule.<br />
Use option 5 to view rule details.<br />
The Environment, Object Code, and Mask fields display in the upper-left section of the<br />
panel. The mask defines which rules apply to each section of the object name. Creating a<br />
name rule automatically creates a mask. The mask is defined in lower-case letters. Each<br />
letter within the mask name corresponds to a set of rules based on position as follows:<br />
If more than one rule exists for a specific position, each rule must have a unique<br />
sequence number.<br />
Any rules after the first rule for a position must have *AND or *OR specified in the<br />
And/Or field to indicate a Boolean condition.<br />
Overlapping rules is not allowed. Overlapping a new rule with an existing rule<br />
(based on position and length) causes an error message.<br />
Each time you modify a rule, the Mask field updates to reflect the fields added or<br />
removed from the rule set.<br />
Deleting the first rule for a position (And/Or = BLANK) deletes all rules for that<br />
position. Deleting any other rule (And/Or < > BLANK) only deletes that rule. If the<br />
Comparison field value is *CALL, the program calls your external user exit program<br />
with the required parameters.<br />
139
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
140<br />
To add an object name rule<br />
1 Press F6=Add to display the Add Obj Name Rule window.<br />
2 Complete the fields as described in the following table and press ENTER. The Object<br />
Name Rules panel displays.<br />
Field Description<br />
Add Object Name Rules Field Descriptions<br />
Position Specify the starting position of the object name portion to validate. Valid values<br />
are 1–10 (standard OS/400 object length).<br />
Length Specify the length of the object name portion to validate. Valid values are 1–10<br />
(standard OS/400 object length). The length cannot overlap an existing rule.<br />
Sequence Specify the sequential order to process the name rules. Valid values are 1–999.<br />
And/Or (Optional) Specify a logical operator between two expressions. Valid values are<br />
BLANK in the first rule for a position, and *AND or *OR in subsequent rules.<br />
Comparison Specify a logical operator that compares a portion of the object name to the value<br />
specified in the Value field. Valid values are *EQ, *NE, *LT, *LE, *GT, *GE, or<br />
*CALL (user exit program).<br />
For *CALL, the Comparison field user exit program parameters to define are:<br />
Environment: (10,a)<br />
Object Code: (7,a)<br />
Name Section: (10,a) The contents of the object name (starting position for the<br />
specified length).<br />
Return Code: (1,a) Set the return code in the user program to 1 for a valid<br />
object name or 0 for an invalid object name. If the program ends in error,<br />
<strong>Implementer</strong> assumes the value is invalid.
Field Description<br />
Add Object Name Rules Field Descriptions<br />
Option 2: All Object Codes for a Specific Environment<br />
Object Name Rules<br />
Value Specify a value to compare to the logical operator defined in the Comparison<br />
field. Valid values are a constant value (no quotes), a special value (see special<br />
values listed next), or a user exit program (see user exit program parameters<br />
listed for Comparison). The special values valid for the comparison values *EQ<br />
and *NE are:<br />
*NUM: Generic numeric value.<br />
*ALPHA: Generic alphanumeric value.<br />
*BLANK: Generic blank value.<br />
Deleting the first rule for a position (And/Or = BLANK) deletes all rules for that<br />
position. Deleting any other rule And/Or < > BLANK) deletes only that rule. If the<br />
Comparison field value is *CALL, the program calls your external user exit<br />
program with the required parameters.<br />
This option allows you to define name rules that enforce validation for all active object codes<br />
for a specific environment.<br />
To work with name rules for all object codes for a specific environment<br />
1 From the <strong>Implementer</strong> Menu, type 42 and press ENTER to access Work with<br />
Environments.<br />
2 Select an environment with option 2=Change, and press ENTER. The Change<br />
Environment panel displays.<br />
3 Press F18=Name Rules. The Work with Object Name Rules panel displays. The Object<br />
Code field displays the default value *ALL, indicating all object codes specific to this<br />
environment.<br />
4 Press F6=Add. The Add Object Name Rule window displays.<br />
5 Complete the fields as described in “Add Object Name Rules Field Descriptions” on<br />
page 140.<br />
6 Press ENTER. The Object Name Rules panel displays.<br />
Option 3: Specific Object Code for All Environments<br />
This option allows you to define name rules that enforce validation of a specific object code<br />
active to all environments.<br />
141
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
142<br />
To work with name rules for a specific object code for all environments<br />
1 From the <strong>Implementer</strong> Menu, type 44 and press ENTER to access Work with Object<br />
Codes.<br />
2 Select an object code with option 2=Change, and press ENTER.<br />
3 Press F18=Name Rules. The Work with Object Name Rules panel displays. The<br />
Environment field displays the default value *ALL, indicating specific object codes for all<br />
environments.<br />
4 Press F6=Add. The Add Object Name Rules window displays.<br />
5 Complete the fields as described in “Add Object Name Rules Field Descriptions” on<br />
page 140.<br />
6 Press ENTER. The Object Name Rules panel displays.<br />
Project-based Application Paths<br />
<strong>Implementer</strong> uses application paths in the development cycle to define the flow of members/<br />
objects between environments. <strong>Implementer</strong> also uses application paths to determine the<br />
location of source and related objects for an object, for example, when compiling with a check<br />
out or create request action of recompile.<br />
The application path provides control by restricting access so members/objects cannot move<br />
outside of the defined flow. It also allows defaulting the From environment and target<br />
environment values when checking out and creating a promotion request.<br />
You can define an application path at the environment level or project level. Each path can<br />
have a standard and an emergency path that a member/object follows from the time it is<br />
checked out to the time it is promoted back into production.<br />
Functionally, environment paths and project paths are identical, but certain business<br />
situations make it more practical to use a project path. For example, two active projects in<br />
development typically use different environment paths. By using a project path instead of an<br />
environment path, you can avoid performing excessive overrides when checking out and<br />
promoting items associated with one project that are not associated with the other project.<br />
Project paths are beneficial when your development model consists of multiple test<br />
environments, particularly when the test environments are determined on a project-byproject<br />
basis.<br />
Key Considerations<br />
In check out and create request a project path overrides an environment path. In other<br />
words, if a project with a defined path is specified, the project path is followed;<br />
otherwise, the environment path is followed. For details, see page 101.
Project-based Application Paths<br />
You can specify an environment group on a project path. For details, see “Environment<br />
Groups” on page 125.<br />
You must define the project path to the project before using it in <strong>Implementer</strong>.<br />
You cannot delete an environment that is defined on a project path.<br />
When copying or deleting a project also copies or deletes the related path records.<br />
For customers using the <strong>Implementer</strong> and <strong>MKS</strong> Source integration, project paths are not<br />
available when using the Export to <strong>Implementer</strong> (ISIEXPORT) command. For details, see<br />
“<strong>Implementer</strong> and <strong>MKS</strong> Source Integration” on page 259.<br />
A user must have authority to override both standard and emergency paths to override a<br />
default project path when performing standard and emergency functions. These<br />
authorities are defined in Work with Users.<br />
The administrator usually performs this task. Adding or changing a project path<br />
requires authority to project maintenance and authority to host environment<br />
maintenance.<br />
To define a standard or emergency path for a project<br />
1 From the <strong>Implementer</strong> Menu, type option 15, Work with Projects, and press ENTER.<br />
The Work with Projects panel displays.<br />
2 Type option 17=Standard Path, or option 18=Emergency Path next to the project and<br />
press ENTER. The Environment Path panel displays.<br />
3 To add a new path entry, press F6=Add. The Add Path Entry panel displays. The Project<br />
field displays the name of the project you selected on the previous panel.<br />
143
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
144<br />
4 Complete this panel as follows:<br />
In the Sequence number field, specify a the number that represents the sequence<br />
order in relation to the other entries on the default project path. Create sequences<br />
with sufficient numeric space in between to allow adding future sequences without<br />
having to alter each sequence on the path, for example, use sequence 10, 20, and 30.<br />
In the Entry field, specify the name or parameter of the library or environment.<br />
*USRPRF: Entry defaults from the user profile for both check out environment<br />
or library, and target environment or target environment group.<br />
Development library: Specify the name of the development library. This is the<br />
target library in check out.<br />
Environment: Specify the name of the *PRD, *TST, or *QAC environment. Can<br />
be the From or target environment in check out or create request. Use F4=List to<br />
select from the Select Environment list.<br />
Environment group: Specify the name of the environment group. This is the<br />
target environment group when creating a request.<br />
The Entry type field, is a display-only field that automatically defaults after you<br />
create the sequence.<br />
Lib is a development library.<br />
*PRD is a production environment or primary environment of a target<br />
environment group.<br />
*TST is a development environment.<br />
*QAC is a quality assurance or test environment.<br />
5 When finished, press ENTER to add the record. The panel remains open for the entry of<br />
additional records. Press F12 to return to the Standard Project Path panel with the new<br />
path records listed in sequential order.<br />
User-Defined PDM Options<br />
<strong>Implementer</strong> allows you to create IBM Programming Development Manager (PDM) options<br />
to perform check out and create promotion request functions directly from within PDM.<br />
You typically perform this task once to set up the user-defined options, although you can<br />
perform the function any time thereafter as it does not have the interdependencies that some<br />
of the other setup tasks have.
To view sample PDM options<br />
1 From the PDM Work with Members panel, press F18=Change defaults.<br />
Issue or Design Request Stamping<br />
To view the example PDM options, set the Option file on the Change Defaults panel as<br />
follows:<br />
Option File IMPDMOPT<br />
Library <strong>MKS</strong>IM<br />
Member IMPDMOPT<br />
2 Press ENTER.<br />
3 Press F16=User options to view the <strong>Implementer</strong> options interface.<br />
Sample PDM options for the check out and create request functions are included. The<br />
default option names are CO (check out) and CR (create request). You can name the<br />
user-defined options as needed when adding them directly to your PDM options file.<br />
These options use the ICHKOUT and ICRTRQS commands respectively.<br />
TIP Many customers use the CO option to check out individual members in PDM,<br />
but use the Create Request menu option because it is easier to select objects.<br />
Common Questions<br />
Can you copy PDM options from IMOPT directly into a PDM options file with the Copy File (CPYF)<br />
command?<br />
No. PDM does not properly order your options in the options file when you do this. You<br />
must manually add them into your standard PDM options file.<br />
Issue or Design Request Stamping<br />
<strong>Implementer</strong> allows you to stamp objects with the issue or design request number the object<br />
was checked out for. This provides an audit trail that ties each object change back to the issue<br />
or DR that requested the change. With similar information available in the corresponding<br />
issue or DR, you have a complete circle of cross-references and auditable information for<br />
every software change.<br />
To ensure the stamping of both new and existing objects, the process automatically occurs in<br />
the three functions that support object creation: check out, compiling from the Workbench,<br />
and promotion. During these development stages, <strong>Implementer</strong> updates the description of<br />
the object by recording the issue or DR number in the PTF Number attribute. If multiple locks<br />
exist with multiple issues or DRs, the object is stamped with the primary number associated<br />
with the initial lock. For inquiry, use the Display Object Description (DSPOBJD) command to<br />
view the PTF Number attribute.<br />
145
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
146<br />
For information on using object version stamping in check out and promotion, see the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
NOTE Due to IFS constraints, <strong>Implementer</strong> does not support stamping issue or DR<br />
numbers directly to IFS objects. However, for inquiry and reporting through<br />
<strong>Implementer</strong>, the information is available in the repository.<br />
To set up issue or DR object stamping<br />
1 From the <strong>Implementer</strong> Menu, type option 45, System Control, and press ENTER. The<br />
System Control Maintenance panel displays.<br />
2 Press PAGE DOWN three times.<br />
3 In the Activate issue object stamping field, specify Y to activate this feature. For more<br />
information on this field, see “Activate object version stamping” on page 70.<br />
4 Press ENTER to process the change.<br />
Object Version Stamping<br />
<strong>Implementer</strong> allows you to stamp objects, lock records, and repository records with a version<br />
number at pre-determined stages within the development cycle. This provides an audit trail<br />
that allows you to track every version of an object. It also allows you to identify specific<br />
information about deployed objects under change control.<br />
The version number scheme and development stage the object is stamped in, either<br />
check out, check out and promotion, or user-defined, is determined by the versioning method<br />
you define in System Control. <strong>Implementer</strong> automatically increments the version number<br />
based on the versioning method you specify. During the applicable development stage,<br />
<strong>Implementer</strong> updates the description of the object by recording the new revision number in<br />
the APAR ID attribute. The repository record is updated when you run the build list as<br />
described in the next section.<br />
During the build list for a *PRD environment, <strong>Implementer</strong> stamps the version number to the<br />
repository record for each object in the production environment (repository records for *TST<br />
and *QAC environments have a blank version number) as follows:<br />
If the object has a valid version number, then <strong>Implementer</strong> assigns that version to the<br />
repository record. For details, see “Environment Repository Build” on page 117.<br />
If the object does not have a version or has an invalid version, then <strong>Implementer</strong> assigns<br />
the version number 1 or 1.0 (based on the defined versioning method) to the repository<br />
record. If a user-defined versioning method is specified, a user exit is allowed for you to<br />
set the version number.
Object Version Stamping<br />
For inquiry, use the Display Object Description (DSPOBJD) command to view the APAR ID<br />
attribute. In addition, you can display an object’s revision number in the Revision field on the<br />
Workbench (F11=Display Revision) and Work with Objects (F10=Display Revision) panels.<br />
NOTE<br />
Due to IFS constraints, <strong>Implementer</strong> cannot stamp version numbers directly to<br />
IFS objects. However, for inquiry and reporting through <strong>Implementer</strong>, the<br />
information is available in the repository.<br />
<strong>Implementer</strong> disregards source-only objects during version number processing.<br />
The build does not stamp actual objects—only development activity does this.<br />
To set up object version stamping<br />
Versioning Methods<br />
1 From the <strong>Implementer</strong> Menu, type option 45, System Control, and press ENTER. The<br />
System Control Maintenance panel displays.<br />
2 Press PAGE DOWN three times.<br />
3 In the Activate object version stamping field, type Y to activate the feature. For more<br />
information on this field, “Activate object version stamping” on page 70.<br />
4 In the Assign native version number at field, specify the versioning method as follows:<br />
1 = checkout only. For details on this method, see “Method 1: Assign Version in<br />
Check Out” on page 148.<br />
2 = checkout and promotion to production environments. For details on this<br />
method, see “Method 2: Assign Version in Check Out and Promotion” on page 148.<br />
3 = user defined. For details on this method, see “Method 3: User-Defined Version”<br />
on page 149.<br />
5 Press ENTER to process the change.<br />
<strong>Implementer</strong> supports three native versioning methods. The first two methods are defined in<br />
<strong>Implementer</strong>; the third method allows you to implement your own user-defined routine.<br />
NOTE If you have <strong>MKS</strong> Source integration enabled, then the native revision number<br />
scheme applies only to objects and items not archived in <strong>MKS</strong> Source. The version<br />
number is assigned during promotion to the first *QAC environment enabled for<br />
<strong>MKS</strong> Source archiving. If <strong>MKS</strong> Source integration is not enabled, then the native<br />
revision number scheme applies to all items.<br />
147
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
148<br />
Method 1: Assign Version in Check Out<br />
This method implements a whole numbering scheme (no decimal), for example:<br />
Version 1<br />
Version 2<br />
Version 3<br />
Version 4<br />
With this method, <strong>Implementer</strong> assigns the version number when an object is checked out for<br />
create or change, and when rejected from a *QAC environment. Each time the object is<br />
checked out, the number increments by one.<br />
Scenario Example<br />
Object A in *PRD environment is version 2. Object A is checked out to *TST<br />
environment. Object A in *PRD is still version 2. Object A in *TST is now version 3.<br />
Object A version 3 is promoted to *QAC environment.<br />
Object A is concurrently checked out to *TST environment, making it version 4. Object A<br />
in *PRD is still version 2. Object A in *QAC is still version 3.<br />
Object A version 4 is promoted to *QAC environment. Object A now has two lock<br />
records in the *QAC environment—one is version 3, and the other is version 4.<br />
Object A version 4 in *QAC is promoted to *PRD. Object A in *PRD environment is now<br />
version 4.<br />
Method 2: Assign Version in Check Out and Promotion<br />
This method implements a decimal numbering scheme with numbers left and right of the<br />
decimal, for example:<br />
Version 2.0<br />
Version 2.1<br />
Version 2.2<br />
Version 3.0<br />
With this method, <strong>Implementer</strong> assigns the version number when an object is checked out for<br />
create or change, when promoted to production environments, and when rejected from a<br />
*QAC environment. When the object is checked out (including concurrent check out) the
Object Version Stamping<br />
number to the right of the decimal increments by one. When promoted to production, the<br />
number to the left of the decimal increments by one and the number to the right of the<br />
decimal resets to zero.<br />
NOTE Promoting without locks causes the version number to increment only when<br />
the object is promoted to a *PRD environment.<br />
Scenario Example<br />
Object A in *PRD environment is version 2.0. Object A is checked out to *TST<br />
environment. Object A in *PRD is still 2.0. Object A in *TST is version 2.1.<br />
Object A version 2.1 is promoted to *QAC environment.<br />
Object A is concurrently checked out to *TST environment, making it version 2.2.<br />
Object A in *PRD is still version 2.0. Object A in *QAC is still version 2.1.<br />
Object A version 2.2 is promoted to *QAC environment. Object A now has two lock<br />
records in the *QAC environment—one is version 2.1 and the other is version 2.2.<br />
Object A version 2.2 in *QAC is promoted to *PRD. Object A in *PRD environment is<br />
now version 3.0.<br />
Method 3: User-Defined Version<br />
You can define a program with a versioning scheme of up to 30 characters, which is the<br />
length of the Revision field that displays on various panels in <strong>Implementer</strong>. However,<br />
because the field updated in the actual object description is only seven characters long, only<br />
the first seven characters of the version number are recorded in the object’s description. Thus,<br />
to update the object description parameter on the actual object, define your program with a<br />
number scheme of seven characters or less. To apply object versioning without actual object<br />
stamping, the versioning scheme can be up to 30 characters.<br />
The versioning program must exist in the same library on all host and remote systems. If the<br />
program references objects, for example, files or data areas, the library containing the objects<br />
must be in the user’s interactive library list and in the library list of the <strong>Implementer</strong> job<br />
description MWIJOBD.<br />
Define your versioning program with an entry parameter group as described next.<br />
Parameter Length Description<br />
Description 512, alpha Data passed into the versioning program. See format<br />
requirements in the next table.<br />
Version Number 30, alpha Parameter the version number is returned in.<br />
Return Value 10, alpha Returns blanks if no errors occur. If a value is returned, the<br />
version number is ignored.<br />
149
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
150<br />
where the format of the Description parameter is as follows:<br />
Description Parameter<br />
Field Format<br />
The following tables describe the events that trigger the user-defined object versioning<br />
program and the parameter values passed at each trigger point.<br />
Trigger Point: Build List<br />
Triggers when the Build List is run for a *PRD environment.<br />
passed version number = *Blanks<br />
values for P@Data<br />
Valid Values<br />
Start<br />
Position<br />
From Environment environment name 1 10<br />
To Environment environment name 11 20<br />
From Environment Type *PRD, *QAC, or *TST 21 24<br />
To Environment Type *PRD, *QAC, or *TST 25 28<br />
Object object name 29 38<br />
Object Code environment name 39 45<br />
Function see Trigger Points listed next 46 55<br />
Action 1=Change, 2=Create, or 3=Recompile 56 56<br />
PRD Environment production environment name 57 66<br />
PRD Library production library name 67 76<br />
Description Parameter Field Parameter Value Passed<br />
From Environment *Blank<br />
To Environment Build List environment name<br />
From Environment Type *Blank<br />
To Environment Type *PRD<br />
Object Object name<br />
Object Code Object code<br />
Function '*BUILD'<br />
Action *Blank<br />
PRD Environment Build List environment name<br />
PRD Library Build List environment object library<br />
End<br />
Position
Trigger Point: Check Out<br />
Object Version Stamping<br />
Triggers when loading the subfile for the Check Out panel, loading the Check Out panel, and<br />
calling to retrieve the next valid version number. Program called any time ENTER or<br />
F9=Accept is pressed.<br />
passed version number = Subfile value<br />
values for P@Data<br />
Description Parameter Field Parameter Value Passed<br />
From Environment Check out FROM environment<br />
To Environment Check out TO environment<br />
From Environment Type FROM environment type<br />
To Environment Type TO environment type<br />
Object Object name<br />
Object Code Object code<br />
Function '*CO-RTV'<br />
Action Value of Action field in the subfile<br />
PRD Environment *PRD environment of FROM environment<br />
PRD Library *Blanks<br />
Trigger Point: Check Out<br />
Triggers when you enter the value for revision number. Program called to validate the<br />
specified version number.<br />
version number = Subfile value<br />
values for P@Data<br />
Description Parameter Field Parameter Value Passed<br />
From Environment Check out FROM environment<br />
To Environment Check out TO environment<br />
From Environment Type FROM environment type<br />
To Environment Type TO environment type<br />
Object Object name<br />
Object Code Object code<br />
Function '*CO-VLD'<br />
Action Value of the Action field in subfile<br />
151
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
152<br />
Description Parameter Field Parameter Value Passed<br />
PRD Environment *PRD environment of FROM environment<br />
PRD Library *Blanks<br />
Trigger Point: ICHKOUT and ICHKOUTIFS Commands<br />
Triggers when using the ICHKOUT and ICHKOUTIFS commands. Program called once to<br />
verify if object version stamping is active and to retrieve the next valid version number.<br />
passed version number = *Blanks<br />
values for P@Data<br />
Description Parameter Field Parameter Value Passed<br />
From Environment From environment<br />
To Environment To environment<br />
From Environment Type From environment type<br />
To Environment Type To environment type<br />
Object Member/Object name<br />
Object Code Object code<br />
Function '*CO-RTV'<br />
Action Value of the Action field in subfile<br />
PRD Environment *PRD environment of FROM environment<br />
PRD Library *Blanks<br />
Trigger Point: Create Request and ICRTRQS Command<br />
Triggers in create request and when using the ICRTRQS command. Program called once to<br />
verify if object version stamping is active and to retrieve the next valid version number.<br />
passed version number = *Blanks<br />
values for P@Data<br />
Description Parameter Field Parameter Value Passed<br />
From Environment From environment<br />
To Environment To environment<br />
From Environment Type From environment type<br />
To Environment Type To environment type<br />
Object Member/Object name
Description Parameter Field Parameter Value Passed<br />
Object Code Object code<br />
Function '*PROMOTE'<br />
Action Value of the Action field in subfile<br />
Considerations With OS/400 and <strong>Implementer</strong><br />
Considerations With OS/400 and <strong>Implementer</strong><br />
PRD Environment *PRD environment of FROM environment<br />
PRD Library *Blanks<br />
This section covers iSeries system information as it relates to <strong>Implementer</strong> and <strong>Implementer</strong><br />
Receiver.<br />
Operating System Upgrades<br />
The following considerations apply to installing a new release of the OS/400 operating<br />
system. No special considerations are required for PTF installation.<br />
Before you upgrade to a new release of the operating system, contact your distributor or<br />
<strong>MKS</strong> Customer Care to determine any impact the new release may have on your version<br />
of <strong>Implementer</strong>. At publication of this guide, <strong>Implementer</strong> required no changes for<br />
compatibility with the versions of OS/400 currently supported.<br />
If you use <strong>Implementer</strong> Receiver to distribute changes to a remote system, you may have<br />
changed communication entries when you initially installed <strong>Implementer</strong>. After the<br />
operating system upgrade, you must verify and reapply the changes as needed—this<br />
step is frequently overlooked.<br />
By default, an OS/400 upgrade does not retain the <strong>Implementer</strong> communication entry<br />
because the default communications subsystem QCMN is in library QSYS, and the<br />
objects in library QSYS are replaced during the operating system upgrade/installation.<br />
Before the upgrade, you can move subsystem QCMN to another library such as QGPL,<br />
or after installing the new release, you must reapply the communications entry to the<br />
QCMN subsystem.<br />
If you upgrade the host system to a release level later than the release level of the remote<br />
system, verify <strong>Implementer</strong> is set up to distribute using the previous release support<br />
feature of OS/400. To do this, in <strong>Implementer</strong>’s Network Configuration, change the<br />
target release to the version of the operating system on the remote system. To determine<br />
the previous versions the host OS/400 version allows, verify the allowed values for the<br />
Target Release (TGTRLS) parameter on the Restore Library (RSTLIB) command.<br />
153
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
Changing the System Name<br />
154<br />
The name of the host system is stored in the <strong>Implementer</strong> database. If you change the OS/400<br />
system name, for example, to use a descriptive name other than that delivered with the<br />
system, you must make the corresponding change in <strong>Implementer</strong>.<br />
To change the host system name, use <strong>Implementer</strong> Menu option 46, Network<br />
Configuration, which lists the host system and each remote system for distribution. Add<br />
the new system and specify the new OS/400 system name (use the OS/400 Display<br />
Network Attributes (DSPNETA) command to verify). Delete the obsolete system name.<br />
For details, see “Network Configuration” on page 167.<br />
In Work with Environments, you must also change each environment defined as a local<br />
environment to reflect the new host system name. For details, see “Environments” on<br />
page 81.<br />
NOTE The system name <strong>Implementer</strong> uses for the remote system is the OS/400<br />
remote location name, not the remote system name. Thus, changing the OS/400<br />
system name of the remote system does not require a change to <strong>Implementer</strong>.<br />
System Library List Requirements<br />
Do not place the <strong>Implementer</strong> product library (<strong>MKS</strong>IM is the default library name) or the<br />
<strong>Implementer</strong> Receiver library (<strong>MKS</strong>IR is the default library name) on the system library<br />
list. <strong>Implementer</strong> does not work correctly if these libraries are on the system library list.<br />
For C ‘#include’ members and externally defined files, you must manually maintain the<br />
<strong>Implementer</strong> database file IMSYSLIB. The file consists of one field for library entries.<br />
You must specify any system libraries that contain header file ‘#include’ members that<br />
are used for C development. When ‘#include’ statements are found in a C source<br />
member, <strong>Implementer</strong> determines if the ‘#include’ member exists in this list of system<br />
libraries in IMSYSLIB. If the ‘#include’ member is located in the header file in any of the<br />
system libraries specified in this file, the ‘#include’ member is not handled as a related<br />
object within <strong>Implementer</strong>.<br />
Independent Auxiliary Storage Pools<br />
<strong>Implementer</strong> supports using Independent Auxiliary Storage Pools (IASPs) to manage objects.<br />
An IASP is a DASD grouping mechanism similar to a normal ASP in that it defines an<br />
individual storage device, but unlike a normal ASP, an IASP can be activated and deactivated<br />
on demand. An IASP can also be shared between multiple systems and logical partitions<br />
(LPARs) through high speed networking, allowing DASD utilization on a single system or<br />
shared between multiple systems.
Web-based Development for IFS Objects<br />
When used on a single system, the storage defined by the IASP can be activated and<br />
deactivated within a job; however, only one primary ASP can be active at a time. If a job<br />
switches from one IASP to another, the libraries that reside in the first IASP are no longer<br />
available. When used on multiple systems, the storage defined by the IASP can be accessed<br />
by all systems simultaneously, as if it was local.<br />
<strong>Implementer</strong> moves objects between IASPs similar to how it moves objects between standard<br />
ASPs. Although IASPs support multiple libraries with the same name in different IASPs,<br />
<strong>Implementer</strong> associates a named ASP device with the environment.<br />
Key Considerations<br />
This feature requires OS/400 V5R2 or later.<br />
<strong>Implementer</strong> on the host system and <strong>Implementer</strong> Receiver on a remote system must be<br />
in a normal system ASP, for example, ASP 1–32), to ensure each is available regardless of<br />
which IASP is active.<br />
The IASP that <strong>Implementer</strong> moves objects to or from must be active when each process<br />
starts. Use the VRYCFG command to start or end an IASP. <strong>Implementer</strong> does not<br />
manage, start, or end IASPs.<br />
When moving objects, all activity occurs to and from a single IASP. <strong>Implementer</strong> does<br />
not support moving objects from one IASP to another IASP.<br />
Before checking out or promoting to or from an IASP environment, you must issue the<br />
Set ASP Group (SETASPGRP) command. If your shop is already working with IASPs,<br />
this is likely already configured, for example, as part of the daily system startup routine<br />
or handled through a job scheduler (the administrator can confirm this).<br />
The SETASPGRP command syntax is as follows:<br />
SETASPGRP ASPGRP(xxxxxxx)<br />
Where xxxxxxx is the name of the ASP group.<br />
Web-based Development for IFS Objects<br />
<strong>Implementer</strong> allows you to efficiently manage the software changes of all objects that reside<br />
on the iSeries system. This includes support for the development of your client/server and<br />
e-Business applications, as well as the check out and promotion deployment of IFS objects<br />
using a Web browser interface.<br />
This browser-based integration is built on the existing proven framework of <strong>Implementer</strong><br />
technology and includes the latest support for IBM HTTP Web servers: the original Web<br />
Server for iSeries and the Apache Web Server for iSeries. It also supports using <strong>MKS</strong> Integrity<br />
issues or DesignTracker DRs when performing the change management functions.<br />
155
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
Requirements<br />
156<br />
The requirements for using Web-based development are as follows:<br />
<strong>Implementer</strong> <strong>2006</strong>.<br />
The *PRD, *TST, and *QAC environments that manage IFS development must be<br />
defined in <strong>Implementer</strong> with the IFS directory path, path owner, and IFS object owner.<br />
In addition, the *PRD environment must have a standard application path. For details on<br />
environment setup, see page 81.<br />
Internet Explorer 4.0 or later, or Netscape 4.5 or later.<br />
Using the original Web Server for iSeries requires OS/400 V5R1 or later.<br />
Using the Apache Web Server for iSeries requires:<br />
O/S 400 V5R1 or later.<br />
Knowledge of the Apache Web Server for iSeries configuration and operations.<br />
Access to the httpd.conf configuration file for the Apache Web Server instance to<br />
configure.<br />
iSeries Web Server Setup<br />
The <strong>Implementer</strong> Web interface supports using either of the IBM HTTP Web servers: the<br />
original Web Server for iSeries or the Apache Web Server for iSeries. You must configure the<br />
Web interface to use one of these servers. If using the Apache Web Server for iSeries, see<br />
page 158 for further instructions.<br />
Original Web Server for iSeries Setup<br />
The OS/400 HTTP configuration file defines what a Web browser is able to access on your<br />
iSeries using the original Web Server for iSeries. The system administrator or a user that is<br />
authorized to and familiar with the following functions must modify the TCP/IP HTTP<br />
configuration file as follows:<br />
Define server-based security protection based on the OS/400 user profile and password.<br />
Enable three method directives.<br />
Define mapping directives for the location of the <strong>Implementer</strong> interface programs.<br />
Stop and restart the HTTP Server.<br />
IMPORTANT Only one server at a time can be listening on a specified port. You can<br />
simultaneously run more servers on a single system, but each server must listen on a<br />
unique port.
To access the HTTP configuration file<br />
Web-based Development for IFS Objects<br />
Issue the Work with HTTP Configuration (WRKHTTPCFG) command as follows. You must<br />
have authority to the command to edit the file.<br />
WRKHTTPCFG CONFIG<br />
To implement server-based security protection<br />
Within the HTTP Configuration file, add the following server protection directives. <strong>MKS</strong><br />
recommends you add the server directive entries near the beginning of the file.<br />
#Protect the Web interface program<br />
Protection IM {<br />
PasswdFile %%SYSTEM%%<br />
ACLOverride Off<br />
Mask All@*<br />
AuthType Basic<br />
ServerID <strong>Implementer</strong><br />
UserID %%SERVER%%<br />
}<br />
Protect /cgi-bin/imweb IM<br />
To enable the method directives<br />
Within the configuration file, enable the GET, HEAD, and POST method directives as follows:<br />
# ***METHOD DIRECTIVES***<br />
Enable GET<br />
Enable HEAD<br />
Enable POST<br />
To define the mapping directives<br />
The browser integration requires an entry in the configuration file to establish the directory<br />
location of your <strong>Implementer</strong> interface programs. If you installed the HTTP Server when you<br />
installed the iSeries system, IBM supplied a default and a sample HTTP configuration file<br />
already configured and enabled. In this case, you may need to change the default settings<br />
rather than add new ones.<br />
The default location is the <strong>Implementer</strong> product library <strong>MKS</strong>IM. Specify <strong>MKS</strong>IM unless the<br />
library name was changed when <strong>Implementer</strong> was installed.<br />
Add the following mapping directive to the configuration file:<br />
# ***MAPPING DIRECTIVES***<br />
Exec/cgi-bin/* /QSYS.LIB/<strong>MKS</strong>IM.LIB/*.PGM %%EBCDIC%%<br />
157
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
158<br />
To stop and restart the TCP/IP server<br />
To display your page through the Web browser, the TCP/IP HTTP server must be active.<br />
You must stop and restart the server for it to recognize the <strong>Implementer</strong> CGI programs.<br />
1 Issue the End TCP/IP Server (ENDTCPSVR) command and change the parameters as<br />
required for your configuration.<br />
2 Once the server job ends, issue the Start TCP/IP Server (STRTCPSVR) command and<br />
change the parameters as required for your configuration.<br />
3 To verify the server is active, use the Work with Active Jobs (WRKACTJOB) command<br />
and press PAGE DOWN to access the QHTTPSVR Server subsystem job.<br />
There should be multiple instances of the server job running under user profile<br />
QTMHHTTP. The first instance is a batch job. The remaining instances are the batch<br />
immediate (BCI) jobs.<br />
The number of active jobs depends upon the HTTP attributes, a value set by the Change<br />
HTTP Attributes (CHGHTTPA) command.<br />
TIP You can automate this process by adding the job to an existing OS/400 start up<br />
routine, or by changing the HTTP attributes to start the server automatically.<br />
You can now use the Web interface for IFS development. For details, see the <strong>MKS</strong> <strong>Implementer</strong><br />
<strong>2006</strong> User <strong>Guide</strong>. The next section describes setting up the Apache Web Server configuration.<br />
Apache Web Server for iSeries Setup<br />
The httpd.conf configuration file defines what a Web browser is able to access on your<br />
iSeries using the Apache Web Server for iSeries.<br />
The system administrator or a user that is authorized to and familiar with the server’s<br />
configuration and operations must use the Edit File (EDTF) command to modify the<br />
httpd.conf configuration file for the Apache Web Server instance to be configured.<br />
NOTE For details on the Apache Web Server, refer to the IBM documentation<br />
located at http://httpd.apache.org/docs-2.0/.<br />
To edit the configuration file<br />
1 Issue the following command to access the configuration file:<br />
EDTF STMF(’/www/apachedft/conf/httpd.conf’)<br />
IMPORTANT If you are not using the default Apache Web Server configuration file,<br />
replace the STMF parameter with the appropriate configuration file name.
Mounted Drive Support for IFS Objects<br />
2 Add the following directives to the httpd.conf file in the main Web site or virtual host.<br />
TIP Use the cut-and-paste function to your 5250 emulation program instead of<br />
typing the following values.<br />
ScriptAlias /cgi-bin/imweb /qsys.lib/mksim.lib/imweb.pgm<br />
<br />
Options +ExecCGI<br />
CGIConvMode %%EBCDIC/MIXED%%<br />
AllowOverride None<br />
AuthType Basic<br />
ProfileToken off<br />
AuthName <strong>Implementer</strong><br />
order allow,deny<br />
allow from all<br />
require valid-user<br />
UserID %%SERVER%%<br />
PasswdFile %%SYSTEM%%<br />
<br />
NOTE If the <strong>Implementer</strong> product is installed into a library other than <strong>MKS</strong>IM,<br />
replace <strong>MKS</strong>IM with that library name when defining this directive.<br />
3 Press F3=Save/Exit twice to save the file and return to the command line.<br />
4 Restart the server instance.<br />
The server must be active to display your page through the Web browser. You must stop<br />
and restart the server for it to recognize the new configuration directives. For details on<br />
this task, see page 158.<br />
Mounted Drive Support for IFS Objects<br />
<strong>Implementer</strong> provides mounted drive support for managing IFS objects on a system running<br />
Windows NT Server.<br />
Key Considerations<br />
Environments associated with an NT Server mounted drive must have a directory path<br />
entry that begins with \QNTC, for example, \QNTC\<strong>MKS</strong>\PRD\ACCOUNTS_PAYABLE. For<br />
details on defining the directory path, see “Directory Setup Field Descriptions” on<br />
page 94.<br />
To access an NT drive from the iSeries (for example, using WRKLNK) the user profile<br />
used to sign on to the iSeries must exist on the NT Server with the same password.<br />
159
Chapter 3: <strong>Implementer</strong> <strong>Administration</strong><br />
160<br />
<strong>Implementer</strong> uses the profile defined in the SDMAUTUSR data area to access the<br />
NT Server. The default user profile name in the data area is SDMAUTUSR. The data area<br />
is located in the <strong>Implementer</strong> product library (<strong>MKS</strong>IM is the default library name).<br />
The user profile and password defined on the iSeries must be the same profile and<br />
password defined on the NT Server. The user profile and password combination must<br />
be identical to any remote systems that use directories on the mounted NT Server.<br />
Individual profiles are not required on the NT Server for those profiles to access<br />
<strong>Implementer</strong> and manage directories on the NT Server.<br />
<strong>Implementer</strong> user profile SDMAUTUSR is the object owner of IFS objects it promotes to<br />
the NT Server. In addition, the objects inherit the authorities of the target directory<br />
(authorities defined to the environment or existing on the from object are disregarded).<br />
NOTE The Reset Authorities function does not set or change object owners or change<br />
authorities of IFS objects.<br />
Establishing the Communication<br />
NetServer requires a security officer profile to connect to the iSeries. The minimum<br />
requirement is *IOSYSCFG authority to start NetServer.<br />
To establish communications<br />
1 On a PC connected to the host iSeries, select Start > Programs > IBM AS400 Client Access<br />
> AS400 Operations Navigator.<br />
2 In the Primary Environments list, double click the system where <strong>Implementer</strong> is installed.<br />
3 Double click the Network icon.<br />
4 Double click the Servers icon.<br />
5 Double click the TCP/IP icon.<br />
6 Verify the NetServer status is Started. If NetServer is not started, right click NetServer,<br />
and from the menu click Start.
C HAPTER FOUR<br />
Remote Distribution Concepts<br />
and Setup<br />
Configuring <strong>Implementer</strong> for Remote Deployment<br />
4<br />
The distribution features of <strong>Implementer</strong> allow you to deploy changes from one iSeries system to<br />
other iSeries systems, as well as to logical partitions (LPARs).<br />
A variety of options are available to control how to perform distribution. This chapter introduces you<br />
to the <strong>Implementer</strong> Receiver on a remote system, distribution methods and concepts, setting up<br />
communications for distribution, and submitting distribution jobs.<br />
This chapter covers the following topics:<br />
“<strong>Implementer</strong> Receiver” on page 162<br />
“Distribution Methods” on page 164<br />
“Communications Considerations” on page 165<br />
“Network Configuration” on page 167<br />
“Setting Up Communications Entries” on page 169<br />
“Setting Up for TCP/IP Distribution” on page 173<br />
“Setting Up for SNADS Distribution” on page 179<br />
“Distribution Options” on page 180<br />
“Controlling Remote Job Schedules” on page 181<br />
“Distribution Steps” on page 189<br />
“Move Steps” on page 189<br />
“Multiple System Development” on page 189<br />
“Saving and Restoring Remote Tape Archives” on page 192<br />
“Problem Determination” on page 193<br />
161
Chapter 4: Remote Distribution Concepts and Setup<br />
<strong>Implementer</strong> Receiver<br />
162<br />
<strong>Implementer</strong> Receiver is a separately licensed product that runs on a remote iSeries system<br />
and receives software changes from <strong>Implementer</strong> on the host iSeries system. The Receiver is a<br />
subset of the host <strong>Implementer</strong> product. A separate license agreement and license keys are<br />
required for each <strong>Implementer</strong> Receiver to receive changes distributed from the <strong>Implementer</strong><br />
host system.<br />
<strong>Implementer</strong> contains all objects needed to distribute changes to remote systems and LPARs.<br />
The primary activities initiated on the host system are: compile, distribution, and move of a<br />
promotion request, deletion of a promotion request, and the Reset Authorities and Build List<br />
functions. The <strong>Implementer</strong> Receiver allows you to accomplish both host and remote<br />
initiated activities.<br />
The <strong>Implementer</strong> Receiver menu provides access to:<br />
Work with Remote Request panel to inquire, print, and move promotion requests, and<br />
view target environments, related requests, and special commands<br />
Restore Remote Request (IRSTRMTRQS) command to restore distributions from tape<br />
(also accessible from a command line)<br />
Move Remote Request (IMOVRMTRQS) command to complete a remote promotion by<br />
moving the items into target environments (also accessible from a command line)<br />
release management functions<br />
administrative functions<br />
Installation of the <strong>Implementer</strong> Receiver includes steps on both the host and remote systems.<br />
The default <strong>Implementer</strong> Receiver library name is <strong>MKS</strong>IR. If you change this name, you must<br />
also change the RCVLIB data area in the corresponding host system. If you install the<br />
<strong>Implementer</strong> Receiver into a library other than <strong>MKS</strong>IR, you must manually add that library<br />
name to the top of the library list for the IMPJOBD job description. <strong>Implementer</strong> uses the<br />
IMPJOBD job description when submitting a remote initiated move request.<br />
To activate the <strong>Implementer</strong> Receiver for temporary or permanent use, you must use the<br />
<strong>MKS</strong> Security Reset (RESET) command on the remote system to enter the license keys sent<br />
with your contract or in a separate letter. If you do not have valid license keys, contact <strong>MKS</strong><br />
Customer Care.<br />
NOTE For detailed information on installing or upgrading the <strong>Implementer</strong><br />
Receiver, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>.
Integration With Local Promotions<br />
<strong>Implementer</strong> Receiver<br />
A powerful feature in the architecture of <strong>Implementer</strong> is the seamless support for remote<br />
distributions. This means you define environments to <strong>Implementer</strong> and designate whether<br />
the environments are located on local or remote systems (a remote environment must have a<br />
remote system name specified in the environment definition).<br />
Promotions to local and remote systems occur for an environment based on the environment<br />
description; thus, <strong>Implementer</strong>’s distribution features are able to share features with the local<br />
promotions. For example, to distribute a change you create a promotion request, compile the<br />
request, and perform the Move Requests function to distribute the change. This is basically<br />
the same process used to promote to a local environment, meaning you only need to learn<br />
one mechanism for both local and remote promotions. The process supports a single<br />
promotion request promoting members/objects to both local and remote libraries, either by<br />
manually selecting multiple environments, or by using the environment group feature.<br />
Remote System Inventory<br />
<strong>Implementer</strong> maintains a complete inventory of the members and objects distributed to each<br />
remote environment. This information is available on many inquiry panels and reports on the<br />
host system, and includes the following information:<br />
date and time a member/object was promoted to the remote system<br />
assigned project (if using projects)<br />
promotion request details<br />
After initially setting up <strong>Implementer</strong>, you must run the Build List function to analyze the<br />
members/objects in remote environments and load the inventory into the <strong>Implementer</strong><br />
repository on the host system. For details, see “Environment Repository Build” on page 117.<br />
If needed, the Reset Authorities function allows you to set the object owners and authorities<br />
on the remote system as defined for the environment. For details, see “Resetting Authorities”<br />
on page 372.<br />
Remote Source Members<br />
You can specify that source is stored on the remote system for an environment. For example,<br />
you can store source on the remote system for infrequently modified applications when you<br />
do not retain source on the development system, or use it to secure source on a different<br />
system.<br />
Remote source members can be checked out from the remote system and optionally compiled<br />
during promotion on the remote system. This applies to source members that have related<br />
objects, such as source members for files and programs. <strong>Implementer</strong> recognizes source-only<br />
163
Chapter 4: Remote Distribution Concepts and Setup<br />
164<br />
items such as OCL, sort specifications, and text members. This ensures you include and send<br />
source to the remote for environments that have local source, as some applications require<br />
the source members during execution.<br />
NOTE Storing source on the remote only can cause problems for developers when<br />
attempting to browse source members not checked out, and they have restricted<br />
access to the remote system. In this case you can check out the source from the<br />
remote system; <strong>Implementer</strong> creates a temporary DDM file and copies the source<br />
from it.<br />
Consideration for Database Files<br />
<strong>Implementer</strong> avoids problems associated with the distribution of database files to remote<br />
systems. For example, <strong>Implementer</strong> supports promoting logical files without the related<br />
physical file on a request, and ensures that all necessary physical files are duplicated into the<br />
work library so a logical file is never based on a physical file outside of the <strong>Implementer</strong> work<br />
library. The duplicated physical files are not promoted into production so you never have<br />
additional access paths over the production environment. This also ensures successful<br />
distribution and restoration of the logical files to the remote system.<br />
For complex database files, <strong>Implementer</strong> provides the same support on the remote system as<br />
that provided on the local system.<br />
Distribution Methods<br />
<strong>Implementer</strong> supports the distribution of source members and objects on tape or by using<br />
OS/400 communications with SDMCom, TCP/IP, or SNADS. Different distribution methods<br />
can be defined per environment. The following table provides an overview of each<br />
distribution method.<br />
Distribution<br />
Method<br />
Description<br />
SDMCom SDMCom is a feature of <strong>Implementer</strong> that improves performance by 20–35% over<br />
SNADS distribution. Its advanced features use compression algorithms and<br />
blocking specifically for remote distributions.<br />
SDMCom eliminates reliance on SNADS distribution queues, directory entries, and<br />
network files, which helps simplify setup and eliminate the number of potential areas<br />
of distribution failures. For example, SDMCom eliminates concerns of whether<br />
directory entries exist or distribution queues are started. Distribution with SDMCom<br />
is performed directly within the <strong>Implementer</strong> distribution job—it is not sent to a<br />
distribution queue like QSNADS uses.
Distribution<br />
Method<br />
Communications Considerations<br />
APPC Programs<br />
Description<br />
Communications Considerations<br />
TCP/IP TCP/IP is available for both FTP and tape distributions.<br />
You must define the TCP/IP address and port in <strong>Implementer</strong>’s Network<br />
Configuration. You must also define the TCP/IP communications subsystem and job<br />
queue. When you install <strong>Implementer</strong>, the TCP/IP communications subsystem<br />
IMCOM and the communications job queue IMCOM are both created.<br />
TCP/IP must be set up between the host and remote systems. You can add the<br />
Communications Control (ICOMCTL) command to your daily OS/400 startup routine<br />
(for example, the IPL procedure) or start it manually.<br />
SNADS Distribution with SNADS requires creating directory entries on both the local and<br />
remote systems. SNADS must be set up between the two systems. You must define<br />
a distribution queue with the Configure Distribution Services (CFGDSTSRV)<br />
command. You must configure the distribution queue used by <strong>Implementer</strong> to start<br />
distribution when an item is in the distribution queue.<br />
Tape Distribution on tape involves two steps: create the tape on the local system and<br />
restore the tape on the remote system. You can use any OS/400 tape media. To<br />
restore work libraries from a tape at the remote site, use the Restore Remote<br />
Request (IRSTRMTRQS) command, either from the <strong>Implementer</strong> Receiver menu<br />
option or the command line.<br />
DVD Valid only for release management environments. For details, see the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release Management <strong>Guide</strong>.<br />
Before setting up communications for <strong>Implementer</strong> distributions, review the following<br />
information regarding the communication lines and programs supported by <strong>Implementer</strong>.<br />
<strong>Implementer</strong> uses APPC (Advanced Program to Program Communication) programs to start<br />
jobs on a remote system related to remote environments. APPC programs can be referred to<br />
as communications programs or ICF (Intersystem Communications Facility) files. You do not<br />
need this information to use <strong>Implementer</strong>, but it helps to understand how it works.<br />
<strong>Implementer</strong> uses APPC programs as follows:<br />
An APPC program is used during promotion for the distribution and move steps. The<br />
same APPC program is used during the compile step for the environment designated as<br />
having source on the remote system. For remote initiated moves, an APPC program is<br />
used if the remote environment is defined to update the host on remote initiated moves.<br />
In this case, the APPC program updates the host with information regarding the status<br />
of the promotion request, archive information, time stamping for each member and<br />
object and, if specified, job log information.<br />
165
Chapter 4: Remote Distribution Concepts and Setup<br />
166<br />
The Build List function uses an APPC program to retrieve source and object information<br />
from a remote system. Generally, you run a build when you define a new environment.<br />
The Reset Authorities function uses an APPC program to change the owners and<br />
authorities to objects for a remote environment. Generally, you reset authorities when<br />
you define a new environment.<br />
The delete request function (available from a number of different menu options) uses an<br />
APPC program to delete work libraries or SNADS network files that exist on the remote<br />
system. This ensures deleting a promotion request does not leave unwanted source,<br />
objects, work libraries, or network files on the remote system.<br />
Communication Lines<br />
APPN Lines<br />
Switched Lines<br />
<strong>Implementer</strong>’s distribution facilities use LU6.2 protocol, which is also known as APPC.<br />
<strong>Implementer</strong> is independent of the type of APPC line. This means changes can be distributed<br />
over SDLC lines or token ring lines. Changes are not distributed using asynchronous lines,<br />
since this type of line does not support the LU6.2 protocol.<br />
<strong>Implementer</strong> supports lines configured for APPN (Advanced Peer-to-Peer Network) reconnections.<br />
Whereas <strong>Implementer</strong> uses APPC programs, a situation that requires using<br />
APPN for distribution to the remote is when the host system is not directly connected to the<br />
remote. For example, system A connects directly to system B, and system B connects directly<br />
to system C—however, system A does not connect directly to system C. In this case, you<br />
must define the lines using APPN to distribute changes from system A to system C.<br />
The OS/400 operating system provides support for APPN. Use APPN when you define your<br />
network of iSeries systems and specify how remote systems that are not directly connected<br />
route to each other.<br />
<strong>Implementer</strong> supports switched (common carriers) or non switched (leased/dedicated) lines.<br />
If you use switched lines, <strong>Implementer</strong> has the option to vary on and vary off the<br />
communications configuration before and after a distribution to the system. This feature is<br />
particularly useful when you have one switched line shared by multiple systems. Without<br />
this support you would have to vary on and off the communications line, controller, and<br />
device before distributing to a different system sharing the same communications port. In the<br />
Network Configuration menu option, specify the communications line, controller, and device<br />
for <strong>Implementer</strong> to automatically vary on or off.
Network Control Programs<br />
Network Configuration<br />
Network Control Program (NCP) is a software product that runs on an IBM mainframe. NCP<br />
serves as a communications controller between two iSeries systems in a network. This is also<br />
described as using Virtual Telecommunications Access Method (VTAM), IBM’s application<br />
program interface.<br />
<strong>Implementer</strong> users that use NCP must set up communications differently because of certain<br />
communications parameters that are changed by NCP. These parameters are usually set to<br />
the OS/400 defaults by most iSeries users; however, if you use NCP, the following<br />
parameters do not usually use the OS/400 defaults:<br />
remote location name<br />
local location name<br />
mode name<br />
remote network identifier<br />
Find the values for these four parameters on your system by displaying the description of the<br />
APPC device description on the local system that connects to the remote system. Then,<br />
specify the same values for these fields for the remote system in Network Configuration.<br />
Network Configuration<br />
The system-wide communication parameters used by <strong>Implementer</strong> are defined in Network<br />
Configuration, option 46 on the <strong>Implementer</strong> Menu. Network Configuration allows you to<br />
define and maintain information about the remote systems you deploy software changes to<br />
using either SNA or TCP/IP distribution. Establishing a network configuration is only<br />
required if you distribute to remote systems—you must define each remote system you<br />
distribute to in Network Configuration.<br />
If you use TCP/IP for distribution between host and remote systems, you must define the<br />
TCP/IP address and port in Network Configuration. TCP/IP has additional setup<br />
requirements as described in “Setting Up for TCP/IP Distribution” on page 173.<br />
<strong>Implementer</strong> must be installed on the host system and the <strong>Implementer</strong> Receiver must be<br />
installed on each remote system before you establish communications between the systems.<br />
Once the systems are defined in Network Configuration, you can define the environments for<br />
each remote system.<br />
TIP If you have multiple remote environments, consider defining an environment<br />
group to target with all remote distributions.<br />
167
Chapter 4: Remote Distribution Concepts and Setup<br />
168<br />
To add or change a system in Network Configuration<br />
1 From the <strong>Implementer</strong> Menu, type option 46, or type STRIM *NETCFG at the command<br />
line and press ENTER. The Network Configuration Maintenance panel displays.<br />
2 To create a new system, press F6=Add, or to create a system by copying an existing<br />
system, type 3 in the Opt field and press ENTER. To change an existing system, select the<br />
system with option 2=Change and press ENTER.<br />
3 Specify the following fields:<br />
In the System field, type the name of the remote system to distribute to. This field<br />
allows entry only when initially creating the system.<br />
In the Description field, type a system description.<br />
In the Target Release field, specify if the remote system is at an older release of the<br />
operating system than the host system. Specify *CURRENT, *PRV, or the actual<br />
version name.<br />
4 Complete the remaining fields based on the distribution method (SNA or TCP/IP) as<br />
described in the following sections.<br />
NOTE The second and third Network Configuration Maintenance panels are for<br />
SNA distribution. If you intend to use both TCP/IP and SNA communications with<br />
this system, complete both the SNA and TCP/IP fields as required; otherwise leave<br />
one or the other blank.<br />
To configure Network Configuration for SNA distribution<br />
1 Follow the previous steps to create or change the system.<br />
2 On the second Network Configuration Maintenance panel, define the information as<br />
needed. The following steps describe where to find the necessary information:<br />
To determine the system name on the remote system, use the Display Network<br />
Attributes (DSPNETA) command.<br />
To determine the description of the device used to communicate with the remote, on<br />
the host system use the Display Device Description (DSPDEVD) command for:<br />
remote location name<br />
local location name<br />
mode<br />
remote network identifier
Setting Up Communications Entries<br />
3 Press ENTER to access the third Network Configuration Maintenance panel and continue<br />
entering the information.<br />
To determine the description of the communication lines, on the host system use the<br />
Display Line Description (DSPLIND) command for:<br />
attached non switched controllers for the control unit<br />
connection type for the line type<br />
4 Press ENTER to update the changes.<br />
To configure Network Configuration for TCP/IP distribution<br />
If you use TCP/IP for distribution between host and remote systems, complete these steps<br />
for each remote system you distribute to. In addition, if you use the Remote Initiated Move<br />
Update Host feature, you must complete these steps for the host system.<br />
1 Follow the previous steps to create or change the system.<br />
2 From the Network Configuration Maintenance panel, press ENTER twice to display the<br />
fourth Network Configuration Maintenance panel.<br />
3 Complete the fields on this panel as follows:<br />
In the TCP/IP Address field, specify an IP address, a system name in a DNS server,<br />
or a system name in a host table. The default value is blank.<br />
In the Port field, specify a valid number between 1 and 65535. The default number is<br />
30005. <strong>MKS</strong> recommends you use a number higher than 1024 to avoid conflict with<br />
standard services such Telnet, FTP, and Web servers.<br />
The port you define on the host system must match the port defined on the remote<br />
system. The port value must also match the port value you specify in the<br />
Communications Control (ICOMCTL) command you define on both the host and<br />
remote systems as described in “Setting Up for TCP/IP Distribution” on page 173.<br />
4 Press ENTER to update the system record.<br />
Setting Up Communications Entries<br />
<strong>Implementer</strong> uses communications to distribute requests from the host system to one or more<br />
remote systems. You have three options for setting up <strong>Implementer</strong> for communications and<br />
distribution between systems:<br />
use pre-existing communications entries<br />
add communications entries using an existing mode description<br />
add communications entries using an <strong>Implementer</strong>-specific mode description<br />
169
Chapter 4: Remote Distribution Concepts and Setup<br />
170<br />
This section explains the setup procedures for each option. For a comparison of the options,<br />
see “Understanding <strong>Implementer</strong>” on page 9.<br />
Option 1: Using Existing Communication Entries<br />
This option requires no additional setup steps. <strong>MKS</strong> recommends you initially set up<br />
<strong>Implementer</strong> to use an existing communications mode description. When using this<br />
approach, the communications job runs using the <strong>Implementer</strong> user profile MWIPROD.<br />
Option 2: Using an Existing Mode Description<br />
This option requires you to create communications entries using an existing mode<br />
description. It has setup tasks on both the host and remote systems.<br />
Host System Setup<br />
Before starting this task, you must have the name of the communications subsystem on the<br />
host system. This is typically subsystem QCMN and is referred to as qcmn in the following<br />
instructions.<br />
To perform setup on the host system<br />
1 Add a communications entry by issuing the following command:<br />
ADDCMNE SBS(qcmn)<br />
DEV(APPC-device)<br />
JOBD(<strong>MKS</strong>IM/MWIJOBD)<br />
DFTUSR(MWIPROD) MODE(*ANY)<br />
2 Change the device description by issuing the following command:<br />
CHGDEVAPPC DEVD(APPC-device) MODE(existing-modes)<br />
For example, the command for APPC device RMTDEV using mode BLANK is:<br />
CHGDEVAPPC DEVD(RMTDEV) MODE(BLANK)<br />
3 On the host system, issue the following command to change the <strong>Implementer</strong><br />
Communications User (IMCMNUSR) data area value to blanks, which allows using the<br />
communications entry defined next.<br />
CHGDTAARA DTAARA(<strong>MKS</strong>IM/IMCMNUSR)VALUE(' ')<br />
where VALUE is defined by a blank character enclosed in single quotes.<br />
4 In <strong>Implementer</strong> Menu option 46, Network Configuration, change the mode name of the<br />
remote system to the mode you are using.<br />
a) Select the remote system with option 2=Change and press ENTER to display the<br />
Network Configuration Maintenance panel.
Setting Up Communications Entries<br />
b) In the Mode Name field, type the existing mode name and press ENTER.<br />
Remote System Setup<br />
Before starting this task, you must have the name of the communications subsystem on the<br />
remote system. This is normally subsystem QCMN and is referred to as qcmn in the following<br />
instructions.<br />
To perform setup on the remote system<br />
1 Add a communications entry by issuing the following command:<br />
ADDCMNE SBS(qcmn)<br />
DEV(APPC-device)<br />
JOBD(<strong>MKS</strong>IM/MWIJOBD)<br />
DFTUSR(MWIPROD) MODE(*ANY)<br />
2 Change the APPC device description by issuing the following command:<br />
CHGDEVAPPC DEVD(APPC-device) MODE(existing-modes)<br />
For example, the command for existing APPC device RMTDEV using mode BLANK is:<br />
CHGDEVAPPC DEVD(RMTDEV) MODE(BLANK)<br />
Option 3: Using a Specific Mode Description<br />
This option requires creating an <strong>Implementer</strong>-specific communications entry on the host<br />
system. The setup tasks are performed on the host and each remote system.<br />
Host System Setup<br />
Before starting this task, you must have the following information available:<br />
The name of the communications subsystem on the host system. This is normally<br />
subsystem QCMN and is referred to as qcmn in the following instructions.<br />
The name of the APPC device on the host that is used to connect to the remote system.<br />
This is referred to as APPC-device in the following instructions.<br />
The system name of the remote systems you distribute changes to. This is referred to as<br />
remote-system-name in the following instructions.<br />
To perform setup on the host system<br />
1 Add a communications entry by issuing the following command:<br />
ADDCMNE SBS(qcmn)<br />
DEV(APPC-device)<br />
JOBD(<strong>MKS</strong>IM/MWIJOBD)<br />
DFTUSR(MWIPROD) MODE(*ANY)<br />
171
Chapter 4: Remote Distribution Concepts and Setup<br />
172<br />
2 Change the <strong>Implementer</strong> Communications User (IMCMNUSR) data area to blanks by<br />
issuing the following command:<br />
CHGDTAARA DTAARA(<strong>MKS</strong>IM/IMCMNUSR) VALUE(' ')<br />
where VALUE is defined by a blank character enclosed in single quotes. This allows using<br />
the communications entry defined next.<br />
3 Create a mode description on the host system that corresponds to the mode description<br />
on the remote. This allows you to specify the amount of activity needed for<br />
<strong>Implementer</strong>-related activities. Issue the following command:<br />
CRTMODD MODD(IMPMODD) TEXT('<strong>Implementer</strong> Mode')<br />
4 Associate the mode description with the communications subsystem. The default user<br />
profile on the communications entry is the profile that all <strong>Implementer</strong> APPC jobs run<br />
under. You can specify any user profile—a common entry is QUSER.<br />
a) To display the device description and determine the current modes used by the<br />
device, issue the following command:<br />
DSPDEVD DEVD(APPC-device)<br />
b) Change the APPC device description by issuing the following command:<br />
CHGDEVAPPC DEVD(APPC-device)<br />
MODE(existing-modes IMPMODD)<br />
For example, the command for APPC device RMTDEV using mode BLANK is:<br />
CHGDEVAPPC DEVD(RMTDEV) MODE(BLANK IMPMODD)<br />
Remote System Setup<br />
Before starting this task, you must have the name of the communications subsystem on the<br />
remote system. This is normally subsystem QCMN and is referred to as qcmn in the following<br />
instructions. In addition, you must have the name of the APPC device that connects the<br />
remote system to the host. This is referred to as APPC-device in the following instructions.<br />
To perform setup on the remote system<br />
1 Add a communications entry by issuing the following command:<br />
ADDCMNE SBSD(qcmn)<br />
DEV(*APPC)<br />
JOBD(IMPRCV/IMPJOBD)<br />
DFTUSR(MWIPROD)<br />
MODE(IMPMODD)<br />
2 Create a mode description on the remote system that corresponds to the mode<br />
description on the host system. This allows you to specify the amount of activity needed<br />
for <strong>Implementer</strong>-related activities. Issue the following command:<br />
CRTMODD MODD(IMPMODD) TEXT('<strong>Implementer</strong> Mode')
Setting Up for TCP/IP Distribution<br />
3 Associate the mode description with the communications subsystem. The default user<br />
profile on the communications entry is the profile that all <strong>Implementer</strong> APPC jobs run<br />
under. You can specify any user profile—a common entry is QUSER.<br />
a) To display the device description to determine the current modes used by the<br />
device, issue the following command:<br />
DSPDEVD DEVD(APPC-device)<br />
b) Change the APPC device description by issuing the following command:<br />
CHGDEVAPPC DEVD(APPC-device)<br />
MODE(existing-modes IMPMODD)<br />
For example, the command for APPC device RMTDEV using mode BLANK, is:<br />
CHGDEVAPPC DEVD(RMTDEV) MODE(BLANK IMPMODD)<br />
Defining the Host for Remote Initiated Moves<br />
You can configure remote environments set up for remote initiated moves to update the host<br />
with request processing information. This feature requires an additional communications<br />
entry on the host for the remote system to access with the update.<br />
The default user profile on the communications entry is the profile that all <strong>Implementer</strong><br />
APPC jobs run under. You can specify any user profile—a common entry is QUSER.<br />
A variety of methods exist for defining the communications entry. The following instructions<br />
work for most organizations; however, if you use other APPC programs or pass-through<br />
sessions, <strong>MKS</strong> recommends you review the applicability of these instructions to your<br />
installation.<br />
To set up a host communication entry for remote initiated moves<br />
Add a communications entry by issuing the following command:<br />
ADDCMNE SBS(qcmn)<br />
DEV(APPC-device)<br />
JOBD(<strong>MKS</strong>IM/MWIJOBD)<br />
DFTUSR(MWIPROD) MODE(*ANY)<br />
Setting Up for TCP/IP Distribution<br />
<strong>Implementer</strong> supports TCP/IP (Transmission Control Protocol/Internet Protocol)<br />
communication as a method of communication between host and remote iSeries systems.<br />
This technology is available for both FTP (File Transfer Protocol) and tape distribution.<br />
173
Chapter 4: Remote Distribution Concepts and Setup<br />
174<br />
Current TCP/IP technology does not support automatic job initiation on a remote system;<br />
thus, <strong>Implementer</strong> provides the Communications Control (ICOMCTL) command that<br />
initiates a communications subsystem, and daemon and monitor communications programs.<br />
These programs monitor the remote TCP/IP port for <strong>Implementer</strong>-specific requests. The<br />
communications programs remain in an idle state until activity initiated from the host system<br />
activates request processing on the remote system. You can use an <strong>Implementer</strong>-supplied<br />
subsystem or an alternate subsystem. For details on the ICOMCTL command, see<br />
“Communications Control Command” on page 177.<br />
If your network configuration requires FTP transfers using non passive mode, <strong>Implementer</strong><br />
provides the FTP Passive Mode (IMFTPPASV) data area to control how its FTP transfer uses<br />
passive mode when sending files using TCP/IP. Passive mode eliminates the requirement on<br />
the receiving system to open a dedicated port for the host to connect to. Most users do not<br />
need to change this data area. For details, see “FTP Passive Mode (IMFTPPASV)” on<br />
page 405.<br />
Key Considerations<br />
IMPORTANT TCP/IP communications must be set up and working successfully;<br />
other than what is required for <strong>Implementer</strong>, <strong>MKS</strong> does not assume responsibility<br />
for configuring or troubleshooting communications.<br />
To determine if a remote system is accessible (at the most basic level), from the host<br />
iSeries system issue the command PING . If you need<br />
assistance with configuring TCP/IP, see your network administrator.<br />
You must define a distribution method for each environment. For details, see<br />
“Distribution method” in the table on page 90.<br />
In Network Configuration, define the distribution method as TCP/IP. If you use<br />
<strong>Implementer</strong>’s remote initiated moves feature, you must also define specific host system<br />
information in the Network Configuration. For details, see “Network Configuration” on<br />
page 167.<br />
The Communications Control (ICOMCTL) command must be set up to run on the<br />
remote with information specific to your communication network. If you use the update<br />
host component of remote initiated moves, you must also define the command to run on<br />
the host system. For details on setting up the ICOMCTL command, see<br />
“Communications Control Command” on page 177.<br />
<strong>Implementer</strong> includes a TCP/IP communications subsystem and communications job<br />
queue, both named IMCOM, which <strong>Implementer</strong> creates in the default product library<br />
(<strong>MKS</strong>IM) during product installation. You can use an alternate subsystem; however, the<br />
benefit of using IMCOM is that it allows you to isolate <strong>Implementer</strong>’s host and remote<br />
processing jobs from all other TCP/IP jobs being processed. For details, see<br />
“Communication Subsystem and Job Queue IMCOM” on page 176.
Setting Up for TCP/IP Distribution<br />
<strong>MKS</strong> recommends you use <strong>Implementer</strong>’s default TCP/IP port, 30005, on both the host<br />
and remote systems; although this is not a requirement.<br />
<strong>MKS</strong> recommends you set all OS/400 TCP/IP attributes to the IBM recommended<br />
defaults.<br />
Firewall Considerations<br />
For TCP/IP to work successfully with <strong>Implementer</strong>, certain external conditions must be met.<br />
The following information on using TCP/IP with a firewall may be helpful to your Network<br />
Administrator, or any other person responsible for the setup and maintenance of your<br />
communications and network.<br />
When using <strong>Implementer</strong> on a system with a firewall, the firewall must be completely<br />
transparent to <strong>Implementer</strong>. Thus, when targeting external iSeries systems with remote<br />
promotions, configure the network firewall to allow traffic through a predefined, userconfigured<br />
TCP/IP port on the remote system. Specify the port in <strong>Implementer</strong>’s Network<br />
Configuration. Uncompromising to your security, <strong>Implementer</strong> ensures that the program<br />
monitoring the port only responds to <strong>Implementer</strong>-specific requests. If needed, you can<br />
restrict activity on the port to specific Internet addresses by establishing firewall rules.<br />
To avoid the possibility of remote system tampering, <strong>Implementer</strong> accepts only certain<br />
requests through TCP/IP. The request information is handled using a token passed from the<br />
host system. The remote system interprets the token to identify which remote function to<br />
invoke. Any requests that present an invalid token are ignored.<br />
For outbound communications of bulk files transfers, <strong>Implementer</strong> uses standard FTP<br />
services that process with the default user profile MWIPROD. This requires the standard FTP<br />
ports 20 and 21 enabled. In addition, for proper authorization and authority to perform the<br />
FTP operation, the MWIPROD user profile must have the Limit Capabilities parameter set to<br />
*NO, as well as have authority to use the following commands on the remote system:<br />
CLRSAVF (Clear Save File)<br />
CRTSAVF (Create Save File)<br />
CRTLIB (Create Library)<br />
DLTLIB (Delete Library)<br />
IMPORTANT Due to the variety of FTP proxy servers and their protocols, the use of<br />
proxy servers is not supported.<br />
OS/400 FTP Service<br />
You must start the standard OS/400 FTP service to use bulk file transfers.<br />
175
Chapter 4: Remote Distribution Concepts and Setup<br />
176<br />
To start the FTP server<br />
Issue the Start TCP/IP Server command as follows:<br />
STRTCPSVR *FTP<br />
Use the Change FTP Attributes (CHGFTPA) command to configure the FTP server to autostart,<br />
and to set other configuration values.<br />
Communication Subsystem and Job Queue IMCOM<br />
<strong>Implementer</strong> includes the TCP/IP communications subsystem IMCOM and a<br />
communications job queue of the same name (IMCOM). Both are created in the default<br />
product library (<strong>MKS</strong>IM) when you install <strong>Implementer</strong>. An alternate subsystem can be<br />
used, however the benefit of using IMCOM is that it allows you to isolate <strong>Implementer</strong>’s host<br />
and remote processing jobs from all other TCP/IP jobs being processed.<br />
You must reference the IMCOM subsystem and job queue, or another subsystem and job<br />
queue if used, in the ICOMCTL command as described in “Communications Control<br />
Command” on page 177.<br />
The IMCOM subsystem processes two types of jobs—daemon jobs and monitor jobs. The<br />
following table defines the characteristics of each job.<br />
Job Type Description<br />
Daemon job Job name defined with D, followed by the port number, for example D30005. There<br />
can be any number of active daemon jobs, the actual number defined by the<br />
number of daemon instances (default is five) you define for the Communications<br />
Control (ICOMCTL) program. When no active jobs exist in the subsystem, there is<br />
exactly this number of daemon jobs (never fewer). A remote process uses one<br />
daemon instance (or session) and dynamically creates a duplicate copy each time<br />
for the next process to use.<br />
Monitor job Job name defined with M, followed by the port number, for example M30005. There<br />
is always only one active monitor job.<br />
CAUTION You must end the IMCOM subsystem to perform a backup of the<br />
<strong>Implementer</strong> Receiver library. However, ending the IMCOM subsystem with active<br />
promotions can cause unpredictable results. Thus, before ending the subsystem<br />
issue the ICOMCTL command with shutdown processing enabled to ensure no<br />
active promotions or other active jobs exist. Use the End Subsystem (ENDSBS)<br />
command to end the IMCOM subsystem.
Communications Control Command<br />
Setting Up for TCP/IP Distribution<br />
The Communications Control (ICOMCTL) command is delivered with <strong>Implementer</strong>. The<br />
command installs on the host system when you install or upgrade <strong>Implementer</strong>. It installs on<br />
the remote system when you install or upgrade <strong>Implementer</strong> Receiver.<br />
To use TCP/IP with <strong>Implementer</strong>, the ICOMCTL command must be set up to run on the<br />
remote system with information specific to your communication network. If you use the<br />
“Update Host” component of remote initiated moves, the command and similar subsystem<br />
must also be defined to run on the host system to allow automatic updates to the host system.<br />
The ICOMCTL command manages the start and end of the <strong>Implementer</strong> TCP/IP<br />
communications subsystem IMCOM (or the subsystem you have specified). It also controls<br />
starting and ending the daemons and monitor job within the subsystem. The daemons<br />
monitor for <strong>Implementer</strong>-specific requests.<br />
You must start the remote subsystem and TCP/IP communications programs by either<br />
manually issuing the ICOMCTL command, or defining the command to run automatically. If<br />
the communications programs are not active in the remote subsystem during <strong>Implementer</strong><br />
processing, any host system requests received on the remote fail with a time out error.<br />
To define the ICOMCTL command<br />
1 Define the ICOMCTL command parameters as described in the next section.<br />
2 Do either of the following:<br />
Add the ICOMCTL command to your OS/400 daily startup routine.<br />
Issue the command interactively by typing ICOMCTL at the command line and press<br />
F4 to prompt. Define the parameters as required and press ENTER. A message<br />
confirms the TCP/IP communications monitor started in the specified port.<br />
IMPORTANT Add the ICOMCTL command to your daily OS/400 startup routine, for<br />
example, the IPL procedure, or start it manually. The subsystem you specify in the<br />
command starts automatically if not active when the command processes.<br />
ICOMCTL Command Parameters<br />
TCP/IP Port<br />
Specify a valid TCP/IP port number between 1-65535. The default value is 30005. Specify the<br />
the same port number for this parameter on both the host and remote ICOMCTL commands.<br />
This port number must match the TCP/IP port value defined in <strong>Implementer</strong>’s Network<br />
Configuration.<br />
177
Chapter 4: Remote Distribution Concepts and Setup<br />
178<br />
Number of daemon instances<br />
Specify the number of simultaneous connections (or sessions) to initially invoke. Valid values<br />
are between 1 and 100. The default value is 5.<br />
Job queue/Library<br />
Specify the name of the job queue to submit the communications program. The default value<br />
is IMCOM, the communications job queue delivered with <strong>Implementer</strong>.<br />
Specify a library name associated with the job queue. The value *LIBL searches the library list<br />
for the job queue library. This is the default value.<br />
Subsystem/Library<br />
Specify the name of the subsystem attached to the job queue. The default value is IMCOM,<br />
the communications subsystem delivered with <strong>Implementer</strong>. If you specify an alternate<br />
subsystem, set the maximum number of jobs parameter (Max Active) to *NOMAX.<br />
This parameter is provided for your convenience: The ICOMCTL command runs in the<br />
subsystem attached to the job queue regardless of the subsystem specified in the command.<br />
This is because the IMCOM subsystem does not automatically start, and if you use the<br />
command defaults, the subsystem must be active to process the jobs submitted to the queue.<br />
Specify the library name associated with the subsystem. The value *LIBL searches the library<br />
list for the subsystem name. This is the default value.<br />
User to run as<br />
Specify a user profile for the command to process with.<br />
Name Specify a valid user profile name.<br />
*CMNUSR Job runs under the user profile specified in the data area IMCMNUSR<br />
(default is MWIPROD). This is the default value.<br />
*CURRENT Job runs under the user profile of the person who submits the command.<br />
Shutdown Processing<br />
Specify whether <strong>Implementer</strong> automatically ends the daemon and monitor jobs in the<br />
IMCOM subsystem. Shutdown processing does not include ending the IMCOM subsystem.<br />
Y Jobs automatically end when processing completes.<br />
N Jobs remain active until manually ended. This is the default value.
Setting Up for SNADS Distribution<br />
Setting Up for SNADS Distribution<br />
<strong>Implementer</strong> works with SNA Distribution Services (SNADS) to distribute changes to remote<br />
iSeries systems. If you are not using SNADS for distribution (for example, you are using<br />
SDMCom) you can bypass this section.<br />
The host iSeries system requires SNADS directory entries for each user profile that sends and<br />
receives remote distributions using SNADS. Before starting the following task, you must<br />
have the remote location name of the iSeries system you distribute to. You must use the<br />
remote location name, not the system name. To determine the remote location name, use the<br />
DSPAPPNINF (Display APPN Information) command if you use APPN, or use the<br />
DSPDEVD (Display Device Description) command for the APPC device that connects to the<br />
remote.<br />
NOTE The remote location name is usually the same as the system name of the<br />
remote. To prevent errors, use the above commands to ensure you use the correct<br />
location name.<br />
Add Directory Entries for Sending User Profiles<br />
A SNADS directory entry must exist for each host user profile defined in <strong>Implementer</strong> that<br />
has authority to distribute changes to remote systems (these user profiles are often already<br />
enrolled).<br />
To create the directory entry for a user not currently enrolled in SNADS<br />
Issue the following command:<br />
ADDDIRE USRID(user-profile local-system-name)<br />
USRD('Text description for the user')<br />
USER(user-profile)<br />
Add Directory Entries for Receiving User Profiles<br />
A SNADS directory entry must exist for each iSeries you distribute changes to. You can<br />
create the directory entry for receiving user profiles in any of three ways:<br />
Use directory entry USER(*ANY *ANY) to allow distribution to any user on the iSeries<br />
system identified to SNADS.<br />
Use directory entry USER(*ANY remote-location-name) to allow distribution to any user<br />
on the iSeries that matches the remote-location-name.<br />
If neither of these directory entries exists, you can create the following <strong>Implementer</strong>specific<br />
directory entry. Only one directory entry is required for the remote location.<br />
Specify this directory when defining the remote iSeries in Network Configuration. It is<br />
usually for user profile MWIPROD, as all network files are sent to that directory entry on<br />
the remote.<br />
179
Chapter 4: Remote Distribution Concepts and Setup<br />
180<br />
To create an <strong>Implementer</strong>-specific directory entry<br />
Issue the following command:<br />
ADDDIRE USRID(MWIPROD remote-system-name)<br />
USRD('<strong>Implementer</strong> on remote-system-name')<br />
SYSNAME(remote-location-name)<br />
Add a Directory Entry for MWIPROD<br />
For remote distributions, you must include a directory entry for the MWIPROD user profile.<br />
Specify the user profile on the remote iSeries where the <strong>Implementer</strong> Receiver receives<br />
changes.<br />
To create the directory entry<br />
Issue the following command:<br />
ADDDIRE USRID(MWIPROD remote-system-name)<br />
USRD('<strong>Implementer</strong>')<br />
USER(MWIPROD)<br />
Distribution Options<br />
This section describes some options you have for controlling the promotions to remote<br />
systems.<br />
Single Step Distribution<br />
<strong>Implementer</strong> can distribute and apply changes to one or more remote systems in a single step<br />
(on one request). You are not required to sign on to the remote system to apply the changes.<br />
After <strong>Implementer</strong> sends the changes to the remote system, it immediately executes an APPC<br />
program to apply the changes to the target libraries. If it is necessary to redistribute from the<br />
host, you can redistribute an existing promotion request without creating a new promotion<br />
request. From the Move Requests selection panel, use option 10=Redistribute.<br />
Two Step Distribution<br />
You can distribute objects to a remote system in one step and move the objects into the target<br />
libraries in a second step. The second step can be initiated from the host system or the remote<br />
system.
Controlling Remote Job Schedules<br />
The first step bundles the objects, distributes to the remote system, receives the objects on the<br />
remote system, and restores them into a temporary holding library. At an appropriate time,<br />
the second step quickly promotes the objects from the holding library to the target libraries.<br />
To minimize the time needed to move the objects into the target libraries, most of the work<br />
(receiving and restoring) is accomplished in the first step.<br />
Remote Initiated Moves<br />
You can initiate the second step of the two step distribution process from the remote system.<br />
Use this approach when you have changes that may take a long time to distribute. Once you<br />
distribute the changes into the holding libraries on the remote system, you can move the<br />
changes into the remote production libraries from the remote system during the second step.<br />
This feature is commonly used as the last step in a nightly job stream on the remote system.<br />
You can initiate remote initiated moves on the <strong>Implementer</strong> Receiver from a menu option, or<br />
by using the Move Remote Request (IMOVRMTRQS) command.<br />
If you use TCP/IP for distribution to remote systems and the update host functionality for<br />
remote initiated moves, additional subsystem requirements apply to processing the<br />
automatic updates to the host system. For details, see “Setting Up for TCP/IP Distribution”<br />
on page 173.<br />
CAUTION If promotion requests are dependent upon the completion of other<br />
requests, you must use a single-threaded job queue.<br />
Simultaneous Distribution to Multiple Remote Sites<br />
<strong>Implementer</strong> supports simultaneous distribution to an unlimited number of remote systems,<br />
while retaining clear visibility to what happens on each remote system.<br />
To perform simultaneous distribution, you must use the Move Request by System/<br />
Environment function and submit the promotion for each system separately to enable the<br />
distribution of multiple jobs. You can use multiple job queues or multi-threaded job queues<br />
to simultaneously distribute to multiple remote systems.<br />
Controlling Remote Job Schedules<br />
<strong>Implementer</strong> allows you to define standard move schedules on the local host development<br />
iSeries system, and then reschedule the move times of specific promotion requests to remote<br />
iSeries systems.<br />
181
Chapter 4: Remote Distribution Concepts and Setup<br />
182<br />
This feature allows you to distribute a promotion request from the host iSeries to multiple<br />
remote iSeries systems simultaneously, placing the remote move step under the control of a<br />
default schedule defined for each remote system. Additional flexibility on the host system<br />
allows you to reschedule the move for specific requests to manage the installation schedule of<br />
selected promotion requests without having to access the remote system.<br />
When scheduling a remote job, two options are available: Use the default job schedule<br />
settings for the target remote environment, or use the Change Remote Request<br />
(ICHGRMTRQS) command to override the default job schedule settings for a request, then<br />
issue the Move Remote Request (IMOVRMTRQS) command to reschedule the job.<br />
Using the Default Job Schedule<br />
To schedule a promotion request to a remote environment based on the default settings for<br />
that environment, use menu option 6, Move Requests by System/Environment to distribute<br />
the request. This option is available for any remote environment set up as defined in “Remote<br />
Job Scheduling” on page 183.<br />
The promotion scheduling defined for the environment appropriately schedules the job<br />
based on the default move time. Then, based on the frequency you define on the remote<br />
OS/400 auto job schedule for the Move Remote Request (IMOVRMTRQS) command, the<br />
move submits using the default schedule.<br />
IMPORTANT The move step must be separate from the distribution step because it<br />
must be a remote-initiated move.<br />
Overriding the Default Job Schedule<br />
The Change Remote Request (ICHGRMTRQS) command is used to enter schedule overrides<br />
to the default move schedule for promotion requests. The command evokes DDM to<br />
communicate the overrides to the schedule overrides file IMRQSO on the remote for each<br />
target remote system on a request. A log of the schedule overrides is maintained in file<br />
IMRQSO on the host and remote systems.<br />
The Move Remote Request (IMOVRMTRQS) command updates the Move job. The<br />
IMOVRMTRQS command reads the schedule overrides file IMRQSO on the remote and<br />
applies the processed overrides to the OS/400 auto job scheduler. Then, based on the<br />
frequency defined on the remote OS/400 auto job schedule for the IMOVRMTRQS<br />
command, the subsystem is polled for new jobs to submit and new overrides not yet applied.<br />
NOTE Only the IMOVRMTRQS command updates the Move job—the<br />
ICHGRMTRQS command does not.
Key Considerations<br />
Controlling Remote Job Schedules<br />
The distribution step must be separate from the move step (from <strong>Implementer</strong> Menu<br />
option 6, Move Requests by System/Environment, use option 10=Distribute).<br />
The remote target environment must be set up to allow remote initiated moves (in Work<br />
with Environments).<br />
Remote Job Scheduling<br />
Complete the following setup tasks to use remote job scheduling:<br />
define remote environment to allow remote-initiated moves<br />
define remote environments with a default move time<br />
on each remote system, create a routine job that issues the Move Remote Request<br />
(IMOVRMTRQS) command for all requests<br />
To define a remote environment for remote initiated moves<br />
1 From the <strong>Implementer</strong> Menu, select option 42, Environments and press ENTER. The<br />
Work with Environments panel displays.<br />
2 Select the remote environment with option 2=Change.<br />
3 Press PAGE DOWN twice to display the third Change Environment panel.<br />
183
Chapter 4: Remote Distribution Concepts and Setup<br />
184<br />
4 Do the following:<br />
In the Remote initiated move field, type Y.<br />
In the Updates host field, type Y or N to indicate whether remote initiated moves<br />
update the host with information such as the request header status, request detail<br />
status, archive information, and job log. If set to N, the status is set to complete once<br />
the request is distributed. Otherwise, the status is not updated until the move<br />
actually occurs on the remote system.<br />
5 To save the change, press ENTER.<br />
To set up default scheduling for a remote environment<br />
1 From the Work with Environments panel, type 13=Promotion scheduling next to remote<br />
environment and press ENTER. The Change Environment panel displays.<br />
2 Press PAGE DOWN to display the second Change Environment panel.<br />
3 In the Move submit date range and Time range fields, specify the default date and time<br />
ranges to use for the majority of requests. The left-most field represents the from date<br />
and time. The right-most field represents the to date and time.<br />
In the Move submit date range fields, specify one of the following values:<br />
*CURRENT Dates default from the system. This is the default value.<br />
Actual Date Type a specific from and to date.<br />
*MONTHSTR From date is the start of the month.<br />
*MONTHEND To date is the end of the month.<br />
*MON<br />
Type an asterisk followed by the first three letters of any day<br />
through *SUN of the week to indicate the from date.
Controlling Remote Job Schedules<br />
In the Time range fields, specify exact from and to times, or specify *CURRENT to<br />
default the time value of the system.<br />
To create a job that issues the move request<br />
1 Use the Add Job Schedule Entry (ADDJOBSCDE) command to add an entry to the<br />
OS/400 job scheduler.<br />
An example daily job schedule entry is:<br />
ADDJOBSCDE JOB(IMAUTOSCH)<br />
CMD(IMOVRMTRQS RQSNUM(*ALL))<br />
FRQ(*WEEKLY)<br />
SCDDATE(*NONE<br />
SCDDAY(*ALL)<br />
SCDTIME(150000)<br />
JOBD(IMPJOBD)<br />
2 If you need to modify the job schedule entry or view a current list of job schedule entries,<br />
use the Work with Job Schedule Entry (WRKJOBSCDE) command.<br />
Change Remote Request (ICHGRMTRQS) Command<br />
The Change Remote Request (ICHGRMTRQS) command communicates schedule changes<br />
for each target remote system on a promotion request. The command can be issued at any<br />
point once the request is created (the request does not have to be at a Move-Pend status).<br />
To use the Change Remote Request (ICHGRMTRQS) command<br />
1 Use the Create Request function to submit a request to a remote environment, or select<br />
an existing request.<br />
2 Type the command ICHGRMTRQS on the command line and press F4=Prompt.<br />
3 Define the command parameters based on your environment and as described next in<br />
“ICHGRMTRQS Command Parameters”.<br />
4 Press ENTER.<br />
ICHGRMTRQS Command Parameters<br />
Request number (RQSNUM)<br />
Specify the request number of the request you created or selected.<br />
185
Chapter 4: Remote Distribution Concepts and Setup<br />
186<br />
Target environment (TGTENV)<br />
Specify the target environment on the request.<br />
Name Specify the target environment names.<br />
Generic* Type a value to include all environments that match the value, for<br />
example, type ABC* to include all environments beginning with<br />
ABC.<br />
*ALL Targets all environments that requests are created for.<br />
From date (FROMDATE)/To date (TODATE)<br />
Specify the starting from date to schedule the move.<br />
*CURRENT From and to dates default from the system.<br />
Actual Date Type a specific from and to date.<br />
*MONTHSTR From date is the start of the month.<br />
*MONTHEND To date is the end of the month.<br />
*MON - *SUN Type an asterisk followed by the first three letters of any day of the<br />
week to indicate the from date.<br />
*REQUEST Dates and times do not change. This is the default value.<br />
From time (FROMTIME)/To time (TOTIME)<br />
Specify the starting from time to schedule the move.<br />
Actual time range Type a specific from and to time.<br />
*CURRENT Defaults the time range from the system.<br />
*REQUEST Dates and times do not change. This is the default value.<br />
NOTE The From date/To date and From time/To time fields, in combination, define a<br />
window of time; thus, if you specify a value in one field you must specify a value in<br />
both of the fields.<br />
Job Queue/Library (JOBQ)<br />
Specify the job queue library and name for the move.<br />
Name Type the name of a specific job queue and library.<br />
*SYSCTL Defaults the job queue specified in System Control Maintenance.<br />
*REQUEST Job queue and library do not change. This is the default value.
Hold on job queue (HOLD)<br />
Specify whether to submit the job on hold.<br />
Move Remote Request (IMOVRMTRQS) Command<br />
Controlling Remote Job Schedules<br />
*YES Job submits on hold.<br />
*NO Job does not submit on hold.<br />
*REQUEST Promotion request determines whether the job submits on hold.<br />
The Move Remote Request (IMOVRMTRQS) command issues the move step for each target<br />
remote environment on the request. If schedule overrides were entered using the Change<br />
Remote Request (ICHGRMTRQS) command, you must issue the IMOVRMTRQS command<br />
to process the override updates to the OS/400 job scheduler.<br />
The IMOVRMTRQS command runs periodically on the remote system to control the move<br />
jobs. For new requests not previously submitted, the move job submits using the default<br />
move time, or if any schedule overrides were specified with the Change Remote Request<br />
(ICHGRMTRQS) command. For inactive requests previously submitted, it updates the<br />
schedule to the last request schedule override received. The audit file IMRQSO is updated for<br />
all submitted requests.<br />
To use the Move Remote Request (IMOVRMTRQS) command<br />
1 Use the Create Requests function to submit a request to a remote environment or select<br />
an existing request.<br />
2 Use the Change Remote Request (ICHGRMTRQS) command to override the default<br />
move schedule. Follow the steps described on page 185.<br />
3 Type the command IMOVRMTRQS on the command line and press F4=Prompt.<br />
4 Define the command parameters based on your environment and as described next in<br />
“IMOVRMTRQS Command Parameters”.<br />
5 Press ENTER.<br />
If schedule overrides cannot be applied, (such as attempting to schedule from a date in<br />
the past) an error message generates. All schedule updates of previously submitted jobs<br />
are attempted, even if an error is encountered on another request.<br />
187
Chapter 4: Remote Distribution Concepts and Setup<br />
188<br />
IMOVRMTRQS Command Parameters<br />
Request number<br />
Specify the request number of the request you created or selected.<br />
Character<br />
Value<br />
System name<br />
Specify the name of the target remote system.<br />
Job Queue/Library (JOBQ)<br />
Specify the job queue library and name for the move.<br />
Hold on job queue (HOLD)<br />
Specify whether to submit the job on hold.<br />
Specify the request number. Resubmits a request at a scheduled<br />
status. For example, resubmits a specific request if the promotion job<br />
was deleted from the system while at a scheduled status. This<br />
resubmits all scheduled jobs based on the default schedule, or the last<br />
override processed.<br />
*ALL For new requests not previously submitted, submits the move job<br />
using the default move time, or if any schedule overrides were<br />
specified with the Change Remote Request (ICHGRMTRQS)<br />
command. For inactive requests previously submitted, updates the<br />
schedule to the last request schedule override received. This does not<br />
resubmit a request at a scheduled status.<br />
*FAILED Submits requests that previously failed and have a failed status. This<br />
does not resubmit a request at a scheduled status.<br />
Name Specify the remote system name.<br />
*NETATR System name is taken from the Network Configuration. This is the<br />
default value.<br />
Name Specify the job queue and library name.<br />
*SYSCTL Uses the job queue specified in System Control Maintenance.<br />
*REQUEST Job queue and library do not change. This is the default value.<br />
*YES Job submits on hold.<br />
*NO Job does not submit on hold.<br />
*REQUEST Request determines whether the job submits on hold. This is the<br />
default value.
Distribution Steps<br />
Move Steps<br />
Distribution Steps<br />
Based on the distribution method selected, the steps vary slightly but basically consist of the<br />
following sub-steps:<br />
Save the <strong>Implementer</strong> work libraries. For tape distribution, the save is to tape. For other<br />
methods, the work libraries are saved to save files.<br />
Send the <strong>Implementer</strong> work libraries (occurs differently for SNADS and SDMCom).<br />
Receive the <strong>Implementer</strong> network file (occurs only for SNADS for distribution).<br />
Restore the work files from the save files (occurs for all distribution methods). Once this<br />
sub-step completes the distribution step is complete. The move step is next.<br />
You can initiate the move step from either the host or remote system.<br />
On the host system you can initiate the move step from: the Workbench, Work with Objects,<br />
Move Request menu option, Move Requests by System/Environment, or the Move Request<br />
(IMOVRQS) command. This invokes a communications program on the remote that<br />
performs the promotion on the remote. The promotion steps are the same as on the local<br />
system. When the move step completes, the time and date that the objects were placed into<br />
production is transmitted back to the host to update the <strong>Implementer</strong> database.<br />
On the remote system you can initiate the move step from the Work with Requests function,<br />
or the Move Remote Request (IMOVRMTRQS) command on the <strong>Implementer</strong> Receiver menu<br />
or the command line. Many users embed the command in an end of day job on the remote<br />
system.<br />
TIP Issue the IMOVRMTRQS command with the request number value *ALL to<br />
complete the promotion of all requests distributed since the last time the command<br />
was issued.<br />
Multiple System Development<br />
<strong>Implementer</strong> supports multiple system development, a feature that allows <strong>Implementer</strong> to<br />
run on multiple systems while sharing the same database.<br />
189
Chapter 4: Remote Distribution Concepts and Setup<br />
190<br />
This feature is useful when you have related development activities spread across multiple<br />
systems, or a development system and a distribution system centrally located with<br />
distribution to many remote systems. You accomplish this with DDM (Distributed Data<br />
Management).<br />
Before using this feature you need to decide which system has the primary version of<br />
<strong>Implementer</strong>. This should be the system <strong>Implementer</strong> is most heavily used on.<br />
You must set the default user profile on the communications entry to have *ALL rights to the<br />
<strong>Implementer</strong> database files on the primary system. By default, DDM jobs run from the<br />
remote system under user profile QUSER and require access to the <strong>Implementer</strong> files. For<br />
details on the communications entry, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>.<br />
Starting and Ending Remote Database Support<br />
A secondary system is prepared for multiple system development by using the Start Remote<br />
Database (STRRMTDB) command. This command changes the <strong>Implementer</strong> database files<br />
(PFs and LFs) to DDM files. You can convert all files or functional subsets (for example, only<br />
lock and conflict processing). An example of the command is:<br />
STRRMTDB RMTLOCNAME(remote_location_name)<br />
RMTPRDLIB(remote <strong>Implementer</strong> library)<br />
MODE(IMPMODD)<br />
LCLLOCNAME(*LOC)<br />
RMTNETID(*LOC)<br />
FILESCVT(*ALL) JOBQ(*PRODUCT)<br />
Specify the location name of the remote system and the name of the <strong>Implementer</strong> library on<br />
that system. If the mode description, local location name, or remote network ID do not match<br />
the defaults, specify the correct values. Prompt the command to show valid values for these<br />
parameters. The default converts all <strong>Implementer</strong> files to remote databases. Alternatively,<br />
you can specify *LOCKS and/or *PROJECTS. For further information, see “Performance<br />
Considerations” on page 191.<br />
After you validate the connection to the remote system (for example, remote location name,<br />
mode, local location name, and remote net ID are valid), a batch job submits to the JOBQ<br />
specified to perform the conversion. The <strong>Implementer</strong> files on the local system should not be<br />
in use when this job runs.<br />
When you no longer need to use this feature, use the End Remote Database (ENDRMTDB)<br />
command to change the DDM files on the secondary system back to physical and logical files.<br />
Once you issue this command, the <strong>Implementer</strong> database files contain the original<br />
information as before the initial Start Remote Database command was issued.<br />
You must install <strong>Implementer</strong> on the host system and the <strong>Implementer</strong> Receiver on each<br />
remote system used for development or that receives changes from the host system.
Performance Considerations<br />
Multiple System Development<br />
You must analyze the performance impact of this feature on the secondary systems to<br />
determine its feasibility within your system setup. Some of the database files opened on the<br />
secondary system are DDM files. To effectively use this feature you need high-speed<br />
transmissions, such as that provided by a Gigabit Ethernet. The secondary systems using<br />
<strong>Implementer</strong> with DDM files do not significantly affect the primary system.<br />
Additionally, to enable the secondary system to use <strong>Implementer</strong>, the communications line to<br />
the primary system must be active and the <strong>Implementer</strong> database files on the primary system<br />
must be available. If the line to the primary system goes down, <strong>Implementer</strong> on the<br />
secondary system is unavailable for use until you re-establish the connection.<br />
If your communication line cannot provide adequate performance when you convert the<br />
<strong>Implementer</strong> files to remote databases, you may want only certain functional areas of the<br />
product to use this feature. On the Start Remote Database command, the default is to convert<br />
all files; however, you can specify to convert only the files related to lock and conflict<br />
processing [FILESCVT(*LOCKS)]. If you specify *LOCKS, each system operates with most<br />
<strong>Implementer</strong> files locally, yet maintains one set of files that enforce, lock, and allow<br />
concurrent development across all systems.<br />
Specify *PROJECTS to have one project tracking database. You can specify one or more of<br />
these values in the FILESCVT list. If you specify *ALL anywhere in the list, it overrides<br />
*LOCKS and/or *PROJECTS.<br />
Request Number Considerations<br />
If you use multiple system development and do not convert all database files, you should<br />
adjust the request number on each secondary system to avoid conflict with the request<br />
numbers on the primary system. For example, if the next request number (in System Control<br />
Maintenance) on the primary system is 500, set the next request number on a single<br />
secondary system to 5500. For multiple secondary systems, the next request numbers can be<br />
divided into equal groups depending on the number of secondary systems. In this way the<br />
likelihood of a duplicate request number generated by requests from the secondary systems<br />
is minimal, so audit records are less confusing.<br />
Each copy of <strong>Implementer</strong> and the <strong>Implementer</strong> Receiver should use a unique prefix for<br />
internal work libraries to ensure an overlap does not occur. Specify a unique two-character<br />
prefix in the data area IMPRFX in the product library of each copy of <strong>Implementer</strong>. For<br />
details, see “<strong>Implementer</strong> Data Areas and User Exit Programs” on page 401.<br />
You should also carefully consider the user profile names you use. To eliminate any<br />
confusion of where a check out occurs, <strong>MKS</strong> recommends you use different user profile<br />
names on the different systems.<br />
191
Chapter 4: Remote Distribution Concepts and Setup<br />
Saving and Restoring Remote Tape Archives<br />
192<br />
<strong>Implementer</strong> Receiver users who require access to the archives of every change made to an<br />
environment must often balance this requirement with the disk space required to store the<br />
archive copies. Archiving to tape provides a solution for off-line storage of archived<br />
member/objects in remote environments.<br />
You can save and remove all archives or specific archives, with access to archive information<br />
for each tape. You can also selectively restore archives back to the system. Once restored, you<br />
can browse the changes and/or recover the changes.<br />
Key Considerations<br />
Remote environments must be set up for archiving. For more information, see<br />
“Environments” on page 81.<br />
Tape archives include IFS and DLO files and directories, if archived.<br />
The archive to tape function uses two temporary libraries <strong>Implementer</strong> automatically<br />
creates at the beginning of the process and deletes at the end. <strong>Implementer</strong> provides the<br />
data area IMARCTAP to store the names of these temporary libraries. The default data<br />
are values are IMARCTAP1 and IMARCTAP2.<br />
CAUTION If you change the default library names in the IMARCTAP data area, you<br />
must specify library names that do not already exist on the system as <strong>Implementer</strong><br />
creates and deletes the libraries as needed. For details, see “<strong>Implementer</strong> Data<br />
Areas” on page 402.<br />
You can initiate all archive to tape functions from the Archives to Tape menu. Access to<br />
archive menu options and commands requires signing on as QSECOFR or with a profile<br />
that has a group profile of QSECOFR or all QSECOFR capabilities.<br />
The archive to tape and restore from tape jobs can be run interactively or in batch.<br />
To save an archive to tape on the <strong>Implementer</strong> Receiver<br />
1 From the <strong>Implementer</strong> Receiver menu, select option 10, Archive to Tape. The Archives<br />
to Tape menu displays.<br />
2 Select option 1, Save Archives to Tape to prompt the Archives to Tape (ISAVARC)<br />
command.<br />
The ISAVARC command can also be prompted from the command line. The command<br />
can be processed interactively, submitted for batch processing, or added to a backup<br />
routine to automate the removal of new archives.
Problem Determination<br />
3 Specify the command parameters as described in “Save Archives to Tape (ISAVARC)<br />
Command Parameters” on page 381, and press ENTER.<br />
A good practice is to use a new tape for each save. The tape label is automatically set by<br />
<strong>Implementer</strong> and initialized with a tape volume of ARC###, where ### represents a<br />
number that starts at 001 and automatically increments for each save. This information is<br />
stored in the <strong>Implementer</strong> data area ITAPEVOLUM. If you need to specify a different<br />
tape.<br />
To restore an archive from tape on the <strong>Implementer</strong> Receiver<br />
1 From the Archives to Tape menu, select option 2, Restore Archives from Tape, or issue<br />
the IRSTARC command to display the Restore Archives from Tape (IRSTARC) command<br />
parameters.<br />
2 Specify the command parameters as described in “Restore Archives from Tape<br />
(IRSTARC) Command Parameters” on page 382, and press ENTER.<br />
Problem Determination<br />
TIP To easily locate the requests to restore, review the archive reports as described<br />
in “Archive Reports” on page 383. This feature is available on the host system only.<br />
If problems occur during distribution or when moving a promotion request, a message is sent<br />
to the user on the local system that initiated the job. The job log is sent to the host system<br />
where you can view it in Job Log Inquiry.<br />
Your initial distributions and/or moves can fail if you have <strong>Implementer</strong> or the remote<br />
communications incorrectly configured. The resulting system messages can be difficult to<br />
diagnose. You should contact your supplier for help in this case. For additional information<br />
on standard installation and communications, see “Understanding <strong>Implementer</strong>” on page 9<br />
and “<strong>Implementer</strong> <strong>Administration</strong>” on page 63.<br />
The remote diagnostic capabilities can be particularly important to users with multiple<br />
remote systems because it eliminates the need to sign on to the different remote sites to<br />
perform problem determination. In most cases, you can determine problems from the host<br />
system, rather than on each remote system.<br />
193
Chapter 4: Remote Distribution Concepts and Setup<br />
194
C HAPTER FIVE<br />
<strong>MKS</strong> Integrity Integration<br />
Setting Up the Integrated SCM Solution<br />
5<br />
Few industries in the world can compare to the rapidly changing realm of computing technology.<br />
Hardware, software, and the dot com eBusiness environment are evolving at an ever increasing rate of<br />
speed. In the explosive Internet and Web-based marketplace, many companies are rushing to take<br />
advantage of this area, creating Web sites, intranets, and online commercial software products.<br />
However the effort involved in managing change has taken its toll unnecessarily on many hardworking<br />
and dedicated people. You may relate to working in a rapid free-fire zone of software<br />
development where nightly builds, if that frequent, provide the only milestones in the process. Such<br />
inadequate measures for backup and security seriously jeopardize the effectiveness of enterprise-wide<br />
contributions. While this is only one scenario, it represents an important fact in this emerging Webbased<br />
marketplace: businesses desperately need solutions that move them from chaos to order.<br />
<strong>MKS</strong> creates solutions that help you where it matters most—in the management of changes in all your<br />
critical files and in the promotion of workflow collaboration among people in your organization. Put<br />
simply, <strong>MKS</strong> has the right solution for your business. In fact, keeping up with the pace of technology<br />
does not have to be painful—on the contrary, <strong>MKS</strong> thinks that setting the pace is much more<br />
rewarding.<br />
This chapter covers the following topics:<br />
“<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration” on page 196<br />
“Converting From DesignTracker to <strong>MKS</strong> Integrity” on page 243<br />
“Emergency Update Mode” on page 255<br />
“<strong>Implementer</strong> and <strong>MKS</strong> Source Integration” on page 259<br />
“<strong>MKS</strong> Integrity Integrations Task Checklists” on page 295<br />
“Export to <strong>Implementer</strong>” on page 296<br />
“Troubleshooting” on page 302<br />
195
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
196<br />
<strong>MKS</strong> Integrity (formerly <strong>MKS</strong> Integrity Manager®) is a highly customizable, process and<br />
workflow management tool.<br />
Any simple defect tracking tool can record the status of a change request, but it does not<br />
monitor all the components that need to be modified, or the variety of tasks that need to be<br />
performed to resolve the issue. <strong>MKS</strong> Integrity extends the concept of defect tracking to<br />
include support for managing components, tasks, and workflow. This is particularly<br />
important when your organization has implemented a Software Configuration Management<br />
(SCM) process for the proposal, review, and approval of all software changes.<br />
Change packages can also aid in the review of source code. By grouping together all changed<br />
members in a change package, developers can easily locate and retrieve the members they<br />
need to review.<br />
As part of the <strong>Implementer</strong> integration, <strong>MKS</strong> Integrity allows you to correlate issues with<br />
change packages that result from <strong>Implementer</strong>-managed development.<br />
A change package allows you to specify groups of member/objects that are affected by an<br />
issue, for example, a solution’s change package might contain programs that need to be<br />
changed in order to correct a problem. This helps to ensure that no hidden features or<br />
changes enter the product.<br />
The <strong>Implementer</strong> and <strong>MKS</strong> Integrity integration:<br />
helps your development team capture and track all of the data related to change in your<br />
software system<br />
allows you to set up a workflow to manage the change process<br />
allows you to create change packages to correlate issues with specific <strong>Implementer</strong><br />
member/object revisions<br />
automatically creates change packages to correlate issues with specific <strong>Implementer</strong><br />
source members and objects<br />
provides metrics for your data including queries, reports, and charts<br />
Multitiered Architecture<br />
Your business problems are unique. Your specific concerns for managing the software<br />
development process in your environment requires a solution tailored to your workflow and<br />
information management process; you are looking for a seamless answer that works with the<br />
tools you prefer to use to get the job done.
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
<strong>MKS</strong> Integrity uses a multitiered architecture to provide improved security and cross-platform<br />
development features. Security is improved because all information related to your software<br />
development history can be kept on secure servers and accessed from a common client<br />
application. Cross-platform development is enhanced because any supported client can<br />
access members on any supported server.<br />
The <strong>MKS</strong> Integrity Server is responsible for all project work on the remote file system, while<br />
the client (<strong>MKS</strong> Integrity) manages all file work on the local user’s file system. Using a client,<br />
remote developers, managers, and Web developers can access <strong>MKS</strong> Integrity through a Web<br />
browser client, such as Internet Explorer or Mozilla.<br />
<strong>MKS</strong> Integrity<br />
Client<br />
Issues and<br />
Change Packages<br />
<strong>Implementer</strong><br />
iSeries 400<br />
Customer Browsers<br />
<strong>MKS</strong><br />
Integrity<br />
Server<br />
IFS<br />
Development<br />
Verification Phase<br />
Testing<br />
Deployment Phase<br />
Production<br />
<strong>MKS</strong> Source<br />
Client<br />
Projects and<br />
Archives<br />
Sandboxes<br />
Using a multitiered architecture, the integration presents a beginning-to-end story for<br />
managing change<br />
197
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
The iSeries Component<br />
198<br />
The <strong>Implementer</strong> and <strong>MKS</strong> Integrity integration manages software applications across your<br />
enterprise with a streamlined process for the creation and approval of mission-critical<br />
business applications. Based on a unique, open, application server architecture, the solution<br />
includes:<br />
workflow (<strong>MKS</strong> Integrity) for collaboration, approval, and change management<br />
host based version control (<strong>Implementer</strong>) and configuration for software management<br />
client/server and Java version control (<strong>MKS</strong> Source, formerly Source Integrity®<br />
Enterprise) and configuration for software management<br />
promotion and deployment (<strong>Implementer</strong>) for the movement of software changes to QA<br />
and production<br />
Process and Workflow<br />
Managers have a window into the development process, allowing them to monitor the<br />
progress of issues and changes. Resolving issues is accomplished through an integrated<br />
change management process facilitated by a common software architecture between<br />
<strong>MKS</strong> products.<br />
Issues<br />
<strong>MKS</strong> Integrity uses issues to track changes during the software development cycle. Problems,<br />
solutions, and tasks are all examples of issues. Issues can be related to each other for<br />
reference, easy tracking, and monitoring. For example, a solution may be associated with a<br />
problem and the relationship allows you to capture the data on the problem resolution<br />
during different stages of the development process. Each issue has an audit trail, which may<br />
be used to evaluate internal processes for the effectiveness of the problem resolution process.<br />
Types<br />
Issue types describe different categories of issues, such as a change request, problem, solution,<br />
or task. For example, you can use one type for issues that record deficiencies in design. You<br />
can use another type for issues that request design changes to fix problems, or to propose<br />
enhancements or new functionality for your component. Similarly, you can use a type for<br />
issues that assign work tasks to address problems or to suggest and implement solutions.<br />
<strong>MKS</strong> Integrity is an extremely flexible issue management system. <strong>MKS</strong> Integrity allows any<br />
number of types. Each type can have its own defined workflow of allowed state transitions<br />
and its own user defined set of fields.
Workflow<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
Every type follows a workflow, which is defined for every issue of that type. Workflow is the<br />
process established by an administrator to capture and track information and steps during<br />
your software development cycle. Each issue type has its own set of states to advance through<br />
the development cycles. For example, a change request might go through the states: new,<br />
approved, coding, testing, and deployed. States can also be shared across several workflows.<br />
Issues and their current states provide change management information necessary to support<br />
business decisions.<br />
<strong>MKS</strong> Integrity helps you manage issues by assigning them to responsible groups and by<br />
tracking and enforcing rules of your workflow. The ability to monitor the progress of issues<br />
at any time means they can be handled in a timely manner. By running reports on the issue<br />
data, you are able to identify problem areas that require attention and evaluate the<br />
effectiveness of improvements over time.<br />
As part of the integration with <strong>Implementer</strong>, you can track changes to members through an<br />
issue’s change package. An <strong>Implementer</strong> change package reflects the iSeries development done<br />
to resolve the issue. For example, a solution’s change package contains all members that were<br />
changed to fix a problem.<br />
The following rules apply when using issues and <strong>Implementer</strong> change packages:<br />
Each change package reflects the members effected for a single production environment.<br />
Multiple change packages are created for a single issue when multiple production<br />
environments are affected. For example, this is the case when making a software fix to an<br />
older version as well as to the new release. If an issue needs to be fixed in more than one<br />
application, a new change package is created for each application, keeping each fix<br />
separate.<br />
Development progress in <strong>Implementer</strong> optionally updates the state of an issue to reflect<br />
the development progress within <strong>Implementer</strong>. For example, when a member is checked<br />
out for an issue, the issue state could be automatically set to “Coding”. When all changes<br />
for an issue are promoted to quality assurance, the state could be automatically set to<br />
“Testing”.<br />
<strong>Implementer</strong> development activities are controlled by an issue’s workflow.<br />
An issues change packages close automatically by promoting the members forward to a<br />
production environment.<br />
The seamless integration between <strong>Implementer</strong> and <strong>MKS</strong> Integrity ensures that all iSeries<br />
development activity not only conforms to standard version control mechanisms within<br />
<strong>Implementer</strong>, but it extends these controls by ensuring that the corporate workflow for<br />
process management setup within <strong>MKS</strong> Integrity is never violated by a single development<br />
action. Then as a result of iSeries development, the enterprise wide issue tracking system is<br />
updated automatically to communicate the issue state change throughout the organization.<br />
Throughout the development process, each member being worked on is individually tracked<br />
on the <strong>MKS</strong> Integrity issue.<br />
199
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
200<br />
The following diagram illustrates this extensive integration.<br />
<strong>Implementer</strong> Actions M KS Integrity<br />
Path<br />
DEV<br />
new state<br />
“Coding”<br />
QAC<br />
new state<br />
“Testing”<br />
PRD<br />
new state<br />
“Deployed”<br />
Issue Created by Authorized User<br />
Issue created by authorized users using browser access<br />
Issue Approved by Issue Review Board<br />
Issue updated by an issue review board<br />
<strong>Implementer</strong> Checkout<br />
Verifies state change allowed from “Approved” to “Coding”<br />
V erifies current state has “checkout” capability<br />
Copies members to DEV environment library<br />
Creates change package for environment PRD<br />
Adds member with status of “checkout”<br />
Changes issue state to “Coding”<br />
<strong>Implementer</strong> Promotion to QAC<br />
Verifies state change allowed from “Coding” to “Testing”<br />
V erifies current state has “prom ote to Q AC 1” capability<br />
Moves members to environment QAC<br />
Updates status of change package entries to “In QA1”<br />
Updates change package status to “In QA1”<br />
Updates issue state to “Testing”<br />
<strong>Implementer</strong> Promotion to PRD<br />
Verifies state change allowed from “Testing” to “Deployed”<br />
Verifies current state has “promote to Production” capability<br />
Moves members to environment PRD<br />
Updates status of change package entries to “In Prod”<br />
Updates change package status to “In Prod”<br />
Closes the change package<br />
Updates issue state to “Deployed”<br />
The integration with <strong>MKS</strong> Integrity allows you to:<br />
create and close change packages<br />
add members/objects from <strong>Implementer</strong> to an issue’s change package<br />
track each member, how the member was changed, and where the member currently is<br />
within the development process<br />
view <strong>MKS</strong> Integrity change package information from <strong>Implementer</strong><br />
view <strong>Implementer</strong> information from <strong>MKS</strong> Integrity<br />
Workflow State Capabilities<br />
Approved<br />
Deployed<br />
The change package provides the common thread through the integration. <strong>Implementer</strong><br />
documents the changes made to your members, and also tracks who made them, when they<br />
were made, and the reasons why.<br />
New<br />
Coding<br />
Testing<br />
Not applicable<br />
Check out<br />
Check out<br />
Promote to QA<br />
Promote to Production<br />
Not applicable
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
The following illustrates how the integration between <strong>Implementer</strong> and <strong>MKS</strong> Integrity<br />
works:<br />
1 You create an issue in <strong>MKS</strong> Integrity. For example, the issue requests a bug fix for a<br />
software installation problem.<br />
2 The developer performs a check out within <strong>Implementer</strong> that automatically creates an<br />
<strong>Implementer</strong> change package. Likewise, developers can automatically create a change<br />
package from the Workbench, by assigning an issue to a lock in the Lock Detail panel, or<br />
by assigning an additional issue in the Multiple Issues panel. The change package is<br />
assigned an ID and is in an open state.<br />
3 Once the changes or additions necessary to satisfy the issue are complete, the developer<br />
promotes the members.<br />
4 The issue moves to the state in the workflow defined for the environment. For example,<br />
the issue is moved from the Test state to the QA1 state.<br />
Sample Workflow<br />
You can define this feature to any <strong>MKS</strong> Integrity state that is defined within the environment<br />
workflow. For the purpose of this document however, the setup steps and examples illustrate<br />
the generation of <strong>Implementer</strong> requests when an issue reaches a state of “Ready for QA”,<br />
based on the following workflow:<br />
Submitted<br />
In Development<br />
work is in progress<br />
work is in initial unit test state<br />
Ready for QA (manually set)<br />
work has passed initial unit test and is considered ready for promotion into QA<br />
environments<br />
an <strong>MKS</strong> Integrity user manually sets an issue to this state when the corresponding<br />
objects have passed initial unit testing and are ready for promotion to QA<br />
environments<br />
In QA1<br />
objects have successfully promoted into the first set of QA environments<br />
Promoting <strong>Implementer</strong> Requests From <strong>MKS</strong> Integrity<br />
You can create and submit promotion requests from within <strong>Implementer</strong> or from within<br />
<strong>MKS</strong> Integrity. When promotion activities are performed from <strong>Implementer</strong>, it is standard<br />
<strong>Implementer</strong> promotion processing.<br />
201
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
202<br />
A separate feature allows you to create and submit promotion requests from within<br />
<strong>MKS</strong> Integrity, without having to use a separate iSeries session. This functionality is<br />
accomplished through <strong>Implementer</strong>’s command processing capabilities, as well as the event<br />
trigger functionality of <strong>MKS</strong> Integrity, and Java scripting.<br />
When the state of an issue changes to a specific user-defined state within the workflow, an<br />
<strong>MKS</strong> Integrity event trigger runs the JavaScript that establishes a connection to the iSeries<br />
and issues the call to the <strong>Implementer</strong> Add Issue Objects to Clipboard (IADDCBDISS)<br />
command. The IADDCBDISS command adds to the <strong>Implementer</strong> Clipboard all objects<br />
locked to a specified issue. Once the objects are successfully copied to the Clipboard, the<br />
<strong>Implementer</strong> Create Request (ICRTRQS) command automatically creates and submits a<br />
request to promote the objects.<br />
All messaging related to promotion processing occurs on the iSeries. If problems occur with a<br />
promotion, e-mail notification is sent to the <strong>MKS</strong> Integrity user ID for problem analysis and<br />
resolution. This feature has setup requirements in addition to setting up the basic integration.<br />
For <strong>MKS</strong> Integrity setup, see page 212. For <strong>Implementer</strong> setup, see page 242.<br />
Assumptions and Requirements<br />
<strong>MKS</strong> assumes both <strong>Implementer</strong> and <strong>MKS</strong> Integrity are configured and working successfully<br />
independently.<br />
The standard requirements for promotion request processing apply to using this feature. For<br />
example, <strong>Implementer</strong> validates user authorities to ensure the <strong>MKS</strong> Integrity user who<br />
invokes the script has the capability to create and submit promotion requests in <strong>Implementer</strong>;<br />
thus, the <strong>MKS</strong> Integrity user responsible for issuing requests must be defined to an<br />
<strong>Implementer</strong> user profile. The <strong>Implementer</strong> user profile is subject to all standard capability<br />
checks, for example, environment authorities and authority to promote.<br />
Similarly, the rules and requirements applicable to each promotion related feature also apply,<br />
such as related object and related request processing.<br />
CAUTION By not associating the <strong>MKS</strong> Integrity user to an <strong>Implementer</strong> user profile,<br />
embedded commands in the script fail.<br />
The <strong>Implementer</strong> and <strong>MKS</strong> Integrity integration described in this guide requires:<br />
<strong>Implementer</strong> <strong>2006</strong>, which requires an iSeries system running OS/400 V5R1 or later, or<br />
i5/OS V5R3 or later. This is assumed installed and configured. For details on installing<br />
<strong>Implementer</strong>, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>.<br />
<strong>MKS</strong> Integrity 2005 or later. This is assumed installed and configured. However, for the<br />
latest features you must have <strong>MKS</strong> Integrity <strong>2006</strong> or later installed and configured. For<br />
details, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> Installation <strong>Guide</strong>.
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
An active TCP/IP connection between the iSeries running <strong>Implementer</strong> and the system<br />
running <strong>MKS</strong> Integrity Server.<br />
You must configure the <strong>Implementer</strong> Server. For details, see “Configuring the<br />
<strong>Implementer</strong> Server” on page 217. For details on managing the <strong>Implementer</strong> Server, see<br />
page 223.<br />
Run the <strong>Implementer</strong> conversion that sets <strong>MKS</strong> Integrity as the default issue tracking<br />
system. For details, see “Converting From DesignTracker to <strong>MKS</strong> Integrity” on page 243.<br />
The <strong>Implementer</strong> and <strong>MKS</strong> Source integration has additional requirements. For details,<br />
see “<strong>Implementer</strong> and <strong>MKS</strong> Source Integration” on page 259.<br />
The following table summarizes the tasks required for the integration between <strong>Implementer</strong><br />
and <strong>MKS</strong> Integrity. It also tells you where to find additional information related to setting up<br />
the integration.<br />
The table includes steps required specifically for installing and setting up the <strong>MKS</strong> Integrity<br />
Server. For complete details on installing and configuring the <strong>MKS</strong> Integrity Server, see the<br />
<strong>MKS</strong> Integrity Server <strong>2006</strong> Installation <strong>Guide</strong>.<br />
To Do This … See …<br />
Understand the system requirements before you<br />
start the installation.<br />
<strong>MKS</strong> Integrity Setup and <strong>Administration</strong><br />
“Assumptions and Requirements” on<br />
page 202.<br />
Set up <strong>MKS</strong> Integrity for the integration. “<strong>MKS</strong> Integrity Setup and <strong>Administration</strong>” on<br />
page 203.<br />
Set up the <strong>Implementer</strong> Server. “Configuring the <strong>Implementer</strong> Server” on<br />
page 217<br />
Set up <strong>Implementer</strong> for the integration. “<strong>Implementer</strong> Setup and <strong>Administration</strong>” on<br />
page 216.<br />
Manage the <strong>Implementer</strong> Server. “Managing <strong>Implementer</strong> Server” on page 223.<br />
Convert from DesignTracker to <strong>MKS</strong> Integrity and<br />
perform a data conversion, if necessary.<br />
“Converting From DesignTracker to<br />
<strong>MKS</strong> Integrity” on page 243.<br />
Use the <strong>Implementer</strong>/<strong>MKS</strong> Integrity integration. See the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Perform emergency operations, if required. “Emergency Update Mode” on page 255.<br />
<strong>MKS</strong> Integrity is flexible—you can customize it in any way that meets your business needs.<br />
Setting up <strong>MKS</strong> Integrity involves an assessment of your current product development<br />
process to allow you to effectively design an installation that reflects your business practices.<br />
203
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
204<br />
This assessment involves no direct interaction with the software. Instead, you need to spend<br />
some time evaluating the product development process currently followed in your<br />
organization and map it so you can customize your <strong>MKS</strong> Integrity project to suit your needs.<br />
This may take longer for some than for others. But the purpose of the assessment is to avoid<br />
the time-consuming task of redesigning a project that was not well-planned in the first place.<br />
When undertaking this assessment, you should focus on these areas:<br />
your workflow and project state transitions<br />
your current tracking mechanism<br />
the scope of implementation within your organization<br />
the relevant teams and user groups<br />
Once the assessment is complete, you can proceed to customizing your installation and refer<br />
to this assessment when setting up <strong>MKS</strong> Integrity. To set up <strong>MKS</strong> Integrity, you need to<br />
define users, groups, projects, states, types, and fields, as well as set up e-mail notification.<br />
For details on assessing your current product development process or setting up<br />
<strong>MKS</strong> Integrity, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
NOTE Administrative functions such as users, groups, projects, states, types, fields,<br />
and triggers are accessible only from the <strong>MKS</strong> Integrity <strong>Administration</strong> Client<br />
graphical user interface (not from the Web interface).<br />
When you have completed setting up <strong>MKS</strong> Integrity, refer to the following sections for<br />
information specific to setting up <strong>MKS</strong> Integrity for integration with <strong>Implementer</strong>:<br />
“Configure the <strong>MKS</strong> Integrity Server for <strong>Implementer</strong> Server” on page 204.<br />
“Manage States and State-based Capabilities” on page 208.<br />
(Optional) “Enable Promotions From <strong>MKS</strong> Integrity” on page 212.<br />
For a checklist of the tasks required to configure the <strong>Implementer</strong> and <strong>MKS</strong> Integrity<br />
integration, see “<strong>MKS</strong> Integrity Integration Setup: Task Checklist” on page 295.<br />
Configure the <strong>MKS</strong> Integrity Server for <strong>Implementer</strong> Server<br />
The tasks associated with configuring the <strong>MKS</strong> Integrity Server for the <strong>Implementer</strong> Server<br />
include the following:<br />
configure security ACLs (based on your version of <strong>MKS</strong> Integrity Server)<br />
set change package authorities<br />
modify the <strong>MKS</strong> Integrity Server configuration file IntegrityClientSite.rc<br />
The <strong>MKS</strong> Integrity administrator who has knowledge of working with the <strong>MKS</strong> Integrity<br />
administration functions typically performs these tasks.
Configuring <strong>MKS</strong> Integrity Server ACLs<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
<strong>Implementer</strong> requires an <strong>MKS</strong> Integrity user ID to proxy all commands sent to<br />
<strong>MKS</strong> Integrity. <strong>MKS</strong> recommends you create a new user ID, for example, iSeries, with a<br />
password that does not expire specifically for this purpose. This should be a user ID you<br />
normally do not log in with. Be sure to create the user ID on both your network and in<br />
<strong>MKS</strong> Integrity. This is also the user ID you define in <strong>Implementer</strong> as described on page 230.<br />
In <strong>MKS</strong> Integrity, this user ID requires:<br />
set up in its own unique group, for example, implementer developer group (the<br />
group should include only users who create and modify <strong>Implementer</strong> change packages)<br />
special privileges set up through the Impersonation ACL to perform work on behalf of<br />
the actual <strong>Implementer</strong> user for certain commands<br />
On the <strong>MKS</strong> Integrity Server, user access is controlled by permissions on ACLs through the<br />
Authorization <strong>Administration</strong> system. The <strong>MKS</strong> Integrity administrator typically performs<br />
ACL configuration. For details, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
NOTE The following task uses the <strong>MKS</strong> Integrity Web interface to configure ACLs;<br />
however, you can also use the <strong>MKS</strong> Integrity <strong>Administration</strong> Client. If using the<br />
client interface, modify the steps as needed.<br />
To configure the security ACLs for <strong>Implementer</strong> Server<br />
1 On the <strong>MKS</strong> Integrity Server, click Start <strong>MKS</strong> Authorization <strong>Administration</strong>.<br />
2 Add the following required ACL entries:<br />
mks:impersonate:group:<br />
principle: <br />
Impersonate allowed<br />
mks:im<br />
Admin allowed<br />
IMPORTANT In this example, implementer developer group is the <strong>MKS</strong> Integrity<br />
group that all <strong>Implementer</strong> users are a member of. Change this variable to reflect the<br />
group name you created. To avoid compromising your security, use a group other<br />
than the everyone group; by default, all users are part of this group.<br />
Customizing Permissions for the <strong>Implementer</strong> Change Package Type<br />
This is a required task that restricts users from the ability to modify user defined change<br />
packages outside of <strong>Implementer</strong>. This is necessary to ensure <strong>Implementer</strong> change packages<br />
remain synchronous between <strong>Implementer</strong> and <strong>MKS</strong> Integrity.<br />
205
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
206<br />
The Super Administrator with Admin permission under the mks:im ACL is permitted to<br />
manage permissions for the <strong>Implementer</strong> change package type.<br />
You customize the permissions for <strong>Implementer</strong> change packages using the following<br />
command:<br />
im editcptype implementer<br />
Using the --permittedGroups option, the Super Administrator controls which groups are<br />
allowed to view <strong>Implementer</strong> change packages. By default, the everyone group is permitted<br />
to view <strong>Implementer</strong> change packages.<br />
IMPORTANT Once new permissions are set for the <strong>Implementer</strong> change package type,<br />
the default settings are overwritten. If you set new permissions where no<br />
parameters are specified, then no one can view <strong>Implementer</strong> change packages.<br />
You perform the following task using the command line interface (CLI) in <strong>MKS</strong> Integrity. For<br />
details, see the <strong>MKS</strong> Integrity <strong>2006</strong> CLI Reference <strong>Guide</strong>.<br />
To customize permissions for the <strong>Implementer</strong> change package type<br />
From the command line interface, issue the following command:<br />
im editcptype -permittedGroups=,:modi<br />
fy implementer<br />
for example,<br />
im editcptype -permittedGroups=implementerdevelopergroup,implementerintegrationgrou<br />
p:modify implementer<br />
Modifying the <strong>MKS</strong> Integrity Server Configuration File<br />
This task is required for the ability to execute <strong>MKS</strong> Integrity and <strong>MKS</strong> Source commands<br />
from within <strong>Implementer</strong> or WDSc. It also provides a comprehensive feature that allows<br />
<strong>Implementer</strong> users to invoke <strong>MKS</strong> Integrity and <strong>MKS</strong> Source GUI gestures from their<br />
workstation.<br />
NOTE The <strong>MKS</strong> Integrity Client must be available to use this feature.<br />
The following table lists the GUI interactions available for each respective <strong>Implementer</strong> user.
<strong>Implementer</strong><br />
User<br />
To modify the <strong>MKS</strong> Integrity Server configuration file<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
IMPORTANT The IntegrityClientSite.rc communications file is located in the<br />
default installation directory of the <strong>MKS</strong> Integrity Server and the default installation<br />
directory of each <strong>MKS</strong> Integrity Client. You must modify the file in each location. To<br />
allow a developer to update the communications file on their desktop, the<br />
instructions for updating the <strong>MKS</strong> Integrity Client are also included in the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
1 Using Notepad or a similar text editor, open file IntegrityClientSite.rc as follows:<br />
On the <strong>MKS</strong> Integrity Server, the file is located in the directory /config/client.<br />
On the <strong>MKS</strong> Integrity Client, the file is located in /<strong>MKS</strong>/IntegrityClient.<br />
2 Verify the following line is not commented out:<br />
daemon.connectionPolicy=mks.ic.common.policy.ICAllowSpecificConne<br />
ctionPolicy<br />
3 Add or update the following statement:<br />
daemon.validConnectionList=127.0.0.1,xxx.x.x.x<br />
where xxx.x.x.x is the IP address of <strong>Implementer</strong> Server.<br />
4 Save the file and exit.<br />
<strong>MKS</strong> Integrity GUI Gesture <strong>MKS</strong> Source GUI Gesture<br />
Administrator Perform initial setup.<br />
Activate integration and<br />
communications between<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity.<br />
Developer Select issues.<br />
View and edit issues from the Select<br />
Issue or Multiple Issues panel.<br />
View the issue summary and URL<br />
location of an issue.<br />
Perform initial setup.<br />
Activate integration and<br />
communications between<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source.<br />
Activate <strong>MKS</strong> Source archiving for<br />
<strong>Implementer</strong> products.<br />
Create development path in<br />
<strong>MKS</strong> Source.<br />
Populate <strong>MKS</strong> Source projects.<br />
Checkpoint projects.<br />
Check out a specific revision.<br />
Copy from specified environment and<br />
select highest revision.<br />
View member history and annotated<br />
views from within the Workbench,<br />
Work with Objects, and WDSc.<br />
207
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
208<br />
Manage States and State-based Capabilities<br />
Throughout the product development lifecycle, issues submitted in <strong>MKS</strong> Integrity follow a<br />
workflow. You can customize the workflow and the stage the issue is in. These stages are<br />
states in <strong>MKS</strong> Integrity. For example, your process may include resource allocation, research,<br />
coding, quality assurance testing, and production. Or your process can be more elaborate.<br />
Further, each issue type can follow a unique workflow.<br />
State Usage Within <strong>Implementer</strong><br />
In <strong>Implementer</strong>, promotion path entries are used to designate the different development<br />
locations. They also correlate to states in <strong>MKS</strong> Integrity, and define the default mapping<br />
between <strong>Implementer</strong> environments and the state of issues for members in those<br />
environments.<br />
<strong>Implementer</strong> has three default promotion paths: *TST, *QAC1, and *PRD. You can create<br />
additional *QAC paths as needed, for example, *QAC2, *QAC3, *QAC4. Promotion path<br />
entries are defined in the <strong>MKS</strong> Integrity State setup, option 47 from the <strong>Implementer</strong> Menu.<br />
NOTE For details on <strong>MKS</strong> Integrity state setup in <strong>Implementer</strong>, see “State Setup in<br />
<strong>Implementer</strong>” on page 232.<br />
<strong>Implementer</strong> State-based Capabilities<br />
In <strong>MKS</strong> Integrity, you assign <strong>Implementer</strong> capabilities to the states used during <strong>Implementer</strong>managed<br />
development. State-based capabilities correlate to the <strong>Implementer</strong> promotion path.<br />
They define the <strong>Implementer</strong> functions (check out, promotion, and rejection) that are allowed<br />
or not allowed for members while an issue is in a defined state.<br />
The following state based capabilities (state transitions) are created in <strong>MKS</strong> Integrity after<br />
you run F8=Configure <strong>MKS</strong> Integrity from <strong>Implementer</strong>’s <strong>MKS</strong> Integrity State Setup panel<br />
(as described on page 233). The capabilities are based on the default path entries in<br />
<strong>Implementer</strong>.<br />
allows checkout to a development environment in <strong>Implementer</strong><br />
allows promotion to QAC environment number 1 as defined in the development path in<br />
<strong>Implementer</strong><br />
allows rejection of changes from a quality assurance environment back to a development<br />
environment in <strong>Implementer</strong><br />
allows promotions to a production environment in <strong>Implementer</strong><br />
The following example shows the state based capabilities that apply to the following<br />
workflow:<br />
Submitted > Checkout > QA1 > QA2 > In Production
State <strong>MKS</strong> <strong>Implementer</strong> State Based Capability<br />
To work with states and state based capabilities in the <strong>MKS</strong> Integrity<br />
<strong>Administration</strong> Client<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
Submitted Allows check out to development environment in <strong>Implementer</strong>.<br />
Checkout Allows check out to development environment in <strong>Implementer</strong>.<br />
Allows promotion to QAC environment #1 as defined in the development path in<br />
<strong>Implementer</strong>.<br />
QA1 Allows promotion to QAC2 environment #2 as defined in the development path<br />
in <strong>Implementer</strong>.<br />
Allows rejection of changes from quality assurance environment back to<br />
development environment in <strong>Implementer</strong>.<br />
QA2 Allows promotion to production environment in <strong>Implementer</strong>.<br />
Allows rejection of changes from quality assurance environment back to<br />
development environment in <strong>Implementer</strong>.<br />
For multiple QA environments, select additional promotion capabilities as<br />
needed. For details, see “<strong>Implementer</strong> State-based Capabilities” on page 208.<br />
In Production None. Once member object is promoted to production, all <strong>Implementer</strong> change<br />
packages automatically close.<br />
In the <strong>MKS</strong> Integrity <strong>Administration</strong> Client, under <strong>MKS</strong> Integrity, select States. The<br />
States view displays.<br />
Any changes you make in the States view have an immediate effect in your <strong>MKS</strong> Integrity<br />
database. Dialog boxes opened from the States view contain Cancel buttons for canceling<br />
operations.<br />
209
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
210<br />
Creating States<br />
You can create states for use in an issue type’s workflow. You can only create one state at a<br />
time. For details on creating states, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
To create a state in the graphical user interface<br />
1 From the States view, do one of the following to display the Create State dialog box:<br />
Select State > Create.<br />
Right click and select Create.<br />
Click<br />
2 In the Name field, enter a name for the state. This is the name the state is referred to in<br />
<strong>MKS</strong> Integrity.<br />
3 Under the Description tab, you can enter a more detailed textual description of the state,<br />
such as the state’s meaning in your workflow. To do this, click the Description tab.<br />
4 Under the Position tab, you can specify where the new state displays in the State list<br />
within an issue. Use the Move Up and Move Down buttons to change the position of the<br />
new state.<br />
5 Under the Image tab, you can associate a custom icon image with the state. To do this,<br />
select Use Custom Image, and click Select to browse for the image file. To have no image<br />
associated with the type, select No Image.<br />
If you choose to use your own custom icon image, the image must be in GIF or JPEG<br />
format, and no larger than 24 by 16 pixels.
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
6 Under the Capabilities tab, you can define state-based capabilities. State based capabilities<br />
allow the check out, promotion, or rejection of members in <strong>Implementer</strong> while an issue is<br />
in a given state.<br />
If the issue state does not allow open change packages, <strong>MKS</strong> Integrity prompts you to<br />
close the issue’s change package before you move any issue to that state.<br />
If an issue state does not allow open change packages, you cannot create new change<br />
packages for any issues in that state.<br />
To display all available state-based capabilities, from the Filter list select .<br />
To display only enabled state-based capabilities, from the Filter list select<br />
.<br />
To define <strong>Implementer</strong> state-based capabilities:<br />
a) From the Filter list, select <strong>MKS</strong> <strong>Implementer</strong> to display only the state-based<br />
capabilities related to this integration.<br />
b) From the list, select the development activities that are allowed while an issue is in<br />
this state.<br />
IMPORTANT If using the <strong>MKS</strong> Source integration as described in “<strong>Implementer</strong> and<br />
<strong>MKS</strong> Source Integration” on page 259, the development state (*TST) must have the<br />
capability Allows open SI change packages to exist.<br />
211
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
212<br />
7 When you are finished setting the new state’s properties, click OK.<br />
IMPORTANT The following setup tasks are required only to promote <strong>Implementer</strong><br />
requests from within <strong>MKS</strong> Integrity. If you do not plan to use this alternate<br />
promotion feature, go to “<strong>Implementer</strong> Setup and <strong>Administration</strong>” on page 216 and<br />
complete the <strong>Implementer</strong> setup as described.<br />
Enable Promotions From <strong>MKS</strong> Integrity<br />
This is an optional feature that allows you to create and promote <strong>Implementer</strong> requests from<br />
within <strong>MKS</strong> Integrity. This feature has setup tasks in both <strong>MKS</strong> Integrity and <strong>Implementer</strong>.<br />
This section describes the setup tasks required in <strong>MKS</strong> Integrity. For details on the<br />
<strong>Implementer</strong> setup tasks, see “Enable Promotions From <strong>MKS</strong> Integrity” on page 242. For an<br />
overview of the feature, see “Promoting <strong>Implementer</strong> Requests From <strong>MKS</strong> Integrity” on<br />
page 201.<br />
Review and perform the following <strong>MKS</strong> Integrity setup requirements:<br />
Verify that the states applicable to your use of this feature exist within your<br />
<strong>MKS</strong> Integrity workflow. Add the states needed.<br />
Verify an e-mail server is defined in the <strong>MKS</strong> Integrity im.properties or<br />
is.properties file (for problem notification).<br />
Verify an e-mail address exists for the <strong>MKS</strong> Integrity user ID responsible for changing<br />
issue states that cause the creation of promotion requests (for problem notification).<br />
Modify a JavaScript file with user-defined values.<br />
Add a new trigger for the state change.<br />
Basic information on completing these tasks is described next. For detailed information, see<br />
the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
Modifying the JavaScript File<br />
The JavaScript file PromoteIssue.js. is located in the default directory:<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
If the <strong>MKS</strong> Integrity Server is running with debug log enabled, the actual commands that are<br />
executed from the script display in the log. The debug log is enabled through the<br />
logger.properties file located in the directory /config/properties.<br />
TIP <strong>MKS</strong> recommends you have someone with JavaScript skills perform the script<br />
modifications.<br />
To modify the JavaScript File<br />
1 Open file PromoteIssue.js using any text editor.<br />
2 Set the following variables defined in the script. Use the comments embedded in the file<br />
to help determine how to set the values. Specify the following values:<br />
iSeriesName is the iSeries system to connect to where <strong>Implementer</strong> is installed. This<br />
can be the TCP/IP host name or the IP address.<br />
userProfile is the <strong>Implementer</strong> user profile on the iSeries that is used to connect to<br />
the system, for example MWIPROD.<br />
NOTE This user profile is for internal purposes—promotions are not submitted by<br />
this user profile. Promotions are submitted using the user profile that changed the<br />
issue state.<br />
userPassword is the password for the <strong>Implementer</strong> user profile defined in the<br />
userProfile variable.<br />
implementerLibraryList is the <strong>Implementer</strong> library list used to run <strong>Implementer</strong><br />
commands.<br />
You can optionally change the following variables in the script:<br />
createRequestCommand is the command that creates and submits the <strong>Implementer</strong><br />
promotion request. You can change any of the command parameters except<br />
FRMLIB, FRMENV, and MBROBJ, which require the value *CLIPBOARD. The<br />
OPTIMIZE parameter defaults to *YES. You can change the value to *NO if<br />
necessary. For details on this topic, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
fromEmail is the e-mail address that sends an e-mail to notify when a problem is<br />
detected on the iSeries.<br />
3 Save any changes to the file. The JavaScript does not require compiling.<br />
Creating an Event Trigger<br />
The event trigger you define in <strong>MKS</strong> Integrity must be rule based. It is used to call the<br />
supplied JavaScript code, which in turn establishes a connection to the specified iSeries<br />
system and issues several <strong>Implementer</strong> commands to create and submit the promotion<br />
requests on the iSeries.<br />
213
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
214<br />
The following tasks describe how to define the trigger for this feature. For details on event<br />
triggers, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
To define an event trigger<br />
1 Open an <strong>MKS</strong> Integrity <strong>Administration</strong> Client session and navigate to the Triggers view.<br />
2 Do one of the following to display the Type panel on the Create Trigger dialog box:<br />
Select Trigger > Create.<br />
Right click and select Create.<br />
Click .<br />
3 In the Name field, specify a name for the new trigger, for example, Promote Issue.<br />
4 Select Rule Based Change Trigger.<br />
5 (Optional). To enter a description for the event trigger, click the Description tab.<br />
6 On the Description panel, specify a description in the field.<br />
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.<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
A prime field, indicated by a prime symbol ('), specifies a new value or condition<br />
for the selected field, and primarily captures a change from one condition to<br />
another. For example, in a workflow with the states Submitted > In<br />
Development > Ready for QA > In QA > Release, the rule based trigger<br />
performs the action whenever an issue is changed to the Ready for QA state<br />
(State'=Ready for QA).<br />
You can define the trigger to any state change that is defined to the <strong>MKS</strong> Integrity<br />
workflow.<br />
b) From the Operator list, select the equal to (=) operator.<br />
c) Select the Constant option. This allows you to select a state value for the field<br />
specified in the Field list, for example, Ready for QA.<br />
Be sure to select the state that corresponds to when you want the trigger to run.<br />
The trigger runs when the issue state changes to this value.<br />
d) Click Add to add the condition to the rule.<br />
8 To select the JavaScript for the new trigger, click the Trigger tab. The Trigger panel<br />
displays.<br />
215
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
216<br />
9 To specify the script file the event trigger runs, do one of the following:<br />
a) In the Script File field, type PromoteIssue.js (the name of the JavaScript file).<br />
a) Click Browse to select the file from the Select Trigger Scripts viewer.<br />
10 Enable the Post option to schedule the trigger to run after the state changes to the<br />
specified value.<br />
11 Click OK to create the trigger.<br />
You are ready to perform the <strong>Implementer</strong> setup and administration tasks as described next.<br />
<strong>Implementer</strong> Setup and <strong>Administration</strong><br />
The <strong>Implementer</strong> Server is the foundation for many Java-based processes invoked by<br />
<strong>Implementer</strong>. It is the gateway to <strong>MKS</strong> Integrity integration. The <strong>Implementer</strong> Server<br />
significantly reduces the scope of effort involved with managing the integrations between<br />
<strong>Implementer</strong>, <strong>MKS</strong> Integrity, and <strong>MKS</strong> Source. Flexible by design, <strong>Implementer</strong> Server<br />
supports running one or more copies of <strong>Implementer</strong> on one iSeries system integrated with a<br />
single copy of <strong>MKS</strong> Integrity. It also allows <strong>MKS</strong> Integrity to remain active when<br />
<strong>Implementer</strong> is shut down for a backup.<br />
After converting from DesignTracker to <strong>MKS</strong> Integrity and completing the <strong>MKS</strong> Integrity<br />
setup and administration tasks, you are ready to perform the <strong>Implementer</strong> setup and<br />
administration tasks. These tasks include:
“Configuring the <strong>Implementer</strong> Server” on page 217.<br />
“Managing <strong>Implementer</strong> Server” on page 223.<br />
“Defining <strong>MKS</strong> Integrity Values in <strong>Implementer</strong>” on page 226.<br />
“State Setup in <strong>Implementer</strong>” on page 232.<br />
“User Profile Setup” on page 235.<br />
“Environment Setup” on page 237.<br />
“Enable Promotions From <strong>MKS</strong> Integrity” on page 242.<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
If you use the release management features of <strong>Implementer</strong>, you must also compete the<br />
field mapping as described in the table beginning on page 231.<br />
Complete the setup tasks in the order listed. For a checklist of the tasks required to configure<br />
the <strong>Implementer</strong> and <strong>MKS</strong> Integrity integration, see “<strong>MKS</strong> Integrity Integration Setup: Task<br />
Checklist” on page 295.<br />
When performing these tasks, <strong>Implementer</strong> validates the supplied information with<br />
<strong>MKS</strong> Integrity. This requires active communications between the two products. For<br />
information on managing the <strong>Implementer</strong> Server, see page 223.<br />
Configuring the <strong>Implementer</strong> Server<br />
The <strong>Implementer</strong> Server runs on the iSeries. A single <strong>Implementer</strong> Server functions for a<br />
single installation of <strong>Implementer</strong>.<br />
The server automatically installs into the default IFS installation directory on the iSeries<br />
when you initially install or upgrade <strong>Implementer</strong>. The default installation directory is:<br />
/<strong>MKS</strong>/<strong>Implementer</strong>/<strong>MKS</strong>IM/server<br />
The <strong>Implementer</strong> Server can also run on the following platforms:<br />
PC running Windows 2000 Server, Windows 2003 Server, or Windows XP Professional,<br />
in close physical proximity (and a local Ethernet connection) to the iSeries.<br />
Integrated xSeries (IXS) running Windows 2000 Server, Windows 2003 Server, or<br />
Windows XP Professional.<br />
For details on installing and configuring <strong>Implementer</strong> Server to run on a PC, see “Install<br />
and Configure <strong>Implementer</strong> Server on a PC” on page 220. Follow the same instructions<br />
to run the server on an IXS.<br />
IMPORTANT When running <strong>Implementer</strong> Server on a PC, the tasks associated with<br />
installing, upgrading, and running the server are manual.<br />
UNIX variants. For information on installing and configuring <strong>Implementer</strong> Server to run<br />
on UNIX, see “Install and Configure <strong>Implementer</strong> Server on UNIX” on page 222.<br />
217
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
218<br />
If you have any third party exit program packages installed to augment system security, you<br />
must configure the programs to allow:<br />
ODBC/JDBC communication.<br />
Remote command execution (using client access/iSeries access server).<br />
You must define the exit programs to allow communication from the system <strong>Implementer</strong><br />
runs on, which may be a localhost, and the user profile specified in the IMCMNUSR data<br />
area (MWIPROD is the default data area value).<br />
Configure <strong>Implementer</strong> Server on the iSeries<br />
The <strong>Implementer</strong> server requires Java Virtual Machine (JVM) 1.4 installed on the iSeries. JVM<br />
1.4 requires OS/400 V5R1 or later, or i5/OS V5R3 or later.<br />
This task allows you to define the control parameters for the <strong>Implementer</strong> Server. Your<br />
<strong>Implementer</strong> user profile must have authority to System Control Maintenance to perform the<br />
following setup tasks.<br />
To configure the <strong>Implementer</strong> Server<br />
1 From the <strong>Implementer</strong> Menu, type option 49, <strong>Implementer</strong> Server, and press ENTER.<br />
2 Complete the fields as described in the following table. When you have finished entering<br />
the information, press ENTER.
Field Name Description<br />
<strong>Implementer</strong> Server Setup Field Descriptions<br />
Current Status Current status of <strong>Implementer</strong> Server.<br />
Use <strong>Implementer</strong><br />
Server<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
Started: Communications between <strong>Implementer</strong> Server and <strong>Implementer</strong><br />
are active.<br />
Starting: Communications between <strong>Implementer</strong> Server and <strong>Implementer</strong><br />
are in the process of being activated.<br />
Stopped: Communications between <strong>Implementer</strong> Server and<br />
<strong>Implementer</strong> are currently not active.<br />
Suspended: Communications between <strong>Implementer</strong> Server and<br />
<strong>Implementer</strong> are on stand-by.<br />
Specify whether <strong>Implementer</strong> Server is configured to perform specific<br />
functionality within <strong>Implementer</strong>.<br />
Y: <strong>Implementer</strong> Server is configured.<br />
N: <strong>Implementer</strong> Server is not configured.<br />
Host address Specify the IP address or host name of the system running <strong>Implementer</strong><br />
Server. This address is used for all communications between <strong>Implementer</strong><br />
and <strong>Implementer</strong> Server.<br />
Valid characters are A–Z, a–z, 0–9, dash (-), underscore (_), and period (.).<br />
The default value is localhost. Case usage is not significant. The host<br />
address is not validated.<br />
Do not enclose the IP address in quotes. For example, 192.168.10 is a<br />
valid address; "192.168.10" is an invalid address. Do not specify a URL<br />
that begins with HTTP:// or HTTPS://.<br />
Server port Specify a unique number between 1 and 65535 for the HTTP port<br />
<strong>Implementer</strong> Server listens on. <strong>MKS</strong> recommends you use a number higher<br />
than 1024. The default value is 8080.<br />
Adapter port Specify a unique number between 1 and 65535 for the port <strong>Implementer</strong><br />
uses to communicate with <strong>Implementer</strong> Server. <strong>MKS</strong> recommends you use<br />
a number higher than 1024. The default value is 54545.<br />
Logging level Specify the level of detail for <strong>Implementer</strong> Server to log.<br />
*INFO logs all informational and warning messages. This is the default<br />
value.<br />
*WARN logs warning messages only.<br />
*DEBUG logs all messages. This level should be used only when<br />
instructed by <strong>MKS</strong> Customer Care.<br />
Startup delay Specify the number of seconds <strong>Implementer</strong> waits between communication<br />
attempts once the start command is issued to start <strong>Implementer</strong> Server.<br />
The default value is 30.<br />
Startup retry count Specify the number of times to retry communications before ending the job<br />
with a communication failure. The default value is 5.<br />
Log files to retain Specify the number of days worth of log files to retain in the <strong>Implementer</strong><br />
Server logs directory. The cleanup task runs every six (6) hours to remove<br />
old files. Specify zero (0) to retain all log files. The default value is 30 (days).<br />
219
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
220<br />
Field Name Description<br />
Time zone offset Specify the number of hours difference between this system and Greenwich<br />
Mean Time (GMT). For example, a system located in Central Standard Time<br />
(CST) has the offset value -6. Valid values are -12 through +12, or<br />
*SYSVAL, which allows you to use the Coordinated Universal Time Offset<br />
(QUTCOFFSET) system value.<br />
The time zone offset is required for <strong>Implementer</strong> and <strong>MKS</strong> Integrity to be<br />
relatively synchronized in time. For example, if <strong>Implementer</strong> is located in the<br />
Central time zone and <strong>MKS</strong> Integrity is in the Eastern time zone, there is<br />
one hour difference between the two servers. By defining the time zone<br />
offset, a change package’s date and time fields are correctly represented in<br />
the time zone where the server is located.<br />
IMPORTANT You must restart <strong>Implementer</strong> Server to effect changes to the time<br />
zone offset value.<br />
Install and Configure <strong>Implementer</strong> Server on a PC<br />
<strong>Implementer</strong> Server can run on a PC or an Integrated xSeries (IXS) running Windows 2000<br />
Server, Windows 2003 Server, or Windows XP Professional. When installed on a PC,<br />
<strong>Implementer</strong> Server runs as a service to ensure it starts automatically when the PC starts.<br />
<strong>Implementer</strong> Server can run from any location except the desktop. The desktop is regarded as<br />
a user’s private space, and as such, you should not run system processes and services from it.<br />
<strong>MKS</strong> recommends you install it in a directory near the root, for example,<br />
c:/<strong>Implementer</strong>_200x_Server.<br />
IMPORTANT<br />
<strong>MKS</strong> recommends you install the latest Database Group PTF, obtainable from<br />
IBM, before running the <strong>Implementer</strong> Server on a PC.<br />
When running <strong>Implementer</strong> Server as a service on a PC, you must manually<br />
perform the tasks associated with installing and upgrading the server, and the<br />
initial startup of the service.<br />
After initially installing <strong>Implementer</strong> and after each subsequent upgrade, you<br />
must manually copy the server directories to the PC and install the service.<br />
The tasks associated with setting up <strong>Implementer</strong> Server to run on a PC or IXS are as follows:<br />
Manually copy the server directory from the IFS installation location on the iSeries to the<br />
target PC.<br />
Configure the <strong>Implementer</strong> properties file with system-specific values.<br />
Install the NT service.<br />
<strong>Implementer</strong> Server Setup Field Descriptions
To copy <strong>Implementer</strong> Server from the iSeries to the target PC<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
1 Sign on to the iSeries with a user profile that has authority to access the <strong>Implementer</strong><br />
Server directory, for example, use a *SECOFR user profile. The default, IFS installation<br />
location of the <strong>Implementer</strong> Server is:<br />
/<strong>MKS</strong>/<strong>Implementer</strong>/<strong>MKS</strong>IM/server<br />
2 Using a tool such as Windows Explorer or iSeries Navigator, copy the entire<br />
<strong>Implementer</strong> Server directory from the IFS on the iSeries to the target PC. You may need<br />
to map to the drive first. Be sure to include /ROOT in the directory path of the target<br />
location.<br />
To configure <strong>Implementer</strong> Server properties file<br />
1 In the root of the <strong>Implementer</strong> Server directory on the target PC, locate the<br />
<strong>Implementer</strong>Server.properties file.<br />
2 Using a standard text editor, such as Notepad, open<br />
<strong>Implementer</strong>Server.properties.<br />
3 Modify the following variables based on the system where <strong>Implementer</strong> is installed:<br />
IMPLEMENTER_HOST is the host name or IP address of the iSeries.<br />
IMPLEMENTER_LIBRARY is the <strong>Implementer</strong> product library. <strong>Implementer</strong> ships in<br />
library <strong>MKS</strong>IM.<br />
IMPLEMENTER_USER is the user ID authorized to the <strong>Implementer</strong> product library.<br />
It must correspond to the user ID defined in the IMCMNUSR data area in the<br />
<strong>Implementer</strong> product library on the iSeries.<br />
This user ID must have *CHANGE authority to all <strong>Implementer</strong> database files.<br />
<strong>MKS</strong> recommends you use the default user profile MWIPROD.<br />
IMPLEMENTER_PASSWORD is the password for the IMPLEMENTER_USER. It must<br />
correspond to the password defined in the IMCMNUSR data area.<br />
INTEGRITY_CLIENT_PORT is the port that all workstations running <strong>MKS</strong> Integrity<br />
Client Client listen on when invoking GUI functions from <strong>Implementer</strong> or WDSc,<br />
for example, issue display, annotated view, or member history. All workstations<br />
running <strong>MKS</strong> Integrity Client that invoke GUI functions from <strong>Implementer</strong> must be<br />
listening on the same port. The default value is 31000. This is an optional property.<br />
Once you configure these values in the properties file, delete the NOT_CONFIGURED<br />
line from the file.<br />
4 Save the changes and close the file.<br />
221
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
222<br />
To install the <strong>Implementer</strong> Server service<br />
1 Optionally modify the install-service.bat file as follows:<br />
The default service name of the server is <strong>MKS</strong> <strong>Implementer</strong> Server. Change the<br />
SERVICENAME environment variable to specify a different service name. This is only<br />
necessary if more than one <strong>Implementer</strong> server is running on a single PC.<br />
To explicitly define the directory where the server runs, change the SERVERDIR<br />
environment variable as needed.<br />
2 Execute the install-service.bat file. This removes the existing <strong>Implementer</strong> Server<br />
service if it is already set up and installs a new service with any new parameters you<br />
optionally defined.<br />
IMPORTANT After performing an upgrade to the <strong>Implementer</strong> Server, you must reinstall<br />
the <strong>Implementer</strong> Server service by running the install-service.bat file.<br />
If you previously modified the file, for example, changed the service name, you<br />
must re-enter the changes before executing the file.<br />
Install and Configure <strong>Implementer</strong> Server on UNIX<br />
<strong>Implementer</strong> Server includes the script runserver.sh that allows you to install and run the<br />
server on a variety of UNIX variants. This document assumes Solaris.<br />
Installing and configuring <strong>Implementer</strong> Server on UNIX requires the assistance of someone<br />
who is familiar with both the iSeries and UNIX, including basic shell operation. It also<br />
requires:<br />
Java Runtime Environment (JRE) 1.4, appropriate for the system, must be installed.<br />
To verify the JRE version, issue the ‘java -version’ command. You can download<br />
many JREs from http://java.com/en/download.<br />
A standard shell scripting language, for example, sh, ksh, bash.<br />
To install <strong>Implementer</strong> Server on UNIX<br />
1 Using your preferred copy method, copy the entire <strong>Implementer</strong> Server subdirectory<br />
from the IFS on the iSeries to the new directory on the UNIX system. The default, IFS<br />
installation location of <strong>Implementer</strong> Server is:<br />
/<strong>MKS</strong>/<strong>Implementer</strong>/<strong>MKS</strong>IM/server<br />
If using FTP, you must use ASCII mode for all files that have .properties, .policy,<br />
.sh, and .xml extensions.<br />
2 Optional: Turn on the execute permission on the runserver.sh script using chmod.<br />
3 Optional: Delete the JRE subdirectory from the server directory (it applies to Windows<br />
systems only).
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
4 Configure <strong>Implementer</strong> Server as described in “Configuring the <strong>Implementer</strong> Server” on<br />
page 217.<br />
5 Configure the <strong>Implementer</strong> Server properties file as described on page 221.<br />
Managing <strong>Implementer</strong> Server<br />
The <strong>Implementer</strong> Server runs based on the values you have defined in <strong>Implementer</strong> Menu<br />
option 49, <strong>Implementer</strong> Server. To ensure sufficient access to the <strong>Implementer</strong> database, the<br />
server job runs under the <strong>Implementer</strong> user profile MWIPROD.<br />
The server must be active for successful communications with <strong>MKS</strong> Integrity and<br />
<strong>MKS</strong> Source. When you install the server on the iSeries, the <strong>Implementer</strong> Server Control<br />
(ICTLSVR) command allows you to start, stop, suspend, and resume the server. The reload<br />
option allows you to reload the server with current configuration and environment<br />
information if communications failed initially. The command also provides status and job<br />
information when the server is active.<br />
<strong>MKS</strong> recommend you add the ICTLSVR command to your normal daily startup routine to<br />
ensure it activates on IPL (Initial Program Load) by the QSTRTUP program. The user profile<br />
that issues the ICTLSVR command must have authority to System Control Maintenance.<br />
Whenever you make a change to the <strong>MKS</strong> Integrity Server, for example, changes to<br />
workflow, workflow authorities, or state capabilities, you must restart <strong>Implementer</strong> Server.<br />
For information on managing the <strong>Implementer</strong> server on a PC, see page 224.<br />
NOTE The <strong>Implementer</strong> data area IMSRVJVA provides the ability to customize<br />
certain aspects of <strong>Implementer</strong> Server. However, this is usually not necessary;<br />
therefore, <strong>MKS</strong> recommends you change the data area values only when instructed<br />
by <strong>MKS</strong> Customer Care.<br />
ICTLSVR Command Parameters<br />
Command<br />
Specify the command action to perform.<br />
*START Activates the server. The server job runs under the default user profile<br />
MWIPROD. This option is not available if the server is running on a PC.<br />
*STOP Shuts down the server. You must stop the server to upgrade or reinstall<br />
<strong>Implementer</strong>.<br />
*SUSPEND Disconnects the JDBC connections from the <strong>Implementer</strong> database to<br />
release resources. Disables requests to <strong>Implementer</strong> by returning a soft<br />
error. This allows you to secure a backup of the <strong>Implementer</strong> product<br />
library.<br />
223
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
224<br />
*RESUME Reconnects the JDBC to the <strong>Implementer</strong> database. Re-enables requests<br />
to <strong>Implementer</strong>.<br />
*STATUS When <strong>Implementer</strong> server is active, reports the current status of the<br />
server and related job information.<br />
*RELOAD Reloads <strong>Implementer</strong> server with current information. Use manually to<br />
reload configuration information, or programmatically to reload<br />
environment information for <strong>MKS</strong> Source integration.<br />
Job Queue/Library<br />
Specify the name of the job queue and corresponding library that <strong>Implementer</strong> server runs in.<br />
The server job activates in this job queue. The default value is IMCOM, a job queue delivered<br />
in the <strong>Implementer</strong> product library <strong>MKS</strong>IM. These parameters are required for the *START<br />
command option.<br />
Managing <strong>Implementer</strong> Server on a PC<br />
The <strong>Implementer</strong> Server service starts automatically when the PC starts. If you need to<br />
manually start the server, from the Windows Control Panel in the System <strong>Administration</strong><br />
group, use the Services application to start the <strong>MKS</strong> <strong>Implementer</strong> Server service (or the<br />
service name you specified if you changed the default value).<br />
Managing <strong>Implementer</strong> Server on UNIX<br />
You must perform the following steps when starting <strong>Implementer</strong> Server. You can optionally<br />
automate this task by including the steps in the system startup script.<br />
To execute <strong>Implementer</strong> Server on UNIX<br />
1 Set the JAVA_HOME environment variable to identify the root location of the JRE.<br />
a) If the Java executable is located in /usr/local/java/jre-1.4.1_02/bin/java,<br />
then set the JAVA_HOME environment variable to /usr/local/java/jre-<br />
1.4.1_02.<br />
b) Optional: You can update the runserver.sh script to include a hard coded<br />
reference to the JAVA_HOME variable.<br />
2 Do one of the following:<br />
If you enabled the execute permission bit in setup, then invoke the runserver.sh<br />
script directly from the command line.<br />
If you did not enable the execute permission bit in setup, then invoke the<br />
runserver.sh script by invoking sh runserver.sh.
<strong>Implementer</strong> Server Patches and PTFs<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
<strong>Implementer</strong> provides patches for <strong>Implementer</strong> Server in the standard <strong>Implementer</strong> PTF<br />
format. When a patch for <strong>Implementer</strong> Server is included with a PTF, the PTF installer<br />
automatically installs the patch into the server directory.<br />
The patches usually distribute as CLASS files (as opposed to JAR files) to allow applying<br />
incremental patches. The class files install into the IFS location:<br />
/mks/implementer//webapps/ROOT/WEB-INF/classes<br />
IMPORTANT If <strong>Implementer</strong> Server runs on a PC, after applying a patch you need to<br />
recopy the server from the IFS to the system where the server runs. Follow the same<br />
instructions as when initially installing the server. You do not need to reinstall the<br />
service.<br />
When you apply an <strong>Implementer</strong> Server patch, a marker file is created in the ‘info’<br />
subdirectory. The marker file identifies which issue the patch applies to. If you apply<br />
multiple patches, then multiple marker files are created in the subdirectory. The marker file is<br />
in the form IMPTFnnnn, where nnnn is the issue number associated with the PTF.<br />
Troubleshooting <strong>Implementer</strong> Server<br />
If you encounter errors with <strong>Implementer</strong> Server, the <strong>Implementer</strong> Server log files register<br />
server activity based on the logging level you define in <strong>Implementer</strong> Menu option 49,<br />
<strong>Implementer</strong> Server.<br />
Server activity for the current date is stored in file implementer-server.log. When the<br />
current date changes, implementer-server.log renames to a date differentiated file name,<br />
and an empty implementer-server.log file is created. The server log files are purged<br />
based on the number of days you specify to retain on the <strong>Implementer</strong> Server Setup panel.<br />
When <strong>Implementer</strong> Server runs on the iSeries, the server log files are stored in the<br />
/logs sub-directory of the IFS. The <strong>Implementer</strong> Display Server Log (IDSPSVRLOG)<br />
command allows you to view history logs. The command has one parameter, DATE,<br />
which accepts the value *CURRENT, or a specific date you enter in YYYYMMDD<br />
format.<br />
IMPORTANT Your user profile must have authority to System Control Maintenance to<br />
issue the IDSPSVRLOG command.<br />
When <strong>Implementer</strong> Server runs on a PC, the log files are stored in the /logs subdirectory<br />
on the PC. You can view the history logs using any standard text editor, such<br />
as Notepad.<br />
225
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
226<br />
<strong>Implementer</strong> Server must be able to communicate with <strong>MKS</strong> Integrity Server for the<br />
integration to work successfully.<br />
A common diagnostic technique when resolving <strong>MKS</strong> Integrity connectivity issues is to<br />
ping the hostname (or IP address) of <strong>MKS</strong> Integrity Server. This technique is effective<br />
provided you ping the server from the correct host.<br />
When <strong>Implementer</strong> Server is installed on an iSeries, the iSeries must be able to<br />
communicate with <strong>MKS</strong> Integrity Server.<br />
When <strong>Implementer</strong> Server is installed on a PC, that PC must be able to<br />
communicate with <strong>MKS</strong> Integrity Server. In this case, the iSeries is not actually<br />
communicating with <strong>MKS</strong> Integrity Server, thus, it is meaningless if you can ping<br />
<strong>MKS</strong> Integrity Server from the iSeries.<br />
If you have Windows XP Service Pack 2 (SP2) installed on the system running<br />
<strong>Implementer</strong> Server, the firewall built into SP2 could interfere with server<br />
communications. You may need to adjust the firewall to allow connections on the Server<br />
and Adapter ports, or disable it entirely.<br />
For additional troubleshooting information, see the table on page 302.<br />
Defining <strong>MKS</strong> Integrity Values in <strong>Implementer</strong><br />
The <strong>MKS</strong> Integrity communication parameters are defined in <strong>Implementer</strong> on the<br />
<strong>MKS</strong> Integrity Setup panel.<br />
Your <strong>Implementer</strong> user profile must have authority to maintain System Control (defined in<br />
Work with Users) to change the default values on the <strong>MKS</strong> Integrity Setup panel. Without<br />
this authority, changes are not allowed and the panel is protected.<br />
To define <strong>MKS</strong> Integrity values in <strong>Implementer</strong><br />
1 From the <strong>Implementer</strong> Menu, type option 47, <strong>MKS</strong> Integrity, and press ENTER, or issue<br />
the STRIM *INTMGRSET command.
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
You can perform the following functions on the <strong>MKS</strong> Integrity Setup panel.<br />
F3=Exit returns to the <strong>Implementer</strong> Menu without processing any information.<br />
F6=State setup displays the <strong>MKS</strong> Integrity State Setup panel to create and modify<br />
<strong>MKS</strong> Integrity promotion path state information. For details, see “State Setup in<br />
<strong>Implementer</strong>” on page 232.<br />
F7=Test allows you to test the communications between <strong>Implementer</strong> Server and<br />
<strong>MKS</strong> Integrity Server. Sets the System Available field status based on the result.<br />
F8=Configure <strong>MKS</strong> Integrity updates <strong>MKS</strong> Integrity with the <strong>Implementer</strong>-related<br />
state based capabilities that control check out and promotion. You perform this<br />
function once as part of the initial setup. Thereafter, use it to add additional *QAC<br />
paths through F6=State Setup. There is no risk in running this function multiple<br />
times. For details on using this function, see page 234. For a list of the capabilities<br />
this function adds to <strong>MKS</strong> Integrity, see “<strong>Implementer</strong> State-based Capabilities” on<br />
page 208.<br />
F9=Apply Pending Changes synchronizes <strong>Implementer</strong> with <strong>MKS</strong> Integrity by<br />
applying any pending updates that were postponed when the <strong>MKS</strong> Integrity<br />
emergency update mode was active. For details on using this function, see<br />
“Applying Pending Changes” on page 257.<br />
F12=Cancel returns to the previous panel without processing any options.<br />
227
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
228<br />
F20=Convert to <strong>MKS</strong> Integrity converts the issue management system from<br />
DesignTracker to <strong>MKS</strong> Integrity. For details, see “Converting From DesignTracker<br />
to <strong>MKS</strong> Integrity” on page 243.<br />
IMPORTANT<br />
Other than completely restoring from a backup, you cannot reverse the results of<br />
invoking this function. Therefore, you must review all related documentation in<br />
this chapter before running a conversion. When you process the function, two<br />
confirmation panels display; the panels include important information on the<br />
function you are about to perform and require a reply. You can cancel the<br />
procedure from either of the panels.<br />
This function does not convert DesignTracker data. For details on converting<br />
data, see page 431.<br />
2 Complete this panel as described “<strong>MKS</strong> Integrity Setup Field Descriptions” on page 228.<br />
(Press PAGE DOWN to access the additional panels.)<br />
3 When you are finished adding the information, press ENTER.<br />
4 To ensure communications are active and the setup you have defined is usable by<br />
<strong>Implementer</strong>, press F7=Test.<br />
5 To configure <strong>MKS</strong> Integrity with the <strong>Implementer</strong> capabilities, press F8=Configure<br />
<strong>MKS</strong> Integrity.<br />
After completing this task, you are ready to perform “State Setup in <strong>Implementer</strong>” as<br />
described on page 232.<br />
Field Description<br />
<strong>MKS</strong> Integrity Setup Field Descriptions<br />
Issue Management System Identifies which product is configured to supply <strong>Implementer</strong> with<br />
issue tracking information and represents the current issue<br />
management system. The default value DesignTracker verifies that<br />
DesignTracker provides all issue information. The value<br />
<strong>MKS</strong> Integrity verifies that <strong>MKS</strong> Integrity provides all issue<br />
information.<br />
The field is input protected. The only way to change the value from<br />
DesignTracker to <strong>MKS</strong> Integrity is by running the conversion that sets<br />
<strong>MKS</strong> Integrity as the default system. Once, converted, there is no<br />
way to change the value back to DesignTracker.<br />
For the integration described in this chapter, the field value must be<br />
<strong>MKS</strong> Integrity. If this is not the value, see “Converting From<br />
DesignTracker to <strong>MKS</strong> Integrity” on page 243.
Field Description<br />
<strong>MKS</strong> Integrity Setup Field Descriptions<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
<strong>MKS</strong> Integrity Current Status Identifies the current status of <strong>MKS</strong> Integrity. Automatically updated<br />
through communication attempts (input is not allowed).<br />
System available indicates whether <strong>MKS</strong> Integrity was available on<br />
the last attempt to communicate.<br />
Yes: Communication between <strong>MKS</strong> Integrity and <strong>Implementer</strong> was<br />
successful.<br />
No: Communication between <strong>MKS</strong> Integrity and <strong>Implementer</strong> was<br />
unsuccessful.<br />
Pending changes indicates whether <strong>Implementer</strong> ran in emergency<br />
update mode when <strong>MKS</strong> Integrity was unavailable and if updates are<br />
pending that need to be applied to <strong>MKS</strong> Integrity.<br />
Yes: New changes exist that need to be sent to <strong>MKS</strong> Integrity for<br />
database synchronization. For details, see “Applying Pending<br />
Changes” on page 257.<br />
No: No new changes need to be sent to <strong>MKS</strong> Integrity.<br />
<strong>MKS</strong> Integrity Connection Setup<br />
The following fields define the communication parameters that allow <strong>Implementer</strong> to work with<br />
<strong>MKS</strong> Integrity and <strong>MKS</strong> Integrity Server.<br />
Communications timeout Number of seconds <strong>Implementer</strong> waits for a valid response after<br />
contacting the <strong>MKS</strong> Integrity Server. Only used when <strong>MKS</strong> Integrity<br />
is the issue management system.<br />
If communications between <strong>Implementer</strong> and <strong>MKS</strong> Integrity Server<br />
are slow, set this to a higher number to prevent time-outs during<br />
normal usage, such as if <strong>MKS</strong> Integrity Server is available but not<br />
responding in a timely manner due to heavy traffic or running a large<br />
query.<br />
Server Address of <strong>MKS</strong> Integrity Server. This server address must be<br />
reachable from the iSeries, as well as work within a clients Web<br />
browser. It is used to construct a URL.<br />
Specify either the IP address or a name that both the Domain Name<br />
Server (DNS) on the iSeries and each client’s Web browser can<br />
resolve.<br />
Valid characters are A–Z, a–z, 0–9, dash (-), underscore (_), and<br />
period (.). Case usage is not verified.<br />
Do not enclose the server address in quotes. For example,<br />
127.0.0.1 is a valid address, "127.0.0.1" is an invalid address.<br />
Server browser port Port number for the <strong>MKS</strong> Integrity Web interface; the port<br />
<strong>Implementer</strong> uses to access the <strong>MKS</strong> Integrity Web interface from<br />
<strong>Implementer</strong> panels. Commonly referred to as the Integrity Server<br />
Port. It must be different from the Server <strong>Implementer</strong> Port.<br />
If the Server field is defined, this is a required field and the value<br />
must be between 1 and 65535. The default value in the property file<br />
is 7001.<br />
229
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
230<br />
Field Description<br />
Server cleanup frequency Number of minutes <strong>Implementer</strong> waits between the end of an<br />
<strong>MKS</strong> Integrity transaction and when the transaction is cleared from<br />
the database.<br />
<strong>MKS</strong> Integrity user ID User ID used for all communication between <strong>Implementer</strong> Server and<br />
<strong>MKS</strong> Integrity Server. This must be the same user ID as described<br />
and specified in “Configuring <strong>MKS</strong> Integrity Server ACLs” on<br />
page 205. This user ID is also used by the IUPDCI command to post<br />
updates back to <strong>MKS</strong> Integrity Server.<br />
Field entry is case sensitive; the case specified in <strong>MKS</strong> Integrity must<br />
be specified here.<br />
Password Password of the <strong>MKS</strong> Integrity user ID specified in the previous field<br />
and required for all communications between <strong>Implementer</strong> Server<br />
and <strong>MKS</strong> Integrity Server. Non display field that displays as blank<br />
when typing the password value.<br />
Description field User-defined issue description field within <strong>MKS</strong> Integrity, for<br />
example, Summary. Contents of this field displays as the long<br />
description for an issue on <strong>Implementer</strong> panels. Entry in this field is<br />
optional. Case specified in <strong>MKS</strong> Integrity must be specified here. The<br />
field must be type Long Text.<br />
<strong>Implementer</strong> project field For <strong>Implementer</strong> project tracking in <strong>MKS</strong> Integrity, specify the name<br />
of the user defined field within <strong>MKS</strong> Integrity that contains the<br />
<strong>Implementer</strong> project field. The case usage specified here must match<br />
the case usage applied to the field in <strong>MKS</strong> Integrity.<br />
This field value must be defined in <strong>MKS</strong> Integrity as Short Text or<br />
Pick data type with a maximum length of seven characters (the field<br />
name can be longer). Any project values in <strong>MKS</strong> Integrity must be<br />
added manually to <strong>Implementer</strong>.<br />
After selecting an issue in <strong>Implementer</strong> using F4=Prompt, the<br />
appropriate project field populates with the value from <strong>MKS</strong> Integrity.<br />
The project reference displays on select <strong>Implementer</strong> panels, for<br />
example, the Workbench and Work with Objects.<br />
iSeries notify user The iSeries user profile to notify when the state of the connection to<br />
<strong>MKS</strong> Integrity changes to either available or unavailable. User is also<br />
notified with the results of the update process when you run a<br />
synchronization using F9=Apply pending changes.<br />
Allow co-existence with<br />
DesignTracker<br />
<strong>MKS</strong> Integrity Setup Field Descriptions<br />
Indicates if co-existence with DesignTracker is enabled. The field is<br />
read only and only applicable if <strong>MKS</strong> Integrity is the default issue<br />
tracking system. For details on co-existence, see “Converting From<br />
DesignTracker to <strong>MKS</strong> Integrity” on page 243.<br />
Last allowed DR number Applicable only if DesignTracker co-existence is enabled. Specify the<br />
last valid design request number when DesignTracker co-existence is<br />
enabled. Any DR/Issue number higher than the specified number is<br />
considered an <strong>MKS</strong> Integrity issue.
Field Description<br />
Release Management Field Mapping<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
Define the following fields to use <strong>MKS</strong> Integrity and the release management features of <strong>Implementer</strong>.<br />
For details, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release Management <strong>Guide</strong>.<br />
Release Management<br />
Active?<br />
<strong>MKS</strong> Integrity Setup Field Descriptions<br />
Specify Y to use the release management features of <strong>Implementer</strong><br />
with <strong>MKS</strong> Integrity. Activation of this feature requires a value in each<br />
of the remaining fields.<br />
Issue type to create Type of issue to create in <strong>MKS</strong> Integrity for each release you create<br />
in release management. You must define this release type in<br />
<strong>MKS</strong> Integrity specifically for release management use.<br />
Deleted release state Issue state to assign to an issue when the corresponding release is<br />
deleted from <strong>Implementer</strong> (the issue is not deleted).<br />
Related issues field Type of relationship to add to the corresponding release issue in<br />
<strong>MKS</strong> Integrity when a new issue is added to a release management<br />
release. Leave the field blank to create a traditional relationship type.<br />
Product field Name of the user defined field within <strong>MKS</strong> Integrity that displays the<br />
product value in an issue. Field must be defined in <strong>MKS</strong> Integrity as<br />
type Long Text.<br />
Version field Name of the user defined field within <strong>MKS</strong> Integrity that displays the<br />
version in an issue. Field must be defined in <strong>MKS</strong> Integrity as type<br />
Long Text.<br />
Release field Name of the user defined field within <strong>MKS</strong> Integrity that displays the<br />
release value in an issue. Field must be defined in <strong>MKS</strong> Integrity as<br />
type Long Text.<br />
Release description Name of the user defined field within <strong>MKS</strong> Integrity that displays the<br />
release description in an issue. Field must be defined in<br />
<strong>MKS</strong> Integrity as type Long Text.<br />
Release type Name of the user defined field within <strong>MKS</strong> Integrity that displays the<br />
release type in an issue. Field must be defined in <strong>MKS</strong> Integrity as<br />
type Long Text.<br />
Release status field Name of the user defined field within <strong>MKS</strong> Integrity that displays the<br />
release status in an issue. Field must be defined in <strong>MKS</strong> Integrity as<br />
type Long Text.<br />
Open date field Name of the user defined field within <strong>MKS</strong> Integrity that displays the<br />
date a release was opened. Field must be defined in <strong>MKS</strong> Integrity<br />
as type Long Text.<br />
Open time field Name of the user defined field within <strong>MKS</strong> Integrity that displays the<br />
time a release was opened. Field must be defined in <strong>MKS</strong> Integrity<br />
as type Long Text.<br />
231
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
232<br />
Field Description<br />
State Setup in <strong>Implementer</strong><br />
<strong>MKS</strong> Integrity Setup Field Descriptions<br />
Close date field Name of the user defined field within <strong>MKS</strong> Integrity that displays the<br />
date a release was closed. Field must be defined in <strong>MKS</strong> Integrity as<br />
type Long Text.<br />
Close time field Name of the user defined field within <strong>MKS</strong> Integrity that displays the<br />
time a release was closed. Field must be defined in <strong>MKS</strong> Integrity as<br />
type Long Text.<br />
<strong>MKS</strong> Integrity is an extremely flexible tool that uses issues to manage development activities.<br />
While it allows for any number of user-defined issues, each issue is identified by a type, and<br />
each type has its own user-defined fields.<br />
<strong>MKS</strong> Integrity controls the <strong>Implementer</strong> development activities of check out and promotion<br />
through an issue’s state, and each issue type can have its own workflow of allowed state<br />
transitions.<br />
<strong>MKS</strong> Integrity associates every item that is changed with the issue it was changed for by way<br />
of an issue change package entry. Change package entries are added and updated only through<br />
<strong>Implementer</strong>’s check out and promotion activities. If checking out from multiple production<br />
environments, the changes for each environment are placed in a different change package.<br />
<strong>MKS</strong> Integrity shows the progress of a change package in <strong>Implementer</strong> development with a<br />
status. Through <strong>MKS</strong> Integrity, you are able to view the status of any member that is<br />
managed through <strong>Implementer</strong>.<br />
In <strong>Implementer</strong>, the default promotion path entries are globally defined in the <strong>MKS</strong> Integrity<br />
State Setup function. <strong>Implementer</strong> provides three default paths: *TST, *QAC1, and *PRD.<br />
You can optionally create an unlimited number of additional *QAC paths as needed, for<br />
example, *QAC2, *QAC3, *QAC4. Each promotion path entry corresponds to a user-defined,<br />
default state that is routinely assigned to an issue when all members of a change package<br />
progress through the development path, or when a member is rejected from a particular<br />
environment in the development path.<br />
If an application requires a unique status, you can override the global definitions at the<br />
environment level. When assigning issue states, <strong>Implementer</strong> processes existing environment<br />
overrides first, if none exist then it assigns the appropriate default global value based on<br />
where the environment is in the promotion path. The environment can override to a different<br />
state or can specify *NONE if no state change is desired. For information on overriding the<br />
default path, see “Environment Setup” on page 237.
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
Performing <strong>MKS</strong> Integrity State Setup requires a user profile that has authority to System<br />
Control Maintenance. The administrator typically performs this task when setting up the<br />
integration. Thereafter, you use it only to change a path’s issue state or to add or delete *QAC<br />
states. When you create a promotion path entry or change an issue state in <strong>Implementer</strong>, the<br />
issue state is validated in <strong>MKS</strong> Integrity.<br />
To configure promotion path entries with issue states<br />
1 From the <strong>Implementer</strong> Menu, type option 47, <strong>MKS</strong> Integrity, and press ENTER, or issue<br />
the command STRIM *INTMGRSET. The <strong>MKS</strong> Integrity Setup panel displays.<br />
2 Press F6=State setup. The <strong>MKS</strong> Integrity State Setup panel displays.<br />
The actions you can perform on this panel are as follows.<br />
Option 2=Change allows you to change the issue state to assign during the various<br />
stages of development. For each default promotion path entry you use, you must<br />
define the issue state to assign to an issue when the issue is in this state. To complete<br />
this task, proceed directly to step 3 page 234.<br />
Option 4=Delete allows to remove the last user-defined *QAC path entry. For<br />
example, if paths *QAC2, *QAC3, and *QAC4 exist, you must delete *QAC4 before<br />
deleting *QAC3 is allowed. Deleting any other promotion path type is not allowed.<br />
Option 5=Display allows you to view state detail for a path.<br />
233
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
234<br />
F6=State setup allows you to create a new promotion path entry on the<br />
<strong>MKS</strong> Integrity State Setup panel. It may be helpful to review “Manage States and<br />
State-based Capabilities” on page 208 before creating a new promotion path entry.<br />
IMPORTANT After adding a new *QAC path, you must update with the new state<br />
capabilities for <strong>Implementer</strong> to check for by running F8=Configure <strong>MKS</strong> Integrity.<br />
Then use <strong>MKS</strong> Integrity State Setup to assign the <strong>Implementer</strong> capabilities to the<br />
appropriate states.<br />
3 Type option 2=Change next to the promotion path, and press ENTER. The <strong>MKS</strong> Integrity<br />
State Detail panel displays.<br />
4 Complete this panel as described in the following table, and press ENTER.<br />
Field Description<br />
<strong>MKS</strong> Integrity State Detail Field Descriptions<br />
Promotion path entry Location on the promotion path the state is being set for. When adding a<br />
new path entry, the value defaults to the next *QAC environment and<br />
cannot be changed.<br />
Description Description about the path level.<br />
Issue state Issue state to assign when an item is in this promotion path location.<br />
Must be a valid state in <strong>MKS</strong> Integrity.<br />
For a *TST entry, the state is set in check out. For a *QAC or *PRD entry,<br />
the state is set after successful promotion. If the value is left blank, the<br />
issue state remains unchanged.
Field Description<br />
User Profile Setup<br />
<strong>MKS</strong> Integrity State Detail Field Descriptions<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
Issue state when rejected Issue state to set when an item in this promotion path location is<br />
rejected. Must be a valid state in <strong>MKS</strong> Integrity.<br />
Applies to *QAC path entries only. If this value is left blank, the issue<br />
state remains unchanged when rejected.<br />
For each <strong>Implementer</strong> user that uses the integration, you must define an <strong>MKS</strong> Integrity user<br />
profile and specify whether the user has authority to activate <strong>MKS</strong> Integrity emergency<br />
mode. In addition, each user that performs an <strong>Implementer</strong> check out or promotion for items<br />
associated with an <strong>MKS</strong> Integrity issue must have a valid user profile in <strong>Implementer</strong> and a<br />
valid user ID in <strong>MKS</strong> Integrity.<br />
The user’s profile can be the same for both products or it can be different. By default,<br />
<strong>Implementer</strong> uses the iSeries user profile, which may or may not be the same as the<br />
<strong>MKS</strong> Integrity user ID. If the <strong>MKS</strong> Integrity user ID is different from the iSeries user profile,<br />
you can optionally define the appropriate <strong>MKS</strong> Integrity user ID to <strong>Implementer</strong>. This allows<br />
all integrations with <strong>MKS</strong> Integrity for a user to consistently use the value specified. There is<br />
no requirement that the password be the same.<br />
<strong>MKS</strong> Integrity Emergency Mode Authority<br />
In the event <strong>MKS</strong> Integrity temporarily cannot be contacted to perform the integrations,<br />
<strong>Implementer</strong> provides a facility that allows the check out and promotion functions to<br />
continue uninterrupted. This is accomplished by activating <strong>Implementer</strong>’s emergency update<br />
mode.<br />
For example, let’s say you have changes on an active request that must be promoted<br />
immediately to correct a level check problem in production, but a communication failure<br />
between <strong>Implementer</strong> and <strong>MKS</strong> Integrity has caused the promotion to fail. By activating the<br />
emergency update mode, you can continue with all required development activities, while<br />
storing the issue updates for subsequent posting once the communications are re-established.<br />
IMPORTANT When emergency update mode is active, <strong>Implementer</strong> is unable to<br />
validate <strong>MKS</strong> Integrity information. Thus, any issue number is accepted in check<br />
out, including invalid numbers, and every promotion is allowed even if the<br />
workflow or capabilities normally prohibit it. For this reason, operating in<br />
emergency mode is not intended as a normal disconnected mode—rather it is for<br />
emergency purposes only, such as when a production environment is down and<br />
must be updated to be active again.<br />
Users must be authorized to control the emergency update mode; for security reasons, no<br />
users are authorized by default. Typically, emergency mode authority is given to select<br />
development managers and senior developers. Once authorized, the user activates and<br />
235
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
236<br />
deactivates the emergency mode through the <strong>MKS</strong> Integrity Emergency Update Active field in<br />
Work with Users, by using option 20=User Defaults, or from the Workbench by using<br />
F18=User Defaults. For details on using this feature, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Using the emergency update mode for remote initiated moves or remote compiles with host<br />
updates requires the <strong>Implementer</strong> user profile MWIPROD defined with the <strong>MKS</strong> Integrity<br />
emergency update field set to Y, and the <strong>MKS</strong> Integrity Emergency Update Active field set to Y<br />
(in User Defaults). For more information, see “Considerations for Remote Processing” on<br />
page 256.<br />
It is not necessary to have the emergency mode authority defined prior to a communication<br />
failure. When communications are down and a change must be made in <strong>Implementer</strong>, the<br />
<strong>Implementer</strong> administrator can authorize and activate the necessary user.<br />
The following task requires that the user profiles associated with this integration exist in<br />
<strong>Implementer</strong> and the user IDs are enrolled in <strong>MKS</strong> Integrity.<br />
NOTE For details on working with users, see “Users” on page 72. For <strong>MKS</strong> Integrity<br />
users, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
To define a user profile for <strong>MKS</strong> Integrity integration<br />
1 From the <strong>Implementer</strong> Menu, type option 41, Users, and press ENTER. The Work with<br />
User Profile panel displays.<br />
2 Select the user profile with option 2=Change, and press ENTER. The Change User Profile<br />
panel displays.
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
3 In the <strong>MKS</strong> Integrity User ID field, specify the name this user logs on with to access<br />
<strong>MKS</strong> Integrity. This user ID is also used for source archiving in <strong>MKS</strong> Source when<br />
<strong>MKS</strong> Source archiving is enabled. The user ID must be set up in <strong>MKS</strong> Integrity and/or<br />
<strong>MKS</strong> Source before defining it here. The field entry is case sensitive. Valid entries are as<br />
follows:<br />
*USRPRF: The iSeries user profile defaults as the <strong>MKS</strong> Integrity user. This is the<br />
default value. iSeries user profiles are specified in all upper case. If the name<br />
specified in <strong>MKS</strong> Integrity is not all upper case, retype the name using the exact case<br />
as that used in <strong>MKS</strong> Integrity.<br />
Name: Specify the valid <strong>MKS</strong> Integrity user ID.<br />
*NONE: The user is not authorized to access <strong>MKS</strong> Integrity.<br />
4 In the <strong>MKS</strong> Integrity emergency update field, specify if this user has authority to activate<br />
and de-activate the <strong>MKS</strong> Integrity emergency update mode and perform emergency<br />
updates. Allows the user to change the value of the <strong>MKS</strong> Integrity Emergency Update<br />
Active field on the Change User defaults panel, which is accessible from Work with<br />
Users using option 20=User Defaults and from the Workbench using F18=User Defaults.<br />
Y: The user has authority to activate the emergency update mode.<br />
N: The user does not have authority to activate the emergency update mode.<br />
5 Press ENTER to update the user profile.<br />
NOTE When activating emergency mode as described in “Emergency Update<br />
Mode” on page 255, the authorized user must sign off the iSeries and sign on again.<br />
When the authorized user accesses <strong>Implementer</strong>, a message displays at the bottom<br />
of the menu to confirm the emergency update mode is active.<br />
Environment Setup<br />
If the environments for this integration already exist and you have already configured the<br />
state setup, depending on your workflow you may not need to perform the following<br />
additional environment setup tasks.<br />
<strong>Implementer</strong> allows you to control whether an issue is required when checking out from<br />
a production environment. This allows you to enforce rules that define how a member<br />
that is checked out from the environment can subsequently be rejected and promoted<br />
throughout the development cycle.<br />
237
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
238<br />
Optional environment overrides to the default states to assign. The default states that are<br />
routinely assigned to an issue when all members of a change package are in a particular<br />
environment or when an item is rejected from a particular environment are defined in<br />
the <strong>MKS</strong> Integrity Setup. At the environment level, you can define overrides to the<br />
global default values.<br />
When assigning states in check out and promotion, environment overrides are assigned<br />
first. If overrides do not exist, the applicable global value is assigned. For details on<br />
global states, see “State Setup in <strong>Implementer</strong>” on page 232.<br />
The following task requires the environments and <strong>MKS</strong> Integrity states used with this<br />
integration exist in <strong>Implementer</strong>. For detailed information on working with environments,<br />
see “Environments” on page 81.<br />
To set an environment to require issues and override issue states<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Environments, and press ENTER. The Work<br />
with Environments panel displays.<br />
2 Select the environment with option 2=Change, and press ENTER. The Change<br />
Environment panel displays.<br />
3 Press PAGE DOWN to display the second Change Environment panel.<br />
4 In the Issue Required for check out field, specify if an issue number is required to check<br />
out an item from the environment. Applies to *PRD environments only.<br />
N An issue number is not required. This is the default value.<br />
Y An issue number is required.<br />
5 Press PAGE DOWN to display the third Change Environment panel.
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
6 In the When arrives in this env field, optionally override the global issue states for the<br />
<strong>MKS</strong> Integrity state to assign to an item when it is checked out or promoted to this<br />
environment.<br />
NAME Specify a valid <strong>MKS</strong> Integrity state name to override the global<br />
value if defined. The name is case sensitive.<br />
*DEFAULT Assigns the default global value as defined in <strong>MKS</strong> Integrity State<br />
setup. If the default is not set, no updates occur. This is the default<br />
value for this field for all environment types. The state is set as<br />
follows:<br />
If checking out to this environment, assigns the *TST default<br />
state.<br />
If promoting to this environment and it is the first *QAC on<br />
the path, assigns the *QAC1 default state. If promoting to this<br />
environment and it is the second *QAC on the path, assigns<br />
the *QAC2 default state. This cycle continues for each *QAC<br />
environment.<br />
If promoting to this environment and it is type *PRD, assigns<br />
the *PRD default state.<br />
*NONE No updates occur to the issue state.<br />
239
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
240<br />
7 In the When rejected from this env field, specify the <strong>MKS</strong> Integrity state to assign to an<br />
item rejected from this environment.<br />
NAME Specify a valid <strong>MKS</strong> Integrity state name to override the global<br />
value if defined. Valid for *QAC environments only. The name is<br />
case sensitive.<br />
*DEFAULT Assigns the default global value defined in <strong>MKS</strong> Integrity State<br />
Setup. If the default is not set, no updates occur. This is the default<br />
value for all environment types.<br />
The state is set as follows: If rejecting from this environment and it<br />
is the first *QAC environment on the path (the path used to<br />
promote from the current location), assigns the *QAC1 default<br />
state. If rejecting from this environment and it is the second *QAC<br />
environment on the path (the path used to promote from the<br />
current location), assigns the *QAC2 default state. This cycle<br />
continues for each *QAC environment.<br />
*NONE No updates occur.<br />
8 Press ENTER to update the environment information. The Work with Environments<br />
panel displays.<br />
IMPORTANT The following setup tasks are required to promote <strong>Implementer</strong><br />
requests from within <strong>MKS</strong> Integrity. If you do not intend to use this alternate<br />
promotion feature, go to “Converting From DesignTracker to <strong>MKS</strong> Integrity” on<br />
page 243.<br />
Updating Issues Based on Promotion Status<br />
The Update <strong>MKS</strong> Integrity (IUPDCI) command allows you to change the state of an issue<br />
based on the promotion status of objects in a change package. This process keeps<br />
<strong>MKS</strong> Integrity synchronous with the development cycle by triggering an issue state change<br />
based on promotion activity. For example, you may want to set the state to “Failed QA”<br />
when a move to QA fails. This is an optional feature.<br />
The IUPDCI command is invoked as an <strong>Implementer</strong> “After Move-OK” special command for<br />
each environment you want to trigger the state change.<br />
After connecting to the source iSeries and retrieving a list of all issues associated with the<br />
promotion request, the mass update of issues to the specified state occurs. The state change<br />
occurs only after all objects contained in the change package have reached the new location<br />
(QA or production). All issues in the change package must be promotable to the given state.<br />
<strong>MKS</strong> Integrity allows for an unlimited (and possibly recursive) number of relationships. The<br />
IUPDCI command uses a commit/rollback processing architecture, whereby the status<br />
update occurs only when all issues associated with the specified promotion request are at a<br />
state that allows the update. If any one of the issues do not update, then no issues update.
IUPDCI Command Requirements and Setup<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration<br />
<strong>MKS</strong> Integrity uses a Java back end that resides on the iSeries to initiate a communication<br />
session with the <strong>MKS</strong> Integrity Server. The Update <strong>MKS</strong> Integrity (IUPDCI) command uses<br />
Java Runtime Environment 1.5 on the iSeries, which is provided in i5/OS release V5R3 and<br />
later. The IUPDCI command verifies Java is installed prior to running.<br />
In addition, you must change the IMJDKVER data area value to ‘1.5’ for the IUPDCI<br />
command to use Java 1.5. For details, see “<strong>Implementer</strong> Data Areas and User Exit Programs”<br />
on page 401.<br />
If the target <strong>MKS</strong> Integrity Server runs on an AIX system, Java Development Kit (JDK)<br />
version 1.4 is required on the client to communicate with <strong>MKS</strong> Integrity on the AIX system<br />
and use the IUPDCI command. <strong>Implementer</strong> provides the JDK Version (IMJDKVER) data<br />
area that allows you to store the JDK version to use with the Update <strong>MKS</strong> Integrity (IUPDCI)<br />
command. The default data area value is 1.2 (enclosed in single quotes (‘ ‘). You must install<br />
JDK version 1.4 on the iSeries, and change the IMJDKVER data area value to 1.4. On OS/400<br />
V5R2, you can install JDK version 1.4 from the IBM license product installation media. On<br />
OS/400 V5R1, you can install JDK version 1.4 by installing IBM PTF SI05336 and following<br />
the instructions included with the PTF.<br />
The setup requirements for the IUPDCI command are as follows:<br />
copy <strong>MKS</strong> Integrity files to the iSeries<br />
create a special command for the applicable environments<br />
To copy the <strong>MKS</strong> Integrity files to the iSeries<br />
1 Open Windows Explorer, and click Tools > Map Network Drive. The Map Network Drive<br />
dialog box displays prompting for a drive and path name.<br />
2 Select the drive name you want to use or accept the default value.<br />
3 For the path, type:<br />
//Your_System_Name/mks/<strong>Implementer</strong>/<strong>MKS</strong>IM/lib<br />
NOTE The default product library is <strong>MKS</strong>IM. If you changed the product library to<br />
another name, substitute the changed name for <strong>MKS</strong>IM.<br />
4 Make sure the Reconnect at Logon box is not enabled, and click OK. You may be<br />
prompted for a user ID and password to connect to the system.<br />
5 From Windows Explorer, select and expand the drive you just mapped.<br />
6 Navigate to your <strong>MKS</strong> Integrity Client install location. If you accepted the default<br />
location at the time of installation, the default location is:<br />
C:/Program Files/<strong>MKS</strong>/Integrity Client<br />
241
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
242<br />
7 From your <strong>MKS</strong> Integrity Client install location, copy file mksclient.jar from the<br />
/lib directory to the iSeries you mapped to in steps 1–5.<br />
To create the special command<br />
Define the special command for each applicable *QAC and *PRD environment. For detailed<br />
information on special commands, see “Special Command Processing” on page 255.<br />
When promoting changes from development to QA or from QA to production, the issue<br />
updates to reflect the current location and status. The update runs each time a promotion<br />
request targets an environment that has the IUPDCI command defined as a special<br />
command. The actual update occurs after the move portion of the promotion request<br />
successfully completes. When the promotion request is at a status of completed, you can<br />
access <strong>MKS</strong> Integrity to view the updates.<br />
In the following example, the special command is defined for a QA environment:<br />
IUPDCI RQS(#RQSNBR) NEWSTATE('"In QA"')<br />
IMPORTANT The value for NEWSTATE has embedded blanks; therefore, you must<br />
enclose it first in single quotes (' ') and then in double quotes (" ") as illustrated.<br />
IUPDCI Command Parameters<br />
Request Number<br />
Specify the promotion request number to process the special command for. The substitution<br />
variable #RQSNBR processes the command for all promotion requests that target the<br />
environment. This is a seven character alphanumeric field.<br />
New issue state<br />
Specify the new state value to assign to the issue. This is 20 character alphanumeric field.<br />
Mixed-case entry is supported.<br />
Enable Promotions From <strong>MKS</strong> Integrity<br />
This section describes the additional set up required in <strong>Implementer</strong> to create and promote<br />
<strong>Implementer</strong> requests from within <strong>MKS</strong> Integrity. This is an optional feature.<br />
The setup involves tasks in both <strong>MKS</strong> Integrity and <strong>Implementer</strong>. For information on the<br />
<strong>MKS</strong> Integrity tasks, see “Enable Promotions From <strong>MKS</strong> Integrity” on page 212. For an<br />
overview of the feature, see “Promoting <strong>Implementer</strong> Requests From <strong>MKS</strong> Integrity” on<br />
page 201.<br />
Review and perform the following <strong>Implementer</strong> setup requirements as needed:
Converting From DesignTracker to <strong>MKS</strong> Integrity<br />
Verify the <strong>MKS</strong> Integrity user responsible for creating promotion requests in<br />
<strong>MKS</strong> Integrity is defined in <strong>Implementer</strong> and has the required capabilities, for example,<br />
the capability to create and submit promotion requests for the applicable environments.<br />
Define the IEXCCMDUSR data area as described next.<br />
Change the IEXCCMDUSR Data Area<br />
The Command Capability Check Profile (IEXCCMDUSR) data area is used for capability<br />
checking. The data area stores the name of the single user profile that is allowed to issue the<br />
Run <strong>MKS</strong> Integrity Server (IEXCCMDIS) command that is embedded in the JavaScript file.<br />
The user profile you specify in this data area must be the same user profile specified in the<br />
JavaScript file for the userProfile variable (for details, see page 213). This user profile is used<br />
only for this feature; thus, it is not necessary to define the profile in <strong>Implementer</strong> or<br />
<strong>MKS</strong> Integrity. For this reason, consider creating a new profile for this specific purpose, for<br />
example, iSeries.<br />
CAUTION Embedded commands in the script fail if you do not associate the<br />
<strong>MKS</strong> Integrity user ID to an <strong>Implementer</strong> user profile.<br />
To change the IEXCCMDUSR data area value<br />
1 Type the following command:<br />
CHGDTAARA DTAARA(IEXCCMDUSR) VALUE(user_profile_name)<br />
where user_profile_name is the user specified in the script.<br />
2 Press ENTER to update the data area.<br />
You are now ready to convert from DesignTracker to <strong>MKS</strong> Integrity as described next.<br />
Converting From DesignTracker to <strong>MKS</strong> Integrity<br />
When you initially install <strong>Implementer</strong> or upgrade from a release prior to release 5.3,<br />
DesignTracker is the default issue management system. To use <strong>Implementer</strong> with<br />
<strong>MKS</strong> Integrity as described in this chapter, you must convert issue management systems and<br />
activate <strong>MKS</strong> Integrity to establish it as the default system.<br />
When you convert from DesignTracker to <strong>MKS</strong> Integrity, you have the option to use<br />
<strong>MKS</strong> Integrity only, or to use <strong>MKS</strong> Integrity and DesignTracker concurrently on a transitional<br />
basis. With either option, the eventual result is the elimination of DesignTracker as a<br />
production application.<br />
243
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
244<br />
Once <strong>MKS</strong> Integrity is active system-wide, you cannot convert back to DesignTracker.<br />
However, for existing DesignTracker users, provisions are available for enabling select users<br />
to use DesignTracker temporarily. Future upgrades of <strong>Implementer</strong> automatically consider<br />
and retain the settings you define.<br />
Conversion Methods<br />
<strong>Implementer</strong> provides two methods for converting issue management systems from<br />
DesignTracker to <strong>MKS</strong> Integrity: system conversion without data retention or system<br />
conversion with data retention. The latter method includes a feature that, after converting to<br />
<strong>MKS</strong> Integrity, allows you to convert DesignTracker design requests (DRs) and service<br />
requests (SRs) to <strong>MKS</strong> Integrity issues.<br />
To determine which conversion method fits your business requirements, you need to answer<br />
the following question:<br />
Is DesignTracker in use with any DRs you want to keep?<br />
If no, simply convert to <strong>MKS</strong> Integrity as described in “Converting Without Data<br />
Retention” on page 244. This is the case for new installations of <strong>Implementer</strong>.<br />
If yes, convert to <strong>MKS</strong> Integrity as described in “Converting With Data Retention” on<br />
page 247, and optionally convert DRs and SRs to <strong>MKS</strong> Integrity issues as described in<br />
“Converting DesignTracker Data to <strong>MKS</strong> Integrity” on page 431.<br />
NOTE Prior installations of <strong>Implementer</strong> automatically installed demonstration DRs<br />
and SRs. If these are the only requests present, you can delete them. You can also<br />
delete any requests from a pilot project.<br />
Converting Without Data Retention<br />
The tasks described in this section perform a conversion that allows you to convert issue<br />
management systems—that is, switch from using DesignTracker to using <strong>MKS</strong> Integrity,<br />
without retaining any existing DesignTracker data. Converting to <strong>MKS</strong> Integrity without<br />
regard for existing data is straightforward and allows you to quickly begin using<br />
<strong>MKS</strong> Integrity.<br />
This conversion method is applicable when DesignTracker is not used for issue management,<br />
or if it has been used but you do not need to preserve any DRs or SRs that may exist from the<br />
prior use. This conversion method deletes all existing DRs, SRs, DR entity lists, and any DR<br />
references on current locks and lock history. It does not delete the actual locks or lock history.<br />
This is a one time task. Once the conversion successfully completes, you can begin using the<br />
integration.<br />
Your user profile must have authority to System Control Maintenance to perform this task.
CAUTION<br />
Converting From DesignTracker to <strong>MKS</strong> Integrity<br />
This task deletes DesignTracker data. If you need to retain DesignTracker data,<br />
do not perform this task; instead, see “Converting With Data Retention” on<br />
page 247.<br />
<strong>MKS</strong> recommends you perform a backup of the DesignTracker database by<br />
saving the <strong>Implementer</strong> library prior to running this conversion function.<br />
To convert to <strong>MKS</strong> Integrity without retaining data<br />
1 Sign on to the iSeries with a user profile that has authority to System Control<br />
Maintenance and access the <strong>Implementer</strong> Menu.<br />
2 Type option 47, <strong>MKS</strong> Integrity, and press ENTER. Alternatively, on the command line<br />
issue the command STRIM *INTMGRSET. The <strong>MKS</strong> Integrity Setup panel displays.<br />
3 Press F20=Convert to <strong>MKS</strong> Integrity. (Press F24=More keys to view function key F20 in<br />
the list.) The first of three Convert to <strong>MKS</strong> Integrity confirmation windows display.<br />
4 In the Reply field, type N to disallow co-existence, and press ENTER. The second Convert<br />
to <strong>MKS</strong> Integrity panel displays.<br />
CAUTION The function you are about to perform deletes existing DesignTracker<br />
data. If you do not want to delete DesignTracker data, do not perform this step.<br />
However, if this step is not performed or a system conversion is not performed, you<br />
cannot use <strong>MKS</strong> Integrity as described in this chapter.<br />
245
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
246<br />
NOTE There are two Convert to <strong>MKS</strong> Integrity panels. Both panels allow you to<br />
display additional information before converting. Press F2=Display 2nd Level Text.<br />
5 In the Reply field, type Y, and press ENTER.<br />
To cancel the conversion and return to the <strong>MKS</strong> Integrity Setup panel, either: type N in<br />
the Reply field, and press ENTER, press F3=Exit, or F12=Cancel.<br />
After pressing ENTER to continue, the second confirmation window displays. A message<br />
confirms you selected to convert from DesignTracker to <strong>MKS</strong> Integrity.
Converting From DesignTracker to <strong>MKS</strong> Integrity<br />
6 To proceed with the conversion, in the Reply field type G, and press ENTER to perform<br />
the conversion.<br />
To cancel the conversion and return to the <strong>MKS</strong> Integrity Setup panel either: type N in<br />
the Reply field, and press ENTER, press F3=Exit, or F12=Cancel.<br />
After pressing ENTER to continue, the following message displays at the bottom of the<br />
<strong>MKS</strong> Integrity Setup panel: “Successful conversion to <strong>MKS</strong> Integrity.”<br />
The system conversion from DesignTracker to <strong>MKS</strong> Integrity is complete. You are ready to<br />
begin using the new features, as described in the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Converting With Data Retention<br />
For <strong>MKS</strong> customers that currently use DesignTracker for issue management, the tasks<br />
described in this section perform a conversion that allows you to convert issue management<br />
systems—that is, switch from using DesignTracker to using <strong>MKS</strong> Integrity, and retain<br />
existing DesignTracker data. This conversion method enables the <strong>Implementer</strong> feature<br />
co-existence, which is required when converting DesignTracker data to <strong>MKS</strong> Integrity.<br />
The purpose of co-existence is twofold: It avoids application downtime during the<br />
application conversion project by allowing you to simultaneously use both <strong>MKS</strong> Integrity<br />
and DesignTracker, and it allows you to convert DesignTracker DRs, SRs, and related entity<br />
information to <strong>MKS</strong> Integrity issues using the Convert DT to <strong>MKS</strong> Integrity (ICVTDT)<br />
command. By design, it allows some users to use <strong>MKS</strong> Integrity issues without requiring all<br />
users to switch at the same time. This allows for a gradual transition of development teams<br />
when multiple teams share the same <strong>Implementer</strong> installation.<br />
NOTE For details on the ICVTDT command, see “Converting DesignTracker Data to<br />
<strong>MKS</strong> Integrity” on page 431.<br />
Converting to <strong>MKS</strong> Integrity when you need to retain and convert existing data can be an<br />
involved undertaking simply due to the inherent complexities associated with performing<br />
data conversions. For example, a typical data conversion requires mapping existing files and<br />
fields to new values in the new database. Detailed information on performing a data<br />
conversion begins on page 431.<br />
TIP <strong>MKS</strong> can assist with converting your DesignTracker data to <strong>MKS</strong> Integrity, as<br />
well as assist in defining your business processes and workflow for <strong>MKS</strong> Integrity.<br />
For details, contact <strong>MKS</strong> Customer Care.<br />
Before you perform the actual data conversion, however, you need to determine how the<br />
data conversion will occur. In other words, will you perform a one-time conversion of all<br />
applicable data and users, or will you perform a gradual conversion on subsets of data and<br />
users?<br />
247
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
248<br />
The need for this decision—beyond having control of the overall scope of your conversion<br />
project—is that with co-existence you can designate on a user basis which issue tracking<br />
system a user works with. It allows you to have groups of users still using DesignTracker<br />
while other users use <strong>MKS</strong> Integrity. This approach is beneficial to larger organizations with<br />
many end users, as it allows you to train and migrate groups of individuals rather than all<br />
users at once. For information on setting the issue management system for a user, see<br />
page 253.<br />
To simplify working with two issue management systems, while co-existence is active you<br />
configure each issue management system to manage a different range of numbers, where<br />
issues and DRs each have a specific number range that is unique to each type, and numbers<br />
outside of the specified ranges are not allowed. DRs always have the lowest numbers and<br />
<strong>MKS</strong> Integrity issues have the higher numbers.<br />
Everyone is able to view all IDs and some basic information, but the check out and promotion<br />
functions require users to only use the issue management system they are set up for. This<br />
methodology allows DesignTracker to use numbers up to the last allowed DR number you<br />
specify. Information on setting the last DR number begins on page 250.<br />
You achieve a successful conversion when all <strong>Implementer</strong> user profiles that perform check<br />
out or promotion functions are set to use <strong>MKS</strong> Integrity for issue management. Although, it<br />
may be desirable to keep a few users with a second user profile set to use DesignTracker so<br />
they can fully navigate the DesignTracker audit trail.<br />
Once the conversion finishes, the DesignTracker transactions can remain online and visible to<br />
the select DesignTracker users for historical purposes. There is no need to disable coexistence<br />
after you finish the conversion.<br />
IMPORTANT <strong>MKS</strong> recommends you convert to a pilot copy of <strong>MKS</strong> Integrity to verify<br />
the results before going “live” with converted data. <strong>MKS</strong> also recommends you<br />
perform a backup of the DesignTracker database by saving the <strong>Implementer</strong> library<br />
prior to running this conversion program.<br />
Promotion Considerations With Co-existence<br />
The following promotion-related considerations apply to working in the co-existent mode:<br />
All issues for a single promotion request must be in the same issue management system.<br />
In other words, you cannot assign both DRs and issues to the same promotion request.<br />
If using concurrent development, do not allow the same member to have locks<br />
associated with a DR and issue in the same environment, as this will make it non<br />
promotable.<br />
The user that submits a move request must use the same issue management system as<br />
the user who created the request. For example, on a request that contains DRs, both the<br />
requestor and the user submitting the move must be set up to use DesignTracker. On a<br />
request that contains issues, the respective users must be set up to use <strong>MKS</strong> Integrity.
Run the Conversion<br />
Converting From DesignTracker to <strong>MKS</strong> Integrity<br />
This is a one time task. Perform this conversion task only if DesignTracker is, or was, used for<br />
issue management and you need to retain and/or convert any data that may exist from the<br />
prior use.<br />
Your user profile must have authority to System Control Maintenance to perform the task.<br />
IMPORTANT This task allows you to establish <strong>MKS</strong> Integrity as the system-wide issue<br />
tracking system and enable DesignTracker co-existence. While you must perform<br />
this task to later convert DesignTracker data to <strong>MKS</strong> Integrity, it does not actually<br />
convert or delete any data. To convert DesignTracker data to <strong>MKS</strong> Integrity, see<br />
“Converting DesignTracker Data to <strong>MKS</strong> Integrity” on page 431. To completely<br />
remove DesignTracker data without co-existing or converting data, see “Converting<br />
Without Data Retention” on page 244.<br />
To convert to <strong>MKS</strong> Integrity and retain existing data<br />
1 Sign on to the iSeries with a user profile that has authority to System Control<br />
Maintenance and access the <strong>Implementer</strong> Menu.<br />
2 Type option 47, <strong>MKS</strong> Integrity, and press ENTER. Alternatively, on the command line<br />
issue the command STRIM *INTMGRSET. The <strong>MKS</strong> Integrity Setup panel displays.<br />
3 Press F20=Convert to <strong>MKS</strong> Integrity. (Press F24=More keys to view function key F20 in<br />
the list.) The Convert to <strong>MKS</strong> Integrity window displays.<br />
4 In the Reply field, type Y, and press ENTER. Alternatively, press F2 to display additional<br />
information on the function you are about to perform as illustrated next.<br />
249
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
250<br />
5 To continue with the conversion, in the Reply field type Y, and press ENTER.<br />
NOTE If you need to cancel the conversion, either type N in the Reply field, and press<br />
ENTER, press F3=Exit, or F12=Cancel.<br />
When the conversion completes, the following values are set in the <strong>MKS</strong> Integrity Setup<br />
panel:<br />
Issue Management System field value is <strong>MKS</strong> Integrity.<br />
Allow co-existence with DesignTracker field value is Y.<br />
Last allowed DR number field value is 99999.<br />
IMPORTANT For any users that will continue to use DesignTracker, it is necessary to<br />
override the system default of <strong>MKS</strong> Integrity. For details, see “Set a User’s Default<br />
Issue Management System” on page 253.<br />
Set the Last Allowed DR Number<br />
With co-existence, each issue management system uses a different range of ID numbers.<br />
Each <strong>Implementer</strong> function that allows specifying an issue or DR number, or associates an<br />
issue or DR with a lock, ensures the number being used is appropriate for the user’s issue<br />
management system. An error displays if the number specified is outside the range of their<br />
issue management system.
Converting From DesignTracker to <strong>MKS</strong> Integrity<br />
For example, a user who is set up to use DesignTracker tries to check out or promote using<br />
number 12345—by range, an <strong>MKS</strong> Integrity issue number—receives an error. Likewise, if a<br />
user attempts to create a new DR by using either the menu option or the Create Design<br />
Request (DTCRTDR) command, <strong>Implementer</strong> verifies the new DR number is within the valid<br />
DR number range—if the number is not valid, then creating the DR is not allowed.<br />
Displaying the basic description or details of an issue or DR does not require enrollment in<br />
the specific issue management system.<br />
Changing the last allowed DR number value is allowed only if <strong>MKS</strong> Integrity is the default<br />
issue tracking system and DesignTracker co-existence is enabled. The value automatically<br />
sets to 99999—the highest possible DR number—when you convert to <strong>MKS</strong> Integrity and<br />
enable co-existence. Before processing any DRs or issues, you must change this number to<br />
another value based on your data. Thereafter, avoid changing it to eliminate a possible<br />
conflict with existing issues, or DRs that you may subsequently convert to issues.<br />
IMPORTANT You must specify a Last allowed DR number value that allows for all<br />
expected growth in DR usage until DesignTracker is retired, as there is no way to<br />
change this number once you use an <strong>MKS</strong> Integrity issue.<br />
The following task requires you have successfully completed the conversion to<br />
<strong>MKS</strong> Integrity and enabled the option to co-exist with DesignTracker.<br />
To change the last allowed DR number<br />
1 From the <strong>Implementer</strong> Menu, type option 47, <strong>MKS</strong> Integrity, and press ENTER.<br />
Alternatively, on the command line issue the command STRIM *INTMGRSET. The<br />
<strong>MKS</strong> Integrity Setup panel displays.<br />
2 Press PAGE DOWN to display the second <strong>MKS</strong> Integrity Setup panel.<br />
251
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
252<br />
3 In the Allow co-existence with DesignTracker field, verify the value is Y, indicating<br />
DesignTracker and <strong>MKS</strong> Integrity are able to co-exist. This value is required to enable<br />
changing the last allowed DR number. If the value on your system is not Y, see<br />
“Converting With Data Retention” on page 247.<br />
4 In the Last allowed DR number field, type the value of the last valid DR number allowed<br />
in DesignTracker. The default value is 4999.<br />
IMPORTANT Be sure to specify a value that allows for all expected growth in DR<br />
usage until DesignTracker is retired. The value cannot be set below the current<br />
highest DR number created. Any DR number higher than the number specified here<br />
is considered an <strong>MKS</strong> Integrity issue.<br />
5 Press ENTER to update the information.<br />
Set the Next Issue Number in <strong>MKS</strong> Integrity<br />
When using co-existing issue management systems, you must configure each issue<br />
management system to manage a different range of numbers, where issues and DRs each<br />
have a specified number range that is unique to each type, and numbers outside of the<br />
specified ranges are not allowed for either type. DRs always have the lowest range of<br />
numbers and <strong>MKS</strong> Integrity issues have a higher range of numbers.<br />
This is an <strong>MKS</strong> Integrity function, accomplished by adding a new property to the<br />
im.properties file on the <strong>MKS</strong> Integrity Server. For details on configuring properties for<br />
the <strong>MKS</strong> Integrity Server, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
IMPORTANT Make changes to the Integrity Server property files using a text editor,<br />
such as Notepad, and then save as plain text. You must restart the server to effect the<br />
changes.<br />
To set the next issue number in <strong>MKS</strong> Integrity<br />
1 Navigate to the im.properties file located in:<br />
/config/properties<br />
2 Open the file and add the following line to the im.properties file:<br />
mksis.im.minimumIssueNumber=<br />
for example, mksis.im.minimumIssueNumber=70000<br />
NOTE You can increase the next issue number value, you cannot decrease it.
Set a User’s Default Issue Management System<br />
Converting From DesignTracker to <strong>MKS</strong> Integrity<br />
Setting a user’s default issue management system is required only when the conversion of<br />
DesignTracker data is gradual, rather than a one-time conversion.<br />
Each user enrolled in <strong>Implementer</strong> is set automatically to use the default issue tracking<br />
system as defined in the <strong>MKS</strong> Integrity setup, option 47 on the <strong>Implementer</strong> Menu. Once you<br />
convert to <strong>MKS</strong> Integrity and enable co-existence, all users are set to use <strong>MKS</strong> Integrity. If<br />
some users will continue transitional use of DesignTracker, after converting to <strong>MKS</strong> Integrity<br />
you can re-enable each user that will continue to use DesignTracker.<br />
Generally, whichever system a user is set up for determines the text that displays on all<br />
<strong>Implementer</strong> panels and reports. Thus, when using <strong>MKS</strong> Integrity the term “issue” is used.<br />
When using DesignTracker the term “design request” is used. For example, when a user set<br />
up to use <strong>MKS</strong> Integrity displays the Workbench, the field name is Issue, when the field<br />
value may actually contain DR numbers if they are filtered to a lock associated with a user set<br />
up to use DesignTracker. Although the <strong>MKS</strong> Integrity user is able to view the DR number,<br />
they are restricted from using or changing the lock detail because they cannot manipulate<br />
DRs through <strong>Implementer</strong>. The exception to this rule is when displaying activity—each user,<br />
regardless of their default issue management system, can view the activity of other users.<br />
By design, <strong>Implementer</strong> does not allow a single user to use both <strong>MKS</strong> Integrity and<br />
DesignTracker under the same <strong>Implementer</strong> user profile. However, you can work around<br />
this and permit the ability to work in both systems by issuing two different iSeries user<br />
profiles. For example, this might be useful for some administrators or team leaders during<br />
transition to the new system. You can simplify this step by copying existing user profiles.<br />
When changing the user profile or environment values, the applicable <strong>MKS</strong> Integrity fields<br />
are changeable based on the default issue management system as defined in the<br />
<strong>MKS</strong> Integrity Setup, not the current users override.<br />
To set the issue management system for a user in <strong>Implementer</strong><br />
1 From the <strong>Implementer</strong> Menu, type option 41, Users, and press ENTER. The Work with<br />
User Profiles panel displays.<br />
2 Type option 2=Select next to the user profile, and press ENTER. The Change User Profile<br />
panel displays.<br />
3 Press PAGE DOWN to display the second Change User Profile panel.<br />
253
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
254<br />
4 In the Issue Management System field, specify the current issue management system for<br />
this user. This field is only used when co-existing to allow certain users to use<br />
<strong>MKS</strong> Integrity while others use DesignTracker; otherwise, input is protected.<br />
When you activate <strong>MKS</strong> Integrity, all users are set to use <strong>MKS</strong> Integrity. Change this<br />
value only to set the user’s default to DesignTracker and to change it back to<br />
<strong>MKS</strong> Integrity (1=Default) when DesignTracker is no longer used by the user.<br />
1=Default: The user is using the default issue management system as defined on the<br />
<strong>MKS</strong> Integrity Setup panel. This is the default value.<br />
2=DesignTracker: The user is using DesignTracker, even if <strong>MKS</strong> Integrity is the<br />
default issue management system as defined on the <strong>MKS</strong> Integrity Setup panel.<br />
5 Press ENTER to update the information.<br />
IMPORTANT<br />
After changing this value for a user, the user must sign off the iSeries and sign<br />
back on for the change to take effect.<br />
If this user checks out or promotes using <strong>Implementer</strong>’s Web interface, you must<br />
restart the Web server to recognize the new issue management system. For<br />
information on the Web interface, see “Web-based Development for IFS Objects”<br />
on page 155.<br />
The conversion from DesignTracker to <strong>MKS</strong> Integrity is complete. If you need to convert<br />
existing DesignTracker data, see “Converting DesignTracker Data to <strong>MKS</strong> Integrity” on<br />
page 431. If you do not need to convert DesignTracker data, you can begin using the<br />
integration as described in the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.
Emergency Update Mode<br />
Emergency Update Mode<br />
If communications between <strong>Implementer</strong> and <strong>MKS</strong> Integrity become temporarily<br />
unavailable and thereby cause <strong>MKS</strong> Integrity inaccessible to perform updates, <strong>Implementer</strong><br />
provides the Emergency Update Mode facility. When activated, emergency update mode<br />
allows for the uninterrupted continuation of all iSeries development activities, including<br />
check out and promotion.<br />
For example, you have changes on an active request that require immediate promotion to<br />
correct a level check problem in production, but a communication failure between<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity has caused the promotion to fail. By activating the<br />
emergency update mode, you can continue with all required development activities while<br />
storing the issue updates for subsequent posting once the communications are re-established.<br />
Users must have authority to work in emergency update mode and perform emergency<br />
updates. Typically, this authority is given to a few development managers and senior<br />
developers. When authorized, you can activate and deactivate the emergency mode by<br />
changing the value of the <strong>MKS</strong> Integrity emergency update active field, accessible from Work<br />
with Users by using option 20=User Defaults, or from the Workbench by using F18=User<br />
Defaults. For details on the setup requirements, see “<strong>MKS</strong> Integrity Emergency Mode<br />
Authority” on page 235.<br />
TIP To maintain a record of communication failures, you can journal the<br />
<strong>Implementer</strong> file IMCICT and monitor any changes to the file.<br />
Changing the Emergency Update Mode<br />
When the status of communications between <strong>Implementer</strong> and <strong>MKS</strong> Integrity changes, the<br />
user defined as the iSeries Notify User is notified of the change by a message in the user’s<br />
OS/400 message queue. (The iSeries Notify User is defined in <strong>MKS</strong> Integrity setup, option 47<br />
from the <strong>Implementer</strong> Menu.) The user is notified when communications become either<br />
unavailable or available. At the same time, in the <strong>MKS</strong> Integrity Setup, the System Available<br />
field reflects the current status.<br />
When a communication failure occurs, a common practice is to perform problem<br />
determination to assess the magnitude of the failure and its potential impact on<br />
development. Based on these results, and perhaps additional variables such as your current<br />
development activities and the time of day, you can decide whether to activate the<br />
emergency update mode.<br />
For example, if a communication failure occurs that you expect to last for only a brief time<br />
and it does not hinder current development activities, you may decide not to activate the<br />
emergency update mode. In this case, developers can continue with Workbench activities<br />
such as editing and compiling, but they are not allowed to check out or promote. On the<br />
other hand, if a failure occurs during the night that could interrupt the processing of<br />
255
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
256<br />
scheduled promotions that you do not want to end in a failed status, activating the<br />
emergency update mode is necessary to allow <strong>Implementer</strong> to proceed with promotion<br />
request processing.<br />
To allow promotions to complete without an active connection, this feature requires each<br />
user who submits promotions to have their user profile <strong>MKS</strong> Integrity emergency update<br />
active field set to Y in Work with Users.<br />
Emergency Mode Active<br />
When the emergency update mode is active for a user and that user signs on to <strong>Implementer</strong>,<br />
the following message displays at the bottom of the menu to confirm the operating mode:<br />
“<strong>MKS</strong> Integrity emergency update mode is ACTIVE!”.<br />
In active mode, <strong>Implementer</strong> bypasses all capability and validity checking, and postpones all<br />
updates to <strong>MKS</strong> Integrity. This allows the authorized user to continue with the development<br />
activities, such as editing, checking out, and promoting. Move requests continue as normal,<br />
however the <strong>MKS</strong> Integrity status change does not occur until you apply pending changes.<br />
Once you restore communications, you can synchronize the <strong>Implementer</strong> and <strong>MKS</strong> Integrity<br />
databases with pending changes as described in “Applying Pending Changes” on page 257.<br />
Considerations for Remote Processing<br />
When using emergency update mode with remote initiated moves or remote compiles with<br />
host updates, to avoid problems with the host update job failing and the request ending with<br />
a status of Move-fail, you must change the user profile of the user that runs the host update<br />
program (this is usually the <strong>Implementer</strong> user profile MWIPROD).<br />
In Work with Users, set the <strong>MKS</strong> Integrity emergency update field to Y, and in User Defaults<br />
set the <strong>MKS</strong> Integrity emergency update active field to Y. Once communications are back<br />
online, change the user defaults back to N.<br />
Emergency Mode Inactive<br />
When a disruption in communications causes a user not to have emergency update mode<br />
active, <strong>Implementer</strong> sends the user a communications failure message to notify of the<br />
operating mode.<br />
Developers are able to perform some development activities, but the permitted tasks are<br />
limited in scope. For example, working in emergency mode allows editing and compiling,<br />
but check out, promotion, and any tasks that require the use of an issue or validation to<br />
<strong>MKS</strong> Integrity are not allowed.
To activate or deactivate the emergency update mode<br />
1 Use one of the following options to access the Change User Defaults panel:<br />
From the Workbench, press F18=User Defaults.<br />
Emergency Update Mode<br />
From the <strong>Implementer</strong> Menu, type option 41, Users, and press ENTER. Select the<br />
user profile with option 20=User Defaults, and press ENTER.<br />
2 In the <strong>MKS</strong> Integrity emergency update active field, specify Y to activate emergency<br />
update mode, or N to deactivate emergency update mode for the user.<br />
3 Press ENTER to process the update.<br />
4 To activate the change, sign off the iSeries and sign on again.<br />
When emergency update mode is active and the authorized user accesses <strong>Implementer</strong>,<br />
the following message displays at the bottom of the menu to confirm the operating<br />
mode: “<strong>MKS</strong> Integrity emergency update mode is ACTIVE!”.<br />
Applying Pending Changes<br />
Once you restore the communications between <strong>Implementer</strong> and <strong>MKS</strong> Integrity, you need to<br />
apply any pending changes that occurred while the emergency update mode was active.<br />
This function updates any issues that were changed while communications between<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity were unavailable. It updates <strong>MKS</strong> Integrity with the current<br />
state of the issues change packages and change package entries, and sets the state of the<br />
issues to reflect the current status of the change packages.<br />
257
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
258<br />
In the event an issue being processed does not exist, the change package entry log is updated<br />
to indicate that no updates were performed for the issue and no future updates will occur for<br />
the issue. Although no updates occur, the change package entry log is updated to reflect the<br />
issue posted to ensure further updates are not attempted.<br />
If an invalid action or workflow conflict occurred while the emergency update mode was<br />
active, for example, a promotion that would not normally be allowed based on the current<br />
state of an issue, the update to <strong>MKS</strong> Integrity does not occur during the update because it<br />
will only fail. This is a warning condition; as such, it is left for the administrator to ensure the<br />
issue is set to the proper state.<br />
After successfully applying the pending updates, a message of the update results is sent to<br />
the user defined as the iSeries Notify User. If no pending updates exist, a message at the<br />
bottom of the panel confirms this.<br />
Apply Pending Changes Command Option<br />
You can apply pending changes by using a menu interface or by using the Apply Pending<br />
Changes (IAPYPNDCHG) command. You can issue the command from the command line or<br />
embed into a user-defined program. The command has no parameters.<br />
IMPORTANT Before applying pending changes, you must ensure the emergency<br />
update mode is not active.<br />
To apply pending changes, use one of the following options<br />
From a command line, issue the following command:<br />
APYPNDCHG<br />
From the <strong>Implementer</strong> Menu, type option 47, <strong>MKS</strong> Integrity, and press ENTER or issue<br />
the command STRIM *INTMGRSET. The <strong>MKS</strong> Integrity Setup panel displays.<br />
a) Determine whether <strong>MKS</strong> Integrity is available by the value in the System Available<br />
field.<br />
b) Determine if pending changes exist by the value in the Pending Changes field. If<br />
pending changes exist, press F9=Apply Pending Changes.<br />
Apply Pending <strong>MKS</strong> Integrity Changes Report<br />
The Apply Pending <strong>MKS</strong> Integrity Changes report generates automatically when you apply<br />
pending changes by using the menu interface or the command interface. The report generates<br />
to the spool file of the user profile who ran the apply pending changes job. The spool file<br />
name is IMPNDCHG.<br />
The report includes the following information:<br />
date and time the update ran
issue and issue summary<br />
update result<br />
change package ID<br />
environment<br />
change package state<br />
change package status<br />
member and object code<br />
member status<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity integrate with <strong>MKS</strong> Source to give you detailed visibility of<br />
your iSeries source changes using <strong>MKS</strong> Source and <strong>MKS</strong> Integrity.<br />
With this integration, <strong>MKS</strong> Source can be used as a primary repository or a supplemental<br />
archive for native iSeries source members. <strong>MKS</strong> Source is the source code repository for<br />
detail iSeries source changes and updates, and <strong>MKS</strong> Integrity tracks the source members<br />
changed and promoted at the issue level. <strong>Implementer</strong>’s repository tracks the <strong>MKS</strong> Source<br />
revision—the result of promoting the member into an environment set up for <strong>MKS</strong> Source<br />
archiving. <strong>MKS</strong> Source and <strong>MKS</strong> Integrity handle all other tracking and auditing.<br />
The <strong>Implementer</strong> and <strong>MKS</strong> Source integration allows you to:<br />
Check out iSeries source code from <strong>Implementer</strong> or <strong>MKS</strong> Source.<br />
Promote <strong>Implementer</strong> locks, which automatically updates the <strong>MKS</strong> Source repository<br />
and records the <strong>MKS</strong> Source revisions in <strong>Implementer</strong>.<br />
View iSeries source member change history in the <strong>MKS</strong> Source Member History,<br />
including previous release development branches. You can also compare two member<br />
revisions by using the View Differences option.<br />
View changed iSeries source code lines by revision in the <strong>MKS</strong> Source Annotated View.<br />
Review <strong>Implementer</strong> product/release source revisions shown in release checkpoints and<br />
created on <strong>MKS</strong> Source projects that track <strong>Implementer</strong> products.<br />
Use the <strong>MKS</strong> Source iSeries Developer ViewSet to inquire on functions applicable to<br />
iSeries source information.<br />
Initiate the graphical Annotated View and Member History in <strong>MKS</strong> Source using<br />
<strong>Implementer</strong> green screen or WDSc interfaces.<br />
Use <strong>MKS</strong> Source in addition to <strong>Implementer</strong> for iSeries source archiving.<br />
259
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
Process and Workflow<br />
260<br />
Managers have a graphical window into the development process, allowing them to monitor<br />
the progress of issues and changes. The resolution of issues is accomplished through an<br />
integrated change management process facilitated by a common software architecture shared<br />
between <strong>MKS</strong> products.<br />
At the core of the integration, <strong>Implementer</strong>’s release control features have a direct correlation<br />
to change management functions in <strong>MKS</strong> Source as described in the following table.<br />
This release control feature in <strong>Implementer</strong>... ... Correlates to this feature in <strong>MKS</strong> Source<br />
product subproject of base product project<br />
product/version development path<br />
product/version/environment subproject of base environment project<br />
product/version/release release checkpoint<br />
The integration uses two <strong>MKS</strong> Source projects, defined as a base product project and a base<br />
environment project, to store all <strong>Implementer</strong> source archive information.<br />
Product Subproject in Base Product Project<br />
A product subproject is automatically created in the <strong>MKS</strong> Source base product project<br />
for each product when you set the Archived by <strong>MKS</strong> Source field to Y in <strong>Implementer</strong>’s<br />
Product Maintenance panel. Product subprojects are located in the Base Product project<br />
you reference in the <strong>MKS</strong> Source Setup panel in <strong>Implementer</strong>.<br />
Permissions for each product subproject are inherited from the base product project.<br />
All source members associated with the <strong>Implementer</strong> product are stored in the product’s<br />
subproject. When you add or update a member, it is added or checked in to this<br />
subproject. The product subproject contains all versioned contents for all members<br />
checked in for the product, including members that are later dropped. Users should not<br />
be given visibility to the product subproject; they can view the contents through<br />
environment subprojects within the product’s versions.<br />
Before creating a new version of the product in <strong>Implementer</strong>, you redefine the current<br />
version with a development path of *VERSION. A function in <strong>Implementer</strong> allows you<br />
to create an <strong>MKS</strong> Source development path, which assigns branched <strong>MKS</strong> Source<br />
revisions to subsequent promotions into the archived product/version/environments.<br />
This allows you to create a new version with a development path of *HEADREV, and<br />
continue with promotions to the *HEADREV version assigned trunk revisions.<br />
IMPORTANT The base projects referenced in this document are standard <strong>MKS</strong> Source<br />
projects. They act as parent projects to various subprojects. It is not required to<br />
register the base projects as top level projects in <strong>MKS</strong> Source.
Environment Subprojects in Base Environment Project<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
An environment subproject represents the current state of an <strong>Implementer</strong> environment.<br />
Environment subprojects are subprojects of the Base Environment project you reference<br />
on the <strong>MKS</strong> Source Setup panel in <strong>Implementer</strong>. <strong>Implementer</strong> automatically creates an<br />
environment subproject when you set a product/version/environment’s Archived by<br />
<strong>MKS</strong> Source field to Y on the Product Version Environment Maintenance panel.<br />
Permissions for each environment subproject are inherited from the base environment<br />
project.<br />
Environment subprojects allow imports and revision updates only; they do not allow<br />
adds or check in. When you promote a member, it is added or checked in to the product<br />
subproject and then imported to update the revision in the environment subproject.<br />
When you close a release, a function in <strong>Implementer</strong> allows you to create a checkpoint<br />
for associated production environment subprojects. This allows you to review the<br />
project in its current form at any point by viewing the project history using the<br />
checkpoint.<br />
Within each product and environment subproject, the first level subproject is the source<br />
physical file name, the base name of the file is the item name, and the file extension is the<br />
source member type. For example, member MWI0110, member type RPGLE, in source<br />
physical file QALLSRC appears as /MWI0110.RPGLE in subproject QALLSRC. IFS items are<br />
stored in a subproject named ifs.<br />
Assumptions and Requirements<br />
The <strong>Implementer</strong> and <strong>MKS</strong> Source integration requires:<br />
<strong>Implementer</strong> <strong>2006</strong>, which requires an iSeries system running OS/400 V5R1 or later, or<br />
i5/OS V5R3 or later. This is assumed installed and configured. For information on<br />
installing <strong>Implementer</strong>, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>.<br />
<strong>MKS</strong> Integrity Server <strong>2006</strong> or later, and <strong>MKS</strong> Source <strong>2006</strong> or later. This is assumed<br />
installed and configured. For information on installing <strong>MKS</strong> Integrity products, see the<br />
<strong>MKS</strong> Integrity Server <strong>2006</strong> Installation <strong>Guide</strong>.<br />
The <strong>Implementer</strong> Server must be configured and active. For details, see “Configuring the<br />
<strong>Implementer</strong> Server” on page 217. For information on managing <strong>Implementer</strong> Server,<br />
see page 223.<br />
TCP/IP connectivity between the iSeries running <strong>Implementer</strong> and the system running<br />
<strong>MKS</strong> Integrity Server.<br />
NOTE Using <strong>MKS</strong> Integrity is optional with the <strong>Implementer</strong> and <strong>MKS</strong> Source<br />
integration. If using <strong>MKS</strong> Integrity, you must have <strong>MKS</strong> Integrity 2005 or later<br />
installed and configured.<br />
261
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
<strong>MKS</strong> Source Setup and <strong>Administration</strong><br />
262<br />
The integration configuration steps you perform in <strong>MKS</strong> Source are one-time tasks. Once you<br />
complete these setup tasks, no ongoing tasks are required in <strong>MKS</strong> Source.<br />
NOTE The integration can run on the same or a separate server as the <strong>MKS</strong> Integrity<br />
integration and <strong>Implementer</strong> Server.<br />
The setup tasks in <strong>MKS</strong> Source require the assistance of your <strong>MKS</strong> Integrity administrator.<br />
Overall, the <strong>Implementer</strong> and <strong>MKS</strong> Source integration requires the skill sets of both your<br />
<strong>MKS</strong> Integrity administrator and <strong>Implementer</strong> administrator. <strong>MKS</strong> recommends you<br />
coordinate the configuration of this integration with the applicable administrators in your<br />
organization to ensure a successful and smooth process.<br />
The setup tasks in <strong>MKS</strong> Source include the following:<br />
Create two base projects in <strong>MKS</strong> Source to act as parent projects for the product and<br />
environment subprojects. This task begins on page 263.<br />
Create an <strong>MKS</strong> Source integration user, or use the existing <strong>MKS</strong> Integrity integration<br />
user. This task begins on page 264.<br />
Create an <strong>Implementer</strong> Developer group to manage users (developers) of the<br />
integration. This task begins on page 264.<br />
Assign <strong>MKS</strong> Source policies. This task begins on page 265.<br />
Assign ACL permissions to the integration user and <strong>Implementer</strong> Developer group. This<br />
task begins on page 268.<br />
Modify the <strong>MKS</strong> Integrity Client Client configuration file IntegrityClientSite.rc to<br />
enable developers to invoke <strong>MKS</strong> Source GUI gestures from their workstation. This<br />
allows launching annotated views and member history in <strong>MKS</strong> Source from the<br />
<strong>Implementer</strong> Workbench and Work with Objects, as well as WDSc. For details on this<br />
task, see “Modifying the <strong>MKS</strong> Integrity Server Configuration File” on page 206.<br />
When using <strong>MKS</strong> Integrity, the workflow State prior to the first environment enabled for<br />
<strong>MKS</strong> Source archiving (Version Environment, Archived by <strong>MKS</strong> Source = Y) must have<br />
the capability Allows open SI change packages to exist. <strong>MKS</strong> recommends you<br />
enable the first QA environment for <strong>MKS</strong> Source archiving to ensure that all source<br />
member changes promoted from development are captured in <strong>MKS</strong> Source. In this case,<br />
the workflow State In development (or the equivalent value you have defined) must<br />
have this capability. If you use <strong>MKS</strong> Integrity issues and require more information, see<br />
“<strong>Implementer</strong> State-based Capabilities” on page 208.<br />
Detailed information on how to perform each of these tasks is located in the <strong>MKS</strong> Integrity<br />
<strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>. In collaboration with that guide, the following sections contain<br />
important supplemental information you need to know when setting up <strong>MKS</strong> Source<br />
specifically for the integration with <strong>Implementer</strong> as described in this chapter.
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
A chronological checklist of the tasks required to configure the <strong>Implementer</strong> and <strong>MKS</strong> Source<br />
integration is provided page 296. <strong>MKS</strong> recommends you use the checklist to ensure you<br />
complete each required task in the order described.<br />
Creating Base Projects in <strong>MKS</strong> Source<br />
The base projects you create in <strong>MKS</strong> Source are specific to each copy of <strong>Implementer</strong> you<br />
integrate with <strong>MKS</strong> Source. Thus, if you have multiple copies of <strong>Implementer</strong> integrated with<br />
a single copy of <strong>MKS</strong> Source, each copy must reference a different set of base projects.<br />
<strong>MKS</strong> suggests you use a naming convention that is universally common, for example,<br />
BaseProductProject and BaseEnvironmentProject are the project names used<br />
throughout this documentation. Once you create the base projects, the necessary subprojects<br />
are created automatically within each base project based on the values you specify and<br />
functions you perform on <strong>Implementer</strong>’s release control panels.<br />
NOTE Parent projects in <strong>MKS</strong> Source are base projects in <strong>Implementer</strong>.<br />
Under the base product project, <strong>MKS</strong> Source automatically creates a product subproject for<br />
each application product you define in <strong>Implementer</strong>’s release control setup as archived by<br />
<strong>MKS</strong> Source. All source members are stored in these subprojects. When you add or update a<br />
member, the member is added or checked in to this subproject.<br />
NOTE The following task describes how to create a base product project and a base<br />
environment project. <strong>MKS</strong> Source automatically creates product and environment<br />
subprojects when you define the products and product/version/environments in<br />
<strong>Implementer</strong> and activate <strong>MKS</strong> Source archiving by setting the Archived by<br />
<strong>MKS</strong> Source field to Y for each. For details on creating projects in <strong>MKS</strong> Source, see<br />
the <strong>MKS</strong> Source <strong>2006</strong> User <strong>Guide</strong>.<br />
To create the base projects in the <strong>MKS</strong> Source GUI<br />
1 From the <strong>MKS</strong> Window, open the <strong>MKS</strong> Source ViewSet.<br />
2 Select Project > Create. The Specify the Project to Create dialog box displays.<br />
3 If your administrator has specified multiple server roots, from the Look in list select a<br />
location where you want to create the project. Otherwise, go to the next step.<br />
4 Enter the path and file name, or browse to a location on the <strong>MKS</strong> Integrity Server where<br />
you want to create the project, for example, C:/BaseProductProject. If the project<br />
path does not exist on the <strong>MKS</strong> Integrity Server, the new path is created.<br />
5 Enter a name for the project. The default project name is project.pj. The project is<br />
identified by the directory.<br />
6 Click OK. The project displays in a Project view.<br />
7 Repeat steps 1–6 to create the base environment project. Be sure to specify a different<br />
directory for this project.<br />
263
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
264<br />
Creating the Integration User<br />
You have the option to create a specific integration user, or designate an existing <strong>MKS</strong> Source<br />
user profile as the integration user. If you currently use <strong>MKS</strong> Integrity with <strong>Implementer</strong>,<br />
you probably already have a designated profile.<br />
TIP To identify your existing <strong>MKS</strong> Integrity integration user, from the <strong>Implementer</strong><br />
Menu select option 47, <strong>MKS</strong> Integrity Setup, to view the <strong>MKS</strong> Integrity User ID field<br />
value.<br />
Because of certain authorities the integration user must have, the integration user should be a<br />
user that does not usually sign on to the system or use the product. The primary functions of<br />
the integration user are:<br />
connect to the <strong>MKS</strong> Integrity Server from the <strong>Implementer</strong> Server<br />
execute certain commands that a typical user does not have authority to perform<br />
impersonate users to perform work on behalf of the impersonated user<br />
The integration user requires setup in <strong>MKS</strong> Source and <strong>Implementer</strong>. In a later task when you<br />
configure <strong>Implementer</strong> for the integration, you specify this user ID in the <strong>MKS</strong> Source User ID<br />
field on the <strong>MKS</strong> Source Setup panel. For details, see “Defining <strong>MKS</strong> Source Values in<br />
<strong>Implementer</strong>” on page 275.<br />
Information on setting permissions for the integration user begins on page 268. For details on<br />
creating users in <strong>MKS</strong> Integrity, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
Creating the <strong>Implementer</strong> Developer Group<br />
<strong>MKS</strong> recommends you create a group and add the iSeries users to the group, for example,<br />
implementer developer group is used throughout this documentation. This allows you to<br />
set ACLs and permissions for the group rather than for each individual user. If you use<br />
<strong>MKS</strong> Integrity with <strong>Implementer</strong> and you are using the same server for <strong>MKS</strong> Source<br />
integration, the group profile may already exist.<br />
IMPORTANT During a remote initiated move that updates the host, <strong>Implementer</strong> uses<br />
the profile MWIPROD to update the host. If you use remote initiated moves with<br />
host updates (remote environment defined with the Remote initiated move and<br />
Updates host fields set to Y) for promotions with <strong>MKS</strong> Source integration, the<br />
MWIPROD user profile must have an <strong>MKS</strong> Integrity user ID that is part of the<br />
group to work with <strong>MKS</strong> Source.<br />
Information on setting permissions for the <strong>Implementer</strong> Developer group or users begins on<br />
page 268. For details on creating groups or users, see the <strong>MKS</strong> Integrity Server <strong>2006</strong><br />
<strong>Administration</strong> <strong>Guide</strong>.
Setting <strong>MKS</strong> Source Policies<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
<strong>MKS</strong> Source policies at the global level. You can set the policies by using the <strong>MKS</strong> Integrity<br />
<strong>Administration</strong> Client as illustrated in the following task, or by editing the si.policy file<br />
located in the default installation directory C:/Program Files/<strong>MKS</strong> IntegrityServer/<br />
config/policies.<br />
For details on creating or editing <strong>MKS</strong> Source policies, see the <strong>MKS</strong> Integrity Server <strong>2006</strong><br />
<strong>Administration</strong> <strong>Guide</strong>.<br />
To edit <strong>MKS</strong> Source policies using the <strong>MKS</strong> Integrity <strong>Administration</strong> Client<br />
1 Open the <strong>MKS</strong> Integrity <strong>Administration</strong> Client.<br />
2 Click to expand the <strong>MKS</strong> Source node.<br />
3 Click to highlight the Policies section. The Global Policies section displays in the right<br />
pane.<br />
4 Highlight Global Policies in the right display pane.<br />
5 Select Policies > Edit. The policy editor displays the policy section you selected.<br />
TIP To edit global policies, you can also open the shortcut menu by highlighting Global<br />
Policies in the right pane, right clicking, and selecting Edit. To edit project policies,<br />
choose the project in the right pane, right click, and select Edit. If the projects are not<br />
listed, right click and select Create, and then select the appropriate project.<br />
To display the global policies that are set for the <strong>MKS</strong> Integrity Server, double click<br />
to expand the Global Policies section in the right pane.<br />
265
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
266<br />
NOTE To enable a policy option, select that option. For example, to require a<br />
revision description each time a member is checked in, select the Revision<br />
Description Required option. To lock any policy, click the lock box (on the left side)<br />
beside that policy. Locking a policy at the global level prevents any other project<br />
policy or client preference from overriding that policy. A check mark displays for all<br />
enabled policies. A lock symbol displays for all policies that are locked.<br />
Options that have been explicitly set display in a bold typeface.<br />
a) Click the General tab and set the mandatory policies as described in the following<br />
table.<br />
Global Policies: General<br />
Global Policy Policy Value<br />
Revision Description Required Disabled<br />
Archive Description Required Disabled<br />
Deferred Operations Mandatory Disabled<br />
b) Click the Change Packages tab and set the mandatory policies as described in the<br />
following table.<br />
Global Policies: Change Packages<br />
Global Policy Policy Value<br />
Change Packages Enabled Enabled<br />
Track Locks In Change Package Disabled<br />
Use Change Package Tracking Label Disabled<br />
Change Packages Mandatory Disabled<br />
Integrity Manager Issue Mandatory Disableda a While it is not a requirement to use <strong>MKS</strong> Integrity with the <strong>Implementer</strong> and <strong>MKS</strong> Source integration, if<br />
you are using <strong>MKS</strong> Integrity, this policy must be disabled.<br />
NOTE At any time after changing the policy settings, you can restore all default<br />
settings by clicking Reset to Defaults. Clicking the reset button resets only the<br />
options displayed on the current active tab.<br />
6 To accept the changes after editing the policies, click OK.<br />
7 Under the <strong>MKS</strong> Source node, click to expand the Permissions section.<br />
8 Under Permissions, click to highlight Global. A list of users and/or groups displays<br />
in the right pane.
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
9 From the menu, select ACL > Dev Path Inheritance to set the permission to enabled.<br />
When you have finished setting the policies, the expanded Global Policies should look<br />
similar to the following illustration (depending on other policies you may have defined).<br />
Creating and Setting an <strong>MKS</strong> Integrity ACL and Permission<br />
The integration with <strong>MKS</strong> Source requires the integration user configured in an integration<br />
group. <strong>MKS</strong> Source requires an ACL entry for internal processing.<br />
To configure the required <strong>MKS</strong> Integrity ACL<br />
1 On the <strong>MKS</strong> Integrity Server, click Start <strong>MKS</strong> Authorization <strong>Administration</strong>.<br />
2 Add the following required ACL entry:<br />
mks:impersonate:group:<br />
principle: <br />
Impersonate allowed<br />
IMPORTANT In this example, is a group that contains the<br />
integration user. Change this value to reflect the group name you created. To avoid<br />
compromising your security, use a group other than the everyone group; by default,<br />
all users are part of this group.<br />
267
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
268<br />
Creating and Setting <strong>MKS</strong> Source ACLs and Permissions<br />
You can set <strong>MKS</strong> Source ACL permissions at the global level or you can make them project<br />
specific. If you use <strong>MKS</strong> Source for multiple platform development in addition to<br />
<strong>Implementer</strong> iSeries projects, <strong>MKS</strong> recommends you define the permissions for this<br />
integration at the project level to avoid possible conflict with other projects that may require<br />
different ACL values.<br />
Once you have added the integration user and implementer developer group and/or<br />
users to <strong>MKS</strong> Integrity, you must set the ACL permissions that control user access to global<br />
functions, product projects, and environment projects.<br />
The integration user and implementer developer group require different global ACL<br />
permissions and different ACL permissions for projects.<br />
NOTE The following tasks are described using the <strong>MKS</strong> Integrity <strong>Administration</strong><br />
Client. For information on performing these tasks using the <strong>MKS</strong> Integrity Client<br />
GUI, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
The following tasks assume the principals exist. If the principals have not been<br />
created on your system, you must add or import them before you can assign the<br />
permissions.<br />
To set global ACL permissions for the integration user and <strong>Implementer</strong> developer<br />
group<br />
1 From the <strong>MKS</strong> Integrity <strong>Administration</strong> Client, open the <strong>MKS</strong> Source view, click to<br />
expand the Permission section, and then highlight Global. The display pane shows any<br />
existing permission information for the mks:si ACL.<br />
2 Right click to add the principal, or from the Principal list, select the <br />
user.<br />
3 From the menu, select ACL > Change Permissions. The Change Permissions dialog box<br />
displays.
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
4 In the Permissions area, change the condition of the following permissions by clicking<br />
the indicator box and toggling through the condition indicators until the box displays a<br />
green plus sign, indicating the allowed condition.<br />
Set permissions for the user as described in the following table.<br />
5 To accept the changes, click OK.<br />
6 Right click to add the principal, or from the Principal list, select the group.<br />
7 From the menu, select ACL > Change Permissions. The Change Permissions dialog box<br />
displays.<br />
8 In the Permissions area, change the condition of the following permissions by clicking<br />
the indicator box and toggling through the condition indicators until the box displays a<br />
green plus sign, indicating the allowed condition.<br />
Set permissions for the implementer developer group as described in the following<br />
table.<br />
9 To accept the changes, click OK.<br />
Global ACL Permissions: Integration User<br />
ACL Permission Permission Value<br />
AddMember Allowed<br />
ChangePackageAdmin Allowed<br />
CreateChangePackage Allowed<br />
Login Allowed<br />
ShareArchive Allowed<br />
Global ACL Permissions: <strong>Implementer</strong> Developer Group<br />
ACL Permission Permission Value<br />
AddMember Allowed<br />
CreateChangePackage Allowed<br />
Login Allowed<br />
ShareArchive Allowed<br />
To set base product project ACL permissions for the integration user and <strong>Implementer</strong><br />
developer group<br />
1 From the <strong>MKS</strong> Integrity <strong>Administration</strong> Client, open the <strong>MKS</strong> Source view, click to<br />
expand the Permissions section, and highlight Projects. The display pane shows any<br />
existing project permission information for the mks:si ACL.<br />
269
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
270<br />
2 To create a project ACL, select ACL > Create Project ACL from the main menu. The Select<br />
a Project dialog box displays.<br />
NOTE The following illustration shows an existing project ACL.<br />
3 Select the registered <strong>MKS</strong> Source project to create the ACL for,<br />
and click OK. The Confirm ACL Creation dialog box displays.<br />
4 To create the new project ACL, click Yes. The Select ACL Entries to Add dialog box<br />
displays the project ACL name. For example, for the BaseProductProject project, the<br />
project ACL name is mks:si:project:id:BaseProductProject.
5 From the Principal list, select the user.<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
6 In the Permissions area, change the condition of the following required permissions as<br />
described by clicking the indicator box and toggling through the condition indicators<br />
until the box displays a green plus sign, indicating the allowed condition.<br />
Set permissions for the user as described in the following table.<br />
ACL Permissions: Base Product Project: Integration User<br />
ACL Permission Permission Value<br />
AddSubproject Allowed<br />
ApplyProjectLabel Allowed<br />
Checkpoint Allowed<br />
CreateDevpath Allowed<br />
CreateSubproject Allowed<br />
DeleteProjectLabel Allowed<br />
FetchRevision Allowed<br />
ModifyProjectAttribute Allowed<br />
MoveProjectLabel Allowed<br />
OpenProject Allowed<br />
NOTE You can set all other permissions to allowed or denied as needed.<br />
7 To accept the changes, click OK.<br />
8 From the menu, select ACL > View ACL. An ACL mks:si:project view displays.<br />
271
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
272<br />
9 Right click the group, and select Change Permissions. The<br />
Change Permissions dialog box displays.<br />
10 Click Deny All to deny all permissions.<br />
11 Set the ACL permissions for implementer developer group for the<br />
as described in the following table.<br />
ACL Permissions: Base Product Project: <strong>Implementer</strong> Developer Group<br />
ACL Permission Permission Value<br />
AddMember Allowed<br />
CheckIn Allowed<br />
FetchRevision Allowed<br />
Lock Allowed<br />
ModifyAuthor Allowed<br />
ModifyMember Rev Allowed<br />
OpenProject Allowed<br />
12 To accept the changes, click OK. An ACL mks:si:project view displays.<br />
13 Click Close.<br />
To set base environment project ACL permissions for the integration user and<br />
implementer developer group<br />
1 From the <strong>MKS</strong> Integrity <strong>Administration</strong> Client, open the <strong>MKS</strong> Source view, expand the<br />
Permission section, and then highlight Projects. The display pane shows any existing<br />
<strong>MKS</strong> Source projects.<br />
2 Select the registered <strong>MKS</strong> Source project to create the<br />
ACL for, and click OK. The Confirm ACL Creation dialog box displays.
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
3 To create the new project ACL, click Yes. The Select ACL Entries to Add dialog box<br />
displays the project ACL name. For example, for the BaseEnvironmentProject<br />
project, the project ACL name is mks:si:project:id:BaseEnvironmentProject.<br />
4 From the Principal list, select the user.<br />
5 Set permissions for the user as described in the following table.<br />
ACL Permissions: Base Environment Project: Integration User<br />
ACL Permission Permission Value<br />
AddSubproject Allowed<br />
ApplyProjectLabel Allowed<br />
Checkpoint Allowed<br />
CreateDevpath Allowed<br />
CreateSubproject Allowed<br />
DeleteProjectLabel Allowed<br />
FetchRevision Allowed<br />
ModifyProjectAttribute Allowed<br />
MoveProjectLabel Allowed<br />
OpenProject Allowed<br />
NOTE You can set all other permissions to allowed or denied as needed.<br />
6 To accept the changes, click OK.<br />
7 From the menu, select ACL > View ACL. An ACL mks:si:project view displays.<br />
8 Right click group and select Change Permissions. The<br />
Change Permissions dialog box displays.<br />
9 Click Deny All to deny all permissions.<br />
10 Set the ACL permissions for the implementer developer group for the<br />
as described in the following table.<br />
273
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
274<br />
ACL Permissions: Base Environment Project: <strong>Implementer</strong> Developer Group<br />
ACL Permission Permission Value<br />
AddMember Allowed<br />
DropMember Allowed<br />
FetchRevision Allowed<br />
ModifyMemberRev Allowed<br />
OpenProject Allowed<br />
11 To accept the changes, click OK. An ACL mks:si:project view displays.<br />
12 Click Close.<br />
This concludes the setup tasks in <strong>MKS</strong> Source. The <strong>Implementer</strong> administrator must perform<br />
the following setup tasks in <strong>Implementer</strong>.<br />
<strong>Implementer</strong> Setup and <strong>Administration</strong><br />
The setup and administration steps in <strong>Implementer</strong> are primarily one-time tasks; however,<br />
the <strong>MKS</strong> Source integration adds a few steps to the standard <strong>Implementer</strong> release control<br />
activities, which are periodic ongoing tasks. Once you complete the initial tasks to configure<br />
the <strong>MKS</strong> Source integration, the ongoing tasks are standard functions that apply to using<br />
release control within the development cycle and using <strong>MKS</strong> Source as an additional<br />
repository for <strong>Implementer</strong> source.<br />
The setup tasks in <strong>Implementer</strong> require the assistance of your <strong>Implementer</strong> administrator.<br />
Overall, the <strong>Implementer</strong> and <strong>MKS</strong> Source integration requires the skill sets of both your<br />
<strong>MKS</strong> Integrity administrator and <strong>Implementer</strong> administrator. <strong>MKS</strong> recommends you<br />
coordinate the configuration of this integration with the applicable administrators in your<br />
organization to ensure a successful and smooth process.<br />
The one-time setup tasks in <strong>Implementer</strong> include the following:<br />
Define <strong>MKS</strong> Source values in <strong>Implementer</strong>. This task begins on page 275.<br />
Verify object codes for archiving in <strong>MKS</strong> Source. This task begins on page 278.<br />
Verify <strong>Implementer</strong> user profiles have a valid <strong>MKS</strong> Integrity user ID. This task is<br />
described on page 235.<br />
Perform product maintenance (create an initial product or use an existing product) and<br />
activate product source archiving in <strong>MKS</strong> Source to create a product subproject. This<br />
task begins on page 280.<br />
Perform product version maintenance (create a new version or use an existing version)<br />
and set the development path for the current version to *HEADREV (or *VERSION if not<br />
the current release). This task begins on page 283.
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
Starting with production and moving toward QA1, perform product/version/<br />
environment maintenance (use an existing or create a new product/version/<br />
environment) and activate <strong>MKS</strong> Source archiving for the environment, which creates<br />
and populates an environment subproject in <strong>MKS</strong> Source. This task begins on page 286.<br />
A chronological checklist of the tasks required to configure the <strong>Implementer</strong> and <strong>MKS</strong> Source<br />
integration is provided page 296. <strong>MKS</strong> recommends you use the checklist to ensure you<br />
complete each required task in the order described.<br />
NOTE The <strong>Implementer</strong> Server must be active for successful communications with<br />
<strong>MKS</strong> Source. For information on reloading the server with current configuration<br />
and environment information if communications fail, see “Managing <strong>Implementer</strong><br />
Server” on page 223.<br />
Defining <strong>MKS</strong> Source Values in <strong>Implementer</strong><br />
You activate the integration and define the <strong>MKS</strong> Source communication parameters in<br />
<strong>Implementer</strong> on the <strong>MKS</strong> Source Setup panel.<br />
Your <strong>Implementer</strong> user profile must have authority to maintain System Control Maintenance<br />
(defined in Work with Users) to change the default values on the <strong>MKS</strong> Source Setup panel.<br />
Without this authority, changes to the panel are not allowed.<br />
To define <strong>MKS</strong> Source values in <strong>Implementer</strong> and activate the integration<br />
1 From the <strong>MKS</strong> <strong>Implementer</strong> Menu, type 48, <strong>MKS</strong> Source Setup, and press ENTER, or<br />
issue the STRIM *SRCMGT command. The <strong>MKS</strong> Source Setup panel displays.<br />
275
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
276<br />
2 In the Integration enabled field, type Y.<br />
NOTE Once the integration is active, if you later decide to disable it after using<br />
<strong>MKS</strong> Source archiving, a message notifies you that all products configured for the<br />
integration must have the Archived by <strong>MKS</strong> Source set to N before you can disable<br />
the integration on this panel.<br />
3 In the Communications timeout, Server, Server browser port, <strong>MKS</strong> Source User ID, and<br />
Password fields, do either of the following:<br />
Press F16=Copy <strong>MKS</strong> Integrity Setup to import the values defined on the<br />
<strong>MKS</strong> Integrity Setup panel. Use this option when <strong>MKS</strong> Source and <strong>MKS</strong> Integrity<br />
are located on the same server.<br />
Complete the fields as described in the following table. Use this option when<br />
<strong>MKS</strong> Source and <strong>MKS</strong> Integrity are located on different servers and/or use different<br />
user IDs.<br />
4 In the Base Product project and Base Environment project fields, specify the values as<br />
described in the table on page 277.<br />
5 Press F7=Test to ensure communications are active and a connection can be established.<br />
If communications are successful, the System available field value changes to Y, and<br />
a message at the bottom of the panel confirms the status. Continue with the next<br />
step.<br />
If communications are not successful, you must resolve the communication problem<br />
before continuing. Once resolved, continue with the next step.<br />
6 Press ENTER. The two base projects you specified validate in <strong>MKS</strong> Source. An error<br />
displays if problems occur attempting to access the information. After resolving the<br />
error, press ENTER to update the information.<br />
Field Description<br />
<strong>MKS</strong> Source current status<br />
System available<br />
<strong>MKS</strong> Source Setup Field Descriptions<br />
Indicates if communications are active and the integration between<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source is enabled at the system level.<br />
Yes: Communications are active and the integration is<br />
functioning. Required value to receive edit checks on the<br />
remaining fields on this panel.<br />
No: Communications are inactive and the integration is not<br />
functional.
Field Description<br />
<strong>MKS</strong> Source Setup Field Descriptions<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
<strong>MKS</strong> Source connection setup<br />
The following fields define the communication parameters that allow <strong>Implementer</strong> to integrate with<br />
<strong>MKS</strong> Source.<br />
Integration enabled Specify whether the integration between <strong>Implementer</strong> and<br />
<strong>MKS</strong> Source is active.<br />
Yes: The integration is active. Specify Y to activate the<br />
integration.<br />
No: The integration is not active. Specify N to deactivate the<br />
integration. You can also use this setting to save current values<br />
not yet finalized while troubleshooting communication problems.<br />
Communications timeout Number of seconds <strong>Implementer</strong> waits for a valid response after<br />
contacting <strong>MKS</strong> Integrity Server running <strong>MKS</strong> Source. Only used<br />
when <strong>MKS</strong> Source is used for source archiving.<br />
If communications between <strong>Implementer</strong> and <strong>MKS</strong> Integrity Server<br />
are slow, set this to a higher number to prevent time outs during<br />
normal usage, such as if the <strong>MKS</strong> Integrity Server is available but<br />
not responding in a timely manner due to heavy traffic.<br />
Server IP address or host name of <strong>MKS</strong> Integrity Server running<br />
<strong>MKS</strong> Source. Used for all communications between <strong>Implementer</strong><br />
and <strong>MKS</strong> Integrity Server. Must be a host name or IP address, not<br />
a URL that begins with http:// or https://. Can be the same<br />
server or a different server than that specified in the <strong>MKS</strong> Integrity<br />
Setup panel. Do not enclose the value in quotes.<br />
Server browser port The port number used to communicate to <strong>MKS</strong> Integrity Server<br />
running <strong>MKS</strong> Source. Specify a value between 1–65535.<br />
<strong>MKS</strong> Source User ID User profile that has administrative rights in <strong>MKS</strong> Source. This<br />
user ID is used to test the connection to <strong>MKS</strong> Integrity Server, and<br />
is the impersonation user ID used to proxy all commands between<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source. Must be the same user ID as<br />
described in “Creating the Integration User” on page 264. Casesensitive<br />
field—the case specified in <strong>MKS</strong> Source must be<br />
specified here.<br />
Password Password of the <strong>MKS</strong> Source user ID specified in the previous<br />
field. Non display field that displays as blank when typing the<br />
password value. Case-sensitive field—the case specified in<br />
<strong>MKS</strong> Source must be specified here.<br />
Base Product project Specify the base product project in <strong>MKS</strong> Source that all product<br />
subprojects are created under. The project is validated in<br />
<strong>MKS</strong> Source; thus, it must exist in <strong>MKS</strong> Source prior to referencing<br />
here. Type the value exactly as it exists in the <strong>MKS</strong> Source project<br />
directory (including the directory, file name, and file extension), for<br />
example, c:/BaseProductProject/project.pj. a<br />
277
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
278<br />
Field Description<br />
<strong>MKS</strong> Source Setup Field Descriptions<br />
Base Environment project Specify the base environment project in <strong>MKS</strong> Source that all<br />
environment subprojects are created under. The project is<br />
validated to <strong>MKS</strong> Source; thus, it must exist in <strong>MKS</strong> Source prior to<br />
referencing here. Type the value exactly as it exists in the<br />
<strong>MKS</strong> Source project directory (including the directory, file name,<br />
and file extension), for example, c:/<br />
BaseEnvironmentProject/project.pj. a<br />
a The BaseProductProject and BaseEnvironmentProject do not have to be top level projects in<br />
<strong>MKS</strong> Source. The format of your projects may be different from the examples based on your<br />
<strong>MKS</strong> Source platform and configuration options. Ask your <strong>MKS</strong> Source administrator for the exact<br />
entries.<br />
Controlling Archiving in <strong>MKS</strong> Source by Object Code<br />
You can activate and deactivate <strong>MKS</strong> Source archiving at the object code level in<br />
<strong>Implementer</strong>. The archive value set for an object code applies to all environments configured<br />
for <strong>MKS</strong> Source archiving.<br />
When the <strong>Implementer</strong> and <strong>MKS</strong> Source integration is enabled, an object codes’s Archived by<br />
<strong>MKS</strong> Source value defaults based on the following rules:<br />
Source-based object codes and those with a special characteristic of PCFILE are set to<br />
automatically archive in <strong>MKS</strong> Source.<br />
Non source-based object codes and those with a special characteristic of PCDIR are not<br />
eligible for archiving in <strong>MKS</strong> Source; thus, they are set to a value that does not allow<br />
<strong>MKS</strong> Source archiving and cannot be changed.<br />
Before allowing check out and promotion activities using the <strong>MKS</strong> Source integration, you<br />
can optionally deactivate <strong>MKS</strong> Source archiving for other object codes you may not want<br />
archived, for example, IFS object codes for .jar files or Lotus Notes database files.<br />
IMPORTANT Before allowing <strong>Implementer</strong> check out and promotion activity with<br />
<strong>MKS</strong> Source archiving enabled, review the object code Archived by <strong>MKS</strong> Source<br />
values and make any necessary changes. After check out and promotion activity<br />
begins with <strong>MKS</strong> Source archiving enabled, you must only change the Archived by<br />
<strong>MKS</strong> Source value when <strong>Implementer</strong> check out and promotions are not active.<br />
If you change the Archived by <strong>MKS</strong> Source value to Y, to establish accurate<br />
<strong>MKS</strong> Source revisions for existing items with the new object code value, you must<br />
disable and repopulate all archived product/version/environments. To do this,<br />
change the Archived by <strong>MKS</strong> Source value from Y to N for all archived product/<br />
version/environments, then in Product Version Maintenance use F6=Enable<br />
<strong>MKS</strong> Source Archiving, starting with the oldest *VERSION ending with the<br />
*HEADREV version. For more information, see “To create archives for existing<br />
previous versions of iSeries source” on page 285.
To set object codes for archiving in <strong>MKS</strong> Source<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
1 From the <strong>Implementer</strong> Menu, type option 44, Object Codes, and press ENTER. The Work<br />
with Object Codes panel displays.<br />
2 To change an existing object code, type 2=Change next to an object code, and press<br />
ENTER. The Change Object Code panel displays.<br />
3 Complete the panel as needed. For details on completing this panel, see “Object Codes”<br />
on page 127.<br />
In the Archive in <strong>MKS</strong> Source field, specify one of the following:<br />
Y=Yes Archives source for the object code in <strong>MKS</strong> Source if the target<br />
environment is eligible. This is the default value and valid only for<br />
source-based object codes and those with the special characteristic<br />
PCFILE.<br />
N=No Does not archive source for the object code in <strong>MKS</strong> Source. This is the<br />
default value and required value for non source-based object codes<br />
and those with the special characteristic PCDIR.<br />
After changing the field value, a dialog window requires you confirm the action. Type Y,<br />
and press ENTER. <strong>Implementer</strong> searches the repository for objects with this object code. If<br />
an item with this object code has association with an environment archived in<br />
<strong>MKS</strong> Source, existing revisions are removed from all repository items and locks for the<br />
object code/environment.<br />
4 Press ENTER.<br />
279
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
280<br />
Product Setup and Source Archiving<br />
Products are a component of <strong>Implementer</strong>’s release control feature. Release control allows<br />
you to internally manage your software release process as a fundamental part of your daily<br />
change management operation that includes software versioning at the product, version,<br />
release and environment level. It provides for additional management, control, and<br />
orientation by release name or release number, allowing you to effectively manage<br />
production environments.<br />
With release control you can name each release of software before rolling out to production.<br />
While preparing a release for rollout, you automatically “freeze” the environments that<br />
manage the release to ensure unplanned changes are not subsequently promoted beyond a<br />
user-specified cutoff period. After rollout you can view the release history for that release<br />
and other releases as part of the post-project assessment.<br />
In <strong>Implementer</strong> Menu option 51, Products, you must define each product associated with<br />
<strong>MKS</strong> Source archiving. You have the option to use existing products or create new products.<br />
You then activate <strong>MKS</strong> Source archiving for the product, which automatically creates the<br />
product’s subproject in <strong>MKS</strong> Source. <strong>Implementer</strong>’s Product Maintenance panel allows you<br />
to establish product archiving in <strong>MKS</strong> Source. When the Archived by <strong>MKS</strong> Source field value<br />
is N, field entry is not allowed. To change the value to Y and create the product subproject in<br />
<strong>MKS</strong> Source, you use the function F6=Enable <strong>MKS</strong> Source Archiving.<br />
NOTE For details on release management and deployment, see the <strong>MKS</strong> <strong>Implementer</strong><br />
<strong>2006</strong> Release Management <strong>Guide</strong>.<br />
Requirements and Considerations<br />
Each product corresponds to the product subproject directory in <strong>MKS</strong> Source. For this<br />
reason, the product names you use must conform to a naming convention that is<br />
representable on the file system of the operating system that hosts the server for<br />
<strong>MKS</strong> Source. Generally, the product name must start with a letter A–Z and continue<br />
with a contiguous sequence of letters A–Z, numbers 0–9, or underscores ‘_’. The product<br />
name allows 10 characters consisting of letters and numbers only (no special characters),<br />
for example, ACCTRVCV06 is allowed, ACCTRCV-06 is not allowed. (This requirement<br />
also applies to the names of versions, releases, and environments.)<br />
Multiple products cannot archive the same environment—only one product can archive<br />
an environment in <strong>MKS</strong> Source.<br />
The base product project must exist in <strong>MKS</strong> Source before performing the following task.<br />
To work with products and enable <strong>MKS</strong> Source archiving to create product subprojects<br />
1 From the <strong>Implementer</strong> Menu, type option 51, Products, and press ENTER. The Work with<br />
Products panel displays.
2 Do one of the following to display the Product Maintenance window:<br />
Type 1=Create on the first option line, and press ENTER.<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
Select an existing product with option 2=Change, and press ENTER.<br />
Select an existing product with option 3=Copy, and press ENTER.<br />
3 Complete the fields as required. For detailed information on this panel, see the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release Management <strong>Guide</strong>.<br />
4 The Archived by <strong>MKS</strong> Source field defaults to N. To activate source archiving for this<br />
product in <strong>MKS</strong> Source, press F6=Enable <strong>MKS</strong> Source Archiving.<br />
NOTE If the <strong>MKS</strong> Source integration is not active on the <strong>MKS</strong> Source Setup panel in<br />
<strong>Implementer</strong>, the Archived by <strong>MKS</strong> Source field is view-only and function key<br />
F6=Enable <strong>MKS</strong> Source archiving does not display. For details, see “Defining<br />
<strong>MKS</strong> Source Values in <strong>Implementer</strong>” on page 275.<br />
A message displays requiring you to confirm your request to create an <strong>MKS</strong> Source<br />
product project for the selected <strong>Implementer</strong> product.<br />
281
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
282<br />
5 To continue, type Y, and press ENTER.<br />
A series of validations ensure you have the required permissions. A message notifies of<br />
problems trying to create the product project, or if the product or subproject already<br />
exist in <strong>MKS</strong> Source.<br />
IMPORTANT Once you archive a product in <strong>MKS</strong> Source, the Archived by<br />
<strong>MKS</strong> Source field is editable and can be changed to N if needed. If you change the<br />
value to N to deactivate archiving, a message notifies you that interim development<br />
activity performed while environment archiving is not active causes gaps in the<br />
version history if you later reactivate archiving. Interim source changes are not<br />
captured separately in the archives while archiving is off; however, the next<br />
promoted version captures any changes made since the last archived promotion.<br />
You must confirm your request to deactivate archiving. To re-establish the<br />
integration, additional setup work is required. Any change to the Archived by<br />
<strong>MKS</strong> Source field value causes a source reload in <strong>MKS</strong> Source to ensure the server is<br />
refreshed with current data.<br />
Once all edits are passed, a confirmation panel confirms creation of the subproject. On<br />
the Product Maintenance panel, the Archived by <strong>MKS</strong> Source field updates to Y.<br />
<strong>MKS</strong> Source creates the product subproject, for example, the product Inventory has the<br />
subproject INVENTORY/project.pj under the base product project c:/<br />
BaseProductProject/project.pj as illustrated next.<br />
6 Repeat steps 2–5 for each product to archive in <strong>MKS</strong> Source.<br />
NOTE Permissions for each product subproject are inherited from the base product<br />
project.
Product Version Setup and Development Paths<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
Each product you define in <strong>Implementer</strong> and associate with <strong>MKS</strong> Source archiving has one or<br />
more versions that represent different stages of the software. You have the option to use<br />
existing versions or create new versions.<br />
Each product version is associated with a development path in <strong>MKS</strong> Source. The<br />
development path is an identifier that specifies a branch of software development. Changes<br />
made through a new *VERSION development path are assigned suffixed revisions, for<br />
example, 1.4.1.2, which distinguishes them from the unsuffixed revisions assigned to the<br />
main *HEADREV development trunk, for example, 1.5. This allows you to track logical<br />
revisions for multiple versions of a product in simultaneous development.<br />
<strong>Implementer</strong>’s Product Version Maintenance panel allows you to establish the development<br />
path for a product version. Once established, you can process the update that creates the<br />
development path in <strong>MKS</strong> Source.<br />
The valid development path values are as follows:<br />
*NONE: Versions set to development path *NONE are not archived. This is the default<br />
value <strong>Implementer</strong> assigns to the development path for a product version. It is also used<br />
for older releases that are not archived in <strong>MKS</strong> Source.<br />
*HEADREV: This is the starting point for a new version and represents the current<br />
version in development. It is the main trunk on a version tree. The head revision uses the<br />
main trunk development path in the project. The main trunk development path is<br />
always present (you cannot create it).<br />
Only one version of a product can have the development path value *HEADREV<br />
specified at a time. All prior versions must be set to *VERSION before assigning the<br />
value *HEADREV to a new version.<br />
*VERSION: This is a branch on a trunk. You manually set an outgoing *HEADREV<br />
product version’s development path from *HEADREV to *VERSION before you create a<br />
new version, which becomes the new *HEADREV trunk version.<br />
Requirements and Considerations<br />
The version name corresponds to the project checkpoint and development path in<br />
<strong>MKS</strong> Source. For this reason, the version names you use must be representable on the file<br />
system of the operating system hosting the server for <strong>MKS</strong> Source. The version name<br />
must start with a letter A–Z and continue with a contiguous sequence of letters A–Z,<br />
numbers 0–9, or underscores ‘_’.<br />
When a product version has a based on product/version/release specified, the based on<br />
product/version/release must be checkpointed in <strong>MKS</strong> Source. For details, see<br />
“Product/Version/Release Setup and Checkpointing in <strong>MKS</strong> Source” on page 291.<br />
283
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
284<br />
Only one version per product can be set to *HEADREV. When multiple versions exist,<br />
you must set all previous versions to *VERSION before you can set a new version to<br />
*HEADREV.<br />
The product version must not have open releases when creating the development path.<br />
A message notifies you if open releases exist.<br />
Before creating a new release of a product, you must close the current release.<br />
To work with product versions and set the <strong>MKS</strong> Source development path for a version<br />
1 From the <strong>Implementer</strong> Menu, type option 51, Products, and press ENTER. The Work with<br />
Products panel displays.<br />
2 Select the product with option 10=Work with Versions, and press ENTER. The Work with<br />
Product Versions panel displays.<br />
3 Do one of the following to display the Product Version Maintenance window:<br />
Type 1=Create on the first option line, and press ENTER.<br />
Select an existing version with option 2=Change, and press ENTER.<br />
Select an existing version with option 3=Copy, and press ENTER.<br />
NOTE If <strong>Implementer</strong> or the product are not set up for <strong>MKS</strong> Source archiving, the<br />
<strong>MKS</strong> Source Devpath field is view-only, and function key F6=Create Development<br />
Path does not display. For details, see “Product Setup and Source Archiving” on<br />
page 280, and “Defining <strong>MKS</strong> Source Values in <strong>Implementer</strong>” on page 275.
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
4 Complete the fields as required. For <strong>MKS</strong> Source integration, the relevant fields are<br />
Version, Version Description, Based on Product, Based on Version, Based on Release,<br />
and <strong>MKS</strong> Source Devpath. For details on this panel, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release<br />
Management <strong>Guide</strong>.<br />
Do one of the following:<br />
a) If this is the current version, in the <strong>MKS</strong> Source Devpath field, type *HEADREV (this is<br />
the starting point for the version, which is used to create the next current release),<br />
and press ENTER.<br />
b) If this is a previous version (not the current version) in the <strong>MKS</strong> Source Devpath<br />
field type *VERSION.<br />
NOTE The next two steps only apply to the *VERSION development path. The<br />
*HEADREV development path automatically assigns revisions from the main trunk;<br />
therefore, it does not require a development path assigned.<br />
5 To create the *VERSION development path in <strong>MKS</strong> Source, press F6=Create<br />
Development Path in <strong>MKS</strong> Source. A message displays requiring you to confirm your<br />
request to create the <strong>MKS</strong> Source development path for the selected <strong>Implementer</strong><br />
product version.<br />
6 To continue, type Y, and press ENTER.<br />
A series of validations ensure you have the required permissions and the development<br />
path can be created. A message displays if the product development path already exists<br />
or if the product version has an open release. Once all validations successfully pass, the<br />
product project is checkpointed in <strong>MKS</strong> Source with a checkpoint name equal to the<br />
version name, and a development path is created on the checkpoint.<br />
7 Repeat steps 2–6 for each version of the product that requires a development path in<br />
<strong>MKS</strong> Source.<br />
To create archives for existing previous versions of iSeries source<br />
1 Activate archiving for the product.<br />
2 Activate archiving for the oldest version you want to archive in <strong>MKS</strong> Source. Specify the<br />
development path *HEADREV.<br />
3 Activate archiving for each environment within the version.<br />
4 Change the version to use development path *VERSION, and create the development<br />
path.<br />
5 Activate archiving for the next oldest version you want to archive in <strong>MKS</strong> Source.<br />
Specify the development path *HEADREV.<br />
6 Activate archiving for each environment within that version.<br />
285
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
286<br />
7 Repeat steps 4–6 for each of the remaining versions, from the oldest version to the most<br />
current version.<br />
8 Activate archiving for the current version. Specify the development path *HEADREV.<br />
9 Activate archiving for each environment within the current version.<br />
IMPORTANT Once you archive a product version in <strong>MKS</strong> Source, if you change the<br />
<strong>MKS</strong> Source Devpath back to *NONE a dialog window notifies you that the action<br />
results in disabling the integration. Thus, any interim development activity<br />
performed while environment archiving is inactive causes gaps in the version<br />
archive if you later reactivate the integration and archiving.<br />
Product/Version Environments Setup and Environment Population<br />
<strong>Implementer</strong>’s Product Version Environment Maintenance panel allows you to activate<br />
source archiving for the environment, which automatically populates the environment<br />
project in <strong>MKS</strong> Source. This process performs the initial import of environment source by<br />
copying all eligible source items in the <strong>Implementer</strong> environment on the iSeries, performs a<br />
mass check in to the product subproject, imports into the environment subproject, and<br />
updates the <strong>Implementer</strong> repository and locks with the new revisions provided by<br />
<strong>MKS</strong> Source.<br />
Requirements and Considerations<br />
This function applies to production and QA environments only.<br />
Environment names correspond to the environment subproject directory in <strong>MKS</strong> Source.<br />
For this reason, the environment names you use must be representable on the file system<br />
of the operating system hosting the server for <strong>MKS</strong> Source. The environment name must<br />
start with a letter A–Z and continue with a contiguous sequence of letters A–Z, numbers<br />
0–9, or underscores ‘_’.<br />
Running simultaneous environment population jobs can result in invalid revisions in<br />
<strong>MKS</strong> Source and invalid revision references in <strong>Implementer</strong>. Therefore, you must<br />
process the environment population job in a single threaded job queue, or verify the<br />
results of each environment population are correct before enabling the next environment<br />
population.<br />
You must run a Build List for each applicable environment before performing this step.<br />
For details, see page 117.<br />
The environment can be associated with multiple product/versions, but can only be<br />
archived in one product/version.<br />
If a based on product/version/release is specified in the product/version, it must exist<br />
in <strong>Implementer</strong>.
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
If a based on environment is specified, the based on product/version/release specified<br />
in the associated product/version must have a product/version/environment with the<br />
same environment name as the based on environment specified in the target<br />
environment.<br />
The based on product version environment must be archived in <strong>MKS</strong> Source to provide<br />
the starting revisions for the new environment’s population.<br />
You must enable environments in a specific order to ensure the production environment<br />
is assigned lower revisions than those assigned to items in QA environments. First,<br />
enable the production (*PRD) environment and then enable the quality assurance<br />
environments (*QAC). If you have multiple *QAC environments, enable them in order<br />
from production toward QA1, for example, QA4, QA3, QA2, QA1, where QA4 is the<br />
environment closest to “going into” production.<br />
The environment population uses <strong>Implementer</strong>’s repository entries and locks to control<br />
when it assigns new revisions as follows:<br />
When processing a production member, if a based on environment is not specified<br />
or the member does not exist in the based on environment, <strong>Implementer</strong> performs<br />
an <strong>MKS</strong> Source check in to assign the initial revision ID.<br />
When a member exists in a based on environment, <strong>Implementer</strong> uses the based on<br />
member’s revision to assign the new environment member revision.<br />
When processing a member from QA and a lock does not exist, <strong>Implementer</strong><br />
searches the product/version environment list toward production and uses the<br />
revision from the first environment where the member exists.<br />
When processing a member from QA and a lock exists, <strong>Implementer</strong> performs an<br />
<strong>MKS</strong> Source check in to generate a new revision ID.<br />
The following table illustrates the results of processing a member.<br />
Environment Sequence Number Lock Assigned Revision Assigned<br />
PRD 10 N 1.1<br />
QA4 20 N 1.1<br />
QA3 30 Y 1.2<br />
QA2 40 N 1.2<br />
QA1 50 Y 1.3<br />
287
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
288<br />
NOTE<br />
When enabling an environment, <strong>Implementer</strong> verifies the sequence you have<br />
defined on the Product Version Environment Maintenance panel to ensure the<br />
environments process in sequential order from production to QA1.<br />
It is not necessary to enable all environments for a product/version. The revision<br />
advances when the lock moves into the first <strong>MKS</strong> Source archive-enabled<br />
environment encountered.<br />
To work with product/version environments and perform the initial environment<br />
population<br />
1 From the <strong>Implementer</strong> Menu, type option 51, Products, and press ENTER. The Work with<br />
Products panel displays.<br />
2 Select the product with option 10=Work with Versions, and press ENTER. The Work with<br />
Product Versions panel displays.<br />
3 Do one of the following to display the Product Version Environment Maintenance<br />
window:<br />
Type 1=Create on the first option line, and press ENTER.<br />
Select an existing version with option 2=Change, and press ENTER.<br />
Select an existing version with option 3=Copy, and press ENTER.
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
4 Complete the fields as required. For detailed information on this panel, see the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release Management <strong>Guide</strong>.<br />
In the Based on environment field, type the environment name, or position the<br />
cursor in the field, and press F4=Select Environment and use option 1=Select to<br />
select an environment on the Environment Selection window.<br />
In the Always checkout from <strong>MKS</strong> Source field, specify Y to always check out source<br />
from <strong>MKS</strong> Source. With this option, native source member sequence numbers and<br />
source change dates are not maintained when a member is checked out.<br />
The default value N allows you to specify the source check out location as either<br />
<strong>MKS</strong> Source or as a local repository, which maintains native source member line<br />
sequence numbers and source change dates.<br />
The Archived by <strong>MKS</strong> Source field is view-only when the field value is N. This the<br />
required value to change the Based on environment field value as described in the next<br />
step. The value automatically changes to Y after successfully completing the<br />
environment population. Performing an environment population is the only way to set<br />
the field value to Y (you cannot manually change the value to Y). If the job no longer<br />
exists, for example, it was deleted from queue, you can change the value to N, and then<br />
rerun the environment population. If the job fails, you must first resolve the cause of the<br />
failure before rerunning the job.<br />
IMPORTANT Once the environment population successfully completes and the<br />
Archived by <strong>MKS</strong> Source field is set to Y, you can change the value back to N to stop<br />
archiving. This action displays a message to inform you that any development<br />
activity performed while environment archiving is not active causes interim gaps in<br />
the archived versions if you later reactivate archiving.<br />
5 To perform the environment population, press F6=Enable <strong>MKS</strong> Source Archiving.<br />
NOTE Function F6=Enable <strong>MKS</strong> Source Archiving is available only when: The<br />
integration is enabled in <strong>MKS</strong> Source Setup, the product is archived in <strong>MKS</strong> Source,<br />
the product/version is either *HEADREV or *VERSION, and the Archived by<br />
<strong>MKS</strong> Source value is N.<br />
If the product/version has the <strong>MKS</strong> Source Devpath value *VERSION, <strong>Implementer</strong><br />
verifies the development path exists in <strong>MKS</strong> Source. If it does not exist, a message<br />
confirms that you must create the development path in <strong>MKS</strong> Source before performing<br />
the environment population. For details, see “Product Version Setup and Development<br />
Paths” on page 283.<br />
Once all validations pass, a confirmation window displays.<br />
289
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
290<br />
6 Proceed as follows:<br />
a) Optionally specify an existing <strong>MKS</strong> Integrity issue or press F4 to prompt the Select<br />
Issue panel. <strong>Implementer</strong> applies this issue to the items checked in during the<br />
population process.<br />
b) Specify the job queue parameters as needed, and press ENTER. This creates the<br />
environment project in <strong>MKS</strong> Source and submits a job to populate the environment<br />
based on the values you specify.<br />
If you are performing this step to re-enable an environment project that was previously<br />
archived, a message confirms the action and explains that any interim development<br />
performed while archiving was off causes interim gaps in the <strong>MKS</strong> Source archives.<br />
Because of this, the first revision of an item checked in to <strong>MKS</strong> Source after re-enabling<br />
may have changes that occurred in multiple promotions when the environment was not<br />
enabled, appearing as though they all occurred during the last promotion.<br />
During the environment population, on the Work with Product Version Environments<br />
panel, the Archived by <strong>MKS</strong> Source field shows the interim value I to indicate the<br />
environment population is in process. If you attempt to change the field value from I to<br />
N while the process is active, an error message notifies you of the active job and advises<br />
you wait for the job to complete. You also cannot change the field value from I to<br />
If the job does not complete successfully, for example, due to communication problems<br />
between <strong>Implementer</strong> and <strong>MKS</strong> Source, a message informs you of the problem and the<br />
job fails. After resolving the problem, on the Product Version Environment Maintenance
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
panel set the Archived by <strong>MKS</strong> Source field value to N, and resubmit the environment<br />
population by pressing F6 (for details, see step 5 on page 289).<br />
NOTE To assist with error resolution, the submitted job information displays in the<br />
second level text of messages related to the environment population.<br />
Product/Version/Release Setup and Checkpointing in <strong>MKS</strong> Source<br />
Just as you can check in a source file to preserve its changes from one revision to another, you<br />
can also track changes to the configuration of a project and source changes related to a<br />
product release. In <strong>MKS</strong> Source, this is called checkpointing.<br />
Checkpointing saves a copy of the project as a baseline revision in the project’s history. The<br />
checkpoint includes the list of members along with their revision numbers and locations, as<br />
well as subproject revisions and locations, and project and member attributes.<br />
You can use the project’s revision number to keep track of your projects, but to simplify postrelease<br />
maintenance, you can also use a release name label to identify significant project<br />
development milestones when you checkpoint a project.<br />
When you checkpoint a project, <strong>MKS</strong> Source checkpoints the product and environment<br />
subprojects. Using checkpointed projects, <strong>MKS</strong> Source also allows you to view a summary of<br />
the changes that occurred between two versions of a project.<br />
Requirements and Considerations<br />
Release names correspond to the release checkpoint name in <strong>MKS</strong> Source. For this<br />
reason, the release names you use must be representable on the file system of the<br />
operating system hosting the server for <strong>MKS</strong> Source. The release name must start with a<br />
letter A–Z and continue with a contiguous sequence of letters A–Z, numbers 0–9, or<br />
underscores ‘_’.<br />
You must close and checkpoint the current release before you can open a new release in<br />
the same product/version.<br />
Checkpointing a release is a one-time action. Once you checkpoint a release, you cannot<br />
checkpoint it again. You can confirm the checkpoint status on the Product Version<br />
Release Maintenance panel.<br />
The release must be in a closed state. You can confirm the release state on the Product<br />
Version Release Maintenance panel. In the Date closed field, a valid date confirms the<br />
release is closed. If you attempt to checkpoint an open release, a message confirms you<br />
must close the release before checkpointing is allowed.<br />
NOTE To close a release, from the Work with Releases for a Product/Version panel,<br />
select the release with option 12=Change Status, and press ENTER. Select the<br />
appropriate close status with option 1=Select, and press ENTER.<br />
291
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
292<br />
To work with product/version/releases and checkpoint a release<br />
1 From the <strong>Implementer</strong> Menu, type option 51, Products, and press ENTER. The Work with<br />
Products panel displays.<br />
2 Select the product with option 10=Work with Versions, and press ENTER. The Work with<br />
Product Versions panel displays.<br />
3 Select the version with option 10=Work with Releases, and press ENTER. The Work with<br />
Releases for a Product/Version panel displays.<br />
4 Do one of the following to display the Product Version Release Maintenance window:<br />
Type 1=Create on the first option line, and press ENTER.<br />
Select an existing release with option 2=Change, and press ENTER.<br />
Select an existing release with option 3=Copy, and press ENTER.<br />
5 Press F6=Checkpoint in <strong>MKS</strong> Source. The function key displays only when the product<br />
version is archived in <strong>MKS</strong> Source and the release is closed. A confirmation window<br />
displays.<br />
6 In the Reply field type Y to confirm your request to checkpoint the specified product/<br />
version/release.
Preparing for the Next Release<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source Integration<br />
As the development cycle progresses and work on the current release comes to completion,<br />
minimal administration is required to prepare for creating a new release. The basic tasks<br />
consist of closing the current version/release and opening the new version/release.<br />
NOTE The ongoing administration tasks are functions you perform in <strong>Implementer</strong>.<br />
<strong>MKS</strong> Source does not require ongoing administration.<br />
To prepare for a new release<br />
1 Close the current release of the product/version.<br />
a) In the Work with Releases for a Product/Version panel, select the current release<br />
with option 12=Change status, and press ENTER. In the Change Release Status<br />
window, select the appropriate closed status with option 1=Select, and press<br />
ENTER.<br />
b) In the Product Version Release Maintenance panel, checkpoint the release by<br />
pressing F6=Checkpoint in <strong>MKS</strong> Source.<br />
2 Create and open a new release of the product/version.<br />
3 Begin development on the new release.<br />
You can perform patch and PTF release activity with environments in previous versions<br />
of the product now set to development path *VERSION. These changes are tracked on<br />
branch revisions with suffixes after the departure point, for example, 1.4.1.2 for a<br />
change to an item that was at revision 1.4, while the trunk revision, for example, 1.5, is<br />
assigned the next revision of the item promoted into the *HEADREV version.<br />
Preparing for the Next Version<br />
NOTE You must perform these steps for each new release.<br />
As the development cycle progresses and work on the current version comes to completion,<br />
minimal administration is required to prepare for creating a new version. The basic tasks<br />
consist of closing the current version/release and opening the new version/release.<br />
NOTE The ongoing administration tasks are functions you perform in <strong>Implementer</strong>.<br />
<strong>MKS</strong> Source does not require ongoing administration.<br />
293
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
294<br />
To prepare for a new version<br />
1 From the Product Version Maintenance panel, set the current *HEADREV version of the<br />
product to *VERSION to designate it as a previous version, and press F6=Create<br />
Development Path in <strong>MKS</strong> Source.<br />
This forces any further development onto the *VERSION development path, and assigns<br />
suffixed *VERSION branch revisions to items subsequently promoted, rather than<br />
*HEADREV trunk revisions that are assigned to items promoted in the new *HEADREV<br />
version you create in step 5.<br />
IMPORTANT When you create a new version, you must enable the version’s<br />
environments for <strong>MKS</strong> Source archiving before development starts on the new<br />
version. This ensures that all new development performed for the new version is<br />
reflected in the source archives. It also ensures the revision numbers in the previous<br />
version correctly initialize into the new version (using the “based-on” references<br />
when you define the new version/environments).<br />
2 Duplicate the existing environment libraries for the new version. Use new library names<br />
to differentiate between the versions.<br />
3 Create environments for the new version. For details, see “Environments” on page 81.<br />
4 Run the Build List for the new environments. For details, see “Environment Repository<br />
Build” on page 117.<br />
5 Create a new version of the product in Work with Product Versions and set the<br />
development path value to *HEADREV.<br />
6 In Work with Product Version Environments, add environments to the version. For the<br />
based on environment, specify the corresponding environment from the previous<br />
release.<br />
7 Create the environment project. In Product Version Environment Maintenance, press<br />
F6=Enable <strong>MKS</strong> Source Archiving. This creates the environment subproject in<br />
<strong>MKS</strong> Source under the base environment project, and performs the initial import<br />
(synchronization) of the environment source. For details, see “Product/Version<br />
Environments Setup and Environment Population” on page 286.<br />
8 Create and open a new release of the product/release.<br />
NOTE You must perform steps 1–9 for each new version/release.<br />
9 Begin development on the new release.<br />
You can also perform patch and PTF release activity with environments in previous<br />
versions of the product now set to development path *VERSION. These changes are<br />
tracked on branch revisions with suffixes after the departure point, for example,
<strong>MKS</strong> Integrity Integrations Task Checklists<br />
1.4.1.2 for a change to an item that was at revision 1.4, while the trunk revision, for<br />
example, 1.5, is assigned the next revision of the item promoted into the *HEADREV<br />
version.<br />
<strong>MKS</strong> Integrity Integrations Task Checklists<br />
The following task checklists apply to the steps required to set up the integrations between<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity, and <strong>Implementer</strong> and <strong>MKS</strong> Source. The checklists are<br />
helpful aids to use when setting up the integrations, and if you encounter problems with the<br />
integrations. <strong>MKS</strong> recommends you verify the completion of each required task prior to<br />
calling Customer Care.<br />
Step<br />
Number<br />
NOTE The setup tasks in <strong>MKS</strong> Integrity and <strong>MKS</strong> Source require the assistance of<br />
your <strong>MKS</strong> Integrity administrator. Likewise, the setup tasks in <strong>Implementer</strong> require<br />
the assistance of your <strong>Implementer</strong> administrator. <strong>MKS</strong> recommends you<br />
coordinate the configuration of this integration with the applicable administrators in<br />
your organization to ensure a successful and smooth process.<br />
Task Description<br />
<strong>MKS</strong> Integrity Integration Setup: Task Checklist<br />
1 Configure <strong>MKS</strong> Integrity Server ACLs on page 205.<br />
2 Customize permissions for <strong>Implementer</strong> change package type on<br />
page 205.<br />
3 Modify the <strong>MKS</strong> Integrity Server communications file on page 206.<br />
4 Create states on page 210.<br />
5 Enable promotions from <strong>MKS</strong> Integrity (optional) on page 212.<br />
6 Define <strong>MKS</strong> Integrity values in <strong>Implementer</strong> on page 226.<br />
7 State setup in <strong>Implementer</strong> on page 232.<br />
8 User profile setup on page 235.<br />
9 Environment setup on page 237.<br />
10 (Optional) Enable updating issues based on promotion status on page 240.<br />
11 (Optional) Enable promotions from <strong>MKS</strong> Integrity on page 242.<br />
12 Convert from DesignTracker to <strong>MKS</strong> Integrity on page 243.<br />
Task<br />
Complete<br />
295
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
Export to <strong>Implementer</strong><br />
296<br />
Step<br />
Number<br />
Task Description<br />
<strong>MKS</strong> Source Integration Setup: Task Checklist<br />
1 Modify the <strong>MKS</strong> Integrity Server configuration file on page 206.<br />
2 Define <strong>Implementer</strong> state-based capabilities if using <strong>MKS</strong> Integrity with<br />
<strong>MKS</strong> Source and <strong>Implementer</strong> on page 208.<br />
3 Create base projects in <strong>MKS</strong> Source on page 263.<br />
4 Create the integration user on page 264.<br />
5 Create the <strong>Implementer</strong> Developer group on page 264.<br />
6 Set <strong>MKS</strong> Source policies on page 265.<br />
7 Create and set an <strong>MKS</strong> Integrity ACL and permission on page 267.<br />
8 Create and set <strong>MKS</strong> Source ACLs and permissions on page 268.<br />
9 Define <strong>MKS</strong> Source values in <strong>Implementer</strong> on page 275.<br />
10 Define or modify object codes for archiving in <strong>MKS</strong> Source on page 278.<br />
11 Product setup and source archiving on page 280.<br />
12 Product version setup and development paths on page 283.<br />
13 Product/version environment setup and environment population on<br />
page 286.<br />
14 Product/version/release setup and checkpoint in <strong>MKS</strong> Source on page 291.<br />
Check<br />
Complete<br />
The <strong>Implementer</strong> and <strong>MKS</strong> Source integration provides Export to <strong>Implementer</strong>, a Java<br />
application that runs on Windows. The export function allows you to check out and<br />
optionally deploy PC-based software changes, initiated by an <strong>MKS</strong> Integrity issue and<br />
modified under <strong>MKS</strong> Source control, to an IFS location under <strong>Implementer</strong> change<br />
management control on the iSeries.<br />
The export runs using DTBridge, a client application delivered with <strong>Implementer</strong>. When<br />
activated, the export retrieves a list of <strong>MKS</strong> Integrity issues for a single or group of issues<br />
based upon the entry of either an issue number or a build number. The bi-directional updates<br />
occur automatically and include the creation of an <strong>Implementer</strong> change package for each<br />
selected issue. The status of the change packages reflect the current development progress<br />
within <strong>Implementer</strong>.
Requirements<br />
The following is required to use this feature:<br />
Export to <strong>Implementer</strong><br />
Complete the setup tasks described in “<strong>Implementer</strong> and <strong>MKS</strong> Integrity Integration” on<br />
page 196.<br />
Download, install, and configure DTBridge. DT Bridge requires:<br />
TCP/IP connection to the iSeries system where <strong>Implementer</strong> is installed.<br />
<strong>Implementer</strong> <strong>2006</strong> or later.<br />
Windows 2000 Professional or later.<br />
For product and component compatibility, the DTBridge version must match the<br />
<strong>MKS</strong> Integrity version requirements as described in the following table.<br />
DTBridge is delivered with <strong>Implementer</strong>; however, the DTBridge version does not need<br />
to match the <strong>Implementer</strong> version. If DTBridge is currently installed, you can verify the<br />
current version by starting the DTBridge Console, and from the DTBridge toolbar click<br />
Help > About.<br />
Installing DTBridge<br />
The tasks involved with downloading and installing DTBridge are as follows:<br />
Verify the TCP/IP connection.<br />
<strong>MKS</strong> Integrity Version DTBridge Release<br />
<strong>2006</strong> <strong>2006</strong><br />
2005 2005<br />
Download and install the self-extracting installation program dtbridge.exe.<br />
DTBridge requires an active TCP/IP connection to the iSeries where <strong>Implementer</strong> is installed.<br />
If you cannot communicate with the iSeries server successfully, DTBridge will not properly<br />
connect to process the database changes.<br />
PING is an MS-DOS program that allows you to verify that a particular Internet Protocol (IP)<br />
address exists and can accept requests. PING is used diagnostically to verify that a host<br />
computer you are trying to reach has communications enabled and operational. To verify<br />
your TCP/IP connection, you can either ping the system or ping the iSeries servers (requires<br />
ClientAccess installed on the local PC), as described next. If ping is unsuccessful, contact your<br />
system administrator.<br />
To ping the system to verify the TCP/IP connection<br />
1 At a command prompt, type CD.., and press ENTER to return to the root directory C:/.<br />
297
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
298<br />
2 Type PING (system name), and press ENTER.<br />
A message confirms that either ping was successful, or a time out occurred and the<br />
system was not located.<br />
To ping the iSeries servers<br />
1 At a command prompt, type CD.., and press ENTER to return to the root directory C:/.<br />
2 Type CWBPING (system name), and press ENTER.<br />
After polling the iSeries servers, a message confirms the status—either ping of the server<br />
was successful, or a time-out occurred and the server was not located.<br />
Use either of the following methods to download DTBridge from the iSeries and install onto<br />
your desktop.<br />
Map Network Drive allows you to copy data by sector. Depending on the speed of your<br />
PC, this method may take longer than File Transfer Protocol (FTP).<br />
FTP allows you to perform a bulk data transfer. This method is generally quicker than<br />
mapping a drive, but involves more steps.<br />
To download and install DTBridge using a mapped network drive<br />
1 Open Windows Explorer, and click Tools > Map Network Drive. The Map Network Drive<br />
dialog box displays prompting for a Drive and Path name.<br />
2 Select the drive name to use or accept the default value.<br />
3 For Path, type //Your_System_Name/mks/<strong>Implementer</strong>/<strong>MKS</strong>IM<br />
NOTE The default, product library name is <strong>MKS</strong>IM. If you changed the product<br />
library to another name, substitute the changed name for <strong>MKS</strong>IM.<br />
4 Make sure the Reconnect at Logon box is not enabled, and click OK. You may be<br />
prompted for a user ID and password to connect to the system.<br />
5 From Windows Explorer, select and expand the drive you just mapped.<br />
6 Double click dtbridge.exe and follow the installation wizard. The default installation<br />
directory is:<br />
C:/Program Files/<strong>MKS</strong>/<strong>Implementer</strong>/DTBridge<br />
You can change the destination directory during the install if required.<br />
To download and install DTBridge using FTP<br />
1 At a command prompt, type FTP, and press ENTER. The ftp> prompt displays.<br />
2 Type OPEN your_system_name, and press ENTER. A message confirms the connection is<br />
in progress, and a prompt displays requesting a user ID.
Export to <strong>Implementer</strong><br />
3 Specify a valid user ID for the system you opened in step 2, and press ENTER. A prompt<br />
displays requesting the password for the specified user ID.<br />
4 Type the password, and press ENTER.<br />
5 Type bin, and press ENTER. A message confirms the representation type is binary image.<br />
6 Type quote site namefmt 1, and press ENTER. A message confirms that naming<br />
format 1 is enabled.<br />
7 Type cd /mks/<strong>Implementer</strong>/<strong>MKS</strong>IM, and press ENTER. A message confirms the current<br />
directory changed, for example, /mks/<strong>Implementer</strong>/<strong>MKS</strong>IM.<br />
NOTE The default, product library name is <strong>MKS</strong>IM. If you changed the product<br />
library to another name, substitute the changed name for <strong>MKS</strong>IM.<br />
8 Type lcd C:/temp, and press ENTER. A message confirms the local directory is C:/<br />
temp. (You may need to create this directory if it does not exist.)<br />
9 Type get dtbridge.exe, and press ENTER. The self-extracting installation executable<br />
transfers into directory C:/temp on your PC.<br />
10 Type quit, and press ENTER. The C:/ prompt displays.<br />
11 Type cd C:/temp, and press ENTER.<br />
12 Type dtbridge.exe, and press ENTER. The default installation directory is:<br />
C:/Program Files/<strong>MKS</strong>/<strong>Implementer</strong>/DTBridge<br />
You can change the destination directory during the installation if required.<br />
13 Follow the installation wizard to complete the installation.<br />
Configuring DTBridge Components and Properties<br />
This section explains how to configure the DTBridge components required for the<br />
<strong>Implementer</strong> and <strong>MKS</strong> Source integration described in this chapter, as well as the help desk<br />
integration described in “Help Desk Integration” on page 324. The setup involves:<br />
granting authority to an <strong>Implementer</strong> file<br />
defining DTBridge properties file<br />
The DTBridge properties file contains the application control parameters for several<br />
integrations. Based on the integration you are configuring, the applicable properties must be<br />
defined prior to using DTBridge.<br />
The export feature described in this chapter uses the DTSystemName, DTUser, and<br />
DTPassword properties to connect to the iSeries and perform the required processing on the<br />
iSeries system specified in the DTSystemName property. The CIBuildNumberField is used<br />
299
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
300<br />
to identify the name of the custom field you created in <strong>MKS</strong> Integrity that will contain the<br />
build number (the field used to find all related issues for the export process). This is a<br />
required property if you are using <strong>MKS</strong> Integrity with the Export to <strong>Implementer</strong> feature.<br />
NOTE<br />
The IUPDCI command feature requires additional configuration. For details, see<br />
“Updating Issues Based on Promotion Status” on page 240.<br />
The DT Call Association Properties are used for the features described in “Help<br />
Desk Integration” on page 324.<br />
Some DesignTracker properties relate to obsolete functionality that is in the<br />
process of deprecation. Thus, the only DesignTracker properties you need to<br />
configure are those described in this guide.<br />
To authorize the user profile to the <strong>Implementer</strong> file<br />
Issue the following OS/400 command:<br />
GRTOBJAUT OBJ(<strong>MKS</strong>IM/IMCICT)<br />
OBJTYPE(*FILE)<br />
USER(DTUSER)<br />
AUT(*CHANGE)<br />
To start DTBridge Console and configure the DTBridge properties file<br />
1 Click Start > Programs > <strong>MKS</strong> <strong>Implementer</strong> > DTBridge Console. The DTBridge Console<br />
window displays. Notice the Status bar indicates DTBridge is currently not active.<br />
2 Click File > Setup from the menu. The Edit DTBridge Setup properties file displays.<br />
Instructions and example properties are included within the file. The properties file is<br />
organized by functional area. The beginning of each section lists the properties with a<br />
brief description and an example. At the end of each section, the property displays again<br />
as property name=x.<br />
When defining the property value, type the value as follows:<br />
property name=property value<br />
3 Use the following tables to define the properties respective to the functionality you are<br />
setting up.<br />
4 When you are finished, click File > Save Setup.<br />
IMPORTANT The following tables define the applicable properties in the DTBridge<br />
file. When defining the OS/400 values, you must use upper case syntax.
General Properties Description<br />
Logging level to use<br />
when application is run<br />
DTBridge General Properties<br />
Export to <strong>Implementer</strong><br />
0 = Basic logging only. Messages include the DR number and <strong>MKS</strong> Integrity<br />
issue number relationship, and verification that the DR was created.<br />
1 = Detailed Logging. Messages include the DR number, related text and<br />
description information, and the DR and <strong>MKS</strong> Integrity issue number relationship.<br />
This information is useful for diagnostic and support purposes.<br />
Log JDBC 0 = No. No logging. This is the default value.<br />
1 = Yes. Generates a detailed log of all JDBC connection messages. (JDBC is the<br />
Java form of ODBC, and is the communication method between DTBridge and<br />
multi-platform databases.) This information is useful for diagnostic and support<br />
purposes, for example, if you have a problem connecting to DTBridge.<br />
Issue Source Product to derive issues from. Specify CI if you are using <strong>MKS</strong> Integrity.<br />
DesignTracker Properties Description<br />
DesignTracker Properties<br />
DTSystemName Name of the iSeries system where DesignTracker is installed.<br />
DTLibrary Name of the DesignTracker installed library. The default product library is <strong>MKS</strong>IM.<br />
DTUser Name of the DesignTracker user that has authority to the library defined in the<br />
DTLibrary property.<br />
DTPassword Password associated with the DTUser property.<br />
<strong>MKS</strong> Integrity Properties Description<br />
<strong>MKS</strong> Integrity Properties<br />
CIServerName Full name of the server that is running the Integrity Server to connect with. A<br />
value is required.<br />
CIPort Port number to use to communicate with the Integrity Server defined in the<br />
CIServerName property. The default is 9001. A value is required.<br />
CIUserName Name of the user to connect to the Integrity Server. A value is required.<br />
CIUserPassword Password associated with the CIUserName property. A value is required.<br />
CIBuildNumberField Name of a custom <strong>MKS</strong> Integrity field to contain the Build Number. A value is<br />
required if using the Export to <strong>Implementer</strong> feature. Create the custom field as a<br />
Short Text field with a maximum length of 30.<br />
301
Chapter 5: <strong>MKS</strong> Integrity Integration<br />
<strong>MKS</strong> Source/<strong>MKS</strong> Integrity<br />
Integration Properties<br />
Troubleshooting<br />
302<br />
<strong>MKS</strong> Source/<strong>MKS</strong> Integrity Integration Properties<br />
Description<br />
DefaultIMEnvironment Default <strong>Implementer</strong> *TST environment on the iSeries to check out to in the<br />
Export to <strong>Implementer</strong> function. This is an optional property.<br />
DefaultProject Default <strong>Implementer</strong> project to use in the Export to <strong>Implementer</strong> function.<br />
DefaultStagingLocation Default IFS location on the iSeries where to pull objects from.<br />
For each slash in the actual name, define the property with two slashes (//).<br />
For example, if the default IFS location is /home/mydirectory, specify<br />
//home//mydirectory. This is an optional property.<br />
The following information can help you resolve common problems with <strong>Implementer</strong> Server.<br />
Symptom Possible Cause Resolution<br />
Using ICTLSVR<br />
*START, F7=Test in<br />
<strong>MKS</strong> Integrity Setup<br />
panel, or F7=Test in<br />
<strong>MKS</strong> Source Setup<br />
panel results in error<br />
VIM8598 “Unable<br />
to communicate<br />
with the <strong>MKS</strong><br />
Integrity<br />
Server”.<br />
#1: IP address for system running <strong>Implementer</strong><br />
Server is not in <strong>MKS</strong> Integrity config file<br />
IntegrityClientSite.rc.<br />
Also see <strong>MKS</strong> Integrity weblogic.log for error<br />
message with missing IP, for example:<br />
Thu Feb 9 14:32:25 CDT <strong>2006</strong>:<br />
<br />
* * * * ERROR * * * * (0):<br />
ICAllowSpecificConnectionPolicy failed<br />
the connection. Connection: 10.17.4.6:<br />
is not on the list of acceptable<br />
machines.<br />
#2: Network may not be configured to communicate<br />
between the system running <strong>Implementer</strong> server<br />
and system running <strong>MKS</strong> Integrity.<br />
From system running <strong>Implementer</strong> Server, ping<br />
system where <strong>MKS</strong> Integrity Server is located (see<br />
<strong>MKS</strong> Integrity Setup panel, Server port field).<br />
<strong>Implementer</strong> Server running on iSeries, from<br />
command line issue<br />
ping <br />
(IP address must be in single quotes .<br />
<strong>Implementer</strong> server running on a PC, from<br />
command prompt run ping .<br />
In the IntegrityClientSite.rc<br />
file, specify the IP addresses for the<br />
system running <strong>Implementer</strong> Server<br />
and the localhost (127.0.0.1) in<br />
daemon.validConnectionList=<br />
For details, see “Modifying the<br />
<strong>MKS</strong> Integrity Server Configuration<br />
File” on page 206.<br />
Verify and correct network<br />
configuration.<br />
Specify correct system running<br />
<strong>MKS</strong> Integrity Server in Server port<br />
field on <strong>Implementer</strong>’s <strong>MKS</strong> Integrity<br />
Setup panel and/or <strong>MKS</strong> Source<br />
Setup panel. For details, see<br />
“Defining <strong>MKS</strong> Integrity Values in<br />
<strong>Implementer</strong>” on page 226, and<br />
“Defining <strong>MKS</strong> Source Values in<br />
<strong>Implementer</strong>” on page 275.
C HAPTER SIX<br />
Third Party Integrations<br />
Configuring <strong>Implementer</strong> for Integrated Development Environments<br />
6<br />
<strong>MKS</strong> is committed to the continuous development and growth of <strong>Implementer</strong>’s integrations with<br />
third party software tools and applications.<br />
This chapter covers the following topics:<br />
“ABSTRACT Integration” on page 304<br />
“AllFusion 2E Change Management Integration” on page 304<br />
“American Software Integration” on page 313<br />
“AOS Message Manager Integration” on page 315<br />
“AS/SET Integration” on page 316<br />
“BPCS Integration” on page 320<br />
“BRMS/400 Integration” on page 322<br />
“Code/400 Integration” on page 323<br />
“Help Desk Integration” on page 324<br />
“LANSA Integration” on page 328<br />
“Lawson Software Integration” on page 333<br />
“Lotus Domino Integration” on page 336<br />
“PathFinder Integration” on page 354<br />
“PeopleSoft World Integration” on page 355<br />
“Powerhouse (Cognos) Integration” on page 362<br />
“ROBOT Integration” on page 364<br />
“WebSphere Development Studio Client for iSeries Integration” on page 365<br />
303
Chapter 6: Third Party Integrations<br />
ABSTRACT Integration<br />
304<br />
<strong>Implementer</strong>’s integration with ABSTRACT does not require additional setup. For<br />
information on using the integration, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
AllFusion 2E Change Management Integration<br />
The <strong>Implementer</strong> Adapter for AllFusion 2E Change Management (CM) is a separately<br />
licensed product that provides change control for AllFusion 2E developed applications and<br />
traditionally developed (3GL) applications. <strong>Implementer</strong> is compatible with AllFusion 2E<br />
release 8.1 and earlier. The integration requires a specific license key to activate.<br />
The procedures required for setting up the integration, including:<br />
considerations for libraries and commands<br />
understanding basic concepts<br />
considerations for EXCUSRPGM and EXCUSRSRC<br />
support for SQL<br />
Considerations for Libraries and Commands<br />
Basic Concepts<br />
While following the setup steps described in this chapter, keep in mind the following product<br />
and library considerations. If you received the <strong>Implementer</strong> product from Computer<br />
Associates and it is enabled for AllFusion 2E change management:<br />
The host library default name is Y2SYCM (not <strong>MKS</strong>IM).<br />
The remote library default name is Y2SYCR (not <strong>MKS</strong>IR).<br />
Use the STRCM command in place of the Start <strong>Implementer</strong> (STRIM) command.<br />
Use the STRCR command in place of the Start <strong>Implementer</strong> Receiver (STRIR) command.<br />
You must know a few basic concepts to understand how change management occurs for<br />
AllFusion 2E developed applications. These concepts are described briefly next and<br />
expanded upon later.
Change Controlled Models<br />
AllFusion 2E Change Management Integration<br />
The process for enabling a model for change control differs for pre-existing models as<br />
opposed to newly created models. For newly created models, the process is as simple as<br />
creating the model with the Create Model Library (YCRTMDLLIB) command, specifying the<br />
<strong>Implementer</strong> product library (<strong>MKS</strong>IM or Y2SYCM) in the change control parameter<br />
(CHGCTL). For established AllFusion 2E models, you have to initialize the version type of all<br />
of the model objects.<br />
To accomplish this, various tools are available for analysis and modification, such as the Start<br />
Change Control (YSTRCHGCTL) and Associate Production Model (YASCPRDMDL)<br />
commands. You must also define the model to <strong>Implementer</strong> as an AllFusion 2E environment.<br />
Type a model library name on the AllFusion 2E options panel, accessible using option 10<br />
from the Work with Environments panel.<br />
The following examples help to clarify these concepts.<br />
Example 1<br />
You have existing development and production models and you want to implement change<br />
control.<br />
1 Start Change Control (YSTRCHGCTL) command<br />
If your production model is closely synchronized to the changes in development, you<br />
can achieve implementation most easily by using the YSTRCHGCTL command. You<br />
need to specify the set version type (SETVSNTYP) parameter (the possible values are<br />
available in the command help text). The most sophisticated value for this parameter is<br />
*ASSOC, which invokes the Associate Production Model (YASCPRDMDL) command<br />
described next.<br />
2 Associate Production Model (YASCPRDMDL) command<br />
The YASCPRDMDL command compares objects between two models. It matches objects<br />
by Owner name/Object type/Copy name in the development (source) model with the<br />
Owner name/Object type/Object name in the target model. If a match is found, the<br />
object in the development model is set as a production version.<br />
The production model provided to the YASCPRDMDL command should ideally be the<br />
related production environment you define in the CM environment setup. If you do not<br />
have a production model, you can use a QA model instead.<br />
For this approach to be effective, you must achieve development cutoff of all changes,<br />
both functional and database. If functional cutoff is not an option, database cutoff is a<br />
minimum requirement to obtain a predictable result.<br />
You should note how objects are identified between the two models. For non versionable<br />
objects, matching is straightforward because of the one-to-one relationship. For<br />
versionable objects such as the functions, a more arbitrary pairing method could cause<br />
some unexpected results. The program reads the development model objects in Owner/<br />
305
Chapter 6: Third Party Integrations<br />
306<br />
Type/Name order. If a match is found in the target model, the program tries to make the<br />
object PRD (if it is not already). If any other version in the group is PRD, the attempt<br />
fails, the information is written to a report, and processing continues. The result is the<br />
first version in a group, alphabetically, set to PRD.<br />
If the wrong version is flagged as the production version, you have to make manual<br />
changes. Use the Associate Production Model Report to identify which objects to correct.<br />
For each object, change the version that was set by the YASCPRDMDL command to<br />
DEV, and set the version to production. The Work with Versions (YWRKVSN) and<br />
Change Model Object (YCHGMDLOBJ) commands can be useful for this.<br />
Example 2<br />
You have a development model and traditional production library, and you want to<br />
implement change control and establish a production model.<br />
1 If the production library in your existing system was generated from your development<br />
model, you have two options. You can define a separate environment for the existing<br />
3GL production library, or you can create a new model library and define its generation<br />
library as the existing 3GL production library. Either solution works, but the first<br />
solution has overhead of both extra promotion steps and extra disk space requirements.<br />
2 For either situation, you must identify the objects in development that constitute the<br />
objects in production. If you already have <strong>Implementer</strong> as your change control system,<br />
this is not necessary since the production version types are already set.<br />
To identify the production objects in your existing development model, either:<br />
Use the Start Change Control (YSTRCHGCTL) command, particularly if your<br />
existing promotion system places permanent locks on those objects promoted to<br />
production (set the version type to *BYLOCK).<br />
Alternately, follow these steps if the production flags have not been established:<br />
Issue the YBLDMDLLST command to create a model list of all the non<br />
versionable objects in the model, in other words, exclude functions and<br />
messages. Do not include <strong>Implementer</strong>-supplied objects.<br />
Issue the Execute Model Object List (YEXCMDLLST) command to call change<br />
model object (YCHGMDLOBJ) for each list entry, and change the version type<br />
of the objects to production (*PRD).<br />
Create a model list of all functions and messages, excluding those supplied by<br />
AllFusion 2E (versionable objects). For each object, include only the version in<br />
production. Do not include more than one version for a group, as it causes an<br />
error in the next step.<br />
Generate the YEXCMDLLST command as before for the non versionable<br />
objects. An error occurs if you attempt to set more than one version in a group<br />
to production.
AllFusion 2E Change Management Integration<br />
3 Establish that all objects flagged as production are the current versions for their groups.<br />
To create a list of all objects in the model, issue the following command:<br />
YBLDMDLLST MDLLST(PRDLST)<br />
CUROBJ(*NO)<br />
To remove all objects that are current or have a development version type, issue the<br />
following command:<br />
YFLTMDLLST MDLLST(PRDLST)<br />
OUTLST(PRDLST)<br />
CUROBJ(*NO)<br />
VSNTYP(*PRD)<br />
OUTFLAGVAL(*SELECTED)<br />
To return all of the objects on the list to a current status, issue the following<br />
command:<br />
YEXCMDLLST MDLLST(PRDLST)<br />
RQSDTA('YRDRMDLOBJ<br />
FRMOBJNAM(*CURRENT)<br />
TOOBJSGT(&Y@)<br />
TOOBJSGT(&Y@)<br />
TFRNAM(*NO)')<br />
FLAGVAL(*SELECTED)<br />
4 With the production objects in your development model correctly established, you are<br />
ready for the final step⎯creation of the production model objects.<br />
a) To populate the production model, issue the Copy Model Object (YCPYMDLOBJ)<br />
command. If you ran YSTRCHGCTL as instructed in step 2, or if <strong>Implementer</strong> is<br />
active for the development or production model, disable it by setting the YCHGCTL<br />
model value to *NONE.<br />
b) Build a model list of all production objects in the development model, and, using<br />
the Copy Model Object (YCPYMDLOBJ) command, copy that list to the new<br />
production model.<br />
c) Re-establish <strong>Implementer</strong> by setting the YCHGCTL model value to the name of<br />
your <strong>Implementer</strong> product library specified in the development and production<br />
models.<br />
Versioning 2E Messages<br />
AllFusion 2E message versions are typically always recreated except when translating<br />
terminology to another language. However, <strong>Implementer</strong> allows you to control whether to<br />
create a new message version when checking out 2E messages. In Work with Environments,<br />
select the 2E environment with option 10=AllFusion 2E. On the Change Environment panel,<br />
in the Crt new version of MSG objects field, the default value Y automatically creates a new<br />
message version. Change the value to N to retain the original version of 2E messages.<br />
307
Chapter 6: Third Party Integrations<br />
Support for EXCUSRSRC and EXCUSRPGM<br />
308<br />
By default, <strong>Implementer</strong> allows you to promote the AllFusion 2E EXCUSRSRC and<br />
EXCUSRPGM functions separately from their associated implementation 3GL source and<br />
objects. This is called “Independent EXCUSRSRC and EXCUSRPGM”.<br />
You can also automatically promote the 3GL source and objects associated with EXCUSRSRC<br />
and EXCUSRPGM functions when these functions are promoted. When enabled, the<br />
implementation objects for EXCUSRSRC and EXCUSRPGM function types are derived and<br />
included on the promotion request. With this feature, the implementation source and/or<br />
objects may not be checked out or promoted separately from this model object. This is called<br />
“Dependant EXCUSRSRC and EXCUSRPGM”.<br />
This feature is controlled by the User source and user program promotion method field in<br />
Work with Environments. When upgrading AllFusion 2E CM, the existing default method of<br />
independent EXCUSRSRC and EXCUSRPGM is retained. Enabling this feature provides<br />
capabilities that were available prior to AllFusion 2E CM release 6.0.<br />
Considerations for EXCUSRSRC and EXCUSRPGM<br />
When promoting EXCUSRSRC and EXCUSRPGM, even though the Remove source field is<br />
set to Y, the source for the user programs is not removed.<br />
Storing Source and Object Outside the Generation Library<br />
There are three common ways to store EXCUSRPGM source and objects outside the test<br />
model generation library. The following paragraphs briefly describe the scenarios and<br />
implementation steps. Each scenario uses the XCB target HLL object attribute in AllFusion 2E<br />
(see note) to create a new, corresponding object code in <strong>Implementer</strong>. The examples assume<br />
the EXCUSRPGMs are type CLP. If they are other HLL types, copy the appropriate shipped<br />
object code instead of CLP.<br />
For each of the following scenarios, define the XCB object code. Copy the shipped CLP code<br />
to XCB, and change its source file value to YXCBLSRC.<br />
1 Source in an alternate source file in the generation library with object in the generation<br />
library.<br />
Create an XCB object code.<br />
2 Source in an alternate source file in the generation library with objects in a library other<br />
than the generation library.<br />
Create an XCB object code.<br />
On the Environment Object Code Override panel, change the object library to the<br />
library you want to store the EXCUSRPGM object in.
Support for SQL<br />
AllFusion 2E Change Management Integration<br />
3 Source in an alternate source file in a library other than the generation library.<br />
Create an XCB object code.<br />
On the Environment Object Code Override panel, change the object library value to<br />
the library you want to store the EXCUSRPGM object in. (Use the F8=Object code<br />
override on the Change Environment panel.)<br />
Change the Environment Object Code Override source location library to the library<br />
to store the EXCUSRPGM source in.<br />
Regardless of the scenario, perform the following steps in AllFusion 2E for each<br />
EXCUSRPGM or EXCUSRSRC.<br />
4 When editing the function in AllFusion 2E, change the language from CLP, RPG, or CBL<br />
to XCB.<br />
5 Display the AllFusion 2E Edit Generation Types panel, and change the name of the SCB<br />
source types source file to the source file name used on the XCB object code definition in<br />
<strong>Implementer</strong>.<br />
To define an environment for 3GL source and object processing associated with<br />
EXCUSRSRC and EXCUSRPGM functions<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Environments, to display the Work with<br />
Environments panel.<br />
2 Select the AllFusion 2E environment with option 10=AllFusion 2E and press ENTER.<br />
3 In the User source and user program promotion method field, specify one of the<br />
following values:<br />
1=Dependent Automatically adds associated implementation source and<br />
objects to the promotion request.<br />
2=Independent Does not add the associated implementation source and<br />
objects. This is the default value.<br />
IMPORTANT If you change the environment to add dependent objects, do not have<br />
any 3GL source and objects checked out that are associated with a model object.<br />
<strong>Implementer</strong> supports the SQL-related generation options available in earlier releases of<br />
AllFusion 2E. This includes the creation of SQL tables, indices, and views, and the<br />
corresponding functions that create RPG SQL and COBOL programs.<br />
309
Chapter 6: Third Party Integrations<br />
310<br />
When creating a promotion request, <strong>Implementer</strong> recognizes these SQL types of generated<br />
objects and assigns the appropriate object code when determining the implementation<br />
objects to add to the promotion request.<br />
This feature capitalizes on the SQL-specific object codes delivered with <strong>Implementer</strong>. Verify<br />
your setup with the YSQLPF (tables), YSQLLF (indices and views), and SQL program types<br />
(RPGSQL and CBLSQL) as described in the following sections.<br />
Managing SQL Files, Indices, and Views<br />
<strong>Implementer</strong> provides the YSQLPF and YSQLLF objects codes to manage AllFusion 2E SQL<br />
files, indices, and views. In an AllFusion 2E model, these items have different model object<br />
attributes, but share the same:<br />
source member type (YSQL)<br />
source file (QSQLSRC)<br />
creation command (YEXCSQL)<br />
When generating YFIL model objects as SQL, <strong>Implementer</strong> uses the object code YSQLPF for<br />
the associated implementation object. When generating YACP model objects as SQL,<br />
<strong>Implementer</strong> uses the object code YSQLLF for the associated implementation object. Thus,<br />
verify the YSQLPF and YSQLLF object codes are defined as follows, and that they are active<br />
to each applicable AllFusion 2E environment.<br />
NOTE You must define the parameter sequences of the creation commands as<br />
shown to avoid extraneous messages in your job log.<br />
Field Required Value<br />
Object code/Description YSQLPF (AllFusion 2E SQL physical file)<br />
Activity flag 1<br />
Object type *FILE<br />
Object attribute PF<br />
Source member type YSQL<br />
Default source file QSQLSRC<br />
Object authority *KEEP<br />
Creation process C<br />
Creation command YEXCSQL MBR(#SRCMBR)<br />
OBJLIB(#FILLIB)<br />
SRCFILE(#SRCLIB/#SRCFIL)
Field Required Value<br />
Managing SQL Functions<br />
AllFusion 2E Change Management Integration<br />
Object code/Description YSQLLF (AllFusion 2E SQL indices/views)<br />
Activity flag 1<br />
Object type *FILE<br />
Object attribute LF<br />
Source member type YSQL<br />
Default source file QSQLSRC<br />
Object authority *KEEP<br />
Creation process C<br />
Creation command YEXCSQL MBR(#SRCMBR)<br />
OBJLIB(#FILLIB)<br />
SRCFILE(#SRCLIB/#SRCFIL)<br />
In an AllFusion 2E model, an SQL function created over an SQL file has an object attribute of<br />
RPG or CBL. Based on the type of function, it also has:<br />
source member type of SQLRPG or SQLCBL<br />
source file of QRPGSRC or QCBLSRC<br />
creation command of CRTSQLRPG or CRTSQLCBL<br />
For managing AllFusion 2E SQL functions, <strong>Implementer</strong> provides the RPGSQL and RPGCBL<br />
object codes. By using these SQL-specific object codes to check out SQL functions,<br />
<strong>Implementer</strong> assigns the appropriate program type object code to the lock.<br />
When you create a promotion request, <strong>Implementer</strong> adds the model objects to the request for<br />
each model object using a YFUN code, and adds the corresponding 3GL objects—including<br />
the programs—with an object code of RPGSQL or CBLSQL.<br />
Verify the RPGSQL and CBLSQL object codes are defined as follows, and that they are active<br />
to each applicable AllFusion 2E environment.<br />
Field Required Value<br />
Object code/Description RPGSQL (AllFusion 2E RPG SQL function)<br />
Activity flag 1<br />
Object type *PGM<br />
Object attribute RPG<br />
Source member type SQLRPG<br />
Default source file QRPGSRC<br />
311
Chapter 6: Third Party Integrations<br />
Object Code Setup for Parallel Installation<br />
312<br />
Field Required Value<br />
Object authority *KEEP<br />
Creation process C<br />
Creation command CRTSQLRPG PGM(#PGMLIB/#OBJECT)<br />
SRCFILE(#SRCLIB/#SRCFIL)<br />
COMMIT(*NONE)<br />
SRCMBR(#SRCMBR)<br />
Field Required Value<br />
Object code/Description CBLSQL (AllFusion 2E CBL SQL function)<br />
Activity flag 1<br />
Object type *PGM<br />
Object attribute CBL<br />
Source member type SQLCBL<br />
Default source file QSQLSRC<br />
Object authority *KEEP<br />
Creation process C<br />
Creation command CRTSQLCBL PGM(#PGMLIB/#OBJECT)<br />
SRCFILE(#SRCLIB/#SRCFIL)<br />
COMMIT(*NONE)<br />
SRCMBR(#SRCMBR)<br />
If you have upgraded from an <strong>Implementer</strong> release prior to release 5.0 and you performed a<br />
parallel installation as explained in the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>, before using<br />
the software you must add certain AllFusion 2E-specific object codes to <strong>Implementer</strong>.<br />
The following table defines the object codes to add.<br />
Object Code Description<br />
Creation<br />
Sequence<br />
YACP AllFusion 2E access path 9120 YACP<br />
YAPP AllFusion 2E application 9120 YAPP<br />
YARR AllFusion 2E array 9120 YARR<br />
YCND AllFusion 2E condition 9120 YCND<br />
YFIL AllFusion 2E file 9120 YFIL<br />
Special<br />
Characteristics
Object Code Description<br />
NOTE<br />
The creation sequences are suggested values you may change.<br />
Set the Object authority field to *KEEP, and the Creation process field to C.<br />
For details on adding or changing objects codes, see page 127.<br />
American Software Integration<br />
American Software Integration<br />
American Software, Incorporated (ASI) develops a portfolio of enterprise and supply chain<br />
software applications designed to automate planning and operational functions with leading<br />
e-business solutions, enterprise resource planning (ERP), supply chain management, flow<br />
manufacturing, warehouse management, and transportation operations. The following<br />
information explains how to use <strong>Implementer</strong> with the (ASI) application software.<br />
Object Code Requirements<br />
American Software uses a special command for compiling, which, among other things,<br />
merges both a base version of a source member, ASI PTFs, and customer changes into a<br />
temporary source member and then compiles the source member. The ASI change<br />
management process is automated using ASI-specific objects.<br />
To perform ASI compiles within <strong>Implementer</strong>, you need to create new object codes similar to<br />
the following standard object codes.<br />
CBL (Cobol Programs)<br />
CLP (Control Language Programs)<br />
DSPF (Display Files)<br />
PRTF (External Printer Files)<br />
LF (Logical Files)<br />
PF (Physical Files)<br />
Creation<br />
Sequence<br />
YFLD AllFusion 2E field 9120 YFLD<br />
YFUN AllFusion 2E function 9120 YFUN<br />
YMSG AllFusion 2E message 9120 YMSG<br />
Special<br />
Characteristics<br />
Object codes are maintained using <strong>Implementer</strong> Menu option 44, Object Codes. For details,<br />
see “Object Codes” on page 127.<br />
313
Chapter 6: Third Party Integrations<br />
314<br />
To perform an ASI Cobol compile with <strong>Implementer</strong>, create a new object code as shown next<br />
(illustrates an object code named CBLASI, but any naming convention can be used).<br />
Field Value<br />
Object Code/Description CBLASI (ASI COBOL Program)<br />
Object type PGM<br />
Object attribute CBL<br />
Source member type TXT<br />
Default source file UCBLSRC<br />
Special characteristics ASICBL<br />
Object authority *KEEP<br />
Creation process C<br />
Creation command ASIUTILIB/PUTCRTOBJ OBJ(#PGMLIB/#OBJECT)<br />
SRCMBR(#OBJECT)<br />
SRCFL(#SRCLIB/QCBLSRC)<br />
OBJTYPE(CBL)<br />
PRMSRCFL(QCBLSRC)<br />
Change the other object codes in the same way. The object code controls, among other things,<br />
how objects are compiled. Instead of calling the standard IBM Create Cobol Program<br />
(CRTCBLPGM) command, the CBLASI object code calls the ASI command that merges and<br />
compiles Cobol source code. You can deactivate the standard object codes (such as CBL and<br />
RPG) in each environment.<br />
You must make the following two changes prior to running the <strong>Implementer</strong> Build List. For<br />
details, see “Environment Repository Build” on page 117.<br />
1 In the environment’s object code overrides, change the source file to the actual “Q”<br />
libraries (QCBLSRC).<br />
2 Change the object codes to a source member type of the actual source file (CBL) instead<br />
of TXT.<br />
After the build completes, you can change the source file back to the “U” libraries<br />
(UCBLSRC), and change the object codes back to TXT.<br />
Library and Library List Requirements<br />
The PUTCRTOBJ command requires the three source files located within the same library. In<br />
other words, the library you are making changes in (in source file UCBLSRC members) must<br />
have a copy of the TCBLSRC source file and QCBLSRC source file in the same library as<br />
UCBLSRC.
Typically, these source files are:<br />
QCBLSRC (unmodified current release)<br />
TCBLSRC (PTFs to current release)<br />
UCBLSRC (customer changes to current release)<br />
AOS Message Manager Integration<br />
In addition, the environment library list must match the library list of the ASICOMPILE job<br />
description, with the libraries listed in the same order.<br />
Troubleshooting Problems<br />
The following information may be helpful with resolving typical problems related to<br />
message files.<br />
Problem Resolution<br />
Source mismatch Change the Source member type to TXT.<br />
Checked out QSRC instead of USRC The default source file must be USRCxxx.<br />
TSRC and USRC not copied Special characteristics not entered for object type.<br />
AOS Message Manager Integration<br />
AOS Message Manager interfaces with <strong>Implementer</strong> to allow you to monitor the status of<br />
promotion requests. The messages can be set up to automatically create an OS/400 message<br />
to one or more user profiles. In addition, you can send <strong>Implementer</strong> messages directly to a<br />
pager to notify someone not signed on to the iSeries that a situation requires attention.<br />
To set up the AOS Message Manager integration<br />
1 From the <strong>Implementer</strong> Menu, select option 45, System Control Maintenance. The System<br />
Control Maintenance panel displays.<br />
2 Press PAGE UP to display the second panel.<br />
3 In the Secondary message queue field, type the name of the AOS Message Manager<br />
message queue. This points AOS Message Manager to the message queue where all<br />
messages in <strong>Implementer</strong> are sent, and to the appropriate <strong>Implementer</strong> users.<br />
You can also page a user when specific messages are received. For more information, see<br />
the AOS Pager Manager Users <strong>Guide</strong>.<br />
315
Chapter 6: Third Party Integrations<br />
AS/SET Integration<br />
316<br />
The <strong>Implementer</strong> Adapter for AS/SET is a separately licensed product that manages AS/SET<br />
definitions and generated traditional objects independently.<br />
You can check out AS/SET definitions, make modifications, and promote to QA and<br />
production to complete the cycle. <strong>Implementer</strong> automatically handles locking the definitions<br />
and ensures proper check in by promoting in a controlled fashion. An audit trail is<br />
maintained of all activities to the definitions. <strong>Implementer</strong>’s inquiries and reports include the<br />
AS/SET definitions and generated objects you manage.<br />
There are specific commands to copy, delete, and verify existence of AS/SET definitions from<br />
within <strong>Implementer</strong>. These functions are used to manage definitions and as standalone<br />
commands.<br />
Setting Up the Integration<br />
The setup activities necessary to handle AS/SET applications are as follows:<br />
Install AS/SET on the system.<br />
Change the library list in the job description (MWIJOBD) to include the AS/SET product<br />
libraries.<br />
IMPORTANT You must include the AS/SET libraries in the job description to ensure<br />
the promotion of AS/SET definitions does not abnormally end.<br />
Include the AS/SET product libraries ASSETO, ASSETF, and ASSETGPL on your<br />
interactive library list to manage an AS/SET definition.<br />
In System Control Maintenance, set the AS/SET installed field to Y.<br />
Set up standard environments to manage AS/SET applications.<br />
Set the Compile required field to N if you use this environment only for AS/SET<br />
definitions.<br />
Enable the “Remove member in from library/environment” feature in Work with<br />
Environments for AS/SET definitions.<br />
Associate the standard environment with an application set where the definitions for the<br />
environment reside. Once the existing environment is associated with an application set,<br />
it becomes a special AS/SET environment. The indication of this special environment<br />
displays on the second detailed Change Environments panel. The application set name<br />
you specify must exist (<strong>Implementer</strong> does not create application sets). If the application<br />
set name is blank, the environment type reverts to Standard on the Change<br />
Environment panel.
AS/SET Integration<br />
Use object codes with the following special characteristics for AS/SET definitions.<br />
Object Code Description<br />
If you need different object codes, they must have special characteristics beginning with<br />
ADK. Create the object codes as non source and non object based.<br />
NOTE<br />
Setting Up for Archiving<br />
ADKDSP AS/SET display program definition.<br />
ADKBAT AS/SET batch program definition.<br />
ADKRPT AS/SET report program definition.<br />
ADKMDL AS/SET data model.<br />
ADKLLD AS/SET field definition.<br />
ADKFIL AS/SET file definition.<br />
ADKAUD AS/SET audit trail definition.<br />
ADKSUB AS/SET action subroutine definition.<br />
You can promote AS/SET definitions to an environment group. You must define<br />
the primary environment as an AS/SET environment. If non AS/SET<br />
environments exist in the group, the AS/SET definitions are not promoted to<br />
these environments, although the promotion of both AS/SET definitions and the<br />
generated objects occurs to the AS/SET environments in the group.<br />
When you run the Build List for AS/SET environments, the member/object list<br />
includes both traditional objects and AS/SET definitions that exist in the<br />
application set specified for the environment.<br />
After defining an AS/SET environment (a standard environment associated with an AS/SET<br />
application set) perform the following task to enable archiving for AS/SET definitions.<br />
To set up for AS/SET archiving<br />
1 In the Archive version fields on the Change Environment panel, specify the number of<br />
levels (versions) to retain for archiving. You must also specify the archive library name<br />
and number of versions for traditional objects.<br />
2 In the Work with Environments panel, type 11=AS/SET, and press ENTER. The Create<br />
Environment panel displays.<br />
3 In the Archive application set field, type the name of the archive application set, and<br />
press ENTER.<br />
317
Chapter 6: Third Party Integrations<br />
Setting Capabilities for Checked Out Generated Objects<br />
318<br />
You can configure <strong>Implementer</strong> to automatically allow modifying either all AS/SETgenerated<br />
objects or CL programs only.<br />
To enable modifying AS/SET-generated objects or CL programs<br />
1 From the <strong>Implementer</strong> Menu, select option 42, Environments, and press ENTER. The<br />
Work with Environments panel displays.<br />
2 Type 11=AS/SET to select the AS/SET environment and press ENTER. The Create<br />
Environment panel displays.<br />
3 In the Allow C/O of generated objects field and the Allow C/O of generated CL field, type<br />
Y or N to indicate whether the specified AS/SET-generated items allow modification.<br />
These objects are identified with an associated object code, for example, CLPOBJ,<br />
RPGOBJ, and PFOBJ. You can enter any of the following combinations in these fields.<br />
Field Entry Combinations<br />
Allow C/O of generated objects (Y/N) N N Y<br />
Allow C/O of generated CL (Y/N) Y N Y
Setting Up for Generated Object Promotions<br />
AS/SET Integration<br />
You can configure <strong>Implementer</strong> to automatically promote all AS/SET-generated objects with<br />
other promotion items.<br />
NOTE When creating a promotion request, AS/SET is required in your library list.<br />
However, to avoid generated object not being added to the request when promoting<br />
from an application set other than the one you are currently in, you should not be<br />
within the AS/SET product.<br />
To enable the automatic promotion of AS/SET generated objects<br />
1 From the <strong>Implementer</strong> Menu, select option 42, Environments, and press ENTER. The<br />
Work with Environments panel displays.<br />
2 Type 11=AS/SET to select the AS/SET environment and press ENTER. The Create<br />
Environment panel displays the AS/SET details as illustrated on page 318.<br />
3 In the Promote generated objects field, specify one of the following values.<br />
0: Does not add generated objects to the promotion request.<br />
1: Adds only generated objects to the promotion request.<br />
2: Adds generated source and objects to the promotion request.<br />
4 Press ENTER.<br />
You have the option to override these default settings at promotion time as explained next.<br />
AS/SET Dependency Check<br />
The Check ADK Dependencies (ICHKADKDEP) command checks for AS/SET object<br />
dependencies of any ADK items during check out.<br />
This feature requires setting up the <strong>Implementer</strong> Job Description (MWIJOBD) library list and<br />
a special command at the environment level. There are no special setup requirements within<br />
AS/SET.<br />
To change the job description<br />
1 On the OS/400 command line, type the following command and press F4=Prompt.<br />
CHGJOBD JOBD(MWIJOBD)<br />
2 Define the Library parameter (this is the library where the job description exists; <strong>MKS</strong>IM<br />
is the default).<br />
319
Chapter 6: Third Party Integrations<br />
320<br />
3 Define the Initial Library List parameter as follows, and press ENTER.<br />
Add the AS/SET object library (ASSETO is the default) before the AS/SET file<br />
library (ASETF is the default).<br />
Add the AS/SET object library and AS/SET file library before the <strong>Implementer</strong><br />
library.<br />
Add the QTEMP library in any position on the library list.<br />
Special Command Setup<br />
You must define the AS/SET Dependency Check as a special command attached to the *TST<br />
environment to run automatically after check out.<br />
To define the special command<br />
1 From Work with Environments, select the *TST environment with option 19=Special<br />
commands. The Work with Environment Special Commands panel displays (the panel<br />
may display existing commands).<br />
2 Press F6=Add. The Expanded Command Display panel displays.<br />
3 Define the special command as follows:<br />
In the For Action field, type 6 (Checkout).<br />
In the When to do field, type 2 (After-OK).<br />
In the Command field, type:<br />
ICHKADKDEP MBROBJ(#OBJECT)<br />
OBJCODE(#OBJCOD)<br />
FRMENV(#FRMENV)<br />
TOENV(#TRGENV)<br />
4 Press ENTER.<br />
BPCS Integration<br />
To use <strong>Implementer</strong> with SSA/BPCS software, you must make special compile changes.<br />
These changes involve setting up required object codes within <strong>Implementer</strong>, and possibly<br />
making changes to your environment setup. These setup tasks are explained next.<br />
Compile Considerations<br />
The first consideration for performing BPCS compiles within <strong>Implementer</strong> is to determine<br />
whether all compiles are BPCS compiles, or whether some compiles are BPCS compiles and<br />
others are not performed through BPCS commands or programs (for example, DSPF).
BPCS Integration<br />
If all compiles use BPCS commands or programs, you must change the standard object<br />
codes delivered with <strong>Implementer</strong>.<br />
If some compiles do not use BPCS commands or programs, you must create new object<br />
codes for the BPCS compiles and retain the standard object codes for the non BPCS<br />
compiles.<br />
For information on making these changes, see “Setting Up Object Codes” on page 321.<br />
BPCS provides programs for compiling, rather than using the standard IBM creation<br />
commands like CRTCLPGM. The BPCS compilation commands, such as CLCRTCLP, cannot<br />
be called directly because these commands submit the compile. The <strong>Implementer</strong> compile<br />
step requires the program or command used for compilation running within the<br />
<strong>Implementer</strong> submitted compile job (the command cannot submit a different job). For this<br />
reason, BPCS compiles within <strong>Implementer</strong> are performed using the BPCS programs<br />
submitted by the BPCS compile commands, not by the command itself.<br />
BPCS supports compiling the following source types.<br />
Source Type BPCS Programs Existing New<br />
CLP CLCRTCLP CLP CLPB<br />
DSPF CRTDSPLY2 DSPF DSPFB<br />
LF CLCRTLFILE LF LFB<br />
PF CLCRTPFILE PF PFB<br />
PRTF CLCRTPRTF PRTF PRTFB<br />
RPG CLRPG RPG RPGB<br />
The BPCS programs have the same first four parameters as follows:<br />
object-name (#OBJECT)<br />
to-library (#PGMLIB or #FILLIB)<br />
source-file-name (#SRCFIL)<br />
source-library (#SRCLIB)<br />
Setting Up Object Codes<br />
Change the object codes as follows. For details, see “Object Codes” on page 127.<br />
321
Chapter 6: Third Party Integrations<br />
Setting Up Environments<br />
322<br />
Existing<br />
Object Code<br />
New Object<br />
Code<br />
If you create new object codes to support BPCS compiles, any environments you define<br />
automatically allow the BPCS object codes that call the BPCS compiler and the standard<br />
object codes that call the OS/400 compiler. Thus, you may want to deactivate the standard<br />
object codes for BPCS environments.<br />
To deactivate standard object codes for BPCS environments<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Environments and press ENTER.<br />
2 Type 2=Change to select a BPCS environment. The Change Environment panel displays.<br />
3 Press F8=Object Codes. The Change Environment Object Code Overrides panel displays.<br />
4 In the Allow field, type N next to the object code to deactivate it.<br />
5 Press ENTER to save the change.<br />
BRMS/400 Integration<br />
Command or String to Use<br />
CLP CLPB CALL PGM(CLCRTCLP) PARM(#OBJECT #PGMLIB #SRCFIL<br />
#SRCLIB '*YES')<br />
DSP DSPFB CALL PGM(CRTDSPLY2) PARM(#OBJECT #PGMLIB #SRCFIL<br />
#SRCLIB '*YES' 'BPCS' '*YES')<br />
LF LFB CALL PGM(CLCRTLFILE) PARM(#OBJECT #FILLIB #SRCFIL<br />
#SRCLIB '*YES' '*YES')<br />
PF PFB CALL PGM(CLCRTPFILE) PARM(#OBJECT #FILLIB<br />
#SRCFIL#SRCLIB '*YES' *NO' '*YES' '*YES' 'BPCS'<br />
'PGMMSGQ')<br />
PRTF PRTFB CALL PGM(CLCRTPRTF) PARM(#OBJECT #PGMLIB #SRCFIL<br />
#SRCLIB '*YES' '*YES')<br />
RPG RPGB CALL PGM(CLRPG) PARM(#OBJECT #PGMLIB #SRCFIL<br />
#SRCLIB '*YES' '*YES')<br />
<strong>Implementer</strong> supports using a third party save/restore utility for saving archives to tape. For<br />
example, you can use IBM’s Backup Restore Management System (BRMS/400), or an<br />
internally developed program. In this scenario, all Archive to Tape menu options are<br />
available except for menu option 2, Restore Archives from Tape. When you need to restore a<br />
tape archive created by a third party utility, you must restore the tape using that utility.
Code/400 Integration<br />
Using a third party utility requires you activate the <strong>Implementer</strong> data area IMSVPGM, as<br />
well as activate a skeleton CL program provided in the <strong>Implementer</strong> source file QSAMPLE.<br />
Once set up, you can use the Save Archives to Tape option on the Archive to Tape Menu to<br />
call your internally defined command (rather than the standard IBM Save Library (SAVLIB)<br />
command).<br />
NOTE QSAMPLE is a source file delivered in the <strong>Implementer</strong> product library<br />
(<strong>MKS</strong>IM is the default product library). QSAMPLE provides technical information<br />
and programs that help you to customize certain features of <strong>Implementer</strong>.<br />
To set up archiving to tape for a third party save/restore utility<br />
1 Perform the environment archive setup as described in “Environments” on page 81.<br />
2 In the <strong>Implementer</strong> source file QSAMPLE, modify the CL program IMSVLB2 to call your<br />
third party save command.<br />
For details on using QSAMPLE, refer to the source contained within the file.<br />
3 Activate the IMSVPGM data area by issuing the Change Data Area (CHGDTAARA)<br />
command as follows:<br />
CHGDTAARA DTAARA(IMSVPGM (1 10)) VALUE(LIBRARY)<br />
CHGDTAARA DTAARA(IMSVPGM (11 10)) VALUE(PROGRAM)<br />
Where the value in positions 1 through 10 is the library name associated with your<br />
internal program, and the value in positions 11 through 20 is the name of the internal<br />
program defined in program IMSVLB2 in QSAMPLE. For details on the IMSVPGM data<br />
area, see “Save Program Name (IMSVPGM)” on page 411.<br />
Code/400 Integration<br />
CODE/400 (CoOperative Development Environment/400) is a workstation-based, client/<br />
server development environment that is available with IBM’s WebSphere Development<br />
Tools for the iSeries. With CODE/400, you can edit, compile, and debug client/server<br />
applications, as well as applications written in many other OS/400 languages. For details on<br />
using Code/400, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Requirements and Setting Up<br />
This guide assumes CODE/400 and <strong>Implementer</strong> are set up and running successfully within<br />
your organization.<br />
323
Chapter 6: Third Party Integrations<br />
324<br />
To create the user-defined options<br />
Access PDM to create the user-defined options that access CODE/400 from the <strong>Implementer</strong><br />
Workbench.<br />
For example, to invoke CODE/400 to edit a source member, create an option defined with the<br />
following command syntax:<br />
where:<br />
Call qcode/evfcfdbk parm('37' 'Y' 'OS400' ' CODEEDIT<br />
"&L/&F (&N)"')<br />
Value Description<br />
37 Coded character set identifier (CCSID) used to send information to the<br />
desktop.<br />
Y Specify Y to display a message, or N to bypass messages.<br />
OS400 Specify the type of server to log messages in the command shell. If the OS/400<br />
server is not defined, you may get an error in the command shell.<br />
Specify the CODE/400 server location, or (empty brackets) to use the first<br />
active CODE/400 server.<br />
CODEEDIT Specify the command to run on the desktop (indicated by ). You must<br />
enclose the command in double quotes. The command options are:<br />
CODEBRWS to browse.<br />
CODEEDIT to edit.<br />
CODEDSU to design (screens).<br />
"&L/&F (&N)" &L is the library.<br />
&F is the source file.<br />
&N is the member name.<br />
Must have a blank space between &F and (&N) to correctly substitute the<br />
source file.<br />
Help Desk Integration<br />
<strong>Implementer</strong> integrates with open help desk and Customer Relationship Management<br />
(CRM) applications, providing the ability to associate calls that are logged in a help desk<br />
software package with DesignTracker design requests (DR) and service requests (SR).<br />
You can use <strong>MKS</strong> SupportCenter or any other help desk software that has an ODBC (Open<br />
Database Connectivity) or JDBC (Java Database Connectivity) accessible database.
Requirements<br />
This help desk integration requires the following:<br />
DTBridge is installed and configured. DTBridge is delivered with <strong>Implementer</strong><br />
Help Desk Integration<br />
DesignTracker is installed and configured as your issue management application (you<br />
must not be using <strong>MKS</strong> Integrity for issue tracking). DesignTracker is delivered with<br />
<strong>Implementer</strong>.<br />
SupportCenter 3.2 is installed; however this requirement does not force you to use<br />
SupportCenter as your help desk application. SupportCenter is required for the use of<br />
the call header file, which is populated with the data extracted from your help desk<br />
database when the update runs. SupportCenter is delivered with <strong>Implementer</strong>. If<br />
SupportCenter is your help desk application, this guide assumes it is configured. If<br />
SupportCenter is not your help desk solution, this guide assumes that a different help<br />
desk product is configured.<br />
Setting Up the Help Desk Integration<br />
These instructions assume that <strong>Implementer</strong>, DesignTracker, DTBridge, and SupportCenter<br />
are installed and configured. In addition, you must perform the following setup in the<br />
DTBridge properties file prior to running the Associate Calls Update program.<br />
DTBridge Properties Setup<br />
The DTBridge properties file (DTBridge.properties) contains the application control<br />
properties for the Associate Calls functionality and a few other integrations. The DT Call<br />
Association properties relate to the Associate Calls Update program. For details on<br />
DTBridge, see “Installing DTBridge” on page 135.<br />
To start DTBridge Console and configure the DTBridge properties file<br />
1 Click Start > Programs > <strong>MKS</strong> <strong>Implementer</strong> > DTBridge Console. The DTBridge Console<br />
window displays. Notice the Status bar indicates DTBridge is not active.<br />
2 Click File > Setup from the menu. The Edit DTBridge Setup properties file displays.<br />
The properties file is organized by functional area. The help desk integration requires<br />
input in the DT Call Association Properties only.<br />
At the beginning of each section the properties are listed with a brief description and<br />
example. At the end of each section, the property displays again as property name=x.<br />
Instructions and examples are also included within the DTBridge properties file.<br />
3 Configure the properties as described in the following table. Define OS/400 values using<br />
upper case syntax. When defining the property value, type the value as follows:<br />
property name=property value<br />
325
Chapter 6: Third Party Integrations<br />
DT Call Association<br />
Properties<br />
326<br />
4 When you are finished, click File > Save Setup.<br />
Description<br />
DT Call Association Properties<br />
SCLibrary Name of your SupportCenter library or the library that contains the HDPHDRP file.<br />
SCUser User profile that has authority to the library defined for SCLibrary.<br />
SCPassword Password associated with the SCUser property.<br />
HDDSN Name of the ODBC data source that points to the help desk database to extract call<br />
information from.<br />
HDUser User ID to access the help desk database defined for the HDDSN property.<br />
HDPassword Password associated with the HDUser property.<br />
HDDRSelectSQL SQL statement that retrieves call information to generate SupportCenter call header<br />
records associated with DesignTracker DRs. The SQL select statement must include<br />
the following fields in the order listed.<br />
Call ID, 10a<br />
Customer Number, 10a<br />
Customer Name, 30a<br />
Product Name, 10a<br />
Allocated to, 10a<br />
Waiting on, 10a<br />
Call Status, 1a<br />
Design Request #, 5,0<br />
HDSRSelectSQL SQL statement that retrieves call information to generate SupportCenter call header<br />
records associated with DesignTracker SRs. The SQL select statement must include<br />
the following fields in the order listed.<br />
Call ID, 10a<br />
Customer Number, 10a<br />
Customer Name, 30a<br />
Product Name, 10a<br />
Allocated to, 10a<br />
Waiting on, 10a<br />
Call Status, 1a<br />
Service Request #, 5,0<br />
NOTE For details on SQL statements, see “Defining the Structured Query Language<br />
Statements” in the next section.
Updating Calls<br />
Defining the Structured Query Language Statements<br />
Help Desk Integration<br />
When defining the Structured Query Language (SQL) statements for the HDDRSelectSQL<br />
and HDSRSelectSQL properties, specify the selected fields in the following order:<br />
Call ID (10a)<br />
Customer Number (10a)<br />
Customer Name (30a)<br />
Product (10a)<br />
Allocated to (10a)<br />
Waiting on (10a)<br />
Call Status (1a)<br />
DR or SR number (5,0)<br />
The size of the original field in your help desk software is not important because the field<br />
truncates to the size indicated when updating the SupportCenter call header file.<br />
The following is an example SQL statement:<br />
SELECT SUBSTR(S_SRV_REQ.SR_NUM,1,10),<br />
SUBSTR(S_SRV_REQ.CST_OU_ID,1,10), SUBSTR(S_ORG_EXT.NAME,1,30),<br />
SUBSTR(S_PROD_INT.NAME,1,10), SUBSTR(S_EMPLOYEE.LOGIN,1,10),<br />
SUBSTR(S_SRV_REQ.SR_SUB_STAT_ID,1,10),<br />
SUBSTR(S_SRV_REQ.SR_STAT_ID,1,1), SUBSTR(S_SRV_REQ.SR_CST_NUM,3,5)<br />
FROM SIEBEL.S_EMPLOYEE S_EMPLOYEE, SIEBEL.S_ORG_EXT S_ORG_EXT,<br />
SIEBEL.S_PROD_INT S_PROD_INT, SIEBEL.S_PROD_LN S_PROD_LN,<br />
SIEBEL.S_SRV_REQ S_SRV_REQ WHERE S_SRV_REQ.CST_OU_ID =<br />
S_ORG_EXT.ROW_ID AND S_SRV_REQ.PRDINT_ID = S_PROD_INT.ROW_ID AND<br />
S_PROD_INT.PR_PROD_LN_ID = S_PROD_LN.ROW_ID AND<br />
S_SRV_REQ.OWNER_EMP_ID = S_EMPLOYEE.ROW_ID AND ((S_SRV_REQ.SR_CST_NUM<br />
Like 'DR%') AND (S_PROD_LN.NAME Like '%<strong>MKS</strong>%'))<br />
You run the Associate Calls Update program from the DTBridge Console. A Java class<br />
executes your defined SQL statements, which associates calls with the appropriate DR or SR<br />
and generates a history log of the associated calls. For example, any records containing data<br />
that maps incorrectly (such as alpha data in the numeric DR/SR number field) causes a<br />
warning message in the history log. The invalid records are skipped, and the process<br />
continues with the next record. A total count of all warnings posted (resulting in records not<br />
updated) prints at the end of the log. To view the latest history log, from the DTBridge<br />
Console, click File > View History.<br />
327
Chapter 6: Third Party Integrations<br />
328<br />
You can view prior history logs through Windows Explorer. The default location is C:/<br />
Program Files/<strong>MKS</strong>/<strong>Implementer</strong>/DTBridge. History log names consist of the date and<br />
time created, and the file extension .log, for example, DTHD<strong>2006</strong>0115134216.log.<br />
Once the update successfully completes, access DesignTracker and view the updated DRs<br />
and SRs with option 17=Display calls.<br />
DTBridge Silent Update<br />
Updating calls using the silent method allows you to quickly process the updates without<br />
interactively viewing the updates or subsequent messages that occur. The updates and<br />
corresponding status are recorded to a log file in the same directory.<br />
To update calls using DTBridge silent method<br />
From your Windows desktop, click Start > Programs > <strong>MKS</strong> <strong>Implementer</strong> > Associate Help<br />
Desk Calls.<br />
The update processes during a brief pause. When it completes, you can review the history log<br />
file for detailed job information.<br />
DTBridge Console Update<br />
Updating calls using the DTBridge console provides a GUI interface that allows you to<br />
interactively view the updates and subsequent messages as they occur.<br />
To update calls using DTBridge Console<br />
1 From your Windows desktop, click Start > Programs > <strong>MKS</strong> <strong>Implementer</strong> > DTBridge<br />
Console. The DTBridge window displays.<br />
2 Click Tools > Associate Calls. Status messages display to indicate each process that<br />
occurs and the subsequent results.<br />
LANSA Integration<br />
The <strong>Implementer</strong> Adapter for LANSA is a separately licensed product that provides<br />
integration with the following LANSA products:<br />
LANSA for iSeries<br />
LANSA for the Web<br />
Visual LANSA<br />
The integration provides for the controlled check out and promotion of LANSA objects,<br />
allowing you to manage the development of LANSA files, fields, processes, and functions, as<br />
well as Web and Extensible Markup Language (XML) components and system variables.
LANSA Integration<br />
You manage LANSA objects with LANSA environments. A LANSA environment type is<br />
established by associating an <strong>Implementer</strong> environment with a valid LANSA partition. This<br />
ensures any changes to objects in a partition are managed using the associated environment.<br />
Specific object codes accomplish the check out and promotion of LANSA objects to and from<br />
the LANSA environments. The Check Out function locks the name of the LANSA object<br />
and—depending on the environment definition—copies (export and import) the LANSA<br />
objects to the development environment.<br />
Promotion prepares the LANSA objects for export and moves (imports) the objects into the<br />
target environment. Distribution of LANSA objects to remote locations is supported.<br />
LANSA objects are archived in the archive library specified for the target environment.<br />
<strong>Implementer</strong> supports using LANSA task tracking to manage the development of LANSA<br />
objects and related issues.<br />
All reports and inquiries track the LANSA objects managed by <strong>Implementer</strong>.<br />
Setting Up the Interface<br />
The following information applies to setting up the integration. For more information, see<br />
“LANSA Prerequisites” on page 107.<br />
In System Control Maintenance, verify the LANSA installed field is set to Y.<br />
Change the <strong>Implementer</strong> job description (MWIJOBD) to include the LANSA product<br />
libraries in the library list.<br />
IMPORTANT The job description must include the LANSA libraries to avoid the<br />
promotion of LANSA definitions ending abnormally.<br />
Verify the <strong>Implementer</strong> user profile MWIPROD has authority to modify and delete the<br />
definitions for all LANSA objects managed with <strong>Implementer</strong>.<br />
<strong>Implementer</strong> provides the IMLNPSO data area that allows you to store the name of the<br />
LANSA partition security officer. <strong>Implementer</strong> runs the LANSA command for export/<br />
import using the partition security officer profile to prevent migration failures caused by<br />
insufficient authority to the LANSA command and the items being exported. For details<br />
on the data area, see “LANSA Partition Security Officer (IMLNPSO)” on page 408.<br />
If distributing LANSA objects to remote locations using the <strong>Implementer</strong> Receiver,<br />
<strong>Implementer</strong> uses the IMPJOBD job description (in library <strong>MKS</strong>IR) on the remote system<br />
to set the library list for remote jobs. This requires you add the LANSA product libraries<br />
DC@PGMLIB, DC@DTALIB, and DC@DEMOLIB to the IMPJOBD library list. If you<br />
renamed the LANSA product libraries, add the renamed libraries to the initial library list<br />
of the IMPJOBD job description.<br />
329
Chapter 6: Third Party Integrations<br />
330<br />
<strong>Implementer</strong> supports only one copy of LANSA product libraries per installation. If you<br />
use separate copies of LANSA on a single system where each copy has its own data and<br />
program libraries, for example, one copy for development and/or QA and another copy<br />
for production, each LANSA copy must point to a different copy of <strong>Implementer</strong>. For<br />
information on troubleshooting problems with this usage, see the related messages in job<br />
MON_BK0516. For information on installing parallel versions of <strong>Implementer</strong>, see the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>.<br />
Defining Environments and Loading the Repository<br />
The set up activities associated with managing LANSA applications include setting up the<br />
environments that manage LANSA objects. You must associate each of these environments<br />
with a partition where the LANSA applications reside.<br />
In Work with Environments, establish the environment as a LANSA environment by<br />
specifying an existing LANSA partition in the LANSA partition name field.<br />
In the Copy LANSA object in check out field, specify whether to copy LANSA objects to<br />
this environment during check out.<br />
Do not specify the same partition for a From environment and target environment if the<br />
environments are used for the same check out or promotion session. The special<br />
environment type displays on the second Change Environments panel. If you remove<br />
the partition name, the environment type reverts to a standard environment.<br />
If you use a LANSA environment only for LANSA definitions, set the Compile required<br />
field to N.<br />
The export step exports LANSA objects on the request to a save file. You can set<br />
promotion processing to automatically submit through the export step only. In the<br />
Change Environment panel, specify Y in the Auto submit in create rqs field, and type<br />
1=Expt in the Through step field.<br />
To verify successful completion of the export, review the export reports generated by<br />
LANSA, or use data area IMLNMSG as described in “Ending Promotions Based on<br />
Message ID” on page 331.<br />
To use an environment group for LANSA objects, the primary environment must be a<br />
LANSA environment. LANSA objects are moved to other environments in the group<br />
only if they have a special environment type of LANSA.<br />
To archive LANSA objects, each LANSA environment must specify the archive library<br />
and the number of archive versions to retain. For information on how to archive and<br />
recover LANSA requests, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Run the Build List to create the list of LANSA objects in the partition associated with the<br />
LANSA environment. <strong>Implementer</strong> analyzes the LANSA repository and retrieves the list<br />
of LANSA objects.
Ending Promotions Based on Message ID<br />
LANSA Integration<br />
<strong>Implementer</strong> provides the IMLNMSG data area that allows you to store the message IDs of<br />
errors you want to force a promotion to fail on if the error is encountered. Fatal messages<br />
automatically cause the promotion to fail.<br />
During promotion processing, <strong>Implementer</strong> compares the message IDs written in the export<br />
list spool file to the message IDs recorded in the IMLNMSG data area. When a match is<br />
found, it ends the processing of the promotion job.<br />
This data area is blank by default. When adding multiple message IDs, separate the message<br />
ID values with one blank space.<br />
LANSA Object Codes<br />
<strong>Implementer</strong> provides the following object codes for checking out and promoting LANSA<br />
definitions. Before using the object codes for the first time, you must run the Build List for<br />
each LANSA environment to update the repository.<br />
<strong>Implementer</strong> uses the object code’s special characteristic to derive logic. The special<br />
characteristic matches the object code name and assigns the object authority *KEEP. You can<br />
change the name of an object code, but you cannot change the special characteristic.<br />
Object Code Description<br />
LANFLD LANSA fields.<br />
LANFIL LANSA files.<br />
LANFLDT LANSA files with data.<br />
LANPROC LANSA process.<br />
LANFNC LANSA functions.<br />
LANWEBC LANSA Web components.<br />
LANXMLC LANSA XML components.<br />
LANSVAR LANSA system variables.<br />
LANMVAR LANSA multi-lingual system variables.<br />
<strong>Implementer</strong> supports having the same file name in a single partition that exists in two<br />
different libraries. This feature requires using separate object codes for each file library. In<br />
addition, each separate object code must have the object library specified at the environment<br />
level. For information on setting up object codes, see page 127. For information on overriding<br />
a default library for an object code and environment, see “Environment Overrides” on<br />
page 133.<br />
331
Chapter 6: Third Party Integrations<br />
LANSA Task Tracking<br />
Visual LANSA<br />
332<br />
<strong>Implementer</strong> supports using LANSA task tracking to manage your LANSA development<br />
and related issues.<br />
Task tracking replaces the use of <strong>Implementer</strong> projects. With task tracking enabled,<br />
<strong>Implementer</strong> processes LANSA tasks as projects by creating a project record from the<br />
specified task number, if one does not already exist. To support the LANSA task number<br />
format of 8 characters and <strong>Implementer</strong>’s project number format of 7 characters, the LANSA<br />
task number right-truncates when converted to the <strong>Implementer</strong> project ID.<br />
<strong>Implementer</strong> creates a project record for any task number that exists in the LANSA task<br />
definition log file with a status of Open or Work. <strong>Implementer</strong> also creates a project record if<br />
the task exists in the LANSA TTS object register file and the task number does not exist in the<br />
<strong>Implementer</strong> project file. If the task does not exist in the TTS object register file, any value<br />
specified in the Project Reference field is processed as a project number by <strong>Implementer</strong>.<br />
When creating a request, the locked project number defaults in the Project Reference field on<br />
the Create Request panel. During the move, the project number defaults in the TASK_ ID<br />
parameter on the LANSA command for exporting and importing.<br />
The LANSA command allows only one task number; thus, only one task number is allowed<br />
per promotion request. Using project filters guarantees only one task number per request. If<br />
you select records for more than one task number, exit the Create Request panel and clear the<br />
selected objects to omit.<br />
LANSA task tracking is controlled in <strong>Implementer</strong> by the LANSA Task Usage (IMLNTSK)<br />
data area. The data area value must be *YES to enable task tracking (the default value is<br />
*NO).<br />
To enable LANSA task tracking<br />
Issue the CHGDTAARA command as follows:<br />
CHGDTAARA DTAARA(IMLNTSK) VALUE(*YES)<br />
<strong>Implementer</strong> provides integration with Visual LANSA for the development of your graphical<br />
and client/server applications in a Windows-based development environment.<br />
Key Considerations<br />
The following information applies to setting up and using Visual LANSA with <strong>Implementer</strong>.<br />
Environment pathing must be set up for LANSA environments. The test partition is<br />
allowed on only one path.
Lawson Software Integration<br />
Emergency development requires a separate emergency development partition. The<br />
emergency partition is allowed on only one path.<br />
All environments on the path require the Copy LANSA objects in check out field set to N.<br />
Visual LANSA requires the use of task tracking within your development model. For<br />
details, see “LANSA Task Tracking” on page 332.<br />
The MWIPROD user profile must have data read authority to the following LANSA files<br />
used by <strong>Implementer</strong> programs:<br />
DC@F76V1 (TTS Object Event Log)<br />
DC@F75V2 (TTS Task Definition Log)<br />
DC@F74V1 (TTS Object Register)<br />
Change the DC@A07 data area in LANSA to set an <strong>Implementer</strong> exit program that<br />
executes the LANSA APIs to run a command. This task is described next.<br />
To change the DC@A07 data area in LANSA<br />
Issue the following command:<br />
CHGDTAARA DTAARA(DC@PGMLIB/DC@A07 (689 20)) VALUE('<strong>MKS</strong>IM<br />
IMLNUSEX')<br />
IMPORTANT Previous releases of the <strong>Implementer</strong> and Visual LANSA integration<br />
required adding a trigger to LANSA file DC@F76 in library DC@DTALIB. The<br />
DC@A07 data area replaces the need for the trigger; thus, you must remove the<br />
trigger if it exists. Use the following command to remove the trigger:<br />
RMVPFTRG FILE(DC@DTALIB/DC@76) TRGTIME(*ALL) TRGEVENT(*ALL)<br />
Lawson Software Integration<br />
Lawson Software provides a comprehensive and customizable solution that includes<br />
applications for enterprise performance management, distribution, financial statements,<br />
human resources, procurement, retail operations, and service process optimization.<br />
<strong>Implementer</strong> is compatible with all releases of Lawson Software.<br />
When configuring <strong>Implementer</strong> for integration with Lawson, two features of the Lawson<br />
modules require additional setup considerations:<br />
Source and object library structure.<br />
LID method of screen and report generation in Lawson 7.<br />
333
Chapter 6: Third Party Integrations<br />
Source and Object Library Structure<br />
334<br />
In a typical Lawson environment, source is delivered in a single source library and source<br />
members are stored in application-specific source files. For example, the accounts payable<br />
source file QAPRPGSRC contains all source members for the Accounts Payable module.<br />
The recommended approach for configuring <strong>Implementer</strong> is to define one set of<br />
environments that encompasses all Lawson applications, rather than a set of environments<br />
for each application. The Lawson source is contained in one library with many source files<br />
that differentiate the application modules. The source types specified on each source member<br />
allows <strong>Implementer</strong> to assign object codes when you run the Build List.<br />
LID Method of Screen and Report Generation<br />
Lawson 7 provides a Graphical User Interface (GUI) for viewing the application’s screens and<br />
reports. Another feature provides greater control of report printing. This method of creating<br />
screens and reports is referred to as “LID method of screen and report generation”.<br />
<strong>Implementer</strong> supports the management of screen and report generation by using specific<br />
object codes you create for each Lawson application module. The object codes have userdefined<br />
commands and programs. To assist with the minimal setup, <strong>Implementer</strong> provides<br />
sample programs in source file QSAMPLE (in the <strong>Implementer</strong> product library <strong>MKS</strong>IM) that<br />
describe how to create the command and CL program for each object code. Refer to the<br />
following Lawson-related items in QSAMPLE:<br />
Member/Object Type Description<br />
PCRTPRNT7 CMD Lawson create print command.<br />
PCRTPRNT7C CLP Lawson create print command CPP for LID method of screen and<br />
report generation.<br />
PCRTSCRN7 CMD Lawson create screen command.<br />
PCRTSCRN7C CLP Lawson create screen command CPP.<br />
See the instructions included in source member PCRTPRNT7 for creating the printer related<br />
object code. See the instructions included in source member PCRTSCRN7 for creating the<br />
screen related object code. These commands execute the Lawson LAWENV program to set<br />
library lists and environment variables, and execute the Lawson command to create GUI<br />
information for the screens and reports.<br />
NOTE For details on QSAMPLE, see “Customizing <strong>Implementer</strong>” on page 414.
The object code values required for a Lawson screen generation are as follows:<br />
Field Required Value<br />
Object Code SCRNAP7<br />
Source member type SCRN<br />
Default source file APRPGSRC7<br />
Object authority *KEEP<br />
Creation process M<br />
The object code values required for a Lawson report source are as follows:<br />
Lawson Software Integration<br />
Creation command PCRTSCRN7 LAWENV(#ENV) LAWAPP(application_name)<br />
SOURCE(#SRCFIL) MEMBER(#OBJECT)<br />
Field Required Value<br />
Object Code PRNTAP7<br />
Source member type PRNT<br />
Default source file APRPGSRC7<br />
Object authority *KEEP<br />
Creation process M<br />
Creation command PCRTPRNT7 LAWENV(#ENV) LAWAPP(application_name)<br />
SOURCE(#SRCFIL) MEMBER(#OBJECT)<br />
NOTE The instructions in QSAMPLE explain that the object code uses the creation<br />
command with the default parameters defined for the CL program, and instruct you<br />
to modify the CL using the default values for the LAWENV and LAWAPP<br />
parameters. Thus, if you modify the default value of either of these parameters, you<br />
must include the parameters and new values on the object code creation command.<br />
Environment Setup<br />
If you deploy Lawson applications to a remote environment defined with local source and<br />
local compiles (in Work with Environments), an additional configuration step is required to<br />
create the LID information during promotion.<br />
For each remote environment defined with local source and local compile location, create a<br />
special command to run on the remote system as described next.<br />
335
Chapter 6: Third Party Integrations<br />
336<br />
To create the special command for a remote environment<br />
1 From Work with Environments, select the remote Lawson environment with option<br />
19=Special commands and press ENTER. The Work with Special Commands panel<br />
displays.<br />
2 Press F6=Create. The Expanded Command Display panel displays.<br />
3 Define the fields as follows:<br />
In the For Action field, type 4=Move.<br />
In the When to do field, type 2=After-OK.<br />
In the Sequence number field, type 1.0. If the environment has other special<br />
commands, specify the number in relation to the other special commands.<br />
In the Command field, type the following command syntax:<br />
IEXCRQSDTL OBJCODE(*ALL)<br />
RQSNBR(#RQSNBR)<br />
TARGET(ENV_NAME)<br />
COMMAND(PCRTPRNT7 LAWENV(#TRGENV) LAWAPP(AP)<br />
SOURCE(#SRCFIL) MEMBER(#SRCMBR))<br />
4 Press ENTER to add the command.<br />
Frequently Asked Questions<br />
Do I need to define the CALL LAWENV command in a special command?<br />
No. The CL program delivered in QSAMPLE executes the LAWENV command to set the<br />
library list and Lawson environment variables to ensure the LID-created objects are created<br />
successfully.<br />
How are you able to run the LAWENV program in a submitted program?<br />
Passing blanks as the second parameter allows the LAWENV program to run in batch.<br />
Do I need to change the <strong>Implementer</strong> job description to include Lawson libraries?<br />
No. During check out and promotion <strong>Implementer</strong> uses the environment library list to<br />
perform the required library manipulation.<br />
Lotus Domino Integration<br />
<strong>Implementer</strong> provides integration with Lotus Domino to offer change management support<br />
for iSeries-based Lotus Notes and your internally developed Domino software applications.
Lotus Domino Integration<br />
This separately licensed feature provides browser-based check out, promotion, and<br />
deployment of Lotus Notes Storage Files (NSF) and Notes Template Files (NTF) from<br />
Domino Designer. To ensure the Notes databases you deploy have the correct authority,<br />
<strong>Implementer</strong> allows you to set the Domino Access Control List (ACL) during check out and<br />
promotion.<br />
The integration supports using <strong>MKS</strong> Integrity issues or DesignTracker design requests when<br />
checking out and promoting NSFs and NTFs. The integration builds on the framework of the<br />
existing <strong>Implementer</strong> technology that includes the latest support for IFS technology and<br />
change management of client/server applications. The integration capitalizes on the<br />
browser-based support <strong>Implementer</strong> provides for IFS objects.<br />
With this solution, the <strong>Implementer</strong> for Domino interface incorporates Domino development<br />
in tandem with your iSeries development. From within Domino, developers can check out<br />
the Notes databases using a browser interface. After completing the work, objects can be<br />
promoted through a browser interface to a *QAC or *PRD environment back on the iSeries.<br />
After promotion, the objects reside in a staging repository where they are subsequently<br />
deployed to a Domino server or Domino clients. The server updates are accomplished by<br />
either another iSeries under the control of <strong>Implementer</strong>, or an NT mounted drive. Domino<br />
client updates are under the control of Tivoli.<br />
To facilitate ease of use, developers can use <strong>Implementer</strong> without familiarity of the iSeries, by<br />
using a browser interface that supplies functionality to the desktop. For access to the iSeries,<br />
the interface construct uses CGI (Common Gateway Interface) technology.<br />
<strong>Implementer</strong> enables you to track all software changes made to Lotus Domino objects that<br />
reside on the iSeries, with the following benefits:<br />
Centralized Registry of Objects in iSeries Folders<br />
The <strong>Implementer</strong> repository maintains objects that reside in the IFS directory, as well as<br />
traditional OS/400 member/objects. Use the <strong>Implementer</strong> Work with Objects function to<br />
view repository items.<br />
Promotion Transaction History<br />
The Request Inquiry panel maintains a current list of all items promoted into a particular<br />
environment by <strong>Implementer</strong>. For IFS objects, historical data provides vital information<br />
such as object author, object authorities, and time/date stamps for each step of a<br />
promotion.<br />
Synchronized With Legacy Applications<br />
<strong>Implementer</strong> for Domino supports controlled deployment of multiple applications<br />
during a single promotion. You can install traditional OS/400 objects along with IFS<br />
objects, without having to maintain multiple software packages for tracking and<br />
maintaining objects on the iSeries and Domino server. This deployment architecture<br />
ensures minimum downtime during your application programming.<br />
337
Chapter 6: Third Party Integrations<br />
Requirements<br />
338<br />
Deployment Packaging<br />
Easily create change packages of Notes databases to deploy using the menu or from<br />
command line interfaces in <strong>Implementer</strong>. Initiate package deployment using the<br />
deployment server—configurable to automatically install change packages on each<br />
target server—with no intervention required on your part.<br />
Customizable scheduling of change packages allows you to install changes when you<br />
need them. For change packages deployed to multiple servers, you can schedule each<br />
package to run at a specific time based on the local needs of each server. Upon<br />
completion, status information posts back to the deployment server.<br />
Synchronized With Back Office Development<br />
<strong>Implementer</strong> for Domino allows you to deploy changes consisting of both Lotus Notes<br />
content and integrated back office changes. This ensures synchronous deployment of<br />
your RPG or COBOL based business logic and DB2/400 databases (integrated with<br />
Notes applications) to your testing or production servers. This deployment architecture<br />
ensures a minimum of downtime for your applications.<br />
Synchronized With Other e-Business Initiatives<br />
<strong>Implementer</strong> for Domino manages your e-Business development needs when they<br />
expand beyond Notes applications. As with back office development, it also allows for<br />
management of your Java executables; static HTML, XML, and XSL; and graphics (such<br />
as JPEG and GIF files), along with your Notes development.<br />
This <strong>Implementer</strong> release is certified to work with Domino release 6.0. The requirements for<br />
these integrated features are as follows:<br />
<strong>Implementer</strong> <strong>2006</strong> for deployment of Lotus NSFs and NTFs. <strong>Implementer</strong> requires<br />
OS/400 V5R1 or later, or i5/OS V5R3 or later.<br />
Lotus Notes R4.6 or later (including Notes Client, Domino Designer, and Domino<br />
Administrator).<br />
Domino Server R4.6 or later for deployment. The Domino Server provides the easiest<br />
and most flexible use of the Lotus Notes database and the <strong>Implementer</strong> change<br />
management software by using the same platform to create, change, move, and deploy<br />
the Lotus NSFs and NTFs.<br />
This integration expands to Domino Servers on platforms other than the iSeries. For<br />
example, you can run a Domino Server on a Windows NT platform to create Lotus NSFs<br />
and NTFs, which you can place under <strong>Implementer</strong> change management control using a<br />
mapped network drive or shared network folder.<br />
Internet Explorer 4.0 or later, or Netscape 4.5 or later.
iSeries Setup and Configuration<br />
Lotus Domino Integration<br />
This integration supports using either of the IBM HTTP Web servers: the original Web Server<br />
for iSeries or the Apache Web Server for iSeries. Before using the integration, your system<br />
administrator or a user who is authorized and familiar with server setup functions needs to<br />
configure the Web interface to use one of these servers. For detailed information on setting<br />
up the servers, see “iSeries Web Server Setup” on page 156. When you have finished that<br />
task, continue with “<strong>Implementer</strong> Setup and Configuration” in the next section.<br />
NOTE The following sections describe how to set up the basic Lotus Domino<br />
integration. For details on setting up ACL management, see “Managing the Domino<br />
Access Control List” on page 343. For details on setting up database signing, see<br />
“Database and Template Signing” on page 351.<br />
<strong>Implementer</strong> Setup and Configuration<br />
The following tasks assume the *PRD, *TST, and *QAC environments that manage Lotus<br />
development and IFS objects are set up in <strong>Implementer</strong> with the IFS directory path and path<br />
owner, IFS object owner, and archive information (if archiving). When defining the Domino<br />
environments, define the *PRD environment with a standard application path. In addition, to<br />
ensure the correct ownership of Domino database archives, specify an archive directory that<br />
is outside of the standard Domino data directory. For details on environment setup, see<br />
“Environments” on page 81.<br />
<strong>Implementer</strong> provides the Domino Server Data Directory (IMDOMDATA) data area that<br />
allows you to record the server data directory for <strong>Implementer</strong> to use to call the Domino API.<br />
This is only required if you are using Domino 6.0 and the Domino server does not use the<br />
Domino 5 default data directory /notes/data.<br />
In the IMDOMDATA data area (located in the <strong>Implementer</strong> product library <strong>MKS</strong>IM) you<br />
must specify the actual data directory used by the Domino sever. The data area is delivered<br />
with a blank default value.<br />
To change the IMDOMDATA data area<br />
1 Issue the CHGDTAARA command and press F4 to prompt.<br />
2 In the New value field, specify the data directory for the Domino server.<br />
3 Press ENTER.<br />
339
Chapter 6: Third Party Integrations<br />
Domino Designer Setup and Configuration<br />
340<br />
The <strong>Implementer</strong> for Domino integration uses Uniform Resource Locator (URL) technology<br />
to access the iSeries and run the check out and promotion programs. This allows you to run<br />
the <strong>Implementer</strong> Software Adapter for Domino programs by using any viable method for<br />
accessing Internet addresses, such as:<br />
type the URL in the browser Address bar<br />
add the URL to the browser Favorites list<br />
create custom tools in Domino Designer 6.0 (SmartIcons in Domino Designer 5.0)<br />
Using Domino tools or SmartIcons allows you to customize the <strong>Implementer</strong> for Domino<br />
programs and run the browser-based functions from the desktop. These methods require you<br />
create either tools or icons defined with the URL path on the iSeries that points to the Web<br />
check out program and the Web promotion program.<br />
If you use <strong>MKS</strong> Integrity for issue management within <strong>Implementer</strong>, you can automate the<br />
integration by creating tools or SmartIcons to run <strong>MKS</strong> Integrity from within Domino<br />
Designer. For details on this feature, see “<strong>Implementer</strong> and Integrity Manager Integration”<br />
on page 21.<br />
To run the <strong>Implementer</strong> for Domino Web programs from an Internet Explorer or<br />
Netscape browser<br />
Open your browser, and in the Address bar type the URL for the iSeries (include the bin<br />
directive), for example:<br />
http://your-iSeries-name/cgi-bin/imweb?cmd=chkout<br />
where,<br />
//your_iSeries_name defines the iSeries host name<br />
/cgi-bin defines the reference within the HTTP configuration that points to the<br />
<strong>Implementer</strong> library<br />
/imweb?cmd=chkout defines the <strong>Implementer</strong> program to run<br />
To create custom tools in Domino Designer 6.0<br />
1 From Domino Designer, click Tools > Add Tool. The Add Tool dialog box displays.
2 Follow the Domino Designer instructions for creating custom tools.<br />
Lotus Domino Integration<br />
In the Tool Name field, specify a text description to identify the menu item, for<br />
example, <strong>Implementer</strong> Check Out.<br />
In the Tool Action field, enable Run program.<br />
In the Tool Action text box, type the HTTP address location to access the<br />
<strong>Implementer</strong> Web function, for example:<br />
address for Web check out:<br />
http://system_name/cgi-bin/imweb?cmd=chkout<br />
address for Web reject:<br />
http://system_name/cgi-bin/imweb?cmd=reject<br />
address for Web promotion:<br />
http://system_name/cgi-bin/imweb?cmd=crtrqs<br />
From the Tool Context list, click the options that control when the tool is available.<br />
3 Click OK to create the tool and add the tool to the Tools menu.<br />
4 Repeat steps 1–3 for each <strong>Implementer</strong> Web function: check out, reject, and promotion.<br />
Once you complete this task, the <strong>Implementer</strong> Web functions are accessible from the<br />
Tools menu as illustrated next.<br />
341
Chapter 6: Third Party Integrations<br />
342<br />
To add SmartIcons to Domino Designer 5.0<br />
1 From Domino Designer, click File > Preferences > SmartIcon Settings.<br />
2 Follow the Domino Designer instructions for adding SmartIcons.<br />
Add an icon for each <strong>Implementer</strong> Web function: check out, reject, and create request.<br />
For each icon, specify the @URLOpen formula statement that starts the each respective<br />
program, for example:
formula for Web check out:<br />
@URLOpen ("http://system_name/cgi-bin/imweb?cmd=chkout")<br />
formula for Web reject:<br />
@URLOpen ("http://system_name/cgi-bin/imweb?cmd=reject")<br />
formula for Web promotion:<br />
@URLOpen ("http://system_name/cgi-bin/imweb?cmd=crtrqs")<br />
Lotus Domino Integration<br />
where, system_name/cgi-bin defines the iSeries host name (virtual location the iSeries<br />
server maps to) and imweb?cmd=(value) defines the <strong>Implementer</strong> program to run.<br />
To add an icon for <strong>MKS</strong> Integrity, define the URL by specifying the installation location<br />
of <strong>MKS</strong> Integrity. This may be a file location on your desktop, or a server name and IP<br />
address if located on another server, for example:<br />
or<br />
@URLOpen ("http://server_name:7001")<br />
D:/Program Files/<strong>MKS</strong>/Integrity Client/bin/<strong>MKS</strong> Integrity.exe<br />
Once added, the icons display on the Domino Designer toolbar.<br />
Managing the Domino Access Control List<br />
A Domino Access Control List (ACL) is a collection of entries in a table that define which<br />
access rights a user has to the database.<br />
343
Chapter 6: Third Party Integrations<br />
344<br />
Every database has an ACL that specifies the level of access that users and servers have to the<br />
database. Although the names of access levels are the same for users and servers, those<br />
assigned to users determine the tasks that users can perform in a database, while those<br />
assigned to servers determine what information within the database the servers can replicate.<br />
The ACL allows a manager to control user access by requiring authentication of the user’s<br />
identity or membership in a predefined group. Access is then granted according to the<br />
assigned rights.<br />
For each user, server, or group in an ACL you can specify:<br />
Access levels that control which tasks a user can perform in a database, or control what<br />
information within a database a server can replicate.<br />
Access level privileges that enhance or restrict the access level assigned to each name in the<br />
ACL.<br />
User types that identify whether a name in the ACL is for a person, server, or group.<br />
User types provide additional security for a database.<br />
Roles that allow a database designer to define a subset of users, servers, or both to<br />
provide controlled access to database design elements, or to some database functions.<br />
The <strong>MKS</strong> <strong>Implementer</strong> Adapter for Lotus Domino supports the management of Domino<br />
database ACLs by allowing you to set the ACL at various stages in the development cycle.<br />
The following setup tasks assume the <strong>Implementer</strong> environments used for the Lotus Domino<br />
integration exist. For more information, see “<strong>Implementer</strong> Setup and Configuration” on<br />
page 339. In addition, this feature requires:<br />
authorizing a user profile to the IFS directories<br />
defining the ACL directives<br />
creating a special command that sets the ACL<br />
Defining QNOTES Authority to IFS Directories<br />
The user profile QNOTES must have authority to all IFS files and directories in the<br />
environment paths of the *PRD, *TST, and *QAC environments. This is established in<br />
<strong>Implementer</strong> by defining the user profile value QNOTES as the directory path owner and IFS<br />
file owner for native IFS directories.<br />
To authorize user profile QNOTES to the IFS directories<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Environments, and press ENTER. The Work<br />
with Environments panel displays.<br />
2 Select the environment with option 20=Directory setup and press ENTER. The Work with<br />
Environments - Directory Setup panel displays.<br />
In the Directory path owner field, type QNOTES.
In the IFS file owner field, type QNOTES.<br />
3 Press ENTER.<br />
Lotus Domino Integration<br />
4 Repeat these steps for each *PRD, *TST, and *QAC environment defined for this feature.<br />
Defining ACL Directives<br />
You define the ACL directives as a series of commands, either in a source physical file<br />
(maintainable with SEU) or in the <strong>Implementer</strong> promotion request comments. You should<br />
use a source physical file when the directives are static or unchanging and apply to one or<br />
more Notes databases in an environment. This recommended method provides maximum<br />
control when assigning ACL access rights. For examples of this method, see page 346.<br />
When the directives are more dynamic and varying in nature, you can use the <strong>Implementer</strong><br />
promotion request comments; however, this method renders less control due to its free-form<br />
structure.<br />
For setting an ACL in check out, you must define the directives in a source physical file<br />
member. The format of the directives is as follows:<br />
where:<br />
**STRDOMACL<br />
addrole <br />
removerole <br />
removeallrole<br />
addacl :::<br />
removeacl <br />
removeallacl<br />
**ENDDOMACL<br />
NOTE The **STRDOMACL and **ENDDOMACL markers are only used when the ACL<br />
directives are embedded in the promotion request comments.<br />
Value Description<br />
Domino access identifier the ACL applies to.<br />
= Domino access identifier type being set. Valid values are mixedgroup, person,<br />
persongroup, server, servergroup, and unspecified. This value is validated.<br />
Access level to grant. Valid values are noaccess, depositor, reader, author, editor,<br />
designer, and manager. This value is validated.<br />
Comma-delimited list of roles to assign to the ACL entry. If the role does not exist<br />
for the ACL it is added automatically.<br />
345
Chapter 6: Third Party Integrations<br />
346<br />
Example ACL Directive<br />
removeallacl<br />
removeallrole<br />
addrole user<br />
addrole developer<br />
addacl findept:persongroup:reader:developer,user<br />
addacl misdept:persongroup:noaccess:developer<br />
addacl vpfinance:person:manager:user<br />
Defining Special Commands<br />
The following <strong>Implementer</strong> special commands allow you to set the Domino ACL:<br />
Set Domino ACL (ISETDOMACL) command<br />
Execute Checkout (IEXCCKOCMD) command<br />
Execute Request Detail (IEXCRQSDTL) command<br />
The ISETDOMACL command establishes and maintains an ACL for a specified Domino<br />
database file. The ISETDOMACL command is described in detail in this section.<br />
The IEXCCKOCMD and IEXCRQSDTL commands are command processors. Independent of<br />
one anther, they allow you to distinguish certain items during check out and promotion<br />
(respectively) for additional special command processing. The IEXCCKOCMD and<br />
IEXCRQSDTL commands actually condition the processing of any command you specify.<br />
Based on criteria you define for the special command, the selected items checked out or<br />
promoted are identified, and the commands you specify execute for the objects that meet the<br />
conditional criteria.<br />
You use the ISETDOMACL command in conjunction with either the IEXCCKOCMD<br />
command or the IEXCRQSDTL command. Together, they allow for setting a Domino ACL at<br />
your choice of two stages in the development cycle: check out or promotion. This architecture<br />
eliminates potential mis-use of the command by only allowing the command processing, and<br />
thus, controlled ACL management, within the specified job stream.<br />
The IEXCCKOCMD and IEXCRQSDTL commands are explained at a high level in this<br />
section as they pertain to ACL management with the ISETDOMACL command. Command<br />
examples are included. For details on special command processors and valid substitution<br />
variables, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
To define a special command to set an ACL<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Environments, and press ENTER. The Work<br />
with Environments panel displays.<br />
2 Select the appropriate environment with option 19=Special commands, and press<br />
ENTER. The Work with Environments Special Commands panel displays.<br />
3 Press F6=Create.
Lotus Domino Integration<br />
4 Complete this panel based on your requirements. The ISETDOMACL command syntax<br />
and command parameters are described next. For a description of the fields on this<br />
panel, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
5 When you have finished, press ENTER to create the special command.<br />
6 Repeat these steps for each applicable environment.<br />
ISETDOMACL Command Syntax<br />
ISETDOMACL DB(NAME)<br />
ACLDIR(*FILE or *COMMENT)<br />
ACLFILE(FILE_NAME)<br />
ACLMBR(MEMBER_NAME)<br />
RQSNBR(<strong>Implementer</strong> request number)<br />
ISETDOMACL Command Parameters<br />
Database (DB)<br />
Specify the name of the Domino database to process.<br />
ACL directive source (ACLDIR)<br />
Specify where to retrieve the ACL control directives.<br />
*FILE Sets the ACL in check out or promotion. Retrieves the ACL control<br />
directives from an existing source physical file. You must also qualify<br />
the ACLFILE, Library, and ACLMBR parameters.<br />
*COMMENT Sets the ACL during promotion. Retrieves the ACL control directives<br />
from the promotion request comments you define when creating the<br />
promotion request. You must also qualify the RSQNBR parameter.<br />
ACL directive source file (ACLFILE)<br />
If you specified *FILE for the ACL directive source (ACLDIR) parameter, specify the name of<br />
the file to read the ACL directives from.<br />
Library<br />
If you specified an ACL directive source file name, specify the name of the library associated<br />
with the file referenced.<br />
347
Chapter 6: Third Party Integrations<br />
348<br />
Member (ACLMBR)<br />
If you specified an ACL directive source file name, specify the file member to read.<br />
IMPORTANT Due to OS/400 limitations, the short member name generated by<br />
<strong>Implementer</strong> is not a valid ACLMBR name due to the tilde (~) character. Thus, if you<br />
are using the #SHORTNM substitution variable for the ACLMBR parameter in a<br />
special command in check out or promotion, each tilde character in the substituted<br />
value automatically translates to the number sign (#) character.<br />
For example, you specify the long file name databasefile.nsf, <strong>Implementer</strong><br />
generates the name database~1, and creates the directive source member name<br />
database#1.<br />
Request number (RQSNBR)<br />
If you specified *COMMENT in the ACL directive source (ACLDIR) parameter, specify the<br />
<strong>Implementer</strong> request number that contains the request comments.<br />
Setting ACLs in Check Out<br />
The IEXCCKOCMD and ISETDOMACL commands are used together to set a Domino ACL<br />
for development use when checking out to a *TST environment. After defining the<br />
ISETDOMACL command within the IEXCCKOCMD command as an environment level<br />
special command for the target environment, the command processes for all appropriate<br />
objects checked out to the environment. If a special command fails during check out, the<br />
process halts and the error displays. After correcting the problem you can retry the check out.<br />
This method requires defining the ACL directives in an existing source physical file.<br />
NOTE<br />
When defining the IEXCCKOCMD command to run the ISETDOMACL<br />
command, to avoid possible errors in the browser if an object does not exist in the<br />
target directory, set the ACTION parameter value to *CHANGE (rather than<br />
*CREATE). This issues the command for only items that are checked out for<br />
change.<br />
The ISETDOMACL command is applicable for setting an ACL on the iSeries<br />
server; however, do no use it in check out if the development (*TST) environment<br />
is on a local PC, for example, \QNTC\DEVDEMO\HOME\TST1.<br />
IEXCCKOCMD and ISETDOMACL Example<br />
In the following example, the special command is set to run after a successful check out.
Lotus Domino Integration<br />
The IEXCCKOCMD command is defined to process the ISETDOMACL command for all<br />
NSF objects checked out for change to the LOTUS_TST environment.<br />
Within the ISETDOMACL command, the substitution variable #PATHOBJ ensures the<br />
specified ACL processing occurs in the directory of the target environment.<br />
The ACL directives are defined in a source file, which you define by the use of<br />
ACLDIR(*FILE).<br />
Setting ACLs in Promotion<br />
The IEXCRQSDTL and ISETDOMACL commands are used together to set a Domino ACL in<br />
a target environment during promotion. After defining the ISETDOMACL command within<br />
the IEXCRQSDTL command as an environment-level special command for the target<br />
environment, the command processes for all appropriate objects on the promotion request.<br />
With this method, you have the option to place the ACL directives in either an existing source<br />
physical file or the <strong>Implementer</strong> promotion request comments. When setting a standard<br />
ACL, <strong>MKS</strong> recommends you retrieve the ACL directives from a source physical file. When<br />
setting a specific ACL for a specific database, <strong>MKS</strong> recommends you retrieve the directives<br />
from the promotion request comments.<br />
IEXCRQSDTL and ISETDOMACL Examples<br />
In the following example, the special command is set to run before the move occurs.<br />
349
Chapter 6: Third Party Integrations<br />
350<br />
The IEXCRQSDTL command is defined to process the ISETDOMACL command for all<br />
NSF objects on a promotion request.<br />
Within the ISETDOMACL command, note the use of #FRMDIR/#OBJECT instead of<br />
#PATHOBJ. This ensures the specified ACL processing occurs in the work library rather<br />
than the target directory—if for any reason the ACL manipulation fails or the promotion<br />
fails, the production database is not effected.<br />
The ACL directives are defined in the request comments, which you set by the use of<br />
ACLDIR(*COMMENT).<br />
The following are additional examples of using the IEXCRQSDTL command to process the<br />
ISETDOMACL command in promotion.<br />
This example sets an ACL for a database from a file named ACLMASTER in the<br />
<strong>MKS</strong>IMUSR library, using a member name based on the short object code (derived by<br />
<strong>Implementer</strong>). This allows you to specify the ACL on a database basis.<br />
ISETDOMACL DB('#FRMDIR/#OBJECT')<br />
ACLDIR(*FILE)<br />
ACLFILE(<strong>MKS</strong>IMUSR/ACLMASTER)<br />
ACLMBR('#SHORTNM')<br />
NOTE Due to OS/400 limitations, if the #SHORTNM substitution variable for the<br />
ACLMBR parameter contains any tilde characters, the substituted value<br />
automatically translates to the number sign (#) character. For details, see<br />
“MEMBER” in “ISETDOMACL Command Parameters” on page 347.
Lotus Domino Integration<br />
This example sets an ACL the same for all databases promoted in the environment.<br />
ISETDOMACL DB('#FRMDIR/#OBJECT')<br />
ACLDIR(*FILE)<br />
ACLFILE(<strong>MKS</strong>IMUSR/ACLMASTER)<br />
ACLMBR('ACLMASTER')<br />
This example sets an ACL based on the target environment. The ACL is specified by<br />
creating a member in file <strong>MKS</strong>IMUSR/ACLMASTER using the target environment<br />
name as the member name.<br />
ISETDOMACL DB('#FRMDIR/#OBJECT')<br />
ACLDIR(*FILE)<br />
ACLFILE(<strong>MKS</strong>IMUSR/ACLMASTER)<br />
ACLMBR('#TRGENV')<br />
Database and Template Signing<br />
<strong>Implementer</strong> provides the ability to sign Domino databases (NSF) and template files (NTF)<br />
during promotion to QA and production environments. The signed databases and templates<br />
can be promoted to one or more host and remote iSeries systems. If signing fails for any<br />
reason, the promotion request is set to a move fail status, and messages related to the failure<br />
are sent to the iSeries job log.<br />
Key Considerations<br />
This feature requires Lotus Domino 6.0 or later running on the iSeries.<br />
Setup of this feature in Domino requires the assistance of a Domino database<br />
administrator who is familiar with how Lotus Domino is configured in your shop.<br />
All signing is performed by a single Domino agent application running in a Domino<br />
Web server.<br />
Signing is performed on the source system prior to moving the database and template to<br />
the target system/environment.<br />
The user that performs signing must be either the administrator or full administrator<br />
and have manager rights to the database being signed.<br />
Each user who has rights to sign databases for the target system must be set up in<br />
<strong>Implementer</strong> on the source system.<br />
Lotus Domino Setup<br />
The setup tasks in Lotus Domino require a database administrator to do the following:<br />
351
Chapter 6: Third Party Integrations<br />
352<br />
Install the <strong>MKS</strong>Utility.nsf database (provided with <strong>Implementer</strong>) into the Domino<br />
Server directory of your choice (based on your Lotus Domino configuration). This is the<br />
Domino agent signing application.<br />
The utility database installs into the standard root IFS space on your iSeries when you<br />
install or upgrade <strong>Implementer</strong>. The default installation location is:<br />
/<strong>MKS</strong>/<strong>Implementer</strong>/product_library/Domino/<strong>MKS</strong>Utility.nsf<br />
Ensure the <strong>MKS</strong>Utility.nsf database is signed by a user that has privileges to Run<br />
Unrestricted Methods and Operations on the server where database signing occurs.<br />
Apply any necessary ACLs to the database as needed.<br />
CAUTION Future upgrades of <strong>Implementer</strong> require you recopy the database, re-sign<br />
the database, and re-apply any other changes, for example, ACLs.<br />
Configure the Domino Server to have the Domino Web Engine use Session<br />
Authentication with either Single Server or Multiple Servers.<br />
<strong>Implementer</strong> Setup<br />
The setup tasks in <strong>Implementer</strong> include the following:<br />
Define the Domino server URL and Domino users in <strong>Implementer</strong>.<br />
Define a special command for each Lotus Domino environment that manages the<br />
databases and templates to be signed. Define the ISGNDOMDB command within the<br />
<strong>Implementer</strong> special command processor IEXCRQSDTL at the environment level, to run<br />
for any promotion action except the delete action.<br />
To define the Domino Server URL and Domino users<br />
NOTE This task requires an <strong>Implementer</strong> user profile that has authority to maintain<br />
System Control Maintenance.<br />
1 From the <strong>Implementer</strong> Menu, type 45, System Control Maintenance, and press ENTER.<br />
2 Press PAGE DOWN twice to access the third System Control Maintenance panel.
Lotus Domino Integration<br />
3 In the Domino server URL field, specify the Lotus Domino server URL location that<br />
points to the Domino database signing application <strong>MKS</strong>Utility.nsf.<br />
This must be a valid URL that includes any subdirectories necessary to find the<br />
<strong>Implementer</strong> utility database <strong>MKS</strong>Utility.nsf, for example,<br />
http://servername.domain:port/subdir.<br />
4 Press F13=Domino Credentials to display the Work with Domino Users panel.<br />
5 Press F6=Add.<br />
6 In the Domino user-id field, specify the Domino user ID that has authority to sign<br />
databases and templates.<br />
7 In the Password field, specify the corresponding password for the Domino user ID. (The<br />
password does not display on this panel.)<br />
8 Press ENTER to return to the Work with Domino Users panel. Continue adding Domino<br />
users, or press F3=Exit.<br />
To define the special command<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Work with Environments, and press<br />
ENTER.<br />
2 Select the Lotus Domino environment with option 19=Special Commands, and press<br />
ENTER. The Work with Environment Special Commands panel displays.<br />
3 Press F6=Create. The Expanded Command Display panel displays.<br />
4 In the For Action field, type 4=Move. (Valid to run only on the host system.)<br />
5 In the When to do field, type 1=Before.<br />
353
Chapter 6: Third Party Integrations<br />
354<br />
6 In the Sequence number field, specify when to issue the command in relation to any<br />
other special commands defined for the environment.<br />
7 In the Command field, type IEXCRQSDTL and press F4=Prompt.<br />
8 Complete the remaining field parameters as described in the next section. For details on<br />
the IEXCRQSDTL special command and special command processing, see the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
9 Press ENTER to add the command.<br />
10 Repeat these steps for each applicable environment and object code as needed.<br />
Sign Domino Database (ISGNDOMDB) Command Parameters<br />
Domino database (DB)<br />
Specify the name of the database to sign. Enclose the value in quotes as illustrated in<br />
“ISGNDOMD Command Syntax”.<br />
Domino userid (USER)<br />
Specify the Domino user ID that has a authority to sign the database.<br />
ISGNDOMD Command Syntax<br />
ISGNDOMDB DB('database_name') USER(authorized_user_ID)<br />
Example of IEXCRQSDTL and ISGNDOMDB Command<br />
IEXCRQSDTL OBJCODE(.NSF)<br />
NAME(*ALL)<br />
ACTION(*CHANGE)<br />
RQSNBR(#RQSNBR)<br />
TARGET(#TRGENV)<br />
COMMAND(ISGNDOMDB DB('#FRMDIR/#OBJECT') USER('user_ID')<br />
PathFinder Integration<br />
TIP If the environment manages only .NSF and .NTF objects codes, you can specify<br />
OBJCODE (*ALL) to allow signing both object types with one special command.<br />
<strong>Implementer</strong> interfaces with PathFinder, a documentation utility product from Hawkeye<br />
Systems, Inc. <strong>Implementer</strong> works with PathFinder Versions 5.1 or later.<br />
<strong>Implementer</strong> supports all cross-environment related objects defined within the primary<br />
Hawkeye database library. <strong>Implementer</strong> uses PathFinder information for related object<br />
processing during check out and create request.
PeopleSoft World Integration<br />
Before using PathFinder information with <strong>Implementer</strong>, in Work with Environments you<br />
must define each environment that PathFinder documents. In addition, you must run the<br />
PathFinder “Build Object Cross Reference” for each library defined within the environments.<br />
For more information on this function, see the PathFinder User Manual and online help.<br />
Once PathFinder is enabled, related object information is available in check out to help<br />
determine the members/objects impacted by a planned change. When items are checked<br />
back into the environments documented by PathFinder, you can specify to add related<br />
objects to the request. This analysis is done using the information previously loaded into<br />
PathFinder.<br />
NOTE Hawkeye does not currently support cross-environment related object<br />
processing for objects that exist in *QAC environments.<br />
To define Pathfinder for an environment<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Environments, and press ENTER. The Work<br />
with Environments panel displays.<br />
2 Select the environment with option 2=Change and press ENTER.<br />
3 Press PAGE DOWN to access the second panel.<br />
4 In the Maintain related obj info field, type Y.<br />
5 In the Source of information field, type 2 for PathFinder.<br />
IMPORTANT PathFinder does not currently support ILE programs in the Real Time<br />
X-Ref Update (REALUPD) command. However, <strong>Implementer</strong> allows you to bypass<br />
the attempted real time update for these objects to prevent errors on promotions.<br />
Data area IMBNDUPD in the <strong>Implementer</strong> product library is shipped with a value<br />
of N to bypass the update. Once you receive a version of PathFinder that supports<br />
ILE programs, change the value of this data area to Y. When the data area is set to N,<br />
<strong>Implementer</strong> does not update the PathFinder database for ILE programs; thus, run<br />
normal PathFinder updates regularly to keep your data current.<br />
PeopleSoft World Integration<br />
The <strong>Implementer</strong> Adapter for PeopleSoft World (formerly J.D. Edwards) manages PeopleSoft<br />
World applications. The interface is available by purchasing and installing the separately<br />
licensed <strong>Implementer</strong> Adapter for PeopleSoft World software. The integration requires a<br />
specific license key for activation.<br />
355
Chapter 6: Third Party Integrations<br />
356<br />
<strong>Implementer</strong> supports the management of PeopleSoft World soft coding items such as User<br />
Defined Code, DreamWriters, Member Master, Data Dictionary, Vocabulary Override,<br />
WorldWriter, FASTR, and Processing Option. <strong>Implementer</strong> also manages PeopleSoft World<br />
traditional objects, such as RPG and CLP, and includes updating the Software Version<br />
Repository (SVR).<br />
<strong>Implementer</strong> provides object codes specifically for checking out and promoting PeopleSoft<br />
World soft coding items to and from PeopleSoft World special environments. The check out<br />
function locks the name of the PeopleSoft World soft coding item, allowing you to develop<br />
and promote PeopleSoft World items in a controlled method. Distribution of PeopleSoft<br />
World soft coding items to remote locations is supported. <strong>Implementer</strong>’s reports and<br />
inquiries track the PeopleSoft World items it manages.<br />
This release of <strong>Implementer</strong> provides support for any PeopleSoft World 8.X version. After<br />
following the initial instructions in the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>, perform the<br />
following tasks to configure the host system.<br />
Configuring the Interface<br />
The interface objects are shipped in the <strong>Implementer</strong> product library in save file IMJDESAVF.<br />
You must restore the save file to the PeopleSoft World interface library IMJDE. This library is<br />
referred to as IMJDE or the interface library throughout this chapter.<br />
The setup instructions assume both <strong>Implementer</strong> and PeopleSoft World are installed on the<br />
system. The additional set up activities include the following:<br />
Restore the interface save file objects.<br />
Apply license keys.<br />
Define the MWIJOBD job description.<br />
Enable PeopleSoft World support in <strong>Implementer</strong>.<br />
Set up environments to handle PeopleSoft World soft coding items and associate each<br />
environment with the common library where PeopleSoft World applications are located.<br />
Set up archiving.<br />
Activate object codes.<br />
Set up environment groups (optional).<br />
Configure remote systems, if applicable.<br />
IMPORTANT To manage PeopleSoft World soft coding items, you must add the PeopleSoft<br />
World product libraries JDFSRC, JDFDATA, and JDFOBC to your interactive library list.<br />
For more information, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.
To restore the interface save file objects<br />
PeopleSoft World Integration<br />
After installing <strong>Implementer</strong>, sign on to the system as the security officer and issue the<br />
following command:<br />
RSTOBJ OBJ(*ALL)<br />
SAVLIB(DSSII)<br />
DEV(*SAVF)<br />
SAVF(<strong>MKS</strong>IM/IMJDESAVF)<br />
RSTLIB(IMJDE)<br />
IMPORTANT The IMJDE library must be on the system prior to restoring the save file<br />
objects. If it does not exist, use the Create Library (CRTLIB) command to create it,<br />
and then issue the Restore Object (RSTOBJ) command as indicated.<br />
To apply the security codes for the host system<br />
1 Add the <strong>Implementer</strong> PeopleSoft World interface library to your library list by issuing<br />
the following command:<br />
ADDLIBLE (IMJDE)<br />
2 Type the RESETCOD command, and press F4 to prompt. The Reset Security Codes panel<br />
displays.<br />
In the <strong>Implementer</strong> library field, type the interface library name, IMJDE.<br />
In the next four fields (Security Code #1 through Security Code #4) specify the<br />
security codes for up to four iSeries systems. Type each code (provided with the<br />
product media) in the appropriate field.<br />
3 Press ENTER.<br />
To define the MWIJOBD job description<br />
Verify the following libraries exist in the MWIJOBD library list:<br />
<strong>Implementer</strong> PeopleSoft World Interface library (IMJDE).<br />
PeopleSoft World product libraries (JDFDATA and JDFOBJ).<br />
IMPORTANT Your interactive library list must have the IMJDE library above the<br />
PeopleSoft World product libraries.<br />
To enable PeopleSoft World support in <strong>Implementer</strong><br />
In System Control Maintenance, set the PeopleSoft installed field to Y.<br />
357
Chapter 6: Third Party Integrations<br />
Environment Setup<br />
358<br />
Once you define environments for PeopleSoft World integration, any new object codes you<br />
create support the PeopleSoft World compiles. The environments include both PeopleSoft<br />
World object codes (that call the PeopleSoft World compiler) and standard object codes (that<br />
call the OS/400 compiler). You can optionally deactivate the standard object codes if they are<br />
not used. For details, see “Deactivating Standard Object Codes” on page 361.<br />
NOTE If you create an environment group for PeopleSoft World soft coding items,<br />
the primary environment must be a PeopleSoft World environment.<br />
To set up PeopleSoft World special environments<br />
1 Set up standard environments to manage PeopleSoft World applications.<br />
2 To associate the standard environment with a PeopleSoft World common library, use<br />
option 16 in the Work with Environments panel. Once the existing environment is<br />
associated with a PeopleSoft World common library, it becomes a special PeopleSoft<br />
World special environment. The common library name you specify must exist<br />
(<strong>Implementer</strong> does not create a common library).<br />
To identify this as a special environment, PeopleSoft displays in the Special<br />
Environment field on the second detailed Change Environment panel. If you remove the<br />
common library name, the environment type reverts to Standard.<br />
3 From the Change Environment panel, press F13=Library List to change the compile<br />
library list in the environment definition to include the following libraries:<br />
<strong>Implementer</strong> PeopleSoft World Interface library (IMJDE).<br />
PeopleSoft World product libraries (JDFSRC, JDFDATA, and JDFOBJ).<br />
IMPORTANT Your interactive library list must have library IMJDE above the<br />
PeopleSoft World product libraries. The PeopleSoft World common library does not<br />
need to be on the environment library list; when it is defined on the PeopleSoft<br />
World setup panel, <strong>Implementer</strong> adds it when needed.<br />
Setting Up for Archiving Soft Coding Items<br />
You can archive PeopleSoft World soft coding items such as DreamWriters and Data<br />
Dictionaries into an archive common library you specify for the environment. <strong>Implementer</strong><br />
also supports selective rollback of the archived soft coding items.<br />
An archive environment must be a PeopleSoft World special environment that has an<br />
associated archive common library.
To set up for archiving<br />
PeopleSoft World Integration<br />
1 From the <strong>Implementer</strong> Menu, type 42, Environments, and press ENTER. The Work with<br />
Environments panel displays.<br />
2 Select the environment to set up with option 16=PeopleSoft, and press ENTER. The<br />
Change Environment panel displays.<br />
3 In the PeopleSoft archive library field, specify a valid archive library name for archiving<br />
the soft coding items. The library should be the same name as the <strong>Implementer</strong> archive<br />
library assigned to the environment.<br />
4 Press ENTER to save the entry.<br />
5 Press F12 to return to the Work with Environments panel.<br />
6 Type option 2=Change and press ENTER. The Change Environment panel displays.<br />
7 Specify a value in the Source library field. In the Archive Versions field, specify the<br />
number of archive versions to retain for PeopleSoft World soft coding items. These fields<br />
establish the archiving of PeopleSoft World soft coding items.<br />
8 Press ENTER.<br />
Object Codes for Soft Coding Items<br />
Use the following object codes and matching special characteristics delivered with<br />
<strong>Implementer</strong> to manage PeopleSoft World soft coding items. You must first activate the<br />
object codes (in Work with Object Codes) for all applicable environments.<br />
NOTE For information on activating and deactivating object codes, see “Object<br />
Codes” on page 127.<br />
If needed you can override the common library for all PeopleSoft World soft coding items.<br />
On the object code overrides panel, select the PeopleSoft World environment with option<br />
2=Change, and press F8=Object Codes.<br />
Object Code Description<br />
JDEUDE User Defined Code (UDC).<br />
JDEUDS User Defined Code tables, to set up or change update authorization for specific<br />
users, PeopleSoft World user class/group, or *PUBLIC. Allows you to control<br />
which users are authorized to change certain UDC tables.<br />
JDEDWR DreamWriters.<br />
JDEMBM Member Masters.<br />
JDEDDC Data Dictionaries.<br />
359
Chapter 6: Third Party Integrations<br />
Object Codes for Traditional Objects<br />
360<br />
Object Code Description<br />
JDEVOV Vocabulary overrides.<br />
JDEMNU Menus.<br />
JDEWWR WorldWriters.<br />
JDEFST FASTR.<br />
JDEPRO Processing Options.<br />
JDEWCS World Case.<br />
JDNSPC For traditional objects (like RPG, CLP), required to update the Software Version<br />
Repository in PeopleSoft World for traditional objects.<br />
Use the following object codes delivered with <strong>Implementer</strong> to manage PeopleSoft World<br />
traditional objects. You must first activate the object codes (in Work with Object Codes) for all<br />
applicable environments.<br />
Object Code/ Description<br />
JDEDSPF Display file.<br />
JDEPF Physical file.<br />
JDELF Logical file.<br />
JDECLP CL program.<br />
JDERPG RPG program.<br />
JDEPRTF Generates printer file overrides during promotion (valid for local compiles only).<br />
With the exception of the JDEPRTF object code, each object code has the special characteristic<br />
JDNSPN. The JDEPRTF object code has the special characteristic JDNPRTF, which adopts the<br />
same functionality as the JDNSPC special characteristic. All traditional objects managed by<br />
<strong>Implementer</strong> with these object codes/special characteristics update the Software Version<br />
Repository (SVR) in PeopleSoft World during check out and promotion. The objects must<br />
exist as member IDs in the SVR file. When working with a new object, you must first create<br />
the member ID in the SVR file to enable <strong>Implementer</strong> updates.<br />
IMPORTANT Only one copy of JDE files F9801 and F9802 can exist across your<br />
environments. In other words, the production, QA, and development environments<br />
share these two files; multiple copies of these files cause incorrect SVR updates.
Deactivating Standard Object Codes<br />
PeopleSoft World Integration<br />
You can deactivate any standard object codes not needed for PeopleSoft World special<br />
environments.<br />
To deactivate standard object codes for PeopleSoft World environments<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Environments, and press ENTER.<br />
2 In the Opt field, type 2=Change, and press ENTER. The Change Environment panel<br />
displays.<br />
3 Press F8=Object Codes. The Change Environment Object Code Overrides panel displays.<br />
4 In the Act Flg field, type N next to each object code to deactivate in the environment.<br />
5 Press ENTER to save the changes.<br />
Installing the Interface on Remote Systems<br />
<strong>Implementer</strong> supports the distribution of PeopleSoft World soft coding items such as User<br />
Defined Code, DreamWriters, and Member Masters to remote systems. This section pertains<br />
to sending PeopleSoft World soft coding items to remote systems using the <strong>Implementer</strong><br />
Receiver.<br />
The interface objects are shipped with <strong>Implementer</strong> in save file IMJDESAVF, which is<br />
automatically installed when you install the <strong>Implementer</strong> Receiver. You must restore the<br />
save file to the <strong>Implementer</strong> Receiver product library, <strong>MKS</strong>IR. After installing the<br />
<strong>Implementer</strong> Receiver, perform the following tasks to configure the remote system.<br />
To restore interface save file objects on a remote system<br />
1 Sign on to the remote system as the system security officer.<br />
2 Issue the following command:<br />
RSTOBJ OBJ(*ALL)<br />
SAVLIB(DSSII)<br />
DEV(*SAVF)<br />
SAVF(<strong>MKS</strong>IR/IMJDESAVF)<br />
RSTLIB(<strong>MKS</strong>IR)<br />
IMPORTANT On the <strong>Implementer</strong> Receiver, restore the interface objects into the<br />
<strong>Implementer</strong> Receiver library <strong>MKS</strong>IR. If you changed the name of the <strong>Implementer</strong><br />
Receiver library, replace <strong>MKS</strong>IR with the new name.<br />
Because any subsequent upgrades to the <strong>MKS</strong>IR library overwrite the restored save<br />
file objects, when upgrading the <strong>Implementer</strong> Receiver you must perform these<br />
tasks again to reinstall the interface objects.<br />
361
Chapter 6: Third Party Integrations<br />
362<br />
To apply security codes to the remote system<br />
1 Add the <strong>Implementer</strong> Receiver library to your library list by issuing the following<br />
command:<br />
ADDLIBLE <strong>MKS</strong>IR<br />
2 Type the RESETCOD command, and press F4 to prompt the command. The Reset Security<br />
Codes panel displays.<br />
In the Remote <strong>Implementer</strong> library field, specify the remote <strong>Implementer</strong> Receiver<br />
library name (<strong>MKS</strong>IR is the default library name).<br />
In the Security Code #1 through Security Code #4 fields, specify the security code<br />
(provided with the product media) for up to four iSeries systems.<br />
3 Press ENTER.<br />
4 To reset authority on the restored objects, ensure the <strong>Implementer</strong> libraries are on the<br />
library list, and issue the following command.<br />
IGRTAUT LIBNAM(<strong>MKS</strong>IR)OBJNAME(*ALL)<br />
Ignore any error messages after issuing this command.<br />
5 Change the library list in the job description of the communications entry to include the<br />
PeopleSoft World product libraries.<br />
IMPORTANT The job description must include the PeopleSoft World libraries to avoid<br />
the abnormal end of promotions with PeopleSoft World soft coding items.<br />
Ensure the user profile MWIPROD has data management authority to all files in all<br />
PeopleSoft World libraries on the host and remote systems. In addition, enroll<br />
MWIPROD as part of “GROUP” within PeopleSoft World.<br />
Powerhouse (Cognos) Integration<br />
Using <strong>Implementer</strong> with Powerhouse (Cognos) requires creating an object code for each of<br />
the Cognos creation commands: QTP, QUIZ, QUICK, and QDESIGN.<br />
To create the object codes<br />
1 From the <strong>Implementer</strong> Menu, type option 44, Object Codes, and press ENTER. The Work<br />
with Object Codes panel displays.<br />
2 Press F6=Add to display the Create Object Code panel.
3 Complete the fields using the values described in the following tables.<br />
Powerhouse (Cognos) Integration<br />
The examples illustrate each object code having the same name as the creation command<br />
it is created for. However, this is merely a suggestion; you can assign any object code<br />
name to the object code.<br />
4 When finished, press ENTER to save the information.<br />
QTP Object Code<br />
Field Value<br />
Object code/Description QTP (QTP Program (PowerHouse))<br />
Activity flag 1<br />
Object type *USRSPC<br />
Object attribute QTP<br />
Source member type QTP<br />
Default source file PHZTSRC<br />
Creation sequence 519<br />
Special characteristics COGPT<br />
Object authority *KEEP<br />
Creation process C<br />
Creation command QTP DICTIONARY(*LIBL/COGNOSSLS)<br />
AUTO(#SRCLIB/SRCFIL #OBJECT)<br />
QUIZ Object Code<br />
Field Value<br />
Object code/Description QUIZ (QUIZ program)<br />
Activity flag 1<br />
Object type *USRSPC<br />
Object attribute QUIZ<br />
Source member type QUIZ<br />
Default source file PHQZSRC<br />
Creation sequence 518<br />
Special characteristics COGPZ<br />
Object authority *KEEP<br />
Creation process C<br />
Creation command QUIZ DICTIONARY(*LIBL/COGNOSSLS)<br />
AUTO(#SRCLIB/#SRCFIL #OBJECT)<br />
363
Chapter 6: Third Party Integrations<br />
ROBOT Integration<br />
364<br />
Field Value<br />
QUICK Object Code<br />
Object code/Description QUICK (QUICK Program (PowerHouse))<br />
Activity flag 1<br />
Object type *USRSPC<br />
Object attribute QUICK<br />
Source member type QUICK<br />
Default source file PHQKSRC<br />
Creation sequence 517<br />
Special characteristics COGPK<br />
Object authority *KEEP<br />
Creation process C<br />
Creation command QUICK DICTIONARY(*LIBL/COGNOSSLS)<br />
AUTO(#SRCLIB/#SRCFIL #OBJECT)<br />
Field Value<br />
QDESIGN Object Code<br />
Object code QDESIGN (QDESIGN Program (PowerHouse))<br />
Activity flag 1<br />
Object type *USRSPC<br />
Object attribute QDESIGN<br />
Source member type QDESIGN<br />
Default source file PHQZSRC<br />
Creation sequence 520<br />
Special characteristics COGPZ<br />
Object authority *KEEP<br />
Creation process C<br />
Creation command QDESIGN DICTIONARY(*LIBL/COGNOSSLS)<br />
AUTO(#SRCLIB/#SRCFIL #OBJECT)<br />
<strong>Implementer</strong> supports using ROBOT for job scheduling. With this integration, you can<br />
identify one or more target environments for ROBOT to use when submitting promotion jobs<br />
such as compiles and moves. You can also use ROBOT for other <strong>Implementer</strong> jobs unrelated<br />
to promotions, such as submitting reports.
Setting Up Non Promotion Jobs<br />
WebSphere Development Studio Client for iSeries Integration<br />
The following task describes how to set up <strong>Implementer</strong> to use ROBOT for scheduling non<br />
promotion jobs.<br />
To enable ROBOT scheduling<br />
1 From the <strong>Implementer</strong> Menu, type option 45, System Control Maintenance, and press<br />
ENTER.<br />
2 Press PAGE DOWN to display the second panel.<br />
3 In the Submission method for non-promotion functions field, type 2. This enables the use<br />
of ROBOT for scheduling in place of standard OS/400 scheduling.<br />
4 Press ENTER to save the change.<br />
Setting Up Promotion Jobs<br />
The following task describes how to set up a target environment for job scheduling with<br />
ROBOT. For promotion requests that target multiple environments, the primary environment<br />
controls whether ROBOT is used.<br />
To setup target environments for ROBOT<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Environments, and press ENTER. The Work<br />
with Environments panel displays.<br />
2 Use option 13=Promotion scheduling to select an environment. The Change<br />
Environment panel displays.<br />
3 In the Job submitted by field, type 2 to specify ROBOT is used to schedule promotions to<br />
the selected environment.<br />
4 Press ENTER to process the update.<br />
WebSphere Development Studio Client for<br />
iSeries Integration<br />
The IBM WebSphere® Development Studio Client for iSeries (WDSc) plug-in for<br />
<strong>Implementer</strong> allows users to access <strong>Implementer</strong>’s version control functions from within<br />
<strong>Implementer</strong>-specific, context-sensitive menu options on the WDSc Remote System Explorer<br />
(RSE) menu.<br />
365
Chapter 6: Third Party Integrations<br />
Overview<br />
366<br />
This fully integrated solution provides support for your Integrated Development<br />
Environment (IDE) native and client/server software development targeted for an iSeries,<br />
allowing you to access the functionality of <strong>Implementer</strong> while working within IBM’s Eclipsebased<br />
technology in the following iSeries-focused offerings:<br />
WebSphere Development Studio Client for iSeries (includes WebSphere Studio Site<br />
Developer (WSSD)).<br />
WebSphere® Development Studio Client Advanced Edition for iSeries (includes<br />
WebSphere Studio Application Developer (WSAD)).<br />
For the purpose of this guide, both offerings are referenced as WDSc.<br />
The plug-in blends transparently into the IDE, allowing you to work within the framework of<br />
your existing <strong>Implementer</strong> software configuration management (SCM) structure. The<br />
integration additionally supports using <strong>MKS</strong> Integrity for issue management, and<br />
<strong>MKS</strong> Source for your PC-based development.<br />
NOTE The setup tasks related to this integration are typically performed by each<br />
developer (rather than an administrator) on individual clients; therefore, the setup<br />
tasks are described in the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong> rather than this guide.<br />
WDSc is an IBM development tool used for developing multiple types of applications for an<br />
iSeries. It is the iSeries offering of IBM’s Eclipse-based WebSphere Studio Workbench<br />
(WSW). It includes the full functionality of WebSphere Studio Site Developer Advanced<br />
(WSSDA) and additional major components specific to the iSeries.<br />
In WDSc, perspectives are used to manage the iSeries development. A perspective is a group of<br />
views that show various aspects of the resources on the workbench. A user can switch<br />
perspectives, depending on the current task, and customize the layout of the views and<br />
editors within each perspective.<br />
WDSc has three perspectives for iSeries development. This document describes the use of the<br />
iSeries Projects and Remote Systems Explorer (RSE) perspectives as they relate to using the<br />
fully integrated WDSc plug-in for <strong>Implementer</strong>.<br />
The following shows a graphical view of the plug-in from within the RSE perspective.
WebSphere Development Studio Client for iSeries Integration<br />
After performing an <strong>Implementer</strong> check out, the member is opened in the default LPEX editor<br />
for modification. Once the changes are complete, the member is ready for compiling and<br />
promotion—all from within WDSc.<br />
The types of users that benefit from using this integration include native iSeries developers<br />
who use RSE, and native iSeries developers who use iSeries Projects.<br />
To highlight some of the integration features, developers have:<br />
<strong>Implementer</strong>-specific, context-sensitive menu options on the Remote System Explorer<br />
menu in WDSc that provide direct access to the <strong>Implementer</strong> SCM functions of check<br />
out, reject, promotion, and processing. This includes access to the <strong>Implementer</strong> compile<br />
function from within WDSc, ensuring compiles retain all existing attributes like when<br />
run from the <strong>Implementer</strong> Workbench.<br />
Flexibility with process changes, where any SCM process can be performed on the<br />
<strong>Implementer</strong> Workbench or from within WDSc. Team members can use their interface of<br />
choice, regardless of which interface other team members use or which interface was<br />
used for a prior process. For example, you can check out through the <strong>Implementer</strong><br />
Workbench, and then edit and compile through WDSc.<br />
367
Chapter 6: Third Party Integrations<br />
368<br />
An <strong>Implementer</strong> properties page provides clear visibility to current member and object<br />
information for all items under the control of <strong>Implementer</strong>. For example, it shows the<br />
current status and environment, as well as the lock details for all active locks on a<br />
specific item.<br />
For diagnostic purposes, a log generates for all <strong>Implementer</strong> actions performed within<br />
WDSc. A preferences facility allows you to set the message logging level to record<br />
specific types of messages, for example, error messages, warning messages, or<br />
informational messages.<br />
For <strong>MKS</strong> Integrity customers, the integration supports tracking your iSeries<br />
development with issues, and further integrates with the <strong>MKS</strong> Integrity® Worktray<br />
Plug-in for Eclipse. The worktray plug-in allows a developer to view <strong>MKS</strong> Integrity<br />
issues, <strong>MKS</strong> Source change packages, and <strong>Implementer</strong> change packages without exiting<br />
from the WDSc environment.<br />
For <strong>MKS</strong> Source customers, <strong>MKS</strong> provides additional support for WDSc. <strong>MKS</strong>’s<br />
integration with WebSphere Studio Workbench (WSW) allows users to access<br />
<strong>MKS</strong> Source version control commands when using the WSSDa component of WDSc to<br />
perform Web and client/server development.<br />
For more information on WebSphere Studio Workbench, browse to:<br />
www.ibm.com/software/ad/workbench<br />
WDSc for iSeries Requirements<br />
IMPORTANT For additional information related to requirements and assumptions,<br />
see the Readme file included with the <strong>Implementer</strong> plug-in.<br />
To configure and use the <strong>Implementer</strong> and WDSc integration, in RSE you need to define<br />
a connection to the iSeries system where <strong>Implementer</strong> is installed. For more information<br />
on creating a new system connection or connecting to the system, refer to the<br />
appropriate WDSc documentation or online help.<br />
Install and configure WDSc 6 or WDSc 5 on each client. If using WDSc 5, <strong>MKS</strong><br />
recommends you use WDSc 5.1.2.<br />
You must install and configure any required client service packs.<br />
You must install and configure the required host components. For details browse to:<br />
http://www-306.ibm.com/software/awdtools/wdt400/sysreq/index.html<br />
OS/400 V5R1 or later is required on the iSeries that hosts <strong>Implementer</strong>. <strong>MKS</strong><br />
recommends you check with IBM for PTFs required for WDSc.
WebSphere Development Studio Client for iSeries Integration<br />
This guide assumes you know how to use WebSphere Studio Site Developer and<br />
WebSphere Development Studio Client for iSeries. For information on using either<br />
product, refer to the appropriate IBM product documentation or online help.<br />
<strong>Implementer</strong> Requirements<br />
Install and configure <strong>Implementer</strong> <strong>2006</strong>. For information on installing <strong>Implementer</strong>, see<br />
the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>.<br />
Install <strong>Implementer</strong> plug-in version 5.7.x or later for use with WDSc 6.<br />
<strong>Implementer</strong> also provides plug-in version 5.6.x for use with WDSc 5. Integration with<br />
the <strong>MKS</strong> Integrity worktray plug-in requires <strong>Implementer</strong> plug-in version 5.6.1 or later.<br />
For more information, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Each <strong>Implementer</strong> production environment used for check out or promotion must have<br />
a development path defined. The paths may have been set up when <strong>Implementer</strong> was<br />
initially configured, verify they exist. Environment paths are defined in <strong>Implementer</strong><br />
Menu option 42, Environments. For details, see “Environments” on page 81.<br />
To ensure check out occurs to a development library when using personal development<br />
libraries, any applicable environments must have *USRPRF as the development location<br />
in the environment path. For more information, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User<br />
<strong>Guide</strong>.<br />
Integration with <strong>MKS</strong> Integrity and the <strong>MKS</strong> Integrity® Worktray Plug-in for Eclipse<br />
requires installing and configuring <strong>MKS</strong> Integrity <strong>2006</strong> or later.<br />
369
Chapter 6: Third Party Integrations<br />
370
C HAPTER SEVEN<br />
Administrative Utilities<br />
Maintaining <strong>Implementer</strong><br />
7<br />
This chapter describes the various utilities and tools <strong>Implementer</strong> provides to assist<br />
you with setting up and maintaining <strong>Implementer</strong>.<br />
This chapter covers the following topics:<br />
“Submitting Job Overrides” on page 372<br />
“Resetting Authorities” on page 372<br />
“Purging Environment History” on page 374<br />
“Repository Maintenance” on page 376<br />
“Saving and Restoring Tape Archives” on page 379<br />
“Clearing Remote QA Environments” on page 384<br />
“User Capability Wizard” on page 385<br />
“Deleting Tutorial Information” on page 396<br />
“Function Key <strong>Administration</strong>” on page 397<br />
371
Chapter 7: Administrative Utilities<br />
Submitting Job Overrides<br />
372<br />
System Control Maintenance allows you to define a standard default job queue and library<br />
where all environment-related submitted jobs run. In Work with Environments, the<br />
F18=Submit Overrides function allows you to override the global defaults for the job queue<br />
and library. If you use the OS/400 job scheduler or ROBOT job scheduling, you can also<br />
schedule jobs to run for a specific date and time. The overrides remain in effect for any jobs<br />
submitted during the current session⎯in other words, until you exit from Work with<br />
Environments. This feature applies to submitting job overrides for promotion requests, as<br />
well as for the Build List, Reset Authorities, and Purge History functions.<br />
To submit job overrides<br />
1 From the Work with Environments panel, press F18=Submit Overrides. The Job<br />
Submission Overrides window displays.<br />
2 Complete the following fields as described.<br />
In the Job queue, Library, and Hold on job queue fields, specify the standard OS/400<br />
submit job parameters as required.<br />
In the Schedule date field, specify a date for the job to run. The default value is<br />
*CURRENT. You can change the value to any value valid for the Submit Job<br />
(SBMJOB) command.<br />
NOTE *MONTHSTR (start of the month) and *MONTHEND (end of the month) are<br />
not applicable when using ROBOT to submit promotion requests.<br />
In the Schedule time field, specify a time for the job to start. The default value is<br />
*CURRENT. You can change the value to any value valid for the Submit Job<br />
(SBMJOB) command. Specify Time Range fields in HH:MM:SS format.<br />
3 Press ENTER to process the overrides and return to the Work with Environments panel.<br />
Resetting Authorities<br />
Each environment has specific authorities as defined in Work with Environments. The<br />
Change Environment Object Authorities function allows you to define the user profiles that<br />
have authority to reference objects within the environment. The Reset Authorities function<br />
allows you to grant or revoke authorities for all objects in the libraries of any environment<br />
you have move capabilities for.<br />
The object ownership and authorities are reset based on how the authorities are defined for<br />
the environment. To ensure authorities reset for all objects, run the environment Build List<br />
prior to submitting the Reset Authorities.
Resetting Authorities<br />
Use this function for production environments when you initially set up <strong>Implementer</strong>, and<br />
when you need to:<br />
revoke all authorities from objects or libraries<br />
change owners of environment libraries<br />
change owners of all objects<br />
grant authorities for all objects<br />
<strong>Implementer</strong> sets authorities during promotion. If you need to change individual member/<br />
objects, in Create Request use option 2=Toggle Authority Method to toggle the authorities on<br />
specific members/objects from *KEEP (keeps the authority of the original object in the target<br />
environment) or *GRANT (grants authority based on the target environment).<br />
Key Considerations<br />
CAUTION If you set the environment authorities incorrectly, it could render the<br />
application software unusable by users due to insufficient authority to use the<br />
objects. Alternatively, it could also allow unauthorized access to the application and<br />
associated database files by granting too much authority.<br />
Use this function to establish the proper authorities for all objects within an<br />
environment, when authorities have changed in create request, or when you need to<br />
change them for a specific reason.<br />
You must have authority to host environment maintenance and move authority to reset<br />
authorities for a host environment. You must have authority to remote environment<br />
maintenance and move authority to reset authorities for a remote environment.<br />
Authority to host and remote environment maintenance is defined at the user level, in<br />
Work with Users. Move authority is defined at the environment level, in Work with<br />
Environments, User Capabilities.<br />
This job submits with the defaults defined in System Control. For information on<br />
overriding the job submission defaults, see “Submitting Job Overrides” on page 372.<br />
<strong>Implementer</strong> sets the authorities of IFS files within an environment’s directory the same<br />
as it sets the authorities on traditional objects and libraries. You must set the authorities<br />
when defining the environment.<br />
For new environments with no source library or source files, <strong>Implementer</strong> automatically<br />
creates the source library and source files during promotion, and sets the authorities<br />
based on the object authorities defined for the environment.<br />
373
Chapter 7: Administrative Utilities<br />
374<br />
When promoting to a Windows NT Server, IFS objects inherit the authorities of the<br />
target directory, regardless of authorities defined to the environment or existing on the<br />
from object. The object owner is user SDMAUTUSR (or the user profile defined to<br />
<strong>Implementer</strong> data area SDMAUTUSR). Unlike traditional objects, the object owner is not<br />
set by the Reset Authorities function.<br />
NOTE The Reset Authorities function does not change the authorities or owners of<br />
IFS objects in environments on a mounted drive.<br />
To reset authorities<br />
Common Questions<br />
1 From Work with Environments, select the environment with option 31, Reset<br />
Authorities, and press ENTER. A message displays confirming the action you are about to<br />
perform. (If you need to cancel without running the job, press F3=Exit or F12=Cancel.)<br />
2 Press F9=Submit to submit the reset authority job. The Work with Environments panel<br />
redisplays.<br />
What conditions warrant running Reset Authorities (other than when initially setting up the<br />
environment)?<br />
It may be necessary to run this function after initial setup if the libraries within the<br />
environments become corrupt external to <strong>Implementer</strong> use. You should restrict external<br />
access to the libraries you have under <strong>Implementer</strong>’s controlled.<br />
When is it necessary to rerun Reset Authorities and overwrite the authorities that exist?<br />
Use this function if users have either too much or not enough authority to an environment.<br />
Purging Environment History<br />
The Purge History function purges the <strong>Implementer</strong> database of completed promotion<br />
requests for a specific environment or globally for all environments. The function is available<br />
on both the host and remote system. On the host system, you can optionally purge lock status<br />
and history, object status history, and concurrent development activity.<br />
The function purges information from the <strong>Implementer</strong> database. It does not delete system<br />
objects or information. After purging, you can delete the environment if necessary.<br />
For details on deleting environments, see page 96.
Key Considerations<br />
Purging Environment History<br />
To purge host environments, you must have authority to environment maintenance and<br />
move authority for the environment. To purge remote environments, you must have<br />
authority to remote environment maintenance and move authority for the environment.<br />
Authority to host and remote environment maintenance is defined in Work with Users.<br />
Move authority is defined in Work with Environments, User Capabilities.<br />
When purging history for all environments (F19=Purge All History), users cannot access<br />
or use <strong>Implementer</strong> while the purge is running (requires a dedicated database). When<br />
purging specific environments, users cannot access the selected environment while the<br />
purge is running.<br />
Purging completed requests removes requests that completed on or before the purge<br />
date you specify. It removes the entire promotion request if the request is from the<br />
purged environment, or if the request targets a single environment and that<br />
environment is purged. If a request targets multiple environments and the secondary<br />
target environment is purged, it removes the purged primary environment from the<br />
request and the second environment becomes the primary environment on the request.<br />
In addition, <strong>Implementer</strong> adds a comment to the request, for example, “The primary<br />
target environment ‘name’ was purged on date by ‘user’.” When removing<br />
a purged secondary environment from the request, <strong>Implementer</strong> also adds a comment to<br />
the request, for example, “The target environment ‘name’ was purged on date<br />
by ‘user’.”<br />
You can optionally purge closed locks and object status history for production<br />
environments by specifying *ALL for the purge to date. If a lock is from or to the purged<br />
environment, it removes the lock and all related history. If a lock was copied from a<br />
purged environment, it removes any references to the environment from the lock and<br />
related history. If the history of a lock includes passing through a purged environment,<br />
the portion of history related to the purged environment.<br />
CAUTION Use this option cautiously—it purges the <strong>Implementer</strong> database of<br />
historical data, thereby removing audit trail information from production<br />
environments.<br />
Only requests that are non-release management packages can be removed. For details on<br />
purging release management environments, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Release<br />
Management <strong>Guide</strong>.<br />
<strong>MKS</strong> recommends you print the Activity Report, option 31 on the <strong>Implementer</strong> Menu,<br />
prior to running Purge History. This report is useful for analyzing the status of all<br />
environments and projects.<br />
375
Chapter 7: Administrative Utilities<br />
376<br />
To purge environment history<br />
1 From the <strong>Implementer</strong> Menu, type option 42, Environments, and press ENTER.<br />
From the <strong>Implementer</strong> Receiver menu, type option 8, Environments, and press ENTER.<br />
On the remote system you also have the option to use the Purge History (IDBPRG)<br />
command. Type IDBPRG and press ENTER to display the Purge History window. The<br />
Purge History command is valid only on the <strong>Implementer</strong> Receiver.<br />
2 Select the environment to purge with option 32, Purge History. To purge history for all<br />
environments, press F19=Purge All History. The Purge History panel displays.<br />
3 Complete the fields as described in the following table of “Purge History Field<br />
Descriptions”.<br />
4 Press F9=Submit to submit the job (or press F3=Exit to cancel the purge function).<br />
NOTE For information on overriding the default job queue and submission method<br />
on the host system, see “Submitting Job Overrides” on page 372. On the remote<br />
system, data area IRJOBQ stores the remote job queue, and data area IRSBMMTD<br />
stores the submission method. For details, see “<strong>Implementer</strong> Data Areas” on<br />
page 402.<br />
Field Description<br />
Repository Maintenance<br />
Purge History Field Descriptions<br />
Environment Name If purging a single environment, this field defaults to the<br />
environment selected on the Work with Environments panel. If you<br />
selected to purge all environments, the field defaults to *ALL.<br />
Purge to date Specify the ending date to purge all completed requests. For<br />
promotion requests, this is the completion date of each request. For<br />
locks and object history, it is the date the lock was released on the<br />
host system. Specify *ALL to purge up to the current date.<br />
Purge lock/obj status history Specify whether to purge lock and object status history. This option<br />
is valid only for host production environments. Status history is not<br />
purged for locks released on the specified purge to date, or for<br />
existing locks with active concurrent development.<br />
Y: Purges lock and object status history.<br />
N: Does not purge lock and object status history. This is the<br />
default value.<br />
<strong>Implementer</strong>’s member/object repository is the source for items that display in Object<br />
Inquiry and Work with Objects. Repository Maintenance allows you to modify the object<br />
codes associated with traditional member/objects and IFS objects within the repository for an<br />
environment.
Repository Maintenance<br />
This is useful, for example, if unexpected results occur after running the Build List for an<br />
environment. You can modify an existing object code, such as change PFOBJ to PF after<br />
locating the source, without having to rerun the Build List. The IFS command is useful for<br />
loading IFS objects into the <strong>Implementer</strong> database.<br />
Key Considerations<br />
The Change Repository (ICHGREP) command allows you to add, change, or delete<br />
object codes for traditional member/objects.<br />
The Change Repository IFS (ICHGREPIFS) command allows you to add or delete object<br />
codes for IFS objects. You cannot change IFS object codes, because the object code is<br />
always the IFS extension (for example, .EXE) or the object short name.<br />
You must have standard move authority for the environment being maintained to issue<br />
the ICHGREP and ICHREPIFS commands.<br />
To maintain the repository for traditional member/objects<br />
At the command line, issue the following:<br />
ICHGREP FUNCTION(*ADD, *CHG, *DLT)<br />
NAME(MEMBER/OBJECT_NAME)<br />
ENV(ENVIRONMENT_NAME)<br />
OBJCODE(OBJECT_CODE_NAME)<br />
NEWOBJCODE(NEW_OBJECT_CODE_NAME)<br />
DLTDTA(Y, N)<br />
NOTE The parameter NEWTYPE is valid only for the *CHG function.<br />
To maintain the repository for IFS objects<br />
At the command line, issue the following:<br />
ICHGREPIFS FUNCTION(*ADD, *DLT)<br />
OBJ(IFS_OBJECT_NAME)<br />
ENV(ENVIRONMENT_NAME)<br />
DLTDTA(Y, N)<br />
377
Chapter 7: Administrative Utilities<br />
378<br />
Change Repository Command Parameters<br />
Function<br />
Specify the action to perform.<br />
*ADD Adds an item to the repository for the specified environment. This is the<br />
default value.<br />
*CHG Changes an item in the repository for the specified environment. Valid for<br />
traditional member/objects only.<br />
*DLT Deletes an item from the repository for the specified environment.<br />
Member or Object<br />
Specify the name of the member or object to add, change or delete.<br />
Environment<br />
Specify the environment location of the member or object (the environment you are adding to<br />
or deleting from).<br />
Object code<br />
Specify the object code currently assigned to the item. Valid for traditional member/objects<br />
when the Function is *CHG.<br />
New object code<br />
Specify the new object code to assign to the item. Valid for traditional member/objects when<br />
the Function is *CHG.<br />
Delete from the database<br />
This parameter is valid for IFS objects when the Function is *DLT. The *DLT function allows<br />
you to delete the object from the database. The default value is blank.<br />
Y Deletes the member or object from the database.<br />
N Deletes the member or object from the environment repository only (does<br />
not delete from the database).<br />
Development Library Maintenance<br />
The Delete Library Reference (IDLTLIBREF) command allows you to delete obsolete records<br />
from the <strong>Implementer</strong> repository for development libraries. The command removes all<br />
references to member/objects within the library, including current locks. Use this command<br />
when few to no open locks exist.
To issue the IDLTLIBREF command<br />
From an <strong>Implementer</strong> command line, issue the following command:<br />
IDLTLIBREF LIB(LIBRARY_NAME or *ALL)<br />
Saving and Restoring Tape Archives<br />
Saving and Restoring Tape Archives<br />
<strong>Implementer</strong> users who require access to the archives of every change made to an<br />
environment must often balance this requirement with the disk space required to store the<br />
archive copies. Archiving to tape minimizes the impact of large archives by allowing you to<br />
store the archives off line.<br />
You can save and remove all archives or specific archives. You have access to the archive<br />
information for each tape. You can selectively restore archives back to the system. Once<br />
restored, you can browse the changes and/or recover the changes back into production.<br />
This feature is also available on the <strong>Implementer</strong> Receiver. For details, see “Saving and<br />
Restoring Remote Tape Archives” on page 192.<br />
NOTE For information on archiving and archive recovery, see the <strong>MKS</strong> <strong>Implementer</strong><br />
<strong>2006</strong> User <strong>Guide</strong>.<br />
Key Considerations<br />
Tape archives include IFS and DLO files and directories, if archived.<br />
The archive to tape function uses two temporary libraries that <strong>Implementer</strong><br />
automatically creates at the beginning of the process and deletes at the end. <strong>Implementer</strong><br />
provides the data area IMARCTAP to store the names of these temporary libraries. The<br />
default data are values are IMARCTAP1 and IMARCTAP2.<br />
CAUTION If you change the default library names in the IMARCTAP data area, you<br />
must specify library names that do not exist on the system, as <strong>Implementer</strong> creates<br />
and deletes the libraries as needed. For details, see “<strong>Implementer</strong> Data Areas” on<br />
page 402.<br />
You can initiate all archive to tape functions from the Archives to Tape menu. Access to<br />
the menu options and commands requires you sign on as QSECOFR or with a profile<br />
that has a group profile of QSECOFR or QSECOFR capabilities.<br />
A good practice is to use a new tape for each save. <strong>Implementer</strong> automatically sets the<br />
tape label and initializes the tape with volume ARC###, where ### represents a number<br />
that starts at 001 and automatically increments for each save. <strong>Implementer</strong> data area<br />
ITAPEVOLUM store this information.<br />
379
Chapter 7: Administrative Utilities<br />
380<br />
<strong>Implementer</strong> provides query reports on the host system that allow you to locate and list<br />
all archives saved to tape. You can view the reports online or select to print.<br />
To restore a tape archive, you can use the menu option or a command option to restore<br />
the archives for any environment archive on a request you need to back out.<br />
To perform recovery, use <strong>Implementer</strong> Menu option 23, Archive Recovery, to select the<br />
request to recover. <strong>Implementer</strong> automatically creates and promotes a standard archive<br />
recovery request. You can browse the source through Archive Recovery or Object<br />
Inquiry. For details, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
<strong>Implementer</strong> supports using a third party save/restore utility to save archives to tape.<br />
For example, you can use IBM’s Backup Restore Management System (BRMS/400), or an<br />
internal program. For details, see “BRMS/400 Integration” on page 322.<br />
The archive to tape and restore from tape functions are available on the host and<br />
<strong>Implementer</strong> Receiver. You can run the jobs interactively or in batch. For details on the<br />
remote system functions, see “Saving and Restoring Remote Tape Archives” on<br />
page 192.<br />
Working With Tape Archives<br />
The Archives to Tape menu provides access to the functions and reports associated with tape<br />
archives. Access to these functions requires signing on to the system with the QSECOFR user<br />
profile, or a user profile that has a group profile of QSECOFR or QSECOFR capabilities.<br />
To access the Archives to Tape menu<br />
Do one of the following:<br />
From the <strong>Implementer</strong> Menu, type option 24, Archive to Tape, and press ENTER.<br />
From a command line, issue the STRIM *ARCTAP command, or the GO IMARCTAP<br />
command (library <strong>MKS</strong>IM must be in your library list).<br />
CAUTION The next task initializes a tape and optionally clears the tape contents. To<br />
avoid the loss of saved data, verify you have the correct tape before continuing.<br />
To save an archive to tape<br />
1 From the Archive to Tape menu, select option 1, Save Archives to Tape to prompt the<br />
Archives to Tape (ISAVARC) command. You can also prompt the ISAVARC command<br />
from the command line.
2 Complete the command parameters as described next and press ENTER.<br />
Saving and Restoring Tape Archives<br />
Process the command interactively, submit for batch processing, or add it to a backup<br />
routine to automate the removal of new archives.<br />
NOTE When using a third party save/restore utility and you select option 1, the<br />
Save Archives to Tape panel is replaced as instructed by your internally described<br />
program in IMSVLB2 in QSAMPLE. As such, the remaining steps in this task do not<br />
apply; follow the steps applicable to the utility you are using. For more information,<br />
see “BRMS/400 Integration” on page 322.<br />
Save Archives to Tape (ISAVARC) Command Parameters<br />
Tape Device<br />
Specify the name of the tape device to use for the save operation.<br />
Archive library<br />
Do one of the following:<br />
Specify the name of the library that contains the archived objects. If multiple<br />
environments share an archive library, this allows you to save in a single operation all<br />
objects for all environments that use the library.<br />
Specify *ALL to save the objects from all archive libraries. This option allows you to save<br />
all objects in all archive libraries for all environments.<br />
Specify *ENV to save the objects for a particular environment. If multiple environments<br />
share an archive library, it saves only the objects for that environment rather than the<br />
entire contents of the library. This option requires a value in the following Archive<br />
environment field.<br />
Archive environment<br />
Specify the name of the environment associated with the archived objects. This saves the<br />
archived objects only, not the entire archive library.<br />
From date<br />
Specify a date (in YY/MM/DD format) to include all objects archived on or after the date.<br />
To date<br />
Specify a date (in YY/MM/DD format) to include all objects archived on or before the date.<br />
NOTE The From date and To date fields allow you to include objects that were<br />
changed on, before, after, or within the dates specified. Use the fields separately, or<br />
in combination to process a date range selection. The default value for each field is<br />
blank, which bypasses date filtering.<br />
381
Chapter 7: Administrative Utilities<br />
382<br />
Density<br />
Specify the density of the tape. The default value is *DEVTYPE.<br />
Target release<br />
Specify the release level of the operating system for the saved objects. The default value is<br />
*CURRENT.<br />
Initialize tape<br />
Specify whether to initialize the tape before the save operation. If you specify *NO and the<br />
tape has the wrong volume ID, a message notifies you that the volume ID does not match.<br />
You must correct the error before continuing.<br />
Submit<br />
The default value *YES submits the job to batch processing. Specify *NO to process the job<br />
interactively.<br />
Job queue/Library<br />
The default values *PRODUCT/*LIBL assign the default job queue defined in System<br />
Control Maintenance. Change the values as needed.<br />
Hold on job queue<br />
Specify the standard OS/400 submit job value as needed.<br />
To restore an archive from tape<br />
1 From the Archives to Tape menu, select option 2, Restore Archives from Tape, or issue<br />
the IRSTARC command to display the Restore Archives from Tape (IRSTARC) command<br />
parameters.<br />
2 Specify the IRSTARC command parameters as described next, and press ENTER.<br />
TIP Review the archive reports described in the next section to easily locate the<br />
requests to restore.<br />
Restore Archives from Tape (IRSTARC) Command Parameters<br />
Request Number<br />
Specify the request number to restore, or specify *ALL to restore all requests on the tape for<br />
the specified environment.
Environment<br />
Saving and Restoring Tape Archives<br />
Specify an environment to restore the recovered members/objects into. Archives restore into<br />
the same archive library they were saved from.<br />
Tape Device<br />
Specify the name of the device you are using to restore the tape.<br />
Submit<br />
Archive Reports<br />
The default value *YES submits the job to batch processing. Specify *NO to process the job<br />
interactively.<br />
Job queue/Library<br />
The default values *PRODUCT/*LIBL uses the default job queue defined in System Control<br />
Maintenance. Change the values as needed.<br />
Hold on job queue<br />
Specify the standard OS/400 submit job value as needed.<br />
IMPORTANT If you previously saved and cleared archive libraries, the <strong>Implementer</strong><br />
files that manage the archives still reflect the object in the archive library, when<br />
actually, it is not. For this reason, a cleared object may still appear on the archive<br />
report, but any attempt to recover the cleared object fails since the object is not<br />
actually on the tape. To recover the remaining items on the request, use the IBM<br />
Data File Utility (DFU) command to remove the record that refers to the archive that<br />
was deleted from the <strong>Implementer</strong> archive file (IMARTP).<br />
<strong>Implementer</strong> provides report queries to help you manage tape archives. The following<br />
reports are available on the Archives to Tape menu:<br />
Archives per Tape Report<br />
Archives by Request Report<br />
Archives by Environment Report<br />
Select any of the respective menu options to prompt the query. Standard query record<br />
selection allows you to limit the reports to a specific tape, promotion request, or environment<br />
of interest. You have the option to view information online or print the report.<br />
383
Chapter 7: Administrative Utilities<br />
Clearing Remote QA Environments<br />
384<br />
When you promote from a host and a remote QA environment to a production environment<br />
on a single request, <strong>Implementer</strong> retains a copy of the source and objects in the remote QA<br />
environment. By default, <strong>Implementer</strong> does not delete items from remote environments.<br />
For situations when this is not the desired result, <strong>Implementer</strong> provides a feature that allows<br />
you to delete the items in a remote QA environment after successful promotion from the<br />
environment. This is beneficial when QA and production environments exist on both the host<br />
and remote systems, and you want to automatically delete source and objects from the<br />
remote QA environments. For example, a promotion request created on a host system targets<br />
both local and remote QA environments. After successful QA testing, a new request created<br />
from the host QA environment targets both host and remote production. As part of the final<br />
move processing for the request, a special command you define runs based on your<br />
specifications and deletes the source and objects from the remote QA environment.<br />
NOTE This feature is available for AllFusion 2E environments by setting up the<br />
special command as described in this section. You must also set the <strong>Implementer</strong><br />
data area values for IMDLTFRMUP and IMDLTFRMUS to ‘YES’. For details, see<br />
“<strong>Implementer</strong> Data Areas” on page 402.<br />
Key Considerations<br />
Define the remote QAC environment with the Remove obj in from lib/env field and the<br />
Remove src in from lib/env field set to 1 (Always). For details, see the environment field<br />
descriptions on page 131.<br />
Define a special command for the remote environment to run for all promotion requests<br />
that target the environment. The special command automatically runs after the move<br />
completes, when the source and objects are in the target libraries.<br />
Add the <strong>Implementer</strong> Receiver library to the library list of the remote environment to<br />
support processing the special command.<br />
Define the object codes, or enable environment object code overrides for the remote QA<br />
environments. For details, see “Removing Source and Objects After Promotion” on<br />
page 92.<br />
To define the special command<br />
1 From the Work with Environments panel, select the remote production environment<br />
with option 19=Special commands, and press ENTER.<br />
2 Press F6=Add.
3 Complete the following fields and press ENTER.<br />
To modify the remote production environment library list<br />
User Capability Wizard<br />
1 From the Work with Environments panel, select the remote environment with option<br />
2=Change and press ENTER.<br />
2 Press F13=Library List to display the Edit Environment Library List - Remote panel.<br />
3 Complete the following fields:<br />
In the Sequence Number field, specify the next sequence number.<br />
In the Library field, specify the name of the <strong>Implementer</strong> Receiver library. The<br />
default product library for the <strong>Implementer</strong> Receiver is <strong>MKS</strong>IR. If you changed the<br />
library name when you installed the <strong>Implementer</strong> Receiver, substitute your changed<br />
name for the default name.<br />
4 Press ENTER to update the list.<br />
User Capability Wizard<br />
Environment (remote environment name)<br />
For Action 4 (Move)<br />
When to do 5 (After move-ok)<br />
Command IRMVFRMOBJ<br />
RQSNBR(#RQSNBR)<br />
TRGENV(#TRGENV)<br />
FRMENV(REMOTE_QA_ENVIRONMENT)<br />
The Capability Wizard is a graphical user interface (GUI) tool designed to minimize the setup<br />
and maintenance of user authorities in <strong>Implementer</strong>. It allows you to rapidly reflect new<br />
business rules quickly, by changing the capabilities of multiple users or environments with a<br />
single action.<br />
The administrator, or anyone responsible for working with user authorities in <strong>Implementer</strong>,<br />
can benefit from using this time saving application tool. The major advantage to using the<br />
Capability Wizard over the Work with Users function is that it allows you to process<br />
concurrent changes to the capabilities for multiple users and environments.<br />
The Capability Wizard requires adding new users through the Work with Users function, as<br />
well as adding new environments through Work with Environments function, both<br />
accessible from the <strong>Implementer</strong> Menu. You can create the initial records with the minimum<br />
requirements, and use the time-efficient Capability Wizard to complete the setup and<br />
perform ongoing maintenance.<br />
385
Chapter 7: Administrative Utilities<br />
386<br />
The Capability Wizard is delivered with <strong>Implementer</strong>. In addition to the requirements for<br />
<strong>Implementer</strong>, this feature requires:<br />
Windows<br />
Java Virtual Machine 1.1 (provided)<br />
TCP/IP connection to the iSeries<br />
Installing on Windows<br />
The Capability Wizard requires Java Runtime Environment (JRE) 1.1.5, or later. This is<br />
included with the installation program. The installation process searches for the existing JRE<br />
on the target PC and if it is not located, installation of the JRE is performed before the<br />
Capability Wizard installation. The installation requires you:<br />
Verify TCP/IP connectivity.<br />
Download the self-extracting executable capwiz.exe.<br />
Run the Capability Wizard install program capwiz.exe and follow the instructions that<br />
display in the setup procedure.<br />
Verify the user profile. The user profile you use must have *CHANGE rights to the<br />
<strong>Implementer</strong> file IMUSEN, and *USE rights to files MWIPF200 and MWIPF300. By<br />
default, only QSECOFR and MWIPROD profiles have these rights.<br />
Verifying TCP/IP Connectivity<br />
The Capability Wizard requires an active TCP/IP connection to the iSeries system where the<br />
<strong>Implementer</strong> database is located. If you cannot communicate with the OS/400 server<br />
successfully, the Capability Wizard cannot properly connect to the iSeries to perform the<br />
database updates.<br />
Ping is an MS-DOS program that allows you to verify that a particular Internet Protocol (IP)<br />
address exists and can accept requests. Ping is used diagnostically to verify that the host<br />
computer you are trying to reach has communications enabled and is operating. To verify<br />
your TCP/IP connection, you can either ping the system or ping the iSeries servers (requires<br />
ClientAccess installed on the local PC) as described next. If ping is unsuccessful, contact your<br />
system administrator.<br />
To ping the OS/400 servers<br />
1 From a command prompt, type cd.. and press ENTER to display the root directory c:/.
2 Type CWBPING (system_name) and press ENTER.<br />
where system name is the name of the system you are attempting to ping.<br />
User Capability Wizard<br />
You may see polling of multiple OS/400 servers. A message confirms the status: Either<br />
ping of the specified server was successful, or a time out occurred without locating the<br />
server.<br />
To ping the system<br />
1 At a command prompt, type cd.. and press ENTER to display the root directory c:/.<br />
2 Type PING (system_name) and press ENTER.<br />
A message confirms the status: Either ping of the specified server was successful, or a<br />
time out occurred without locating the server.<br />
Installing on the Desktop<br />
You have two options for downloading and installing the JRE and Capability Wizard from<br />
the iSeries onto your PC. The method you choose is simply a matter of preference.<br />
Map Network Drive copies data by sector and may take longer than the FTP method,<br />
depending on the speed of your PC.<br />
FTP (File Transfer Protocol) performs a bulk data transfer. It is quicker than the map<br />
drive method, but involves more steps.<br />
The default installation directory is C:/<strong>MKS</strong>/<strong>Implementer</strong>/Capability Wizard. You can<br />
select a different directory if necessary.<br />
During installation of the Capability Wizard, you may be prompted to install the Java<br />
Runtime Environment if not already installed.<br />
To install the Capability Wizard using the Map Network Drive method<br />
1 Open Windows Explorer and click Tools > Map Network Drive. A Map Network Drive<br />
dialog box displays prompting for a drive and path name.<br />
2 Select the drive name to use or accept the default value.<br />
3 For the path, type:<br />
//Your_System_Name/<strong>MKS</strong>/<strong>Implementer</strong>/<strong>MKS</strong>IM<br />
NOTE The default product library name is <strong>MKS</strong>IM. If you changed the product<br />
library to another name, substitute the changed name for <strong>MKS</strong>IM.<br />
4 Make sure the Reconnect at Logon box is disabled and click OK. You may be prompted<br />
for a user ID and password to connect to the system.<br />
387
Chapter 7: Administrative Utilities<br />
388<br />
5 From Windows Explorer, select and expand the drive you just mapped.<br />
6 Double click capwiz.exe.<br />
7 Follow the installation instructions presented on the screens. When you complete the<br />
installation, you can begin using the Capability Wizard.<br />
To install the Capability Wizard using the FTP method<br />
1 At a command prompt, type FTP and press ENTER to display an ftp> prompt.<br />
2 Type OPEN your_system_name and press ENTER. A message confirms, "Connected to<br />
your_system_name".<br />
3 A prompt displays requesting a user. Type a valid user ID for the system you opened in<br />
step 2, and press ENTER.<br />
4 A prompt displays requesting the password for the user ID specified in step 3. Type the<br />
password and press ENTER.<br />
5 Type bin and press ENTER. A message confirms "Representation type is binary<br />
IMAGE".<br />
6 Type quote site namefmt 1 and press ENTER. A message confirms you are using<br />
naming format "1".<br />
7 Type cd /<strong>MKS</strong>/<strong>Implementer</strong>/<strong>MKS</strong>IM and press ENTER. A message confirms, "Current<br />
directory changed to /mks/<strong>Implementer</strong>/<strong>MKS</strong>IM".<br />
NOTE The default product library name is <strong>MKS</strong>IM. If you changed the product<br />
library to another name, substitute the changed name for <strong>MKS</strong>IM.<br />
8 Type lcd c:/temp and press ENTER. A message confirms, "Local directory now<br />
c:/temp". (You may need to create this directory if it does not exist.)<br />
9 Type get capwiz.exe and press ENTER. The self-extracting installation executable<br />
transfers to your PC into directory c:/temp.<br />
10 Type quit and press ENTER to display the c:/ prompt.<br />
11 Type cd c:/temp and press ENTER.<br />
12 Type capwiz.exe and press ENTER.<br />
13 Follow the installation instructions presented on the screens. When you complete the<br />
installation, you can begin using the Capability Wizard.<br />
Using the Capability Wizard<br />
The Capability Wizard allows you to authorize <strong>Implementer</strong> users to perform specific<br />
functions in the environments they work with.
User Capability Wizard<br />
The Capability Wizard prompts you to sign on to the iSeries. Your user profile must be set up<br />
in <strong>Implementer</strong> and have authority to user profile maintenance and environment<br />
maintenance.<br />
NOTE Instructions on using this utility are also in file Readme.txt installed with<br />
the Capability Wizard.<br />
To start the Capability Wizard<br />
1 From your Windows desktop, click<br />
Start > Programs > <strong>MKS</strong> <strong>Implementer</strong> > Capability Wizard.<br />
A command prompt window displays to inform you the program is starting, followed<br />
by the User Capability Wizard Welcome dialog box. Click the following command<br />
buttons to perform an action:<br />
Previous allows you to return to the previous panel.<br />
Next allows you to process current selections and display the next window.<br />
Cancel allows you to close the Capability Wizard.<br />
2 Follow the steps on the Welcome dialog box and click Next. The System Configuration<br />
dialog box displays.<br />
389
Chapter 7: Administrative Utilities<br />
390<br />
The status bar currently indicates you are not connected.<br />
IMPORTANT The user profile you sign on with must have *CHANGE rights to the<br />
<strong>Implementer</strong> file IMUSEN, and *USE rights to files MWIPF200 and MWIPF300. By<br />
default, only QSECOFR and MWIPROD profiles have these rights. For more<br />
information, see “Verifying TCP/IP Connectivity” on page 386.<br />
3 In the System name field, type the name of the iSeries or the IP address of the system you<br />
are connecting to.<br />
4 In the User ID, Password, and Library fields, specify the user ID, password, and installed<br />
<strong>Implementer</strong> library name (if other than the default product library name <strong>MKS</strong>IM).<br />
5 Click Next. The Enrolled Users list displays.<br />
If the Wizard is unable to connect to the specified system, the status indicates that an<br />
error has occurred. You can review the error details in the files CapWiz Output.txt<br />
and Error Log.txt.<br />
If this process locks up, press CTRL + ALT + DEL and use the Task Manager to end the<br />
Capability Wizard function. If the first attempt to connect fails, it may be necessary to<br />
close and restart the Wizard.<br />
Selecting Enrolled Users<br />
The Enrolled Users list displays all enrolled users. You can select all users, a combination of<br />
multiple users, or a specific user.<br />
NOTE To enroll new users you must use the Work with Users function. For details,<br />
see “Users” on page 72.
To select users<br />
1 In the Enrolled Users list, click a user.<br />
User Capability Wizard<br />
To select a block of users, click the first user and while pressing SHIFT, click the last<br />
user. To omit selective users, press CTRL and click the user.<br />
To select multiple users, press CTRL and click each user.<br />
To select all enrolled users, enable the Select ALL users option. To omit selective<br />
users, press CTRL and click the user.<br />
2 Click Next. The Environment list displays.<br />
Selecting Environments<br />
The Environment list displays the environments that users work in.<br />
You can use a variety of selection criteria to limit the view of environments. For example, you<br />
can select all environments, or any combination of development, QA, and production<br />
environments.<br />
You may want to filter by environment type. For example, you can select just development or<br />
production environments, or all development and all QA environments.<br />
391
Chapter 7: Administrative Utilities<br />
392<br />
To select an environment<br />
1 In the Environment list, click an environment. To select by environment type, enable the<br />
Environment types check box for the type of environments you want to view.<br />
To select a block of environments, click the first environment, and while pressing<br />
SHIFT, click the last environment. To omit selective environments, press CTRL and<br />
click the environments.<br />
To select multiple environments, press CTRL and click each environment.<br />
To select all environments, enable the Select ALL Environments option. To omit<br />
selective environments, press CTRL and click the environment.<br />
2 Click Next. The Authority list displays, filtered by the specified environment type.
User Capability Details<br />
User Capability Wizard<br />
The authority types that display in the list are based on predefined templates that define<br />
the typical user groups associated with <strong>Implementer</strong>. You cannot change the standard<br />
authorities of these templates. To modify the standard values, see the Readme.txt in the<br />
installation directory. For information on authority types, see “Understanding<br />
<strong>Implementer</strong>” on page 9.<br />
The Custom authority allows you to override the standard defaults for any user. For<br />
information on this option, see “Customizing User Capabilities” on page 394.<br />
Click Detail to display the Capability Details list to view the authorities and options<br />
defined for each authority type. For details, see “User Capability Details” in the next<br />
section.<br />
Click Next to define this user with the standard rights and authorities associated<br />
with the selected authority type.<br />
The Confirm Selections dialog box displays. Proceed with “Updating the<br />
<strong>Implementer</strong> Database” on page 395.<br />
The Authority list allows you to define the functions a user type is allowed to access. You can<br />
view the authority details for any enrolled user. For a description of each capability, see<br />
“Environments and User Capabilities” on page 109.<br />
To view capability details for a user<br />
1 Click an authority and then click Detail.<br />
The Capability Details list displays the standard capabilities for a specified authority<br />
type, by environment type. Use the scroll bar to view the capabilities settings. The only<br />
authority type you can modify is Custom Capability Group.<br />
393
Chapter 7: Administrative Utilities<br />
394<br />
2 Click OK. The Authority Templates list displays.<br />
You can work with additional authority types or proceed with updating the<br />
<strong>Implementer</strong> database.<br />
To update the <strong>Implementer</strong> database<br />
1 Click OK. The Confirm Selections dialog box displays.<br />
2 Proceed with “Updating the <strong>Implementer</strong> Database” on page 395.<br />
Customizing User Capabilities<br />
You can use the custom capability group to modify a user’s standard capabilities and<br />
authorities. This is the only capability group that allows changes. The value in the Allowed<br />
field controls the allowed capabilities.<br />
To customize user capabilities<br />
1 Select the CUSTOM Authority type.<br />
2 Click Details.<br />
3 For the environment type and capability you are changing, double click the value in the<br />
Allowed field to display the list of allowed values.<br />
4 Click the value you want to define. Valid options are:<br />
Y (allowed)<br />
N (not allowed)<br />
(this is the default value)
5 Click OK. The Authority list displays.<br />
6 Click Next. The Confirm Selections dialog box displays.<br />
Updating the <strong>Implementer</strong> Database<br />
User Capability Wizard<br />
The Capability Wizard uses TCP/IP to perform SQL updates to <strong>Implementer</strong>. When you are<br />
ready to update the <strong>Implementer</strong> database, you can either process the update and return to<br />
continue processing additional updates, or process the update and exit the Capability<br />
Wizard.<br />
On the Confirm Selections dialog box, the Status bar indicates pending <strong>Implementer</strong> updates<br />
exist. The Status bar confirms either the number of records selected for production<br />
environment update, or that no production environments were selected to update.<br />
395
Chapter 7: Administrative Utilities<br />
396<br />
To confirm your selections and update the <strong>Implementer</strong> database<br />
1 (Optional) Enable the Repeat option to continue with additional updates without exiting<br />
the application.<br />
2 Click Finish. The Successful Update message box displays.<br />
3 Click OK.<br />
If you enabled the Repeat option, the Enrolled Users list displays; otherwise, the<br />
application closes.<br />
Deleting Tutorial Information<br />
<strong>Implementer</strong> includes demonstration data to help new users learn to use the software and<br />
help experienced users to use new features. If you selected to install demonstration data<br />
when you installed <strong>Implementer</strong>, you can delete the tutorial data when it is no longer<br />
needed.<br />
To delete tutorial information<br />
1 Delete the tutorial libraries. For a list of these libraries, see Appendix A of the<br />
<strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>.<br />
2 From the Workbench, delete the locks for the member/objects associated with tutorial<br />
environments. For details, see “Deleting a Lock” in the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
3 To remove the historical data, from Work with Environments, use option 32, Purge<br />
History.<br />
CAUTION Purge history removes the history of completed requests and locks for an<br />
environment based on dates you specify. If you are using <strong>Implementer</strong> for change<br />
management in production (not just for training), performing this function may<br />
result in the removal of that data. For details, see “Purging Environment History” on<br />
page 374.<br />
4 Delete the demonstration environments by using <strong>Implementer</strong> Menu option 42,<br />
Environments. For details, see “Deleting an Environment” on page 96.
Function Key <strong>Administration</strong><br />
Function Key <strong>Administration</strong><br />
The Work with Function Keys function allows you to change the definition of command keys<br />
on a modifiable panel. You can add, change, or delete specific command keys. There are<br />
specific key numbers for global keys and the capacity to either make the key global or<br />
override it for each specified panel.<br />
You can define specific function keys to directly access your internal systems (such as a<br />
problem tracking or help desk system) from the <strong>Implementer</strong> Menu or <strong>Implementer</strong> Receiver<br />
Menu, or add commonly used commands to a function key.<br />
To work with function keys<br />
1 From the <strong>Implementer</strong> Menu, select option 50, Function Keys, and press ENTER. The<br />
Work with Function Keys Panel Select panel displays.<br />
From the <strong>Implementer</strong> Receiver menu, select option 9, Function Keys, and press ENTER.<br />
2 Select the panel you want to work with (or *ALL) using option 1=Work with panel.<br />
The Work with Function Keys - Key Select panel displays. For a description of the fields<br />
on this panel, see “Key Select Maintenance Field Descriptions”.<br />
Use option 1=Change to change function keys, or option 8=Refresh overridden global<br />
function keys. If the global column displays O (indicating a global function key with<br />
specific overrides for the panel), option 8 resets the function key to its original global<br />
values and causes Y to display in the global column. This option is available on all panels<br />
except the *ALL (global) panel. Use option 9=Delete to delete function keys.<br />
To change a function key<br />
1 From the Work with Function Keys - Key Select panel, select the key to change with<br />
option 1=Change, and press ENTER. The Work with Function Keys - Key Maint panel<br />
displays.<br />
2 Complete the fields on this panel as defined in the following table, and press ENTER to<br />
process the changes.<br />
397
Chapter 7: Administrative Utilities<br />
398<br />
Field Description<br />
Key Select Maintenance Field Descriptions<br />
Panel ID Identifies the panel that function keys are defined for. This value displays in<br />
the upper left-hand corner of the product panels.<br />
Panel width Specifies the width of the panel.<br />
Nbr of lines Specifies how many lines display on the panel.<br />
Key Number assigned to the function key.<br />
0: ENTER<br />
1–24: Function keys 1 through 24<br />
25: ROLL UP<br />
26: ROLL DOWN<br />
27: HELP<br />
28: HOME<br />
29: CLEAR<br />
100+: Document-only function keys. Allows you to document and display<br />
on panels some of the commonly used keys on your keyboard. You can<br />
number document-only function keys from 100–999. These keys do not<br />
process, rather they document available keys that process outside the<br />
application program (for example, SYSTEM REQUEST ATTENTION and<br />
various PC hot key sequences). When creating a document-only function<br />
key, you cannot enter an action or command.<br />
Key name Derived from the function key prefix and number (not maintainable for<br />
regular function keys). You can enter this on the Work with Function Keys -<br />
Key Maintenance panel for document-only function keys.<br />
Function key text Text to display on the panel, following the separator for the function key. For<br />
example, for F8=Spool Files the function key text is Spool Files.<br />
Valid Indicates whether the function key is valid on this panel.<br />
Y: The function key is valid.<br />
N: The function key is not valid. Invalid function keys do not display, for<br />
example, ROLL UP on a panel with only one page.<br />
Display Defines whether the function key displays on the panel, if valid. The value<br />
for this entry is used only if the function key is valid.<br />
Y: The function key displays.<br />
N: The function key does not display. If the Valid field is set to Y, the<br />
function key remains valid, for example, the ENTER key.
Field Description<br />
Function Key <strong>Administration</strong><br />
Global Defines whether the function key is a global key (defined to the *ALL panel)<br />
and whether the key definition was overridden from its global definition. This<br />
entry is not maintainable.<br />
Y: The key is an unchanged global key. The specified key definition is equal<br />
to the global key definition.<br />
O: The global definition is overridden for this function key.<br />
Blank: The key is not a global key. The function key is defined globally, but<br />
one of the attributes is redefined on this panel.<br />
Action/Command This entry can be an action or a command as follows:<br />
Actions are prefaced by an asterisk (*); commands are not.<br />
If the entry contains an action, the action returns to the program processing<br />
the panel. You cannot maintain actions.<br />
If the entry contains a command, the command runs when you press the<br />
function key. You can maintain a command by typing 1 in the selection entry<br />
and pressing ENTER.<br />
399
Chapter 7: Administrative Utilities<br />
400
A PPENDIX A<br />
<strong>Implementer</strong> Data Areas and<br />
User Exit Programs<br />
Customizing <strong>Implementer</strong><br />
A<br />
The additional features described in this appendix allow you to further customize your<br />
<strong>Implementer</strong> database.<br />
This appendix covers the following topics:<br />
“<strong>Implementer</strong> Data Areas” on page 402<br />
“Customizing <strong>Implementer</strong>” on page 414<br />
401
Appendix A: <strong>Implementer</strong> Data Areas and User Exit Programs<br />
<strong>Implementer</strong> Data Areas<br />
402<br />
<strong>Implementer</strong> has numerous data areas that control various features and functions within the<br />
product. You can modify the data area values to further customize your <strong>Implementer</strong><br />
database.<br />
The data areas are located on either the host system or the remote system, although some<br />
data areas exist on both systems as noted. On the <strong>Implementer</strong> host system the data areas are<br />
located in the default product library <strong>MKS</strong>IM. On the <strong>Implementer</strong> Receiver the data areas<br />
are located in the default product library <strong>MKS</strong>IR.<br />
To change the data areas, sign on to the iSeries with the <strong>Implementer</strong> user profile MWIPROD,<br />
or a user profile with *ALLOBJ special rights, and use the standard OS/400 Change Data<br />
Area (CHGDTAARA) command.<br />
IMPORTANT The data areas described are those that you can safely change. You<br />
should not change other data areas in the <strong>Implementer</strong> library.<br />
Add Related Objects for Service Programs (IMADDOBJ)<br />
The IMADDOBJ data area allows you to control how <strong>Implementer</strong> handles objects related to<br />
service programs during related object processing. This prevents the unnecessary recompile<br />
of objects that use service programs when modules are changed but the signature does not<br />
change.<br />
Valid values for the data area are *YES (default value) and *NO. Set the value to *NO to<br />
activate this feature and bypass recompiling objects related to service programs.<br />
Archive to Tape Libraries (IMARCTAP)<br />
The IMARCTAP data area contains the name of two temporary libraries used by the archive<br />
to tape function. The default data area value is IMARCTAP1 in positions 1 through 10, and<br />
IMARCTAP2 in positions 11 through 20, enclosed in single quotes, for example, ‘IMARCTAP1<br />
IMARCTAP2’.<br />
CAUTION <strong>Implementer</strong> deletes and recreates the libraries in this data area as needed,<br />
for example, when submitting the archive to tape. Thus, if you change the default<br />
library names stored in IMARCTAP, you must specify libraries that do not exist or<br />
are not needed elsewhere on your system.<br />
Bind Update (IMBNDUPD)<br />
The IMBNDUPD data area allows you to bypass the PathFinder update for ILE programs.<br />
Valid values are *YES or *NO (default value) enclosed in single quotes. Set the value to<br />
‘*YES’ to activate this feature.
Communications User Profile (IMCMNUSR)<br />
<strong>Implementer</strong> Data Areas<br />
The IMCMNUSR data area contains the user profile and password <strong>Implementer</strong> uses to<br />
initiate communications to a remote system when distributing changes to the remote system.<br />
The data area is located on both the host system and the <strong>Implementer</strong> Receiver.<br />
The default value is MWIPROD in positions 1 through 10 (user profile name), and MWIPROD<br />
(password) in positions 11 through 20. You must enclose the values in single quotes that<br />
encompass the entire 20-character field, for example, ‘MWIPROD MWIPROD ’.<br />
If the data area value is blank, a user profile is not available for <strong>Implementer</strong> to initiate<br />
communications with the remote. In this case the user profile is derived by retrieving the<br />
communication entries defined in the communication subsystem on the remote system.<br />
Check Out/Reject Options (IMCOREJ)<br />
The IMCOREJ data area pertains to checking out and rejecting changes from QA, when the<br />
member/object being checked out already exists in the target check out location. By default, a<br />
message window displays to notify you the member/object exists in the target location, and<br />
you are required to select a copy option to proceed. The data area allows you to bypass the<br />
display of the message window and automatically default the copy option.<br />
The data area value allows four character positions. Positions 1 and 2 relate to checking out.<br />
Positions 3 and 4 relate to rejecting from QA. The default value is NSNS, which prompts the<br />
display of the window and requires selecting a copy from option. The data area layout and<br />
allowed values are as follows.<br />
Position Description Valid Values<br />
1 Controls display of the “Mbr/Obj<br />
Already Exists” window in check out.<br />
2 Allows you to set the default copy<br />
option when position 1 is set to Y.<br />
3 Controls display of the “Mbr/Obj<br />
Already Exists” window when<br />
rejecting from QA.<br />
4 Allows you to set the default copy<br />
option when position 3 is set to Y.<br />
Y = Does not display the window.<br />
N = Displays the window to allow selection of a<br />
copy option.<br />
S = Skip.<br />
R = Replace.<br />
X = Replace All.<br />
K = Keep Existing.<br />
A = Keep All Existing.<br />
Y = Does not display the window.<br />
N = Displays the window to allow selection of a<br />
copy option.<br />
S = Skip.<br />
R = Replace.<br />
X = Replace All.<br />
K = Keep Existing.<br />
A = Keep All Existing.<br />
403
Appendix A: <strong>Implementer</strong> Data Areas and User Exit Programs<br />
404<br />
Delete User Programs and User Source During Promotion<br />
(IMDLTFRMUP and IMDLTFRMUS)<br />
For AllFusion 2E CM users, the IMDLTFRMUP and IMDLTFRMUS data areas allow you to<br />
control whether to remove user programs (IMDLTFRMUP) and user source (IMDLTFRMUS)<br />
in the from library after successful promotion. You can delete programs and display files<br />
without removing database files from development or test libraries to retain test data.<br />
The data areas exist on both the host and remote system. On the remote, the data areas<br />
control whether user programs and user source are removed from the remote QA<br />
environment during promotion to the remote. This is beneficial when both QA and<br />
production environments exist on both the host and remote systems.<br />
Valid values for the data areas are *YES or *NO enclosed in single quotes. The default value is<br />
‘*YES’. The value *NO overrides the value specified on a promotion request.<br />
NOTE<br />
If using these data areas to enable <strong>Implementer</strong>’s remote QA environment<br />
cleanup feature, you must also set up a special command to run as part of the<br />
promotion. For details, see “Clearing Remote QA Environments” on page 384.<br />
For traditional member/objects and IFS objects, this functionality is available<br />
using object code overrides. For details, see “Object Code Overrides” on page 91.<br />
Delete Locks (IMDLTLOCK)<br />
The IMDLTLOCK data area allows you to set default values on the Confirm Delete of Locks<br />
panel that displays when you select a member/object with option 4=Delete from the<br />
Workbench.<br />
You can specify different values for the deletion of locks, source, and objects. The valid data<br />
area values are *YES or *NO. The default value *YES sets the value to Y for all options. The<br />
value *NO sets the value to N for all options.<br />
You can also specify a three-character string consisting of a combination of Y and N to<br />
individually set each value. For example, if IMDLTLOCK is set to YYN, the result is Delete<br />
locks = Y, Delete sources = Y, Delete objects = N. If IMDLTLOCK is set to NYN, the result is<br />
Delete locks = N, Delete sources = Y, Delete objects = N.<br />
NOTE Users must have lock maintenance rights set to Y in the environment for<br />
authority to override these defaults. This is defined in Work with Environments,<br />
User Capabilities.<br />
Delay Evoked Jobs (IMDLYJOB)<br />
The IMDLYJOB data area allows you to place an evoked job into a delay state once the job<br />
becomes active. Working with remote jobs can be difficult, as a batch job on one machine<br />
initiates the job on another machine. Developers typically use this feature to capture specific
<strong>Implementer</strong> Data Areas<br />
diagnostic information at a customer site for debugging or tracing a job. It is also used when<br />
changes are required to a remote job, or to examine characteristics of a job before it begins to<br />
implement changes.<br />
The data area is located on both the host system and the remote system.Valid values are *YES<br />
or *NO enclosed in single quotes. The default value ‘*NO’ allows the job to continue<br />
normally without delay. The value *YES immediately places the evoked job into a delay state<br />
upon going active and sends a message to the QSYSOPR message queue stating that the job is<br />
in delay status. The job delays for one minute before going active again. It delays another<br />
minute and repeats indefinitely until you change the data area value to *NO.<br />
Domino Server Data Directory (IMDOMDATA)<br />
The IMDOMDATA data area allows you to record the server data directory that <strong>Implementer</strong><br />
uses to call the Domino API. This is only required when using Domino 6.0 and the Domino<br />
server does not use the Domino 5 default data directory /notes/data.<br />
The data area value is blank by default. If necessary, change the value to the actual Domino<br />
data directory being used.<br />
NOTE For details on the <strong>Implementer</strong> and Lotus Domino integration, see “Lotus<br />
Domino Integration” on page 336.<br />
Display Message Panel (IMDSPMSG)<br />
The IMDSPMSG data area is used in Work with Objects to control the display of a message<br />
when filtering the subfile using only the Object Status field.<br />
The valid data area values are *YES or *NO enclosed in single quotes. The default value<br />
‘*YES’ displays a message explaining that filtering on object status only can be time<br />
consuming. The message allows you to continue with the selected filter, or return to specify<br />
additional filters. The value *NO bypasses the message altogether.<br />
Emergency Request Submit Through Step (IMEMGSTP)<br />
The IMEMGSTP data area allows you to redefine the default auto submit through step for<br />
emergency promotion requests.<br />
The valid numeric values for IMEMGSTP are 2 (compile), 3 (distribute), or 4 (move), enclosed<br />
in single quotes. The default value is ‘4’.<br />
FTP Passive Mode (IMFTPPASV)<br />
The IMFTPPASV data area allows you to control how <strong>Implementer</strong>’s FTP transfer uses<br />
passive mode when sending files using TCP/IP. Passive mode eliminates the requirement on<br />
the receiving system to open a dedicated port for the host to connect to.<br />
405
Appendix A: <strong>Implementer</strong> Data Areas and User Exit Programs<br />
406<br />
The data area is located on both the host system and the remote system. Valid values are<br />
*YES or *NO enclosed in quotes. The default value “*YES” uses passive mode. Set the value<br />
to “*NO” to use non passive mode.<br />
IMPORTANT Most users do not change this data area. You should change the value<br />
only if your network configuration requires FTP transfers using non passive mode.<br />
JDK Version (IMJDKVER)<br />
The IMJDKVER data area relates to using <strong>MKS</strong> Integrity for issue management with<br />
<strong>Implementer</strong>. The data area allows you to store the Java Development Kit (JDK) version to<br />
use when using the Update <strong>MKS</strong> Integrity (IUPDCI) command to update <strong>MKS</strong> Integrity on<br />
an AIX system. This is required only if the target <strong>MKS</strong> Integrity Server runs on an AIX system<br />
(JDK version 1.4 is required on the client for communications).<br />
The default data area value is ‘1.2’ enclosed in single quotes. To use the IUPDCI command<br />
on an AIX system, you must install JDK version 1.4 on the iSeries, and change the IMJDKVER<br />
data area value to ‘1.4’. On OS/400 V5R2, you can install JDK version 1.4 from the IBM<br />
license product installation CD. On OS/400 V5R1, install JDK version 1.4 by ordering the<br />
required PTFs from IBM.<br />
NOTE For details on using <strong>MKS</strong> Integrity with <strong>Implementer</strong>, see “<strong>Implementer</strong> and<br />
<strong>MKS</strong> Integrity Integration” on page 196.<br />
<strong>Implementer</strong> Library Name (IMLIBRARY)<br />
The IMLIBRARY data area contains the name of the <strong>Implementer</strong> product library. It is a 10character<br />
data area. You must enclose the value in single quotes. The default value is<br />
‘<strong>MKS</strong>IM’.<br />
Change the data area value if you rename the <strong>Implementer</strong> library after initial installation, or<br />
if you require a parallel installation of the product (two versions of <strong>Implementer</strong> on the same<br />
system). When you install <strong>Implementer</strong> with a name other than <strong>MKS</strong>IM, the data area value<br />
is appropriately set by the installation procedure.<br />
NOTE If you have <strong>Implementer</strong> enabled for AllFusion 2E, (you received the<br />
<strong>Implementer</strong> product from Computer Associates), the default product library is<br />
Y2SYCM. When <strong>Implementer</strong> is installed with a name other thanY2SYCM, the<br />
installation procedure appropriately sets the data area value.<br />
Log Evoked Programs (IMLOGCL)<br />
The IMLOGCL data area allows you to change the logging level on <strong>Implementer</strong>-evoked<br />
jobs. The data area is located on both the host system and the remote system. It is useful<br />
when a unique job description is not available for <strong>Implementer</strong> on the remote system, and<br />
changing the logging level is not possible without impacting other users on the system.
<strong>Implementer</strong> Data Areas<br />
This value affects jobs evoked on the host after a remote initiated move is submitted on the<br />
remote. The valid data area values are *YES or *NO enclosed in single quotes. The default<br />
value ‘*NO’ allows logging as currently defined. The value *YES changes the job to log CL<br />
instructions with the maximum message logging level 4 0 *SECLVL. This ensures logging of<br />
all messages and retains the job log upon job termination.<br />
Submit Multiple Jobs (IMMULTJOB)<br />
The IMMULTJOB data area allows you to submit multiple jobs when submitting promotion<br />
requests. Valid values for the data area are *YES or *NO enclosed in single quotes. The<br />
default value ‘*YES’ allows the submission of multiple jobs. The value *NO does not submit<br />
multiple jobs.<br />
Once a promotion request is submitted <strong>Implementer</strong> determines whether the request was<br />
submitted to multiple jobs or a single job. This requires:<br />
The Add related objs to request field set to N (in Work with Environments) for all target<br />
environments on the request.<br />
The Compile required field set to N (in Work with Environments) for all target<br />
environments on the request. If Compile required=Y, the compile phase must be<br />
complete.<br />
For requests that target multiple environments or an environment group, you cannot use<br />
the Move Request by System/Environment option to override the request and submit<br />
the move on a per-environment basis.<br />
For requests that target a specific system, you cannot use the Move Request by System/<br />
Environment options 10=Distribute all, 11=Move all, or 12=Distribute and move all, to<br />
submit the distribution or move.<br />
Multiple Object Single Source Check Out (IMMULTOBJ)<br />
The IMMULTOBJ data area allows you to check out multiple objects that have single source<br />
members, allowing the single source member to create multiple objects. This practice, most<br />
common with physical files, works for all source-based objects.<br />
The valid values for the data area are *YES or *NO enclosed in single quotes. The default<br />
value ‘*NO’ does not allow checking out an object that has multiple objects with the same<br />
source member. Set the value to *YES to allow checking out an object that has multiple objects<br />
with a single source member.<br />
IMPORTANT Checking out a single source member with multiple objects is not<br />
considered a concurrent development condition. Therefore, if you enable<br />
IMMULTOBJ, be aware you could easily overwrite changes to work in process—<br />
that is, objects checked out and changed but not promoted through to production.<br />
407
Appendix A: <strong>Implementer</strong> Data Areas and User Exit Programs<br />
408<br />
Allow Member/Object on Multiple Requests (IMMULTRQS)<br />
The IMMULTRQS data area controls whether a member/object is allowed on multiple open<br />
promotion requests concurrently.<br />
Valid values for the data area are *NO or *YES enclosed in single quotes. The default value<br />
‘*NO’ does not allow an item on multiple promotion requests. Set the value to *YES to allow<br />
an item on multiple promotion requests.<br />
LANSA Error Messages (IMLNMSG)<br />
The IMLNMSG data area allows you to store the message IDs of LANSA errors you want to<br />
force a request to fail on when the error occurs during promotion processing. Fatal messages<br />
automatically cause the promotion to fail. During promotion, <strong>Implementer</strong> compares the<br />
message IDs written in the spool file of the export list to the message IDs recorded in the<br />
IMLNMSG data area. When a match is established, processing of the promotion job ends.<br />
This default data area value is blank. To store multiple messages IDs, separate the message<br />
IDs with a blank space.<br />
LANSA Partition Security Officer (IMLNPSO)<br />
The IMLNPSO data area allows you to store the name of the LANSA partition security<br />
officer. <strong>Implementer</strong> runs the LANSA command for export/import using the partition<br />
security officer profile to prevent migration failures caused by insufficient authority to the<br />
LANSA command and the items being exported.<br />
The data area is located on both the host system and the remote system and must be set on<br />
each system. The default data area value is blank. To change the data area, specify the<br />
partition security officer name in positions 1 through 10.<br />
LANSA Task Usage (IMLNTSK)<br />
The IMLNTSK data area allows you to enable LANSA task tracking in <strong>Implementer</strong>. Task<br />
tracking allows <strong>Implementer</strong> to process LANSA tasks as project numbers by creating an<br />
<strong>Implementer</strong> project record from the specified task number (if it does not already exist).<br />
The default data area value is *NO. Set the value to *YES to enable task tracking and for<br />
integration with Visual LANSA. For details, see “LANSA Task Tracking” on page 332 and<br />
“Visual LANSA” on page 332.<br />
Creation Commands That Allow the TGTRLS Parameter (IMPRVCMDS)<br />
The IMPRVCMDS data area allows you to store a list of creation commands that accept the<br />
Target Release (TGTRLS) parameter to perform local compiles for a remote environment.<br />
You can add other creation commands to the data area, although you do not need to change<br />
it often. For example, adding a command can be required if a new object is created by an<br />
upgrade to the operating system and you do not have the required version of <strong>Implementer</strong>.
Path Slash (IMPATHSLSH)<br />
<strong>Implementer</strong> Data Areas<br />
The IMPATHSLSH data area is used for the development of IFS and DLO objects on a non<br />
English system. IFS and DLO objects have a backward slash (\) in the object path; however,<br />
the actual backward slash character is not the same character for all languages. The data area<br />
allows you to specify the translated character to substitute for the backward slash. The<br />
default data area value is ‘\’.<br />
Process Package (IMPKGPRC)<br />
The IMPKGPRC data area is used with the release management features of <strong>Implementer</strong>. It<br />
allows you to define how to handle a package creation job if an error occurs with member/<br />
objects when creating the package. Valid values are as follows:<br />
Blank Terminates the package creation job and deletes the package.<br />
*FAILEND Processes the job through to the end, ends in failure, and deletes<br />
package. Messages are sent of member/object errors.<br />
*PROCESS Processes all member/objects but does not add member/objects with<br />
errors. Messages are sent of skipped members/objects.<br />
Work Library Prefix (IMPRFX)<br />
The IMPRFX data area contains the prefix assigned to the name of all <strong>Implementer</strong> work<br />
libraries. The data area is located on both the host system and the remote systems. It is three<br />
characters in length. Most work libraries use all three characters, but some use only the first<br />
two characters. You must enclose the value in single quotes. The default value is ‘IM’.<br />
When using two parallel versions of <strong>Implementer</strong>, you must change the data area so that one<br />
version of <strong>Implementer</strong> uses a different prefix of work libraries. You can also change the<br />
prefix to set the work libraries to follow internal naming conventions.<br />
Remove Member/Object From QA on Reject (IMREJECT)<br />
The IMREJECT data area controls how <strong>Implementer</strong> handles source and objects when<br />
checking out for reject from a *QAC environment. It allows you to reject member/objects<br />
from QA and check them back into development on the original lock. The source (for source<br />
based objects) or object (for non source based objects) is copied back into development from<br />
QA. The lock is redirected to development for continued programming effort. By requiring<br />
locks on promotion requests, the items in QA remain for further testing and not promoted to<br />
the next QA or production environment, while development continues.<br />
The data area also controls the default value that displays in the Delete Member/Objects field<br />
on the Delete Member/Objects While Rejecting window when an item is selected for reject.<br />
The valid data area values area *YES or *NO enclosed in single quotes. The default value<br />
‘*NO’ sets the field defaults to N and retains member/objects in QA. Set the value to *YES to<br />
set the field defaults to Y and delete member/objects from QA.<br />
409
Appendix A: <strong>Implementer</strong> Data Areas and User Exit Programs<br />
410<br />
Regardless of the data area value the field values can be overridden during check out. You<br />
can also set <strong>Implementer</strong> to bypass the display of the Delete Member/Objects While<br />
Rejecting window and enforce the rules set by the IMREJECT data area. For details, see<br />
“Bypass Window on Reject From QA (IMBYPSRJW)” described next.<br />
Bypass Window on Reject From QA (IMBYPSRJW)<br />
The IMBYPSRJW data area allows you to control the display of the Delete Member/Objects<br />
While Rejecting window when rejecting items from a *QAC environment.<br />
The default data area value *NO enables the window display. Set the value to *YES to bypass<br />
the window display. For example, if source and object always remains in QA when rejecting<br />
and developers are not allowed to override the rule, set the IMREJECT data area to *NO, and<br />
set the IMBYPSRJW data area to *YES.<br />
Reclaim Group (IMRCLAGRP)<br />
When exiting the <strong>Implementer</strong> main menu, the Reclaim Activation Group (RCLACTGRP)<br />
command automatically executes. If you use activation groups or ASC Sequel, the command<br />
causes user programs that use activation groups to fail, and causes ASC Sequel to fail after<br />
<strong>Implementer</strong> runs and ends in an iSeries session.<br />
The IMRCLAGRP data area allows you to control execution of the RCLACTGRP command<br />
when exiting the <strong>Implementer</strong> main menu. The default data area value is ‘*YES’. Change<br />
the value to ‘*NO’ to bypass execution of the RCLACTGRP command.<br />
Return File and Member ID After Promotion (IMRETFILID)<br />
The IMRETFILID data area allows you to retain existing file and member IDs when<br />
promoting physical files and logical files. The data area is located on both the host system<br />
and the remote systems.<br />
The default value *NO deactivates the feature. Set the value to *YES on both the host and<br />
remote to retain the file and member IDs on both systems. The file and member IDs are taken<br />
out of the from file and applied to all target files. If the file exists in the From environment,<br />
the file and member IDs are derived from that file. If the file does not exist in the From<br />
environment, the file and member IDs are derived from the object created in the <strong>Implementer</strong><br />
work library. Exceptions to this general rule are:<br />
When a PF and related LFs do not exist in the From environment and a request is created<br />
for the PF with the LFs added as related objects, the file and member IDs for the PF come<br />
from the object created in the <strong>Implementer</strong> work library, and the file and member IDs for<br />
the LFs come from the target logical files.<br />
When targeting a remote environment that has the source library/compile location set to<br />
R (remote), the compile option must be set to N to retain the file and member IDs.
Sequential Request (IMSEQRQS)<br />
<strong>Implementer</strong> Data Areas<br />
The IMSEQRQS data area pertains to the processing sequence of promotion requests for<br />
environments that are not compiled. This does not apply to emergency promotions. By<br />
default, <strong>Implementer</strong> processes all compile requests based on a compile date edit. For<br />
environments with the Compiled Required field set to N, this data area allows you to bypass<br />
the date edit and process requests sequentially by request number.<br />
The default data area value *NO allows all requests to process based on the date edit. Change<br />
the value to *YES to bypass the date edit when not compiling and allow promotions to<br />
process in request number sequence.<br />
Special Commands (IMSPCCMD)<br />
The IMSPCCMD data area contains a list of <strong>Implementer</strong> commands that are available as<br />
special commands. The commands can be used as special commands without having the<br />
<strong>Implementer</strong> library in the library list of the target environment. All other special commands<br />
require the <strong>Implementer</strong> library in the target library list or a qualified library name. Users do<br />
not maintain this data area.<br />
NOTE To issue <strong>Implementer</strong> commands as special commands, the product library<br />
(<strong>MKS</strong>IM is the default) must be on the environment library list. For AllFusion 2E,<br />
the product library (Y2SYCM is the default) must be on the environment library list.<br />
Save Program Name (IMSVPGM)<br />
The IMSVPGM data area pertains to the Archive to Tape feature. It allows you to identify a<br />
third party save/restore utility to a create off-line storage of archived information. For<br />
example, you can use IBM’s Backup Restore Management System (BRMS) or your own<br />
version of a save/restore utility.<br />
This is a 20 character data area: Positions 1 through 10 store the library name associated with<br />
internal program, and positions 11 through 20 store the name of the internal program.<br />
This feature also requires defining values to a skeleton program named IMSVLB2 located in<br />
the <strong>Implementer</strong> source file QSAMPLE. For detailed information on setting up to use a third<br />
party save/restore utility, see “BRMS/400 Integration” on page 322.<br />
Promotion Batch Step Test Mode (IMTSTMOD)<br />
The IMTSTMOD data area controls when promotion batch steps are performed, and whether<br />
they run in test mode or real mode. This feature is only useful for testing purposes and used<br />
under the direction of <strong>MKS</strong> Customer Care. The data area values are as follows.<br />
*NO The job continues as normal. This is the default value.<br />
411
Appendix A: <strong>Implementer</strong> Data Areas and User Exit Programs<br />
412<br />
*MSG Activates additional messaging during the batch promotion of a request<br />
and allows it to run without actually compiling or moving items. Each<br />
internal phase of the request receives a cryptic start/end message to<br />
accurately determine the internal phase being processed, helping to<br />
identify which part of the promotion completed and which part is<br />
processing when an error occurs. This is useful to identify some<br />
promotion problems. Customer Care may request you change the setting<br />
if additional information in needed.<br />
*YES Do not use without direction from Customer Care. Causes all promotion<br />
requests to appear as though related processing is complete, but does not<br />
actually compile or move objects. The job completes successfully and the<br />
request is set to completed status. When active, there are no messages<br />
about individual items on the request being compiled or moved, and<br />
instead of calling the compile or move programs, the program names are<br />
listed in the job log to show when they would be called.<br />
Invalid Logical File Control (IMWRNTRGLF)<br />
The IMWRNTRGLF data area controls how <strong>Implementer</strong> handles the recompile of logical<br />
files implicitly added to a promotion request that results in compile fail status, for example,<br />
due to missing or invalid source.<br />
The data area is located on both the host and remote systems, but currently only used on the<br />
remote system. Valid values are as follows.<br />
*ABT The promotion aborts. This is the default value.<br />
*DLT Deletes the invalid logical files and generates the Display File Description<br />
(DSPFD) and Display File Field Description (DSPFFD) reports to allow<br />
manually recreating the logical files.<br />
*INQ The promotion pauses and prompts for an action to continue. Valid replies<br />
are D to delete the logical file and C to cancel the request.<br />
Next Tape Label (ITAPEVOLUM)<br />
The ITAPEVOLUM data area controls the next volume ID for archives saved to tape.<br />
<strong>Implementer</strong> automatically initializes a tape with volume ID ARC###, where ### is a number<br />
starting with 001 that increments for each archive saved. The data area does not usually<br />
require a manual change.<br />
Reference File to Set Authority (LFREFOBJ, PFREFOBJ)<br />
The LFREFOBJ and PFREFOBJ data areas control the authority used to promote physical and<br />
logical files. It is a 20-character data area. Positions 1 through 10 store a file name, and<br />
positions 11 through 20 store a library name. The file specified is used as the reference object<br />
when setting authority to PFs and LFs on a promotion. If the data area value is blank, the<br />
authority to promote PFs and LFs is based on the value specified in the environment<br />
definition.
Receiver Library Name (RCVLIB)<br />
<strong>Implementer</strong> Data Areas<br />
The RCVLIB data area on the host system contains the name of the <strong>Implementer</strong> Receiver<br />
library for the remote system. It is a 10-character data area enclosed in single quotes. The<br />
default value is ‘<strong>MKS</strong>IR’.<br />
Change the data area value only if you use an <strong>Implementer</strong> Receiver library name other than<br />
<strong>MKS</strong>IR on the remote system, or if you are running two parallel versions of <strong>Implementer</strong>,<br />
and <strong>Implementer</strong> is used to send changes to remote systems.<br />
NOTE If you have <strong>Implementer</strong> enabled for AllFusion 2E CM, this data area is in the<br />
AllFusion 2E host library Y2SYCM and contains the name of the AllFusion 2E CM<br />
Receiver library on the remote system (the default is Y2SYCR).<br />
Authorized User of IFS Objects (SDMAUTUSR)<br />
The SDMAUTUSR data area stores the user profile <strong>Implementer</strong> uses to manage all objects<br />
that exist outside of the QSYS library, for example, IFS files and directories.<br />
The default value is ‘SDMAUTUSR’ (enclosed in single quotes). The user profile is created<br />
with a random password and the following characteristics: all object special authority,<br />
enabled status, a current (non expired) password.<br />
To use a different profile, specify a user profile that has the same characteristics to enable<br />
<strong>Implementer</strong> to properly manage objects outside of the QSYS library. Use the Change User<br />
Profile (CHGUSRPRF) command to set the characteristics as follows:<br />
CHGUSRPRF USRPRF(name)<br />
PASSWORD(password)<br />
STATUS(*ENABLED)<br />
SPCAUT(*ALLOBJ)<br />
PWDEXPITV(*NOMAX)<br />
In addition, the user profile must be enrolled in the system distribution directory by using the<br />
Work with Directory Entries (WRKDIRE) command. A user ID entry of *ALL is not sufficient.<br />
IMPORTANT <strong>Implementer</strong> uses the SDMAUTUSR user profile and password to<br />
access an NT Server for IFS object management on a mounted drive. For this<br />
purpose the user profile and password must be identical and the values defined on<br />
the iSeries must be the same user profile and password defined on the NT Server.<br />
For details, see “Mounted Drive Support for IFS Objects” on page 159.<br />
Remote Job Queue (IRJOBQ)<br />
The IRJOBQ data area contains the name of the remote job queue. It is used along with data<br />
area IRSBMMTD, which stores the job submission method. The data area is located on the<br />
remote system in the <strong>Implementer</strong> Receiver library (default is <strong>MKS</strong>IR).<br />
413
Appendix A: <strong>Implementer</strong> Data Areas and User Exit Programs<br />
414<br />
This is a 20 character data area. Positions 1 through 10 store the job queue name, and<br />
positions 11 through 20 store the library name. You must enclose the values in single quotes,<br />
for example, ‘QBATCH *LIBL ‘.<br />
Remote Job Submission Method (IRSBMMTD)<br />
The IRSBMMTD data area contains the submission method for remote jobs. The data area is<br />
located on the remote system in the <strong>Implementer</strong> Receiver product library.<br />
This is a one character data area. Valid values are 0 or 1, enclosed in single quotes, for<br />
example, ‘1’.<br />
Work Library Cleanup (IMWLCLNUP)<br />
The IMWLCLNUP data area is used with the release management features of <strong>Implementer</strong><br />
when using multiple <strong>Implementer</strong> Receivers on the same iSeries. The data area allows you to<br />
install the same delivery on each remote system by controlling the deletion of the<br />
<strong>Implementer</strong> work libraries used during delivery installation.<br />
The data area is located on the remote system in the <strong>Implementer</strong> Receiver library <strong>MKS</strong>IR.<br />
The default data area value *YES deletes the work libraries. Set the value to *NO to retain the<br />
work libraries. Set the value to *NO on each <strong>Implementer</strong> Receiver, and then change it to<br />
*YES before installing the last delivery. For more information, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong><br />
Release Management <strong>Guide</strong>.<br />
Customizing <strong>Implementer</strong><br />
<strong>Implementer</strong> provides the source file QSAMPLE, which is an ever-growing source of<br />
technical information that helps you to further customize <strong>Implementer</strong>. The source file is<br />
located in the <strong>Implementer</strong> product library <strong>MKS</strong>IM.<br />
User Exit Programs<br />
IMPORTANT Check the latest <strong>MKS</strong> <strong>Implementer</strong> Release Notes for release-related<br />
changes to QSAMPLE that may require recompiling your modified source<br />
programs.<br />
The following is a partial list of the user exit programs provided in QSAMPLE. Refer to the<br />
source in QSAMPLE for more details on these and other user exit programs.
Program Name Description<br />
Customizing <strong>Implementer</strong><br />
IMPRMV3 Allows you to customize the setting of authorities on objects promoted through<br />
<strong>Implementer</strong>.<br />
IMCODF Allows you to customize path defaults during check out.<br />
IMCRDF Allows you to customize path defaults during create request.<br />
IMCOMO8 Allows you to customize concurrent development processing. To set concurrent<br />
development to include only the items checked out from the same environment,<br />
see “Concurrent Development Scope” on page 71.<br />
IMUPDLCK Allows you to bypass updating the source/object locks on a request after the<br />
successful move of source/objects to the specified environment.<br />
When using programs from QSAMPLE, <strong>MKS</strong> recommends you place them in a library other<br />
than the <strong>Implementer</strong> product library, for example, <strong>MKS</strong>IMMOD, so they are not affected by<br />
product upgrades. You must add the modified library to the interactive library lists for all<br />
users, as well as the library list of any batch programs that use the commands. In addition,<br />
when using a modification library you must change the <strong>Implementer</strong> commands to remove<br />
the default product library parameter from all commands (the default product library name<br />
is <strong>MKS</strong>IM).<br />
Edit Library List Command<br />
The Edit Library List (IEDTLIBL) command allows you to modify the library list of an<br />
<strong>Implementer</strong> environment. You must have authority to the environment and standard move<br />
capabilities for the environment library list you want to modify.<br />
The command is located in the <strong>Implementer</strong> product library in source file QSAMPLE. For<br />
detailed instructions on creating the command, refer to the comments in the IEDTLIBL<br />
command source in QSAMPLE.<br />
You prompt the command from a command line, specify the Environment name and<br />
<strong>Implementer</strong> library parameters, and press ENTER to retrieve the current library list of the<br />
specified environment. Libraries can be added to the end or middle of the list (they are added<br />
in the order entered).<br />
To add a library to an environment’s library list, type the greater-than character (>) in the<br />
Control field.<br />
To remove a library from an environment’s library list, type the less-than character (
Appendix A: <strong>Implementer</strong> Data Areas and User Exit Programs<br />
416<br />
IEDTLIBL Command Parameters<br />
Environment Name<br />
Specify the name of the environment associated with the library list to modify.<br />
<strong>Implementer</strong> Library<br />
Specify the name of the <strong>Implementer</strong> product library (default product library is <strong>MKS</strong>IM).<br />
Specify another name if you changed the product library name when you installed<br />
<strong>Implementer</strong>.<br />
Library List Type<br />
Specify the system location of the library. Valid values are (L) Local or (R) Remote. The<br />
default value is L. When setting a local and remote library list for an environment, you must<br />
create two separate lists. The command does not support both local and remote libraries in<br />
the same list.<br />
Library<br />
Specify the name of the library to add or remove from the list.
A PPENDIX B<br />
Environment Examples<br />
A <strong>Guide</strong> to Setting Up Environments<br />
B<br />
This appendix provides setup examples of typical environments for the most common<br />
development scenarios. Although the examples do not describe all possible settings, they<br />
may be helpful when initially setting up <strong>Implementer</strong>.<br />
The examples illustrate specific environment settings for the following environment<br />
types:<br />
“Local Production” on page 418<br />
“Local Development” on page 419<br />
“Local Quality Assurance” on page 420<br />
“Local User Acceptance” on page 422<br />
“Remote Production” on page 423<br />
417
Appendix B: Environment Examples<br />
Local Production<br />
418<br />
The following table describes how to define an environment for local production.<br />
Field Description<br />
Environment Specify the environment name. It is helpful to design a recognizable<br />
naming convention, for example, AR_PRD.<br />
Description Specify a brief description of the environment, for example, Demo 1<br />
Production.<br />
Administrator Specify the <strong>Implementer</strong> administrator profile.<br />
Env type Specify the type of environment. Valid options are *PRD (production),<br />
*QAC (quality assurance), and *TST (development).<br />
Library defaults<br />
Specify the program library, files library, source library, and archive library names. If the libraries do not<br />
exist, <strong>Implementer</strong> automatically creates them when promoting a request to the environment. The<br />
library owner is the user profile defined in the Lib owner fields.<br />
Library Owner,<br />
Object Owner<br />
Applies to new objects created in <strong>Implementer</strong>, when you run Reset<br />
Authorities for an environment.<br />
Archive Versions Specify the number of archive versions to keep (up to 99 versions).<br />
Create request defaults: CHG fields<br />
The Chg field, parallel to the next four fields, controls whether you can change (override) these values<br />
when creating a promotion request that targets this environment. Specify Y to allow overrides.<br />
Compile required Yes. Allows auto submit in create request.
Field Description<br />
Local Development<br />
The following table describes how to define an environment for local development.<br />
Local Development<br />
Auto submit in create rqs Yes. Allows automatic promotion within a request to one of four levels:<br />
compile, distribute and move, or export (if a LANSA environment).<br />
Through step 2 (automatically promotes through the compile step).<br />
Add related objects to rqs Yes (automatically adds related objects to a promotion request) for<br />
compile purposes. Related environments include all programs related<br />
to a file, as well as all related ILE components.<br />
Check out required Yes. Members/objects require check out before adding them to a<br />
promotion request. You must also check out newly created members/<br />
objects, or have the name reserved.<br />
Allow authority overrides Yes. Allows changing object authority on a promotion request from<br />
*KEEP to *GRANT.<br />
Field Description<br />
Environment Specify the environment name. It is helpful to design a recognizable<br />
naming convention, for example, AR_TST.<br />
Description Specify a brief description of the environment, for example,<br />
Developer’s Development Env.<br />
Administrator Specify the <strong>Implementer</strong> administrator profile.<br />
419
Appendix B: Environment Examples<br />
Local Quality Assurance<br />
420<br />
Field Description<br />
Env type Specify the type of environment *TST (development), *QAC (quality<br />
assurance), or *PRD (production).<br />
Library defaults<br />
Specify the program library, files library, source library, and archive library names.<br />
Library Owner,<br />
Object Owner<br />
Applies to new objects created in <strong>Implementer</strong>, when you run Reset<br />
Authorities for an environment.<br />
Archive Versions Development usually does not archive versions.<br />
Create request defaults: CHG field<br />
Yes. The Chg field, parallel to the next four fields, controls whether you can change the corresponding<br />
field values when working with this environment.<br />
Compile required No.<br />
Auto submit in create rqs No. Does not allow automatic promotion of a request.<br />
Submit through step Specify a value (1–4) even if the previous step is set to N.<br />
Add related objects to rqs Yes. Automatically adds related objects to a promotion request.<br />
Check out required No. Member/objects do not require check out before adding them to a<br />
promotion request.<br />
Allow authority overrides No. Not allowed to change object authority on a promotion request.
Local Quality Assurance<br />
The following table describes how to define an environment for local quality assurance.<br />
Field Description<br />
Environment Specify the environment name. It is helpful to design a recognizable<br />
naming convention, for example, AR_QAC.<br />
Description Specify a brief description of the environment, for example, Quality<br />
Assurance Env.<br />
Administrator Specify the <strong>Implementer</strong> administrator user profile.<br />
Env type Specify the type of environment, *TST (development), *QAC (quality<br />
assurance), or *PRD (production).<br />
Library defaults<br />
Specify the program library, files library, source library, and archive library names.<br />
Library Owner,<br />
Object Owner<br />
Applies to new objects created in <strong>Implementer</strong>, when you run Reset<br />
Authorities for an environment.<br />
Archive Versions Specify the number of archive versions to keep (up to 99 versions).<br />
Create request defaults: CHG field<br />
Yes. The Chg field, parallel to the next four fields, controls whether you can change the corresponding<br />
field values when working in this environment.<br />
Compile required Yes. Members are usually compiled before promoting to a test<br />
environment.<br />
Auto submit in create rqs Yes. Allows automatic promotion of a request to 1 of 4 levels: compile,<br />
distribute and move, or export (if a LANSA environment).<br />
Submit through step 2 (automatically promotes through the compile step).<br />
Add related objects to rqs Yes. Automatically adds related objects to a promotion request.<br />
Check out required Yes. Members/objects require check out before adding them to a<br />
promotion request. You must also check out newly created members/<br />
objects.<br />
Allow authority overrides No. Not allowed to change object authority on a promotion request.<br />
421
Appendix B: Environment Examples<br />
Local User Acceptance<br />
422<br />
The following table describes how to define an environment for local user acceptance.<br />
Field Description<br />
Environment Specify the environment name. It is helpful to design a recognizable<br />
naming convention, for example, USRACPT.<br />
Description Specify a description of the environment, for example, User<br />
Acceptance Env.<br />
Administrator Specify the <strong>Implementer</strong> administrator user profile.<br />
Env type Specify the type of environment, *TST (development), *QAC (quality<br />
assurance), or *PRD (production).<br />
Library defaults<br />
Specify the program library, files library, source library, and archive library names.<br />
Library Owner,<br />
Object Owner<br />
Applies to new objects created in <strong>Implementer</strong>, when you run Reset<br />
Authorities for an environment.<br />
Archive Versions Specify the number of archive versions to keep (up to 99 versions).
Field Description<br />
Remote Production<br />
Remote Production<br />
Create request defaults: CHG field<br />
Yes. The Chg field, parallel to the next four fields, controls whether you can change the corresponding<br />
field values when working with this environment.<br />
Compile required No.<br />
Auto submit in create rqs Yes. Allows automatic promotion of a request to 1 of 4 levels: compile,<br />
distribute and move, or export (if a LANSA environment).<br />
Submit through step 2 (automatically promotes through the compile step).<br />
Add related objects to rqs Yes. Automatically adds related objects to a promotion request.<br />
Check out required Yes. Members/objects require check out before adding them to a<br />
promotion request. You must also check out newly created members/<br />
objects.<br />
Allow authority overrides No. Not allowed to change object authority on a promotion request.<br />
Defining an environment for remote production requires the entry of information in various<br />
fields across three Work with Environments panels. Press PAGE DOWN to access each panel.<br />
423
Appendix B: Environment Examples<br />
424<br />
The following table describes how to define an environment for remote production.<br />
Field Description<br />
Environment Specify the environment name. It is helpful to design a recognizable<br />
naming convention, for example, RMTSYS1.<br />
Description Specify a brief description of the environment, for example, Remote<br />
Production # 1.<br />
Administrator Specify the <strong>Implementer</strong> administrator.<br />
Env type Specify the type of environment, *PRD (production), *QAC (quality<br />
assurance), or *TST (development).<br />
Library defaults<br />
Specify the program library, files library, source library, and archive library names.<br />
Library Owner,<br />
Object Owner<br />
Applies to new objects created in <strong>Implementer</strong>, when you run Reset<br />
Authorities for an environment.<br />
Archive Versions Specify the number of archive versions to keep (up to 99 versions).<br />
Create request defaults: CHG field<br />
Yes. The Chg field parallel to the next four fields controls whether you can change the corresponding<br />
field values when working in this environment.<br />
Compile required No.<br />
Auto submit in create rqs Yes. Allows automatic promotion of a promotion request to 1 of 4<br />
levels: compile, distribute and move, or export if a LANSA<br />
environment.<br />
Submit through step 4 (automatically promotes through the Move step).<br />
Add related objects to rqs Yes. Automatically adds related objects to a promotion request.
Press PAGE DOWN to access the second Create Environment panel.<br />
Field Description<br />
Remote Production<br />
Check out required No. Members/objects do not require check out before adding them<br />
to a promotion request.<br />
Allow authority overrides No. Not allowed to change object authority on a promotion request.<br />
Special environment For a remote environment, this must be a standard LANSA or<br />
PeopleSoft World environment, not an AllFusion 2E or AS/SET<br />
environment.<br />
Issue required for check out Specify whether you require an issue for all check out activity<br />
(requires <strong>MKS</strong> Integrity installed for issue tracking).<br />
When DesignTracker is used for issue management, this field name<br />
is Design Request required for check out.<br />
Project reference required Specify whether you require a project for check out.<br />
Retain error-free job logs Specify Y or N to indicate whether to maintain error-free job logs in<br />
an <strong>Implementer</strong> database file.<br />
Remove obj in from lib/env Specify 2=Never (<strong>Implementer</strong> never deletes items from remote<br />
production environments).<br />
Remove src in from lib/env Specify 2=Never (<strong>Implementer</strong> never deletes items from remote<br />
production environments).<br />
Maintain related object info Specify Y or N, as needed. If Y, complete the next four fields as<br />
needed based on the source of related object information.<br />
Source of information Specify the source of related object information. Valid options are<br />
1=<strong>Implementer</strong> or 2=Hawkeye PathFinder.<br />
PathFinder X-ref library Specify the PathFinder x-ref library where related object information<br />
is stored if PathFinder maintains related objects.<br />
Update PathFinder X-ref Specify whether to automatically update PathFinder information<br />
during request promotion.<br />
DOCLIBL for X-ref updates Specify the documentation library list name in PathFinder that<br />
contains the library names of cross-referenced objects.<br />
425
Appendix B: Environment Examples<br />
426<br />
Press PAGE DOWN to access the third Create Environment panel.<br />
Field Description<br />
When arrives in<br />
this env<br />
Specify the <strong>MKS</strong> Integrity issue state to set for an item when checked<br />
out or promoted to this environment. Required only if <strong>MKS</strong> Integrity is<br />
the issue tracking system.<br />
Name: Specify the name of a valid <strong>MKS</strong> Integrity status to assign.<br />
*DEFAULT: Assigns the appropriate <strong>MKS</strong> Integrity default value.<br />
For example, when an item is checked out to *TST environment,<br />
the default issue status for *TST is set. When promoted to *PRD<br />
environment, the default issue status for *PRD is set. If promoted<br />
to this environment and it is the first *QAC on the path, the issue<br />
status for *QAC1 is set; if second *QAC on the path, the issue<br />
status *QAC2 is set.<br />
*NONE: Status is not assigned or updated.<br />
For information on using <strong>MKS</strong> Integrity, see page 196.<br />
When rejected from this env Specify the <strong>MKS</strong> Integrity issue state to set for an item when rejected<br />
from this environment. Required only if <strong>MKS</strong> Integrity is the issue<br />
tracking system.<br />
Name: Specify the name of a valid <strong>MKS</strong> Integrity status to assign.<br />
*DEFAULT: Assigns the appropriate <strong>MKS</strong> Integrity default value.<br />
For example, when an item is rejected from this environment to the<br />
first *QAC environment on the path, the default status for *QAC1 is<br />
assigned; for the second *QAC environment on the path, the<br />
default status for *QAC2 is assigned.<br />
*NONE: Status is not assigned or updated.<br />
System Specify the system name defined in Network Configuration.<br />
Source library location L=Local (compile runs on host system, objects sent to remote).
Field Description<br />
Network Configuration<br />
Remote Production<br />
Compile location L=Local (compile runs on host system, objects sent to remote).<br />
Values for Source Library Location and Compile Location must be<br />
the same.<br />
Distribution method 4=SDMCom. SDM-Com is a feature of <strong>Implementer</strong> that improves<br />
performance 20–35% over SNADS distribution. Its advanced<br />
features use compression algorithms and blocking specifically for<br />
remote distributions.<br />
Remote initiated move Specify Yes or No for a remote operator to initiate moves.<br />
Updates host No. If Remote initiated move is set to Y, this field allows you to update<br />
the host with information such as job logs and messages.<br />
Retain requests on remote Specify whether to retain requests on the remote system.<br />
Promotion notification queue Specify the promotion notification queue on remote system.<br />
Target release Specify if the remote system is at a different release of the operating<br />
system than the host system. Useful when you have multiple<br />
environments that target a single remote, to specify different target<br />
release values for each environment.<br />
*NETCONFIG: Retrieves the value defined for Target Release<br />
parameter in menu option 46, Network Configuration. This is the<br />
default value.<br />
*CURRENT: Remote system is at same operating system level as<br />
host system.<br />
*PRV: Remote system is at an earlier release of the operating<br />
system.<br />
Name: Specify actual version name, for example, V5R2M0.<br />
This example describes the required fields and suggested values in Network Configuration<br />
for remote environments.<br />
427
Appendix B: Environment Examples<br />
428<br />
This is the first Network Configuration Maintenance panel<br />
Field Description<br />
System Specify the system name to send changes to (can only be defined when<br />
you define a new system).<br />
Description Specify a brief description of the system.<br />
Target release Specify the OS/400 release level of the remote (target) system.<br />
*CURRENT: Remote system is at same operating system level as host<br />
system.<br />
*PRV: Remote system is at an earlier release of the operating system.<br />
Name: Specify the version name, for example, V5R2M0.<br />
SNA Communications options<br />
The following options allow you to define how to distribute to the remote system.<br />
Remote location name Specify the name of the remote location that changes are sent to. If you<br />
use Network Control Program (NCP), this is the NCP system name. It is<br />
not the name displayed in Display Network Attributes (DPSNETA). The<br />
value *SYSTEM uses the current system name.<br />
Local location name Specify the name of the local location where changes are sent from.<br />
Mode name Specify the name of the system object that contains controlling information<br />
for an APPC session. Enter a specific mode name, or *NETATR to use the<br />
default identifier in the network attributes. If you created a communication<br />
mode for <strong>Implementer</strong>, use IMPMODD.
Field Description<br />
Remote network<br />
identifier<br />
Press PAGE DOWN to access the second Network Configuration Maintenance panel.<br />
Remote Production<br />
Specify the name of the remote network where the location resides<br />
(usually *NETATR).<br />
Name: Enter the specific name of the remote network.<br />
*NETATR: Name is taken from the network attributes.<br />
*LOC: System automatically selects the remote network ID.<br />
*NONE: Non remote network ID is used.<br />
SNADS user ID Specify the SNADS user ID used to send network files to the specified<br />
system. This is typically user profile MWIPROD. Use this ID only if you<br />
distribute to the remote via SNADS (determined by the distribution method<br />
defined for the environment in Work with Environments).<br />
SNADS user address Specify the SNADS user address used to send network files to the<br />
specified system. This is the remote system name.<br />
Name: Address used when enrolling user in SNADS directory entry.<br />
*SYSTEM: System name used for the address listed above (current<br />
system name).<br />
Field Description<br />
Switched line Specify Y or N whether the communications line is a switched line.<br />
Switched line name Specify the name of the switched line (required to auto vary on and auto<br />
vary off the line).<br />
Control unit name Specify the name of the control unit associated with the line to this<br />
system.<br />
429
Appendix B: Environment Examples<br />
430<br />
Field Description<br />
Auto vary on Specify whether to vary on the communications line, controller, and<br />
device before remote processing begins.<br />
Auto vary off Specify whether to vary off the communications line, controller, and<br />
device after remote processing completes.<br />
Remote wait time Specify the number of minutes the remote program waits before<br />
attempting to receive a network file (promotion request).<br />
Remote no. of retries Specify the number of times the remote program attempts to receive a<br />
network file. Each retry attempt waits for the number of minutes specified<br />
in the Remote Wait Time field. If the network file is not received after this<br />
number of retries, request processing ends and the request status is set<br />
to the appropriate failed status: Comp-fail, Dist-fail, or Move-fail.
A PPENDIX C<br />
Converting DesignTracker<br />
Data to <strong>MKS</strong> Integrity<br />
Migrating Legacy Data to <strong>MKS</strong> Integrity<br />
C<br />
This appendix is for DesignTracker customers who are converting to <strong>MKS</strong> Integrity for<br />
issue management and have a requirement to convert existing DesignTracker data to<br />
<strong>MKS</strong> Integrity issues. This allows you to make history visible in <strong>MKS</strong> Integrity and bring<br />
future work into <strong>MKS</strong> Integrity.<br />
The tasks in this chapter explain how to convert existing DesignTracker design requests<br />
(DRs), service requests (SRs), and DR entity information to <strong>MKS</strong> Integrity issues, by<br />
using the <strong>Implementer</strong> conversion tool.<br />
<strong>MKS</strong> can assist with converting your DesignTracker data to <strong>MKS</strong> Integrity by providing<br />
conversion assistance, as well as assist in defining your business processes and workflow<br />
to <strong>MKS</strong> Integrity. For more information on this option, contact <strong>MKS</strong> Customer Care.<br />
This appendix covers the following topics:<br />
“Requirements” on page 432<br />
“Overview” on page 432<br />
“Rules and Actions” on page 433<br />
“Generating and Configuring the Conversion Properties File” on page 441<br />
“Post Conversion Considerations” on page 454<br />
431
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
Requirements<br />
Overview<br />
432<br />
The following requirements apply to using this data conversion:<br />
Install or upgrade to <strong>Implementer</strong> <strong>2006</strong>, including configuring the <strong>Implementer</strong> Server.<br />
Install or upgrade to <strong>MKS</strong> Integrity <strong>2006</strong>.<br />
In addition, you must define you development process and workflow <strong>MKS</strong> Integrity,<br />
and any fields and field values you map must exist in <strong>MKS</strong> Integrity. For details on this<br />
topic, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
<strong>MKS</strong> Integrity is set as the default issue tracking system within <strong>Implementer</strong>, with<br />
DesignTracker co-existence enabled. These tasks are described in “Converting With Data<br />
Retention” on page 247.<br />
If you have already converted to <strong>MKS</strong> Integrity, you may have already completed the<br />
following requirements that are described in Chapter 5. To verify this:<br />
Review “Set the Last Allowed DR Number” on page 250 and make any necessary<br />
changes.<br />
Review “Set the Next Issue Number in <strong>MKS</strong> Integrity” on page 252 and make any<br />
necessary changes.<br />
Review “Set a User’s Default Issue Management System” on page 253 and make any<br />
necessary changes.<br />
The conversion tool uses the <strong>MKS</strong> Integrity Setup information defined in <strong>Implementer</strong> to<br />
communicate with <strong>MKS</strong> Integrity and create issues, as such, communications between<br />
<strong>Implementer</strong> and <strong>MKS</strong> Integrity must be active to use the conversion tool. For details on<br />
this topic, see “Defining <strong>MKS</strong> Integrity Values in <strong>Implementer</strong>” on page 226.<br />
<strong>MKS</strong> Integrity, unlike DesignTracker, has an enterprise focus that uses different process<br />
control mechanisms and field types than DesignTracker. As such, converting data to<br />
<strong>MKS</strong> Integrity using <strong>Implementer</strong>’s automated conversion tool requires that the controls,<br />
workflow, issue types, fields, field values, and users, which are essential to operating your<br />
business, are set up in <strong>MKS</strong> Integrity prior to running the data conversion. These items are<br />
not created by the conversion.<br />
Once <strong>MKS</strong> Integrity is set up and <strong>Implementer</strong> is converted to use <strong>MKS</strong> Integrity for issue<br />
management in co-existence with DesignTracker, you can focus on the data conversion<br />
aspect of your project.
Rules and Actions<br />
You have the option to convert all data at the same time, or gradually convert subsets of data,<br />
for example, by product, user, department, or project. Perhaps your business model requires<br />
only the conversion of DRs (not SRs)—the conversion tool has the flexibility to accommodate<br />
each of these scenarios, and more. The Work with Design Requests and Work with Service<br />
Requests subsetting functions are used to select the DRs or SRs for conversion.<br />
As explained in “Set a User’s Default Issue Management System” on page 253, <strong>Implementer</strong><br />
allows you to designate on a user basis which issue tracking system a user is working with. In<br />
other words, you can temporarily have groups of users using DesignTracker, while other<br />
users are using <strong>MKS</strong> Integrity. This approach is beneficial to larger organizations with many<br />
end users, as it allows you to train and migrate groups of individuals rather than all users at<br />
once.<br />
<strong>Implementer</strong> provides a conversion tool that is delivered in the form of the Convert DT to<br />
<strong>MKS</strong> Integrity (ICVTDT) command. Unlike most <strong>Implementer</strong> commands, this command<br />
works together with a conversion property file that resides on the <strong>Implementer</strong> Server. The<br />
conversion results post to a conversion log on the same system. Using the conversion tool,<br />
you are able to generate the conversion properties file you use to map existing DesignTracker<br />
data and fields to corresponding values already defined in <strong>MKS</strong> Integrity. Details on the<br />
ICVTDT command begin on page 438. Information on mapping data begins on page 441.<br />
Once the conversion properties are properly set up and you have all the required data<br />
mapped, the conversion tool is used to convert the DesignTracker data to <strong>MKS</strong> Integrity<br />
issues. Information on using the conversion tool begins on page 433.<br />
The data conversion is complete when all applicable data is converted to <strong>MKS</strong> Integrity<br />
issues and no users are set to use DesignTracker for issue management. Information on post<br />
data conversion activities begins on page 454.<br />
Rules and Actions<br />
The conversion tool allows you to convert existing DesignTracker DRs, SRs, and DR entity<br />
information to <strong>MKS</strong> Integrity issues and related change packages. You can convert subsets of<br />
DRs and/or SRs, making it possible to have groups of DRs or SRs convert differently<br />
depending on the values specified in the conversion properties file when the conversion<br />
runs.<br />
DRs must have no open locks to convert. Once converted, a DR cannot be associated with a<br />
lock, for example, a converted DR cannot be used in check out. Editing a converted DR or SR<br />
is allowed; however, any changes made to a converted DR or SR are not updated to the<br />
corresponding <strong>MKS</strong> Integrity issue. Thus, a good business practice is to only make changes to<br />
the new issue.<br />
433
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
434<br />
Each DesignTracker DR and SR field is optionally mapped to an <strong>MKS</strong> Integrity field as<br />
defined by you. DR entities and corresponding fields automatically convert to <strong>Implementer</strong><br />
change packages in <strong>MKS</strong> Integrity. Fields can either be omitted, or they can have the name of<br />
an existing <strong>MKS</strong> Integrity field to populate with the data. The “Logged by User” and<br />
“Logged Date” always convert to internal fields.<br />
For each field you convert, if there is a master file in DesignTracker setup, the DesignTracker<br />
field value is assigned to the corresponding <strong>MKS</strong> Integrity field value as defined in the<br />
conversion properties file. This allows replacing the shorter abbreviated values common in<br />
DesignTracker, with the longer, more descriptive values common to <strong>MKS</strong> Integrity. For<br />
example, DesignTracker status values can be set to existing <strong>MKS</strong> Integrity state values.<br />
After the data conversion, the DRs and related lock history remain in DesignTracker,<br />
unchanged and available online to select DesignTracker users for historical and auditing<br />
purposes.<br />
TIP <strong>MKS</strong> recommends you assign the new <strong>MKS</strong> Integrity issue number to one of the<br />
user defined fields on DRs and SRs so it is visible when displaying a DR or SR. This<br />
also makes it available to include in reports and queries.However, this has no<br />
impact on the fact that once a DR or SR is converted, it will not convert again even if<br />
included in selection criteria.<br />
User Profile and Resource Fields<br />
<strong>Implementer</strong> attempts to convert all user profile and resource fields to the <strong>MKS</strong> Integrity user<br />
values defined for Project Leader and Developer Resource.<br />
<strong>Implementer</strong> retrieves the user ID that corresponds to the resource ID in the DesignTracker<br />
Resource master file. From the user ID, the OS/400 user profile is retrieved from the<br />
<strong>Implementer</strong> Work with Users function to verify if an <strong>MKS</strong> Integrity user ID is specified. If<br />
any of these values are invalid or not specified, the alternate value is used.<br />
In the event a name cannot convert, when defining the ICVTDT command parameters you<br />
must specify a valid default user to assign to the issue if there is no conversion for the user or<br />
available resource in DesignTracker.<br />
NOTE This rule applies when mapping to an <strong>MKS</strong> Integrity user field. If mapping to<br />
a text field, the original text maps to the new field.<br />
Entities Added as Change Package Entries<br />
When a converted DR is associated with a DesignTracker entity, an <strong>Implementer</strong> change<br />
package is created based on the standard <strong>MKS</strong> Integrity change package creation rules.
The Create User ID for a change package is determined in the following order:<br />
Rules and Actions<br />
assigns the user associated with the DR entity, if the user is enrolled in <strong>MKS</strong> Integrity<br />
assigns the development resource initials associated with the DR entity, if the user is a<br />
valid <strong>Implementer</strong> user and enrolled in <strong>MKS</strong> Integrity<br />
assigns the DRs Logged By user, if the user is a valid <strong>Implementer</strong> user and enrolled in<br />
<strong>MKS</strong> Integrity<br />
assigns the default create user as specified in the ICVTDT command (see “Default create<br />
user” on page 440)<br />
The change package status is set after the members are added. Because a converted DR<br />
cannot be associated with open locks, the change packages automatically close once<br />
converted.<br />
Conversion Log File<br />
Processing of the Convert DT to <strong>MKS</strong> Integrity (ICVTDT) command generates a conversion<br />
log file that lists any errors found in the setup and any problems detected during the actual<br />
conversion. <strong>MKS</strong> recommends you review the log file each time the ICVTDT command is<br />
processed, as it is the only place truncation warnings appear.<br />
The log is located on the <strong>Implementer</strong> Server. The log name is:<br />
implementer-conversion-YYYYMMDDHHMMSS.log<br />
Where YYYYMMDDHHMMSS is the date and time the log was created (the time stamp is based on<br />
a 24-hour clock), for example, implementer-conversion-<strong>2006</strong>04213124701.log.<br />
Message and Error Handling<br />
For every 50 items converted, a status message displays at the bottom of the display to<br />
indicate the actual number of converted items, for example, “Converted 50 items” and<br />
“Converted 2,500 items”. When the conversion ends, the total number of converted DRs<br />
and SRs display.<br />
If the conversion properties are incorrectly defined or problems occur when adding<br />
<strong>Implementer</strong> change packages for the DR entities, the conversion halts and the problems are<br />
logged to the conversion log file. You must resolve these problems before restarting the<br />
conversion.<br />
If a specific DR or SR does not convert, the problems are logged to the conversion log file and<br />
the conversion continues processing. After resolving the problem, you can restart the<br />
conversion without modifying the parameter selection (previously converted issues are<br />
excluded).<br />
435
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
436<br />
Conversion Considerations<br />
DRs that are currently linked to SRs in DesignTracker will not have a relationship<br />
automatically added between the new issues in <strong>MKS</strong> Integrity—this requires a manual<br />
change. In addition, because the following data (if used) is not applicable to <strong>MKS</strong> Integrity, it<br />
does not convert:<br />
DR and SR approval related information<br />
process control information, for example, field display and validation controls, and<br />
<strong>Implementer</strong> state controls<br />
release management information<br />
ProjectMaster information<br />
SupportCenter attached calls<br />
Organizational Activities<br />
The organizational activities required to perform the data conversion include the following:<br />
1 Pilot the integration.<br />
a) In <strong>Implementer</strong>, run the system conversion that allows DesignTracker and<br />
<strong>MKS</strong> Integrity to co-exist.<br />
b) Configure <strong>MKS</strong> Integrity, which includes:<br />
Types, workflow, fields, and field values. The workflow must allow any state<br />
transition to any other state. In addition, no mandatory fields can be specified<br />
in the workflow. The fields cannot have editability rules; remove any existing<br />
editability rules. You can modify this open workflow to be more restrictive<br />
once the conversion has finished.<br />
Enroll users.<br />
c) Configure <strong>Implementer</strong> to use <strong>MKS</strong> Integrity.<br />
d) Map your existing data to <strong>MKS</strong> Integrity by completing the conversion properties<br />
file.<br />
e) Run the Convert DT to <strong>MKS</strong> Integrity (ICVTDT) command to convert a sampling of<br />
DRs (for testing purposes, these DRs can be copied from other DRs).<br />
f) Verify the setup by using the <strong>Implementer</strong> and <strong>MKS</strong> Integrity functions to check out<br />
and promote back to production.<br />
g) Document all <strong>Implementer</strong> and <strong>MKS</strong> Integrity set up steps.<br />
h) Apply the set up changes to the production copies if piloting the conversion in<br />
separate installations.
Rules and Actions<br />
2 Plan and perform any required training (pilot installations can be used for this purpose).<br />
3 Configure <strong>MKS</strong> Integrity for any remaining changes:<br />
a) Workflow, fields, and types.<br />
b) Enroll users (non pilot users).<br />
4 Perform the conversion.<br />
a) Secure a backup of the <strong>Implementer</strong> and <strong>MKS</strong> Integrity databases.<br />
b) Issue the Convert DT to <strong>MKS</strong> Integrity (ICVTDT) command for each group of DRs<br />
and SRs requiring conversion.<br />
c) Perform any additional <strong>MKS</strong> Integrity setup changes.<br />
d) Verify the set up by using the <strong>Implementer</strong> and <strong>MKS</strong> Integrity functions for check<br />
out and promotion.<br />
e) Begin using the new features.<br />
Example of a Basic Conversion<br />
The following tasks illustrate the steps required to perform and complete a typical data<br />
conversion.<br />
1 Issue the following command to run the conversion and generate the initial conversion<br />
properties file:<br />
ICVTDT MODE(*EDIT) TYPE(*BOTH) DFTCRTUSR(CVTUSER)<br />
A message confirms the file was generated and the location of the file.<br />
NOTE To generate a new conversion properties file, delete or rename the existing file.<br />
2 Define the mappings from DesignTracker values to <strong>MKS</strong> Integrity fields and values.<br />
In the conversion properties file, modify the field and value settings using any<br />
desktop ASCII editor, such as Notepad. For details, see “Generating and Configuring the<br />
Conversion Properties File” on page 441.<br />
3 In <strong>MKS</strong> Integrity, set up any new types, fields, or field values that will be used for<br />
DesignTracker DRs or SRs.<br />
4 From the Work with Design Requests and/or Work with Service Requests functions, use<br />
F17 to subset the list of requests to convert.<br />
5 Edit the conversion settings by issuing the following command:<br />
ICVTDT MODE(*EDIT) TYPE(*BOTH) DFTCRTUSR(CVTUSER)<br />
437
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
438<br />
6 Resolve all errors reported in the conversion log file. For details, see “Conversion Log<br />
File” on page 435.<br />
7 Run the conversion by issuing the following command:<br />
ICVTDT MODE(*CONVERT) TYPE(*BOTH) DFTCRTUSR(CVTUSER)<br />
8 Review the conversion log file for errors and warnings. For details, see “Message and<br />
Error Handling” on page 435.<br />
9 If the alternate was used to handle undefined values, in <strong>MKS</strong> Integrity, query for issues<br />
that use the alternate values for fields and modify the values as needed.<br />
Convert DT to <strong>MKS</strong> Integrity (ICVTDT) Command<br />
The Convert DT to <strong>MKS</strong> Integrity (ICVTDT) command is the tool that allows you to generate<br />
an initial <strong>Implementer</strong> conversion properties file, validate the entries in the file, and convert<br />
existing DRs and SRs into <strong>MKS</strong> Integrity issues.<br />
The command uses the current DR and SR selection criteria that are applied when subsetting<br />
the Work with Design Requests or Work with Service Requests functions for the user that<br />
issues the command, or the selection criteria of the last report generated by the user<br />
(whichever is most current). This allows you to view and report on the information to<br />
convert. The conversion automatically excludes any items already converted.<br />
The command converts DRs and SRs based on the values defined in the implementerconversion.properties<br />
file that installs in the root directory where the <strong>Implementer</strong><br />
server is installed. Records convert based on the sort order determined by using the DR and<br />
SR summary report criteria. For information on the conversion properties file, see<br />
“Generating and Configuring the Conversion Properties File” on page 441.<br />
The command provides three operational modes, depending on the Conversion Mode<br />
parameter value specified.<br />
Command parameter Conversion properties file status / command action<br />
*EDIT or *CONVERT Creates file if it does not exist.<br />
*EDIT Edits existing file.<br />
*CONVERT Edits existing file. If no errors, converts data.<br />
Create an initial prototype of the conversion properties file by issuing the command with the<br />
*EDIT parameter value, which populates the file based on the data currently defined to<br />
DesignTracker. The property file can be edited using any ASCII text editor. You can issue the<br />
ICVTDT command with the *EDIT parameter value as often as needed to validate the<br />
conversion property file until no errors are reported. When you are ready to convert data,<br />
issue the command with the *CONVERT parameter value.
Rules and Actions<br />
The command generates a conversion log file that lists any errors found in the setup, as well<br />
as any errors that occur during the data conversion. For details, see “Conversion Log File” on<br />
page 435.<br />
The command performs the following edits that must pass validation:<br />
The user running the conversion is enrolled in <strong>MKS</strong> Integrity and set up in <strong>Implementer</strong><br />
as a DesignTracker user.<br />
The default <strong>MKS</strong> Integrity user is valid.<br />
If converting DRs, a valid DR issue type is specified.<br />
If converting SRs, a valid SR issue type is specified.<br />
Each field is mapped to an existing <strong>MKS</strong> Integrity field (unmapped fields are omitted).<br />
Each field is mapped to a field of the proper type.<br />
For each field that has a restricted list of entries, each valid DesignTracker field value is<br />
mapped to a valid <strong>MKS</strong> Integrity field value.<br />
NOTE This requires all new field values defined in <strong>MKS</strong> Integrity. <strong>MKS</strong> professional<br />
services provides tools to help with this task if you have a lot of values to define.<br />
The alternate value, if specified, is a valid <strong>MKS</strong> Integrity value for the field.<br />
Each <strong>MKS</strong> Integrity field is assigned to only one DesignTracker field within DRs and<br />
SRs. For example, the State field can be assigned to both DRs and SRs as separate<br />
entities, but it cannot be assigned more than once within DRs or SRs alone.<br />
No open locks exist for DRs. If DRs with open locks are found, a message is sent to the<br />
conversion log and the edit or conversion does not occur.<br />
To use the ICVTDT command, DesignTracker and <strong>MKS</strong> Integrity must be set up as coexisting<br />
issue management systems as described in “Converting With Data Retention” on<br />
page 247.<br />
NOTE The ICVTDT command converts data only. For information on converting the<br />
issue management system, see “Converting From DesignTracker to <strong>MKS</strong> Integrity”<br />
on page 243.<br />
439
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
440<br />
Convert DT to <strong>MKS</strong> Integrity (ICVTDT) Command Parameters<br />
Conversion mode<br />
Specify whether to run the conversion in edit mode or conversion mode as follows:<br />
*EDIT Validates the conversion setup as defined in the implementerconversion.properties<br />
file. Does not convert DRs or SRs.<br />
Creates initial prototype implementer-conversion.properties file<br />
populated with the default values of all master data currently defined in<br />
the DesignTracker setup. The resulting file may be large depending on<br />
the volume of data. Use this file to map existing DesignTracker fields to<br />
the corresponding <strong>MKS</strong> Integrity fields.<br />
If you have made significant changes to your setup since creating the<br />
initial conversion properties file, delete or rename the file and generate a<br />
new one.<br />
*CONVERT Validates the conversion setup as with the *EDIT parameter, and if the<br />
configuration file is valid, converts DRs and SRs to issues.<br />
Type to convert<br />
Specify the type of DesignTracker requests to convert.<br />
Default create user<br />
IMPORTANT The first time you issue this command, specify the *EDIT<br />
parameter value to generate an initial conversion properties file. This file<br />
contains data from your existing setup and must be generated to validate your<br />
conversion setup and data mapping. You may have to do this multiple times<br />
until the expected results are achieved. Rerun the ICVTDT command with the<br />
*EDIT value until the log file is error free. When you are satisfied with the edit<br />
results, you are ready to convert DRs and SRs by issuing the command using<br />
the *CONVERT parameter value.<br />
*BOTH Converts both DRs and SRs.<br />
*DR Converts DRs only.<br />
*SR Converts SRs only.<br />
Specify an <strong>Implementer</strong> user profile name to assign as the Created by user for issues and<br />
change packages when a user associated with a DR, SR, or DR entity cannot be assigned, for<br />
example, if a user profile no longer exists or a user is not enrolled in <strong>MKS</strong> Integrity.<br />
The default name specified here must be set up in <strong>Implementer</strong> as an <strong>MKS</strong> Integrity user and<br />
enrolled in <strong>MKS</strong> Integrity.<br />
Based on the type, the Created by user is assigned in the following order:
Type Order of assignment<br />
Command Usage Examples<br />
Generating and Configuring the Conversion Properties File<br />
Issues Logged by user.<br />
Default create user specified in the ICVTDT command.<br />
Change Packages User associated with the DR entity, if the user is enrolled in <strong>MKS</strong> Integrity.<br />
Development resource initials associated with the DR entity, if the user is a<br />
valid <strong>Implementer</strong> user and enrolled in <strong>MKS</strong> Integrity.<br />
DRs Logged By user, if the user is a valid <strong>Implementer</strong> user and enrolled in<br />
<strong>MKS</strong> Integrity.<br />
Default create user specified in the ICVTDT command.<br />
First, the ICVTDT command is used to generate and validate the setup defined in the<br />
conversion properties file for DRs and SRs. Data is not converted. An example of this<br />
command is:<br />
ICVTDT MODE(*EDIT) TYPE(*BOTH) DFTCRTUSR(CVTUSER)<br />
Next, the ICVTDT command is used to convert a subset of DRs to <strong>MKS</strong> Integrity issues.<br />
This example assumes that any errors reported in the conversion properties file as a<br />
result of issuing the command in the first example are resolved. If any DRs are<br />
associated with an invalid user profile, <strong>Implementer</strong> assigns the <strong>MKS</strong> Integrity user<br />
defined for the default user profile CVTUSER. An example of this command is:<br />
ICVTDT MODE(*CONVERT) TYPE(*DR) DFTCRTUSR(CVTUSER)<br />
Last, the ICVTDT command is used to convert the user’s defined subset of DRs and SRs<br />
to <strong>MKS</strong> Integrity issues. An example of this command is:<br />
ICVTDT MODE(*CONVERT) TYPE(*BOTH) DFTCRTUSR(CVTUSER)<br />
Generating and Configuring the Conversion<br />
Properties File<br />
Before converting DesignTracker data, you must map the existing data to corresponding<br />
values in <strong>MKS</strong> Integrity. This is accomplished by fist generating the <strong>Implementer</strong> conversion<br />
properties file. After generating the file, you must map the DesignTracker fields to the<br />
<strong>MKS</strong> Integrity fields.<br />
If your DesignTracker setup changes you can edit the conversion properties file, or if you<br />
want to completely recreate the conversion property file from scratch, either delete or rename<br />
the existing file on the <strong>Implementer</strong> Server and then rerun the edit process.<br />
After reviewing the following information, you can perform the task on page 446 that<br />
explains how to generate, edit, update, and save the file as needed for the data conversion.<br />
441
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
Data Mapping Considerations<br />
442<br />
The overall success of your data conversion is contingent upon two criteria: the accuracy of<br />
workflow and values you define in <strong>MKS</strong> Integrity, and the accuracy with which you map<br />
existing DesignTracker data values to the new values. To support this objective, this section<br />
contains specific information you need to know in preparation for mapping data and<br />
configuring the conversion properties file.<br />
Field Mapping<br />
You must map all applicable DesignTracker fields to a corresponding valid field in<br />
<strong>MKS</strong> Integrity. You accomplish this by configuring the <strong>Implementer</strong> conversion properties<br />
file. An example of the conversion properties file is illustrated in the table on page 446. You<br />
may find it helpful to use this table as a template when mapping your data.<br />
Prior to running the conversion, you must define any new fields in <strong>MKS</strong> Integrity (the<br />
conversion does not create fields). An error occurs if a specified field is not of the required<br />
type.<br />
Field Values<br />
Several fields in DesignTracker contain data that you can prompt or that is validated to<br />
master file data. To allow for a parallel structure in <strong>MKS</strong> Integrity, you can convert these<br />
fields to either a Pick or Short Text data type in <strong>MKS</strong> Integrity. The DesignTracker fields are:<br />
Product<br />
Product/component<br />
Product/version<br />
Priority<br />
Company/division<br />
Company/division/department<br />
Cost center<br />
System<br />
Request type<br />
Request status<br />
Review the following table to determine whether to use a Pick or Short Text data type.
Data Type Description<br />
Generating and Configuring the Conversion Properties File<br />
Pick Allows selection of predefined values only. If values exist in the DesignTracker<br />
database that do not match the current master files, it causes an error. This could<br />
occur by entering data when the System Control value was set to bypass entry<br />
validation.<br />
After the conversion, you can rename the Pick entry to rename all references to it.<br />
Short Text Allows any text and also provides a list of standard options. All values defined in<br />
DesignTracker for this field are added as suggestions. If values exist in DRs or SRs<br />
that are not in the master files, they are set for the issue (unlike the Pick data type).<br />
After the conversion, you can rename a suggestion without impact to any other<br />
issues that contain the suggestion. To change an issue you must edit and change<br />
the new value.<br />
Users and resources do not require mapping because the conversion uses the <strong>Implementer</strong><br />
user’s profile for <strong>MKS</strong> Integrity as specified in Work with Users. These values convert to the<br />
corresponding <strong>MKS</strong> Integrity user profile. If a user is not defined, the default user specified<br />
on the ICVTDT command is used.<br />
However, the <strong>MKS</strong> Integrity Log by User, although set using the same logic, is handled<br />
differently to handle cases when the DesignTracker user that originally logged the DR or SR<br />
is no longer an active user, and therefore, not enrolled in <strong>MKS</strong> Integrity. To account for this,<br />
you should set the Logged by User to convert to a string field to allow the Logged by User<br />
name, as it appears in DesignTracker, to map to this field. Any DesignTracker fields that<br />
convert to an <strong>MKS</strong> Integrity user can be placed in a User field type.<br />
NOTE Blank spaces in DesignTracker values automatically translate to an<br />
underscore “_” in the value entry. This file is built from master files; thus, if any<br />
values used in the DesignTracker database are not listed in the master file, you must<br />
add those values. If the values contain blanks, you must substitute an underscore for<br />
the blanks. Underscore values are not required when specifying the new<br />
<strong>MKS</strong> Integrity value.<br />
Alternate Values<br />
The conversion allows each field to have an alternate value specified. The alternate value is<br />
automatically used when a map entry is not specified for the corresponding field value for a<br />
DR or SR. The alternate value serves a dual purpose:<br />
If multiple values are specified for a field in DesignTracker and you want most of them<br />
to use the same value in <strong>MKS</strong> Integrity, you can set the alternate value for those fields,<br />
and set the other values to a value other than the alternate.<br />
If existing DesignTracker data is not defined in the setup lists for the data type in<br />
<strong>MKS</strong> Integrity and you specify a Pick data type, an error occurs during the conversion if<br />
an alternate value is not specified. If this occurs, either rerun the conversion after the<br />
443
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
444<br />
conversion of mapped values is finishes, or create the issues by using the value specified<br />
as the alternate value, and then query the issues in <strong>MKS</strong> Integrity and change them as<br />
needed.<br />
Long Text Fields and Descriptions<br />
In DesignTracker, all text information displays using a fixed font size, whereas <strong>MKS</strong> Integrity<br />
uses a variable font size. Similarly, the long descriptions in DesignTracker allow for a<br />
limitless amount of data, whereas the long text fields in <strong>MKS</strong> Integrity have a size limit. The<br />
conversion tool handles these database variances as follows:<br />
When converting long text fields in DesignTracker, each line of text is separated with a<br />
“new line” character in <strong>MKS</strong> Integrity (paragraphs are not created). If existing text is<br />
spaced to form columns of information, this format is not replicated in <strong>MKS</strong> Integrity.<br />
If the data for a long description exceeds the limit of the <strong>MKS</strong> Integrity field, during the<br />
conversion the extra text and corresponding message are written to the error log. This<br />
allows you to manually enter the data into another field, for example, using cut and<br />
paste, or edit the text to a size that fits in the field. When this occurs the text in the issue<br />
field indicates a truncated value.<br />
Hierarchical Field Considerations<br />
DesignTracker allows for parent/child data relationships, where some fields are sub-fields of<br />
other fields, resulting in a hierarchical data structure. The hierarchical field considerations<br />
apply to the following DesignTracker fields:<br />
Product/component<br />
Product/version<br />
Company/division<br />
Company/division/department<br />
<strong>MKS</strong> Integrity does not support user defined hierarchical data; thus, you can place this type<br />
of data into a Pick or Short Text data type, as explained in “Field Values” on page 442. When<br />
you generate the property file, the description for all hierarchical entries is built based on the<br />
hierarchical field values. Once converted, the data in <strong>MKS</strong> Integrity is separated by a forward<br />
slash “/” to indicate the different data levels.<br />
For example, in the company/division/department field:<br />
ACME Mfg is the company description for ACME Manufacturing<br />
Widgets is the division description for WID<br />
Accounting is the department description for ACCT<br />
The generated key is:<br />
ACME/WID/ACCT=ACME Mfg/Widgets/Accounting
Mapping to the Project Field<br />
Generating and Configuring the Conversion Properties File<br />
Some fields in the conversion property file can be mapped into the Project field. Fields that<br />
are mapped into this field automatically parse using a forward slash “/” as the project<br />
hierarchy delimiter. All project levels must be created with the appropriate hierarchy. For<br />
example, the company/division/department value of Acme/Widgets/Accounting has the<br />
project hierarchy:<br />
Acme<br />
Widgets<br />
Accounting<br />
If you are mapping to a project field data type, the <strong>Implementer</strong> conversion properties value<br />
must have a forward slash (/) at the beginning of the new field name, for example, /Acme/<br />
Widgets/Accounting.<br />
NOTE This option is valid only if you are not using <strong>Implementer</strong> projects with<br />
<strong>MKS</strong> Integrity issues for project tracking as described in the “<strong>Implementer</strong> project<br />
field” description on page 230.<br />
New Issue Number<br />
<strong>MKS</strong> recommends you assign the <strong>MKS</strong> Integrity new issue number to one of the user defined<br />
fields in DesignTracker so it is included in reports and queries. If a previously converted DR<br />
or SR is included in a query used for conversion, it is excluded even if the new issue number<br />
is not stored in a user defined field.<br />
Generating the Conversion File<br />
The following tasks allow you to generate an initial conversion properties file. The values<br />
listed in the initial file are based on your existing DesignTracker data. For each applicable<br />
DesignTracker field value, you need to define the corresponding conversion value to assign<br />
in <strong>MKS</strong> Integrity.<br />
The overall success of your data conversion relies upon the accuracy of your data mapping.<br />
For assistance with completing this task, see the table of the <strong>Implementer</strong> conversion<br />
properties on page 446.<br />
445
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
446<br />
To generate and configure the conversion properties file<br />
1 Generate an initial conversion properties file by issuing the following command. Change<br />
the parameter values as needed based on your requirements:<br />
ICVTDT MODE(*EDIT)<br />
TYPE(*BOTH)<br />
DFTCRTUSR(default_user_name)<br />
A message confirms the conversion property file generated and the location of the file.<br />
For detailed information on this command, see “Convert DT to <strong>MKS</strong> Integrity (ICVTDT)<br />
Command Parameters” on page 440.<br />
2 Open the file using a standard text editor and modify the conversion properties to<br />
correspond with the information applicable to your database.<br />
3 To retain the changes, save the implementer-conversion.properties file as a plain<br />
text file.<br />
4 Once the conversion properties file is populated with valid values, re-issue the<br />
command to verify no errors exist. When you are satisfied with your results, you are<br />
ready to convert the data.<br />
<strong>Implementer</strong> Conversion Properties<br />
The tables in this section describe the <strong>Implementer</strong> conversion properties file. There are two<br />
sections to the conversion properties file: general conversion control properties, and DR and<br />
SR field conversion properties. You may find it helpful to use the tables as a template when<br />
mapping your data.<br />
<strong>Implementer</strong> Conversion<br />
Control Properties<br />
Description<br />
mks.implementer.dr.ud_field=0 Controls which user defined field holds the issue number for a converted<br />
DR. Valid values are:<br />
0 (none—default value)<br />
1 (user defined field #1)<br />
2 (user defined field #2).<br />
Note that any data in the specified user defined field will be overwritten.<br />
mks.implementer.sr.ud_field=0 Controls which user defined field holds the issue number for a converted<br />
SR. Valid values are:<br />
0 (none—default value)<br />
1 (user defined field #1)<br />
2 (user defined field #2)<br />
Note that any data in the specified user defined field will be overwritten.
<strong>Implementer</strong> Conversion<br />
Control Properties<br />
Description<br />
Generating and Configuring the Conversion Properties File<br />
mks.implementer.dr.issue_type Defines the <strong>MKS</strong> Integrity issue type to use for DRs, for example,<br />
Defects.<br />
mks.implementer.sr.issue_type Defines the <strong>MKS</strong> Integrity issue type to use for SRs, for example,<br />
Features.<br />
Design Request and Service Request Field Conversion<br />
Properties and Definitions<br />
Referring to the table on page 448, the field definitions for the design request and service<br />
request conversion properties are as follows:<br />
mks.implementer.dr and mks.implementer.sr indicate whether this field is part of<br />
a design request or service request.<br />
intmgrfield is the <strong>MKS</strong> Integrity field to contain the converted DesignTracker data for<br />
a specific DesignTracker field.<br />
In the following example, the <strong>MKS</strong> Integrity field Priority contains the converted<br />
requester priority for a DR<br />
mks.implementer.dr.intmgrfield.requester_priority=Priority<br />
value is the value to assign in <strong>MKS</strong> Integrity that replaces the value in DesignTracker<br />
In the following example, the <strong>MKS</strong> Integrity field Priority uses the new values of High<br />
for A, Medium for B, and Low for C:<br />
mks.implementer.dr.value.requester_priority.A=High<br />
mks.implementer.dr.value.requester_priority.B=Medium<br />
mks.implementer.dr.value.requester_priority.C=Low<br />
NOTE<br />
The initial <strong>MKS</strong> Integrity field values specified in the conversion properties file<br />
come from the description of the value in DesignTracker. Alternately, you can<br />
edit the description in DesignTracker and recreate the conversion properties file.<br />
For more information, see the table on page 438.<br />
Any spaces in DesignTracker values automatically translate to an underscore “_”<br />
in the value entry. Because this file is built from master files, if any values used in<br />
the DesignTracker database are not listed in the master file, you need to add<br />
those values. If the values contain blanks, you must substitute an underscore for<br />
the blanks. Underscore values are not required when specifying the new<br />
<strong>MKS</strong> Integrity value.<br />
447
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
448<br />
alternate is the default value to automatically assign in <strong>MKS</strong> Integrity if a specific<br />
replacement for the value is not in DesignTracker. If left blank and no replacement value<br />
is found, the conversion reports an error.<br />
In the following example, if the DR priority is set and the value is not A, B, or C, then the<br />
<strong>MKS</strong> Integrity field Priority is set to unknown.<br />
mks.implementer.dr.value.requester_priority.alternate=unknown<br />
Design Request and Service Request Field Conversion Properties<br />
DesignTracker<br />
Description/Field<br />
Name<br />
mks.implementer.dr.intmgrfield.number= DR number<br />
DRDRNB<br />
mks.implementer.dr.intmgrfield.logged_by_user_id=<br />
mks.implementer.dr.value.logged_by_user_<br />
id.alternate=<br />
Recommended<br />
<strong>MKS</strong> Integrity<br />
Field Data Type<br />
Integer<br />
Logged by user User or Short Text<br />
DRLGUI<br />
This field is not used as the actual issue<br />
Created By userid; it can be assigned to<br />
any field. If assigned to a Short Text field,<br />
it can be used to store the user who<br />
created the DR, even if the user is not<br />
enrolled in <strong>MKS</strong> Integrity.<br />
When assigning to a Short Text field, do<br />
not specify an alternate value as the<br />
system verifies the user is defined in<br />
<strong>Implementer</strong> with an <strong>MKS</strong> Integrity<br />
user ID.<br />
mks.implementer.dr.intmgrfield.logged_date= Logged date Date<br />
DRLGDT<br />
This field is not used as the issue<br />
Created Date field. It can be assigned to<br />
any field.<br />
mks.implementer.dr.intmgrfield.closed_date= Closed date<br />
DRCLDT<br />
mks.implementer.dr.intmgrfield.closed_flag= Closed flag<br />
DRCLFG<br />
mks.implementer.dr.intmgrfield.title= Title<br />
DRDRTT<br />
mks.implementer.dr.intmgrfield.type=<br />
mks.implementer.dr.value.type.alternate=<br />
mks.implementer.dr.intmgrfield.system=<br />
mks.implementer.dr.value.system.alternate=<br />
mks.implementer.dr.intmgrfield.product=<br />
mks.implementer.dr.value.product.alternate=<br />
DR type<br />
DRDRTB<br />
System<br />
DRSYSY<br />
Product<br />
DRPDPD<br />
Date<br />
Boolean<br />
Short Text or<br />
Summary<br />
Pick or Short Text<br />
Pick, Project, or<br />
Short Text<br />
Pick, Project, or<br />
Short Text
Design Request and Service Request Field Conversion Properties<br />
mks.implementer.dr.intmgrfield.product_component=<br />
mks.implementer.dr.value.product_component.<br />
alternate=<br />
mks.implementer.dr.intmgrfield.product_version=<br />
mks.implementer.dr.value.product_version.<br />
alternate=<br />
Generating and Configuring the Conversion Properties File<br />
Product/<br />
component<br />
DRPDPD/<br />
DRCPCP<br />
Product/version<br />
DRPDPD/<br />
DRVRVR<br />
mks.implementer.dr.intmgrfield.expected_date= Expected date<br />
DREXDT<br />
mks.implementer.dr.intmgrfield.requested_date= Requested date<br />
DRRQDT<br />
mks.implementer.dr.intmgrfield.requester_<br />
priority=<br />
mks.implementer.dr.value.requester_priority.alternat<br />
e=<br />
mks.implementer.dr.intmgrfield.benefits_priority=<br />
mks.implementer.dr.value.benefits_priority.<br />
alternate=<br />
mks.implementer.dr.intmgrfield.development_<br />
priority=<br />
mks.implementer.dr.value.development_priority.<br />
alternate=<br />
mks.implementer.dr.intmgrfield.status=<br />
mks.implementer.dr.value.status.alternate=<br />
mks.implementer.dr.intmgrfield.project_leader_<br />
initials=<br />
mks.implementer.dr.value.project_leader_initials.alt<br />
ernate=<br />
mks.implementer.dr.intmgrfield.development_<br />
resource_initials=<br />
mks.implementer.dr.value.development_resource_<br />
initials.alternate=<br />
Requester priority<br />
DRRQPR<br />
Benefits priority<br />
DRBNPR<br />
Development<br />
priority<br />
DRDVPR<br />
Status<br />
DRSTST<br />
Project leader<br />
initials<br />
DRPLIN<br />
Developer initials<br />
DRDRIN<br />
mks.implementer.dr.intmgrfield.estimated_effort= Estimated effort<br />
DRENEF<br />
mks.implementer.dr.intmgrfield.estimated_cost= Estimated cost<br />
DRENCS<br />
mks.implementer.dr.intmgrfield.estimated_<br />
completion_date=<br />
DesignTracker<br />
Description/Field<br />
Name<br />
Estimated<br />
completion date<br />
DRECDT<br />
Recommended<br />
<strong>MKS</strong> Integrity<br />
Field Data Type<br />
Pick, Project, or<br />
Short Text<br />
Pick, Project, or<br />
Short Text<br />
Date<br />
Date<br />
Pick or Short Text<br />
Pick or Short Text<br />
Pick or Short Text<br />
Pick, Project, or<br />
Short Text<br />
User or Short Text<br />
(converts to<br />
<strong>MKS</strong> Integrity<br />
user)<br />
User or Short Text<br />
(converts to<br />
<strong>MKS</strong> Integrity<br />
user)<br />
Float<br />
Float<br />
Date<br />
449
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
Design Request and Service Request Field Conversion Properties<br />
mks.implementer.dr.intmgrfield.implementer_<br />
project_reference=<br />
mks.implementer.dr.value.implementer_project_<br />
reference.alternate=<br />
mks.implementer.dr.intmgrfield.estimated_effort_<br />
remaining=<br />
mks.implementer.dr.intmgrfield.estimated_cost_<br />
remaining=<br />
mks.implementer.dr.intmgrfield.total_actual_<br />
effort=<br />
450<br />
<strong>Implementer</strong><br />
project reference<br />
DRIMPJ<br />
Estimated effort<br />
remaining<br />
DRTEEF<br />
Estimated cost<br />
remaining<br />
DRTECS<br />
Total actual effort<br />
DRTAEF<br />
mks.implementer.dr.intmgrfield.total_actual_cost= Total actual cost<br />
DRTACS<br />
mks.implementer.dr.intmgrfield.company=<br />
mks.implementer.dr.value.company.alternate=<br />
mks.implementer.dr.intmgrfield.company_division=<br />
mks.implementer.dr.value.company_division.<br />
alternate=<br />
mks.implementer.dr.intmgrfield.company_division_<br />
department=<br />
mks.implementer.dr.value.company_division_<br />
department.alternate=<br />
mks.implementer.dr.intmgrfield.cost_center=<br />
mks.implementer.dr.value.cost_center.alternate=<br />
Company<br />
DRCOCO<br />
Company/division<br />
DRCOCO/<br />
DRDVDV<br />
Company/division/<br />
department<br />
DRCOCO/<br />
DRDVDV/DRDPD<br />
Cost center<br />
DRCECE<br />
mks.implementer.dr.intmgrfield.contact= Contact<br />
DRCTCT<br />
mks.implementer.dr.intmgrfield.production_<br />
environment=<br />
mks.implementer.dr.value.production_environment.<br />
alternate=<br />
DesignTracker<br />
Description/Field<br />
Name<br />
Production<br />
environment<br />
DRPREV<br />
mks.implementer.dr.intmgrfield.duplicate_number= Duplicate request<br />
number<br />
DRDDNB<br />
mks.implementer.dr.intmgrfield.user_defined_field_1= User defined<br />
field #1<br />
DRU1UD<br />
Recommended<br />
<strong>MKS</strong> Integrity<br />
Field Data Type<br />
Pick or Short Text<br />
for <strong>Implementer</strong><br />
projects or Project<br />
type for other<br />
projects<br />
Float<br />
Float<br />
Float<br />
Float<br />
Pick, Project, or<br />
Short Text<br />
Pick, Project, or<br />
Short Text<br />
Pick, Project, or<br />
Short Text<br />
Pick, Project, or<br />
Short Text<br />
Short Text<br />
Pick, Project, or<br />
Short Text<br />
Short Text or<br />
Integer<br />
Pick or Short Text
Design Request and Service Request Field Conversion Properties<br />
mks.implementer.dr.intmgrfield.user_defined_field_2= User defined<br />
field #2<br />
DRU2UD<br />
Generating and Configuring the Conversion Properties File<br />
mks.implementer.dr.intmgrfield.last_date_updated= Last date updated<br />
DRRUDT<br />
Design Request Long Text Fields<br />
mks.implementer.dr.intmgrfield.alternative_text= Alternatives text<br />
DRNRTB<br />
mks.implementer.dr.intmgrfield.long_description= Description<br />
DRNRTB<br />
mks.implementer.dr.intmgrfield.bulletin_board= Bulletin board<br />
DRNRTB<br />
mks.implementer.dr.intmgrfield.benefits_text= Benefits text<br />
DRNRTB<br />
mks.implementer.dr.intmgrfield.development_info= Development<br />
information<br />
DRNRTB<br />
mks.implementer.dr.intmgrfield.user_defined= User defined text<br />
DRNRTB<br />
mks.implementer.sr.intmgrfield.number= SR Number<br />
SRSRNB<br />
mks.implementer.sr.intmgrfield.logged_by_user_id=<br />
mks.implementer.sr.value.logged_by_user_id.<br />
alternate=<br />
DesignTracker<br />
Description/Field<br />
Name<br />
Recommended<br />
<strong>MKS</strong> Integrity<br />
Field Data Type<br />
Pick or Short Text<br />
Date<br />
Long Text<br />
Long Text<br />
Long Text<br />
Long Text<br />
Long Text<br />
Long Text<br />
Integer<br />
Logged by user User or Short Text<br />
SRLGUI<br />
This field is not used as the actual issue<br />
Created By userid; it can be assigned to<br />
any field. If assigned to a Short Text field,<br />
it can be used to store the user who<br />
created the DR, even if the user is not<br />
enrolled in <strong>MKS</strong> Integrity.<br />
When assigning to a Short Text field, do<br />
not specify an alternate value, as the<br />
system verifies the user is defined in<br />
<strong>Implementer</strong> with an <strong>MKS</strong> Integrity<br />
user ID.<br />
mks.implementer.sr.intmgrfield.logged_date= Logged date Date<br />
SRLGDT<br />
This field is not used as the issue<br />
Created Date; it can be assigned to any<br />
field.<br />
451
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
Design Request and Service Request Field Conversion Properties<br />
mks.implementer.sr.intmgrfield.closed_date= Closed date<br />
SRCLDT<br />
mks.implementer.sr.intmgrfield.closed_flag= Closed flag<br />
SRCLFG<br />
mks.implementer.sr.intmgrfield.title= Title<br />
SRSRTT<br />
mks.implementer.sr.intmgrfield.type=<br />
mks.implementer.sr.value.type.alternate=<br />
mks.implementer.sr.intmgrfield.system=<br />
mks.implementer.sr.value.system.alternate=<br />
mks.implementer.sr.intmgrfield.product=<br />
mks.implementer.sr.value.product.alternate=<br />
mks.implementer.sr.intmgrfield.product_component=<br />
mks.implementer.sr.value.product_component.<br />
alternate=<br />
mks.implementer.sr.intmgrfield.product_version=<br />
mks.implementer.sr.value.product_version.<br />
alternate=<br />
452<br />
SR type<br />
SRSRTB<br />
System<br />
SRSYSY<br />
Product<br />
SRPDPD<br />
Product/<br />
component<br />
SRPDPD/<br />
SRCPCP<br />
Product/ version<br />
SRPDPD/<br />
SRVRVR<br />
mks.implementer.sr.intmgrfield.expected_date= Expected date<br />
SREXDT<br />
mks.implementer.sr.intmgrfield.requested_date= Requested date<br />
SRRQDT<br />
mks.implementer.sr.intmgrfield.requester_<br />
priority<br />
mks.implementer.sr.value.requester_priority.<br />
alternate=<br />
mks.implementer.sr.intmgrfield.benefits_priority=<br />
mks.implementer.sr.value.benefits_priority.<br />
alternate=<br />
mks.implementer.sr.intmgrfield.status=<br />
mks.implementer.sr.value.status.alternate=<br />
Requested priority<br />
SRRQPR<br />
Benefits priority<br />
SRBNPR<br />
Status<br />
SRSTST<br />
mks.implementer.sr.intmgrfield.estimated_effort= Estimated effort<br />
SRESEF<br />
mks.implementer.sr.intmgrfield.estimated_cost= Estimated cost<br />
SRESCS<br />
mks.implementer.sr.intmgrfield.company=<br />
mks.implementer.sr.value.company.alternate=<br />
DesignTracker<br />
Description/Field<br />
Name<br />
Company<br />
SRCOCO<br />
Recommended<br />
<strong>MKS</strong> Integrity<br />
Field Data Type<br />
Date<br />
Boolean<br />
Short Text or<br />
Synopsis<br />
Pick or Short Text<br />
Pick, Project, or<br />
Short Text<br />
Pick, Project, or<br />
Short Text<br />
Pick, Project, or<br />
Short Text<br />
Pick, Project, or<br />
Short Text<br />
Date<br />
Date<br />
Pick or Short Text<br />
Pick or Short Text<br />
State, Pick, or<br />
Short Text<br />
Float<br />
Float<br />
Pick, Project, or<br />
Short Text
Design Request and Service Request Field Conversion Properties<br />
mks.implementer.sr.intmgrfield.company_division=<br />
mks.implementer.sr.value.company_division.<br />
alternate=<br />
mks.implementer.sr.intmgrfield.company_division_<br />
department=<br />
mks.implementer.sr.value.company_division_<br />
department.alternate=<br />
mks.implementer.sr.intmgrfield.cost_center=<br />
mks.implementer.sr.value.cost_center.alternate=<br />
Generating and Configuring the Conversion Properties File<br />
Company/division<br />
SRCOCO/<br />
SRDVDV<br />
Company/division/<br />
department<br />
SRCOCO/<br />
SRDVDV/<br />
SRDPDP<br />
Cost center<br />
SRCECE<br />
mks.implementer.sr.intmgrfield.contact= Contact<br />
SRCTCT<br />
mks.implementer.sr.intmgrfield.duplicate_number= Duplicate SR<br />
number<br />
SRDSNB<br />
mks.implementer.sr.intmgrfield.user_defined_field_1= User defined<br />
field #1<br />
SRU1UD<br />
mks.implementer.sr.intmgrfield.user_defined_field_2= User defined<br />
field #2<br />
SRU2UD<br />
mks.implementer.sr.intmgrfield.last_date_updated= Date last updated<br />
SRRUDT<br />
Service Request Long Text Fields<br />
DesignTracker<br />
Description/Field<br />
Name<br />
mks.implementer.sr.intmgrfield.alternative_text= Alternatives text<br />
SXNRT<br />
mks.implementer.sr.intmgrfield.long_description= Description<br />
SXNRTB<br />
mks.implementer.sr.intmgrfield.benefits_text= Benefits text<br />
SXNRTB<br />
mks.implementer.sr.intmgrfield.user_defined= User defined text<br />
SXNRTB<br />
Recommended<br />
<strong>MKS</strong> Integrity<br />
Field Data Type<br />
Pick, Project, or<br />
Short Text<br />
Pick, Project, or<br />
Short Text<br />
Pick, Project, or<br />
Short Text<br />
Short Text<br />
Short Text or<br />
Integer<br />
Short Text<br />
Short Text<br />
Date<br />
Long Text<br />
Long Text<br />
Long Text<br />
Long Text<br />
453
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
Post Conversion Considerations<br />
454<br />
Review and perform the following tasks after you have finished converting all DesignTracker<br />
data to <strong>MKS</strong> Integrity:<br />
Modify converted values<br />
If the alternate value was used to handle undefined values, in <strong>MKS</strong> Integrity, query for<br />
issues that used the alternate values for fields and modify the values as needed. For<br />
details, see the <strong>MKS</strong> Integrity Server <strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>.<br />
Set all users to use <strong>MKS</strong> Integrity<br />
In <strong>Implementer</strong>, verify the appropriate users are set to use <strong>MKS</strong> Integrity for issue<br />
management. For details, see “Set a User’s Default Issue Management System” on<br />
page 253.<br />
Start using the new features<br />
When you have successfully completed the data conversion, you can begin using the<br />
new features as described in the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> User <strong>Guide</strong>.<br />
Each converted DR and SR retains a permanent record of the <strong>MKS</strong> Integrity location and<br />
issue number it converted to. Likewise, displaying a converted issue in <strong>MKS</strong> Integrity<br />
identifies the DR it was created from, if that field is set as recommended. This information<br />
provides an audit trail that is useful for cross-referencing a converted DR or SR with its<br />
corresponding issue in <strong>MKS</strong> Integrity, and vice versa.<br />
This feature requires the Issue Management System field for your <strong>Implementer</strong> user profile<br />
set to 2=DesignTracker. For this purpose it may be helpful to create a secondary user profile<br />
for a few users—one profile set to <strong>MKS</strong> Integrity and the second profile set to DesignTracker.<br />
Or, you can create a single default profile for DesignTracker users to use. For details, see “Set<br />
a User’s Default Issue Management System” on page 253.<br />
To display the <strong>MKS</strong> Integrity URL for a converted DR or SR<br />
1 From the DesignTracker Menu, use option 1, Design Requests, or option 3, Service<br />
Requests, to display the respective Work with panel.<br />
2 Select the DR or SR with option 5=Display, and press ENTER to display the request.<br />
The <strong>MKS</strong> Integrity URL field displays up to 120 characters of text that wraps to the next<br />
line as needed. As shown in the next illustration, the URL indicates the location and<br />
issue number the converted request mapped to. (A non converted DR or SR displays the<br />
text Not converted.)
Post Conversion Considerations<br />
455
Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />
456
A PPENDIX D<br />
Glossary<br />
Definitions of Common <strong>Implementer</strong> Terms<br />
D<br />
This appendix provides a description of the many terms used in software change<br />
management and throughout <strong>Implementer</strong>. Review this appendix to learn these terms<br />
and definitions, and understand how they relate to <strong>Implementer</strong>.<br />
NOTE For a description of <strong>MKS</strong> Integrity terms, see the <strong>MKS</strong> Integrity Server<br />
<strong>2006</strong> <strong>Administration</strong> <strong>Guide</strong>. For a description of <strong>MKS</strong> Source terms, see the<br />
<strong>MKS</strong> Source <strong>2006</strong> User <strong>Guide</strong>.<br />
action An action is used to indicate the process to perform to a member/object. The<br />
action is specified when checking out a member/object and when creating a request for a<br />
member/object. The following actions are valid for checking out and creating a<br />
promotion request:<br />
1 = Change<br />
2 = Create<br />
3 = Delete<br />
8 = Regen (only valid for AllFusion 2E model objects)<br />
9 = Recompile<br />
administrator The administrator sets up and configures <strong>Implementer</strong>. The<br />
administrator defines users, environments, environment capabilities. The administrator<br />
also defines the <strong>MKS</strong> Integrity parameters required in <strong>Implementer</strong> for integration.<br />
application path An application path refers to the standard and emergency paths set up<br />
in Work with Projects and Work with Environments. Application paths are used in the<br />
development cycle to define the flow of member/objects between environments. They<br />
are also used to determine the location of source and related objects for an object, for<br />
example, when compiling with a check out or create request action of recompile.<br />
The two basic types of application paths are:<br />
Project path<br />
This term refers to the standard and emergency paths set up in Work with Projects.<br />
A path can be defined for each project to represent the development flow of<br />
member/objects associated with the project. This type of path is beneficial when<br />
457
Appendix D: Glossary<br />
458<br />
routinely using multiple testing environments, especially when the test environments<br />
are determined on a project by project basis.<br />
Environment path<br />
This term refers to the standard and emergency paths set up in Work with<br />
Environments. A path can be defined for each production environment, representing the<br />
development flow of member/objects associated with the environment. Environment<br />
paths provide control, while eliminating redundancy when checking out and promoting,<br />
by restricting access so members/objects cannot move outside of the defined flow. It also<br />
allows defaulting the From environment and target environment values when checking<br />
out and creating a promotion request. Users can be restricted to the defined paths,<br />
preventing any circumvention of the predefined flow of work back into production, or<br />
they can be authorized to override a default path.<br />
If you use both environment paths and project paths, the project path is the default path in<br />
check out and create request when a project with a defined path is specified.<br />
NOTE Do not confuse the term application path with the term path, which refers to<br />
support provided by for IFS objects.<br />
application set Application set refers to AS/SET application sets, a partition of the ADK<br />
product where definitions such as programs, data models, files and fields are stored. An<br />
application set refers to an environment such as development or production, where copies of<br />
the application definitions are stored.<br />
archive recovery Archive recovery is the <strong>Implementer</strong> function that recovers members/<br />
objects or backs them out of a promotion request. It is also called rollback.<br />
archiving Archiving refers to the duplication of an existing production source member,<br />
object, or file (without data) into a designated library before the to-be-implemented object is<br />
moved into production. You use the archive to store members and/or objects or file<br />
information. Members/objects are placed in the archive during the Move Request function.<br />
Archiving is optional. It is defined by the environment definition. You can archive up to 99<br />
versions of files, objects, or source.<br />
The archive serves two purposes. First, it supports archive recovery or the rollback of a<br />
request. Second, the archive can be used to browse previous versions of a source member.<br />
batch programs for AS/SET Batch programs for AS/SET is an ADK program type designed<br />
to perform file-processing functions. No online display panels are involved in batch<br />
programs.<br />
binding directory A binding directory is a list of modules and service programs that may be<br />
needed when creating an ILE or Service program. It is not a repository of the modules and<br />
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<br />
work with <strong>Implementer</strong>. It’s model value *CHGCTL is set to that of the product library,<br />
<strong>MKS</strong>IM or Y2SYCM.<br />
Glossary<br />
change list A change list is an AllFusion 2E model object list defined in <strong>Implementer</strong>. You<br />
can explicitly create a model object list for an AllFusion 2E environment, or create one when<br />
you check out an AllFusion 2E model object during an editing session. This is referred to as a<br />
model object list in <strong>Implementer</strong>.<br />
check in Check in describes the process of promoting a member/object back into<br />
production after it is checked out. Check in removes the lock.<br />
check out Check out is the <strong>Implementer</strong> function that takes a member/object from a<br />
production environment (or quality assurance environment), copies it to a developer’s<br />
development library or environment, and places a lock on it. This makes the member/object<br />
in use by the user who checked it out.<br />
Clipboard The Clipboard is a work space for member/objects. After adding an item on the<br />
Clipboard, you can display, remove, or add more items to the Clipboard. The Clipboard<br />
holds the selected items until they are processed. At least one item must exist on the<br />
Clipboard before you can run a Clipboard function. You can select a list of items and process<br />
the list by another function. Once you run the function for the items, the items are listed<br />
within that function and removed from the Clipboard.<br />
co-existence Co-existence is an <strong>Implementer</strong> feature that allows you to convert<br />
DesignTracker DRs and SRs to <strong>MKS</strong> Integrity issues.<br />
compile request Compile request is an <strong>Implementer</strong> function that compiles source members<br />
into the work libraries and moves non source-based objects into work libraries, according to<br />
the migration request instructions. Developers typically perform this task.<br />
concurrent development Concurrent development is when two or more versions of a<br />
member/object exist at the same time. It is the result of checking out a member/object that is<br />
already checked out. When concurrent development occurs, the multiple versions of the<br />
member/object are considered in conflict with each other. The ability to check out a<br />
member/object for concurrent work can be restricted to certain users. See also, non<br />
sequential development and sequential development.<br />
conflict When concurrent development is started, a conflict is created for that specific<br />
member/object. You must resolve a conflict before a member/object can be promoted.<br />
constraint A constraint is a set of rules that defines the relationship between two files. For<br />
example, a constraint can be used to maintain the integrity between a customer header file<br />
and a customer detail file, by not allowing changes to the header table file without changing<br />
the detail file. See also, trigger.<br />
create request Create request is the <strong>Implementer</strong> function of initiating a promotion request<br />
for the purpose of migrating source and/or objects to production or quality assurance<br />
environments. Developers typically perform this task.<br />
459
Appendix D: Glossary<br />
460<br />
currency Currency is an AllFusion 2E model object that all other related model objects point<br />
to. It is an object that has usage. A non current object has no usage in the model.<br />
current model object The current model object is what the user can view or edit in an<br />
AllFusion 2E model. Multiple versions of the model object can be checked out to and<br />
accessible from one or more model object lists. However, only the current version displays in<br />
the model.<br />
data model A data model is an entity defined in the ADK repository that refers to one or<br />
more files, associated fields, and associated relationships.<br />
design request A design request is a feature of DesignTracker used to indicate what work<br />
needs to be done. DesignTracker automatically installs when you install <strong>Implementer</strong>.<br />
NOTE If you use <strong>MKS</strong> Integrity for issue tracking with <strong>Implementer</strong>, you do not use<br />
DesignTracker.<br />
design request approval A design request approval can be:<br />
0 = No<br />
1 = Yes<br />
2 = Pending<br />
For an approval type of:<br />
1 = Development<br />
2 = Test<br />
3 = Production environment<br />
design request disposition The design request disposition can be:<br />
0 = Not Ready (always set to 0 when entity is added to the list)<br />
1 = Ready for checkout (entity is ready to be checked out)<br />
2 = In development (entity is checked out to development)<br />
3 = In quality assurance (entity is checked out and in quality assurance for testing)<br />
4 = Completed (entity moved into a *PRD environment)<br />
design request status The design request status is the current state of a design request.<br />
The <strong>Implementer</strong> entity controls related to design request status are: allow ready to check<br />
out, allow check out, allow promotion to a test environment, and allow promotion to a<br />
production environment. Upon approval from all designated users, the status can be<br />
automatically changed by DesignTracker. You set up the approval/status relationship in<br />
DesignTracker System Control.<br />
directory See IFS directory.
Glossary<br />
DLO Document Library Object (DLO) refers to a file or folder that exists in the QDLS file<br />
system on an iSeries. These objects, referred to in <strong>Implementer</strong> as IFS objects, are supported<br />
for change management. See also IFS object, IFS file, and IFS directory.<br />
document A document is a special type of file created by OfficeVision/400 and stored in the<br />
QDLS space. A document is a file, but a file is not necessarily a document. It is the OS/400<br />
term for any object residing within an IFS folder on the iSeries. Within <strong>Implementer</strong>, the term<br />
IFS object is used.<br />
environment An environment identifies a collection of libraries, object owners, authorized<br />
users, and rules about how the libraries are controlled by <strong>Implementer</strong>. See also related<br />
environment.<br />
environment ID An environment ID is a sequential number assigned to each target<br />
environment on a promotion request. The number, which starts at one and increments by<br />
one, is used for naming some libraries, save files, and other objects used as part of the<br />
promotion request.<br />
environment library list Environment library list is a list of up to 250 libraries used for<br />
compilation in the environment. Of these, 248 entries are available for your use. The last two<br />
entries are reserved for QTEMP and the <strong>Implementer</strong> work library on the promotion request.<br />
The environment library list is used also when processing special commands for a request.<br />
environment type An environment type defines whether an environment is for production<br />
(*PRD), quality assurance (*QAC), or development (*TST). It enforces check out an<br />
promotion restrictions and ensures the developers do not attempt to copy members/objects<br />
from one production environment to another.<br />
export An export is the process of saving LANSA objects into a device or save file to move<br />
them from one LANSA partition to another, on the same or different system.<br />
export list An export list is a named list of LANSA objects to be exported from one LANSA<br />
partition to another. There are two types of lists provided by LANSA: One is visible to<br />
LANSA users and maintainable within the LANSA menu. The other is not visible to you but<br />
provided for object management vendors. <strong>Implementer</strong> creates an export list whenever it<br />
copies LANSA objects from one partition to another partition.<br />
file A file refers to the support <strong>Implementer</strong> provides for traditional OS/400 files and<br />
objects in the IFS (referred to as IFS files). To avoid confusion, whenever an IFS file object is<br />
referenced in <strong>Implementer</strong>, the term IFS file is used.<br />
<strong>Implementer</strong> supports all traditional OS/400 files, for example, physical files, logical files,<br />
display files, message files, printer files, SQL tables, and SQL indices and views. See also IFS<br />
file.<br />
folder A folder represents the OS/400 term for a collection of documents in a single<br />
location. The term is used as part of support <strong>Implementer</strong> provides for IFS objects. It<br />
corresponds to IFS directory. See also IFS directory.<br />
461
Appendix D: Glossary<br />
462<br />
function A function describes a particular <strong>Implementer</strong> menu option or command. For<br />
example, the Activity Report function refers to the interactive menu option activity that<br />
prints the Activity Report and the submitted job that prints the report.<br />
A function is also a specific type of AllFusion 2E model object you can promote (FUN); an<br />
executable program or collection of programs.<br />
function redirection Function redirection relates to when an AllFusion 2E function is<br />
checked out and a new version of that function is created. Function redirection occurs to<br />
ensure the selected version of the model object is current and has its internal references<br />
directed towards the other object in the model. See also, currency.<br />
IFS directory IFS directory is the location of an IFS file. When used in this capacity, the<br />
directory usually refers to the full directory path. See also path.<br />
This term is used as part of support <strong>Implementer</strong> provides for IFS objects. The term<br />
corresponds to the OS/400 term, folder. In <strong>Implementer</strong>, it is referred to as a directory.<br />
IFS file IFS file refers to the contents of IFS directories on the iSeries. It is the PC term for any<br />
object stored in a directory. Some examples of files are executable programs, database files, or<br />
video segments.<br />
Within <strong>Implementer</strong>, the object name for an IFS file contains the IFS file name and the object<br />
code contains the dot and extension. If the file name has no extension, the object code is<br />
represented by a dot (.). Any name longer than eight characters and any extension longer<br />
than six characters is converted (allowing one position for the “.”), for example:<br />
IFS File Name Member/Object Name Object Code<br />
HelloiSeriesWorld.class HELLOiSe~1 .CLASS<br />
HelloiSeriesWorld HELLOiSe~1 .<br />
The combination of the IFS file name and extension is known as the environment relative<br />
name. Environment relative names up to 100 characters are supported. Environment relative<br />
names greater than 100 characters require setting up an environment with a deeper<br />
development path structure. See also IFS directory.<br />
IFS object IFS object refers to the objects (IFS files and directories) stored in the IFS space on<br />
the iSeries (IFS objects are not stored in libraries). It represents the IFS file names, directory<br />
names, or complete directory contents specified in check out and create request. IFS files and<br />
directories appear on reports and in audits. <strong>Implementer</strong> supports the following IFS objects:<br />
IFS Files<br />
You can check out or promote individual IFS files by using the object name and object<br />
code. Each file checked out or promoted is listed on reports and audits.<br />
IFS Directories<br />
You can check out or promote the contents of a subdirectory (including subdirectory<br />
contents) by using the backward slash (\) object code. For example, if you check out or
Glossary<br />
promote \dir2, all files and directories listed in subdirectory 2 are included. On reports<br />
and audits only the directory name (dir2) is listed.<br />
*.*<br />
You can check out or promote the contents of an environment’s directory (including<br />
files, subdirectories, and contents) by specifying *.* for the object name, and a<br />
backward slash (\) for the object code. For example, if you check out or promote<br />
IFS\dir using *.*, all IFS files and directories in IFS\dir are included. Reports and<br />
audits show member/object *.* to indicate that all contents were affected.<br />
implementation object An implementation object is the resulting OS/400 source and objects<br />
created from the generation of an AllFusion 2E model object. For example, a function usually<br />
creates source and objects for a program, display file, and help text. The source and objects<br />
generated for these objects are referred to as the implementation objects.<br />
<strong>Implementer</strong> Receiver The <strong>Implementer</strong> Receiver is a component of <strong>Implementer</strong> that<br />
resides on a remote system. Software can be distributed to the <strong>Implementer</strong> Receiver.<br />
import An import is the process of restoring LANSA objects from a device or save file<br />
created in an export activity into a different partition.<br />
JDE JDE is the abbreviation for J.D. Edwards (now PeopleSoft World).<br />
keyword restriction A keyword restriction is a facility that restricts access to object code<br />
command keywords. It is used to restrict sensitive keywords, such as the User Profile<br />
(USRPRF) keyword that controls adopted authorities.<br />
LANSA function A LANSA function is an OS/400 executable program created by LANSA<br />
and user-defined.<br />
LANSA objects LANSA objects are objects created in LANSA, such as files, fields, processes,<br />
and functions. They are not necessarily OS/400 objects.<br />
lock A lock is applied to a member/object when it is checked out. The lock is automatically<br />
released when the member object is promoted to a production (*PRD) environment.<br />
A Standard lock is the user action that created the lock through a standard check out.<br />
An Emergency lock is the user action that created the lock through an emergency check<br />
out.<br />
member/object A member/object is a member and/or object under <strong>Implementer</strong> control.<br />
It can be an object or source stored in a library, an element managed by a CASE tool (such as<br />
AllFusion 2E), or an IFS file. For example, it refers to an object for a data area, but for an RPG<br />
program it refers to the member and object.<br />
model object A model object is an AllFusion 2E object you can check out. AllFusion 2E has<br />
eight object types you can check out: access paths (ACP), applications (APP), arrays (ARR),<br />
conditions (CND), field (FLD), files (FIL), functions (FUN), and messages (MSG).<br />
463
Appendix D: Glossary<br />
464<br />
model object list Model object list is an AllFusion 2E feature that allows grouping some of<br />
the objects in a model into a named list. For change control purposes, model objects are<br />
checked out to lists to indicate changes were made or are planned. The model object lists are<br />
attached to the AllFusion 2E model and can be selected for AllFusion 2E promotions. Once<br />
you use a model object list for check out, it becomes a change list.<br />
model object name Model object name is the 25-character name given to an AllFusion 2E<br />
model object.<br />
move request Move request is an <strong>Implementer</strong> task that moves all object/source from the<br />
environments or libraries to the target environments. It performs any request instructions<br />
that impact production data, for example, MRGMSGF. In addition, it moves previous<br />
versions of source and objects to the archive libraries before the move, if specified.<br />
My Workbench My Workbench is a panel that allows developers to perform all necessary<br />
development work. The panel contains the items to be worked on and provides access to all<br />
tools needed to complete the development of the items and move them off the Workbench.<br />
The tools allow you to select and add items to the Workbench, access standard development<br />
tools to edit, compile and test items, and access user-defined tools through user-defined<br />
options. From the Workbench, you can access promotion functions to move completed items<br />
back into production, and book time against projects.<br />
non sequential development Non sequential development is the term used when the lock<br />
for a member/object does not follow the defined, standard development path. Any deviation<br />
from the defined workflow for a specific member is non sequential development. See also,<br />
sequential development and concurrent development.<br />
object code An object code defines a type of object and/or member to be promoted. The<br />
object code in <strong>Implementer</strong> combines information from the OS/400 object type and source<br />
type. Many object codes are shipped with <strong>Implementer</strong> and others can be user-defined.<br />
SQL-based objects use specific SQL object codes. For IFS files, the object code is the file<br />
extension.<br />
owning model object The owning model object is the name of a model object that owns<br />
another model object. For example, an access path (ACP) model object is always owned by a<br />
file (FIL) object. Not all model objects have an owning model object.<br />
partition A partition is a division of a LANSA system that has its own field reference files<br />
and processes. Each partition in LANSA is completely independent and no cross-referencing<br />
is allowed across partitions. A partition in LANSA is comparable to an environment in<br />
<strong>Implementer</strong>.<br />
path A path represents the location of a directory or subdirectory. It is the complete list of<br />
all directories and subdirectories between the root directory and the directory being<br />
identified. The subdirectories in the path are separated by a backward slash (\). For<br />
example, to identify the path of the SYSTEM directory nested in the WINDOWS directory that<br />
stems from the root directory, the notation is \WINDOWS\SYSTEM. See also qualified name<br />
and application path.
<strong>Implementer</strong> supports three paths in the IFS structure:<br />
Project relative path is the portion of the path that is unique to each object in the<br />
environment path. For example, \SUBDIR\PROGRAM.EXE.<br />
Glossary<br />
Environment path is the path specified at the environment level and common to all IFS<br />
objects in that environment. For example, \<strong>MKS</strong>\DEMO\PRD\INVENTORY.<br />
Full path is the environment path appended to the project relative path. For example,<br />
<strong>MKS</strong>\DEMO\PRD\INVENTORY\SUBDIR\PROGRAM.EXE.<br />
NOTE Avoid confusing the term path with the term application path, which refers to<br />
both standard and emergency paths for projects and environments.<br />
PeopleSoft World data dictionary element A data dictionary element refers to records in a<br />
dictionary for every field used in the system. This file controls how a field performs and edits<br />
on the screen and report. It also controls the edit processes of the field for validation.<br />
PeopleSoft World DREAM Writer A DREAM Writer has two parts that break down as<br />
follows: data selection that is translated to OPNQRYF or logical, and processing options that<br />
are user-controlled, program passed parameters.<br />
PeopleSoft World menu Menus are data records keyed to a menu name. This allows changes<br />
to menus without the need for programming.<br />
PeopleSoft World soft coding or vocabulary override Soft coding or vocabulary override<br />
refers to literals on screens that are not constants in the DDS of a screen object, but are<br />
retrieved from a file that is keyed to a program name. This allows changes to literals without<br />
the need for programming.<br />
PeopleSoft World software inventory or member master Software inventory or member<br />
master is a file that records each object in PeopleSoft World. This file contains the general<br />
severity level for compilation and other details for PeopleSoft World integration.<br />
PeopleSoft World soft coding items These are soft coding items supported by PeopleSoft<br />
World, such as user-defined codes, DREAM Writers, Member Master, Data Dictionary, Soft<br />
Coding, and Menus.<br />
PeopleSoft World traditional object These are traditional objects that require PeopleSoft<br />
World compiling, such as RPG programs, CL programs, and Assemblers (ASM).<br />
PeopleSoft World user-defined code (UDC) User-defined code is a generic table system for<br />
data field validation. The table system is controlled by three keys: System number, Table<br />
name, Element.<br />
primary target environment A primary target environment is the first target environment in<br />
a series of multiple target environments. The primary target environment is used in create<br />
request to check the existence of the target members/objects, to determine if the action for a<br />
member/object is create or change.<br />
465
Appendix D: Glossary<br />
466<br />
process A process is a logical grouping of related functions, for example, a process called<br />
ORDERENTRY consists of a number of functions, such as sales order maintenance, credit<br />
limit check, and sales order print.<br />
project Projects are used in <strong>Implementer</strong> to document why a change is made. A project<br />
reference can be used to check out and promote a member/object.<br />
promotion Promotion takes members/objects from one environment (or library) and moves<br />
them forward to a target environment. The term also refers to the entire process of returning<br />
a member/object back into production after it is checked out (compile and promote from<br />
development to QA, and promote from QA to production).<br />
promotion request A promotion request is a collection of related source members, sourcebased<br />
objects, non source based objects, or non OS/400 objects to be promoted to production<br />
libraries or quality assurance.<br />
qualified name A qualified name refers to a path and file name. This term is used as part of<br />
the support <strong>Implementer</strong> provides for IFS objects. For example, the qualified name of file<br />
SYSEDIT.EXE stored in the directory WINDOWS\SYSTEM is<br />
\WINDOWS\SYSTEM\SYSEDIT.EXE.<br />
related environment A related environment is the relationship of one environment to other<br />
environments in the format of an ordered list. The relationship is defined in Work with<br />
Related Environments. Related environment information is used in check out to display the<br />
member/object lists and related objects in different related environments. It uses the same<br />
order (sequence) to find a member/object in the list.<br />
repository A repository is an entity within the ADK product where you can create and<br />
maintain files, fields, data models, and reusable program specifications, such as action<br />
subroutines.<br />
requester A requester is the individual who creates a promotion request.<br />
request number A request number is the unique, four-character alphanumeric value<br />
assigned by <strong>Implementer</strong> when a new promotion request is created. It is used to identify the<br />
promotion request. Beginning with number 0001, the number increments by one for each<br />
new promotion request until number 9999 is reached. When this occurs, the left most position<br />
changes to an alpha character and the other positions reset to 0 (zero). Reading from right to<br />
left, this cycle continues until each position goes through the range 0–9, and A–Z. When<br />
number ZZZZ is reached, the number scheme automatically resets to number 0001.<br />
request status The request status defines where a promotion request is in the promotion<br />
cycle. It describes what steps were performed for the request and what remains to be done.<br />
For a complete listing of status codes, see “Request Inquiry” in the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong><br />
User <strong>Guide</strong>.<br />
required object Required objects are traditional source and executable objects generated<br />
from AS/SET program definitions. It contrasts the related object concept used in<br />
<strong>Implementer</strong> for traditional objects, which relates logical files to physicals and the programs<br />
that refer to them.
Glossary<br />
reset authorities Reset authorities is an <strong>Implementer</strong> function that revokes all object<br />
authorities for the libraries as specified in the environment, and then grants object authorities<br />
based on the authorities from the environment authority table.<br />
sequential development Sequential development is the term used when all locks for a<br />
member/object follow the defined standard development path and never deviate from the<br />
defined workflow. See also, non sequential development and concurrent development.<br />
session model list A session model list is the default model object list assigned when you<br />
begin an AllFusion 2E editing session. The model object list usually defaults to your OS/400<br />
user profile.<br />
You should not use the default session model list as a check out model object list. Instead,<br />
change the default value using the Edit Model Profile Editing options on the Access to model<br />
field value *DSNR on the Change AllFusion 2E User Capabilities panel or the AllFusion 2E<br />
Designer (*DSNR) menu. You can also have model users create and use their own object<br />
model list.<br />
stage library A stage library is a work library used to prepare (stage) each object before it<br />
moves into the target environment. The setting of object authorities, physical and logical<br />
members, and physical file data occurs while the object is in this library. A stage library exists<br />
while the move is in process.<br />
step A step refers to one of the up to four phases required to complete a request. In order,<br />
the steps are as follows:<br />
Model copy, only applies to AllFusion 2E special environments.<br />
Export, only applies to LANSA special environments.<br />
Compile, the compile step is optional.<br />
Distribute, only applies to requests that contain remote target environments.<br />
Move, required for every request.<br />
subdirectory A subdirectory refers to a directory and its contents that are stored within<br />
another directory. Subdirectories are included in the support <strong>Implementer</strong> provides for IFS<br />
objects. The term corresponds to the OS/400 term, folder. In <strong>Implementer</strong>, this is referred to<br />
as a directory. See also IFS directory.<br />
surrogate A surrogate is the internal identifier assigned to each AllFusion 2E model object.<br />
target environment group A target environment group is a group of environments<br />
promoted to at the same time. A target environment group is used when you create a<br />
promotion request to promote to more than one environment, eliminating the need to select<br />
each environment separately every time a promotion request is created.<br />
trigger A trigger is a set of actions that are executed automatically whenever a specified<br />
event occurs to a specified SQL-based table. An event can be an insert, update, or delete<br />
operation. The trigger can be run either before or after the event. Triggers are used to<br />
467
Appendix D: Glossary<br />
468<br />
preserve program to table integrity by checking on or changing data in a consistent manner.<br />
They help maintain the integrity of a database by preventing incorrect, unauthorized, or<br />
inconsistent changes to data. See also, constraint.<br />
version For AllFusion 2E environments, a version is a copy of a model object that is created<br />
in the same model. Only functions (FUN) and messages (MSG) can have multiple versions or<br />
are versionable. Versions are created by <strong>Implementer</strong> when you check out a model object that<br />
is previously checked out, and when archiving during the move step.<br />
version group A version group consists of all of the versions created for a model object.<br />
Only one version in the version group is the current version.<br />
workbench See My Workbench.<br />
work library A work library is a temporary library used during promotion to ensure the<br />
orderly movement of source and objects into the correct target libraries. The work libraries<br />
only exist while a promotion request is open (the status is not complete).
Index<br />
*GRANT authority method 96, 373<br />
*KEEP authority method 96, 373<br />
A<br />
ABSTRACT integration<br />
setup 304<br />
ACLs (Access Control Lists)<br />
Domino ACLs<br />
set in check out 348<br />
set in promotion 349<br />
Lotus Domino integration 345<br />
QNOTES directory authority 344<br />
action<br />
defined 457<br />
Activity Report 375, 396<br />
administrator<br />
<strong>Implementer</strong>, defined 457<br />
AllFusion 2E integration<br />
command considerations 304<br />
environment cleanup 404<br />
library considerations 304<br />
message versioning 307<br />
model check out considerations 307<br />
model value YSYSCHG 307<br />
object codes for model objects 464<br />
product library 406<br />
receiver library 413<br />
remote QA environment cleanup 384<br />
setup for EXCUSRSRC and EXCUSRPGM<br />
308<br />
American Software integration<br />
setup considerations 313<br />
AOS Message Manager integration<br />
setup 315<br />
Apache Web Server<br />
browser based development<br />
server requirements 156<br />
server setup 158<br />
APPC programs 165<br />
application path<br />
defined 457<br />
environment path setup 102<br />
project path setup 142<br />
using environment groups 125<br />
application set<br />
defined 458<br />
apply pending changes<br />
IAPYPNDCHG command 258<br />
<strong>MKS</strong> Integrity changes report 258<br />
to <strong>MKS</strong> Integrity 258<br />
architecture<br />
client/server 196<br />
multi tiered 196<br />
server 198<br />
software 198<br />
archive recovery<br />
defined 458<br />
archive reports<br />
Archives by Environment 383<br />
Archives by Request 383<br />
Archives per Tape 383<br />
archive to tape 379<br />
change volume ID 193, 379<br />
menu (IMARCTAP) 380<br />
reports 383<br />
restoring 193, 382<br />
saving 381<br />
submit to batch 381, 382, 383<br />
with third party utility 322<br />
Archive to Tape menu (IMARCTAP) 192, 379<br />
archiving<br />
defined 458<br />
LANSA requests 330<br />
setup considerations 14<br />
to tape<br />
IMARCTAP data area 192, 379<br />
setting up for 379<br />
third-party utility support 411<br />
AS/SET integration<br />
ADK object code setup 317<br />
application sets setup 316<br />
archiving setup 317<br />
capabilities for generated objects 318<br />
environment group setup 317<br />
469
Index<br />
environment setup 107<br />
promoting generated objects 319<br />
setup overview 316<br />
special characteristics 317<br />
system control maintenance setup 316<br />
assessing development process 204<br />
associate calls update<br />
console method 328<br />
history logs 327<br />
setup 325<br />
silent method 328<br />
authority<br />
Capability Wizard for setup 80<br />
MWIPROD 117<br />
QSECOFR 117<br />
restricting OS/400 security 79<br />
security data areas 412<br />
authority method<br />
*GRANT 96, 373<br />
*KEEP 96, 373<br />
B<br />
batch programs for AS/SET<br />
defined 458<br />
binding directory<br />
defined 458<br />
BPCS integration<br />
deactivate standard object codes 322<br />
setup 320<br />
BRMS integration 322, 380<br />
build list 118<br />
different source and object names 118<br />
Environment Repository Report 122<br />
for IFS objects 119<br />
IBLDMBOLST command option 119<br />
running a build 119<br />
setup overview 13<br />
stamping object revision numbers 118<br />
build member/object list, see build list<br />
C<br />
capabilities, state based 208<br />
Capability Wizard<br />
command buttons 389<br />
customizing user capabilities 394<br />
feature overview 385<br />
installing<br />
on desktop 387<br />
on Windows 386<br />
470<br />
verifying TCP/IP connectivity 386<br />
requirements 386<br />
selecting environments 391<br />
selecting users 390<br />
starting and using 389<br />
updating <strong>Implementer</strong> 395<br />
working with capability details 393<br />
change<br />
applying pending changes 258<br />
managing and tracking 198–199<br />
pending 257<br />
change controlled model<br />
defined 459<br />
change list<br />
defined 459<br />
change repository<br />
for IFS objects 377<br />
for traditional objects 376<br />
change request<br />
managing, overview 57<br />
process overview 59<br />
changes report<br />
<strong>MKS</strong> Integrity 258<br />
check in<br />
defined 459<br />
check out<br />
defined 459<br />
enable one step checkout 77<br />
set Domino ACLs 348<br />
client/server architecture 196<br />
clipboard<br />
defined 459<br />
CODE/400 integration<br />
setup 323<br />
co-existing issue management systems<br />
convert DesignTracker data to issues 431<br />
enable co-existence 249<br />
feature overview 247<br />
promotion considerations 248<br />
set last DR number 250<br />
set next issue number 252<br />
set user’s default system 253<br />
Cognos integration<br />
setup 362–364<br />
commands<br />
IAPYPNDCHG, Apply Pending Changes<br />
258<br />
IBLDMBOLST, Build List 119<br />
ICGHREP, Change Repository 376<br />
ICHGREPIFS, Change Repository IFS 377<br />
ICHGRMTRQS, Change Remote Request<br />
185
ICRTRQS, Create Request 36<br />
ICVTDT, Convert DT to <strong>MKS</strong> Integrity 438<br />
IDBPRG, Purge History 376<br />
IDLTLIBREF, Delete Library References<br />
378<br />
IDSPSVRLOG, Display Server Log 225<br />
IEDTLIBL, Edit Library List 415<br />
IEXCCKOCMD, Execute Checkout 349<br />
IEXCRQSDTL, Execute Request Detail 349<br />
IMARCTAP Archive to Tape 380<br />
IMARCTAP, Archive to Tape 192, 379<br />
IPRTREPRPT, Repository Report 123<br />
ISETDOMACL, Set Domino ACL 347<br />
IUPDCI, Update <strong>MKS</strong> Integrity 240<br />
IVFYRPT, Verification Report 124<br />
special commands by environment 103<br />
STRCM Start AllFusion 2E CM 10<br />
STRCR Start AllFusion 2E CM Receiver 10<br />
STRIM Start <strong>Implementer</strong> 10<br />
STRIM Start <strong>Implementer</strong>, keywords 11<br />
STRIR Start <strong>Implementer</strong> Receiver 10<br />
STRTCPSVR, Start TCP/IP Server 158<br />
WRKHTTPCFG, Work with HTTP<br />
Configuration 157<br />
comments<br />
in create request 69<br />
communications<br />
emergency update mode 255–259<br />
mode name 428<br />
options 428<br />
remote network identifier 429<br />
*LOC 429<br />
*NETATR 429<br />
*NONE 429<br />
name 429<br />
SNADS configuration 179<br />
TCP/IP configuration 173<br />
communications user profile data area 403<br />
compile listing<br />
delete after promotion 66<br />
compile request<br />
defined 459<br />
concurrent development<br />
concurrent development scope 71<br />
defined 459<br />
resolve conflicts capability 111<br />
user capability 111<br />
configuring property files<br />
conversion properties file 441<br />
DTBridge properties file 300, 325<br />
conflict request<br />
defined 459<br />
constraint<br />
defined 459<br />
controlling remote job schedules 181<br />
conventions 4<br />
conversion properties file 445–453<br />
convert to <strong>MKS</strong> Integrity<br />
conversion methods 244<br />
prerequisites 248<br />
with data retention<br />
basic conversion example 437<br />
conversion properties file 446<br />
data conversion rules 433<br />
feature overview 247<br />
generate the conversion file 445<br />
ICVTDT command 438<br />
mapping data 441<br />
<strong>MKS</strong> assistance options 431<br />
organizational activities 436<br />
overview of data conversion 432<br />
run the conversion 249<br />
see also, co-existing<br />
set last DR number 250<br />
set next issue number 252<br />
set user’s default system 253<br />
without data retention<br />
overview 244<br />
run the conversion 244<br />
Convert to <strong>MKS</strong> Integrity (ICVTDT) command<br />
438<br />
create request<br />
create in batch 69<br />
default promotion method 69<br />
defined 459<br />
optimize PF promotions 69<br />
require comments feature 69<br />
currency<br />
defined 460<br />
current model object<br />
defined 460<br />
customer care options 5<br />
customizing <strong>Implementer</strong> 414<br />
D<br />
data area<br />
changing 402<br />
for AllFusion 2E 402<br />
IMADDOBJ, add related for service<br />
programs 402<br />
IMARCTAP, archive to tape libraries 402<br />
IMBNDUPD, Pathfinder update 402<br />
Index<br />
471
Index<br />
472<br />
IMBYPSRJW, bypass window on reject<br />
410<br />
IMCMNUSR, communications user<br />
profile 172, 403<br />
IMCOREJ, check out/reject options 403<br />
IMDLTFRMUP, delete user programs 404<br />
IMDLTFRMUS, delete user source 404<br />
IMDLTLOCK, delete locks 404<br />
IMDLYJOB, delay evoked jobs 404<br />
IMDOMDATA, Domino server data<br />
directory 339, 405<br />
IMDSPMSG, display message panel 405<br />
IMEMGSTP, emergency through step 405<br />
IMFTPPASV, FTP Passive Mode 174, 405<br />
IMJDKVER, JDK Version 241<br />
IMJDKVER, JDK version 406<br />
IMLIBRARY, <strong>Implementer</strong> library name<br />
406<br />
IMLNMSG, LANSA error messages 408<br />
IMLNPSO, LANSA partition security<br />
officer 408<br />
IMLNTSK, LANSA task usage 332, 408<br />
IMLOGCL, change logging level 407<br />
IMMULTJOB, submit multiple jobs 407<br />
IMMULTOBJ, multiple object single<br />
source check out 407<br />
IMMULTRQS, same item on multiple<br />
requests 408<br />
IMPATHSLSH, path slash 409<br />
IMPKGPRC, process package 409<br />
IMPRFX, work library prefix 409<br />
IMPRVCMDS, create commands and<br />
TGTRLS parameter 408<br />
IMRCLAGRP, reclaim activation group<br />
410<br />
IMREJECT, remove objects on QA reject<br />
409<br />
IMRETFILID, return file and member ID<br />
after promotion 410<br />
IMSEQRQS, sequential request 411<br />
IMSPCCMD, special commands 411<br />
IMSVPGM, save program name 323, 411<br />
IMTSTMOD, promotion batch steps test<br />
mode 411<br />
IMWLCLNUP, Work Library Cleanup 414<br />
IMWRNTRGLF, invalid logical file control<br />
412<br />
IRJOBQ, remote job queue 376, 413<br />
IRSBMMTD, remote job submission<br />
method 376, 413, 414<br />
ITAPEVOLUM next tape label for<br />
archives 193, 379<br />
ITAPEVOLUM, next tape label for<br />
archives 412<br />
LFREFOBJ, reference file to set LF<br />
authority 412<br />
object codes for promotion 137<br />
PFREFOBJ, reference file to set PF<br />
authority 412<br />
RCVLIB, Receiver library name 413<br />
retain values when promoting 136<br />
SDMAUTUSR, authorized user profile for<br />
IFS objects 413<br />
data model<br />
defined 460<br />
database purge, see purge history<br />
deleting tutorial data 396<br />
design request<br />
approvals, defined 460<br />
convert to issue 431<br />
defined 460<br />
disposition, defined 460<br />
object stamping<br />
overview 146<br />
setup 146, 147<br />
require for check out 87<br />
status, defined 460<br />
DesignTracker<br />
convert to <strong>MKS</strong> Integrity<br />
overview 243<br />
with data retention 247<br />
without data retention 244<br />
development process, assessing 204<br />
directory<br />
defined 462<br />
distribution<br />
APPC programs 165<br />
communication line considerations 166<br />
APPN 166<br />
network control program (NCP) 167<br />
switched line 166<br />
concepts 161<br />
database file considerations 164<br />
<strong>Implementer</strong> Receiver 162<br />
integration with local promotions 163<br />
LPAR support 162<br />
move step considerations 189<br />
multiple system development 189<br />
performance 191<br />
request number consideration 191<br />
options<br />
single step 180<br />
two step 180<br />
problem determination 193
emote initiated moves 181<br />
remote source members 163<br />
simultaneous to multiple remotes 181<br />
substeps described<br />
receive network file 189<br />
restore from save files 189<br />
save work libraries 189<br />
send work libraries 189<br />
distribution methods 164<br />
SDMCom 164, 427<br />
SNADS 165<br />
tape 165<br />
TCP/IP 165, 173<br />
DLO<br />
defined 461<br />
document<br />
defined 461<br />
Domino Designer, see Lotus Domino<br />
integration<br />
DTBridge<br />
installing on desktop 298<br />
installing on Windows 297<br />
properties file 299–300<br />
accessing and updating 299<br />
general properties 301<br />
<strong>MKS</strong> Integrity properties 300<br />
SQL for help desk integration 327<br />
SupportCenter properties 326<br />
requirements for using 297<br />
verifying TCP/IP connectivity 297<br />
E<br />
e-mail messaging 72<br />
emergency update mode 255–259<br />
activate/deactivate 257<br />
active mode 256<br />
apply pending changes 257<br />
changing modes 255<br />
development considerations 256<br />
inactive mode 256<br />
MWIPROD requirement 236, 256<br />
environment<br />
add dependencies to request 86<br />
add related objects to request 86<br />
source of information 88<br />
application development path 102<br />
build repository list 117–121<br />
clearing remote QA 384<br />
delete an environment 96<br />
delete objects after promotion 92<br />
distinguish local and remote 89<br />
environment group 126<br />
environment special commands 103<br />
feature overview 81<br />
library authority setup 68<br />
library list<br />
considerations 97<br />
defined 461<br />
how used 96<br />
setup 97<br />
name consideration for <strong>MKS</strong> Source 82<br />
object code<br />
deactivate for BPCS 322<br />
overrides 91<br />
overrides setup 92<br />
object name rules 138<br />
related environment 100<br />
defined 466<br />
remove object in from lib/env 87<br />
remove source in from lib/env 87<br />
require issue or design request 87<br />
retain request on remote 90<br />
setup<br />
AS/SET requirements 107<br />
basic setup 82–91<br />
for IFS objects 93<br />
LANSA requirements 107<br />
local development 419–420<br />
local production 418–419<br />
local quality assurance 420–421<br />
local user acceptance 422–423<br />
PeopleSoft World requirements 108<br />
remote production 423–430<br />
TCP/IP setup 174<br />
types<br />
defined 461<br />
user capabilities 109–112<br />
environment authorities<br />
Capability Wizard 80<br />
establish or reset 372<br />
environment group<br />
feature overview 125<br />
on application path 125<br />
environment ID<br />
defined 461<br />
environment path<br />
defined 458<br />
Environment Report 106<br />
Environment Repository Report 122<br />
Environment Verification Report 123<br />
Execute Checkout (IEXCCKOCMD) command<br />
349<br />
Index<br />
473
Index<br />
Execute Request Detail (IEXCRQSDTL)<br />
command 349<br />
export<br />
defined 461<br />
export list<br />
defined 461<br />
export to <strong>Implementer</strong> from <strong>MKS</strong> Source<br />
feature overview 296<br />
property file setup 302<br />
F<br />
file<br />
defined 461<br />
File Transfer Protocol, see FTP<br />
firewall configuration for TCP/IP 175<br />
folder<br />
defined 461<br />
FTP<br />
for TCP/IP distribution 175<br />
function<br />
defined 463<br />
function keys<br />
changing, menu option 397<br />
function redirection<br />
defined 462<br />
G<br />
getting help 5<br />
getting started with <strong>Implementer</strong> 1<br />
glossary of terms 457<br />
H<br />
Hawkeye integration<br />
requirements 354<br />
setup 354–355<br />
help desk integration 324–328<br />
feature overview 324<br />
requirements 325<br />
setup<br />
DTBridge properties file 325<br />
SQL statements for properties 327<br />
transaction history logs 327<br />
using the integration<br />
overview 327<br />
update calls console method 328<br />
update calls silent method 328<br />
HTTP server<br />
browser based development<br />
474<br />
I<br />
configuring 157<br />
server port requirements 156<br />
server security requirements 156<br />
IAPYPNDCHG, Apply Pending Changes<br />
command 258<br />
IASP<br />
requirements for using 154<br />
IBLDMBOLST Build List command 119<br />
IBM Backup Restore Management System, see<br />
BRMS integration<br />
IBM WebSphere Development Studio Client for<br />
iSeries, see WDSc integration<br />
ICHGREP Change Repository command 376<br />
ICHGREPIFS Change Repository IFS command<br />
377<br />
ICHGRMTRQS Change Remote Request<br />
command 185<br />
IDBPRG Purge History command 376<br />
IDLTLIBREF Delete Library References<br />
command 378<br />
IEDTLIBL Edit Library List command 415<br />
upgrade considerations 415<br />
IEXCCKOCMD, Execute Checkout command<br />
349<br />
IEXCRQSDTL, Execute Request Detail<br />
command 346, 349<br />
IFS directory<br />
defined 462<br />
IFS object<br />
defined 462<br />
IFS object management<br />
automatic object code setup 68<br />
browser-based development<br />
HTTP configuration 157<br />
HTTP mapping directives 157<br />
HTTP method directives 157<br />
HTTP server security 157<br />
iSeries setup 156<br />
starting the TCP/IP server 158<br />
environment setup 93<br />
mounted drive setup 159<br />
IMADDOBJ data area 402<br />
IMARCTAP command 380<br />
IMARCTAP data area 402<br />
IMBNDUPD data area 402<br />
IMBYPSRJW data area 410<br />
IMCMNUSR data area 172, 403<br />
IMCOM
end before backup 176<br />
TCP/IP job queue 176<br />
TCP/IP subsystem 176<br />
IMCOMCTL<br />
command parameters 177<br />
IMCOREJ data area 403<br />
IMDLTFRMUP data area 404<br />
IMDLTFRMUS data area 404<br />
IMDLTLOCK data area 404<br />
IMDLYJOB data area 404<br />
IMDOMDATA data area 339, 405<br />
IMDSPMSG data area 405<br />
IMEMGSTP data area 405<br />
IMFTPPASV data area 405<br />
IMJDKVER data area 241, 406<br />
IMLIBRARY data area 406<br />
IMLNMSG data area 408<br />
IMLNPSO data area 408<br />
IMLNTSK data area 332, 408<br />
IMLOGCL data area 407<br />
IMMULTJOB data area 407<br />
IMMULTOBJ data area 407<br />
IMMULTRQS data area 408<br />
IMPATHSLSH data area 409<br />
IMPKGPRC, data area 409<br />
implementation object<br />
defined 463<br />
<strong>Implementer</strong> Receiver<br />
defined 463<br />
local partitioning (LPAR) 162<br />
see also, remote<br />
<strong>Implementer</strong> Server<br />
configuring the server 217–219<br />
IDSPSVRLOG command 225<br />
install and configure on iSeries 218<br />
install and configure on PC 220<br />
install and configure on UNIX 222<br />
log files to retain 219<br />
managing the server 223–225<br />
patches and PTFs 225<br />
purge server log files 225<br />
server log file 225<br />
status descriptions 219<br />
time zone offset 220<br />
troubleshooting 225<br />
import<br />
defined 463<br />
IMPRFX data area 409<br />
IMPRVCMDS data area 408<br />
IMRCLAGRP data area 410<br />
IMREJECT data area 409<br />
IMRETFILID data area 410<br />
IMSEQRQS data area 411<br />
IMSPCCMD data area 411<br />
IMSVPGM data area 411<br />
IMSYSLIB considerations 154<br />
IMTSTMOD data area 411<br />
IMWLCLNUP data area 414<br />
IMWRNTRGLF data area 412<br />
Independent Auxiliary Storage Pool, see IASP<br />
installing <strong>Implementer</strong> 2<br />
Integrated File System, see IFS<br />
integrated solutions<br />
change management 50<br />
change request process overview 58<br />
development lifecycle overview 52<br />
iSeries component overview 198<br />
iSeries management 50<br />
managing change requests overview 53<br />
multi tiered architecture 197<br />
overview 196<br />
process and workflow 198<br />
software configuration management 50<br />
IPRTREPRPT, Repository Report 123<br />
IRJOBQ, remote job queue data area 376, 413<br />
IRSBMMTD, remote job submission data area<br />
376, 414<br />
ISAVARC Save Archives to Tape command<br />
192, 379<br />
ISETDOMACL, Set Domino ACL command<br />
347<br />
ISGNDOMDB, Sign Domino Database<br />
command 354<br />
ISNDMAIL command 72<br />
issue<br />
convert DesignTracker data to 431<br />
environment issue state 89<br />
manage, overview 198<br />
object stamping setup 146, 147<br />
require for check out 87<br />
issue types<br />
defined 198<br />
relationships 199<br />
ITAPEVOLUM data area 193, 379, 412<br />
IUPDCI, Update <strong>MKS</strong> Integrity command 240<br />
IVFYRPT, Environment Verification Report 124<br />
J<br />
J.D. Edwards, see PeopleSoft World integration<br />
JDE<br />
defined 463<br />
see also, PeopleSoft World integration<br />
Index<br />
475
Index<br />
job description<br />
MWIJOBD<br />
AS/SET 316<br />
LANSA 329<br />
library list considerations 97<br />
job overrides<br />
for purge history 376<br />
submitting 372<br />
K<br />
keyword restriction<br />
defined 463<br />
L<br />
LANSA integration<br />
archiving 330<br />
data areas<br />
IMLNMSG, error messaging 408<br />
IMLNPSO, partition security officer<br />
408<br />
IMLNTSK, task tracking and Visual<br />
LANSA 332, 408<br />
environment setup 107<br />
integration overview 328<br />
MWIJOBD job description 329<br />
object codes<br />
for LANSA objects 331<br />
same file and partition 331<br />
setting up 134<br />
objects<br />
defined 463<br />
partition security officer 408<br />
stop promotion by message ID 331<br />
task tracking<br />
feature overview 332<br />
setting up 332<br />
Visual LANSA 332–333<br />
IMLNTSK data area 408<br />
requirements and setting up 332<br />
Web interface setup 328<br />
Lawson Software integration 333<br />
level check<br />
incorrect library list 97<br />
LFREFOBJ data area 412<br />
library<br />
establish authorities<br />
after changing 374<br />
disallow unauthorized access 374<br />
incorrect authority set 374<br />
476<br />
restrict external access 374<br />
library authority setup 68<br />
library list<br />
considerations for MWIJOBD job<br />
description 97<br />
Edit Library List (IEDTLIBL) command<br />
415<br />
environment library list 96<br />
for special commands 96<br />
level check if incorrect 97<br />
system library list requirements 154<br />
third party integration considerations 97<br />
local partitioning (LPAR) support 161<br />
lock<br />
defined 463<br />
logging CL statements 407<br />
Lotus Domino integration 336<br />
ACLs<br />
set in check out 348<br />
set in promotion 349<br />
adding custom tools 340<br />
adding SmartIcons 342<br />
database signing<br />
agent signing application 352<br />
Domino setup 351–352<br />
<strong>Implementer</strong> setup 352–354<br />
ISGNDOMDB command 354<br />
key considerations 351<br />
upgrade considerations 352<br />
Domino server URL 72<br />
IMDOMDATA data area 339<br />
integration requirements 338<br />
managing NSF and NTF objects 337<br />
setup<br />
adding custom tools 340<br />
adding SmartIcons 342<br />
defining ACL directives 345<br />
Domino Designer setup 340<br />
<strong>Implementer</strong> setup 339<br />
iSeries setup and configuration 339<br />
QNOTES directory authority for<br />
ACLs 344<br />
M<br />
managing<br />
issues 198, 199<br />
states 208–212<br />
member/object<br />
defined 463<br />
member/object list
for different source/object names 118<br />
menus<br />
command options, see Start <strong>Implementer</strong><br />
(STRIM) command<br />
<strong>Implementer</strong> Menu 11<br />
messages<br />
logging level 408<br />
<strong>MKS</strong> Integrity integration<br />
assessing process 204<br />
changes report 258<br />
convert to <strong>MKS</strong> Integrity 243–254<br />
conversion methods 244<br />
converting data 431–453<br />
set last allowed DR number 250<br />
set next issue number 252<br />
set user’s default system 253<br />
with data retention 247<br />
without data retention 244<br />
current status 229<br />
default issue management system 228<br />
development scenario 60<br />
DTBridge<br />
IUPDCI special command setup 242<br />
update from <strong>Implementer</strong> 241<br />
emergency update mode 255–259<br />
activate/deactivate 257<br />
active mode 256<br />
apply pending changes 257<br />
changing modes 255<br />
development considerations 256<br />
inactive mode 256<br />
environments<br />
issue state 89<br />
require issue in checkout 87<br />
setting up 203–240<br />
communication parameters 229<br />
emergency mode authority 235<br />
environments 237<br />
<strong>Implementer</strong> setup 216<br />
issue management system 228<br />
managing states 208<br />
<strong>MKS</strong> Integrity parameters in<br />
<strong>Implementer</strong> 226<br />
overriding issue states 238<br />
promote from <strong>MKS</strong> Integrity 212–<br />
216, 242–243<br />
promotion path status entries 233<br />
require issues in check out 237<br />
state based capabilities 208<br />
states in <strong>Implementer</strong> 233–235<br />
updating state changes 234<br />
user profiles 235<br />
state based capabilities 208<br />
system requirements 202, 261<br />
user for <strong>MKS</strong> Integrity Server 74<br />
<strong>MKS</strong> Source integration<br />
archive source for object code 132<br />
export to <strong>Implementer</strong><br />
feature overview 259<br />
property file setup 302<br />
<strong>Implementer</strong> setup and administration<br />
274–295<br />
define <strong>MKS</strong> Source in <strong>Implementer</strong><br />
275<br />
define object codes 278<br />
product/version and development<br />
path 283<br />
product/version environments and<br />
population 286<br />
product/version/release and<br />
checkpointing 286<br />
products and source archiving 280<br />
<strong>MKS</strong> Source setup 262–274<br />
create base projects 263<br />
create <strong>Implementer</strong> group 264<br />
create integration user 264<br />
modify Integrity Server<br />
communication file 206<br />
set <strong>MKS</strong> Source policies 265<br />
prepare for next release 293<br />
prepare for next version 293<br />
process and workflow 260<br />
requirements 261<br />
<strong>MKS</strong>IM library data area 406<br />
<strong>MKS</strong>IM product library<br />
library list considerations 97<br />
system library list 154<br />
<strong>MKS</strong>IR product library<br />
RCVLIB data area 413<br />
system library list 154<br />
model object<br />
defined 463<br />
model object list<br />
defined 464<br />
model object name<br />
defined 464<br />
model value YSYSCHG 307<br />
mounted drive setup for IFS 159<br />
move request<br />
defined 464<br />
multi tiered architecture 196, 197<br />
multi-platform scenarios 49–61<br />
change management 50<br />
change request process overview 58<br />
Index<br />
477
Index<br />
development lifecycle 52<br />
iSeries management 50<br />
managing change requests overview 53<br />
software configuration management 50<br />
MWIJOBD job description<br />
library list considerations 97<br />
MWIPROD user profile<br />
authority and object owner 117<br />
SNADS user ID 429<br />
My Workbench<br />
defined 464<br />
N<br />
network configuration<br />
environment examples<br />
local location name 428<br />
remote location name 428<br />
system name 428<br />
target release 428<br />
feature overview 167<br />
setup for remote deployment 168<br />
SNA distribution setup 168<br />
TCP/IP distribution setup 169<br />
NewVersion<br />
applying new vendor release 35<br />
non-sequential development<br />
defined 464<br />
O<br />
object code<br />
AllFusion 2E model objects 133<br />
archive source in <strong>MKS</strong> Source 132<br />
auto-create for IFS objects 68<br />
changing 129<br />
deactivating 128<br />
deleting IFS object codes 135<br />
DTAARA to copy from library 137<br />
DTAARAR to retain existing value 137<br />
environment build list 119<br />
environment overrides 91, 92, 133<br />
for AS/SET special characteristics 134<br />
for DDM support 135<br />
for IFS objects 135<br />
for LANSA 133, 134, 331<br />
Web interface setup 331<br />
for PeopleSoft World 133, 134<br />
functional purpose 137<br />
object name rules 137<br />
reactivating 129<br />
478<br />
repository maintenance 376<br />
set data area value in promotion 137<br />
user profile overrides 80<br />
object name rules<br />
all object codes/specific environment 141<br />
feature overview 137<br />
name validation 137<br />
rule maintenance 137<br />
specific object code/all environments 141<br />
specific object code/environment 138<br />
object version stamping<br />
activate issue or DR stamping 70<br />
activate object version stamping 70<br />
build repository to set version 118<br />
feature overview 146<br />
initialize version numbers 146<br />
setup 147<br />
version methods 147<br />
<strong>MKS</strong> Source integration 147<br />
user defined program 71<br />
version number methodology 70<br />
optimize PF promotions 69<br />
OS/400<br />
changing the system name 154<br />
commands<br />
DSPNETA 154<br />
RSTLIB 35<br />
IMSYSLIB for C development 154<br />
new releases 153<br />
previous release support 408<br />
restricting user authority 79<br />
owning model object<br />
defined 464<br />
P<br />
partition<br />
defined 464<br />
path<br />
defined 464<br />
see also, application path or project path<br />
PathFinder integration<br />
see Hawkeye integration<br />
PDM<br />
defining options 144<br />
option for ICHKOUT command 145<br />
option for ICRTRQS command 145<br />
pending changes<br />
applying 257, 258<br />
PeopleSoft World integration<br />
common library setup 108
data dictionary<br />
defined 465<br />
DREAM Writer<br />
defined 465<br />
environment setup 108<br />
installing on host 356<br />
integration overview 355<br />
menu<br />
defined 465<br />
object code setup 134<br />
printer file overrides 360<br />
soft coding item<br />
archiving setup 358<br />
defined 465<br />
software inventory or member master<br />
defined 465<br />
traditional object<br />
defined 465<br />
traditional object codes 360<br />
user defined code (UDC)<br />
defined 465<br />
security for 359<br />
PFREFOBJ data area 412<br />
Powerhouse integration<br />
setup 362<br />
prerequisites to using this guide 4<br />
previous OS/400 release support 408<br />
primary target environment<br />
defined 465<br />
problem determination<br />
logging CL statements 407<br />
process<br />
assessing product development 204<br />
defined 466<br />
project<br />
create a project path 142<br />
defined 466<br />
setup considerations 13<br />
project path<br />
defined 458<br />
project tracking<br />
with an issue 230<br />
promotion<br />
defined 466<br />
enable one step promotion 77<br />
from Domino Designer<br />
set Domino ACLs 349<br />
from within <strong>MKS</strong> Integrity 201<br />
<strong>Implementer</strong> setup 242–243<br />
<strong>MKS</strong> Integrity setup 212–216<br />
one step, in batch 69<br />
request comments feature 69<br />
promotion request<br />
defined 466<br />
properties files<br />
conversion properties file 441<br />
DTBridge properties file 300, 325<br />
purge history<br />
function overview 374<br />
object status 374<br />
on remote system 376<br />
submitting job overrides 376<br />
Q<br />
QSAMPLE<br />
Edit Library List (IEDTLIBL) command<br />
415<br />
IMCODF user exit 415<br />
IMCRDF user exit 415<br />
IMPRMV3 user exit 415<br />
IMUPDLCK user exit 415<br />
overview of user exit programs 414<br />
QSECOFR user profile<br />
authority 117<br />
qualified name<br />
defined 466<br />
R<br />
RCVLIB data area 413<br />
receiver, see <strong>Implementer</strong> Receiver<br />
related documentation 3<br />
related environment<br />
defined 466<br />
related object processing<br />
add from path without locks 72<br />
environment setup 86<br />
maintain across environments 69<br />
related objects<br />
IMSYSLIB considerations 154<br />
IMSYSLIB for C development 154<br />
related request setup 69<br />
remote<br />
change remote request command 185<br />
communications options 428<br />
controlling remote job schedules 181<br />
environment, vs. local environment 89<br />
job queue data area (IRJOBQ) 413<br />
job submission method data area<br />
(IRSBMMTD) 414<br />
see also <strong>Implementer</strong> Receiver 185<br />
reports<br />
Index<br />
479
Index<br />
Activity Report 375, 396<br />
Archives by Environment 383<br />
Archives by Request Report 383<br />
Archives Per Tape Report 383<br />
Environment Report 106<br />
Environment Repository Report 122<br />
Environment Verification Report 123<br />
repository<br />
defined 466<br />
environment build 117–121<br />
report of environment status 122<br />
repository maintenance<br />
function overview 376<br />
IDLTLIBREF command 378<br />
request number<br />
defined 466<br />
next number assigned 66<br />
requester<br />
defined 466<br />
required objects<br />
defined 466<br />
reset authorities<br />
defined 467<br />
function overview 372<br />
IFS considerations 373<br />
setup overview 13<br />
Restore Library (RSTLIB) command 35<br />
restoring<br />
archive from tape 193, 382<br />
ROBOT integration<br />
scheduling 68<br />
setup 364<br />
S<br />
scenarios<br />
host system, overview 15<br />
local 25, 27, 29, 33<br />
modification to vendor software 33<br />
multiple database libraries, same<br />
structure 25<br />
multiple software releases 29<br />
separate production modifications 27<br />
multi-platform development and<br />
deployment 60<br />
release control 37<br />
remote 41, 43, 45, 46, 48<br />
check out from remote 48<br />
multiple remote production, same<br />
changes 45<br />
multiple remotes 46<br />
480<br />
remote production, different request<br />
41<br />
testing on remote 43<br />
remote production same request 39<br />
remote system, overview 16<br />
scheduling<br />
promotion steps 99<br />
setup for ROBOT 68<br />
SDMAUTUSR data area<br />
for IFS mounted drive 159<br />
IFS authorized user 413<br />
SDMCom<br />
distribution 165<br />
security officer<br />
authority 117<br />
Send eMail Message command 72<br />
sequential development<br />
defined 467<br />
server<br />
Apache Web Server for iSeries 155<br />
<strong>Implementer</strong> server<br />
setup and administration 216–225<br />
QHTTPSVR 158<br />
TCP/IP HTTP 158<br />
Set Domino ACL (ISETDOMACL) command<br />
347<br />
setup<br />
ABSTRACT integration 304<br />
American Software integration 313<br />
archive considerations 14<br />
archive to tape 379<br />
AS/SET integration 316<br />
BPCS integration 320<br />
CODE/400 integration 323<br />
Cognos integration 362<br />
environments 81–91<br />
general considerations 13<br />
Hawkeye integration 354<br />
LANSA integration 328<br />
PeopleSoft World integration 355<br />
Powerhouse integration 362<br />
projects, considerations 13<br />
ROBOT integration 364<br />
system control maintenance 65–72<br />
user profiles 72–80<br />
Sign Domino Database (ISGNDOMDB)<br />
command 354<br />
SNADS<br />
communication setup 179<br />
distribution 165<br />
user address 429<br />
*SYSTEM 429
name 429<br />
user ID 429<br />
software architecture, common 198<br />
software development lifecycle<br />
change request process 59<br />
managing change requests 57<br />
overview 52<br />
source and object name<br />
when different 118<br />
special commands<br />
for Domino ACL support 346<br />
for <strong>MKS</strong> Integrity integration 242<br />
special commands by environment<br />
apply to all environments 104<br />
feature overview 103<br />
library list 96<br />
Start AllFusion 2E CM (STRCM) command 11<br />
Start AllFusion 2E CM Receiver (STRCR)<br />
command 10<br />
Start <strong>Implementer</strong> (STRIM) command<br />
keywords and options 11<br />
menu options 10<br />
Start <strong>Implementer</strong> Receiver (STRIR) command<br />
10<br />
Start TCP/IP Server (STRTCPSVR) command<br />
158<br />
state 208–212<br />
state based capabilities 208<br />
state setup 232–235<br />
detail field descriptions 234<br />
promotion path status entries 233<br />
updating state changes 234<br />
step<br />
defined 467<br />
Structured Query Language (SQL)<br />
for help desk integration 327<br />
submitting<br />
job overrides 372<br />
multiple jobs 407<br />
support options 5<br />
surrogate<br />
defined 467<br />
System Control Maintenance<br />
add related objects from path 72<br />
assign version number method 70<br />
cross environment related objects 69<br />
default SMTP server 72<br />
feature overview 65<br />
next request number 66<br />
object version stamping 70<br />
one step promotion in batch 69<br />
optimize PF promotions 69<br />
promotion request comments 69<br />
require issue or DR stamping 70<br />
setup overview 13<br />
unique versioning programs 71<br />
system library list<br />
<strong>MKS</strong>IM library 154<br />
<strong>MKS</strong>IR library 154<br />
system name<br />
change OS/400 name 154<br />
T<br />
tape<br />
distribution 165<br />
tape archiving 379<br />
target environment group<br />
defined 467<br />
TCP/IP<br />
adding server security 157<br />
distribution 165<br />
distribution method 173<br />
environment setup 174<br />
firewall configuration 175<br />
FTP passive mode 174, 405<br />
HTTP server port requirements 156<br />
HTTP server security requirements 156<br />
IMCOM job queue 176<br />
IMCOM subsystem 176<br />
network configuration setup 169<br />
OS/400 FTP service 175<br />
overview 173<br />
set up considerations, additional 175<br />
starting the server 158<br />
STRTCPSVR, Start TCP/IP Server<br />
command 158<br />
verifying DTBridge connection 297<br />
TGTRLS parameter 408<br />
third party integrations<br />
BRMS 322, 380<br />
deactivate object codes 127<br />
Lawson Software 333<br />
WDSc 365<br />
tracking change 198–199<br />
trigger<br />
defined 467<br />
tutorial data, deleting 396<br />
types<br />
defined 198<br />
typographical conventions 4<br />
Index<br />
481
Index<br />
U<br />
Uniform Resource Locator, see URL<br />
Update <strong>MKS</strong> Integrity (IUPDCI) command 240<br />
upgrading <strong>Implementer</strong> 2<br />
IEDTLIBL command considerations 415<br />
URL<br />
for Domino Designer integration 340<br />
user authority<br />
Capability Wizard 385<br />
to environment 109–112<br />
User Capability Wizard, see Capability Wizard<br />
385<br />
user environment capabilities 80<br />
user exit program<br />
customizing <strong>Implementer</strong> 414<br />
IMCODF 415<br />
IMCOMO8 415<br />
IMCRDF 415<br />
IMPRMV3 415<br />
IMUPDLCK 415<br />
user profile<br />
enrolling in <strong>Implementer</strong> 72<br />
environment capabilities 80<br />
for communications 403<br />
function overview 72<br />
maintain customer setup 78<br />
maintain product versions setup 78<br />
maintain products setup 78<br />
<strong>MKS</strong> Integrity user 74<br />
MWIPROD user profile 429<br />
object code overrides 80<br />
one step checkout setup 77<br />
one step promotion setup 77<br />
override remove from src/obj 75<br />
QSECOFR user profile 117<br />
remove src/obj in from library 76<br />
user program and source<br />
remove during promotion 404<br />
utilities<br />
clear remote environment 384<br />
purge host environment history 374<br />
purge remote environment history 376<br />
repository maintenance 376<br />
System Control Maintenance 65<br />
V<br />
version<br />
AllFusion 2E, defined 468<br />
482<br />
version group<br />
AllFusion 2E, defined 468<br />
versioning<br />
build list to set object version 118<br />
initializing version numbers 146<br />
issue or DR object stamping<br />
feature overview 146<br />
setup 146, 147<br />
object stamping overview 146<br />
object version stamping setup 147<br />
versioning methods 147<br />
Visual LANSA, see LANSA integration<br />
W<br />
WDSc integration 365<br />
benefits and features 367<br />
integration overview 366<br />
requirements<br />
<strong>Implementer</strong> requirements 369<br />
WDSc requirements 368<br />
Web based development<br />
Apache Web Server for iSeries setup 158–<br />
159<br />
environment setup 156<br />
HTTP server setup 156–158<br />
accessing HTTP configuration 157<br />
adding security directives 157<br />
enabling method directives 157<br />
mapping location directives 157<br />
overview 156<br />
starting and stopping server 158<br />
WebSphere Development Studio Client for<br />
iSeries, see WDSc<br />
where to go next 203<br />
work library<br />
defined 468<br />
prefix 409<br />
Workbench<br />
defined 464<br />
WRKHTTPCFG, Work with HTTP<br />
Configuration command 157<br />
Y<br />
Y2SYCM library 406<br />
Y2SYCR library 413<br />
YSYSCHG model value 307