Novell is now a part of Micro Focus

Novell's Project 2000: Meeting the Challenge of Century Compliance

Articles and Tips: article

Program Manager
Major Market Operations

01 Jul 1997

The dreaded year 2000 is rapidly approaching, and with the media spouting dire predictions of the widespread collapse of computing systems, many network administrators are getting nervous. Find out what Novell is doing to help you meet the Year 2000 challenge.


As the year 2000 approaches, information systems will undergo a date transition that will present some major challenges to the information technology industry. To conserve disk space and memory, many software programs represent the date with two digits. As a result, these programs will not operate correctly unless they are reprogrammed to accommodate the new century. With an estimated 60 million users around the world, Novell has a responsibility to its customers and to the information technology community in general to properly address these year 2000 issues.

As a part of this effort, Novell has established a program to ensure Year 2000 compliance for customers and partners. Project 2000 defines the criteria and process that is the basis for this compliance. Through this process, Novell will identify products that support the next millennium and correct or discontinue products that do not. Additionally, Novell is working with its third-party developers to ensure compliance in integrated products. This project includes validation of Novell's internal applications as well. Novell will also monitor and incorporate additional compliance issues identified by the industry at large.

This AppNote provides some background information to help you understand the nature and scope of the Year 2000 problem. It then presents an overview of Novell's Project 2000 for dealing with Year 2000 issues as they relate to the products that Novell sells, as well as to the internal applications and technology Novell uses to conduct business.

Background on the Year 2000 Problem

From the early days of software development, two-position year fields were used to reduce data entry, memory requirements, data storage requirements and computer processing cycles. At the time, carrying the century field was considered a waste of limited resources and unnecessary because field always contained the value "19".

This convention persisted even as memory, storage, and computer processing cycles became more available. Program code containing two-position year fields was reused or enhanced in developing new systems, and data with two-position year fields was passed from older systems to newer ones. When these systems were being developed, it was never envisioned that they would still be running at the turn of the century. The fact that they are still in production today is a reflection of both the quality of the systems and the difficulty of replacing them with more modern technology. Unfortunately, habits of the past have followed us into the future.

Impact of the Year 2000 Problem

What will happen when these legacy systems try to process dates of 2000 and beyond? The year 2000 will be stored as "00" which may be interpreted as 1900. This could cause systems to either produce erroneous results or to stop processing completely.

Date Ambiguity. This misinterpretation of the date primarily affects calculations, comparisons and sequencing, but any use of a two-position year field is a potential problem. Much has been written about the problems facing business applications that compute such things as ages, expiration dates, and due dates, by subtracting one year from another. For instance, at the year 2000, the age of someone born in 1960 will be computed as B60 years old, instead of 40 years old.

The Year 2000 as a Leap Year. Another component of the Year 2000 issue is that 2000 is a leap year. This may not have been incorporated into date routines since century years are only leap years if they are divisible by 400. Thus even if date routines use a four-position year, there is a concern that they may not incorporate the necessary logic to recognize that 2000 is a leap year.

Other Ramifications. The Year 2000 issue is generally discussed in terms of what will happen January 1, 2000 if the systems have not been fixed. In actuality, some systems have already required date conversion and it is likely that other systems are producing erroneous results and the errors have not yet been noticed. For instance, application systems which handle 30-year mortgage computations required correcting in 1970. The Gartner Group estimated that 20 percent of business applications would fail in 1995 due to date computations. Between now and January 1, 2000, systems that use dates in the future, such as forecasting, long term expirations, and archival and backup, may begin to fail. Systems that use fiscal years may begin to fail in or before 1999. Other systems may fail during the transition period between 1999 and 2000.

What Systems Are Affected? The systems affected are primarily legacy systems, although all systems should be checked to ensure they correctly handle a four-digit year field. The types of systems include mainframe, client/server, workstations, distributed systems, telecommunications systems like PBXs, networks, routers, hubs, and communication processors.

The software potentially impacted includes that developed in-house, developed commercially, and software developed by end-users for their own use. The impact is not limited to application software. It is a potential problem in system software, such as operating systems and system utilities, embedded microcode, firmware, and hardware. Another significant aspect of the problem is the data bases and files where the two-position year fields are stored.

Industry estimates are that as high as 90 percent of programs and 4 percent of the lines of code will need to be changed. Because of the pervasive use of dates in systems, to find the specific 4 percent of the code to be changed will require examination of 100 percent of the code. The only safe assumption is that all systems are affected until they have been assessed and found to be Year 2000 compliant.

