And the reason you'll find most programmers aren't too worried about Y2K is that they know that code trace compilers find these sorts of bugs before the source ever gets fully compiled and implemented. A bad date or data format instruction won't compile correctly in most modern debuggers and will be found by the tracer and flagged. So in 99% of the cases where the source code is available there shouldn't really be any problems.

I'm aware that source is missing, however, in many installations. But fortunately it seems that in this instance most organizations are simply replacing systems and not attempting to recode. It's rare given the high profile Y2K has achieved over the last couple years that an IT manager would play with that kind of fire when a reinstall of a compliant system is generally just a checkbook and a week or two of install time away. It's generally a medium to large financial hit, but one that will be taken this year, and whose benefits, besides Y2K compliance, will be felt in 2000 and beyond, and one most organizations are more than happy to take if it ensures continuity and shareholder peace-of-mind and stock valuation stability.

-- Paul Annacone (paul.annac@NOSPAM.ps1.nasa.gov), November 13, 1999

Answers

Hhhmmm, you're obviously not the NASA employee who went to the cave. Thanks for the good news. It sounds like all the other good news. Makes us prep harder. Worth a few seconds of make-belief relief, tho. If you are correct we'll be very happy campers.

-- Ashton & Leska in Cascadia (allaha@earthlink.net), November 13, 1999.

Paul, I am considered a software expert and that was the stupidest shit I've ever read. Its obvious that you've studied the problem for all of 3 minutes.

With people like you working at NASA, the Metric/English error that just demolished the centerpiece of their Mars explorations becomes a little more understandable.

-- a (a@a.a), November 13, 1999.

really? surveys suggest that programmers comprise between 10 - 15% of all those who have been purchasing long-term storable foods (ie rice, beans, etc). this was also repeated by the president of lumen foods in an interview several months ago.

i agree that the majority of programmers are not worried, but enough 'get it' to put them in the largest group - by profession - of people who are concerned enough to be preparing.

-- lou (lanny1@ix.netcom.com), November 13, 1999.

Ok, well if you're "considered a software expert", (whatever the hell THAT means), then your assurance is all i need, mr "A"...

-- Joe (Joe@Joesplace.org), November 13, 1999.

Oh My! Another sincere polly...A late one to (in relation to the the good news, every thing is fine) crowd. Well...not such a large crowd. I can't wait untill he swaps bonifides with Cory Hamasaki, and tells him that there is nothing to worry about.

Don't you just love it when they send in the really light weights in the last quarter.

Young one, when it is all said and done...It will be the embeded systems which will have done for you. And that! Dear sir you can take to the bank (if you can find one open next spring, that is).

~~~~~~~~~~~~~~~~~~~~~~Shakey~~~~~~~~~~~~~~~~~~

-- Shakey (in_a_bunker@forty.feet), November 13, 1999.

Paul,

You're overlooking a few things. First, not all systems have been designated as "mission-critical" and thus could have problems because no effort has been made to remediate them.

Secondly, in a recent survey of large corporations, 44% of those responding said they do not expect all of their critical systems to be compliant by year's end:

http://www.usa.capgemini.com/news/pr99.asp?id=109

[snip]

The survey, sponsored by Cap Gemini America, Inc., a leading information technology and management consulting company, finds a majority of large corporations  56 percent -- now expect 100 percent of their critical systems to be compliant by year's end, up from 48 percent in August.

[snip]

Lastly, some foreign countries and some small businesses in the U.S. are heavily relying on "Fix On Failure"--not taking any action now and waiting to see if there are problems in January before doing anything. Global supply chains are at risk next year.

-- Linkmeister (link@librarian.edu), November 13, 1999.

Wow, Paul

Thanks. You may want to talk to those dolts over on Wall St in Manhattan. You know the guys that spent 6 or 7 billion dollars to fix a problem that doesn't exist. Damn.

To bad they didn't speak with you first.

How long have you been working with big iron mainframes Paul?

I happen to know couple of real critical pipeline systems that failed recently when the owners tried to implement thier "compilations" as it were. Maybe you could help them? Maybe their compiler isn't quite as large or handy as yours seems to be.

Well, best of luck to you in the New Year. See ya in the soup lines.

