RENOVATION PHASE

Overview

The renovation phase is the phase during which changes to systems are actually made. If the Year 2000 can be defined as a management problem rather than a technical problem, then the prior two phases illustrate the management issues which must be faced while the renovation phase deals primarily with technical issues.

During the renovation phase, decisions made in prior phases on how systems/processes will be made compliant are actually implemented. For example, systems/processes can be made compliant in several ways. They are:

Code Acceptance
Code Retirement
Code Reengineering
Code Modification

-Expand date fields
-Algorithm/Sliding Scale/Windowing/Procedural Workaround
-Relative dates
-Encapsulation
-Bridges/Filters

In addition, there are several other issues which must be addressed during this phase. Missing source is recreated here, either through redevelopment or by sending load modules off to those companies specializing in re-creation of source modules.

Standardized date routines can either be purchased or developed, however there are economies to be gained if one set of well-written, documented and tested date routines is used throughout the organization rather than having each individual program mer or programming area develop and test their own. Removing inline date conversion routines and converting to standardized date routines promotes efficiency if for no other reason than to insure that the correct logic tests are used.

Files and Databases are reformatted. There is no advantage to modifying programs to read and write century compliant dates unless the storage media for those dates are also upgraded to maintain the new file formats.

If tools were identified in earlier phases as part of the solution to the Year 2000 problem, then this is the phase where those tools are installed and used.

 

Each of these areas is discussed in greater detail below.

ESTABLISHING DATE STANDARDS

External date routines present a challenge to the project manager. The purpose of external standardized date routines is to insure compatibility with others outside of the enterprise. For external interfaces, the project manager must take steps to insure that the data that is shared does not corrupt the targeted data base on either side of the exchange.

The date standards as expressed in the current ANSI X.3.30-1985 do not adequately address the issue of the eight digit date field as it relates to the Year 2000 problem. NIST has issued a modification to FIPS 4-1 (Representation for Calendar Date and Ordi nal Date for Information Interchange) that has been accepted by the Federal Y2K Interagency Committee as the defacto standard. Although FIPS 4-1 stipulates an eight digit date format (CCYYMMDD), the Interagency Committee has only embraced the year (CCYY) portion of the standard.

There is no mandate that the entire field be populated. The reasoning is simple. There will be instances in which the sending and receiving applications have no need for the eight digit date field. From a best practices perspective the project manager wou ld not require a conversion to an eight digit date field and would populate only those elements needed to properly function. The ANSI X.3.30-1985 is scheduled to be modified to address the Y2K issue, but in the interim the project manager must make a decision on what format their organization will adopt taking into consideration the FIPS 4-1.

TYPES OF CODE RENOVATION

Code Acceptance

Code acceptance is an acknowledgment that the subject application "as-is" without internal modification, will not affect the enterprise' ability to function to and through the Year 2000. An application can be accepted if

1. It is already Year 2000 compliant
2. Compliance will be achieved through external means (e.g. bridges/filters).
3. It has no dates.

These applications will nonetheless require validation.

Code Retirement

One of the byproducts of the Year 2000 is a good house cleaning. The mapping of source to executables may reveal outdated source, still in the repository, which is no longer executed or needed in the production environment. This has the advantage of reducing both the overall Year 2000 labor costs as well as storage costs.

In addition, as systems are prioritized in the assessment phase, their ongoing worth is established. Companies must draw the line at what must absolutely be made Year 2000 compliant and what can wait. Systems which the enterprise can live without, or for which the enterprise has alternative workarounds, become candidates for retirement, espe cially if the process performed by the application is no longer needed or other applications perform the same business process.

Code Reengineering

Existing applications become candidates for reengineering as part of the Year 2000 project when the benefits to be derived from re-examining the business processes outweigh the risk associated with taking on additional work in a limited time frame.

Reengineering is often undertaken to improve future maintainability, upgrade technology, migrate to different hardware/software platforms, or include major new functionality. The downside of reengineering is that technology is often placed on the critical path, and in a project of the scope and magnitude of the Year 2000, this risk becomes enormous, particularly as the Year 2000 draws ever closer. The time period when this was a viable solution is rapidly passing, and companies must choose a date and make a go/no go decision on projects which are being redeveloped and reengineered and are lagging behind schedule. The decision point must be made while time is still available to modify the existing system.

Code Modification (Expand date fields/Algorithm/Sliding scale/Relative dates)

If the application functionality is needed through the Year 2000, it is a candidate for modification. Modification is a process that is taken to insure that the application or data process will accommodate the user requirements and not have a negative impact on the data that is used into the year 2000.

During the initial inventory/assessment process, recommendations should be made as to the extent of the modification needed. This may vary across the application. For example, even if an application is scheduled for retirement, it may in fact require some degree of modification to make it to the retirement date. A non-intrusive application which is not impacted by the year 2000 requirement may need modification to prevent corrupt data from impacting other systems.

There are many variables that will drive the modification requirements for any particular application or process. Generally, modification falls into one of the following categories.

Expansion
Sliding scale (windowing)
Relative dates
Encapsulation
Bridges/Filters

A discussion of the relative merits follows, however, it is important to note that the approach selected will be influenced by the point in time in which work is started.

Expansion

Expansion is the most simplistic and straightforward of the methods of code modification, and involves expanding the date field from 2 digits to 4 digits. It allows date calculations to be made across the century boundary without fear of erroneous results, and without the requirement of ongoing procedural maintenance.

Pro:

     Fix is more permanent in nature
     Requires less procedural change

Con:

     Requires data conversion
     May require bridging between modified and unchanged programs
     Requires additional storage
     Screens/Reports may be too full to accommodate expanded dates and this may require a redesign
     May require additional tuning due to increased I/Os and paging

Sliding Scale/Algorithm/Windowing/Procedural Workaround

These terms are used interchangeably and involve the use of a procedural interpretation of the date. They allow the program to continue to function with 2 digit dates, and Interpret the century from "known" information. For example, if the year falls between 50 and 99, the century may be assumed to be 19, and if the year falls between 00 and 49, the century may be assumed to be 20. The split may be set at any point, but will require maintenance as the date selected draws near. In addition, files transferred between systems must use the same windowing technique, or they might assume the year to be in different centuries.

Pro:

     Does not require data conversion
     Takes less time to implement
     Eliminates requirement for bridging between modified and unchanged programs

Con:

     Requires more procedural changes
     Each program requires more detailed examination and different approach for applying windowing technique
     Each date may require different time window
     May be difficult to implement for some 3rd party software
     Will require more testing due to procedural orientation

Relative Dates

Relative Dates count time from some point in the past, and store the result as a numeric value in the date field. Associated logic/utilities must interpret the result and present the field in some meaningful display format. This approach allows for accur ate century date processing and date calculations across the century without increasing file formats or storage requirements. There may be some additional processing required to interpret the correct date.

Pro:

     Does not require additional storage
     Does not require procedural changes
     Minimum modification to software

Con:

     Requires building of common date utilities
     Requires data conversion
     Requires all programs accessing database to change at once

Encapsulation

This approach rolls back all dates, including tables, by 28 years in order to assure day of week compatibility, including the system clock. Logic must then be developed to reformat dates being presented on output reports/files/screens.

Pro:

     Does not require data conversion
     Minimum modification to software
     Affected code is easier to locate
     Requires less testing that other approaches
     After some time, time shifting can be turned off and system will operate in the new century

Con:

     Must be documented and understood by new programmers doing software maintenance
     May not be possible to implement for 3rd party software
     Difficult to implement if system has hard coded business rules (E.G. if 96 apply this maintenance procedure)

RE-CREATING MISSING SOURCE CODE

All source code must be located and inventoried during the assessment phase, as well as being mapped to its associated load module. It is likely that this process will identify some situations where the source code is missing. The first step is to determine if the load module is actually being executed. Many production libraries are cluttered with obsolete modules that were not removed when they were replaced by other modules.

If the load module is still required, the source must be re-created so that it can be examined to see if Year 2000 changes are needed. There are several ways to approach re-creating the code. If documentation is available, programmers could be assigned to rewrite the system based on those specifications. The drawback to this approach is th at there is no guarantee that the new code will match the old exactly. There is also the possibility that undocumented changes were made to the code over the years and these changes would also be missing from the re-created code.

Another option is to use the disassembler to break the load module back down into assembler statements. The drawback to this approach is that the result obtained is explicit base and displacement notation which is difficult, if not impossible to maintain. Regardless of what language the code was originally written in, the results will always be assembler code when this option is used. An experienced assembler programmer could then rewrite the code to create source that is maintainable.

A third option is to contract with one of the third party vendors who can re-create missing source code. They will return source code that will produce an equivalent load module for each executable sent. The code will also be easier to maintain and modify than the code produced by the disassembler. They may also be able to provide the code in the original language in which it was written. If the original code was COBOL, COBOL will be returned.

STANDARDIZED DATE ROUTINES

The term standardized date routine in the context of the renovation phase has to do with how the application or process uses and calculates dates rather than with external data standards established by such organizations as NIST and the ANSI X.12 committe e. This includes such things as conversion from Gregorian to Julian dates, processing relative date formats, and so on. During this phase, organizations have the opportunity to implement one standardized method for handling dates throughout their entire p ortfolio of code. At no other time will every line of code and every usage of date fields be subjected to the scrutiny that this project mandates. The numerous date conversion routines, many of which do not correctly process dates after December 31, 1999, can be replaced with one common routine to handle dates properly. All in-line date conversion coding should be replaced with a call to the standard date routine.

Standardized date routines can be written in-house with maintenance assigned to a technical support group. An alternative is to purchase a vendor package that contains any of the date conversion routines likely to be needed. The advantage of such a packa ge is knowing it has been thoroughly tested and that it handles all of the supported date formats correctly. If standard date routines are written in-house, they must be thoroughly tested as part of validation phase activities.

CHANGE DATA FILES AND DATA BASES

During the assessment phase you made the decisions regarding dates in your files and databases that will be implemented during this phase. In the renovation phase you will write the data conversion programs that will transform the dates in your files into the previously selected format. Important factors to consider are the relationship between the data and the systems that process and create the data. Scheduling becomes critical if you are expanding from two digit years to four digit years because the fi les must be converted at the same time as the programs unless a bridge program is written to handle the situation.

USE OF TOOLS

There are a variety of tools available to assist with the Year 2000 issue. There are tools that help identify the date fields in your code which can be employed during the assessment phase to estimate the work effort involved in making your Year 2000 changes. There are also a large number of tools in several different categories that can be use d as you undertake your renovation effort. Although testing tools are generally thought to be used only in the testing phase, a number of them can be helpful in the renovation phase to assist with unit testing, so they have been included. A brief descript ion of each of these types of tools follows.

NOTE:  This material was adapted from the tool information contained in "The Year 2000 Software Crisis—Challenge of the Century" by William M. Ulrich and Ian S. Hayes published by Yourdon Press.

MIGRATION TOOLS

Calendar Routines

Several vendors offer libraries of standardized date logic routines that handle calendar functions. Some examples are: verifications of day of week, distance between two dates and holiday calculations. These tools are particularly useful to organizations who are not employing standard date routines.

Automated Change Facility

No tool offers a fool proof automated method to change date fields, but there are tools available that take some of the burden off the programmer/analyst to change each and every occurrence from one format to the other. There are two types of tools available - interactive and batch.

Interface and Bridge Generator

Any migration effort that employs a date expansion strategy must have a tool to bridge the differences in shared files between compliant and non-compliant applications. There are four different strategies: custom interfaces, bridge generators, data migration tools, or automated conversion tools.

Configuration Manager

A configuration management tool is essential to the year 2000 project. Failure to implement a configuration management mechanism (a.k.a. version control) puts an organization in jeopardy because non-compliant applications can be inadvertently mixed with compliant applications--a recipe for disaster!

Comparison/Change Integration Facility<

Comparison tools enable review of manual or automated changes to code by comparing the previous and current versions. There are many types of tools that vary in intelligence. The simplest compares two versions of a file and renders a report listing line-b y-line differences. More sophisticated tools actually interpret the differences in sequence to identify additions/deletions and can ignore expected differences in line numbers and date fields.

 

Data migration

Once the method of change has been selected files and databases must be expanded to the new format. Data migration tools can convert data structures and expand data definitions, saving the cumbersome task of developing migration routines.

