With all the focus on an improper White House dalliance, it’s easy to lose sight of a couple of other items of note: the unlikely but possible global economic meltdown and – even harder to get a grip on – the possible difficulties 14 months from now when all the 999s on time’s odometer turn to 000s.

Like most of you, I am a babe in these woods. Like most of you, I don’t think anything really terrible is going to happen. (Having lived through many of them, I don’t count a recession, for example, as terrible.) But even those of us who are just essentially powerless spectators make a serious mistake, I think, if we don’t take precautions – and now, or soon, when it’s the easiest thing in the world to stock up on a couple of month’s emergency supplies just in case. If you missed my broad, non-technical rationale for this, please click here.

Today and tomorrow: Insights from folks much more competent than me.

From Dan Frerking: “I am a software developer for a small insurance company in the midwest. I also have a 4 year degree in Computer information Systems. My expertise is in Oracle, Cobol and C programming languages. We are wrapping up our Year 2000 project of which I was in charge of the coding part. I was amazed how much of our software was not compliant including the operating systems of our UNIX, NT, and Novel servers, and our phone switch. Just about everything needed to be upgraded or changed. We were lucky. We are only a 4-year-old company with very recent hardware and very modern tools.

Krishna’s comment that any compentent [sic] CS grad student can fix all Y2K problems in matter of days is laughable.”

A.T.: Dan has a lot more to say, some of it technical, some of it pretty simple – and scary. To read it, click here.

From Fred Holborn: “I’ve done extensive research on Y2K and found that having lots of smart people working on it doesn’t insure success. Check these out. Then check your pulse …

DoD: High Ramp to Completion
www.dtic.mil/c3i/y2k/slides_1998/sld005.htm

DoD: Some mission-critical DoD systems will not be Year 2000 compliant
www.defenselink.mil/news/Jun1998/n06301998_9806303.html

DoD: How will the Defense Department’s 30,000 computer systems react as Jan. 1, 2000, begins ticking?
www.defenselink.mil/news/Jul1998/n07021998_9807023.html

DoD: Y2K Standard Briefing:
www.dtic.mil/c3i/y2k/slides_1998/july1998.ppt

Navy: The U.S. Navy and the Y2K Challenge: Answering the Bell
www.cnoy2k.navy.mil/NY2K/document/SOCOM/Default.htm

DoD: A National View of Nuclear Deployment
www.dtic.mil/c3i/y2k/slides_1998/sld024.htm

From Bruce Chapman: “Your thinking on Y2K tracks pretty well with George Gilder, one of our senior fellows, who also is a sponsor and the moderator of a forthcoming national conference on the public policy issues of Y2K. [A.T.: It was September 24. But you can get a sense of it by visiting the Web site at the end of Bruce’s message.] This is the first conference that puts the full public policy agenda on the table. Chairs of the House and Senate Y2K committees (Sen. Bennett, Rep. Horn) and the White House Council on Y2K will be there, as well as a host of state officials, business people, techies and writers.

Here’s the problem (in addition to the Grand Canyon of marbles analogy you cited): With the Clinton sex scandals and Asian stock market flu absorbing the news, the important is being driven out of public attention by the immediate. We run the risk of public opinion going straight from Bill-Gates-Will-Fix-It to We’re-All-Gonna-Die. Which, as you say, is not constructive.

“We plan to air some public policy solutions, not the least of which is that media and responsible politicians AND CORPORATE LEADERS (who typically are taking a go-it-alone stance) have to move this problem way up the agenda of governmental interest – in Congress, yes, but especially in the Administration.

“You can check out the conference at www.discovery.org.

“P.S. I first had the Year 2000 problem pointed out to me when I became director of the U.S. Census Bureau in 1981 and took my initial tour of the mainframes. We all laughed about the problem ‘someone’ was going to have in 19 years!”

Tomorrow: More (but soon: Gummi Bears)

__________________________________
continuation of Dan Frerking’s comments:

“A normal Cobol system can have several hundred modules. Some of them are what I will call ‘Main’ programs that have what we call ‘Copy books,’ which are small pieces of code, or file descriptions. They also ‘call’ other Cobol programs. For Krishna, it is kind of like a Header and a Library in C. Cobol can get its data from several sources, either a database like IBM’s DB2 or a unique COBOL database file called VSAM ‘Virtual Sequencial [sic] Access Method.’

