Hello everyone,

I would only suggest this as a preliminary report, since the extent of
impact due to the Y2K problems are beyond my scope to estimate at this
time also since it is clear that many businesses are not sure as of yet
whether their software is compliant or not (for example Microsoft's
change of mind).

If you see something I missed please let me know. As for some good
places to search to see if your software is y2k a couple of good places
are:

http://www.itpolicy.gsa.gov/mks/yr2000/cioy2k.htm

http://y2k.policyworks.gov/index.cfm

http://www.army.mil/army-y2k/

Thanks,

Christopher M. Klaus

**ARM CM SW:**

***Bison, gcc, and gdb*** are all gnu products. From gnu we have a
statement of no guarantee. There is an argument to why gnu should be
fine, since gnu uses a similar 32-bit standard for time keeping like
unix systems and thus will probably work until 2038 like unix systems.

I suggest no action for the year 2000; and to reexamine for year 2038.
(Note: the year 2038 issue should be solved by moving to a 64-bit
system.)

( See http://www.gnu.ai.mit.edu/software/year2000.html for more
information.)

**Perl** is based on the gmtime() and localtime() functions which has
the same 32-bit standard, which should be fine until the year 2038.
Their website says they are a "...nominally year 2000 compliant tool..."
in that when used correctly they feel they are compliant.

I suggest no action for the year 2000; and to reexamine for the year
2038. (Note: the year 2038 issue should be solved by moving to a 64-bit
system.)

