There have been a number of questions/comments on computer code remediation and implementation prior to 1/1/2000. The premise of many official (and unofficial polly comment) is as follows. If computer code is "fixed" and put into production months before 1/1/2000 then this assures that that code will function on/post 1/1/2000. This is simply not the case for several reasons. Non-programmers have difficulty understanding that there are often a myriad of pathways though large software systems. Its a bit like navigating from one side of a city to the other. There might be 2 or 3 major pathways that most traffic will take, but a significant amount can literally take hundreds of other paths. In the case of remediated code with windowing methodology, a major shift in pathway will take place on 1/1/2000. Think of this as a new off ramp on the highway of LIFE which you must take. Transactions will hit the other half of an IF statement (in whatever language) and execute code it hasn't touched before (except by whoever 'tested' it). There will be some obvious failures (program abends/fails/screechs to a halt) and some not so obvious errors (potentially worse). Furthermore, the underlying production environment (operating system file handling, library/archive backup, sort handling, etc) will all radically change on 1/1/2000 for every production system.

I know this is a bit geeky, but there seems to be this growing perception that Y2K problems will escalate along a smooth curve through the year with clear markers which will predict Y2000 failures. I don't think so. Maybe an obvious spike on 1/1/1999 for State rollovers, but thats probably it until the end of the year. (And maybe JAE as it accummulates through the year - but I doubt it.) Its true that more problems will become public knowledge as media attention focuses on the coming millenia. However, I see 1/1/2000 as a sudden, severe spike. Thats not to say it will necessarily be obvious on that day (unless the grids/telecomm go down). I can imagine giant systems thrashing about like dying mastodons for a month before rigor mortis sets in. So don't get complacent as time goes on. The Fat Lady has to sing.

-- RD. ->H (drherr@erols.com), March 26, 1999

Answers

Sorry, should have said "7/1/1999 State rollovers"

-- RD. ->H (drherr@erols.com), March 26, 1999.

Great point RD. This is why extensive testing is so important. It's much more than just turning the clock forward and running a system. You've got to add some year 2000 data to all those existing files to get a real picture. You've got to force some exceptions to see how a program reacts. You've got to do a detailed analysis of the output of every program before you pass it along to the next. This is all very time consuming stuff, and time is the problem. Ant the not-so-obvious problems ARE going to be a big problem, come the end of Jan. when you "balance the books". Just my $.02 <:)=

-- Sysman (y2kboard@yahoo.com), March 27, 1999.

Could you please explain what you mean by production system in the following:

"Furthermore,the underlying production environment (........)will all change radically on the 1/1/2000 for every production system"

Are you refering to a manufactuuring production system or is this programmer's terminology ?

Thanks

-- All at sea (griffen@globalnet.co.uk), March 27, 1999.

Briefy, and simplified: "Production" code is the code that is actually being used to run the business, whether it's banking or manufacturing, whatever. As opposed to "development" or "test" code". When code under develepment has been tested (?) sufficiently (?) that the developers/testers think it works fairly well, then it is "cut over" to "production."

-- vbProg (vbProg@MicrosoftAndIntelSuck.com), March 27, 1999.

RD;

>I know this is a bit geeky, but there seems to be this growing perception that Y2K problems will escalate along a smooth curve through the year with clear markers which will predict Y2000 failures. I don't think so. Maybe an obvious spike on 1/1/1999 for State rollovers, but thats probably it until the end of the year. (And maybe JAE as it accummulates through the year <

Sir;

I agree with you, (that alone should scare you), and I see that what you are saying very closely parallels the "real world" that we have now. I too can't buy into the bell curve theory. I believe that the hobgoblins will be out in full force on New Years Dday.

I am on record as saying that I believe that we (the PTB) can keep a lid on this thing through about June, after which I expect that enough folks will be talking about it that a general panic can, and will, ensue.

This is premised solely on the sheer volume of entities that open a new fiscal year 2000 on 1 July. I think that it is some 36 states, plus only God knows how many departments, agencies, commissions, businesses, Mom & Pops, etc. Remember that the Federal Government used that date as a fiscal year until the last few years, and many enterprises simply said "me Too".

However, it is a lot easier for the Government to change it's fiscal year than it is for we mere mortals to do so, hence I believe that the numbers of people involved in these business operations will be enough to allow for the old "grapevine" to cause the cat to leave the sack. I personally don't plan on having any more time than that to be as prepared as possible for the Fat Lady.

I may well be wrong in this, and our current stupidity in Yugoslavia could very well render this all moot in any event. However, for now, I hold to the late June early July timeframe. Hope I'm wrong.

Remember though that I am the village idiot, and I still believe that Infomagic has it pretty well nailed down as a distinct possibility if we aren't exceedingly careful in what we do.

For now, I still hold at an 8.5 and I am growing ever more pessimistic as the time disappears into yesteryear.

Care to hazard a SWAG on the dreaded "Cyberterrorists" activity in reference to the computer code?

S.O.B.

-- sweetolebob (buffgun@hotmail.com), March 27, 1999.

All at Sea,

"Furthermore,the underlying production environment (........)will all change radically on the 1/1/2000 for every production system"

When you use a computer, the application program you are using (say Word Perfect for word processing) is controlled by another set of more basic, and usually invisible, programs called an operating system. More than likely you are on this forum using either Internet Explorer or Netscape as a Web Browser. These are application programs under the control of an operating system like Windows 95 or 98. This operating system does a lot of behind the scenes work to keep you happy like providing the date and time to application programs. It also controls how computer files are created, deleted and kept in a certain order. The point I was making was that these "invisible" services are vital to every computer no matter what the scale. When your electric company sends you a printed bill, that piece of paper is generated at the end of a fairly complicated process that involves sequentially running several (perhaps dozens) of application programs. Each of these programs knows when to start and what information files to use (and where they are) based on job control information given to the underlying operating system (OS). Someone like Cory Hamasaki is a systems programmer who installs and maintains the functions of the operating system. Perhaps 1 out of a hundred programmers are systems people. If the operating system fails, everything the computer "crashes", ie. NOTHING runs. Certain kinds of computers have unique operating systems that are particularly vulnerable to Y2K problems. This could be a critical factor post 99.

I was trying to make 2 points. First, the current remediation efforts are often followed by inadequate testing. They are being thrown back into "production" (i.e. actual business use) very quickly. Some of the pre-2000 errors are obvious and some aren't. In any case, as the date progresses past Rollover, a new path will be taken through ALL remediated code if it involves 'windowing'. This means 90+% of all remediation.

Second, the operating system services will also be in a 'new' environment and there will be some errors at that level. Therefore, since every system will suddenly be in a changed environment, some systems which had been running "remediated" code for months will come to a screeching halt as it hits rather virgin (inadequately tested) code. The common press make it sound like "gee, 99% remediated by July 99 so no sweat in January 00". Wrong - dead wrong-- as any experienced enterprise programmer should know. And I guarantee that you don't fix these problems in 3 days.

-- RD. ->H (drherr@erols.com), March 27, 1999.

RD:

The arguments you make seem rather fundamental. Do you intend to imply that the geeks doing remediation are unaware of them? I should think that the concept of testing in the environment in which programs are expect to run, would have occurred to most geeks already. What am I missing here?

-- Flint (flintc@mindspring.com), March 27, 1999.

Flint,

I was aiming for the non-software types. Thats probably 90% of this forum if you count the lurkers. I was commenting on the persistent media reports which imply that once code is remediated and running now, then there is nothing to worry about. This is often repeated by the uninformed as proof of "its all hype".

The arguments you make seem rather fundamental. Do you intend to imply that the geeks doing remediation are unaware of them? I should think that the concept of testing in the environment in which programs are expect to run, would have occurred to most geeks already. What am I missing here? -Flint

Of course the geeks know. But some simply don't care about adequate testing. And the PHMs want the code running NOW. So guess what, its put back into production after a very shallow dip in the post 2000. pool. If what I'm hearing from around the country is right, a lot of Anderson billing code for utilities is having gran mal seizures on a daily basis after "remediation". -- Flint (flintc@mindspring.com), March 27, 1999.

-- RD. ->H (drherr@erols.com), March 27, 1999.

RD:

Good points, and troubling. I'm well aware that proper testing is tedious, time consuming and easy to slight. I know that there is some pressure on now to show more progress more rapidly than careful testing would permit. I know that we tend to reduce the scope of our test plan to fit the time allocated for testing.

Still, even a "shallow dip in the post-2000 pool" will be sufficient to locate some (perhaps most) of the more howling blunders. And seizures happening now have a silver lining, in that we are finding and fixing them while everything still works pretty well. Putting remediated code back into production, even with inadequate pre- production testing, allows some time during which we can weed out a number of bugs introduced during remediation.

I agree that we'll have a big spike within a month or two of rollover. I don't know how sick systems will get before they're on the road to recovery. I know those who claim they're ready, at best *think* they're ready, and will face many unpleasant surprises from directions both expected and unsuspected. But I guess I have a little more faith in those doing the work than you do. Most geeks I know are neither lazy nor stupid, and don't want the rug pulled out from under them either.

-- Flint (flintc@mindspring.com), March 27, 1999.