Contents Blowdown Y2K Ready? FX-Net Development 3-D Visualization FX-Connect Turbulence Etcetera Publications Contact The Editor Design: Wilfred von Dauster

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.)