( See http://language.perl.com/news/y2k.html for more information.)

**IDL** is y2k compliant. According to their website, "IDL does not
itself manage or use system time; it simply passes the operating system
time to the user." Thus if our system is compliant IDL will be
compliant.

Their is no action to be taken here.

( See http://www.rsinc.com/idl/main.html for more information. )

**NetCDF** is a format and thus is y2k compliant. Russ Rew with the UCAR
Unidata Program writes, "All versions/releases of netCDF are Year 2000
ready, because none of the netCDF libraries or programs deal in any
special way with dates as a data type."

There is no action needed for netCDF format. There is action for netCDF
data in that we should check what kind of date is being stored, if it is
y2k compliant, and if not do we need it to be (ie for calculations).

( See http://www.unidata.ucar.edu/glimpse/netcdf/2801 for more
information. )

**ARM IDPCs:**

> **Ebbr** needs more investigation to be sure it's ingest is y2k
> compliant.

**Ecor** may have a y2k issue due to the naming convention. From Dick
Hart I have the following information:

> *Chris,*
>
> *The ecor computer will not have any problem handling the century
> roll-over.*
>
> *The only possible problem would be with the ingest. The ecor data
> file*
>
> *names use yydddhhm.\* where yy is 2-digit year, ddd is 3-digit julian
> day,*
>
> *hh is 2-digit hour, and m is tens of minutes (either 0 or 3). The
> file*
>
> *names will go from 99365233.\* to 00001000.\* just as the ingested
> file*
>
> *name will go from \*.991231.\* to \*.000101.\*.*
>
> *Dick*

**VCEIL** needsmore investigation to be sure it's ingest is y2k
compliant. So far I have this information from Connor:

> *Hi Chris,*
>
> *First the hardware:*
>
> *The VCeil instrument does not have any internal clock, so it will be*
>
> *immune to Y2K issues. I am in the process of documenting the BIOS on*
>
> *each instrument PC, to insure that each is compliant.*
>
> *Next the operating system:*
>
> *The PCs are running WinNT 4.0, which is Y2K compliant.*
>
> *Finally, the data acquistion program:*
>
> *The original CT-VIEW code provided by Vaisala was written in Visual*
>
> *Basic, compiled 16-bit. ARM has significantly modified the code,*
>
> *increasing functionality, and converting to true 32-bit. Testing is*
>
> *required to determine if the data acquisition program is Y2K
> compliant.*
>
> *The filenames are named with a YYMMDDHH.DAT format. It shouldn\'t be
> a*
>
> *problem to change the name to YYYYMMDDHH.DAT, but it remains to be
> seen*
>
> *if there are any hidden bugaboos. Brian Ermold is the primary author
> of*
>
> *the modifications to the original Vaisala code, so some of these
> issues*
>
> *will need to be worked on by/with him.*
>
> *Any other Q\'s, feel free to drop me a line.*
>
> *Connor*
>
> *Br*

**MPL, BLC, RL, AERI, and WSI** are not y2k compliant. The following
discussion from Laurie Gregory describes the problems:

> *Chris,*
>
> *I checked on the ingests for IDPCs MPL, BLC, RL, AERI, and WSI for
> Y2K*
>
> *problems. I didn\'t go into great depth to figure out what problems
> are*
>
> *expected, but here is what I found from a cursory look -*
>
> *All of the ingests I checked deal with time and there will have to*
>
> *at least some changes in each to make them Y2K compliant. Here are 3
> ways the*
>
> *ingests use time that are seem to be most common*
>
> *1) Determine the current time and to timeout if the ingest has run*
>
> *too long. (These should be relying on system time\'s and hopefully*
>
> *are Y2K compliant, but should be double checked). Here are some*
>
> *of the functions related to this -*
>
> *elapsed_time_since (startTime)*
>
> *get_ingest_time_limit(PLAT, platnum);*
>
> *get_current_time(&startTime);*
>
> *2) Reading and converting the times from the raw files. This is*
>
> *where a lot of 2 digit years are manipulated. I anticipate*
>
> *this will be where the main changes will be to the ingests.*
>
> *Some shared routines that are associated with this that should*
>
> *be checked are:*
>
> *days_sinceJan(MM, YY) + DD;*
>
> *set_sample_time(hhmm, jday, YY, ztime)*
>
> *3) Setting up the mail messages to the MDS. This is reliant on some*
>
> *shared library code that will have to be checked. Also some*
>
> *coordination may need to be made to check that it does not*
>
> *affect the way the MDS code handles the MDS messages automatically*
>
> *generated by the ingests. I don\'t anticipate any major problems*
>
> *or changes though. One shared library function I found that*
>
> *should be checked is*
>
> *sol_set_mail_header_info(ztime.zt_Sec,NULL,NULL);*
>
> *So, if we check the shared library code, I see only minor changes*
>
> *to the ingests themselves. The changes should only take a couple*
>
> *of days. However, I have the following concerns -*
>
> *o There will be changes being made at instrument level and*
>
> *the machines which are collecting and logging the data. These
> changes*
>
> *will have to be made to make them Y2K compliant. The WSI, for*
>
> *example, relies on a computer running DOS and the RL relies on a*
>
> *i486 running Windows 3.1. There may be changes, which I can not*
>
> *anticipate at this time, which will cause changes in the IDPC.*
>
> *For instance, raw file names may change, or the format of the data
> files*
>
> *might change. I\'m attaching a response from Tim Tooman that*
>
> *contains some info on Y2K effects on the WSI & RL.*
>
> *o Four digit years in data file names. If we don\'t use 4 digit*
>
> *years, filenames won\'t sort properly. If we do go to a 4 digit*
>
> *year in the filenames, that will be additional changes in the*
>
> *ingest code and in all other systems which use our data files.*
>
> *The change to 4 digit years in ARM filenames will have to*
>
> *coordinated with changes to other processing code (like Zebra or the*
>
> *bundling scripts) and with the EC & Archive. I believe the*
>
> *consensus is that we are moving toward 4 digit years in the*
>
> *filenames.*
>
> *o Some ingests rely on outside software. The AERI, for example,
> relies on*
>
> *the ohwhio libraries that should be checked for Y2K problems.*
>
> *o If/When any changes are made to IDPCs or shared code, we*
>
> *will have to coordinate those changes with the other sites which*
>
> *also use the same code.*
>
> *I guess the bottom line is that there are Y2K problems with*
>
> *the IDPC\'s that I checked (MPL, BLC, RL, AERI, and WSI). What*
>
> *is the impact? I think there will be minor changes needed to*
>
> *the ingest code. I think, however, that when fit into the*
>
> *scheme of things, there will have to be good amount of time and*
>
> *effort put into testing and coordinating even minor changes. There*
>
> *may be cascading affects for ingests that are implemented across*
>
> *sites and there will be coordination issues within the pipeline to*
>
> *make sure that the instruments, collection routines, ingest
> routines,*
>
> *transfer, and MDS mechanisms are all in sync.*
>
> *For this round, I only checked the ingests. Other code probably*
>
> *should be checked like the shared library code, bundling scripts,
> collection*
>
> *routines, etc\... I\'m not sure who all is checking on what. Let me
> know*
>
> *if you need any other information.*
>
> *-Laurie*
>
> *\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\**
>
> *Name : Laurie Gregory Brookhaven National Laboratory*
>
> *e-mail: Laurie.Gregory@arm.gov P.O. Box 5000, Building 490D*
>
> *phone : 516-344-2266 30 Bell Avenue*
>
> *Fax : 516-344-3911 Upton, NY 11973*
>
> *\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\**
>
> **Blc_comm and sonde_comm** are y2k compliant. Richard Eagan describes
> their status as follows:
>
> *Chris,*
>
> *Both blc_comm and sonde_comm (Belfort Ceilometer and Vaisala Sonde*
>
> *collection software) appear to by Y2K compliant. However, neither*
>
> *have been tested.*
>
> *Blc_comm generates data file names of the form:*
>
> *YYYMMDDhhmmss where: YYY = years since 1900*
>
> *That, I believe, is adequate to survive the Y2K transition.*
>
> *rce*
>
> *\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--*
>
> *Richard Eagan voice: (630) 252-3435*
>
> *Systems Engineer fax: (630) 252-5128*
>
> *Argonne National Laboratory e-mail: eagan@dis.anl.gov*
>
> *9700 S. Cass Ave.*
>
> *Argonne, Il 60439-4832*
>
> *Mail Stop DIS 900-12*
>
> *\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--*

Shared code that I can think of include the SDS ingest libraries,

ftp_comm, ICM, TDB, zebra, StageCheck. You can check the /apps/src

directory too.

ftp_comm

ICM

StageCheck

**ARM COTs SW:**

**Window 95 and NT 4.0** are compliant with patches. The following
information from Jesse Smith and website supplied by Trav Stratton agree
with this information:

> *Chris,*
>
> *I have checked on our Filemaker Pro database, it is Y2K compatible.*
>
> *The operating systems NT 4.0 and Windows95 are both Y2K compatible
> with*
>
> *a couple of patches. However, we will probably will be upgrading to*
>
> *NT5.0 in the near future for the operations PCs.*
>
> *Pioneer Telephone tells me that the telephone systems are Y2K*
>
> *compliant. They will send me a letter to confirm this.*
>
> *The other concern I have is the BIOS in the PCs. All of the PCs that
> I*
>
> *have purchased for operations are Y2K compatible. The older PCs at
> the*
>
> *BFs and the instruments will have to be tested for compliance.*
>
> *The alarm system is in the process of being redesigned. I will talk*
>
> *with the designer about Y2K and let you know what I find out.*
>
> *Jess*

( See http://www.microsoft.com/year2000/ for more information. )

As a plan of action I would suggest watching Microsoft's website and
adding patches as necessary.

**Solaris** 2.6 is considered y2k compliant when free patches are
installed. As of now there seems to be no patches on their website for
y2k; but there is a location for them if the are needed in the future.

As a plan of action, the network administrator should watch the sun
website for the latest information on whether solaris 2.6 needs a patch
and install patches as required.

**Solaris** 2.3-2.51 is considered not y2k compliant; but patches may be
available to correct these problems.

I believe our plan of action for this is agreed on, to move to solaris
2.6.

( See http://www.sun.com/y2000/cpl.html and
http://www.sun.com/y2000/enhancements.html for more information on sun
software and hardware. )

**ARM SW DEV in-house:**

**Shared libraries** are not y2k compliant. The shared lib did have a
couple of bad areas of which two were well commented and the others may
not be a problem. They are:

the program *ingest_zeb.c*, the functions: *days_since 1970* and
*set_sample_time* are commented as not y2k and one is hard coded to stop
at y2k.

the program *ingest_zeb.h*, the function *isleap(y)* to check leap year
has a formula that may not caculate 2000 as a leap year.

the program *ingest_log.c*, the function *instrlog_summary_time* uses a
2 digit year; but it doesn\'t seem to be used for calculation.

The method used to find these was using grep on time, gmtime, date, and
year.

Although the code changes seem minor, implications need to be explored
before any code is changed. So the first plan of action is to find where
these programs are used and how these functions would impact their
usage. I would say a 1-2 days to fix the code; but at least a week to
explore implications for someone who knows the system.

**Tdb** is not y2k compliant. A letter with a description of the problem
from Richard Eagan follows:

> *It appears that the tdb library is not currently Y2K compliant. The
> tdb*
>
> *internal function get_GMT_string() uses strftime() with a format
> argument of*
>
> *\'%y\' which returns only the \'year within century \[0,99\]\'. Also,
> the function*
>
> *GMT_string_cmp() performs time comparisons on time string that has
> only a*
>
> *2-digit year, thus time comparisons between 1999 dates and 2000 dates
> will*
>
> *fail.*
>
> *There may be other problems. I did not see a need to look deeper at
> this*
>
> *point.*
>
> *The tdb has an api of several functions which pass a time variable:*
>
> *o tdb_delete_timed,*
>
> *o tdb_fetch_timed,*
>
> *o tdb_insert_timed, and*
>
> *o tdb_replace_timed.*
>
> *The time arg is in the standard unix format of \'seconds since
> 00:00:00*
>
> *UTC, January 1, 1970\'. Therefore, the api is expected to remain
> un-changed*
>
> *after the tdb is fixed. However, applications that use these
> functions should*
>
> *be examined to ensure they use time in a Y2K compliant manner.*
>
> *There is a command line tool associated with the tdb: tdbjar*
>
> *which may use an arg of the form YYMMDDHHMMSS. Tdbjar and scripts
> which use*
>
> *the command will need to be fixed.*
>
> *These problems are fairly trivial to fix, probably on the order of
> only 2-4*
>
> *days. NOTE, however, that it is not at all clear that a modified tdb
> lib*
>
> *will properly interface with the database that was created before
> the*
>
> *modifications.*
>
> *rce*
>
> *\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--*
>
> *Richard Eagan voice: (630) 252-3435*
>
> *Systems Engineer fax: (630) 252-5128*
>
> *Argonne National Laboratory e-mail: eagan@dis.anl.gov*
>
> *9700 S. Cass Ave.*
>
> *Argonne, Il 60439-4832*
>
> *Mail Stop DIS 900-12*
>
> **MDS** is not y2k compliant. Kathy Doty describes the flaws as
> follows:
>
> *Chris,*
>
> *I did some preliminary checking of the software that*
>
> *provides the SGP MDS application and found that*
>
> *there are a number of areas that will need software modifications*
>
> *to make them y2k compliant.*
>
> *The c programs that handle taking email messages and turning*
>
> *them into MDS entries all contain calculations using time.*
>
> *I have a number of perl and c shell scripts that also perform*
>
> *calculations with time. In some areas I found \"19\" hard coded for*
>
> *the first two digits of the year. :(*
>
> *What is the impact?*
>
> *Changes to a number of programs and scripts that provide the*
>
> *MDS capability are required.*
>
> *I think this will require a good amount of effort and time to make
> the*
>
> *changes and perform tests. To be conservative in my estimate, I
> would*
>
> *say certainly greater than a few weeks - more likely a month or
> more.*
>
> *Kathy*
>
> *\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--*
>
> *Kathy J. Doty \| email:doty@bnl.gov*
>
> *Brookhaven National Laboratory \|*
>
> *DAS/ASD/SISG \|*
>
> *P.O. Box 5000, Bldg. 490D \| Phone:(516) 344-3832*
>
> *Upton, NY 11973-5000, U.S.A \| Fax: (516) 344-3911*

**MISC**

From using a global search with grep for gmtime I found the following
potential problem areas, which still need to be check closer. The action
item is to check each and determine if a y2k issue exists.

./dev/bin/StageCheck.pl

./dev/bin/blc_rename.pl

./dev/bin/comlog_rename.pl

./dev/bin/comlog_report.pl

./dev/bin/digicora_rename.pl

./dev/bin/mpl_rename.pl

./dev/bin/rwp_daily_tar.pl

./dev/bin/runcallang.pl

./dev/bin/rwp_rename.pl

./dev/bin/siros_time.pl

./dev/bin/sneaknet_report.pl

./dev/bin/sonde_filter.pl

./dev/bin/aos_rename.pl

./dev/bin/pccora_rename.pl

./dev/bin/sonde_nws_extract.pl

./dev/bin/mmcr_bundle.pl

./dev/bin/icm.pl

./dev/bin/opslog_sendmail.pl

./dev/bin/xyplot

./dev/bin/read_if_tape.pl

./dev/bin/rwp_default_par.pl

./dev/bin/mplhr_rename.pl

./dev/bin/setup_aeri_comm.pl

./dev/bin/wsi_butler.pl

./dev/bin/wsi_butler.pl%

./dev/lib/perl/filter.pl

./dev/lib/perl/redirect.pl

./dev/lib/perl/mfrsr_butler.pl

./dev/lib/perl/rwp_param_butler.pl

./dev/tools/archive_source.pl