The "Code" is NOT broken!

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

NO! THE "CODE" IS NOT "BROKEN" AND WHAT'S MORE, IT NEVER WAS!
Considering the credentials and eons of experience claimed by the various participants here, I am truly appalled.
That the question should be initiated and indeed insisted upon as a subject for discussion by two individuals who have displayed some of the least understanding of the mechanics of instructing a computer how to do what you wish it to do and the flimsiest claim to logical thought (Mr. Decker and Stephen Poole, respectively), is understandable.
That NONE of the technical folks (and Sysman, I'm particularly disappointed in you) have raised a red flag and hollered, "WHOA!", is not.
To begin with, "code", is a perfectly acceptable term to describe the contents of a computer program. A program is nothing more than a list of instructions to the computer that tell it what do and in what order to do it. "LA" is "code" (in Basic Assembler for 360/370/390) for the Load Address instruction. "Print" is "code" in several high-level languages for a group of instructions that tell the computer how to take certain data and display it on a hardware device (usually called a printer). All "code" (and there are many "codes") ultimately is a kind of shorthand for binary numbers. ALL information inside a computer is ones and zeros, or binary numbers. Whatever representation that is used to make it easier for humans to deal with this situation is properly termed, "code".
Now the particular sequences of code that relate to a specific task (such as the "print" above) are usually called routines. Thus there are print routines, sort routines, disk read routines, tape read routines, etc. The Y2K problem arises because of the way in which "date routines" are constructed. The reasons why are not relevant, but the fact that nearly all date routines are constructed, designed, written, made, or however you choose to say it, to operate between the years 1900 and 1999 is the problem. The basic assumption that is almost universal is that this code is executing in the 20th century. (I realize that the 20th century will not be truly over until the end of the year 2000, but let's not complicate this too much more) When that assumption is not correct, the code will not yield the correct answer. It's that simple and you could not ask for a better example of an assumption, "making an ass out of you and out of me".
"Broken" means, "does not work properly, or at all". This is NOT an accurate description of the "code", AT THIS TIME. It will not BE an accurate description until such time as the code attempts to process a date which is outside of the range it was designed to deal with. In most cases, this will occur at midnight on December 31, 1999. Code which looks forward and experiences the JoAnn Effect is an exception to the 1900-1999 date range.
The term, "fixing the code" only adds to the confusion since the word "fix" has come to have a much broader connotation in our society than "broken". We say one who undergoes biological sterilization gets "fixed", we say that a sporting event which experiences a pre-arranged outcome is "fixed", and we say that a traffic citation which magically disappears does so because someone "fixed" it. All things considered, "fixing the code" is a quite apt term, as long as we don't fall into the trap of assuming that it infers that the code is broken. In the Y2K instance, it means that the code will be broken, if we don't "fix" it in time.
The "fix", then, is not a repair. The code is functioning perfectly and will continue to do so until the precise instant that it attempts to calculate date arithmetic outside its "window". The "fix" is a re-design of the date routine, and they are far from all being the same. They are as many and varied as the number and "flavors" of programmers who have authored them since the early 1950s. To complicate things, the only calculations more common than date arithmetic in computers are the simple "2+2=4" (well, actually, 0010+0010=0100) common arithmetic routines. We cannot possibly hope to find and redesign all date routines. We can only hope to deal with enough of them to keep things afloat while we find the rest.
If we sink, it will not matter, but if we manage to keep our heads above water, it will take years and years to ferret out all the date code in the world's computer programs.
These particulars of the Y2K problem's "nitty-gritty" are not in question. What is in question is what the results of this state of affairs will be.

-- Hardliner (searcher@internet.com), May 28, 1999

Answers

Hardliner --- You can't blame this one (how it pains me to say so) on Poole or Decker's tortured understanding of software but mainly on me. It is an inflammatory, though I feel, useful shorthand for describing what you far more accurately state in your opening post.
In my defense, when challenged, I have said it is "broken" only ANTICIPATORILY, though with great certainty (ie, much will fail to execute properly at rollover and beyond, without doubt, and despite the intense efforts to remediate).
With respect to the details:
Of course, "code" is appropriate. I think only one person (Cherri?) was so clueless as to challenge that. Great explanation, though.
You're right that "fixing" is also mainly a misnomer at this time (pre-rollover). Fundamentally, we are identifying candidate date routines and analyzing their executable behavior to determine whether
1. They are date routines at all (given the weirdness of 30 years of computational archaeology, that is not a given). Automated tools are useful but far from a panacea.
2. They matter enough to fix (some date routines have been orphaned by later code and don't "do anything" anymore; others will "break" after rollover but their effects are judged to be trivial relative to the OTHER date work that must be done in step 3 and beyond).
3a. The routine and/or application in which they are embedded should be replaced, either because it is long-past time to do so or because it is too nasty to remediate them. This raises a host of other questions I won't go into here.
3b. The routine is critical and must be remediated so that the application won't fail or give spurious results past rollover.
Actually, the above is merely assessment (HA!), but perhaps useful for purposes of this thread. Remediation, testing (unit, system, production et al) and repair of show-stoppers in subsequent use are all "just a small matter of programming."
As someone not currently in the Y2K trenches (I get to run one of those Doonesbury-style Internet ecommerce businesses where the investors tell the programmers NOT to finish or earn any revenue because it makes raising huge sums of money difficult, I kid you not), I shudder even when thinking through the crude steps above.
Flashbacks.
The only other caveat to the above is that, as more and more 1999 applications begin to rely on post-rollover calculations, we will begin seeing "rollover style" failures (JoAnne but not only that).
I agree whole-hearedly that it will be five to ten years before Y2K is over programmatically. How serious that is remains to be proven.
If forced (I still like the consciousness-focusing aspect of the statement, "the code is broken"), I will pore over COBOL code tonight and repeat over and over, "WILL be broken", "WILL be broken," "WILL be ...."

-- BigDog (BigDog@duffer.com), May 28, 1999.

Actually, I've never had a problem with the 'broken code' phrase. I think we all understand (to different degrees, to be sure) that any code that deals with dates outside the design window will produce what is called (in my little corner of the computer world) 'undefined' results. Which means, we don't have any idea what it will do. The results might be harmless, but the cannot be good (even if it isn't very bad).
The main problem with the 'code is broken' slogan is that it doesn't allow for differentiation. We need to change this to 'less broken all the time' or 'located where breaks are important or not important' or 'is only broken where dates are mishandled.'
Nobody argues that progress isn't being made. Few (and nobody knowledgeable) claims that ALL date bugs will be critical. Most even understand that there is a vast difference between 100% compliant and 100% belly up. Some understand that even minimal testing can find most of the worst bugs. And a few even understand that fix-on-failure isn't impossible, and may even be sufficient depending on how easy fix and recovery turn out to be.

-- Flint (flintc@mindspring.com), May 28, 1999.

Ahh, come on now Hardliner, we are talking about Y2K here. OK, I'll give you a half point because the code is not NOW boken, well, most of it anyway. <:)=

-- Sysman (y2kboard@yahoo.com), May 28, 1999.

Hardliner,
If the axle to a persons car were cracked they would say "it's broken" and has to be "fixed" even though it might not physically fall apart until some later time. Would _you_ say that it's not "broken"?
The fact is that a whole lot of code that was expected to handle dates properly (including dates in the future) will not. That sir, is "broken" code.
-TECH32-

-- TECH32 (TECH32@NOMAIL.COM), May 28, 1999.

As a long time DP professional (1/3 century, including programming and EDP Auditing) I must disagree with your implication that you must wait until the actual glitch to occur in production before you declare the code "broken". A program (or system) is designed to work over an intended period of time...and if it cannot work for the duration, it is broken. Thus my "one shot" program that won't work next year is not broken. My ongoing payroll program that won't work come January 1 is definitely broken.

-- Mad Monk (madmonk@hawaiian.net), May 28, 1999.

BigDog,
I didn't say that Mr. Decker and Stephen Poole were responsible for the phrase, only that they were the individuals who initiated and insisted on discussing the question.
Flint,
No one with an understanding of the mechanics of the problem beyond a certain level could take issue with anything you said, but that's the problem that I see. I suspect that a majority of the participants on this forum (including the lurkers) haven't got that level of understanding. I am simply attempting to state things in such a way that those without that level of knowledge will be able to understand.
Sysman,
I picked on you for two reasons: I'm sure that you understand, to the 'bit' level, what it's all about and I know that you could have easily explained it in terms that a non-computer person could relate to.
-TECH32-,
Your example and question go to the heart of my argument.
In the case of the cracked axle, it may or may not fall apart at some future time (depending on how much it might be stressed), but once it is cracked, it is not capable of performing 100% of its designed function. Once it is cracked, it is most assuredly broken.
In the case of current date routines however, if they were designed to operate on any date/time between 1900 and 1999, they are currently capable of performing everything that they were designed to do. Such routines are not currently broken, and technically, will not even be broken after the rollover, (since they were never designed to handle dates after that point in time) anymore than we would consider a 1/2 ton pickup "broken" because it could not haul 30 tons of cargo.
Flint,
No one with an understanding of the mechanics of the problem beyond a certain level could take issue with anything you said, but that's the problem that I see. I suspect that a majority of the participants on this forum (including the lurkers) haven't got that level of understanding. I am simply attempting to state things in such a way that those without that level of knowledge will be able to understand.
Sysman,
I picked on you for two reasons: I'm sure that you understand, to the 'bit' level, what it's all about and I know that you could have easily explained it in terms that a non-computer person could relate to.
-TECH32-,
Your example and question go to the heart of my argument.
In the case of the cracked axle, it may or may not fall apart at some future time (depending on how much it might be stressed), but once it is cracked, it is not capable of performing 100% of its designed function. Once it is cracked, it is most assuredly broken.
In the case of current date routines however, if they were designed to operate on any date/time between 1900 and 1999, they are currently capable of performing everything that they were designed to do. Such routines are not currently broken, and technically, will not even be broken after the rollover, (since they were never designed to handle dates after that point in time) anymore than we would consider a 1/2 ton pickup "broken" because it could not haul 30 tons of cargo.
Mad Monk,
It sounds to me like we are in violent agreement.
What you said, "A program (or system) is designed to work over an intended period of time...and if it cannot work for the duration, it is broken.", is not always true. Computers do what we tell them to do, not necessarily what we want them to do.
It may have been the intention of the author of your payroll program that it function forever, but if he coded it to assume the 20th century, he "told" it something different than what he wanted to. Thus, it was designed (albeit inadvertently) to operate only in the 20th century, and as long as it does what it was "told" to do, it cannot, by definition be "broken".
I made no implications--indeed, declarations of humans are irrelevent as to the functioning of a fragment of code. Either it does or it doesn't. I agree wholeheardedly however, that waiting until something fails to take action when you know it will is foolhardy.

-- Hardliner (searcher@internet.com), May 28, 1999.

I suspect that the above repetition is why some refer to it as "Microsuck". . .

-- Hardliner (searcher@internet.com), May 28, 1999.

Good grief!
Our natural languages are more complex than our computer languages.
"The code is broken" is slang for a concept.
"Y2K" is slang for a concept.

-- No Spam Please (No_Spam_Please@anon_ymous.com), May 28, 1999.

Hardliner--
By your definition, no code could ever be broken, since it was written by programmers, and therefore must do what they wanted. Illogical. The question is what the system designers intended...if the intent was for it to work into the year 2000 and beyond...and it cannot work properly, it is broken and requires repair or replacement.

-- Mad Monk (madmonk@hawaiian.net), May 28, 1999.

Yeah, right, arguing that "the code is broken" is a stupid statement means that we think that the code is not broken. Gimme a break. The question is not whether "the code" is broken. The question is whether we're all gonna let a bunch of machines decide how we live. C'mon, do you really believe that we have no control over the machines?

-- Buddy (buddydc@go.com), May 28, 1999.

aargh!!! By your definition nitroglycerin isn't dangerous unless it explodes. Or maybe it isn't an explosive unless it explodes. This thread just confuses newbies....

-- RD. ->H (drherr@erols.com), May 28, 1999.

NSP,
Exactly! While it is fairly easy to explain what "Y2K" means, the explanation of, "The code is broken" is not so simple to relate to one who has not spent a fair amount of time in the computer business.
Mad Monk,
I suggest that you read what I wrote again. "Broken" code is most definitely a possibility. If a programmer writes a routine to average the balances of all accounts in a bank, and he does not write it so that he gets the correct answer, that code is "broken".
In the case of most date arithmetic, it is unquestionable that the programmer knew (or should have known) that the code would not function correctly after 1999.
The crux of the matter is that the code will do what the programmer tells it to do, but may not do what he intends it to do. It just depends on whether or not he told it to do what he wanted it to do.
If the code is correctly designed as intended (as most date routines are), by definition they cannot be broken.
"Repair", by definition, is what is required when something is broken. Replacement will suffice whether something is broken or simply obsolete, as most date arithmetic code is.
Buddy,
I'm not quite sure how to respond to that. I do not think that the code is not broken, I know it is not broken. It is functioning perfectly, and is capable of doing everything it was designed to do. It is doing exactly what it was told to do and moreover, it is doing exactly what the decision makers wanted it to do. That will also be true after the rollover.
The problem is that the decision makers have changed their minds as to what they want the code to do. They now want it to correctly process dates after 1999.
I agree with you that the question should not be, "Is the code broken?", but I disagree that it should be, ". . .whether we're all gonna let a bunch of machines decide how we live."
I do not believe that "we" have no control over our machines, but the critical question is, "Who is 'we'?" The decision makers, be they managers, "movers and shakers" or whoever, are the ones with the control, both over the programmers and over the machines, and by extension, over all that the machines affect or "control".

-- Hardliner (searcher@internet.com), May 28, 1999.

My god - I'm agreeing with No Spam!
Hardliner,
yup - it's broke. it will not work - it was improperly/badly/inaccurately coded from day one. it is failing already.
it am broke!

-- Andy (2000EOD@prodigy.net), May 28, 1999.

Hardliner said at the top,
"The "fix" is a re-design of the date routine, and they are far from all being the same. They are as many and varied as the number and "flavors" of programmers who have authored them since the early 1950s. To complicate things, the only calculations more common than date arithmetic in computers are the simple "2+2=4" (well, actually, 0010+0010=0100) common arithmetic routines. We cannot possibly hope to find and redesign all date routines. We can only hope to deal with enough of them to keep things afloat while we find the rest."
The "many and varied" is unquestionable. Whether it is effectively a "redesign" is another of the key points of debate.
I think part of Hardliner's point is that we are looking at something quite a bit different than buggy code TRADITIONALLY understood. We are looking at (worse, trying to find) WORKING code that is doing exactly what its designers ORIGINALLY intended but that won't do what is NEEDED after 1/1/2000 (sorry for shouting, but emphasis might be helpful).
In my experience, that is analogous to testing (ie, trying to break or find potential breakage points in working code) but different.
Although pollys and doomers who have worked on Y2K seem to disagree violently about this (as I said, I don't do Y2K remediation), it remains open to question as to how easy it is to find, remediate and test for this singular challenge (redesign?). One of the reasons we have equally violent arguments about the nature of the potential show-stoppers is probably due to this singularity and our uncertainty about its implications.
Hardliner, yes? No? Or am I projecting into your thread?

-- BigDog (BigDog@duffer.com), May 28, 1999.

RD,
C'mon, you can do better than that!
Nitro is dangerous because it can explode.
Nitro is an explosive.
Computer code which performs exactly as designed and intended cannot be "broken".
What's happened is that the short sighted bean-counters said, "I don't give a sh*t if it can calculate dates after 1999, it's only 1972!" ('73,'74,'75, etc.) Now, they "give a sh*t".
What's confusing about that?

-- Hardliner (searcher@internet.com), May 28, 1999.

"I think part of Hardliner's point is that we are looking at something quite a bit different than buggy code TRADITIONALLY understood. We are looking at (worse, trying to find) WORKING code that is doing exactly what its designers ORIGINALLY intended but that won't do what is NEEDED after 1/1/2000 (sorry for shouting, but emphasis might be helpful)."
I thing BD has nailed it.
"doing exactly what its designers ORIGINALLY intended"
Many programmers would take issue with this statement but they were at the time overruled by the CHM's.

-- Andy (2000EOD@prodigy.net), May 28, 1999.

Hardliner:
People who pick nits like you do are part of the reason that most people are convinced that "everything is ok." If people who understand computers argue over insignificant topics like "the code is broken" "is not" "is too"... shheeeesh
Any computer professional should know that the potential for significant crashes or production of bad data is very real. It is extremely unethical to muddy the waters of discussion with such drivel.
We have a moral obligation to present the facts. The facts are:
Many computer programs will not work the way they are supposed to. Many organizations have done a good job fixing their programs. Many organizations have not done a good job (half the programmers out there are below average and write sloppy or buggy code.) Many organizations have not even taken a look yet. Most computer projects are delivered late and/or buggy. The consequence of preparing for Y2K and having it be a "bump in the road" are insignificant compared to the consequence of having Y2K be a major event and not having prepared.
www.y2kkitchen.com

-- sally strackbein (sally@y2kkitchen.com), May 28, 1999.

Hardliner,
No program spec ever said 'make this code work only until the end of 1999 and then it should stop working'. It was lack of forsight that led to this 'broken' code, not some explicit design choice.
-TECH32-

-- TECH32 (TECH32@NOMAIL.COM), May 28, 1999.

Andy,
You're right ("it will not work")
You're right ("it is failing already.")
I agree ("it was improperly/badly/inaccurately coded from day one.")
But you're wrong to say that it's "broken". It is doing exactly what it was coded and intended to do from day one, however much we don't want it to do the same thing after 1999.
As I remarked to RD, the managers have simply changed their "minds" (I know, that's a stretch) as to what the design criteria are.
BigDog,
You've grasped my argument precisely.
As to the "redesign" question, I think if Ford or GM can change the shape of a taillight lens and call it redesign, it's fair to call a change in the way a routine calculates the date redesign also.

-- Hardliner (searcher@internet.com), May 28, 1999.

HLiner,
"It is doing exactly what it was coded and intended to do from day one, however much we don't want it to do the same thing after 1999."
yup - I'm probably thinking that I would not have coded it that way, hence the slight disconnect...

-- Andy (2000EOD@prodigy.net), May 28, 1999.

-TECH32-,
The explicit design choice that you're looking for was, "Forget about the first two digits, hard code them as '19'." This design spec said, "Correctly calculate date/time arithmetic until 1999 and then start over at 1900. This choice indeed showed a lack of foresight, but it did not result in broken code. It resulted in code that performed flawlessly (and still is doing so) for decades and will continue to do exactly what it was designed and intended to do until midnight on December 31, 1999.
Ms. Strackbein,
I sincerely hope for your sake that there are things other than reason and assign priorities that you do well, because you most assuredly have struck out in those areas.
If you are ignorant enough to fail to realize that working with computers is remarkably akin to picking the fly shit out of black pepper, you are also far over your head in this discussion.
As to my ethics, I see no evidence that you are qualified to evaluate anyone's ethics, let alone classify a discussion of that which you apparently have little, if any, real knowledge. It is clear that your lack of ability to comprehend the discussion confuses you and thus you "see" only mud. Do you classify everything that you do not understand as "drivel"?
As to your "facts", what many computer programs are "supposed" to be doing, is EXACTLY WHAT THEY ARE DOING NOW! THE POINTY HAIRED MANAGERS OF OUR SOCIETY SAID SO!
Your apparent need to publish "the facts" should be accompanied by a knowledge of JUST WHAT THOSE FACTS ARE!
If you are so dense as to miss the fact that we are in the current state of affairs because our decision makers ordered our productive workers to do that which was in their financial interest but detrimental to the rest of society, then you indeed need to "go back to school" and get educated about where Y2K came from and where we'll end up if we don't address the cause of the problem.

-- Hardliner (searcher@internet.com), May 28, 1999.

I would like to ask a question.
A programmer in 1967 wrote an Assembler routine to sort all records based on an assumption of 99 being the greatest value in a 'yy' of a date field, and the routine worked very effeciently with all error trapping constraints in place. This logical sort routine worked so well for such a large number of similiar routines, that rather than write a new routine every time to sort all records, programmers in 1968 ,69,70...95 used the same sort routine within their project. The entire rest of the project also used canned routines folded within their own personal brand of logic/illogical system design. Loops nested within loops, trapped by errors to the nth degree of possibility and even improbability, to deliver the desired results. Everything from automatic backup to temp control valves in a reactor may use the same routine and therefore may be suseptible to flawed data when trying to add,sub,mult,divide,compare,sample,etc with 00 in the [yy]
Confound this by programs *etched* physcially into chips that used the same sort routine, in other words CANNOT BE OVERWRITTEN at the source, that may control traffic lights, oxygen delivery systems at the hospital, fire response computer at the local engine house, etc,.
Then of course for security reasons the sort routine in the Norad Defense System would be encrypted, as would a large banks accounting system, Boeings CnC milling machine,(producing sensitive parts), etc
Added might be a double dose of rewrites and runtime failure coverups, false positive on condition yy ERROR ERRor ErOr/* , etc etc etc etc etc etc etc etc etc
Warning Will Robinson, DANGER DANGER INTRUDER ALERT DANGER
The question is, could something *like* this happen? Excuse that last part. My humble appologies. jenuflecting. =\ =\ =\

-- unspun@lright (mikeymac@uswest.net), May 28, 1999.

"THE POINTY HAIRED MANAGERS OF OUR SOCIETY SAID SO!"
Surely CHM's - crewcut-haired managers in the 60's???

-- Andy (2000EOD@prodigy.net), May 28, 1999.

unspun
yes it could, it can and it will.

-- Andy (2000EOD@prodigy.net), May 28, 1999.

Hardliner:
I don't find working with computers to be like picking fly shit out of black pepper. That shows your bias.
I find joy in well written software. It sings to me. Poorly written software reminds me of spider webs entwined around and within your version. But then, I don't spend my time with your kind of software. I guess I've had the good fortune to have had mentors who loved what they did (and did it well) and passed that to me.
I am well aware that the Y2K problem is a management problem. At this point, what good is it to argue about who caused it? It's about like saying, "They did it to save memory." BS! They did it because punch cards only had 80 columns. Addressing the cause of the problem is a waste of time. The kind of people who made the decisions that got us where we are are still running the show. Guess what. They are not going to make good decisions now either! It is too late!
Your yelling at me does not make what you are saying profound. It is still drivel. Look up the word.
Those of us who comprehend the Y2K problem need to be discussing what can be done to save our own skins and the skins of those we love (assuming you love someone). We need to simplify the explanations we give to those who have not had the privilege to be geeks and nerds (I am a nerd/geek).

-- sally strackbein (sally@y2kkitchen.com), May 28, 1999.

Hardliner,
Your response to Sally Strackbein was over-the-line. Cool off.
- - - - -
Sally,
My apologies for Hardliner's overreaction.

-- No Spam Please (No_Spam_Please@anon_ymous.com), May 28, 1999.

No Spam Please saying that Hardliner "crossed the line". If that isn't the pot calling the kettle black! Go back and look at a few of your own past posts NSP.

-- none (none@none.none), May 28, 1999.

none (none@none.none),
>If that isn't the pot calling the kettle black! Go back and look at a few of your own past posts NSP.
So, you're saying that someone who makes a mistake is not entitled to chastise someone else for making that mistake?

-- No Spam Please (No_Spam_Please@anon_ymous.com), May 29, 1999.

As to the assumption that the y2k can be fixed...I bought new billing software in October 1998. The programmer rolled the clock at my request and then spent the next three days with us. That version was 3.4. I just had the programmer back again (free of charge) to install Version 5.2. This is the fourth time he has been back to our business.
Point is...If they can't get it right now, what in the heck makes anyone think that they will get it right when the chips are down (pun intended). I have no faith in the business community being willing to put forth a mega effort to fix 'code' when they can't do it now with no pressure.It would seem to be a moot point because when it breaks, it'll all break at once...and there will be no fixing that.

-- Lobo (atthelair@yahoo.com), May 29, 1999.

Ahhh stop squabbling the bunch of you :)
we'll find out how broke it is soon enough...

-- Andy (2000EOD@prodigy.net), May 29, 1999.

>"Broken" means, "does not work properly, or at all". This is NOT an accurate description of the "code", AT THIS TIME. It will not BE an accurate description until such time as the code attempts to process a date which is outside of the range it was designed to deal with. In most cases, this will occur at midnight on December 31, 1999. Code which looks forward and experiences the JoAnn Effect is an exception to the 1900-1999 date range.
I'm not aware of any software that was designed to work solely in the years 1900 to 1999. All the software I've ever worked on was intended either for very short-term ("throwaway") use or for an indefinite period of use. Clearly, the former case shouldn't pose any Y2K hazards, but just as clearly the latter case does, your sophistry to the contrary notwithstanding. In other words, the code in "indefinite lifespan" software (the vast majority of software) IS broken if it fails due to the expiration of 1999.

-- Steve Heller (stheller@koyote.com), May 29, 1999.

Hardliner,
Since I think we see pretty much eye-to-eye, I'm going to grin thru this for now.
unspun@lright,
You have touched on an area not yet discussed in this thread. A utility like SORT doesn't care if the data it's sorting on is a date, account number, dollar amount, or anything else. It deals with DATA. Just my opinion here, but dealing with dates in data is just as big a part of the problem as fixing the date "code." Sorting is a good example of where "windowing" doesn't work. The whole point of windowing is to avoid expanding date fields in existing files. So come 2000, when the code does break, and year fields have 00 in them, they'll sort before anything else, not after like they should.
So the point here is that the "code" in SORT will not break, the data will break. <:)=

-- Sysman (y2kboard@yahoo.com), May 29, 1999.

Settle down folks. This stuff is great. Am learning a suprising amount about a foreign subject. Gratefull illerate here.

-- Carlos (riffraff1@cybertime.net), May 29, 1999.

Carlos,
Get out of the back row and move a little closer. Ask away, the resources here are many, from both sides lately. Please, do hit the "about" link once in a while.
And everyone,
This mess started in the following thread, by a new unknown named The pollys. Yea, right... <:)=
Is the code broken?

-- Sysman (y2kboard@yahoo.com), May 29, 1999.

Hey Sysman-- This BUD 's for you
Back Up Date Is there a potential problem with reinfecting a "massaged" system accidentialy with corrupt data via a auto backup routine initiated at exactly the wrong time, so to speak? Say on 01/30/00 for example, the routine might compare [yy]'s to [yyyy]'s and crash...or data that is ?Fixed? being corrupted by old data from 99 (or vice a versa) on update?

-- unspun@lright (mikeymac@uswest.net), May 29, 1999.

Once more into the breach:
mikeymac,
That's a remarkably accurate description of the way things work in the real world. Another example (although not date related) is that the diagnostic routines first written to test the hardware functioning of a '1A' Add in System 360 are incorporated, bit for bit, in the corresponding diagnostic software for System 390.
Ms. Strackbein,
Again you make assumptions that should (but probably don't) embarrass you. The reason that you don't find working with computers like picking the fly shit out of pepper is that such experience as you may have is apparently limited to those high level interactions where designing a bit mask for a single byte is considered sophisticated. Should you ever find yourself attempting to discern which bit in a 64 byte wide data path is intermittently failing (egad! what a thought), even you would recognize how apt the comparison is. My perspective is a function of some 30 odd years of just such activity. Should you choose to characterize that as "bias", feel free. Everyone will make their own evaluation as to the accuracy of such.
Your poetic description of "singing software" and "spider webs entwined around and within your (my) version" and your haughty disdain for "your (my) kind of software" clearly reveals much of what passes for thought in your head. Good fortune or not, you clearly have not had exposure to much in the way of either hardware or operating system internal functioning.
Now the Y2K problem may be properly called a "management problem" in that poor management by self-interested managers caused it, but it is more properly characterized as an "obsolete code" problem because that's what needs to change, FIRST. Let's keep the lights on and the water flowing and the phones working first, and THEN, we need to insure that we don't have to do all of this again.
There is no argument about who caused the problem. Many here have recounted personal experiences that invariably indict the "bean-counters". As to their motivation, I quite clearly recall the explanation given to me by the vice-president of a $40,000,000 bank (a small, single branch bank) to the effect that the "extra" 4K of memory for his IBM 1401 would break his budget and was out of the question. In the matter of punched cards, your ignorance is showing again. Only IBM cards had 80 columns. Sperry-Univac cards had 90. In either case, the year was represented by a single digit in those cards.
Your belief that, "Addressing the cause of the problem is a waste of time", simply reveals that you either feel inadequate to the task of confronting those who make such decisions or are, for whatever reasons, willing to go through it all again.
I did not "yell" at you because I believed that what I had to say was in any way profound. In fact, what I had to say was simply accurate. I "yelled" at you because I think it appropriate to yell at people who don't know what they're talking about yet attempt to convince others that they do. Clearly, you are the babosa here.
And Ms. Strackbein, you've got a helluva lot of cheek and no class whatsoever to even use the word ethics, when the first "need" you bray about is, ". . .discussing what can be done to save our own skins. . ."! How utterly noble. . .
If you feel called to "simplify" your explanations for those who have not been privileged to achieve your own lofty status, by all means do so. But try not to say things that are inaccurate simply because they are easier to understand.
NSP,
Your definition of "The Line" is unacceptable to me. Who appointed you the Jello Sheriff? I didn't ask the "Singing Software Lady" to question or attack my ethics!
But, since the subject of ethics has arisen, I'll tell you plainly that yours stink. You have neither the right nor the ability to apologize for me. If I have any apologizing to do, I'm quite able to do it for myself.
In the future, I'll thank you to confine your comments to attacks on me without your taking liberties with my manners.
And to Steve Heller,
Your "awareness" needs some help, bub. Nearly all date/time processing software currently in use was designed to work only in the 1900-1999 "window". As to intentions, there's a saying about the Road to Hell and Good Intentions. Perhaps you've heard of it?
Let me suggest a short course in the English language for you. There is no "sophistry" involved; only simple language. Anything, be it a software routine or a monkey wrench, that is capable of all that it was designed to do, is by definition, not broken. You may not change the language simply because you have a preference for a certain turn of phrase or even because you cannot think outside of a box.

-- Hardliner (searcher@internet.com), May 29, 1999.

My apologies for the double posting.

-- Hardliner (searcher@internet.com), May 29, 1999.

unspun,
Not sure I follow you, but as for backup files...
This is a matter for the book-keepers. When was that file EXPANDED? Oh s!@t, we've got to put the old one back??? What was that program that they ran to expand this file? When did we do that Y2K compliant, latest and greatest, version upgrade? When did the programmer move it from test to production????? WHAT... HE RETIRED!?!?!?!?!?
Fun yet? <:)=

-- Sysman (y2kboard@yahoo.com), May 29, 1999.

Nice to see ya hanging out again Hardliner. <:)=
Nice to see ya . < . : . ) . =

-- SSyysmmannnnnn (y2kbo...y2kboard@taho...yahoo.com), May 29, 1999.

Catching up this morning, I REALLY feel like a vet having trauma flashbacks. Thanks to the young geeks and geekettes who are fighting THIS information war. I hope you win (no thanks to the pollys). As for me: more beans. More ammo.
Got stable sort routines?

-- BigDog (BigDog@duffer.com), May 29, 1999.

sheesh,yes,y2k is a design flaw,not a bug,or broken code,or a virus,or whatever.the rhetoric that's being thrown around here is fast approaching masterbation

-- zoobie (zoobiezoob@yahoo.com), May 29, 1999.

It's ironic that computer professionals, who must use "precise languages" to communicate instructions, would not agree with Hardliner's "precise language."
Imprecise thinking has brought us to a point where infrastructure failure possibilities are being discussed worldwide. Increasing our precision won't hurt us. We're destined to do something like this to ourselves again, if we don't.
Precise thinking leads to precise language. Precise language communicates instructions precisely.

-- PNG (png@gol.com), May 29, 1999.

PNG -- good point. Not to split the difference (I've been known to speak rather definitely on this forum), I think the unease comes more from a weariness with the constant hair-splitting over Y2K's pedigree, status and likely impact. However, I don't think that WAS Hardliner's intent. Heck, he expects TOTAL meltdown and Slick making a bid for total power.
It is true that a big reason for our status is IT's gross immaturity as a profession and that includes everyone: wilful ignorance on the part of CEOs; flabby IT management; brilliant but narcissistic geeks, and most of all, an unwillingness on the part of technology consumers to ask the hard questions of "all-of-the-above".
We do need to be more precise, particularly in our understanding of how to measure "results" and "values". CASE didn't cut it (too top-down, dictatorial, "SAP-like"). Hacking doesn't cut it. Looking at IT over the next 100 years or so, we are probably 30-50 years away still (IMHO) from getting to the first truly useful precision level. Hard to say whether Y2K failures and their political fallout will hasten or retard that.
It sure doesn't hurt to exercise the brain cells along the way. After all, this particular thread is for geeks or their relatives. We're supposed to be interested in this kind of stuff, no?

-- BigDog (BigDog@duffer.com), May 29, 1999.

Aww, damnit BigDog, had to go and use the "S" word, didn't you.
My 2 cents. I agree that the IT profession suffers greatly from a lack of certifiable standards. The fact is, the ultimate test of software is "does it work now". This is one reason I try to avoid "prototyping" systems during development; too often, if the "prototype" functions well, it is adopted for production. Code that had no real design applied is brought forward into production, because it "works".
The problem I saw with CASE technologies was the lack of a seemless interface to actual "code". (Other than perhaps that toolset from TI, the name of which escapes me at the moment). We tried to work with KnowledgeWare, which as CASE tools went was fairly good. But the actual code generation, for lack of a better word, "sucked". We made almost universal use of a "lower" CASE tool, TELON. Great code generator, but lacked the upper level "design" specifications. But it did result in fairly standardized routines and systems.
In my opinion, the whole purpose of CASE, RAD, etc., was to move the business analyst closer to actual code. Too often, the actual business need is lost or altered between the business requirements, and the actual technical design.
That is one reason I feel SAP has grown so much. A large part of the "design" is implemented via configuration changes, done by the "business" analysts. With SAP, the analyst can directly change the way the system works, without the intervention of programmers, systems analysts, etc. Both bad and good, but in the end I think it's better than before.
I do disagree with the concept we'll be spending years ferreting out date routines. I posted my opinion awhile back on c.s.y2k, but I truly think Y2k will end up being the death-knell of these old, monolithic systems, whether or not they're modified currently to handle the rollover. Even if they basically function, I think they'll be fairly unstable. And, I think the momentum will accelerate to replace these systems following the rollover. Maybe some of this is wishful thinking on my part; but I have seen numerous plans to initiate new projects following the rollover. So, while problems will be dealt with as they are encountered, the systems themselves I believe will be scheduled for replacement.

-- Hoffmeister (hoff_meister@my-dejanews.com), May 29, 1999.

Hardliner must be a newbie. Be nice people...we have a chance to convert a new GI! Isn't that wonderful. Each person who "gets it" will usually tell 2 others... so lets explain (nicely) to Hardliner that
the code is broken
we started to late
its systemic and interconnected
the .gov wants to keep ALL this under wraps
When the sheeple (clueless masses) find out the hard way 1-1-0000 there will be blood in the streets
start preping NOW for TEOTWAWKI
If you can get these topics, the normal fear you feel as denial passes will not be so bad.
Welcome Hardliner...may Y2K find you well prepared to fend off the clueless masses!

-- Regular (welcome@wagon.4newbies), May 29, 1999.

Hardliner:
You are right, I probably don't know as much about bits and bytes as you do, and I didn't know about the 90 column card. I started my programming career on 360/30s programming in assembler I was responsible for 10 360/30s and they used 80 column cards. I did, however, know about the 1 digit year problem. All punch cards did not use 1 digit years. How would you have indicated a birth date with a 1 digit year?
When I talk about "saving my own skin," it is because you are more likely to be able to save someone else when you are in a position of safety yourself. You should have checked me out before you accused me of having no class. I do not hide behind anonymity like you do. Who I am and what my motives are are in plain sight for everyone to see.
My reason for getting into this discussion is to challenge all the intellects out there to do what Ed Yourdon is doing. Use your intellect to get some conversations going that could do some good.
You are right again when you say, "Your belief that, "Addressing the cause of the problem is a waste of time", simply reveals that you either feel inadequate to the task of confronting those who make such decisions or are, for whatever reasons, willing to go through it all again." I do, in fact, feel inadequate to the task of confronting . That's why I do not take on the task of doing it.
You say, "FIRST. Let's keep the lights on and the water flowing and the phones working first, and THEN, we need to insure that we don't have to do all of this again." I agree, but I have no faith that it will be done. If you are in the trenches working on this, I applaud you.
I do, however, take on the task of telling people what they can do when "those who make such decisions," make bad ones. My major concern is that if we have major problems, FEMA, the Red Cross and the rest of the folks who rush in to help when a disaster hits cannot be everywhere and cannot help everyone. I spend an enormous amount of time and money to encourage average people, who have the resources, to do at least minimal preparations. I try not to scare them off by making the problem so complicated that they can't understand it or the task so large that it seems impossible.
You might enjoy picking apart my "Bean Theory." http://www.y2kkitchen.com/html/y2k_bean_theory.html
Again, I challenge all of you to use your intellects to do some good.

-- sally strackbein (sally@y2kkitchen.com), May 29, 1999.

Regular, Hardliner has been around for a LOOOOONNNGGG time!

-- Gayla Dunbar (privacy@please.com), May 29, 1999.

Hardliner,
I think it's a measure of how weak YOUR argument has become that you're reduced to debating semantics now. But just for the record, I very rarely ever use the phrase "the Code is Broken!" except when quoting a Doom-leaner. (Art Bell and Gary North seem to love the phrase -- not moi.)
And you think I'm the "least qualified" to discuss code here? Heh. I guess that's just proof that we run in different circles.
But do me a favor: don't tell that to any of the companies for whom I've programmed (and taught programming techniques to, in many cases); they might want their money back.
Gotta run; I need to finish writing the code for this little Windows(tm) VxD-and-shell widgie-thingie that'll do real-time control for several transmitters over microwave and T1 links ... :)
Don't worry; I won't discuss that with you, because I doubt very seriously that you'd understand one word out of twenty.
Now go away.

-- Stephen M. Poole, CET (smpoole7@bellsouth.net), May 29, 1999.

Hoff --- I agree pretty much down the line with your thoughts on CASE. Code generation was a laugh riot, to be sure.
SAP aside (and as I've said, I actually like it), I also agree with your post Y2K picture, with one major caveat. Yes, whether Y2K is a bump or a disaster (short of entire infrastructure collapse), we will be seeing lots of system replacement.
However (and this is a big one), those 2,000 or so (I'm making the number up) HUGE enterprise systems that "run the world" can't be replaced on a dime. Hence, my "five to ten years" to close-out Y2K worldwide. And that may be too optimistic by far ... for them.
I continue to believe that most of us fail to understand their operational role in making the world's "trains" run on time and their consequently desperate exposure to Y2K.
Even the next 10,000 or so (say) enterprise systems (which probably are amenable to things like SAP or their equivalent in other application types) are a magnitude-level easier.
As for Poole, it's ironic that the type of stuff he purports to do is not mission-critical, by and large. 'Course, it could explain why he is a fanatical polly (the "anti-Milne").

-- BigDog (BigDog@duffer.com), May 29, 1999.

BigDog,
I need to make a few comments here in the interest of clarity.
My point, in starting this thread, was quite simply that the code is NOT broken; it is functioning quite well. To say otherwise is simply inaccurate and the publication of inaccurate information can never improve one's credibility.
As to my personal views regarding "Slick" and a "TOTAL meltdown", I have concluded the following:
At one time, I held the opinion (and still do, for that matter) that only one thing was certain about "Sadly Insane", and that was his unpredictability. I am saddened and angered to find myself holding the same opinion of an American president. I really don't know what to expect from "Slick", but I do believe that he is as evil a man as any who have ever held power over others and would put absolutely nothing past him.
The question of a "TOTAL meltdown" is a bit dicey, since the term is somewhat imprecise. Generally, I agree with those who hold that TEOTWAWKI does not mean the same thing to everyone and that effects of the Y2K problem will be differentiated according to location. I have faith in the words of men like Lane Dexter, who operates a hydro-electric dam for the City of Seattle when he says, "I don't know about anywhere else, but we'll have power here." The guys with dirt under their fingernails are truly the ones who will make or break us in the days to come. I have serious concerns about the same areas that most everyone else here does, and have NO faith in the "happy face" pronouncements of PR flaks. I fail to see how the federal government can survive in anything like its present form when, according their own reports, over 90% of their computer systems will not be compliant by the rollover. I see the same thing for state governments and any other governmental entities that are computerized to any significant degree. As I have said, I don't believe than any current government above the county level will be operating 18 months from now. I DO think that there will be some organization, probably built around the armed forces that will coalesce and attempt to perform some of the more basic functions of a national government, but I expect such to be VERY different from what now exists. The jury is very much still out on industry and commerce, since the bulk of the information available to us is self-reported and thus suspect. I am not encouraged by the fact that the single instance that I have accurate, first hand knowledge of is a multi state concern which lies on its website and lies to its management in internal communications, about the status of its Y2K problem. I do not think it likely that this is an unusual situation. Because of my conclusions about government, and because of our society's dependence on government in so many areas, I expect a certain amount of chaos to come about, but I also know that built into each of us is the Prime Directive of Nature, "Survive!" I certainly plan to do so. I and my family have been a part of a local group for nearly two years now that has agreed to face whatever comes, together. We have prepared as well as we have been able, and have managed to reach a point where we not only are secure in our own survival, but are able to help an indeterminate number of others in various ways. We view our preparations as aimed at transitioning to a simpler way of life as opposed to sustaining the current one and should such prove un-necessary, none of our preparations will go to waste. Although I consider myself PREPARED for a complete meltdown, I do not know what to expect. I think the future, as always, will become somewhat clearer the closer we get to it.
Hoff,
You may well be right about the replacement versus remediation angle. It certainly makes sense, yet that very fact makes me wonder if it will happen. I believe that if it is cost effective, replacement will be the order of the day and if not, we'll just keep on making the same old mistakes all over again.
"Regular",
Thank you for the advice and good wishes. They are reciprocated.
Ms. Strackbein,
You are obviously correct in that dates as "data" would always require more than one column, but dates as labels of "now" generally only used a single column. The problem was self-solving however, as the cards physically wore out long before the practice caused a problem.
I have a problem with your concept of saving yourself first in order that you may help others. I owe my life and continued existence to many fine men and women who put my safety first and without regard to their own. It is, however, a difference of values and you are quite free to hold whatever values you think are appropriate.
I described you as "having no class" because you took it upon yourself to question and attack my ethics. Regardless of what I might have found in "checking you out", that was an act without class.
As for my anonymity, not only have I paid my dues to this society and am entitled to such, it insures that my words will be judged on their merits, rather than on whoever I might be. My reasons for anonymity are, quite frankly, none of your business and you are free to draw whatever conclusions about it that you wish. Your motives are irrelevant whether plain and open or not. It is your actions which will count where it matters.
I find it strange and inconsistent that you should choose to pursue your stated objective by questioning my (or anyone's) ethics. If you cannot see that ceasing to parrot the moronic phrase, "The code is broken", might do some good, I cannot help you.
I admire your honesty in revealing your fears about confronting the PsTB, yet that very revelation displays clearly that you have the necessary courage to do just that. I think that you should reconsider your position. You might be surprised what one person can accomplish with such opposition.
I must admit that I too, am not optimistic about the likelihood of our avoiding a repetition of all this, but I refuse to accept my own pessimism as an excuse to give up the fight.
Your efforts as described, are certainly worthy endeavors and I wish you much success. I will caution you again, however, that you will defeat yourself in the end if you attempt to avoid "scaring people off" by giving them inaccurate information.
Stephen Poole,
You do know how to read, don't you? (at least minimally?) What I said about you, was that you had displayed the, ". . .flimsiest claim to logical thought. . ." of the two individuals who initiated the question. As I recall, you vehemently asserted that the Titanic situation was in NO way analogous to the Y2K situation and attempted an analogy of your own. Something to the effect that a single apple had NOTHING in common with a truckload of fruit. You exposed not only a serious lack of botanical knowledge, but your inability to make connections between related concepts. You need a great deal of practice at reasoning before you venture out into the real world. It wouldn't hurt you to learn to read a bit more carefully either.
For your own sake, develop a more realistic perception of the relative value of virtual device drivers in the grand scheme of things before you blow your own horn again.

-- Hardliner (searcher@internet.com), May 29, 1999.

none (none@none.none),
I'm curious as to what you mean about "a few of [my] own past posts". Will you please write to me at nos_pam_please@hotmail.com and explain further?
- - - - -
Hardliner,
Will you please write to me at nos_pam_please@hotmail.com to explain what you mean about my ethics "stink"?

-- No Spam Please (usuallly No_Spam_Please@anon_ymous.com) (nos_pam_please@hotmail.com), May 29, 1999.

CODE!!! CODE!!! Why do you all it code?? It is software. You are programming. not coding. As for being broken, you may write some that works just fine, but has an area that will not function as you had thought you had "programmed" it to do. The entire thing will not crack in half and crash and burn, leaving you with a dead program, it will produce erronious results where logical results were expected.
And Yes, the expression "the code is broken" causes non computing people to think an entire system will not work. Does a data processor "code"? Does a web page maker "code"? does a person writing in their notepad "code"? Are you "coding" if you write an operating system? Are you "coding" if you use an write a program using an operating system? Am I coding if I change the font color? (I wrote what I did because it was a "pet peeve)

-- Cherri (sams@brigadoon.com), May 29, 1999.

Cherri,
The dictionary definition that is relevant to this discussion is:
Code n. . . . 3. A set of signals, characters, or symbols used in communications, as the Morse code. 4. A set of symbols with arbitrary, prearranged meaning, as words, letters or numerals, used for secrecy or brevity in transmitting messages.
As I noted above, all information inside computers, both data and instructions, is in the form of binary numbers--ones and zeros. Any representation of such in anything except binary numbers is, by definition, in a coded form. A lot of data is coded in the form of the English language or arabic numerals. Instructions are almost always coded in higher level languages such as "C" or COBOL. Frequently, binary numbers are coded as hexidecimal or octal numbers. It's all various forms of "shorthand" to avoid finite but interminably long streams of ones and zeros.
Instructions that are a part of the hardware design are said to be "hard-wired" instructions. Instructions in Read Only Memory (such as a PC's BIOS chip) are called, "microcode" which is generally taken to be a synonym for the word, "firmware". Instructions which compose operating systems and application programs are called, "macrocode" which is generally taken to be a synonym for the word, "software". Parts of instructions which are written as constants (such as the '19' for the century) are said to be "hard-coded".
These are common terms in the computer industry, most of which have their origin in IBM manuals and answer your question, "Why do you (c)all it code??"
You err in failing to note that logical results and erroneous results are not mutually exclusive. If you begin with a false premise, and reason perfectly (that is, your logic is correct), you will arrive at a conclusion which is logically valid but factually erroneous.
You also err in stating that a defect will not result in a "dead program". The truth of the matter is that a failure in a complex system, while sometimes resulting in catastrophic results, is most likely to result in a simple cessation of system operation. In the IBM mainframe world, this is commonly called an "ABEND", which is an acronym for "abnormal end". Attempting an invalid operation (such as trying to divide by zero, as might occur from a '00' operand) will simply shut down the program and will not result in erroneous, or any other, results. (At that point, it is up to the operating system to prevent the failure from halting the entire system.)
The remainder of your questions ("am I, are you, coding if. . .?) are answered in the affirmative in all cases except those in which you express yourself in binary numbers.

-- Hardliner (searcher@internet.com), May 29, 1999.

Hardliner,
I understand about binary, octal and hex. As a matter of fact I can take a line of "code" and trace it digitally throughout a computer (mainframe) throughout every component. I am just being a little anal about the wording. I learned "programming" "data processing" HTM(L) writing and like the differentiating. I may not like the wording "coding" but I am sure I will live *grin*. I also get irritated when someone puts the toilet paper on the roller the wrong way.

-- Cherri (sams@brigadoom.com), May 29, 1999.

Scene One:
Darth Kid meeting Darth Maul:
DK: The code is not broken.
DM: Listen, kid, it's broken.
DK: The Force will not let it be broken.
DM: You lose. It's broken.
DK: The Force will make it compliant.
DM: Fat chance, kid. Prepare to die.
DK: You can't win with the Dark Side of the Force.
DM: Heh. Watch my spin!

-- dinosaur (dinosaur@williams-net.com), May 29, 1999.

Hardliner,
You have achieved a new status: that of someone who not only forgets what he READS, but what he has WRITTEN as well. From the initial post in this thread:
two individuals who have displayed some of the least understanding of the mechanics of instructing a computer ... and the flimsiest claim to logical thought (Mr. Decker and Stephen Poole, respectively) ...
... so, I responded to that. Maybe you need someone to keep up with what you've written -- and with what I'VE written. I've never said anything about apples here. I did say the Titanic was a terrible analogy ... and it is.
As for Poole, it's ironic that the type of stuff he purports to do is not mission-critical, by and large.
Whew, you're a piece of work. The system that I'm working on now is quite "mission critical," thank you. Date-sensitive, too (and yes, it's Y2K-ready[g]). :)
And by the way: I'm not really an "anti-Milne;" he's not worth the time. Very few people take him seriously, so why should I bother?

-- Stephen M. Poole, CET (smpoole7@bellsouth.net), May 30, 1999.

Cherri,
The term "code" came from the first programmer who ever had to swim through Microsoft's wonderful documentation. :)

-- Stephen M. Poole, CET (smpoole7@bellsouth.net), May 30, 1999.

poole you simpleton,
"Date-sensitive, too (and yes, it's Y2K-ready[g]). :)"
not without power, maroon,
and as for your mirosucks comment, yup they were around before the word "code" was coined, oh yes, yup, yup yup...

-- Andy (2000EOD@prodigy.net), May 30, 1999.

Andy,
Go play with your Nintendo and leave the serious discussion to the adults.

-- Stephen M. Poole, CET (smpoole7@bellsouth.net), May 30, 1999.

Master Poole,

As it is now apparent that you are functionally illiterate, for your edification the paragraph in question follows, with suitable annotation (in red) for the mentally handicapped:
"That the question should be initiated ( in this thread as follows:
Flint,

Can we do "the code is broken" next?

Regards,

-- Mr. Decker (kcdecker@worldnet.att.net), May 27, 1999.

Decker,

Yes, please. Lets. :)

-- Stephen M. Poole, CET (smpoole7@bellsouth.net), May 27, 1999.

-- The pollys (Decker@nd.Poole), May 28, 1999)

and indeed insisted upon as a subject for discussion by two individuals ( neither of which has been named in this paragraph as yet) who have displayed some of the least understanding of the mechanics of instructing a computer how to do what you wish it to do (here is the FIRST description of an individual) and the flimsiest claim to logical thought (here is the SECOND description of an individual) (Mr. Decker and Stephen Poole, (here the names of the TWO individuals in question are stated in THIS paragraph) respectively), (and here the TWO descriptions are referenced to the TWO individuals so named. The word "respectively", means that the descriptions apply sequentially and individually to the TWO individuals named in the order that the TWO descriptions appeared.) is understandable."

In the case of Mr. Decker, the description is simply a reflection of his own characterization of the state of his knowledge. In your case, Poole, the description is a result of the mental malfunction that you displayed in this thread

The Titanic analogy is far from perfect but it does share certain themes with the Y2K situation.(These are my words that you repeated from an earlier post on the same thread.)

No it doesn't; it's completely inapplicable. You're comparing a single apple with a truckload of different types of fruit.

-- Stephen M. Poole, CET (smpoole7@bellsouth.net), May 20, 1999.

As the above clearly reveals, you have either got a reading comprehension problem, or a cognitive one (or more likely, both). Further, it would seem, your own words, "I've never said anything about apples here.", indict you as having either a selective or malfunctioning memory or as a liar. (although the possibility exists that someone else posted the above in your name, I find it less than credible that anyone would willingly impersonate you)

While I have no way of ascertaining (and really could not care less) whether or not you have achieved chronological majority, it is clear that you have yet to achieve the status of "adult" in the mental department.

-- Hardliner (searcher@internet.com), May 30, 1999.

Umm at the risk of bringing a balista to a machine gun fight, having hunted a few nits, I gotta point out that the IBM SYS 3 used a two row (90 I think) col card. Either 90 or 50.
Chuck

-- Chuck, a night driver (rienzoo@en.com), May 30, 1999.

Chuck,
You're right! I'd forgotten about System 3, probably because I think I've only ever seen ONE! As I remember, the cards it used were tiny (less than half the size of the "regular" IBM or Univac cards). Didn't it use round holes like the Univac?
Since you're from New York, you probably remember the toll tickets that you got as you entered the NY state Thruway. They were Univac cards.

-- Hardliner (searcher@internet.com), May 30, 1999.

Hardliner,
ROTFLMAO!!! Superb - LOL, what a maroon poole is - this thread has made my day!

-- Andy (2000EOD@prodigy.net), May 30, 1999.

Another oddity that was used for a while, may still be in various installations was paper tape with round holes punched in them. Most often used in multi-function machine shop equipments. I think Sperry may have produced them. Maybe not?
By the by, many of these did use and refer to date in regards to production, inventory back stock, shipping and recieving, warehousing, CPM, MRP, MRO, etc. Boooing used them for a time in many machining jobs. Hope that's not part of their workaround regiem
This was of course pre barcode, which, by the way, is the topic for another date reduntant source of corrupt dat(um). Maybe {:>(

-- unspun@lright (mikeymac@uswest.net), May 31, 1999.

"Another oddity that was used for a while, may still be in various installations was paper tape with round holes punched in them. Most often used in multi-function machine shop equipments. I think Sperry may have produced them. Maybe not?"
We used to IPL our ancient British Airways ICL 1904A and 1906S machines with this loop of paper!
No wonder ICL are crap.

-- Andy (2000EOD@prodigy.net), May 31, 1999.

Moderation questions? read the FAQ