Y2K issues for ARM IDPCs
Summary of Year 2000 Problems in the ARM IDPCs (as of 6/11/1998)
- Problems in individual scripts and programs:
There are numerous scripts and individual programs which collect, ingest, bundle, and process the data on each system. Almost all have or may have Y2K problems, however for each individual item it should only take a few hours to assess and fix. Also some, like the ingests and bundling scripts, are similar to each other and have common problems. The ingests in particular usually
call the same common shared library functions to convert time and rename files. So once the common libraries (BW at the EC & XDC and the shared SDS libraries at the SGP, NSA and TWP data systems) are fixed, only minor changes should be
needed for most ingests. See the code inventory lists for each data system for more details.
- Problems in the common libraries
There are a handful of common functions that deal with time or in renaming files in the shared libraries. These functions will have to be assessed, fixed and
tested. Some of the changes may affect a number of the ingests, so additional
testing on individual ingests, will be required. Also, these libraries are based on Zebra. So it is important that a Y2K compliant version of Zebra
is installed and tested along with changes made to the shared libraries. There
has now been an analysis done on the Y2K problems in Zebra. Also, some changes
and testing has been done on BW. For more information, see Tim Shippert's
analysis of time with Zebra.
- Dependence on outside factors
Another concern is that there will be outside factors that determine how and
when the Y2K problems are fixed within the IDPC's. One concern is that as
instruments and external data sources themselves become Y2K compliant, the incoming data may change. This may cause unexpected changes and delays in
fixing and testing some of IDPCs. Another concern is that the users of our data can not yet deal with 4 digit filenames. The EC, for example, can not
yet accept filenames with 4 digit years from the SGP or XDC. Also, there
may be other programs, databases, quicklooks, etc. utilized both within
and outside of our data systems which may need changes to parse the four-digit year filenames.
What we did to assess the problems:
We surveyed the programs and scripts which are part of the IDPCs across the XDC, EC, SGP, NSA, and TWP data systems. We checked for areas in the code which may not work properly either in the year 2000 or
will have to be changed to process data stream names with four digit years.
SGP SDS
NSA and TWP SDS
- Excell list of programs and scripts including y2k problems:
Excell version and HTML version
- There are about 9 ingests and 3 collection programs the NSA data system
which require changes. A number of the ingests, shared libraries, and other
code within the system are based on code also used on the SGP and NSA
data systems. Both the NSA and TWP data systems are already using four-digit
year filenames.
XDC
- Excell list of programs and scripts including y2k problems:
Excell version and HTML version
- XDC Standings
There are about 65 individual scripts and programs which process the
XDC IDPCs. Most of have simple problems each of which could be fixed
within a few hours. However, testing and integrating the changes could
take longer. Some changes are also dependent on outside factors, such as
requiring patches to Zebra. It was estimated that it could take about
90 days for a single person to assess, change and test the entire set of
IDPC's. This does not include delays or time needed to install and test
new version of software not generated at the XDC (such as BW, Zebra,
GRIB Utilities, etc...). There will probably also be other problems
found while changes and testing are being done.
VAPs (EC)
Sample Templates for organizing Y2K issues for IDPCs
More Information on Y2K