MKS Implementer 2006 Administration Guide
MKS Implementer 2006 Administration Guide
MKS Implementer 2006 Administration Guide
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
®<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