REDEVELOPMENT TOOLS

Metrics Analyzers

Metrics analyzers measure software quality using industry standard metrics. They are useful in identifying complex programs that will take greater effort to correct and validate.

Data Name Rationalizer

One of the most frustrating things you will face are confusing data names. Data name rationalizer tools research, analyze and rename data names across an application. This eliminates redundant variable definitions and aliases.

Structuring Tools

These tools reduce complexity of older programs by rewriting them and changing inefficient logic following the rules of structured programming. This results in simpler, easier to maintain programs. These tools are best used in the year 2000 effort prior t o date modification. In addition, they simplify internal bridging routines because they isolate input/output and CALL statements into standalone paragraphs.

Code Slicers

Code slicing tools enable the user to break large complex programs into smaller more manageable programs, or to extract code to create reusable subroutines. With the year 2000 project they have the capability to create reusable date subroutines and elimin ate redundant logic.

Language Migration Tools

Migration tools help you change source code from an older version of a language to a newer version. This is important in a year 2000 project since the older version may not be year 2000 compliant.

Reverse Engineering Tools

Reverse engineering tools analyze applications and extract functionality so it can be extended and regenerated into a new application. This technology is not fully automated but it is useful in year 2000 projects where applications are migrated to new platforms or environments.

TESTING TOOLS

Test Data Generators

Test Data Generators automate some of the tedious task of generating test data based upon parameters identified by an analyst. Theses tools are also useful for adding/ updating date values that reflect future events.

On-Line Capture and Playback

On-line capture and playback tools create reusable test scripts that are used in an online environment. Specific scripts are generated that guarantee predictable results when used as input for testing applications. These tools capture the data input to an on-line system and place the data in a test script. The playback portion of the tool dire cts the on-line screen inputs into the test application over and over again.

Test Coverage Analyzers

Test coverage analyzers are used to perform comprehensive testing by determining how much code in an application has been tested. Dynamic analyzers report on the percentage of program logic that has been executed during a test by tracing execution paths b ased on predetermined test data. This tells the analyst whether or not the test cases should be expanded to improve coverage. Static analyzers examine source code paths and also tell the analyst where specific areas of logic should be covered by test data .

Virtual Data Utility

Virtual data utilities intercept and reset the current date used by applications so the mainframe system dates don’t have to be reset to perform date testing. These tools allow batch and online systems to be tested without affecting other applicatio ns on the same system. This is an alternative to an isolated, stand-alone test environment.

Environment Simulators

These tools enable unit testing to be conducted by simulating the environment on a work station. This is useful because an analyst can quickly set up and execute multiple preliminary tests to identify and correct problems prior to testing the application s in the mainframe environment.

Execution Simulators and Debuggers

Execution simulators step through source code and don’t actually execute the program to follow control flow. Since they don’t execute the program, they don’t require data. The user is queried at each decision point and must enter informatio n for execution to continue. This is a quick verification of program changes. Debuggers actually use test data to monitor the program’s execution and allow the programmer/analyst to set breakpoints to examine the data. Both tools are available in ma inframe and PC versions.

Comparison Facility

These tools enable the analyst to compare results from a system prior to year 2000 modifications to the updated year 2000 compliant system to be sure they are identical.

INTERACTION WITH OTHER INITIATIVES

The Year 2000 work effort will not bring about upgraded systems--it will merely ensure that the systems will work accurately in the Year 2000 and beyond. Historically, data processing technicians gravitate to the more exciting state-of-the-art technologi es and they can very easily overlook the Year 2000 project when preparing the Information Technology Budget. It is the responsibility of the project manager to make senior management aware of the need to fully fund the Year 2000 project. This means not on ly allocating funds for code modifications, but also exploring the state-of-the-art technologies that can assist with the conversion itself.

Most organizations will have a full slate of new development work, re-engineering projects and ongoing maintenance scheduled that will fully occupy their programming staffs. Most of these organizations will not have the proper resources set aside for Year 2000 work. It is the responsibility of the Year 2000 project director to make upper management aware of the significance of this project and make certain that it is properly staffed. As the renovation and validation phases proceed the project director ne eds to remain aware of changing resource requirements and shift extra resources onto the project if the need arises. This will usually mean that other projects will need to be delayed or canceled or extra staff will need to be obtained through hiring or a warding of a service contract.

