January 1st 2000. Definite Deadline The phenomenon of a "deadline" is well known. Every project reaches a point in time at which the products and/or services have to be delivered conform specification. Often this point in space lies past the agreed deadline and yet another comprise has to be reached between the client and the supplier. Also Millennium projects suffer from this inability to meet all agreements. But the Millennium transition is inevitable. In other words the deadline for delivery can be shifted upward but not past the year 2000. This is a definite deadline! Many companies need more time than is available. In the old days the pope could be helpful in adjusting the calendar a bit. However, in modern times the church does not hold that much influence as compared to a few centuries ago. We are facing a definite deadline!

The Abyss As the turn of the century approaches rapidly the job has to be done in less and less time. Unless we are prepared to save vital parts of business and let other parts dive into the ocean's abyss the credo is "All hands on deck" for Millennium, and nothing else. And, as available time runs out, more and more people are needed to do the job. However, it takes an average of nine month to make a baby.

As wages go up In a free world of demand and supply an increasing demand combined with a steady supply causes an ever increasing price level. Wages for IT personnel are no different. The less resources the higher their wages. Toward the year 2000 this phenomenon will become more and more noticeable.

The Risk Many companies take refuge in recruiting young people who have just left school, retired programmers and the unemployed who have been given a crash course in programming. With the exception of retired programmers, these people do not have extensive experience in programming. Although less expensive as compared to experienced personnel, one can question the quality and motivation of these employees. Poor quality may decrease instead of increase the reliability of systems. One must have strong nerves to expose one's business critical systems to such a scenario and at the same time endanger the continuity of the day-to-day business.

Patented Delay Although LivingImpact has no papal ambitions, she has developed a patented method to delay the definite "deadline". The method is called PMI2000, Postponed Millennium Impact. The method is supported by patented tools for automated analysis and adaptation. PMI2000 can be implemented at low cost in e.g. Cobol environments. And other programming languages are under development. PMI2000 does not search for all date fields but it lets the system travel in time; internally back to the past and externally into the present. Applying PMI2000 opens new possibilities to choose any alternative scenario to solve the Millennium bug at any convenient moment. This can be expansion, the correct way to solve the Millennium bug, package selection, etceteras. Advantage is that this can even be done when wages have settled to their normal level again and new technologies have come up.

1 The Millennium Bug

In the early sixties and seventies data-storage was expensive and computer programs were designed to optimize the use of data-storage devices. Therefore, datefields were generally stored without century indication. E.g. 1968 was stored, and still is, as 68. A simple calculation of a person's age, at this moment 1998, gives the correct result; 98 - 68 equals 30. However, after the turn of the century in the year 2000 the same calculation results in 00 - 68 being equal to -68, giving a complete inaccurate picture of this person's age. Actually what is meant is 2000 - 1968 equals 32 which would be the correct age two years from now. However, the computer not being aware of the century difference cannot produce the correct age without further adaptations.

Numerous examples can be given were these computations by computers can go wrong, and will go wrong, e.g. banking systems, stock markets, telephone systems and the use of credit cards with two digit expiration dates. Disfunctioning of these systems may eventually lead to the total disruption of the functioning of whole societies.

World-wide computer systems contain hundred's of billions of lines of code supporting business processes in the financial markets, trade industries, etceteras. Datefields inapt to accommodate a century indication are used everywhere in these systems. A tremendous amount of code has to be screened in order to locate these defective datefields. Subsequently, this code has to be changed and tested in order to make the programs work correctly in the next millennium … and the problem is everywhere!!!

2 A Temporary Problem

For many applications the Millennium problem is only a temporary problem. Companies such as telecom operators, broadcasting companies, flight reservation agencies, etceteras often deal with only a limited time span in their active database. The applications supporting their business run smoothly now, will have year 2000 related problems for a limited time span and will run smoothly again when the lowest possible value for any year field steps over the year 2000. Exactly for these application PMI2000 is the solution. When PMI2000 is implemented, it takes the applications over the Millennium transition and, when the application is out of the danger zone, PMI2000 can be removed.

3 Traditional Solutions

In the traditional solutions all datefields have to be identified and the programs have to be changed. Often the data bases or files involved have to be changed also.

