🚀 go-pugleaf

<>
> The problem won't be the computers, but the software.  Some software is
> bound to be wrong, only considering the last two digits of the year.

And thereby hangs a tale:  In 1978, when I was working in banking, I
ran across a curious date storage format.  It seems that transaction
dates were coded with the last digit of the year in one nibble, the
month in hex in the next, and the date (in packed decimal) in the next
two.  I asked one of the more senior systems analysts about this and
she informed me that when the record was originally designed, only the
month and day (in packed decimal) had been included.  This caused
sorting problems on statements printed in January, because checks
written in the December of the previous year would sort after checks
written in January of the current.  So the format had been modified to
the one I just described.

"Good grief!" said I.  "What happens in January of 1980?"  She turned
pale and admitted she had considered that before but managed to put it
out of her mind.  "So why not go ahead and fix it now?"  I asked.

She pointed out that fixing it would require expanding the demand
deposit master record format, a mammoth undertaking.  About a billion
COBOL programs would have to be recompiled.  At this shop we were still
on cards and a rush compile took about a week.  "You want to do that?"
she inquired.  This time I turned pale.  We considered our options,
knowing that one or the other of us would be called upon to fix the
problem.  And you know what we did?

First, I modified the daily demand deposit program with code that
checked for the date and about mid-1979 started printed warnings on the
console of what would happen come new year.  Then the systems analyst
and I got new jobs.  This is known as stepwise interactive development.

-- 
D Gary Grady
Duke U Comp Center, Durham, NC  27706
(919) 684-3695
USENET:  {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary