Year 2000: Thoughts to Keep You Up at Night



Year 2000: Thoughts to Keep You Up at Night

John R. Ackermann

Law Vice President, Services and Systemedia Law Group

NCR Corporation

I. What’s the Problem?

The central issue is that most computer programs written more than a few years ago (and even some new ones) use 2 digits to represent the year. This causes date calculations to fail when the year rolls over from 99 to 00.

Until recently, computer storage and memory were very expensive, and every byte counted. Programmers figured that programs written in the ‘60s, ‘70s, and even ‘80s would be replaced long before 2000. But that turned out not to be the case. It’s painful and expensive to replace critical systems, so inertia took its toll.

The Year 2000 problem is also at least partially a carryover from the way people do business – writing a two-digit year is common behavior, and programmers transferred that convention to the programs they wrote.

Other date-related problems are also rolled up under “Year 2000”.

2000 is a leap year, but many people (and the programs they write) think it isn’t.

Some programs use dates like 9/9/99 or 1/1/00 as special values.

Some operating systems and other programs have failure dates later in the 21st century (discussed below).

II. How do you define “Year 2000 compliant?”

There’s no standard definition, and it’s not as easy as it looks to come up with one that’s robust and unambiguous.

For example, some products use a “convention” technique instead of four-digit year fields -- they define a rule for date interpretation (e.g., “if the year is 70 or earlier, add 2000, otherwise add 1900”).

This is convenient, but may cause interoperability problems if two programs that need to talk to each other don’t choose the same cutoff date.

The alternative is compliance by “format” or “expansion”, which means ensuring that all date fields include century, decade, and year information.

Can you accept compliance by convention, and the possible interoperability problems that may result, in your environment?

What about leap year, special dates, calendar rollovers, etc.? These aren’t strictly “year 2000” problems, but it’s best to deal with them now to avoid later pain.

Many definitions are frankly pretty sloppy. NCR chose to use a very detailed approach (the attached “NCR Year 2000 Qualification Requirements Definition”). NCR warrants its Qualified products to meet this definition.

The Definition uses the term “Qualified” to differentiate from generic compliance, and includes both a text description, and a 45-point checklist, that Qualified products must meet.

It also includes the concept of “Qualified with Comment” to address issues like convention and other points that may impact the product’s operation. (A product that uses convention techniques may still be Qualified, but the cutoff date used must be noted.)

III. What’s the Risk?

Application software.

The classic Y2K risks are accounting, payroll, and other software applications, often written in COBOL, that rely on date processing (e.g., aging of invoices, scheduling shipments, calculating age or expiration dates).

It’s not just a COBOL problem, though – programs written in any language are susceptible.

In addition to the executable code, the format of stored data may be a problem – if the date fields in a database don’t include century information, fixing the program may not be enough.

It’s not just application software.

Hardware may have problems (BIOS or other firmware; Real Time Clocks). For example, the clock in most PCs manufactured prior to 1996 will not automatically roll over from 12/31/99 to 1/1/2000 (but there are workarounds for this, so you probably won’t have to throw your old PC away).

Many (most?) operating systems will require updates as well.

32-bit versions of UNIX will fail on January 19, 2038 when their internal seconds counter rolls over.

MS-DOS and Windows 3.1 will fail in 2035 when their counters roll over.

Even if the operating system kernel is Y2K ready, utilities and other tools may not be. For example, directory listing programs may only display two-digit years for the file date, or system calendars may not be able to span the century crossing.

Tape backup routines may fail if they think that new files are old ones – they may even overwrite the new file with an earlier version.

It’s not just computers.

Many devices today have embedded controllers, all of which could have Y2K problems.

Examples are telephone systems, security systems, uninterruptable power supplies, HVAC systems, etc.

As an additional date to watch for, the Global Positioning System – the satellite navigation system used by ships, airplanes, and the military – has a calendar rollover on August 21/22, 1999 (but most modern GPS receivers will gracefully deal with this).

The Gartner Group estimates that 50 million embedded systems will experience anomalies during 1999.

It’s not just you.

Your company may have all its systems updated and tested, but what about your suppliers? Will the products and services they sell you be Y2K ready? And, will they be able to deliver those products and services after January 1, 2000 – will their infrastructure and IT systems be ready?

Don’t define “supplier” too narrowly. In some countries, the readiness of utilities such as electricity and telephone service is unclear. You may not consider that to be a serious risk where you live, but if you are in rented space, will your landlord’s security and HVAC systems be ready? How about your corporate jet’s navigation systems?

IV. Dealing With It.

The Six Step program:

Inventory - Identify all systems, hardware, software, data, and 3rd party components throughout all areas of your organization.

Assessment - For each component identified in the inventory, determine the impact of the year 2000 issue.