One technique uses expansion of the datefields which is actually the proper implementation of a datefield. Computer programs are changed by expanding yearfields from two year-digits to four year-digits, 98 becomes 1998 and 00 becomes 2000. Apart from identifying all datefields and changing the programs, related data files have to be converted to include the century indication and interfaces to other systems have to be changed.
A second technique uses interpretation with fixed or gliding window. Yearfields are either interpreted as being part of the 20th century when higher than a certain year, say 80, or being part of the 21st century when lower than the chosen year. Such a solution means that 98, being higher than 80, is interpreted as 1998, whereas 00, being lower than 80, is interpreted as 2000. In this solution the yearfield remains a two-digit field.

Typically, the traditional solutions use the following steps:
· identify as many datefields as possible through extensive analysis of the programs;
· change the programs to make the system year 2000 compliant;
· test the programs with the following objectives:
Þ make sure that the changes are correct;
Þ make sure that no infections are left undetected.

Usually scanning of the code is used to identify datefields, i.e. identifying date-related strings such as 'DATE', 'YY', 'MM', 'DD', etc. Additionally, proliferation of date infections, i.e. the transfer of the contents of datefields to other fields which themselves cannot easily be detected as datefields has to be determined. This process is usually called tracing.
The identification of as many datefields as possible implies a time-consuming analysis process involving many resources, high costs and a prolonged time-span; for larger systems containing over 1 to 2 million lines of code it may take 3 to 5 months. Changing and testing of the code may expand this time span to 1 to 1,5 years … and time definitely runs out!!!

4 The Principle of Time Travel

Computer systems getting into trouble at the dawning of the next millennium will keep functioning correctly, as they always did, when set back some years in time. However, setting the whole computer system back some years in time will make it unable to communicate with the outside world. Alternatively, the applications software can be altered such that it functions internally in the past and presents itself externally in the present. This principle is called 'time travel'.

All input which contains datefields is lowered by a fixed amount of years (-d). The application performs its functions in the past were it always operates correctly. Upon output the datefields are raised again with the same amount of years (+d) such that the application presents the results in the present time.

The principle of time travel leads to Postponed Millennium Impact (PMI2000) which means that the appearance of the year 2000 in the applications software can be evaded for a longer period. With this solution any follow-up becomes possible, e.g. continuing exploitation, traditional renovation, rebuild, package-selection or phase-out, without the restriction of the turn of the century.

The principle is deeply involved with the applications software of computer systems and does not intervene with system clocks, system routines or other middleware. This means that the principle of Postponed Millennium Impact can be applied to systems, subsystems or programs without affecting the surroundings of the system, subsystem or program. Also, the adapted system, subsystem or program can still communicate with its surrounding environment just as it always did making partial implementation of the principle possible.

5 The PMI2000 Solution

In order to avoid time-consuming analysis, changing and testing of programs, the PMI2000, Postponed Millennium Impact 2000, solution uses the principle of time-travel such that the application functions internally as if it were some years back in the past, where it always functioned correctly, and presents itself externally in the present time with the correct dates. Consequently, adapted systems still communicate with other systems without further adaptations! The functionality of the application is unchanged.
Depending on the user environment a multiple of 4 years can be chosen as the time span for the time travel when only leap years have to be synchronized. When also the days of the week have to be synchronized, a multiple of 28 years must be chosen.
With PMI2000 a shell is created around all inputs and outputs in the application in which the ± d time transition is created. Part of the shell is a Supporting Module which communicates with a Repository containing information on all datefields that are involved at input or output.

The PMI2000 implementation of time travel uses the following steps:
· Analyze Sources:
· gather the sources and copy members;
· analyze the sources to identify all input / output using PMI tools;
· Adapt Sources:
· adapt the sources to implement a time travel shell using PMI tools;
· Build Repository:
· build a repository containing information on datefields using PMI tools;
· complete the repository with client supplied date information

The deliverables of the PMI2000 Migration Process are:
· Adapted sources with the time travel shell implemented;
· Supporting Module making the ± d time transition;
· Repository with information on datefields that are involved in input / output. The information tells the Supporting Module where a datefield resides in the i/o structures.

6 Benefits of the PMI2000 Solution