Within the last few years the full magnitude of Year 2000-related date conversion has attracted a lot of attention. Estimates by the Gartner Group total this transition's cost at up to $600 billion worldwide. Keenly aware of the sheer size and urgency of the year 2000 issue, Novell is prepared to provide products that are validated to conform with the needs of this transition.

Addressing the Management Challenge

The Year 2000 problem is primarily a business and a management problem. What makes it such a challenge is its sheer size. In most cases, the changes needed to each individual component are not technically difficult. The difficulty comes in the planning, scheduling, coordinating, and managing an effort of this magnitude.

Project coordination is one example of the management challenge. Some areas to consider include:

  • Components within a system. Date fields must be identified and made consistent in all components of a system (files, databases, programs, and so on). The timing of the date change implementation should be such that all are ready before system and acceptance testing can begin.

  • Shared components between systems on the same hardware platform. Systems sharing a hardware platform often share data files and databases and may share common objects, utilities and subroutines. If these are not all converted at the same time, temporary bridges may need to be put in place to handle converting date fields between two and four-position years.

  • Shared date functions between applications and operating systems. Application software is usually dependent on the operating system for some date functions, such as system dates. Unfortunately, not all operating systems have been updated to be Year 2000 compliant. Some operating systems may never be updated to be Year 2000 compliant.

  • Shared components between software and hardware or firmware. In some systems, hardware or firmware may need to be upgraded to be Year 2000 compliant.

Creating a Year 2000 Compliance Test Bed

In most cases, creating a compliant environment will require coordination in building compliant versions of hardware, firmware, operating system, database version, third-party application software, in-house developed software, and utilities (such as backup systems).

Identifying the Technical Requirements

The technical issues involved in the Year 2000 effort revolve around accepting, creating, manipulating and outputting calendar related data accurately. While the concern is focused on the roll over from 1999 to 2000, Year 2000 compliance also involves other date related events that may occur well before or after the year 2000. The following table identifies requirements for Novell's Year 2000 compliant products and business applications:

Requirement No.
Requirement Description


The product or business application must correctly display dates up to the year 2035. This includes debugging, logging, and diagnostic information that may be used by other programs.


The product or application must correctly treat the year 2000 as a leap year.


The product or business application must correctly calculate the day of the week for all dates from 1980 to 2035.


The product's or business application's calendar arithmetic must correctly count time durations between any two dates from 1980 to 2035. This includes, but is not limited to, the following critical dates:

Friday, December 31, 1999Saturday, January 1, 2000Monday, February 28, 2000Tuesday, February 29, 2000Wednesday, March 1, 2000Sunday, December 31, 2034Monday, January 1, 2035

In addition, the difference between 01/01/1980 and 01/01/2035 should calculate to 20,089 days.


The product or business application must sort dates in proper chronological order for any collection of dates from 1980 to 2035.


The product or business application must treat dates and durations intended to mean "no date" or "never" explicitly, rather than using shorthand such as all 0s or all 9s. Specific attention is directed to 9/9/99.


For each product or business application: Wherever a time stamp is stored in binary, the time stamp must be tested for rollover to zero or rollover to negative to ensure proper handling. All time stamps used for dates must have sufficient capacity to function properly during the years 1980 to 2035 without ambiguity.


For each product or business application: Any file format used as input to a subsequent process must be scrutinized and the subsequent process analyzed to ensure proper operation of the combined functionality between 1980 and 2035.


For each product or business application: Any file format that is changed as a result of these requirements will be supported by documentation describing the migration from the old format to the new format. Programs that manipulate the new format must also tolerate the old format.


For each product or business application; Any wire protocol that is changed as a result of these requirements will be supported by documentation describing the migration from the old wire protocol to the new wire protocol. Servers or clients that use the new protocol must be able to tolerate the old protocol as well. If two devices must exchange times or time stamps and only one of them is capable of the old format, the newer device must be capable of supplying the old format.

Novell's Plan for Meeting the Year 2000 Challenge

To assure the integrity of Novell's products and business processes, Novell has initiated Project 2000, a company-wide plan addressing year 2000 issues.

Organization of Novell's Year 2000 Effort

Project 2000 is organized with an executive level Steering Committee reporting to the President of Novell and is supported by a full-time Project Manager. Project teams from all Product Groups, Business Application Groups, and Marketing and Communications report to the Project Manager. In addition, Novell's corporate quality group is acting as an internal auditor for compliance validation. Novell will also undergo third-party certification for Year 2000 compliancy.

Role of Project 2000 Teams

