Re: Confusing language, was Re: Help help.. please.i am totaly new in ada programing

[Richard D Riehle <laoXhai@ix.netcom.com>]

>Robert A Duff wrote:
>
>> That might be true in some cases, but I think that in the vast majority
>> of cases, Y2K bugs were caused by sloppiness.

Well, now.  That raises my dander a little bit, Mr. Duff.  I am 
privileged to be one of those people who contributed to the creation
of the Y2K problem.  My contribution was not a function of sloppiness.
It was carefully planned.  In some cases it was the most effective
solution available.

In 1969, working in a computer programming environment heavily dependent
on 80-column punched cards, we discovered that the single column assigned
to hold the year would create problems with calculations when we turned
over to 1970.  What to do.  What to do.  We decided to use the 11 punch
for the 7, the 12 for the 8, and a combination of the two for the 9. This
created a nice little Y2K problem.  None of us expected to be using the
program with punched cards in the year 2000.  

I worked on some COBOL projects for both commercial and DoD software
in the 1960's and 1970's.  The COBOL compilers were not designed to
use binary numbers.  We did have hexadecimal values.  So we coded the
year in a single byte, representing two digits.  Usage Comp-1 and Comp-2
were regarded as strange, and they were not portable, so we almost always 
designed with Comp-3 or Display. The disk drives were not large, the
storage access methods unsophisticated, and primary memory was often
a concern.  If, in a file of 50,000 records, we could save 50,000
bytes of storage by using only one byte for the date, that was a
significant savings.  The fact is that often we had many types of
records with many kinds of dates so we were often saving in the 
neighborhood of a half-million bytes.   When your maximum disk storage
is ten megabytes, guess what we are going to do?

Once those files were designed, they continued to be used even after
the hardware grew to accomodate larger date fields.  New programs that
used this earlier data also used their files.   Those new programs were
designed to preserve compatibility with the original files.  The model
simply grew upon itself.  In commercial environments one does not 
periodically rewrite the entire system.  Certainly, one does not create
incompatibilities between current and historical electronic records.

So many of the pronouncements about Y2K are a function of
oversimplicfication.  Those of us who were creating the problem
were doing the best we could given the environments in which we
were working.  Sometimes the question would be raised, "What do 
we do when the century turns over."  The people in the trenches
who were writing programs even asked such questions.  

The Y2K problem is a function of the economics of the period. Most
managers understood that no one would promote them for solving some
problem with implications 20 years distant.  There were too many
projects to get finished with more imminent potential for disaster.

If there was sloppiness, it was a managerial sloppiness, not a
technological sloppiness.  All the structured programming in the
world, all the object-oriented programming methods, all the blame
one can affix on any technological approach, fails to recognize the
true complexity of the problem going all the way back to its origins.

For a concrete example, let me share the following.  A programmer was
converting some programs from COBOL to Ada.  The layout for a record
in his design, as late as 1987, was,

         type XXXXXXXXXX is
            record
                ...
                MM  : String (1..2);
                YY  : String (1..2);
                DD  : String (1..2);
                ...
            end record;

When asked about it, he noted that the original files were designed that
way and his program was required to process the data without altering
its formats.   Was he being sloppy?  Perhaps.  But who was going to 
authorize copying the ten years worth of files on magnetic tape that
would have been necessary to preserve the historical continuity of this
database?

Richard Riehle
http://www.adaworks.com