SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Strategies & Market Trends : Roger's 1998 Short Picks

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: James Unterburger who wrote (10668)6/27/1998 7:04:00 PM
From: daffodil  Read Replies (3) of 18691
 
As one of the ancients who programmed in COBOL and other languages (10 bonus points if you remember ARGUS) in the 60's and 70's, for several different companies and for applications ranging from payroll to CAD/CAM, I believe that it is true that tens of thousands of programs were written with a two-digit year code.

Today, when even laptops have 6 GB hard drives, it's hard to remember how precious those 2 little digits were in the COBOL era. Expanding the year field to 4 digits was therefore not an option, but we could have avoided the problem with a few extra lines of code that would have protected us till, say, 2068. For example, "IF DATE < 68 ADD 1 to SW-2000", "IF SW-2000 = 1 GO TO YEAR-2000" . Why did we so often not bother? I think about that question a lot. We weren't lazy, but we were always striving to be efficient. Somehow we (the techies of our generation) simply assumed that change would come so fast that there was no way our code would last beyond our 50th birthday! But, for many companies and many applications, it has. Running these archaic batch-processed programs is still a nightly ritual at virtually thousands of companies. So the problem is real.

One thing that I have read on SI, and that in my opinion is highly unlikely, is the assertion that some of these programs can't even be located--that somehow these millions/billions of lines of code cannot even be found to be fixed. IMO that's hogwash. Virtually all of the programs still in use have been under continuous active maintenance since they were written. Finding and fixing all of the little twists of convoluted logic that involve the date code isn't as simple as one might think, though. For these programs, there is no silver bullet--1990's technology can assist the programmer, but only human intervention will do.

I also believe that most of the companies relying on these dinosaur programs have been actively planning and implementing their solutions for several years. Whether requiring simple maintenance or complete replacement of the system, this is not going to come as a surprise to large companies on 1/1/00.

However, I am concerned about the problem of embedded systems, and the readiness of governmental entities with regard to ancient code....I believe there is cause for great concern in those sectors.

I hope this is helpful. daffodil
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext