Is it possible that "patches" are holding everything up?

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I do not know a lot about computers and would like anyone that does to comment on the possiblity that the systems that did not get fully "fixed" for Y2K are now running on a patch. Can this be done in a wide range of systems in differing industries- I.E. oil, electric, banking, telecommunications, ETC? Lastly, do these things called patches have a life span? Thanks...

-- Sam (timespn@uoo.com), January 26, 2000

Answers

As a programmer for 25+ years, I can assure you that patches are ALWAYS holding everything up. Particularly in old systems, you just keep patching until it all gets replaced somewhere down the line.

There is nothing magical about Y2k patches. The danger comes from the fact that never in history have so many new patches been introduced in such a short time. And Y2k work is NOT FUN, so patches have been placed by people who resented having to do it, who were being kept from something they considered more important. Often, the programmers were drafted from some other much more exciting project and told to learn some archaic language they thought was dead, just so they could patch the programs. Rotten career move.

Stuff breaks all the time, just like the pollies love to tell you. We don't know how many things will break from y2k problems, we don't know whether we fixed enough of the bad code, we don't know if we can fix what DOES break (the stuff we missed when we thought we were fixing it all) fast enough for the company to survive.

-- bw (home@puget.sound), January 26, 2000.


The problem is a software patch would require the same amount of time to make as actually upgrading the software. If you could have spent the time making a patch then you could have spent the time updating the actual code. Also, many Y2K fixes ARE software patches anyways.

-- Joe (TheRebel12@aol.com), January 26, 2000.

bw: I get the impression from your post that Y2K problems are like unseen gremlins buried deep in a program waiting to leap out and go BANG. Is this a correct assumption or visualization of the problem? Also, if a program has not been fully Y2K fixed would the bad code remain unknown with unknown affects?...or is it an easy matter to look at the program and know what more you need to fix and where the problems will occur.

MrsPeal

-- MrsPeal (...@...com), January 26, 2000.


MrsPeal - you might think of it like proofreading a description of a picture - the thousand words from the cliche. This description is intended to let someone visualize the picture itself.

You find lots of errors and fix them, and you hope you found all of them. But the ones you didn't find are there, "lurking" in the sense that they eluded you but will be apparent to some other reader. To that reader they seem obvious, but you missed them because you were in a hurry, or tired, or your mind wandered just as you were scanning that part of the text.

Ok, you have this description of a picture, but it's not the picture itself. Well, the machine can't "run" the description, it has to have the picture, so we run a special kind of program (a "compiler") that turns the description into the picture, and the machine runs that.

Joe had the picture in mind, not the description. There is a second kind of patch where you change tiny chunks of the compiled program, like retouching the picture. It's much more complex than changing the code. I don't know of any Y2k patches done that way, other than some IBM mainframe software fixes (which are often released as that kind of patch).

Ok, we miss some stuff, and other people who proofread our stuff miss some, so in that sense there are hidden flaws in the picture. Some will be trivial, some might never be used at all. Programs have thousands of sentences, some intended for extremely rare situations (like how you renew a driver license for a left-handed dentist with a wooden leg), and might never happen. Well, there aren't any specifically for that dentist, but that's the idea - very unusual cases.

What we do is thorough tests of the heavily used sentences, and moderate testing of the less-used ones, and sometimes no testing of the really rare stuff. That's not good practice, but it happens. Some companies, who didn't start Y2k work until 1998, did very light testing of even the critical stuff. So probably some of that will break, some if it will be catastrophic to that company. It'll seem like BANG to them, when the computer center manager calls the CEO and says they can't do payroll or pay bills or order any goods for the next two months.

-- bw (home@puget.sound), January 26, 2000.


bw,

You have it pretty well nailed. At least I'd say so from my something around 20 years of experience in this business. I liked your picture analogy, btw.

Joe, your statement is true if two conditions hold absolutely true. First, that the application's upgrade will meet all the requirements without modification (which is another way of saying that it will not fail to meet even more business requirements that the version in production fails to meet).

Second, that the darn thing was not developed in-house. If it was, or was significantly patched in-house before the contemplated upgrade, then things can get sticky. Why do people customize? Either they change the business to accommodate the software's capabilities and limitations, or they (do or pay to have done) some of the opposite.

Sam, what I am most wary of right now is not those systems and applications I can see and get at -- I am definitely wary of those imbedded systems (from controllers and sensors on up in complexity) and their interactions with larger process control systems.

The address http://nckodokan.com/charts/crude.html presents graphics which, if based solidly on fact, indicate refinery mishaps jumped in 1999. Why? My guess is that they were working at installing and debugging upgrades to various refinery process control systems.

Production lines producing widgets (whatever the heck widgets are) may not explode. They may just stop. They may not stop but produce widgets with too many QC problems to ship. Is this happening? My guess is yes.

Will we hear (from the regular media) about the non-explosive failures? Not likely. No business is going to risk lawsuits and loss of customer and investor confidence until the situation is truly horrible. What defines 'horrible'? Well, try yesterday's post regarding traffic fines in Richmond, Va.: http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=002POJ

MrsPeal, some will go bang, some will do just a wee little chirp. Isn't the bangs that worry me -- they're kindof hard to miss -- it's the little ones causing gradual degredation to data such as accounting records. They can be nightmares to find.

And, MrsPeal, I do hope you are referring to the original Mrs Peal (Dianna Rigg), and not the latest copy! Yeah, that dates me -- so what!

-- Redeye in Ohio (cannot@work.com), January 26, 2000.



Sam:

What do you mean by a patch? Some consider the windowing technique to be a "patch." Depending on the method used in windowing, these "patches" could last for 30-50 years.

Joe:

I disagree that a software patch would require the same amount of time to make as actually upgrading the actual code. Let's consider the "patch" offered to IMS shops. Currently, the IMS database shows the date internally using 7 characters. If I remember correctly, it's in a signed packed format, so May 01, 1999 is stored as 0990501C, with C being the designation for a positive integer. I've seen several shops use the high-order half-byte to reflect century. 0 will indicate 19. 1 will indicate 20, 2 will indicate 21, etc. This "patch" will last for 9 centuries and accommodate arithmetic on dates, while a complete upgrade would require every entry in the database to be expanded and every program using that database to be extensively changed.

bw: We're getting a little closer in philosophy. Who woulda thunk it?

-- Anita (notgiving@anymore.com), January 26, 2000.


Anita's right, "patch" is a pretty loose word. "Windowing" is a patch using the first definition I gave - you change the source code so the logic is expressed a little differently. "Expansion" is a better solution, but can be very expensive. Anything you do to a system, done just to keep it running, not to make it run better or to give more functions, you could call a "patch". It's kind of in the eye of the patcher.

When fixing Y2k problems, you are usually balancing (1) a high cost of doing the fix and a low cost for continuing maintenance against (2) a low cost of doing the fix and a high cost for maintenance. Windowing CAN be fairly cheap, but you have to remember to fix it again near the end of the windowing timespan. Expansion costs a lot and lasts until the year 10,000. The decision can be quite complex, with many ramifications running all through the company. If you do either one wrong, it can be more expensive than you can possibly believe.

-- bw (home@puget.sound), January 26, 2000.


Moderation questions? read the FAQ