-- Gordon (g_gecko_69@hotmail.com), November 13, 1999.

Duh! This guy is a major simpleton. Another one that Darwin will remove from the gene pool.

-- anonymous (anonymous@anonymous.com), November 13, 1999.

"thier" "compilations"??? Ed Yourdon, save us from these morons!

-- null (sparks@supernet.commmmmmmm), November 13, 1999.

Paul, I must respectfully disagree. The FORMAT isn't necessarily the problem. I know that (in a COBOL context) "YEAR PIC 9(2)" (two digits, numeric, for those who don't speak ancient languages) is perfectly valid. If I try to move "AA" in there, the compiler is probably going to hiccup all over me -- but if I move two numbers (or even one number, usually), the program will say, "Fine, boss" and do just what I told it to do. The problem is that two digits for a year just aren't going to cut it.

Let's assume that "YEAR" currently sits at "99" (which it does). After rollover, I'll add "1" to that. Assuming that the program doesn't blow up (since you've just spilled over to three digits), it'll most likely read "00" after truncation of the high-order digit (I make myself hot when I speak techie-talk). Anyway, fine. Now compare that new year (00) to THIS year (99). Is it greater-than, or less-than? You and I know that the "00" means "2000", so it's obviously GREATER than. No problem.

The computer doesn't know that, though, and no compiler on earth (that I'm aware of) is going to make such an assumption, either. It's going to compare as it was programmed to do -- "00" is LESS than "99". Oops.