“If you are lucky and the data source is DB2, and the date columns are numeric 6 (YYMMDD), you can alter a table in the database and add columns to hold the entry and create a new index using it without affecting the programs that use it. This will solve half of the problem – storage. The other part of the problem about the programs will be discussed later.

“If you are not that lucky and using VSAM, and the dates are stored YYMMDD, records are physically stored like the following. Notice how 99 is bigger than 98 but 00 is less than 97.

Trans Date Amount
000103 212.50
000229 381.98
975402 298.98
980904 30.30
981201 120.32
990213 457.23
990909 234.98
991231 279.93

“The obvious thing to do is to expand the field to numeric 8, and add 19000000 to them. That is great, but every program that uses this file will have to be recompiled with the file description changed. If not, they will abort at runtime. When you recompile them, any intermediate dates will have to be lengthened, any screen input dates will have to be lengthened, any date validation will have to be changed, all report programs will have to be changed, any strange date logic will have to be changed.

“Now, multiply this by several hundred dates in several hundred ‘Main programs’ and several hundred ‘Copy books,’ and several hundred ‘Called programs.’ And one more thing … they all have to come up at the same time with no bugs!!!

“It gets a lot more fun if source code is either lost or an old version. The place I used to work had lost the correct version of one of the Called programs. When I recompiled these programs and tested them, the payroll checks were coming out at $5,000 for 40 hours a week for a data entry operator. The data entry operators thought I was doing a great job, but the boss was not amused. It took two weeks of trial and error to get it working correctly again. I could not imagine how long it would have taken if the code was lost.

“I would also like to dispel the myth that it is mostly a COBOL problem. Most programs including MS Access 2.0 and Oracle’s Developer 2000 tools have problems. Look at their web sites if you do not believe me.

“Oracle is the 2nd largest software company in the world. Their main product is their database, but they also make tools that are used to develop client server applications, and are increasingly focusing on the web.

“Oracle has been marketing their tools as Year 2000 compliant. While this statement is true, it is not as cut and dried as that. The truth is as recently as a couple of years ago when you install Oracle on your server by default the date format is DD-MON-YY, this causes a little problem. If you type in 01-JAN-00, and the current date is before 2000, it interprets the date as 01-JAN-1900. If it is 01-JAN-2000, and you type in 31-DEC-99 it interprets it as 31-DEC-2099. The fun part is, it writes it to the database this way, so if a Y2K compliant program reads it, then the results will be wrong.

“There are several work arounds for this problem, including upgrading to a ‘Date enhanced version’ that they just released, and changing the date format to interpret it differently, but they both include going through every program and physically changing any non year 2000 code i.e. anything that says DD-MON-YY.

“It only takes missing one little problem in the middle of one program to corrupt your database. What is bad about this is the problem will show up on the compliant programs, and not in the one with the bug.

“I am not an authority on other newer products like Visual Basic and Paradox but I have heard they may have these same problems. It is not the products themselves that are not year 2000 compliant, but the way they are being used.

“As for embedded chips … I can think of at least one example of how a date may cause a chip to fail. The scenario is dependent on this assumption. An embedded chip has storage parameters like this.

‘flag’    one character in length
‘date’   2 characters in length
‘flag2’  1 character in length

and so on…

“If the logic in the chip either adds 1 to a 99 or gets the number of years since 1900 (something like tm_year for you C programmers) then what will happen? 100 will be put into the date field resulting in an overflow, and 0 put into flag2. Now what does flag2 do? And what does 0 mean to the chip? Shut a life support system down? Open a valve in a nucular [sic] power plant? Shut off fuel to the jet engines? I do not know. It may not do anything, but the possibility is there.

“What does all of this mean? It means there is a real problem out there. And we should not be listening to any cocky student who does not have a clue about what he is talking about. It also means that everyone that wants to maintain our high standard of living that this country enjoys, should be doing everything possible to ensure that their organization can survive. If we do not take this thing seriously, then the topic of conversation in the soup line in March 2000 will be ‘hey remember when the Dow was only down to 7600?’ and ‘Do you think it will top 500 this week?'”

 

 

Comments are closed.