DEVELOP THE RENOVATION SCHEDULE

All systems should be included in the renovation schedule. This facilitates setting priorities, should there be insufficient time to make all enterprise code Year 2000 compliant. The primary focus of this section is to identify what the basic elements of the renovation schedule should be. The project manager will have to determine which elements will be included in the schedule as well as the level of detail of the schedule. The schedule should reflect the needs of the customer and provide the information needed to manage the Year 2000 conversion effort. Do not waste time working on a renovation schedule for a system which is to be retired or does not make it into the funding window of your overall program, but do include it in the inventory along with the decisions reached re garding it.

The renovation schedule may require tough decisions. In some cases there is going to have to be some trade off between the customer requirements and the technical feasibility of converting the application to a Year 2000 compliant platform. For example, the customer's current database vehicle may have to be replaced with a Year 2000 compliant vehi cle that will significantly change the user interface, operating procedures, data manipulation, and screen access. The project manager may identify the need for an offset where the conversion will require more dollars than have been allocated for the application. The project manager may request that the customer make up the difference. There will be give and t ake between the project manager and the customer in coming up with the best practice solution for each application.

It is expected that most of the really tough decisions will have been negotiated with the customer during the assessment phase so that when the renovation work begins the customer will understand the impact that the Year 2000 changes will have on the users, the priority their system has in the overall renovation phase, the time line and work s chedule, the resource allocation, and an understanding of how their application will function after the conversion is completed.

ELEMENTS OF THE RENOVATION SCHEDULE

While there are any number of elements to be considered in developing the renovation schedule three primary elements must be identified early on to properly develop the schedule. They are time, labor, and funding.

Time is related to the man hours needed to complete the conversion/modification as expressed in a total man hour requirement (Example: 200 man hours). The actual time in days, weeks or months on a calendar for a 200 man hour project being worked on by 5 p eople and will be represented as a one week project on the time line instead of five weeks.

The second element, labor, is a representation of the availability of human resources against their level of training and ability to produce work. There is a return on investment which the project manager may want to calculate into the renovation schedule that represents the benefits of the learning curve for each labor category. Here it is expected that the individual who has worked on similar conversions will change the value of the labor category and reduce the total man hour requirement for any given conversion process.

The third element, funding, is perhaps the most difficult to calculate. As the renovation process begins the project manager will be faced with 'discovery', i.e., issues and items that were not originally considered or understood. This is why all the known variables must be included in the original renovation schedule even if it is not known what impact they may have once the implementation begins. It should be noted that this 'discovery' may have a positive impact on the work and reduce time, labor or funding required to complete the conversion. From the stand point of best practice approach this positive benefit should be returned to the customer.

The renovation schedule most include the three primary elements as well as any other elements, information or issues which will assist the project manager in developing the final schedule and the final conversion estimates for the customer. From the momen t a system, platform, user requirement is identified the project manager should start to develop the appropriate renovation schedule. As the inventory and assessment phases are completed and the information is made available the renovation schedule should be modified to include the information provided. It is expected that the renovation schedule for the overall enterprise effort as well as the subordinate renovations schedules that address the individual conversion will be a dynamic document and will require continuous updates. This cries out for automation and there are a number of vendors who are pushing software that will assist the project manager in tracking this very large effort.

TIME TABLES

The renovation schedule will include a number of separate documents that support the master conversion process. One of the most important documents associated with the renovation schedule is the time table. This table includes milestones and provides a method of measurement to the individual process it addresses. This is the document that is us ed by the customer and senior management to determine how well the project is going. It also is a gauge that tells the project manager when selected resources need to be made available to the individual conversion effort. The energy used to develop a good time table up front will more than pay for itself as the conversion progresses. This table should not be complicated in fact it should be relatively simplistic and easily understood by all players. Confusion and wasted time going over a complicated table could jeopardize the whole program and destroy the credibility of the project.

PRIORITY LIST

