As the year 2000 approaches, the dire predictions of global computer
chaos have been growing ever louder. Because FSL deals largely in a
time-sensitive product – weather data – the questions naturally arise:
Are we ready? What has been done so far? What do we plan to do? Will
we fulfill the prognosticators' worst pronouncements?

Response teams throughout the laboratory are either well along on or
have already completed Y2K mitigation and validation activities. In
particular, they have completed their analyses and code updates for Y2K
compliance for projects that support critical missions, including the
National Profiler Network system, LAPS, MAPS/RUC, WFO-Advanced, and
GLOBE. To meet NOAA's compliance requirements, all systems must be
reviewed to confirm that they correctly store, process, input, and output data
containing date information regardless of whether the data
contain dates before, on, or after January 1, 2000.

Before discussing what has been done and what remains for FSL to do
before the clock ticks over to 2000, we will mention some of the
complications that could ensue if precautions are not taken.

National Profiler Network – Wind profilers measure vertical profiles
of horizontal wind speed and direction from near the surface to above
the tropopause. A disruption of profiler data from the National
Profiler Network (NPN) would hamper work at the National Weather Service
(NWS), Federal Aviation Administration (FAA), military, national
universities, and other agencies. Forecasters and researchers use the
data to verify numerical weather models, forecast aircraft turbulence,
monitor spatial and temporal evolution of mesoscale features, and much
more.

LAPS and MAPS/RUC – Without model output from the Local Analysis and
Prediction System (LAPS) and the Mesoscale Analysis and Prediction
System (MAPS), running operationally as the Rapid Update Cycle (RUC),
important model output covering the mesoscale (20 to 200 km) and
national scale would be unavailable at the NWS forecast offices. Also,
FAA, private corporations, military, and emergency management staff rely
on these models to provide quality-controlled, three-dimensional
displays of specific weather (e.g., the LAPS analyses in Figure 1) to
pinpoint precise development of severe weather.

WFO-Advanced – The WFO-Advanced system is the backbone of the
Advanced Weather Interactive Processing System (AWIPS) being installed
at all Weather Forecast Offices (WFOs) and River Forecast Centers around
the country. Even a small Y2K glitch could cause major complications,
since accurate weather predictions affect commerce and transportation
activities worldwide.

GLOBE – The GLOBE (Global Learning and Observations to Benefit the
Environment) program links students, teachers, and researchers worldwide
in carrying out environmental research. An interruption of data and
communication could bring to a halt thousands of global environmental
experiments being conducted at the GLOBE schools, data would be
unavailable or destroyed, and normal communication between the academic
and research community would be impossible.

The Y2K Problem

Much of the worldwide Y2K discussion concerns commercial applications
such as financial databases that have traditionally stored dates with 2-digit
year fields. Older date-manipulating software in these systems is
likely to treat the date string "1/1/00" as "January 1, 1900," and
consequently produce rather undesirable results.

The predominant Y2K issue at FSL has been slightly different, centering
on our historical time-based data file naming scheme rather than
internal time value processing. The naming scheme dates back to the
earliest days of the laboratory [around 1980 when it was called the
Program for Regional Observing and Forecasting Services (PROFS)], and
its use of VAX/VMS computers that originally limited file names to nine
characters. According to convention, data file names follow the pattern
"YYJJJHHMM," in which "YY" represents the last 2 digits of year; "JJJ,"
julian day; "HH,"hour; and "MM," minute.

As FSL migrated from VMS to UNIX platforms several years ago, this
legacy convention was largely retained. The FORTRAN software library
modules that convert file name strings to and from an internal binary
representation were ported to operate on the new systems. As originally
coded, the standard system time-to-file name conversion function
computed a year value representing "years since 1900," which fit nicely
into a 2-digit string. However, this function is certain to crash a
program when the value 100 is returned in 2000.

More recently, C and perl software modules in the Central Facility were
developed to replace legacy data acquisition components. Systems staff
retained the old naming scheme for backward compatibility, but avoided
dependence on the problematic FORTRAN modules. Instead, they utilized
the standard C time function "gmtime" to decompose system time into
year, month, day, etc., values prior to formatting a file name string.
As with the FORTRAN routine, however, the year value returned by this
function is again "years since 1900," rather than "year of the century."
Hence, software that incorrectly assumes the latter will likely crash
due to a memory violation, or at best produce file names with an
unusable 3-digit "year," i.e., 100JJJHHMM.

Figure 1. LAPS analyses for 1 January 1999 illustrate the types of
detailed data that could be unavailable if there is a Y2K problem at
FSL.

Other, less common problem areas are associated with translating
date fields contained in data messages that are received from
external sources. For example, one Central Facility product
arrives from the data vendor with a date string identified as "DD-MMM-YY." As
in the banking system, translator software must
properly account for "00" when 2000 arrives.

Y2K Activities

The process of finding and exterminating Y2K bugs has been ongoing
throughout FSL for at least two years. In July 1997, a Y2K working
group with representatives from affected projects and divisions met
to recommend file naming conventions for Central Facility public
datasets. The discussion focused on backward compatibility and
ease of implementation, and led to the conclusion that we should
retain the well-established 2-digit year style, rather than switch
to a 4-digit year for these files. Expanding the length of file
names would require numerous application program changes, whereas
modifying the underlying time-handling routines to properly
recognize "00 " as "2000" would reduce the modifications to only a
few modules. Accordingly, various users of these datasets have
implemented changes to ensure proper Y2K behavior.

