> > From: Bob Leif, Ph.D.
> >
> > Two questions. 1) Was this date package written in Ada? And 2) If it was
> > written in Ada, how much work did it take to fix? I suspect that there
> > may
> > have been other Year 2K problems in Ada. However, the ease of maintaining
> > Ada made the effort to repair minimal. Minimal effort projects are seldom
> > reported because they do not change the budget. Actually, the Year 2K
> > problem is NOT the disease. If Year 2K problem is significant, it is a
> > symptom of poorly engineered software.

I wrote the fix.  I added a sliding window for 2-digit date interpretations,
that can be changed by the application.  I fixed the get_from_text routines
to accept either 2-digit or 4-digit dates (with the 2-digit dates being
interpreted based on the sliding window).  I also added 4-digit output
routines.  Even with the bad spec and implementations mentioned below, it was
a simple matter to make these changes.  The hardest part was figuring out
what changes to make that would be least obtrusive (if there existed any code
using the package), and most likely to be correct even if used "stupidly".

Note that the spec for dates.a is a very *bad* abstraction.  It was only a
toy interface used for the "Getting Started with VADS" document, and was
included as source only so the user could "follow along" with the
documentation.  It was put into "publiclib", where there was explicitly NO
Verdix (originally) or Rational (later) commitment to correctness.

The implementation is so brain-dead, I was embarrassed to work on the code
body -- for example, subtraction of two dates is done by incrementing the
lesser date until it equals the greater date, incrementing the count of days
with each iteration of the loop.  The spec is so bad an abstraction (really
it is a non-abstraction) that I cannot believe anyone actually ever used the
package outside of the Getting Started document

To top it off, the package itself was *NOT* Y2K-non-compliant per se.  It was
only that the package *might* have been *easily* used in a Y2K-non-compliant
manner that caused the problem.

The package could have been used in a Y2K-compliant way by any application
that did a little work when calling it.  That is the problem with
Y2K-compliance and "parts of a program" (including the choice of language) --
they simply are inconsistent concepts.  Only an application can be
Y2K-compliant or Y2K-non-compliant, not any particular part of an
application.

In spite of disclaimers, poor abstraction, and poor implementation, crazed
Y2K-zealots were having major problems with this "non-compliant" package in
VADS.  Essentially they concluded that all of VADS was non-compliant.
 Telling them to simply delete the package from their release did not weaken
their resolve.

Eventually it became clear that rather than try to talk sense into these
people, it was easier and less time consuming to simply put out a version of
the package that was more likely to be used in a Y2K-compliant manner by
"dumb" applications (which by my reckoning are the only ones that might use
the package).

Hopefully this is the last discussion on this aspect of Y2K-compliance.  I
personally find it all a bunch of hype over nothing.  Some things will break,
but few will break on Jan 1, 2000.  Most will break a year or two before that
or in the ensuing year.  For example, when your new charge card came with a
02/01 expiration date, that was an opportunity for a Y2K failure.  Similarly,
when you go to renew your car license in Jan 2001 from the last registration
that was done in 1999, that is an opportunity for a Y2K failure -- I can
envision them getting 2000 right, but screwing up on subtracting 99 from 01.
 There are all sorts of ways to make programs that break, and Y2K is only one
of them.  In the end, all critical things will work (because people have
checked), and many non-critical things may break (I consider the IRS
non-critical unless I get audited).

It is a great opportunity for COBOL, FORTRAN and assembly code programmers to
make a lot of money if they can stand reverse-engineering some of the worst
code ever written.  The C-code guys are good until 2032 :-).

Regards,
Steve

Steven Deller, Apex Ada Marketing
[log in to unmask], (410) 757 6924
Rational Software Corporation, http://www.rational.com