Cory,

I have read and enjoyed your posts. You have a keen sense of humor and they are always entertaining. However, they are not very informative. You sometimes give examples of possible trends, such as the info you got from the blone chick about her and her boy friend bugging out and taking a world boat tour to get away from Y2k issues. Again, this is very entertaining but does little to inform anyone about Y2K issues.

You say that you have been a "big iron" programmer for a couple of decades and a active member of the Y2K DeeCee group. With your credentials and contacts you should be in a good position to obtain inside info about what's really going on with Y2K. How about sharing some of the inside scoop with the rest of us? For example, I'm not asking you to violate any NDA you may have signed. However, I'm asking for concrete examples of Y2K glitches. What do you say Cory, care to share any gems with us?

-- Watcher5 (anon@anon.com), June 18, 1999

Answers

Watcher5:

Hey, give Cory some slack. He's a hard worker. Be patient.

-- Randolph (dinosaur@williams-net.com), June 18, 1999.

Gartner Group says y2k "begins" next month. Stay tuned.

-- a (a@a.a), June 18, 1999.

I'm not cory but I am a computer programmer. I've been hired for the summer by a local firm that produces predictive models of the stock market. This is an example of a y2k bug that I found in the code I was working on. The program had to read from two files, one where the date was saved as one number in the format yymm (where 8512 == December 1985) and the other one was saved in the format mmyy. The program assumes that the proper format for dates is yymm. A conversion code looks through all of the dates read in from the files and then applies this test.

if( yymm < 5000 ) { //Switch mmyy to yymm //e.g. 1285 becomes 8512 //or 0001 becomes 0100 }

This is not how all y2k bugs look, this is just an example

So what? you may ask. The date got a little screwed up. No big deal right? Well...maybe, maybe not. If all the date routine does is print the date to the screen or to a printer then the flaw in the code is really no big problem. The output looks a little funny and thats about all. -BUT- If the program does any operations at all involving the month or the year then there is a problem. For example, Suppose the program has month specific tasks.

let month equal some number between 1 and 12 if(month == 1) //Do something else if(month == 2) //Do something else

Now, if month == 0 what happens? I don't know, the program may crash, return garbage answers, important jobs go undone, nothing good.

Or a problem may occur with the year. Suppose we have two files. One is full of all current files < 5 years old (Call it CURRENT) the other is full of all files > 5 years old (Call it ARCHIVE). five_yrs_ago = 95; data_yr = 1; //from our example above

if(data_yr < five_yrs_ago) //send data to ARCHIVE else //send data to CURRENT

Any program (or any human for that matter) that needs the file will not find it in CURRENT where they expect it to be. Once again, nothing good will come of this.

Hope this helped.

Oh, BTW when I showed this section of the code to my boss, I asked him what he wanted me to do about it. "Oh, just flag it and fix it later." Later? sigh.

John

-- John Ainsworth (ainsje@cstone.net), June 18, 1999.

Check the thread about VSAM catalogs in bit.listserv.ibm-main, especially the posting by Gil. I raised this issue a year or two ago in comp.software.year-2000.

I copy-posted part of the current VSAM catalog thread to comp.software.year-2000 yesterday but for some reason, there were not a lot of responses.

You can also hit www.IBM.com and download a 400 page manual that details the serious technical issues.

Lots of good info there. If you have specific questions on any of the issues in the IBM manual, drop a note here or in comp.software.year-2000 and I'll be glad to rap with you.

-- cory (kiyoinc@ibm.XOUT.net), June 18, 1999.

Following up. I hadn't seen that kind of "auto-sensing" software before but I'm sure that there are other examples out there. This is especially bad because this is the kind of problem that might run for a long time, produce incorrect results, corrupt databases, and when it's finally found, it will take months of reprocessing to fix.

The IBM Year 2000 manual is based on IBM's experience and has been updated on a regular basis. It is a standard reference. While someo of the issues only apply to specific systems, it contains general information and a executive summary that is well written and very accessable.

Any doubters, pollys, broomies (a broomie is someone who is sweeping the Y2K problem under the carpet.) should review the IBM manual before making 'sweeping' statements.

I've lost track of the pollys here (or I'd make rude noises in their direction.) but their argument is really with the IBM Year 2000 manual and not Ed Yourdon, me, a.a, or any of the "awake at the switch."

Gotta run. My status reports are late, I have donuts to eat. See you all at Sam's Club, I'll be the one pushing the flat with cans of ham, beans, rice, molassass.... say, this sounds like a great recipe.

-- cory (kiyoinc@ibm.XOUT.net), June 19, 1999.

here's a post from Cory (some time ago in C.S.Y2K) that I saved.

It's just a simple little example, but I found it useful in understanding how the data output of a Y2K "glitch" can be so bizarre:

begin quote:

-------------- a fun little Y2K program ------

/* yy.cmd - demo rexx */ /* Records expire on the next anniversary date */

a.1 = " 12/15/98 Record 1 " a.2 = " 03/03/99 Record 2 " a.3 = " 06/15/00 Record 3 "

do j = 1 to 3 parse var a.j ddate cmt parse var ddate mm "/" dd "/" yy

yy = yy + 1

say cmt ddate ", renew on " mm || "/" || dd || "/19" || yy

end /* do */

---------- This is the output ------------

Record 1 12/15/98 , renew on 12/15/1999 Record 2 03/03/99 , renew on 03/03/19100 Record 3 06/15/00 , renew on 06/15/191

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

It's interesting that record 2 and record 3 fail in different ways. How many systems will truncate 19100 to 1910 or right justify 06/15/191 to 06/15/ 191.

This sample is not important if intelligent people read the output. If the output records are passed to another computer program, that program will misinterpret the data, and pass even stranger results to the next program in the series.

Cory Hamasaki 906 days, 21,752 hours now.

End Quote

-- Plonk (realaddress@hotmail.com), June 19, 1999.

Someone I know well works at a mid-size insurance company here in the TwinCities and the company can hardly keep their computer system up for 3 hrs. straight. They did a whole bunch of Y2K work (touted as fixing everything) and it only got worse. Also, where are those 2 lists (36 p. total) of failures I saw a while back? CH's site? www.y2ksafeminnesota.com

-- MinnesotaSmith (y2ksafeminnesota@hotmail.com), June 19, 1999.

Don't if this is what you're looking for, but here's Y2K glitch LINK

-- Sandmann (Sandmann@alasbab.com), June 19, 1999.