Analysis / Strategy - Based on the results of the assessments, determine the appropriate strategy to assure information systems will handle the year 2000 issue.

Correction - Based on the chosen course of action from the previous step, execute. There are five options for dealing with a non-compliant system:

Redevelop

Replace

Renovate

Rehost (move the application to a new platform that is Y2K ready)

Retire

Test - Make sure it works. (This may be the hardest part, and the one to which many organizations pay the least attention.)

Deployment - Deploy the new and/or updated systems assuring all appropriate parties have been trained.

Suppliers

Y2K representations and warranties are great, but it’s better to solve the problem than litigate it!

Most companies initially sent survey forms to suppliers asking numerous questions about the Y2K readiness of products.

This failed miserably; generic forms didn’t ask the right questions, and no company (at least, no company with counsel!) would respond to forms asking for “guarantees” or “assurances” relating to products that had already been sold.

The Gartner Group estimates that surveys yield only a 30% response rate, and of those only 3 to 10 percent appear to be accurate.

In addition to product questions, savvy purchasers have now recognized the infrastructure problems described above, and are asking questions about supplier IT and systems readiness, as well as about the readiness of the supplier’s suppliers. Just asking questions, though, has the same problem as product-related questionnaires – surveys typically don’t yield useful results.

The new approach is to do site audits with key suppliers. This is time consuming and expensive, but companies are realizing that this may be the only way to get a good understanding of their suppliers’ readiness. Key audit issues include:

product status;

readiness of supplier EDI and logistics systems; and

status of the supplier’s suppliers.

No matter what approach you take, you must have contingency plans and alternative suppliers lined up in case key suppliers have a Y2K catastrophe.

Your customers:

You’re not the only one worried about Y2K supplier issues. Expect to see similar surveys or audit requests asking the same things of you. It’s best to formulate a plan to respond to these inquiries – you’re likely to see many of them over the next months.

V. Litigation Hot Spots

Initial notes:

So far, there have been no court decisions that address what a vendor’s liability is for Y2K failures. That being the case, no one can do more than guess how far liability might extend. Keep that in mind when you hear claims about Y2K litigation.

There have been a handful of lawsuits filed in the US, the majority of them by one well-known firm.

As of April, 1998, the Gartner Group was aware of nearly 200 disputes that were in pre-litigation settlement discussions. There have been a significant number of settlements in the $1M - $10M range.

Product-related litigation areas are likely to be:

Breach of warranty in sales contracts.

Breach of UCC implied warranties in sales transactions.

Fraud/misrepresentation.

Claims under hardware or software maintenance contracts alleging entitlement to a Y2K upgrade.

Claims based on a vendor charging for Y2K upgrades (several class actions of this type have already been filed by Milberg Weiss Bershad Hynes & Lerach).

Other litigation areas are likely to be:

Shareholder derivative suits against companies (and directors/officers) who haven’t adequately addressed Y2K issues within their enterprises, or who haven’t adequately disclosed their potential risks.

Incidental/consequential damage claims due to Y2K-induced failure to perform (e.g., supplier unable to deliver because of systems failures).

IP claims for unauthorized modification of software to make it Y2K ready (though I personally don’t think this will be a significant issue).

VI. Fun Facts

According to the Gartner Group (April, 1998):

The total cost of Year 2000 is likely to be $600 billion.

25% of companies worldwide have still not started Y2K compliance efforts (about 10% of these have minimal automation, while another 10% plan to “ride it out”).

Less than 20% of all organizations will achieve full compliance by January 1, 2000.

At least 90% (and maybe 100%) of organizations that think they are currently fully compliant, aren’t.

Through early 1998, the rest of the world lags North America and the UK by at least six months in readiness.

And, both the Euro and the Asian economic situation are drawing resources away from Y2K efforts in those areas.

Actual Y2K costs at three companies averaged $6.46 per line of code.

Companies are spending 10 to 30 percent of their IT budgets on Y2K activities in 1998, and most are doing so by redirecting existing budgets, not spending new money. In 1999, large companies will spend over 40% of their IT budgets on Y2K.

VII. The Bottom Line

Y2K isn’t a difficult technical problem – your systems people know how to fix the code. It is a fiendishly difficult project management problem that requires involvement from all parts of the enterprise, and the visible commitment of senior management.

VIII. References and Resources

Lots of web sites:

The Year 2000 Information Center:

The Year 2000 Law Center: y2klawcenter.html

Year 2000 Legal Links:

Legal Issues Concerning the Year 2000 Millennium Bug: legal/jjin1.htm

ITAA Y2K Law Page (includes status of Y2K litigation): Y2Klaw.htm

Beyond Awareness: Ten Management And Ten Legal Pitfalls Regarding The Year 2000 Computer Problem That You May Not Have Considered, YET!: archive/beyond.html#legal1

Open Group Y2K Page: rdg.public/tech/base/year2000.html