The priority list is one of the most difficult documents to develop. There is not an application, network, system or platform that is not critical to the user of the process. Every organizational officer will be unhappy with his position on the priority l ist unless he is number one. The priority list should not be developed by the project manager. This decision should be made by the Chief Information Officer of the business unit. The project manager should assist the CIO by providing all available inform ation, including the customer survey, the inventory, the assessment, the renovation schedule and perhaps a suggested list of core business processes that are critical to the running of the parent organization. Beyond that, the CIO should negotiate the position on the priority list wit h the customer. The project manager who attempts to establish a priority list will compromise his position with every customer who is not number one on the list. It is also imperative that the CIO support the project manager on conversion using the priority list and to be open and flexible when new information is provided as the conversion moves forward.

WORK SCHEDULE (RESOURCES)

Once the time table has been approved and the CIO or equivalent has set the priority list and renovation schedule, the project manager should develop the work schedule. An accurate list of current and future resources (time, labor and funding) must be allocated to the individual work units. There will be a need for different skills at different ti mes over the wide range of conversion necessary in any organization. The interaction between diverse projects is the responsibility of the project manager and the work schedule will bring a disciplined approach to the wide variety of activities required. The work schedule should list all resources including in-house expertise not directly in support of the project as we ll as contract vehicles which can be activated with minimum impact. Other resources may include excess capacity in one organizational sector that may be teamed to support the overall conversion. Here again it is imperative that the CIO's office support t he project manager in gaining access to the resources listed in the work schedule.

BRIDGES/FILTERS

A bridge or filter is a method which ensures that converted applications can successfully interface with unconverted applications during the time frame they must coexist. This can be temporary while applications are being modified according to different schedules, or it can be a permanent solution to the year 2000 problem in some instances. B ridges and filters ensure that processing continues normally even when applications are converted at different times without adversely affecting data integrity and the daily processing of data.

Identification and evaluation of the application interfaces is an activity that must be conducted during the establishment of the renovation schedule. This information is essential in helping to develop a schedule that will allow you to modify and validat e applications that exchange date oriented data simultaneously whenever possible. Multiple systems undergoing renovation on the same schedule will result in a cost savings since it eliminates the need for bridges or filters among those systems. This will save development time and cost as well as saving additional validation effort which would be required upon the removal of the bridge or filter. This method provides for a much cleaner transition.

It is more likely however that most applications will make year 2000 modifications at different times rather than simultaneously. In cases where year 2000 compatible data is passed to an application (internal and/or external) that is not year 2000 compati ble, a bridge or filter will be required to expand or contract the date fields on either the sending or receiving application. If the sending application has created a file that is year 2000 compliant, but the receiving application has not made their year 2000 changes and they are not ready to receive or process a file in the new record format, then a bridge or filter is required to reconvert the file back to the old format so it can be processed by the receiving application. On the other hand, if the se nding application is not year 2000 compliant, but the receiving application is year 2000 compliant, then the receiving entity will need to convert the file to the new year 2000 format by using a bridge or filter.

It is important that the entities exchanging data communicate regularly regarding their conversion schedules and to determine who will develop bridges or filters if they are necessary. As the conversion process progresses, issues will arise that will be s olved more expeditiously if the sending and receiving entities understand the process and can negotiate a mutually agreeable solution.

A bridge or filter program can be either generic or unique. A generic bridge or filter program is one that uses parameters to identify the correct data and can be used for a large number of different files produced and used by many different applications. These should be used whenever possible to reduce the amount of programming effort that would be needed to create multiple programs. There will be files however that can not be easily converted by means of a generic utility. It will be necessary to write a unique bridge or filter program for each of these files.

If data is exchanged with several entities that are converting on different timeframes, it is more efficient to use one bridge or filter that is "table driven". The table will contain a list of all entities that you exchange data with for a part icular application and whether or not their data is year 2000 compliant. This enables one bridge or filter to access the table and determine if the bridge or filter needs to be invoked. The table can be easily updated as each entity’s data is made ye ar 2000 compliant until eventually the bridge or filter can be removed. This method eliminates the need to develop redundant bridges or filters for applications that are changing on different schedules. Obviously this is cost effective, as one bridge or f ilter can be used as opposed to many. In addition to the cost savings this method ensures consistency which diminishes the possibility of error.

BACK TO TOP OF PAGE