Major projects within FSL that have been receiving extensive Y2K
audits include the wind profiler system, LAPS, MAPS/RUC, WFO-Advanced, and
GLOBE, as discussed below.

NOAA's National Profiler Network – As one of seven designated
"mission critical systems" within NOAA's office of Oceanic and
Atmospheric Research (OAR), the NPN system is being closely
monitored to ensure that it will maintain complete system integrity
during its transition into 2000.

The Demonstration Division has implemented testing and
validation/verification procedures to guarantee that the NPN will
not encounter Y2K problems. Their early response to avoiding
potential problems, along with comprehensive documentation, has
served as a guidepost for other OAR organizations in assuring that
their respective mission critical systems are Y2K compliant as
well. (Click here for more
information on
this work.)

LAPS – With the revision of the LAPS time-handling software, it
is expected to continue performing correctly in the advertised
valid range, from 1990 to 2027. The system is being scrutinized
both within the context of AWIPS and the U.S. Air Force Weather
Agency system. An Air Force evaluation team, assisted by an
outside consulting firm, is conducting tests on computers running
with the system clock advanced to move into 2000. (Click here for
more
information.)

MAPS/RUC – Similar modifications and tests have been performed
on MAPS, which is running at the National Centers for Environmental
Prediction (NCEP) as the Rapid Update Cycle. Model input and
output data from a previous period were saved to tape with modified
dates, as if the data were from 31 December 1999 – 1 January 2000.
Testing of the RUC software with Y2K modifications was completed
successfully using this special dataset. These modifications have
been integrated into operations at NCEP. The same changes were
made last July to MAPS software running at FSL. (Click here for more
information.)

AWIPS WFO-Advanced – The WFO-Advanced (AWIPS) software is
undergoing Y2K testing by the National Weather Service. A
significant amount of work went into ensuring that both newly
developed and pre-existing code modules are Y2K compliant.
Recently, an internal review of the many elements of AWIPS
(developed at FSL and elsewhere) found the system to be in
excellent shape. It should be noted that when the designers of the
WFO-Advanced system started development with a clean slate several
years ago, they devised a new file naming scheme that utilizes 4-digit year
strings to avoid the ambiguity of two digits. They also
created a standard time class library to ensure that all components
correctly handle time information.

GLOBE – GLOBE project staff in the International Division began
taking action early to ensure Y2K readiness, and assess the GLOBE
software to be nearly ready for 2000. Y2K-compliant upgrades to
Sun and SGI operating system software and the Oracle database are
planned for early 1999. Project managers have also identified
several scripts for Y2K fixes. Since date menus within data entry
forms already use 4-digit year fields, they are not expected to
cause trouble. Further, GLOBE software rejects year values earlier
than 1994, the first year of the project, thus ensuring that years
will not be misinterpreted as 1900 instead of 2000.

Other Concerns – Unlike these externally sponsored projects, FSL
Central Facility activities for Y2K are largely still in the
identification and analysis phase, with some modules known to need
corrections. Most of these errors reflect a common misuse of the C
time structure, and the fixes are expected to be straightforward
and low-risk. Corrected software is scheduled to be tested and in
place by mid-1999. The Central Facility update task has been
simplified by the planned decommissioning of all legacy VAX
hardware and software early in 1999.

The Facility Division also plans to create Y2K test datasets with
file times and date fields modified to span 31 December 1999 – 1
January 2000. FSL application developers, especially those not
directly affiliated with the major projects already described, can
use the test datasets and other resources to help shake out their
own Y2K issues.

The Outlook

Of course we will not know categorically that all elements of FSL
software will continue to run in Y2K until we arrive at that
fateful New Year's Day, 2000, but it appears that the doomsayers
will need to look elsewhere for their disasters. In contrast to
the corporate setting in which non-Y2K-compliant legacy third-party
software and databases must be repaired, several factors have
tipped the odds in our favor: we have many excellent software
developers who are already familiar with our code, virtually all of
our critical software has been developed locally, and all of the
source code for our systems is available.

As a final note, while it appears that FSL will weather the Y2K
storm, there are other problematic dates on the, albeit distant,
horizon. As currently defined, the 32-bit clock used by UNIX
systems is set to fail at approximately 3:15 a.m. on 19 January
2038. The present LAPS internal time parameter will expire ten
years before that, in 2027. Farther out, the MAPS Surface Analysis
System (MSAS), a component of AWIPS, is good until 2080. Beyond
that, because many modules have not fully accounted for leap year
rules, some systems likely will not provide correct dates beyond 28
February 2100, which is not a leap year [divisible by 100], whereas
2000 is a leap year [divisible by 400]. Perhaps in 2100 some of us
could be nudged out of deep retirement to work on the problem.

(Bob Lipschutz is a researcher in the Facility Division, headed by
Dr. Peter A. Mandics. He can be reached here.)