NCR Year 2000 Home Page:

Most computer companies have Y2K pages at their main web site, usually with a “year2000” at the end of the URL

Publications:

BNA just launched their “Year 2000 Law Report” ($495/year).

Lexis Law Publishing has “Countdown 2000” ($149/year).

NCR

Year 2000

Qualification Requirements Definition

Version 3.0

2/04/1998

NCR and Year 2000 Qualification

Meaning of “Year 2000 Qualification”

The purpose of this document is to provide our customers, partners, suppliers, and employees a definition for NCR products that are "Year 2000 Qualified." Throughout the industry, the term “year 2000 compliance” remains ambiguous and this document is our attempt to place our stake in the sand. To avoid confusion with less precise descriptions of the year 2000 issue, NCR uses the term “Year 2000 Qualified” to identify products which meet our definition.

Some products will be listed in the NCR Year 2000 Qualification List as "Qualified With Comment", and an appropriate notation will be documented in the comment field. Any warranty made by NCR with respect to those products will be subject to any limitations contained or referenced in the comment field.

We anticipate that this document will evolve over time as more information about the requirements and testing are known.

I. As used by NCR, "Year 2000 Qualification" means that an NCR product has been reviewed to confirm that it stores, processes (including sorting and performing mathematical operations), inputs, and outputs data containing date information correctly regardless of whether the data contains dates before, on, or after January 1, 2000. NCR products which do not perform date manipulation, and which do not alter any date information that flows through them, are also considered Year 2000 Qualified.

In addition to the requirements contained in this document, NCR Year 2000 Qualified Products also comply with the standards and definitions listed in Appendix A.

II. Specifically:

Dates before, on or after January 1, 2000 may be interpreted and stored using either "FORMAT" or "CONVENTION" techniques. As used by NCR, “Year 2000 Qualification” means that the FORMAT technique is used. However, Qualification by CONVENTION may be used in circumstances where compliance by FORMAT is impractical, or where CONVENTION is required to meet specific external interface requirements; in that case the convention used must be specifically documented. “FORMAT” and “CONVENTION” have the following definitions:

FORMAT: All dates are stored, processed, input, and output in formats that preserve century, decade, and year information.

CONVENTION: Dates are stored, input, or output in a format that preserves only decade and year information, but are processed through a "sliding window" calculation. For example, if the year is 00 to 70, add 2000, and if the year is 71 to 99, add 1900. There is no industry standard for the “cut-off” date used in such calculations, and therefore interfaces may not work correctly between programs or systems using different conventions. Any NCR product achieving Qualification through CONVENTION must clearly document the cut-off date and any other necessary information relating to the bridging calculation used. This documentation must be included in the product’s entry in the NCR Year 2000 Qualification List.

III. Leap Year

The year 2000 itself must be correctly processed as a leap year. In other words, the two days following February 28, 2000 must properly be interpreted as Tuesday, February 29, 2000, and Wednesday, March 1, 2000.

IV. Display

Any display of a date, whether on screens or in reports, should use a four-digit year (YYYY). However, if two-digit display of a date is commonly accepted and does not cause confusion, the year field may be displayed as two digits.

V. Firmware and Hardware

Any firmware, hardware, or networking component in a Year 2000 Qualified computer platform must process dates in accordance with this Definition.

Vl. System Integration

Year 2000 Qualification extends only to the specific product configuration tested, and does not include other software, firmware, or hardware products which may be used in conjunction with the tested configuration. For an NCR product configuration consisting of multiple components to be considered “Year 2000 Qualified,” each constituent component, regardless of vendor, must be "Year 2000 Qualified" in accordance with this Definition, and the system as a whole must be tested for Year 2000 Qualification. “Constituent components” include all software (including operating systems, programs, packages, and utilities), firmware, hardware, networking components, and peripherals provided by NCR as part of the configuration.

The Year 2000 status of third party products not provided by NCR is beyond the scope of this Definition.

Vll. Contracts

All contracts with vendors for products to be used in the computer system or platform MUST state that Year 2000 Qualification is a performance requirement.

VIII. Year 2000 Product Qualification Requirements

All of the following questions must be answered as indicated or “NA” for any NCR product to be identified as “Year 2000 Qualified.” Any deviations from these responses must be specifically documented, and an exception must be noted in the product’s entry in the NCR Year 2000 Qualification List.