The Project 2000 teams are responsible for coordinating the Year 2000 issues and information, reporting the status of assessments, business risks, systems conversions, testing processes and sharing lessons learned with other team members. These teams are comprised of representatives from the Product and Business Application Groups. Each Product and Business Application Group is responsible for the Year 2000 changes to their systems and products. Each group developed an overall inventory of their systems, prioritized the conversion of the systems based on the criticality of each system, and has developed a plan which includes resources to perform the work. Within the Product and Business Application Groups, each group manager is responsible for the planning and conversion of their own systems, consistent with Project 2000 requirements.

Project Phases

While the Year 2000 challenge is an urgent matter, responding to this challenge without the proper analytical discipline could prove counter-productive in achieving timely and cost-effective results. Novell began this process by clearly articulating the criteria for "Year 2000 Compliance." These criteria provide the basis for the project's implementation phases that are being used to guide the planning and execution of Year 2000 activities. Novell's Project 2000 consists of seven phases to assess information systems. Following this framework in a timely fashion provides confidence that your business functions and services successfully continue into the year 2000 and beyond.

Awareness. This is the preliminary phase of the project. The purpose of this comprehensive planning phase is to recognize, define and publicize the issues involved. During this phase, management support is obtained and plans are put in place to begin the actual Year 2000 effort. Detailed schedules and milestones are also developed. A key requirement for success of any project of this magnitude is an understanding of the issues and a commitment to successfully implement the right solutions on the part of all management and technical personnel involved. This project requires a significant commitment of resources. Support of senior management is essential in making tradeoffs and setting priorities in order to ensure that products and business applications are converted and thoroughly tested.

Assessment. The purpose of this phase is to assess the vulnerability of all systems and products-in production as well as in the planning stages-to the Year 2000 problem and to develop a plan for correcting any non-compliant components that may be discovered or obsoleting others. After the inventory of every identified component is completed, prioritize the conversion efforts. We suggest conducting a pilot during this phase to test standards and procedures and fine tune time estimates. The pilot's results will prevent problems in subsequent conversions.

This is perhaps the most critical phase in the entire project. To the extent that it is performed accurately and completely, it forms the basis for completing the remaining phases in a timely manner.

Renovation. Renovation is defined as the phase where code is actually changed to be Year 2000 compliant. In addition to updating source code, common date routines may be developed and file conversion and bridge programs written. Configuration management plays a key role in maintaining the integrity of these and ongoing changes.

Conversion. The actual conversion consists of modifying all product components and business applications to be Year 2000 compliant. All routines that deal with date calculations need to be checked carefully and all related components must be examined to determine if there are any date impacts. All documentation needs to be updated to reflect any new date formats or processing. In most cases, this requires teams working on different areas. Code analysis identifies the date fields by finding references to "Date," "Year," "YY," and so on, determining the fields they are moved to or from, and repeating the process until all date fields have been identified. All routines that deal with calculations need to be checked carefully to see whether they recognize that the year 2000 is a leap year.

Validation. During this phase, all changed components are tested. Test requirements must conform to Project 2000 requirements and should follow standard corporate testing procedures. As with any conversion, various levels of testing are needed, including unit, system, acceptance, integration and interface testing. Tests should be conducted using at least these three different date conditions:

  • Current system date, existing file dates

  • Current system date, file dates after 1999

  • System and file dates after 1999

Implementation. Implementation is the phase where the Year 2000 compliant business applications are put back into production and Year 2000 compliant products are released for production. Implementation plans should consider issues such as upgrade migration path, cost, and revenue impact.

The technical aspects of the Year 2000 issue are only important in resolving the functional problems that might occur. The issue as it relates to our customers is how these changes are going to impact their business. Constant consideration to existing data and processes must be incorporated in the implementation. One critical concern is the interfaces between converted systems and systems not yet converted. Batch or interactive bridges serve as a solution, converting the representation of dates to the expected format. Novell is sensitive to the impact this will make on our customers' business. We are dedicated to fix any functional problems but also to make any fixes as painless and practical as possible.

Certification. This final step allows for either internal or external "auditors" to assess whether or not your plan was comprehensive and followed. Doing this will help ensure that you have not missed essential areas or steps in the process.

Ready for the Future

Project 2000 is a detailed development plan designed to protect Novell's customers from year 2000 ramifications. Novell encourages all organizations and individuals to develop a plan to evaluate their critical operations. This plan should include assessing readiness for the date change and modifying areas that prohibit a smooth transition, as well as backup plans for any systems not fully compliant by January 1, 2000. Novell is pleased to be a partner in your business as, together, we move forward into the next century.

Frequently Asked Questions About Novell's Year 2000 Strategy

