I've written hundreds, and have worked on thousands of programs in the past 31 years. I get paid for my hobby. Mainframe, PC, Black Boxes, lots of ASSEMBLY (machine language), fair amount of COBOL, assorted other languages. I started on punched card equpiment, and have been fortunate enough to have seen more "sides" of the computer business than most "experts". Just wanted to introduce myself. . So, where do I stand on Y2K? Let me tell you what I think I know. True, many if not most programs (ie. software - be it on a mainframe, PC or "embedded system") do NOT use any date "functions" at all. Those that do sometimes only use it only to display or print. None of the above is, itself, a Y2K problem. We all know what 01/01/00 is. So we are left a "small" percentage of programs that use the date in some sort of calculation. You wouldn't believe the number of ways a programmer can "play with" a date. I've seen dates in YYMMDD format (so it sorts nice), converted to binary, and compressed to 2 bytes. I've seen the YY part "float" in a transaction code. Of those programs that do date calculations, most are very dependant on the date. These programs must be updated, and possibly moved to "Y2K ready" hardware. However, this is only the tip of the iceberg. . Even programs that have no date functions must have input data, and some sort of output. Existing "master files" may need to be updated ("windowing" sometimes helps here). If a file has a date field that has been expanded, then ALL programs that access THAT file must be updated, EVEN IF THEY DON'T USE THE DATE! Many modern data-base systems can do this for you. However, it's the old "flat file" format that is the problem. This is, by far, the format of a vast majority of all existing computer files. In a well designed system, this type of update may be as simple as re-compiling the program, using an updated "copy book", assuming things like the source code and compiler can be found. None of this is all that involved. It's the NUMBER of files, and their relationship with other files, and other programs, and other computers than concerns me, not to mention the amount of "front end" work that must be done just to identify files and programs and hardware that need work, and "back end" work to see if it all works! . I work for a computer service firm. Our biggest client has been with us for 17 years, and makes use of dates more than most. They used to do batch updates on the mainframe. About 10 years ago we installed a PC based LAN for them, and wrote CLIPPER programs for their update system. The production, 300+ custom written programs, (reports, composed books, questionaires, and lately CD-ROMs, etc.), is still done on the mainframe. Most programs would need some, from very minor to very major, Y2K work. We were honest with them: we didn't think we could do the job on time. That was summer, 1996. As a result they gave us the OK to "throw it all out", and develop a NEW system, using "state of the art" development tools. It started out as a Windows based GUI, but soon changed to Web based. Using a fair amount of off-the-shelf software, but still requires MUCH custom code. It's keeping 6-7 developers, 3 support people, a couple of managers, and 1 mainframe/network administrator (me) very busy! We'll still use the mainframe for their 1999 "rush", and hope to have the "new technology" ready for their summer 2000 production. We are lucky. We know their data and products better than they do! We are also lucky that we have a very good relationship with this client. They understand that they have to work with us, and they understand that they may have a less than perfect system in 2000. We figure it will take about 2 more years to give them everything they have now. They are paying us top rate for development of the new system, much more than their annual maintenance and production fees to us. They also understand what the result would have been, had they paid us to attempt to patch the old system. We are all very lucky, and I think the exception. This is ONE of our clients. Like i said, it's the NUMBER of ... . So where do I stand on Y2K? If the bump is a 1, and Gary North is a 10, I think I'm at about 6.5 - much better than the 9 I was a few years ago!!! Now, if they could only get working on that damned grid ...

-- Sysman (working@it.com), February 04, 1999

Answers

Thanks for the insight.

-- Watchful (seethesea@msn.com), February 04, 1999.

My concern is that the world is already on a "slippery-slope".

* Any "yutz with ears" (and money) can be a terrorist.

* Due to currency not being based in anything tangable, "implosion" is a very real threat. Asia and latin-america have had many "bad hair-days" already.

* There are on-going religious and idealogical wars which are getting hotter.

* Just-in-time manufacturing (bad when supply is interrupted).

Although most stuff will work (mine included, of course), a lot will not. Even the smiley-face types like Koskinen warn about things like rail-distribution and "developing" countries. The world is moving very fast, and sh*t happens. Given the current "debt crisis", the failure of desalination plants in the middle-east, and numerous business failures (Brazil, China, Russia, Italy, etc.), things could "destabalize".

