Here's an interesting tidbit for the Ada community to consider as we head
into Tri-Ada:


On a major weapon simulator program, we have uncovered an unusual problem.
Our application program code was written in Ada 83 based on an older
FORTRAN system. The application itself does no date processing. For student
record-keeping, the instructor enters a date but it is stored as a text
string and is NOT used in any type of calculations.

We are however confronted with a Y2K problem. The Digital UNIX operating
system currently used is NOT Y2K compliant. The system administrator can
only enter dates between 1969 and Dec. 31st, 2000. Note that the problem
will NOT occur on Dec. 31st, 1999 as with most systems. So what's the
problem? Well, the application does use the system date as a seed for
random number generation. This is still not a problem since the
administrator can just set a bogus date. However, the system is also being
sold overseas and the foreign operators who are used to a different
calendar system may not understand how to set the date to a usable value.

So here's the problem: If we update the operating system, the compiler we
are currently using returns numerous compilation errors when recompiling
the code. The compiler is the older Meridan compiler. We are thus faced
with the following dilemna: If we upgrade the operating system, we can't
compile the code - if we don't upgrade, we can't satisfy government Y2K
compliance requirements and may cause problems with the international
users. Obviously, it doesn't make sense to have the Ada vendor community
take a giant step backwards and create an Ada 83 compiler for a NEW
operating system. Thus, we may be faced with the task of migrating all of
our application code to Ada 95 and finding a new compiler. Since the Y2K
compliant version of Digital UNIX may not be released until Jan. '98, we
are rapidly approaching crunch time.

I think the Ada community might want to consider a workshop or forum at
Tri-Ada to address Ada Y2K issues and solutions.

Dean Runzel
Computer Engineer
US Army STRICOM

The opinions expressed above are my own and do not reflect any official
government position or policy.