Q. Is Novell addressing year 2000 related software issues?

A. Yes, Novell has had a project, with executive level support, underway for some time. Project 2000 is clearly defined with well articulated goals and objectives. The Project is structured with a Steering Committee, which reports to the President of Novell, to provide overall guidance and direction, a project manager, and two project teams. These project teams are comprised of representatives from product groups and business application groups within Novell. In addition, Novell's corporate quality group is acting as a third-party observer and auditor for compliance and certification.

Q. What is Novell's definition of "Year 2000 Compliant"?

A. Novell defines a product compliant that, when used as designed and documented, correctly creates or receives date information within and between the 20th and 21st centuries, as long as all other products (software, firmware, hardware products, and so on) used with the product accurately exchange date data with the application.

Q. Are Novell products Year 2000 compliant today?

A. Novell has been developing software with the year 2000 in mind for some time. Novell is currently well into the project to certify its products as year 2000 compliant by the end of 1997. Novell's products are undergoing meticulous testing and review to validate year 2000 compliance based on criteria Novell has developed from industry-wide standards. While Novell does not anticipate any problems with our products, we are undergoing a thorough review and validation process for all of our supported products. Our objective in this process is to ensure our customers that Novell products are compliant and ready for the next millennium. Rather than providing invalidated assurances based on this work in progress, Novell products' year 2000 compliance verification will remain contingent upon the conclusion of this project and certification by a third party.

Q. When do you expect that all Novell products will be Year 2000 compliant?

A. Novell is currently well into a major project to certify its products as year 2000 compliant by the end of 1997. Novell anticipates that all new versions of our products shipped after January 1, 1998, will be Year 2000 compliant. Compliance information on the various Novell products will be made public as the compliance program is completed.

Q. How will you communicate to your customers the status of your products?

A. Novell will continue to use its existing communication channels to communicate Year 2000 to customers. Web sites at and will be used to deliver updates, patches, and upgrade information concerning year 2000 issues.

Q. Are your internal business systems compliant? If not, do you have a plan?

A. As a company, Novell has developed a plan and is engaged in our own efforts to have all internal business systems compliant well in advance of the year 2000. We have already begun assessing and updating all our information systems and applications to allow business functions and services to operate normally through the turn of the century.

Q. What testing resources does Novell have to test Year 2000 compliance?

A. With Novell's SuperLab, one of the largest PC test labs, Novell is singularly positioned to test systems and networks. Novell will be working very closely with its partners, developers, and integrators to assure customers that Novell products are compliant. Novell Labs is currently considering how its facilities might be used to assist customers in their testing efforts.

Q. Is there a migration or upgrade path to Year 2000 compliant versions of your products?

A. At this time we have not published any official Year 2000 product migration strategy. More information will be released as product compliance processes are completed.

Q. What is your suggestion as to how customers should be working with you to become compliant?

A. Novell encourages all organizations and individuals to develop a plan to examine and assess their critical operations. This plan should include evaluating their readiness for the year 2000 date change, developing changes to areas that would prohibit a smooth transition, as well as devising backup plans for any systems that may not be fully compliant by the time January 1, 2000, arrives. We request that any compliance issues discovered through these efforts be communicated to your account representative, who is in communication with the Year 2000 Project Team. In turn, we will be placing on our company Internet sites more detailed information about our year 2000 testing processes and results.

Sources of Additional Information on the Year 2000 Issue

There is a great deal of information available on the Internet on the Year 2000 issue. Some good starting points for additional information are listed below:

  • Novell's Year 2000 Web Page ( contains information specific to Novell and provides access to additional Year 2000 information.

  • The Year 2000 Information Center, sponsored by Peter De Jager and the Tenagra Corporation ( contains numerous articles, information on user groups and conferences, and information on vendors supplying Year 2000 services and tools.

  • The Interagency Committee Year 2000 Home Page, which is also the GSA Year 2000 Home Page ( provides access to information prepared by the Interagency Committee and access to other government Year 2000 Home Pages.

  • The IBM planning guide entitled "The Year 2000 and 2-Digit Dates: A Guide for Planning and A Guide for Planning and Implementation" ( contains information that is relevant to planning for the conversion regardless of the component.

  • The "Year 2000 FAQ, Frequently Asked Questions about the Year 2000 Computer Crisis"( contains a compilation of answers to frequently asked questions.

  • The GTE "Proposed Criteria for 'Century Compliance'" paper provides information regarding the scope of the Year 2000 challenge and identifies and discusses suggested criteria for assessing compliance. This document can be found at

* Originally published in Novell AppNotes


The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates