Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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 -- Ignore unavailable to you. Want to Upgrade?

To: James Unterburger who wrote (10668)	6/27/1998 12:21:00 PM
From: Neil_L	Respond to of 18691

You have to differentiate between the methodology for storing dates and the actual storage of them. While many methods work and are in some use, the most common method over the years is to store in the form of yymmdd, regardless of the numerical or character storage type used...packed, ASCII, binary, etc. Also, its over the years that newer and more efficient data types have been constructed. Other methodologies include julian dates, but even here we have examples of the century not being included. While it is difficult to argue the pros and cons of which way may be better, the fact remains that the vast majority of dates are stored as yymmdd or some variation that does not take into account the century, and after all, thats what its all about. I can also verify to the tediousness of the work. Going back into your own code many years later can be bad enough, but going into someone elses code written many years ago can be very tiresome and error-prone. Also, there are many systems where the original crew has moved on and no-one really understands the original business logic completely, many little patches and hard-coding has been used over the years to keep it all going, provide some of the problems when deciding to rewrite or replace the system. It many times is the case where the y2k problem is small compared to the alternative. I know I may sound a little doomsdayish but thats only in relation to the complacency out there. I do become more and more concerned about the problem the more I read as it becomes clearly apparent that we are not prepared with very little time left and an immovable target date. Once again, mans reactionary nature willed be called upon to temper the problem. Neil.

To: James Unterburger who wrote (10668)	6/27/1998 7:04:00 PM
From: daffodil	Read Replies (3) \| Respond to 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