|( |DATE MANIPULATION QUESTIONS |NA |No |Yes |

| | | | | |

| |Does the product: | | | |

|1. |Use December 31, 1999 as a regular end of year without special meaning? | | |( |

|2. |Treat September 9, 1999 as a regular day with no special meaning? | | |( |

|3. |Do any of the following date field manipulations? | |( | |

|4. |99 indicates last record | |( | |

|5. |00 to indicate a null record | |( | |

|6. |99 and 00 default values | |( | |

|7. |Special interpretations of 00 | |( | |

|8. |Hard coded 19 in 4-digit year field | |( | |

|9. |Separate manipulations of century digits | |( | |

|10. |Include any license date expiries associated with the end of 1999? | |( | |

|11. |Use dates in name constructions? | |( | |

|12. |Mix date data and control information in commands or flags which are interpreted as one or the other depending on | |( | |

| |their values? | | | |

|13. |Use a date as part of the key of an indexed file? | |( | |

|( |YEAR AND CENTURY QUESTIONS |NA |No |Yes |

| | | | | |

| |Does the product: | | | |

|1. |Recognize 2000 as a leap year? | | |( |

|2. |Allow itself to be set to any date after 12/31/1999 including 02/29/2000? | | |( |

|3. |Indicate the correct day, date and time when the following test is performed: With the date set to 12/31/1999, | | |( |

| |power the product off and then back on when the time will be in 1/1/2000. | | | |

|4. |Indicate the correct day, date, and time when the following test is performed: With the date set to some time after| | |( |

| |1/1/2000, power the product off and back on. | | | |

|5. |Display the date correctly as 2/29/2000 when the following test is performed: With the date set to 2/28/2000, power| | |( |

| |the product off, and then back on when the next day has been reached. | | | |

|6. |Treat January 1, 2000, a Saturday? | | |( |

|7. |Treat February 29, 2000, a Tuesday? | | |( |

|8. |Treat March 1, 2000, a Wednesday? | | |( |

|9. |Treat February 28, 2001, a Wednesday? | | |( |

|10. |Treat March 1, 2001, a Thursday? | | |( |

|( |DATA BASE ACCESS AND STORAGE |NA |No |Yes |

| | | | | |

| |Does the product: | | | |

|1. |Code all years as in a manner that preserves century, decade, and year information? | | |( |

|2. |Correctly perform all of the following manipulations across the century boundary? | | |( |

|3. |Computations of time spans, due-dates, etc. | | |( |

|4. |Sorting of data. | | |( |

|5. |Selections based on key fields | | |( |

|6. |Selections based on non-key fields | | |( |

|( |OS & APPLICATION QUESTIONS |NA |No |Yes |

| | | | | |

| |Does the product: | | | |

|1. |Display the year as an unambiguous value with a minimum of two digits? | | |( |

|2. |Correctly handle data with dates before 1/1/2000, on 1/1/2000 and after 1/1/2000 with the system clock set to | | |( |

| |today's date? | | | |

|3. |Correctly handle data with dates before 1/1/2000, on 1/1/2000 and after 1/1/2000 with the system clock set | | |( |

| |to1/1/2000? | | | |

|4. |Correctly handle data with dates before 1/1/2000, on 1/1/2000 and after 1/1/2000 with the system clock set after | | |( |

| |1/1/2000? | | | |

|5. |Correctly handle data with dates before 1/1/2000, on 1/1/2000 and after 1/1/2000 with the system clock set to | | |( |

| |12/31/1999? | | | |

|6. |Correctly process dates with the system clock set to 12/31/1999 and processing allowed to continue across the | | |( |

| |century boundary? | | | |

|7. |Correctly handle date comparisons where one date is not greater than 12/31/1999 and the other date is not less than | | |( |

| |1/1/2000? | | | |

|8. |Use a sliding window for year calculations? | |( | |

|9. |Contain a date format that does not preserve century information? | |( | |

|10. |Create and/or store data in files or log files, or generate reports that do not preserve century information in date| |( | |

| |fields? | | | |

|11. |Use a 32 bit incrementing signed value for date and time? | |( | |

|12. A |Correctly set and maintain the century digits in the real time clock? | | |( |

|12. B |If century information is not correctly set in the real time clock by the product hardware (NO to Question 12A), | | |( |

| |does the operating system or system software correctly set and maintain the century information in the real time | | | |

| |clock? (If 12A = NO and 12B = YES, product satisfies the criteria). | | | |

|13. |Correctly handle all time interval calculations based on the century transition – both looking back into the past, | | |( |

| |and looking forward into the future? | | | |

|14. |Correctly handle future time interval calculations that span the century transition? | | |( |

|15. |Make use of data previously stored by the product or previous versions of the product and does it correctly read and| | |( |

| |handle date and time interval calculations? | | | |

|16.. |Formally tested for year 2000 Qualification? | | |( |

Appendix A

The purpose of this Appendix is to identify industry or national standard Year 2000 compliance definitions which NCR meets or exceeds the requirements. NCR will compare our Qualification Definition with relevant industry and country standards and we will determine whether we meet them or not, and if not, what we see as the difference.

Meets or Exceeds

• Sweden Year 2000 compliance definition

Failed to Meet

• None at this time

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download