T&E Year 2000 Cost Profile

Figures calculated in accordance with model developed under GSA contract with OAO
All percentages are based on the total implementation cost, which the TRE Year 2000 team estimated
at $150M.

10%  $15.0M Detailed problem assessment / business case
includes 2 % ($3M) for problem ID & planning

10%  $15.0M _ Assessment of existing code to locate suspects
15%  $22.5M _ Tools, diagnostics, & compliance testing
65%  $97.5M Fix and confirm *
100% $150M
* The “fix” figure assumes entire cost of fixing T&E problems will be borne by the T&E community.

This amount may be reduced by gaining commitment from services, agencies, etc. to assist with
solutions involving systems they support.

FIGURE 3

While this is the most sensible methodology, other alternatives exist. These alternatives, ranked
for practicality include: a most critical systems approach whereby crucial systems such as payroll
are attacked in sequence, an enterprise approach involving a holistic top-down assessment of the
entire enterprise, and a re-engineering approach. The critical systems approach has great merit so
long as critical system interfaces as previously discussed are factored into the systems evaluation
rules. The enterprise approach may have merit, but requires a massive management commitment
over and above necessary working level effort. The re-engineering approach, while attractive in
concept, cannot not practically come to fruition in time for the immutable Year 2000 deadline. It is
important to note that despite the selected approach, any Year 2000 solution demands a high degree
of direct user involvement in all phases of activity. There is general consensus among the vendors
that any turn-key contractor based strategy is bankrupt.

3. The T&E Year-2000 Team evaluated one promising technology to help ease the Year 2000
code assessment burdens noted above. Rather than parse the actual code, one firm, named
DBSTAR, suggested that the actual data produced from the code held significant insights. These
data could be assessed for highly probable data patterns concerning the manipulation of year
based data. The DBSTAR tool set was initially developed to provide a map of legacy systems for
purposes of intelligent systems re-engineering. This established data mapping code works with
singular data sources such as a column of like data, large data matrices and whole systems of

13



systems/equipments under the RSA (Range Standard Architect) program. This program is
scheduled to be completed prior to 2000.

Mr. Ken Clarke (5/29/96)

Mr. Clarke is Program Manager for the GPS office at Chesapeake Test Range. He was aware of
the Year 2000 problem. A complete inventory of computer hardware/software for the GPS
systems was not available. He stated that the only date information used in GPS systems was
IRIG based and that this utilized the Julian date format. He felt that the Year 2000 problem
would not have any impact. (However, see Joe Gwinn message below.)

Mr. Tony Winkleman (6/18/96)

Mr. Winkleman is Program Manager for the Real Time Dynamic Radar Cross Section (RCS)
Test Facility at Chesapeake Test Range. Mr. Winlkeman advised the team that Y2000 tests he
performed on the radar controller computer (Motorola Unix Version 3.5.1) demonstrated that it
will not except dates beyond 1999 on input. Attempts to enter any year in the two digit year
field between 00 and 69 are reset to 70. However, the system appeared to successfully
“rollover” to 2000 when the system date was advanced to 12/31/99. Subsequently, new files
where apparently correctly dated with Year 2000 creation dates. Regardless, the inability to
input correct dates would be detrimental to the operation of Mr. Winlkeman’s function. He
anticipates this machine will be replaced before 2000.

Mr. Joe Gwinn (6/26/96)

Mr. Gwinn is an engineer at Raytheon. The information below was provided by him via email to
interested parties and was not obtained by Year-2000 Team interviewers. His message is
included here with his permission.

Subject: The Millennium comes early to GPS
Ihave good news and I have bad news.
The good news is that GPS will not have a "Year 2000" problem.

The bad news is that GPS System Time will roll over at midnight 21-22 August 1999, 132 days
before the turn of the millennium. On 22 August 1999, unless repaired, many or all GPS
receivers will claim that it is 6 January 1980, 23 August will become 7 January, and so on. I
would expect that some manufacturers have already solved the problem, but many have not.

The details: Section 3.3.4(b) (page 33) of the ICD-GPS-200 rev B (30 November 1987 issue)
states that the GPS Week count starts at midnight 5-6 January 1980 UTC, and that the GPS
Week field is modulo 1024. This means that the week count will roll over 1024/52 = 19.69 years
from then, or in 1980 + 19.7= 1999.7 (August 1999), only a few years from now.

C6



and the reduction of Telemetry and TSPI data. Computational Fluid Dynamics (CFD) and
Structures are now largely done by the engineering competencies, 4.2 and 4.3. He was generally
aware of the Year 2000 issue. He maintains some 300 programs. These programs are generally
20 years old. They are largely written in FORTRAN with more recent ones in C++.
Photogramteric data reduction programs use Julian code for dates. Telemetry input comes in
IRIG Julian date format. He possesses an 87 page abstract book listing these programs and their
nature:
Description of the Application/Program
Capability/Utilization
Name
Program or Sub-program
Aircraft or projects supported
In-house or commercial
Date of last update or review
T&E areas supported
Hardware required
Host
Operating system
Threading (multiple or single)
Network association(s)
Unique features
Limitations

He feels a test plan is required to seek and isolate Year 2000 instances, examine the potentially
susceptible code, do the trade-offs, and make the fix. He will assign a Year 2000 lead to examine
his computer systems for Year 2000 impact and provide the findings to this team. He suggested
further investigation be conducted in:

Metrology - Mr. Jimmy Fairfax
Avionics and Mission Technology - Mr. Dan Dickey

Mr. Terry Collom (4/17/96).

Mr. Collom is responsible for instrumentation and its fabrication at NAWCAD, Patuxent River.
He was made aware of the Year 2000 issue through a television spot he saw the preceding night.
He sincerely felt the Year 2000 issue had minimal impact at first blush. He agreed with Mr.
Rymer (see below) who laid the problem in the hands of the suppliers, be they maintenance
contractors or Original Equipment Manufacturers (OEM). He was concerned about support
systems such as Supply, which could affect his logistics flow. He agreed to have the problem
examined more closely in his department.

The departmental report indicated, as expected, that the effect of business systems and
Commercial Off The Shelf (COTS) products were the primary concern. Four internal inventory
programs were cited as needing repair. They are:

Ready Issue,

c2



Mr. Dave Jennings (5/14)

Mr. Jennings is Chief, Optical Engineering Division for ATC. His division provides visual
documentation of RDT&E testing to include ballistic, automotive and live fire testing of Army
materiel. He is aware of the Y2K problem and a minor impact is anticipated. Date/time fields
are not a critical element in operating camera systems. They have PC's and commercial software
which will be updated by the manufacturer. They do not estimate any costs will be incurred for
Year 2000 corrections.

Mr. John Gerdes (5/14)

Mr. Gerdes is an engineer in the Radiation & Simulation Directorate of ATC. This directorate is
responsible for monitoring X-rays, health physics, customer data acquisition, and systems
analysis. They are aware of the Year 2000 problem and have done their own analysis. All old
PC controllers (BIOS) will be upgraded. Most computers will be replaced with new models
before 2000. Software fixes will be prepared for laboratory programs. They have estimated a
cost of $200-$300K and six man-months of effort.

Mr. Bill Burch (5/14)

Mr. Burch is an environmentalist in the Environmental Office of ATC. His department is aware
of the Y2K problem. His office tracks hazardous waste materials and all such information is
stored in a database of the Hazardous Waste Tracking System. This system resides on a
minicomputer maintained by the Directorate of Information Management (DOIM). DOIM
interfaces with the DoD Environmental Network Information Exchange (DENIX) in Washington
DC. His opinion is that there will be little or no impact to his operation due to the Year 2000
transition.

