Implementing an automatic code conversion system

Background The Aer Lingus Year 2000 IT project started in early 1996. An initial survey, followed by a detailed analysis, produced an inventory of 239-plus applications under the control of the IT department. These applications run on a variety of platforms: MVS/IMS mainframes, Unix/Risc machines, PCs and some Digital VAX and Wang equipment. Application sizes ranged from the large reservations system down to small PC applications. The applications break down as follows: Number Category Action 29 Dead/Redundant Monitor timely demise 43 Due for replacement Monitor replacement, test for compliance 32 Compliant Test for compliance 135 Non-compliant Investigate, modify, test. The 135 applications which need further investigation because they are believed to be non-compliant are broken down under three headings: ALCS Reservations, departure control and other related applications, written in Assembler, which run under ALCS on the IBM mainframe. These are being checked and made compliant by in-house experts. This will be followed by intensive Year 2000 testing. PC-based applications These are written mainly in Clipper and Visual Basic and will also be converted and tested in-house. Other, non-ALCS, mainframe applications These applications total around 2m lines of code. They are written in a variety of languages, including Cobol, Focus, PL/1, Easytrieve and Assembler. In order to find the best method and tools for making these varied applications compliant, Aer Lingus set up a pilot project in early 1997. Pilot We selected a module, consisting of around 25 000 lines of Cobol, PL/1 and Assembler, from one of our larger applications which we knew to be non-compliant. This source was sent to a number of tool vendors and service providers. These ranged from small firms which provided tools for simple one-level scans on the source for date occurrences, to service providers who offered a complete analysis/scanning/conversion service. Based on the responses and results returned by these companies, it was decided to outsource all of the 2m lines of code to one company, Alydaar, for conversion. This company can quickly process large amounts of code, in a variety of languages, using small teams of experts backed up by powerful analysis and conversion software. Reasons for going automatic The main reasons for outsourcing the 2m lines of code were the limited in-house resources and the flexibility offered by the outsourcer. According to industry standards, 2m lines of Cobol code equate to 20 man-years of conversion effort. This contrasts with Alydaar`s throughput capability of 1m- 1,5m lines of code per month per conversion team of 3-5 people. In addition, by giving all of the code to one outsourcer, we are assured of a single conversion standard throughout all applications. The quick turnaround means reduced application freeze time. Because the conversion is carried out quickly, it can be scheduled to suit our testing requirements and capabilities. Implementation Outsourcing code, even for automatic conversion, is more than just a matter of packaging the 2m lines of code and waiting for it to come back. The work has to be carefully scheduled and monitored. We agreed with Alydaar to send them our code in batches to a schedule which suited our overall conversion and testing plan. The typical process for the conversion of a batch is: 1. Analysis by Alydaar of the batch contents, onsite. 2. The application is frozen. Only emergency modifications are made to the production code from this point. The frozen code is preserved unchanged. 3. Baseline test No 1. As with any application being modified for Year 2000 compliance, we run and preserve a thorough baseline test before conversion starts. 4. Packaging and dispatch of the frozen code for conversion in the US. 5. Conversion by Alydaar. An initial scan may throw up questions about particular code segments, date constants, and more. While the conversion is ongoing, there are regular sessions during which these questions are answered and progress is reviewed. The conversion is done at one of Alydaar`s facilities by one of their conversion teams, backed up by a powerful code conversion program. The program scans and analyses the code and, based on the conversion requirements specified (in our case, windowing), it suggests the necessary code changes. These changes are kept to a minimum; only operations which are likely to cause problems in 2000, such as comparisons and calculations, are changed. Existing code is commented out and replaced by calls to a standard date routine. The code changes suggested by the conversion program are reviewed and ticked off manually and the converted code is output, ready for compilation and quality checking. 6. Baseline test No 2. After the converted code has been returned, we rerun the previous baseline tests to ensure that the functionality of the applications has not been affected. 7. Year 2000 tests. We test the applications for full Year 2000 compliance on our dedicated test platform. 8. Changes made to the production code, if any, can now be applied to the compliant application which is then rolled back into production. Results We have packaged and dispatched our first batch for conversion. This consisted of one large revenue accounting application which could not be easily subdivided, a total of ~1m lines of Cobol, Focus, PL/1, Easytrieve and Assembler. The on-site analysis by Alydaar took a couple of days, as we had already gathered detailed information on each application and on the files and interfaces. We specified our conversion requirements. Questions which arose after the initial code scan and during the conversion process were answered at our regular conference calls. Progress has been good and the code conversion is complete, on schedule. The code is due to be returned to us, after final quality checks, at the end of September. At that stage we will have our dedicated Year 2000 test platform set up, the upgraded CPU and Dasd will be available and the test tools installed. Our baseline and Year 2000 testing will then commence. Some Alydaar staff will be onsite to assist with the initial testing and to brief our maintenance programmers on the conversion methodology and the functioning of their standard date routine. When the Year 2000 compliance testing of this first application has been completed, we will send the balance of our mainframe code to Alydaar for conversion, in four batches. This part of our Year 2000 compliance process is due to be completed in July 1998. It is planned to have all current applications Year 2000 compliant by 31 December 1998. The project will continue into 1999, with compliance testing of any applications which have been significantly modified after initial compliance certification and any new applications which were implemented while the Year 2000 project was in progress. Problems and solution The Year 2000 issue has received much publicity. It is indeed a problem, but manageable. It is not the end of the world, as some pundits predict. Year 2000 compliance is a two-stage process. The first stage is inward-looking and concerned with making a company`s own computer systems compliant. The second stage, which is just as important and can be carried out in parallel, is outward-looking. It is to ensure, or at least gain a level of comfort, that key suppliers of goods and services are also working on their compliance. There are still many companies ignoring or underestimating the effort and timescale required for Year 2000 compliance, including some airlines. There are just over two years left to the new millennium. But most airlines` reservations systems will make their first 2000 bookings in early 1999. Their engineering systems may shortly attempt to order long-lead time parts for their aircraft. For companies starting late, a rapid code conversion using an automated system such as that offered by Alydaar may be the only solution. If an airline lacks the resources or expertise to make its reservations systems compliant in the time remaining, it may need to turn to airline reservation service providers, such as Aer Lingus. Maybe there is still time for someone starting now to achieve Year 2000 compliance. But they must start now. Next week or next month may be too late! The Alydaar code conversion factory is represented in South Africa by Software Futures.