Computer experts sweat out the Y1.999K problem
Robert F
of the geeks here can comment.
From today's WSJ.
Robert Folsom
=================
February 9, 1999
Work Week
FIRST THINGS FIRST: Computer experts sweat out the Y1.999K problem.
Troubleshooters, told to avert computer crashes when the year 2000 arrives,
are also tackling glitches involving nine dates in 1999. The most worrisome
is Sept. 9 because some old software systems use a "9999" code to signal an
error or the end of a program. Diamond Data Systems Inc., a Kenner, La.,
computer-services firm, has two dozen Y2K people also working on "nines"
flaws.
Finding a 9999 "bug" isn't "overly complex work," says Paul Lypaczewski,
president of TrueSpectra Inc., a Toronto-based Internet-graphics provider.
"But if you have old software, you may have to spend a lot of time going
through it."
The nines bug, which affects fewer computer systems than the Y2K problem, is
probably even "more damaging if it doesn't get caught," says Robert Martin,
Y2K coordinator for high-tech researcher Mitre Corp., Bedford, Mass.
Lane Core Jr.
wrote:
>The "more damaging" quote at the end is what got my attention. Perhaps some
>of the geeks here can comment....
>The nines bug, which affects fewer computer systems than the Y2K problem, is
>probably even "more damaging if it doesn't get caught," says Robert Martin,
>Y2K coordinator for high-tech researcher Mitre Corp., Bedford, Mass.
Hooey.
---------------------------------------------------------------------------
Mr. Lane Core Jr. elc...@sgi.net http://users.sgi.net/~elcore/elc_y2k.htm
---------------------------------------------------------------------------
"More software projects have gone awry for lack of calendar time than for
all other causes combined". Frederick P. Brooks, _The Mythical Man-Month_
Bradley K. Sherman
Robert F <rob...@bellsouth.net> wrote:
>The "more damaging" quote at the end is what got my attention. Perhaps some
>of the geeks here can comment.
> ... Diamond Data Systems Inc., a Kenner, La.,
>computer-services firm, has two dozen Y2K people also working on "nines"
>flaws. ...
Diamond Data Systems is a remediation consultant. What this
means is that then have convinced customers that they should
pay DDS to look for (most likely non-existant) 9999 problems.
I only mention this because it could be read as saying that
the company has two dozen Y2k people looking at DDS' systems,
which is not the case.
Now beyond that, I have used 9's as a sentinel but I've
never been so stupid as to use a string of 9's that
could in any manner be mistaken for a legitimate date.
I could see 9 Sept 1999 as '19990909', '09091999', '090999',
'990909', or even '099909' from a programmer on drugs but
'9999'? Very, very unlikely.
--bks
David Ramsey
of the year. Thus, if someone were tracking dates that way you could
write 9999.
--
==============================================================
| "Always listen to experts. They'll tell you what can't be |
| done, and why. Then do it." |
| -- Lazarus Long, in Robert Heinlein's Time Enough for Love |
==============================================================
Robert Egan
date. I never even heard of it, either as a real issue or as a gag,
until I started reading the posts here. Frankly, I find it hard to
believe there's more than a dozen cases in the entire world.
On the other hand, I -did- work with an archiving system which used
12/31/99 as way to indicate "indefinite" storage. I don't work there
anymore, but I hope they've upgraded the application, or a lot of media
will be "scratched" that weekend!
Regards
Robert Egan
Robert F wrote:
>
> The "more damaging" quote at the end is what got my attention. Perhaps some
> of the geeks here can comment.
>
> [snip]
>
> The nines bug, which affects fewer computer systems than the Y2K problem, is
> probably even "more damaging if it doesn't get caught," says Robert Martin,
> Y2K coordinator for high-tech researcher Mitre Corp., Bedford, Mass.
--
To reply by email: remove nospam_allowed.
Robert Egan
>
> It was common in 2nd generation (before my time). Some systems and
> languages didn't have EOF sensing.
>
I have used "sentinels" frequently. I just -NEVER- heard of anyone using
9/9/99. That's the whole point of the thread.
> There is a huge inventory of code that pre-dates databases and a
> significant inventory that pre-dates EOF sensing.
>
> In the mid 1970's I saw 9's cards being taught as the proper way to
> terminate files.
Yes. As Bradley said, 99/99/99 -WAS- used -OFTEN-. I myself was taught
that technique in school in the late seventies. But I don't know anybody
born on that date, and I'll bet you don't either.
>
> [snip brief history of relational database development]
>
Hope this clears up any misunderstanding.
Regards
Robert Egan
M.Kobobel
the 99th day
of the year. Thus, if someone were tracking dates that way
you could
write 9999.<<
Nope, that would either be 99099. I can't think of a single
instance where a programmer would use less than 3 digits for
a Julian day.
Bradley K. Sherman
David Ramsey <dra...@voicecommander.com> wrote:
>I think the 9999 reference is due to April 9th, 1999 being the 99th day
>of the year. Thus, if someone were tracking dates that way you could
>write 9999.
Okay, except the article explicitly says
"The most worrisome is Sept. 9 because some old
software systems use a "9999"
I think we're all in agreement then that the article needs
a rewrite.
--bks
cory hamasaki
hoff_meister
>
> On Wed, 10 Feb 1999 00:33:21, Robert Egan <egan263@nospam_allowed.ix.netcom.com> wrote:
>
> > In all my years of IT work, I never saw 9/9/99 used as a "sentinel"
> > date. I never even heard of it, either as a real issue or as a gag,
> > until I started reading the posts here. Frankly, I find it hard to
> > believe there's more than a dozen cases in the entire world.
>
> It was common in 2nd generation (before my time). Some systems and
> languages didn't have EOF sensing.
>
> There is a huge inventory of code that pre-dates databases and a
> significant inventory that pre-dates EOF sensing.
>
> In the mid 1970's I saw 9's cards being taught as the proper way to
> terminate files.
>
Cory, could you explain how a 9's card could lead to a 9/9/99 date? Or
for that matter, the other problem date of April 9?
I'm assuming this must be a problem in some systems, but I haven't been
able to figure out just how this happens. How does 999999 translate to
990909, or 090999, or for that matter 99099? Like I said, I've been
trying to envision how this would happen, and just haven't been able to
figure out any likely scenarios.
Hoffmeister
Theo DP
>From: Robert Egan <egan263@nospam_allowed.ix.netcom.com>
>Date: 2/9/99 10:46 PM Central Standard Time
>Message-id: <36C10F3D.9AE92A22@nospam_allowed.ix.netcom.com>
>
>cory hamasaki wrote:
>>
>> It was common in 2nd generation (before my time). Some systems and
>> languages didn't have EOF sensing.
>>
>
>9/9/99. That's the whole point of the thread.
>
<<Snippety-Doo-Dah>>
The story I've heard is that 090999 was used when date edits precluded the use
of 999999.
That said, I've never seen such a use in my 20+ years.
David Ramsey
given a while back for the 9999 "problem".
"M.Kobobel" wrote:
> >>I think the 9999 reference is due to April 9th, 1999 being
> the 99th day
> of the year. Thus, if someone were tracking dates that way
> you could
> write 9999.<<
>
Andy Kushner
Robert Egan wrote in message
<36C0D3D0.914125DC@nospam_allowed.ix.netcom.com>...
>In all my years of IT work, I never saw 9/9/99 used as a "sentinel"
>date. I never even heard of it, either as a real issue or as a gag,
>until I started reading the posts here. Frankly, I find it hard to
>believe there's more than a dozen cases in the entire world.
>
>12/31/99 as way to indicate "indefinite" storage. I don't work there
>anymore, but I hope they've upgraded the application, or a lot of media
>will be "scratched" that weekend!
>
>Regards
>Robert Egan
Robert,
Ditto on that. I think the 9/9/99 is yet another
red herring.
In regards to the 12/31/99 issue, if you're referring to
the expiration date for tapes in a well known application
on MVS, I believe it was fixed in the mid-90s. I first installed
it at our shops in 1981 and wondered what would happen
in '99.
Before the hard core DoomBrood (tm) start thinking about
another opportunity for disaster, the application also
treated the year "98" as a special case. Therefore, anyone
that expects problems in 99 should have had tons of
problems last year. If they haven't fixed it yet, then
Darwin's theory probably applies.
Andy Kushner
GeorgeV...@usa.net
kiy...@ibm.XOUT.net (cory hamasaki) wrote:
> In the early 1980's, I saw a live, in the naked metal, IBM 7080 computer
> running production work at a military facility.
In the mid '60s I was programming a 7080 and we learned of a shop
that was running 705 code on a 360/65 with the 7080 emulator. (The
7080 was backward compatible from the 705 III to the 705.) This shop was
some insurance company, and it was not expected to re-write the 705
code since it "worked". Unfortunately, the 360/65 7080 emulation
was so much slower than the native 7080, not many were willing to
use the 360.
I have always felt that if IBM had made a 7084, the 360 woiuld have been
in big trouble.
Your point about ancient code is valid.
George
This is the timeframe
> in which the demonized FAA replaced their 3050's (360 mod 50's) with the
> 3083's.
>
> In the late 1990s, some buds took down a live 360 mod 40 with 2314 disk
> drives that was running production for an insurance company.
>
> In a world where companies that sell browsers, run search engines, and
> lord help us, sell books on the Internet, have valuations in the
> billions of dollars, it's hard to understand the importance of legacy
> code.
>
> Get over it people; the world does not run on eBay, it runs on legacy
> iron, 50,000 IBM style mainframes, 500,000 AS/400s, 100,000 S/3xs, and
> who knows how many VAXen, PDP-11's, and DGs.
>
> But hey, what do I know, any clown who can click up a Lan and call
> himself a lord is qualified to run his keyboard.
>
> It's started to unravel, time has run out, management is babbling
> like crazed loons, tonight I heard about another deathmarch. All
> weekends and holidays are cancelled for the rest of the year.
>
> cory hamasaki 325 Days, 7,800 Hours, Less than 11 months.
> http://www.kiyoinc.com/current.html
>
>
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Ron Martell
>Robert,
>
>Ditto on that. I think the 9/9/99 is yet another
>red herring.
>
>In regards to the 12/31/99 issue, if you're referring to
>the expiration date for tapes in a well known application
>on MVS, I believe it was fixed in the mid-90s. I first installed
>it at our shops in 1981 and wondered what would happen
>in '99.
>
>Before the hard core DoomBrood (tm) start thinking about
>another opportunity for disaster, the application also
>treated the year "98" as a special case. Therefore, anyone
>that expects problems in 99 should have had tons of
>problems last year. If they haven't fixed it yet, then
>Darwin's theory probably applies.
>
That rings a bell. There was a post a month or so ago from someone
who stated that he had seen 9/9/99 used as a tape expiration date.
Hopefully I marked the posting to be retained - I'll look for it this
evening.
Ron Martell Duncan B.C. Canada
--
Microsoft MVP
On-Line Help Computer Service
http://www.islandnet.com/~rmartell/online.htm
cory hamasaki
docd...@clark.net
cory hamasaki <kiy...@ibm.XOUT.net> wrote:
[snippolinio]
> DYL-260,
... in case anyone missed an eloquent, pithy editorial comment made
earlier about this:
'GkkhhhhaaaoooOOOOOoooorrrrrkkkkkkk... phthooOOie!'
DD
hoff_meister
C'mon now, Cory. I can make up a hundred examples of clueless coding,
that could fail at anytime.
That wasn't the point. Your response to Robert's post that he'd never
seen 9/9/99 used as a "sentinel" date was "it was common in 2nd
generation". This is your example?
Hoffmeister
Gary L. Smith
: Yes. As Bradley said, 99/99/99 -WAS- used -OFTEN-. I myself was taught
: that technique in school in the late seventies. But I don't know anybody
: born on that date, and I'll bet you don't either.
Of course you don't -- that date is in the future! But perhaps someday
you will, since according to Excel DATE(99,99,99) is June 7, 2007.
--
Gary L. Smith g...@infinet.com
Columbus, Ohio
Lane Core Jr.
>>Subject: Re: Computer experts sweat out the Y1.999K problem
>>From: Robert Egan <egan263@nospam_allowed.ix.netcom.com>
>>I have used "sentinels" frequently. I just -NEVER- heard of anyone using
>>9/9/99. That's the whole point of the thread....
>The story I've heard is that 090999 was used when date edits precluded the use
>of 999999.
>
>That said, I've never seen such a use in my 20+ years.
See http://www.y2ktimebomb.com/Computech/Issues/lcore9850.htm
Robert Egan
>
> In regards to the 12/31/99 issue, if you're referring to
> the expiration date for tapes in a well known application
> on MVS, I believe it was fixed in the mid-90s. I first installed
> it at our shops in 1981 and wondered what would happen
> in '99.
>
No. It was strictly home grown. One of the SysOps was taking COBOL
courses at night so he could transfer to IT and he wrote it for kicks.
It worked so well, they put it into production.
Robert Egan
While I find the 9/9/99 situation astounding, I -have- seen equally
ridiculous examples in production code, so it wouldn't surprise me. I
still feel that this is a much rarer occurence than 12/31/99.
Your article should put this thread to rest.
Regards
Robert Egan
Lane Core Jr. wrote:
>
> See http://www.y2ktimebomb.com/Computech/Issues/lcore9850.htm
Moshe Shulman
>Hoffy and Egan,
>
>Here's a record;
>
>1...v....1....v....2....v....
>123197HOFFY JOE
>090999EGAN SAM
>999999EOF EOF
>
>/* nosubstringrange */
>
>dcl 1 record,
> 2 date,
> 3 month char(02),
> 3 day char(02),
> 3 year char(02),
> 2 lastname char(10),
> 2 firstname char(20),
>
>call readrec();
>
>if substr(record.date.day, 1, 3) = "999" then call doeof();
>
>call processrec();
>
>Hmmmm, Sam Egan's data doesn't get processed.
Cory this is just poor programming as it just doesn't make sense. You
have to be an idiot to do that. All 6 digit dates that I have seen
have used '999999' as the highest date.
--
Moshe Shulman mshu...@ix.netcom.com 718-438-7340 x21
Empire State Supply
'There is something facinating about science. One gets such wholesale
returns of conjecture out of such a trifling investment of facts.'
Mark Twain
Andy Kushner
Ron Martell wrote in message <36c2c20e...@news.islandnet.com>...
>>the expiration date for tapes in a well known application
>>on MVS, I believe it was fixed in the mid-90s. I first installed
>>it at our shops in 1981 and wondered what would happen
>>in '99.
>>
>
>That rings a bell. There was a post a month or so ago from someone
>who stated that he had seen 9/9/99 used as a tape expiration date.
>
>Hopefully I marked the posting to be retained - I'll look for it this
>evening.
>
>
>Ron Martell Duncan B.C. Canada
This commercial package on MVS used the EXPDT field of
LABEL parameter to define a code used in the vendor's
proprietary database, and the tape could not be written
on before that date. They used the Julian date of
99365 (December 31, 1999) to indicate the tape will
*never* expire. As I said, way back in '81 (I was a
mere babe in arms then) I wondered what would happen
in 1999. I was told yesterday by our sole remaining MVS-head
that version 5 of that package fixed this in the early to mid-90s.
Like I said previously, the package also used EXPDTs in '98
for codes as well, so most shops have either upgraded to the
new release, or I expect they are dead.
Andy Kushner
Y2K Whit
>You
>have to be an idiot to do that.
Makes about as much sense, as those using 6 digit dates less then 10 years
ago.... but naaaaaaaaaa...only an idiot would do that....
.
.
Remember to practice a RANDOM ACT of KINDNESS :)
Jim Cobbs
> This commercial package on MVS used the EXPDT field of
> LABEL parameter to define a code used in the vendor's
> proprietary database, and the tape could not be written
> on before that date. They used the Julian date of
> 99365 (December 31, 1999) to indicate the tape will
> *never* expire.
The only serious implication to all this is that unless the operating
system and/or tape management system used at a site have been "fixed" is
that tape that should be protected by software will no longer be
protected by that software and are available to be written on.
This is, maybe, not such a big deal as many non-geeks think: you still
have to physically put a "write ring" into a slot in the back of the
physical tape reel ("No ringie, no writeie" was the memory jogger)
and/or turn a little dial on the newer tape cartridges.
The only folks that could end up in deep do-do are the ones that run
really sloppy operations -- and maybe they deserve what they will get?
What happens is that folks get lazy: they leave the "write ring" in the
tapes (or dont' change the dial setting on cartridges) and depend on the
software to protect them. In any case you still have to order up the
"expired" tape and physically mount it before anything can happen to
it.
You could have a whole tape vault full of tapes that are as safe as the
day they were created just because they *are* old tapes and are not in
current production.
phy...@computerpro.com
elc...@sgi.net (Lane Core Jr.) wrote:
>
> See http://www.y2ktimebomb.com/Computech/Issues/lcore9850.htm
>
Lane's article also mentions the problem of *users* manipulating their data
with special-meaning dates. ISTM that the problem of "flag" dates lurking in
the data of *COMPLIANT* systems could easily be overlooked during the
assessment stages of a y2k project.
I know of at least 5 y2k-compliant apps that I either worked on or built,
where the users invented their own "key fields" using valid dates. These are
all xbase apps, with 2- or 4-digit-year entry allowed, but 4-digit-year
displayed and stored. Each of my apps where I know this has happened have ad
hoc query functions or user-definable report parameters. For instance, the
user decides that "09/09/99" will mean "this item is obligated but not
committed in this FY". Then they can run a report for all records containing
this date to extract the "obligated but not committed" items. At least three
of these apps even have "status" fields to store a code for this type of item
("O"bligated, "C"ommitted, "P"aid, whatever) and the users do their cute
tricks with dates anyway.
Sometimes this misuse occurs when the user doesn't know (or doesn't want to
bother with) the correct value for a required date field -- they have to
enter something, so they put in "01/01/01" (the one I've seen most often) or
"09/09/09" or "09/09/99". I built an inventory app with a required "Delivery
Date" field; when that app went into production a complete physical inventory
of the facility was required -- there was no existing inventory. The person
who did the physical inventory didn't want to bother matching up PO's from
dozens of branches, so he frequently entered a delivery date of "01/01/01".
This was in 1995, and I asked him what he would do when we actually got to
Jan 2001 -- even though the display (and the stored value) was "2001", he had
assumed he was entering "1901". Once he got that straight, he firmly asserted
that "all of that stuff would definitely be gone long before then"... even
though more than half of that "stuff" was 10, 15, even 20 years old at the
time. Later on, he wanted me to remove the validation check on other date
fields -- it annoyed him to keep getting warning messages like "Disposal date
is earlier than Delivery date -- do you want to edit?" (I didn't disable it
<g> ). His successor was smarter; when we added another building to the
inventory, he used "01/01/80" (at my suggestion) for items he didn't want to
track down. But he wouldn't authorize me to modify all the existing
"01/01/01" records. When I left 18 months ago, there were still about 500
(~10%) active records with "01/01/2001" delivery dates.
About 6 months ago, the xbase data was imported into a "compliant" Oracle
inventory app -- I don't know if anybody still working there knows about those
"01/01/2001" dates.
--
Pam
Unofficial c.s.y2k smallish FAQ
http://www.computerpro.com/~csy2kfaq.html
Ralph Daugherty
On Wed, 10 Feb 1999 04:51:22, hoff_meister <hoff_m...@my-dejanews.com>
wrote:
> Cory, could you explain how a 9's card could lead to a 9/9/99 date? Or
> for that matter, the other problem date of April 9?
>
> I'm assuming this must be a problem in some systems, but I haven't been
> able to figure out just how this happens. How does 999999 translate to
> 990909, or 090999, or for that matter 99099? Like I said, I've been
> trying to envision how this would happen, and just haven't been able to
> figure out any likely scenarios.
>
> Hoffmeister
Hoffy and Egan,
Here's a record;
1...v....1....v....2....v....
123197HOFFY JOE
090999EGAN SAM
999999EOF EOF
/* nosubstringrange */
dcl 1 record,
2 date,
3 month char(02),
3 day char(02),
3 year char(02),
2 lastname char(10),
2 firstname char(20),
call readrec();
if substr(record.date.day, 1, 3) = "999" then call doeof();
call processrec();
Hmmmm, Sam Egan's data doesn't get processed.
Sure, this isn't likely but there is no doubt that this code is out
there.
In fact, they might have defined the EOF signal as 09/09/99 because it
does pass a reasonable date check while 99/99/99 might be rejected.
Will this problem occur in production systems somewhere? Absolutely.
Is it common? I'd guess not but I don't know.
Can it be fixed on failure? Depends on the expertise in the shop, do
they have the source? Will they notice the problems? How long before
Sam complains about lost data.
I get back to the 50,000 IBM style mainframes and millions of legacy
systems. COBOL (and assembly language, RPG, DYL-260, MarkIV,
Nomad, PL/I, and hundreds of other languages and databases) runs the
world.
This stuff is at risk. What ever it does, it will do it differently
after the singularity.
Well, lunch is over, back to work.
cory hamasaki 324 Days, 7,788 Hours, Less than 11 Months.
Cory, programmers who didn't have EOF capability sure as heck didn't have
substrings. Furthermore, what kind of loony programmer defines a field as
char(2) and then substrings 3 positions from the start of the field of length
2? Let's not get too convulated here. Fields were set to all 9's and
compared to all 9's. Sometimes the field was a 2 digit year, most of the time
it was a 6 digit date, but it wasn't that complicated. Neither the
environment nor the programming sophistication in a 9's substitution for EOF
situation lead to expectations of seeing your example code floating around out
there. There is data out there with expiration dates of 9/9/99, but whatever
9's problems there were in the code has now been encountered, remediated or
fixed on failure, and life has moved on. To bigger and better things. Last
one in pull the dozer 'cross the road. :)
Ralph
Roland Teigen
somewhere. I would say I don't think it will be *common*. My guess is that it will be as common
as JAE's, some of which we will never hear about. The real question currently I think is,
can Japan, Canada and New York State keep a lid on problems they encounter as a result of April 1,1999
being their FY2000? Thoughts anyone?
Ralph Daugherty <ra...@ee.net> wrote in article <36C33FAF...@ee.net>...
Bradley K. Sherman
Roland Teigen <rol...@lexis-nexis.com> wrote:
> ... My guess is that it will be as common
>as JAE's, some of which we will never hear about. ...
Have we heard about *any* JAE's yet?
--bks
Ralph Daugherty
accounting systems. None of the news about New York's systems have been very
good, but we don't know about their accounting systems. The fiscal year 2000
is a real Y2K problem that happens to start in 1999, unlike any of the stuff
below. My opinion is that fiscal year accounting systems have either been
remediated or they haven't (safe statement, heh?). There's no middle ground
or fix on failure to it. Technically, since the OMB requires all Federal
government systems to be done by March 31, the status of the FY accounting
systems as separate items wasn't supposed to be an issue. In reality,
organizations should break out the statuses for accounting systems and state
up or down whether their accounting systems have been remediated and placed
back into production. Not "we'll be ready". Have they finished or not? Are
they ready for fiscal year 2000? I won't be surprised to see several
organizations push the start of the fiscal year back this year as an
accounting rule change.
Ralph
P.S. You're too kind to Cory. Any of us can dream up stupid code
examples. Hoff asked for a real world example of a 9/9/99 used in code and
how it could in any way be confused with all 9's. He got none. Instead of
just admitting this is an old wive's tale, it keeps getting propped up with
"anything can happen" scenarios bacause none of us has seen but a minute
fraction of all existing code, therefore who knows what man hath wrought. I
know that the code example Cory dreamed up needs more than remediation. It
needs a proper burial.
Roland Teigen <rol...@lexis-nexis.com> wrote:
I think Cory's point is well taken. There is no strangeness in code that
hasn't been done
somewhere. I would say I don't think it will be *common*. My guess is that
it will be as common
Lane Core Jr.
<egan263@nospam_allowed.ix.netcom.com> wrote:
>Thanks Lane.
You're welcome.
>While I find the 9/9/99 situation astounding, I -have- seen equally
>ridiculous examples in production code, so it wouldn't surprise me. I
>still feel that this is a much rarer occurence than 12/31/99.
>
>Your article should put this thread to rest.
Well, we seem to get a new one every few weeks.
Moshe Shulman
>In article <01be5609$8ed264c0$3523...@cteigrc.lexis-nexis.com>,
>Roland Teigen <rol...@lexis-nexis.com> wrote:
is that
>it will be as common
>Have we heard about *any* JAE's yet?
Yes, but they have been handled without any serious impact on the
general economic fabric of society.
Moshe Shulman
>>Cory this is just poor programming as it just doesn't make sense.
>>You
>>have to be an idiot to do that.
>Makes about as much sense, as those using 6 digit dates less then 10
years
>ago.... but naaaaaaaaaa...only an idiot would do that....
No whit, 6 digit dates were not only logical, but had sound reasons
at that time. That there would be a future problem is another issue.
Y2K Whit
why I always say I'm not a *real* programmer. Ralph, not all programmers
followed guidelines and did things by the book. Especially since much of what
was being written/ created was non-exsistant at the time. There are many
different kinda people out there, and back then - many computer folks learned
as I did, by pushing buttons - not by reading instructions. Cory was trying
to give an example of bad code, he did well.
This whole 9/9/99 thing bothers me alot because it's like having something on
the tip of your tongue and not being able to articulate it. I remember very
clearly working with a database system in the early 80's where you COULD NOT
use bogus dates, as all the real programmers here seem to have used (99/99/99)
the system I was using .. wouldnt have ALLOWED 99/99/99, because of idiot
proofing I'd used. a month over 12, a day over 31 .. just wouldnt be allowed.
The latest possible date I could have used to reflect anything would be
12/31/99 .. but I'm a lazy typer .. so 11/11/99 or 9/9/99 would have been what
I entered. Folks here keep saying that translates to 09/09/99 but it would
have in the code I was using. 9/9/99 = 9/9/99 in the code *I* used then. It's
been SOOOOOOOOO many years and so many things have gone on in my life, I just
can *not* explaine exactly how or why - all I know is it had to do with the
idiot proofing I used back then.
The only thing I can assume here .. with all the REAL programmers - is that
they didnt idiot proof their code, translating into hundreds of thousands of
user errors since then .. ie they are allowed to transpose the dates so that
21/41/80 ... would have been a valid date... as would (I keep hearing here
99/99/99) had they transposed 12/14/80 on something I'd worked on .. it'd
popped up with a screen that says "NOT A VALID DATE - TRY AGAIN BUCKO" or
something to that effect "FUCK THE BEAR" comes to mind.. (inside joke)
Anyhow - I guess I just have to assume that I was the only one who did this
sorta thing back then...
Personally I'm not worried about 9/9/99 because most programmers seem to think
it is a non-issue... I think the amount of variation will cause it all to just
sorta blend in (ie those who used 11/11/99 .. or 12/31/99 ...etc) I was lazy ..
so 11/11/99 worked for me.
I really can't see any of those dates being a national or global issue however,
it'll just be another smoke screen for the pollyannas...99% of programmers say
- it wont be an issue, but they'll use those few who predicted it , to somehow
prove that y2k wont be a problem...
Whitney
David K. Bryant
>Get over it people; the world does not run on eBay, it runs on legacy
>iron, 50,000 IBM style mainframes, 500,000 AS/400s, 100,000 S/3xs, and
>who knows how many VAXen, PDP-11's, and DGs.
Let us not forget Wang VS. It's surprizing how many
are humming away, without maintenance or admin, in some
small office around the world.
Even in your native Hawaii the county clerk keeps the
property records on a Wang.
Two thirds of the public housing authority offices run
on a Wang.
Used to be that 40% of law offices, you guessed it.
Unfortunately, the clueless are in charge now.
The LANs are invading. R-R-U is the law of the land.
(Re-boot, Re-Load, Upgrade)
steve
->In article <01be5609$8ed264c0$3523...@cteigrc.lexis-nexis.com>,
->Roland Teigen <rol...@lexis-nexis.com> wrote:
->> ... My guess is that it will be as common
->>as JAE's, some of which we will never hear about. ...
->
->Have we heard about *any* JAE's yet?
How many companies have started their FY already?
Here's hoping it's not going to get as bad as I
think it's going to get...
Visit http://www.bright.net/~fixit/ to see what I do ->
(note the url for my proper user ID)