I am actually excited about things like cures for cancer, artificial- intelligence, new sources of energy and anti-gravity (new propulsion source). All of these items are covered in respectable journals (although anti-gravitiy is still more of a dream than anything tangable). *IF* population growth can be controlled, the global standard of living could be made quite high.

...but right now, things are fragile. A small Y2K problem might be the "straw that breaks the camel's back".

-- Anonymous99 (Anonymous99@anonymous.com), February 04, 1999.

I certainlyu hope people read the WHOLE post and don't stop at the part about not using dates much. Glad you commented in the need to attack EVERY program that touches a piece of data with an expanded date. I am familiar with a couple applications that pick up an IMS segment, define the whole thing as filler, and start working on different parts of the segment with multiple, layered redefines. If someone change the date field, and someone else doesn't know, then the data will NOT be correct and the machine (or the suystem) will come down. This system also does some fantastic things with pointers and calculation thereof for faster access to data, so if the date is part of the key, . . . . . . .

Chuck

-- Chuck, night driver (rienzoo@en.com), February 04, 1999.

Good background info, thanks.

Notice anybody the substantial difference in the "body" of evidence stated indicating complexity - but solvable given enough time and talent. The troll alarms won't include this type of analysis, and will assume glibly that because this company analyzed and prepared, all have been blessed with equal foresight.

But notice too that there is a substantial amount of work remaining, requiring "two years" more effort.

-- Robert A. Cook, PE (Kennesaw, GA) (cook.r@csaatl.com), February 04, 1999.

I appreciate the time you took to give understandable viewpoints and descriptions. You've contributed some valuable information to the forum.

-- Mr_Kennedy (y2kPCfixes@motivatedseller.com), February 04, 1999.

The guy in the next office is a CLIPPER and Dbase man from way back. He wants to know two things - why would your programs not run under the newer programming systems - lots of old Dbase and so forth programs just open a window and run fine under Visual Dbase, MS Visual Foxpro 6.0, etc. And second, he wants to know if you have ever heard of the command SET CENTURY ON. According to him, it makes Dbase language programs Y2K compatible. Don't ask me, just passing on what he told me.

-- Paul Davis (davisp1953@yahoo.com), February 04, 1999.

Paul, Your friend is correct on both counts. CLIPPER programs are less of a problem than many other languages. Our problem isn't with any specific language, but with the file structures. These files had 2 digit dates in several hundred locations, including sort keys, and transaction types. The clipper front-end would have required some work, but nothing compared to all those back-end flat-format files on the mainframe! This system has been thru many years of annual updates, additions, and bug fixes, with many programmers working on it. It had grown into an out-of-control pile of spaghetti code, becoming very hard to understand, and maintain. This helped in the decision to start from scratch.

-- Sysman (working@it.edu), February 04, 1999.

Sysman brings up the point that so many miss: Y2K is more than just a hardware, operating system software, or even application software problem. Its also a huge data problem! The best analogy that I ever heard (from Jim Lord's writings over at www.y2ktimebomb.com) is to think of it like a huge multi-layered cake. The bottom two layers represent the hardware and operating system -- and are very skinny. The next layer is a few times larger, and represents applications. But the top layer is many times the size of all the other layers combined, and represents data.

Most people just focus on the bottom two layers (as in "My MAC is AOK-Y2K"), a few understand the importance of the third (e.g., CLIPPER), but then there is All That Data.

Y2K CANNOT BE FIXED.

-- Jack (jsprat@eld.net), February 04, 1999.

Good analysis, Sysman.

I'm an ex Clipper programmer, now in Microsoft hell because Nantucket and Computer Associates dropped the ball with Clipper/Visual Objects.

Anyone using any applications in Excel, Access, Visual Basic -- even recent ones -- you are very likely to have date problems. Test, if you can.

-- vbProg (vbProg@microsoftsucks.com), February 04, 1999.

To paraphrase a saying, "ITS THE DATA, STUPID!".

-- RD. ->H (drherr@erols.com), February 04, 1999.

Thanks for some feedback everyone. Lets see, yes, it is the data, AND programs, AND hardware... I like the ONION better than the layer cake: the core is small and powerful, and each layer gets bigger and thicker... FILLER X(6) should be FILLER X(8)... etc. I'm impressed - I didn't get much Flame or Trolling on my post! Off to <== ...

-- Sysman (working@it.edu), February 04, 1999.

And the onion makes you cry when you cut into it.

-- Wiseguy (got@it.com), February 04, 1999.