TORONTO USERS GROUP for Midrange Systems
nsuring your organization is prepared for the Year 2000 will be a significant project for any organization. In this article, I will review the four phases of a Year 2000 project plan: Inventory, Assessment, Conversion and Testing. Hopefully, you will gain an appreciation for the task ahead and an idea of just how far reaching this problem may be within your company.
Before I get to the project phases, I'll begin with a few comments on the AS/400 itself. OS/400 version V3R2 and V3R7 are Year 2000 ready. In fact, the AS/400 was the first computer to be certified Year 2000 ready by the Information Association of America (ITAA). Therefore, your plans must include provision to upgrade your operating system to one of these releases. Some of the new features included in these releases are: a Qcentury system value and 4-digit date formatting capability for CVTDTA, RPG and COBOL. They make it easier for you to modify your programs for Year 2000 compliance. These applications enablers are also available as PTFs for V3R1 and V3R6 (see chart), but these releases are not Year 2000 ready.
It is recommended that you begin a Year 2000 project by performing a complete inventory of your IT environment. Start by listing your hardware configurations, network configuration, system software release levels, DP skills and availability. Expand this list by including your external IT contacts: EDI, suppliers, customers and banks. Next, focus on your business applications. Create a listing of all your AS/400 program objects and note if the current version of the source code is available. Also count the number of lines of code within the program. Many consultants and conversion tools use a line count to estimate the scope of the project.
Now the project gets challenging. You must comb through your applications to find all date references within databases, display files, printer files and of course your programs. Programmers are renowned for their cryptic abilities, so expect this step to be rather challenging. A project like this demonstrates the value of good documentation. Date strings to look for include: the use of date formats (YYMMDD), month, mth, year, yr, today, begin, start, week, etc. Once you have found the date fields, trace the flow of this information throughout your organization. Where is the date created, what applications use it, and where does it go? Is the data being downloaded to a PC spreadsheet? If so, add the spreadsheet to your list. Who else is using the data: customers, suppliers, other departments or banks? You will have to coordinate your Year 2000 plans with them. If one of these companies is not Year 2000 ready at the same time that you are, you will have to write a bridge program
Now you have to make a decision. Will you modify your programs, upgrade to a Year 2000 ready version of the application, or replace the software? Assuming that you plan to modify the programs, the two most common techniques for Year 2000 application design are: 4-digit year representation and windowing. The recommended approach is to modify all your date fields to include a 4-digit year YYYY. This design provides a complete, permanent and obvious solution. It will however require a larger field length, so expect your disk usage to increase. Another technique is windowing. Using this method, you retain the 2-digit representation of the year, but make an assumption that 00-39 represents the years 2000 to 2039 and 40-99 represents the years 1940 to 1999. Using this technique you avoid having to expand the date fields but since they only cover a span of 100 years, it cannot be used by everyone. Also expect a performance impact related to the overhead of calculating the date conversions. Several other design methodologies are available, but whichever one you choose, try to be consistent in every application.
If date fields are used extensively throughout your applications, you will undoubtedly be making a significant number of modifications. Extensive testing will be required. Begin with basic operational tests, to ensure that the applications work under normal circumstances. Jan 1st 2000 is a Saturday (I checked). Are you planning to run day-end, week-end, month-end, quarter-end and year-end jobs that weekend? Set the systems clock for December 31st 1999 and see how the applications react as the year changes to 2000. Test your recovery procedures. Can you restart operations after a fatal error? What about your historical data? You may have to keep some of the original programs specifically for this data. Changing the system date and century system value may not be something you want to do on your production AS/400, so consider using a separate AS/400 for testing.
Yes, this can become a huge project, fortunately there are a number of tools available to assist you. This months article by John Vanzante lists several Year 2000 web sites. Most provide lists of Year 2000 tools and services.
I would like to conclude by referring you to some of IBM's Year 2000 redbooks:
T
<
G