|
Practical Methods for Your Year 2000 Problem Robert Chapman 1997 | 236 pages Includes CDROM ISBN: 188477752X |
|||
 |
$55.00 | Softbound print book | |
Preface
This book is predicated on two realities within today's data processing environment (regardless of how data processing is defined or who executes it). First, most software systems and some hardware systems are not demonstrably Year 2000 Ready. The term Year 2000 Ready is defined by IBM in the book The Year 2000 and 2-Digit Dates: A Guide for Planning and Implementation. Second, most people are overwhelmed by the task of addressing this problem and don't have a clue as to how all of this work is going to get done.With such a hard and fast requirement that these systems be made Year 2000 Ready in a timely and affordable manner, it is understandable that people are getting nervous. It is also understandable that the prices for services are escalating at a faster and faster rate as 2000 approaches. Many service providers, consultants, programming shops, and the like are using phrases like "money is no object," "once in a lifetime opportunity to retire," and "my price just went up". The trade press is running continuous stories about the price per line of code. In 1996 the price per line of code was set at a low of $.30 and a high of $.65. In early 1997 these same publications were quoting prices running from $1.30 to $1.65 per line of code and consulting firms had reached $2.65 per line of code in their proposals. Here it is, the middle of 1997 and already there are forecasts of $6.50 to $7.50 per line of code by 1998. It is certain that these prices are going to escalate with each passing day as the fever pitch of this situation is headlined in the trade journals.
For the corporate employee with a calculator in hand, it is easy to see that the prices quoted to make their software and hardware systems Year 2000 Ready are more than the original development and deployment costs. There are two problems associated with this conclusion. The first is that no company can afford to drop every other project it is involved in and use everyone available to become Year 2000 Ready. The second is that 80% of all projects fail in one of three major areas: cost, functionality, or delivery date.
This book is designed to assist data processing organizations in reaching the Year 2000 Ready state. To reach this end, it is imperative that Year 2000 project managers accept as fact one point: to be successful in a Year 2000 Ready project requires absolute control of the scope of the effort. This book will provide a methodology that controls the scope of the Year 2000 Ready effort. In addition, this book will describe a step by step methodology to minimize the cost and duration of Year 2000 Ready efforts.
Every methodology relies on a tool base of some type, even if it is only those utilities that an experienced developer uses in his day to day environment. This methodology does not require any explicit set of tools; any tools providing the types of functionality referenced in this book will do. However, to ensure continuity of presentation and the need to provide real life examples, a single set of tools is used in this book. These tools are from the IBM VisualAge 2000 toolset and contain the following products.
- IBM VisualAge for COBOL Professional. This workstation-based
product provides a COBOL compiler which is the same as the IBM
COBOL for OS/390 and VM mainframe compiler. A tool called Application
Understanding parses JCL, builds a support database, and provides
graphical tools for finding and tracing file and program references.
VisualAge for COBOL Professional also contains a conversion tool
for converting COBOL programs using older ANSI standard code to
the latest release. Finally, it contains tools for finding date
constructs and presenting them in either a batch or a GUI-based
format.
- Isogon's SoftAudit/One and SoftAudit/2000. These
tools identify the vendor software products residing in MVS data
centers. The SoftAudit/2000 product will link nonvendor load modules
back to the source libraries from which they are derived.
- Edge Information Group's Edge Portfolio Analyzer product. This product will inspect load modules on an MVS system and identify the compiler type and version, and the compiler options specified during the compile and link process.
Additional tools used include the IBM Search Manager/2 product and some custom REXX, BAL, and COBOL programs.
Admittedly, this is an IBM MVS centric look at the Year 2000 solution domain. If one is faced with a Year 2000 problem on another platform, there are similar tools available. But, more important, is the fact that the methodology presented in this book is platform independent and will be both valid and cost effective on any development platform. The methodology can easily be mapped onto other toolsets regardless of the platform involved. For a simple example, consider the use of grep on a UNIX platform as a substitute for Search Manager/2. While individual executions of grep will be more time consuming than queries in Search Manager/2, the results will be just as useful.
Most of the programming and analysis tools used in this book are available directly from IBM. A try-and-buy CD-ROM containing IBM's VisualAge for COBOL product, is provided with this book. The software on this CD-ROM runs on Windows 95, Windows NT and OS/2. Additional products which are mainframe centric are also available through IBM. Once again, while these products are used to demonstrate the methodology, they are not required. Other products which provide similar functions should be just as applicable.
Overview of the contents
Chapter 2. Introduction to the lowest cost methodology. This chapter sets the rules and the describes the reasons for them. This chapter also contains a short road map describing the sequence in which the methodology is covered in this book. This is the most controversial chapter of the book and will provide the reader with many opportunities to complain, judge, and philosophize.
Chapter 3. Setting Up the project schedule. Building and maintaining a project schedule is a major undertaking. Getting and keeping visibility of the project effort is extremely important. This chapter tells you how.
Chapter 4. Inventory. Find out what you have and how much of it there is. This chapter demonstrates the use of the ISOGON and EDGE products along with other more custom solutions that should be considered. More important, it tells you what to look for, how to look for it, and how to track it.
Chapter 5. Categorizing dates and minimizing project scope. The key to the lowest cost effort lies in this chapter. If dates are categorized incorrectly, the coding, testing, and file handling processes will cost more than necessary and be more likely to fail.
Chapter 6. Bridges, date expansion, and date compression. When a date has been identified as being Year 2000 sensitive and it must have a century indicator associated with it, there are three alternatives available to the project team for its conversion. This chapter tells you how to choose the alternative and how best to implement it.
Chapter 7. Assessment. Once the inventory is complete, it needs to be analyzed, and this analysis has to be performed in a specific way. Right here is where the first opportunity to lose control of the project scope occurs. Learn how to focus the assessment effort to reduce the upcoming work.
Chapter 8. Creating the test scripts. Traditional project efforts spend over half of all development monies on testing. This is a surprising figure because when the project schedules are generated, testing occupies much less than that amount. The problem is that most testing occurs informally during the development effort. Minimizing the testing cost requires that the testing effort be explicitly identified and managed. But since most Year 2000 testing efforts turn out to be unmanageably huge, it is also imperative that the minimum testing schedule possible be developed. This chapter tells you how to do this.
Chapter 9. Creating the testing environment. Often the creation of a test environment becomes either physically or politically impossible. This chapter will introduce several ways in which testing environments can be set up and managed.
Chapter 10. Making the changes. By this time it should be obvious that making the actual changes is a fairly trivial effort. Explaining how to make these changes in a routine manner so they can be folded back into the production systems is the goal of this chapter.
Chapter 11. Testing the changes. Testing actually consists of two parts. First is the running of the tests. Second is tracking and scheduling the tests. Tests need to be run until all problems are identified. It is possible to forecast the amount of testing necessary, but only under a very few specific circumstances. Even so, knowing what these circumstances are will allow the reader to go a long way toward controlling the testing effort.
Chapter 12. Implementing the changes. This process could be trivial, depending on the types of dates encountered. Or this process could be very sensitive to the cycle of the software systems executing in the production environment.
Appendix A. Requisite warnings and anecdotes. You have heard it all before. If you need or want to hear it again, then read this appendix. It is hard to be serious when so much organically processed material is flying through the air.
Appendix B. IBM VisualAge for COBOL Professional. This is an introduction to the VisualAge for COBOL family from a user's point of view.
Appendix C. Isogon SoftAudit/One. This is a brief discussion of the installation and use of this product in a real world environment.
Appendix D. Isogon SoftAudit/2000. This is a brief discussion of the installation and use of this product in a real world environment.
Appendix E. Edge Portfolio Analyzer. This is a brief discussion of the installation and use of this product in a real world environment.
Appendix F. IBM Search Manager/2. This is a versatile tool that can be used to enhance the documentation of any project. While finding references in 750 MB of code (37,000 files with over 10,000,000 lines of code) can be daunting, it is a stroll in the park with Search Manager/2.
Appendix G. IBM REXX, BAL and COBOL routines. REXX has been available on most of IBM's mainframe operating systems for the last 15 years. Examples of how this old workhorse of a language can help the Year 2000 project are given. Additional programs in COBOL and BAL are given to assist in the acquisition of Year 2000 information.
Appendix H. IBM VisualAge for COBOL Try-and-buy CD-ROM contents and installation instructions. Although the CD-ROM comes with its own set of instructions, this appendix provides some insight into the installation process and the use of the tools.
Glossary. Many of the buzzwords and abbreviations are defined here.
Finally, this book does not deal with project administration, company politics, setting up budgets, or staffing issues. Management styles differ from person to person and organization to organization. If the reader concentrates on implementing the project work as described in this book, they can use whatever management technologies are available to them.
There is no attempt to convince management that it should embark on a Year 2000 project. Upper management already knows it has to worry about the Year 2000 status of its computer systems. If it doesn't, it is because it simply doesn't want to know about it. This book is for those who not only know they may have a Year 2000 problem, but want to take an intelligent approach to addressing the entire issue.
DESCRIPTION
Practical Methods for Your Year 2000 Problem gives the Year 2000 project team a step-by-step methodology for addressing the Year 2000 problem. By seeking to minimize the amount of work to be performed, and thus maximize the probability of having a successful Year 2000 project, the book is geared towards (a) helping the inhouse personnel understand, scope and, execute their project while (b) removing the need to spend large amounts of money on professional consulting firms. The VisualAge 2000 toolset by IBM is used for examples.Practical Methods for Your Year 2000 Problem identifies what you need to look for, how you need to look at it, and what to do with what you see. No other book or company in the market today provides a solution as comprehensive and cost-effective as this. Starting with the clear, concise, and unambigous definitions of what dates are and how programs and files relate to them, the book goes on to describe how to change them to be useful forever, not just up to the next century.
Finally, Practical Methods for Your Year 2000 Problem gives practical and comprehensive advice on all aspects of the Year 2000 problem, from inventorying software and hardware through to implementing large numbers of interrelated programs, files, and tables.