Postponed Millennium Impact opens new possibilities to overcome the Millennium transition. For systems with a short time window the PMI2000 is a definite solution for a temporary problem. However, after implementing PMI2000 one may choose alternative strategies such as traditional renovation, redesign/rebuild, package selection and phase-out. Also, partial implementation of adapted programs becomes possible. Any future scenario is open again.
After the Millennium transition an application, containing two-digit datefields, has become totally unreliable. In the traditional approach all datefields are searched for. However, it is most likely that some datefields are left undetected. Therefore, extensive testing has to be done to verify the reliability of the application.
The PMI2000 solution is only concerned with finding all inputs and outputs which are found with 100% guarantee. Therefore, the problem is localized again and testing becomes less time consuming.

Further advantages of the PMI2000 solution are:

• Business critical situations can be solved quickly and endangered business can survive
• Time reduction for implementation as compared to traditional solutions is considerable
• Cost reduction for implementation as compared to traditional solutions is considerable
• Automated tool support is optimal and, therefore, the resource demand is much less than with the traditional approaches
• Partial implementation is possible.

7 Deliverables of the PMI2000 Solution

The deliverables are:

• Adapted sources;
• Supporting module;
• Repository.

A supporting module is part of the deliverables and communicates with the repository containing information on date fields such that the time travel becomes possible.

Q&A

Questions and Answers
The PMI 2000 process

Q. What is the estimated time for conversion per 1M lines?
Estimation is that 6 to 8 weeks per person to adapt 1 million lines of code (1 mloc) are required. The time for adaptation depends quite linearly on the amount of loc's as it depends mainly on the visual checks and not so much on the application of the PMI2000 tools. Obviously, with smaller systems the bandwidth of the estimated time for adaptation will become larger.

Q. What are the steps in the PMI2000 process? What is the estimated time per step?
The PMI2000 is executed using the following steps:
· Assessment of the sources to be adapted
· Intake to obtain the metrics of the system
· Analysis in preparation of the adaptation
· Adaptation of the sources
· Building of the repository
· Completion of the repository
· Compilation of the sources
· Delivery of the products

It is our experience from tests and pilots performed that the time needed per step varies per system. Intake and reporting of untraceable components typically takes several days. Analysis, adaptation and building / completion of the repository roughly take one third of the total time of the project each, although this may vary for different systems. Compilation of the adapted sources again takes several days.
Q. To what platforms and programming languages does PMI2000 apply to?
Since PMI2000 is applied at the software applications level it is independent of the platform and can be applied to such platforms as VAX, AS/400, S/36, S/38, HP3000, Data General, etceteras.

Q. Power Builder 2000, Oracle and 5th generation languages: How does PMI2000 deal with it?
Usually the 4th and 5th generation languages or software development environments already use 4-digits year fields including a century indication and applications written in these languages are Y2k compliant. It is suggested that spot checks and tests are used to verify 2000 compliance for these applications.

Q. Can PMI2000 be adapted to other languages?
The PMI2000 service is designed for third generation languages such as COBOL, Fortran, RPG and PL/1 although in principle it can be adopted to apply to any programming language. Still the General Principle of Time Travel is independent of any programming language.
At this moment PMI2000 is fully developed for COBOL and RPG.

Q. Other then the 28 year delay, Can this solution be applied to another 28 years?
The PMI2000 system is parameterised with a 28-year setting. This setting can also be multiples of 28 years. Therefore, another 28 years is possible. Actually it is a time shift from the time period 1900-2000 to 1928-2028 and with another 28 years to 1956 - 2056.

Q. What is required from the client's side, in the delivery process?
A critical factor is the delivery of the sources by the client in the correct format. For that we supply the client with delivery instruction, however some time might be lost in the process of transferring the sources to the PC environment, or when there are some untraceable components, (i.e. the client fails to deliver all necessary sources). Ones all source have been absorbed in the PC environment the process is straightforward.

Q. What is the estimated increase in code size expected after conversion?
Applying PMI2000 to a system, results in an addition of 8 to 10 statements per input/output statement, which is suspect to have date fields involved. Assuming 1% of the code to be relevant input/output gives a 10% increase in code size.

Q. Suppose a person was born in 1/1/1900. What will show on the screen, and what is the calculation PMI2000 does?
On the screen you will see 1/1/1900 (if that is the format/mask of the date field on the screen). Assuming today (the system date) is 1/9/1998 the calculated days elapsed will amount to 36037.

