|
____________________________________________________
OSSG Year 2000
Investigator's Guide
February 17, 1997
This handbook provides guidelines for investigating
code for Year 2000 readiness and describes the forms
that must be used to report investigation findings.
________________________ Note ________________________
This document and the report questionnaire are posted
in Note 5 in the EVMS::Y2K notes conference (.TXT) and
in the BULOVA::DOCD$:[Y2K] directory (.PS).
______________________________________________________
*** DIGITAL CONFIDENTIAL ***
_________________________________________________________________
Contents
1 Introduction
1.1 Overview of this Document..................... 1-1
1.2 Overview of the OSSG Year 2000 Project........ 1-1
1.3 OSSG Year 2000 Resources...................... 1-4
2 The OSSG Year 2000 Investigation Process
2.1 Searching Code for Date or Time Related "Hot
Spots"........................................ 2-1
2.2 Analyzing Potential Problem Areas in Code .... 2-3
2.3 Testing Your Code for Year 2000 Readiness..... 2-9
2.4 Documenting Your Findings .................... 2-10
2.5 Fixing Year 2000 Problems .................... 2-12
3 Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions.................................. 3-1
3.2 Year 2000 Status Definitions.................. 3-6
3.3 Sample Year 2000 Investigation Report ........ 3-9
4 Reporting OSSG Year 2000 Problems
4.1 Filing a YEAR-2000 QAR Report................. 4-1
4.2 Sample YEAR-2000 QAR Report................... 4-4
iii
1
_________________________________________________________________
Introduction
1.1 Overview of this Document
This document covers the following topics:
o Introduction (Chapter 1)
Provides an overview of the OSSG Year 2000 project and
the resources available.
o Year 2000 Investigation Process (Chapter 2)
Describes what to look for in your investigations or
testing and suggests the kinds of fixes to make.
o Filling Out the Investigation Report (Chapter 3)
Explains how to fill out a report for the code you
investigate.
o Reporting Year 2000 Problems (Chapter 4)
Lists the information that you must provide when filing
a problem report for a Year 2000 problem.
This document is available in the following locations:
o BULOVA::DOCD$:[Y2K]Y2K_INVESTIGATOR_GUIDE.PS
o EVMS::Y2K notes conference, Note 5 (.TXT format)
1.2 Overview of the OSSG Year 2000 Project
The major objective of the OSSG Year 2000 Project is to
ensure that customers can count on our software to work
in a predictable and correct manner into the Year 2000 and
beyond.
Customers also need to know the status of our code as soon
as possible so that they can scope out the need to make any
changes in their own code.
1-1
Introduction
1.2 Overview of the OSSG Year 2000 Project
The major concern behind the so-called "Year 2000 problem"
is the representation of years with only two digits instead
of four (for example, "96" instead of "1996"). Use of 2-
digit year representations can cause application problems
during the transition to the year 2000. It can result
in processing errors, especially in cases of sorting,
comparison, and arithmetic operation.
The major requirements that the OSSG Year 2000 Project is
addressing are the following:
o Timely availability of Year 2000 ready products,
including hardware, system software, and layered
products
Many customers need our products to be Year 2000 ready
by the end of 1997 to allow them adequate time to test
and correct their own software during 1998 and put their
Year 2000 ready applications into production during
1999.
o Support and information on the status of installed
products
Customers want to know the state of our products in
terms of Year 2000 readiness. They also want to know the
techniques and methodologies used to find, correct, and
test problems.
o The emerging legal and contractual requirements around
the Year 2000 issue mandate a "Due Diligence" approach
and analysis of our products. For example, in order
to do business with the U.S. government, Digital must
conduct an investigation and document our level of Year
2000 readiness.
For the OSSG Year 2000 Project, due diligence means
that we will do our best to make sure that information
technology environments using our software will continue
to work without problems through the Year 2000 and
beyond.
The OSSG Year 2000 Project will take the following actions
to meet the Year 2000 readiness requirements:
o Investigate all OSSG software products. NOTE: Retiring
products will be handled on a case-by-case basis to
determine whether they need to be investigated and made
1-2
Introduction
1.2 Overview of the OSSG Year 2000 Project
Year 2000 ready. (For details, see the description of
RETIRED status in Section 3.2.)
o Address problems found by fixing them, documenting them,
or providing enhancements as appropriate.
o Ensure that OSSG can provide Year 2000 ready code for
each OSSG software product by the end of 1997. This
effort applies to the most recent version shipped to
customers (for example, OpenVMS Version 7.1). Fixes
and enhancements should also be backported to previous
versions whenever possible.
o Document our search, correction, and testing techniques
and methodologies to ensure that this information is
captured for possible future audits.
o Document the status of and issues related to all date
/time interfaces, routines, global date/time cells, and
data structures.
o Incorporate Year 2000 awareness in our ongoing processes
to ensure that no Year 2000 problems are introduced in
the future.
The investigations to uncover any Year 2000 problems (or
to ensure that there are no problems) are critical to
the success of the overall project. The results obtained
and methods learned from your investigations will lay the
groundwork for the remaining phases of this project.
To address the due diligence requirement, we ask you to
ensure that the methods and tools you use for your searches
and analyses provide results that are equivalent to the
results that would be obtained from a line-by-line code
review. Each group must determine if the way to achieve
this is by actually conducting a line-by-line inspection
of the code or if other techniques and/or tools can be used
to achieve the same results while easing the search and
analysis effort.
A tool is being planned that would search OpenVMS code for
potential Year 2000 problem areas. However, such a tool
is not necessary to conduct an effective investigation. In
fact, no tool can adequately and sufficiently substitute
for a line-by-line review of the code base. Such a tool can
1-3
Introduction
1.2 Overview of the OSSG Year 2000 Project
point to the most obvious problem modules, but it does not
ensure that other modules can be ignored.
1.3 OSSG Year 2000 Resources
The following resources are available to OSSG personnel
conducting Year 2000 code investigations:
o OSSG Year 2000 team members:
- Karen STAR::MARION (Project Manager) DTN: 381-1455
- Vittorio STAR::MEZZANO (Program Manager) DTN: 381-
2675
- Curt STAR::SPACHT (QTV Project Leader) DTN: 381-0046
- Pat JARETH::NELSON (Documentation Project Leader)
DTN: 381-1415
- Carlos VMSSG::FUERTES (Release Project Leader) DTN:
381-1698
- For other OSSG Y2K contacts, see Note 45 in EVMS::Y2K
(which will be updated as necessary) or consult the
Y2K team member for your group.
o EVMS::Y2K notes conference
Some older notes in this conference may not reflect the
latest policies and approaches adopted by the recently
convened OSSG Year 2000 team. If notes conflict with the
definition of the project as described in this guide,
please follow the guidelines in this document or consult
an OSSG Y2K team member.
o BULOVA::DOCD$:[Y2K] directory
Contains a .PS file of this document (Y2K_
INVESTIGATOR_GUIDE.PS), the report questionnaire (Y2K_
QUESTIONNAIRE.TXT), and a dynamic listing of date/time
related interfaces, routines, global cells, and data
structures (Y2K_INTERFACE_NAMES.LST). Other files of
interest may be added in the future. (Watch for a READ_
ME.TXT file.)
o EVMS::DOCD2$:[Y2K]Y2K_INTERFACE_NAMES.LST
Contains a copy of the Y2K_INTERFACE_NAMES.LST file from
BULOVA for the convenience of local users,
1-4
Introduction
1.3 OSSG Year 2000 Resources
o YEAR-2000 QAR database (see Chapter 4)
o Search tool for OpenVMS software
A search tool is planned, but is not yet available.
1-5
2
_________________________________________________________________
The OSSG Year 2000 Investigation Process
This chapter outlines OSSG's Year 2000 investigation
process, which consists of the following steps:
1. Searching code for date or time related data (see
Section 2.1)
2. Analyzing potential problem areas in code (see
Section 2.2)
3. Testing the system for Year 2000 problems (see
Section 2.3)
4. Documenting your findings (see Section 2.4)
5. Fixing any Year 2000 problems (see Section 2.5)
2.1 Searching Code for Date or Time Related "Hot Spots"
Whenever possible, investigations should be executed by
engineers familiar with the code being reviewed.
Conduct your investigation on the latest version of the
product that shipped to customers. For OpenVMS and its
layered products, this means that all code that runs on
OpenVMS Version 7.1 must be investigated. Some groups may
also decide to investigate older versions of the product
that will still be supported in the Year 2000. If you are
not sure which version of code to investigate, ask your
group's Y2K team member.
Search your code for all instances of date or time related
APIs, structures, global cells, and so forth. Where
feasible, you can use search techniques to help isolate
problem areas in a component. However, such techniques
should not be used at the risk of missing date or time
references that would be caught in a line-by-line visual
inspection.
2-1
The OSSG Year 2000 Investigation Process
2.1 Searching Code for Date or Time Related "Hot Spots"
It is also important to ensure that new code in streams
under development does not introduce Year 2000 errors.
Please help us raise awareness among the engineering
community.
Which Files Should You Investigate?
Because of conditionalizing, .LIS files may not
represent the entirety of your code. Please conduct your
investigation on source files to ensure that all code paths
are covered. However, .LIS files may contain additional
information, such as macro expansions, that is useful
in identifying potential trouble spots in your code. Use
your best judgement about which files to investigate in
order to ensure that OSSG's investigation is as thorough as
possible.
Tips for OpenVMS and Layered Product Investigators
The following information might be helpful for OpenVMS and
layered product investigators:
o Manually, or with a canned procedure, search component
map files for time and date related APIs and global
cells. For completeness, your search should include
the names of all interfaces, routines, global cells,
and data structures having to do with OpenVMS date/time
mechanisms, even if they are Year 2000 safe. This is
necessary because a good date can be turned into a
form that causes an error with year 2000 dates. For
example, a good date can be taken from the system and
be locally converted into an invalid truncated field.
(The EVMS::Y2K notes file contains several examples;
for instance, see the description of a DAP overflow
condition in Note 27.7.)
o A dynamic list of many OpenVMS interfaces, routines,
global cells, and data structures that relate to timing
or dates is posted in the following locations:
- EVMS::Y2K notes conference, Note 6
- BULOVA::DOCD$:[Y2K]Y2K_INTERFACE_NAMES.LST
- EVMS::DOCD2$:[Y2K]Y2K_INTERFACE_NAMES.LST
2-2
The OSSG Year 2000 Investigation Process
2.1 Searching Code for Date or Time Related "Hot Spots"
This list cannot be assumed to be complete, but it may
be useful in getting you started. Keep in mind that,
depending on the nature of the code being reviewed, you
may also need to do a manual search for other APIs and
global cells.
________________________ Help! ________________________
We need your input to make the search list complete.
If your investigations uncover a global cell,
interface name (whether or not it is in the code
you own), or data structure offset that is not in
the posted list, assume it is your responsibility to
report its name for inclusion in the list. Post your
findings in a reply to Note 6. The master list will be
updated and reposted as needed.
______________________________________________________
o We hope to provide a search tool to do multi-name
lookups based on a list of all known date/time related
cells, internal interfaces, system services, macros, and
RTL routines. However, such a tool is not necessary to
conduct an effective investigation.
________________________ Note ________________________
There is no known tool that can adequately substitute
for a line-by-line review of the code. The tool can
identify the most obvious problem modules, but it does
not replace a more careful analysis.
______________________________________________________
2.2 Analyzing Potential Problem Areas in Code
Section 2.1 explains how to search code for time-related
"hot spots." This section tells how to analyze the
potential problem areas that you found.
2-3
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
Steps for Investigators
Following are steps for analyzing possible problem areas:
1. Examine the source code and data flow for time/date APIs
or structures for possible Year 2000 problems.
Watch for the following conditions as well as for any
other time/date conditions that are unique to the code
you are investigating:
o 2-digit representation of year
o Incorrect sequencing of dates
o Invalid date differentials
o Procedures that add or subtract 1900 (or another
hard-coded century value) from the date
o Code that causes incorrect scheduling of system
events
If you think of other conditions that would be helpful
to publish for other investigators, please post them as
a reply to Note 10 in EVMS::Y2K.
2. You might find that you need to make a more detailed
analysis than is immediately apparent. Dates might be
converted to an identity or format that is no longer
obviously a date and passed on to other routines.
3. Make sure that the format of the date/time stamps
outputs unambiguous date data. For example, you might
need to examine the user interface to ensure that the
format can accommodate the 4-digit year.
4. After you analyze code found by searching for known date
/time APIs and data structures, you may need to search
and review the code further.
The OpenVMS Specific Sample of Year 2000 Safe Code section
(later in this chapter) includes a list of questions to use
when you review code.
2-4
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
Criteria for Year 2000 Readiness
Your code is considered year-2000-ready if you have
determined and documented that the code consistently does
the following:
o Contains 4-digit year display fields, user interface,
and report fields
- Uses correct direct and indirect date field sizes
- Accommodates century where appropriate in data entry
o Uses data structures that can handle dates to year 2000
and beyond without causing a data overflow
o Accepts 4-digit year format (field expansion)
- Correctly identifies logic filter (if no expansion is
used)
- Can verify present and future use of processing
filter (if no expansion is used)
o Correctly accepts dates from operating system, sorts
dates, calculates resultant values based on dates, and
passes date formats and values
o Correctly identifies all interface and access data
points
o Correctly handles Year 2000 as a leap year
OpenVMS Specific Sample of Year 2000 Safe Code
Following is an example of time use in a driver that is
Year 2000 safe.
extern unsigned __int64 EXE$GQ_SYSTIME;
unsigned __int64 bin_time; |
bin_time = EXE$GQ_SYSTIME + 100000;
exe_std$instimq((int) (bin_time & 0xffffffff),
(int) ((bin_time >> 32) & 0xffffffff),
(TQE *) &ucb->ucb$l_tqe);
The example does the following:
1. Reads the system time quadword EXE$GQ_SYSTIME and adds
10 milliseconds to it.
2. Tells the system to notify the driver after 10
milliseconds has elapsed.
2-5
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
The Year 2000 is not an issue: the time/date arithmetic
is based on the current time expressed as a binary integer
(which includes a 4-digit year) and a delta time 10ms in
the future; the final result maintains the correct format.
The following table contains questions to answer when you
review code that handles dates and times. The table also
includes sample answers that are based on the example in
this section.
2-6
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
2-7
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
___________________________________________________________
Question____________________________Answer_________________
1 Does your module import time Yes, by reading EXE$GQ_
/date information in any way? SYSTIME
If so, does the year come in Yes
with four digits?
What does your module do with Adds a delta value,
the time/date information? 10ms, to the current
times.
If your code manipulates the Yes
date, does it use all four
digits of the year?
2 Does your code include or Yes, so I reported the
reference a global timing undocumented global
variable or interface that is cell in a reply to Note
not in the list posted in Note 6.
6 in EVMS::Y2K?
3 Do you store a date in any No
data structures, either as
a date string or a binary
integer?
Is the data structure field No data structures
large enough for a 4-digit
year?
4 Does the module export any No
time/date information, either
as a date string or a binary
integer?
Are all four digits of the Nothing exported
year included?
5 Does the module do any time Yes, as noted above,
/date arithmetic? 10ms is added to the
current time.
If so, are 4-digit years used? The full year is
included in EXE$GQ_
SYSTIME and the final
calculation maintains a
____________________________________Y2K-ready_format.______
2-8
The OSSG Year 2000 Investigation Process
2.3 Testing Your Code for Year 2000 Readiness
2.3 Testing Your Code for Year 2000 Readiness
While testing cannot be used as a substitute for
investigating code, you can identify potential Year 2000
problems by testing software in an artificial environment
that simulates future dates.
Many systems, including OpenVMS, allow you to set the
system clock forward to create an appropriate testing
environment. This allows you to check whether days of the
week correctly correlate with dates and to verify that
the year 2000 includes 29 days in February (for example,
January 1 should fall on a Saturday and March 1 should be a
Wednesday).
Note that many system applications and layered products
are affected by any substantial modification of system
time. The following procedure (originally published for
customers) is similar to that used for common maintenance
operations (such as system upgrades) and includes steps
that minimize the side-effects of modifying system time.
1. Remove the system to be tested from the production
environment. This will ensure data integrity during
the test sessions.
2. Check that the installed PAKs will not expire during
the testing period. If your system has temporary PAKs,
contact your application vendor.
3. Perform a complete backup of the system disks.
4. Bring the system to a known, quiescent state. For
example:
a. Reboot the system.
b. Stop all pending batch and print jobs.
c. Stop all background processes that are unrelated to
the testing requirements.
5. Use the SET TIME command to set the system clock date
forward to your testing date. For example, you might set
the date to December 31, 1999, and watch the transition
to January 1, 2000.
2-9
The OSSG Year 2000 Investigation Process
2.3 Testing Your Code for Year 2000 Readiness
6. Initialize and complete tests for your specific
environment. This might involve restarting applications
shut down in the previous step.
7. Bring the system back to a known, quiescent state. For
example:
a. Stop all pending batch and print jobs.
b. Stop all background processes in anticipation of a
system shutdown.
_______________________ Caution _______________________
Setting the system time backwards is dangerous,
because applications might halt and freeze as side-
effects of testing.
______________________________________________________
8. Perform one of the following:
o Reset the system clock to the current time.
o Reboot the system using a conversational SYSBOOT and
set the system parameter SETTIME to 1. This causes
the system to prompt you to enter the system time.
________________________ Note ________________________
The following step is important. It repairs any unseen
effects on layered products and applications that may
have occurred by resetting the system time.
______________________________________________________
9. Restore the system disk.
10.Reboot the system.
You can now restore the system to a production environment.
2.4 Documenting Your Findings
Documenting the findings of your investigation is as
important as the investigation itself for several reasons:
o The process and results of the code investigation for
the entire OSSG inventory must be captured for possible
future audits.
2-10
The OSSG Year 2000 Investigation Process
2.4 Documenting Your Findings
o Customers need to know the status of our code as soon
as possible so that they can scope out the need to make
changes to their own code.
You must submit several types of documentation:
o Report the status of all investigated modules
See Chapter 3 for instructions on filing an
investigation report.
o Report all Year 2000 problems
See Chapter 4 for instructions on filing a QAR for every
Year 2000 problem - no matter how insignificant it may
seem!
o Report undocumented date/time interfaces, routines,
and global cells (see the following OpenVMS Requirement
section)
OpenVMS Requirement
If you find any date/time-related interface, routine,
global cell, etc. that is not listed in the master list in
Note 6 of EVMS::Y2K, please reply to that note and list the
new names with their status (PASS or FAIL), if known. (The
PASS/FAIL statuses are defined in Section 3.2.) Note which
category they belong to (for example, system services,
lexical functions, LIB$ routines, etc.).
The Y2K team will regularly update and repost the master
list as needed in the following locations:
o EVMS::Y2K notes conference, Note 6
o BULOVA::DOCD$:[Y2K]Y2K_INTERFACE_NAMES.LST
o EVMS::DOCD2$:[Y2K]Y2K_INTERFACE_NAMES.LST
_____________________ IMPORTANT! _____________________
Collecting every time and date related name is
critical because Customer Services plans to make a
package of these names available for customers to use
for their own Year 2000 investigations.
Even global cells and routines that handle non-date
oriented timing formats are important for this list
2-11
The OSSG Year 2000 Investigation Process
2.4 Documenting Your Findings
because they help locate "hot spots" in nearby code
that might not otherwise be identified.
______________________________________________________
2.5 Fixing Year 2000 Problems
Whenever possible, the ideal fix is to change any 2-digit
year representation to a 4-digit year representation.
The following guidelines were adapted from a posting by Jim
Kauffman in August 1996 in the EVMS::Y2K notes file:
o Change all 2-digit year fields in data files to 4-digit
year fields. Getting them into the source data files
often prevents ambiguous or inattentive code from later
doing incorrect calculations.
o Convert all output year fields to 4-digit year fields
where possible. This will eliminate many cases
where customers parse our displays to get timestamp
information with truncated years.
________________________ Note ________________________
We must document every such change in release notes
for customers, so be sure to document all such changes
when you check them in.
______________________________________________________
o Replace all "ad hoc" date and/or time calculations or
conversions with OpenVMS system or RTL calls. OpenVMS
calls either deal with only 4-digit years or abide by
the default system sliding window range for 2-digit
interpretation. Any RTL calls that have problems now
will either be fixed or will have a Year 2000 safe
interface in time for the Year 2000 readiness release.
For OpenVMS Alpha, use the global cell EXE$GL_
TRANSITION_YEAR, where appropriate, or wait for
some anticipated system services that will allow
nonprivileged access to the global cell.
2-12
The OSSG Year 2000 Investigation Process
2.5 Fixing Year 2000 Problems
OpenVMS Checkins
Year 2000 code fixes and enhancements should be checked
into the Y2K streams on STAR (for VAX) and EVMS (for
Alpha). Please use the SCT template in Note 2 of the
SCT-Y2K notes conference. Note that the VAX and Alpha
conferences have the same name, but reside on STAR and
EVMS, respectively. (The template is also available at
VMSCMS$:SCT$Y2K.TEMPLATE on the EVMS cluster.)
2-13
3
_________________________________________________________________
Filling Out the OSSG Year 2000 Investigation Report
Read and follow the guidelines for code investigations in
Chapter 2 before filling out the investigation report.
You can copy the report questionnaire from the following
locations:
o BULOVA::DOCD$:[Y2K]Y2K_QUESTIONNAIRE.TXT
o Note 5 in the EVMS::Y2K notes file
3.1 Instructions
Please read the following instructions as you fill out
the report questionnaire. A sample filled-in questionnaire
follows these instructions.
___________________ IMPORTANT NOTE ___________________
We plan to design a tool to automatically read and
tabulate the data in this questionnaire, so please
follow the instructions carefully. Please do not
delete questions or wrap lines in the table.
If you have questions, consult the Y2K team member for
your group. (See Note 45 in EVMS::Y2K for the current
list of team members.)
______________________________________________________
Question 3
Enter the name of the Y2K team member for your group.
3-1
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
Question 4
Investigate the code for the latest version of the product
that shipped to customers. For OpenVMS and its layered
products, this means that all code that runs on OpenVMS
Version 7.1 must be investigated. If you are not sure which
version to investigate, ask the Y2K team member for your
group.
If your product ships on different architectures, also
specify the architecture investigated. For OpenVMS, specify
OpenVMS VAX V7.1 and/or OpenVMS Alpha V7.1.
If common code is used for multiple architectures, you can
file a single report that specifies both architectures.
If conditionals, such as IFDEFS, are used in common code,
and no problems are found inside the conditionals, you can
still file a single report. However, if there are problems,
file separate reports for each architecture. Also file
separate reports for each architecture if they do not share
common code.
Question 5
If your report does not cover an entire product, specify
the component(s) included in your report; for example,
SECURITY or BUGCHECK. (In some cases, the same component
may be covered in multiple reports.)
Question 6
Read the instructions that follow this example before
filling in each field. All data for one entry must be on
one line. The template suggests a tabbed format, but you
can adjust it as necessary. If you have long module names,
you may have to use a 132-column format.
_____________________ IMPORTANT! _____________________
Enter only the requested data in this template. If
you have comments, enter them in Question 10. The
mechanical search tool cannot interpret extra fields
in this template.
______________________________________________________
3-2
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
Facility Interface or
Name Module Name Status Routine Name I/R/G QAR #s
---------------------------------------------------------------------------------
FACILITY-X MODULE1 N/A
MODULE2 PASS INTERFACE1 I
FAIL ROUTINE1 R 141
FACILITY-Y MODULE3 PASS INTERFACE2 I
PASS GLOBAL1 G
PASS DATASTRUCT1 G
FAIL INTERFACE3 I 142,143
MODULE4 RETIRED
MODULE5 DEPENDS
o Facility name
Specify the facility name, if relevant. Otherwise,
specify the component name.
o Module name
To ensure the completeness of our investigation, specify
the full name of each source module investigated. Do not
use wildcards!
o Status
Refer to Section 3.2 for definitions of the allowable
status values.
If a module is N/A, DEPENDS, or RETIRED, enter the
module status here. Enter any dependencies in Question
7.
If a module contains a date/time interface or a routine
that incorrectly uses a date/time interface, we must
document its investigation. Enter the status for the
interface or routine that you report on this line.
o Interface, routine, global cell, or data structure name
If a module contains code for an interface that
imports or exports date or time data or a routine that
incorrectly uses a date/time interface, enter the full
name of the interface or routine. Do not use wildcards!
3-3
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
Please use the most common name for the interface or
routine. If it has any aliases, enter them in Question
8. You need not document internal routines that do not
export any date/time data.
If the module defines or creates a time/date-related
global variable or data structure offset, list it here.
If one module contains more than one date/time interface
or routine that must be documented, enter a separate
line for each (as shown in the example).
If you document an OpenVMS date/time interface or
routine, check Note 6 of EVMS::Y2K for the following:
o Is the interface, routine, global cell, or data
structure offset included in the master list in Note
6?
o Is the status (PASS/FAIL) listed? Is it listed
correctly?
If you have a name or status to add or correct in the
list, please reply to Note 6 (as described under OpenVMS
Requirement in Section 2.4).
o I/R/G
The Year 2000 documentation must differentiate between
date/time interfaces, routines, and global cells:
- I = This line reports a programming or a user
interface.
- R = This line reports an internal routine with an
incorrect date calculation.
- G = This line reports a date/time related global cell
or data structure offset.
o YEAR-2000 QAR database numbers
Every Year 2000 problem must be reported in the YEAR-
2000 QAR database. (Layered products should submit QARs
through Sue STAR::AVERY. See Chapter 4 for details.)
For every interface or routine with FAIL status, enter
the number(s) of all YEAR-2000 QARs. Use a comma to
separate multiple QAR numbers.
3-4
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
________________________ Note ________________________
See Chapter 4 for a list of questions that must
be addressed when you file a QAR in the YEAR-2000
database.
______________________________________________________
Question 7
For every module listed in Question 6 with DEPENDS status,
list the dependencies and their status (FAIL or UNK, for
unknown) as shown in the following example:
Module Name Dependencies
-----------------------------------------------------------
MODULE5 INTERFACE4=UNK, INTERFACE5=FAIL
Question 8
If any of the interfaces or routines listed in Question 6
can be referenced by alternate names, list them as shown in
the following example:
Interface or
Routine Name Aliases
-----------------------------------------------------------
EXE$GETTIM SYS$GETTIM, $GETTIM, $GETTIM_S, $GETTIM_G
List all names by which a timing interface can be called
externally (even by privileged users). Include all high-
level language routines as well as all forms of system
service calling names.
Question 10
If any of your modules use a date/time global cell, please
list the cell names here. Also reply to Note 6 in EVMS::Y2K
if you find global cell names that are not already listed
there. If you have comments for the Y2K team that were
not captured by other questions in this report, also enter
those here. If you have information to share with others
about the investigation techniques you used, you can either
post a reply to EVMS::Y2K Note 10 or include them here.
3-5
Filling Out the OSSG Year 2000 Investigation Report
3.2 Year 2000 Status Definitions
3.2 Year 2000 Status Definitions
You must classify all modules, date/time interfaces, and
routines that use date/time interfaces by specifying one of
the following status designators:
o N/A
o PASS
o DEPENDS
o FAIL
o RETIRED
Each status is fully defined in the following sections.
N/A: No Date/Time Data
Code does not contain or manipulate date or time data.
PASS: Ready for the Year 2000
Code meets the following requirements:
o Code will continue to function as the date changes from
December 31, 1999 to January 1, 2000, and well beyond
that, without intervention.
o All date calculations, representations, and translations
are correct for any date data within the supported date
range.
o The code provides 4-digit year interfaces and APIs.
o For 2-digit year representations, the code meets one
of the following requirements and is already fully
documented:
- Interprets the value of a fixed or variable offset to
determine whether a 2-digit year belongs to the 20th
or 21st century. (For example, OpenVMS Alpha uses the
system global cell EXE$GL_TRANSITION_YEAR.)
- Includes an encoding and decoding mechanism that
allows unique and unambiguous representation of years
over a range that spans the latter portion of the
20th century and extends well into the 21st century.
3-6
Filling Out the OSSG Year 2000 Investigation Report
3.2 Year 2000 Status Definitions
o Correctly processes, calculates, compares, and
sequences date data within and between the 20th and
21st centuries, including leap year calculations, when
used in a supported manner.
DEPENDS: Readiness Depends Upon External Code
The code in itself is rated PASS, but it calls an interface
or routine whose status is not yet documented as PASS or
FAIL in the list in Note 6.
The Year 2000 team will attempt to coordinate testing
so that the status of dependencies is publicly available
before dependent code is tested. For example, the following
commonly used interfaces and global cells have been
investigated and found to be Year 2000 ready:
o $ASCTIM
o $BINTIM
o $GETTIM
o $NUMTIM
o $SCHDWK
o $SETIME
o $SETIMR
o EXE$GL_ABSTIM
o EXE$GQ_SYSTIME
If your code is Year 2000 ready and calls nothing other
than what's listed above (or an alias), your code qualifies
as PASS.
FAIL: Not Ready for the Year 2000
Code must be classified as FAIL if ANY of the following
conditions apply:
o Software uses an interface or routine whose Year 2000
status is FAIL.
o Code contains Year 2000 limitations or restrictions such
as the following:
- There are minor limitations or restrictions, which
may or may not already be publicly documented.
3-7
Filling Out the OSSG Year 2000 Investigation Report
3.2 Year 2000 Status Definitions
- The code returns a 2-digit year.
- The code uses 2-digit years (even if it is Year 2000
safe), but this usage is not yet fully documented.
- Calculation errors are possible under certain
circumstances.
- Catastrophic problems could occur because the
software does not function properly with date data
beyond December 31, 1999 - or, in some cases, even
earlier. Code should not be used in an environment
that requires correct handling of dates between now
and January 2000.
RETIRED
*** Read this carefully! ***
The component is retired/unsupported or will be retired
/unsupported as of January 1, 1999 -AND- your product
manager has explicitly stated that the code need not be
investigated. Questions about whether a retiring product
should be investigated should be directed to Vittorio
STAR::MEZZANO.
If you do investigate code for components that are slated
for retirement, specify N/A, PASS, DEPENDS, or FAIL for
that code.
___________________ Notify Y2K Team ___________________
For all products slated for retirement, please notify
Vittorio STAR::MEZZANO and Pat JARETH::NELSON of the
expected retirement date so that customers can be
informed. Specify whether or not the code is being
investigated.
______________________________________________________
3-8
Filling Out the OSSG Year 2000 Investigation Report
3.3 Sample Year 2000 Investigation Report
3.3 Sample Year 2000 Investigation Report
Subj: PASS, LMF V1.2 on OpenVMS Alpha and VAX, LMF
Year 2000 Investigation Report
Please follow instructions in Chapter 3 of the OSSG Year 2000
Investigator's Guide when filling out this questionnaire. Your
cooperation is critical to the success of this project. Thank you!
1. Your nodename::username: EVMS::ANONYMOUS
2. Your 7-digit DTN: 381-6354
3. The Y2K contact person for your group: Chris Petrovic
4. Product (including architecture) and version: LMF V1.2 for
OpenVMS Alpha
and VAX
5. Component(s): LMF
6. Inventory (See the Investigator's Guide for instructions.)
3-9
Filling Out the OSSG Year 2000 Investigation Report
3.3 Sample Year 2000 Investigation Report
Facility Interface or
Name Module Name Status Routine Name I/R/G QAR #s
--------------------------------------------------------------------------------
LIB PCBDEF.SDL pass pcb$l_quantum G
LMF CHECKRECORD.B32 n/a
LMF CREATE.B32 pass
LMF ISSUE.B32 pass
LMF LICENSE_CHECK.B32 pass
LMF LICENSE_CHECK_DATA.B32 retired
LMF LIST.B32 pass
LMF LISTMSG.MSG n/a
LMF LMF$CHECKSUM.B32 n/a
LMF LMF$CHECKSUM_MSG.MSG n/a
LMF LMF$GROUP_TABLE.B32 pass
LMF LMF$PURDY.MAR n/a
LMF LMFMAIN.B32 pass
LMF LMFMSG.MSG n/a
LMF LMF_MOVE.B32 pass
LMF LOAD.B32 pass
LMF MAKE_SMM.B32 pass
LMF RABFABERR.B32 n/a
LMF UPDATE.B32 pass
LMF SHOW_CHARGEMSG.MSG n/a
LMF SMM_MSG.MSG n/a
LMF START.B32 n/a
MANAGE LMF$LICENSE.COM pass
MANAGE LMF$LICENSE_LANGUAGE.COM n/a
MANAGE SYSMANLICENSE.B32 n/a
CLD LMF.CLD pass
SYS SYSLICENSE.MAR pass sys$grant_license I
SYS SYSLOOKUP_LICENSE.B32 pass sys$lookup_license I
SYS SYSLOOKUP_LICENSE64.B32 n/a
SYS SYSTEM_DATA_CELLS.MAR pass exe$gq_systime G
CLIUTL SHOWLICENSE.B32 pass
7. Status of module dependencies:
Module Name Dependencies
-----------------------------------------------------------
3-10
Filling Out the OSSG Year 2000 Investigation Report
3.3 Sample Year 2000 Investigation Report
8. Aliases for interfaces and routines listed in your inventory
above (if applicable)
Interface or
Routine Name Aliases
-----------------------------------------------------------
9. What investigation and testing techniques did you use?
For each technique that you used in this list, replace the "o"
that precedes it with an "X". If you mark "Other", please start
your description after the colon (:).
X Visual scan of code
X Mechanical search of code
X Tested the interfaces during a rollover to year 2000
X Other (please describe): Knowledge of design so knew
where dates are used.
10. (Optional) Comments:
- sys$grant_license and sys$lookup_license are undocumented
system services
Send this report from your personal account to JARETH::Y2K with
the following information in the Mail subject line:
Subj: Status, Product name (incl. architecture), Facility or
component name
For "Status" enter the status associated with the first true
statement in this list:
o This report contains at least one FAIL status.
o This report contains at least one DEPENDS status.
o This report contains at least one PASS status.
o This report contains at least one RETIRED status.
o This report contains only N/A statuses.
3-11
4
_________________________________________________________________
Reporting OSSG Year 2000 Problems
The YEAR-2000 QAR database has been created to track
problems exclusively related to Year 2000 issues. Do not
file any other problem reports in this database.
If your project team tracks problem reports locally (for
example, PATHWORKS Client), send a copy of each report to
Sue STAR::AVERY, our OpenVMS layered product coordinator.
Sue will track these problems for us so that all OSSG Year
2000 problems can be monitored from a central QAR database.
4.1 Filing a YEAR-2000 QAR Report
File a QAR in the YEAR-2000 database for every problem
related to the Year 2000 issue. The following sections
detail the information needed in each part of a YEAR-
2000 QAR. A sample filled in QAR report follows the
instructions.
_________________ Template Available _________________
For your convenience, an optional QAR template that
includes fields for the required information is posted
as a reply to Note 5 in EVMS::Y2K.
______________________________________________________
Severity Level
When assigning severity levels for a YEAR-2000 QAR, use the
following guidelines:
o Showstopper
Catastrophic Year 2000 bug. For example, data is
corrupted or the system hangs or crashes.
4-1
Reporting OSSG Year 2000 Problems
4.1 Filing a YEAR-2000 QAR Report
o High
Noncompliant date/time interface, routine, global cell,
or data structure with no available Year 2000 ready
substitute
o Medium
Noncompliant date/time interface, routine, global cell,
or data structure with an available Year 2000 ready
substitute
o Low
Minor problem that can easily be fixed or documented
QAR Abstract
Include the following information in the abstract for each
YEAR-2000 QAR:
o Product
o Architecture
o Version investigated
Problem Report
Include the following in the problem report:
o Describe the problem.
o List the names of all date/time interfaces, routines,
global cells, and data structures.
o On what date does the code fail?
- On or before May 19, 1997
- On or before January 1, 2000
- On or before January 1, 2038
- After January 1, 2038 (please specify):
o Specify all timing formats used in the code.
o Documentation requirements
We must document all Year 2000 problems found in shipped
code as well as all changes that we make to shipped
code, no matter how trivial. For example, if you change
any 2-digit year displays to 4-digit year displays,
please specify what has changed.
4-2
Reporting OSSG Year 2000 Problems
4.1 Filing a YEAR-2000 QAR Report
Please also answer the following questions:
- Is there any reason why this interface should not be
documented for customers and third parties?
- Is there existing documentation that should be
modified (with either corrections or additions)?
If possible, list manual title, chapter or page, type
of change, etc.
- Will the Year 2000 problem or its fix require new
documentation? If so, specify the scope and audience
(internal or customers) of required documentation.
- If applicable, include a summary of the release
note.
Answer
Include the following information in the answer to the
problem:
o Describe the proposed fix for this problem.
Is a code fix or enhancement required, or can the
problem be resolved by a workaround or adequate
documentation?
o If you do not expect the code to ever meet Year 2000
readiness requirements, please explain.
For example, if the problem cannot be totally fixed
because our code must conform to certain coding
standards or other restrictions, please note the
standard or restriction. Is it an internal or external
restriction? (Example: DAP protocol) Is there a
workaround that can make the interface Year 2000 ready?
o Is it feasible to backport this fix? If so, to what
version? If not, what are the restrictions?
o Is your fix included in a patch kit? If so, please list
the patch kit number(s) if you know them.
4-3
Reporting OSSG Year 2000 Problems
4.2 Sample YEAR-2000 QAR Report
4.2 Sample YEAR-2000 QAR Report
TBS
4-4
|
|
____________________________________________________
OSSG Year 2000
Investigator's Guide
February 17, 1997
This handbook provides guidelines for investigating
code for Year 2000 readiness and describes the forms
that must be used to report investigation findings.
________________________ Note ________________________
This document and the report questionnaire are posted
in Note 5 in the EVMS::Y2K notes conference (.TXT) and
in the BULOVA::DOCD$:[Y2K] directory (.PS).
______________________________________________________
*** DIGITAL CONFIDENTIAL ***
_________________________________________________________________
Contents
1 Introduction
1.1 Overview of this Document..................... 1-1
1.2 Overview of the OSSG Year 2000 Project........ 1-1
1.3 OSSG Year 2000 Resources...................... 1-4
2 The OSSG Year 2000 Investigation Process
2.1 Searching Code for Date or Time Related "Hot
Spots"........................................ 2-1
2.2 Analyzing Potential Problem Areas in Code .... 2-3
2.3 Testing Your Code for Year 2000 Readiness..... 2-9
2.4 Documenting Your Findings .................... 2-10
2.5 Fixing Year 2000 Problems .................... 2-12
3 Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions.................................. 3-1
3.2 Year 2000 Status Definitions.................. 3-6
3.3 Sample Year 2000 Investigation Report ........ 3-9
4 Reporting OSSG Year 2000 Problems
4.1 Filing a YEAR-2000 QAR Report................. 4-1
4.2 Sample YEAR-2000 QAR Report................... 4-4
iii
1
_________________________________________________________________
Introduction
1.1 Overview of this Document
This document covers the following topics:
o Introduction (Chapter 1)
Provides an overview of the OSSG Year 2000 project and
the resources available.
o Year 2000 Investigation Process (Chapter 2)
Describes what to look for in your investigations or
testing and suggests the kinds of fixes to make.
o Filling Out the Investigation Report (Chapter 3)
Explains how to fill out a report for the code you
investigate.
o Reporting Year 2000 Problems (Chapter 4)
Lists the information that you must provide when filing
a problem report for a Year 2000 problem.
This document is available in the following locations:
o BULOVA::DOCD$:[Y2K]Y2K_INVESTIGATOR_GUIDE.PS
o EVMS::Y2K notes conference, Note 5 (.TXT format)
1.2 Overview of the OSSG Year 2000 Project
The major objective of the OSSG Year 2000 Project is to
ensure that customers can count on our software to work
in a predictable and correct manner into the Year 2000 and
beyond.
Customers also need to know the status of our code as soon
as possible so that they can scope out the need to make any
changes in their own code.
1-1
Introduction
1.2 Overview of the OSSG Year 2000 Project
The major concern behind the so-called "Year 2000 problem"
is the representation of years with only two digits instead
of four (for example, "96" instead of "1996"). Use of 2-
digit year representations can cause application problems
during the transition to the year 2000. It can result
in processing errors, especially in cases of sorting,
comparison, and arithmetic operation.
The major requirements that the OSSG Year 2000 Project is
addressing are the following:
o Timely availability of Year 2000 ready products,
including hardware, system software, and layered
products
Many customers need our products to be Year 2000 ready
by the end of 1997 to allow them adequate time to test
and correct their own software during 1998 and put their
Year 2000 ready applications into production during
1999.
o Support and information on the status of installed
products
Customers want to know the state of our products in
terms of Year 2000 readiness. They also want to know the
techniques and methodologies used to find, correct, and
test problems.
o The emerging legal and contractual requirements around
the Year 2000 issue mandate a "Due Diligence" approach
and analysis of our products. For example, in order
to do business with the U.S. government, Digital must
conduct an investigation and document our level of Year
2000 readiness.
For the OSSG Year 2000 Project, due diligence means
that we will do our best to make sure that information
technology environments using our software will continue
to work without problems through the Year 2000 and
beyond.
The OSSG Year 2000 Project will take the following actions
to meet the Year 2000 readiness requirements:
o Investigate all OSSG software products. NOTE: Retiring
products will be handled on a case-by-case basis to
determine whether they need to be investigated and made
1-2
Introduction
1.2 Overview of the OSSG Year 2000 Project
Year 2000 ready. (For details, see the description of
RETIRED status in Section 3.2.)
o Address problems found by fixing them, documenting them,
or providing enhancements as appropriate.
o Ensure that OSSG can provide Year 2000 ready code for
each OSSG software product by the end of 1997. This
effort applies to the most recent version shipped to
customers (for example, OpenVMS Version 7.1). Fixes
and enhancements should also be backported to previous
versions whenever possible.
o Document our search, correction, and testing techniques
and methodologies to ensure that this information is
captured for possible future audits.
o Document the status of and issues related to all date
/time interfaces, routines, global date/time cells, and
data structures.
o Incorporate Year 2000 awareness in our ongoing processes
to ensure that no Year 2000 problems are introduced in
the future.
The investigations to uncover any Year 2000 problems (or
to ensure that there are no problems) are critical to
the success of the overall project. The results obtained
and methods learned from your investigations will lay the
groundwork for the remaining phases of this project.
To address the due diligence requirement, we ask you to
ensure that the methods and tools you use for your searches
and analyses provide results that are equivalent to the
results that would be obtained from a line-by-line code
review. Each group must determine if the way to achieve
this is by actually conducting a line-by-line inspection
of the code or if other techniques and/or tools can be used
to achieve the same results while easing the search and
analysis effort.
A tool is being planned that would search OpenVMS code for
potential Year 2000 problem areas. However, such a tool
is not necessary to conduct an effective investigation. In
fact, no tool can adequately and sufficiently substitute
for a line-by-line review of the code base. Such a tool can
1-3
Introduction
1.2 Overview of the OSSG Year 2000 Project
point to the most obvious problem modules, but it does not
ensure that other modules can be ignored.
1.3 OSSG Year 2000 Resources
The following resources are available to OSSG personnel
conducting Year 2000 code investigations:
o OSSG Year 2000 team members:
- Karen STAR::MARION (Project Manager) DTN: 381-1455
- Vittorio STAR::MEZZANO (Program Manager) DTN: 381-
2675
- Curt STAR::SPACHT (QTV Project Leader) DTN: 381-0046
- Pat JARETH::NELSON (Documentation Project Leader)
DTN: 381-1415
- Carlos VMSSG::FUERTES (Release Project Leader) DTN:
381-1698
- For other OSSG Y2K contacts, see Note 45 in EVMS::Y2K
(which will be updated as necessary) or consult the
Y2K team member for your group.
o EVMS::Y2K notes conference
Some older notes in this conference may not reflect the
latest policies and approaches adopted by the recently
convened OSSG Year 2000 team. If notes conflict with the
definition of the project as described in this guide,
please follow the guidelines in this document or consult
an OSSG Y2K team member.
o BULOVA::DOCD$:[Y2K] directory
Contains a .PS file of this document (Y2K_
INVESTIGATOR_GUIDE.PS), the report questionnaire (Y2K_
QUESTIONNAIRE.TXT), and a dynamic listing of date/time
related interfaces, routines, global cells, and data
structures (Y2K_INTERFACE_NAMES.LST). Other files of
interest may be added in the future. (Watch for a READ_
ME.TXT file.)
o EVMS::DOCD2$:[Y2K]Y2K_INTERFACE_NAMES.LST
Contains a copy of the Y2K_INTERFACE_NAMES.LST file from
BULOVA for the convenience of local users,
1-4
Introduction
1.3 OSSG Year 2000 Resources
o YEAR-2000 QAR database (see Chapter 4)
o Search tool for OpenVMS software
A search tool is planned, but is not yet available.
1-5
2
_________________________________________________________________
The OSSG Year 2000 Investigation Process
This chapter outlines OSSG's Year 2000 investigation
process, which consists of the following steps:
1. Searching code for date or time related data (see
Section 2.1)
2. Analyzing potential problem areas in code (see
Section 2.2)
3. Testing the system for Year 2000 problems (see
Section 2.3)
4. Documenting your findings (see Section 2.4)
5. Fixing any Year 2000 problems (see Section 2.5)
2.1 Searching Code for Date or Time Related "Hot Spots"
Whenever possible, investigations should be executed by
engineers familiar with the code being reviewed.
Conduct your investigation on the latest version of the
product that shipped to customers. For OpenVMS and its
layered products, this means that all code that runs on
OpenVMS Version 7.1 must be investigated. Some groups may
also decide to investigate older versions of the product
that will still be supported in the Year 2000. If you are
not sure which version of code to investigate, ask your
group's Y2K team member.
Search your code for all instances of date or time related
APIs, structures, global cells, and so forth. Where
feasible, you can use search techniques to help isolate
problem areas in a component. However, such techniques
should not be used at the risk of missing date or time
references that would be caught in a line-by-line visual
inspection.
2-1
The OSSG Year 2000 Investigation Process
2.1 Searching Code for Date or Time Related "Hot Spots"
It is also important to ensure that new code in streams
under development does not introduce Year 2000 errors.
Please help us raise awareness among the engineering
community.
Which Files Should You Investigate?
Because of conditionalizing, .LIS files may not
represent the entirety of your code. Please conduct your
investigation on source files to ensure that all code paths
are covered. However, .LIS files may contain additional
information, such as macro expansions, that is useful
in identifying potential trouble spots in your code. Use
your best judgement about which files to investigate in
order to ensure that OSSG's investigation is as thorough as
possible.
Tips for OpenVMS and Layered Product Investigators
The following information might be helpful for OpenVMS and
layered product investigators:
o Manually, or with a canned procedure, search component
map files for time and date related APIs and global
cells. For completeness, your search should include
the names of all interfaces, routines, global cells,
and data structures having to do with OpenVMS date/time
mechanisms, even if they are Year 2000 safe. This is
necessary because a good date can be turned into a
form that causes an error with year 2000 dates. For
example, a good date can be taken from the system and
be locally converted into an invalid truncated field.
(The EVMS::Y2K notes file contains several examples;
for instance, see the description of a DAP overflow
condition in Note 27.7.)
o A dynamic list of many OpenVMS interfaces, routines,
global cells, and data structures that relate to timing
or dates is posted in the following locations:
- EVMS::Y2K notes conference, Note 6
- BULOVA::DOCD$:[Y2K]Y2K_INTERFACE_NAMES.LST
- EVMS::DOCD2$:[Y2K]Y2K_INTERFACE_NAMES.LST
2-2
The OSSG Year 2000 Investigation Process
2.1 Searching Code for Date or Time Related "Hot Spots"
This list cannot be assumed to be complete, but it may
be useful in getting you started. Keep in mind that,
depending on the nature of the code being reviewed, you
may also need to do a manual search for other APIs and
global cells.
________________________ Help! ________________________
We need your input to make the search list complete.
If your investigations uncover a global cell,
interface name (whether or not it is in the code
you own), or data structure offset that is not in
the posted list, assume it is your responsibility to
report its name for inclusion in the list. Post your
findings in a reply to Note 6. The master list will be
updated and reposted as needed.
______________________________________________________
o We hope to provide a search tool to do multi-name
lookups based on a list of all known date/time related
cells, internal interfaces, system services, macros, and
RTL routines. However, such a tool is not necessary to
conduct an effective investigation.
________________________ Note ________________________
There is no known tool that can adequately substitute
for a line-by-line review of the code. The tool can
identify the most obvious problem modules, but it does
not replace a more careful analysis.
______________________________________________________
2.2 Analyzing Potential Problem Areas in Code
Section 2.1 explains how to search code for time-related
"hot spots." This section tells how to analyze the
potential problem areas that you found.
2-3
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
Steps for Investigators
Following are steps for analyzing possible problem areas:
1. Examine the source code and data flow for time/date APIs
or structures for possible Year 2000 problems.
Watch for the following conditions as well as for any
other time/date conditions that are unique to the code
you are investigating:
o 2-digit representation of year
o Incorrect sequencing of dates
o Invalid date differentials
o Procedures that add or subtract 1900 (or another
hard-coded century value) from the date
o Code that causes incorrect scheduling of system
events
If you think of other conditions that would be helpful
to publish for other investigators, please post them as
a reply to Note 10 in EVMS::Y2K.
2. You might find that you need to make a more detailed
analysis than is immediately apparent. Dates might be
converted to an identity or format that is no longer
obviously a date and passed on to other routines.
3. Make sure that the format of the date/time stamps
outputs unambiguous date data. For example, you might
need to examine the user interface to ensure that the
format can accommodate the 4-digit year.
4. After you analyze code found by searching for known date
/time APIs and data structures, you may need to search
and review the code further.
The OpenVMS Specific Sample of Year 2000 Safe Code section
(later in this chapter) includes a list of questions to use
when you review code.
2-4
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
Criteria for Year 2000 Readiness
Your code is considered year-2000-ready if you have
determined and documented that the code consistently does
the following:
o Contains 4-digit year display fields, user interface,
and report fields
- Uses correct direct and indirect date field sizes
- Accommodates century where appropriate in data entry
o Uses data structures that can handle dates to year 2000
and beyond without causing a data overflow
o Accepts 4-digit year format (field expansion)
- Correctly identifies logic filter (if no expansion is
used)
- Can verify present and future use of processing
filter (if no expansion is used)
o Correctly accepts dates from operating system, sorts
dates, calculates resultant values based on dates, and
passes date formats and values
o Correctly identifies all interface and access data
points
o Correctly handles Year 2000 as a leap year
OpenVMS Specific Sample of Year 2000 Safe Code
Following is an example of time use in a driver that is
Year 2000 safe.
extern unsigned __int64 EXE$GQ_SYSTIME;
unsigned __int64 bin_time; |
bin_time = EXE$GQ_SYSTIME + 100000;
exe_std$instimq((int) (bin_time & 0xffffffff),
(int) ((bin_time >> 32) & 0xffffffff),
(TQE *) &ucb->ucb$l_tqe);
The example does the following:
1. Reads the system time quadword EXE$GQ_SYSTIME and adds
10 milliseconds to it.
2. Tells the system to notify the driver after 10
milliseconds has elapsed.
2-5
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
The Year 2000 is not an issue: the time/date arithmetic
is based on the current time expressed as a binary integer
(which includes a 4-digit year) and a delta time 10ms in
the future; the final result maintains the correct format.
The following table contains questions to answer when you
review code that handles dates and times. The table also
includes sample answers that are based on the example in
this section.
2-6
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
2-7
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
___________________________________________________________
Question____________________________Answer_________________
1 Does your module import time Yes, by reading EXE$GQ_
/date information in any way? SYSTIME
If so, does the year come in Yes
with four digits?
What does your module do with Adds a delta value,
the time/date information? 10ms, to the current
times.
If your code manipulates the Yes
date, does it use all four
digits of the year?
2 Does your code include or Yes, so I reported the
reference a global timing undocumented global
variable or interface that is cell in a reply to Note
not in the list posted in Note 6.
6 in EVMS::Y2K?
3 Do you store a date in any No
data structures, either as
a date string or a binary
integer?
Is the data structure field No data structures
large enough for a 4-digit
year?
4 Does the module export any No
time/date information, either
as a date string or a binary
integer?
Are all four digits of the Nothing exported
year included?
5 Does the module do any time Yes, as noted above,
/date arithmetic? 10ms is added to the
current time.
If so, are 4-digit years used? The full year is
included in EXE$GQ_
SYSTIME and the final
calculation maintains a
____________________________________Y2K-ready_format.______
2-8
The OSSG Year 2000 Investigation Process
2.3 Testing Your Code for Year 2000 Readiness
2.3 Testing Your Code for Year 2000 Readiness
While testing cannot be used as a substitute for
investigating code, you can identify potential Year 2000
problems by testing software in an artificial environment
that simulates future dates.
Many systems, including OpenVMS, allow you to set the
system clock forward to create an appropriate testing
environment. This allows you to check whether days of the
week correctly correlate with dates and to verify that
the year 2000 includes 29 days in February (for example,
January 1 should fall on a Saturday and March 1 should be a
Wednesday).
Note that many system applications and layered products
are affected by any substantial modification of system
time. The following procedure (originally published for
customers) is similar to that used for common maintenance
operations (such as system upgrades) and includes steps
that minimize the side-effects of modifying system time.
1. Remove the system to be tested from the production
environment. This will ensure data integrity during
the test sessions.
2. Check that the installed PAKs will not expire during
the testing period. If your system has temporary PAKs,
contact your application vendor.
3. Perform a complete backup of the system disks.
4. Bring the system to a known, quiescent state. For
example:
a. Reboot the system.
b. Stop all pending batch and print jobs.
c. Stop all background processes that are unrelated to
the testing requirements.
5. Use the SET TIME command to set the system clock date
forward to your testing date. For example, you might set
the date to December 31, 1999, and watch the transition
to January 1, 2000.
2-9
The OSSG Year 2000 Investigation Process
2.3 Testing Your Code for Year 2000 Readiness
6. Initialize and complete tests for your specific
environment. This might involve restarting applications
shut down in the previous step.
7. Bring the system back to a known, quiescent state. For
example:
a. Stop all pending batch and print jobs.
b. Stop all background processes in anticipation of a
system shutdown.
_______________________ Caution _______________________
Setting the system time backwards is dangerous,
because applications might halt and freeze as side-
effects of testing.
______________________________________________________
8. Perform one of the following:
o Reset the system clock to the current time.
o Reboot the system using a conversational SYSBOOT and
set the system parameter SETTIME to 1. This causes
the system to prompt you to enter the system time.
________________________ Note ________________________
The following step is important. It repairs any unseen
effects on layered products and applications that may
have occurred by resetting the system time.
______________________________________________________
9. Restore the system disk.
10.Reboot the system.
You can now restore the system to a production environment.
2.4 Documenting Your Findings
Documenting the findings of your investigation is as
important as the investigation itself for several reasons:
o The process and results of the code investigation for
the entire OSSG inventory must be captured for possible
future audits.
2-10
The OSSG Year 2000 Investigation Process
2.4 Documenting Your Findings
o Customers need to know the status of our code as soon
as possible so that they can scope out the need to make
changes to their own code.
You must submit several types of documentation:
o Report the status of all investigated modules
See Chapter 3 for instructions on filing an
investigation report.
o Report all Year 2000 problems
See Chapter 4 for instructions on filing a QAR for every
Year 2000 problem - no matter how insignificant it may
seem!
o Report undocumented date/time interfaces, routines,
and global cells (see the following OpenVMS Requirement
section)
OpenVMS Requirement
If you find any date/time-related interface, routine,
global cell, etc. that is not listed in the master list in
Note 6 of EVMS::Y2K, please reply to that note and list the
new names with their status (PASS or FAIL), if known. (The
PASS/FAIL statuses are defined in Section 3.2.) Note which
category they belong to (for example, system services,
lexical functions, LIB$ routines, etc.).
The Y2K team will regularly update and repost the master
list as needed in the following locations:
o EVMS::Y2K notes conference, Note 6
o BULOVA::DOCD$:[Y2K]Y2K_INTERFACE_NAMES.LST
o EVMS::DOCD2$:[Y2K]Y2K_INTERFACE_NAMES.LST
_____________________ IMPORTANT! _____________________
Collecting every time and date related name is
critical because Customer Services plans to make a
package of these names available for customers to use
for their own Year 2000 investigations.
Even global cells and routines that handle non-date
oriented timing formats are important for this list
2-11
The OSSG Year 2000 Investigation Process
2.4 Documenting Your Findings
because they help locate "hot spots" in nearby code
that might not otherwise be identified.
______________________________________________________
2.5 Fixing Year 2000 Problems
Whenever possible, the ideal fix is to change any 2-digit
year representation to a 4-digit year representation.
The following guidelines were adapted from a posting by Jim
Kauffman in August 1996 in the EVMS::Y2K notes file:
o Change all 2-digit year fields in data files to 4-digit
year fields. Getting them into the source data files
often prevents ambiguous or inattentive code from later
doing incorrect calculations.
o Convert all output year fields to 4-digit year fields
where possible. This will eliminate many cases
where customers parse our displays to get timestamp
information with truncated years.
________________________ Note ________________________
We must document every such change in release notes
for customers, so be sure to document all such changes
when you check them in.
______________________________________________________
o Replace all "ad hoc" date and/or time calculations or
conversions with OpenVMS system or RTL calls. OpenVMS
calls either deal with only 4-digit years or abide by
the default system sliding window range for 2-digit
interpretation. Any RTL calls that have problems now
will either be fixed or will have a Year 2000 safe
interface in time for the Year 2000 readiness release.
For OpenVMS Alpha, use the global cell EXE$GL_
TRANSITION_YEAR, where appropriate, or wait for
some anticipated system services that will allow
nonprivileged access to the global cell.
2-12
The OSSG Year 2000 Investigation Process
2.5 Fixing Year 2000 Problems
OpenVMS Checkins
Year 2000 code fixes and enhancements should be checked
into the Y2K streams on STAR (for VAX) and EVMS (for
Alpha). Please use the SCT template in Note 2 of the
SCT-Y2K notes conference. Note that the VAX and Alpha
conferences have the same name, but reside on STAR and
EVMS, respectively. (The template is also available at
VMSCMS$:SCT$Y2K.TEMPLATE on the EVMS cluster.)
2-13
3
_________________________________________________________________
Filling Out the OSSG Year 2000 Investigation Report
Read and follow the guidelines for code investigations in
Chapter 2 before filling out the investigation report.
You can copy the report questionnaire from the following
locations:
o BULOVA::DOCD$:[Y2K]Y2K_QUESTIONNAIRE.TXT
o Note 5 in the EVMS::Y2K notes file
3.1 Instructions
Please read the following instructions as you fill out
the report questionnaire. A sample filled-in questionnaire
follows these instructions.
___________________ IMPORTANT NOTE ___________________
We plan to design a tool to automatically read and
tabulate the data in this questionnaire, so please
follow the instructions carefully. Please do not
delete questions or wrap lines in the table.
If you have questions, consult the Y2K team member for
your group. (See Note 45 in EVMS::Y2K for the current
list of team members.)
______________________________________________________
Question 3
Enter the name of the Y2K team member for your group.
3-1
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
Question 4
Investigate the code for the latest version of the product
that shipped to customers. For OpenVMS and its layered
products, this means that all code that runs on OpenVMS
Version 7.1 must be investigated. If you are not sure which
version to investigate, ask the Y2K team member for your
group.
If your product ships on different architectures, also
specify the architecture investigated. For OpenVMS, specify
OpenVMS VAX V7.1 and/or OpenVMS Alpha V7.1.
If common code is used for multiple architectures, you can
file a single report that specifies both architectures.
If conditionals, such as IFDEFS, are used in common code,
and no problems are found inside the conditionals, you can
still file a single report. However, if there are problems,
file separate reports for each architecture. Also file
separate reports for each architecture if they do not share
common code.
Question 5
If your report does not cover an entire product, specify
the component(s) included in your report; for example,
SECURITY or BUGCHECK. (In some cases, the same component
may be covered in multiple reports.)
Question 6
Read the instructions that follow this example before
filling in each field. All data for one entry must be on
one line. The template suggests a tabbed format, but you
can adjust it as necessary. If you have long module names,
you may have to use a 132-column format.
_____________________ IMPORTANT! _____________________
Enter only the requested data in this template. If
you have comments, enter them in Question 10. The
mechanical search tool cannot interpret extra fields
in this template.
______________________________________________________
3-2
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
Interface,
Facility Routine, or
Name Module Name Status Global Cell I/R/G QAR #s
---------------------------------------------------------------------------------
FACILITY-X MODULE1 N/A
MODULE2 PASS INTERFACE1 I
FAIL ROUTINE1 R 141
FACILITY-Y MODULE3 PASS INTERFACE2 I
PASS GLOBAL1 G
PASS DATASTRUCT1 G
FAIL INTERFACE3 I 142,143
MODULE4 RETIRED
MODULE5 DEPENDS
o Facility name
Specify the facility name, if relevant. Otherwise,
specify the component name.
o Module name
To ensure the completeness of our investigation, specify
the full name of each source module investigated. Do not
use wildcards!
o Status
Refer to Section 3.2 for definitions of the allowable
status values.
If a module is N/A, DEPENDS, or RETIRED, enter the
module status here. Enter any dependencies in Question
7.
If a module contains a date/time interface or a routine
that incorrectly uses a date/time interface, we must
document its investigation. Enter the status for the
interface or routine that you report on this line.
o Interface, routine, global cell, or data structure name
If a module contains code for an interface that
imports or exports date or time data or a routine that
incorrectly uses a date/time interface, enter the full
name of the interface or routine. Do not use wildcards!
3-3
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
Please use the most common name for the interface or
routine. If it has any aliases, enter them in Question
8. You need not document internal routines that do not
export any date/time data.
If the module defines or creates a time/date-related
global variable or data structure offset, list it here.
If one module contains more than one date/time interface
or routine that must be documented, enter a separate
line for each (as shown in the example).
If you document an OpenVMS date/time interface or
routine, check Note 6 of EVMS::Y2K for the following:
o Is the interface, routine, global cell, or data
structure offset included in the master list in Note
6?
o Is the status (PASS/FAIL) listed? Is it listed
correctly?
If you have a name or status to add or correct in the
list, please reply to Note 6 (as described under OpenVMS
Requirement in Section 2.4).
o I/R/G
The Year 2000 documentation must differentiate between
date/time interfaces, routines, and global cells:
- I = This line reports a programming or a user
interface.
- R = This line reports an internal routine with an
incorrect date calculation.
- G = This line reports a date/time related global cell
or data structure offset.
o YEAR-2000 QAR database numbers
Every Year 2000 problem must be reported in the YEAR-
2000 QAR database. (Layered products should submit QARs
through Sue STAR::AVERY. See Chapter 4 for details.)
For every interface or routine with FAIL status, enter
the number(s) of all YEAR-2000 QARs. Use a comma to
separate multiple QAR numbers.
3-4
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
________________________ Note ________________________
See Chapter 4 for a list of questions that must
be addressed when you file a QAR in the YEAR-2000
database.
______________________________________________________
Question 7
For every module listed in Question 6 with DEPENDS status,
list the dependencies and their status (FAIL or UNK, for
unknown) as shown in the following example:
Module Name Dependencies
-----------------------------------------------------------
MODULE5 INTERFACE4=UNK, INTERFACE5=FAIL
Question 8
If any of the interfaces or routines listed in Question 6
can be referenced by alternate names, list them as shown in
the following example:
Interface or
Routine Name Aliases
-----------------------------------------------------------
EXE$GETTIM SYS$GETTIM, $GETTIM, $GETTIM_S, $GETTIM_G
List all names by which a timing interface can be called
externally (even by privileged users). Include all high-
level language routines as well as all forms of system
service calling names.
Question 10
If you have comments for the Y2K team that were not
captured by other questions in this report, enter them
here. If you have information to share with others about
the investigation techniques you used, you can either
post a reply to EVMS::Y2K Note 10 or include them here.
3-5
Filling Out the OSSG Year 2000 Investigation Report
3.2 Year 2000 Status Definitions
3.2 Year 2000 Status Definitions
You must classify all modules, date/time interfaces, and
routines that use date/time interfaces by specifying one of
the following status designators:
o N/A
o PASS
o DEPENDS
o FAIL
o RETIRED
Each status is fully defined in the following sections.
N/A: No Date/Time Data
Code does not contain or manipulate date or time data.
PASS: Ready for the Year 2000
Code meets the following requirements:
o Code will continue to function as the date changes from
December 31, 1999 to January 1, 2000, and well beyond
that, without intervention.
o All date calculations, representations, and translations
are correct for any date data within the supported date
range.
o The code provides 4-digit year interfaces and APIs.
o For 2-digit year representations, the code meets one
of the following requirements and is already fully
documented:
- Interprets the value of a fixed or variable offset to
determine whether a 2-digit year belongs to the 20th
or 21st century. (For example, OpenVMS Alpha uses the
system global cell EXE$GL_TRANSITION_YEAR.)
- Includes an encoding and decoding mechanism that
allows unique and unambiguous representation of years
over a range that spans the latter portion of the
20th century and extends well into the 21st century.
3-6
Filling Out the OSSG Year 2000 Investigation Report
3.2 Year 2000 Status Definitions
o Correctly processes, calculates, compares, and
sequences date data within and between the 20th and
21st centuries, including leap year calculations, when
used in a supported manner.
DEPENDS: Readiness Depends Upon External Code
The code in itself is rated PASS, but it calls an interface
or routine whose status is not yet documented as PASS or
FAIL in the list in Note 6.
The Year 2000 team will attempt to coordinate testing
so that the status of dependencies is publicly available
before dependent code is tested. For example, the following
commonly used interfaces and global cells have been
investigated and found to be Year 2000 ready:
o $ASCTIM
o $BINTIM
o $GETTIM
o $NUMTIM
o $SCHDWK
o $SETIME
o $SETIMR
o EXE$GL_ABSTIM
o EXE$GQ_SYSTIME
If your code is Year 2000 ready and calls nothing other
than what's listed above (or an alias), your code qualifies
as PASS.
FAIL: Not Ready for the Year 2000
Code must be classified as FAIL if ANY of the following
conditions apply:
o Software uses an interface or routine whose Year 2000
status is FAIL.
o Code contains Year 2000 limitations or restrictions such
as the following:
- There are minor limitations or restrictions, which
may or may not already be publicly documented.
3-7
Filling Out the OSSG Year 2000 Investigation Report
3.2 Year 2000 Status Definitions
- The code returns a 2-digit year.
- The code uses 2-digit years (even if it is Year 2000
safe), but this usage is not yet fully documented.
- Calculation errors are possible under certain
circumstances.
- Catastrophic problems could occur because the
software does not function properly with date data
beyond December 31, 1999 - or, in some cases, even
earlier. Code should not be used in an environment
that requires correct handling of dates between now
and January 2000.
RETIRED
*** Read this carefully! ***
The component is retired/unsupported or will be retired
/unsupported as of January 1, 1999 -AND- your product
manager has explicitly stated that the code need not be
investigated. Questions about whether a retiring product
should be investigated should be directed to Vittorio
STAR::MEZZANO.
If you do investigate code for components that are slated
for retirement, specify N/A, PASS, DEPENDS, or FAIL for
that code.
___________________ Notify Y2K Team ___________________
For all products slated for retirement, please notify
Vittorio STAR::MEZZANO and Pat JARETH::NELSON of the
expected retirement date so that customers can be
informed. Specify whether or not the code is being
investigated.
______________________________________________________
3-8
Filling Out the OSSG Year 2000 Investigation Report
3.3 Sample Year 2000 Investigation Report
3.3 Sample Year 2000 Investigation Report
Subj: PASS, LMF V1.2 on OpenVMS Alpha and VAX, LMF
Year 2000 Investigation Report
Please follow instructions in Chapter 3 of the OSSG Year 2000
Investigator's Guide when filling out this questionnaire. Your
cooperation is critical to the success of this project. Thank you!
1. Your nodename::username: EVMS::ANONYMOUS
2. Your 7-digit DTN: 381-6354
3. The Y2K contact person for your group: Chris Petrovic
4. Product (including architecture) and version: LMF V1.2 for
OpenVMS Alpha
and VAX
5. Component(s): LMF
6. Inventory (See the Investigator's Guide for instructions.)
3-9
Filling Out the OSSG Year 2000 Investigation Report
3.3 Sample Year 2000 Investigation Report
Interface,
Facility Routine, or
Name Module Name Status Global Cell I/R/G QAR #s
--------------------------------------------------------------------------------
LIB PCBDEF.SDL pass pcb$l_quantum G
LMF CHECKRECORD.B32 n/a
LMF CREATE.B32 pass
LMF ISSUE.B32 pass
LMF LICENSE_CHECK.B32 pass
LMF LICENSE_CHECK_DATA.B32 retired
LMF LIST.B32 pass
LMF LISTMSG.MSG n/a
LMF LMF$CHECKSUM.B32 n/a
LMF LMF$CHECKSUM_MSG.MSG n/a
LMF LMF$GROUP_TABLE.B32 pass
LMF LMF$PURDY.MAR n/a
LMF LMFMAIN.B32 pass
LMF LMFMSG.MSG n/a
LMF LMF_MOVE.B32 pass
LMF LOAD.B32 pass
LMF MAKE_SMM.B32 pass
LMF RABFABERR.B32 n/a
LMF UPDATE.B32 pass
LMF SHOW_CHARGEMSG.MSG n/a
LMF SMM_MSG.MSG n/a
LMF START.B32 n/a
MANAGE LMF$LICENSE.COM pass
MANAGE LMF$LICENSE_LANGUAGE.COM n/a
MANAGE SYSMANLICENSE.B32 n/a
CLD LMF.CLD pass
SYS SYSLICENSE.MAR pass sys$grant_license I
SYS SYSLOOKUP_LICENSE.B32 pass sys$lookup_license I
SYS SYSLOOKUP_LICENSE64.B32 n/a
SYS SYSTEM_DATA_CELLS.MAR pass exe$gq_systime G
CLIUTL SHOWLICENSE.B32 pass
7. Status of module dependencies:
Module Name Dependencies
-----------------------------------------------------------
3-10
Filling Out the OSSG Year 2000 Investigation Report
3.3 Sample Year 2000 Investigation Report
8. Aliases for interfaces and routines listed in your inventory
above (if applicable)
Interface or
Routine Name Aliases
-----------------------------------------------------------
9. What investigation and testing techniques did you use?
For each technique that you used in this list, replace the "o"
that precedes it with an "X". If you mark "Other", please start
your description after the colon (:).
X Visual scan of code
X Mechanical search of code
X Tested the interfaces during a rollover to year 2000
X Other (please describe): Knowledge of design so knew
where dates are used.
10. (Optional) Comments:
- sys$grant_license and sys$lookup_license are undocumented
system services
Send this report from your personal account to JARETH::Y2K with
the following information in the Mail subject line:
Subj: Status, Product name (incl. architecture), Facility or
component name
For "Status" enter the status associated with the first true
statement in this list:
o This report contains at least one FAIL status.
o This report contains at least one DEPENDS status.
o This report contains at least one PASS status.
o This report contains at least one RETIRED status.
o This report contains only N/A statuses.
3-11
4
_________________________________________________________________
Reporting OSSG Year 2000 Problems
The YEAR-2000 QAR database has been created to track
problems exclusively related to Year 2000 issues. Do not
file any other problem reports in this database.
If your project team tracks problem reports locally (for
example, PATHWORKS Client), send a copy of each report to
Sue STAR::AVERY, our OpenVMS layered product coordinator.
Sue will track these problems for us so that all OSSG Year
2000 problems can be monitored from a central QAR database.
4.1 Filing a YEAR-2000 QAR Report
File a QAR in the YEAR-2000 database for every problem
related to the Year 2000 issue. The following sections
detail the information needed in each part of a YEAR-
2000 QAR. A sample filled in QAR report follows the
instructions.
_________________ Template Available _________________
For your convenience, an optional QAR template that
includes fields for the required information is posted
as a reply to Note 5 in EVMS::Y2K.
______________________________________________________
Severity Level
When assigning severity levels for a YEAR-2000 QAR, use the
following guidelines:
o Showstopper
Catastrophic Year 2000 bug. For example, data is
corrupted or the system hangs or crashes.
4-1
Reporting OSSG Year 2000 Problems
4.1 Filing a YEAR-2000 QAR Report
o High
Noncompliant date/time interface, routine, global cell,
or data structure with no available Year 2000 ready
substitute
o Medium
Noncompliant date/time interface, routine, global cell,
or data structure with an available Year 2000 ready
substitute
o Low
Minor problem that can easily be fixed or documented
QAR Abstract
Include the following information in the abstract for each
YEAR-2000 QAR:
o Product
o Architecture
o Version investigated
Problem Report
Include the following in the problem report:
o Describe the problem.
o List the names of all date/time interfaces, routines,
global cells, and data structures.
o On what date does the code fail?
- On or before May 19, 1997
- On or before January 1, 2000
- On or before January 1, 2038
- After January 1, 2038 (please specify):
o Specify all timing formats used in the code.
o Documentation requirements
We must document all Year 2000 problems found in shipped
code as well as all changes that we make to shipped
code, no matter how trivial. For example, if you change
any 2-digit year displays to 4-digit year displays,
please specify what has changed.
4-2
Reporting OSSG Year 2000 Problems
4.1 Filing a YEAR-2000 QAR Report
Please also answer the following questions:
- Is there any reason why this interface should not be
documented for customers and third parties?
- Is there existing documentation that should be
modified (with either corrections or additions)?
If possible, list manual title, chapter or page, type
of change, etc.
- Will the Year 2000 problem or its fix require new
documentation? If so, specify the scope and audience
(internal or customers) of required documentation.
- If applicable, include a summary of the release
note.
Answer
Include the following information in the answer to the
problem:
o Describe the proposed fix for this problem.
Is a code fix or enhancement required, or can the
problem be resolved by a workaround or adequate
documentation?
o If you do not expect the code to ever meet Year 2000
readiness requirements, please explain.
For example, if the problem cannot be totally fixed
because our code must conform to certain coding
standards or other restrictions, please note the
standard or restriction. Is it an internal or external
restriction? (Example: DAP protocol) Is there a
workaround that can make the interface Year 2000 ready?
o Is it feasible to backport this fix? If so, to what
version? If not, what are the restrictions?
o Is your fix included in a patch kit? If so, please list
the patch kit number(s) if you know them.
4-3
Reporting OSSG Year 2000 Problems
4.2 Sample YEAR-2000 QAR Report
4.2 Sample YEAR-2000 QAR Report
TBS
4-4
|
|
____________________________________________________
OSSG Year 2000
Investigator's Guide
February 24, 1997
This handbook provides guidelines for investigating
code for Year 2000 readiness and describes the forms
that must be used to report investigation findings.
________________________ Note ________________________
This document and the report questionnaire are posted
in Note 5 in the EVMS::Y2K notes conference (.TXT) and
in the BULOVA::DOCD$:[Y2K] directory (.PS). |
|
This revision includes change bars on sections that |
are new or changed since the February 17 version. |
______________________________________________________
*** DIGITAL CONFIDENTIAL ***
1
_________________________________________________________________
Introduction
1.1 Overview of this Document
This document covers the following topics:
o Introduction (Chapter 1)
Provides an overview of the OSSG Year 2000 project and
the resources available.
o Year 2000 Investigation Process (Chapter 2)
Describes what to look for in your investigations or
testing and suggests the kinds of fixes to make.
o Filling Out the Investigation Report (Chapter 3)
Explains how to fill out a report for the code you
investigate.
o Reporting Year 2000 Problems (Chapter 4)
Lists the information that you must provide when filing
a problem report for a Year 2000 problem.
This document is available in the following locations:
o BULOVA::DOCD$:[Y2K]Y2K_INVESTIGATOR_GUIDE.PS
o EVMS::Y2K notes conference, Note 5 (.TXT format)
1.2 Overview of the OSSG Year 2000 Project
The major objective of the OSSG Year 2000 Project is to
ensure that customers can count on our software to work
in a predictable and correct manner into the Year 2000 and
beyond.
Customers also need to know the status of our code as soon
as possible so that they can scope out the need to make any
changes in their own code.
1-1
Introduction
1.2 Overview of the OSSG Year 2000 Project
The major concern behind the so-called "Year 2000 problem"
is the representation of years with only two digits instead
of four (for example, "96" instead of "1996"). Use of 2-
digit year representations can cause application problems
during the transition to the year 2000. It can result
in processing errors, especially in cases of sorting,
comparison, and arithmetic operation.
The major requirements that the OSSG Year 2000 Project is
addressing are the following:
o Timely availability of Year 2000 ready products,
including hardware, system software, and layered
products
Many customers need our products to be Year 2000 ready
by the end of 1997 to allow them adequate time to test
and correct their own software during 1998 and put their
Year 2000 ready applications into production during
1999.
o Support and information on the status of installed
products
Customers want to know the state of our products in
terms of Year 2000 readiness. They also want to know the
techniques and methodologies used to find, correct, and
test problems.
o The emerging legal and contractual requirements around
the Year 2000 issue mandate a "Due Diligence" approach
and analysis of our products. For example, in order
to do business with the U.S. government, Digital must
conduct an investigation and document our level of Year
2000 readiness.
For the OSSG Year 2000 Project, due diligence means
that we will do our best to make sure that information
technology environments using our software will continue
to work without problems through the Year 2000 and
beyond.
The OSSG Year 2000 Project will take the following actions
to meet the Year 2000 readiness requirements:
o Investigate all OSSG software products. NOTE: Retiring
products will be handled on a case-by-case basis to
determine whether they need to be investigated and made
Year 2000 ready. (For details, see the description of
RETIRED status in Section 3.2.)
1-2
Introduction
1.2 Overview of the OSSG Year 2000 Project
o Address problems found by fixing them, documenting them,
or providing enhancements as appropriate.
o Ensure that OSSG can provide Year 2000 ready code for
each OSSG software product by the end of 1997. This
effort applies to the most recent version shipped to
customers (for example, OpenVMS Version 7.1). Fixes
and enhancements should also be backported to previous
versions whenever possible.
o Document our search, correction, and testing techniques
and methodologies to ensure that this information is
captured for possible future audits.
o Document the status of and issues related to all date
/time interfaces, routines, global date/time cells, and
data structures.
o Incorporate Year 2000 awareness in our ongoing processes
to ensure that no Year 2000 problems are introduced in
the future.
The investigations to uncover any Year 2000 problems (or
to ensure that there are no problems) are critical to
the success of the overall project. The results obtained
and methods learned from your investigations will lay the
groundwork for the remaining phases of this project.
To address the due diligence requirement, we ask you to
ensure that the methods and tools you use for your searches
and analyses provide results that are equivalent to the
results that would be obtained from a line-by-line code
review. Each group must determine if the way to achieve
this is by actually conducting a line-by-line inspection
of the code or if other techniques and/or tools can be used
to achieve the same results while easing the search and
analysis effort.
A tool is being planned that would search OpenVMS code for
potential Year 2000 problem areas. However, such a tool
is not necessary to conduct an effective investigation. In
fact, no tool can adequately and sufficiently substitute
for a line-by-line review of the code base. Such a tool can
point to the most obvious problem modules, but it does not
ensure that other modules can be ignored.
1-3
Introduction
1.2 Overview of the OSSG Year 2000 Project
1.3 OSSG Year 2000 Resources
The following resources are available to OSSG personnel
conducting Year 2000 code investigations:
o OSSG Year 2000 team members:
- Karen STAR::MARION (Project Manager) DTN: 381-1455
- Vittorio STAR::MEZZANO (Program Manager) DTN: 381-2675
| - Curt STAR::SPACHT (QTV Project Leader) DTN: 381-0046
|
| - Sue STAR::AVERY (Layered Products Coordinator) DTN
| 381-0163
- Pat JARETH::NELSON (Documentation Project Leader)
DTN: 381-1415
- Carlos VMSSG::FUERTES (Release Project Leader) DTN:
381-1698
- For other OSSG Y2K contacts, see Note 45 in EVMS::Y2K
(which will be updated as necessary) or consult the
Y2K team member for your group.
o EVMS::Y2K notes conference
Some notes in this conference may not reflect the
latest policies and approaches adopted by the recently
convened OSSG Year 2000 team. If notes conflict with the
definition of the project as described in this guide,
please follow the guidelines in this document or consult
an OSSG Y2K team member.
o BULOVA::DOCD$:[Y2K] directory
Contains a .PS file of this document (Y2K_
INVESTIGATOR_GUIDE.PS), the report questionnaire (Y2K_
QUESTIONNAIRE.TXT), and a dynamic listing of date/time
related interfaces, routines, global cells, and data
structures (Y2K_INTERFACE_NAMES.LST). Other files of
interest may be added in the future. (Watch for a READ_
ME.TXT file.)
1-4
Introduction
1.3 OSSG Year 2000 Resources
o EVMS::DOCD2$:[Y2K]Y2K_INTERFACE_NAMES.LST
Contains a copy of the Y2K_INTERFACE_NAMES.LST file from
BULOVA for the convenience of local users,
o YEAR-2000 QAR database (see Chapter 4)
o Search tool for OpenVMS software
A search tool is planned, but is not yet available.
1-5
2
_________________________________________________________________
The OSSG Year 2000 Investigation Process
This chapter outlines OSSG's Year 2000 investigation
process, which consists of the following steps:
1. Searching code for date or time related data (see
Section 2.1)
2. Analyzing potential problem areas in code (see
Section 2.2)
3. Testing the system for Year 2000 problems (see
Section 2.3)
4. Documenting your findings (see Section 2.4)
5. Fixing any Year 2000 problems (see Section 2.5)
2.1 Searching Code for Date or Time Related "Hot Spots"
Whenever possible, investigations should be executed by
engineers familiar with the code being reviewed.
Conduct your investigation on the latest version of the
product that shipped to customers. For OpenVMS and its
layered products, this means that all code that runs on
OpenVMS Version 7.1 must be investigated. Some groups may
also decide to investigate older versions of the product
that will still be supported in the Year 2000. If you are
not sure which version of code to investigate, ask your
group's Y2K team member.
Search your code for all instances of date or time related
APIs, structures, global cells, and so forth. Where
feasible, you can use search techniques to help isolate
problem areas in a component. However, such techniques
should not be used at the risk of missing date or time
references that would be caught in a line-by-line visual
inspection.
2-1
The OSSG Year 2000 Investigation Process
2.1 Searching Code for Date or Time Related "Hot Spots"
It is also important to ensure that new code in streams
under development does not introduce Year 2000 errors.
Please help us raise awareness among the engineering
community.
Which Files Should You Investigate?
Because of conditionalizing, .LIS files may not represent
| the entirety of your code. However, .LIS files may contain
| additional information, such as macro expansions, that is
| useful in identifying potential trouble spots in your code.
| In most cases, source code should be investigated, but use
your best judgement about which files to investigate in
order to ensure that OSSG's investigation is as thorough as
| possible.
|
| STARLET and LIB Ownership
|
| Because STARLET and LIB modules are contributed by many
| different people, there can be a question of ownership. For
| now, we will manage ownership of these files as follows:
|
| o If you know you own modules in one of these facilities,
| please investigate them.
|
| o If you're not sure what modules you own, please assume
| ownership wherever possible.
|
| However, before investigating a module, check Note 7
| in EVMS::Y2K for a list of STARLET and LIB modules that
| have already been investigated. This will help to avoid
| duplication of effort.
|
| ____________ Help Us Keep Note 7 Current! ____________
|
| We will attempt to have Note 7 reflect the latest
| investigations. You can help by submitting reports for
| STARLET and LIB modules as soon as possible and doing
| one of the following:
|
| o Reply to Note 7 with a list of STARLET and LIB
| modules that you have investigated.
|
| o When you send in an investigation report that
| includes modules from these facilities, preface
| the Subject line with STARLET or LIB to get our
| attention. (See How to Submit Your Report in
| Chapter 3 for other information to include in
| the Subject line.)
| ______________________________________________________
2-2
The OSSG Year 2000 Investigation Process
2.1 Searching Code for Date or Time Related "Hot Spots"
|
Tips for OpenVMS and Layered Product Investigators
The following information might be helpful for OpenVMS
investigators and for layered product investigators whose |
products run on OpenVMS: |
o Manually, or with a canned procedure, search component
map files for time and date related APIs and global
cells. For completeness, your search should include
the names of all interfaces, routines, global cells,
and data structures having to do with OpenVMS date/time
mechanisms, even if they are Year 2000 safe. This is
necessary because a good date can be turned into a
form that causes an error with year 2000 dates. For
example, a good date can be taken from the system and
be locally converted into an invalid truncated field.
(The EVMS::Y2K notes file contains several examples;
for instance, see the description of a DAP overflow
condition in Note 27.7.)
o A dynamic list of many OpenVMS interfaces, routines,
global cells, and data structures that relate to timing
or dates is posted in the following locations:
- EVMS::Y2K notes conference, Note 6
- BULOVA::DOCD$:[Y2K]Y2K_INTERFACE_NAMES.LST
- EVMS::DOCD2$:[Y2K]Y2K_INTERFACE_NAMES.LST
This list cannot be assumed to be complete, but it may
be useful in getting you started. Keep in mind that,
depending on the nature of the code being reviewed, you
may also need to do a manual search for other APIs and
global cells. (See the OpenVMS Requirement section in
Section 2.4 for information on how you can help us make
this list complete.)
o We hope to provide a search tool to do multi-name
lookups based on a list of all known date/time related
cells, internal interfaces, system services, macros, and
RTL routines. However, such a tool is not necessary to
conduct an effective investigation.
2-3
The OSSG Year 2000 Investigation Process
2.1 Searching Code for Date or Time Related "Hot Spots"
________________________ Note ________________________
There is no known tool that can adequately substitute
for a line-by-line review of the code. The tool can
identify the most obvious problem modules, but it does
not replace a more careful analysis.
______________________________________________________
2.2 Analyzing Potential Problem Areas in Code
Section 2.1 explains how to search code for time-related
"hot spots." This section tells how to analyze the
potential problem areas that you found.
Steps for Investigators
Following are steps for analyzing possible problem areas:
| 1. Examine the code and data flow for all time and date
| related APIs, system global cells, data structure
| fields, media formats, and message formats for possible
| Year 2000 problems. Be sure to check all dates that are
| input or output.
|
| Watch for the following conditions and coding practices
| as well as any other time/date conditions that are
unique to the code you are investigating:
o 2-digit representation of year
| o Small binary fields that may represent dates
o Invalid date differentials
o Procedures that add or subtract 1900 (or another
hard-coded century value) from the date
o Code that results in incorrect sequencing of dates
o Code that causes incorrect scheduling of system
events
If you think of other conditions that would be helpful
to publish for other investigators, please post them as
a reply to Note 10 in EVMS::Y2K.
2-4
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
2. You might find that you need to make a more detailed
analysis than is immediately apparent. Dates might be
converted to an identity or format that is no longer
obviously a date and passed on to other routines.
3. Make sure that the format of the date/time stamps
outputs unambiguous date data. For example, you might
need to examine the user interface to ensure that the
format can accommodate the 4-digit year.
4. After you analyze code found by searching for known date
/time APIs and data structures, you may need to search
and review the code further.
The OpenVMS Specific Sample of Year 2000 Safe Code section
(later in this chapter) suggests a list of questions to use
when you review code.
Criteria for Year 2000 Readiness
Your code is considered Year 2000 ready if you have
determined and documented that the code consistently does
the following:
o Contains 4-digit year display fields, user interface,
and report fields
- Uses correct direct and indirect date field sizes
- Accommodates century where appropriate in data entry
o Uses data structures that can handle dates to the year
2000 and beyond without causing a data overflow
o Accepts 4-digit year format (field expansion)
- Correctly identifies logic filter (if no expansion is
used)
- Can verify present and future use of processing
filter (if no expansion is used)
o Correctly accepts dates from the operating system, sorts
dates, calculates resultant values based on dates, and
passes date formats and values
o Correctly identifies all interface and access data
points
o Correctly handles Year 2000 as a leap year
2-5
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
OpenVMS Specific Sample of Year 2000 Safe Code
Following is an example of time use in a driver that is
Year 2000 safe.
extern unsigned __int64 EXE$GQ_SYSTIME;
unsigned __int64 bin_time; |
bin_time = EXE$GQ_SYSTIME + 100000;
exe_std$instimq((int) (bin_time & 0xffffffff),
(int) ((bin_time >> 32) & 0xffffffff),
(TQE *) &ucb->ucb$l_tqe);
The example does the following:
1. Reads the system time quadword EXE$GQ_SYSTIME and adds
10 milliseconds to it.
2. Tells the system to notify the driver after 10
milliseconds has elapsed.
The Year 2000 is not an issue: the time/date arithmetic
is based on the current time expressed as a binary integer
(which includes a 4-digit year) and a delta time 10ms in
the future; the final result maintains the correct format.
The following table suggests questions to answer when you
review code that handles dates and times. The table also
includes sample answers that are based on the example in
this section.
2-6
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
Question____________________________Answer_________________
1 Does your module import date Yes, by reading EXE$GQ_
information in any way? For SYSTIME
example, in APIs, system
global cells, data structure
fields, media formats, or
message formats?
If so, does the year come in Yes
with four digits?
What does your module do with Adds a delta value,
the date information? 10ms, to the current
times.
If your code manipulates the Yes
date, does it use all four
digits of the year?
2 For OpenVMS, does your code Yes, so I reported the |
include or reference a global undocumented global
timing variable or interface cell in a reply to Note
that is not in the list posted 6.
in Note 6 in EVMS::Y2K?
3 Do you store a date in any No
data structures, either as a
date string or a binary field? |
Is the data structure field No data structures
large enough for a 4-digit
year?
4 Does the module export any No
date information, either as
a date string or a binary
integer?
Are all four digits of the Nothing exported
year included?
2-7
The OSSG Year 2000 Investigation Process
2.2 Analyzing Potential Problem Areas in Code
Question____________________________Answer_________________
5 Does the module do any time Yes, as noted above,
/date arithmetic? 10ms is added to the
current time.
If so, are 4-digit years used? The full year is
included in EXE$GQ_
SYSTIME and the final
calculation maintains a
____________________________________Year_2000_ready_format.
2.3 Testing Your Code for Year 2000 Readiness
While testing cannot be used as a substitute for
investigating code, you can identify potential Year 2000
problems by testing software in an artificial environment
that simulates future dates.
Many systems, including OpenVMS, allow you to set the
system clock forward to create an appropriate testing
environment. This allows you to check whether days of the
week correctly correlate with dates and to verify that
the year 2000 includes 29 days in February (for example,
January 1 should fall on a Saturday and March 1 should be a
Wednesday).
Note that many system applications and layered products
are affected by any substantial modification of system
time. The following procedure (originally published for
customers) is similar to that used for common maintenance
operations (such as system upgrades) and includes steps
that minimize the side-effects of modifying system time.
1. Remove the system to be tested from the production
environment. This will ensure data integrity during
the test sessions.
2. Check that the installed PAKs will not expire during
the testing period. If your system has temporary PAKs,
contact your application vendor.
3. Perform a complete backup of the system disks.
2-8
The OSSG Year 2000 Investigation Process
2.3 Testing Your Code for Year 2000 Readiness
4. Bring the system to a known, quiescent state. For
example:
a. Reboot the system.
b. Stop all pending batch and print jobs.
c. Stop all background processes that are unrelated to
the testing requirements.
5. Use the SET TIME command to set the system clock date
forward to your testing date. For example, you might set
the date to December 31, 1999, and watch the transition
to January 1, 2000.
6. Initialize and complete tests for your specific
environment. This might involve restarting applications
shut down in the previous step.
7. Bring the system back to a known, quiescent state. For
example:
a. Stop all pending batch and print jobs.
b. Stop all background processes in anticipation of a
system shutdown.
_______________________ Caution _______________________
Setting the system time backwards is dangerous,
because applications might halt and freeze as side-
effects of testing.
______________________________________________________
8. Perform one of the following:
o Reset the system clock to the current time.
o Reboot the system using a conversational SYSBOOT and
set the system parameter SETTIME to 1. This causes
the system to prompt you to enter the system time.
________________________ Note ________________________
The following step is important. It repairs any unseen
effects on layered products and applications that may
have occurred by resetting the system time.
______________________________________________________
2-9
The OSSG Year 2000 Investigation Process
2.3 Testing Your Code for Year 2000 Readiness
9. Restore the system disk.
10.Reboot the system.
You can now restore the system to a production environment.
2.4 Documenting Your Findings
Documenting the findings of your investigation is as
important as the investigation itself for several reasons:
o The process and results of the code investigation for
the entire OSSG inventory must be captured for possible
future audits.
o Customers need to know the status of our code as soon
as possible so that they can scope out the need to make
changes to their own code.
You must submit several types of documentation:
o Report the status of all investigated modules
See Chapter 3 for instructions on filing an
investigation report.
o Report all Year 2000 problems
See Chapter 4 for instructions on filing a QAR for every
Year 2000 problem - no matter how insignificant it may
seem!
o Report undocumented date/time interfaces, routines,
and global cells (see the following OpenVMS Requirement
section)
OpenVMS Requirement
If you find any date/time-related interface, routine,
global cell, etc. that is not listed in the master list in
Note 6 of EVMS::Y2K, please reply to that note and list the
new names with their status (PASS or FAIL), if known. (The
PASS/FAIL statuses are defined in Section 3.2.) Note which
category they belong to (for example, system services,
lexical functions, LIB$ routines, etc.).
The Y2K team will regularly update and repost the master
list as needed in the following locations:
o EVMS::Y2K notes conference, Note 6
o BULOVA::DOCD$:[Y2K]Y2K_INTERFACE_NAMES.LST
2-10
The OSSG Year 2000 Investigation Process
2.4 Documenting Your Findings
o EVMS::DOCD2$:[Y2K]Y2K_INTERFACE_NAMES.LST
_____________________ IMPORTANT! _____________________
Collecting every time and date related name is
critical because Customer Services plans to make a
package of these names available for customers to use
for their own Year 2000 investigations.
Even global cells and routines that handle non-date
oriented timing formats are important for this list
because they help locate "hot spots" in nearby code
that might not otherwise be identified.
______________________________________________________
2.5 Fixing Year 2000 Problems
Whenever possible, the ideal fix is to change any 2-digit
year representation to a 4-digit year representation.
The following guidelines were adapted from a posting by Jim
Kauffman in August 1996 in the EVMS::Y2K notes file:
o Change all 2-digit year fields in data files to 4-digit
year fields. Getting them into the source data files
often prevents ambiguous or inattentive code from later
doing incorrect calculations.
o Convert all output year fields to 4-digit year fields
where possible. This will eliminate many cases
where customers parse our displays to get timestamp
information with truncated years.
________________________ Note ________________________
We must document every such change in release notes
for customers, so be sure to document all such changes
when you check them in.
______________________________________________________
o For code that runs on OpenVMS, replace all "ad hoc" date |
and/or time calculations or conversions with OpenVMS |
system or RTL calls. Any RTL calls that have problems |
now will either be fixed or will have a Year 2000 safe |
interface in time for the Year 2000 readiness release. |
OpenVMS system calls mostly deal only with 4-digit |
2-11
The OSSG Year 2000 Investigation Process
2.5 Fixing Year 2000 Problems
| years. However, on OpenVMS Alpha systems, 2-digit years
| are allowed under certain circumstances. These 2-digit
| years are interpreted using the global cell EXE$GL_
| TRANSITION_YEAR (see the following section for details).
|
| To convert your "ad hoc" 2-digit year usage, use one of
| the following:
|
| - Use the $BINTIM system service or a $BINTIM
| derivative (any system timing interface that deals
| directly with 2-digit years).
|
| - Wait to use some anticipated system services that
| will allow nonprivileged access to the EXE$GL_
| TRANSITION_YEAR global cell. Those interfaces are
| still undefined, but will be created as part of the
| Year 2000 Project.
|
| - Privileged Alpha code can utilize the global cell
| EXE$GL_TRANSITION_YEAR.
|
| Using the OpenVMS Global Cell EXE$GL_TRANSITION_YEAR
|
| The global cell EXE$GL_TRANSITION_YEAR defines a date
| range that identifies which century a given 2-digit year
| field belongs to. The cell currently holds a value of 57,
| defining a date range of 1957 to 2056. This cell is used
| in the $BINTIM service and, by association, the DCL SET
| TIME command. This functionality was added to OpenVMS Alpha
| because the battery-backed watch allows only a 2-digit
| year field and we needed a way to deal with truncated years
| consistently across the system. This windowing technique
| provides a fixed range of date years determined by the
| EXE$GL_TRANSITION_YEAR global cell. In the near future this
| may become a sliding window defined by new system services.
|
OpenVMS Checkins
Year 2000 code fixes and enhancements should be checked
into the Y2K streams on STAR (for VAX) and EVMS (for
Alpha). Please use the SCT template in Note 2 of the
SCT-Y2K notes conference. Note that the VAX and Alpha
conferences have the same name, but reside on STAR and
EVMS, respectively. (The template is also available at
EVMS::VMSCMS$:SCT$Y2K.TEMPLATE.)
2-12
3
_________________________________________________________________
Filling Out the OSSG Year 2000 Investigation Report
Read and follow the guidelines for code investigations in
Chapter 2 before filling out the investigation report.
You can copy the report questionnaire from the following
locations:
o BULOVA::DOCD$:[Y2K]Y2K_QUESTIONNAIRE.TXT
o Note 5 in the EVMS::Y2K notes file
3.1 Instructions
Please read the following instructions as you fill out
the report questionnaire. A sample filled-in questionnaire
follows these instructions.
___________________ IMPORTANT NOTE ___________________
We plan to design a tool to automatically read and
tabulate the data in this questionnaire, so please
follow the instructions carefully. Please do not
delete questions or wrap lines in the table.
If you have questions, consult the Y2K team member for
your group. (See Note 45 in EVMS::Y2K for the current
list of team members.)
______________________________________________________
Question 3
Enter the name of the Y2K team member for your group.
3-1
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
Question 4
Investigate the code for the latest version of the product
that shipped to customers. For OpenVMS and its layered
products, this means that all code that runs on OpenVMS
Version 7.1 must be investigated. If you are not sure which
version to investigate, ask the Y2K team member for your
group.
If your product ships on different architectures, also
specify the architecture investigated. For OpenVMS, specify
OpenVMS VAX V7.1 and/or OpenVMS Alpha V7.1.
If common code is used for multiple architectures, you can
file a single report that specifies both architectures.
If conditionals, such as IFDEFS, are used in common code,
and no problems are found inside the conditionals, you can
still file a single report. However, if there are problems,
file separate reports for each architecture. Also file
separate reports for each architecture if they do not share
common code.
Question 5
If your report does not cover an entire product, specify
the component(s) included in your report; for example,
SECURITY or BUGCHECK. (In some cases, the same component
may be covered in multiple reports.)
Question 6
Read the instructions that follow this example before
filling in each field. All data for one entry must be on
one line. The template suggests a tabbed format, but you
can adjust it as necessary. If you have long module names,
you may have to use a 132-column format.
_____________________ IMPORTANT! _____________________
Enter only the requested data in this template. If
you have comments, enter them in Question 10. The
mechanical search tool cannot interpret extra fields
in this template.
______________________________________________________
3-2
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
Interface,
Facility Routine, or
Name Module Name Status Global Cell I/R/G QAR #s
--------------------------------------------------------------------------------
FACILITY-X MODULE1 N/A
MODULE2 PASS INTERFACE1 I
FAIL ROUTINE1 R 141
FACILITY-Y MODULE3 PASS INTERFACE2 I
PASS GLOBAL1 G
PASS DATASTRUCT1 G
FAIL INTERFACE3 I 142,143
MODULE4 RETIRED
MODULE5 DEPENDS
o Facility name
Specify the facility name, if relevant. Otherwise,
specify the component name.
o Module name
To ensure the completeness of our investigation, specify
the full name of each source module investigated. Do not
use wildcards!
o Status
Refer to Section 3.2 for definitions of the allowable
status values.
If a module is N/A, DEPENDS, or RETIRED, enter the
module status here. Enter any dependencies in Question 7.
|
If a module contains a time/date interface, routine, |
global cell, or data structure (as described in the next |
bullet), we must document its investigation. Enter the |
status for the interface, routine, etc. that you report |
on this line. |
|
o Interface, routine, global cell, or data structure |
|
If a module contains code for one of the following, |
enter the full name in this column. Do not use |
wildcards! |
|
- An interface that imports or exports date or time |
data |
3-3
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
| - A routine that incorrectly uses a date/time interface
| -AND- exports date data.
|
| - Time or date-related global cell or data structure
| offset that is defined in this module
|
| Please use the most common name for an interface or
| routine. If it has any aliases, enter them in Question 8.
|
| If one module contains more than one item that must be
| documented, enter a separate line for each (as shown in
| the example).
|
| If this entry documents OpenVMS code, check Note 6 of
EVMS::Y2K for the following:
- Is the interface, routine, global cell, or data
structure offset included in the master list in Note 6.
- Is the status (PASS/FAIL) listed? Is it listed
correctly?
If you have a name or status to add or correct in the
list, please reply to Note 6 (as described under OpenVMS
Requirement in Section 2.4).
o I/R/G
|
| Specify I, R, or G to identify what you entered in the
| last column:
|
| - I = This line reports a programming or a user interface.
|
| - R = This line reports an internal routine that uses
| and exports unsafe date data.
- G = This line reports a date/time related global cell
or data structure offset.
o YEAR-2000 QAR database numbers
Every Year 2000 problem must be reported in the YEAR-
2000 QAR database. (Layered products should submit QARs
through Sue STAR::AVERY. See Chapter 4 for details.)
3-4
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
For every interface or routine with FAIL status, enter
the number(s) of all YEAR-2000 QARs. Use a comma to
separate multiple QAR numbers.
________________________ Note ________________________
See Chapter 4 for a list of questions that must
be addressed when you file a QAR in the YEAR-2000
database.
______________________________________________________
Question 7
For every module listed in Question 6 with DEPENDS status,
list the dependencies and their status (FAIL or UNK, for
unknown) as shown in the following example:
Module Name Dependencies
----------------------------------------------------------
MODULE5 INTERFACE4=UNK, INTERFACE5=FAIL
Question 8
If any of the interfaces or routines listed in Question 6
can be referenced by alternate names, list them as shown in
the following example:
Interface or
Routine Name Aliases
----------------------------------------------------------
EXE$GETTIM SYS$GETTIM, $GETTIM, $GETTIM_S, $GETTIM_G
List all names by which a date interface can be called |
externally (even by privileged users). Include all high-
level language routines as well as all forms of system
service calling names.
Question 10
|
If you have comments for the Y2K team that were not |
captured by other questions in this report, enter them |
here. If you have information to share with others about
the investigation techniques you used, you can either post
a reply to EVMS::Y2K Note 10 or include them here. |
3-5
Filling Out the OSSG Year 2000 Investigation Report
3.1 Instructions
| How to Submit Your Report
|
| Send your completed report from your personal account to
| JARETH::Y2K with the following information in the Mail
| subject line:
|
| Subj: Status, Product name (incl. architecture), Facility or
| component name
|
| For "Status" enter the status associated with the first
| true statement in this list:
|
| o This report contains at least one FAIL status.
| o This report contains at least one DEPENDS status.
| o This report contains at least one PASS status.
| o This report contains at least one RETIRED status.
| o This report contains only N/A statuses.
|
| _______________ STARLET and LIB Reports _______________
|
| If your report includes STARLET or LIB modules and
| you have not replied to Note 7 in EVMS::Y2K, please
| preface the Subject line with STARLET or LIB to get
| our attention.
| ______________________________________________________
3.2 Year 2000 Status Definitions
You must classify all modules, date/time interfaces, and
routines that use date/time interfaces by specifying one of
the following status designators:
o N/A
o PASS
o DEPENDS
o FAIL
o RETIRED
Each status is fully defined in the following sections.
N/A: No Date/Time Data
Code does not contain or manipulate date or time data.
3-6
Filling Out the OSSG Year 2000 Investigation Report
3.2 Year 2000 Status Definitions
PASS: Ready for the Year 2000
Code meets the following requirements:
o Code will continue to function as the date changes from
December 31, 1999 to January 1, 2000, and well beyond
that, without intervention.
o All date calculations, representations, and translations
are correct for any date data within the supported date
range.
o The code provides 4-digit year interfaces and APIs.
o For 2-digit year representations, the code meets one
of the following requirements and is already fully
documented:
- Interprets the value of a fixed or variable offset to
determine whether a 2-digit year belongs to the 20th
or 21st century. (For example, OpenVMS Alpha uses the
system global cell EXE$GL_TRANSITION_YEAR.)
- Includes an encoding and decoding mechanism that
allows unique and unambiguous representation of years
over a range that spans the latter portion of the
20th century and extends well into the 21st century.
o Correctly processes, calculates, compares, and
sequences date data within and between the 20th and
21st centuries, including leap year calculations, when
used in a supported manner.
DEPENDS: Readiness Depends Upon External Code
The code in itself is rated PASS, but it calls an interface
or routine whose status is not yet documented as PASS or
FAIL in the list in Note 6.
The Year 2000 team will attempt to coordinate testing
so that the status of dependencies is publicly available
before dependent code is tested. For example, the following
commonly used interfaces and global cells have been
investigated and found to be Year 2000 ready:
o $ASCTIM
o $BINTIM
o $GETTIM
3-7
Filling Out the OSSG Year 2000 Investigation Report
3.2 Year 2000 Status Definitions
o $NUMTIM
o $SCHDWK
o $SETIME
o $SETIMR
o EXE$GL_ABSTIM
o EXE$GQ_SYSTIME
If your code is Year 2000 ready and calls nothing other
than what's listed above (or an alias), your code qualifies
as PASS.
FAIL: Not Ready for the Year 2000
Code must be classified as FAIL if ANY of the following
conditions apply:
o Software uses an interface or routine whose Year 2000
status is FAIL.
o Code contains Year 2000 limitations or restrictions such
as the following:
- There are minor limitations or restrictions, which
may or may not already be publicly documented.
- The code returns a 2-digit year.
- The code uses 2-digit years (even if it is Year 2000
safe), but this usage is not yet fully documented.
- Calculation errors are possible under certain
circumstances.
- Catastrophic problems could occur because the
software does not function properly with date data
beyond December 31, 1999 - or, in some cases, even
earlier. Code should not be used in an environment
that requires correct handling of dates between now
and January 2000.
3-8
Filling Out the OSSG Year 2000 Investigation Report
3.2 Year 2000 Status Definitions
RETIRED
*** Read this carefully! ***
The component is retired/unsupported or will be retired
/unsupported as of January 1, 1999 -AND- your product
manager has explicitly stated that the code need not be
investigated. Questions about whether a retiring product
should be investigated should be directed to Vittorio
STAR::MEZZANO.
If you do investigate code for components that are slated
for retirement, specify N/A, PASS, DEPENDS, or FAIL for
that code.
___________________ Notify Y2K Team ___________________
For all products slated for retirement, please notify
Vittorio STAR::MEZZANO and Pat JARETH::NELSON of the
expected retirement date so that customers can be
informed. Specify whether or not the code is being
investigated.
______________________________________________________
3.3 Sample Year 2000 Investigation Report
Subj: PASS, LMF V1.2 on OpenVMS Alpha and VAX, LMF
Year 2000 Investigation Report
Please follow instructions in Chapter 3 of the OSSG Year 2000
Investigator's Guide when filling out this questionnaire. Your
cooperation is critical to the success of this project. Thank you!
1. Your nodename::username: EVMS::ABIS
2. Your 7-digit DTN: 381-6254
3. The Y2K contact person for your group: Chris Petrovic
4. Product (including architecture) and version: LMF V1.2 for OpenVMS
Alpha and VAX
5. Component(s): LMF
6. Inventory (See the Investigator's Guide for instructions.)
3-9
Filling Out the OSSG Year 2000 Investigation Report
3.3 Sample Year 2000 Investigation Report
Interface,
Facility Routine, or
Name Module Name Status Global Cell I/R/G QAR #s
--------------------------------------------------------------------------------
LMF CHECKRECORD.B32 n/a
LMF CREATE.B32 pass
LMF ISSUE.B32 pass
LMF LICENSE_CHECK.B32 pass
LMF LICENSE_CHECK_DATA.B32 retired
LMF LIST.B32 pass
LMF LISTMSG.MSG n/a
LMF LMF$CHECKSUM.B32 n/a
LMF LMF$CHECKSUM_MSG.MSG n/a
LMF LMF$GROUP_TABLE.B32 pass
LMF LMF$PURDY.MAR n/a
LMF LMFMAIN.B32 pass
LMF LMFMSG.MSG n/a
LMF LMF_MOVE.B32 pass
LMF LOAD.B32 pass
LMF MAKE_SMM.B32 pass
LMF RABFABERR.B32 n/a
LMF UPDATE.B32 pass
LMF SHOW_CHARGEMSG.MSG n/a
LMF SMM_MSG.MSG n/a
LMF START.B32 n/a
MANAGE LMF$LICENSE.COM pass
MANAGE LMF$LICENSE_LANGUAGE.COM n/a
MANAGE SYSMANLICENSE.B32 n/a
CLD LMF.CLD pass
SYS SYSLICENSE.MAR pass sys$grant_license I
SYS SYSLOOKUP_LICENSE.B32 pass sys$lookup_license I
SYS SYSLOOKUP_LICENSE64.B32 n/a
CLIUTL SHOWLICENSE.B32 pass
7. Status of module dependencies:
Module Name Dependencies
--------------------------------------------------------------
3-10
Filling Out the OSSG Year 2000 Investigation Report
3.3 Sample Year 2000 Investigation Report
8. Aliases for interfaces and routines listed in your inventory above
(if applicable)
Interface or
Routine Name Aliases
--------------------------------------------------------------
9. What investigation and testing techniques did you use?
For each technique that you used in this list, replace the "o"
that precedes it with an "X". If you mark "Other", please start
your description after the colon (:).
X Visual scan of code
X Mechanical search of code
X Tested the interfaces during a rollover to year 2000
X Other (please describe): Knowledge of design so knew
where dates are used.
10. (Optional) Comments:
- sys$grant_license and sys$lookup_license are undocumented
system services
Send this report from your personal account to JARETH::Y2K with the
following information in the Mail subject line:
Subj: Status, Product name (incl. architecture), Facility or
component name
For "Status" enter the status associated with the first true
statement in this list:
o This report contains at least one FAIL status.
o This report contains at least one DEPENDS status.
o This report contains at least one PASS status.
o This report contains at least one RETIRED status.
o This report contains only N/A statuses.
3-11
4
_________________________________________________________________
Reporting OSSG Year 2000 Problems
The YEAR-2000 QAR database has been created to track
problems exclusively related to Year 2000 issues. Do not
file any other problem reports in this database. |
|
Layered Product Problem Reporting |
|
If your project team tracks problem reports locally (for |
example, PATHWORKS Client), send a copy of each report to |
Sue STAR::AVERY, our OpenVMS layered product coordinator. |
Sue will enter each report as a QAR in the YEAR-2000 QAR |
database and will track these problems for us so that all |
OSSG Year 2000 problems can be monitored from a central QAR
database.
4.1 Filing a YEAR-2000 QAR Report
File a QAR in the YEAR-2000 database for every problem
related to the Year 2000 issue. The following sections
detail the information needed in each part of a YEAR-
2000 QAR. A sample filled in QAR report follows the
instructions.
_________________ Template Available _________________
For your convenience, an optional QAR template that
includes fields for the required information is posted
as a reply to Note 5 in EVMS::Y2K.
______________________________________________________
Severity Level
When assigning severity levels for a YEAR-2000 QAR, use the
following guidelines:
o Showstopper
Catastrophic Year 2000 bug. For example, data is
corrupted or the system hangs or crashes.
4-1
Reporting OSSG Year 2000 Problems
4.1 Filing a YEAR-2000 QAR Report
o High
Noncompliant date/time interface, routine, global cell,
or data structure with no available Year 2000 ready
substitute
o Medium
Noncompliant date/time interface, routine, global cell,
or data structure with an available Year 2000 ready
substitute
o Low
Minor problem that can easily be fixed or documented
QAR Abstract
Include the following information in the abstract for each
YEAR-2000 QAR:
o Product
o Architecture
o Version investigated
Problem Report
Include the following in the problem report:
o Describe the problem.
o List the names of all date/time interfaces, routines,
global cells, and data structures.
o On what date does the code fail?
- On or before May 19, 1997
- On or before January 1, 2000
- On or before January 1, 2038
| - After January 1, 2038 (please specify):
|
| o Specify all date formats used in the code.
o Documentation requirements
We must document all Year 2000 problems found in shipped
code as well as all changes that we make to shipped
code, no matter how trivial. For example, if you change
4-2
Reporting OSSG Year 2000 Problems
4.1 Filing a YEAR-2000 QAR Report
any 2-digit year displays to 4-digit year displays,
please specify what has changed.
Please also answer the following questions:
- Is there any reason why this interface should not be
documented for customers and third parties?
- Is there existing documentation that should be
modified (with either corrections or additions)?
If possible, list manual title, chapter or page, type
of change, etc.
- Will the Year 2000 problem or its fix require new
documentation? If so, specify the scope and audience
(internal or customers) of required documentation.
- If applicable, include a summary of the release
note.
Answer
Include the following information in the answer to the
problem:
o Describe the proposed fix for this problem.
Is a code fix or enhancement required, or can the
problem be resolved by a workaround or adequate
documentation?
o If you do not expect the code to ever meet Year 2000
readiness requirements, please explain.
For example, if the problem cannot be totally fixed
because our code must conform to certain coding
standards or other restrictions, please note the
standard or restriction. Is it an internal or external
restriction? (Example: DAP protocol) Is there a
workaround that can make the interface Year 2000 ready?
o Is it feasible to backport this fix? If so, to what
version? If not, what are the restrictions?
o Is your fix included in a patch kit? If so, please list
the patch kit number(s) if you know them.
4-3
Reporting OSSG Year 2000 Problems
4.2 Sample YEAR-2000 QAR Report
4.2 Sample YEAR-2000 QAR Report
TBS
4-4
|