As400 Applications Moving To The 21st Century

SG24-4790-00
AS/400 Applications: Moving to the 21st Century January 1997
IBML
International Technical Support Organization AS/400 Applications: Moving to the 21st Century January 1997
SG24-4790-00
Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix F, Special Notices on page 233.
First Edition (January 1997)

This edition applies to OS/400 Version 3, Release 1, 5763-SS1, and later versions. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. JLU Building 107-2 3605 Highway 52N Rochester, Minnesota 55901-7829 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation 1997. All rights reserved. Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures Tables
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii ix xi xi xii xiv
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preface . . . . . . . . . . . . . . . . . How This Redbook Is Organized The Team That Wrote This Redbook . . . . . . . . Comments Welcome
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 1. Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 3
Chapter 1. Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 2. Application Restructuring
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 9 13 13 13 15 17
Chapter 2. Internal Application Modernization
. . . . . . . . . . . . . . . . . . .
Chapter 3. Interactive Language Environment (ILE) 3.1 What is ILE? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 How ILE Works Chapter 4. DB2/400 Triggers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 5. DB2/400 Referential Integrity (RI)
. . . . . . . . . . . . . . . . . . . .
Part 3. Year 2000 Enablement
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19 21 21 21 22 22 23 25 26 27 31 32 36 37 37 38 39 39 40
Chapter 6. Executive Summary . . . . . . . . . . . . . . . . . . . . . . 6.1 Does this Really Mean Me? . . . . . . . . . . . . . . . . . . . . . . 6.2 But I ve Been Told... . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 What s My Role and What Can I Expect? . . . . . . . . . . . . . . 6.4 What Are IBM and the Solution Developers Doing to Assist Me? 6.5 So, What s the Bottom Line? . . . . . . . . . . . . . . . . . . . . . Chapter 7. The Year 2000 - A Transition 7.1 Year 2000 Exposure Classification . 7.2 Scope of Year 2000 Transition . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 8. Planning to Resolve Your Year 2000 Exposures . . . . . . . . . . . . . . . . . 8.1 Planning Considerations . . . . . . . . . . . . 8.2 Inventory Your Software Portfolio
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 9. Identifying Two-Digit Year Exposures . . . . . . 9.1 Locating References . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1 Tracing References Back to Their Source 9.2 Determining the Impact of Two-Digit Year Data Fields . 9.3 Investigating How Other Software Entities Use the Data 9.3.1 Data Sharing . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Copyright IBM Corp. 1997
iii
Chapter 10. Reformatting Year-Date Notation . . . . . . . . . . . . . . . 10.1 Solutions and Techniques . . . . . . . . . . . . . . . . . . . . . . . . 10.1.1 Solution #1: Conversion to Four-Digit Year Format Using SAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data-Type Date . . . 10.1.2 Solution #2: Conversion to Full Four-Digit Year Format . . . . . . . . . . . . . . 10.1.3 Solution #3: One-Digit Century Code . . . . . . . . . . . . . . . . . . . . . . . 10.1.4 External Century Code 10.1.5 Embedded Century Code . . . . . . . . . . . . . . . . . . . . . . 10.1.6 Solution #4: Windowing Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Using a Common Date/Time Service Routine . . . . . . . . . . . . . . 10.3 Considerations When Selecting Solutions . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 Solution Applicability 10.3.2 Bridge Programs Help Stage Format Conversions . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.3 Other Programming Situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Guidelines Chapter 11. Testing Techniques for Year 2000 Changes . . . . . . . . . . . . 11.1 Structural Testing Techniques . . . . . . . . . . . . . . . . 11.1.1 Operations Testing . . . . . . . . . . . . . . . . . . . 11.1.2 Stress Testing . . . . . . . . . . . . . . . . . 11.1.3 Recovery Testing . . . . . . . . . . . . 11.2 Functional Testing Techniques 11.2.1 Requirements Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2 Regression Testing . . . . . . . . . . . . . . 11.2.3 Error Handling Testing . . . . . . . . . . . . . 11.2.4 Manual Support Testing . . . . . . . . . . . . . . . . 11.2.5 Intersystem Testing 11.2.6 Parallel Testing . . . . . . . . . . . . . . . . . . . 11.3 How to Change Date and Time for Testing . . . . . 11.4 Basic Testing Scenarios . . . . . . . . . . . . . . . . 11.4.1 Basic Scenarios to Test Your PC System Clock
. . . . . . . .
41 41 41 42 44 44 45 46 49 49 50 50 51 52 55 55 55 55 56 56 56 56 57 57 57 57 58 58 59 61 61 63
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 12. Migration Consideration for Year 2000 Transition 12.1 Plan for Migration . . . . . . . . . . . . . . . . . . . . . . . 12.2 Perform Migration . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 13. Tool Categories and Available System Features to Ease Year 2000 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.1 Tool Characteristics 13.2 Tool Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2.1 Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 13.2.2 Project Management . . . . . . . . . . . . . . . . . . . . . . . 13.2.3 Program Level Analysis 13.2.4 Code Editing and Restructuring . . . . . . . . . . . . . . . . . . . 13.2.5 Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2.6 Automate Testing 13.3 IBM System Features for AS/400 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.1 The IBM RPG Family 13.3.2 Using OPM RPG/400 Date Support . . . . . . . . . . . . . . . . . 13.3.3 Using System/36 Compatible Date Support . . . . . . . . . . . . 13.3.4 The IBM COBOL Family for AS/400 System . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.5 The IBM C Family for AS/400 System . . . . . . . . . . 13.3.6 Integrated Language Environment for OS/400 13.3.7 DB2/400 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.8 OS/400 CL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65 65 66 66 67 67 68 69 69 70 70 77 77 78 78 79 79 85
iv
AS/400 Applications: Moving to the 21st Century
13.3.9 Application Dictionary Services/400 . 13.3.10 Application Development Manager/400
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90 90
Part 4. External Application Modernization
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
93 95 95 96 99 99 100 100 101 101 101 101 102 102 103 103 104 109 112
Chapter 14. GUI/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1 What Are The Benefits of This Approach? 14.2 Building a GUI Client for an Existing AS/400 Application
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 15. Using VRPG Client/2 to Create Modern Applications 15.1 VRPG as a Tool for Modernization . . . . . . . . . . . . . . . 15.2 Familiarization with VRPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3 Documentation for VRPG 15.4 Converting Legacy RPG Code to VRPG . . . . . . . . . . . . 15.4.1 Advantages in Converting RPG Applications to VRPG 15.4.2 Disadvantages in Converting RPG applications to VRPG 15.4.3 Other Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.5 Event-Driven Programming . . . . . . . . . 15.6 Summary of Steps for Conversion to VRPG 15.7 Conversion to VRPG in Detail . . . . . . . . . . . . . . . . . . 15.7.1 Converting To RPG IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.7.2 Converting Display Formats . . . . . . . . . . . . 15.7.3 Converting RPG IV Code to VRPG . . . . . . . . . . . . . . . . . . . . . 15.8 Beyond the Conversion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 5. Modernizing Your Development Environment
. . . . . . . . . . . . . . . . . . . . .
113 115 119 120 122 122 123 126 128 131 133 134 139 141 142 143 143 144 145
Chapter 16. Application Dictionary Services (ADS/400)
. . . . . . . . . . . . .
Chapter 17. Application Development Manager (ADM/400) . . . . 17.1 ADM/400 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 17.1.1 Who Uses Application Development Manager/400? . . . 17.2 The Order Entry Application and ADM/400 . . . . . . . . . . . . . . . . . . . . . . . . 17.2.1 The Order Entry Project Hierarchy 17.2.2 Importing the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2.3 Building the Application 17.2.4 Run and Test the Order Entry Application . . . . . . . . . 17.3 Develop the Follow-On Version of the Order Entry Application 17.3.1 Create Version 2 Hierarchy for the Order Entry Project . 17.3.2 Move Version 1 Hierarchy Under Version 2 . . . . . . . . 17.3.3 Change the Promote Code . . . . . . . . . . . . . . . . . . 17.4 Application Development Manager/400 Summary . . . . . . . Chapter 18. COoperative Development Environment/400 18.1 Why Use CODE/400 for Development? . . . . . . . 18.2 The Functions of CODE/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3 How CODE/400 Works
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 6. Appendices
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
151 153 153
Appendix A. Two Possible Scenarios for Year 2000 Conversion A.1 Considerations for Conversion Without a Year 2000 Tool .
. . . . . . . . . . . . . . .
Contents
A.2 Considerations for Using Year 2000 Conversion Tools Appendix B. ADS/400 Date Scan Program Appendix C. RPG/400 Order Entry Program Appendix D. RPG IV Order Entry Program Appendix E. VRPG Order Entry Program Appendix F. Special Notices
. . . . . . . . . .
158 165 169 187 209 233 235 235 235 235 237 237 238 239 241 243
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix G. Related Publications . . . . . . . . . . . . . . . . G.1 International Technical Support Organization Publications G.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . G.3 Other Publications . . . . . . . . . . . . . . . . . . . . . . . How to Get ITSO Redbooks . . . . . . . . . . How IBM Employees Can Get ITSO Redbooks How Customers Can Get ITSO Redbooks . . . . . . . . . . . . . IBM Redbook Order Form List of Abbreviations Index
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
Figures
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. Roadmap to 21st Century . . . . . . . . . . . . . . . . . . . . . . . . . . Modularization Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . Present Database Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Improved Program Design Improved Database Design . . . . . . . . . . . . . . . . . . . . . . . . . A Corporate Networked Computing Environment . . . . . . . . . . . . . . . . . Graphical Representation of the Sliding Window Technique GUI/400 Sample Window . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing Display Files - Starting Point . . . . . . . . . . . . . . . . . . Importing Display Files - Selecting the Source Member . . . . . . . . Importing Display Files - Selecting the Record Format . . . . . . . . . Parts Palette Showing the Imported Display Files . . . . . . . . . . . . An Imported Display Before Customizing . . . . . . . . . . . . . . . . . An Imported Display After Customizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADS/400 Customized Year 2000 Impact Analysis ADS/400 Object Impact Analysis . . . . . . . . . . . . . . . . . . . . . . ADS/400 Related Files with Date Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Year 2000 Conversion Effort Distribution The Hierarchy of the Base Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Work with Groups Using PDM Display Adding PROGRAMMER1 and PROGRAMMER2 to Order Entry Project IMPPART Command to Import Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rebuilding the Complete Application . . . . . . . . . . . . . . . . . . . . . QPLYBLDP Output After Building . . . . . . . . . . . . . . . . . . . . Add Project Library List Command Run the Order Entry Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Order Entry Application Display Project Hierarchy for a Follow-On Version of Order Entry Application . . . . . . . . . . . . . . . . . . . . . . . Creating the COMMON Group . . . . . . . Copying the Non-Program Parts to the COMMON Group Creating the PRODUCTION_V2 Group . . . . . . . . . . . . . . . . . . . Copying the Program Source Parts to the PRODUCTION_V2 Group . . . . . . . . . . . . . . Deleting Parts Copied to the COMMON Group . . Adding PRODUCTION_V2 Group under PRODUCTION_V1 Group Moving the Version 1 Hierarchy under the PRODUCTION_V2 Group . . . . . Moving the TEST Group under the PRODUCTION_V2 Group Displaying the Promote Code for Each Group . . . . . . . . . . . . . . LPEX - RPG Source Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LPEX - Calculation Prompt . . . . . . . . . . . . . . . Debug - Execute/Step from Debug Window . . . . . . . . . . . . . . . . . . . . . . . . . DSU - Physical File Update DSU - Display File Records . . . . . . . . . . . . . . . . . . . . . . . . . DSU - Display File Work Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DSU - Change Field Edit Attributes ADS/400 - Set Criteria for Date Related Field Selection . . . . . . . . ADS/400 Sample Display - Compile Related Logical Files . . . . . . . ADS/400 - Find Programs in Relation of Modified Field of a File . . . . . ADS/400 - Find Display File in Relation to the Modified Program
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
5 10 . 11 . 14 . 15 . 28 . 48 . 97 104 105 106 107 108 109 116 117 117 120 124 125 126 127 128 130 131 132 132 134 135 135 136 137 138 139 140 140 141 146 146 147 147 148 148 149 154 155 156 158
vii
viii
Tables
1. 2. 3. 4. 5. 6. 7. 8. 9. Date Formats for Date Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Date Values Time Formats for Time Data Type . . . . . . . . . . . . . . . . . . . Time Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DDS Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RPG Keywords CL Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DDS Keywords Year 2000 Impact Analysis/Conversion Tool System Requirements
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
72 72 . 73 . 74 154 156 157 158 159
ix
Preface
This redbook contains detailed coverage of how existing old, unstructured applications can be modernized to take them into the 21st century. Utilizing a set of modern application development tools, legacy applications do not only have a new look and feel for the end-users benefit, but can also be restructured to take advantage of the latest 3GL programming tools and techniques to make the programmers lives easier and more productive. In addition, enabling the applications to survive the year 2000 and beyond is a step all application developers must take. Some knowledge of the AS/400 system, application design, and programming is assumed. cms
How This Redbook Is Organized

The redbook is organized as follows:
Part 1, Introduction This part provides an introduction to the application development issues you are facing going to the next century. It gives you an overview of how one can be more productive and how to modernize existing applications. It includes: Chapter 1, Introduction
Part 2, Application Restructuring This part describes how you can use DB2/400 and the new facilities of ILE (the Integrated Language Environment) to better modularize and structure your application code. It includes: Chapter Chapter Chapter Chapter 2, 3, 4, 5, Internal Application Modernization Interactive Language Environment (ILE) DB2/400 Triggers DB2/400 Referential Integrity (RI)
Part 3, Year 2000 Enablement This part is also part of the internal modernization step of the roadmap. Since Year 2000 enablement is so important to all applications, any application must be prepared to meet this challenge as part of their modernization efforts. It includes: Chapter 6, Executive Summary Chapter 7, The Year 2000 - A Transition Chapter 8, Planning to Resolve Your Year 2000 Exposures Chapter 9, Identifying Two-Digit Year Exposures Chapter 10, Reformatting Year-Date Notation Chapter 11, Testing Techniques for Year 2000 Changes Chapter 12, Migration Consideration for Year 2000 Transition Chapter 13, Tool Categories and Available System Features to Ease Year 2000 Changes
Part 4, External Application Modernization This part looks at the possibilities of modernizing your applications externally (that is, changing the look and feel of the user interface). Two alternatives to modernizing your applications are provided, use of a
xi
Graphical User Interface (GUI) and use of the products available to move existing RPG applications to a client/server environment. It includes:
Chapter 14, GUI/400 Chapter 15, Using VRPG Client/2 to Create Modern Applications
Part 5, Modernizing Your Development Environment This part describes the IBM AS/400 Application Development tools which can help in the systematic design, development, and maintenance of applications. It includes: Chapter 16, Application Dictionary Services (ADS/400) Chapter 17, Application Development Manager (ADM/400) Chapter 18, COoperative Development Environment/400
Part 6, Appendices This section provides additional information such as scenarios for converting to the Year 2000 and program listings from a demo program illustrating some of the application modernization functions. It includes: Appendix Appendix Appendix Appendix Appendix A, B, C, D, E, Two Possible Scenarios for Year 2000 Conversion ADS/400 Date Scan Program RPG/400 Order Entry Program RPG IV Order Entry Program VRPG Order Entry Program
The Team That Wrote This Redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization Rochester Center. Jan Arbouw, IBM Netherlands, is an AS/400 Systems Specialist at the AS/400 Marketing and Support Organization in the Netherlands. His areas of expertise include technical support on AS/400 client/server development, especially VRPG Client/2 and CODE/400. He has 27 years of experience within IBM, including development of IBM business applications and supporting IBM AS/400 customers. Nick Screnci, IBM Australia, is an AS/400 Systems Specialist in Australia. He has 16 years of experience in the computer industry, including 10 years experience in developing application systems. He teaches IBM classes in the Asia Pacific area on VRPG Client/2. He holds a Bachelors degree in Business from the University of Technology in Sydney and a Diploma in Accountancy from the New South Wales Institute of Technical and Further Education. His areas of expertise include VRPG Client/2, performance analysis, and capacity planning for the AS/400 system, application development, marketing, and accounting. Bob Presser, MillenniApp Solutions, is an AS/400 Consultant in the U.S. He has 26 years of experience in the computer field, all in the IBM mid-range arena. He has a Bachelor of Science degree in Mechanical Engineering from Drexel University in Philadelphia. His areas of expertise include extensive application development, technical support, security, and communications. He is the librarian for COMMON U.S. and has made several technical presentations at COMMON and other user groups.
xii
Claudio Retico, IBM Italy, is an AS/400 development specialist in Italy. His areas of expertise include database design, RPG prgramming, PC programming, and integrating the AS/400 system with PC LAN networks. Midori Tasaka, IBM Japan, is an Information Technology Specialist at the Retail and Distribution marketing office in Japan. She has 10 years of experience in the field of IBM S/38 and the AS/400 system. She holds a Bachelor of Liberal Arts degree from International Christian University in Tokyo. Her areas of expertise include IBM midrange systems technical support, performance management, and retail applications. Neil Willis, IBM Rochester, is a Senior ITSO Specialist at IBM Rochester. He has 11 years of experience in performance, capacity planning and application development. He has presented at COMMON and to other AS/400 special interest groups. Prior to joining the ITSO, he was an Advisory Systems Specialist and AS/400 team leader in Sydney, Australia. George M. Yeung, IBM Canada, is a manager in SWS Product Services, Toronto Lab. His current responsibilities are in AS/400 application development services enablement. Fernando Zuliani, IBM Rochester, is an AS/400 certified I/T specialist in the ITSO Rochester. He has 9 years of experience in the I/T field. He has worked at IBM for 8 years. His areas of expertise include OS/400, client/server, VisualAge generator, application development, and performance. Susan M. Gantner, IBM Canada, is a technical advocate for AS/400 application development products and is located in the IBM Lab in Toronto. Susan specializes in application development and database on the AS/400 system and is a regular speaker at COMMON and Technical Conferences for AS/400 customers around the world. Susan has spent 21 years in the field of application deevlopment. Prior to joining IBM, she developed applications for corporations in Atlanta, GA, working with a variety of hardware and software platforms. She joined IBM as a Systems Engineering Specialist for the S/38. She spent 5 years working in Rochester, Minnesota, supporting customers and IBMers around the world with database and programming challenges. Thanks to the following people for their invaluable contributions to this project: T.M.J. (Ted) Zonderland Technical Competence Manager, AS/400, IBM Netherlands Jon Paris Technical Advocate, AS/400 Application Development Products, Toronto Lab Aki Fukai IBM Software Services Planning, Availability Services, Rochester E.B.( Brian) Sawyer IBM Midrange Technology Manager, Oak Brook, Ill. Bruce Vining Base System Enablers, IBM Rochester Gabriella (Babi) Erler AS/400 Division, IBM Somers, NY
Preface
xiii
Comments Welcome
We want our redbooks to be as helpful as possible. Should you have any comments about this or other redbooks, please send us a note at the following address: redbook@vnet.ibm.com Your comments are important to us!
xiv
Part 1. Introduction
This part describes the issues we face going into the next century. It provides an overview of how to be more productive and how to modernize existing applications.
Many AS/400 customers have applications that were designed and developed many years ago by in-house staff or other organizations. Some of these applications probably use conventional green-screens . Many of the application programs may be large and unstructured. Few have good documentation, if any at all. Many installations have unstructured programming environments as well, which make the ever-present maintenance backlog more difficult to deal with. Most of these applications use dates that are not century-enabled (that is, they do not have a one or two-digit century field and contain no logic to handle the transition from 19xx to 20xx. The purpose of this Redbook is to make the AS/400 technical community more aware of the techniques and tools available to modernize their applications, fix their date bugs, and move their user interfaces toward the more desirable GUI look that end-users are more comfortable with. The Year 2000 date problem we all face presents us with the perfect opportunity for action to modernize our applications now, as we all know we should. In this book, we lay out a road map consisting of several steps in modernizing various aspects of your applications. The application road map consists of the following steps. Note that it is not always necessary to take each step on the road map and it is also not necessary to follow the road map to the end. Some applications, for example, do not require graphical user interfaces. By using these steps and the tools and techniques outlined here, you can accomplish a clearly planned application modernization strategy. The road map strives to accomplish modernization in three major areas:
External application modernization: Provide a more modern user interface for the end users of the application. This can be as simple as providing a graphical interface to existing application code or could go to the extent of providing true client/server environment for the users.
Internal application modernization: To make the application viable for years to come, it should be modernized internally (well structured, modular, and taking full advantage of the system and language techniques available in the latest releases). Taking the time and effort to do this pays off easily for applications that continue to be in use for years to come. Making these changes makes the application more reliable and easier to maintain and improve over time.
Modernization of your development environment: Doing either of the preceding steps is extremely difficult without the help of the appropriate tools. Tools such as impact analysis tools, change management and version control tools, and workstation-based programmer workbench tools not only make the programmers lives a bit easier, but can also greatly improve their productivity and allow them to get more work done in less time.
By combining all three types of modernization you can see dramatic enhancements in the ability of the applications to serve the business and in the satisfaction of not only the end users, but also the programmers. Our road map includes the following major steps:
Internal application modernization: Modularize and structure code for productivity and client/server preparation. Enable applications for the year 2000 and beyond.
External application modernization: Provide a simple graphical interface. Move applications to true client/server.
Modernization of the development environment: Enhance productivity with updated development tools.
The following chapters describe in detail how to implement structured code using the new Integrated Language Environment (ILE) languages, how to identify and fix date bugs, how to modernize your development environment to enhance programmer productivity, and how to give applications a GUI look and feel. Throughout the text, we mention what specific tools are available to make these changes with the most control and with the least effort. These chapters are organized in such a way as to allow you to implement or omit any one without affecting the overall result. That is, you can choose to modularize your applications or not, you can convert dates (if necessary or not) if your applications are already century safe, or you can choose whether to implement GUI interfaces or not. The choice is yours, but we recommend taking some action now. The purpose of this book is to illustrate a clear road map of how to take those existing old, unstructured applications into the 21st century. Utilizing a set of modern application development tools, your legacy applications do not only have a new look and feel for the end users benefit, but can also be restructured to take advantage of the latest of 3GL programming tools and techniques to make the programmers lives easier and more productive. And, of course, enabling the applications to survive the year 2000 and beyond is a step all application developers must take. As we said before, it is not strictly necessary that each step be followed or that all steps be done in all shops. But to paint a more complete picture of the possibilities, we describe ways to accomplish all of the steps and, where applicable, how to use the tools from IBM and other vendors to help smooth the road.
Figure 1. Roadmap to 21st Century
Part 2. Application Restructuring

This part describes the first step of modernization, internally modernizing applications. It contains a discussion on how DB2/400 and the new facilities of the Integrated Language Environment (ILE) might be used to better modularize and structure application code. It includes:

Chapter Chapter Chapter Chapter
2, 3, 4, 5,
Internal Application Modernization Interactive Language Environment (ILE) DB2/400 Triggers DB2/400 Referential Integrity (RI)

Older applications are often written in large pieces. Today, the industry generally agrees that utilizing a more modular structure in our code designs can greatly improve the productivity of developers and the reliability of the code. Many AS/400 developers, however, have learned over the years that program calls can be expensive and, therefore, often avoid using a modular design in the interest of providing better application performance. The newer Integrated Language Environment (ILE) compilers, however, can allow a more modular coding style with much less call overhead than before. This is because the ILE compilers allow programmers to develop, write and compile code in relatively small pieces and bind the code together into program objects. When this is done, the call time between the pieces is much faster. The resulting application can have performance attributes close to a large program while allowing the productivity benefits of writing and compiling code in smaller parts. Code reuse is much more likely in this kind of environment and performance tuning of the reusable parts can often actually improve the application s overall performance. Furthermore, DB2/400 has some new features that can help in the restructuring of applications. Database triggers can be used for code that should always be executed when a particular database record is updated, deleted or added. Using triggers for these common functions makes it easier to ensure that the functions always occur and allows the programmers to remove that code from their application programs. Referential Integrity can also reduce certain types of repetitive code in applications. The following list is a guide to take advantage of these new offerings: 1. Modularize your application. Avoid repeating the same code in different portions of a large program or in different programs (use subroutines or ILE bound procedures wherever possible). 2. Group similar functions. 3. Move database control to the database level (use triggers and referential integrity). The following figure shows the modularization technique:
Figure 2. Modularization Strategy
In Figure 2, repeatable portions of code are structured as procedures in ILE service programs (Functions I, II, and III). This greatly facilitates program maintenance as these functions are captured in one location. DB2/400 also offers many features and functions to simplify program construction and the modernization of an application. Specifically, we are referring to the use of Referential Integrity and Triggers. The concept is simply to move the data controls and usage rules from the programs directly to the database design. This eliminates the need for repetitive code within the application every time the data is used. With this technique, the same actions can be enforced and data integrity can be ensured every time the data is invoked. An added benefit is in eliminating the risk of the routines for the data rules and controls being forgotten. A further advantage is that fewer lines of code need to be generated to deliver the same functions. For more examples on DB2/400 programming, please refer to the redbook, DATABASE 2/400 Advanced Database Functions , GG24-4249. The many features and functions of the ILE environment offer significant benefits in the modernization of an application. Converting your application to the ILE environment is highly recommended. Please refer to AS/400 ILE Application Development Example , SC41-3602, for more details on the conversion process. To illustrate some of these techniques, we use a portion of a simple order entry application. The basic design is:
10
Figure 3. Present Database Structure
In this exercise, the large order entry program was modularized into smaller code modules that are bound either within the program object or, for the reusable parts of the application, bound into a service program. We put some of the database logic into a trigger program and also into referential integrity constraints. Figure 4 on page 14 illustrates the design improvements in our simple application where we implemented ILE and incorporated functions such as dynamic link with a service program, Referential Integrity, and Triggers.
11
12
Chapter 3. Interactive Language Environment (ILE)

This chapter gives a short introduction to ILE and at a high level describes how to take advantage of the new features of ILE to improve your program design.
3.1 What is ILE?

The Integrated Language Environment (ILE) model significantly enhances application development environments on the AS/400 system. ILE gives power to the programmer by providing the foundation for future application growth through improved application performance and quality, and improved programmer productivity. The ILE family of compilers provides greater flexibility in choosing the language (or languages) best suited for your applications. C, RPG, COBOL, and CL code can be bound into a single program, regardless of the mix of source languages. Supporting and enhancing the use of modular code allows smaller, more maintainable modules. The ILE model provides a significant evolutionary enhancement to application development on the AS/400 system. The ILE model addresses your key requirements for improved application performance, improved programmer productivity, and improved application quality. Enhancements to support the new Integrated Language Environment provided through OS/400 Version 3 Release 1 include:

Static binding New integrated run-time environment Enhanced inter-language communication support Bindable system APIs Source view debugger Greater flexibility in controlling run-time environments
The addition of static binding to the AS/400 system has significantly reduced the system overhead and increased the performance of calls on the system. This change allows programmers to create more modular programs that greatly increase program design flexibility, are easier to understand, are reusable, and are smaller. With smaller program modules, compiles take less time since only the changed module needs to be recompiled and then rebound to make the application. This module replacement simplifies the support and maintenance processes for large applications. However, existing non-ILE programs continue to run on the AS/400 system and can be used with ILE programs. ILE and non-ILE programs can call each other.
3.2 How ILE Works

Using ILE, the application redesign is shown in Figure 4 on page 14.
13
Figure 4. Improved Program Design
The steps taken to enable the redesign are:
Convert the source programs from RPG III format to RPG IV with the CVTRPGSRC command. Break up the application code into logical units that can be compiled separately and called from the mainline. Use static binding by calling between the modules with CALLB. Identify all common code routines that are reusable in other programs to include as modules in a service program. Use the CRTxxxMOD function to compile each of the modules. Create one or more service programs using the CRTSRVPGM command. Create the ILE program with the CRTPGM command specifying the modules unique to this program to be bound by copy and specifying the service program name (or names) for the reusable modules.
For additional information on conversion from the OPM environment to ILE, refer to AS/400 ILE Application Development Examples , SC41-3602.
14
Chapter 4. DB2/400 Triggers

With the use of Triggers, we can pass control or conditions from the application to the data. This facilitates two key functions:
The control functions and operations are not carried out by multiple versions of the code. This eliminates potential errors caused by improper placement of these routines. Once the control functions are established in the data, they work even if the programmer forgets to include equivalent subroutines.
Figure 5 shows the use of trigger and Referential Integrity in the database redesign of the sample application.
Figure 5. Improved Database Design
The following code shows the programming improvements using the trigger technique instead of the traditional method of coding. It shows the common way of coding to check for, in our example, order header consistency and its relationship (integrity) with the order detail.
15
C MOVE OKAUD 1 C* VERIFY SALES RAPR. AUTHORITY TO INSERT ORDER WITH PRESENT C* CUSTOMER. IF ALL OK UPDATE ORDER AND END TRANSACTION ELSE C* ROLBACK TRANSCTION AND DELETE ORDER HEADER C CALL RADT C PARM SRNBR C PARM CUSNBR C PARM OKAUD C OKAUD IFEQ 0 C UPDATORDERHDR 81 C 81 SETON 7701 C ELSE C *LOVAL SETLLORDH01L 80 C ROLBK C CALL CORD C PARM ORHNBR C SETON 77 C ENDIF
The external program, RADT, is called each time the order header file needs to be updated. The RADT program checks on whether the sales representative has the authority to process the order for specific customers assigned to this representative. If the representative is authorized, the program accepts the transaction and updates the order. Otherwise, the program negates the transaction and deletes the order. A trigger can be set up with the following command:
ADDPFTRG FILE(A960121/ORDERHDR) TRGTIME(*BEFORE) TRGEVENT(*UPDATE) PGM(RADT)

This command generates a function equivalent to the RADT program before each update operation on the file. This database feature enables us to modify the code to: C C UPDATE SETON ORDERHDR 7701 81
81
As shown, the coding is simplified. The control function is passed to the data and is executed each time the data is accessed.
16
Chapter 5. DB2/400 Referential Integrity (RI)

Referential Integrity is another advanced function that allows rules to be defined at the database level. The concept is that these rules are implicitly executed each time the data is accessed. This relieves the need to develop equivalent code to handle the same rules within the program. The rule that Referential Integrity enforces is to ensure that files that are dependent on other files always have corresponding records. In this case, we want to ensure that there is never an order header record added to the database unless there is a corresponding customer master record present. Likewise, a customer master record cannot be deleted if there are corresponding order header records present. We want similar rules to govern the relationships between the Order Header and Order Detail files and between the Order Detail and Product Item files. We want to define the following rules in our sample application: 1. Order details (ORDERDTL) cannot exist without an order header (ORDERHDR). 2. An order detail (ORDERDTL) cannot be created if a product number (PRDNBR) does not exist. 3. An order header (ORDERHDR) cannot be created if a customer number (CUSTOMER) does not exist. 4. A sales representative number cannot be processed without a valid and authorized customer. To code all of these rules in the traditional approach is difficult. With Referential Integrity, the operation is simple. The constraints (rules) are set up on the physical file with the ADDPFCST command. With the rules set up in the database, the amount of code needed to address the controls is dramatically reduced. Before using Referential Integrity, the program looks similar to this:
17
C* C C* C* C C* C C C C C C C C C C C* C C C
CHECK DUPLICATE KEY DTLK SETLLORDD01L 80 We made a previous check to verify consistency of order header so *in99=*off -> NO ERROR IN HEADER *IN99 IFEQ *OFF ERROR WRITING FOR DUPLICATE PRODUCT *IN80 IFEQ *ON SETON 64 EXSR SUBTR ELSE WRITEORDERDTL ADD 1 REC1 WRITESFL01R SETON 22 ENDIF ELSE ORDER HEADER LOST ERROR SETON 69 EXSR SUBTR ENDIF
With the constraints (rules) defined, the database controls the integrity (relationship between the order header and order detail). The preceding program is greatly simplified to look similar to this:
C C* R.I.Error C *IN80 C C C C C C C
WRITE IFEQ SETON EXSR ELSE ADD WRITE SETON ENDIF
ORDERDTL *ON
80
64 SUBTR 1 SFL01R REC1 22
18
Part 3. Year 2000 Enablement

The following several chapters deal with the issue of Year 2000 enablement. They define the problem, identify your exposures, help you plan for resolution, and give you methods for successfully accomplishing program and data conversion. Most of the content for these chapters was taken from the generally available IBM document entitled, The Year 2000 and 2-Digit Dates: A Guide for Planning and Implementation , GC28-1251. Since this Redbook is primarily for AS/400 customers, the content has been modified or enhanced to deal with AS/400 issues and interests. Sections that are applicable to all systems, but not specifically to the AS/400 system, have been left intact although some contain more detail than a typical AS/400 shop may require. Other sections have been removed entirely, since they deal specifically with mainframe related topics. This part includes:

Chapter 6, Executive Summary Chapter 7, The Year 2000 - A Transition Chapter 8, Planning to Resolve Your Year 2000 Exposures Chapter 9, Identifying Two-Digit Year Exposures Chapter 10, Reformatting Year-Date Notation Chapter 11, Testing Techniques for Year 2000 Changes Chapter 12, Migration Consideration for Year 2000 Transition Chapter 13, Tool Categories and Available System Features to Ease Year 2000 Changes
19
20
Chapter 6. Executive Summary

A phenomenon exists in the Information Technology (IT) industry because, historically, many computer programs make use of dates represented by only two digits (for example, 95 rather than 1995). However common this practice might be, it causes programs (both system and application) that perform arithmetic operations, comparisons, or sorting of date fields to yield incorrect results when working with years outside the range of 1900 through 1999. IBM refers to this phenomenon as the Year 2000 Challenge .
6.1 Does this Really Mean Me?

The scope of the Year 2000 challenge spans the entire IT industry. A data mismatch can exist in any level of hardware or software from microcode to application programs, in files and databases, and is present on all platforms (IBM and non-IBM). In recent years, the IT trade press has given ever greater attention to this phenomenon with increasingly ominous article titles. However dramatic all of this may sound, consider the following scenarios to help put the phenomenon and its business ramifications into perspective. Imagine that if in the first quarter of the year 2000, your company cannot process its 1999 end-of-year billing or end-of-year payroll properly; your corporate credit card holders are refused most transactions because their accounts appear delinquent; your 1999 year-end profit data cannot be calculated properly; and your utility companies cut off their services due to your apparent late bill payments. Similarly, your household and personal financial situation can encounter a similar dilemma if your creditors do not also strive to meet this challenge. Although referred to as the Year 2000 challenge and often as the Year 2000 Problem , this is really a two-digit year problem. Your Information Systems (IS) organization needs to plan for and address the date changes well in advance of January 1, 2000. This is not only a future challenge; it has existed in the banking industry since as early as 1970 when application programs encountered problems with amortization and interest table calculations for the standard 30-year mortgage. Consider also, the standard 5-year automobile loan, a 15-year mortgage, a long-term insurance policy, a database that retains birth dates (which includes an ever increasing set of dates over 100 years). Even before January 1, 2000, your computing environment might not function as expected because your systems and application programs cannot process dates later than December 31, 1999, properly.
6.2 But I ve Been Told...

There are many misconceptions associated with the cause of the Year 2000 challenge. These include:
This is a problem that occurs only after 1999: As previously noted, expect to experience problems well in advance of the year 2000. Application programs manipulating such data probably produce incorrect results today.
This is a hardware problem rather than a problem for your IS organization:
21
To the contrary, this problem comes mostly from application programs and data using two digits for year representations. These programs have been purchased from solution developers, written in-house by your system and application programmers, leased from various software vendors, or shared among the IS community. Frugality was the rule when such programs were first written and every byte of saved storage was important. Human nature seems to dictate that writing and the keyboard entry of two digits is more practical than four digits. Saving even a small amount of space in a database was more important in the 1960 s and 1970 s than it is today, and most programmers never expected such code to still be in use 20 or 30 years later. This short-sighted programming practice has only recently surfaced as a problem, and only a rare program provided for four digits for the Year 2000.
This is a problem that only occurs on mainframe systems and legacy applications: Any system or program (large or small) can be affected if it uses two digits for year representation. In fact, such problems have been encountered in recently developed desktop software as well.
6.3 What s My Role and What Can I Expect?

For many institutions, you can expect the initial size of this Year 2000 work effort to appear overwhelming and the overall project to appear enormous, as it should. This is not a trivial project. Expect the need for your sponsorship to dedicate personnel, dedicate computer resources, approve the requisition of potential Year 2000 tools and service support, and a budget to fund it all. The solutions provided here are not particularly difficult to implement, and the technical solutions are not complex when viewed on a program-by-program basis. It is the overall project size and the program and data inter-relationships that introduces the true project complexity. Expect the need to appoint a cross department and cross-divisional focal point to manage it all.
6.4 What Are IBM and the Solution Developers Doing to Assist Me?
The project is manageable within the available time-frame and support is currently available from both IBM and many solution developers. IBM is committed to address the Year 2000 challenge within its own product offerings, to deliver Year 2000-ready software, and to assist you in your efforts. The IBM document, ( The Year 2000 and 2-Digit Dates: A Guide for Planning and Implementation ) for which this summary is provided, is the result of an IBM multi-divisional effort to articulate the overall IBM support with respect to the impending Year 2000 transition. It is intended to provide the IS community with planning, methodology, and guidance information needed to convert their application systems to correctly manipulate dates outside the range of 1900 through 1999.
The Year 2000 and 2-Digit Dates: A Guide for Planning and Implementation is available through your IBM representative or in softcopy form through the Internet. This document provides your IS personnel both generic and IBM-specific information on:
How to plan a Year 2000 transition.
22
How to detect and remove Year 2000 exposures. How to test and migrate to a revised Year 2000-ready system. Where to find further information (an extensive bibliography lists many of the most prominent publications and trade press articles concerning the Year 2000 challenge).
This document also provides information that addresses:
Multiple platform solutions (including IBM product-specific information) for: All IBM and non-IBM IS platforms All IBM operating systems IBM programming languages
Current IS tools (from IBM and non-IBM software vendors): Tools are available today to help your IS personnel identify potential exposures in your applications, assist their efforts in the categorization of potential exposures, and assist the testing and transition to a Year 2000-ready application environment.
Consulting services: IBM consulting service offerings provide skills and expertise for the understanding and the solution of your applications Year 2000 transition.
Although this guide is designed mainly to provide in-depth information to your IS technical staff (that is, your applications and systems programmers), the support that it demands must come from you. This is not a small undertaking for your IS staff within any aspect of your IS environment. If your business relies on computer processing, and that processing includes date manipulation, your business may be at risk. This paper provides direction for your organization to begin a pro-active response to this challenge.
6.5 So, What s the Bottom Line?

Your immediate attention to this effort and a directive to your IS organization to plan for and solve your Year 2000 challenge is critical. When you face your stockholders who ask, Now that you spent xxx dollars on this project, what do we have now that we did not have in 1995? , simply respond: We still have a viable business, one that accepts billing, correctly computes interest and invoices, and calculates our stock dividends. Not all of our competition can make that same claim!
Chapter 6. Executive S u m m a r y
23
24
Chapter 7. The Year 2000 - A Transition

Although January 1, 2000 is still approximately three years away, you need to plan for and address the 1999 to 2000 date change well in advance of that date. Even before we reach January 1, 2000, your computing environment might not work as expected because your systems and application programs do not process dates later than December 31, 1999, properly. However dramatic the following sounds, consider these scenarios to help put the problem into perspective. Imagine that all stock exchanges close down indefinitely because of invalid transactions; credit card companies refuse most transactions because cardholders appear delinquent on their payments; mortgage companies are besieged by angry borrowers who have just received delinquency notices in error and been charged extra interest; and utility companies cut off service to many customers due to apparent late bill payments. The potential exposure mostly comes from, but is not limited to, the use of a two-digit year (YY) format, instead of a four-digit (YYYY) format for year representation within programs, files, databases, and processes. For example, the year 1996 is represented as 96, the year 1999 as 99, and so on. Thus, January 1, 2000, is represented as 01/01/00 (if using MMDDYY format in your data) and might be interpreted as January 1, 1900. This causes programs that perform arithmetic operations, comparisons, or sorting of date fields to yield incorrect results when manipulating year-date data of 2000 and beyond. The potential exposures that may be encountered, and their variations (listed in Section 7.1, Year 2000 Exposure Classification on page 26) have been referred to by IBM as the Year 2000 challenge. The scope of the Year 2000 challenge spans the entire Information Technology industry. A data mismatch can exist in any level of hardware or software, from microcode to applications, in files and databases, and is present on all (IBM and non-IBM) Information System (IS) platforms. Some general misconceptions of the Year 2000 challenge include: 1. This is a problem that occurs only when and after the century rolls over: The challenges of handling the Year 2000 changes may occur well before the Year 2000 arrives. Typically, forecasting applications that deal with future dates encounters problems well in advance of the Year 2000. In fact, applications are already facing the problem (for example, the financial applications that deal with life insurance or bond policies that have expiration dates that go beyond the Year 2000). In such an application, the programs need to handle the dates beyond the Year 2000 when checking policy expiration. 2. This is a hardware clock problem that should be resolved by the computer vendors: To the contrary, this problem comes mostly from application programs and data using two digits for year representations even though the hardware clock and system timer services support a four-digit year format. 3. This is a problem that only occurs on mainframe systems and legacy applications: Any system or program can be affected if it uses only two digits for year representation such as any file, database, log with two-digit year fields, and
25
any data entry, query, update and output processing that employs two-digit year fields. It can also affect programs, systems, databases, and other functions and processing that receive input from these programs and data.
7.1 Year 2000 Exposure Classification

The Year 2000 phenomenon is further compounded by the numerous variations used to express year and date notation in data and the mathematical calculations performed on those date notations. These variations can be classified as the following exposure types:
Incorrect century: 1 Problems can occur when the first two digits in a year are assumed to be 19 and: Ignored during data entry and update. Hard-coded for output.
Dates used as a special value: Special values of the last two digits in a year might be used for a special purpose (for example, 99, 365/99, or 12/31/99 might be used to indicate no expiration date or 00 to indicate an unknown year).
Incorrect field format determination: Some existing programs determine the date-time format (that is, MMDDYY, DDMMYY, YYMMDD) by testing an appropriate part of the date field (for example, checking if the first two characters of the date field are values within an acceptable month, day, or year range such as 1-12, 1-31, or 32).
Arithmetic calculation: The arithmetic calculations that operate on dates with two-digit year representation might have potential exposures. For example, a person with a birthday of November 10, 1961 is considered to be minus (-) 61 years old rather than 39 years old on November 10, 2000, if the years 1961 and 2000 are represented by 61 and 00, respectively. Generally, a program that is not expecting a signed value ignores the sign. Thus, in this example, the 61 might be interpreted as the absolute value 61. Not only is the value still incorrect, it is even less detectable than the incorrect 61. Further, if such incorrect data is then stored in a database, it is considered a data integrity exposure.
Sequence: When only two digits are used to represent a year, programs that collate year data sort that data out of sequence in some cases. For example, the year 2000 (if represented as 00) is ordered prior to the year 1999 (if represented as 99).
Data integrity:
Although IBM recognizes that the 21st century begins at 0000 hours, January 1, 2001, for purposes of this document, we are defining the 20th to 21st century boundary to be between 2400 hours, December 31, 1999, and 0000 hours, January 1, 2000. This allows a discussion of the 21st century to include all dates with a 20yy format inclusive of the year 2000. Hence, the year 2100 is likewise relegated to the 22nd century.
26
In programs where historical dates are used, for example, all events occurring in 1800, 1900, and 2000 are not distinguishable when the years are represented by only two digits.
Leap year calculation: A specific year is a leap year if it is either evenly divisible by 400 or evenly divisible by 4 and not evenly divisible by 100. For example, the year 1900 was not a leap year but the year 2000 is a leap year. Some potential exposures caused by the identification of the year 2000 as a non-leap year are: Day-in-year calculations. The year 2000 has 366 days, not 365. Day-of-the-week calculations. February 28, 2000, is a Monday and March 1 is a Wednesday, not a Tuesday which is February 29, 2000. Week-of-the-year calculations. The 11th week of the year 2000 is March 5 through March 11, not March 6 through March 12.
7.2 Scope of Year 2000 Transition

The computing environment today is mostly constructed and integrated around the theme of heterogeneous, open, distributed, and client/server computing. The computers from different vendors are networked together to provide an integrated and distributed computing environment. Even though there are many different kinds of platforms in such an environment, they all tend to have the following common components: Computer Hardware

CPUs Storage devices Input/output devices Communication devices And so on
Computer Software

Microcode Operating systems Middleware, such as database management systems, telecommunication control programs, transaction monitoring programs, and so on. Programming languages, such as RPG, COBOL, FORTRAN, PASCAL, PL/I, C, and assembler Solution developers and 3 rd party software providers Application programs
People Those who develop and maintain the system, those who operate the system, those who provide its input and use its output, those who manage and ensure the quality of the system, and those who provide manual processing activities in a system. These people include:

End users Management
27
Auditors, quality assurance people System analysts System designers Programmers Operations personnel
Data The information that the system records and processes. Procedures Formal policies and instructions for operating the system. Figure 6 illustrates these components in an organization s networked computing environment. At each computing node (viewing the figure vertically), IS personnel follow procedures to access the data by means of computer software and hardware. The computing nodes (viewing the figure horizontally) are networked together by communication hardware and software to communicate to other computing nodes internal and external to the organization. The data is thereby accessible anywhere and anytime while the computing nodes are connected.
Figure 6. A Corporate Networked Computing Environment
28
The Year 2000 phenomenon potentially has both vertical and horizontal impact on such a computing environment as depicted in Figure 6. Vertically, the Year 2000 phenomenon can originate from or affect the key components of the computing systems, that is, hardware, software, people, data, and procedures. Horizontally, the phenomenon can propagate as the contaminated data flows to other computing systems inside and outside of the organization. In short, the scope spans the entire information technology industry. Although this is a complicated and far-reaching problem, it is not a technically difficult problem to resolve when viewed on a module-by-module or routine-by-routine basis. The degree of complexity is directly related to the inter-relationships between routines and programs and the data passed between them. This is not a trivial programming exercise. Your realization of a Year 2000-ready system demands immediate management commitment, dedicated resources (personnel and hardware), strategic planning, rapid development, acceptance testing, a well-planned migration, and an adequate budget. The following chapters address these issues and provide basic approaches for some specific issues.
29
30
Chapter 8. Planning to Resolve Your Year 2000 Exposures

To successfully address the challenges present within your computer system, you need to obtain your management s understanding, support, and an uncompromising commitment to provide resources to meet your needs. Expect the need for a knowledgeable executive sponsor to address budgetary, personnel, and hardware resource requirements, cross-department and cross-divisional requirements, and overall scheduling and project management. It is imperative that this effort begin with and be managed through a central focal point responsible for critical project aspects such as overall scheduling, coordinating, and setting a consistent methodology through all project phases. This chapter and the following chapter focus on those project phases such as planning, exposure identification, exposure elimination, testing, migration, and the selection of available tools. The larger your computing environment, the more diverse its software, the more decentralized its physical environment, the greater control you must exercise, and the greater the communication that must exist across the individual projects. The time to begin both planning and your Year 2000 transition is now. Understand the following considerations:
Getting requirements and design changes into the development cycle takes time. The review and modification of the application takes time. Securing resources and skills takes time. Handling the problem in real time disrupts your customer services, and the business impact is significant. Most organizations are already short-handed when addressing their current workload and the challenges they possess. Therefore, with this additional effort, perform a risk assessment and identify what is critical to the success of your business and determine and prioritize those work items. A significant amount of code rework may be required to complete your Year 2000 transition. It is not merely a problem that can be fixed by expanding the data fields. You must make changes to your data dictionary (field reference files), databases, files, programs, and so on. Within some institutions, programs are already producing incorrect output, and many organizations that do not have problems yet today, can expect problems tomorrow. For example, insurance companies, when calculating rates for persons born in 1994, might find themselves assessing 101-year-old rates on a new-born scale, or potentially assessing a new-born at the same rate as a centenarian.
For some organizations, it may not be mandatory to act now, but it can save code redesign, especially data rework. Each day that passes prior to your Year 2000 transition allows more data to be added to your databases and the potential for additional routines and programs that are added to your system. Also, expertise that is present today is no longer available later. Finally, there have been projections that the availability of consulting and out-sourcing services to meet Year 2000 transition needs will become increasingly limited as we approach the year 2000. For organizations with applications that handle future dates or those with thousands of application programs, the consequence of delaying the resolution of the problem may be disastrous to their continued future success.
31
8.1 Planning Considerations

You need to plan for changes across all aspects of your IS environment. The following task categories might prove useful when approaching this task: 1. Identify and communicate the organization goal: The goal is to have the function and operation of an organization Year 2000-ready before any disruption caused by the two-digit year data occurs. Year 2000-ready means that products, programs, files, databases, and processes have or produce no logical or arithmetic inconsistencies when dealing with dates beyond 1999. 2. Identify the deliverables and associated schedules for:

Hardware Software Documentation Training Maintenance Operations Administration Acceptance criteria for all deliverables
3. Analyze job assignments: For each task:
Identify the responsible person or organization, for example: Customers Management: - Chief executive officer - Chief financial officer - Chief information officer - Software development managers - Operation/administration managers - Budget/finance managers - Others Computer vendors Solution developers IT out-sourcing vendors Consulting/integration services providers System analysts System designers System/application programmers Operations personnel End users Auditors, quality assurance people Measure the estimated completion time. Identify precedences/dependencies. Identify resources and skills. Identify critical path schedule. Measure efforts. Measure costs. Identify technical factors. Analyze potential benefits: Return on investment Achievement of business goals Potential quality and acceptance of the approach
32
Your business keeps running. Analyze risk factors: Complexity of the task Resource/time constraints Length of project Critical development skills
4. Measure the criticality of each task and prioritize: Evaluate and determine how critical the functions of each entity are to the business success of the organization, and prioritize the sequence of providing Year 2000-ready solutions. An entity can be an individual, a department, a division, a business unit, customers, vendors, and so on, that are involved in the operations of the organization. The factors contributing to how critical you consider a task to be might include pressure of demand from end users for Year 2000-ready systems, legal issues, financial issues, or political issues. Impact to Business To determine the impact to your business, consider including these tasks:

Critical to the operation of the business (such as legal compliance) Critical to the uninterrupted operation of the business (such as payroll) Required to support the business (such as management and financial reports) Required to support the business; however, the importance and timetable for the activity is lower than an item above (such as regular scheduled reports). Desirable, but not absolutely required to support the business.
Impact to Operations Once classified by task, determine the impact severity. For example, you can use categories such as: Fatal Critical Operations abend or terminate. Operations produce an incorrect result. (For example, expiration dates for food or pharmaceutical products are calculated as over 100 years old, not one or several days old.) Minor inconvenience, annoyance, or irritation. (For example, inventory reports collate dates of 00 prior to 99.)
Marginal
Based on the impact to a particular process, evaluate the desirability of reworking a particular piece of code. Here is an opportunity for your IS management and your business strategists to affect the overall business practice. Together, these groups should consider possibilities such as:

Abandon the business process. Combine the process with other processes. Replace the process with a new state-of-the-art process.
5. Establish a critical event horizon : Business environments are unique. The initial date when your institution begins experiencing Year 2000 problems is also unique. If you prepare business forecasts of a three-year cycle, the fourth quarter of 1996 might be your critical event horizon. If you deal in automobile loans, 1995 might be
33
your critical event horizon. It is probably a rare institution that does not experience some form of Year 2000 difficulty until 1999 or 2000. 6. Provide data administration:
Identify the scope and responsibility of migrating the affected data: Exclusive: The affected data object is created and processed exclusively by this business area and is independent of any other business area. This can be at an individual, department, or the business area level with further decomposition and analysis. Primary responsibility: The business area defines the affected data object and other business areas should use that definition or negotiate for its redefinition. Secondary responsibility: The affected data object is defined and created by a different business area in the enterprise, and is distributed only within the scope of the enterprise. Each business area defines its own use of the object that is provided by the business area with the primary responsibility. External exposures: - The affected data object is defined and created by either this or a different business area in the enterprise, and is distributed beyond the scope of the enterprise. - Data is created outside of your enterprise and then imported and used within it.
Determine formats of the data dictionary (field reference files). Determine procedures for changing and entering data elements. Determine procedures for collaborative data sharing and use.
7. Decide project technical and management approaches:

Programming standards, conventions, and guidelines Platform for application development Hardware/software Development methodology Development and test procedures Proto-typing and parallel development: Commonly used in software development projects and should be applied wherever appropriate. Apply a divide-and-conquer approach to partition the Year 2000 project into smaller projects so that development and testing can proceed in parallel. Parallel development can shorten the development cycle. This is extremely critical when dealing with time-sensitive projects such as this Year 2000 project.
Process/data modeling Data dictionary (field reference files) Documentation structure, layout, and standards Reviews and walk-throughs
34
Quality assurance procedures Testing methodology Automated tools Migration of and bridging to existing Year 2000-ready systems Estimated future costs of maintenance
8. Identify project constraints, interfaces, and dependencies:
End users/customers: Availability of test and other data Availability of facilities and services Responsibility for reviews Responsibility for end user tests Other actions
Special contract negotiations Out-sourcing and consulting services: Justification for the out-sourcing and consulting services. Obligations for the out-sourcing and consulting services providers.
Interfaces and dependencies with other projects Supporting services and facilities required Hardware and software to be used Solution Developer-automated tools to be used Risks and alternative solutions Other assumptions
9. Provide standards, guidelines, quality assurance, and review procedures:
Year 2000-ready standards for purchasing hardware/software vendor products. Year 2000-ready system requirements on request for proposal for out-sourcing and integration services providers. Organizational Year 2000-ready standard/guidelines/process for specification, design, development, and testing of new and existing software. Year 2000-ready checklists for potential exposures. Standard for machine-human interface (refer to Section 10.4, Guidelines on page 52 for a list of standards). Procedures for submitting and processing proposed changes. The procedures should evaluate why change is needed, consequence of not making the change, and its effect on product, cost, and schedule. Procedures for sign-offs and approvals: The procedures should solicit comments from knowledgeable and affected people about effects on product, documents, schedule, and costs.
Procedures for future follow-up.
35
8.2 Inventory Your Software Portfolio

Once you have put your Year 2000 plan in place, you can begin the task of converting your software programs for Year 2000 readiness. The first step requires that you thoroughly understand your computing environment and compile an inventory of all the software programs within that environment. In order to obtain such an inventory, perform the following steps: 1. List all libraries that your production uses. 2. List all objects in your production libraries and determine if any objects are no longer used. 3. Obtain all documentation for your applications. If you cannot find any, use any documentation tool to help compile this information. ADS/400 can assist you in producing cross references of your applications. 4. Verify the object and source integrity. You should compare the descriptions of your objects and their matching source in the following manner:
For programs, use:
DSPOBJD DETAIL(*FULL) OUTPUT(*OUTFILE)

Then look at the source file name/library/member name and source change date/time.
For source files, use:
DSPFD TYPE(*MBR) OUTPUT(*OUTFILE)

Then look at the last change date/time of the related members. If they match the values in the DSPOBJD output, you have source/object integrity. If not, you must research further and correct any inconsistencies first. Such an inventory allows you to:
Analyze your portfolio for definition and movement of date-related data elements and the use of date-related calculations and manipulation. Identify and remove Year 2000 exposures. Track and control changes to your portfolio to more easily monitor and prevent injecting new Year 2000 exposures into your inventory while your Year 2000 resolution work progresses. Test the new (Year 2000-ready) version of the software programs in your portfolio.
Once you have completed the preceding activities, you are ready to migrate from your current computing environment to your Year 2000-ready environment. The following chapters discuss these activities in detail and provide options and suggestions for your consideration.
36
Chapter 9. Identifying Two-Digit Year Exposures

To identify the potential exposures caused by using two-digit year representations of dates, you first need to locate references to all date-related data.
9.1 Locating References

Locating date-related data and code is itself a major piece of the work effort that you must address. The most complete method starts with an inventory of every programming entity used in your IS center. Once compiled, you can review each program individually. Alternatively, use the following, more systematic approaches to locate two-digit year data and date-related code. (Solution developer products are available to assist with this effort:) 1. Review the following documents for direct or indirect references to date-related data and formats. Trace these references back to the application source code to locate references in that code as well:

Requests for proposal Statements of work Planning documents that describe future IS needs Existing studies about the current system Software development standards and process documents Software quality assurance requirements System requirements specifications System design specifications Program specifications User instructions and procedures Data dictionaries (field reference files)
2. Review program information for date references to include, for example, date variables, date functions or routines, and character strings. The following character strings might be included in either your code or its comments: AS-OF, ASOF MDY, MMDDYY BEGIN, BEG, BGN MMYY CCYY START CYYDDD, TERM TIME CYYDDMM, TIMESTAMP, CYYMMDD CURR, CURRENT TIME-STAMP DATE, DAT, DTE, DT TIMEDATE DAY, DA, DD THISDATE DDMMYY, DDDYY TOD, T-O-D DIFFDATE WEEK DOB WEEKDAY DOH YEAR, YR, YY END YMD, YYMMDD, EXPIRE, EXP YYDDD JULIAN and so on. MONTH, MON, MO, MMM
37
Data entry forms, screen display formats, report formats Definitions of data fields, records, structures, files, and databases Source code, computer program listings, cross-reference reports Command languages, for example, CL and REXX Data indexes (access paths, physical and logical) Data dictionaries (field reference files) Date/time service routines Sort routines
3. Use a test system: Install an isolated, non-production system with a duplicated image of your system and application software. In large systems, consider dedicating a separate machine, segregated (in either time or place) from any other system (or systems). This segregation is crucial to guarantee that you avoid contamination due to system clock advancement or untested, and yet imperfect, modified code.
With a changed date/time setting: Set the system date and time to a future date and time value after January 1, 2000. During such testing, be sure to use compatible data that is synchronized with the revised application software, that data crosses a 100-year boundary, and to update your current operating procedures to reflect this new data requirement as well. For example, the 100-year window can be 1900 through 1999 or 1995 through 2094, or you can use both range types. The more varied are your window type (or types), the more incorrect code you uncover. This testing helps you identify many (but not all) Year 2000 exposures.
With changed data: If you only change date fields in a routine, you are not introducing new logic into that routine. Although the fields are increased from two-digit to four-digit fields, you only need to recompile the routine to generate those new field lengths. If you did not change the logic, you need not test that logic. Typical testing is appropriate in a separate test system using new data, but Year 2000-specific testing is really unnecessary. In this testing, ensure that the changes in the operand lengths produce the expected results. If the results match those produced prior to your changes, the application is successfully performing data calculations using the new four-digit data rather than the previous two-digit data, and you have met your migration criteria.
Refer to Chapter 11, Testing Techniques for Year 2000 Changes on page 55 for a more detailed discussion of testing techniques and issues. 4. Use a combination of the preceding approaches.
9.1.1 Tracing References Back to Their Source

For any potential exposure that you identified, also identify all direct and indirect references of this exposure. You can do so by tracing the flow of the data to identify its immediate source and destination and repeat the tracing process until all sources and destinations of all potential data exposures are identified.
38
9.2 Determining the Impact of Two-Digit Year Data Fields

Once you have located date-related data fields by one or more of the preceding approaches, you can classify the use or reference of those fields into one of the following categories:
No impact: The program uses a four-digit year representation in all occurrences. The program uses a two-digit year representation within a program, but does not have any internal exposures, nor is it passed externally as a two-digit year in any way. The program uses a two-digit year representation within a program, but does not have internal exposures. The two-digit year is passed externally but cannot be referenced (for example, for display only) by another program.
Note: Such output might be labelled as cosmetic only and for interpretation by a human only, but this also might have its own set of ramifications. A municipality that tracks school age children more frequently begins inviting centenarians to enroll in kindergarten. If a printout of residents reads:
Birth date: 10/14/89

what does the clerk compiling the list of 6-year-old children assume? Another type of exposure is externalized by display-only dates that have been coordinated with a hard-coded 19 for the century. Such two-digit exposures might exist for terminal display or special forms where the 19 is preprinted. Therefore, be aware of and consider the potential impact of date fields in all situations; these might not always be obvious exposures.
Impact: The program uses a two-digit year representation within a program. It does not have internal exposures, but the two-digit year is externalized and can be referenced by another program. The program uses a two-digit year representation and has internal exposures.
9.3 Investigating How Other Software Entities Use the Data

You also need to investigate the ways data is shared among software entities. The greater the degree and scope of data sharing, the more global is your task and the more critical is the need to prevent the further propagation of and data contamination by two-digit year data. Except possibly in a rather small IS environment, you cannot know how output is used by all other programs that might access it. Several factors that affect how data is shared or used among software entities follow. These factors and the types of data sharing provide some of the links making up this data web .
Chapter 9. Identifying Two-Digit Year Exposures
39
9.3.1 Data Sharing

Three factors affect the sharing of data between modules: 1. The number of data items passed between modules. (The more data passed, the tighter the relationship.) 2. The amount of control data passed between modules. (The more control data passed, the tighter the relationship.) 3. The amount of global data elements shared between modules. (The more global data elements shared, the tighter the relationship.) Several types of data sharing can occur between two modules in a program. Two modules can communicate:
Through a variable or data structure (for example, array, table, or record) that is passed directly as a parameter between the two modules. The data is used for problem-related data processing, not for program control purposes. Through a variable or data structure (for example, array, table, or record) that is passed directly as a parameter between the two modules. However, only part of the data in these composite data elements is needed in the call; that is, more data is passed than needed. A change in one of the data structures to accommodate a change in either the calling or called module can affect other modules as well. By passing data from one module to another to control the order of instruction execution. (For example, a control flag is set in one module and tested in a CASE or WHEN statement in another module.) By passing data between modules through some mutually agreed upon location in a global data area. A change in one module might then require changes in other modules sharing the same data area. By one module reaching into the internals of another module to get or deposit data or control its function (for example, a branch from one module s code into another module). A change in either module might require a thorough analysis of the internals of both modules to determine how to deal with the consequences of the change.
If contaminated (two-digit year data) is shared among modules, you must identify the exposure caused by the data sharing on the receiving side of the transaction. Once you have identified Year 2000 exposures, apply the appropriate techniques (as provided in Chapter 10, Reformatting Year-Date Notation on page 41) to reformat these date and time representations.
40
Chapter 10. Reformatting Year-Date Notation

This chapter provides a number of techniques that you can employ to correct improper date notation and use. Because some techniques are appropriate only to unique situations, this section also lists the advantages, disadvantages, and IBM recommendations for their use. When selecting a proposed Year 2000 solution, evaluate the following factors: 1. What is the external impact due to incompatible date format changes? That is, what other programs or what output are affected and to what extent do those programs require change if this solution is implemented for this particular program? 2. How current are the program modules that reference the date formats externalized by the exposures? That is, are there any plans to either eliminate or replace this particular program or routine, the programs that input to it, or those that receive or use its output? 3. What functions are impaired due to Year 2000 exposures? That is, is any mission-critical function within your company compromised due to not reworking or replacing a particular program?
10.1 Solutions and Techniques

As you identify Year 2000 exposures by the approaches described in Chapter 9, Identifying Two-Digit Year Exposures on page 37, your next step is to rework the current program and data exposures to make your applications Year 2000-ready. You can apply the following solutions to remove potential Year 2000 exposures. Each solution is presented with an example technique to change the potential exposure. These suggested techniques require both program and data changes. Several solutions and techniques and their associated pros and cons follow:
10.1.1 Solution #1: Conversion to Four-Digit Year Format Using SAA Data-Type Date
This solution is a four-digit solution to change the data type of the date field from P(packed decimal), S(zoned decimal), or A(character) to L(date). This approach requires changes to both the data and the program by converting all references and uses of two-digit year format (YY) to date data type format. The default format for an SAA date data type field is *ISO, that is, YYYY-MM-DD. You can change this format using keyword DATFMT either in DDS or in RPG into *USA (=MM/DD/YYYY), *EUR (=DD.MM.YYYY), or *JIS (=YYYY-MM-DD). You should avoid using DATFMT(*MDY, *DMY, *YMD) as it presents dates in two-digit year format. An SAA date data type field can be used in both OPM and ILE environments. The real benefit of using this format comes with ILE. For example, ILE RPG/400 provides new commands such as ADDDUR, SUBDUR, TEST, and EXTRCT. With ADDDUR/SUBDUR, you can add/subtract a duration to or from a date. You can extract part of a date with EXTRCT and test for a valid date with TEST without
41
creating a user calendar or complicated date arithmetic such as leap year calculations. This method also requires that you convert all software programs that reference or use the updated data simultaneously, or use a bridging mechanism to perform the conversion between old and new data and programs. Refer to Section 10.3.2, Bridge Programs Help Stage Format Conversions on page 50 for more details on bridge programs. (You can accomplish this program and data conversion in steps.) Otherwise, you immediately encounter data integrity problems caused by the inconsistency of date/time data formats.
10.1.1.1 Pros and Cons

Pros 1. Can provide four-digit year format. It is considered to be a complete, permanent, and obvious solution. 2. Employs the ISO format (YYYY-MM-DD) by default. 3. Provides increased security against potential inappropriate decisions today if you do not selectively ignore cosmetic only situations. 4. Can ease your migration if you selectively ignore cosmetic only situations. Cons 1. Need to convert the year data from two-digit format to four-digit format in all cases. 2. Requires that you relocate adjacent fields in the date field layout, and usually requires that you increase record lengths. 3. Inherent future risk in initial assessment that determines a particular situation can be ignored as cosmetic only . 4. Increased DASD space usage required due to data field expansion of data (consider including not only active but also archive data) and duplicate DASD space during conversion. 5. Might experience a performance impact due to increased time in processing and date access.
10.1.2 Solution #2: Conversion to Full Four-Digit Year Format

This solution is a four-digit solution that externalizes a four-digit year format. This approach requires changes to both the data and the programs by converting all references and uses of two-digit year format (YY) to four-digit year format (YYYY). It also requires that you convert all software programs that reference or use the updated data simultaneously, or use a bridging mechanism to perform the conversion between old and new data and programs. Refer to Section 10.3.2, Bridge Programs Help Stage Format Conversions on page 50 for more details on bridge programs. (You can accomplish this program and data conversion in steps.) Otherwise, you immediately encounter data integrity problems caused by the inconsistency of date/time data formats. To ease your migration, you might consider ignoring any non-impact (cosmetic) data fields in the YY format. A cosmetic date is one that, if externalized, is only interpreted by humans. Such occurrences might include the date on an output
42
separator page or a display-only date on a display in a window-driven application. Note: Be careful when selecting those situations that you decide to ignore and call cosmetic only. Be certain that they do not cause any data integrity exposures or ambiguity, or are not accessed by any other program. Such instances of non-problem YY formats appear in a report header that shows the printing date of the report. The date is meant for human understanding only, not computer program manipulation. Consider the potential for future change. For example:

Today s reports might be written to a data set tomorrow. Display-only dates today may prove useful as a collating value when archiving that output tomorrow to meet a new business or government standard. Even when viewed by a human, two-digit dates can prove ambiguous if the data spans 100 years.
If you allow the end user to continue to input two-digit dates for compatibility and ease of data entry, the responsibility to translate that data into a full four-digit date falls to you, the application or systems programmer. One possible solution is to apply a context-sensitive prompt to allow the user to select a century indicator. For example, allow all dates to be entered as two-digit dates and automatically prefix those with the current century unless the date is a future date or historical date. What constitutes future or historical is your decision but can be any date other than today s current day, week, month, year, and so on. Using this scheme, a future date in context of a loan maturity date can be set to 20yy, or a historical date automatically forces the user to select a century from a choose a century (...16, 17, 18) prompt list.

Pros 1. Can provide four-digit-year format. It is considered to be another complete, permanent, and obvious solution. 2. Provides increased security against potential inappropriate decisions today if you do not selectively ignore cosmetic only situations. 3. Can ease your migration if you selectively ignore cosmetic only situations. Cons 1. Need to convert the year data from two-digit format to four-digit format in all cases. 2. Requires that you relocate adjacent fields in the date field layout, and usually requires that you increase record lengths. 3. Inherent future risk in initial assessment that determined a particularly situation can be ignored as cosmetic only . 4. Increased DASD space usage required due to data field expansion of data (consider including not only active but also archive data) and duplicate DASD space during conversion. 5. Might experience a performance impact due to increased time in processing and date access.
43
6. Some programming languages allow integer dates that are offset from a base date to be stored in files, databases, or passed as parameters between programs. Such integer dates provided by COBOL intrinsic functions, Language Environment callable services, the CICS FORMATTIME command DAYCOUNT option, and other similar functions must conform to the standard YYYYMMDD format. This standard eliminates potential ambiguous data and errors due to each integer-date system using a unique starting date. Therefore, the potential for mixing incompatible integer dates when passed outside a single source module is extremely high and must be avoided.
10.1.3 Solution #3: One-Digit Century Code

This is basically a two-digit year solution with an additional one-digit to define the century. There are two possible ways to use this method: First, add a separate one-digit century code field to an existing six-digit date ( external century code ); and second, expand the date field to seven digits by adding a one-digit century code in front of the date ( embedded century code ).
10.1.4 External Century Code

This solution basically uses an existing two-digit year date and adds a separate one-digit century code to identify the correct date and year. For example, OS/400 V3R2 provides a new system value called QCENTURY. The format of QCENTURY is CHAR(1) and the system value supports the values 0 for 19YY and 1 for 20YY so that you can retrieve this value and make use of it in your application. This approach requires changes to both the data and the programs. For the database, the change is fairly simple. Add a one-digit field to the end of the current record format (for each date field in the record) so that it does not need to recompile the related programs if they are not using the date field. If the date field is used as a key in an access path, you must also change the access path to include the new century code field in the key fields section so that the correct collating sequence is achieved. For the programs, the change is not that simple. You should closely examine your program for the date arithmetics. For example, in RPG, you may have to use data structure to combine the six-digit date field and the century code to obtain the correct result from date duration calculation. Here again, you might consider ignoring any cosmetic date fields in the YY-format, especially in display and printer files. Refer again to Solution #1 for the discussion about this cosmetic data. The biggest benefit of this conversion method comes with its transition process, that is, to enable you to make a two-step conversion. You can convert the database format first adding the century code at the end, and then copy the current data into the new format with the *MAP option. When you finish adding the appropriate century code data, you can start modifying your programs later. As the base data format including date fields remains the same, the transition does not have to take place at one time.
44

Pros 1. Able to convert the database format first and modify the programs later. 2. Provides easy solution for data migration into the new format, just use CPYF with *MAP option, and add Century Code data later. 3. Can ease your migration if you selectively ignore cosmetic only situations. Cons 1. Additional logic required to all programs that perform date calculations, such as the use of data structures to combine the date fields and the century code fields. 2. Collating sequence is not correct if the date field is used as a key unless the century code is added to the key. 3. Requires that you increase record lengths. 4. Inherent future risk in initial assessment that determines a particularly situation can be ignored as cosmetic only . 5. Increased DASD space usage required due to the addition of the new century code field.
10.1.5 Embedded Century Code

This solution is meaningful only when you are using a date format of YMD in a six-digit, packed decimal field. You can expand your six-digit date field into seven-digit packed decimal, and add century code data as the first digit of the field. Because of the nature of packed decimal, both six digits and seven digits are stored in the same length of four characters in the physical file record. Therefore, the real benefit of this solution is that it does not increase DASD space usage. This approach requires changes to both the data and the programs by converting all references and uses of two-digit year format (YY) to three-digit year format (CYY). Since it changes the date format itself, the conversion steps are not as simple as it is in the External Century Code method. It also requires that you convert all software programs that reference or use the updated data simultaneously, or use a bridging mechanism to perform the conversion between old and new data and programs. The same considerations apply here for this bridging mechanism and cosmetic data handling as they are already discussed in Solution #1.

Pros 1. Correct data sequencing is retained. 2. No extra disk space increase required. Cons 1. Need to convert the year data from two-digit format to three-digit format in all cases. 2. Requires the data conversion from YY-format to CYY-format.
45
10.1.6 Solution #4: Windowing Techniques

This is a two-digit solution that externalizes either two-digit or four-digit year formats. This approach requires changes to your programs only; no data changes are required. IMPORTANT! These approaches can be applied only to dates within a maximum 100-year period at any one time. This solution is considered temporary because there is no guarantee that in the future, your applications do not expand to process dates that are more than 100 years apart. Therefore, this approach always carries with it a potential future exposure. (For example, humans are living longer. Therefore, databases that include birthdays (medical, civil, insurance, and so on) and the applications that access that data are already at risk with many dates spanning 100+ years.)
Two types of windowing techniques have been defined: the fixed window technique and the sliding (rolling) window technique.
10.1.6.1 Fixed Window Technique

The fixed window technique uses a static 100-year interval that generally crosses a century boundary. This technique determines the century of a two-digit year by comparing the two-digit year against a window of 100 years. The user specifies the number of years in the past and future relative to a specific year within the 100-year interval. Consider this specific example: If the years of date-related data of your application fall in the range of January 1, 1960, to December 31, 2059, you can use a two-digit year to distinguish dates prior to the year 2000 from the year 2000 and beyond. If using the current system year of 1995, the number of years in the past and future are specified as 35 and 64, respectively. Program logic determines the century based on the following data checking. If the two-digit year representation of a specific year is XY, if:

XY60, it is a 20th century date (19 xy)

Otherwise (that is, xy59), it is a 21st century date (20 xy).
If, for example, you need to maintain a window of 35 past years and 64 future years, such that next year, 1996, your application can successfully deal with dates in the range 1961 through 2060, you need to adjust this program checking every year. The inherent future risk when employing this technique is obvious, and when compared to the sliding window technique, is far less desirable.

Pros 1. No need to expand the two-digit year data to a four-digit format. 2. Can provide four-digit year format for data reference. 3. Can distinguish years from different centuries using only two-digit year format (provided the years being processed are in the range of 100 years at any one time). 4. Can be useful if the particular program is being phased out and a temporary solution is appropriate.
46
Cons 1. Potential exposures exist when or if the function of the software application needs to process years beyond the range of 100 years. 2. Expect a performance impact in direct proportion to the quantity of date processing the particular application handles due to the overhead of two-digit year to four-digit year conversion. 3. All programs that use the fixed window technique may need to be manually updated on a yearly basis depending on how your date routine is packaged. 4. All programs that accept output from the fixed window technique must use the same assumptions (current date, past, and future windows). 5. Retaining a two-digit year representation does not provide collating sequence support. Nor does the use of a fixed window technique provide indexing sequence support when two-digit years are used as index keys in indexed files. You need to provide additional processing to obtain correct collating and indexing sequence output.
10.1.6.3 Sliding Window Technique

The sliding window technique uses a self-advancing 100-year interval that generally crosses a century boundary. This technique determines the century of a two-digit year by comparing the two-digit year against a window of 100 years. The user specifies the number of years in the past and future relative to the system year (generally the current year) that the system sets 2. and maintains. Your applications can access the date that the system sets and automatically advances. This is the main advantage of using a sliding window over the fixed window (where the window is immovable without manually revising the programs each year). As appropriate to your application environment, you can maintain more than one window. For example, you can set one window to process historical dates, one for mortgage dates, one for birth dates, and so on; and the program adjusts the system date and past and future windows to meet the specific application s needs. Consider this specific example. If the dates in your application fall into a range of 35 years in the past and 64 years into the future based on the current year, 1995, your program can accept and accurately deal with dates of 1960 through 2059. Next year, 1996, the window advances and your application accurately deals with dates of 1961 through 2060. Graphically, Figure 7 on page 48 illustrates this example using the current (1995) 100-year window and that same window when the current system date has progressed to the year 2024.
IBM product, Language Environment, provides an option whereby you can set the system year to other than the current year. This flexibility then allows you to set a 100-year range you require; it need not even contain the current year. Refer to Chapter 13, Tool Categories and Available System Features to Ease Year 2000 Changes on page 65
47
Figure 7. Graphical Representation of the Sliding Window Technique. system dates, 1995 and 2024, as an example.)
(Using two current
A sliding window approach requires programming logic to interpret the meaning of all two-digit year data. Such additional programming logic can be packaged into a common data/time service routine, callable from a two-digit year data exploiter. This reduces the programming overhead and impact to the calling programs. The IBM product, Language Environment, provides common date/time service routines with sliding window features. By default, Language Environment uses a window of 80 years in the past and 20 years into the future that is automatically adjusted based on the current year date. For details on using and setting the past/future window range, refer to Chapter 13, Tool Categories and Available System Features to Ease Year 2000 Changes on page 65.

Pros 1. No need to expand the two-digit year format to a four-digit format. 2. Can provide four-digit year format for data reference. 3. Can distinguish years from different centuries using only two-digit year format (provided the years being processed are in the range of 100 years at any one time). 4. No need to convert the date data to a new date representation scheme. Cons 1. Potential exposures exist when or if the function of the software application needs to process years beyond the range of 100 years. 2. Potential performance impact in direct proportion to the quantity of date processing the particular application handles.
48
3. All programs that accept output from the sliding window technique must use the same assumptions (current date, past and future windows). 4. Retaining a two-digit year representation does not provide collating sequence support. Nor does the use of a sliding window technique provide indexing sequence support when two-digit years are used as index keys in indexed files. You need to provide additional processing to obtain correct collating and indexing sequence output.
10.2 Using a Common Date/Time Service Routine

In large system applications, it is common to find that more than one date/time service is in use. However, some date/time service routines may have Year 2000 exposures of their own, for example, the routine (or routines) only provides a two-digit year format. Fixing the exposed date/time routine (or routines) is one possible solution. Selecting a vendor date/time routine that is certified as Year 2000-ready for consolidation and replacement of your in-house date/time service routines is another alternative. While fixing your current date/time routine (or routines) exposures, you may find it worth your effort to consolidate all your date/time service routines into one common date/time service routine . If you detect any Year 2000 exposures during or following the consolidation, you can reformat your program and data and decide on the appropriate solution (or solutions) you use. That is, you can package any new code, encoding and conversion routines, windowing-specific data, and so on, into the common date/time service routine. This common date/time service routine package might be considered a four-digit solution that externalizes both two-digit-year and four-digit-year formats. The benefit of using such a common date/time service routine is lower future maintenance because all services are consolidated rather than replicated throughout your applications. (See Chapter 2, Internal Application Modernization on page 9 for techniques.)
10.3 Considerations When Selecting Solutions

As described in Section 9.2, Determining the Impact of Two-Digit Year Data Fields on page 39, potential two-digit year exposures can be classified into two categories (no impact and impact). When selecting an appropriate solution (or solutions) for the impact categories, be sure to consider not only the applicability of the solution (or solutions) on the module itself, but also the potential impact and adjustments on the external modules that receive data from this module. You have three basic choices; you can:

Change your application. Change your application and the data. Invest in a new application (which can also require some date data changes).
Certainly, most IS organizations will build their 2000-ready system on a combination of these choices. When more than one solution appears feasible, weigh its appropriateness based on:

Time available Resources available (personnel and hardware) Project cost (individual application conversions and overall)
49
As today s IS environment becomes increasingly complex and sophisticated, the instances of program and data isolation decreases. In an open and distributed computing network, data is able to flow from site-to-site, system program-to-application program (or application program to system program), and so on. You must ensure that these layers of software speak the same language . As you add in-house code, solution developer-written code, and migrate your operating system, be sure to review that software for date format compatibility across the network.
10.3.1 Solution Applicability

Different combinations of solutions are applicable to different situations. Evaluate solutions based on a best-solution combination basis when considering both a module itself and other related modules. For example, when applying:
Solution #1 ( date data type) or Solution #2 (full four-digit solution) to a certain module, another module that receives data from this module can receive: Two-digit year data as before, provided there is no exposure for itself. Two-digit year data as before and apply Solution #4 (windowing techniques) for its own exposures. Four-digit year data and apply Solution #1 ( date data type), Solution #2 (full four-digit solution), or Solution #3 (one-digit century code) for its own exposure removal.
Solution #3 (one-digit century code) to a certain module, another module that receives data from this module can receive: Two-digit year data as before, provided there is no exposure for itself. Two-digit year data as before and apply Solution #4 (windowing techniques) for its own exposures. One-digit century code data and apply Solution #1 ( date data type), Solution #2 (full four-digit solution), or Solution #3 (one-digit century code) for its own exposure removal.
Solution #4 (windowing techniques) to a certain module, another module that receives data from this module may either receive two-digit year data as before and apply Solution #4 itself or receive four-digit year data and apply Solution #1 ( date data type), Solution #2 (full four-digit solution), or Solution #3 (one-digit century code) for its own exposure removal.
10.3.2 Bridge Programs Help Stage Format Conversions

Bridge programs are often used to convert data from one record format to another. If you use such a program, it should define:

Input date format and encoding method. Output date format and encoding method. Logic that converts the data from input format to output format based on their encoding methods.
You can apply bridge programs during program execution or file and database conversion. For application during program execution, the conversion occurs each time data is passed between programs or between program and source data using different record formats. For application during file and database conversion, the bridge program reads one record at a time from the source, transparently converts the record format, and writes out the data in the new
50
format to the destination. The process is incremental and can continue until all the records in the source are converted. Bridge programs for data format conversion provide the following benefits:
Granularity when changing the code and data: With the scope of the Year 2000 project, it is not practical (if possible) to change all the code and data at once. Bridge programs allow the gradual conversion of the programs and data and still maintain the compatibility between different data formats. For example, you can change some of your programs to adopt a new data format and still be able to communicate to programs using the old format (after conversion by the bridge programs). Therefore, changes to the remainder of your programs can be performed in an incremental manner as convenient.
Flexibility when choosing appropriate solutions: Bridge programs allow you to select the appropriate mix of different solutions to best meet your specific circumstances while maintaining the compatibility between different data formats. For example, you can design your programs so that they can process data in different formats. You can have active data in a four-digit year format and archive the same type of data in two-digit year format. The bridge program distinguishes the data in these various formats by reading the records and, when necessary, converting the data to the appropriate format.
10.3.3 Other Programming Situations

Other programming situations you should consider might include:
The possibility that a data format has become outdated and will not function correctly beyond December 31, 1999 (or earlier). Such data formats might be outdated even earlier and have already been superseded by another method by the solution developer.
When migrating to Year 2000 support, your applications (operations) might support only two-digit year format, only four-digit year format, or both formats. It is possible that the two-digit values are assumed to be 19xx dates. Therefore, be aware that all these must be eventually updated or the functions fail or give unpredictable results after December 31, 1999, if not sooner.
Changes to operations procedures: Be sure to educate your operators about command changes so that they know when they must use a full four-digit date (for example, 2000, to avoid implying 1900 if they only enter 00).
When erroneous data is produced for a limited and known time frame and changes are not justified: You might have a situation that is best handled manually to meet a short time period where programming changes simply are not justified. Consider using two-digit year data if a time frame such as a single 24-hour period (December 31, 1999 to January 1, 2000) or a single week (December 25, 1999 through January 1, 2000) is the only time your application does not provide correct results. For example, a program that looks at a sales report to compare the current day s merchandise movement with the previous seven
51
days. Because there are only eight reports containing both 1999 dates and 2000 dates, you might decide to handle the problem manually rather than changing the code. Note: Use a certain amount of common sense when deciding which applications to change, which to replace, and which to ignore. Do not lose your perspective of your institution s business needs and priorities, and the impact and cost a particular application s change might have on attaining those goals.
10.4 Guidelines
While retaining a perspective of any external impact, module currency, and what functions are impaired due to Year 2000 exposures, use the following guidelines when applying Year 2000 solutions. Note: This is not intended to be an exhaustive guideline, but rather a foundation upon which to start your specific Year 2000 date-data resolution. 1. Establish an in-house date standard . Conformance to the ISO Standard 8601 in the following list is a valuable starting point. The earlier such a standard is in place, the sooner your IS organization can avoid creating new date issues and the propagation of current ones. You can refer to:
ANSI X3.30-1985 (R1991) Representation for Calendar Date and Ordinal Date for Information Interchange ANSI X3.51-1994 Information Systems -- Representations of Universal Time, Local Time Differentials, and United States Time Zone References for Information Interchange ISO 8601:1988 Data Elements and Interchange Formats -- Information Interchange -- Representation of Dates and Times
These standards are available in the following places:
ANSI Online Home Page (access to ANSI catalog and standards documents):
http://www.ansi.org/
OSI Online Home Page (access to ISO catalog and standards documents):
http://www.iso.ch/
2. Minimize potential impact to external references due to incompatible date format changes. For example:
Maintain the two-digit-year format as an option when four-digit format is required for an application program interface (API) that provides two-digit-year data references.
3. Avoid any ad-hoc solutions; such solutions inevitably require a future problem investigation and removal, and should be considered temporary solutions only. For example:
Do not determine the century of a two-digit year by comparing the two-digit year against a hard-coded threshold, for example, 60. If the two-digit year is greater than or equal to 60, the year is a 20th century year; otherwise, it is a 21st century year. Do not fix the leap year calculation formula by adding logic to check if the current year is the year 2000. This solution temporarily fixes the leap
52
year calculation problem by singling out the year 2000, but it does not fix the leap year calculation problem for other years in multiples of 400. 4. A two-digit year format might be acceptable for human-only viewing purposes, for example, displays, hardcopy reports, and so on. However, any such data can be, and often is, added to a data set and read by another program. A log that can be used as input to any program should not be considered in this (non-impact, for human viewing only) category. 5. When changing the date format of any log , ensure that all the contributing programs adopt the new date format as well. 6. Consider the Year 2000 solutions listed in this document (see Section 10.1, Solutions and Techniques on page 41) for applicability in the following order:
Using a common date/time service routine (a four-digit solution that can support both two-digit and four-digit formats). This is: Considered a long-term solution. The recommended solution for its support of both two-digit year and four-digit year formats that provide a long-term solution and no impact to two-digit year data references.
Solution #1 or #2 (conversion to a date data type or a full four-digit year format that externalizes four-digit formats): Considered a long-term solution. Only supports four-digit year formats that have an impact on two-digit year data reference.
Solution #3 (conversion to a one-digit century code) that externalizes three-digit formats): Considered a reasonably long term solution. Only supports three-digit year formats that have an impact on two-digit year data reference.
Solution #4 (windowing techniques that externalize both two-digit and four-digit formats): Considered a temporary solution and should only be used when Solution #1, #2, or #3 is not practical . (This is an arguable issue because there are applications that deal only with years in the range of 100 years. However, there is no guarantee that the functions of the applications will never change in the future and require four-digit year formats.) Has potential exposures when the function of the program needs to process years beyond the range of 100 years. Use this solution only when: - Processing is always limited to the current date data, for example, at the time of IPL or time of job creation. - Expanding the date-data field is costly, and the function of the software program is phased out before any exposure occurs.
53
54
Chapter 11. Testing Techniques for Year 2000 Changes

Testing can be formalized into a four-phase process, as follows: Test Type Unit testing Integration testing System testing Acceptance testing Used to Test A single program module A related group of program modules The entire software application The entire software application with live data for production readiness
Ideally, these phases should be completed sequentially. However, when development work is done in parallel, module coding, unit testing, and integration testing are commonly integrated, followed by system testing and acceptance testing. During the process of testing, apply a combination of verification and validation techniques. Unit and integration testing are primarily used for program verification. These two forms of testing comprise structural testing, which is used to uncover errors injected during program coding. System and acceptance testing are used for program validation, and these two forms of testing comprise functional testing, which is used to uncover errors that occur when implementing requirements or design specifications. The following sections cover some useful testing techniques and scenarios for Year 2000 testing.
11.1 Structural Testing Techniques

Structural testing ensures sufficient testing of a function s implementation and helps determine that all structures of the system are integrated to form a cohesive unit.
11.1.1 Operations Testing

Apply operations testing to determine whether the system is ready for normal system (production) operations. In contrast, recovery processing (discussed in Section 11.1.3, Recovery Testing on page 56) is intended for abnormal system operations. Considering the potential scope and magnitude of your Year 2000 transition, every aspect of the normal operation might be impacted to some extent as you revise programs and data for Year 2000 readiness. Operations testing ensures that, prior to production, your IS staff can properly administer the applications using the new support mechanisms, documentation, procedures, and training as you complete your Year 2000 transition.
11.1.2 Stress Testing

Apply stress testing to determine if the system can function when transaction volumes are larger than normally expected. The typical areas that are stressed include disk space, transaction speeds, output generation, computer capacity, and interaction with people. When testing Year 2000 changes, it is essential to verify that the existing resources can handle the normal and abnormal volumes of transactions after the restructuring of the code and the possible expansion of the data fields. For example, apply stress tests to determine:
55
If existing CPU capacity is sufficient to meet expected user turnaround time when a particular solution is applied and uses more CPU cycles and processing time for code conversion. If existing disk capacity is sufficient to accommodate the additional disk space and provide acceptable disk access time when a particular solution is applied and expands the year data field.
11.1.3 Recovery Testing

Apply recovery testing to ensure that the system can restart processing after losing system integrity. This is essential for systems in which the continuity of operation is critical to end users. Recovery processing normally involves the ability to go back to the last checkpoint, then reprocess up to the point of failure. The success of the recovery depends heavily on complete backup data and checkpointing. Any data integrity or unresolved exposures that lead to inconsistent data or code after you have implemented appropriate Year 2000 solutions affects the completeness of backup data. On the other hand, checkpointing is time oriented and sensitive. Any mishandling of the time-related data might invalidate system checkpointing. The recovery testing is thus critical in a Year 2000 testing environment. It can also involve manual functions (such as hardware or operating system failure), loss of database integrity, operator error, or loss of input capability. Recovery testing should include all aspects of the recovery processing.
11.2 Functional Testing Techniques

Functional testing is designed to ensure that the system and end-user requirements and specifications are achieved. Functional testing focuses on the results of processing rather than how processing is implemented. To accomplish this, create test cases to evaluate the functional correctness of the system and programs. Functional testing techniques are included in the following sections.
11.2.1 Requirements Testing

Apply requirements testing to verify that the system performs its function correctly and that it remains functional over a continuous period of time. Functional checklists such as user requirements, design specifications, compliance of organization s polices, and procedures are used to create test cases to ensure that these requirements are still satisfied following your Year 2000 transition. Note that if the Year 2000 solutions are merely restructuring code and reformatting data without major redesign of the applications or systems, most requirements testing can be covered by another method, regression testing.
11.2.2 Regression Testing

Apply regression testing to ensure that all aspects of a system remain functionally correct after changes have been made to a program in the system. Because the potential exists for a tremendous amount of data and programs to be involved in your Year 2000 transition, any change to an existing program in the system can have a snowballing or cascading effect on other areas in the system. A change that introduces new data or parameters, or an incorrectly implemented change can cause a problem in previously tested parts of the
56
system, simply because of the way data can be shared between software entities. Regardless of how an error was introduced or propagated, regression testing needs to be conducted to retest even unchanged parts or programs of the system. Normally, tests that have been previously run are reused to ensure that the same results are achieved. In most cases, regression testing is automated because the test cases and the results are already known.
11.2.3 Error Handling Testing

A normal error-handling cycle is an iterative process that either prevents errors from occurring, or recognizes and corrects errors that have occurred. Error-handling testing is necessary to determine the ability of the system to properly process incorrect transactions that can be reasonably expected as types of error conditions. For example, programs that accept only the four-digit year data entry format need to provide error messages for data entry in two-digit year format, and vice versa for programs that accept only two-digit year data entry format. When changing from two-digit year format to four-digit year format, you need to apply error handling testing to verify the appropriate error handling functions.
11.2.4 Manual Support Testing

Apply manual support testing to evaluate the adequacy of the processes used by people (end users) who must handle the new data generated from the automated applications with Year 2000 support. Types of data from these applications include data entry and report generation. Any new data format should be easy to understand and not ambiguous. This method includes testing the interfaces (for example, displays, procedures, operation manuals, and online help displays) between end users and the application program. End users should be trained and use procedures provided by the system personnel. Testing should be conducted without any other assistance.
11.2.5 Intersystem Testing

Applications are frequently connected with other applications to provide a higher or deeper level of functionality. Data may be shared between applications or systems. Multiple applications or systems may be involved in such an environment. This is the typical environment for Year 2000 projects. Intersystem testing is required to ensure that the connection functions properly between the applications. This test determines that the proper parameters and data are correctly passed between applications, and proper coordination and timing of each function exists between applications.
11.2.6 Parallel Testing

Parallel testing is used to determine whether the processing and results of a new version of an application are consistent with the processing and results of the previous version of the application. It should be applied when the old and new versions of the application are similar. For Year 2000 solutions without any major function redesign, this is the ideal technique. Parallel testing requires that the same input data be run through the two versions of the application. However, if the new application changes data formats, such as reformatting the year-date notation to four-digit format, you must modify the test input data before testing.
57
The efficiency and effectiveness of parallel processing is highly dependent on the degree of difficulty encountered in verifying output results and preparing common input. It may be difficult to automatically verify the results of processing by comparing the results on a tape or disk file. Some automated test tools or customized solutions can be used to prepare input and verify output more quickly.
11.3 How to Change Date and Time for Testing

By nature, Year 2000 exposures are time-sensitive and time-driven. Basic Year 2000 testing requires that you set the system date and time to a point where Year 2000 exposures can be detected and removed. Attention: Be cautious before resetting the system timer. Some system resources and functions are time-sensitive and may be activated or de-activated when you reset the system clock. Such effects can occur when you either set the system clock forward or backward. Without careful planning, you can cause the loss of these system resources and functions, some of which might prove difficult and time consuming to recover. Ensure that you do not contaminate your production system or production databases when running various test scenarios. Consider:

Providing a separate test system and storage device (or devices). Providing a separate set of test data.
The most vulnerable resources and functions subject to expiration include:

User IDs Passwords Data files and databases Authorization/protection Licences/services Network access Automation functions (as well as unexpected activation) Hierarchical storage management
You can change the system date and time as follows:
On the AS/400 system: Use the Change System Value (CHGSYSVAL) command with the QDATE parameter. For example, CHGSYSVAL QDATE( 101300) changes the system date to October 13, 2000, on a system using MMDDYY date formats (QDATFMT). To make sure all jobs on the AS/400 system are using this new date, you should switch off the power on the AS/400 system (PWRDWNSYS) and conduct your testing after the subsequent IPL. On a PC: Use a CMOS setup utility or execute the DATE command in DOS Version 3 Release 3 or later.
11.4 Basic Testing Scenarios

The scenarios for Year 2000 testing depend heavily on the system environment and applications. Some basic Year 2000 testing scenarios that are common for most installations are suggested here:
58
Set the clock to test process cycles and automatic functions that are activated on a regular basis. These scenarios can be used to identify Year 2000 exposures that need to be fixed as well as to validate programs after applying Year 2000 solutions. Daily Weekly Semi-monthly Monthly Bimonthly Quarterly Semi-annually Annual Automatic archiving Automatic restart/restore On demand
Test setting and displaying special dates, including: 1900/2/29 should fail, the year 1900 is not a leap year. 1996/2/29 should succeed, the year 1996 is a leap year. 2000/2/29 should succeed, the year 2000 is a leap year. 00/01/01 should display an unambiguous four-digit-year date, the value of which depends on the application (for example, 1900/01/01, 2000/01/01, and so on). 1999/12/31 should be able to distinguish between a regular end-of-year 1999 date and a special meaning date (for example, a never-expiring date indicator).
Test the processing of time-sensitive data with different combinations of data and time: 1. Use the current system clock and test data with dates: Before 2000/01/01 After 2000/01/01
2. Set the system clock before the year 2000 (for example, 1999/12/31) and test data with dates: Before 2000/01/01 After 2000/01/01
3. Set the system clock after 2000/01/01 and test data with dates: Before 2000/01/01 After 2000/01/01
11.4.1 Basic Scenarios to Test Your PC System Clock

Some older models of the PC may not have the capability to set or roll over the system clock beyond the year 2000 because the Basic Input/Output System (BIOS) is unaware of the century digits. Some suggested scenarios for testing for Year 2000-readiness of your PC system clock follow:
Test if the system clock can be set beyond the year 2000: 1. Set the system clock to 2000/01/01, 00:01:00. 2. Check the date.
59
3. If the date is set correctly, switch the power off, switch the power back on, and re-check the date.
Test the system clock automatic update function: 1. Test the system clock automatic update function when the power is on: a. Set the system clock to 1999/12/31, 23:58:00. b. Keep the power on. c. Wait until the clock reaches the year 2000. d. Check the date. e. If it is set correctly, switch the power off, and re-check the date. 2. Test the system clock automatic update function when the power is off: a. Set the system clock to 1999/12/31, 23:58:00. b. Switch the power off. c. Wait until the clock reaches the year 2000. d. Switch the power back on. e. Check the date.
Test the time update by the operating system: 1. Test the time update after suspension of a time-sensitive program: a. b. c. d. e. Set the system clock to 1999/12/31, 23:58:00. Suspend a time-display program without a wake-up timer. Keep the power on. Wait until the clock reaches the year 2000. Resume the time-display program and check the date.
2. Test the time update after suspension and wake-up of time-sensitive program: a. Set system clock to 1999/12/31, 23:58:00. b. Suspend a time-display program with the wake up timer set at 2000/01/01, 00:01:00. c. Keep the power on. d. Wait until the time display program wakes up . e. Check the date.
60
Chapter 12. Migration Consideration for Year 2000 Transition

To accomplish a successful migration and eliminate your current Year 2000 exposures, you need to follow a well-architected migration plan and prepare to execute that plan prior to actually performing the migration. This section provides an outline that you can use as a checklist of those steps that help you plan, prepare, and execute your migration. Note that some steps may not be necessary for your specific environment.
12.1 Plan for Migration

1. Plan for migration:

Determine the sequence of steps needed for migration. Review the migration procedures with your system administration staff and your end-user community. Determine the resources and time required for migration. Assign individuals or organizations to each migration step. Document the migration sequence and responsibilities. Develop a schedule for migration of the new system to reach production mode.
2. Examine all changed data that use new and changed date format:

Determine the source of the new data in the existing systems. Determine the data that can be converted automatically. Determine the data that must be converted manually.
3. Design bridges and interfaces among packages and reusable modules to maintain compatibility, if needed:

Design bridges and interfaces to application packages, if needed. Design bridges and interfaces to reusable application systems, if needed. Design bridges and interfaces to old systems that coexist with the new systems, if needed. Design tests for the verification and validation of these bridge facilities, if needed.
4. Design procedures for manual data conversion:

Update documents and procedures that are used for manual data entry. Determine checking mechanism for the accuracy and completeness of manually entered data. Design the new displays with new date format for manually entering new data and review with your end-user community. Design and update the software to load the manually prepared data into the new system. Run a rehearsal of the manual data entry and estimate the impact of the new data format on data entry time.
5. Design procedures for automated data conversion:

61
Design new software or use automated tools for automated data conversion. Determine a checking mechanism for the accuracy and completeness of automatically converted data. Design recovery procedures for conversion of data errors caused by missing data. Estimate the resources and time for automated data conversion.
6. Develop the data conversion systems:

Develop subsystems to convert existing data. Develop subsystems for entering new data. Develop bridges and interfaces to old systems that remain in production. Develop bridges and interfaces to application packages and reusable modules. Verify and validate the accuracy of the data conversion systems.
7. Plan the hardware installation for new system, if needed. 8. Plan for final system testing:

Determine the testing strategy. Develop the detailed test plan and schedule. Determine the types of tests to be conducted on the new system. Plan the testing environment: Design the migration tests for the systems and applications. Determine what testing software or tool (or tools) are used for each type of testing. Determine what testing libraries are used for each specific set of programs and data. Install the required testing software (for example, test data generator, test utilities, debugging utilities, and so on). Build test libraries and test data. Coordinate the testing with your development team and your system administration staff.
9. Documentation and training:

Update your corporate standard guideline . Update your technical documentation (for example, development guidelines and testing handbooks). Update the production procedures. Update the user documentation: Update the online documentation, including help displays, online manuals, computer-aided training, and so on. Test the online help and training aids with your end users to evaluate the acceptance of the new online information. Update all hardcopy documentation to reflect changes and review the documentation with your end users.
62
Plan and conduct training program to smooth the migration process.
12.2 Perform Migration

1. Update production procedures, if necessary. 2. Install the Year 2000-ready production system environment:

Coordinate with vendors for the hardware installation, if needed. Install the hardware of the new production system, if needed. Coordinate with system programmers and operators for the installation of the Year 2000-ready software. Install the Year.2000-ready system, vendor, and application software on the new production system.
3. Perform data conversion process:

Load existing data into the new system s databases. Execute the data conversion programs or automated tools for data conversion. Load manually-prepared data through data entry. Integrate the existing and converted data. Test the integrated data to verify data integrity.
4. Perform final system and migration testing:
Plan the sequence in which separately developed subsystems are tested and verified in reasonable combinations. Verify that the portions of the system that have no changes still runs properly as changes are made to other portions of the system. Verify that the program handles all of its transactions correctly and remains stable for a defined period of time. Verify that the system can accept input from, and provide output to other systems with which it interfaces as interfaces change. Verify end-user acceptance of the new system to certify the system as acceptable for production.
5. Activate the new system in production:

Switch the new system to production mode. Run the new system in parallel with the old system. Phase out the old system as the new system becomes stable.
6. Migration review:

Monitor and evaluate system performance, throughput, and reliability. Determine what system tuning is needed based on system status records. Track and evaluate user acceptance of the new system. Determine and document what system and application function enhancements are needed. Plan and schedule the system and application function enhancements.
Chapter 12. Migration Consideration for Year 2000 Transition
63
Coordinate system function enhancements with vendors. Design and develop required in-house application function enhancements. Determine when the system and application enhancements are applied. Apply the enhancements, once available, to the new system.
64
Chapter 13. Tool Categories and Available System Features to Ease Year 2000 Changes
With the critical time constraint of the Year 2000 challenge, customers require that Year 2000-ready applications are available shortly. In addition, customers demand Year 2000-ready applications of high quality and reasonable cost. It is not possible to achieve this without the use of powerful and productive tools. There are a variety of tools available from solution developers that can help you confront the software challenge of the 1999 to 2000 date change. To be effective and efficient in providing the ability to rapidly change programs and data to properly handle the year 2000, the tools must have certain characteristics. Some important tool characteristics and tool types that are necessary to make these changes are summarized in this chapter.
13.1 Tool Characteristics

The tools should provide necessary features such as:

Interactive environment Batch processing capability Graphic user interface Ease of use Rapid proto-typing Speedy and easy editing and updating Stepwise refinement Backward recovery
In addition, consider both the software development and deployment or target environment of the tools such as:
Platform Host only Workstation only PC only Client/server-based Cooperative processing with host LAN based
Prerequisite hardware (both minimum required and recommended for PC specification, if necessary) such as: Memory and storage required DASD needed for tool installation DASD needed for tool usage
Prerequisite software that is required and supported such as: Host operating system (for example, OS/400, Windows NT) PC/Workstation operating system (for example, DOS, Windows, OS/2) Network operating system (for example, NetWare, Banyan, Windows NT) Communication protocols (for example, TCP/IP, SNA, IPX, NetBIOS)
Languages supported or generated such as RPG and COBOL
65
Once you run the appropriate tools against your operating system to reformat Year 2000 exposures, be sure that the newly created system maintains its ability to:

Achieve good machine performance. Process a reasonably large number of users. Process reasonably large databases. Process high-traffic volumes. Provide networking access. Provide recovery from failures. Provide security. Provide audibility or accounting. Provide ease of maintenance.
13.2 Tool Categories

The following sections highlight some useful tool types for handling the Year 2000 challenge. A brief description is provided for each of the types. Most of these tools are used in normal proto-typing and application development. The tool types are categorized in the following sections.
13.2.1 Impact Analysis

To analyze the impact to your programs, you can use tools to:
Analyze complexity:
Determines the complexity of a software design or code using a metric such as fan-in/fan-out , degree of nesting, or other characteristics. These tools provide complexity analysis to allow you to estimate the effort required to change the date/time-related items in your source code.
Analyze impact:
Analyzes the program modules and related data to determine what is impacted and related. These tools are time efficient but do not always guarantee the accuracy of their analysis because they tend to over estimate what is affected. When an impact analysis tool indicates that some data is affected, it does not always mean that the data needs to be changed (such as to reformat the date-related data and programs for Year 2000 readiness).
Analyze metrics:
Collects, analyzes, and reports the results of metrics quantification and analysis activities. These tools can analyze and predict how much work, in quantification, is needed to reformat the date-related data and programs for the year 2000, based on a metrics or cost model. You must validate the accuracy of the metrics you intend to use, that is, its predictions against actual human performance in real-life situations.
Analyze database:
Investigates the structure and flow within a database to observe the characteristics of the database and determine if certain measurements and requirements can be realized (for example, analyze the year fields of the databases for any use and cross reference of two-digit years).
66
13.2.2 Project Management

To help manage the project, you can use tools to:
Inventory software:
Determines all code, JCL, databases, and other programs that constitute your system to provide a complete list for impact analysis. The list can be further divided into lists of sub-systems when partitioning and prioritization of the project is necessary.
Track changes:
Tracks and logs all requests for code and data changes. Requests are tracked through completion or resolution. Any inconsistent and missing changes of data or programs due to date format changes are minimized.
13.2.3 Program Level Analysis

To analyze programs and data at a program level, you can use tools to:
Analyze data flow:

Shows the flow of data among modules in procedures or programs. Determines if a data flow diagram is complete, consistent, and adheres to those rules established that govern flow. This provides both high-level and low-level views of data flow within the system, and is used to verify completeness of the program and data changes.
Diagram logic structure:

Diagrams how program modules call sub-modules, and what data and control information these program modules share. These tools display multiple program views.
Diagram data structure:

Diagrams the representation of appropriate parts of a data model as the structure is used by a database management systems structure and relational structures.
Diagram relationships:
Illustrates multiple relationships of a program module or data element at the same time. This is useful to understand how data is shared among the programs that have access to it.
Diagram decomposition:
Allows a high-level overview specification for a design or data model to be successfully decomposed into smaller entities for further observation and analysis. It facilitates the partitioning of a project that is too large to tackle all at once, such as the Year 2000.
Slice programs:
Allows you to view all of the code affecting a given variable or statement. Forward slicing starts with a name or statement, and indicates what that name or statement affects. Backward slicing starts with a name or statement, and indicates all of the parts of the program that can affect it.
Analyze logic:
Inspects the use of control logic within a program, determines if it is proper, and mechanizes the specified design. It is useful for verification and
67
validation of the correct manipulation of time when windowing techniques are used.
13.2.4 Code Editing and Restructuring

To help edit and restructure code for your programs, you can use tools to:
Power browse:
Allows you to scan and inspect code. Scanning can be switched between program (data) structure charts and code. These tools are more powerful than regular text editors. They can provide, for example, syntax checking, sophisticated capability to find data or information, or the ability to edit multiple programs. These types of tools can also include reverse engineering tools or maintenance workbench tools.
Find dates:
Locates date-oriented data, variables, declarations, comments, or other information in code for investigation of potential reformatting.
Comparison:
Compares two software programs, files, or data sets to identify commonalities and differences. It is extremely useful for the verification of program changes when date reformatting is done by simple field expansion.
Cross reference:
Lists where variables, procedures, or other items are located in the code. These tools speed up browsing and provide a limited form of impact analysis.
Expand fields:
Automatically expands two-digit year fields into four-digit year fields. It saves editing time tremendously and provides complete coverage of field expansion.
Analyze interfaces:
Determines if a range of variables in the programming interfaces is correct, as the variables are referenced across the reference boundaries. It can designate four-digit year format as a standard interface and enforce the standard in the programming interfaces.
Analyze standards and consistency:

Determines whether prescribed development standards have been followed. Identifies inconsistency in conventions used in requirements, designs, or programs. These tools can help you introduce standard or more uniform names to date-oriented fields or keywords, and improve the consistency and accuracy of data. These tools enforce consistent indentation and alignment.
Trace requirements:
Traces how the requirements are realized in the design and code.
Modularize code:
Generates modular code and top-down control flow. It reduces the scope of complex programs by creating separate modules. It also identifies routines that are frequently referenced or changed, for example, date/time services routines, and creates re-usable code libraries.
Standard date subroutine:
68
Creates reusable program modules that have correctly implemented date handling. These date subroutines can replace individually developed date subroutines to standardize the use of a date routine. These tools also reduce the chance of error and the cost of development, maintenance, and testing.
13.2.5 Code Generation

To generate code for your programs, you can use tools to:
Generate database code:

Generates database code directly from the data structure diagram.
Paint screen:
Generates code for the displays of a computer-user dialog or data entry when the displays need updating for reformatting the date.
Generate dialog:
Generates dialogs that conform to specified standards (for example, four-digit year input/output standard in any dialog).
Generate reports:
Generates code for the structure and layout of a report along with calculations of derived fields in the report.
Generate code:
Generates executable code from high-level specifications.
13.2.6 Automate Testing

To automate testing for your programs, you can use tools to:
Simulate:
Represents certain features or functions of the behavior of a physical or abstract system. One example of such a tool is a clock simulator that can change your system clock while being transparent to your programs. Tools such as these provide an easy way to quickly expose your programs to Year 2000 scenarios.
Analyze tests:
Determines the test case coverage on a set of programs being tested (whether a segment of code had been tested by other testing).
Generate test data:

Generates test data directly from a specification and facilitates a sequence of testing steps.
Test data libraries:

Organizes test data for use. These libraries are most useful in regression tests.
Test drivers
Automates testing by triggering test cases during testing. These tools often provide test input, execute the test cases, compare actual test output with expected results, and report test results.
69
13.3 IBM System Features for AS/400 System

You can use the IBM products and tools listed here to help you address the changes required as you proceed with your Year 2000 transition. The tools listed, however, represent only a subset of the AS/400 oriented offerings available to you for application development. A more complete list of available tools is available in the AS/400 Application Development Handbook , G325-6249.
13.3.1 The IBM RPG Family

For application code written in RPG, IBM has developed several RPG language compilers. These compilers target the host application development environment. IBM s RPG compilers for the AS/400 system are:

Integrated Language Environment (ILE) RPG IV Original Program Model (OPM) RPG/400 System/36 compatible compiler
All three RPG language compilers are available with either the Integrated Language Environment RPG for OS/400 Version 3 product (5716-RG1) or the IBM Integrated Language Environment RPG/400 Version 3 product (5763-RG1).
Using ILE RPG IV Date Support: The ILE RPG IV compiler has the following support for dates:
Retrieval of the job date through special words UDATE and UYEAR: this level of support provides for a two-digit year. Retrieval of the job date through special words *DATE and *YEAR: this level of support provides for a four-digit year. Retrieval of the system date through operation TIME: this level of support provides for both two-digit and four-digit years. Date, time, and time-stamp data type support: this level of support provides for date operations such as subtraction, addition, extraction, testing, comparison, and move. Calling OPM System APIs: this level of support provides for both two-digit and four-digit years. Calling ILE Date APIs: this level of support provides for both two-digit and four-digit years. SQL date, time, and time-stamp data type support: this level of support provides for four-digit years.
This section provides information on how to use RPG date, time, and time-stamp fields. Specifically, it covers:

The date-time data format types and their formats. User date special words. How to edit date-time fields. Date-time keywords. Date-time operations and how to use them.
70
13.3.1.1 Date-Time Data Types and Formats

Date, time, and time-stamp fields have an internal format that is independent of the external format. The internal format is the way the data is stored in the program. The external format is the way the data is stored in files. You need to be aware of the internal format when:

Passing parameters Overlaying subfields in data structures
There is a default internal format for date, time, and time-stamp fields. In general, to change the internal format for a specific field, you must define the field and specify its internal format on a definition specification. Similarly, to change (or specify) the external format for program-described fields, you specify the format on the corresponding input or output specification. For fields in an externally described file, the external data format is specified in the data description specifications in position 35. You cannot change the external format of externally described date-time format fields. For subfields in externally described data structures, the data formats specified in the external description are used as the internal formats of the subfields by the compiler. The reason for this difference is that a data structure, even if externally described, exists only when a program is running.
Internal Format: The default format for date, time, and time-stamp fields is *ISO. In general, it is recommended that you use the default ISO internal format, especially if you have a mixture of external format types.
For date, time, and time-stamp fields, you can change the default format in two ways. You can use the DATFMT and TIMFMT keywords on the control specification to change the default internal format, if desired, for all date-time fields in the program. In addition, you can use the definition specification to:
Override the default internal format by using the DATFMT and TIMFMT keywords. Specify an initial value for a date, time, or time-stamp field that is different than the default by using the INZ keyword.
Specifying an External Format for a Date-Time Field: If you have date, time, and time-stamp fields in program-described files, you must specify their external format. You can specify a default external format for all date, time, and time-stamp fields in a program-described file by using the DATFMT and TIMFMT keywords on a file description specification. You can specify an external format for a particular field as well. Specify the desired format in position 31 through position 34 on an input specification. Specify the appropriate keyword and format in position 53 through position 80 on an output specification.
For more information on each format type, see the appropriate section in the remainder of this chapter.
Date Data Type: Date fields have a predetermined size and format. They can be defined on the definition specification. Leading and trailing zeros are required for all date data.
Date constants or variables used in comparisons or assignments do not have to be in the same format or use the same separators. Also, dates used for I/O
71
operations such as input fields, output fields, or key fields are also converted (if required) to the necessary format for the operation. The default internal format for date variables is *ISO. This default internal format can be overridden globally by the control specification keyword DATFMT and individually by the definition specification keyword DATFMT. The hierarchy used when determining the internal date format and separator for a date field is: 1. From the DATFMT keyword specified on the definition specification. 2. From the DATFMT keyword specified on the control specification. 3. *ISO. There are two kinds of date data formats: two-digit and four-digit year formats. For two-digit year formats, years in the range of 1940 to 2039 can be represented. This leads to the possibility of a date overflow condition occurring when converting from a four-digit year format to a two-digit year format. The following table lists the formats for date data.
Table 1. Date Formats for Date Data Type
Format Name *MDY *DMY *YMD *JUL *ISO *USA *EUR *JIS Description Month/Day/Year Day/Month/Year Year/Month/Day Julian International Standards Organization IBM USA Standard IBM European Standard Japanese Industrial Standard Christian Era Format MM/DD/YY DD/MM/YY YY/MM/DD YY/DDD YYYY-MM-DD MM/DD/YYYY DD.MM.YYYY YYYY-MM-DD Length 8 8 8 6 10 10 10 10 Example 01/15/91 15/01/91 91/01/15 91/015 1991-01-15 01/15/1991 15.01.1991 1991-01-15
The following table lists the *LOVAL, *HIVAL, and default values for all the date formats.
Table 2. Date Values
Format Name *MDY *DMY *YMD *JUL *ISO *USA *EUR *JIS Description Month/Day/Year Day/Month/Year Year/Month/Day Julian International Standards Organization IBM USA Standard IBM European Standard Japanese Industrial Standard Christian Era *LOVAL 01/01/40 01/01/40 40/01/01 40/001 0001-01-01 01/01/0001 01.01.0001 0001-01-01 *HIVAL 12/31/39 31/12/39 39/12/31 39/365 9999-12-31 12/31/9999 31.12.9999 9999-12-31 Default Value 01/01/01 01/01/01 01/01/01 01/001 0001-01-01 01/01/0001 01.01.0001 0001-01-01
72
*CYMD Support: A three-digit year representation is also supported for fields used by the MOVE, MOVEL, and TEST operations only. This support is provided for compatibility with the system *CYMD format. The three-digit year format is:
*CYMD
where:

Century/Year/Month/Day
Cyymmdd
Valid separators are / - . , & (the blank separator). Valid values for C are 0 (the 20th century) or 1 (the 21st century). Valid values must fall between 040/01/01 to 139/12/31, where 040 represents the year 1940 and 139 represents the year 2039.
Time Data Type: Time fields have a predetermined size and format. They can be defined on the definition specification. Leading and trailing zeros are required for all time data.
Time constants or variables used in comparisons or assignments do not have to be in the same format or use the same separators. Also, times used for I/O operations such as input fields, output fields, or key fields are also converted (if required) to the necessary format for the operation. The default internal format for time variables is *ISO. This default internal format can be overridden globally by the control specification keyword TIMFMT and individually by the definition specification keyword TIMFMT. The hierarchy used when determining the internal time format and separator for a time field is: 1. From the TIMFMT keyword specified on the definition specification. 2. From the TIMFMT keyword specified on the control specification. 3. *ISO. The following table lists the formats for time data.
Table 3. Time Formats for Time Data Type
Format Name *HMS *ISO *USA Description Hours:Minutes:Seconds International Standards Organization IBM USA Standard. AM and PM can be any mix of upper and lower case. IBM European Standard Japanese Industrial Standard Christian Era Format HH:MM:SS HH.MM.SS HH:MM A M or HH:MM PM HH.MM.SS HH:MM:SS Length 8 8 8 Example 14:00:00 14.00.00 02:00 PM
*EUR *JIS
8 8
14.00.00 14:00:00
The following table lists the *LOVAL, *HIVAL, and default values for all of the time formats.
73
Table 4. Time Values

Format Name *HMS *ISO *USA *EUR *JIS Description Hours:Minutes:Seconds International Standards Organization IBM USA Standard. AM and PM can be any mix of upper and lower case. IBM European Standard Japanese Industrial Standard Christian Era *LOVAL 00:00:00 00.00.00 00:00 A M 00.00.00 00:00:00 *HIVAL 24:00:00 24.00.00 12:00 A M 24.00.00 24:00:00 Default Value 00:00:00 00.00.00 00:00 A M 00.00.00 00:00:00
Time-Stamp Data Type: Time-stamp fields have a predetermined size and format. They can be defined on the definition specification. Time-stamp data must be in the format:
yyyy-mm-dd-hh.mm.ss.mmmmmm (length 26).

Microseconds (.mmmmmm) are optional for time-stamp literals and if not provided, are padded on the right with zeros. Leading zeros are required for all time-stamp data. The default initialization value for a time-stamp is midnight of January 1, 0001 (0001-01-01-00.00.00.000000). The *HIVAL value for a time stamp is 9999-12-31-24.00.00.000000. Similarly, the *LOVAL value for a time stamp is 0001-01-01-00.00.00.000000.
13.3.1.2 User Date Special Words

The user date special words (UDATE, *DATE, UMONTH, *MONTH, UDAY, *DAY, UYEAR, and *YEAR) allow the programmer to supply a date for the program at run time. The user date special words access the job date that is specified in the job description. The user dates can be written out at output time; UDATE and *DATE can be written out using the Y edit code in the format specified by the control specification. (For a description of the job date, see the AS/400 Work Management Guide , SC41-4306.)
Rules for User Date: Remember the following rules when using the user date:
UDATE, when specified in position 30 through position 43 of the output specifications, prints a six-character numeric date field. *DATE, when similarly specified, prints an eight-character (four-digit year portion) numeric date field. These special words can be used in three different date formats: Month/day/year Year/month/day Day/month/year Use the DATEDIT keyword on the control specification to specify the editing to be done. If this keyword is not specified, the default is *MDY.
For an interactive program, the user date special words are set when the job starts running. For a batch program, they are set when the job is sent to the job queue. In neither case are they updated when the program runs over midnight or when the job date changes. Use the TIME operation code to obtain the time and date while the program is running. UMONTH, *MONTH, UDAY, *DAY, and UYEAR specified in position 30 through position 43 of the output specifications print a two-position numeric date field. *YEAR can be used to print a four-position numeric date field. Use
74
UMONTH or *MONTH to print the month only, UDAY or *DAY to print the day only, and UYEAR or *YEAR to print the year only.
UDATE and *DATE can be edited when they are written if the Y edit code is specified in position 44 of the output specifications. The DATEDIT keyword on the control specification determines the format and the separator character to be inserted (for example, 12/31/88, 31.12.88., 12/31/1988). UMONTH, *MONTH, UDAY, *DAY, UYEAR and *YEAR cannot be edited by the Y edit code in position 44 of the output specifications. The user date fields cannot be modified. This means they cannot be used: In the result field of calculations As factor 1 of PARM operations As the factor 2 index of LOOKUP operations With blank after in output specifications As input fields
The user date special words can be used in factor 1 or factor 2 of the calculation specifications for operation codes that use numeric fields. User date fields are not date data type fields but are numeric fields.
13.3.1.3 Editing Date Fields

The Y edit code is normally used to edit a three-digit to nine-digit date field. It suppresses the leftmost zeros of date fields, up to but not including the digit preceding the first separator. Slashes are inserted to separate the day, month, and year. The DATEDIT and DECEDIT keywords on the control specification can be used to alter edit formats. Note: The Y edit code is not valid for *YEAR, *MONTH, and *DAY. The Z edit code removes the sign (plus or minus) from and suppresses the leading zeros of a numeric field. The decimal point is not placed in the field and is not printed. The Y edit code suppresses the leftmost zeros of date fields, up to but not including the digit preceding the first separator. The Y edit code also inserts slashes (/) between the month, day, and year according to the following pattern:
nn/n nn/nn nn/nn/n nn/nn/nn nnn/nn/nn nn/nn/nnnn nnn/nn/nnnn nnnn/nn/nn nnnnn/nn/nn
Format Format Format Format
used used used used
with with with with
M, D M, D Y in Y in
or blank or blank position position
in position 19 in position 19 19 19
13.3.1.4 Date Operations

Date operations allow you to perform date and time arithmetic, extract portions of a date, time or time-stamp field, or test for valid fields. They operate on date, time and time-stamp fields, and character and numeric fields representing dates, times, and time stamps. The date operations are:

ADDDUR EXTRACT SUBDUR TEST

75
With ADDDUR, you can add a duration to a date or time. With SUBDUR, you can subtract a duration from a date or time, or calculate the duration between two dates, times, or time stamps. With EXRTRACT, you can extract part of a date, time, or time stamp. With TEST, you can test for a valid date, time, or time-stamp field. The valid duration codes (and their short forms) are:

*YEARS for the year (*Y) *MONTHS for the month (*M) *DAYS for the day (*D) *HOURS for the hours (*H) *MINUTES for the minutes (*MN) *SECONDS for the seconds (*S) *MSECONDS for the microseconds (*MS).
Adding or Subtracting Dates: When adding (or subtracting) a duration in months to (or from) a date, the general rule is that the month portion is increased (or decreased) by the number of months in the duration and the day portion is unchanged. The exception to this is when the resulting day portion exceeds the actual number of days in the resulting month. In this case, the resulting day portion is adjusted to the actual month end date.
For example, adding one month to 95/05/30 ( *YMD format) results in 95/06/30, as expected. The resulting month portion has been increased by 1; the day portion is unchanged. On the other hand, adding one month to 95/05/31 results in 95/06/30. The resulting month portion has been increased by 1 and the resulting day portion has been adjusted because June has only 30 days. Subtracting one month from 95/03/30 yields 95/02/28. In this case, the resulting month portion is decreased by 1 and the resulting day portion adjusted because February has only 28 days (in non-leap years). Similar results occur when adding or subtracting a year duration. For example, adding one year to 92/02/29 results in 93/02/28, an adjusted value since the resulting year is not a leap year.
Calculating Durations Between Dates: The SUBDUR operation can be used to calculate a duration by subtracting two dates, times, or time stamps. The result of the calculation is a complete unit; any rounding that is done is downwards. The calculation of durations includes microseconds.
For example, if the actual duration is 384 days, and the result is requested in years, the result is one complete year because there are 1.05 years in 384 days. A duration of 59 minutes requested in hours results in zero hours. Here are some additional examples.
Duration in between ============ ========== Months 1994-02-28 1994-03-15 1994-03-15 Years 1994-03-15 1994-03-31
and ============ 1994-03-28 1995-03-14 1995-03-15 1995-03-14 1995-03-31
is =========== 1 month 11 months 12 months 0 years 1 year
1970-03-14-23.00.00.000000 1970-03-14-22.00.00.000001 0 years Hours 1990-03-14-12.34.45.123456 1989-03-14-12.34.45.123457 0 years
76
Unexpected Results: If adjustment takes place on a date-time addition or subtraction, a subsequent duration calculation probably results in a different duration than the one originally added or subtracted. This is because the calculated duration no longer contains a complete unit, and so, rounding down yields one unit less than expected. This is shown in Example 1 and Example 2.
A second unexpected result can be seen in Example 3 and Example 4. Different initial dates give the same result after adding one month. When subtracting one month from the result, it is impossible to arrive at both initial dates.
1.
95/05/31 ADDDUR 1:*MONTH 95/06/30 SUBDUR 95/05/31
gives 95/06/30 gives zero months
You might expect the result of the SUBDUR to be one month. 2. 95/06/30 ADDDUR 1:*MONTH 95/07/30 SUBDUR 95/06/30 This is the expected result. 3. 95/01/31 ADDDUR 1:*MONTH 95/01/28 ADDDUR 1:*MONTH gives 95/02/28 gives 95/02/28 gives 95/07/30 gives one month
Two different dates yield the same date due to adjustment. 95/02/28 SUBDUR 1:*MONTH gives 95/01/28
Reversing the addition does not result in the original dates.
13.3.2 Using OPM RPG/400 Date Support

The OPM RPG 400 compiler has the following support for dates:
Retrieval of the job date through special words UDATE and UYEAR: this level of support provides for a two-digit year. Retrieval of the job date through special words *DATE and *YEAR: this level of support provides for a four-digit year. Retrieval of the system date through operation TIME: this level of support provides for both two-digit and four-digit years. Calling OPM System APIs: this level of support provides for both two-digit and four-digit years. SQL date, time, and time-stamp data type support: this level of support provides for four-digit years.
13.3.3 Using System/36 Compatible Date Support

The System/36 compatible compiler has the following support for dates:
Retrieval of the job date through special words UDATE and UYEAR: this level of support provides for a two-digit year. Retrieval of the system date through operation TIME: this level of support provides for a two-digit year. Calling OPM System APIs: this level of support provides for both two-digit and four-digit years.
77
13.3.4 The IBM COBOL Family for AS/400 System

For application code written in COBOL, IBM has developed several COBOL language compilers. These compilers target the host application development environment. IBM s COBOL compilers for the AS/400 system are:

Integrated Language Environment (ILE) COBOL/400 Original Program Model (OPM) COBOL/400 System/36 compatible COBOL compiler
All three COBOL language compilers are available with either the Integrated Language Environment COBOL for OS/400 Version 3 product (5716-CB1) or the IBM Integrated Language Environment COBOL/400 Version 3 product (5763-CB1).
13.3.4.1 Using COBOL Date Support

The COBOL ACCEPT statement is supported by the three compilers previously listed. This level of support provides for a two-digit year when referencing DATE or DAY. Calling OPM System APIs is supported by the three compilers previously listed. This level of support provides for both two-digit and four-digit years. The COBOL WHEN-COMPILED special register is supported in both the OPM and ILE COBOL/400 compilers. This level of support provides for a two-digit year. Calling ILE Date APIs is supported by the ILE COBOL/400 compiler. This level of support provides for both two-digit and four-digit years. SQL is supported by both the OPM and ILE COBOL compilers. This level of support provides for four-digit years.
13.3.5 The IBM C Family for AS/400 System

For application code based on C, IBM has developed language compilers for both C and C++. IBM s C based compilers for the AS/400 system are:

Integrated Language Environment (ILE) C for OS/400 VisualAge C++ for OS/400
13.3.5.1 Using C and C++ Date Support

The C library, available to both compilers, provides many functions related to date and time retrieval, manipulation, and formatting. This level of support provides for four-digit years. Calling OPM System APIs is supported by both compilers. This level of support provides for both two-digit and four-digit years. Calling ILE Date APIs is supported by both compilers. This level of support provides for both two-digit and four-digit years. SQL is supported by the ILE C for OS/400 compiler. This level of support provides for four-digit years.
78
13.3.6 Integrated Language Environment for OS/400

Integrated Language Environment (ILE) for OS/400 is IBM s common run-time environment for enterprise applications written in the ILE languages of RPG, COBOL, C, and CL. ILE is designed to provide defined calling conventions, enhanced inter-language communication, and callable services in areas such as date and time, math, storage management, and exception handling. ILE services are standard in OS/400 starting with Version 2 Release 3. ILE provides a number of date functions that include:
Ability to parse dates in an infinite number of formats by using a picture string as a parsing guide. Retrieve the current date. Convert a date character string to a Lilian (integer) format, thereby enabling easy date arithmetic operations. Convert a Lilian date to a date character string. Century sliding window.
The ILE century sliding window technique may provide a short term solution for some applications. If you are unable to change all of your applications and data at the same time, the century window allows two-digit years to be interpreted in a 100-year window. Any 100-year window can be selected. You pass a two-digit year to ILE and ILE returns a four-digit year based on the 100-year window. The advantage to the century window is that you need to change only the application code and not the databases with two-digit years. This allows you to change the application programs one at a time or groups at a time without affecting your databases. Note: This only works for dates that range less than 100 years. For example, dates of birth may not be appropriate for this solution.
13.3.7 DB2/400 SQL

DB2/400, a standard part of OS/400, provides the run-time support for SQL on the AS/400 system. SQL provides support for the database data types of date, time, and time stamp and operations such as add, subtract, assignment, and compare. The DB2 Query Manager and SQL Development Kit product (5716-ST1 or 5763-ST1) provides SQL pre-compilers for AS/400 programming languages such as RPG, C, and COBOL. SQL support provides for four-digit year support.
13.3.7.1 Using Date, Time, and Time-Stamp Support

Date, time, and time stamp are data types represented in an internal form not seen by the SQL user. Date, time, and time stamp can be represented by character string values and assigned to character string variables. The database manager recognizes the following as date, time, and time-stamp values:

A value returned by the DATE, TIME, or TIMESTAMP scalar functions. A value returned by the CURRENT DATE, CURRENT TIME, or CURRENT TIMESTAMP special registers. A character string when it is an operand of an arithmetic expression or a comparison and the other operand is a date, time, or time stamp. For example, in the predicate:
79
... WHERE HIREDATE < 1950 -01-01

if HIREDATE is a date column, the character string 1950 -01-01 is interpreted as a date.
A character string variable or constant used to set a date, time, or time-stamp column in either the SET clause of an UPDATE statement, or the VALUES clause of an INSERT statement.
For more information on character string formats of date, time, and time-stamp values, refer to DB2/400 SQL Reference , SC41-3612.
Specifying Current Date and Time Values: You can specify a current date, time, or time stamp in an expression by specifying one of three special registers: CURRENT DATE, CURRENT TIME, or CURRENT TIMESTAMP. The value of each is based on a time-of-day clock reading obtained during the running of the statement. Multiple references to CURRENT DATE, CURRENT TIME, or CURRENT TIMESTAMP within the same SQL statement use the same value. The following statement returns the age (in years) of each employee in the EMPLOYEE table when the statement is run:
SELECT YEAR(CURRENT DATE - BIRTHDATE) FROM CORPDATA.EMPLOYEE

The CURRENT TIMEZONE special register allows a local time to be converted to Universal Coordinated Time (UTC). For example, if you have a table named DATETIME containing a time column type with a name of STARTT, and you want to convert STARTT to UTC, you can use the following statement:
SELECT STARTT - CURRENT TIMEZONE FROM DATETIME

Date/Time Operands and Durations: Date/time values can be incremented, decremented, and subtracted. These operations may involve decimal numbers called durations . A duration is a positive or negative number representing an interval of time. There are four types of durations:
Labeled durations A labeled duration represents a specific unit of time as expressed by a number (which can be the result of an expression) followed by one of the seven duration keywords: YEARS, MONTHS, DAYS, HOURS, MINUTES, SECONDS, or MICROSECONDS. 3 The number specified is converted as if it were assigned to a DECIMAL(15,0) number. A labeled duration can only be used as an operand of an arithmetic operator in which the other operand is a value of data type DATE, TIME, or TIMESTAMP. Thus, the expression HIREDATE + 2 MONTHS + 14 DAYS is valid whereas the expression HIREDATE + (2 MONTHS + 14 DAYS) is not. In both of these expressions, the labeled durations are 2 MONTHS and 14 DAYS. Date duration A date duration represents a number of years, months, and days, expressed as a DECIMAL(8,0) number. To be properly interpreted, the number must have the format yyyymmdd , where yyyy represents the number of years, mm the number of months, and dd the number of days.
Note that the singular form of these keywords is also acceptable: YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, and MICROSECOND.
80
The result of subtracting one date value from another, as in the expression HIREDATE - BRTHDATE, is a date duration. Time duration A time duration represents a number of hours, minutes, and seconds, expressed as a DECIMAL(6,0) number. To be properly interpreted, the number must have the format hhmmss where hh represents the number of hours, mm the number of minutes, and ss the number of seconds. The result of subtracting one time value from another is a time duration. Time-stamp duration A time-stamp duration represents a number of years, months, days, hours, minutes, seconds, and microseconds, expressed as a DECIMAL(20,6) number. To be properly interpreted, the number must have the format yyyymmddhhmmsszzzzzz, where yyyy, mm, dd, hh, mm, ss, and zzzzzz represent, respectively, the number of years, months, days, hours, minutes, seconds, and microseconds. The result of subtracting one time-stamp value from another is a time-stamp duration.
Date/Time Arithmetic in SQL: performed on date/time values is the operand of addition, the rules governing the use of the
The only arithmetic operations that can be are addition and subtraction. If a date/time value other operand must be a duration. The specific addition operator with date/time values follow:
If one operand is a date, the other operand must be a date duration or labeled duration of years, months, or days. If one operand is a time, the other operand must be a time duration or a labeled duration of hours, minutes, or seconds. If one operand is a time stamp, the other operand must be a duration. Any type of duration is valid. Neither operand of the addition operator can be a parameter marker.
The rules for the use of the subtraction operator on date/time values are not the same as those for addition because a date/time value cannot be subtracted from a duration, and because the operation of subtracting two date/time values is not the same as the operation of subtracting a duration from a date/time value. The specific rules governing the use of the subtraction operator with date/time values follow:
If the first operand is a date, the second operand must be a date, a date duration, a string representation of a date, or a labeled duration of years, months, or days. If the second operand is a date, the first operand must be a date or a string representation of a date. If the first operand is a time, the second operand must be a time, a time duration, a string representation of a time, or a labeled duration of hours, minutes, or seconds. If the second operand is a time, the first operand must be a time or string representation of a time. If the first operand is a time stamp, the second operand must be a time stamp, a string representation of a time stamp, or a duration. If the second operand is a time stamp, the first operand must be a time stamp or a string representation of a time stamp.
81
Neither operand of the subtraction operator can be a parameter marker.
Date Arithmetic: Dates can be subtracted, incremented, or decremented. Subtracting Dates: The result of subtracting one date (DATE2) from another (DATE1) is a date duration that specifies the number of years, months, and days between the two dates. The data type of the result is DECIMAL(8,0). If DATE1 is greater than or equal to DATE2, DATE2 is subtracted from DATE1. If DATE1 is less than DATE2, however, DATE1 is subtracted from DATE2, and the sign of the result is made negative. The following procedural description clarifies the steps involved in the operation RESULT = DATE1 - DATE2.
If DAY(DATE2) <= DAY(DATE1) then DAY(RESULT) = DAY(DATE1) - DAY(DATE2). If DAY(DATE2) > DAY(DATE1) then DAY(RESULT) = N + DAY(DATE1) - DAY(DATE2) where N = the last day of MONTH(DATE2). MONTH(DATE2) is then incremented by 1. If MONTH(DATE2) <= MONTH(DATE1) then MONTH(RESULT) = MONTH(DATE1) - MONTH(DATE2). If MONTH(DATE2) > MONTH(DATE1) then MONTH(RESULT) = 12 + MONTH(DATE1) - MONTH(DATE2). YEAR(DATE2) is then incremented by 1. YEAR(RESULT) = YEAR(DATE1) - YEAR(DATE2). For example, the result of DATE( 3/15/2000 ) - DATE( 12/31/1999 ) is 215 (or, a duration of 0 years, 2 months, and 15 days).
Incrementing and Decrementing Dates: The result of adding a duration to a date or of subtracting a duration from a date is itself a date. (For the purposes of this operation, a month denotes the equivalent of a calendar page. Adding months to a date is the same as turning the pages of a calendar, starting with the page on which the date appears.) The result must fall between the dates January 1, 0001 and December 31, 9999 inclusive. If a duration of years is added or subtracted, only the year portion of the date is affected. The month is unchanged, as is the day unless the result is February 29 of a non-leap-year. In this case, the day is changed to 28, and SQLWARN6 in the SQLCA is set to W to indicate the end-of-month adjustment.
Similarly, if a duration of months is added or subtracted, only months and, if necessary, years are affected. The day portion of the date is unchanged unless the result is invalid (September 31, for example). In this case, the day is set to the last day of the month and SQLWARN6 in the SQLCA is set to W to indicate the end-of-month adjustment. Adding or subtracting a duration of days affects the day portion of the date, and potentially the month and year. Adding a labeled duration of DAYS does not cause an end-of-month adjustment. Date durations, whether positive or negative, may also be added to and subtracted from dates. As with labeled durations, the result is a valid date, and a warning indicator is set in the SQLCA whenever an end-of-month adjustment is necessary.
82
When a positive date duration is added to a date, or a negative date duration is subtracted from a date, the date is incremented by the specified number of years, months, and days in that order. Thus DATE1 + X, where X is a positive DECIMAL(8,0) number, is equivalent to the expression:
DATE1 + YEAR(X) YEARS + MONTH(X) MONTHS + DAY(X) DAYS

When a positive date duration is subtracted from a date, or a negative date duration is added to a date, the date is decremented by the specified number of days, months, and years in that order. Thus, DATE1 - X, where X is a positive DECIMAL(8,0) number, is equivalent to the expression:
DATE1 - DAY(X) DAYS - MONTH(X) MONTHS - YEAR(X) YEARS

When adding durations to dates, adding one month to a given date gives the same date one month later unless that date does not exist in the later month. In that case, the date is set to that of the last day of the later month. For example, January 28 plus one month gives February 28; and one month added to January 29, 30, or 31 results in either February 28 or, for a leap year, February 29. Note: If one or more months is added to a given date and then the same number of months is subtracted from the result, the final date is not necessarily the same as the original date.
Time Arithmetic: Times can be subtracted, incremented, or decremented. Subtracting Times: The result of subtracting one time (TIME2) from another (TIME1) is a time duration that specifies the number of hours, minutes, and seconds between the two times. The data type of the result is DECIMAL(6,0). If TIME1 is greater than or equal to TIME2, TIME2 is subtracted from TIME1. If TIME1 is less than TIME2, however, TIME1 is subtracted from TIME2, and the sign of the result is made negative. The following procedural description clarifies the steps involved in the operation RESULT = TIME1 - TIME2.
If SECOND(TIME2) <= SECOND(TIME1) then SECOND(RESULT) = SECOND(TIME1) - SECOND(TIME2). If SECOND(TIME2) > SECOND(TIME1) then SECOND(RESULT) = 60 + SECOND(TIME1) - SECOND(TIME2). MINUTE(TIME2) is then incremented by 1. If MINUTE(TIME2) <= MINUTE(TIME1) then MINUTE(RESULT) = MINUTE(TIME1) - MINUTE(TIME2). If MINUTE(TIME2) > MINUTE(TIME1) then MINUTE(RESULT) = 60 + MINUTE(TIME1) - MINUTE(TIME2). HOUR(TIME2) is then incremented by 1. HOUR(RESULT) = HOUR(TIME1) - HOUR(TIME2). For example, the result of TIME( 11:02:26 ) - TIME( 00:32:56 ) is 102930 (a duration of 10 hours, 29 minutes, and 30 seconds).
Incrementing and Decrementing Times: The result of adding a duration to a time, or of subtracting a duration from a time, is itself a time. Any overflow or underflow of hours is discarded, thereby ensuring that the result is always a time. If a duration of hours is added or subtracted, only the hours portion of the time is affected. The minutes and seconds are unchanged.
83
Similarly, if a duration of minutes is added or subtracted, only minutes and, if necessary, hours are affected. The seconds portion of the time is unchanged. Adding or subtracting a duration of seconds affects the seconds portion of the time, and potentially the minutes and hours. Time durations, whether positive or negative, are also added to and subtracted from times. The result is a time that has been incremented or decremented by the specified number of hours, minutes, and seconds in that order. TIME1 + X, where X is a DECIMAL(6,0) number, is equivalent to the expression:
TIME1 + HOUR(X) HOURS + MINUTE(X) MINUTES + SECOND(X) SECONDS

Time-Stamp Arithmetic: Time stamps can be subtracted, incremented, or decremented. Subtracting Time Stamps: The result of subtracting one time stamp (TS2) from another (TS1) is a time-stamp duration that specifies the number of years, months, days, hours, minutes, seconds, and microseconds between the two time stamps. The data type of the result is DECIMAL(20,6). If TS1 is greater than or equal to TS2, TS2 is subtracted from TS1. If TS1 is less than TS2, however, TS1 is subtracted from TS2 and the sign of the result is made negative. The following procedural description clarifies the steps involved in the operation RESULT = TS1 - TS2.
If MICROSECOND(TS2) <= MICROSECOND(TS1) then MICROSECOND(RESULT) = MICROSECOND(TS1) MICROSECOND(TS2). If MICROSECOND(TS2) > MICROSECOND(TS1) then MICROSECOND(RESULT) = 1000000 + MICROSECOND(TS1) - MICROSECOND(TS2) and SECOND(TS2) is incremented by 1. The seconds and minutes part of the time stamps are subtracted as specified in the rules for subtracting times. If HOUR(TS2) <= HOUR(TS1) then HOUR(RESULT) = HOUR(TS1) - HOUR(TS2). If HOUR(TS2) > HOUR(TS1) then HOUR(RESULT) = 24 + HOUR(TS1) - HOUR(TS2) and DAY(TS2) is incremented by 1. The date part of the time stamps is subtracted as specified in the rules for subtracting dates.
Incrementing and Decrementing Time Stamps: The result of adding a duration to a time stamp, or of subtracting a duration from a time stamp is itself a time stamp. Date and time arithmetic is performed as previously defined, except that an overflow or underflow of hours is carried into the date part of the result, which must be within the range of valid dates. Microseconds overflow into seconds.
84
13.3.8 OS/400 CL
The following sections show, in detail, the Year 2000 four-digit date support for selected OS/400 CL Commands.
13.3.8.1 CVTDAT (Convert Date)

The Convert Date (CVTDAT) command converts a date value from one format to another without changing its value. CVTDAT provides for both two-digit and four-digit year formats.
13.3.8.2 OPNQRYF (Open Query File)

The Open Query File (OPNQRYF) command opens a file that contains a set of database records that satisfies a database query request. OPNQRYF provides for both two-digit and four-digit years.
Date, Time, and Time-Stamp Comparisons Using the OPNQRYF Command: A date, time, or time-stamp value can be compared either with another value of the same data type or with a string representation of that data type. All comparisons are chronological, which means the farther a time is from January 1, 0001, the greater the value of that time.
Comparisons involving time values and string representations of time values always include seconds. If the string representation omits seconds, zero seconds are implied. Comparisons involving time-stamp values are chronological without regard to representations that might be considered equivalent. Thus, the following predicate is true:
TIMESTAMP(1990 -02-23-00.00.00) > TIMESTAMP(1990 -02-22-24.00.00 )
When a character, DBCS-open, or DBCS-either field or constant is represented as a date, time, or time stamp, the following rules apply: Date: The length of the field or literal must be at least eight if the date format is *ISO, *USA, *EUR, *JIS, *YMD, *MDY, or *DMY. If the date format is *JUL (yyddd), the length of the variable must be at least six (includes the separator between yy and ddd). The field or literal may be padded with blanks. Time: For all of the time formats (*USA, *ISO, *EUR, *JIS, *HMS), the length of the field or literal must be at least four. The field or literal may be padded with blanks. Time stamp: For the time-stamp format (yyyy-mm-dd-hh.mm.ss.uuuuuu), the length of the field or literal must be at least 16. The field or literal may be padded with blanks.
Date, Time, and Time-Stamp Arithmetic Using OPNQRYF CL Command: Date, time, and time-stamp values can be incremented, decremented, and subtracted. These operations may involve decimal numbers called durations . The following definition shows durations and a specification of the rules for performing arithmetic operations on date, time, and time-stamp values. Durations: A duration is a number representing an interval of time. The four types of durations are:
Labeled Duration
85
A labeled duration represents a specific unit of time as expressed by a number (which can be the result of an expression) used as an operand for one of the seven duration built-in functions: %DURYEAR, %DURMONTH, %DURDAY, %DURHOUR, %DURMINUTE, %DURSEC, or %DURMICSEC. The functions are for the duration of year, month, day, hour, minute, second, and microsecond respectively. The number specified is converted as if it was assigned to a DECIMAL(15,0) number. A labeled duration can only be used as an operand of an arithmetic operator when the other operand is a value of data type *DATE, *TIME, or *TIMESTP. Thus, the expression HIREDATE + %DURMONTH(2) + %DURDAY(14) is valid, whereas the expression HIREDATE + (%DURMONTH(2) + %DURDAY(14)) is not. In both of these expressions, the labeled durations are %DURMONTH(2) and %DURDAY(14). Date Duration A date duration represents a number of years, months, and days expressed as a DECIMAL(8,0) number. To be properly interpreted, the number must have the format yyyymmdd , where yyyy represents the number of years, mm the number of months, and dd the number of days. The result of subtracting one date value from another, as in the expression HIREDATE - BRTHDATE, is a date duration. Time Duration A time duration represents a number of hours, minutes, and seconds expressed as a DECIMAL(6,0) number. To be properly interpreted, the number must have the format hhmmss , where hh represents the number of hours, mm the number of minutes, and ss the number of seconds. The result of subtracting one time value from another is a time duration. Time-stamp Duration A time-stamp duration represents a number of years, months, days, hours, minutes, seconds, and microseconds expressed as a DECIMAL(20,6) number. To be properly interpreted, the number must have the format yyyymmddhhmmsszzzzzz, where yyyy, mm, dd, hh, mm, ss, and zzzzzz represent, respectively, the number of years, months, days, hours, minutes, seconds, and microseconds. The result of subtracting one time-stamp value from another is a time-stamp duration.
Rules for Date, Time, and Time-Stamp Arithmetic: The only arithmetic operations that can be performed on date and time values are addition and subtraction. If a date or time value is the operand of addition, the other operand must be a duration. The specific rules governing the use of the addition operator with date and time values follow:
If one operand is a date, the other operand must be a date duration or a labeled duration of years, months, or days. If one operand is a time, the other operand must be a time duration or a labeled duration of hours, minutes, or seconds. If one operand is a time stamp, the other operand must be a duration. Any type of duration is valid.
The rules for the use of the subtraction operator on date and time values are not the same as those for addition because a date or time value cannot be subtracted from a duration, and because the operation of subtracting two date
86
and time values is not the same as the operation of subtracting a duration from a date or time value. The specific rules governing the use of the subtraction operator with date and time values follow:
If the first operand is a date, the second operand must be a date, a date duration, a string representation of a date, or a labeled duration of years, months, or days. If the second operand is a date, the first operand must be a date or a string representation of a date. If the first operand is a time, the second operand must be a time, a time duration, a string representation of a time, or a labeled duration of hours, minutes, or seconds. If the second operand is a time, the first operand must be a time or string representation of a time. If the first operand is a time stamp, the second operand must be a time stamp, a string representation of a time stamp, or a duration. If the second operand is a time stamp, the first operand must be a time stamp or a string representation of a time stamp.
Date Arithmetic: Dates can be subtracted, incremented, or decremented. Subtracting Dates: The result of subtracting one date (DATE2) from another (DATE1) is a date duration that specifies the number of years, months, and days between the two dates. The data type of the result is DECIMAL(8,0). If DATE1 is greater than or equal to DATE2, DATE2 is subtracted from DATE1. If DATE1 is less than DATE2, however, DATE1 is subtracted from DATE2, and the sign of the result is made negative. The following procedural description clarifies the steps involved in the operation RESULT = DATE1 - DATE2.
If %DAY(DATE2) <= %DAY(DATE1) then %DAY(RESULT) = %DAY(DATE1) - %DAY(DATE2). If %DAY(DATE2) > %DAY(DATE1) then %DAY(RESULT) = N + %DAY(DATE1) - %DAY(DATE2) where N = the last day of %MONTH(DATE2). %MONTH(DATE2) is then incremented by 1. If %MONTH(DATE2) <= %MONTH(DATE1) then %MONTH(RESULT) = %MONTH(DATE1) - %MONTH(DATE2). If %MONTH(DATE2) > %MONTH(DATE1) then %MONTH(RESULT) = 12 + %MONTH(DATE1) %MONTH(DATE2). %YEAR(DATE2) is then incremented by 1. %YEAR(RESULT) = %YEAR(DATE1) - %YEAR(DATE2). For example, the result of %DATE( 3/15/2000 ) - %DATE( 12/31/1999 ) is 215 (or, a duration of 0 years, 2 months, and 15 days).
Incrementing and Decrementing Dates: The result of adding a duration to a date, or of subtracting a duration from a date, is itself a date. (For the purposes of this operation, a month denotes the equivalent of a calendar page. Adding months to a date is the same as turning the pages of a calendar, starting with the page on which the date appears.) The result must fall between the dates January 1, 0001, and December 31, 9999, inclusive. If a duration of years is added or
87
subtracted, only the year portion of the date is affected. The month is unchanged, as is the day unless the result is February 29 of a year that is not a leap year. In this case, the day is changed to 28. Similarly, if a duration of months is added or subtracted, only months and, if necessary, years are affected. The day portion of the date is unchanged unless the result is not valid (September 31, for example). In this case, the day is set to the last day of the month. Adding or subtracting a duration of days affects the day portion of the date, and potentially the month and year. Date durations, whether positive or negative, may also be added to and subtracted from dates. As with labeled durations, the result is a valid date. When a positive date duration is added to a date, or a negative date duration is subtracted from a date, the date is incremented by the specified number of years, months, and days in that order. Thus, DATE1 + X, where X is a positive DECIMAL(8,0) number, is equivalent to the expression:
DATE1 + %DURYEAR(%YEAR(X)) + %DURMONTH(%MONTH(X)) + %DURDAY(%DAY(X))

When a positive date duration is subtracted from a date, or a negative date duration is added to a date, the date is decremented by the specified number of days, months, and years in that order. Thus, DATE1 - X, where X is a positive DECIMAL(8,0) number, is equivalent to the expression:
DATE1 - %DURDAY(%DAY(X)) - %DURMONTH(%MONTH(X)) - %DURYEAR(%YEAR(X))

When adding durations to dates, adding one month to a given date gives the same date one month later unless that date does not exist in the later month. In that case, the date is set to that of the last day of the later month. For example, January 28 plus one month gives February 28; and one month added to January 29, 30, or 31 results in either February 28 or, for a leap year, February 29. Note: If one or more months are added to a given date and the same number of months is subtracted from the result, the final date is not necessarily the same as the original date.
Time Arithmetic: Times can be subtracted, incremented, or decremented. Subtracting Times: The result of subtracting one time (TIME2) from another (TIME1) is a time duration that specifies the number of hours, minutes, and seconds between the two times. The data type of the result is DECIMAL(6,0). If TIME1 is greater than or equal to TIME2, TIME2 is subtracted from TIME1. If TIME1 is less than TIME2, however, TIME1 is subtracted from TIME2, and the sign of the result is made negative. The following procedural description clarifies the steps involved in the operation RESULT = TIME1 - TIME2.
If %SECOND(TIME2) <= %SECOND(TIME1) then %SECOND(RESULT) = %SECOND(TIME1) - %SECOND(TIME2). If %SECOND(TIME2) > %SECOND(TIME1) then %SECOND(RESULT) = 60 + %SECOND(TIME1) %SECOND(TIME2). %MINUTE(TIME2) is then incremented by 1. If %MINUTE(TIME2) <= %MINUTE(TIME1) then %MINUTE(RESULT) = %MINUTE(TIME1) - %MINUTE(TIME2).
88
If %MINUTE(TIME2) > %MINUTE(TIME1) then %MINUTE(RESULT) = 60 + %MINUTE(TIME1) - %MINUTE(TIME2). %HOUR(TIME2) is then incremented by 1. %HOUR(RESULT) = %HOUR(TIME1) - %HOUR(TIME2). For example, the result of %TIME( 11:02:26 ) - %TIME( 00:32:56 ) is 102930 (a duration of 10 hours, 29 minutes, and 30 seconds).
Incrementing and Decrementing Times: The result of adding a duration to a time or of subtracting a duration from a time is itself a time. Any overflow or underflow of hours is discarded, thereby ensuring that the result is always a time. If a duration of hours is added or subtracted, only the hours portion of the time is affected. The minutes and seconds are unchanged.
Similarly, if a duration of minutes is added or subtracted, only minutes and, if necessary, hours are affected. The seconds portion of the time is unchanged. Adding or subtracting a duration of seconds affects the seconds portion of the time, and potentially, the minutes and hours. Time durations, whether positive or negative, also can be added to and subtracted from times. The result is a time that has been incremented or decremented by the specified number of hours, minutes, and seconds in that order. TIME1 + X, where X is a DECIMAL(6,0) number, is equivalent to the expression:
TIME1 + %DURHOUR(%HOUR(X)) + %DURMINUTE(%MINUTE(X)) + %DURSEC(%SECOND(X))

Time-Stamp Arithmetic: Time stamps can be subtracted, incremented, or decremented. Subtracting Time Stamps: The result of subtracting one time stamp (TS2) from another (TS1) is a time-stamp duration that specifies the number of years, months, days, hours, minutes, seconds, and microseconds between the two time stamps. The data type of the result is DECIMAL(20,6). If TS1 is greater than or equal to TS2, TS2 is subtracted from TS1. If TS1 is less than TS2, however, TS1 is subtracted from TS2 and the sign of the result is made negative. The following procedural description clarifies the steps involved in the operation RESULT = TS1 - TS2:
If %MICSEC(TS2) <= %MICSEC(TS1) then %MICSEC(RESULT) = %MICSEC(TS1) %MICSEC(TS2). If %MICSEC(TS2) > %MICSEC(TS1) then %MICSEC(RESULT) = 1000000 + %MICSEC(TS1) - %MICSEC(TS2) and %SECOND(TS2) is incremented by 1. The seconds and minutes part of the time stamps are subtracted as specified in the rules for subtracting times: If %HOUR(TS2) <= %HOUR(TS1) then %HOUR(RESULT) = %HOUR(TS1) - %HOUR(TS2). If %HOUR(TS2) > %HOUR(TS1) then %HOUR(RESULT) = 24 + %HOUR(TS1) - %HOUR(TS2) and %DAY(TS2) is incremented by 1.
89
The date part of the time stamp is subtracted as specified in the rules for subtracting dates.
Incrementing and Decrementing Time Stamps: The result of adding a duration to a time stamp or of subtracting a duration from a time stamp is itself a time stamp. Date and time arithmetic is performed as previously defined, except that an overflow or underflow of hours is carried into the date part of the result, which must be within the range of valid dates. Microseconds overflow into seconds.
13.3.9 Application Dictionary Services/400

IBM Application Dictionary Services/400 is a host-based, integrated impact analysis tool to improve programmer productivity and application quality during application development and maintenance. The product is a feature of the Application Development ToolSet/400 and is integrated with such tools as Source Entry Utility (SEU), Screen Design Aid (SDA), and Data File Utility (DFU). It is fully menu-driven, simple to learn and has virtually no learning curve for experienced AS/400 programmers. Application Dictionary Services provides the ability to place a dictionary or a cross-referencing index over data and programs. When programmers want to make a change to an application program, they use the dictionary to determine the effect that change has on other programs, files, and data. A programmer is saved from manually performing the tedious and error-prone work of looking for these relationships. This, coupled with the Application Dictionary Services mass compile feature, can improve the quality of applications and decrease the amount of time programmers spend maintaining existing code. With the pervasiveness of date information in many applications, this impact analysis and mass compile capability can simplify your transition to a Year 2000-ready application base.
13.3.10 Application Development Manager/400

IBM Application Development Manager/400 is a host-based change management tool that provides application developers with a development environment to effectively and efficiently manage application development and maintenance. The product is integrated with the AS/400 Product Development Manager (PDM) and is a feature of Application Development ToolSet/400. It can be used either from the PDM menu, or by typing the Control Language (CL) commands on the command line. Application Development Manager provides a discipline to better control the development and maintenance environment. It forces the project leader to define the application environment, outlining the different stages of application (production, test, or fix) and the roles of each developer. The developers work in a well-organized environment, which in turn, leads to increased productivity. Through its version control facility, it allows the creating and managing of several versions of the same applications with less disk utilization and the audit trail feature keeps a log of all changes made to an application, allowing better monitoring of the application.
90
With the pervasiveness of date information in many applications, this change management tool can simplify your transition to a Year 2000 safe application base.
91
92
Part 4. External Application Modernization

This part looks at the possibilities of modernizing applications externally, that is,. changing the look and feel of the user interface. Two altenatives to modernize your applications are provided, using a Graphical User Interface (GUI) and using the products available to move existing RPG applications to a client/server environment. It includes:

Chapter 14, GUI/400 Chapter 15, Using VRPG Client/2 to Create Modern Applications
93
94
Chapter 14. GUI/400

As AS/400 application portfolios are managed into the 21st century, some applications are retired, some are completely rewritten, and others are modernized and enhanced using approaches such as GUI/400. Here is an overview of using a product such as GUI/400 to enhance your application with minimal programming.
14.1 What Are The Benefits of This Approach?

One of the most important benefits of GUI/400 is that the return on investment from certain existing applications can be extended. From an implementation perspective, the key benefits of the GUI/400 approach are speed and reliability. Modernization and enhancement can be delivered quickly and, because the underlying application is not modified, testing requirements are eliminated. The development resources normally required to debug fundamental code changes and to engineer systems turnover can be assigned to other projects. From a user perspective, the speed of delivery means that changes in business operations or emerging windows of business opportunity can be quickly reflected in applications. In addition, users experience the intrinsic benefits of a graphical user interface: Ease of use: Most people find graphical user interfaces more intuitive and easy to use than character-based interfaces. Speedy training : Because they are intuitive, GUI interfaces are easier to learn. With windows, toolbars, and push buttons, users can navigate through applications without having to learn and memorize special codes. And most users are already familiar with using a GUI, so they quickly adapt those skills to each new application that they interact with. Workflow improvement : GUI/400 developers can design workflow improvements into the GUI clients that they build. Here is a real-world example: Entering an order into an enterprise-scale accounting system requires a clerk to navigate through 14 displays. Much of the information on those displays is not relevant to the order-entry process. With GUI/400, this process is reduced to a smaller number of displays, and only the relevant information is requested. Instead of tabbing through 150 data items, the user enters 22 data items, and does so in a user-friendly, graphical environment. Improved productivity : All of the benefits described here result in improved user productivity. This can translate into higher throughput with existing resources, or cost reduction because fewer resources are required to do a job.
95
User satisfaction : When applications are reliable, easy to learn, and easy to use, user satisfaction is enhanced. GUIs are more fun to use than character-based interfaces, and GUI users perceive their systems to be state-of-the art. For many existing AS/400 applications, the addition of a GUI client is a robust and timely answer to the challenges of supporting users into the 21st century. This option can be implemented as a simple modernization, or expanded to encompass desktop integration and enhancement.
14.2 Building a GUI Client for an Existing AS/400 Application

It is a simple and fast process to build a GUI client for an existing AS/400 application using GUI/400. For building GUI windows out of an existing application, the project follows these standard steps: 1. Install the Collector software on a PC connected to the AS/400 system. The Collector software is provided on one diskette and requires Client Access/400 or PC Support/400. 2. Run the Collector against the existing AS/400 application. Running the collector takes only seconds. The Collector captures detailed display information and creates an AWHOST file, which is in ASCII text format. The Collector performs the capture automatically (it does not require human intervention to run nor does it require running the application). The AWHOST file is transferred to a PC. 3. Using GUI/400 ADK (the developer s kit), a picture album is automatically created containing all of the green-screens in the application, and each of the green-screens is uniquely identified. This takes about 10 seconds. The Best Guess panels are automatically created by GUI/400 ADK in less than one minute. At this point, over 80% of the job is complete. 4. The next step is the final customization to correctly position and refine push buttons, fields, and list boxes; to rename or reformat fields; and to add graphics where necessary or desirable. In this application, certain information that is presented as raw data is now presented in graphical format. 5. The new GUI windows are compiled into an .AWR file and installed in the GUI/400 directory on the machine where the AS/400 connection is established. Total elapsed time for this project from receipt of the AWHOST file is under two hours. 6. Each PC-based user of the GUI-enhanced application now installs GUI/400 RTS Pro on their PC. When they initiate the AS/400 application, the GUI windows are shown instead of the green-screens . Performance of the underlying AS/400 application is not affected by GUI/400. Windows are presented to OS/2 users or to Windows users (GUI/400 supports both environments). In addition to the application modernization previously described, GUI/400 also enables desktop integration and enhancement. For example, using GUI/400, the developer can integrate this Order Entry application with an imaging application that shows a picture of the item that is being ordered. Or using GUI/400 s scripting capability, the developer can enhance the existing application with a function that automatically sends an order confirmation to the customer through
96
e-mail. In either of these examples, the underlying AS/400 application code is not modified in any way.
Figure 8. GUI/400 Sample Window
A sample GUI/400 window is shown in Figure 8. This is much more appealing than the original 5250 green screen .
Chapter 14. GUI/400
97
98
Chapter 15. Using VRPG Client/2 to Create Modern Applications

This chapter shows how VRPG can be used as a tool to modernize applications while protecting the RPG skills of your programmers. The result is a move to client/server computing.
15.1 VRPG as a Tool for Modernization

In order to address the question of whether VRPG is a tool that can be used to modernize applications, let s first understand what VRPG is. VRPG is a programming language, a development environment, and a run-time environment that allows you to develop application systems on a PC. You can code, compile, test, and run applications on the PC itself. This results in a reduction in the developer workload on an AS/400 system, and allows more resources to be available for other AS/400 users. As VRPG runs on a PC, it also gives a user the opportunity to be mobile , but is limited by things such as:

The size and portability of the PC itself The physical method for communicating and accessing data on an AS/400 system. It is possible to build VRPG applications that access only PC files, and hence, connection to an AS/400 system is not required (except at the time when installing VRPG).
VRPG can establish a true client/server relationship with the AS/400 system when access is required to AS/400 data. VRPG programs execute on the PC, and if they need to access AS/400 database information, VRPG does this seamlessly, just as if the program was running natively on the AS/400 system. A connection to the AS/400 system is required for this to take place (for example, token-ring), and this can be easily configured using VRPG pull-down menus. Applications developed using VRPG have a Graphical User Interface (GUI) and have a PC look-and-feel about them. Applications can utilize a mouse to point to parts on the window, and users can enjoy using a much more user friendly interface than the typical legacy systems that use the more traditional green-screen approach. The VRPG language is based on RPG (RPG IV), allowing programming staff to utilize their current RPG skills when moving to this new environment. The skills transition for the programming staff is much easier compared to other alternatives available today. Furthermore, the company s investment in the technical staff s RPG skills is protected. The preceding issues are all issues that application developers face in developing modern applications. As we move towards the 21st century, users will demand better applications and interfaces. VRPG is, therefore, a good choice as a tool for modernizing applications. It allows you to:

Run applications on your PC. Develop client/server applications. Give users GUI applications that are easy to use.
99
Easy to use for programmers to adopt as they can utilize their current RPG skills.
15.2 Familiarization with VRPG

Applications are developed using OS/2 as the base platform with the current version of VRPG. Once the application is developed, it can run on an OS/2 platform, or it can be ported so that it can run on a Windows 3.1 platform. The OS/400 releases that were current at the time of writing this manual were V3R1 or V3R6. Product numbers are 5763-VR1 on V3R1 and 5716-CL1 (Feature S2) on V3R6. The two versions are functionally the same, the only difference is the directory structure. VRPG can be installed in one of three ways:

From CD From a LAN server drive From client access shared folders
Detailed installation instructions and information on prerequisite products can be found in Installing Application Development ToolSet Client Server for OS/400 , SC09-2188-00.
15.3 Documentation for VRPG

With VRPG, considerable effort has been made to give information to the application developer during the application development process. For example, if you are unsure of the syntax of the EVAL operation code in VRPG, you simply type in the EVAL operation code (while editing the program source code), and press the Help key. A Help window is displayed with an explanation of the EVAL operation code. This is a much easier approach than the traditional way of doing things where the programmer had to turn away from the display, find the appropriate manual, then figure out what to look for in the index, and finally turn to the correct page. Furthermore, it is not unusual to find hypertext links in the online information being read. If we use the EVAL operation code example again, there are working examples available in hypertext that further explain the use of the EVAL operation code. This online information is taken from the following five manuals:
Installing Application Development ToolSet Client Server for OS/400 , SC09-2188-00 Client/Server Visual Programming with VRPG Client for OS/2 , SC09-2131-01 VRPG Client for OS/2 Parts Reference , SC09-1846-01 VRPG Client for OS/2 Language Reference , SC09-1847-01 Getting Started with VRPG Client for OS/2 , SC09-2195-00
100
15.4 Converting Legacy RPG Code to VRPG

Perhaps one of the most frequently asked questions when people consider using VRPG to develop their applications is, Can I convert my existing RPG applications to VRPG ? The answer to this question is yes . However, simply answering yes is an injustice to the person asking the question as there are a number of points that should be considered. For example, is it better to take the opportunity to rewrite the application system from scratch? Although the remainder of this chapter is aimed at helping the application developer to convert RPG code to VRPG, it should be made clear that sometimes it may be better to rewrite the applications. Each situation is different and should be decided based on its merits. It is worth mentioning a few points that may be considered in such a situation. The following sections are offered as a starting point.
15.4.1 Advantages in Converting RPG Applications to VRPG

There is investment protection in your current application code. Users are already familiar with the way the current applications work. It allows your programming staff the opportunity to develop their skills in application development using VRPG before embarking on the development of a new application system using VRPG.
15.4.2 Disadvantages in Converting RPG applications to VRPG
Legacy code has typically not taken advantage of some of the more modern application development techniques. Legacy code is (typically) full of stop-gap fixes that makes it nearly impossible to understand. It is cumbersome to operate a program in VRPG that has just been migrated to work exactly the same as it did in RPG (for example, typing a D in a subfile line to indicate that the line should be deleted).
15.4.3 Other Considerations

There are other issues that should be considered such as:
Do you have a legal right to the source code for the application system, and do you have the necessary support if you migrate it to VRPG? Is there any documentation for application systems planning to migrate to VRPG? Do you have the source for all of the programs in the application? If you have multiple versions of the source, can you reliably identify which is the current version?
This list is not intended to be a complete list of the things that should be considered. However, the answers to some of the preceding questions help to lead you in the right direction as to whether it is practical to consider converting a given RPG application to VRPG.
101
The remainder of this chapter concentrates on helping application developers migrate existing RPG applications to VRPG. For demonstration purposes, a sample RPG III has been included in Appendix C, RPG/400 Order Entry Program on page 169. A listing of the final VRPG program is included in Appendix E, VRPG Order Entry Program on page 209.
15.5 Event-Driven Programming

In the non-VRPG environment, programmers typically write display programs utilizing either one of two methods;
Defining the WORKSTN file as a combined primary file and utilizing the RPG cycle. This is where the program receives input from the WORKSTN file only once for each RPG cycle. Using the EXFMT operation code. In this case, the RPG cycle is typically not used. When a program encounters an EXFMT statement, it waits for input from the user before executing the next line in the calculation specifications.
In VRPG, both of these methods are no longer utilized to handle event-driven activities. Instead, a new kind of subroutine (called an action subroutine) can be created each time an event occurs. An event is a signal generated as a result of a change to the state of a part. Note: A part is a term that is used in VRPG. Its equivalent in the native RPG environment is a field in the DDS of a display format. An example of an event is pressing an OK push button. There are many different types of events that can occur with parts. The method we use to code an action subroutine for an event is similar to the way we code normal subroutines in the native RPG environment, that is, subroutines are coded between BEGSR and ENDSR operation codes. Action subroutines are coded between BEGACT and ENDACT operation codes. You notice that the sample program in Appendix E, VRPG Order Entry Program on page 209 has many of these subroutines. Event-driven programming is one of the most critical concepts that application developers have to understand when working with VRPG. If you are not already familiar with this concept, you may want to take the time to review the sample VRPG program that has been provided. Look for the action subroutines (that is, those enclosed between BEGACT and ENDACT operation codes) and see if you can determine when those subroutines are being executed.
15.6 Summary of Steps for Conversion to VRPG

The intention of this section is to give a high-level overview of what is involved in a conversion to VRPG. The remaining sections in this chapter describe in much greater depth, an approach that was taken to convert a sample program. Before-and-after compiled listings of the sample program used are in:

Appendix C, RPG/400 Order Entry Program on page 169 Appendix D, RPG IV Order Entry Program on page 187 Appendix E, VRPG Order Entry Program on page 209
The following steps involved in the conversion consist of; 1. Convert non-RPG IV code to RPG IV format.
102
2. Convert display formats. 3. Convert RPG code to VRPG. 4. Test and debug. Most of the subroutines in the program were able to be converted with little (if any) modifications. The modifications were to;

Replace EXFMT statements and WRITE statements for the WORKSTN file. Display error messages in an error message box (instead of showing the entire display again with the error message). Replace statements that did a SETLL using *HIVAL or *LOVAL with statements that used *START or *END. Add miscellaneous lines to handle displaying windows, doing the equivalent of a position cursor, and so on.
There were 14 subroutines in the original program, and (of course) the Mainline. All subroutines in the program except for two of them (and the Mainline) were able to be converted with only changes similar to those previously described. The subroutines that required changes over and beyond this were:
SRCINS, which basically had a loop and became redundant in the VRPG version of the program. SRRIDT, which was split into two subroutines at the point where the EXFMT was originally coded. The MAINLINE, which did not get converted. This was expected as VRPG is an event-driven language. The Mainline was (in a sense) replaced by a series of action subroutines that control what gets executed.
There is a significant resemblance between the original program and the final VRPG program. The next section of this chapter discusses, in more detail, the steps that are previously outlined.
15.7 Conversion to VRPG in Detail

The following sections describe the process of converting a sample application first to RPG IV and then converting to VRPG.
15.7.1 Converting To RPG IV

Converting RPG code to RPG IV code is a relatively simple process. All you need to do is run the CVTRPGSRC command (which is now a standard OS/400 command), and the command generates RPG IV source code for the program that you nominate. For example, the program in Appendix D, RPG IV Order Entry Program on page 187 was converted to RPG IV using the following command:
CVTRPGSRC FROMFILE(A960121C/QRPGSRC) FROMMBR(ORDENT) TOFILE(A960121C/QRPGLESRC) TOMBR(*FROMMBR)

The RPG III program that was converted is in Appendix C, RPG/400 Order Entry Program on page 169. If this process is not familiar to you, you might take the time to examine the differences between the two versions of the programs.
103
One point to note is that once the CVTRPGSRC command was issued, the RPG IV version of the program was recompiled successfully without any further modification. The resulting printed output is included in the Appendix D, RPG IV Order Entry Program on page 187. At the risk of pointing out the obvious, you are not required to do this step at all if the program you want to convert to VRPG is already written in RPG IV.
15.7.2 Converting Display Formats

Display formats that are used in the native RPG IV environment can be converted to VRPG. This is done from the GUI designer. The following information outlines the steps involved. Start from the GUI Designer, and select Import display file from the Project pull-down menu as shown in Figure 9.
Figure 9. Importing Display Files - Starting Point
104
A window similar to the one in Figure 10 is shown. In that window, you see a box, File hierarchy , where you select the server, library, and member that you want to work with. As you select the appropriate member, notice that the File name: field (in the top left-hand corner of the window) is automatically filled in for you.
Figure 10. Importing Display Files - Selecting the Source M e m b e r
105
When you have selected the member you want to work with, the record format names are displayed in the Record list: box (as shown in Figure 11). In this window, select the record format name that you want to import and press the Import push button (bottom left-hand corner of the window - see Figure 11). This starts the import process. You can repeat this process until all of the formats you need have been imported.
Figure 11. Importing Display Files - Selecting the Record Format
106
When you have completed importing your display formats, press the Cancel push button, and you return to the GUI designer. The display formats that you have imported should appear on both your Parts Palette and your Parts Catalog as shown in the example in Figure 12.
Figure 12. Parts Palette Showing the Imported Display Files
107
You can drag-and-drop the new part (which is really your imported display format) onto your Window With Canvas part. If you do not see all of the fields (known as parts in VRPG), re-size the Window With Canvas as you see fit, and you eventually see them. You should end up with a window that resembles the display format that you imported from the AS/400 display file. Figure 13 is an example of an AS/400 display file that was imported to VRPG. You probably find that fields are not exactly where you want them to be, and you probably need to make at least some cosmetic changes to the window. Nevertheless, you should find it much easier than designing the window from scratch.
Figure 13. An Imported Display Before Customizing
108
Figure 14. An Imported Display After Customizing
Figure 14 shows how the window looked after it was customized. Once you have finished migrating and customizing your windows, you are ready to start converting the RPG IV code to VRPG.
15.7.3 Converting RPG IV Code to VRPG

As we already know, programmers have their own style and approach to writing programs. Even if identical specifications are given to a number of different programmers, different programs are probably produced regardless of the fact that each program delivers the same functions. That is not to say that any one approach is correct or better. It is just recognition of the fact that there are many different ways to approach any programming task. The conversion to VRPG is merely just another programming task. Hopefully, the approach that is documented here helps make your job of converting to VRPG (and modernizing your applications) easier. The approach that was taken to convert the sample program to VRPG considered the VRPG events needed to be programmed in order to replicate the non-VRPG program functions.
15.7.3.1 CREATE Event for the ORDER Window

The first item that was considered was the CREATE event (generation of an event before a given window is displayed). This is equivalent to having a program initialization subroutine in a non-VRPG environment. An alternative is using a *INZSR routine. However, as the code needed to be repeated for every new order, and there was some window manipulation to be done, the CREATE event was selected instead.
109
A CREATE action routine was generated for the window called ORDER. You notice that the original program did not have an initialization routine. The initialization that was done was incorporated in the initial section of the Mainline. This was placed in the CREATE action-subroutine for the ORDER window with the following steps:
A call to a routine named SRRSTR that converted to a VRPG program with minor (if any) changes. A call to the routine named SRCINS that was copied up to the point where it called the subroutine, ORDENT. The end part of the SRCINS subroutine was omitted in the VRPG version of the program because it contained a redundant loop that was executed for each line added to the order. Some window handling that prepares and displays the first window.
The SRRSTR subroutine calls a subroutine, SRCORD. This call remained in the VRPG version and the SRCORD routine was converted without modification The SRCINS routine had calls to subroutines MAXKEY and INIHDR. These calls:

Remain as they were in the non-VRPG version of the program. The MAXKEY and INIHDR routines came across to the VRPG program with only minor changes (these changes are documented as comments in the subroutines themselves).
15.7.3.2 The First Window is Displayed

At this point, the VRPG program has all the code required to display the first window. (For your reference, an example of this window is shown in Figure 14 on page 109.) The next step was to convert the code to be executed when the push buttons at the bottom of the window are pressed. The push buttons being considered here are:

ACCEPT push button EXIT push button
Both of these generate a PRESS event for the ORDER window.
15.7.3.3 PRESS Event, ACCEPT Push Button, ORDER Window

The action routine for this event (Appendix E, VRPG Order Entry Program on page 209) calls the subroutine ORDENT. This is the same call in the SRCINS subroutine in the non-VRPG version of the program. However, to fit in with the event-driven characteristics of VRPG, it now appears in this action subroutine. The ORDENT subroutine is converted to VRPG in full, with only a minor change to handle the displaying of an error message window. The ORDENT subroutine calls a routine, WRRD, which is also converted to VRPG with only minor changes. The non-VRPG version of the program shows the display that enables order lines to be shown in the routine, SRRIDT. This routine was split into two subroutines at the point where the EXFMT occurred. The first of the two parts was included in this action subroutine.
110
15.7.3.4 PRESS Event, EXIT Push Button, ORDER Window

The last item we need to allow for in the Order Header window is the PRESS event for the EXIT push button. All we needed to do here was terminate the program (that is, set on *INLR). At this point, we are ready to consider what code is required for the second window (the order details window, ORDERD, in the VRPG program).
15.7.3.5 PRESS Event, ENTER Push Button, ORDERD Window

We have already discussed how only the first portion of the routine, SRRIDT, was included in the PRESS event of the ACCEPT push button in the ORDER window. The remainder of that original routine is now called from the action routine for the PRESS event of the ENTER Push Button in the ORDERD window. In summary, the original SRRIDT subroutine had to be split into two subroutines at the point where the EXFMT occurred. From that point on, only minor changes were made to accommodate the VRPG way of handling things such as displaying error message boxes, window manipulation, and so on. The SRRIDT subroutine called three different subroutines (SUBTR, RSTO and DLTPRD). All three of these subroutines were converted and incorporated into the VRPG version of the program with again, minor changes.
15.7.3.6 PRESS Event, FINALIZE Push Button, ORDERD Window

In the original program, the end of an order was signalled by pressing F3. The subroutine that was subsequently called was SRFNLO, which conveniently handled everything that needed to be done. Subsequently, the SRFNLO subroutine was converted (with minor modification) and this action routine called it. The SRFNLO routine also called SRCORD (which has already been discussed), and a routine, SRRADT, which was converted with minor modification. At the end of this action routine, a few extra lines were added to re-display the order header window so that the next order is processed. This creates the loop that was originally provided by the Mainline.
15.7.3.7 LOSTFOCUS Event, SFL01R Part, ORDERD Window

This action subroutine was not really required. The code in it was copied from the SRRIDT routine (in fact, it is duplicated). It was done as a performance consideration more than anything else, as it allows the VRPG program to do some processing while the user is still typing (that is, when the conditions it is looking for occur).
15.7.3.8 Approach for Displaying Error Messages

The approach used to display error messages was to display error message boxes at the point in the program where the error was found. This approach proved to be quite effective and relatively simple to do. The following list shows the steps that were involved:
Find all error messages that the non-VRPG version of the program can display and define them in the VRPG messages file (for further information on how to do this, refer to the Working with Messages chapter in the Client/Server Visual Programming with VRPG Client for OS/2 , SC09-2131). Locate the point in the program where the indicator used to control displaying the error message is turned on.
111
Add a line to display the error message box (that is, using the DSPLY operation code).
This turned out to be a rather trivial task and quick to implement for each error message.
15.8 Beyond the Conversion

You may recall that some application systems were converted from the S/38 to the AS/400 system, and from the S/36 or S/34 to the S/38, and so on. You will agree that the new technology of that time had significant extra features that enabled that programmer to create better programs. The previous section described how to convert a program to VRPG. The result of doing this produced a program that had a Graphical User Interface (GUI), but was similar in the way that it operated and interacted with the user. This is definitely an improvement on the traditional green-screen applications, but VRPG has the ability to deliver much more. To demonstrate some of the possibilities, the VRPG program discussed in this chapter can be further modified to incorporate some of extra techniques. For example, it is possible to link VRPG applications to Visual C++ parts. There are a number of parts and classes that have already been written that allow more powerful user presentation graphics. The AS/400 system is able to give application developers the ability to deliver applications that are technically advanced in their architecture. VRPG gives application developers the ability to deliver applications that utilize client/server techniques, have a graphical user interface, and subsequently are much easier to use.
112
Part 5. Modernizing Your Development Environment

The chapters in this part describe the IBM AS/400 Application Development tools that help in the systematic design, development, and maintenance of applications. Application Dictionary Services/400 (ADS/400), Application Development Manager/400 (ADM/400), and the COoperative Development Environment/400 (CODE/400) provide key functions to enhance every programmer s productivity. An example of how ADS/400 might be used for scanning data to locate where date fields are used for Year 2000 impact analysis is included. Examples of where ADM/400 and CODE/400 are used for project and application development and maintenance are also included. This part includes:

Chapter 16, Application Dictionary Services (ADS/400) Chapter 17, Application Development Manager (ADM/400) Chapter 18, COoperative Development Environment/400
113
114

ADS/400 integrates a dictionary database program with the AS/400 application development tools. It stores descriptions of application objects and their relationships in a data dictionary, thereby maintaining a complete inventory of all components. As you make changes to an object, the information in the dictionary is automatically updated. ADS/400 can help you design and maintain your applications by enabling you to do the following:
To determine where fields are used in the objects that constitute your application, and to determine what files or programs are affected by a change to a given field. This enables you to assess the impact of a change before it is made. To ensure that any change to a field is reflected in all objects that refer to that field, and if necessary, to recompile files or programs that are affected by this change. To identify certain physical files as field reference files. To search for strings in a source member. To scan for externally described field names in RPG programs to determine if a change to that field has real impact. To determine which programs are calling a specific program, or which programs are being called by a specific program. To create physical files based on field reference files. To build SQL table files based on field reference files, and build SQL index files based on the SQL table files and physical files.
An ADS/400 application dictionary documents information about every object in your application s libraries and saves it in a set of database files. These files are kept up-to-date automatically, and serve as a means of navigating through the application. A dictionary can document up to 99 libraries depending on their size. Note that the dictionary contains information describing the objects; the objects themselves remain in the AS/400 libraries in which they were created. Please refer to Application Dictionary Services/400 User s Guide , SC09-1860-00, for more information. Once you have created an application dictionary for your applications, you can search for a particular field/file/program, make changes to the source member, and compile the object and its related objects, all through the PDM-like menu displays. Or, this application dictionary can be used separately for your own application so that you can write a query program for scan and search purposes. For the project at hand, the ADS/400 tool is used to analyze the impact of the date fields in the application to size the Year 2000 problem. The first step is to create a dictionary for the application using the create dictionary option. The next step is to attempt to search for possible date fields. You might consider using a simple program similar to the one listed in Appendix B, ADS/400 Date Scan Program on page 165 for this purpose. The program can be linked to option 55 of the ADS Main Menu. The objective of this program is to
115
filter the content of the ADS field reference file to isolate possible date fields. The program also produces a summary report that shows all possible date fields found within the application. The sample report is shown in Figure 15 on page 116.
Possible Date Fields found using ADS/400 ======================================== match criteria: numeric field with 2, 3, 4, 6 digits field which contains selected text or substring ======================================== Number File Record External Field of Field Text File Type Format Field Name Type Digits Description ---------- ---------- ---------- ----------- ------ ----------------------------DAT_DES PF-DTA DFTRCD DTA_DES A 0 DATA DESCRIPTORS ----------Inspected field for file DAT_DES: 1 ODET DSPF SFL01C Inspected field for file ODET: OHRD DSPF ORDER DSPF ORDER DSPF ORDER Inspected field for file OHRD: PF-DTA PF-DTA ORDERHDR ORDERHDR REC1 1 *IN25 ORHDLY ORHDTE 3 6 6 DELIVERY DATE <---ORDER DATE <---A S S 0 6 6 S 4
Library --------A960121
ORDERHDR
ORHDLY P ORHDTA P ----------Inspected field for file ORDERHDR: 2 LF LF ORDERHDR ORDERHDR ORHDLY ORHDTA ----------2 PRDEXP ----------1 P P P
ORDH01L
6 6
DELIVERY DATE <---ORDER DATE <----
Inspected field for file ORDH01L: STOCK PF-DTA STOCK
EXPIRE DATE
<----
Inspected field for file STOCK: STOCK01L LF STOCK
PRDEXP P ----------Inspected field for file STOCK01L: 1 PRDEXP P ----------Inspected field for file STOCK02L: 1 LF STOCK
EXPIRE DATE
<----
STOCK02L
EXPIRE DATE
<----
Figure 15. ADS/400 Customized Year 2000 Impact Analysis
Using ADS/400 to filter the reference file gives you a good start to your analysis of the Year 2000 issue. If the decision is to change the size of a field, the report gives you some feel for the number of fields and files requiring the change. The next step is to identify the programs using those impacted files. Figure 16 on page 117 and Figure 17 on page 117 show the objects as they are used within programs, physical files, logical files, and libraries.
116
Figure 16. ADS/400 Object Impact Analysis
Figure 17. ADS/400 Related Files with Date Fields
117
118
Chapter 17. Application Development Manager (ADM/400)

Today, change is intrinsic to most software engineering endeavors. Applications consist of many components, some of which are based on previous versions and all of which may be undergoing constant revision. The problems of application development are further complicated by the inter-dependencies that exist between components. Changing just one component may result in changes to several other components that depend on it. To build and maintain high-quality applications efficiently, application development organizations must have a consistent and systematic approach to manage changes they are making to their applications. They are looking for standard methods and procedures and, where possible, automation to improve productivity and reduce backlogs. Development organizations need to be able to organize and manage all the components of an application as a unit. They also need to be able to control the baseline or master version of an application. They often want to control multiple versions of components or of entire applications, and they want to be able to make quick fixes to the code they are developing. They need a mechanism that allows for shared access to components, and they want the means to plan and manage their entire development process. They must reduce the time they spend in maintaining applications so that they have more time to develop new applications. IBM Application Development Manager/400 is a host-based change management tool that provides application developers a development environment to effectively and efficiently manage applications development. The product is integrated with the AS/400 Product Development Manager (PDM) and is available as an extra option to the PDM menu. It can be used with the PDM menu or by typing the Control Language (CL) commands on the command line. The product allows the project leader or administrator to define the application and the roles of each developer. The developers work in a well-organized and disciplined environment, which in turn, increases productivity. This is a productivity tool for the entire application development team. It can be used to manage existing applications by defining a project and importing the existing source members and objects into different groups of the project and compiling the entire application. References... Refer to Application Development ToolSet/400: Application Development Manager/400 Introduction and Planning Guide , GC09-1807, and Application Development ToolSet/400: Application Development Manager/400 User s Guide , SC09-2133, for detailed information.
The major activities in an application development environment do not vary proportionately with the complexity of the application. In reality, the activities in the project management and test phases grow exponentially as the applications
119
increase in complexity. The following diagram illustrates the distribution of the major efforts in small, medium, and large systems environments, each with the need to deal with the Year 2000 conversion project.
Figure 18. Year 2000 Conversion Effort Distribution
The major effort is in the test phase. This is unavoidable due to the intrinsic complexity of the task. A Year 2000 conversion tool can handle the physical conversion of fields, files, and programs. The ultimate success lies in testing to ensure the conversion worked. It is clearly more complex to test 1000 programs than to test 100 or 50 programs. Project management is also a significant part of the effort in a large systems environment. This is due to the need to track the many testing activities, synchronize the large number of programs, manage the activities of a larger programming staff, and so on.
17.1 ADM/400 Benefits

The Application Development Manager/400 product answers many of the needs of today s application developers. It provides a team of application developers working in an AS/400 environment with a mechanism for efficiently and effectively managing their development environment and its application objects throughout the life of the application.
120
Benefits
A standard development process: ADM/400 can assist a development team to define the application that suits its organization and methods.
Increased productivity: This product helps developers to organize modifications to existing code and in writing new code. Developers can work efficiently and productively as they write their code, compile, and test it. Their development activities and changes are tracked and monitored in a well-organized fashion.
Flexibility and versatility: The structure defined at the beginning of a project does not restrict the development team. This structure is changed and refined at any time as the demands of the project change. ADM/400 monitors the changes as developers are added to or removed from the project. An audit trail is also established as code is shared and reused.
Support for several versions of an application: Developers can create and maintain multiple versions of an application in both the development and production environments using ADM/400. They can easily identify which versions of source and objects belong to a particular version of the application.
An automated and faster build process: Developers can rely on the powerful build process to build, or compile, the source code for an application more quickly. They no longer have to analyze the relationships between pieces of code; the build process does this for them automatically.
Data security and integrity: The structure that the Application Development Manager/400 environment provides ensures the integrity and security of production, test, and development versions of the code. Developers are able to work with different versions of the code. They work in an environment where they are assured that they do not overwrite one another s changes.
An audit trail: A project log records what has changed in the application, the commands used to change the hierarchy or components it contains, who issued the commands, and when the activity took place.
Notification about the status of any component of the application: Developers receive messages that notify them that a part they are requesting is already being changed, that it exists in another branch of the project hierarchy, and that a change made in one version may also have to be made in another version. This is useful when fixes to a production version of a part have to be propagated to the same part used in other areas of the application. The person doing this work needs to know where the part is in the hierarchy and who has checked it out to a development group. Another useful command to help with your fixes is the Merge Part (MRGPART) command. This is ADM/400 s interface to the File Compare and Merge Utility. This command merges specific parts or all the parts in the default search path from a specified target group. This function can be
121
particularly useful if you must migrate a change from a part to the same part used somewhere else. It is also useful for merging vendor changes with your own changes for a given part.
Archiving: Developers can choose to use the archive function when they promote a source to a higher level. If a version of that source exists already at that level, that version is archived before it is replaced.
Ability to package applications: The Application Development Manager/400 product provides a mechanism that assists in the packaging process. The various solutions for packaging and distribution are discussed in the AS/400 Software Life Cycle Management with Application Development Manager/400 & SystemView System Manager/400 , SG24-4187-01.
17.1.1 Who Uses Application Development Manager/400?

The two main groups of users of this product are:
The project administrator: The person who creates a project is automatically authorized to work on the project as the project administrator. This person defines the phases, such as development and testing, through which components of an application go before they are actually placed in a production environment. This person performs the following actions: Maintain the project hierarchy, divided into groups. Enroll and remove developers from the project and grant them authority to the different groups.
The developers: The application developer is any member of the development team who has been given access to the application by the project administrator. Application developers usually only have update access to specific groups. They perform the following tasks: Create or change source code (parts) of the application in a development group. Parts to be modified are copied from the application group already under control of Application Development Manager/400. Compile parts and applications using the build process that automates much of this work. Test the application (or parts), either within the control of Application Development Manager/400, or externally by moving the code to another test environment.
17.2 The Order Entry Application and ADM/400

This section covers the setup of our environment and the import of the Order Entry application into Application Development Manager/400. The guidelines for using Application Development Manager/400 and the setup considerations are well documented in the Application Development Manager/400 User s Guide , SC09-2133, and the Application Development Manager/400 Introduction and Planning Guide , GC09-1807. The overall process involves:
122
Setting up the Order Entry project hierarchy: Creating a project. Creating project groups. Enrolling users to a project.
Importing the existing application into Application Development Manager/400. Building the application: Printing and analyzing the build report.
Running and testing the application: Adding a project to the library list.
17.2.1 The Order Entry Project Hierarchy

The project hierarchy is set up through:

Creating a project. Creating project groups that are organized into levels. Enrolling users to a project.
A project is a complete application consisting of a collection of one or more groups. A group in a project is a collection of parts used in the same phase in a development process. A part is an object, such as an AS/400 physical file or a program, or a source member containing RPG/400 code for an RPG program. It may also be other items, such as a field in a record or a record in a file that you have defined for your application. A project hierarchy is a collection of groups that are organized into levels with each level representing one of the phases in the development process. Figure 19 on page 124 shows the project hierarchy that was created for the Order Entry application project. This sample project is comprised of four levels that contains five groups: PRODUCTION_V1, TEST, DEVELOPMENT, PROGRAMMER1, and PROGRAMMER2.
123
Figure 19. The Hierarchy of the Base Project
We created the Project Order Entry and the other groups as shown in Figure 19 with the following commands: To create the Order Entry project:
CRTPRJ PRJ(ORDER_ENTRY) SHORTPRJ(OEA) SAVDTA(*YES) + TEXT( Order Entry Application )

To create the PRODUCTION_V1 group:
CRTGRP PRJ(ORDER_ENTRY) GRP(PRODUCTION_V1) SHORTGRP(PRDV1) + PARENT(*NONE) PRMCODE(PRODUCTION_V1) NOTIFY(*DEVELOPER) + TEXT( This is the version 1 production group for project OE )
To create the TEST group:
CRTGRP PRJ(ORDER_ENTRY) GRP(TEST) SHORTGRP(TST) PARENT(PRODUCTION_V1) + PRMCODE(PRODUCTION_V1) NOTIFY(*DEVELOPER) TEXT( Test group for project OE )
To create the DEVELOPMENT group:
CRTGRP PRJ(ORDER_ENTRY) GRP(DEVELOPMENT) SHORTGRP(DEV) PARENT(TEST) + PRMCODE(PRODUCTION_V1) NOTIFY(*DEVELOPER) TEXT( Development group for project OE )
To create the PROGRAMMER1 group:
CRTGRP PRJ(ORDER_ENTRY) GRP(PROGRAMMER1) SHORTGRP(PGM1) PARENT(DEVELOPMENT) + PRMCODE(PRODUCTION_V1) NOTIFY(*DEVELOPER) TEXT( Programmer1 group for project OE )
To create the PROGRAMMER2 group:
CRTGRP PRJ(ORDER_ENTRY) GRP(PROGRAMMER2) SHORTGRP(PGM2) PARENT(DEVELOPMENT) + PRMCODE(PRODUCTION_V1) NOTIFY(*DEVELOPER) TEXT( Programmer2 group for project OE )
124
Figure 20 on page 125 shows the Work with Groups Using PDM display. This display shows all the groups in the sample Order Entry project hierarchy.
Work with Groups Using PDM Project . . . . . . . . . . ORDER_ENTRY_____________________
DEVSYS01
Type options, press Enter. 2=Change 4=Delete 25=Find string 29=Check in Opt ___ ___ ___ ___ ___ Level 01 02 03 04 04 Group PRODUCTION_V1 TEST DEVELOPMENT PROGRAMMER1 PROGRAMMER2
12=Work with 30=Promote
14=Build 38=Import ...
Bottom Parameters or command ===> _________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F6=Create F9=Retrieve F10=Command entry F23=More options F24=More keys
Figure 20. Work with Groups Using PDM Display
Notice that the groups are indented to show their position in the hierarchy. So, for example, PRODUCTION_V1 is the parent group of TEST, and DEVELOPMENT is the parent group of PROGRAMMER1 and PROGRAMMER2. Also, the level indicator for each group helps you determine the project hierarchy. The purpose of this level indicator is to identify the hierarchical position of the groups within the project. DEVELOPMENT Group... In this project hierarchy, the DEVELOPMENT group allows you to promote your changes to a common group without affecting the test and production version of the application. This approach has the following benefits:
The administrator can ensure that all of the developers changes are able to be compiled before promoting them to the TEST group. If they do not compile, the administrator can request the developers to make the necessary corrections. Developers can make numerous checkouts, changes, or promotes without affecting the test or production version of the application. When you export your application from a production or test library, you can always track it back to the exact version of source for that object. This also provides better control over who can promote parts to the test and production groups in case you need to implement a sign-off procedure for audit purposes.
125
17.2.1.1 Enrolling Programmers to a Project

After creating all of the project groups required for the Order Entry application hierarchy, you need to enroll (add) the two programmers (in this case, PGMR1 and PGMR2) to the project. Both programmers have update access to their respective development groups. On the Work with Project using PDM display, use option 41 (Add user) beside the project Order Entry. Figure 21 shows how PGMR1 and PGMR2 are added to the Order Entry project using the Add Project User display.
Add Project User (ADDPRJUSR) Type choices, press Enter. Project . . . . . . User profile . . . . User type . . . . . Project access level Development group . + for . . . . . . > ORDER_ENTRY Name . . . . . . PGMR1 _____ Name . . . . . . > *DEVELOPER *DEVELOPER, *ADMIN . . . . . . *UPDATE *READ, *UPDATE . . . . . . PROGRAMMER1 _____________________ more values ________________________________
Bottom F9=All parameters F11=Keywords F14=Command string F24=More keys
Figure 21. Adding PROGRAMMER1 and PROGRAMMER2 to Order Entry Project
Now, we have added the PGMR1 and PGMR2 programmers to the Order Entry project. These programmers can look at any part in the entire project. However, they can only update or build a part in their development groups (in this case, PROGRAMMER1 and PROGRAMMER2 respectively).
17.2.2 Importing the Application

In this section, we import an existing Order Entry application stored in the YEAR2000 library into the ORDER_ENTRY project. Import means to copy one or more objects, parts, or source members from an AS/400 library into an Application Development Manager/400 project hierarchy. Either a project administrator or an application developer can import objects, provided they have sufficient AS/400 authority to the objects that they want to import. They also need update access to the group in which they are importing the objects. Typically, the administrator imports an entire application or a large piece of an application, while a developer is more likely to import just a few source members or objects. Figure 22 on page 127 shows the Import Part command that was used to import the entire existing Order Entry application into the ADM/400 ORDER_ENTRY project.
126
Import Part (IMPPART) Type choices, press Enter. Object to import . . . . . . . . > Library . . . . . . . . . . . > Object type . . . . . . . . . . > Member . . . . . . . . . . . . . Project . . . . . . . . . . . . > Group . . . . . . . . . . . . . > Type . . . . . . . . . . . . . . Part . . . . . . . . . . . . . . Language . . . . . . . . . . . . Promote code . . . . . . . . . . Source file . . . . . . . . . . Copy Data . . . . . . . . . . . Replace existing data . . . . . Part List . . . . . . . . . . . > Archive . . . . . . . . . . . . Text description . . . . . . . . __________________________________ F3=Exit F4=Prompt F24=More keys F5=Refresh *ALL______ Name, generic*, *ALL YEAR2000__ Name, *CURLIB, *LIBL *FILE _____ *ALL, *SRC, *NONSRC, *CLD... *ALL______ *ALL, name, generic* ORDER_ENTRY_____________________ PRODUCTION_V1______________________ *OBJTYPE__ *OBJTYPE, name, BLDOPT... *NAME_____ *NAME, name *ATTR_____ *ATTR, name, *NONE, C, CBL... *GRP_ *GRP, *NONE *TYPE_____ *FROMFILE, name, *TYPE *YES *NO, *YES *NO_ *NO, *YES *NONE_____ *NONE, name *NO_ *NO, *YES *TEXT______________________________________ Bottom F13=How to use this display
F12=Cancel
Figure 22. IMPPART Command to Import Parts
The import is done directly into the production group assuming that the application is running as designed. If for some reason you need to maintain the application, you can still use the TEST and DEVELOPMENT versions. If the promotion to the production level is done using the Archive function, the original imported part is retained. In our example, we used *FILE in the Object Type prompt, which specifies that source members and files are imported. Changing the Source File prompt from *FROMFILE to *TYPE signifies that each source part should be stored in a default file according to its type. For example, source RPGSRC goes into file QRPGSRC. The following message appears at the bottom of the Work with Groups Using PDM display: TEXT(*TEXT) is specified so that the text description of each imported object or database member is preserved after the import process. Unique part text is often used to easily identify the part when packaging or modifying the application. If TEXT( Importing Order Entry application ) is specified, all imported parts have the same text field contents - Importing Order Entry application! You can use the following command from the command line instead of the previous display in order to import the parts required for the Order Entry application project:
/* Import the PARTS into the PRODUCTION_V1 Group */ IMPPART OBJ(YEAR2000/*ALL) OBJTYPE(*FILE) MBR(*ALL) PRJ(ORDER_ENTRY) + GRP(PRODUCTION_V1) SRCFILE(*TYPE) DATA(*YES) TEXT(*TEXT)
67 parts processed, 0 parts not processed .
127
17.2.3 Building the Application

After the application is successfully imported into group PRODUCTION_V1, the application must be built in Application Development Manager/400. This causes all application parts to be compiled. The build process creates the relationships between source and object, as well as between components. In this sample Order Entry project, we build an application by compiling all the parts in the PRODUCTION_V1 group. We also display a build report using the WRKSPLF command. The Application Development Manager/400 build process determines which parts of an application have changed and, based on the relationships between those parts, recompiles them so that all parts are current in relation to their dependencies. A create relationship is established when a source part is compiled to create an output part such as a program. There are several kinds of dependency relationships . A dependency relationship between two parts exists when one requires another part in order to be built. Each time we compile a part, the information about dependent parts used in the compilation of the part is stored as its dependency relationship. Parts that have never been built before do not have relationships. Their relationships are added from the information returned from the compilers after their first build. Figure 23 shows the Build Part command that was used to build (compile) all the parts in the PRODUCTION_V1 group.
Build Part (BLDPART) Type choices, press Enter. Project . . . . . Group . . . . . . Type . . . . . . . Part . . . . . . . Language . . . . . Search path . . . Scope of build . . Force build . . . Build mode . . . . Save list . . . . Perform bind step Part List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > > > > ORDER_ENTRY PRODUCTION_V1 *ALL______ *ALL______ *ALL______ > *DFT______ > *NORMAL__ *NO_ *COND___ *NO_ *YES *NONE_____ Name Name, *generic*, *ALL... Name, *generic*, *ALL *ALL, name, *generic* *DFT, name *NORMAL, *LIMITED, *EXTENDED *NO, *YES *COND, *UNCOND, *RPTONLY *NO, *YES, *DLT *YES, *NO *NONE, name
F3=Exit F4=Prompt F24=More keys
F5=Refresh
F12=Cancel
Bottom F13=How to use this display
Figure 23. Rebuilding the Complete Application
We used the following command to rebuild the complete application in Application Development Manager/400:
128
/* Build the parts into the PRODUCTION_V1 Group */ BLDPART PRJ(ORDER_ENTRY) GRP(PRODUCTION_V1) TYPE(*ALL) PART(*ALL) + SHCPTH(*DFT) SCOPE(*NORMAL) FORCE(*NO) BLDMODE(*COND) SAVLST(*NO)
17.2.3.1 Build Part Command Keywords

Search path = *DFT The build process uses the default hierarchy to find parts when building, which, in this sample case, is the PRODUCTION_V1 group. Scope to build = *NORMAL The default value *NORMAL means that we are building all of the parts. Force build = *NO The default value *NO means that the parts have never been compiled before but are now being compiled. Build mode = *COND Using this default value stops the build processing for the part if the development part to this part fails to build. Since all the parts are compiled, this prompt has no effect. Save list = *NO Specify that the compiler listing and build-report listing need not be saved. Note! You may notice that some parts are being compiled more than once. BLDPART only knows what the compiler tells it, so it may not compile some parts in the correct order until it has learned about all of the dependent relationships between parts. The following message appears at the bottom of the Work with Groups Using PDM display when all the parts in the PRODUCTION_V1 group have been compiled:
34 parts build, 0 parts failed, 0 warnings .
17.2.3.2 Display the Build Report

A build report is always generated when you compile one or more parts. It consists of three sections: Build Report Build Messages The build-messages section lists both the message numbers and message text for warnings or errors found during the build process. Build Outputs The build-outputs section shows the build outputs created by the build process. The build-report section lists the parameters that were specified on the Build Part (BLDPART) display.
To see the details of the build process, look in the QPLYBLDP spooled file. An example of such report is shown in Figure 24 on page 130.
129
5763PW1
V3R1M0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Development Manager/400 - Build Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : ORDER_ENTRY PRODUCTION_V1 *ALL *ALL *DFT *NORMAL *NO *COND *NO *YES *DFT ORDER_ENTRY BLDOPT Part ---------*DFT *DFT *DFT *DFT *DFT *DFT BLDOPT Part ---------*DFT *DFT *DFT *DFT *DFT *DFT *DFT BLDOPT Part ---------*DFT *DFT *DFT *DFT *DFT BLDOPT Part ---------*DFT *DFT *DFT BLDOPT Part ---------*DFT *DFT *DFT *DFT *DFT *DFT *DFT *DFT *DFT N D O F B
7/24/96
11:14:20
Project . . . . . . . Group . . . . . . . . Type . . . . . . . . . Part . . . . . . . . . Search path . . . . . Scope of build . . . . Force build . . . . . Build mode . . . . . . Save list . . . . . . Perform Bind Step . . Search path part used Search path used . . .
PRODUCTION
DDSSRC-PF Part Group ---------- -------------------CUSTOMER PRODUCTION_V1 DAT_DES PRODUCTION_V1 ORDERDTL PRODUCTION_V1 ORDERHDR PRODUCTION_V1 SALESCUS PRODUCTION_V1 STOCK PRODUCTION_V1 DDSSRC-LF Part Group ---------- -------------------CUS01L PRODUCTION_V1 ORDD01L PRODUCTION_V1 ORDH01L PRODUCTION_V1 RSTRL PRODUCTION_V1 SALC01L PRODUCTION_V1 STOCK01L PRODUCTION_V1 STOCK02L PRODUCTION_V1 DDSSRC-DSPF Part Group ---------- -------------------DSPMSGD PRODUCTION_V1 FNLORDD PRODUCTION_V1 ODET PRODUCTION_V1 OHRD PRODUCTION_V1 ORDENTWS PRODUCTION_V1 CLPSRC Part Group ---------- -------------------AMODN PRODUCTION_V1 OPM PRODUCTION_V1 STROE PRODUCTION_V1 RPGSRC Part Group ---------- -------------------CINS PRODUCTION_V1 CORD PRODUCTION_V1 FNLO PRODUCTION_V1 OE PRODUCTION_V1 ORDENT PRODUCTION_V1 RADT PRODUCTION_V1 RIDT PRODUCTION_V1 RSTO PRODUCTION_V1 RSTR PRODUCTION_V1
FILE Created ---------CUSTOMER DAT_DES ORDERDTL ORDERHDR SALESCUS STOCK FILE Created ---------CUS01L ORDD01L ORDH01L RSTRL SALC01L STOCK01L STOCK02L FILE Created ---------DSPMSGD FNLORDD ODET OHRD ORDENTWS PGM Created ---------AMODN OPM STROE PGM Created ---------CINS CORD FNLO OE ORDENT RADT RIDT RSTO RSTR * * * * * E
Group -------------------*NONE *NONE *NONE *NONE *NONE *NONE
Reason for Building ---------------------------------------------------Source part has not been built before. Source part has not been built before. Source part has not been built before. Source part has not been built before. Source part has not been built before. Source part has not been built before.
Group -------------------*NONE *NONE *NONE *NONE *NONE *NONE *NONE
Reason for Building ---------------------------------------------------Source part has not been built before. Source part has not been built before. Source part has not been built before. Source part has not been built before. Source part has not been built before. Source part has not been built before. Source part has not been built before.
Group Reason for Building -------------------- ---------------------------------------------------*NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before.
Group Reason for Building -------------------- ---------------------------------------------------*NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before.
Group Reason for Building -------------------- ---------------------------------------------------*NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before. *NONE Source part has not been built before. U I L D R E P O R T * * * * *
Figure 24. QPLYBLDP Output After Building
Note: Notice that since the build was successful, there is no build-messages listing.
17.2.3.3 Add a Project to the Library List

In this sample Order Entry project, we add the project libraries of project ORDER_ENTRY to the library list. We can use option 45, Add project library list, or the system-supplied user-defined option AP on the Work with Parts Using PDM display to set the library list, or use the following command:
ADDPRJLIBL PRJ(ORDER_ENTRY) GRP(PRODUCTION_V1)
130
A user-defined option can be either any AS/400 system command or user command containing parameters allowing you to execute operations that you do frequently simply by typing an option on a PDM display. A system-supplied user-defined option is a predefined user option that is available in PDM. In this case, AP is a system-supplied user-defined option that allows you to add project libraries to your library list. To add the project ORDER_ENTRY to the library list, type the system-supplied user-defined option AP beside any part and press F4 (Prompt). The Add Project Library List (ADDPRJLIBL) display is shown:
Add Project Library List (ADDPRJLIBL) Type choices, press Enter. Project . . . Group . . . . Scan hierarchy Search path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > > > > ORDER_ENTRY________________________ PRODUCTION_V1______________________ *YES *YES, *NO *DFT______ *DFT, name
F5=Refresh
F12=Cancel
Figure 25. Add Project Library List Command
The following message appears at the bottom of the Work with Parts Using PDM display:
ADDPRJLIBL completed successfully .
17.2.4 Run and Test the Order Entry Application

Now the application is ready to be tested. We run the Order Entry application that was created in Section 17.2.3, Building the Application on page 128. Running the application allows you to verify it. Note that this Order Entry application references files that were built in the group library PRODUCTION_V1. So the ADDPRJLIBL in Section 17.2.3.3, Add a Project to the Library List on page 130 is essential to add the project libraries to the library list before running the application to verify it. Use option 16 (Run) for the AMODN program part as shown in Figure 26 on page 132 to verify and test if rebuilding the Order Entry application in group PRODUCTION_V1 was successful.
131
Work with Parts Using PDM Project . . . . . . . . Specified group . . . . Position to . . . . . . ORDER_ENTRY_____________________ PRODUCTION_V1___________________ __________ Position to type . . . . .
DEVSYS01
___________
Type options, press Enter. 2=Change 3=Copy 4=Delete 5=Display 8=Display information 13=Change information
6=Print 14=Build
7=Rename 16=Run ...
Opt Part Type Language Group ___ VDEVPG TXTSRC *NONE PRODUCTION_V1 16___AMODN_______PGM_________CLP_________PRODUCTION_V1 ___ CINS PGM RPG PRODUCTION_V1 ___ CORD PGM RPG PRODUCTION_V1 ___ FNLO PGM RPG PRODUCTION_V1 ___ OE PGM RPG PRODUCTION_V1 ___ OPM PGM CLP PRODUCTION_V1 More... Parameters or command ===> _________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F6=Create F9=Retrieve F10=Command entry F23=More options F24=More keys
Figure 26. Run the Order Entry Program
The Order Entry display looks similar to this:
DEVSYS01 ADMININ ORDER ENTRY 7/24/96 19:07:31 ============================================================================ ORDER NUMBER.: 00018 ORDER DATE...: 7/24/96 CUST. NUMBER.: 00002 Frank Q. French DELIVERY DATE: 7/24/97 ============================================================================ Please enter your order items: Product No.: 00002 Quantity: ____10 ============================================================================== A C Code Description Qty Un. Price Total Price ============================================================================== _ 00002 Eraser (10 pieces) 10 5.65 56.50
Bottom -----------------------------------------------------------------------------Order Total............: 56.50 ____________________________________________________________________________ Enter=Accept PF3=Exit

Figure 27. Order Entry Application Display
132
17.3 Develop the Follow-On Version of the Order Entry Application

In this section, we create a follow-on version of the Order Entry application using the Application Development Manager/400 product. We convert the previous application that was coded in OPM RPG language to the new ILE RPG environment. ILE Environment... The Application Development Manager/400 product is especially useful for ILE environments. Since there are many objects (parts) involved in the development process of ILE applications, Application Development Manager/400 is helpful in identifying relations and dependencies between the different parts.
The follow-on version overall process involves:
Creating Version 2 of the Order Entry project hierarchy: Creating the COMMON group to handle Version 1 and Version 2 non-program parts. Copying the non-program parts from the PRODUCTION_V1 group to the COMMON group. Creating the PRODUCTION_V2 group. Copying the program-source parts from PRODUCTION_V1 group to PRODUCTION_V2 group. Deleting the non-program parts from the PRODUCTION_V1 group.
Moving the Version 1 hierarchy under Version 2. Changing the promote code.
Note: Creating a follow-on hierarchy of a project is typically performed by an administrator. The version 1 hierarchy for the Order Entry application can be expanded to allow for the development of a version 2. There are two ways of doing this: 1. Move the existing group hierarchy below the PRODUCTION_V1 group under a new group, PRODUCTION_V2. Development for the follow-on version is done in the new PRODUCTION_V2 branch of the hierarchy, thereby preserving Version 1 code. Groups that allow fixes to Version 1 need to be created. 2. Create new groups under the new PRODUCTION_V2 group. The advantage to this approach is that you can preserve your Version 1 branch for fixes to Version 1. However, these two ways are useful when developing the follow-on application using the same source type programs. This is not our example since we are going to develop the follow-on application using the ILE RPG environment instead of continuing with the OPM RPG. The problem is that an RPGSRC part XYZ in PRODUCTION_V1 still exists after an RPGLESRC part XYZ is created in PRODUCTION_V2. Both parts are visible from the V2 groups and both are built by the BLDPART command. In this situation, we recommend the hierarchy as shown in Figure 28 on page 134, where all three groups have different
133
promote codes. COMMON contains non-program parts. This way, you do not have to worry about V1 OPM programs being created in your V2 groups. From this point on, we implement this scenario as an example to demonstrate how you can create a follow-on version of your project using Application Development Manager/400.
Figure 28. Project Hierarchy for a Follow-On Version of Order Entry Application
Changing the Hierarchy Structure... Application Development Manager/400 does not allow you to make changes to a hierarchy structure while someone is working in that project. If it did, the integrity of the project hierarchy is jeopardized. All user IDs associated with the project should be logged off. You should be on the STRPDM display before proceeding.
17.3.1 Create Version 2 Hierarchy for the Order Entry Project

To create a Version 2 hierarchy for the Order Entry project, you can press F6 (Create) to create a group on the Work with Groups Using PDM display. Figure 29 on page 135 shows the CRTGRP command that was used to create the COMMON group for the Order Entry Project. Remember, the COMMON group contains non-program parts.
134
Create Group (CRTGRP) Type choices, press Enter. Project . . . . . . . . . . . . > ORDER_ENTRY Name Group . . . . . . . . . . . . . COMMON __________________________ Short group . . . . . . . . . . COMMO Name Parent group . . . . . . . . . . *NONE___________________________ Promote code . . . . . . . . . . COMMON __________________________ Coded character set . . . . . . *PARENT *PARENT, integer, *JOB, *HEX Notify . . . . . . . . . . . . . *NONE_____ *NONE, name, *DEVELOPER PARTL required . . . . . . . . . *NO_ *NO, *YES Text description . . . . . . . . This is the COMMON group that handles V1 and V2 non-program parts______________
F5=Refresh
F12=Cancel
Figure 29. Creating the COMMON Group
Figure 30 shows the CPYPART command that was used to copy the non-program parts from the PRODUCTION_V1 group to the COMMON group.
Copy Part (CPYPART) Type choices, press Enter. From project . From group . . From type . . From part . . To project . . To group . . . To type . . . To part . . . Scan hierarchy Promote code . Source file . Copy Data . . Part list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > ORDER_ENTRY_____________________ > PRODUCTION_V1___________________ > FILE ______ Name, *ALL, BLDOPT, BNDDIR... > *ALL Name, *ALL *FROMPRJ________________________ > COMMON__________________________ *FROMTYPE_ *FROMTYPE, name, BLDOPT... *FROMPART_ *FROMPART, name *YES *YES, *NO *GRP_ *GRP, *NONE *TYPE_____ *SAME, name, *TYPE *YES *NO, YES *NONE_____ *NONE, *PRV, name
F5=Refresh
F12=Cancel
Figure 30. Copying the Non-Program Parts to the COMMON Group
The following message appears at the bottom of the display:

Note: You should repeat the previous command to copy the DDSSRC parts to COMMON as well, or simply issue the following command:
135
CPYPART FROMPRJ(ORDER_ENTRY) FROMGRP(PRODUCTION_V1) FROMTYPE(DDSSRC) + FROMPART(*ALL) TOGRP(COMMON) SRCTYPE(*TYPE)


Copying Parts... In this sample Order Entry project where we are changing the code from OPM RPG to ILE RPG, the non-program parts are copied to the COMMON group, while the program-source parts are copied to the new PRODUCTION_V2 group. However, when implementing this scenario, you must verify which source parts have to be copied to a common group and which have to be copied to the new version production group. For this purpose, you may want to use the report shown in Figure 24 on page 130. In our case, we also are moving some OPM CLP programs to ILE CLP.
Figure 31 shows the CRTGRP command that was used to create the PRODUCTION_V2 group for the Order Entry Project.
Create Group (CRTGRP) Type choices, press Enter. Project . . . . . . . . . . . . > ORDER_ENTRY Name Group . . . . . . . . . . . . . PRODUCTION_V2 ___________________ Short group . . . . . . . . . . PRDV2 Name Parent group . . . . . . . . . . COMMON__________________________ Promote code . . . . . . . . . . PRODUCTION_V2 ___________________ Coded character set . . . . . . *PARENT *PARENT, integer, *JOB, *HEX Notify . . . . . . . . . . . . . *NONE_____ *NONE, name, *DEVELOPER PARTL required . . . . . . . . . *NO_ *NO, *YES Text description . . . . . . . . This is the Version 2 Production Group for project OE__________________________
F5=Refresh
F12=Cancel
Figure 31. Creating the PRODUCTION_V2 Group
Figure 32 on page 137 shows the CPYPART command that was used to copy the program source parts from the PRODUCTION_V1 group to the PRODUCTION_V2 group.
136
Copy Part (CPYPART) Type choices, press Enter. From project . From group . . From type . . From part . . To project . . To group . . . To type . . . To part . . . Scan hierarchy Promote code . Source file . Part list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > ORDER_ENTRY_____________________ > PRODUCTION_V1___________________ > RPGSRC ____ Name, *ALL, BLDOPT, BNDDIR... > *ALL Name, *ALL *FROMPRJ________________________ > PRODUCTION_V2___________________ > RPGLESRC __ *FROMTYPE, name, BLDOPT... *FROMPART_ *FROMPART, name *YES *YES, *NO *GRP_ *GRP, *NONE *TYPE_____ *SAME, name, *TYPE *NONE_____ *NONE, *PRV, name
F5=Refresh
F12=Cancel
Figure 32. Copying the Program Source Parts to the PRODUCTION_V2 Group

Note: You should repeat the previous command to copy the CLPSRC parts to the PRODUCTION_V2 group as CLLESRC, or simply issue the following command:
CPYPART FROMPRJ(ORDER_ENTRY) FROMGRP(PRODUCTION_V1) FROMTYPE(CLPSRC) + FROMPART(*ALL) TOGRP(PRODUCTION_V2) TOTYPE(CLLESRC) SRCTYPE(*TYPE)


Figure 33 on page 138 shows the DLTPART command that was used to delete the non-program parts from the PRODUCTION_V1 group.
137
Delete Part (DLTPART) Type choices, press Enter. Project . . . Group . . . . Type . . . . . Part . . . . . Part list . . Delete archive . . . . . . . . . . . . . . . . . . . . . . . . . versions . . . . . . . . . . . . . . . . . . . > ORDER_ENTRY_____________________ . > PRODUCTION_V1___________________ . > DDSSRC ____ Name, *generic*, *ALL... . *ALL______ Name, *generic*, *ALL . *NONE_____ *NONE, *PRV, name . *NO_ *NO, *YES
F5=Refresh
F12=Cancel
Figure 33. Deleting Parts Copied to the COMMON Group

Note: You should repeat the previous command to delete the FILES from the PRODUCTION_V1 group as well, or simply issue the following command:
DLTPART FROMPRJ(ORDER_ENTRY) FROMGRP(PRODUCTION_V1) FROMTYPE(FILE) + FROMPART(*ALL)


Figure 34 on page 139 shows the Work with Groups Using PDM display where you can see that the PRODUCTION_V2 group was added under the COMMON group.
138
DEVSYS01
Type options, press Enter. 2=Change 4=Delete 25=Find string 29=Check in Opt ___ ___ ___ ___ ___ ___ ___ Level 01 02 03 04 05 05 02 Group COMMON PRODUCTION_V1 TEST DEVELOPMENT PROGRAMMER1 PROGRAMMER2 PRODUCTION_V2
Bottom Parameters or command ===> ________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F6=Create F9=Retrieve F10=Command entry F23=More options F24=More keys Group PRODUCTION_V2 created successfully.
Figure 34. Adding PRODUCTION_V2 Group under PRODUCTION_V1 Group
17.3.2 Move Version 1 Hierarchy Under Version 2

Now we want to move the Version 1 hierarchy under the Version 2 PRODUCTION group. On the Work with Groups Using PDM display, you should type option 2 (Change) beside the TEST group and press F4 (Prompt) . When the Change Group display appears, you must type PRODUCTION_V2 in the Parent group and Promote code prompt parameters. After this, move the TEST group under the PRODUCTION_V2 group. Figure 35 on page 140 shows the Change Group display that was used to move the TEST group under the PRODUCTION_V2 group.
139
Change Group (CHGGRP) Type choices, press Enter. Project . . . . . . . . . . . . > ORDER_ENTRY Name Group . . . . . . . . . . . . . > TEST Name Parent group . . . . . . . . . . PRODUCTION_V2 ___________________ Promote code . . . . . . . . . . PRODUCTION_V2 ___________________ Notify . . . . . . . . . . . . . *DEVELOPER *SAME, name, *NONE, *DEVELOPER PARTL required . . . . . . . . . *NO__ *SAME, *NO, *YES Text description . . . . . . . . > This is the TEST Group____________________ _______________________________________________________________________________ _______
F5=Refresh
F12=Cancel
Figure 35. Moving the Version 1 Hierarchy under the PRODUCTION_V2 Group
Figure 36 shows that the Version 1 hierarchy now is under Version 2 PRODUCTION group.
DEVSYS01
Type options, press Enter. 2=Change 4=Delete 25=Find string 29=Check in Opt ___ ___ ___ ___ ___ ___ ___ Level 01 02 02 03 04 05 05 Group COMMON PRODUCTION_V1 PRODUCTION_V2 TEST DEVELOPMENT PROGRAMMER1 PROGRAMMER2
Bottom Parameters or command ===> ________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F6=Create F9=Retrieve F10=Command entry F23=More options F24=More keys Group TEST changed.
Figure 36. Moving the TEST Group under the PRODUCTION_V2 Group
140
17.3.3 Change the Promote Code

Before changing any code for Version 2, you have to change the promote codes for the other groups in the project hierarchy. The PRODUCTION_V2 group should be used as the Promote code parameter for each group you change. To change the promote code using the Work with Groups Using PDM display, you should type option 2 (Change) beside each group and press F4 (Prompt) . When the Change Group display appears, you must type PRODUCTION_V2 in the Promote code prompt parameters as described previously in Figure 35 on page 140; or you can issue the following commands: To change the promote code for the DEVELOPMENT group:
CHGGRP PRJ(ORDER_ENTRY) GRP(DEVELOPMENT) PRMCODE(PRODUCTION_V2)

To change the promote code for the PROGRAMMER1 group:
CHGGRP PRJ(ORDER_ENTRY) GRP(PROGRAMMER1) PRMCODE(PRODUCTION_V2)

To change the promote code for the PROGRAMMER2 group:
CHGGRP PRJ(ORDER_ENTRY) GRP(PROGRAMMER2) PRMCODE(PRODUCTION_V2)

Note: You should always ensure that all parts are promoted to the PRODUCTION_V1 group before moving the groups. Figure 37 shows the promote codes for each group.
DEVSYS01
Type options, press Enter. 2=Change 4=Delete 25=Find string 29=Check in Opt ___ ___ ___ ___ ___ ___ ___ Level 01 02 02 03 04 05 05 Group COMMON PRODUCTION_V1 PRODUCTION_V2 TEST DEVELOPMENT PROGRAMMER1 PROGRAMMER2
Promote code COMMON PRODUCTION_V1 PRODUCTION_V2 PRODUCTION_V2 PRODUCTION_V2 PRODUCTION_V2 PRODUCTION_V2
Bottom Parameters or command ===> ________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F6=Create F9=Retrieve F10=Command entry F23=More options F24=More keys
Figure 37. Displaying the Promote Code for Each Group
You are now ready to start converting your OPM RPG Order Entry application to the ILE RPG environment using the Application Development Manager/400 product. The PRODUCTION_V1 group contains the production version of the Order Entry application, while all the other groups can be used to develop the follow-on version of the Order Entry application.
141
17.4 Application Development Manager/400 Summary

Using the Application Development Manager/400 product with our sample Order Entry application project provides an introduction of the product features. This high level approach supplies you with enough product details for a better understanding on how easy it is to import your existing application into an Application Development Manager/400 project, convert it, develop follow-on versions, or handle fixes.
142
Chapter 18. COoperative Development Environment/400

The Application Development ToolSet for OS/400 (ADTS) provides an integrated application development environment in the AS/400 system. It has three features: 1. The base product features provide a group of utilities that take care of the day-to-day programming activities such as code editing, display design, and data file management. 2. The Application Dictionary Services/400 (ADS/400) helps you with cross reference information about where files and fields are used in your application. This can be useful for scanning where date fields are found. 3. Application Development Manager/400 (ADM/400) helps you during the maintenance phase of the development. ADM/400 allows you to better manage changes across production and development environments. The Application Development ToolSet Client/Server for OS/400 (ADTS CS) is specifically intended for a client/server environment. It comes with two optional features: 1. VRPG Client feature is used for developing programs that run in the workstation (client/server) environment. This product is described in Chapter 15, Using VRPG Client/2 to Create Modern Applications on page 99. 2. The CODE/400 feature provides the edit/compile/debug facilities on the PC for developing AS/400 host programs. CODE/400 works not only seamlessly together with VRPG, but also with ADTS/400 and ADM/400 which run on the host system. All of these products together give you the tools to develop and maintain your application more efficiently and in less time.
18.1 Why Use CODE/400 for Development?

AS/400 programmers are familiar with the Application Development ToolSet utilities such as Programming Development Manager (PDM), Source Entry Utility (SEU) and Screen Design Utility (SDA). CODE/400 is a good addition to these development tools. It is easy to use and it provides key functions to enhance every programmer s productivity. The integration between the source editor, screen and report designer, program verifier, program compiler, and debugger makes it a powerful tool. CODE/400 is installed on the OS/2 platform to take advantage of its robust operating system and true multi-tasking capabilities. It relieves tying up the AS/400 resources in a production environment. Using CODE/400 is one step in the modernization process. Because CODE/400 and VRPG share many functions, you have one environment for both client and server application development. Programmers now do not have to switch between different work environments. Also CODE/400 makes better use of your PC processing capacity. It takes the load off of your AS/400 processor. Editing, program verification, and even invoking host program compilation can be done on the workstation. CODE/400 and VRPG Client/2, the two features of ADTS CS, have many common features:
143
The current version of CODE/400 works with WorkFrame/2 under OS/2. There will soon be versions of CODE/400 that work with Windows 95 and Windows NT as well. CODE and VRPG use the same source editor. Therefore, you can create server AS/400 RPG programs and client VRPG programs with the same editor. Debugging AS/400 server programs is the same as for the VRPG programs. You can start it from your workstation. Communication with the AS/400 system from the workstation is a function of CODE/400 also used by VRPG. If necessary, the client program automatically starts the connection to the AS/400 server.
18.2 The Functions of CODE/400

CODE/400 is a workstation-based suite of development tools for 3GL multi-user host application development. It runs under OS/2 (and soon under Windows 95 or Windows NT), yet offers a seamless connection to the AS/400 system. CODE/400 consists of:
A programmable editor (LPEX) with language sensitive features for RPG, ILE RPG, CL, ILE CL, COBOL, ILE COBOL, ILE C, REXX, and CMD sources. Local RPG and COBOL program verifiers that detect compile errors on the workstation before submitting the compile to the AS/400 system. An interface that invokes the AS/400 compilers and retrieving compiler errors back onto the workstation. A programmable debugging facility with source or listing view that finds the errors in your RPG, COBOL, and CL programs while they run on the AS/400 system. A design utility (DSU) that creates and maintains display, printer, physical files, and logical files. The GUI interface of the workstation makes it more powerful compared to the AS/400 utilities.
The programmable LPEX editor provides significant productivity improvements over the host-based edit and compile development process. The LPEX editor supports many of the SEU prefix area commands, allowing you to make the move to CODE/400 easier. Besides that, is has many additional functions:

Full online editor help Language sensitive help Local syntax checking on the PC RPG and COBOL program verification Language-specific format lines Prompting with pop-up windows Use of colors to make it easier to read the source The ability to edit multiple sources at the same time Copy and paste from one source to the other Submitting host compiles and binds directly from the source
Compile errors are returned directly to a workstation error feedback window, allowing the programmer to view second-level help. Also, with a mouse click on the error line, the cursor is positioned in the source to the line of code that has the error. This reduces the time and effort to get a clean and error free compile.
144
The CODE/400 programmable debugger allows you to watch each line of source executing as the program runs on the AS/400 system. What you can do is:

Look at the source or listing of a program while it runs. Debug ILE or OPM programs or mixed applications. Debug interactive, batch, or remote jobs. Single-step through the source. Step in or over subroutines. Set breakpoints simply by clicking on the source line. Set trace points. Watch variables as they change during program execution. View or change the value of variables simply by clicking on the variable in the displayed source code. Save/restore debugging information.
DSU provides you with a single WYSIWYG interface for developing display, printer, and database files, using the power of the GUI workstation and mouse to enhance the developers productivity over using host design tools. With DSU, you can:

Move, change, and delete fields using the mouse. Highlight several fields to move at the same time. Have open up to 15 design windows with a unlimited number of records on one design window. Have locally syntax and semantic checking without using AS/400 resources.
CODE/400 is the evolution of PDM, SEU, SDA, and RLU. It complements these trusted products by offering a workstation-based alternative. It promises and delivers higher productivity, host off-load, and a safe introduction into the exploding world of personal computers and client/server.
18.3 How CODE/400 Works

The work area of the LPEX editor shown in Figure 38 on page 146 looks the same as SEU on the AS/400 system. An additional function is the use of colors for the different statements and fields. This makes your source listing more readable. The pull-down menus from the action bar contain many programming functions. For instance, you can start the verification or compilation of your program directly from your editor with a simple mouse click.
145
Figure 38. LPEX - RPG Source Program
You can add or change statements directly in your source or you can use the prompt (F4) facility. The prompt window in Figure 39 is an example of a date compare prompt window. Pressing F1 gives you help windows, providing you with all the assistance needed.
Figure 39. LPEX - Calculation Prompt
Debugging on a graphical workstation is powerful because of the different windows you can open and watch. By just double-clicking on a statement, multiple breakpoints can be set. This simple step is also available for viewing variables. Just select the variables with the mouse. You can directly execute the program from the source in step mode as well as shown in Figure 40 on
146
page 147. During execution, the contents of the selected variables are shown in the variable window (or windows).
Figure 40. Debug - Execute/Step from Debug Window
CODE/400 provides programmers with significant functionality. With the Design Screen Utility (DSU), you can design display files, as well as physical, logical, and printer files. Figure 41 is an example of a physical file edit window.
Figure 41. DSU - Physical File Update
DSU has the same functions as Screen Design Aid (SDA); see Figure 42 on page 148 and Figure 43 on page 148. However, changing the date fields is an easier job on the PC because it allows you to select multiple fields by dragging a box around it and moving these fields to their new positions. You can change the characteristics of a date field with easy-to-use prompt windows. Figure 44 on page 149 is the prompt window for the field edit information.
147
Figure 42. DSU - Display File Records
Figure 43. DSU - Display File Work Display
148
Figure 44. DSU - Change Field Edit Attributes
For more information on CODE/400, please refer to the following manuals:

CODE/400 Debug Tool V3R1 , SC09-1905 CODE/400 Installation V3R1 , SC09-1908 LPEX Command Reference V3R1 , SC09-1910 CODE/400 V3R1 Self-Study Guide , SC09-1911 ADTS CS/400 V3R1 Intro to Application Development Using , SC09-1934 Introducing ADTS/400 & AS/400 Server Access Programs V3R1.0 , SC09-1939
149
150
Part 6. Appendices
This section provides additional information such as scenarios for converting to the Year 2000 and program listings from a demo program illustrating some of the application modernization functions. It includes:

Appendix Appendix Appendix Appendix Appendix
A, B, C, D, E,
Two Possible Scenarios for Year 2000 Conversion ADS/400 Date Scan Program RPG/400 Order Entry Program RPG IV Order Entry Program VRPG Order Entry Program
151
152
Appendix A. Two Possible Scenarios for Year 2000 Conversion

This appendix addresses two sets of considerations for Year 2000 conversion. Once you have determined the scope of your conversion effort according to the consideration factors identified in Section 7.2, Scope of Year 2000 Transition on page 27, you need to decide whether or not to use a Year 2000 tool. The following scenarios depend upon the size and complexity of your project in terms of money, human resources, and time constraints.
Manual conversion: This is the typical situation for small-to-medium sized applications. In this environment, the complexity is not great enough to justify a conversion tool. Therefore, you might modify your applications using AD development tools such as ADS/400 or CODE/400. In those situations, it may also be useful to consider re-engineering one or more of your applications using the ILE environment. Tools-aided conversion: This pertains more to the medium and large-sized applications. In this situation, the usage of a tool is strongly recommended to reduce the manual effort required. This brings down the cost of the conversion itself. For the test phase, it is difficult to find a simple, inexpensive, and efficient general test tool. Therefore, the testing should be done manually, and this probably becomes the brunt of the conversion cost.
One other major cost consideration is in the area of project management, for example, how to maintain the several versions of software and how to track the test status. Using both a Year 2000 tool and ADM/400 should provide a good solution. ADM/400 allows you to define the development (or conversion) and testing framework. For detailed information about ADM/400, see Chapter 17, Application Development Manager (ADM/400) on page 119.
A.1 Considerations for Conversion Without a Year 2000 Tool

In this scenario, your application s complexity is not great enough to justify a conversion tool. The decision is to modify it manually. The following list contains some tips to perform the application conversion. You need to set up new conversion libraries for source, program, and data objects in the same fashion as your production environment. In the library that contains your source files, you should copy all members from the related source files. Next, you should delete any members that are no longer used in your application. In addition, if you are going to use ADS/400 in this scenario, the recommendation is that you recompile every object at this point from the copied source in the new libraries. Otherwise, the copied objects retain the reference to the original libraries so that you cannot obtain an accurate inventory for your new environment. 1. Analyze and modify files: You should start your conversion by analyzing files, specifically, field reference and physical files. To identify the possible date fields in those files, the program dictionary of ADS/400 is a great help. In the Work with Fields display of ADS/400, you can use its text search function and a generic-search capability for field names, specifying keywords such as DATE , YEAR , DAY , and so on, as shown in Figure 45 on page 154.
153
Subset Fields to Work With Dictionary . . . . . : A960121DD
Type choices, press Enter. Field . . Record . . File . . . Library Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . YY* *ALL *ALL *ALL *ALL *ALL, name, generic* *ALL, name, generic* *ALL, name, generic* *ALL, name, generic* *ALL, attribute F4 for list
Text: Search words . . . . . . . . .
Search condition . . . . . . .
DATE DAY YEAR 1
1=Or, 2=And
F3=Exit
F4=Prompt
F5=Refresh
F12=Cancel
Figure 45. ADS/400 - Set Criteria for Date Related Field Selection
For an advanced search function, you can create a simple user program that queries the ADS/400 dictionary. A sample program is shown in Appendix B, ADS/400 Date Scan Program on page 165. Whether you use ADS/400 or SEU is irrelevant. In addition to looking for field names containing date references, the following list of keywords might be used in the string search function to find the possible date fields.
Table 5. DDS Keywords
Keywords DATFMT Description Along with data type (L), using the specification of *MDY, *DMY, and *YMD results in a two-digit year. Specification of this keyword results in a two-digit year. Specification of this keyword results in two-digit year. For Four-Digit Year Adaptation Change the specification into *ISO, *USA, *EUR, or *JIS for the four-digit year. If you specified DATFMT(*ISO), (*USA), (*EUR), or (*JIS), remove this keyword. Replace this keyword with EDTWRD( __/__/____) ( in the case of MDY). Replace this keyword with EDTWRD( __/__/____) ( in the case of MDY). Default format is YYYY-MM-DD, unless it comes with DATFMT specification. Refer to the usage of DATFMT in this table.
DATSEP EDTCDE(Y)
EDTWRD ( __/__/__) Data type (L)
Another recommendation is for you to examine your logical files as well. At this point, compile the modified files. ADS/400 helps you again in this step by providing the Work with Impacted Files display. In Figure 46 on page 155, you can see a physical file along with its related logical files, which allows you to delete, edit, and compile files from just one display.
154
Work with Impacted Files Dictionary . . . . . : Field . . . . . . . : File . . . . . . . . : A960121DD PRDEXP STOCK
Record . . . . . : Library . . . . :
STOCK A960121DA
Type options, press Enter. 2=Edit 4=Delete 10=Work with programs referencing file
9=Work with related files 14=Compile
Opt
Level 0 1 1
File STOCK STOCK01L STOCK02L
Library A960121DA A960121DA A960121DA
Attribute PF-DTA LF LF
Text Stock PF (Object does not exist.) (Object does not exist.)
Bottom F3=Exit F4=Prompt F5=Refresh F6=Work with objects to recreate F12=Cancel F21=Print list F24=More keys Job 212427/A960121D/STOCK01L submitted to job queue QBATCH in library QGPL. +
Figure 46. ADS/400 Sample Display - Compile Related Logical Files
2. Analyze and modify programs: Upon completion of the analysis and modification of the source file (DDS) for physical and logical files, proceed with analyzing the program source. In Figure 47 on page 156, ADS/400 helps you find the programs required for modification from the modified field of the file. This field file-program cross reference helps you not only track down all of the possible two-digit year usage in your programs, but also checks all of the programs that need to be recompiled due the file layout changes.
155
Work with Objects to Recreate Dictionary . . . . . : Object . . . . . . . : Library . . . . . : A960121DD STOCK A960121DA
Type . . . :
*FILE
Type options, press Enter. 2=Edit 16=Change compile command
4=Drop
Opt
Object CORD RSTO STOCK STOCK01L STOCK02L
Library A960121DA A960121DA A960121DA A960121DA A960121DA
Type *PGM *PGM *FILE *FILE *FILE
Attribute RPG RPG PF-DTA LF LF
Text Cancel Order Stock procedure <Y2K-ENAB Stock PF Primary key LF for STOCK LF FOR CATEGORY ON STOCK
F3=Exit F4=Prompt F11=Display more text
F5=Refresh F12=Cancel
Bottom F6=Submit recreate job F24=More keys
Figure 47. ADS/400 - Find Programs in Relation of Modified Field of a File
Using either ADS/400 or SEU, you can start searching for the known date field specifying the field name in the string search option. In addition to specifying the field name, the following list of keywords might be used to identify the possible date fields.
Table 6. RPG Keywords
Keywords DATFMT ILE/OPM ILE Description For the Control Specification Statement (H format) and for Definition Specification Statement (D format), it specifies the internal date format for the date fields. Using the specification of *MDY, *DMY, or *YMD results in a two-digit year. Retrieval of the job date with these keywords result in a two-digit year. These operations perform the date/time arithmetic, extract the portions from the date field, and test for valid fields. This is a good place to look. Retrieves the system date and time. SQL date, time, and timestamp data type support. For Four-Digit Year Adaptation Change the specification into *ISO, *USA, *EUR, or *JIS for the four-digit year.
UDATE, UYEAR ADDDUR, EXTRCT, SUBDUR, TEST TIME
ILE/OPM
Replace it with the keyword *DATE or *YEAR. Provides for both two-digit and four-digit years. Change the length of the fields.
ILE
ILE/OPM
Provides for both two-digit and four-digit years. Change the length of the fields. Provides for four-digit year.
SQL
ILE/OPM
156
Table 7. CL Tips
Keywords OPNQRYF Description Supports the date, time, and time-stamp comparisons, as well as the date arithmetic, which may involve durations. Also supports the build-in-functions such as %DATE, %YEAR, %TIMESTP %CURDATE, %DURYEAR, and %CURTIMESTP. Converts a date value from one format to another without changing its value. The current DATE parameter returns the six-digit date. Retrieves the operation date of the object/member of the file. For Four-Digit-Year Adaptation All functions in OPNQRYF support a four-digit year format. Change the length of the variables if the database has been changed to support a four-digit year.
CVTDAT
Provides for both two-digit and four-digit year formats. Change the length of the variables. Use the parameter CYMDDATE (new with V3R2), which provides seven-digit code as CYYMMDD. Already deploys the date format of CYYMMDDHHMMSS at V3R1.
RTVJOBA
RTVMBRD, RTVOBJD (CRT, EXP, CHG, SAV, RST, USE, RESETDATE) ADDJOBSCDE, CHGJOB, CHGJOBD, CHGJOBSCDE, CRTJOBD, SBMJOB RTVJRNE (STRDATE & ENDDATE)
Specifies the job date or the scheduled date.
All DATE parameters accept a four-digit year at OS/400 V3R2. As for the two-digit year, OS/400 uses the windowing technique so that year 40 through year 99 becomes 19YY, and year 00 through year 39 becomes 20YY. As mentioned in the preceding row, all DATE parameters accept a four-digit year at V3R2. In addition, ENTFMT(*type3) and ENTFMT(*type4) return ISO dated entry formats.
Specify the starting and ending date for the search of the journal entry.
Next, you need to check if your program that needs to be modified calls other programs and ensure that all date-related parameters are changed as well. ADS/400 helps you with options such as Work with Calling Programs or Work with Called Programs . Before starting to recompile the modified programs, you need to examine the related display and printer files as well. 3. Analyze and modify display files and printer files: To analyze the related display and printer files, ADS/400 once again helps you find the files that are used in your modified programs with its dictionary function shown in Figure 48 on page 158. From the Work with Files Used display, use option 6 = Design . This calls up the SDA display for your display file, or RLU display for the printer file, so that you can easily check if your expanded date field fits or overflows in the existing format. One consideration needs to be made beforehand. Not all date fields need to be expanded. If your current display format does not have any extra space for the date expansion, you might consider ignoring any non-impact (cosmetic) data fields in YY format. In this case, verify that they do not cause any data integrity exposures or ambiguity. Make sure that these date representations are meant for viewing only and not for computer program manipulation.
157
Work with Files Used Dictionary . . . . . : Program . . . . . . : Text . . . . . . . . : A960121DD CINS Library . . . . : A960121DA Insert order header - RPG version. <Y2K-enabled>
Type options, press Enter. 2=Edit 4=Delete 5=Display 10=Work with programs referencing file
6=Design 14=Compile ...
Opt
File CUS01L OHRD OHRD ORDH01L
Record CUSTOMER EXITLINE ORDER ORDERHDR
Use 01 03 03 03
Library A960121DA A960121DA A960121DA A960121DA
Attribute LF DSPF DSPF LF
Record text EXIT LINE ORDER ENTRY
F3=Exit F12=Cancel
F4=Prompt F16=User options
F5=Refresh F23=More options
Bottom F10=Command entry F24=More keys
Figure 48. ADS/400 - Find Display File in Relation to the Modified Program
Other than looking for field names containing date references, the following list of keywords can be used to isolate the possible date fields.
Table 8. DDS Keywords
Keywords EDTCDE(Y) EDTWRD ( __/__/__) DATE Specification of this keyword retrieves the job date and it comes with a two-digit year. Description Specification of this keyword results in a two-digit year. For Four-Digit Year Adaptation Replace this keyword with EDTWRD( __/__/____) ( in case of MDY). Replace this keyword with EDTWRD( __/__/____) ( in case of MDY). Leave it as is for the cosmetic data. Need to have some program logic to display a four-digit year instead of DATE.
When you are finished modifying all of the necessary source members, you can compile the files and programs using option 14 (=compile) either in ADS/400 or PDM. Make sure you compile in the correct order. Then you can proceed to the unit test phase. See Chapter 11, Testing Techniques for Year 2000 Changes on page 55 for the test considerations.
A.2 Considerations for Using Year 2000 Conversion Tools

In this scenario, your application s complexity is medium to high. Your decision is to use a reliable Year 2000 conversion tool. You need to exercise extreme caution in your tool selection as there are many varieties of tools available. Some of them may provide only the impact-analysis function, while others may only focus on performing automated source modification with statistical reports. You need to ensure that the selected tool provides the functions needed to meet your company s conversion objectives.
158
Here again, you need to set up new conversion libraries for source, program, and data objects in the same fashion as your production environment. Most of the conversion tools do require that you set up a new library so that the tool can copy the modified source into it. We recommend that you set up the conversion source libraries first in addition to the new libraries required by the tool. You should copy everything in your application, delete any source members/objects that are no longer used, and test them to ensure they work in the conversion environment correctly just as they do in the production environment. Then you can run your conversion tool within this conversion environment. This may take extra disk space but assures you of the most efficient and correct result of the conversion. The following list contains functions for successful Year 2000 conversions. You might use this as a checklist to find a tool best suited for your project.
Table 9 (Page 1 of 6). Year 2000 Impact Analysis/Conversion Tool System Requirements
Description Methodology Printed hard copy Interactive help text Environments Software platforms AS/400 native System/36 Environment System/38 Environment Tool execution environment Host PC National language enabled Priority 1 2 2 1 2 2 1 2 2
159
Description Features Object support File definition Externally described Program described File types Physical Logical Display Printer Communications Tape Diskette Languages RPG COBOL CL VRPG C PL/1 FORTRAN BASIC Environments OPM ILE Other Security Commands Data Queues Data areas Queries DFUs SQL File transfer definitions Tool documentation Printed hard copy Interactive help text Priority 1 1 1 1 1 1 1 2 3 3 1 1 1 3 3 3 3 3 1 2 1 1 1 1 2 2 2 2 1 2 2
160
Description Search / Modification Rules User maintainable system values (Modifiable at project/task/library/file & field levels) Converted date default format - *DATE, YYYYMMDD, and so on Converted year default format - YYYY, CYY, and so on Default format of existing data - MMDDYY, YYMMDD, and so on Upper/lower case support Controls Project/task capability Associations for: libraries, objects & object types Partition large application Create bridge program System management Checkpoint/restart capability Source change control - multi-programmer Process controls - movement throughout tool Statistics capability - Interactive display/report Number of affected files, fields, programs, and so on Number 100% convertible Number requiring manual review/conversion Time estimates - automatic and manual DASD requirements 1 1 2 2 1 2 1 1 1 Priority 1 1 1 1 1
161
Description Impact Analysis Confirm source/object match/existence Program to source match Missing source program Source to program match Missing executable program Date mismatch Object renamed Object moved User maintainable rules Field name include/exclude - starts/ends with, contains Field text keywords - contains Edit codes Edit words Object types/attributes where dates are used Possible date field lengths (2,4,5,6,7,8,12) & type (A/N) Variable selection of objects to be analyzed System date API support Physical data verification - MM field contains 01-12 Batch processing capability Interactive review of intermediate results Detail display with assurance level Manual confirm/delete/add Manual update of field format - MMDDYY, YYMMDD, and so on Manual update of display/printer edit code/word Interactive display of DDS source file record Interactive display of program source Interactive display of field physical data Printed report capability Cross-reference capability Copy books - use Forward and backward propagational analysis Manual conversion identified Priority 1 1 1 2 3 3 1 1 1 1 1 1 1
162
Description Source Conversion Variable selection of source to be converted Batch processing capability Provide comments in new source for lines added/changed/deleted Provide comments in new source for lines needing manual change Interactive list display of source members changed showing status Entry of physical file usage - permanent/temporary (no conversion) Interactive display/edit of changed source Ability to alter file layouts or calculations based on a future Printed report capability Drill down capability Object Conversion / Creation Variable selection of objects to be created Batch processing capability Controlled order of object type creation Dependent object automatic re-creation Automatic creation of data conversion program Printed report capability Data Conversion Variable selection of files to be converted Batch processing capability Data types Pre-test with all records Pre-test with record sample - user definable Production - live Ability to handle large files/limited DASD - copy from/to tape with re-formatting Printed report capability 1 2 1 2 2 2 1 1 2 1 2 2 Priority 1 2 1 1 1 1 -
1 2 1
163
Description Testing Capture Keystrokes Screens Reports Data file record adds/deletes/changes Playback Keystrokes Comparison Screens Reports Data file record adds/deletes/changes Exception reporting Priority 1 1 1 1 1
The functions of the selected tool must meet your company s Year 2000 requirements and objectives. Therefore, careful selection of the conversion tool is vital to the success of your project.
164
Appendix B. ADS/400 Date Scan Program

The following programs can help you scan ADS/400 field references to find possible date fields. They search field definitions and try to locate date fields according to the following basic rules: 1. Search all numeric fields with two, three, four, or six digits, or fields where the field name is the same as the heading or text for that field. 2. Identify field names or column headings with character patterns that may represent date, month, year, and so on. No special attention is given to upper or lower case characters.
INSPECT INSPECTFM INSPECT21 INSPECT21 PREPARE21
CLP DSPF QMQRY QMFORM QMQRY
Main program DSPF of main program QM query to print impact report QM form for printing QM query for filter function
The detailed listings are as follows: CL Main Program:

PGM DCL DCLF SNDRCVF IF CHGVAR IF OVRPRTF STRQMQRY VAR(&LV1) TYPE(*CHAR) LEN(25) FILE(INSPECTFM) RCDFMT(FMT01) COND(&IN03 *EQ 0 ) THEN(DO) VAR(&LV1) VALUE(&LIBADS *CAT / QDNDHFDA ) COND(&IN08 *EQ 1 ) THEN(DO) FILE(QPQXPRTF) TOFILE(QSYSPRT) QMQRY(INSPECT21) OUTPUT(*PRINT) + QMFORM(*QMQRY) SETVAR((V1 &LV1) (V2 + &TV1) (V3 &TV2) (V4 &TV3) (V5 &TV4) + (V6 &CV1) (V7 &CV2) (V8 &CV3) (V9 &CV4)) FILE(*PRTF) COND(&IN10 *EQ 1 ) THEN(DO) OBJ(QDNDHFDA) FROMLIB(&LIBADS) + OBJTYPE(*FILE) NEWOBJ(FLDBCK) DATA(*YES) MSGID(CPF0000) QMQRY(PREPARE21) OUTPUT(*) SETVAR((V1 +
DLTOVR ENDDO IF CRTDUPOBJ MONMSG STRQMQRY ENDDO ENDDO ENDPGM
DSPF for Main Program:

A*%%TS A*%%EC A A A*%%TS A A A A A A A A A A A A A A A A A A A A A A SD 19960516 115734 A960121A REL-V3R1M0 5763-PW1
DSPSIZ(24 80 *DS3) R FMT01 SD 19960516 115734 A960121A REL-V3R1M0 5763-PW1 CF03(03 end ) CF08(08 print ) CF10(10 go ) 1 2321 st Century Inspector for ADS/400 DSPATR(HI) 6 6 ADS/400 Library name: 22 1 DSPATR(UL) 23 2 F3=End F8=Print impact report F10=Convert ADS Dict. 11 6 Text search string...: 14 6 Colhdg search string: 9 26 ---------------------------------------------------- I 6 29DSPATR(HI) CHECK(ME) CHECK(RB) I 11 29DSPATR(HI) CHECK(ME) CHECK(RB)
LIBADS
10A
TV1
10A
165
A A A A A A A A A A A A A A A A A A A A A A A A A A A
CV1
10A
TV2
10A
TV3
10A
TV4
10A
CV2
10A
CV3
10A
CV4
10A
I 14 29DSPATR(HI) CHECK(ME) CHECK(RB) I 11 41DSPATR(HI) CHECK(ME) CHECK(RB) I 11 53DSPATR(HI) CHECK(ME) CHECK(RB) I 11 65DSPATR(HI) CHECK(ME) CHECK(RB) 8 29 Date Year Month Day I 14 41DSPATR(HI) CHECK(ME) CHECK(RB) I 14 53DSPATR(HI) CHECK(ME) CHECK(RB) I 14 65DSPATR(HI) CHECK(ME) CHECK(RB) 18 11 Example: 18 25 % Dat% 18 37 ( insert explicit single quote) DSPATR(HI)
QM Query for Print Report:

SELECT WHLIB, WHFILE, WHDCDL,WHNAME, WHFLDE, WHFLDT, WHFLDD , whftxt FROM &V1 WHERE ((WHFLDD in(2, 3, 4, 6)) or (TRANSLATE(WHFTXT) LIKE &V2) OR (TRANSLATE(WHFTXT) LIKE &V3) OR (TRANSLATE(WHFTXT) LIKE &V4) OR (TRANSLATE(WHFTXT) LIKE &V5) OR (TRANSLATE(WHCHD1) LIKE &V6) OR (TRANSLATE(WHCHD1) LIKE &V7) OR (TRANSLATE(WHCHD1) LIKE &V8) OR (TRANSLATE(WHCHD1) LIKE &V9) OR (TRANSLATE(WHCHD2) LIKE &V6) OR (TRANSLATE(WHCHD2) LIKE &V7) OR (TRANSLATE(WHCHD2) LIKE &V8) OR (TRANSLATE(WHCHD2) LIKE &V9) OR (TRANSLATE(WHCHD3) LIKE &V6) OR (TRANSLATE(WHCHD3) LIKE &V7) OR (TRANSLATE(WHCHD3) LIKE &V8) OR (TRANSLATE(WHCHD3) LIKE &V9)) AND (WHDCDL NOT IN( PF-SRC , PF-FRF ) ) ORDER BY WHLIB, WHFILE, WHNAME, WHFLDE
QM Query to Filter Data:

DELETE FROM &V1 WHERE NOT(((WHFLDD in(2, 3, 4, 6)) or (TRANSLATE(WHFTXT) LIKE &V2) OR (TRANSLATE(WHFTXT) LIKE &V3) OR (TRANSLATE(WHFTXT) LIKE &V4) OR (TRANSLATE(WHFTXT) LIKE &V5) OR (TRANSLATE(WHCHD1) LIKE &V6) OR (TRANSLATE(WHCHD1) LIKE &V7) OR (TRANSLATE(WHCHD1) LIKE &V8) OR (TRANSLATE(WHCHD1) LIKE &V9) OR (TRANSLATE(WHCHD2) LIKE &V6) OR (TRANSLATE(WHCHD2) LIKE &V7) OR (TRANSLATE(WHCHD2) LIKE &V8) OR (TRANSLATE(WHCHD2) LIKE &V9) OR (TRANSLATE(WHCHD3) LIKE &V6) OR (TRANSLATE(WHCHD3) LIKE &V7) OR (TRANSLATE(WHCHD3) LIKE &V8) OR (TRANSLATE(WHCHD3) LIKE &V9)) AND (WHDCDL NOT IN( PF-SRC , PF-FRF ) ) )
QM Form to Print Summary of Date Field:

Query Management/400 763SS1 V3R1M0 Form . . . . . Library . . Text . . . . . Nbr 1 2 3 4 5 6 7 8 940909 . . : . . : . . : INSPECT21 A960121ADS Field impact report Usage BREAK1 BREAK2 Type Column Information Indent Width 2 10 2 10 2 10 2 10 2 10 2 5 2 6 2 50 Edit Seq 1 2 3 4 5 6 7 8
Heading Library File File_type Record_Format External_Field Name Field_Type Number_Of_Digits Field Text_Descripti on
COUNT
166
Page Information Heading text . . . . . . . . . . . . . . . : YES Blank lines before heading . . . . . . . . : 0 Blank lines after heading . . . . . . . . . : 2 Line Align Heading Text 1 CENTER Possible data filed in application 2 CENTER ======================================================= 3 LEFT match criteria: numeric field with 2, 3, 4, 6 digits 4 LEFT field same as text or column heading 5 LEFT selected substring 6 CENTER ======================================================= Footing text . . . . . . . . . . . . . . . : YES Blank lines before footing . . . . . . . . : 2 Blank lines after footing . . . . . . . . . : 0 Line Align Footing Text 1 CENTER ADS/400 21st Century Impact analysis Final Information Final text . . . . . . . . . . . . . . . . : NO New page for final text . . . . . . . . . . : NO Put final summary at line . . . . . . . . . : 1 Blank lines before text . . . . . . . . . . : 0 Break Information Break number . . . . . . . . . . . . . Columns with this break number . . . . Heading text . . . . . . . . . . . . . New page for heading . . . . . . . . . Blank lines before heading . . . . . . Blank lines after heading . . . . . . . Repeat column headings . . . . . . . . Footing text . . . . . . . . . . . . . New page for footing . . . . . . . . . Blank lines before footing . . . . . . Blank lines after footing . . . . . . . Put break summary at line . . . . . . . Line Align Footing Text 1 RIGHT Inspected field for lib. Break number . . . . . . . . . . Columns with this break number . Heading text . . . . . . . . . . New page for heading . . . . . . Blank lines before heading . . . Blank lines after heading . . . . Repeat column headings . . . . . Footing text . . . . . . . . . . New page for footing . . . . . . Blank lines before footing . . . Blank lines after footing . . . . Put break summary at line . . . . Line Align Footing Text 1 RIGHT Inspected field for Detail line spacing . . . . . . . Outlining for break columns . . . Default break text . . . . . . . Column wrapped lines kept on page Column heading separators . . . . Break summary separators . . . . Final summary separators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : 1 1 NO NO 0 0 NO YES YES 0 1 1
&1: Break Information . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : 2 2 NO NO 0 0 NO YES NO 0 1 1
file &2: Option Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : 1 YES YES YES YES YES YES
Appendix B. ADS/400 Date Scan Program
167
168
Appendix C. RPG/400 Order Entry Program

5763RG1 V3R1M0 940909 Compiler . . . . . . . . . . Command Options: Program . . . . . . . . . Source file . . . . . . . Source member . . . . . . Source listing options . . Generation options . . . . Source listing indentation Type conversion options . Sort sequence . . . . . . Language identifier . . . SAA flagging . . . . . . . Generation severity level Print file . . . . . . . . Replace program . . . . . Target release . . . . . . User profile . . . . . . . Authority . . . . . . . . Text . . . . . . . . . . . Phase trace . . . . . . . Intermediate text dump . . Snap dump . . . . . . . . Codelist . . . . . . . . . Ignore decimal data error Allow null values . . . . Actual Program Source: Member . . . . . . . . . . File . . . . . . . . . . . Library . . . . . . . . . Last Change . . . . . . . Description . . . . . . . IBM RPG/400 IBM RPG/400 A960121C/ORDENT A960121C/QRPGSRC *PGM *SOURCE *NOXREF *NOLIST *NOXREF *NONE *NONE *HEX *JOBRUN *NOFLAG 9 *LIBL/QSYSPRT *YES *CURRENT *USER *LIBCRTAUT *SRCMBRTXT *NO *NONE *NONE *NONE *NO *NO ORDENT QRPGSRC A960121C 05/30/96 11:11:13 Order Entry program A960121C/ORDENT 06/03/96 16:57:10 Page 1
. . . : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : : : : : : : : : : : : : : : : :
*GEN *NOATR
*NODUMP *NODUMP
*NOSECLVL *NOSRCDBG *NOOPTIMIZE
*NOLSTDBG
169
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE S o u r c e L i s t i n g H 100 FORDENTWSCF E WORKSTN 200 F DSPMSGD KRENAMEDSPM 300 F REC1 KSFILE SFL01R RECORD FORMAT(S): LIBRARY A960121C FILE ORDENTWS. EXTERNAL FORMAT ORDER RPG NAME ORDER EXTERNAL FORMAT EXITLINE RPG NAME EXITLINE EXTERNAL FORMAT SFL01R RPG NAME SFL01R EXTERNAL FORMAT SFL01C RPG NAME SFL01C EXTERNAL FORMAT FOOT RPG NAME FOOT EXTERNAL FORMAT LINE RPG NAME LINE EXTERNAL FORMAT DSPMSGD RPG NAME DSPM EXTERNAL FORMAT FNLORDR RPG NAME FNLORDR 400 FRSTRL IF E K DISK RECORD FORMAT(S): LIBRARY A960121 FILE RSTRL. EXTERNAL FORMAT HDR RPG NAME HDR 500 FCUS01L UF E K DISK KCOMIT RECORD FORMAT(S): LIBRARY A960121 FILE CUS01L. EXTERNAL FORMAT CUSTOMER RPG NAME CUSTOMER 600 FORDH01L UF E K DISK KCOMIT A RECORD FORMAT(S): LIBRARY A960121 FILE ORDH01L. EXTERNAL FORMAT ORDERHDR RPG NAME ORDERHDR 700 FORDD01L UF E K DISK KCOMIT A RECORD FORMAT(S): LIBRARY A960121 FILE ORDD01L. EXTERNAL FORMAT ORDERDTL RPG NAME ORDERDTL 800 FSALC01L UF E K DISK KCOMIT RECORD FORMAT(S): LIBRARY A960121 FILE SALC01L. EXTERNAL FORMAT SALESCUS RPG NAME SALESCUS 900 FSTOCK01LUF E K DISK KCOMIT RECORD FORMAT(S): LIBRARY A960121 FILE STOCK01L. EXTERNAL FORMAT STOCK RPG NAME STOCK 1000 FSTOCK02LUF E K DISK KCOMIT 1100 F STOCK KRENAMESTOCK2 RECORD FORMAT(S): LIBRARY A960121 FILE STOCK02L. EXTERNAL FORMAT STOCK RPG NAME STOCK2 1200 I JOBI0400 C JB400 A000000 INPUT FIELDS FOR RECORD ORDER FILE ORDENTWS FORMAT ORDER. A000000 ORDER ENTRY A000001 1 5 CUSNBR A000002 6 110ORHDTE A000003 12 170ORHDLY B000000 INPUT FIELDS FOR RECORD EXITLINE FILE ORDENTWS FORMAT EXITLINE.
DO NUM
06/03/96 LAST UPDATE
16:57:10 Page PAGE PROGRAM LINE ID *****
05/20/96 05/20/96 05/20/96
05/20/96
05/20/96
05/20/96
05/20/96
05/20/96
05/20/96
05/29/96 05/29/96
05/20/96
170
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT 06/03/96 SEQUENCE IND DO LAST NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE NUM UPDATE B000000 EXIT LINE C000000 INPUT FIELDS FOR RECORD SFL01R FILE ORDENTWS FORMAT SFL01R. C000001 1 1 CHOICE C000002 2 21 DDESCR C000003 22 282DPRICE C000004 29 372DITTOT C000005 38 420SFQTY C000006 43 47 SFCODE C000007 48 48 ALTFLD D000000 INPUT FIELDS FOR RECORD SFL01C FILE ORDENTWS FORMAT SFL01C. D000001 1 40REC1 D000002 5 9 DPRDNR D000003 10 140DQUANT E000000 INPUT FIELDS FOR RECORD FOOT FILE ORDENTWS FORMAT FOOT. F000000 INPUT FIELDS FOR RECORD LINE FILE ORDENTWS FORMAT LINE. G000000 INPUT FIELDS FOR RECORD DSPM FILE ORDENTWS FORMAT DSPMSGD. H000000 INPUT FIELDS FOR RECORD FNLORDR FILE ORDENTWS FORMAT FNLORDR. I000000 INPUT FIELDS FOR RECORD HDR FILE RSTRL FORMAT HDR. I000001 1 5 ORHNBR NUMBER I000002 6 15 SRNBR SESSION NUMBER I000003 P 16 212ORHTOT TOTAL VALUE J000000 INPUT FIELDS FOR RECORD CUSTOMER FILE CUS01L FORMAT CUSTOMER. J000001 1 5 CUSNBR CODE J000002 6 25 CUSNAM NAME J000003 26 40 CUSTEL TEL. NBR. J000004 41 55 CUSFAX FAX NBR. J000005 56 75 CUSADR ADDRESS J000006 76 95 CUSCTY CITY J000007 96 100 CUSZIP ZIP CODE J000008 P 101 1062CUSCRD CREDIT LIMIT J000009 P 107 1122CUSTOT TOTAL ORDERED K000000 INPUT FIELDS FOR RECORD ORDERHDR FILE ORDH01L FORMAT ORDERHDR. K000001 1 5 ORHNBR NUMBER K000002 6 10 CUSNBR CUSTOMER CODE K000003 P 11 140ORHDTA ORDER DATE !!! K000004 P 15 180ORHDLY DELIVERY DATE !!! K000005 P 19 242ORHTOT TOTAL VALUE K000006 25 34 SRNBR SESSION NUMBER L000000 INPUT FIELDS FOR RECORD ORDERDTL FILE ORDD01L FORMAT ORDERDTL. L000001 1 5 ORHNBR NUMBER L000002 6 10 PRDNBR PRODUCT CODE L000003 P 11 130ORDQTY PROD. QUANTITY L000004 P 14 182ORDTOT ITEM VALUE L000005 19 19 PRDALT ALTERNATIVE PRD. M000000 INPUT FIELDS FOR RECORD SALESCUS FILE SALC01L FORMAT SALESCUS. M000001 1 10 SRNBR SR CODE M000002 11 15 CUSNBR CUSTOMER CODE M000003 P 16 212SRAMT TOTAL FOR SR N000000 INPUT FIELDS FOR RECORD STOCK FILE STOCK01L FORMAT STOCK. N000001 1 5 PRDNBR CODE N000002 6 25 PRDDES DESCRIPTION N000003 P 26 290PRDEXP EXPIRE DATE N000004 P 30 332PRDPRC PRICE N000005 P 34 360PRDQTA ORDERABLE QTA
16:57:10 Page PAGE PROGRAM LINE ID
171
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT 06/03/96 16:57:10 Page SEQUENCE IND DO LAST PAGE PROGRAM NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE NUM UPDATE LINE ID N000006 37 41 SPLNBR SUPPLIER CODE N000007 42 45 PRDCAT CATEGORY N000008 P 46 480PRDQTM MINIMUN QTA O000000 INPUT FIELDS FOR RECORD STOCK2 FILE STOCK02L FORMAT STOCK. O000001 1 5 PRDNBR CODE O000002 6 25 PRDDES DESCRIPTION O000003 P 26 290PRDEXP EXPIRE DATE O000004 P 30 332PRDPRC PRICE O000005 P 34 360PRDQTA ORDERABLE QTA O000006 37 41 SPLNBR SUPPLIER CODE O000007 42 45 PRDCAT CATEGORY O000008 P 46 480PRDQTM MINIMUN QTA 1300 IJAREA DS 05/20/96 1400 I B 1 40BRTN 05/20/96 1500 I B 5 80BAVA 05/20/96 1600 I 9 18 JBNAME 05/20/96 1700 I 19 28 UNAME 05/20/96 1800 I 29 34 JBNBR 05/20/96 1900 I 35 50 JOBID 05/20/96 2000 I 1 50 RTVJOB 05/20/96 2100 I B 51 540JOBLEN 05/20/96 2200 I 55 62 JOBFMT 05/20/96 2300 I 63 88 JOBNAM 05/20/96 2400 IHVAR DS 05/20/96 2500 I 1 5 ORHNBR 05/20/96 2600 * 05/20/96 2700 I AUTHORIZATION DENC MSG1 05/20/96 2800 I IED FOR THIS CUSTO05/20/96 2900 I MER 05/20/96 3000 * 05/20/96 3100 IFLDS DS 05/20/96 3200 I B 1 40MSGLEN 05/20/96 3300 I B 5 80PGMSTK 05/20/96 3400 I B 9 120RTVLEN 05/20/96 3500 IINDDS DS 05/20/96 3600 I B 1 20IND1 05/20/96 3700 I B 3 40IND2 05/20/96 3800 I B 5 60IND3 05/20/96 3900 I B 7 80IND4 05/20/96 4000 I DS 05/29/96 4100 I 1 60DTE 05/29/96 4200 I 1 20MM 05/29/96 4300 I 3 40DD 05/29/96 4400 I 5 60YY 05/29/96 4500 I DS 05/29/96 4600 I 1 60DTE1 05/29/96 4700 I 1 20YY1 05/29/96 4800 I 3 40MM1 05/29/96 4900 I 5 60DD1 05/29/96
172
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 5100 ******************************************************************** 5200 * 5300 * K E Y L I S T S A N D F I E L D D E F I N I T I O N S 5400 * 5500 ******************************************************************** 5600 C *LIKE DEFN ORHNBR NBR 5700 C *LIKE DEFN CUSNBR CODE 5800 C *LIKE DEFN ORHTOT PORDT 5900 C *LIKE DEFN CUSNBR CUSNO 6000 C *LIKE DEFN ORHNBR NEWORD 6100 * 6200 C NBRKL KLIST 6300 C KFLD NBR 6400 * 6500 C DTLK KLIST 6600 C KFLD ORHNBR 6700 C KFLD PRDNBR 6800 * 6900 C ORDH KLIST 7000 C KFLD ORHNBR 7100 * 7200 C CUST KLIST 7300 C KFLD CUSNBR 7400 * 7500 C SALC KLIST 7600 C KFLD SRNBR 7700 * 7800 C PRDK KLIST 7900 C KFLD PRDNBR 8000 * 8100 C PLIST2 PLIST 8200 C PARM RTVVAR 61 8300 C PARM RTVLEN 8400 C PARM RTVFMT 8 8500 C PARM RTVNAM 26 8600 C PARM RTVID 16 8700 * 8800 C KEYFLD KLIST 8900 C KFLD SRNBR 9000 C KFLD CUSNBR 9100 C*********** KFLD PARM1 9200 C************ KFLD PARM2
DO NUM
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/20/96 ****** 05/20/96 * 05/20/96 * 05/20/96 * 05/20/96 ****** 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96
173
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 9400 ******************************************************************** 9500 * 9600 * M A I N L I N E 9700 * 9800 ******************************************************************** 9900 C MOVEL 0 OK 1 10000 * LenDH++--== 10100 C OK DOWNE 2 10200 C MOVEL*BLANKS CUSNBR 5 10300 C MOVEL*BLANKS ORHNBR 5 10400 C Z-ADD0 TOTAMT 112 10500 C EXSR SRRSTR RESTART 10600 C EXSR SRCINS 10700 * LenDH++--== 10800 C OK IFEQ 0 10900 C EXSR SRRIDT 11000 C OK IFEQ 0 11100 C EXSR SRFNLO 11200 C SETOF 03 1 11300 C ENDIF 11400 C ENDIF 11500 * 11600 C OK IFEQ 1 11700 C EXSR SRCORD 11800 C ENDIF 11900 C ENDDO 12000 * 12100 C MOVE 1 *INLR 12300 12400 12500 12600 12700 12800 12900 13000 13100 13200 13300 13400 13600 13700 13800 13900 14000 14100 14200 DLTPRD BEGSR ************************************************* * * ************************************************* C DTLK CHAINORDD01L 82 C N82 DELETORDERDTL C EXSR SUBTR C SETON 23 C UPDATSFL01R C SETOF 23 * LenDH++--== C ENDSR ERR BEGSR ***************************************************** * * ***************************************************** C MOVE 1 RTNCD C EXFMTFNLORDR C ENDSR C C
DO NUM
B001 001 001 001 001 001 B002 002 B003 003 003 E003 E002 B002 002 E002 E001
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/20/96 ****** 05/20/96 * 05/20/96 * 05/20/96 * 05/20/96 ****** 11/29/94 05/20/96 05/09/96 11/29/94 11/29/94 11/29/94 05/20/96 05/20/96 05/20/96 11/29/94 05/20/96 11/29/94 05/20/96 05/21/96 11/29/94 11/29/94 05/20/96 11/29/94 05/20/96 11/29/94 05/09/96 05/20/96 05/21/96 05/20/96 05/29/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96
1 1
174
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 14400 C INIHDR BEGSR 14500 ***************************************************** 14600 * INITIALISE FIELDS FOR NEW ORDER HEADER INFO * 14700 ***************************************************** 14800 C Z-ADD0 BAVA 14900 C Z-ADD0 BRTN 15000 C Z-ADD50 JOBLEN 15100 C MOVEL * JOBNAM 15200 C MOVEL*BLANKS JOBID 15300 C MOVELJB400 JOBFMT 15400 C MOVELDATE1 ORHDTE 15500 C MOVELDATE2 ORHDLY 15600 * LenDH++--== 15700 C ENDSR 15900 16000 16100 16200 16300 16400 16500 16600 16700 16800 16900 17000 17100 17200 17300 17400 17500 17600 17700 17800 17900 18100 18200 18300 18400 18500 18600 18700 18800 18900 19000 19100 19200 19300 MAXKEY BEGSR ***************************************************** * * ***************************************************** C MOVE *HIVAL NBR C NBRKL SETLLORDH01L C READPORDH01L 99 * LenDH++--== C *IN99 IFEQ *ON C Z-ADD1 AP1 50 C ELSE C MOVELORHNBR AP1 C ADD 1 AP1 C ENDIF * LenDH++--== C CLEARORDERHDR C MOVELAP1 NEWORD C MOVELAP1 ORHNBR C MOVELAP1 NBR * LenDH++--== C ENDSR ORDENT BEGSR ***************************************************** * * ***************************************************** C MOVE *BLANKS CUSDES C EXSR WRRD C CUSNO CHAINCUS01L 16 C Z-ADD0 OTOT 92 * LenDH++--== C *IN03 IFEQ 0 C *IN16 ANDNE 1 C MOVE NEWORD ORHNBR C MOVE UNAME SRNBR C C
DO NUM
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/20/96 05/29/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96 05/29/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96
3 B001 001 X001 001 001 E001
B001 001 001 001
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 19400 C MOVE CUSNO CUSNBR 19500 C MOVE OTOT ORHTOT 19600 C MOVE ORHDTE ORHDTA 19700 C WRITEORDERHDR 19800 C Z-ADD1 INSOK 19900 C MOVELCUSNAM CUSDES 20000 C WRITEORDER 20100 C ELSE 20200 C 16 SETON 98 1 20300 C ENDIF 20400 * LenDH++--== 20500 C ENDSR
DO NUM 001 001 001 001 001 001 001 X001 001 E001
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96
175
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 20700 C RSTO BEGSR 20800 ***************************************************** 20900 * CHECK PRODUCT REQUESTED. * 21000 ***************************************************** 21100 C MOVE *ZERO WQTA 50 21200 C MOVE *BLANK WCAT 4 21300 * 21400 C STK1 KLIST 21500 C KFLD DPRDNR 21600 C STK2 KLIST 21700 C KFLD WCAT 21800 * 21900 C Z-ADDORHDLY DTE 22000 C EXSR CVTDTE 22100 C Z-ADDDTE1 DELDT 60 22200 C* 22300 C STK1 CHAINSTOCK01L 80 1 22400 C* 22500 C *IN80 IFEQ *ON 22600 C MOVE -1 IND1 22700 C MOVE *ZERO IND3 22800 C MOVE *BLANK DDESCR 22900 C MOVE *ZERO DPRICE 23000 C GOTO DONE0 23100 C ELSE 23200 C Z-ADDPRDEXP DTE 23300 C EXSR CVTDTE 23400 C Z-ADDDTE1 EXPDT 60 23500 C EXPDT IFGE DELDT 23600 C Z-ADDPRDQTA WQTA 23700 C Z-ADDPRDPRC DPRICE 23800 C MOVE PRDCAT WCAT 23900 C MOVE PRDDES DDESCR 24000 C ENDIF 24100 C ENDIF 24200 C* 24300 C* If the available quantity is enough to meet the ordered 24400 C* quantity, the product record is updated and the product 24500 C* information is passed back to the calling subroutine. 24600 C* 24700 C WQTA IFGE DQUANT 24800 C WQTA SUB DQUANT LEFTQ 50 24900 C Z-ADDLEFTQ PRDQTA 25000 C UPDATSTOCK 25100 C MOVE *ZERO IND1 25200 C MOVE *ZERO IND3 25300 C GOTO DONE0 25400 C ELSE 25500 C *LOVAL SETLLSTOCK01L 25600 C END 25700 C* 25800 C* If there is not enough quantity for the customer-ordered 25900 C* OR EXPIR DATE OF PRODUCT IF NOT COMPATIBLE WITH DELIVERY ORDER DA 26000 C* ,an alternative within same product category number is
DO NUM
B001 001 001 001 001 001 X001 001 001 001 B002 002 002 002 002 E002 E001
B001 001 001 001 001 001 001 X001 001 E001
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 TE 05/29/96
176
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 26100 C* searched. 26200 C* We assume that we ll pass back only the first one to the 26300 C* calling subroutine even though there may be several alternatives 26400 C* in the STOCK file. 26500 C* 26600 C STK2 SETLLSTOCK02L 26700 C SETOF 81 1 26800 C STK2 READESTOCK02L 81 3 26900 C Z-ADDPRDEXP DTE 27000 C EXSR CVTDTE 27100 C Z-ADDDTE1 EXPDT 60 27200 C *IN81 DOWEQ*OFF 27300 C PRDQTA ANDLTDQUANT 27400 C EXPDT ANDGTDELDT 27500 C STK2 READESTOCK02L 81 3 27600 C *IN81 IFEQ *OFF 27700 C Z-ADDPRDEXP DTE 27800 C EXSR CVTDTE 27900 C Z-ADDDTE1 EXPDT 60 28000 C ENDIF 28100 C ENDDO 28200 C* 28300 C *IN81 IFEQ *OFF 28400 C MOVE PRDNBR DPRDNR 28500 C MOVE PRDDES DDESCR 28600 C MOVE PRDPRC DPRICE 28700 C Z-ADDPRDQTA WQTA 28800 C ELSE 28900 C EXPDT IFGT DELDT 29000 C MOVE -1 IND3 29100 C ELSE 29200 C MOVE -1 IND4 29300 C ENDIF 29400 C MOVE *ZERO IND1 29500 C MOVE *BLANK DDESCR 29600 C MOVE *ZERO DPRICE 29700 C GOTO DONE1 29800 C ENDIF 29900 C* 30000 C WQTA SUB DQUANT LEFTQ 30100 C Z-ADDLEFTQ PRDQTA 30200 C UPDATSTOCK2 30300 C* 30400 C MOVE *ZERO IND1 30500 C MOVE *ZERO IND3 30600 C* 30700 C DONE1 TAG 30800 C DONE0 TAG 30900 * 31000 C ENDSR 31100 ***************************************************** 31200 *COVERT DATE FROM MDY TO YMD FORMAT * 31300 ***************************************************** 31400 C CVTDTE BEGSR
DO NUM
B001 001 001 001 B002 002 002 002 E002 E001 B001 001 001 001 001 X001 B002 002 X002 002 E002 001 001 001 001 E001
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96 05/29/96
10
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 31500 C MOVE YY YY1 31600 C MOVE MM MM1 31700 C MOVE DD DD1 31800 C ENDSR
DO NUM
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/29/96 05/29/96 05/29/96 05/29/96
11
177
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 32000 C SRCINS BEGSR 32100 ***************************************************** 32200 * INSERT ORDER HEADER DETAILS * 32300 ***************************************************** 32400 * LenDH++--== 32500 C MOVE UDATE DATE1 60 32600 C MOVE DATE1 APP 20 32700 C ADD 1 APP 32800 C MOVELDATE1 DATE2 60 32900 C MOVE APP DATE2 33000 C EXSR MAXKEY GET NEW N. ORD. 33100 C EXSR INIHDR 33200 * LenDH++--== 33300 C********** CALL QUSRJOBI 33400 C************* PARM RTVJOB 33500 C********** PARM JOBLEN 33600 C*********** PARM JOBFMT 33700 C************ PARM JOBNAM 33800 C************ PARM JOBID 33900 * LenDH++--== 34000 C************ MOVELRTVJBA JAREA 34100 C MOVEL 0 OK 34200 C Z-ADD0 INSOK 10 34300 C SETOF 15 1 34400 C WRITEEXITLINE 34500 C MOVELNEWORD ORHNBR 34600 C******************* MOVELORHNBR ORDNO 34700 C SETON 50 1 34800 * LenDH++--== 34900 C *IN03 DOWNE 1 35000 C INSOK ANDNE1 35100 C EXSR ORDENT 35200 C ENDDO 35300 * 35400 C *IN03 IFEQ 1 35500 C MOVE 2 OK 35600 C ELSE 35700 * LenDH++--== 35800 C INSOK IFEQ 1 35900 C MOVE 0 OK 36000 C COMIT 36100 C ELSE 36200 C MOVE 3 OK 36300 C ROLBK 36400 C ENDIF 36500 * 36600 C ENDIF 36700 * LenDH++--== 36800 C ENDSR 37000 37100 C SRCORD BEGSR *****************************************************
DO NUM
B001 001 001 E001 B001 001 X001 B002 002 002 X002 002 002 E002 E001
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/20/96 05/29/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96
12
178
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 37200 * * 37300 ***************************************************** 37400 C ORDH SETLLORDD01L 37500 C SETOF 80 1 37600 C ORDH READEORDD01L 80 3 37700 * LenDH++--== 37800 C *IN80 DOWEQ*OFF 37900 C PRDK CHAINSTOCK01L 81 1 38000 C *IN81 IFEQ *OFF 38100 C ADD ORDQTY PRDQTA 38200 C UPDATSTOCK 38300 C ENDIF 38400 C DELETORDERDTL 38500 C ORDH READEORDD01L 80 3 38600 C ENDDO 38700 * LenDH++--== 38800 C ORDH CHAINORDH01L 80 1 38900 C N80 DELETORDERHDR 39000 C COMIT 39100 * LenDH++--== 39200 C ENDSR 39400 39500 39600 39700 39800 39900 40000 40100 40200 40300 40400 40500 40600 40700 40800 40900 41000 41100 41200 41300 41400 41500 41600 41700 41800 41900 42000 42100 42200 42300 SRFNLO BEGSR ***************************************************** * * ***************************************************** C MOVE *BLANK WSR 10 C SETOF 01 * * If the total order amount is greater than the customer s * credit limit, the program displays an error message. * C CUST CHAINCUS01L 80 * LenDH++--== C *IN80 IFEQ *OFF * C CUSCRD IFGE PORDT C ADD PORDT CUSTOT C UPDATCUSTOMER C ELSE C SETON 6601 C ENDIF * LenDH++--== C ELSE C SETON 6601 C ENDIF * * The total order amount is added to the sales_rep s amount. * LenDH++--== C ORDH CHAINORDH01L 80 C *IN80 IFEQ *OFF C SALC CHAINSALC01L 81 C
DO NUM
B001 001 B002 002 002 E002 001 001 E001
13
1 B001 B002 002 002 X002 002 E002 X001 001 E001
1 2
1 2
1 1 B001 001
179
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 42400 C *IN81 IFEQ *OFF 42500 C ADD PORDT SRAMT 42600 C UPDATSALESCUS 42700 C ELSE 42800 C SETON 4401 1 2 42900 C ENDIF 43000 C ENDIF 43100 * 43200 C ORDH CHAINORDH01L 80 1 43300 * LenDH++--== 43400 C *IN80 IFEQ *OFF 43500 C Z-ADDPORDT ORHTOT 43600 C MOVE 0 OKAUD 1 43700 C EXSR SRRADT 43800 * LenDH++--== 43900 C OKAUD IFEQ 0 44000 C UPDATORDERHDR 81 2 44100 C 81 SETON 7701 1 2 44200 C ELSE 44300 C *LOVAL SETLLORDH01L 80 1 44400 C ROLBK 44500 C EXSR SRCORD 44600 C SETON 77 NO ROLBK LAST 1 44700 C ENDIF 44800 * LenDH++--== 44900 C ELSE 45000 C SETON 7701 1 2 45100 * 45200 C ENDIF 45300 C* 45400 C *IN01 IFEQ *OFF 45500 C MOVE 0 RTNCD 45600 C COMIT 45700 C ELSE 45800 C MOVE 1 RTNCD 45900 C* EXSR ERR 46000 C ROLBK 46100 C ENDIF 46200 * LenDH++--== 46300 C ENDSR 46500 46600 46700 46800 46900 47000 47100 47200 47300 47400 47500 SRRADT BEGSR ***************************************************** * GET THE USERID * ***************************************************** C Z-ADD61 RTVLEN C MOVEL JOBI0400 RTVFMT C MOVEL * RTVNAM P C MOVE RTVID P C************** CALL QUSRJOBI PLIST2 C************** MOVE RTVVAR RTVAPI C KEYFLD CHAINSALC01L 71 C
DO NUM B002 002 002 X002 002 E002 E001
B001 001 001 001 B002 002 002 X002 002 002 002 002 E002 X001 001 E001 B001 001 001 X001 001 001 E001
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 DELETE 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96
14
180
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 47600 * LenDH++--== 47700 C *IN71 IFEQ 1 47800 C MOVELMSG1 MSGFLD 47900 C EXFMTDSPM 48000 C MOVE 1 OKAUD 48100 C******* MOVE 1 PARM3 48200 C ENDIF 48300 * LenDH++--== 48400 C ENDSR 48600 48700 48800 48900 49000 49100 49200 49300 49400 49500 49600 49700 49800 49900 50000 50100 50200 50300 50400 50500 50600 50700 50800 50900 51000 51100 51200 51300 51400 51500 51600 51700 51800 51900 52000 52100 52200 52300 52400 52500 52600 52700 SRRIDT BEGSR ***************************************************** * * ***************************************************** C ORDH CHAINORDH01L 99 C Z-ADD0 DODCUM C MOVE 0 OK C Z-ADD0 REC1 C WRITELINE C SETON 52 C WRITESFL01C C SETOF 522223 * LenDH++--== C *IN03 DOWEQ*OFF C MOVE *BLANK DPRDNR C Z-ADD0 DQUANT C N65N66N68 WRITEFOOT C 22 SETON 50 C SETON 51 C EXFMTSFL01C C SETOF 505168 C SETOF 636465 * LenDH++--== C *IN03 IFEQ 1 C LEAVE C ELSE C *IN12 IFEQ 1 CANCEL ORDER C ROLBK C MOVEL 1 OK C GOTO SETLR C ENDIF C ENDIF * LenDH++--== C 22 READCSFL01R 81 C *IN81 IFEQ *OFF C *IN22 ANDEQ*ON C SELEC C CHOICE WHEQ D C EXSR DLTPRD C* CHOICE WHEQ OTHER C ENDSL C ELSE C
DO NUM B001 001 001 001 E001
15
1 1 2 3 B001 001 001 001 001 001 001 001 001 B002 002 X002 B003 003 003 003 E003 E002 3 001 B002 002 B003 X003 003 E003 X002
1 1 1 2 3 1 2 3
181
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 52800 C MOVE 0 OK 52900 * 53000 * The CALL of the STOCK PROCEDURE (at the remote system) 53100 * is prepared. The indicator variables are set to zero: 53200 * 53300 C MOVE *ZERO IND1 -1=no prod fnd 53400 C MOVE *BLANK DDESCR Prod descriptio 53500 C MOVE *ZERO IND3 -1=no alternat. 53600 C MOVE *ZERO DPRICE Prod price 53700 C MOVE *ZERO IND4 -1=EXPIRED 53800 * 53900 C EXSR RSTO 54000 * 54100 C IND4 IFLT *ZERO Item EXPIRED 54200 C MOVE 1 *IN68 54300 C MOVE *BLANK DDESCR 54400 C MOVE *ZERO DPRICE 54500 C ELSE 54600 C IND1 IFLT *ZERO Item not found 54700 C IND3 ORLT *ZERO 54800 C MOVE 1 *IN65 54900 C MOVE *BLANK DDESCR 55000 C MOVE *ZERO DPRICE 55100 C ELSE IF ITEM FOUND 55200 * LenDH++--== 55300 C PRDNBR IFNE DPRDNR Alternat. item 55400 C MOVE 1 *IN67 55500 C MOVE A PRDALT 55600 C MOVE A ALTFLD 55700 C ELSE 55800 C MOVE 0 *IN67 55900 C MOVE PRDALT 56000 C MOVE ALTFLD 56100 C ENDIF END IF ALTERN 56200 * LenDH++--== 56300 C MOVE PRDNBR DPRDNR Product # 56400 C MOVE PRDNBR SFCODE Product # 56500 C Z-ADDDQUANT SFQTY 56600 C DPRICE MULT DQUANT DITTOT Item total 56700 C DITTOT ADD DODCUM DODCUM Cumulative 56800 * 56900 * An order detail record is inserted in the local database, 57000 * if referential integrity rules are not violated, i.e. 57100 * the primary key of ORDERDTL file must be unique, and/or a 57200 * corresponding order number must exist in the ORDERHDR 57300 * parent file. Otherwise an SQL error message is sent from 57400 * database management: 57500 * 57600 C MOVE DPRDNR PRDNBR 57700 C MOVE DQUANT ORDQTY 57800 C MOVE DITTOT ORDTOT 57900 C MOVE DITTOT PORDT 58000 C WRITEORDERDTL 80 2 58100 *
DO NUM 002
002 002 002 002 002 002 B003 003 003 003 X003 B004 004 004 004 004 X004 B005 005 005 005 X005 005 005 005 E005 004 004 004 004 004
004 004 004 004 004
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96 05/20/96 05/29/96 05/20/96 05/20/96 05/29/96 05/20/96 05/20/96 05/20/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96 05/29/96 05/20/96 05/20/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96 05/20/96 05/20/96
16
182
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 58200 C *IN80 IFEQ *ON ERROR WRITING 58300 C SETON 64 1 58400 C EXSR SUBTR 58500 C ELSE 58600 C ADD 1 REC1 58700 C WRITESFL01R 58800 C SETON 22 1 58900 C ENDIF 59000 C ENDIF 59100 C ENDIF 59200 C ENDIF 59300 C ENDDO 59400 * 59500 C SETLR TAG 59600 * 59700 C COMIT 59800 * 59900 C ENDSR
DO NUM B005 005 005 X005 005 005 005 E005 E004 E003 E002 E001
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96
17
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT SEQUENCE IND NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE 60100 C SRRSTR BEGSR 60200 ***************************************************** 60300 * THIS ROUTINE INITIALISES FIELDS FOR A NEW ORDER * 60400 ***************************************************** 60500 C MOVEL*BLANKS JAREA 60600 C********** MOVEL*BLANKS RTVJBA 60700 C MOVELJB400 JOBFMT P 60800 C MOVEL * JOBNAM P 60900 C MOVEL*BLANKS JOBID 61000 C MOVEL*BLANKS ORHNBR 61100 C MOVEL*BLANKS USERID 10 61200 * LenDH++--== 61300 C CALL QUSRJOBI 61400 C PARM RTVJOB 61500 C PARM JOBLEN 61600 C PARM JOBFMT 61700 C PARM JOBNAM 61800 C PARM JOBID 61900 * LenDH++--== 62000 C********** MOVELRTVJOB JAREA 62100 C UNAME CHAINRSTRL 99 1 62200 C *IN99 IFEQ 0 62300 C EXSR SRCORD 62400 C ENDIF 62500 * LenDH++--== 62600 C ENDSR 62800 62900 63000 63100 63200 63300 63400 63600 63700 63800 63900 64000 64100 64200 64300 64400 64500 64600 64700 64800 64900 P000000 C SUBTR BEGSR ***************************************************** * The accumul. order total on the display has to be * * adjusted: * ***************************************************** C SUB DITTOT DODCUM C ENDSR WRRD BEGSR ***************************************************** * * ***************************************************** C WRITEORDER C SETOF 979899 C SETOF 1523 C READ ORDENTWS 50 C N03 ORHDTE IFGT ORHDLY C SETON 25 C ENDIF C MOVELCUSNBR CUSNO * LenDH++--== C ENDSR OUTPUT FIELDS FOR RECORD ORDER FILE ORDENTWS FORMAT ORDER. C
DO NUM
B001 001 E001
06/03/96 16:57:10 Page LAST PAGE PROGRAM UPDATE LINE ID 05/20/96 05/29/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/29/96 05/29/96 05/29/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96 05/20/96
18
1 2 3 1 2 3 1 B001 001 E001
183
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT 06/03/96 SEQUENCE IND DO LAST NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE NUM UPDATE P000000 ORDER ENTRY P000001 CUSNBR 5 CHAR 5 P000002 ORHDTE 11 ZONE 6,0 P000003 ORHDLY 17 ZONE 6,0 P000004 ORHNBR 22 CHAR 5 P000005 CUSDES 40 CHAR 18 Q000000 OUTPUT FIELDS FOR RECORD EXITLINE FILE ORDENTWS FORMAT EXITLINE. Q000000 EXIT LINE R000000 OUTPUT FIELDS FOR RECORD SFL01R FILE ORDENTWS FORMAT SFL01R. R000001 DDESCR 20 CHAR 20 R000002 DPRICE 27 ZONE 7,2 R000003 DITTOT 36 ZONE 9,2 R000004 SFQTY 41 ZONE 5,0 R000005 SFCODE 46 CHAR 5 R000006 ALTFLD 47 CHAR 1 S000000 OUTPUT FIELDS FOR RECORD SFL01C FILE ORDENTWS FORMAT SFL01C. S000001 REC1 4 ZONE 4,0 S000002 DPRDNR 9 CHAR 5 S000003 DQUANT 14 ZONE 5,0 T000000 OUTPUT FIELDS FOR RECORD FOOT FILE ORDENTWS FORMAT FOOT. T000001 DODCUM 11 ZONE 11,2 U000000 OUTPUT FIELDS FOR RECORD LINE FILE ORDENTWS FORMAT LINE. V000000 OUTPUT FIELDS FOR RECORD DSPM FILE ORDENTWS FORMAT DSPMSGD. V000001 MSGFLD 45 CHAR 45 W000000 OUTPUT FIELDS FOR RECORD FNLORDR FILE ORDENTWS FORMAT FNLORDR. W000001 RTNCD 1 CHAR 1 X000000 OUTPUT FIELDS FOR RECORD CUSTOMER FILE CUS01L FORMAT CUSTOMER. X000001 CUSNBR 5 CHAR 5 CODE X000002 CUSNAM 25 CHAR 20 NAME X000003 CUSTEL 40 CHAR 15 TEL. NBR. X000004 CUSFAX 55 CHAR 15 FAX NBR. X000005 CUSADR 75 CHAR 20 ADDRESS X000006 CUSCTY 95 CHAR 20 CITY X000007 CUSZIP 100 CHAR 5 ZIP CODE X000008 CUSCRD 106P PACK 11,2 CREDIT LIMIT X000009 CUSTOT 112P PACK 11,2 TOTAL ORDERED Y000000 OUTPUT FIELDS FOR RECORD ORDERHDR FILE ORDH01L FORMAT ORDERHDR. Y000001 ORHNBR 5 CHAR 5 NUMBER Y000002 CUSNBR 10 CHAR 5 CUSTOMER CODE Y000003 ORHDTA 14P PACK 6,0 ORDER DATE !!! Y000004 ORHDLY 18P PACK 6,0 DELIVERY DATE !!! Y000005 ORHTOT 24P PACK 11,2 TOTAL VALUE Y000006 SRNBR 34 CHAR 10 SESSION NUMBER Z000000 OUTPUT FIELDS FOR RECORD ORDERDTL FILE ORDD01L FORMAT ORDERDTL. Z000001 ORHNBR 5 CHAR 5 NUMBER Z000002 PRDNBR 10 CHAR 5 PRODUCT CODE Z000003 ORDQTY 13P PACK 5,0 PROD. QUANTITY Z000004 ORDTOT 18P PACK 9,2 ITEM VALUE Z000005 PRDALT 19 CHAR 1 ALTERNATIVE PRD. 1000000 OUTPUT FIELDS FOR RECORD SALESCUS FILE SALC01L FORMAT SALESCUS. 1000001 SRNBR 10 CHAR 10 SR CODE 1000002 CUSNBR 15 CHAR 5 CUSTOMER CODE 1000003 SRAMT 21P PACK 11,2 TOTAL FOR SR 2000000 OUTPUT FIELDS FOR RECORD STOCK FILE STOCK01L FORMAT STOCK.
19
184
SYSNM001 5763RG1 V3R1M0 940909 IBM RPG/400 A960121C/ORDENT 06/03/96 SEQUENCE IND DO LAST NUMBER *...1....+....2....+....3....+....4....+....5....+....6....+....7...* USE NUM UPDATE 2000001 PRDNBR 5 CHAR 5 CODE 2000002 PRDDES 25 CHAR 20 DESCRIPTION 2000003 PRDEXP 29P PACK 6,0 EXPIRE DATE 2000004 PRDPRC 33P PACK 7,2 PRICE 2000005 PRDQTA 36P PACK 5,0 ORDERABLE QTA 2000006 SPLNBR 41 CHAR 5 SUPPLIER CODE 2000007 PRDCAT 45 CHAR 4 CATEGORY 2000008 PRDQTM 48P PACK 5,0 MINIMUN QTA 3000000 OUTPUT FIELDS FOR RECORD STOCK2 FILE STOCK02L FORMAT STOCK. 3000001 PRDNBR 5 CHAR 5 CODE 3000002 PRDDES 25 CHAR 20 DESCRIPTION 3000003 PRDEXP 29P PACK 6,0 EXPIRE DATE 3000004 PRDPRC 33P PACK 7,2 PRICE 3000005 PRDQTA 36P PACK 5,0 ORDERABLE QTA 3000006 SPLNBR 41 CHAR 5 SUPPLIER CODE 3000007 PRDCAT 45 CHAR 4 CATEGORY 3000008 PRDQTM 48P PACK 5,0 MINIMUN QTA * * * * * E N D O F S O U R C E * * * * * A d d i t i o n a l D i a g n o s t i c M e s s a g e s * 7089 100 RPG PROVIDES SEPARATE INDICATOR AREA FOR FILE ORDENTWS.
20
5763RG1 V3R1M0
940909 K e y
F i e l d
SYSNM001 IBM RPG/400 I n f o r m a t i o n
A960121C/ORDENT
06/03/96
16:57:10
Page
21
FILE/RCD 02 RSTRL HDR
PHYSICAL FIELD
LOGICAL FIELD
ATTRIBUTES
SRNBR 03 CUS01L CUSTOMER CUSNBR 04 ORDH01L ORDERHDR ORHNBR 05 ORDD01L ORDERDTL ORHNBR PRDNBR 06 SALC01L SALESCUS SRNBR CUSNBR 07 STOCK01L STOCK
CHAR
10
CHAR
CHAR
CHAR CHAR
5 5
CHAR CHAR
10 5
08
PRDNBR CHAR 5 STOCK02L STOCK2 IS THE RPG NAME OF THE EXTERNAL FORMAT STOCK. PRDCAT CHAR 4
5763RG1 V3R1M0
940909
* QRG7031 Severity: 00 Message . . . * QRG7089 Severity: 00 Message . . . file. * * * * * E N D
SYSNM001 IBM RPG/400 A960121C/ORDENT M e s s a g e S u m m a r y Number: 24 . : The Name or indicator is not referenced. Number: 1 . : RPG provides a Separate-Indicator area for the O F M E S S A G E S U M M A R Y * * * * *
06/03/96
16:57:10
Page
28
185
186
Appendix D. RPG IV Order Entry Program

5763RG1 V3R1M0 940909 RN Command . . . . . . . . . Issued by . . . . . . . Program . . . . . . . . . Library . . . . . . . . Text description . . . . Source Member . . . . . . Source File . . . . . . . Library . . . . . . . . CCSID . . . . . . . . . Text description . . . . Last Change . . . . . . . Generation severity level Default activation group . Compiler options . . . . . Debugging views . . . . . Output . . . . . . . . . . Optimization level . . . . Source listing indentation Type conversion options . Sort sequence . . . . . . Language identifier . . . Replace program . . . . . User profile . . . . . . . Authority . . . . . . . . Truncate numeric . . . . . Fix numeric . . . . . . . Target release . . . . . . Allow null values . . . . IBM ILE RPG/400 A960121C/ORDENT . : CRTBNDRPG . : A960121C . : ORDENT . : A960121C . : *SRCMBRTXT . : ORDENT . : QRPGLESRC . : A960121C . : 37 . : Order Entry program . : 06/04/96 10:55:01 . : 10 . : *YES . : *NOXREF *GEN *NOSECLVL *SHOWCPY *EXPDDS *EXT *NOEVENT . : *STMT . : *PRINT . : *NONE . : *NONE . : *NONE . : *HEX . : *JOBRUN . : *YES . : *USER . : *LIBCRTAUT . : *YES . : *NONE . : V3R1M0 . : *NO SYSNM001 06/04/96 10:56:47 Page 1
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
187
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line S o u r c e L i s t i n g 1 FORDENTWS CF E WORKSTN 2 F RENAME(DSPMSGD:DSPM) 3 F SFILE(SFL01R:REC1) *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : ORDENTWS A960121C/ORDENTWS * * Record format(s) . . . . . : ORDER ORDER * * EXITLINE EXITLINE * * SFL01R SFL01R * * SFL01C SFL01C * * FOOT FOOT * * LINE LINE * * DSPM DSPMSGD * * FNLORDR FNLORDR * *--------------------------------------------------------------------------------------------* 4 FRSTRL IF E K DISK *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : RSTRL A960121/RSTRL * * Record format(s) . . . . . : HDR HDR * *--------------------------------------------------------------------------------------------* 5 FCUS01L UF E K DISK COMMIT *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : CUS01L A960121/CUS01L * * Record format(s) . . . . . : CUSTOMER CUSTOMER * *--------------------------------------------------------------------------------------------* 6 FORDH01L UF A E K DISK COMMIT *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : ORDH01L A960121/ORDH01L * * Record format(s) . . . . . : ORDERHDR ORDERHDR * *--------------------------------------------------------------------------------------------* 7 FORDD01L UF A E K DISK COMMIT *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : ORDD01L A960121/ORDD01L * * Record format(s) . . . . . : ORDERDTL ORDERDTL * *--------------------------------------------------------------------------------------------* 8 FSALC01L UF E K DISK COMMIT *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : SALC01L A960121/SALC01L * * Record format(s) . . . . . : SALESCUS SALESCUS * *--------------------------------------------------------------------------------------------* 9 FSTOCK01L UF E K DISK COMMIT *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : STOCK01L A960121/STOCK01L * * Record format(s) . . . . . : STOCK STOCK * *--------------------------------------------------------------------------------------------*
Page 2 Change Src Seq Date Id Number
960520 960520 960520
000100 00 00
960520
000400
960520
000500
960520
000600
960520
000700
960520
000800
960520
000900
188
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line 10 FSTOCK02L UF E K DISK COMMIT 11 F RENAME(STOCK:STOCK2) *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : STOCK02L A960121/STOCK02L * * Record format(s) . . . . . : STOCK2 STOCK * *--------------------------------------------------------------------------------------------* 12 D JB400 C CONST( JOBI0400 ) 13 D JAREA DS 14 D BRTN 1 4B 0 15 D BAVA 5 8B 0 16 D JBNAME 9 18 17 D UNAME 19 28 18 D JBNBR 29 34 19 D JOBID 35 50 20 D RTVJOB 1 50 21 D JOBLEN 51 54B 0 22 D JOBFMT 55 62 23 D JOBNAM 63 88 24 D HVAR DS 25 D ORHNBR 1 5 26 * 27 D MSG1 C CONST( AUTHORIZATION DEN28 D IED FOR THIS CUSTO29 D MER ) 30 * 31 D FLDS DS 32 D MSGLEN 1 4B 0 33 D PGMSTK 5 8B 0 34 D RTVLEN 9 12B 0 35 D INDDS DS 36 D IND1 1 2B 0 37 D IND2 3 4B 0 38 D IND3 5 6B 0 39 D IND4 7 8B 0 40 D DS 41 D DTE 1 6 0 42 D MM 1 2 0 43 D DD 3 4 0 44 D YY 5 6 0 45 D DS 46 D DTE1 1 6 0 47 D YY1 1 2 0 48 D MM1 3 4 0 49 D DD1 5 6 0
Page 3 Change Src Seq Date Id Number 960529 001000 960529 00
960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960529 960529 960529 960529 960529 960529 960529 960529 960529 960529
001200 001300 001400 001500 001600 001700 001800 001900 002000 002100 002200 002300 002400 002500 002600 002700 002800 002900 003000 003100 003200 003300 003400 003500 003600 003700 003800 003900 004000 004100 004200 004300 004400 004500 004600 004700 004800 004900
189
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line 51 ************************************************************************** 52 * * 53 * K E Y L I S T S A N D F I E L D D E F I N I T I O N S * 54 * * 55 ************************************************************************** 56=IORDER *--------------------------------------------------------------------------------------------* * RPG record format . . . . : ORDER * * External format . . . . . : ORDER : A960121C/ORDENTWS * * Format text . . . . . . . : ORDER ENTRY * *--------------------------------------------------------------------------------------------* 57=I A 1 5 CUSNBR 58=I S 6 11 0ORHDTE 59=I S 12 17 0ORHDLY 60=IEXITLINE *--------------------------------------------------------------------------------------------* * RPG record format . . . . : EXITLINE * * External format . . . . . : EXITLINE : A960121C/ORDENTWS * * Format text . . . . . . . : EXIT LINE * *--------------------------------------------------------------------------------------------* 61=ISFL01R *--------------------------------------------------------------------------------------------* * RPG record format . . . . : SFL01R * * External format . . . . . : SFL01R : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 62=I A 1 1 CHOICE 63=I A 2 21 DDESCR 64=I S 22 28 2DPRICE 65=I S 29 37 2DITTOT 66=I S 38 42 0SFQTY 67=I A 43 47 SFCODE 68=I A 48 48 ALTFLD 69=ISFL01C *--------------------------------------------------------------------------------------------* * RPG record format . . . . : SFL01C * * External format . . . . . : SFL01C : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 70=I S 1 4 0REC1 71=I A 5 9 DPRDNR 72=I S 10 14 0DQUANT 73=IFOOT *--------------------------------------------------------------------------------------------* * RPG record format . . . . : FOOT * * External format . . . . . : FOOT : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 74=ILINE *--------------------------------------------------------------------------------------------* * RPG record format . . . . : LINE * * External format . . . . . : LINE : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 75=IDSPM *--------------------------------------------------------------------------------------------* * RPG record format . . . . : DSPM * * External format . . . . . : DSPMSGD : A960121C/ORDENTWS *
Page 4 Change Src Seq Date Id Number 960520 005100 960520 005200 960520 005300 960520 005400 960520 005500 1000001 1 1 1 1 1 1000002 1000003 1000004 2000001 2 2 2 2 2 3000001 3 3 3 3 3000002 3000003 3000004 3000005 3000006 3000007 3000008 4000001 4 4 4 4 4000002 4000003 4000004 5000001 5 5 5 5 6000001 6 6 6 6 7000001 7 7 7
190
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line *--------------------------------------------------------------------------------------------* 76=IFNLORDR *--------------------------------------------------------------------------------------------* * RPG record format . . . . : FNLORDR * * External format . . . . . : FNLORDR : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 77=IHDR *--------------------------------------------------------------------------------------------* * RPG record format . . . . : HDR * * External format . . . . . : HDR : A960121/RSTRL * *--------------------------------------------------------------------------------------------* 78=I A 1 5 ORHNBR NUMBER 79=I A 6 15 SRNBR SESSION NUMBER 80=I P 16 21 2ORHTOT TOTAL VALUE 81=ICUSTOMER TOTAL VALUE *--------------------------------------------------------------------------------------------* * RPG record format . . . . : CUSTOMER * * External format . . . . . : CUSTOMER : A960121/CUS01L * *--------------------------------------------------------------------------------------------* 82=I A 1 5 CUSNBR CODE 83=I A 6 25 CUSNAM NAME 84=I A 26 40 CUSTEL TEL. NBR. 85=I A 41 55 CUSFAX FAX NBR. 86=I A 56 75 CUSADR ADDRESS 87=I A 76 95 CUSCTY CITY 88=I A 96 100 CUSZIP ZIP CODE 89=I P 101 106 2CUSCRD CREDIT LIMIT 90=I P 107 112 2CUSTOT TOTAL ORDERED 91=IORDERHDR TOTAL ORDERED *--------------------------------------------------------------------------------------------* * RPG record format . . . . : ORDERHDR * * External format . . . . . : ORDERHDR : A960121/ORDH01L * *--------------------------------------------------------------------------------------------* 92=I A 1 5 ORHNBR NUMBER 93=I A 6 10 CUSNBR CUSTOMER CODE 94=I P 11 14 0ORHDTA ORDER DATE !!! 95=I P 15 18 0ORHDLY DELIVERY DATE !!! 96=I P 19 24 2ORHTOT TOTAL VALUE 97=I A 25 34 SRNBR SESSION NUMBER 98=IORDERDTL SESSION NUMBER *--------------------------------------------------------------------------------------------* * RPG record format . . . . : ORDERDTL * * External format . . . . . : ORDERDTL : A960121/ORDD01L * *--------------------------------------------------------------------------------------------* 99=I A 1 5 ORHNBR NUMBER 100=I A 6 10 PRDNBR PRODUCT CODE 101=I P 11 13 0ORDQTY PROD. QUANTITY 102=I P 14 18 2ORDTOT ITEM VALUE 103=I A 19 19 PRDALT ALTERNATIVE PRD. 104=ISALESCUS ALTERNATIVE PRD. *--------------------------------------------------------------------------------------------* * RPG record format . . . . : SALESCUS * * External format . . . . . : SALESCUS : A960121/SALC01L * *--------------------------------------------------------------------------------------------* 105=I A 1 10 SRNBR SR CODE 106=I A 11 15 CUSNBR CUSTOMER CODE
Page 5 Change Src Seq Date Id Number 7 8000001 8 8 8 8 9000001 9 9 9 9 9000002 9000003 9000004 10000001 10 10 10 10 10000002 10000003 10000004 10000005 10000006 10000007 10000008 10000009 10000010 11000001 11 11 11 11 11000002 11000003 11000004 11000005 11000006 11000007 12000001 12 12 12 12 12000002 12000003 12000004 12000005 12000006 13000001 13 13 13 13 13000002 13000003
191
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line 107=I P 16 21 2SRAMT TOTAL FOR SR 108=ISTOCK TOTAL FOR SR *--------------------------------------------------------------------------------------------* * RPG record format . . . . : STOCK * * External format . . . . . : STOCK : A960121/STOCK01L * *--------------------------------------------------------------------------------------------* 109=I A 1 5 PRDNBR CODE 110=I A 6 25 PRDDES DESCRIPTION 111=I P 26 29 0PRDEXP EXPIRE DATE 112=I P 30 33 2PRDPRC PRICE 113=I P 34 36 0PRDQTA ORDERABLE QTA 114=I A 37 41 SPLNBR SUPPLIER CODE 115=I A 42 45 PRDCAT CATEGORY 116=I P 46 48 0PRDQTM MINIMUN QTA 117=ISTOCK2 MINIMUN QTA *--------------------------------------------------------------------------------------------* * RPG record format . . . . : STOCK2 * * External format . . . . . : STOCK : A960121/STOCK02L * *--------------------------------------------------------------------------------------------* 118=I A 1 5 PRDNBR CODE 119=I A 6 25 PRDDES DESCRIPTION 120=I P 26 29 0PRDEXP EXPIRE DATE 121=I P 30 33 2PRDPRC PRICE 122=I P 34 36 0PRDQTA ORDERABLE QTA 123=I A 37 41 SPLNBR SUPPLIER CODE 124=I A 42 45 PRDCAT CATEGORY 125=I P 46 48 0PRDQTM MINIMUN QTA 126 C *LIKE DEFINE ORHNBR NBR 127 C *LIKE DEFINE CUSNBR CODE 128 C *LIKE DEFINE ORHTOT PORDT 129 C *LIKE DEFINE CUSNBR CUSNO 130 C *LIKE DEFINE ORHNBR NEWORD 131 * 132 C NBRKL KLIST 133 C KFLD NBR 134 * 135 C DTLK KLIST 136 C KFLD ORHNBR 137 C KFLD PRDNBR 138 * 139 C ORDH KLIST 140 C KFLD ORHNBR 141 * 142 C CUST KLIST 143 C KFLD CUSNBR 144 * 145 C SALC KLIST 146 C KFLD SRNBR 147 * 148 C PRDK KLIST 149 C KFLD PRDNBR 150 * 151 C PLIST2 PLIST 152 C PARM RTVVAR 61
Page 6 Change Src Seq Date Id Number 13000004 14000001 14 14 14 14 14000002 14000003 14000004 14000005 14000006 14000007 14000008 14000009 15000001 15 15 15 15 15000002 15000003 15000004 15000005 15000006 15000007 15000008 15000009 960520 005600 960520 005700 960520 005800 960520 005900 960520 006000 960520 006100 960520 006200 960520 006300 960520 006400 960520 006500 960520 006600 960520 006700 960520 006800 960520 006900 960520 007000 960520 007100 960520 007200 960520 007300 960520 007400 960520 007500 960520 007600 960520 007700 960520 007800 960520 007900 960520 008000 960520 008100 960520 008200
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line 153 C PARM RTVLEN 154 C PARM RTVFMT 8 155 C PARM RTVNAM 26 156 C PARM RTVID 16 157 * 158 C KEYFLD KLIST 159 C KFLD SRNBR 160 C KFLD CUSNBR 161 C*********** KFLD PARM1 162 C************ KFLD PARM2
Page 7 Change Src Seq Date Id Number 960520 008300 960520 008400 960520 008500 960520 008600 960520 008700 960520 008800 960520 008900 960520 009000 960520 009100 960520 009200
192
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 164 ************************************************************************** 165 * * 166 * M A I N L I N E * 167 * * 168 ************************************************************************** 169 C MOVEL 0 OK 1 170 * LenDH++--== 171 C OK DOWNE 2 172 C MOVEL *BLANKS CUSNBR 5 173 C MOVEL *BLANKS ORHNBR 5 174 C Z-ADD 0 TOTAMT 11 2 175 C EXSR SRRSTR RESTART 176 C EXSR SRCINS 177 * LenDH++--== 178 C OK IFEQ 0 179 C EXSR SRRIDT 180 C OK IFEQ 0 181 C EXSR SRFNLO 182 C SETOFF 03---183 C ENDIF 184 C ENDIF 185 * 186 C OK IFEQ 1 187 C EXSR SRCORD 188 C ENDIF 189 C ENDDO 190 * 191 C MOVE 1 *INLR 193 194 195 196 197 198 199 200 201 202 203 204 206 207 208 209 210 211 212 DLTPRD BEGSR ************************************************* * * ************************************************* C DTLK CHAIN ORDD01L C N82 DELETE ORDERDTL C EXSR SUBTR C SETON C UPDATE SFL01R C SETOFF * LenDH++--== C ENDSR ERR BEGSR ***************************************************** * * ***************************************************** C MOVE 1 RTNCD C EXFMT FNLORDR C ENDSR C C
10:56:47 Do Page Num Line
B01 01 01 01 01 01 B02 02 B03 03 03 E03 E02 B02 02 E02 E01
Page 8 Change Src Seq Date Id Number 960520 009400 960520 009500 960520 009600 960520 009700 960520 009800 941129 009900 960520 010000 960509 010100 941129 010200 941129 010300 941129 010400 960520 010500 960520 010600 960520 010700 941129 010800 960520 010900 941129 011000 960520 011100 960521 011200 941129 011300 941129 011400 960520 011500 941129 011600 960520 011700 941129 011800 960509 011900 960520 012000 960521 012100 960520 960529 960529 960529 960520 960520 960520 960520 960520 960520 960520 960520 960520 960529 960529 960529 960520 960520 960520 012300 012400 012500 012600 012700 012800 012900 013000 013100 013200 013300 013400 013600 013700 013800 013900 014000 014100 014200
82----
23---23----
193
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line 214 C INIHDR BEGSR 215 ***************************************************** 216 * INITIALISE FIELDS FOR NEW ORDER HEADER INFO * 217 ***************************************************** 218 C Z-ADD 0 BAVA 219 C Z-ADD 0 BRTN 220 C Z-ADD 50 JOBLEN 221 C MOVEL * JOBNAM 222 C MOVEL *BLANKS JOBID 223 C MOVEL JB400 JOBFMT 224 C MOVEL DATE1 ORHDTE 225 C MOVEL DATE2 ORHDLY 226 * LenDH++--== 227 C ENDSR 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 MAXKEY BEGSR ***************************************************** * * ***************************************************** C MOVE *HIVAL NBR C NBRKL SETLL ORDH01L C READP ORDH01L * LenDH++--== C *IN99 IFEQ *ON C Z-ADD 1 AP1 C ELSE C MOVEL ORHNBR AP1 C ADD 1 AP1 C ENDIF * LenDH++--== C CLEAR ORDERHDR C MOVEL AP1 NEWORD C MOVEL AP1 ORHNBR C MOVEL AP1 NBR * LenDH++--== C ENDSR ORDENT BEGSR ***************************************************** * * ***************************************************** C MOVE *BLANKS CUSDES C EXSR WRRD C CUSNO CHAIN CUS01L C Z-ADD 0 OTOT * LenDH++--== C *IN03 IFEQ 0 C *IN16 ANDNE 1 C MOVE NEWORD ORHNBR C MOVE UNAME SRNBR C MOVE CUSNO CUSNBR C MOVE OTOT ORHTOT C C
Page 9 Change Src Seq Date Id Number 960520 014400 960529 014500 960529 014600 960529 014700 960520 014800 960520 014900 960520 015000 960520 015100 960520 015200 960520 015300 960520 015400 960520 015500 960520 015600 960520 015700 960520 960529 960529 960529 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 960529 960529 960529 960529 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 015900 016000 016100 016200 016300 016400 016500 016600 016700 016800 016900 017000 017100 017200 017300 017400 017500 017600 017700 017800 017900 018100 018200 018300 018400 018500 018600 018700 018800 018900 019000 019100 019200 019300 019400 019500
----99 B01 01 X01 01 01 E01
5 0
16---9 2 B01 01 01 01 01 01
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 266 C MOVE ORHDTE ORHDTA 267 C WRITE ORDERHDR 268 C Z-ADD 1 INSOK 269 C MOVEL CUSNAM CUSDES 270 C WRITE ORDER 271 C ELSE 272 C 16 SETON 98---273 C ENDIF 274 * LenDH++--== 275 C ENDSR
10:56:47 Do Page Num Line 01 01 01 01 01 X01 01 E01
194
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 277 C RSTO BEGSR 278 ***************************************************** 279 * CHECK PRODUCT REQUESTED. * 280 ***************************************************** 281 C MOVE *ZERO WQTA 5 0 282 C MOVE *BLANK WCAT 4 283 * 284 C STK1 KLIST 285 C KFLD DPRDNR 286 C STK2 KLIST 287 C KFLD WCAT 288 * 289 C Z-ADD ORHDLY DTE 290 C EXSR CVTDTE 291 C Z-ADD DTE1 DELDT 6 0 292 C* 293 C STK1 CHAIN STOCK01L 80---294 C* 295 C *IN80 IFEQ *ON 296 C MOVE -1 IND1 297 C MOVE *ZERO IND3 298 C MOVE *BLANK DDESCR 299 C MOVE *ZERO DPRICE 300 C GOTO DONE0 301 C ELSE 302 C Z-ADD PRDEXP DTE 303 C EXSR CVTDTE 304 C Z-ADD DTE1 EXPDT 6 0 305 C EXPDT IFGE DELDT 306 C Z-ADD PRDQTA WQTA 307 C Z-ADD PRDPRC DPRICE 308 C MOVE PRDCAT WCAT 309 C MOVE PRDDES DDESCR 310 C ENDIF 311 C ENDIF 312 C* 313 C* If the available quantity is enough to meet the ordered 314 C* quantity, the product record is updated and the product 315 C* information is passed back to the calling subroutine. 316 C* 317 C WQTA IFGE DQUANT 318 C WQTA SUB DQUANT LEFTQ 5 0 319 C Z-ADD LEFTQ PRDQTA 320 C UPDATE STOCK 321 C MOVE *ZERO IND1 322 C MOVE *ZERO IND3 323 C GOTO DONE0 324 C ELSE 325 C *LOVAL SETLL STOCK01L 326 C END 327 C* 328 C* If there is not enough quantity for the customer-ordered 329 C* OR EXPIR DATE OF PRODUCT IF NOT COMPATIBLE WITH DELIVERY ORDER DATE 330 C* ,an alternative within same product category number is 331 C* searched. 332 C* We assume that we ll pass back only the first one to the
B01 01 01 01 01 01 X01 01 01 01 B02 02 02 02 02 E02 E01
B01 01 01 01 01 01 01 X01 01 E01
Page 11 Change Src Seq Date Id Number 960529 020700 960529 020800 960529 020900 960529 021000 960529 021100 960529 021200 960529 021300 960529 021400 960529 021500 960529 021600 960529 021700 960529 021800 960529 021900 960529 022000 960529 022100 960529 022200 960529 022300 960529 022400 960529 022500 960529 022600 960529 022700 960529 022800 960529 022900 960529 023000 960529 023100 960529 023200 960529 023300 960529 023400 960529 023500 960529 023600 960529 023700 960529 023800 960529 023900 960529 024000 960529 024100 960529 024200 960529 024300 960529 024400 960529 024500 960529 024600 960529 024700 960529 024800 960529 024900 960529 025000 960529 025100 960529 025200 960529 025300 960529 025400 960529 025500 960529 025600 960529 025700 960529 025800 960529 025900 960529 026000 960529 026100 960529 026200
195
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 333 C* calling subroutine even though there may be several alternatives 334 C* in the STOCK file. 335 C* 336 C STK2 SETLL STOCK02L 337 C SETOFF 81---338 C STK2 READE STOCK02L ----81 339 C Z-ADD PRDEXP DTE 340 C EXSR CVTDTE 341 C Z-ADD DTE1 EXPDT 6 0 342 C *IN81 DOWEQ *OFF 343 C PRDQTA ANDLT DQUANT 344 C EXPDT ANDGT DELDT 345 C STK2 READE STOCK02L ----81 346 C *IN81 IFEQ *OFF 347 C Z-ADD PRDEXP DTE 348 C EXSR CVTDTE 349 C Z-ADD DTE1 EXPDT 6 0 350 C ENDIF 351 C ENDDO 352 C* 353 C *IN81 IFEQ *OFF 354 C MOVE PRDNBR DPRDNR 355 C MOVE PRDDES DDESCR 356 C MOVE PRDPRC DPRICE 357 C Z-ADD PRDQTA WQTA 358 C ELSE 359 C EXPDT IFGT DELDT 360 C MOVE -1 IND3 361 C ELSE 362 C MOVE -1 IND4 363 C ENDIF 364 C MOVE *ZERO IND1 365 C MOVE *BLANK DDESCR 366 C MOVE *ZERO DPRICE 367 C GOTO DONE1 368 C ENDIF 369 C* 370 C WQTA SUB DQUANT LEFTQ 371 C Z-ADD LEFTQ PRDQTA 372 C UPDATE STOCK2 373 C* 374 C MOVE *ZERO IND1 375 C MOVE *ZERO IND3 376 C* 377 C DONE1 TAG 378 C DONE0 TAG 379 * 380 C ENDSR 381 ***************************************************** 382 *COVERT DATE FROM MDY TO YMD FORMAT * 383 ***************************************************** 384 C CVTDTE BEGSR 385 C MOVE YY YY1 386 C MOVE MM MM1 387 C MOVE DD DD1 388 C ENDSR
B01 01 01 01 B02 02 02 02 E02 E01 B01 01 01 01 01 X01 B02 02 X02 02 E02 01 01 01 01 E01
196
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 390 C SRCINS BEGSR 391 ***************************************************** 392 * INSERT ORDER HEADER DETAILS * 393 ***************************************************** 394 * LenDH++--== 395 C MOVE UDATE DATE1 6 0 396 C MOVE DATE1 APP 2 0 397 C ADD 1 APP 398 C MOVEL DATE1 DATE2 6 0 399 C MOVE APP DATE2 400 C EXSR MAXKEY GET NEW N. ORD. 401 C EXSR INIHDR 402 * LenDH++--== 403 C********** CALL QUSRJOBI 404 C************* PARM RTVJOB 405 C********** PARM JOBLEN 406 C*********** PARM JOBFMT 407 C************ PARM JOBNAM 408 C************ PARM JOBID 409 * LenDH++--== 410 C************ MOVELRTVJBA JAREA 411 C MOVEL 0 OK 412 C Z-ADD 0 INSOK 1 0 413 C SETOFF 15---414 C WRITE EXITLINE 415 C MOVEL NEWORD ORHNBR 416 C******************* MOVELORHNBR ORDNO 417 C SETON 50---418 * LenDH++--== 419 C *IN03 DOWNE 1 420 C INSOK ANDNE 1 421 C EXSR ORDENT 422 C ENDDO 423 * 424 C *IN03 IFEQ 1 425 C MOVE 2 OK 426 C ELSE 427 * LenDH++--== 428 C INSOK IFEQ 1 429 C MOVE 0 OK 430 C COMMIT 431 C ELSE 432 C MOVE 3 OK 433 C ROLBK 434 C ENDIF 435 * 436 C ENDIF 437 * LenDH++--== 438 C ENDSR 440 C SRCORD BEGSR 441 ***************************************************** 442 * * 443 *****************************************************
B01 01 01 E01 B01 01 X01 B02 02 02 X02 02 02 E02 E01
Page 13 Change Src Seq Date Id Number 960520 032000 960529 032100 960529 032200 960529 032300 960520 032400 960520 032500 960520 032600 960520 032700 960520 032800 960520 032900 960520 033000 960520 033100 960520 033200 960520 033300 960520 033400 960520 033500 960520 033600 960520 033700 960520 033800 960520 033900 960520 034000 960520 034100 960520 034200 960520 034300 960520 034400 960520 034500 960520 034600 960520 034700 960520 034800 960520 034900 960520 035000 960520 035100 960520 035200 960520 035300 960520 035400 960520 035500 960520 035600 960520 035700 960520 035800 960520 035900 960520 036000 960520 036100 960520 036200 960520 036300 960520 036400 960520 036500 960520 036600 960520 036700 960520 036800 960520 960529 960529 960529 037000 037100 037200 037300
197
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 444 C ORDH SETLL ORDD01L 445 C SETOFF 80---446 C ORDH READE ORDD01L ----80 447 * LenDH++--== 448 C *IN80 DOWEQ *OFF 449 C PRDK CHAIN STOCK01L 81---450 C *IN81 IFEQ *OFF 451 C ADD ORDQTY PRDQTA 452 C UPDATE STOCK 453 C ENDIF 454 C DELETE ORDERDTL 455 C ORDH READE ORDD01L ----80 456 C ENDDO 457 * LenDH++--== 458 C ORDH CHAIN ORDH01L 80---459 C N80 DELETE ORDERHDR 460 C COMMIT 461 * LenDH++--== 462 C ENDSR 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 SRFNLO BEGSR ***************************************************** * * ***************************************************** C MOVE *BLANK WSR 10 C SETOFF * * If the total order amount is greater than the customer s * credit limit, the program displays an error message. * C CUST CHAIN CUS01L * LenDH++--== C *IN80 IFEQ *OFF * C CUSCRD IFGE PORDT C ADD PORDT CUSTOT C UPDATE CUSTOMER C ELSE C SETON C ENDIF * LenDH++--== C ELSE C SETON C ENDIF * * The total order amount is added to the sales_rep s amount. * LenDH++--== C ORDH CHAIN ORDH01L C *IN80 IFEQ *OFF C SALC CHAIN SALC01L C *IN81 IFEQ *OFF C ADD PORDT SRAMT C UPDATE SALESCUS C ELSE C
B01 01 B02 02 02 E02 01 01 E01
01----
80---B01 B02 02 02 X02 02 E02 X01 01 E01
6601--
6601--
80---81---B01 01 B02 02 02 X02
198
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 498 C SETON 4401-499 C ENDIF 500 C ENDIF 501 * 502 C ORDH CHAIN ORDH01L 80---503 * LenDH++--== 504 C *IN80 IFEQ *OFF 505 C Z-ADD PORDT ORHTOT 506 C MOVE 0 OKAUD 1 507 C EXSR SRRADT 508 * LenDH++--== 509 C OKAUD IFEQ 0 510 C UPDATE ORDERHDR --81-511 C 81 SETON 7701-512 C ELSE 513 C *LOVAL SETLL ORDH01L 80---514 C ROLBK 515 C EXSR SRCORD 516 C SETON 77---NO ROLBK LAST DELET 517 C ENDIF 518 * LenDH++--== 519 C ELSE 520 C SETON 7701-521 * 522 C ENDIF 523 C* 524 C *IN01 IFEQ *OFF 525 C MOVE 0 RTNCD 526 C COMMIT 527 C ELSE 528 C MOVE 1 RTNCD 529 C* EXSR ERR 530 C ROLBK 531 C ENDIF 532 * LenDH++--== 533 C ENDSR 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 SRRADT BEGSR ***************************************************** * GET THE USERID * ***************************************************** C Z-ADD 61 RTVLEN C MOVEL JOBI0400 RTVFMT C MOVEL(P) * RTVNAM C MOVE(P) RTVID C************** CALL QUSRJOBI PLIST2 C************** MOVE RTVVAR RTVAPI C KEYFLD CHAIN SALC01L * LenDH++--== C *IN71 IFEQ 1 C MOVEL MSG1 MSGFLD C EXFMT DSPM C MOVE 1 OKAUD C******* MOVE 1 PARM3 C
10:56:47 Do Page Num Line 02 E02 E01
B01 01 01 01 B02 02 02 X02 02 02 02 02 E02 X01 01 E01 B01 01 01 X01 01 01 E01
71---B01 01 01 01
199
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 552 C ENDIF 553 * LenDH++--== 554 C ENDSR 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 SRRIDT BEGSR ***************************************************** * * ***************************************************** C ORDH CHAIN ORDH01L C Z-ADD 0 DODCUM C MOVE 0 OK C Z-ADD 0 REC1 C WRITE LINE C SETON C WRITE SFL01C C SETOFF * LenDH++--== C *IN03 DOWEQ *OFF C MOVE *BLANK DPRDNR C Z-ADD 0 DQUANT C N65 CANN66 CANN68 WRITE FOOT C 22 SETON C SETON C EXFMT SFL01C C SETOFF C SETOFF * LenDH++--== C *IN03 IFEQ 1 C LEAVE C ELSE C *IN12 IFEQ 1 C ROLBK C MOVEL 1 OK C GOTO SETLR C ENDIF C ENDIF * LenDH++--== C 22 READC SFL01R C *IN81 IFEQ *OFF C *IN22 ANDEQ *ON C SELECT C CHOICE WHENEQ D C EXSR DLTPRD C* CHOICE WHEQ OTHER C ENDSL C ELSE C MOVE 0 OK * * The CALL of the STOCK PROCEDURE (at the remote system) * is prepared. The indicator variables are set to zero: * C MOVE *ZERO IND1 C
10:56:47 Do Page Num Line E01
99----
52---522223 B01 01 01 01 01 01 01 01 01 01 01 B02 02 X02 B03 03 03 03 E03 E02 01 B02 02 B03 X03 03 E03 X02 02
50---51---505168 636465
CANCEL ORDER
----81
-1=no prod fnd
02
200
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 606 C MOVE *BLANK DDESCR Prod descriptio 607 C MOVE *ZERO IND3 -1=no alternat. 608 C MOVE *ZERO DPRICE Prod price 609 C MOVE *ZERO IND4 -1=EXPIRED 610 * 611 C EXSR RSTO 612 * 613 C IND4 IFLT *ZERO Item EXPIRED 614 C MOVE 1 *IN68 615 C MOVE *BLANK DDESCR 616 C MOVE *ZERO DPRICE 617 C ELSE 618 C IND1 IFLT *ZERO Item not found 619 C IND3 ORLT *ZERO 620 C MOVE 1 *IN65 621 C MOVE *BLANK DDESCR 622 C MOVE *ZERO DPRICE 623 C ELSE IF ITEM FOUND 624 * LenDH++--== 625 C PRDNBR IFNE DPRDNR Alternat. item 626 C MOVE 1 *IN67 627 C MOVE A PRDALT 628 C MOVE A ALTFLD 629 C ELSE 630 C MOVE 0 *IN67 631 C MOVE PRDALT 632 C MOVE ALTFLD 633 C ENDIF END IF ALTERN 634 * LenDH++--== 635 C MOVE PRDNBR DPRDNR Product # 636 C MOVE PRDNBR SFCODE Product # 637 C Z-ADD DQUANT SFQTY 638 C DPRICE MULT DQUANT DITTOT Item total 639 C DITTOT ADD DODCUM DODCUM Cumulative 640 * 641 * An order detail record is inserted in the local database, 642 * if referential integrity rules are not violated, i.e. 643 * the primary key of ORDERDTL file must be unique, and/or a 644 * corresponding order number must exist in the ORDERHDR 645 * parent file. Otherwise an SQL error message is sent from 646 * database management: 647 * 648 C MOVE DPRDNR PRDNBR 649 C MOVE DQUANT ORDQTY 650 C MOVE DITTOT ORDTOT 651 C MOVE DITTOT PORDT 652 C WRITE ORDERDTL --80-653 * 654 C *IN80 IFEQ *ON ERROR WRITING 655 C SETON 64---656 C EXSR SUBTR 657 C ELSE 658 C ADD 1 REC1 659 C WRITE SFL01R 660 C SETON 22---661 C ENDIF
10:56:47 Do Page Num Line 02 02 02 02 02 B03 03 03 03 X03 B04 04 04 04 04 X04 B05 05 05 05 X05 05 05 05 E05 04 04 04 04 04
04 04 04 04 04 B05 05 05 X05 05 05 05 E05
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 662 C ENDIF 663 C ENDIF 664 C ENDIF 665 C ENDDO 666 * 667 C SETLR TAG 668 * 669 C COMMIT 670 * 671 C ENDSR
10:56:47 Do Page Num Line E04 E03 E02 E01
201
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 673 C SRRSTR BEGSR 674 ***************************************************** 675 * THIS ROUTINE INITIALISES FIELDS FOR A NEW ORDER * 676 ***************************************************** 677 C MOVEL *BLANKS JAREA 678 C********** MOVEL*BLANKS RTVJBA 679 C MOVEL(P) JB400 JOBFMT 680 C MOVEL(P) * JOBNAM 681 C MOVEL *BLANKS JOBID 682 C MOVEL *BLANKS ORHNBR 683 C MOVEL *BLANKS USERID 10 684 * LenDH++--== 685 C CALL QUSRJOBI 686 C PARM RTVJOB 687 C PARM JOBLEN 688 C PARM JOBFMT 689 C PARM JOBNAM 690 C PARM JOBID 691 * LenDH++--== 692 C********** MOVELRTVJOB JAREA 693 C UNAME CHAIN RSTRL 99---694 C *IN99 IFEQ 0 695 C EXSR SRCORD 696 C ENDIF 697 * LenDH++--== 698 C ENDSR 700 C SUBTR BEGSR 701 ***************************************************** 702 * The accumul. order total on the display has to be * 703 * adjusted: * 704 ***************************************************** 705 C SUB DITTOT DODCUM 706 C ENDSR
B01 01 E01
Page 19 Change Src Seq Date Id Number 960520 060300 960529 060400 960529 060500 960529 060600 960520 060700 960520 060800 960520 060900 960520 061000 960520 061100 960520 061200 960520 061300 960520 061400 960520 061500 960520 061600 960520 061700 960520 061800 960520 061900 960520 062000 960520 062100 960520 062200 960520 062300 960520 062400 960520 062500 960520 062600 960520 062700 960520 062800 960520 960520 960520 960520 960520 960520 960520 960520 960529 960529 960529 960520 960520 960520 960520 960520 960520 960520 960520 960520 960520 063000 063100 063200 063300 063400 063500 063600 063800 063900 064000 064100 064200 064300 064400 064500 064600 064700 064800 064900 065000 065100 16000001 16 16
708 C WRRD BEGSR 709 ***************************************************** 710 * * 711 ***************************************************** 712 C WRITE ORDER 713 C SETOFF 979899 714 C SETOFF 1523-715 C READ ORDENTWS ----50 716 C N03ORHDTE IFGT ORHDLY B01 717 C SETON 25---01 718 C ENDIF E01 719 C MOVEL CUSNBR CUSNO 720 * LenDH++--== 721 C ENDSR 722=OORDER *--------------------------------------------------------------------------------------------* * RPG record format . . . . : ORDER *
202
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line * External format . . . . . : ORDER : A960121C/ORDENTWS * * Format text . . . . . . . : ORDER ENTRY * *--------------------------------------------------------------------------------------------* 723=O CUSNBR 5A CHAR 5 724=O ORHDTE 11S ZONE 6,0 725=O ORHDLY 17S ZONE 6,0 726=O ORHNBR 22A CHAR 5 727=O CUSDES 40A CHAR 18 728=OEXITLINE *--------------------------------------------------------------------------------------------* * RPG record format . . . . : EXITLINE * * External format . . . . . : EXITLINE : A960121C/ORDENTWS * * Format text . . . . . . . : EXIT LINE * *--------------------------------------------------------------------------------------------* 729=OSFL01R *--------------------------------------------------------------------------------------------* * RPG record format . . . . : SFL01R * * External format . . . . . : SFL01R : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 730=O DDESCR 20A CHAR 20 731=O DPRICE 27S ZONE 7,2 732=O DITTOT 36S ZONE 9,2 733=O SFQTY 41S ZONE 5,0 734=O SFCODE 46A CHAR 5 735=O ALTFLD 47A CHAR 1 736=OSFL01C *--------------------------------------------------------------------------------------------* * RPG record format . . . . : SFL01C * * External format . . . . . : SFL01C : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 737=O REC1 4S ZONE 4,0 738=O DPRDNR 9A CHAR 5 739=O DQUANT 14S ZONE 5,0 740=OFOOT *--------------------------------------------------------------------------------------------* * RPG record format . . . . : FOOT * * External format . . . . . : FOOT : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 741=O DODCUM 11S ZONE 11,2 742=OLINE *--------------------------------------------------------------------------------------------* * RPG record format . . . . : LINE * * External format . . . . . : LINE : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 743=ODSPM *--------------------------------------------------------------------------------------------* * RPG record format . . . . : DSPM * * External format . . . . . : DSPMSGD : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 744=O MSGFLD 45A CHAR 45 745=OFNLORDR *--------------------------------------------------------------------------------------------* * RPG record format . . . . : FNLORDR * * External format . . . . . : FNLORDR : A960121C/ORDENTWS * *--------------------------------------------------------------------------------------------* 746=O RTNCD 1A CHAR 1
203
frame.
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line 747=OCUSTOMER *--------------------------------------------------------------------------------------------* * RPG record format . . . . : CUSTOMER * * External format . . . . . : CUSTOMER : A960121/CUS01L * *--------------------------------------------------------------------------------------------* 748=O CUSNBR 5A CHAR 5 CODE 749=O CUSNAM 25A CHAR 20 NAME 750=O CUSTEL 40A CHAR 15 TEL. NBR. 751=O CUSFAX 55A CHAR 15 FAX NBR. 752=O CUSADR 75A CHAR 20 ADDRESS 753=O CUSCTY 95A CHAR 20 CITY 754=O CUSZIP 100A CHAR 5 ZIP CODE 755=O CUSCRD 106P PACK 11,2 CREDIT LIMIT 756=O CUSTOT 112P PACK 11,2 TOTAL ORDERED 757=OORDERHDR *--------------------------------------------------------------------------------------------* * RPG record format . . . . : ORDERHDR * * External format . . . . . : ORDERHDR : A960121/ORDH01L * *--------------------------------------------------------------------------------------------* 758=O ORHNBR 5A CHAR 5 NUMBER 759=O CUSNBR 10A CHAR 5 CUSTOMER CODE 760=O ORHDTA 14P PACK 6,0 ORDER DATE !!! 761=O ORHDLY 18P PACK 6,0 DELIVERY DATE !!! 762=O ORHTOT 24P PACK 11,2 TOTAL VALUE 763=O SRNBR 34A CHAR 10 SESSION NUMBER 764=OORDERDTL *--------------------------------------------------------------------------------------------* * RPG record format . . . . : ORDERDTL * * External format . . . . . : ORDERDTL : A960121/ORDD01L * *--------------------------------------------------------------------------------------------* 765=O ORHNBR 5A CHAR 5 NUMBER 766=O PRDNBR 10A CHAR 5 PRODUCT CODE 767=O ORDQTY 13P PACK 5,0 PROD. QUANTITY 768=O ORDTOT 18P PACK 9,2 ITEM VALUE 769=O PRDALT 19A CHAR 1 ALTERNATIVE PRD. 770=OSALESCUS *--------------------------------------------------------------------------------------------* * RPG record format . . . . : SALESCUS * * External format . . . . . : SALESCUS : A960121/SALC01L * *--------------------------------------------------------------------------------------------* 771=O SRNBR 10A CHAR 10 SR CODE 772=O CUSNBR 15A CHAR 5 CUSTOMER CODE 773=O SRAMT 21P PACK 11,2 TOTAL FOR SR 774=OSTOCK *--------------------------------------------------------------------------------------------* * RPG record format . . . . : STOCK * * External format . . . . . : STOCK : A960121/STOCK01L * *--------------------------------------------------------------------------------------------* 775=O PRDNBR 5A CHAR 5 CODE 776=O PRDDES 25A CHAR 20 DESCRIPTION 777=O PRDEXP 29P PACK 6,0 EXPIRE DATE 778=O PRDPRC 33P PACK 7,2 PRICE 779=O PRDQTA 36P PACK 5,0 ORDERABLE QTA 780=O SPLNBR 41A CHAR 5 SUPPLIER CODE 781=O PRDCAT 45A CHAR 4 CATEGORY 782=O PRDQTM 48P PACK 5,0 MINIMUN QTA
204
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line 783=OSTOCK2 *--------------------------------------------------------------------------------------------* * RPG record format . . . . : STOCK2 * * External format . . . . . : STOCK : A960121/STOCK02L * *--------------------------------------------------------------------------------------------* 784=O PRDNBR 5A CHAR 5 CODE 785=O PRDDES 25A CHAR 20 DESCRIPTION 786=O PRDEXP 29P PACK 6,0 EXPIRE DATE 787=O PRDPRC 33P PACK 7,2 PRICE 788=O PRDQTA 36P PACK 5,0 ORDERABLE QTA 789=O SPLNBR 41A CHAR 5 SUPPLIER CODE 790=O PRDCAT 45A CHAR 4 CATEGORY 791=O PRDQTM 48P PACK 5,0 MINIMUN QTA * * * * * E N D O F S O U R C E * * * * *
Page 22 Change Src Seq Date Id Number 29000001 29 29 29 29 29000002 29000003 29000004 29000005 29000006 29000007 29000008 29000009
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT SYSNM001 06/04/96 10:56:47 A d d i t i o n a l D i a g n o s t i c M e s s a g e s *RNF7066 00 4 000400 Record-Format HDR not used for input or output. *RNF7089 00 1 000100 RPG provides Separate-Indicator area for file ORDENTWS. * * * * * E N D O F A D D I T I O N A L D I A G N O S T I C M E S S A G E S * * * * * O u t p u t B u f f e r P o s i t i o n s Line Start End Field or Constant Number Pos Pos 723 1 5 CUSNBR 724 6 11 ORHDTE 725 12 17 ORHDLY 726 18 22 ORHNBR 727 23 40 CUSDES 730 1 20 DDESCR 731 21 27 DPRICE 732 28 36 DITTOT 733 37 41 SFQTY 734 42 46 SFCODE 735 47 47 ALTFLD 730 1 20 DDESCR 731 21 27 DPRICE 732 28 36 DITTOT 733 37 41 SFQTY 734 42 46 SFCODE 735 47 47 ALTFLD 737 1 4 REC1 738 5 9 DPRDNR 739 10 14 DQUANT 741 1 11 DODCUM 744 1 45 MSGFLD 746 1 1 RTNCD 748 1 5 CUSNBR 749 6 25 CUSNAM 750 26 40 CUSTEL 751 41 55 CUSFAX 752 56 75 CUSADR 753 76 95 CUSCTY 754 96 100 CUSZIP 755 101 106 CUSCRD 756 107 112 CUSTOT 758 1 5 ORHNBR 759 6 10 CUSNBR 760 11 14 ORHDTA 761 15 18 ORHDLY 762 19 24 ORHTOT 763 25 34 SRNBR 758 1 5 ORHNBR 759 6 10 CUSNBR 760 11 14 ORHDTA 761 15 18 ORHDLY 762 19 24 ORHTOT 763 25 34 SRNBR 765 1 5 ORHNBR 766 6 10 PRDNBR 767 11 13 ORDQTY
Page
23
205
SYSNM001 5763RG1 V3R1M0 940909 RN IBM ILE RPG/400 A960121C/ORDENT 768 14 18 ORDTOT 769 19 19 PRDALT 771 1 10 SRNBR 772 11 15 CUSNBR 773 16 21 SRAMT 775 1 5 PRDNBR 776 6 25 PRDDES 777 26 29 PRDEXP 778 30 33 PRDPRC 779 34 36 PRDQTA 780 37 41 SPLNBR 781 42 45 PRDCAT 782 46 48 PRDQTM 784 1 5 PRDNBR 785 6 25 PRDDES 786 26 29 PRDEXP 787 30 33 PRDPRC 788 34 36 PRDQTA 789 37 41 SPLNBR 790 42 45 PRDCAT 791 46 48 PRDQTM * * * * * E N D O F O U T P U T B U F F E R P O S I T I O N *
SYSNM001
06/04/96 10:56:47
Page
24
* * * *
SYSNM001 940909 RN IBM ILE RPG/400 A960121C/ORDENT K e y F i e l d I n f o r m a t i o n File Internal External Record field name field name Attributes 3 CUS01L CUSTOMER CUSNBR CHAR 5 5 ORDD01L ORDERDTL ORHNBR CHAR 5 PRDNBR CHAR 5 4 ORDH01L ORDERHDR ORHNBR CHAR 5 2 RSTRL HDR SRNBR CHAR 10 6 SALC01L SALESCUS SRNBR CHAR 10 CUSNBR CHAR 5 7 STOCK01L STOCK PRDNBR CHAR 5 8 STOCK02L STOCK2 is the RPG name of the external format STOCK. PRDCAT CHAR 4 * * * * * E N D O F K E Y F I E L D I N F O R M A T I O N * * * * * 5763RG1 V3R1M0
SYSNM001
06/04/96 10:56:47
Page
25
5763RG1 V3R1M0
SYSNM001 940909 RN IBM ILE RPG/400 A960121C/ORDENT E x t e r n a l R e f e r e n c e s Statically bound procedures: Procedure References No references in the source. Imported fields: Field Attributes Defined No references in the source. Exported fields: Field Attributes Defined No references in the source. * * * * * E N D O F E X T E R N A L R E F E R E N C E S * * * * *
SYSNM001
06/04/96 10:56:47
Page
31
206
5763RG1 V3R1M0 Msg id *RNF7031 *RNF7066 *RNF7089 *
SYSNM001 940909 RN IBM ILE RPG/400 A960121C/ORDENT M e s s a g e S u m m a r y Sv Number Message text 00 25 The name or indicator is not referenced. 00 1 Record-Format name of Externally-Described file is not used. 00 1 RPG provides Separate-Indicator area for file. * * * * E N D O F M E S S A G E S U M M A R Y * * * * *
SYSNM001
06/04/96 10:56:47
Page
32
5763RG1 V3R1M0
940909 RN
SYNM0M01 IBM ILE RPG/400 A960121C/ORDENT F i n a l S u m m a r y
SYSNM001
06/04/96 10:56:47
Page
33
Message Totals: Information (00) . . . . . . . : 27 Warning (10) . . . . . . . : 0 Error (20) . . . . . . . : 0 Severe Error (30+) . . . . . . : 0 --------------------------------- ------Total . . . . . . . . . . . . . : 27 Source Totals: Records . . . . . . . . . . . . : 775 Specifications . . . . . . . . : 601 Data records . . . . . . . . . : 0 Comments . . . . . . . . . . . : 174 * * * * * E N D O F F I N A L S U M M A R Y * * * * * Program ORDENT placed in library A960121C. 00 highest severity. Created on 96/06/04 at 10:58:15. * * * * * E N D O F C O M P I L A T I O N * * * * *
207
208
Appendix E. VRPG Order Entry Program

5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS Program . . . . . . . . . . . . : OE Source File . . . . . . . . . . : C:\ROADMAP\OE.vpg Generation severity level . . . : Compiler options . . . . . . . . : Debugging views . . . . . Optimization level . . . . Source listing indentation Type conversion options . Truncate numeric . . . . . Allow null values . . . . Host description cache . . Link libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : 10 *NOXREF *EXPDDS *YES *NONE *NONE *VARCHAR *YES *YES *NONE *NONE OE 6/06/96 17:39:42 Page 1
*GEN *EXT
*SECLVL
*SHOWCPY
*VARGRAPHIC
209
5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS
OE
6/06/96 17:39:42
Page
Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line S o u r c e L i s t i n g
Change Src Seq Date Id Number
1 FRSTRL IF E K DISK remote *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : RSTRL A960121/RSTRL * * Record format(s) . . . . . : HDR HDR * *--------------------------------------------------------------------------------------------* 2 FCUS01L UF E K DISK COMMIT remote *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : CUS01L A960121/CUS01L * * Record format(s) . . . . . : CUSTOMER CUSTOMER * *--------------------------------------------------------------------------------------------* 3 FORDH01L UF A E K DISK COMMIT remote *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : ORDH01L A960121/ORDH01L * * Record format(s) . . . . . : ORDERHDR ORDERHDR * *--------------------------------------------------------------------------------------------* 4 FORDD01L UF A E K DISK COMMIT remote *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : ORDD01L A960121/ORDD01L * * Record format(s) . . . . . : ORDERDTL ORDERDTL * *--------------------------------------------------------------------------------------------* 5 FSALC01L UF E K DISK COMMIT remote *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : SALC01L A960121/SALC01L * * Record format(s) . . . . . : SALESCUS SALESCUS * *--------------------------------------------------------------------------------------------* 6 FSTOCK01L UF E K DISK COMMIT remote *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : STOCK01L A960121/STOCK01L * * Record format(s) . . . . . : STOCK STOCK * *--------------------------------------------------------------------------------------------* 7 FSTOCK02L UF E K DISK COMMIT remote 8 F RENAME(STOCK:STOCK2) *--------------------------------------------------------------------------------------------* * RPG name External name * * File name. . . . . . . . . : STOCK02L A960121/STOCK02L * * Record format(s) . . . . . : STOCK2 STOCK * *--------------------------------------------------------------------------------------------* CONST( JOBI0400 ) 1 5 9 19 4B 0 8B 0 18 28
000001
000002
000003
000004
000005
000006
000007 00
9 10 11 12 13 14
D JB400 D JAREA D BRTN D BAVA D JBNAME D UNAME
C DS
000009 000010 000011 000012 000013 000014
210
5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS Line Number 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
OE
6/06/96 17:39:42
Page
<---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line D JBNBR 29 34 D JOBID 35 50 D RTVJOB 1 50 D JOBLEN 51 54B 0 D JOBFMT 55 62 D JOBNAM 63 88 D HVAR DS D ORHNBR 1 5 * D MSG1 C CONST( AUTHORIZATION DEND IED FOR THIS CUSTOD MER ) * D FLDS DS D MSGLEN 1 4B 0 D PGMSTK 5 8B 0 D RTVLEN 9 12B 0 D INDDS DS D IND1 1 2B 0 D IND2 3 4B 0 D IND3 5 6B 0 D IND4 7 8B 0 D USRINFO S 8A INZ( QUSRJOBI ) LINKAGE(*SERVER) D SetFocus C 1 DSTYLE M STYLE(*WARN) D BUTTON(*OK:*CANCEL) D D D D D D D D D D DS DTE MM DD YY DS DTE1 YY1 MM1 DD1 1 1 3 5 6 2 4 6 0 0 0 0 1 1 3 5 6 2 4 6 0 0 0 0
Change Src Seq Date Id Number 000015 000016 000017 000018 000019 000020 000021 000022 000023 000024 000025 000026 000027 000028 000029 000030 000031 000032 000033 000034 000035 000036 000037 000038 000039 000040 000041 000042 000043 000044 000045 000046 000047 000048 000049 000050 000051 000052 000053
211
OE
6/06/96 17:39:42
Page
Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line 55 ************************************************************************** 56 * * 57 * K E Y L I S T S A N D F I E L D D E F I N I T I O N S * 58 * * 59 **************************************************************************
Change Src Seq Date Id Number 000055 000056 000057 000058 000059
60=IHDR *--------------------------------------------------------------------------------------------* * RPG record format . . . . : HDR * * External format . . . . . : HDR : A960121/RSTRL * *--------------------------------------------------------------------------------------------* 61=I A 1 5 ORHNBR NUMBER 62=I A 6 15 SRNBR SESSION NUMBER 63=I P 16 21 2ORHTOT TOTAL VALUE 64=ICUSTOMER *--------------------------------------------------------------------------------------------* * RPG record format . . . . : CUSTOMER * * External format . . . . . : CUSTOMER : A960121/CUS01L * *--------------------------------------------------------------------------------------------* 65=I A 1 5 CUSNBR CODE 66=I A 6 25 CUSNAM NAME 67=I A 26 40 CUSTEL TEL. NBR. 68=I A 41 55 CUSFAX FAX NBR. 69=I A 56 75 CUSADR ADDRESS 70=I A 76 95 CUSCTY CITY 71=I A 96 100 CUSZIP ZIP CODE 72=I P 101 106 2CUSCRD CREDIT LIMIT 73=I P 107 112 2CUSTOT TOTAL ORDERED 74=IORDERHDR *--------------------------------------------------------------------------------------------* * RPG record format . . . . : ORDERHDR * * External format . . . . . : ORDERHDR : A960121/ORDH01L * *--------------------------------------------------------------------------------------------* 75=I A 1 5 ORHNBR NUMBER 76=I A 6 10 CUSNBR CUSTOMER CODE 77=I P 11 14 0ORHDTA ORDER DATE !!! 78=I P 15 18 0ORHDLY DELIVERY DATE !!! 79=I P 19 24 2ORHTOT TOTAL VALUE 80=I A 25 34 SRNBR SESSION NUMBER 81=IORDERDTL *--------------------------------------------------------------------------------------------* * RPG record format . . . . : ORDERDTL * * External format . . . . . : ORDERDTL : A960121/ORDD01L * *--------------------------------------------------------------------------------------------* 82=I A 1 5 ORHNBR NUMBER 83=I A 6 10 PRDNBR PRODUCT CODE 84=I P 11 13 0ORDQTY PROD. QUANTITY 85=I P 14 18 2ORDTOT ITEM VALUE 86=I A 19 19 PRDALT ALTERNATIVE PRD. 87=ISALESCUS *--------------------------------------------------------------------------------------------* * RPG record format . . . . : SALESCUS * * External format . . . . . : SALESCUS : A960121/SALC01L * *--------------------------------------------------------------------------------------------* 88=I A 1 10 SRNBR SR CODE
1000001 1 1 1 1 1000002 1000003 1000004 2000001 2 2 2 2 2000002 2000003 2000004 2000005 2000006 2000007 2000008 2000009 2000010 3000001 3 3 3 3 3000002 3000003 3000004 3000005 3000006 3000007 4000001 4 4 4 4 4000002 4000003 4000004 4000005 4000006 5000001 5 5 5 5 5000002
212
OE
6/06/96 17:39:42 Do Page Num Line
Page
Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 89=I A 11 15 CUSNBR CUSTOMER CODE 90=I P 16 21 2SRAMT TOTAL FOR SR 91=ISTOCK *--------------------------------------------------------------------------------------------* * RPG record format . . . . : STOCK * * External format . . . . . : STOCK : A960121/STOCK01L * *--------------------------------------------------------------------------------------------* 92=I A 1 5 PRDNBR CODE 93=I A 6 25 PRDDES DESCRIPTION 94=I P 26 29 0PRDEXP EXPIRE DATE 95=I P 30 33 2PRDPRC PRICE 96=I P 34 36 0PRDQTA ORDERABLE QTA 97=I A 37 41 SPLNBR SUPPLIER CODE 98=I A 42 45 PRDCAT CATEGORY 99=I P 46 48 0PRDQTM MINIMUN QTA 100=ISTOCK2 *--------------------------------------------------------------------------------------------* * RPG record format . . . . : STOCK2 * * External format . . . . . : STOCK : A960121/STOCK02L * *--------------------------------------------------------------------------------------------* 101=I A 1 5 PRDNBR CODE 102=I A 6 25 PRDDES DESCRIPTION 103=I P 26 29 0PRDEXP EXPIRE DATE 104=I P 30 33 2PRDPRC PRICE 105=I P 34 36 0PRDQTA ORDERABLE QTA 106=I A 37 41 SPLNBR SUPPLIER CODE 107=I A 42 45 PRDCAT CATEGORY 108=I P 46 48 0PRDQTM MINIMUN QTA 109=ISFL01R *--------------------------------------------------------------------------------------------* * Subfile record format . . : SFL01R * *--------------------------------------------------------------------------------------------* 110=I A 1 1 ALTFLD 111=I A 2 2 CHOICE 112=I A 3 7 SFCODE 113=I A 8 27 DDESCR 114=I S 28 32 0SFQTY 115=I S 33 39 2DPRICE 116=I S 40 48 2DITTOT
Change Src Seq Date Id Number 5000003 5000004 6000001 6 6 6 6 6000002 6000003 6000004 6000005 6000006 6000007 6000008 6000009 7000001 7 7 7 7 7000002 7000003 7000004 7000005 7000006 7000007 7000008 7000009 8000001 8 8 8 8000002 8000003 8000004 8000005 8000006 8000007 8000008
117 118 119 120 121 122 123 124 125 126 127 128 129 130 131
C C C C C * C C * C C C * C C
*LIKE *LIKE *LIKE *LIKE *LIKE NBRKL
DEFINE DEFINE DEFINE DEFINE DEFINE KLIST KFLD KLIST KFLD KFLD KLIST KFLD
ORHNBR CUSNBR ORHTOT CUSNBR ORHNBR
NBR CODE PORDT CUSNO NEWORD
NBR
DTLK
ORHNBR PRDNBR
ORDH
ORHNBR
000060 000061 000062 000063 000064 000065 000066 000067 000068 000069 000070 000071 000072 000073 000074
213
5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS Line Number 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187
OE
6/06/96 17:39:42
Page
<---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line * C CUST KLIST C KFLD CUSNBR * C SALC KLIST C KFLD SRNBR * C PRDK KLIST C KFLD PRDNBR * C PLIST2 PLIST C PARM RTVVAR 61 C PARM RTVLEN C PARM RTVFMT 8 C PARM RTVNAM 26 C PARM RTVID 16 * C KEYFLD KLIST C KFLD SRNBR C KFLD CUSNBR INIHDR BEGSR ***************************************************** * INITIALISE FIELDS FOR NEW ORDER HEADER INFO * ***************************************************** C Z-ADD 0 BAVA C Z-ADD 0 BRTN C Z-ADD 50 JOBLEN C MOVEL * JOBNAM C MOVEL *BLANKS JOBID C MOVEL JB400 JOBFMT C MOVEL DATE1 ORHDTE C MOVEL DATE2 ORHDLY * LenDH++--== C ENDSR C
SRCINS BEGSR ***************************************************** * INSERT ORDER HEADER DETAILS * ***************************************************** C MOVE UDATE DATE1 C MOVE DATE1 APP C ADD 1 APP C MOVEL DATE1 DATE2 C MOVE APP DATE2 C EXSR MAXKEY C EXSR INIHDR C************ MOVELRTVJBA JAREA C MOVEL 0 OK C Z-ADD 0 INSOK C SETOFF C********* WRITE EXITLINE * * The above line used to display the footer of the screen * This is now replaced by a series of SETATR s (for the
6 0 2 0 6 0 GET NEW N. ORD. LenDH++--== 1 1 0 15----
Change Src Seq Date Id Number 000075 000076 000077 000078 000079 000080 000081 000082 000083 000084 000085 000086 000087 000088 000089 000090 000091 000092 000093 000094 000095 000096 000097 000098 000099 000100 000101 000102 000103 000104 000105 000106 000107 000108 000109 000110 000111 000112 000113 000114 000115 000116 000117 000118 000119 000120 000121 000122 000123 000124 000125 000126 000127 000128 000129 000130
214
5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS Line Number 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229
OE
6/06/96 17:39:42
Page
<---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line * VRPG environment) as follows; * C C C C eval eval eval eval %setatr( order : cancel : enabled) = 0 %setatr( order : accept : enabled) = 1 %setatr( order : exit : enabled) = 1 %setatr( order : finalize : enabled) = 0 ORHNBR 50----
C MOVEL NEWORD C******************* MOVELORHNBR ORDNO C SETON * C ENDSR
SRRSTR BEGSR ***************************************************** * THIS ROUTINE INITIALISES FIELDS FOR A NEW ORDER * ***************************************************** C MOVEL *BLANKS JAREA C********** MOVEL*BLANKS RTVJBA C MOVEL(P) JB400 JOBFMT C MOVEL(P) * JOBNAM C MOVEL *BLANKS JOBID C MOVEL *BLANKS ORHNBR C MOVEL *BLANKS USERID * LenDH++--== C CALL USRINFO C PARM RTVJOB C PARM JOBLEN C PARM JOBFMT C PARM JOBNAM C PARM JOBID * LenDH++--== C********** MOVELRTVJOB JAREA C moveL A960121C uname C UNAME CHAIN RSTRL C *IN99 IFEQ 0 C EXSR SRCORD C ENDIF * LenDH++--== C ENDSR
10
99---B01 01 E01
Change Src Seq Date Id Number 000131 000132 000133 000134 000135 000136 000137 000138 000139 000140 000141 000142 000143 000144 000145 000146 000147 000148 000149 000150 000151 000152 000153 000154 000155 000156 000157 000158 000159 000160 000161 000162 000163 000164 000165 000166 000167 000168 000169 000170 000171 000172
231 232 233 234 235 236 237 238 239 240 241
SRCORD BEGSR ***************************************************** * * ***************************************************** C ORDH SETLL ORDD01L C SETOFF C ORDH READE ORDD01L * LenDH++--== C *IN80 DOWEQ *OFF C PRDK CHAIN STOCK01L C *IN81 IFEQ *OFF
80-------80 B01 01 B02
81----
000174 000175 000176 000177 000178 000179 000180 000181 000182 000183 000184
215
OE
6/06/96 17:39:42 Do Page Num Line 02 02 E02 01 01 E01
Page
<---------------------- Source Specifications ----------------------------><---- Comments ----> ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 C ADD ORDQTY PRDQTA C UPDATE STOCK C ENDIF C DELETE ORDERDTL C ORDH READE ORDD01L ----80 C ENDDO * LenDH++--== C ORDH CHAIN ORDH01L 80---C N80 DELETE ORDERHDR C COMMIT * LenDH++--== C ENDSR C MAXKEY BEGSR ***************************************************** * * ***************************************************** C MOVE *HIVAL NBR C****** SETLL ORDH01L * Hival is not supported in VRPG. The above line is * therefore replaced with the following C *END SETLL ORDH01L C * C C C C C C * C*** C C C * C *IN99 IFEQ Z-ADD ELSE MOVEL ADD ENDIF CLEAR MOVEL MOVEL MOVEL ENDSR *ON 1 ORHNBR 1 READP ORDH01L LenDH++--== AP1 AP1 AP1 LenDH++--== ORDERHDR NEWORD ORHNBR NBR LenDH++--== 5 0 ----99
B01 01 X01 01 01 E01
AP1 AP1 AP1
********************************************************************* * * * * ********************************************************************* * C ORDER BEGACT CREATE ORDER * C EXSR SRRSTR C EXSR SRCINS C MOVE *BLANKS CUSNBR C MOVE *BLANKS CUSDES C CUSNBR SETATR SetFocus FOCUS C WRITE ORDER * C ENDACT ********************************************************************* * * * *
216
OE
6/06/96 17:39:42
Page
<---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line ********************************************************************* * C ACCEPT BEGACT PRESS ORDER * C EXSR ORDENT * Continue if no errors found. Otherwise, stay on this window C *in98 ifeq *off C *in25 andeq *off C COMMIT *** THE BEGINNING OF THE ROUTINE NAMED SRRIDT IN THE *** ORIGINAL NON-VRPG VERSION OF THE PROGRAM WAS PUT IN HERE C ORDH CHAIN ORDH01L 99---C Z-ADD 0 DODCUM C MOVE 0 OK C**** Z-ADD 0 REC1 C**** WRITE LINE * The above lines were deleted for the VRPG version of * the program. They used to initialize the SFL record * number and clear the bottom part of the display screen. * C SETON 52---C**** WRITE SFL01C * The above line was deleted for the VRPG version of the program. C SETOFF 522223 * LenDH++--== C*** *IN03 DOWEQ *OFF * The above line was deleted for the VRPG version of the program. C MOVE *BLANK DPRDNR C Z-ADD 0 DQUANT C**N65 C**N66 C**N68 WRITE FOOT * The above line(s) were deleted for the VRPG version of the program. C 22 SETON 50---C SETON 51---C*** EXFMT SFL01C * The above line was deleted for the VRPG version of the program. C SETOFF 505168 C SETOFF 636465 * The following lines were added for the VRPG version of this program clear SFL01R eval %setatr( orderd : orderd : visible) = 1 eval %setatr( order : order : visible) = 0 eval %setatr( orderd : finalize : enabled) = 0 eval %setatr( orderd : orderd : focus) = 1 eval %setatr( orderd : dprdnr : focus) = 1 WRITE endif ORDERD 01 01 01
B01 01 01
01
01
01 01
01 01
01 01
C C C C C C C C
01 01 01 01 01 01 01 E01
217
OE
6/06/96 17:39:42
Page
10
<---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line * C ENDACT
ORDENT BEGSR ***************************************************** * * ***************************************************** C MOVE *BLANKS CUSDES C EXSR WRRD C CUSNO CHAIN CUS01L C Z-ADD 0 OTOT * C* *IN03 IFEQ 0 C* *IN16 ANDNE 1 * The above was removed for the VRPG version of the program * as it referred to *IN03 which is no longer used. It was * replaced by the following 1 line only C *IN16 IFNE C MOVE C MOVE C MOVE C MOVE C MOVE C WRITE C Z-ADD C MOVEL * NEXT LINE DELETED FOR VRPG C* WRITE C ELSE C 16 SETON C *MSG0001 DSPLY C CUSNBR SETATR C ENDIF * C ENDSR C 1 NEWORD UNAME CUSNO OTOT ORHDTE ORDERHDR 1 CUSNAM ORDER
16---9 2
ORHNBR SRNBR CUSNBR ORHTOT ORHDTA INSOK CUSDES
B01 01 01 01 01 01 01 01 01
SetFocus
#REPLY FOCUS LenDH++--==
98---9 0--60--
X01 01 01 01 E01
WRRD BEGSR ***************************************************** * * ***************************************************** * next line deleted for VRPG C***** WRITE ORDER C SETOFF C SETOFF C******** READ ORDENTWS C READ ORDER * * THE ABOVE LINE WAS ORIGINALLY A READ TO THE WORKSTN * FILE IN THE NON-VRPG VERSION OF THE PROGRAM. THIS IS * NO LONGER NECESSARY IN VRPG. C C ORHDTE IFGT SETON ORHDLY
979899 1523-50
25----
B01 01
218
OE
6/06/96 17:39:42
Page
11
<---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line C *MSG0002 DSPLY #REPLY 9 0--60-01 C ORHDLY SETATR SetFocus FOCUS 01 C ENDIF E01 C MOVEL CUSNBR CUSNO * LenDH++--== C ENDSR
********************************************************************* * * * * ********************************************************************* * C EXIT BEGACT PRESS ORDER * C move *on *inlr * C ENDACT ********************************************************************* * * * * ********************************************************************* * C CANCEL BEGACT PRESS ORDERD * C ROLBK C MOVE *BLANKS CUSNBR C MOVE *BLANKS CUSDES C eval %setatr( order : cusnbr : focus) = 1 C eval %setatr( orderd : orderd : visible) = 0 C eval %setatr( orderd : orderd : focus) = 0 C eval %setatr( order : order : visible) = 1 C eval %setatr( order : order : focus) = 1 C WRITE ORDER C EXSR SRRSTR C EXSR SRCINS C ENDACT
********************************************************************* * * * * ********************************************************************* * C ENTER BEGACT PRESS ORDERD * C READ ORDERD C EXSR SRRIDT C ENDACT ********************************************************************* * * * * *********************************************************************
219
OE
6/06/96 17:39:42
Page
12
<---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line * C FINALIZE BEGACT PRESS ORDERD C EXSR SRFNLO
* return for next order C**** Z-ADD C C C C C C C C C EXSR EXSR MOVEL MOVE eval eval eval WRITE ENDACT
TOTAMT
SRRSTR SRCINS *BLANKS CUSNBR *BLANKS CUSDES %setatr( orderd : orderd : visible) = 0 %setatr( order : order : visible) = 1 %setatr( order : cusnbr : focus) = 1 ORDER
SRFNLO BEGSR ***************************************************** * * ***************************************************** C MOVE *BLANK WSR 10 C SETOFF * * If the total order amount is greater than the customer s * credit limit, the program displays an error message. * C CUST CHAIN CUS01L * LenDH++--== C *IN80 IFEQ *OFF * C CUSCRD IFGE PORDT C ADD PORDT CUSTOT C UPDATE CUSTOMER C ELSE C SETON C *MSG0005 DSPLY #REPLY C eval %setatr( orderd : dprdnr : focus) C ENDIF * LenDH++--== C ELSE C SETON C *MSG0005 DSPLY #REPLY C eval %setatr( orderd : dprdnr : focus) C ENDIF * * The total order amount is added to the sales_rep s amount. * LenDH++--== C ORDH CHAIN ORDH01L C *IN80 IFEQ *OFF C SALC CHAIN SALC01L C *IN81 IFEQ *OFF C ADD PORDT SRAMT
01----
80---B01 B02 02 02 X02 02 02 02 E02 X01 01 01 01 E01
6601---60-= 1
6601---60-= 1
80---81---B01 01 B02 02
220
OE
6/06/96 17:39:42 Do Page Num Line 02 X02 02 02 02 E02 E01
Page
13
<---------------------- Source Specifications ----------------------------><---- Comments ----> ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 C UPDATE SALESCUS C ELSE C SETON 4401-C *MSG0007 DSPLY #REPLY --60-C eval %setatr( orderd : dprdnr : focus) = 1 C ENDIF C ENDIF * C ORDH CHAIN ORDH01L 80---* LenDH++--== C *IN80 IFEQ *OFF C Z-ADD PORDT ORHTOT C MOVE 0 OKAUD 1 C EXSR SRRADT * LenDH++--== C OKAUD IFEQ 0 C UPDATE ORDERHDR --81-C 81 SETON 7701-C 81*MSG0011 DSPLY #REPLY --60-C 81 eval %setatr( orderd : dprdnr : focus) = 1 C ELSE C*** *LOVAL SETLL ORDH01L 80 * The above line was changed as *loval is not supported in VRPG C *start setll ordh01l C ROLBK C EXSR SRCORD C SETON 77---NO ROLBK LAST DELE C *MSG0011 DSPLY #REPLY --60-C eval %setatr( orderd : dprdnr : focus) = 1 C ENDIF * LenDH++--== C ELSE C SETON 7701-C *MSG0011 DSPLY #REPLY --60-C eval %setatr( orderd : dprdnr : focus) = 1 * C ENDIF C* C *IN01 IFEQ *OFF C* MOVE 0 RTNCD C COMMIT C ELSE C* MOVE 1 RTNCD C* EXSR ERR C ROLBK C ENDIF * LenDH++--== C ENDSR SRRADT BEGSR ***************************************************** * GET THE USERID * ***************************************************** C Z-ADD 61 RTVLEN C MOVEL JOBI0400 RTVFMT C MOVEL(P) * RTVNAM C
B01 01 01 01 B02 02 02 02 02 X02
02 02 02 02 02 02 E02 X01 01 01 01 E01 B01 01 X01
01 E01
221
OE
6/06/96 17:39:42 Do Page Num Line
Page
14
<---------------------- Source Specifications ----------------------------><---- Comments ----> ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 C MOVE(P) RTVID C************** CALL QUSRJOBI PLIST2 C************** MOVE RTVVAR RTVAPI C KEYFLD CHAIN SALC01L 71---* LenDH++--== C *IN71 IFEQ 1 C******** MOVEL MSG1 MSGFLD C******** EXFMT DSPM * The above 2 lines used to display a message window. * They are now replaced with the following line. C msg1 dsply style #reply C MOVE 1 OKAUD C ENDIF * LenDH++--== C ENDSR
B01
01 01 E01
SRRIDT BEGSR ***************************************************** * * ***************************************************** * The beginning of the original SRRIDT routine, can now * be found in the Accept push botton event routine * (of the ORDER window) * Check to see if requester wants to delete a line in the sub-file
C* 22 READC SFL01R C READC SFL01R * In the original program, *in22 (above) was used by * the program to determine whether or not to display * the sub-file. This is no longer required C *IN81 IFEQ *OFF C* *IN22 ANDEQ *ON * the above line was deleted for the VRPG version C C C C C* C C C * * * * C C C C C * SELECT WHENEQ D OREQ d EXSR DLTPRD WHEQ OTHER ENDSL ELSE MOVE 0 OK
81 ----81
B01
CHOICE CHOICE CHOICE
B02 X02 02 02 E02 X01 01
The CALL of the STOCK PROCEDURE (at the remote system) is prepared. The indicator variables are set to zero: MOVE MOVE MOVE MOVE MOVE *ZERO *BLANK *ZERO *ZERO *ZERO IND1 DDESCR IND3 DPRICE IND4 -1=no prod fnd Prod descriptio -1=no alternat. Prod price -1=EXPIRED 01 01 01 01 01
222
OE
6/06/96 17:39:42 Do Page Num Line 01 B02 02 02 02 02 02 X02 B03 03 03 03 03 03 03 X03 B04 04 04 04 X04 04 04 04 E04 03 03 03 03 03
Page
15
<---------------------- Source Specifications ----------------------------><---- Comments ----> ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 C EXSR RSTO * C IND4 IFLT *ZERO Item EXPIRED C MOVE 1 *IN68 C *MSG0006 DSPLY #REPLY --60-C eval %setatr( orderd : dprdnr : focus) = 1 C MOVE *BLANK DDESCR C MOVE *ZERO DPRICE C ELSE C IND1 IFLT *ZERO Item not found C IND3 ORLT *ZERO C MOVE 1 *IN65 C *MSG0004 DSPLY #REPLY --60-C eval %setatr( orderd : dprdnr : focus) = 1 C MOVE *BLANK DDESCR C MOVE *ZERO DPRICE C ELSE IF ITEM FOUND * LenDH++--== C PRDNBR IFNE DPRDNR Alternat. item C MOVE 1 *IN67 C MOVE A PRDALT C MOVE A ALTFLD C ELSE C MOVE 0 *IN67 C MOVE PRDALT C MOVE ALTFLD C ENDIF END IF ALTERN * LenDH++--== C MOVE PRDNBR DPRDNR Product # C MOVE PRDNBR SFCODE Product # C Z-ADD DQUANT SFQTY C DPRICE MULT DQUANT DITTOT Item total C DITTOT ADD DODCUM DODCUM Cumulative * * An order detail record is inserted in the local database, * if referential integrity rules are not violated, i.e. * the primary key of ORDERDTL file must be unique, and/or a * corresponding order number must exist in the ORDERHDR * parent file. Otherwise an SQL error message is sent from * database management: * C MOVE DPRDNR PRDNBR C MOVE DQUANT ORDQTY C MOVE DITTOT ORDTOT C MOVE DITTOT PORDT C WRITE ORDERDTL --80-* C *IN80 IFEQ *ON ERROR WRITING C SETON 64---C *MSG0003 DSPLY #REPLY --60-C eval %setatr( orderd : dprdnr : focus) = 1 C EXSR SUBTR C ELSE C***** ADD 1 REC1 C MOVE *BLANKS CHOICE C WRITE SFL01R
03 03 03 03 03 B04 04 04 04 04 X04 04 04
223
5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS Line Number 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733
OE
6/06/96 17:39:42 Do Page Num Line 04 04 04 04 04 04 E04 E03 E02 E01
Page
16
<---------------------- Source Specifications ----------------------------><---- Comments ----> ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 C MOVE *BLANKS DPRDNR C Z-ADD 0 DQUANT C eval %setatr( orderd : finalize : enabled) = 1 C eval %setatr( orderd : dprdnr : focus) = 1 C WRITE ORDERD C SETON 22---C ENDIF C ENDIF C ENDIF C ENDIF C**** ENDDO * C**** SETLR TAG C*** COMMIT * The above line(s) are commented out in this (VRPG version). * They now belong in the Finalize Action subroutine * C ENDSR
DLTPRD BEGSR ************************************************* * * ************************************************* C MOVE SFCODE PRDNBR DTLK N82 CHAIN DELETE EXSR SETON UPDATE SETOFF ENDSR ORDD01L ORDERDTL SUBTR SFL01R 23---LenDH++--== 82----
C C C C C C * C
23----
SUBTR BEGSR ***************************************************** * The accumul. order total on the display has to be * * adjusted: * ***************************************************** C SUB DITTOT DODCUM C ENDSR
Change Src Seq Date Id Number 000633 000634 000635 000636 000637 000638 000639 000640 000641 000642 000643 000644 000645 000646 000647 000648 000649 000650 000651 000652 000653 000654 000655 000656 000657 000658 000659 000660 000661 000662 000663 000664 000665 000666 000667 000668 000669 000670 000671 000672 000673 000674 000675 000676
735 736 737 738 739 740 741 742 743
RSTO BEGSR ***************************************************** * CHECK PRODUCT REQUESTED. * ***************************************************** C MOVE *ZERO WQTA C MOVE *BLANK WCAT * C STK1 KLIST
5 0 4
000678 000679 000680 000681 000682 000683 000684 000685 000686
224
OE
6/06/96 17:39:42 Do Page Num Line
Page
17
<---------------------- Source Specifications ----------------------------><---- Comments ----> ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 C KFLD DPRDNR C STK2 KLIST C KFLD WCAT * C Z-ADD ORHDLY DTE C EXSR CVTDTE C Z-ADD DTE1 DELDT 6 0 C* C STK1 CHAIN STOCK01L 80---C* C *IN80 IFEQ *ON C MOVE -1 IND1 C MOVE *ZERO IND3 C MOVE *BLANK DDESCR C MOVE *ZERO DPRICE C GOTO DONE0 C ELSE C Z-ADD PRDEXP DTE C EXSR CVTDTE C Z-ADD DTE1 EXPDT 6 0 C EXPDT IFGE DELDT C Z-ADD PRDQTA WQTA C Z-ADD PRDPRC DPRICE C MOVE PRDCAT WCAT C MOVE PRDDES DDESCR C ENDIF C ENDIF C* C* If the available quantity is enough to meet the ordered C* quantity, the product record is updated and the product C* information is passed back to the calling subroutine. C* C WQTA IFGE DQUANT C WQTA SUB DQUANT LEFTQ 5 0 C Z-ADD LEFTQ PRDQTA C UPDATE STOCK C MOVE *ZERO IND1 C MOVE *ZERO IND3 C GOTO DONE0 C ELSE C* *LOVAL SETLL STOCK01L * The above line was changed as *loval is not supported in VRPG C *START SETLL STOCK01L C END C* C* If there is not enough quantity for the customer-ordered C* OR EXPIR DATE OF PRODUCT IF NOT COMPATIBLE WITH DELIVERY ORDER DATE C* ,an alternative within same product category number is C* searched. C* We assume that we ll pass back only the first one to the C* calling subroutine even though there may be several alternatives C* in the STOCK file. C* C STK2 SETLL STOCK02L C SETOFF 81---C STK2 READE STOCK02L ----81
B01 01 01 01 01 01 X01 01 01 01 B02 02 02 02 02 E02 E01
B01 01 01 01 01 01 01 X01
01 E01
225
OE
6/06/96 17:39:42 Do Page Num Line
Page
18
<---------------------- Source Specifications ----------------------------><---- Comments ----> ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 C Z-ADD PRDEXP DTE C EXSR CVTDTE C Z-ADD DTE1 EXPDT 6 0 C *IN81 DOWEQ *OFF C PRDQTA ANDLT DQUANT C EXPDT ANDGT DELDT C STK2 READE STOCK02L ----81 C *IN81 IFEQ *OFF C Z-ADD PRDEXP DTE C EXSR CVTDTE C Z-ADD DTE1 EXPDT 6 0 C ENDIF C ENDDO C* C *IN81 IFEQ *OFF C MOVE PRDNBR DPRDNR C MOVE PRDDES DDESCR C MOVE PRDPRC DPRICE C Z-ADD PRDQTA WQTA C ELSE C EXPDT IFGT DELDT C MOVE -1 IND3 C ELSE C MOVE -1 IND4 C ENDIF C MOVE *ZERO IND1 C MOVE *BLANK DDESCR C MOVE *ZERO DPRICE C GOTO DONE1 C ENDIF C* C WQTA SUB DQUANT LEFTQ C Z-ADD LEFTQ PRDQTA C UPDATE STOCK2 C* C MOVE *ZERO IND1 C MOVE *ZERO IND3 C* C DONE1 TAG C DONE0 TAG * C ENDSR ***************************************************** *COVERT DATE FROM MDY TO YMD FORMAT * ***************************************************** C CVTDTE BEGSR C MOVE YY YY1 C MOVE MM MM1 C MOVE DD DD1 C ENDSR
B01 01 01 01 B02 02 02 02 E02 E01 B01 01 01 01 01 X01 B02 02 X02 02 E02 01 01 01 01 E01
********************************************************************* * * * * *********************************************************************
226
OE
6/06/96 17:39:42 Do Page Num Line
Page
19
Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 856 * 857 C SFL01R BEGACT LOSTFOCUS ORDERD 858 * 859 860 C READC SFL01R ----81 861 * In the original program, *in22 (above) was used by 862 * the program to determine whether or not to display 863 * the sub-file. This is no longer required 864 865 C *IN81 IFEQ *OFF 866 C* *IN22 ANDEQ *ON 867 * the above line was deleted for the VRPG version 868 869 C SELECT 870 C CHOICE WHENEQ D 871 C EXSR DLTPRD 872 C* CHOICE WHEQ OTHER 873 C ENDSL 874 C endif 875 876 C ENDACT 877 878=OCUSTOMER *--------------------------------------------------------------------------------------------* * RPG record format . . . . : CUSTOMER * * External format . . . . . : CUSTOMER : A960121/CUS01L * *--------------------------------------------------------------------------------------------* 879=O CUSNBR 5A CHAR 5 CODE 880=O CUSNAM 25A CHAR 20 NAME 881=O CUSTEL 40A CHAR 15 TEL. NBR. 882=O CUSFAX 55A CHAR 15 FAX NBR. 883=O CUSADR 75A CHAR 20 ADDRESS 884=O CUSCTY 95A CHAR 20 CITY 885=O CUSZIP 100A CHAR 5 ZIP CODE 886=O CUSCRD 106P PACK 11,2 CREDIT LIMIT 887=O CUSTOT 112P PACK 11,2 TOTAL ORDERED 888=OORDERHDR *--------------------------------------------------------------------------------------------* * RPG record format . . . . : ORDERHDR * * External format . . . . . : ORDERHDR : A960121/ORDH01L * *--------------------------------------------------------------------------------------------* 889=O ORHNBR 5A CHAR 5 NUMBER 890=O CUSNBR 10A CHAR 5 CUSTOMER CODE 891=O ORHDTA 14P PACK 6,0 ORDER DATE !!! 892=O ORHDLY 18P PACK 6,0 DELIVERY DATE !!! 893=O ORHTOT 24P PACK 11,2 TOTAL VALUE 894=O SRNBR 34A CHAR 10 SESSION NUMBER 895=OORDERDTL *--------------------------------------------------------------------------------------------* * RPG record format . . . . : ORDERDTL * * External format . . . . . : ORDERDTL : A960121/ORDD01L * *--------------------------------------------------------------------------------------------* 896=O ORHNBR 5A CHAR 5 NUMBER 897=O PRDNBR 10A CHAR 5 PRODUCT CODE 898=O ORDQTY 13P PACK 5,0 PROD. QUANTITY 899=O ORDTOT 18P PACK 9,2 ITEM VALUE
B01
B02 X02 02 E02 E01
227
OE
6/06/96 17:39:42
Page
20
Line <---------------------- Source Specifications ----------------------------><---- Comments ----> Do Page Number ....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10 Num Line 900=O PRDALT 19A CHAR 1 ALTERNATIVE PRD. 901=OSALESCUS *--------------------------------------------------------------------------------------------* * RPG record format . . . . : SALESCUS * * External format . . . . . : SALESCUS : A960121/SALC01L * *--------------------------------------------------------------------------------------------* 902=O SRNBR 10A CHAR 10 SR CODE 903=O CUSNBR 15A CHAR 5 CUSTOMER CODE 904=O SRAMT 21P PACK 11,2 TOTAL FOR SR 905=OSTOCK *--------------------------------------------------------------------------------------------* * RPG record format . . . . : STOCK * * External format . . . . . : STOCK : A960121/STOCK01L * *--------------------------------------------------------------------------------------------* 906=O PRDNBR 5A CHAR 5 CODE 907=O PRDDES 25A CHAR 20 DESCRIPTION 908=O PRDEXP 29P PACK 6,0 EXPIRE DATE 909=O PRDPRC 33P PACK 7,2 PRICE 910=O PRDQTA 36P PACK 5,0 ORDERABLE QTA 911=O SPLNBR 41A CHAR 5 SUPPLIER CODE 912=O PRDCAT 45A CHAR 4 CATEGORY 913=O PRDQTM 48P PACK 5,0 MINIMUN QTA 914=OSTOCK2 *--------------------------------------------------------------------------------------------* * RPG record format . . . . : STOCK2 * * External format . . . . . : STOCK : A960121/STOCK02L * *--------------------------------------------------------------------------------------------* 915=O PRDNBR 5A CHAR 5 CODE 916=O PRDDES 25A CHAR 20 DESCRIPTION 917=O PRDEXP 29P PACK 6,0 EXPIRE DATE 918=O PRDPRC 33P PACK 7,2 PRICE 919=O PRDQTA 36P PACK 5,0 ORDERABLE QTA 920=O SPLNBR 41A CHAR 5 SUPPLIER CODE 921=O PRDCAT 45A CHAR 4 CATEGORY 922=O PRDQTM 48P PACK 5,0 MINIMUN QTA 923=OSFL01R *--------------------------------------------------------------------------------------------* * Subfile record format . . : SFL01R * *--------------------------------------------------------------------------------------------* 924=O ALTFLD 1A CHAR 1 925=O CHOICE 2A CHAR 1 926=O SFCODE 7A CHAR 5 927=O DDESCR 27A CHAR 20 928=O SFQTY 32S ZONE 5,0 929=O DPRICE 39S ZONE 7,2 930=O DITTOT 48S ZONE 9,2 * * * * * E N D O F S O U R C E * * * * *
Change Src Seq Date Id Number 11000006 12000001 12 12 12 12 12000002 12000003 12000004 13000001 13 13 13 13 13000002 13000003 13000004 13000005 13000006 13000007 13000008 13000009 14000001 14 14 14 14 14000002 14000003 14000004 14000005 14000006 14000007 14000008 14000009 15000001 15 15 15 15000002 15000003 15000004 15000005 15000006 15000007 15000008
228
OE
6/06/96 17:39:42
Page
21
A d d i t i o n a l D i a g n o s t i c M e s s a g e s *RNF7066 00 1 Record-Format HDR not used for input or output. * * * * * E N D O F A D D I T I O N A L D I A G N O S T I C M E S S A G E S * * * * *
O u t p u t
B u f f e r
P o s i t i o n s
Line Start End Field or Constant Number Pos Pos 879 1 5 CUSNBR 880 6 25 CUSNAM 881 26 40 CUSTEL 882 41 55 CUSFAX 883 56 75 CUSADR 884 76 95 CUSCTY 885 96 100 CUSZIP 886 101 106 CUSCRD 887 107 112 CUSTOT 889 1 5 ORHNBR 890 6 10 CUSNBR 891 11 14 ORHDTA 892 15 18 ORHDLY 893 19 24 ORHTOT 894 25 34 SRNBR 889 1 5 ORHNBR 890 6 10 CUSNBR 891 11 14 ORHDTA 892 15 18 ORHDLY 893 19 24 ORHTOT 894 25 34 SRNBR 896 1 5 ORHNBR 897 6 10 PRDNBR 898 11 13 ORDQTY 899 14 18 ORDTOT 900 19 19 PRDALT 902 1 10 SRNBR 903 11 15 CUSNBR 904 16 21 SRAMT 906 1 5 PRDNBR 907 6 25 PRDDES 908 26 29 PRDEXP 909 30 33 PRDPRC 910 34 36 PRDQTA 911 37 41 SPLNBR 912 42 45 PRDCAT 913 46 48 PRDQTM 915 1 5 PRDNBR 916 6 25 PRDDES 917 26 29 PRDEXP 918 30 33 PRDPRC 919 34 36 PRDQTA 920 37 41 SPLNBR 921 42 45 PRDCAT 922 46 48 PRDQTM 924 1 1 ALTFLD 925 2 2 CHOICE 926 3 7 SFCODE
5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS 927 928 929 930 924 925 926 927 928 929 930 * * * * * 8 28 33 40 1 2 3 8 28 33 40 27 32 39 48 1 2 7 27 32 39 48 E N D DDESCR SFQTY DPRICE DITTOT ALTFLD CHOICE SFCODE DDESCR SFQTY DPRICE DITTOT O F O U T P U T B U F F E R
OE
6/06/96 17:39:42
Page
22
P O S I T I O N
* * * *
229
5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS K e y File Record 2 CUS01L CUSTOMER CUSNBR 4 ORDD01L ORDERDTL ORHNBR PRDNBR 3 ORDH01L ORDERHDR ORHNBR 1 RSTRL HDR SRNBR 5 SALC01L SALESCUS SRNBR CUSNBR 6 STOCK01L STOCK PRDNBR 7 CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR F i e l d
OE
6/06/96 17:39:42
Page
23
I n f o r m a t i o n
Internal field name
External field name
Attributes
5 5
10
10 5
STOCK02L STOCK2 is the RPG name of the external format STOCK. PRDCAT CHAR 4 E N D O F K E Y F I E L D I N F O R M A T I O N * * * * *
* * * * *
5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS E x t e r n a l Statically bound procedures: Procedure No references in the source. * * * * * E N D O F E X T E R N A L
OE
6/06/96 17:39:42
Page
29
R e f e r e n c e s
References
R E F E R E N C E S
* * * * *
V i s u a l Action Subroutine ACCEPT+PRESS+ORDER CANCEL+PRESS+ORDERD ENTER+PRESS+ORDERD EXIT+PRESS+ORDER FINALIZE+PRESS+ORDERD ORDER+CREATE+ORDER SFL01R+LOSTFOCUS+ORDERD * * * * * E N D O F
C r o s s
R e f e r e n c e
Parent ORDER ORDERD ORDERD ORDER ORDERD ORDER ORDERD V I S U A L
Part ACCEPT CANCEL ENTER EXIT FINALIZE ORDER SFL01R R E F E R E N C E
Event PRESS PRESS PRESS PRESS PRESS CREATE LOSTFOCUS * * * * *
230
5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS M e s s a g e S u m m a r y
OE
6/06/96 17:39:42
Page
30
Msg id Sv Number Message text *RNF7031 00 23 The name or indicator is not referenced. Cause . . . . . : The field, subfield, TAG, data structure, PLIST, KLIST, subroutine or indicator is defined in the program but not referenced. Recovery . . . : Reference the item, or remove it from the program. Compile again. *RNF7066 00 1 Record-Format name of Externally-Described file is not used. Cause . . . . . : There is a Record-Format name for an Externally-Described File that is not used on a valid input or output operation. Recovery . . . : Use the Record-Format name of the Externally-Described File for input or output, or specify the name as a parameter for keyword IGNORE. Compile again. * * * * * E N D O F M E S S A G E S U M M A R Y * * * * *
5763VR1 V3R1M1, 5716CL1 V3R6 IBM VRPG CLIENT/2, ADTS CS F i n a l Message Totals: Information (00) . . . . . . . : Warning (10) . . . . . . . : Error (20) . . . . . . . : Severe Error (30+) . . . . . . : --------------------------------Total . . . . . . . . . . . . . : 24 0 0 0 ------24 S u m m a r y
OE
6/06/96 17:39:42
Page
31
Source Totals: Records . . . . Specifications Data records . Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : 927 601 0 265 S U M M A R Y * * * * *
* * * * * E N D O F F I N A L Maximum message severity issued 0.
231
232
Appendix F. Special Notices
This publication is intended to help AS/400 customers and AS/400 application developers, by showing them how to make existing, old, unstructured applications more modern and appropriate for the 21st century. References in this publication to IBM products, programs or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM s product, program, or service may be used. Any functionally equivalent program that does not infringe any of IBM s intellectual property rights may be used instead of the IBM product, program or service. Information in this book was developed in conjunction with use of the equipment specified, and is limited in application to those specific hardware and software products and levels. IBM may have this document. these patents. Licensing, IBM patents or pending patent applications covering subject matter in The furnishing of this document does not give you any license to You can send license inquiries, in writing, to the IBM Director of Corporation, 500 Columbus Avenue, Thornwood, NY 10594 USA.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The information about non-IBM ( vendor ) products in this manual has been supplied by the vendor and IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer s ability to evaluate and integrate them into the customer s operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Any performance data contained in this document was determined in a controlled environment, and therefore, the results that may be obtained in other operating environments may vary significantly. Users of this document should verify the applicable data for their specific environment. Reference to PTF numbers that have not been released through the normal distribution process does not imply general availability. The purpose of including these reference numbers is to alert IBM customers to specific
233
information relative to the implementation of the PTF when it becomes available to each customer according to the normal IBM PTF distribution process. The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries:
IBM
The following terms are trademarks of other companies: C-bus is a trademark of Corollary, Inc. PC Direct is a trademark of Ziff Communications Company and is used by IBM Corporation under license. UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Limited. Microsoft, Windows, and the Windows 95 logo are trademarks or registered trademarks of Microsoft Corporation.
Other trademarks are trademarks of their respective companies.
234
Appendix G. Related Publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
G.1 International Technical Support Organization Publications

For information on ordering these ITSO publications see How to Get ITSO Redbooks on page 237.
AS/400 Applications: Year 2000 Enablement and Services Considerations , SG24-4790 Software Life Cycle Management with Application Development Manager/400 Systemview Manager/400 , SG24-4187 Moving to ILE for RPG IV , GG24-4358 DB2/400 Advanced Database Functions , GG24-4249 An Implementation Guide for AS/400 Security and Auditing , GG24-4200
G.2 Redbooks on CD-ROMs

Redbooks are also available on CD-ROMs. Order a subscription and receive updates 2-4 times a year at significant savings.
CD-ROM Title System/390 Redbooks Collection Networking and Systems Management Redbooks Collection Transaction Processing and Data Management Redbook AS/400 Redbooks Collection RISC System/6000 Redbooks Collection (HTML, BkMgr) RISC System/6000 Redbooks Collection (PostScript) Application Development Redbooks Collection Personal Systems Redbooks Collection Subscription Number SBOF-7201 SBOF-7370 SBOF-7240 SBOF-7270 SBOF-7230 SBOF-7205 SBOF-7290 SBOF-7250 Collection Kit Number SK2T-2177 SK2T-6022 SK2T-8038 SK2T-2849 SK2T-8040 SK2T-8041 SK2T-8037 SK2T-8042
G.3 Other Publications

These publications are also relevant as further information sources.
The Year 2000 and 2-Digit Dates: A Guide for Planning and Implementation , GC28-1251 AS/400 ILE Application Development Example , SC41-3602 AS/400 Application Development Handbook , G325-6249 AS/400 Work Management Guide , SC41-4306 DB2/400 SQL Reference , SC41-3612 Installing Application Development ToolSet Client Server for OS/400 , SC09-2188 Client/Server Visual Programming with VRPG Client for OS/2 , SC09-2131 VRPG Client for OS/2 Parts Reference , SC09-1846
235
VRPG Client for OS/2 Language Reference , SC09-1847 Getting Started with VRPG Client for OS/2 , SC09-2195 Application Dictionary Services/400 User s Guide , SC09-1860-00 Application Development ToolSet/400: Application Development Manager/400 Introduction and Planning Guide , GC09-1807 Application Development ToolSet/400: Application Development Manager/400 User s Guide , SC09-2133 CODE/400 Debug Tool V3R1 , SC09-1905 CODE/400 Installation V3R1 , SC09-1908 LPEX Command Reference V3R1 , SC09-1910 CODE/400 V3R1 Self-Study Guide , SC09-1911 ADTS CS/400 V3R1 Intro to Application Development Using , SC09-1934 Introducing ADTS/400 & AS/400 Server Access Programs V3R1 , SC09-1939
236
How to Get ITSO Redbooks

This section explains how both customers and IBM employees can find out about ITSO redbooks, CD-ROMs, workshops, and residencies. A form for ordering books and CD-ROMs is also provided. This information was current at the time of publication, but is continually subject to change. The latest information may be found at URL http://www.redbooks.ibm.com.
How IBM Employees Can Get ITSO Redbooks

Employees may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and information about redbooks, workshops, and residencies in the following ways:

PUBORDER to order hardcopies in United States GOPHER link to the Internet - type GOPHER.WTSCPOK.ITSO.IBM.COM Tools disks To get LIST3820s of redbooks, type one of the following commands:
TOOLS SENDTO EHONE4 TOOLS2 REDPRINT GET SG24xxxx PACKAGE TOOLS SENDTO CANVM2 TOOLS REDPRINT GET SG24xxxx PACKAGE (Canadian users only)
To get lists of redbooks:
TOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET ITSOCAT TXT TOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET LISTSERV PACKAGE
To register for information on workshops, residencies, and redbooks:
TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ITSOREGI 1996

For a list of product area specialists in the ITSO:
TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ORGCARD PACKAGE
Redbooks Home Page on the World Wide Web
http://w3.itso.ibm.com/redbooks
IBM Direct Publications Catalog on the World Wide Web
http://www.elink.ibmlink.ibm.com/pbl/pbl
IBM employees may obtain LIST3820s of redbooks from this page.

REDBOOKS category on INEWS Online send orders to: USIB6FPL at IBMMAIL or DKIBMBSH at IBMMAIL Internet Listserver With an Internet e-mail address, anyone can subscribe to an IBM Announcement Listserver. To initiate the service, send an e-mail note to announce@webster.ibmlink.ibm.com with the keyword subscribe in the body of the note (leave the subject line blank). A category form and detailed instructions will be sent to you.
237
How Customers Can Get ITSO Redbooks

Customers may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and information about redbooks, workshops, and residencies in the following ways:
Online Orders (Do not send credit card information over the Internet) send orders to:
IBMMAIL usib6fpl at ibmmail caibmbkz at ibmmail dkibmbsh at ibmmail Internet usib6fpl@ibmmail.com lmannix@vnet.ibm.com bookshop@dk.ibm.com
In United States: In Canada: Outside North America:
Telephone orders
United States (toll free) Canada (toll free) Outside North America (+45) 4810-1320 - Danish (+45) 4810-1420 - Dutch (+45) 4810-1540 - English (+45) 4810-1670 - Finnish (+45) 4810-1220 - French 1-800-879-2755 1-800-IBM-4YOU (long (+45) (+45) (+45) (+45) (+45) distance charges apply) 4810-1020 - German 4810-1620 - Italian 4810-1270 - Norwegian 4810-1120 - Spanish 4810-1170 - Swedish
Mail Orders send orders to:

I B M Publications Publications Customer Support P.O. Box 29570 Raleigh, NC 27626-0570 USA I B M Publications 144-4th Avenue, S.W. Calgary, Alberta T2P 3N5 Canada IBM Direct Services Sortemosevej 21 DK-3450 Allerd Denmark
Fax send orders to:

United States (toll free) Canada Outside North America 1-800-445-9269 1-403-267-4455 (+45) 48 14 2207
(long distance charge)
1-800-IBM-4FAX (United States) or (+1) 415 855 43 29 (Outside USA) ask for: Index # 4421 Abstracts of new redbooks Index # 4422 IBM redbooks Index # 4420 Redbooks for last six months
Direct Services - send note to softwareshop@vnet.ibm.com On the World Wide Web Redbooks Home Page IBM Direct Publications Catalog http://www.redbooks.ibm.com http://www.elink.ibmlink.ibm.com/pbl/pbl
Internet Listserver With an Internet e-mail address, anyone can subscribe to an IBM Announcement Listserver. To initiate the service, send an e-mail note to announce@webster.ibmlink.ibm.com with the keyword subscribe in the body of the note (leave the subject line blank).
238
IBM Redbook Order Form

Please send me the following:
Title Order Number Quantity
First name Company Address City Telephone number Invoice to customer number Credit card number
Last name
Postal code Telefax number
Country VAT number
Credit card expiration date
Card issued to
Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not available in all countries. Signature mandatory for credit card payment. DO NOT SEND CREDIT CARD INFORMATION OVER THE INTERNET.
How to Get ITSO Redbooks
239
240
List of Abbreviations
CL DDS DSU GUI IBM ILE
Command Language Data Description Specofications Design Screen Utility Graphical User Interface International Business Machines Corporation Interactive Language Environment
LPEX PDM RI RLU SDA SEU
Live Parsing Extensible Editor Program Development Manager Referential Integraty Report Layout Utility Screen Design Aid Source Entry Utility
241
242
Index Special Characters

*CYMD support *DATE 74 *DAY 74 *MONTH 74 *YEAR 74 73
D
data exposure type solution considerations 49 data sharing 40 date arithmetic operations 82 arithmetic using OPNQRYF command 87 comparison using OPNQRYF command 85 cosmetic 42 duration 80, 86 date and time arithmetic operations 81 84 date data field 71 date format for DB2/400 SQL 79 specifying current value 80 date value for DB2/400 SQL 79 dates used as special values 26 debugging 55 duration date 80 labeled 80 time 81 time stamp 81 duration (date, time, and time stamp) 85
A
abbreviations 241 acronyms 241 ADDDUR (add duration) operation code 75 ADM/400 ADS/400 ADTS CS/400 CODE/400 feature 143 VRPG 143 VRPG Client feature 143 ADTS/400 PDM 143 SDA 143 SEU 143 Application Development Manager/400 143 benefits of 120 Application Development ToolSet 143 Application Development ToolSet Client Server 143 arithmetic operations using OPNQRYF command date 87 time 88 time stamp 89
E
edit, date 75 examples CURRENT DATE 80 CURRENT TIMEZONE 80 special register 80 exposures locating 37 exposures classification 26 expression date and time operands 80 EXTRCT (extract date/time) operation code
B
bibliography 235 BLDPART 128 bridge programs used as a conversion tool 50
C
calculations incorrect 26 century support 73 CODE/400 compile 143 verification 143 collating incorrect 26 cosmetic date 42 CRTPRJ 124
75
G
guideline for using reformatting techniques 52
I
identifying two-digit years approaches 37 locating direct references 37 locating indirect references 37 using a test system 37
243
impact severity category 33 IMPPART 127 integrity 26 internal format default formats 71 definition 71 introduction to Year 2000 transition
25
L
labeled duration 80, 85 leap year calculation 27 locating exposures 37 locating two-digit years 37
M
misconceptions of the year 2000 challenge 25
solution considerations to data exposure type 49 solutions for reformatting year notation externalize four-digit format 42, 43 fixed window 46 sliding window 46 use common service routine 49 special value dates 26 special words 74 standards ANSI 52 ISO 52 statements for DB2/400 SQL date value 79 time value 79 time-stamp value 79 SUBDUR (subtract duration) operation code
75
T
technique for reformatting year notation 41 externalize four-digit format 42, 43 fixed window 46 sliding window 46 use common service routine 49 TEST (test date/time/time stamp) operation code testing 55 a function s implementation 55 acceptance testing 55 end-user requirements 56 error handling 57 functional 56 integration testing 55 intersystem 57 manual support 57 operations 55 parallel 57 program validation 55 program verification 55 recovery 56 requirements 56 specifications 56 stress 55 structural 55 system testing 55 unit testing 55 The Application Dictionary Services/400 143 time arithmetic operations 83 arithmetic using OPNQRYF command 88 comparison using OPNQRYF command 85 duration 81, 86 time data field 73 time format for DB2/400 SQL 79 specifying current value 80
O
Open Query File (OPNQRYF) command using date, time, and time-stamp arithmetic 85 date, time, and time-stamp comparison 85 operand date and time 80 OPNQRYF (Open Query File) command using date, time, and time-stamp arithmetic 85 date, time, and time-stamp comparison 85
75
P
phases of testing debugging 55 planning considerations 32 to resolve exposures
31
R
recommendations for using reformatting techniques reformatting year-date notation 41 reformatting techniques guidelines 52 52
S
sequence incorrect sharing data 40 26
244
time stamp arithmetic operations 84 arithmetic using OPNQRYF command 89 comparison using OPNQRYF command 85 duration 81, 86 time value for DB2/400 SQL 79 time-stamp data field 74 time-stamp format for DB2/400 SQL 79 specifying current value 80 time-stamp value tools 65 characteristics 65 environment 65 for code editing 68 for code generation 69 for code restructuring 68 for hardware 65 for impact analysis 66 for program level analysis 67 for project management 67 for software 65 necessary features 65 prerequisite hardware 65 prerequisite software 65 to analyze complexity 66 to analyze consistency 68 to analyze data flow 67 to analyze databases 66 to analyze interfaces 68 to analyze logic 67 to analyze metrics 66 to analyze standards 68 to analyze tests 69 to automate testing 69 to browse code 68 to compare programs 68 to create standard date subroutines 68 to cross reference 68 to diagram data structure 67 to diagram decomposition 67 to diagram logic structure 67 to diagram relationships 67 to expand fields 68 to find dates 68 to generate code 69 to generate database code 69 to generate dialog 69 to generate reports 69 to generate tests 69 to inventory software 67 to modularize code 68 to organize data 69 to paint screens 69 to simulate system behavior 69 to slice programs 67 to test drivers 69
tools (continued) to trace requirements to track changes 67 types 66
68
U
UDATE 74 UDAY 74 UMONTH 74 UYEAR 74
Y
Year 2000 exposure classification introduction 25 problem scope 27 year-date notation reformatting 41 26
Index
245
IBML
Printed in U.S.A.
SG24-4790-00

As400 Applications Moving To The 21st Century

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

As400 Applications Moving To The 21st Century

Transféré par

Droits d'auteur :

Formats disponibles

SG24-4790-00

AS/400 Applications: Moving to the 21st Century January 1997

First Edition (January 1997)

vii ix xi xi xii xiv

Part 2. Application Restructuring

Chapter 2. Internal Application Modernization

Chapter 5. DB2/400 Referential Integrity (RI)

Part 3. Year 2000 Enablement

Copyright IBM Corp. 1997

AS/400 Applications: Moving to the 21st Century

13.3.9 Application Dictionary Services/400 . 13.3.10 Application Development Manager/400

Part 4. External Application Modernization

Part 5. Modernizing Your Development Environment

Chapter 16. Application Dictionary Services (ADS/400)

151 153 153

AS/400 Applications: Moving to the 21st Century

Copyright IBM Corp. 1997

AS/400 Applications: Moving to the 21st Century

72 72 . 73 . 74 154 156 157 158 159

Copyright IBM Corp. 1997

AS/400 Applications: Moving to the 21st Century

How This Redbook Is Organized

Copyright IBM Corp. 1997

The Team That Wrote This Redbook

AS/400 Applications: Moving to the 21st Century

AS/400 Applications: Moving to the 21st Century

Copyright IBM Corp. 1997

AS/400 Applications: Moving to the 21st Century

Copyright IBM Corp. 1997

AS/400 Applications: Moving to the 21st Century

Figure 1. Roadmap to 21st Century

AS/400 Applications: Moving to the 21st Century

Part 2. Application Restructuring

Chapter Chapter Chapter Chapter

Copyright IBM Corp. 1997

AS/400 Applications: Moving to the 21st Century

Chapter 2. Internal Application Modernization

Copyright IBM Corp. 1997

Figure 2. Modularization Strategy

AS/400 Applications: Moving to the 21st Century

Figure 3. Present Database Structure

Chapter 2. Internal Application Modernization

AS/400 Applications: Moving to the 21st Century

Chapter 3. Interactive Language Environment (ILE)

3.1 What is ILE?

3.2 How ILE Works

Copyright IBM Corp. 1997

Figure 4. Improved Program Design

The steps taken to enable the redesign are:

AS/400 Applications: Moving to the 21st Century

Chapter 4. DB2/400 Triggers

Figure 5. Improved Database Design

Copyright IBM Corp. 1997

ADDPFTRG FILE(A960121/ORDERHDR) TRGTIME(*BEFORE) TRGEVENT(*UPDATE) PGM(RADT)

AS/400 Applications: Moving to the 21st Century

Chapter 5. DB2/400 Referential Integrity (RI)

Copyright IBM Corp. 1997

WRITE IFEQ SETON EXSR ELSE ADD WRITE SETON ENDIF

64 SUBTR 1 SFL01R REC1 22

AS/400 Applications: Moving to the 21st Century

Part 3. Year 2000 Enablement

Copyright IBM Corp. 1997

ADDPFTRG FILE(A960121/ORDERHDR) TRGTIME(BEFORE) TRGEVENT(UPDATE) PGM(RADT)

DSPOBJD DETAIL(FULL) OUTPUT(OUTFILE)

DSPFD TYPE(MBR) OUTPUT(OUTFILE)