After reading the database PMI2000 will decrease the year value by 28 years. Therefore, the internal date of birth will become 1/1/1872. The system date representing today will also be decreased by 28 years and will become 1/9/1970. 1/9/1970 minus 1/1/1872 will give a number of days of 36037.

Q. And if the person is born in 31/12/1998?
Apart from the fact that the number of days elapsed will be different the answer is completely analogous. On the other hand such future dates of birth are of course not to be accepted by a system from a functional point of view.

Q. What about someone born in 1/1/2000?
Again the answer is completely analogous. However, when Year of birth is stored with 2 digits in the computer Year of birth in all above mentioned persons, is stored as 00, 98 and 00, respectively, and also shown on the screen as such when no further 'tricks' are applied.
Interpretation to a Year of birth such as 1900 or 2000 is only in one's mind. In the real world it is impossible to overcome (without tricks) a time span of more than 99 years with two digits!

Systems with 2-digit year fields already have a problem today when somebody was born before the year 1900, and these systems can only cover a period from (19)00 up to (19)99.

Again, notice that the (19) is an interpretation in one's mind. The system may equally well be used to cover a period from (20)00 up to (20)99 but not a period going over a century transition, e.g. 1998 up to 2010, when no further 'tricks' are applied (e.g. interpretation with break years). The only correct solution then is expanding the year fields to 4 digits. Yet, for large systems time has run out to implement this solution.

What PMI2000 actually achieves is moving the external imaginary window (19)00 - (19)99 up by 28 years to an external imaginary window (19)28 - (20)27 by setting back the time with 28 years internal in the programs making the mentioned period from 1998 up to 2010 a valid period for 2 digit year field calculations.

Q. If a program is used to calculates dates in a specific (say 5 years) time span. Will my y2k problem be gone in 2005?
Suppose differences between date fields used in a system covers only a limited time span, say three to five years. In that case, the system has only a temporary millennium problem, i.e. for a period of three to five years starting at the exact moment when the highest possible year value hits 2000 first and ending when the lowest possible year value steps over 2000 entering the twenty-first century. After this moment all 2-digit calculations will go fine again!

Q. If so, Will I need to convert this kind of system with the traditional expensive conversion?
Since the problem is temporary, This system needs a temporary solution to survive a temporary millennium problem. A solution that can be implemented in a short period at low cost such as PMI2000 is a great option.

Renovating a larger system containing over a million lines of code amounts to something of US$ 1 to 2 million using the traditional methods such as expansion or interpretation with all risks involved of missing crucial date fields and not meeting the dead line.
If this system only has a temporary millennium problem PMI2000 is definitely a better solution at significant lower price. Use the PMI2000 implementation for the time necessary and when the lowest possible year value steps over 2000 remove PMI2000, (which is easily done at very low cost).

Q. If a person was born before 1900, How do typical programs deal with it today?
They either produce erratic results when processing with 2 digit year fields or have been renovated a longer time ago for processing of 4 digit year fields.

Of course this is the same problem as we are facing now looking at year 2000, but probably the problem has been identified earlier and the these systems has been adapted at a time when there was not yet a threatening dead line. Or used a break year (interpreted so that if date < break year it is of this century, other wise it is probably previous century).

Q. If an break year algorithm was implemented to solve this problem, say: "if year < a then year = 1800" How will PMI2000 deal with it?
Hard coded values, e.g. in equations like if year < '1800', are easily detected by the PMI2000 Analyzer and depending on what is found corrective actions will be implemented.

Q. If the PMI2000 Travelled dates should appear on the screen, report, or the outside world what will be seen?
As mentioned before the adapted programs present date data in the present. The external world, i.e. screens, reports, interfaces to other systems and therefore a human user experiences the present and is not aware of the internal time travel.

Q. How do PMI2000 tools work, what do they do?
The only thing that can be revealed of the PMI2000 tools is that they guarantee that the Analyzer will locate 100% certainty all inputs and outputs to make the 28 year transition possible. The Adaptor adapts most of the I/O statements automatically, few adaptations have to be done by hand.

Q. Is screen re-design is required, with the PMI2000?
Redesign of the screen is not required. Where it was implemented with two digits it can stay two digits. The user will interpret 01 as (20)01 just as he or she interpreted 98 as (19)98. Redesign is of course possible but only for ease of functional use.

Q. How is the PMI2000 protected?
PMI2000 is patented in Europe and now registering in Israel too.