Now, "code tracing" compilers may well point out such an error in logic (I'm assuming there IS such a thing) -- but consider how many places are still functioning on back-level compilers. Reasoning? "If it ain't broke, don't fix it." No systems programmer with any sense is going to put in a ".0" release (as in "7.0" release or whatever) of a compiler -- probably still too many bugs.

Besides, even if the latest and greatest version of a compiler is installed and functional, how many installations are willing to recompile EVERY program in their inventory? I'll answer this one: Damned few. So the old versions of the software are still sitting out there, and will continue to sit until there's a reason for someone to modify them. And, like you said, that's assuming the source code still exists.

I'm sorry to be so long-winded about this, but I feel that just because the tools MAY be out there to solve some of this, not everyone is going to have the time or the inclination to USE those tools. The whole deal these days is "profit, profit, faster, faster" and I'm just not willing to bet the farm on it.

-- I'm Here, I'm There (I'm Everywhere@so.beware), November 13, 1999.

"It's rare given the high profile Y2K has achieved over the last couple years that an IT manager would play with that kind of fire when a reinstall of a compliant system is generally just a checkbook and a week or two of install time away."

Ya. I know it.

-- Clyde (clydeblalock@hotmail.com), November 13, 1999.

If I read the report correctly, NASA is sending the shuttle up to maintain the Hubble telescope before the first of the year.

Why? They don't want to try sending the shuttle after 1/1/00 because they aren't sure it's compliant. (Wish I had a URL, but the article wasn't of great interest to me.)

-- Dean -- from (almost) Duh Moines (dtmiller@midiowa.net), November 13, 1999.

Paul is obviously a VB, Access or Java "programmer" (if you can call that drag-n-drop crap "programming"). Dude, just go back to your cube, and leave us real programmers alone.

'Kay?

48 days.

-- Dennis (djolson@cherco.net), November 13, 1999.

Correct me if I'm wrong, but I got the impression that a lot of the difficulty involved in fixing code instructions for Y2K has to do with the logic. That doesn't seem like something that would be resolved by using a compiler, and probably has to be specifically written for each particular process.

-- Hawk (flyin@high.again), November 13, 1999.

1. Yes, it's about the stupidest thing I've ever heard.

2. Don't knock VB, all your statement demonstrates is *your* ignorance of the language.

3. Paul is *definitely* not using VB!

-- Ron Schwarz (rs@clubvb.com.delete.this), November 13, 1999.

Paul,

I assume that you also think a program will work if it compiles? Let's get real, huh?

-b

-- Bruce W. Roeser (broeser@ccgnv.net), November 13, 1999.

http://www.space.com/news/spaceshuttle/shuttle_y2k_991101.html

[snip]

NASA Wary of Y2K

By Todd Halvorson

Cape Canaveral Bureau Chief

Nov 01 1999 17:02:23 ET

CAPE CANAVERAL - NASA would fly the upcoming Hubble Space Telescope mission over the Christmas holiday if need be, but under no circumstances will Space Shuttle Discovery be in orbit for the onset of the year 2000. That was the word Monday from NASA shuttle program director Ron Dittemore.

In an exclusive interview with space.com, Dittemore said NASA is not taking any chances when it comes to the Y2K computer bug and the potentially dangerous effect it might have on an orbiting spaceship and an astronaut crew. After all, NASA's $2 billion shuttles rely heavily on flight computers and software - not to mention computers in the agency's Mission Control Center in Houston - to safely carry out piloted space voyages.

"We've gone to great lengths to certify ourselves so we can say with certainty that we can operate in a Y2K environment," Dittemore said. "But good common sense and prudent judgment says if you don't have to do it, don't do it."

Discovery and seven astronauts are scheduled to blast off from Kennedy Space Center December 2 on a high-profile mission to fix Hubble's troubled pointing control system, which enables the telescope to lock on to stars, planets, galaxies and other celestial objects. Extensive inspections, repairs, and testing of Discovery's electrical wiring system, however, are making it increasingly difficult for NASA to meet the target launch date.

Dittemore said the agency still has a shot at making the December 2 target date. A slip of three or four days, however, is a real possibility. "I want to be satisfied that we've got all the work done," he said. "If we can make December 2 and do it comfortably, then we'll do that. But if we want to take a couple of extra days, then we'll do that."

Discovery is still in its hangar at KSC while senior shuttle managers review the results of electrical systems tests and other more routine launch processing work. A planned move to KSC's 52-story Vehicle Assembly Building had been slated for early this week, but is on hold until the review work can be finished.

NASA's self-imposed deadline for launching the Hubble repair mission in 1999 is December 14, Dittemore said. Launching December 14 would enable the crew to complete a full 10-day mission and have two extra days to fly in orbit should bad weather on Earth prevent a safe landing attempt. It also would enable ground teams to secure the ship in its KSC hangar and power down all computer systems by December 28 or 29, thus avoiding any potential trouble from the Y2K bug.

The latter scenario, if it came to pass, would call for the crew to be in space on Christmas Day -- something NASA historically has tried to avoid. The agency typically grants its Mission Control and KSC ground teams the holiday off.

[snip]

-- Linkmeister (link@librarian.edu), November 13, 1999.

Paul --

Sorry to bust your bubble guy, but on a couple of points I suspect that you are out in left field somewhere. (Or possibly the parking lot the other side of the fence.)

First specify which languages you are using. C? C++? And how 'bout all those assemblers out there that could care less. (Contrary to popular opinion, anytime you have anything resembling a timing critical module, it has a tendency to get written in assembler, because you can control it better.) I have used 5 or 6 different C compilers, and a couple of C++ compilers, and they just don't care, as long as the syntax is correct. Are you trying to say that the operation 00 - 99 is no longer valid?

Even were the above true, the statement that the fix is a checkbook and a week or two of installation away is absurd. How about all of the testing? Virtually every recompile done is at risk of introducing new errors. For this reason, you have to go through regression testing again. And this is the best case, where a regression suite exists. This is not always, in fact, not often, the case. Then you have to regenerate all of the testing.

Add to this the fact that managers are notoriously loath to appropriate resources to projects that don't buy them anything new, just what they already have. If this weren't true, then they would be in a lot better shape with respect to Y2K remediation today than they are.

-- just another (another@engineer.com), November 13, 1999.

Paul,

I've been programming since the early 80's and I'll agree with the others here who say this is just about the stupidest thing I've ever heard.

How many languages have you worked with?? How many platforms? How many compilers?? Not alot I'll bet. You sound like some college kid parroting what his DGI professor said in class one day...

-TECH32-

-- TECH32 (TECH32@NOMAIL.COM), November 13, 1999.

Pure bullshit... 17 years systems/software experience. You obviously never wrote a line of code in your life.

-- (...@.......), November 13, 1999.

Thanks for the laughs, Paul. I enjoyed your post immensely :-)

