Conference evms::y2k

80.0. "IEEE effort on Y2K (from Kevin Lewis)" by STAR::MEZZANO (What's up, doc?) Mon Jun 02 1997 17:42

Date:	27-MAY-1997 01:14:31.02
From:	US2RMC::"[email protected]" "Kevin Lewis"
Subj:	Review of IEEE Draft document containing Y2K terms and definitions
To:	Michael Pallone <[email protected]>, Rex Lint <[email protected]>, 'Vincent
Mamone' <[email protected]>, 'Vittorio Mezzano' <star::mezzano>

I am serving as the technical editor for the newly formed IEEE project to 
identify and define Y2K terminology. I have attached the first draft of 
this document. I am requesting your input on this draft based on a past 
dialogue I have had with you or because someone has recommended you as a 
reviewer.

Let me summarize this draft:

1)	The actual core content for review is 3 pages in length (sections 1 and 
3)
2)	The draft outlines concepts and definitions. The "concepts" section 
allows industry to address inter-related ideas and to reflect some 
consensus without providing a formal definition
3)	Digital consensus is NOT to define "Y2K compliance", given the 
non-existence of any current Y2K standards; thus the definition included in 
the document focuses on "Y2K readiness" (the issue of compliance is 
addressed as a concept only).
4)	A note on the "Y2K ready" definition: I expect that the last clause 
starting with "provided that...."  will elicit a significant amount of 
controversy given that this clause makes readiness dependent on other 
systems that may or may not be "ready".

This draft will be presented to industry during an interim meeting of the 
IEEE study group to be held on June 10 (day 2 of the NIST Y2K Symposium). 
Please provide any comments you may have to me no later than Monday, June 
2.

The next formal meeting of this group will be in Nashua during the week of 
July 14. I am serving as the coordinator of all feedback to this effort so 
please contact me on anything related to it.

I will send this document both as a Word file and also as text for those 
not on Exchange.

--Kevin Lewis


IEEE PXXXX
Draft Standard for
Year 2000 Terminology




Prepared by the Terminology Working Group of the
Portable Applications Standards Committee



Introduction


(This introduction is not part of IEEE PXXXX, Draft Standard for Year 2000 
Terminology)

This introduction provides background on the rationale used to develop this 
standard. This information is meant to aid in the understanding and usage 
of this standard.

This standard addresses the key industry concern over the existence of 
multiple terms and lexicons that carry varied meanings. IEEE has designed 
this standard to assist individuals and organizations in their efforts to 
develop Year 2000 solutions. Having a base-line set of terms and 
definitions that can serve as a foundation for such efforts is vital.

Participants

At the time IEEE PASC completed this standard, the Year 2000 Terminology 
Working Group had the following membership:

Lowell Johnson, Chair	Kevin Lewis, Technical Editor


The following persons were on the balloting committee:

(To be supplied by IEEE)

Contents


1.	Overview

1.1	Scope
1.2	Purpose
1.2.1	Concepts
1.2.2	Definitions

2.	References

3.	Concepts and Definitions





Draft Standard for
Year 2000 Terminology


1. Overview

The Year 2000 (Y2K) is a problem simply understood. However it requires 
complex solutions. Simply put, this problem is rooted in the representation 
of the year as a two-digit number within computer data and software. This 
representation, when a computer system crosses the year 2000 for time 
processing purposes or when the year actually arrives, will cause failures 
such as:

.	Arithmetic,
.	Comparisons
.	Sorting
.	Incorrect recognition of leap years
.	Conflict with "00" and "99" as reserved values with other meanings
.	Rolling over of system date data, filling up storage registers

The visibility of this problem has risen dramatically over the last six 
months. Many organizations are in varied stages of addressing it, from 
assessment to implementation. Many are somewhere between these to stages. 
This rise in visibility has brought many organizations with solutions to 
the table. Concurrently, their arrival has also brought quite a varied 
lexicon. Many of the terms within these lexicons are similar on the surface 
but have multiple meanings within differing environments, bringing 
potential for great confusion to what is a simply understood problem.

This document identifies definitions and concepts that have the broadest 
applicability to this area of work. The open, consensus method has served 
as the means by which the industry has accomplished this, using the 
accredited standards process as the foundation for this work.

There is no other problem wherein communication between users and vendors, 
and among industries as a whole, is as paramount, given its pervasive 
effects. Having a common lexicon within which the terminology and concepts 
are understood is vital. The information technology (IT) industry's use of 
these terms outlined in this document will minimize confusion. In addition, 
they will enhance the progression of vitally needed solutions by providing 
a common base of accepted definitions upon which these solutions can be 
developed.


1.1	Scope

This standard identifies definitions applicable to the Year 2000 problem in 
computer systems and other related time and date boundary value problems.

1.2 Purpose

This standard supplies common terms, their definitions, and related 
concepts for people working on the Year 2000 problem and other time and 
date boundary value problems.

This document contains two parts: concepts and definitions

1.2.1 Concepts

These are a set of interrelated ideas pertaining to the Y2K issue. This 
document offers an explanation of these concepts based on industry 
consensus achieved in this document's development.

1.2.2 Definitions

These are focused meanings of terms fundamental in the resolution of the 
Y2K issue.


2.	References

This standard shall be used in conjunction with the following publications. 
If the following publications are superseded by an approved revision, the 
revision shall apply.

(To be supplied)


Section 3:	Concepts and Definitions


3.1 	Concepts


3.1.1 Compliance:	brings two distinctive images. Within the industry at 
large, compliance generally means that a system or product functions in a 
manner yielding an expected result or set of results. Within the standards 
community, it denotes a much more detailed approach whereby a system or 
product functions in accordance with a specific set of specifications or 
pre-designed functions, yielding a more precise, usually more quantifiable, 
set of results.

Currently, there are no Y2K standards. Thus the concept of compliance at 
this point in time is ambiguous. However, as the industry progresses 
forward in the development of Y2K solutions, such solutions will entail 
specific product/performance specifications with which individual 
organizations can require compliance.

3.1.2 Readiness: is a system's state of preparedness in handling year 2000 
processes. This state of preparedness is a dynamic state. This document in 
the subsequent section defines "Year 2000 Readiness". However, as 
organizations move further into the implementation phase of applying Y2K 
solutions, this state of readiness will change, given the specific 
environment and mission of the organization(s) involved.

3.1.3 Y2K safe: is a new concept arising out of societal concerns for 
citizen/organizational safety. A consensus is developing over the need to 
ensure that systems do NOT cause direct or indirect injury or damage when 
handling year 2000 processes. The notion here is of a preventive nature. A 
system may not be fully ready to handle such processes. But it can be 
prevented from causing or setting detrimental courses of action in motion 
when it fails to handle one or more year 2000 processes properly.


3.1.4 Conformance: has had multiple connotations within the IT industry. In 
one sense, it refers to function and specification; in another, it refers 
to implementation and practice. Within the Y2K arena, consensus is more 
towards the latter. A system/product is conformant when it adopts a widely 
accepted industry practice in addressing year 2000 processes. Such 
practices serve as reference points.


3.1.5 Fix: is a specific remedy to a specific system/product's handling of 
a year 2000 process. The industry currently reflects strong consensus that 
there is NO ONE fix for all systems; that a range of fixes can, and will 
most likely, apply. Fixes will be dependent on the operating environment 
and the prevailing factors within, such as the degree of interfacing the 
system has with other systems, or the level of date data processing within 
or across systems. This list includes some of the possible fixes under 
industry scrutiny:

.	expanding the year field to four digits
.	encoding century information in a six-digit space
.	using a 100-year logic window
.	employing a data bridge that uses a logic window
.	reversing the system clock and using a 28-year time bridge
.	replacing (or retiring) the system


3.1.6 Format: refers to the basic layout of date data within a Y2K process. 
Organizations have attempted to standardize this layout. However, it has 
become apparent that multiple acceptable formats can and do exist. Thus the 
requirement to have one standard layout is counterproductive. Industry 
consensus on this issue reflects the desire that any acceptable date format 
be recognized by a year 2000 ready system.  The process of identifying 
acceptable formats is on going.


3.2	Definitions

3.2.1 Year 2000 ready: information technology, when used in accordance with 
its associated documentation, is capable upon installation of accurately 
processing, providing, and/or receiving date data from, into, and between 
the twentieth and twenty-first centuries; including leap year calculations, 
provided that all other technology used in combination with the said 
technology properly exchange date data with it.

3.2.2 Date data: user-recognizable expression of dates used by applications 
within a computer system

3.2.3 Date format: the expression of a calendar date in an acceptable 
industry layout

3.2.4 Date processing: the handling of date data within a computer system

3.2.5 Date exchange: the interchange of date data between two or more 
computer systems

3.2.6 System date: internal date, normally not user-recognizable, set 
within a computer system





% ====== Internet headers and postmarks ======
% Received: from cst.ako.dec.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA15687; Tue, 27 May
97 01:02:10 -0400
% Received: by cst.ako.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version
4.0.994.63) id <[email protected]>; Tue, 27 May 1997 01:07:13 -0400
% Message-Id: <c=US%a=_%p=Digital%[email protected]>
% From: Kevin Lewis <[email protected]>
% To: 'Bruce Albertelly' <[email protected]>, 'Dick Smith' <[email protected]>, 'Donna
Harrington' <[email protected]>, James Isaak <[email protected]>, 'Lou Marcoccio'
<[email protected]>, 'Michael Aisenberg' <[email protected]>
% To: Michael Pallone <[email protected]>, Rex Lint <[email protected]>, 'Vincent
Mamone' <[email protected]>, 'Vittorio Mezzano' <star::mezzano>
% Subject: Text version of IEEE Y2K terms draft
% Date: Tue, 27 May 1997 01:07:10 -0400
% X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
% Encoding: 232 TEXT

   An IEEE standard?  Somebody doesn't have enough to do, or April 1st
   came late this year... :-)

	--

   I'd recommend `binary date', rather than `System date' in 3.2.6.

   I know what a `100-year logic window' is, but this should be defined.
   I'd also recommend the recommendation of a particular year, else this
   becomes a giant randomization function for the next generation of date
   engineers.

   I don't know what `reversing the system clock and using a 28-year time
   bridge' implies, but it sounds sufficiently ugly that I don't really
   even want to know...