Ms. Rebecca Joy (5/2

Ms. Joy is an engineer in the Technology Directorate of ATC. Their main function is to track
multi-spectral signature measurements of military targets. All data is housed in a Unix based
minicomputer running Oracle. This office interfaces with the National Ground Intelligence
Center (NGIC) which has developed a system that is linked over a network with twelve other
sites. They are investigating the availability of Year 2000 training necessary for one of their
employees to make modifications to their in-house programs. They estimate costs of $5K.

Mr. Tom Lockard (16 May’

Mr. Lockard is the Chief, Computer Operations for the Directorate of Information Management
(DOIM). The DOIM supports the T&E Command (TECOM) for ongoing system/program
maintenance and production execution of the Test & Evaluation Analysis Management-
Uniformity Plan (TEAM-UP). One of these systems is the Test Resource Management System
(TRMS) which is the primary information management tool for TECOM's testing mission. They
are aware of the Y2K problem. This office maintains and supports the IBM mainframe and

cil



Much test/calibration equipment that is used to maintain these complex instrumentation systems
utilize microprocessors and software to function. Tests have shown that the century change will
impact this equipment. While some of these computers are scheduled for replacement before
2000, several affected systems are not slated for replacement.

Scientific data processing is directly and indirectly dependent on business systems, planning
systems, scheduling systems and other “mundane" large to intermediate sized utilities for smooth
functioning and logistics. To this extent the scientific computing community is vulnerable to and
has a direct stake in the Year 2000 problem. Feeds from external systems not corrected for the
year 2000 pose a potentially substantial risk throughout the T&E scientific data processing
community so far as these systems contain embedded two digit date information which is or may
be subsequently used in further calculations.

3. DESKTOP SYSTEMS: Many personal computers (PC) contain embedded Operating System
and DOS BIOS Year 2000 related design faults. These concerns can range from complete
devastation to mild inconvenience based on how they are embodied and how the systems are
employed by their users. For example, the Naval Air Warfare Center - Patuxent River, Maryland
has some 8,000 PCs and 700 MACs (Macintosh computers’ operating systems are Year 2000
compliant and do not exhibit Year 2000 problems) listed on the Division-wide inventory. The
consequence to localized and base-wide electronic mail and data exchange capabilities, based
largely on personal computer technology are not yet assessed. There are no known additional
funds available to seek, isolate and resolve such Year 2000 issues. There is, however, a sense
among those interviewed that the rate of turnover among PCs will replace presently vulnerable
systems with Year 2000 compliant systems within ample time. Moreover, there is a known, free
“fix” to the PC Year 2000 problem available to users of the World Wide Web. An explanation
of the Year 2000 problem on PCs, a compliance test, and the WEB page address for the “fix”
can be found at Appendix D. For these reasons, no costs have been attributed to T&E for
correcting Year 2000 problems for PCs in this report. The onus will be on users who retain their
existing Year 2000-flawed computers into the next century to adopt the correction.

B. COST ASSESSMENT FOR T&E YEAR 2000 REMEDY: For the purpose of discussing
costs associated with eliminating the Year 2000 problem from the T&E community, computer
assets were divided into three broad categories: pure T&E computer assets, ancillary (base
operations, range scheduling, program management, etc.), and functional dependencies
(information systems in finance, supply, etc.). The pure T&E computer assets are further
subdivided into mainframes, workstations, servers and desktops. As noted above, no costs are
reflected in this report for desktops.

1. T&E COMPUTER ASSETS: Testimony from T&E managers and engineers at the three sites,
and the T&E Year-2000 Team’s own research and analysis leads to the conclusion that all three
sites experience almost exactly the same circumstance regarding Year 2000 as an issue.
Generally, the scientific and engineering applications that operate on pure T&E computer assets
were not found to be adversely affected in and of themselves by Year 2000 problems. This stems
from the simple fact that these applications do not use dates in their operation. This assessment
could not be verified by actual physical examination of representative code or data, but was

7



problems. Provides extensive

costing & resource
requirements

fanalysis. Done on an
lapplication-

[by-application basis which are

Then rolled into a portfolio
sizing

report. Pilot project focus. 800

million lines of code evaluated

since 1991, over 1 billion
under

review.

Decision Systems Currently | Since IA systems engineering and |Unisys 2200, Sun SPARC
Technologies, Inc. supporting | 1986 IS/W engineering company. | Workstations, 486/66 PCs, Unix
6301 Ivy Lane,Suite 600 IRS Lan, COBOL, Windows for
Workgroups,
Greenbelt, MD 20770 300 professionals. Focus is |MSO Open, Microfocus, ORACLE,
SUN Solaris, more
systems development, exec
301-441-3377 info systems, reengineering,

Fax 301-441-4571

Inetwork integration and mgmt,

Has several IDIQ task order
contracts via Fed Agencies

systems integration, info engineering. Y2k is primarily

consulting,strategy, planning.

IDBS(TAR, Inc

185 Berry Street

[San Francisco, CA 94107-
1729

415-512-0300

Brian Boyle

‘Tool examines actual data
artifacts vice code parseing.
[Assesses for probable date data|
[patterns . Resulting annotated
Jdata maps can also serve as
analytical tools for
reengineering efforts..

Analytical tool for data artifact
lanaysis

General Services
Administration

Federal Information Systems
[Support

Technical Services Div

Program (FISSP). Provides
jreqmnts

7th & D Sts. SW, Rm 6109

[contracts to meet IT needs of
Fed

Washington, DC 20407

agencies. Provides existing
|procrmnt

202-708-7700 vehicles. Assists SOW, issues
REP,

Fax 202-708-7714 evaluates proposal, negotiates
task
lorder, administers task. Has

(Gee OAO below) [precompeted contracts for
Yy2K.

IBM "The Year 2000 and 2-Digit

Dates:

E4



(Conv Planning

ICode Conv & Data Conv

‘Testing & Implementation

[Expertise in change analysis,

[config mgmt, and testing
techniques

CAPGEMINI AMERICA YES | Uses artificial intelligence tool
set.
“Transmillennium Services" [Uses their Application
[Renovation
Iselin, N.J. [Center (out source) to leave
your
‘908-906-0400, Fax 908- longoing operations
906-0969 undisturbed.
New York, NY A factory: a highly
disciplined,
212-944-6464 ext 232 ftool-supported outsourcing
vendor
Fax 212-944-8760 who can save money and
provide
fhigh quality deliverables.
Computer Associates YES Pre-packaged solutions and Source code, JCL, PROCS
‘One Computer Associates conv assist for Y2K efforts.  |Database conv, documentation,
Plaza IMVS,VSE, PC Workstations
Islandia, NY 11788-7000 [S/W driven impact assmnt on mainframes/PC workstations
516-342-5224 Detail info on date fields
inventory, LOC, number and % on date fields
“CA Discovery 2000" Y2K project plan, impact anal
imp, unit and system tests,
regression tests, deploy, LCM
Computer Horizons Corp. 26 YES Five phased approach from _ {A service for converting

“Signature 2000 Solution"

discovery (assessment) to

Imainframe COBOL applications

Mountain Lakes, NJ

implementation, Creates
application portfolio,

800-321-2421, Fax 201-
402-7988

then analysis,

construction, testing and

implementation.

IA service for converting main-

frame COBOL applications

limpact Analysis

Conv Planning

[Code Cony & Data Conv

E2



Quintie Systems,Ine. Several | 17 YES impact analysis, Code/File _ [COBOL,SAS,Assembir (BAL),
3166 Des Plaines Ave Cony, automatically expands |PL/1, Fortran, 4GLs, MVS,
Suite 36 to a 4 digit year. S/W converts |VSE/ESA, TANDEM
Des Plaines multiple date formats;
expands, contracts or
ILL 60018 maintains record size; converts
record formats; analyzes data
for date fields; adjusts file data
to simulate
800-699-1169, 708-699- Tuture/past dates which verify program accuracy.
1169
Fax 708-699-1214
‘SEEG, Inc. & CBSI Products support the [COBOL
estimation of
“COBOL Analyst” cost and effort to reengineer
COBOL
(SEEC) 412-682-4991 systems to be Y2K compliant.
Will
(GEEC) Fax 412-682-4958 irain your staff to make
(CBSI 810-488-2088 conversion.
(CBSI) Fax 810-488-2089
Source Recovery Company Creates source code from [SRC recovers COBOL,CICS, DB2,
machine
992 East Freeway Drive code. IMS, BMS MAPS, Assembler, any
Suite A MVS/VSEVM program
Conyers, GA 30207
770-785-9801
Fax 770-160-7316
SYNTEL 16 [A software Solutions Services |IBM mainframes, UNISYS,
Steve Bross Company that provides Digital, UNIX, C/S
technical
919-233-6200, 919-233- people to your site or at their
6485
Fax 919-233-4517 abs. 4000 professionals, time
&
mils, tum key and project,
service
TRANS Century Data 7 Provides a reliable and Mainframes to PCs

Systems

“TRANS Century Calendar
Routines"

[comprehensive set of date
routines

COBOL, DB2, etc.

415-255-7082, 800-837-
7989

lwhich support Y2K conversion

Fax, 415-255-4584

efforts.

E8



Reboot. The DOS year should still be 2000. If it does not your machine has the flaw.

For a Year 2000 solution for your PC refer to the following WEB site:

http://rampages.onramp.net/~gtbecker/

FOSS GIS a SS IGRI ICR CICA ICE A AICI I C1 1 3.21 1 8 3 21 aS aC I ACA oR aC A OR CC CE RCC A CR EE ACEO

DS



ultimate objective would be to make the “Clearing House” operation self sufficient by 1999
through its positive contributions to the T&E community and beyond.

B. RECOMMENDATION 2. Through the “Clearing House”, aggressively promote awareness
campaigns throughout the T&E community. Utilize the Tri-Service Range Commanders Council
(RCC) Working Groups (data reduction and computers, electronic trajectory measurement,
signals measurement, meteorology, telecommunications and timing, range safety, optical
systems) to promulgate Year 2000 issues and investigate and report on areas of vulnerability or
compliance. Likewise, energize management support throughout the Executive Agent to focus
awareness and necessary compliance activities throughout the T&E community. Emphasis
should also be given via electronic means such as the World Wide Web using as many sites as
possible to popularize Year 2000 success stories, techniques and winning strategies. A good start
may be to promulgate the contents of this report throughout the T&E community for critical
review and comment. Such activity tends to heighten Year 2000 awareness and spirit the dialog
necessary to engage a timely, proactive Year 2000 stance throughout the entire T&E community.

17



For the record, this is how the precise rollover date was computed: The origin (time zero) of
GPS System Time, 00:00:00 UTC 6 January 1980, is Julian Day 2,444,244.500. A GPS Cycle is
1,024 weeks, or 7,168 days, so the first GPS rollover will occur at Julian Day (2444244.5+7168)
= 2,451,412.5, which is 00:00:00 UTC 22 August 1999 AD, which is the midnight between
Saturday night the 21st of August, and Sunday morning the 22nd of August, 1999.

I could find no mention of any field in any GPS message that would tell you which 1024-week
cycle you were in. In the July 1993 update of ICD-GPS-200, a note has been added (also on
page 33) saying that the week number *will* roll over, and that users must account for this, but
no way to accomplish this is mentioned. I take this note as further evidence that there is no way
to tell, given only the signal-in-space definition as of July 1993. (I have been unable to find ICD-
GPS-200 on the web. I am told it may be obtained from the GPS Program Office, in the US Air
Force.)

I now have found a more recent authority document to reference. The GPS SPS Signal
Specification, 2nd Edition, issued on 2 June 1995, repeats the words and warnings of ICD-GPS-
200. The GPS SPS Signal Spec does cover the bulk of what's in ICD-GPS-200, and covers the
rollover problem exactly as well as does ICD-GPS-200. The GPS SPS Signal Specification may
be obtained from the web as an Adobe Acrobat (.pdf) document, at
"www.navcen.uscg.mil/gps/reports/sigspec/sigspec.htm".

I have posted notices to a number of relevant newsgroups (NTP, GPS, and Risks). So far,
nobody has even claimed that rollover won't happen, let alone provided a convincing argument.
I did get one now-explained then-inexplicable war story, and a number of questions, and a few
thank-you notes. But, it's been a lot quieter than I would have thought. I think that many more
people care about navigation accuracy (unaffected) than time accuracy (sometimes severely
affected). And, not that many people read such arcane newsgroups.

A fellow at DEC, reacting to my postings, suggested that one can use the offset between UTC
and GPS, currently eleven seconds and increasing more-or-less linearly, as a way to tell which
1024-week cycle you are in, at least for the next few cycles. I have looked into this, and it does
appear to be workable, if rough. If one burns both the date of manufacture and the then-current
value of the GPS-UTC offset into the firmware, it should allow the firmware to solve the rollover
problem for at least three GPS cycles, almost 60 years, which should suffice. The leap-second
story is at"http://tycho.usno.navy.mil/leapsec.html".

I have gotten some email traffic indicating that, just as I had suspected, some manufacturers did
realize that GPS would soon roll over, and were keeping it to themselves in the hope that the
others would fall upon their swords. I have subsequently found more indications that some
manufacturers know, but are keeping it to themselves. One claims to have a solution, the details
of which are proprietary. Not pretty.

Our supplier was dumbfounded when I raised the issue, couldn't stop thanking me for pointing it
out years before rollover. They clearly feel that it could have been a life-threatening disaster for

C7



FESO A SASSO GCC CCIGI ICI ICICI ICICI C1 a 21 1 831 1 a A IR AE A aC OR CAC A A ACR a A I

TEST AND EVALUATION YEAR-2000 TEAM REPORT

Section

Appendix

A.

to the

Test and Evaluation Board of Operating Directors

September 30, 1996

TABLE OF CONTENTS

Title
Executive Summary
Potential Year 2000 Problems
T&E Year-2000 Team Findings

Recommendations

APPENDICES

Title

Enabling Correspondence and Action Plan
for T&E Year 2000 Assessment Team

Study Methodology of the T&E Year 2000
Assessment Team

T&E Year-2000 Team Interview Results

Testing Your Desktop for Year 2000 Compliance

Matrix of Commercial Offerings to Resolve
Year 2000 Questions

Page No

iii

16

Al

Bl

Cl

D1

El

SE SR AC Of ff A OR RO ERR EO A AR CCA AC OC COR FE Ra oe ao ok a

i



Questionnaire - Year 2000 Survey Team

1.

3.

ge

To what extent does your organization directly support TRE?
What is your core T&E function?
Are you aware of the Year-2000 issue?

a) If aware - How are you affected (mission critical (e.g. safety system), minor
impact (date on Xerox machine, phone LCD), etc)?

b) If unaware, do you have resources to assign to assess the impact?

What is being done?

a) External direction?

b) Local plans/action?

Do you have a complete inventory of all computer resources (hardware, software,
firmware and archival systems).

Do you know which of your systems/platforms/computers are affected?

To what extent do external’ interfaces affect your internal operations (e.g. Flight

Scheduling, supply, finance)

What are your estimated costs to become year-2000 ready

Are there other organizations you support or are supporting you that we should talk

to?

OR SCR HC I CR AR SCR SAC CC RCC A Cf oR IO AE RO OR I A Ef EO of fa of EE

B3



related applications based data. When set to filter for year related data, theoretically the results
yield instances of date relevant manipulations and isolates real date activity from mere date
stamps. The problem is that the extent of fidelity, as of July 1, 1996 remains untested and,
therefore, unproved. While the concept is sound, it is, however, based on some degree of
statistical accuracy yielding less than a 100% solution set. Nonetheless, when used in
conjunction with code parsing where practical, the emerging DBSTAR approach makes sense.

D. RELATED DOD ACTIVITIES: As evidenced by the growth in DoD sponsored Year-2000
Home Pages on the World Wide Web since the T&E Year-2000 Team initiated its activities, all
the services are now deeply engaged in Year 2000 activities. These pages are rich in service
based findings and contain many vendor specific tools and solutions. This level of service
activity is further confirmed by direct liaisons established between the T&E Year-2000 Team
and the Army, Navy and Air Force headquarters level teams. To date, most of these teams have
produced nothing beyond the scope of what is reported herein. The Air Force headquarters C4
team, however, has devised a detailed service wide action plan that is gaining wide recognition in
the Federal Government. This approach follows the sequential steps of awareness, assessment,
renovation, validation and implementation. Under this tightly scheduled plan, 1999 becomes the
year of testing. The salient fact, however, is that, as expected, the services are taking this matter
very seriously. Another important contribution came via the well received Year 2000 study
performed for DoD by the Mitre Corporation. It is also significant to note that certain Federal
Acquisition Regulations have already been modified and will continue to be changed to rectify
Year 2000 matters in Federal procurements.

Finally, a May 1996 publication, the Naval Information Systems Management Center (NISMC)
Information Update, provided the following ASD(C3I) Year 2000 guidance:

(1) Ensure vital systems do not fail from date change;
For Existing Systems, both:
-Take corrective action during normal systems maintenance or upgrades, and
- Embedded systems may need ‘out of cycle’ maintenance.
For New Systems:
- Ensure vendors will warrant fault free performance in processing data and date
dependent data (including, but not limited to calculating, comparing and
sequencing) from contract date, not the year 2000.
(2) Report defects in key systems projected to extend into or beyond year 2000 through
service or agency chain of command.

E. FINDINGS SUMMARY: The Year 2000 problem came seemingly out of nowhere and
slapped a huge prospective bill on the DoD doorstep. As noted above, just how large this bill
will be for the T&E community is difficult to ascertain. Unlike most business computing at
corporate levels, T&E computer assets differ greatly and are widely dispersed within range sites
making the matter of approximating costs to find and eliminate the problem circumstantial and
exceedingly difficult to substantiate without significant investment in impact analysis. According
to the testimony of managers and engineers interviewed for this task and the results of the tests,
the Year 2000 flaw is present in at least some scientific and support computing at the ranges, but

14



Year-2000 Problem
Near Term Plan of Action and Milestones for T&E

OBJECTIVE: The objective of this POA&M is to develop a workable plan for the TRE
community to deal with a "Year-2000 Problem" that involves year representation in automated
systems and software. This POA&M is in response to an OSD/DTSE&E Memorandum date
January 1996.

SCOPE: Assess T&E vulnerability to the Year-2000 problem, define the related business and
technical impacts, review other organization's Year-2000 efforts and identify a range of options
for the T&E community to address this issue.

BACKGROUND: There is a real risk that automated systems, including software applications,
will yield inaccurate results at or near the century change if the year is represented using only
two digits. This problem manifests itself when the year becomes "00". As the century cannot be
determined, the computation on the "00" year can lead to totally inappropriate answers. Often a
"00" or "99" in the automated year representation indicates an accepted "default" condition. In
such cases, the year problem can manifest itself as early as the year 1999. This problem also
immediately affects any forecasting system that expresses the year in two digits and projects into
the next century. Even if a system is updated to account for four digit year representation, it is
still vulnerable to other systems that feed it two digit year information. Such information is
frequently embedded in "intelligent numbers", such as Job Order Numbers. Even many personal
computers have design susceptibility to this fault.

ASD (C3J) has notified all DoD of the impending risk. The T&E community is
vulnerable in real-time operations such as weapon system testing, range and flight safety
systems, and time critical data processing where two digit year representation may be involved.
The full range of business systems that support T&E are also in jeopardy of failure at or before
the Year 2000. The recent "Year 2000 Blueprint for Success" conference, heavily attended by
DoD, revealed that as many as 50% of all systems expected to still exist by 2000 may not be
Year-2000 compliant. Conference speakers noted that a top down approach is required to achieve
success. A SECDEF Memorandum of 27 November 1995 establishes Year-2000 guidelines for
new start acquisition programs. Other DoD initiatives are taking shape.

APPROACH: Given the pervasive nature of the Year-2000 problem and the ongoing initiatives
to address it, the T&E approach should be proactive but not duplicative. To formulate such an
approach, we propose forming a small group of T&E experts to answer a number of key
questions: determine the evolving guidance and other initiatives at service and related functional
areas; assess the extent of T&E specific vulnerabilities and how to pinpoint them; and heighten
universal T&E awareness of the Year-2000 problem and the range of potential methods and
solutions that can be brought to bear. An assessment criteria may be developed by which high
leverage T&E systems are identified early and targeted for Year-2000 upgrades. Issues dealing

A3



SECTION 3: RECOMMENDATIONS: Based on the statements of interviewees and the
evidence from its cursory research and analysis, the T&E Year-2000 Team does not see a
compelling reason to immediately launch localized teams of experts at the engineering
applications or supporting hardware/firmware to ferret out all offending date instances in T&E.
This is not to imply that the Team is satisfied that Year 2000 impacts are not hiding in scientific
and engineering systems in the T&E community. The fact is that they are and will undoubtedly
remain hidden in some applications and in some embedded code until they are discovered, either
by intent or by accident! They do not appear, however, to be as mission threatening as is the
case with business applications. The Team feels that as awareness grows scientists, engineers,
and technicians will be alert to Year 2000 instances and more and more problem situations will
be resolved. The Team also feels that there is sufficient time available to convert systems to Year
2000 compliance if awareness campaigns are sufficiently promoted and timely actions effected.
Awareness was a chief concern at the outset, but the Team has seen the rise of several new
efforts in DoD in response to this problem with a concern for both business and weapons
systems.

A. RECOMMENDATION 1: There is the need to establish a centralized facility equipped with
selected Year 2000 tools, an established Year 2000 methodology, established access to proven
Year 2000 vendors such as are available through GSA, and a small cadre of experts trained in the
methodology, the tools, and in assisting requesting commands to identify and resolve Year 2000
problems throughout the T&E community, and coordinate and track the effort DoD-wide.
Therefore, the Team recommends the establishment of a “T&E Year-2000 Clearing House” to
assist DoD components resolve their Year 2000 transition problems. As noted in Section 1.,
Year 2000 conversion in DoD is a major management issue. Technical considerations, as
pervasive and challenging as they may be, are, nevertheless, secondary when compared to
managing the effort. That is why the Team considers that a focused approach to the Year 2000
conversion effort is required. Otherwise each command must pursue the turn-of-the-century
transition independently with attendant lose of uniformity and economics. Operating
independently, commands may or may not acquire a Year 2000 tool set, hire contractors, assign
staff and develop expertise in solving Year 2000 problems they consider unique to their
individual environments. Moreover, once the crisis has passed, such investments will no longer
be of use and would be considered lost as sunk costs. These costs could be significant if repeated
at every range and will only increase as the elapse of time makes repairs more paramount. Thus,
the “Clearing House” approach provides top T&E management a cost effective vehicle to ensure
that attention is focused on discovering Year 2000 problems everywhere, uniformly resolving
them , and reporting results.

An immediate task of this team would be to develop certification criteria for T&E System Year
2000 compliance. The team should be required to integrate its efforts with established Year 2000
Offices at the DoD and Service levels. Given the economy of scale through this clearing house
approach, 2% of its estimated investment for immediate centralized problem identification and
planning per the OAO model seems prudent. Thus, the team recommends an immediate “start-
up” investment of $3M for establishment and operations of the “T&E Year-2000 Clearing
House” in FY97 with future funding based on measured “Clearing House” contributions. The

16



SRR SR CR CR CR AO CCAR CR ACO RA AE RR RE CR ER A A A A

APPENDIX C:

T&E YEAR-2000 TEAM INTERVIEW RESULTS

NAVAL AIR WARFARE CENTER - PATUXENT RIVER, MARYLAND

Mr. George Ryan (4/15/96).

Mr. Ryan serves as the director of the Atlantic Range and Facilities at NAWCAD. He was
generally aware of the Year 2000 issue. He expressed a willingness to spread the word among his
Department heads. He did not have a personal assessment of the scope of the problem or the
cost to repair it, but felt it did have relevance to his organization. He was most supportive of
further investigation of the problem.

Mr. Ron Runyon (4/17/96).

Mr. Runyon serves as the Deputy Comptroller at NAWCAD. He was generally aware of the
Year 2000 issue. He was most concerned with the ability of Central Design Agents (CDAs) who
support feeder systems such as NIFFMS, NALCOMIS, DCPDS to resolve their Year 2000
problems in an effective way before they affect NAWCAD corporate systems. He felt he was
largely dependent on the Information Management Department (IMD) to resolve any lingering
Year 2000 issues within local business systems upon which he must rely. He was fully aware of
the ORACLE four digit date field convention. He felt archival data, which is used frequently,
was particularly vulnerable. He cited RAPS, Travel On-Line, NIFMAS, PAXIS and the
Command Workload Data Base as the key systems upon which he relies. He expressed a
willingness to be part of the solution. He will assign a Comptroller lead to inventory all systems
and assess priorities ,e.g., the current payroll system has two digit date fields. He felt every
system that produced output through precalculation required scrutiny (e.g. all invoices). He
expressed a strong need for IMD support. He felt this work, particularly on current systems,
would have to be accomplished at night or over weekends on overtime. The workload with the
increased Patuxent River population will be huge on its own right.

Production systems involve current transactions and, as such, are dynamic systems. He also felt
much could be found and corrected through periodic data maintenance activities in so far as
archived data were concerned as no transactions are typically run against such data. He expressed
aneed to reach out to CDA POCs and PMs to express our concern for their proactive response.

Mr. Chuck Lancaster (4/17/96).

Mr. Lancaster heads the Scientific and Engineering programming effort for NAWCAD, Patuxent
River. His focus is.on Computer Aided Software Engineering (CASE) tools, Training Ranges,

cl



AFFTC, Edwards AFB Estimated Business System Year 2000 Costs:
. $ 200,000

3. GENERALIZATION TO THE MRTFB COMMUNITY: The wide variance in these honestly
derived Year 2000 compliance costs makes the T&E generalization question most difficult to
answer. A rough average of all costs defined in this survey comes to $8,254,000 per site to
correct scientific and business systems for Year 2000 problems. Applied across all MRTFB sites,
the total estimate for achieving nominal Year 2000 compliance exceeds $150,000,000. This
figure, while in keeping with T&E’s share of larger DoD estimates, however, is largely a best
guess. The estimates from the sites studied were not rigorously developed based on detailed fact.
Their wide range further adds to the uncertainty. Moreover, the costs to identify the true extent of
the problem were not really calculated into the estimates provided. Thus, the estimates do not
reflect the discovery cost to perform inventories, triage “at-risk” systems and interfaces and
establish solid configuration management practices where required. Given these factors,
combined with the need to impress on management that the real problem may not meet the eye,
the loosely derived estimate may well prove to be precipitously low. The perplexing problem is
that to produce a serious Year 2000 business case requires a significantly detailed assessment of
the real Year 2000 impact across all MRTFB installations. This effort in and of itself could easily
cost more than $15,000,000 based on the best available industry estimates of 10% of the total
estimated implementation cost.

C. INDUSTRY TRENDS: T&E Year-2000 Team participants conducted a detailed literature
search of commercial enterprises offering Year 2000 solutions. Much of this literature was
available via the World Wide Web (WWW). The Test and Evaluation Community Network
(TECNET) Home Page contains a growing number of significant DoD related Year 2000
references. This page is http://tecnet1 jcte.jcs.mil:8000/. A number of team participants also
attended key Year 2000 conferences and public Federal meetings where additional commercial
information and Year 2000 insights became available. From these meetings, the team identified
two innovative industry leaders to evaluate via direct interaction. These organizations included:
OAO Corporation which possessed an omnibus task order from the General Services
Administration (GSA) and DBSTAR which offered a unique, but unproved data oriented
approach to Year 2000 assessment. Appendix E contains a tabular compilation of significant
Year 2000 commercial offerings as compiled by the T&E Year-2000 Team.

1. The clear mandate within the recommended industrial trends was to perform a detailed
assessment of all existing code. The most recommended procedure was to literally parse all of
the code for instances of Year 2000 year manipulations that could create serious
misrepresentation problems. This practice goes well beyond a mere inventory of code. (which is
a necessary first step). Rather it requires that this code be analyzed in great detail. Several
vendors and private organizations experienced in Year 2000 problem solving reported that
attempts to analyze code for date instances by human examination only meet with limited
success. Such experiences demonstrate that separate groups of analysts and programmers all
examining the same code will invariably find different sets of instances. Both data elements and
data values that appear to represent dates to one group may not be at all apparent to another.

ll



- day-of-the-week calculations. February 28, 2000 is a Monday and 1 March is a Wednesday,
not a Tuesday which is February 29, 2000.

- week-of-the-year calculations. The 11th week of the year 2000 is 5 through 11 March, not 6
through 12 March.

If the programs that manipulate date information are not properly calibrated for this special once
every 400 year case, date representation will be amiss after the leap year is in effect.

5. DAY CLOCK: The “Day-Clock Problem” involves an even deeper abstraction. Some
operating systems (software) are built such that the default date will revert to something other
than the actual date when the century rolls to 2000. In such cases, depending on the operating
system, dates may or may not be represented correctly, but file storage schemes will be
inaccurate. Most existing DOS BIOS implementations (hardware) also have such problems.
Thus, many personal computers (PC) have design susceptibility to this fault. Their Real Time
Clock (RTC) chips (a hardware component) keep dates as “century/two-digit year/month/day”
but their DOS (operating system - a software component) date is kept as “days-since-
1980/01/01”. On January 1, 2000 the RTC will roll 99 (two digit year) to 00 but the century
remains at 19, so, we have 19/00/01/01 and the date 01,01,2000 effectively becomes 01,01,1900.
Seemingly, DOS correctly handles the change making any date APPEAR correct to the computer
user. The result, however, is an internal date conflict which the computer date conversion
algorithm attempts to resolve by calculating an erroneous date such as 1980-01-04 or 01/01/:0.
Users will be unaware of the problem until they reboot and attempt to access a file with the
erroneous storage/creation date. Over time, all files created after the century roll over will have
that same erroneous creation date. Access to the “real” file may not be available or out of
sequence. Other instances of this problem could have devastating results on archival or backup
data labeling. ( Note that many PCs manufactured since mid-1995 are Year 2000 compliant and
others contain a programmable BIOS chip that can be upgraded by diskette).

6. LICENSE EXPIRATION: Most insidiously, commercial software offerings containing an
embedded license expiration date may go dead at the year 2000 rollover. Worse, if the license
code is definitive, affected commercial software will be “turned-off’ permanently when it “sees”
a year of “00”. This could happen even when only experimenting to see if the Year 2000 problem
exists within other components of the computer system.

B. IMPACTS: These vulnerabilities are compounded by a number of practical considerations.

1. EXTENT OF THE PROBLEM: The Year 2000 problem is pervasive and has a well known
deadline. It particularly extends to aged legacy systems. In such cases, the source code that
produces the undesirable Year 2000 results may well be unavailable, unreadable, impossible to
recompile, undocumented or legally inaccessible because of contractual “ownership” issues. In
other cases, Year 2000 compliant systems are negatively affected by input data from other non-
compliant systems. In fact, studies reveal the majority of Year 2000 problems will manifest
themselves at the interface level. Often this problem is aggravated by less obviously involved



SE SR HCA COR SSC CAC CO CCR AC RR oO EO AR CR IC AO of AC EE

APPENDIX B:
STUDY METHODOLOGY OF THE T&E YEAR-2000 ASSESSMENT TEAM

The T&E Corporate Information Management (CIM) office in the Joint Program Office for T&E
(JPO(T&E)) proposed formation of a T&E Year-2000 Assessment Team to the Board of
Operating Directors (BoOD) for T&E. The proposal was approved by the BoOD on March 5,
1996. The team was assembled under the leadership of Mr. Lloyd (Jerry) Brown of the Naval Air
Warfare Center Aircraft Division, Patuxent River, Maryland in late March. The tri-service team
began meeting on April 3, 1996. The final report was due to the JPO(T&E) by early July 1996.

A. SPECIFIC TASKING: The T&E Year-2000 Team was tasked to develop a workable plan for
the T&E community to deal with the "Year-2000 Problem". This plan is to assess T&E
vulnerability to this problem, define the related business and technical impacts, review other
organization's Year 2000 efforts and identify a range of options for the T&E community to
address this issue.

B. ALTERNATIVES CONSIDERED: The T&E Year-2000 Team considered three leading
alternatives to achieve its tasking within the assigned schedule:

1. TOP-DOWN WALL-TO-WALL SURVEY: The team seriously considered conducting a wall-
to-wall survey of all software running within the TRE community as a first step to assess the
impact of the Year 2000 problem. Some existing resources, such as the T&E CIM Automated
Information System (AIS) study and the Joint Test Assets Database (JTAD) were evaluated as
starting points. Upon further examination, however, neither of these resources were sufficiently
detailed in terms of Year 2000 related information to yield meaningful results. Moreover, these
resources, each resulting from top-down surveys of their own, took far longer than 90 days to
compile. Thus, such an approach was deemed impractical for the near term. The team also felt
that the services would eventually call for such extensive surveys, making the T&E effort in this
area duplicative at best.

2 BENCHMARKING: The team also considered conducting a formal benchmark study on an
organization similar in nature to the DoD T&E infrastructure. This idea was abandoned when the
question of a suitable study partner with close parallels to the overall DoD T&E community in
diversity and complexity became too difficult to answer. The team felt the extent of general
acceptance of the Year 2000 transition problem in April 1996 was still too tenuous, even if a
suitable benchmark study partner were to be identified.

3. CASE STUDY APPROACH: The team also considered focused case studies within identified

portions of the T&E Major Range and Test Facilities Base (MRTFB). This approach used
existing team resources to the fullest possible extent. The team felt that the findings from this

Bl



MEMORANDUM FOR COMMANDER, ABERDEEN TEST CENTER
COMMANDER, AF FLIGHT TEST CENTER
COMMANDER, NAWC AIRCRAFT DIVISION

SUBJECT: Year 2000 Software Issues Survey Team

Senior government and industry officials have identified a potential serious problem
associated with the date coding that will impact most computers and software in the Year 2000
(see attachment). The Test and Evaluation Board of Operating Directors (BoOD) has established
a quick action team to survey the selected Service ranges and identify the risks of this serious
problem to the T&E community. In the June, the BoOD will distribute a report of this team’s
findings to every T&E organization to help mitigate the impacts of this potential problem.
Respectfully request your facility cooperate with this study team on a minimum interference

basis and help to provide the T&E community an assessment of the severity of this problem.

TODD STEVENSON, GS-15
Acting Director

1 Attachment
Action Plan for T&E Survey Team

A6



LR SES SR SA SR CR RC ER CACO OR AE ER ER CE AO A A ACO OF a CAO

TEST AND EVALUATION YEAR-2000 TEAM REPORT
to the
Test and Evaluation Board of Operating Directors
July 10, 1996

EXECUTIVE SUMMARY: The Test and Evaluation (T&E) Board of Operating Directors
(BoOD) commissioned a T&E Year-2000 Team in March 1996 to assess the vulnerability of the
T&E community to Year 2000 problems and their impact within the Department of Defense
(DoD) T&E community. These problems are those which will affect computer based systems at
or near the transition to the year 2000. These problems can lead to possible year
misrepresentation internal to computers, their associated programs and their related data stores.
The T&E Year-2000 Team focused on case studies within the Major Range and Test Facility
Base (MRTFB) to extrapolate an assessment of the overall Year 2000 issue as it pertains to T&E.
The team also surveyed parallel DoD efforts and commercial support available to resolve Year
2000 issues. The team discovered that the T&E community was vulnerable in subtle ways to the
Year 2000 issue. We learned that many major scientific and engineering computer applications
were exempt by merit of the state of the art environment in which they run or the nature of the
applications themselves. While many of these primary applications may well be Year 2000
compliant, the related subsystems, utilities, feeders and management systems upon which they
depend are not. Thus, where they exist, Year 2000 problems in the T&E community are deep
seated, rooted in subtle interfaces and not patently evident. Prevailing commercial practices
recommend an end-to-end review of all existing code for potential Year 2000 problems. Often,
however, the necessary code parsing tools are unavailable or, when available, require costly
expertise to run. Moreover, the original source code may no longer be available in many
significant cases. For these reasons, the T&E Year-2000 Team recommends a methodology
whereby the actual data artifacts from T&E systems be analyzed for instances of Year 2000
problems when the actual code is unavailable. This can be most economically accomplished by a
central T&E “Year-2000 Clearing House” which would impartially screen data submitted by
T&E installations. The resulting annotated data maps and/or code reviews would then be shared
with the affected installations for Year 2000 problem prioritization and repair. A significant side
benefit is that data maps, when created, also serve as substantive analytical tools for broader
enterprise re-engineering initiatives. Once the high priority code is corrected at the installation
level, subsequent testing would be performed by the T&E “Year-2000 Clearing House”. This
approach minimizes the number of knowledgeable tool practitioners and reduces the overall cost
and effort necessitated by data analysis and code parsing at the local level. Moreover, as the T&E
“Year-2000 Clearing House” gains proficiency, it can offer its services to other DoD elements
and thus, potentially reimburse or exceed the initial investment necessary to get it operationally
proficient. The team also strongly recommends a program urgently aimed at heightened
awareness of the importance of this problem.

FE SAIS ICI SIO I CISC RSC IRA ICI SCC IC CR 11 of Cf CR CR CAC CC ACCA AC EC

iii



SERS CRO SIO SR ACR CER FC OR CR RC CORR OR ER COA A ER CEA RCE A EE AE A A A of A HE

FIGURES
Figure Title
1 Y2K Cost Estimate for Sample T&E Activity 9
2 Representative Year 2000 Profile 12
3 T&E Year 2000 Cost Profile 13

SR SR oC CR CC CCR CR CO oA AoC EC Ao OR SOR EO CR EO CEO CO

ii



This is due to the so-called “creative” nature of coding without standards. Clearly, tools are
needed. A number of powerful code parsing tools exist for this purpose. These tools generally
evaluate the code from the standpoints of: Calls to the Operating System, Date formats, Variables
containing dates, Buffers, and Year defaults. However, most of these parsers are largely aimed at
mainframe computers running a large complement of COBOL programs. The more diverse the
language base used, as is the case in T&E, the greater the odds that suitable parsers are
unavailable, much less the necessary compilers. Thus, T&E investment in parsers and the
knowledge to run, or worse yet, create them could be great. The cost of such analysis is estimated
at $35,000 per 1,000,000 lines of COBOL code, assuming a homogeneous code base. OAO, the
General Services Administration’s (GSA) Year 2000 vendor, estimates this initial assessment
effort consumes about 10% of the necessary work to eradicate the Year 2000 problem.

2. Another 15% of the Year 2000 effort, according to OAO, involves assessing and testing tools
for repairing and testing for compliance once the original diagnostics have been performed.
Assuming the completed diagnostics and a reasonable tool set, the next 10% of effort involves
planning with confidence for code correction, testing and implementation. This last phase
consumes some 65% of the overall effort. These estimates were supplied by OAO Corporation,
which is the firm selected by GSA to support and help coordinate Year 2000 activities
throughout the Federal Government. These percentages are illustrated in the FIGURE 2 Pie
Chart. FIGURE 3 applies the OAO model to the estimated Year 2000 T&E costs (Business and
Scientific computing).

Representative Year 2000 Profile
GSA Estimated Cost
(per OAO Corp Study)

Fix & Confirm
65%

Management
10%

Code
Assessment

10%

Diagnostics
15%

FIGURE 2

12



A. VULNERABILITIES: The “Year-2000 Problem” is actually a combination of several
component vulnerabilities related to transition to the year 2000.

1. TWO CHARACTER YEAR REPRESENTATION: The largest and best known class of
“Year-2000 Problems” involves the use of two digit fields to represent the year. In less
technically sophisticated times when computer storage was at a premium, such two byte year
representation was a common convention to conserve space. The characterization of this
phenomena appears when two numeric or alphabetic characters are used as a variable data
element to represent the year only to the decade level. In these cases, the century is assumed to
be a “19”. In some cases, the “19” may actually have been hard coded. Often, the two digit year
characters are embedded in a larger date field. For example, a representation of MM/DD/YY
places the two character year at the end of the larger date string. In other cases, such embedded
dates are more subtle. Examples where strings of data may impart year intelligence include
contract numbers, invoice record numbers or Job Order Number (JON) where the year is
embedded as a two character portion of the larger number. In all these cases, the assumption that
the century is “19” will convey into the year 2000, resulting in incorrect date and day of the
week representation in all resulting instances of date information beyond the transition.

2. RESERVED CHARACTERS IN YEAR FIELDS: A related problem involves the use of the
characters “99” and “00” in year fields. Often these numbers are reserved in year fields to denote
special conditions that affect the computer program operating on this field. For example, the date
string 9/9/99 is often assigned by convention to mean “unlimited” or “unconstrained” date data
is to be used. The string of “99” in the year field may also indicate such things as default values,
the last record in a series of input records or a “null” value. In such cases system “rollovers” on
January 1, 1999 can trigger specific misrepresentations of year data to occur a full year ahead of
the year 2000. Likewise, use of “00” in the year field may indicate a null record or denote an
interrupt vector. In such cases, many applications run in 1999 will be against transactions for the
year 2000. In both instances any system which forecasts transactions by date are in jeopardy.

3. DATE-IN-KEY: Another issue involves data input. The “date-in-key” problem involves the
use of interactive screens to capture date information. Even if the year is internally represented as
four digit century data, the on-line capture field may use the two digit representation to conserve
valuable screen “real-estate”. In such cases, programmatic resolution will be required to reconcile
the century level year differentiation. The software language vendor should be contacted to
ascertain a solution to this problem.

4. LEAP YEAR CALIBRATION: The Leap year issue is even more subtle. A specific year is a
leap year if it is evenly divisible by 400 OR evenly divisible by 4 and not evenly divisible by
100. Thus, the year 1900 was not a leap year but the year 2000 is. Some potential exposures
caused by the identification of the year 2000 as a non-leap year are:

- day-in-year calculations. The year 2000 has 366 days; not 365.



RSS AACR SC ACR SCR COR CR CC OR CE ACR CR ACR RCE A BO A oo

APPENDIX A:
MAR 19 1996
MEMORANDUM FOR CNO (N91)

FROM: Chairman, T&E Board of Operating Directors
4225 Logistics Ave, Suite 2
Wright-Patterson AFB OH 45433-5714

SUBJECT: Test and Evaluation Software Conversion for the Year 2000 Changeover
(DTSE&E Memo, Not Dated)

1. Per the subject memorandum, the Board of Operating Directors (BoOD) was tasked to
establish a program to ensure that all systems expected to migrate through the Year 2000 are
compliant with SECDEF Memorandum, dated 27 November 1995. Specifically, a plan of action
and milestones (POA&M) was developed to assess T&E vulnerability to the Year 2000 problem,
define the related business and technical impacts, review other organization’s Year 2000 efforts,
and identify a range of options for the T&E community to address this issue. This POA&M for
the Year 2000 Software Issue is attached. Recommended funding source for execution of the
POA&M are T&E Corporate Information Management (CIM) Central Funds. The estimated
funding required was $60K.

2. The subject tasker also requested a briefing on the plan of action to provide a plan to the
Defense Test and Training Steering Group or the T&E CIM/EI Steering Council, as appropriate,
in March 1996. The T&E CIM Director, Col Spencer, is prepared to present this briefing when
directed.

3. The BoOD POC for this action is Col Spencer, T&E Joint Program Office (JPO), Director,
DSN 858-4755.

\signed\
FRANCIS C. GIDEON, JR
Major General, USAF
Chairman

Attachment:
POA&M
cc: (listed on next page)

Al



INTERNET DOCUMENT INFORMATION FORM

A. Report Title: Test and Evaluation Year-2000 Team Report

B. DATE Report Downloaded From the Internet: 10 Sep 98

C. Report's Point of Contact: (Name, Organization, Address,
Office Symbol, & Ph #:) George Hurlburt

NAWCAD

Patuxent River, MD

D. Currently Applicable Classification Level: Unclassified

E. Distribution Statement A: Approved for Public Release

F. The foregoing information was compiled and provided by:
DTIC-OCA, Initials: _ PM__ Preparation Date: 10 Sep 98

The foregoing information should exactly correspond to the Title, Report Number, and the Date on
the accompanying report document. If there are mismatches, or other questions, contact the
above OCA Representative for resolution.



OR CS CE A CCR I CR ER HCE A CR IR ER CR FC A A EC RO

APPENDIX D:

TESTING YOUR DESKTOP FOR YEAR 2000 COMPLIANCE
For MACs:
A. From the Control Panel select “Setting Date And Time”.
B. Using the up/down arrows:
1). Set the date to 12/31/99.
2). Set the time to 11/59/01 (minutes and seconds are arbitrary).
C. Select OK or CLOSE the dialog box.
D. Select “Setting Date And Time” again.

E. The date should be at 12/31/99 and the time should be advancing.

ico]

. Wait until the date changes (should roll over to 01/01/00).

. Time should be advancing.

mo

Close the dialog box.
I. Create and save a file.
1) Select the Apple icon from the menu bar.
2) Select the file type (ex: Microsoft Word) from pull down menu.
3) Select File from the menu bar.
4) Select New from the pull down menu.
5) Select the desired Template (ex: Normal).
6) Enter anything into test file.
7) Select File from menu bar.
8) Select Save or Save As from pull down menu (save to your Desktop).
9) Enter the document (file) name (ex: testy2k.doc).
10) Select Save.
J. Select File from the menu bar.

K. Select Quit from the pull down menu.

Di



SECTION 2: T&E YEAR-2000 TEAM FINDINGS: The following section details T&E Year-
2000 Team findings from the initial case study approach:

A. INTERVIEW RESULTS: The specific results of the focused team interviews may be found at
Appendix C. The Year 2000 problem is not trivial within T&E, but may not be as widespread as
initially feared within primary applications employed by the T&E community. The outward
appearances are that a large number of primary functional applications are totally exempt from
Year 2000 related problems. The hidden component of the Year 2000 issue, however, still exists
beyond and beneath the obvious functional considerations found at the applications level. The
Year 2000 transition problems definitely affect significant portions of the business, scientific and
desktop systems within the entire T&E community. The real issue is that these problems, where
they exist, are insidious and not self-evident by the casual observer or even the dedicated user.
The interviews indicated that most managers were willing to learn more about the Year 2000
problem and take necessary actions. There was, however, a subtle undercurrent of denial in the
sense that the problems were attributed to “someone else”, such as vendors or program creators,
or that the problem was not immediately observable, so therefore must be trivial.

1. BUSINESS SYSTEMS: Business systems are clearly the most susceptible to serious Year
2000 problems at MRTFB sites. Many business systems and corporate information systems at
the ranges, however, run under modern database management systems (DBMS) such as Oracle
and its tools. Systems running under such DBMS are considered "safe" in so far that these tools
force four place date fields within the databases themselves. Most "major" business systems have
been or will soon be converted in the Navy and Air Force sites studied. The Army, however, still
employs mainframes running a significant number of Common Business Oriented Language
(COBOL) programs and earlier vintage databases. These applications are highly suspect in terms
of potentially undesirable Year 2000 instances. Additionally, all remaining legacy business
systems, small localized feeder systems, and unconverted middle-ware supporting major systems
at all sites are in the most jeopardy of creating major Year 2000 problems at the T&E sites. Feeds
from externally managed Central Design Agent (CDA) systems and other external feeder
systems regardless of size which are not corrected for the year 2000 pose a significant, but
presently not yet fully dimensioned, risk throughout the business data processing community
within T&E. As has been reported by industrial Year 2000 practitioners, the primary Year 2000
problems are at the interfaces between related systems. Thus, while primary systems may well be
“date safe”, the integrated operations they support may well be highly vulnerable to Year 2000
failures.

2. SCIENTIFIC SYSTEMS: Scientific systems appear by the testimony of their managers to be
less vulnerable to outright Year 2000 problems. While their specific “face-value” Year 2000
vulnerabilities appear to be less widespread, the threats are far more subtle in nature where they
do exist. Most scientific applications deal substantively with the passage of time and the precise
measurement of elapsed time in a relative sense, but few involve time calculations which include
dates or years. Such "date free" systems are exempt from Year 2000 problems by all apparent
functional measures. Some specific areas of vulnerability, however, appear to lend themselves to
a higher probability of Year 2000 occurrences within the T&E scientific computing community.



embedded software in systems and subsystems. The rapid growth of electronic communications
systems also tend to propagate and worsen this potentially serious phenomena.

2. HIDDEN NATURE OF THE PROBLEM: The manipulation of date information can often be
hard to discover. Date manipulations may span hundreds of lines of code within a given
application. In some instances, these manipulations can occur across related programs or within
or among supporting utilities. Often, year manipulations are embedded in controllers, firmware
based micro-code, operating systems, real-time clocks and other less than obvious system level
resources. Thus, even if the application has no apparent date manipulation algorithms, it still may
not be exempt from one of the Year 2000 related problems. A simple example of this phenomena
is a subroutine that date stamps the header information in archival tapes regardless of the rest of
the content.

3. TESTING THE PROBLEM: Testing for Year 2000 compliance yields other problems. Even if
a single application is compliant, its testing must be synchronized with companion applications
which may pass date information to assure the overall system of applications is safe to run. This
problem is non-trivial. Worse, large production systems cannot be shut down for testing. Even
where possible, testing with the year 2000 change can create unexpected havoc among existing
production data. In most cases, setting up a parallel system for tests is utterly prohibitive by cost
or practical considerations.



Viasoft, Inc. YES [Determine scope, size, level of [MVS operating system, including
"Enterprise 2000" effort. Identifies project IMVS/XA and MVS/ESA supporting
reqmnts
Phoenix, AZ fand prepares work plan. products that run in the following
Manages
(602-952-0050, Fax 602- fimplementation and testing of environments: COBOL/370, OS/VS
840-4068
itp://www:viasoft.com [changes, ie., plans, manages, |COBOL, ANSI COBOL; CASE-
land
implements changes. [generated Cobol; Cobol D, E, and F;
CICS, DL/I, IDMS, and SQL;
Workbench
WANG YES Impact Analysis
703-827-3800 Conv Planning
Fax 703-827-3406 Code Conv & Data Conv
Testing & Implementation

[Compiles a list of business

[processes from which
applications

and data bases that support
each

process are determined.

‘Compiled as of 5/31/96

SR SR CR CR CR RS SC COR COR CO FER CoRR RE RACE fC A EA AC A a OE

E9



Mr. Carl Pee

The major Center wide business systems that are expected to continue beyond 2000 are believed
to be century aware and will not suffer significant failures. All of these systems have been
developed within the last 10 years with significant hardware/software upgrades occurring within
the last two years. The systems employ platforms (DEC Alpha), operating systems (UNIX) and
software (Oracle, Sybase) that are reportedly Y2K compliant. Initial programmers and those
doing follow-on maintenance/upgrades are generally Y2K aware. The overall feeling is that very
minor problems, if any, will occur after the Y2K change.

PC Systems/Applications

Mr. Pete VonKlargaard
Mr. Don Knight
Mr. Bruce Berger

It was generally felt that the PCs currently being used across the Center would have a minor, if
any impact at all. The majority of the systems being used are expected to be replaced prior to the
Year 2000 and those that may remain in service are felt to be century aware. Some applications
currently in use have been identified as having date problems (DB II, DB III, Access). However
it is anticipated that these applications will be replaced or upgraded prior to the Year 2000.

Engineering/Range Systems

Dr. Henry Bunch
Mr. Mike Hughes

The primary engineering/range support systems have been replaced/upgraded over the last two
years. It was felt that the hardware/software/operating systems currently being used are century
aware and will not suffer significant problems. Other range instruments such as radar systems,
cine-t’s, etc., are also planned for upgrade, replacement or mothballed prior to the Year 2000.
The overall feeling was that the Y2K will only bring a minor impact to the range/engineering
systems.

Comm/Computer System Infrastructure

Mr. Pete VonKlargaard
Mr. Bruce Berger

Some concern about the impact of Y2K on the overall infrastructure was expressed, however, no
specific problems were identified. A new telephone switch is currently being installed that the
vendor claims is Y2K compliant. Studies, such as Mitre, have reported suspected problems with
telephone switches but confirmation of such as not been shown. Further research is being done
to determine if a problem exists. The impact on Y2K on the network infrastructure is also
unknown. The network consists of numerous routers, gateways, etc., that all could be subject to

C9



4. The Range sites selected are TECOM, Aberdeen, MD; AFFTC, Edwards AFB, CA; and
NAWCAD, Patuxent River, MD. The Year 2000 team initiated interviews at some sites the week
of 15 April and expects to complete this phase of its plan before the end of May. I encourage
your support of this effort at these places. The BoOD POC for this action is Col Ken Spencer,
T&E Joint Program Office (JPO), Director, DSN, 858-4755. The Year 2000 team lead is Jerry
Brown, Naval Air Warfare Center Aircraft Division, Patuxent River, MD, DSN 342-3335.

SR SR A A A RO A Ho of OR I EA ER CO CR CE a a ACO A

A8&



L. Highlight the file you created from the Desktop.
M. Select File from the menu bar.

N. Select Get Info from the pull down menu.

O. Verify that the file create date is Jan 1, 2000.

P. If the file create date is correct your MAC computer is Year 2000 compliant . If the create date is
not correct your MAC is not compliant.

Q. Delete the test file (drag the file icon to Trash can).

R. Reset the date and time to today’s date and the correct time.

D2



MILLENNIUM DATE CHANGE SURVEY
ACTION PLAN FOR T&E SURVEY TEAM

1. The dimensions of the millennium date change , commonly called the Year 2000 problem, are
enormous. Given our reliance on computers , the failure of systems to operate properly can mean
anything from minor inconvenience to major catastrophe: Licenses and permits not issued.
Payroll checks not cut. Personnel, medical and academic records malfunctioning. Errors in
banking and finance. Accounts not paid or received. Inventory not maintained. Vital supplies
not ordered or received. Security locks not functioning. WEAPONS SYSTEMS NOT
FUNCTIONING PROPERLY. Clearly, the Year 2000 conversion should be of substantial
concern to DoD executives in both business and technical functions.

2. For the last 30 or 40 years, programmers have stored date information in “mm/dd/yy” format
versus “mm/dd/yyyy” format to conserve space in disk storage and computer memory. They
adjusted computations to take the two-digit year into consideration when computing time
periods, ending dates, and the like. And they used the two-digit date to control certain program
operations or for special purposes. At that time, most programmers and project managers figured
that their programs would not last into the twenty-first century. They were trying to perform a
service to their management by conserving expensive and limited disk space and computer
memory. Adding two century digits to a date field could add several megabytes of storage
requiring procurement of a disk that then cost upwards of $20,000. It made economic sense to
lop off the two century digits. This practice applied to some scientific as well as business
programming and continues today where traditional methods are still practiced, although popular
modern software languages now require the four-digit date field to be used.

3. Foremost in deciding what to do is estimating the extent of the problem. As a first step in
arriving at this estimate for solving Year 2000 problems at T&E Ranges, the T&E Board of
Operating Directors (BoOD) has established a quick action (90 day) team to focus on the
problem. This Year 2000 team is comprised of representatives from each service. The team
will use the case study approach concentrating on one range-site per service. It will attempt to
assess the vulnerability, impact, range of options, and cost of fixes at each of the three sites.
Generalizing from this information, the resulting findings and analysis will form the basis for
scoping and recommendations for resolution of the problem across all Ranges. This alternative
is within the team’s practical means, involves all services using limited team resources, is
scaleable and can yield a methodologically sound approach for others to follow. Data gathering
will be by means of the interview method. Review and analysis of a variety of computer-
related resource reports provided by the Range sites will augment the interviews.

A7



TEST AND EVALUATION YEAR-2000 TEAM REPORT
to the
Test and Evaluation Board of Operating Directors
July 10, 1996

SECTION 1: POTENTIAL YEAR 2000 PROBLEMS: There is a real risk that automated
systems, including software applications, will yield inaccurate results at or near the century
change. This problem manifests itself when the year becomes 2000, and, in some special cases,
1999. For example, the Global Positioning System (GPS) has a date related error in its receiver
technology which, if not corrected in all GPS receivers, will invalidate GPS positioning data
after August 1999. Business systems, heavily dependent on dates to control their processing, if
not fully corrected for Year 2000 faults, could create massive disruptions in fundamental
business areas upon which T&E depends. Functions such as payroll, accounts payable, accounts
receivable, human resources management and procurement could be seriously affected.
Additionally, T&E support systems such as scheduling tools, maintenance tracking systems and
base operations support systems are vulnerable to Year 2000 deficiencies. The TRE community
itself may be vulnerable to unforeseen disruptions in scheduling operations such as real-time
weapon system testing, range and flight safety systems, and time critical data processing. For
example, simple year related failures in older T&E data systems could interrupt operations or
even affect availability of primary test capabilities, automated target tracking systems, telemetry
systems, T&E based computational systems and vendor provided technical software. Such
failures could also lead to the disruption of data archival systems related to the storage of TRE
data.

The full extent of the potential Year 2000 problem is non-trivial. Put into DoD-wide perspective,
the repair effort appears overwhelming. The overall project in the DoD community requires an
incredible level of coordination and tracking to ensure success. The technical issues to both
business and scientific computing are important, but small in contrast to the project management
issues. At the detail level, conversion activities (hardware, software, and firmware) are routine
and definable. They make up the greatest portion of the effort; however, once defined, assigned,
prioritized, and managed they can proceed simply and effectively. Contrary to initial
perceptions, century compliance is primarily an exercise in large-scale project management.

The Assistant Secretary of Defense for Command, Control, Communications and Intelligence
(ASD(C3]) has formally notified all of the Department of Defense (DoD) of the impending and
very real danger. As noted, the full range of business and base support systems are in real
jeopardy of malfunctioning at or before the year 2000. The size of the T&E systems’ Year 2000
problem appears somewhat more scalable, although the full extent of the situation is not yet
defined. Accordingly, the Director for Test, Systems Engineering and Evaluation (DTSE&E) in
the DoD Office of the Secretary of Defense (OSD) directed an assessment of the Year 2000
problem as it affects T&E. Responsively, the Joint Program Office for T&E (JPO(T&E))
proposed and the T&E Board of Operating Directors (BoOD) commissioned a TRE Year-2000
Team to undertake an assessment of the problem in the T&E community. Pertinent
correspondence and the text of the proposal for a 90 day study effort may be found at Appendix
A. The study methodology adopted by the team is at Appendix B.



its true dimensions are unknown. Even though the Year 2000 conversion’s impact on range
systems does appear on the surface to be minor, a lack of complete inventories of T&E system
computer resources at the three sites studied limited identifying the true extent of what might be
at risk. Further, without more extensive testing, the team can not say with certainty whether the
perception of the Year 2000 problem is really relatively minor or whether more serious
problems, undetectable by casual inspection, are lurking beneath the surface. Significant Year
2000 compliance problems seem to be found in older mainframe or stand-alone systems and their
operating system software. Problems are almost universal in PCs, but the turnover rate of these
computers minimizes the Year 2000 threat since replacements are known to be compliant.
Finally, heightened awareness of the potential problem has been a major benefit of this quick
look exercise. It is through such heightened awareness that progress shall be made across the
board.

15



Version 1.8 9/10/95

fanalysis, date field
loccurrences;

‘S/W Reengineering

conversion to C/L; software

Block2

inventory; assessment of S/W

Intl Business Centre

(quality; metrics; reverse

National Technological Park

lengineering; cost estimating;

Limerick, Ireland

[conversion and testing;

-335030

implementation

Fax +353-61-335051

Titip://www.commerce ie/ep/
piercom/

year2000.html

PKS Services, Inc.

YES

[Outsourcing solutions for
creating

[Cross all platforms.

“Suite 2000"

the Year 2000 test
jenvironment.

908-603-3859 (Mr. Hill)

[No tools for C/S or Open
Systems.

[Impact Analysis

Conv Planning

[Code Conv & Data Conv

Testing & Implementation

The Company has existed for

718 years.

Prince Software, Inc.

20

YES:

IA SIW services company.

ICOBOL,BAL,PL/I,JCL,RPG II,
other 4GLs, CICS, IMS, DB2

1000C Lake St

[Provides "Survey 2000",

Ramsey, NJ 07446

"Translate 2000",

800-934-2022

"Simulate 2000", Proj mgmt

“Portal 2000 Products"

Facility. Y2000 assessment pian, impact analysis and migration
plan, detailed conversion plan and more. Pilot conversion S/W
lanalysis. Converts legacy apps for Y2000 compliance. Includes
code translation, prog mgmt, inventory anal, testing and imp.

E7



other laboratories in the fleet, at ranges and other DoD activities. He was generally aware of the
Year 2000 problem but did not foresee an impact on the work done in his lab. He stated that
although no dates are used in doing the actual calibration work he would examine the
computers for Year 2000 compliance and report the findings back to the team.

Subsequently, Mr. Whetstone reported that two types of laboratory computers are being used for
calibrations of test equipment - - - Hewlett Packard (HP) and Fluke. The HPs support dates to
the year 2080; however, the Flukes are not Year 2000 compliant at all and will only operate
when dates before 2000 are entered. Mr. Whetstone stated that the Flukes are used in 10% - 15%
of the work, the HPs in 50%. Computers are not used in the remaining 35% of the work. The
Fluke OEM will not support upgrades to alleviate the operating system Year 2000 flaw;
however, Mr. Whetstone states that both the HPs and the Flukes are being phased out well
before 2000 and their replacement(s) will be Year 2000 compliant.

Mr. Dan Dickey (5/15/96).

Mr. Dickey is head of Strike Missions System Branch. He was generally aware of the Year 2000
problem but perceived no impact on his operation. His department uses Macintosh, personal
computers (PC), and an HP UNIX for project work . He offered to have systems checked for
2000 compliance and report the findings back to the Team.

Upon setting the computer systems’ clocks to a Year 2000 date, tests were conducted on the
Macintosh and PC types of computers. As expected, the Macintosh systems exhibited no Year
2000 anomalies as they are known to be Year 2000 compliant. The one PC checked, a
COMPAC, appeared to accept the Year 2000 date when the MS DOS date parameter was set. It
responded normally when project applications were run. However, when the application created
a file, the computer’s File Manager saved that file with an erroneous and unrecognizable date,
ie., 1/1/:0. This signifies that the computer software has Year 2000 problems.

Generally, Mr. Dickey’s staff is of the opinion that the current software running on desktops -
functional applications, COTS office applications, and operating systems - will not be running at
the turn of the century. They felt that the hardware platforms won’t be around either and that
replacement systems will be Year 2000-ready. See Note.

Note: These test results are typical of most PCs tested at this site. It is pointed out, however,
that the problem isn’t completely pervasive or all-inclusive. Late model PCs do not exhibit Year
2000 problems. Their Basic Input Output System (BIOS) chip has been upgraded for Year
2000.

Mr. Mike Hardman (4/10/96)

Mr. Hardman is the senior electronics technician responsible for development and maintenance
of the Multiple Target Instrumentation Radar (MIR) at Chesapeake Test Range. He was aware
of the Year 2000 problem and his first impression was that this would not affect the MIR’s
operation. A complete inventory of computer hardware/software for the radar was not available.

C4



He agreed to run Year 2000 date tests on the radar’s computer (a Harris Corp. H1000-2C super
mini) and software applications.

Preliminary tests revealed that the radar computer operating system (HVOS) would not accept
Year 2000 dates, refusing to boot up. Inquiries to the manufacturer (Harris Corp.) revealed that
they were not aware of this problem. Harris is investigating whether newer versions of the
operating system (current version is 8 years old) are compliant. The radar’s application programs
do not use any date information so are unaffected. The impact is considered minor since the
problem will not down the radar system or cause any operational problems.

Mr. Henry Shupe (5/15/96)

Mr. Shupe is a computer scientist responsible for development and maintenance of three Vitro
RIR-778 radar systems at Chesapeake Test Range. He was not aware of the Year 2000 problem.
A complete inventory of computer hardware/software for the radar was not available. He did not
know if his systems would be impacted but agreed to run simple Year 2000 date tests.

Preliminary test results revealed that the radar software/hardware are Year 2000 compliant.
New radar computers are expected to be installed prior to the Year 2000 and they will be
specified to be Year 2000 compliant.

Mr. Bruce Burnsed (5/30/96)

Mr. Burnsed is a senior computer scientist for Vitro Corp. and is responsible for development
and maintenance of range radar systems through the Instrumentation Radar Support Program
(IRSP). The IRSP supports the Navy, Army, Air Force, NASA, DOE, and U.K. test and
evaluation ranges. He was aware of the Year 2000 problem but had not taken any action to
respond to the problem. His first impression was that this was not a problem which would
impact range radar systems. He said he needs to conduct tests and investigations to determine
any impact. No results have been reported to the team to date.

Mr. Sam Schrader (5/16/96)

Mr. Schrader is responsible for the Passcard security systems at Chesapeake Test Range. The
Passcard security systems control access to the facility. He was not aware to the Year 2000
problem. A complete inventory of computer hardware/software for the Passcard security systems
was not available. He did not see any impact that Year 2000 would have on the Passcard
security system but could not say for certain.

Mr. Dick Stepanian (4/30/96)

Mr. Stepanian is responsible for computer/software configuration management at the U.S.A.F.’s
30th Space Wing at Vandenburg AFB. He was aware of the Year 2000 problem. He stated that
this was not an issue at their range because of a planned replacement of all range

CS



Testing & Implementation

[Automated and Manual)

Computer Reserves, Inc. YES impact Analysis and Metrics |MVS/COBOL, BAL code,
Assembler,
800-882-0988 [Conv Planning, |AS/400, Natural
Project Ident
File Processor |A mainframe-based conversion
[Automatic Code Modification [product that reduces conv time by
lorders of mag compared to running
on Pentium PCs
‘Compuware Corp. Products run in standard operating
"Xpediter+, Pathvu, environments, including IBM MVS
Xpediter/Xchange,
File-Aid, DBA Expert to land TSO/ISPF and support IBM
DB2, Retrofit,
Playback” COBOL, OS/VS COBOL, and
COBOL II
Farmington Hills, Michigan
800-521-9353
hittp://www.compuware.com
Coppers & Lybrand YES [Impact Anal - source code [Business Systems
scan and
1751 Pinnacle Drive econometric modeling to
create
McLean, VA 22102-3811 [conv/proj plan
703-918-3716 Reqmnts Anal & Solution Def
Fax 703-918-3764 Sys Delivery Spec
“Diagnostic2000" Test Plan
|Tech/User Procs & Conv
Acceptance Testing
Transition
Data Dimensions, Inc. 28 YES Impact Analysis COBOL

"Template 2000"

(Conv Planning

206-688-1000

Code Conv & Data Conv

Fax 206-688-1099

Testing & Implementation

|A full service millennium

[consulting computer company
that

provides conversion planning
land

fimplementation support for

Y2K

E3



with the timing of cross-functional changes must also be understood. These factors, and other
pertinent Year-2000 information must then be folded into a comprehensive Year-2000 plan for
the T&E community. The team will examine the Year-2000 issue, including: the extent of the
problem in the T&E community, best practices for identifying vulnerable systems and
applications, best practices for rectifying the Year-2000 problem when identified, means of
identifying and addressing necessary interfaces with systems from other functional areas,
methods for dealing with vendor supplied software, methods for documentation and other best
practices from Government and industry.

PROPOSED STUDY TEAM: The approach to developing such a plan involves establishment
of a short term team focused on the Year-2000 problem. This team, chaired by Mr. Jerry Brown
of the Naval Air Warfare Center - Aircraft Division, Patuxent River, Maryland, will be composed
of six BoOD/RCC selected members. Three will represent the services from the T&E business
community and three will represent the services from the T&E engineering community.

SCHEDULE: The team will be stand-up in late March 1996. It will have 90 days to conduct
research and prepare a comprehensive plan. It will report this plan to the BoOD.

RESOURCES: The support of this team will require $30K for required travel and attendance at
scheduled meetings. Another $30K is required for contractor administrative support. Funding
source is either T&E CIM funds or BoOD requested OSD funding to respond to this OSD task.
Team salary shall be borne by the providing organizations.

LOGISTICS: The team is at liberty to identify its own logistics needs within the constraints of
available resources. The T&E CIM office will assist in making necessary arrangements.

A4



Offers expertise in wide range of IT services ~- a full service

company
MASTECH 10 ‘YES |Impact Analysis [Cross Platforms, Open Systems,
Century Date Change Group
412-187-9526, 412-187- (Conv Planning Multiple Languages and DBMSs
2100
800-311-1970, Fax 412- Code Conv & Data Conv
787-7450
Testing & Implementation
Micro Focus, Inc. MVS Application Offloader requires
“Challenge 2000" fine mainframe MVS operating
Palo Alto, California system and TSO/ISPF; Revolve 3.1
415-856-4161, Fax 415- fruns under Windows 3.1 or OS/2
856-6134
Iittp://www.miltd.co.uk 2.2 or above; COBOL Workbench
Millennium Dynamics, Inc. YES A toolset designed to allow in [COBOL
(MDI)
"Vantage YR2000" house century date conversion
of
800-892-7431, 513-369- [COBOL systems and files
3041
Fax 513-369-3077
OAO Corp 5) YES  |Hasa Millennium Solution |H/W, Apps S/W, OSs, Automated
|Center to
7500 Greenway Center assist Fed agencies with Y2K_|tools, IE
Drive conv.
Greenbelt, MD 20772 [Uses process-oriented
methodology
301-345-0750 fand partners with Y2K tool _|Business/Scientific/Engineering
vendors apps
Fax 301-345-0952 T. Impact Assessment
with I. Tools Testing & Ver
General Services I. Project Planning
Adi istrat
Tech Services Div IV. Impl and Testing
Information Resources, Precompeted contract managed
[by
Tih & d Sts, SW Room 6109 GSA - No DPA, no CBD, no
Washington, DC 20407 jjustification. GSA FISSP
contract
202-708-5732 GSA’s Tech Services Div
Piercom Ltd YES |Documents/scopes Y2K COBOL
problems
“Year 2000 Impact in legacy systems. Impact __ |Conversions
Analysis"

E6



Foreword

We express on sincere thanks to the T&E Year 2000 team members who prepared this
report. They provided a valuable service to the DoD community by helping scope a potentially
serious problem with widely varying characteristics and effects. Their donated time for the Year
2000 study came in addition to normal duties. The assessments and reference material in this
report forms the foundation for all T&E Year 2000 efforts to come.

The T&E Year 2000 Team:
Team Leader: Lloyd (Jerry) Brown, NAWCAD, Patuxent River, MD
Members: Robin DeFranks, TECOM, Aberdeen PG, MD
Greg Havens, NAWCAD, Patuxent River, MD

George Hurlburt, NAWCAD, Patuxent River, MD
David King, AFFTC, Edwards AFB, CA

Thanks for your outstanding support!

Director, T&E Corporate Information Management



minicomputer systems for 57 tenants at APG and the TECOM Test Centers. The department
uses COBOL on its mainframe, but runs Oracle and Informix on its minis. The DOIM is
forming a team to assess the magnitude of the Year 2000 problem. They have already started
talking to vendors. A cost analysis of $6M was calculated based upon rough estimates of the
number of lines of COBOL code and industry projections for cost per line.

FASE SAGE GS CCGA CSSA AS SCC GIS SEIS CIR IG ICICI ACI A IRA IR AI a AC AR

C12



some level of failure. However, no vendors or studies have identified specific problems.
Testing methodologies also seem to be non-existent for many of these components.

Other Concerns

Air Force Standard Systems - Numerous AFFTC functions are dependent upon Air Force
Standard Systems. The impact of Y2K on these systems is unknown at the present and cannot be
locally determined. These systems are developed and maintained by the Standard System
Center (SSC) at Gunter AFS, AL. The SSC is evaluating these systems for Y2K impact.

Embedded Systems - The impact of the Y2K on systems embedded within aircraft could not

generally be determined at the local level. Embedded systems will be evaluated by the specific
Major Commands, Special Project Offices.

ABERDEEN TEST CENTER, ABERDEEN, MARYLAND , and

TEST AND EVALUATION COMMAND, ABERDEEN, MARYLAND

Ms. Eileen Viars (4/24)

Ms. Viars is the Senior Computer Specialist for the Computer Operations Division at Aberdeen
Test Center (ATC). Her division is responsible for the collection, processing and reporting of
test data for all test and evaluation decision makers. Her division is aware of the Y2K problem.
She is responsible for running the HP 9000/3000 minicomputers and the local area network
(LAN) . Her department is waiting Year 2000 software patches from Hewlett Packard. Other
software developed in-house will be modified there. The greatest impact will be from systems
external to ATC, i.e., Cost Accounting, Test Resource Management System (TRMS) and the
Defense Finance & Accounting Service (DFAS). She estimates the cost to become Y2K ready
will be $3,000.

Mr. Steven Hawbecker (5/3)

Mr. Hawbecker is a Mechanical Engineer for the Physical Test Division at ATC. His division is
responsible for conducting testing on toxic fumes data acquisition, alternative fire suppressants
and refrigerants and chemical analysis. They are aware of the Y2K problem. They feel that
there will be a minor impact, all test data does not have date/time fields in it. The only problem
would be in the incorrect date on the hardcopy printouts. They are assessing off-the-shelf and
locally written data reduction software for impact and realize that all PC's will need to upgrade
the BIOS. His department is checking with the workstation manufacturers (SUN and Silicon
Graphics) to determine if the problem exists and if these OEMs are preparing a solution. They
estimate a cost of $1,000 to become Y2K ready.

C10



affirmed in nearly every interview. Costs will be incurred. however, to identify and replace
hardware and certain support software that are not inherently Year 2000 compliant by design. In
instances where the hardware’s operating system (OS) is not Year 2000 compliant, either the OS
will have to be upgraded or the hardware replaced (some Original Equipment Manufacturers
(OEMs) do not offer replacement Year 2000 compliant OSs for some computer models). In these
cases, the engineering applications, while Year 2000 compliant themselves, will probably need
to be modified to operate in the new Year 2000 compliant environments. The T&E Year-2000
Team derived the figures below from interview statements, inventory lists where they were
available and by gross estimations. In some cases numbers were provided only as rough
approximations and are, therefore, not considered official

a). Naval Air Warfare Center, Patuxent River: Patuxent River NAS should be commended for
their proactive approach to the Year 2000 problem. A significant program is underway there and
detailed data was available to assist with the T&E Year 2000 team’s analysis. The following
tables reflect the number of pure T&E computing assets at Patuxent River and estimated costs to
convert systems to Year 2000 compliance.

Patuxent River, MD T&E Computer Assets

Computer Type Competency Type Number Total

Mainframes/Minis T&E 34
Engineering 25

59
Workstations T&E 115
Engineering 75

190
Servers T&E 85
Engineering 55

140

Total 389

Of these 389 systems it can be assumed that approximately 1/3 are or will be Year 2000
compliant because they receive normal upgrades from annual maintenance agreements with the
OEM or third party provider; 1/3 are scheduled for replacement before 2000 so no Year 2000
additional cost will incur, and 1/3 (130) must be upgraded. Costs to upgrade such computers are
divided into two categories: systems that are still running the original OS thus requiring many
layers of new software through the model series (or complete system replacement depending on
the economics and time constraints of each situation), and systems that need only the latest OS.
The team assumed that half of these computers will fall into each category (65 each) and that
costs to replace all the OS-series software or completely replace the system (hardware/software)
are, on average, relatively the same. Attendant application software modification costs are also
approximated by rule-of-thumb as equal to the hardware/OS replacement cost.

8



“Year 2000 Customer Guidance Paper"

[A Guide for Planning and

http:/Awww.S300.1BM.com/ implementation”
stories/
pr2000.html
IBS Conversions, Inc. 4 Impact Analysis COBOL
“IBS/Solution 2000" [Conv Planning
708-990-1999 Code Conv & Data Conv
Fax 705-571-0723 Testing & Implementation
Intersolv YES [Provide service direct COBOL, CICS.BMS, DB2, IMS
consulting:
“Intersolv Maintenance assess, identify impact, plan,
Workbench"
‘webmaster@intersolv.com test, implement changes;
stream-
line maintenance, synchronize
production environment
versions
ISOGON Corp Since NO |S/W for testing MVS/ESA and [MVS,COBOL,PL/I,Assembler,other
330 Seventh Ave 1983 MVS/XA using virtual dates. |s,PDS,PDSE,Librarian, Panvelet
New York, NY 10001 ‘Tests for Year 2000 and
212-376-3200/800-568-8828 beyond. Transparent to apps.
*TICTOC" INo code/JCL changes. All
data formats (dec, binary,
Imicrosecs, etc.) Softaudit
Identifies load mods and
lsource mods, tracks usage,
lcounts LOC.
James Martin & Co. YES _ [Impact Analysis COBOL
"The System [Systems redevelopment and
Redevelopment
Methodology” reengineering
800-248-4562
Keane Federal Systems, Inc. 30 YES _| Allied with Viasoff, Inc. General

Corp HQ
Ten City Square
Boston, MA 02129

"Resolve 2000". Over 300
tech/professionals in MD and
VA Offices. Software
services,technology migration.
Has tool-assisted impact
analysis for enviorn. reports,
systems inventory, planning
land situation assessment.

617-241-9200 [Conv Planning.
“Resolve 2000" imp Planning
ES



b). Aberdeen Test Center, Aberdeen , MD: Year 2000 transition costs at Aberdeen Proving
Grounds for pure T&E assets are indicated to be significantly less than the Patuxent River, MD
estimate. Here costs for Year 2000 range from $0 to $300,000 according to the information
made available during interviews.

Aberdeen, MD Year 2000 Estimated T&E Costs:
$ 309,000

c). Air Force Flight Test Center (AFFTC), Edwards AFB, CA: The primary engineering/range
support systems located at the AFFTC have been either replaced or upgraded within the last two
years. It is believed that the hardware/software/operating systems currently being used are
century aware and will not suffer significant problems. Other range instruments such as radar
systems, cine-theodolites, etc., are also planned for upgrade, replacement or to be mothballed
prior to the year 2000. The overall feeling was that the year 2000 will only bring a minor impact
to the range/engineering systems. The major AFFTC business systems that are expected to
continue beyond 2000 are believed to be century aware and also will not suffer significant
failures. It is anticipated that costs for infrastructure and ancillary system failures may range from
$0 to $200,000.

AFFTC, Edwards AFB, CA Year 2000 Estimated T&E Costs
$ 200,000

2. ANCILLARY AND FUNCTIONAL COMPUTER ASSETS: These systems are generally
developed and maintained by each major organization’s information management support
function to support the entire activity or Command. The Naval Air Warfare Center Aircraft
Division, Patuxent River, MD’s and Aberdeen, MD’s estimates below represent overall
functional costs encompassing activities outside those range sites, whereas the estimate for
AFFTC reflects only for Edwards AFB, not the needs of the Air Force Material Command.
Each site has examined its information, management, base support, and range support systems
with regard to Year 2000 impacts. The following estimates reflect the costs to repair or replace
that software and affected hardware platforms, anticipating that some system components will
fail plus the cost to do some level of situational testing.

Naval Air Warfare Center Aircraft Division Estimated Business System Year 2000 Costs:
$15,000,000
Aberdeen Proving Ground Garrison Estimated Business System Year 2000 Costs:

$ 6,000,000



JESSE ASE SE SAS AS CAGOIG IG SECIS ISIC I C1 1 21 1 a2 1 2 1 a aR a A a A AC CR aC A COR

TEST AND EVALUATION YEAR-2000 TEAM REPORT
to the
Test and Evaluation Board of Operating Directors

September 30, 1996

FESO SEAS SCG CSG GCS CSAC aC ACI ACIS ACK aR ACR a ACR a Ak a a A ao

200 7160866)



Tool Control,

AIC Lab Worklog, and

Requisition Tracking.
They were locally developed and can be corrected within a month. Further investigation is
ongoing.

Mr. John Dawson (5/14/96).

Mr. Dawson is responsible for all electromagnetic effects laboratories at NAWCAD, Patuxent
River. He was generally aware of the Year 2000 problem. He felt there was no perceived effect
on his operation. He did survey his people. The largest threat is from desktop computers and they
will all be replaced by 2000. His systems deal heavily in time, but do not involve date
calculations. He acknowledged that Operating Systems should be examined in his older data
systems. He felt his Halon removal program was a greater Year 2000 issue. It must be replaced
by then by regulation and there are no funds allocated for its removal and replacement.

Mr. Ray Nowak (5/19/96).

Mr. Nowak is responsible for large scale Models and Simulations (M&S) and their design and
conduct at NAWCAD, Patuxent River. These systems range from Force-on-Force combat
engagements to single system performance. He is deeply involved in state-of-the-art growth via
High Performance Computing. Growth has been astronomical since the advent of the
Competency Aligned Organization (CAO) realignment. He was generally aware of the Year
2000 problem. In the main, he felt he had little problem. He uses state-of-the-art SGI equipment
which, if not already Year 2000 compliant, will be made so by the OEM who is prompt about
maintaining state-of-the-art integrity in this facility. M&S is time, but not date dependent. He
did identify some areas worthy of further investigation. He had one older lab that used Encore
gear (formerly Gould) that may be susceptible. He was involved in some C4I systems and
associated data links that he felt required further scrutiny for date sensitivity. He was unsure of
GPS and IRIG time based inputs and their effect, but suspected they would be minimal. He
volunteered a report back in a week.

Mr. Bill Rymer (Email exchanges in early April)

Mr. Rymer heads the Telemetry operation at NAWCAD, Patuxent River, including the Real
Time Telemetry Processing System (RTPS). He was initially unaware of the Year 2000 issue.
He had a survey conducted of his operations for Year 2000 susceptibility. No significant threats
were uncovered. Some minor operating system irregularities were reported. He felt the remedy
responsibilities largely fell upon his vendors.

Mr. Steve Whetstone (5/15/96).

Mr. Whetstone was referred to the team by Mr. Jimmy Fairfax of Metrology. Mr. Whetstone
heads the Laboratory Instruments and Standards Branch for Airborne Aircraft Instrumentation.
This laboratory is responsible for calibrating test equipment used aboard aircraft, ships and in

C3



ce:

HQ USAF/TE
SAUS-OR
AMSTE-CG
Commander NAWCWD
AMSTE-TA
NAWCAD (5.1)
AFDTC/CD

HQ USAF/TER
DACS-TE

CNO (N913)
JPO(T&E)
NAWDWD/52D000D

A2



Mawby, Patricia _ , 7

From: hurlburt@tecnet1 jcte.jcs.mil[SMTP:hurlburt@tecnet1 jcte.jcs.mil]
Sent: Sunday, September 06, 1998 9:49 PM
To: pmawby@dtic.mil
Subject: Y2K Paper
Year2000.doc

Per your request is a copy of our Year-2000 paper in MS Word prepared and released under Distribution List "A"
by the Director of T&E Coproprate Information management in late 1996.

Regards,

George

P.S. Please acknowledge successful receipt.

Page 1

AG Meh - 12-2427



For PCs:

G.

H.

. From your Program Manager Desktop menu select Main.
. From Main select Control Panel.
. From the Control Panel select Date/Time.

. Using the up/down arrows:

1) Set the date to 12/31/99.

2) Set the time to 11/59/01 (minutes and seconds are arbitrary)

. Close the dialog box.

. Select the Date/Time icon again.

The date should be 12/31/99 and the time should be advancing.

Wait until the date changes (should roll over to 1/1/00).

J. If the date doesn’t change correctly your PC isn’t year 2000 compliant. You can set the date to
1/1/00 and continue test at Step K if desired, but date will fail.

J. If the date is correct continue test.

K. Close Date/Time dialog box.

L.

Close Control Panel and Main. You should be at Program Manager Desktop.

M. Create and save a file (select Microsoft Word, for example).

N.
0.
P.

Qa

1) Enter anything into the test file.
2) Select File from the menu bar.
3) Select Save As from the pull down menu.
4) Enter the File Name in the highlighted blue box (ex: y2ktest.doc).
5) Select a Directory to store the file.
6) Select OK (double click on the OK).
Select File from the menu bar.
Select Close from the pull down menu.
Exit Microsoft Word (for example).

Select File Manager from menu bar.

R. Select Directory where the file was stored.

D3



approach could be scaled for rough order of magnitude cost estimates and methodological
approaches. This alternative was selected.

C. METHODOLOGY ADOPTED: The T&E Year-2000 Team adopted a case study approach
combined with a complete survey of existing commercial trends toward resolving Year 2000
issues. The case studies applied to the three MRTFB facilities represented on the T&E Year-
2000 Team. These facilities included: the Naval Air Warfare Center Aircraft Division, Patuxent
River Maryland; The Air Force Flight Test Center, Edwards Air Force Base, California; and the
Aberdeen Test Center, Aberdeen, Maryland. The Army’s Test and Evaluation Command, which
has oversight for all Army Development T&E activities, also participated as a contributor. The
team was also augmented by direct consultation with Army, Navy and Air Force T&E
participants serving on service based Command-wide Year-2000 teams. The T&E Year-2000
Team choose to use an interview method to collect relevant Year 2000 information from selected
T&E Field Activity leaders. A copy of the agreed upon interview questionnaire is attached. The
team focused primarily on T&E scientific processing systems operating within the MRTFB. It
also examined T&E support tools often maintained within the base infrastructure level as a
secondary priority. Finally, the team considered the large scale business systems affecting T&E
which are frequently dependent upon CDA organizations or other non-T&E entities. Early in its
existence, the team also agreed upon a format for this final report and a schedule of necessary
events.

B2



them. Every GPS-related product they had ever made would have come back for repair, many
under warantee, all at once. Too close for comfort. And, discovered by luck.

The firmware in all affected (older) units will have to be replaced. This will involve replacement
of PROMs; some are socketed, some are soldered. New units presumably will know better than
to claim dates from before they were manufactured, and/or will allow the user to directly or
indirectly tell the firmware which 1024-week cycle to assume, without requiring replacement of
that firmware at the second rollover, in 1980 + (2*1024/52) = 2019 AD. Some of this equipment
will still be in use then, long after the manufacturer has forgotten the product, or has himself
been forgotten. Nor is it guaranteed that the needed PROMs will still be available.

However, in spite of everything, not everybody will get the message, so system software will
forever have to have an independent idea of what year it is, to know when to disbelieve a receiver
or receivers (they could all be wrong), and to handle arguments between various GPS receivers
(if only some are wrong).

Without a GPS Simulator, there is no way for users to test a GPS receiver for this problem. All
most users can do is to ask their manufacturer for a solution, and also to imbue the system
software with a suitable degree of skepticism about GPS receivers' sense of time.

My intent in posting this note is to alert the entire industry to the problem, allowing it to be

solved with minimal disruption to all. As a technical matter, the solution is quite simple. It's the
logistics that will take some years.

AIR FORCE FLIGHT TEST CENTER (AFFTC), EDWARDS AFB, CALIFORNIA

Interview Results

Informal interviews/discussions concerning the potential impact of the Year 2000 (Y2K)
problem were held with key personnel located in the business, infrastructure, range and
engineering areas at the AFFTC. In general, those interviewed were aware of the Y2K problem.
In addition a total of 131 systems were reviewed and broken down into the following categories:

Locally Developed Business Systems
PC Systems/Applications
Engineering/Range Systems
Comm/Computer Infrastructure

A synopsis of the interviews by functional area follows:
Locally Developed Business Systems

Ms. Julie Karr
Capt. David Winters

C8



MEMORANDUM FOR BOARD OF OPERATING DIRECTORS
ATTN: MAJ GEN F. C. GIDEON, JR , CHAIRMAN
HQ AFMC/DO, 4225 LOGISTICS AVENUE, SUITE 2,
WRIGHT-PATTERSON AFB, OH 45433-5714

SUBJECT: Year 2000 Software Issues Funding -- INFORMATION MEMORANDUM

1. The Board of Operating Directors approved the Year 2000 Software Issues POA&M and
recommended funding it from T&E CIM. During the T&E CIM Steering Council prebriefing,
Mr. Burt observed that the Year 2000 Software Issue effort did not involve business process
reengineering and therefore is not suitable for T&E CIM funding.

2. After reviewing all potential funding alternatives and the POA&M tasks, the JPO(T&E) has
rescoped the tasks and reduced the cost for the quick action team (see attachment). We will
implement the following actions and modifications to the POA&M:

a. The JPO(T&E) will provide TDY funding (less than $10K) for the study team (funds
for study team activity was included in the approved JPO administrative plan), and

b. The study team will request a limited amount of clerical support (about 5 days) from
Patuxent River NAS -- the organization supporting the team leader, Jerry Brown.

C. The JPO(T&E) will sent the attached letter to the survey sites.

3. The JPO(T&E) point of contact for this effort is Colonel Ken Spencer, DSN 858-4755.

TODD STEVENSON, GS-15
Acting Director

1 Attachment

Action Plan for T&E Survey Team with cover letter

ce:
Commander, U.S. Army Test and Evaluation Command (MG Richard W. Tragemann), Aberdeen
Proving Ground, MD 21005-5055

RADM Dana B. McKinney, Commander, Naval Air Warfare Center Weapons Division, Code
000000D, 1 Administrative Circle, China Lake, CA 93555-6001

AS



Initial reaction among the T&E engineers, computer scientists, and technicians interviewed was
vague awareness of the Year 2000 issue and an expression that it’s impact on their systems was
minimal to none. Only one of those interviewed, however, had a complete inventory of his
division’s computer hardware and software applications. Most functional computer applications
in T&E are primarily concerned with operating complex scientific instrumentation systems
which gather, analyze, and store test data. As noted above, these systems deal with data and
time measurements on the order of milliseconds and microseconds. The year is typically not a
factor in these measurements. This fact caused these T&E professionals to dismiss the Year
2000 problem as having no impact on their systems. Further discussions with them about
specific instances of the use of date information in their system’s computer software revealed
potential impacts which they had not considered. These potential impacts arose from the
operating system supporting their instrumentation system’s application software and from
subprograms (such as calibration and data recording/reporting) associated with the main
application software. Extensive off line testing would be needed to gauge the true extent of these
type of date problems.

Year 2000 concerns often lie embedded in older hardware and/or firmware in scientific systems
making them harder to detect and potentially insidious as they tend to act as "time bombs". The
Joint Test Assets Database (JTAD) produced a large list of Patuxent River-based laboratories
each of which most likely contain one or more computational assets. The Patuxent River
inventory system identified a heterogeneous list of computers operating within the site’s
laboratories. These lists reveal that many applications are running under a wide variety of
operating systems. Large scale Time Space Position Information (TSPI) systems such as IRIG-
based tools or the Global Positioning System (GPS) and its calibration ephemera pose a
potential, but not as of yet dimensioned, concern. Command, Control and Communications
systems, including localized data links and Systems Under Test (SUT), may contain latent Year
2000 embedded design susceptibilities and require further research. Sub-systems that place
labeling and header information on storage media may also exhibit year related problems after
year 2000.

Tests conducted on two radar systems revealed that these computers’ operating systems would
not accept year 2000 dates as valid and one would not “boot up”. If the radar computer won’t
boot then the application software will not load. The operating system in this case is
approximately 8 years old; however, it is supported by the manufacture under a maintenance
contract. This manufacturer was unaware of the Year 2000 problem but affirmed that it would
investigate solutions/cost to fix. The fix could be as simple as installation of the latest version of
the operating system. The isolation and resolution of similar deficiencies within T&E systems
awaits further analysis across the T&E community.

Some instrumentation systems on one range utilize “star calibration” to perform system level
calibrations. This is typically a subprogram of the main application program and involves input
of a date to determine a reference or fix of the star position in relation to the instrumentation
system. Testing has not been done to determine Year 2000 impact. The instrumentation
system’s manufacturer has been queried but no new information arising from this was available
at the time of this report.



S. Select View from the menu bar.
T. Select All File Details from the pull down menu.
U. Highlight the file you created.

V. Verify the date the file was created is correct (0/1/00). If incorrect (1/1/:0 for example) your PC
is not Year 2000 compliant.

W. Delete the test file (select File, select Delete from the pull down menu, select YES from the next
three dialog boxes).

X. Exit File Manager.

Y. Reset date and time.

The Reason:

The standard PC computer system maintains two system dates; one is in the CMOS Real Time Clock chip - a
hardware component that is normally on the machine’s motherboard - and one is in the DOS (and Windows)
operating system software. These two dates are represented differently. The CMOS RTC date is kept as
century/two-digit-year/month/day and the DOS date is kept as days-since-1980/01/01 which is converted to
four-digit-year/month/day when any program asks for it. When DOS boots, it normally initializes its current
date by reading the date in the CMOS RTC and converting it to days-since-1980/01/01. DOS maintains its
date as long as the system is running; the CMOS RTC hardware maintains its date whether the system is
running or not, but it does not maintain the century. In the CMOS RTC, year 99 overflows to 00 and the
century remains unchanged so the effective year becomes 1900; in DOS year 1999 overflows to 2000. So
until the system is rebooted there will appear to be no problem with the transition from year 1999 to Year
2000; but trouble lurks in the CMOS RTC date, which has become year 1900. When DOS boots it reads
1900 as an out-of-range date from the CMOS RTC and the date conversion algorithm calculates an
erroneous 1980-01-04. That’s what the DOS date will become after rebooting the system after the Year 2000
transition if the CMOS RTC exhibits the standard flaw.

Another Test:

To determine if your system suffers the Year 2000 CMOS RTC flaw, from a DOS prompt set the date and
time to:

Power off test:
C:>DATE 12-31-1999
C:>TIME 23:59
Power off the system, wait more than one minute,
Power on the system. Allow the system to boot.
Check the DOS date. It should read 01-01-2000. If its not (usually 01-04-1980) your machine has
the flaw.

Power on test:
C:>DATE 12-31-1999
C:>TIME 23:59
Wait for more than one minute.
Check that the DOS year has changed to 2000.

D4



APPENDIX E:

Matrix of Commercial Offerings to Resolve Year 2000 Questions

~ Adpac Corp.

|Locates application data fields;

MVS Operating System, including

"SystemVision Year 2000"

prepares detailed cost estimate;|

IMVS/XA and MVS/ESA supporting

San Francisco, CA

allows "what iP” modeling for

products that run in COBOL, PL/I,

415-777-5400, Fax 415-
546-7130

assessment of different change

Assembler, JCL, SQL, DB2, IMS,

‘adpaccorp@aol.com

Imethods; supports automated
code

IDMS, CICS, IDD.

Ichanges; menu driven;
repeatable,

verifiable; impact analysis.

‘Alydaar S/W Corp 4 [Uses artificial intelligence |General
| product
“SMART CODE" to find and fix every Y2K
[problem
705-544-0092 in software systems —
Fax 705-544-0260 synthetically. Core business
goal
is reengineering solutions.
"AMAR Systems Inc YES __|Planning - assesses app MVS
TTSC portfolio
Date2000 Solutions [Exposure Id- detects date refs
clo Technology Transition [Exposure Solution - correct,
Support migrate,
9801 Broken Lane Pkwy, fest a Year 2000-ready system.
Suite 103
Columbia, MD 21046 Produces inventory of
software,
410-995-6060 [checklist for Y2000, Imp plan.
Toolkit
Fax 410-995-6061 product allows conv & testing
apps in
"Date 2000" piecemeal fashion. Conv data
files
‘Andersen Consulting YES __ Impact Analysis General

El



1) Total OS Line or Entire Hardware System Replacement:
65 x $20,000 = $ 1,300,000
2) Latest OS Replacement:
65 x $3500 = $ 227,000
3) Subtotal $ 1,527,000
4) Application Software Modifications:
$ 1,527,000
5) Total Patuxent River, MD T&E Costs:
$ 3,054,000

The FIGURE 1 Pie Chart below illustrates Year 2000 cost distribution for this T&E Activity.

Y2K Cost Estimate for
Sample T&E Activity

Estimated Y2K site cost = $18M ¢ 389 T&E systems identified
=> 1/3 are “OK”

Ms, T&E = $3M => 1/3 are scheduled for
upgrade/replacement before 2000

=> 1/3 must be fixed (130 systems)
© 65 require major effort
e Problems typically found in
hardware, firmware, operating
systems, and interfaces
= Cost estimate to fix = $1.5M

e Applications generally appear safe

=> Cost estimate to mitigate impacts of
firmware and operating system
changes on applications = $1.5M

FIGURE 1