This link takes you to a page showing 78 different Y2k bugs from web pages. Includes examples of bugs on Navy web site and Netscape web site. Some really weird dates.

http://www.bregt.com/y2k/

-- Brian Bretzke (bretzke@tir.com), January 06, 2000

Answers

Geez...all that and the Mobil speed pass not working in No. Va. It really is happening. Think I'll have a can of tuna and clean my gun.

-- Chris Karcher (lmcmurtry@dove.com), January 06, 2000.

Chris, Put your gun away. You won't need it for a while, if at all. What you will need is patience and objectivity while we watch this thing play out.

-- JoseMiami (caris@prodigy.net), January 06, 2000.

Web pages get the date wrong. Just goes to show you that when you let just anyone near a computer they make mistakes. Building web pages is nothing like programming a computer. Have any mainframes come up with problesms yet?

Now wouldn't it be interesting if the calenders on all of those web pages had been stolen from each other (along with the error?). NO BIG DEAL. Web pages mean nothing, especially when a lot of them are created by "web builders" (programs or templates) that the errors may have from.

-- Cherri (sams@brigadoon.com), January 06, 2000.

A lot of Web pages are written on UNIX (or some variant) machines, and some of these pages show the year as 100 or 19100.

The "100" problem happens because of an improper use of the UNIX "year$" call. When called, the function properly returns the number of years since 1900. When improperly used, it is ASSUMED to always give a two-digit result. At least, it always did before now, right?

The proper way to use year$ is to display the result of the mathematical operation "1900+year$" to get the full year. The improper way is to use year$ by itself (gives 100) or the concatenation of "19" and year$ (gives 19100).

These aren't bugs in UNIX, just sloppy programming. Documentation for the call is clear but programmers didn't bother to read it. A few web page authors, who thought they were clever, changed the concatenated "19" to "20" about midnight. This gave us 20100.

-- Gary S. (garys_2k@yahoo.com), January 06, 2000.

Have any mainframes come up with problesms [Sic] yet?

Cherri, in case you missed these:

Subject: I can't believe this: Dfhsm Audit Y2K critical problem Date: 6 Jan 2000 02:53:53 GMT From: kiyoinc@ibm.XOUT.net (cory hamasaki) Organization: HHResearch Co. Newsgroups: comp.software.year-2000 References: 1

It might be the flu affecting my (limited) ability to reason but aren't we seeing more than a few system level Y2K problems in the mainframe world? How could people have tested for a year and not encountered things like this?

I make this -4 Days and we've seen several problems with archivers and schedulers.

The most popular scheduler for mainframes (kind-a a big boy's Chron) is CA7. CA7 has a Y2K problem discovered only two days ago. This hasn't made the newsgroups yet but I ran into it while rejiggering jobs to make the batch window. So that's my Y2K contribution for the day.

I understand "Y2K is Over", "Y2K was a Big Nothing" and even "Waaaa! Milne called me a butthead so I'll take a couple cheap shots now that I think Y2K is over." but DFSMS is used by thousands of mainframe shops. It is a key part of enterprise storage strategy.

These kinds of systems are fundamental in the mainframe world.

Whatever, I don't care that the pollies think I'm clueless, I'm starting to think I'm clueless. I never expected multiple problems in storage management.

JUrlaub@MICROAGE.COM (Urlaub, Jim) wrote:

> Ref: apar OW42602 > > For all DFSMShsm users, IBM just posted an alert regarding data > loss if you perform an "AUDIT DIRECTORYCONTROLS VOLUMES(vvvvvv) FIX" > (where vvvvvv is an ML1 volume). This will result in the > deletion of the vtoc copies on this ML1 volume that have been > created in year 2000. All vtoc copies created prior to year > 2000 are not affected. Migrated datasets are not affected either. > > Sample errors that I encountered under DFSMShsm 1.4.0 are: > ERR 144 HSML1A - HSM.VTOC.T170119.VPSYS05.D00003 NOT IN P RECORD FOR PSYS05 > ERR 141 HSML1K - SCRATCHED EMPTY DATA SET HSM.VTOC.T311118.VSMSN01.D00003 > > A patch fix is now available for 1.3 only. > Nothing yet on 1.2, 1.4, or 1.5.

How can this be? This is what? The second, third, fourth, general mainframe problem we've seen? Didn't anyone test this?

And yes, Polly Moshe might be right again. They already have a fix for 1.3, the others will be along real-soon-now.

Why would I believe that there was anything but the most cursory testing done? Someone please crosspost this to TB2K. Ed Yourdon could use a good laugh.

cory hamasaki I'm heading for bed, sleep for another 10-12 hours. I'm taking a can of coffee with me. This morning I struggled to get up. I'm hoping that if I can wake up enough to drink the 6 oz can, I'll be able to get out of bed in less than an hour, then drag myself in to fumble around doing whatever clueless thing it is that I do when I'm not watching Baywatch. 

-- (casper@ghost.spook), January 06, 2000

------------------------------------------------------------------------------------------------------

Or, maybe this Y2K alert on IBM's website has nothing to do with mainframes?

DFSMShsm: Do not run the AUDIT function with the FIX parameter until further notice

-- (RUOK@yesiam.com), January 06, 2000.

Things that make you go "hmmmmmn...."

-- Robert A Cook, PE (Marietta, GA) (cook.r@csaatl.com), January 06, 2000.