-- Tim (pixmo@pixelquest.com), November 13, 1999.

-- a (a@a.a),Your answer does nothing to disprove what Paul wrote, it just showed that you are rude to those who dissagree with you, good work on getting newbies to disreguard this board.

i agree that the majority of programmers are not worried, but enough 'get it' to put them in the largest group - by profession - of people who are concerned enough to be preparing.

-- lou (lanny1@ix.netcom.com), November 13, 1999.

lou,

It is IT's who are concerned and preparing, not programmers. Programmers know how the software works, IT's are just glorified data processoers with little real knowledge of how the software works. It is their of understanding that causes them to be afraid.

~~~~~~~~~~~~~~~~~~~~~~Shakey~~~~~~~~~~~~~~~~~~ Cory should really be considered an expert right??? Him and his Jo-Anne effect that didn't happen and derogitory words instead of facts is all you need as proof shows that you are not capable of distinguishing fact from opinion. But then you do not choose to use fact and logic, you have your own opinion and only listen to those opinions that agree with your own.

Linkmeister,

You snipped off the rest of the story, titch titch..shame on you!

Anticipated levels of Year 2000 compliance

The survey, sponsored by Cap Gemini America, Inc., a leading information technology and management consulting company, finds a majority of large corporations  56 percent -- now expect 100 percent of their critical systems to be compliant by year's end, up from 48 percent in August. More than a third (38 percent) expect that 76 percent to 99 percent of their systems will be compliant. The remaining six percent expect to complete between one half and three-quarters of their systems by the end of the year.

One of the longest-running corporate polls to systematically monitor Year 2000 preparedness, the survey includes responses from information technology directors and managers of 156 major U.S. corporations across all major industrial sectors. It is carried out by Rubin Systems, Inc. for Cap Gemini America.

Eighty-two percent of the respondents do not expect non-compliant systems to pose a "significant business risk." Only 12 percent report that non-compliance does pose such a risk, and six percent say they are not sure of the potential impact.

Anticipated levels of Year 2000 compliance The survey, sponsored by Cap Gemini America, Inc., a leading information technology and management consulting company, finds a majority of large corporations  56 percent -- now expect 100 percent of their critical systems to be compliant by year's end, up from 48 percent in August. More than a third (38 percent) expect that 76 percent to 99 percent of their systems will be compliant. The remaining six percent expect to complete between one half and three-quarters of their systems by the end of the year.

Gordon, Here you go again ~~~ I happen to know couple of real critical pipeline systems that failed recently when the owners tried to implement thier "compilations" as it were.

Just what do you mean by "as it were"? Do you mean it had little or nothing to do with what Paul said but you want to make it look like it did?

Can you name the names of those pipeline companies? How come no one else has heard of this?

anonymous, Another person who is clueless to what was being said due to lack of knowledge and ability to understand, so we just get a case of degrade the person who wrote the post, very convincing....

"thier" "compilations"??? Ed Yourdon, save us from these morons!

Frankenstein's monster eh?

Then we finally get some posts that are relevent. -- null (sparks@supernet.commmmmmmm), November 13, 1999.

-- Cherri (sams@brigadoon.com), November 13, 1999.

Paul -

So are you a PS-1 (Payload Specialist 1), as your "spam-free" address might lead one to think? Ever done any truly serious enterprise systems deployments, or even corporate division level, say, 1000 employees/users? If not, please just go away. Go help those folks who couldn't even execute a decent work review and thus allowed that moronic units conversion screwup to lose the Mars probe.

Sorry for the tone, all. I've recently been cranking 12+ hours a day, 7 days a week, on a Y2K conversion/install (complete with truly irate customers and stressed-out executives), and comments like Mr. Annacone's really rub me the wrong way at present. "...just a checkbook and a week or two of install time away", indeed. You, sir, have no clue whatsoever what it takes to replace a mission-critical business system. I got yer checkbook and 2 weeks right here, babe.

We are at D minus 49, and counting...

-- Mac (sneak@lurk.hid), November 13, 1999.

Uh, Paul, this runs counter to empirical observation. Other than that it sounds great. Now, if you were to claim that compilers *introduce* date bugs, many would be glad to listen.

-- Flint (flintc@mindspring.com), November 13, 1999.

Paul, you seem to be somewhat confused as to compile-time versus run-time errors, and just how they are handled. If a programmer chooses to represent a year with two digits, we may now recognize that it was a bad choice, but it was in no sense a "bad date or bad format" that would cause a compiler to flag it as an error.

In point of fact, depending on what else is done with that date, it may or may not result in the computer flagging it as a run-time error when an operation is attempted with it that involves the Year 2000. The result may be that the results are simply wrong, but without any explicit errors as flagged by the computer. In which case, it will only be humans that realize that errors have occurred when they have to deal with incorrect amounts on checks, missed deliveries, etc., etc.

48 days.

Y2K CANNOT BE FIXED!

-- Jack (jsprat@eld.~net), November 13, 1999.

I'll take that bait... and the correct response is: BWAHAHAHAHAHAHA.

-- Colin MacDonald (roborogerborg@yahoo.com), November 14, 1999.

Anyone who thinks that one can do any serious work in VB and/or Access with just drag and drop hasn't done more than the "Hello World" exercises in "Becoming a VB/Access Master in 21 Days". They take heavy coding.

That being said, I'm not a tremdous fan of VB and Access. Which brings up a question -- a poll: IF there is still a functioning computer world post 2000-01-01, what would YOU use for writing programs for your PERSONAL use? (Not necessarily what is in greates demand by IS departments or whatever is the trendy "language du jour" -- but something that lends itself to rapid development of non-trivial programs with file handling and chart and report generation.)

-- A (A@AisA.com), November 15, 1999.

I'ld like to see the "compiler" that sorts 00 after 99. I'ld like to see one that doesn't do incorrect date math on non-compliaant dates.

Sheesh. I just don't know what else to say to this post.

Modern? What about all that 20 and 30 year old COBOL and Assembly language out there? There's a whole bunch of it. How many Fortune 1000 companies don't have at least one mainframe? Oh sure, tools have gotten better over the years, but they still can't fix "logic" errors, and that is what Y2K is all about.

I did a survey here a while ago. We have at least 875 man-years of programming experience. +90% are "doomers." What does that tell you?

My first love is Assembly language. S/3x0 mainframe, x86 PC, old 6502 stuff like the original Apple. Oh yea, I do COBOL and BASIC and C, and I don't know how many others. Almost 32 years.

All I can say to this post is...

Sheesh!

Tick... Tock... <:00=

-- Sysman (y2kboard@yahoo.com), November 15, 1999.

Paul,

I think you know your statement is erroneous, If you know what a compiler is you may have some experience. Are you just trolling to see the basic nature of the audience here or what? In any event I will add my .02 . There are date errors in the code. I like many others on this forum have a background and know that incorrect coding for 2 digit years without appropriate windowing algorithms produce incorrect results as well as run time errors. The evidence is there in the increasing failure rate and dollars spent in remediation. If there wasn't a problem why would the big 3 automotive companies spend a collective 1.4 billion dollars? Why would the U.S. federal government spend 4 billion? Why would the collective Public and Private sectors spend 200 billion (latest per Gartner)? There are a lot of programmers and analysts and systems guys on this forum who provide good information. I can only believe by the naivety of your statement that you either lack a deep background, or you are deliberately leading the uninformed in a direction contrary to the facts, i.e. you are a disinformant.

-- Slammer (BillSlammer@Yahoo.Com), November 15, 1999.

If you take your conclusion - of your original message - seriously, print this thread (to which I'v noticed, you have no responded to the comments above) and give it to your supervisor.

Please add your comments to the reasoned criticisms above, specidfcally rebuting each point.

Add his reply, with a useable email address to him, below your answer - if you're still employed at your present job. He, after all, is responsible for testing and releasing your product - correctly operating programs in the real world.

If, on the other hand, you are at a *.gov or *.mil site, then I understand why we are in the troubles we are.......

-- Robert A. Cook, PE (Marietta, GA) (cook.r@csaatl.com), November 15, 1999.

Paul,

BWAHAHAHAHAHAHAHAHA

-- (cannot-say@this.time), November 15, 1999.