I've been thinking over the y2k problem for the last 3 or 4 years now, and I have two concepts that I'm trying to figure out.

First, as the date is represented using two bytes, and each byte represents 8 bits, that is to say eight 1s or 0s, that makes 256 combinations per byte, and roughly 64,000 combinations for the pair. As only 100 of these combinations are used by current dating methods, why can't the date expand within those 2 bytes to allow use of a separate machine-dating method in which the digits are represented in higher bases, such as hexidecimal, or base 256, for that matter? That would at least extend the deadline.

Now, here's the second part of my thinking: the problem I've come up with for the first part is, one would still need to find every occurrence of the date in the code, and thus one has to search through thousands and millions of lines of code. However, what if we could make the dates jump out and expose themselves automatically by setting up a system with a year of 55 or so, then observing all the pairs of bytes in which 55 occurs, then eliminating all non-55 byte pairs, changing the date to 60, and checking for occurrences of 60, eliminating all non-60 pairs, and continuing this process until every non-date related byte was eliminated, leaving only the date related bytes. Then the afforementioned redating could be applied to the pairs of bytes remaining, leaving the computer knowing that after 99 comes "##" for example, or "^^", and being able to pass mathematical functions over these new numbers. Get it? If you know what's wrong with this plan, please clarify for me. Thanks. (And if it is workable, please forward it to the proper authorities....:) )

Tom Kessler

University of Kansas

-- Tom Kessler (MagicClams@hotmail.com), November 30, 1998

Answers

Biggest problem is exchange of data with y2K compliant systems - re-converting their "good" output to the proposed notational output/input.

Also with the "simple" conversion (converting between modules in different formats) within the same program - might in many cases be easier/more reliable to fix it correctly.

Third is to maintain exchange criteria with "old" current programs - some of their data is essential to maintain - and so some has to be converted to notational, some to 4 digit dates, some to 2 digit dates.

My opinion - better to do it right, save it, , test it, save it, load it, run it. Go to next program.

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), November 30, 1998.

Tom, I giving some thought to this myself. But I keep coming up with the same conclusion.

On the first part...

An easier approach would be to pack the 2 position year

You are right that there are 8 bits to the byte. In hex the represention of a number in character format is F1 for 1, F2 for 2,....F9 for 9. The first four bits comprise the F (0110) and the second comprise the number. For example the hexidecimal representation for the number 1 is 01100001.

Packed fields need not carry the F denoting character. Only the significant digit. Therefore, a single byte could carry 2 digits in packed format instead of 1 digit.

So, in a 6 position date field with the date of 010100 (Jan 1, 00 in mmddyy format) stored you could put an 8 position date.

0110 0000 0110 0001 0110 0000 0110 0001 0110 0000 0110 0000 (hex representation of 01/01/00)in a 6 byte field using character representation in all bytes. -------------------------------------------------------------- 0110 0000 0110 0001 0110 0000 0110 0001 0010 0000 0000 0000

(hex representation of 01/01/2000)in a 6 byte field using character representation in all bytes except year.

The problem is that this is the kind of stuff that got us in this mess to begin with. Its not a standard representation. It would work ok in a closed system, but you start to run into trouble big time if you are passing this date to another system expecting something else. Changes need to made anyway! The only thing you have saved is 2 lousy bytes. AND a lot of date fields are packed anyway!

The ANSI standard for dates may have been screwed up by eliminating the century, but at least it is a standard by which MOST systems are written. And its too late to develop new standards based on manipulating bits to save a couple of bytes.

On the second part. Hard coded dates in programs are a big problem. Not only do the data descriptions need scanning but the procedural parts of programs also. AND data bases would have to been scanned and converted no matter which approach is taken.

If any gearheads out see a problem with my Hex...keep it too yourself. LOL

MVI

-- MVI (vtoc@aol.com), November 30, 1998.

Pretty good points, I think, especially about the digital packing, and the repercussions of miscommunication between systems, but I considered this more a contingency plan than a first line of defense. As such, I agree that plowing through the numbers is a better idea, but in absence of a solution, isn't digit packing better than total meltdown? :) Anyway, I'm still thinking about what you said on the second point, and I'm not sure I follow. I have a program which can be used to scan memory areas in an arcade game for a number, n, such as the number of lives, or whatever, and return all occurrences of that number, then, when all the occurrences have been tabulated, if you kill yourself, then search for (n - 1) among the previous memory locations, you'll find a smaller number of matches, and after killing yourself and searching for (n-2), you'll probably have the final value. I don't see why a similar procedure can't be run in an active mainframe. If you can explain further, please do.

Tom

-- Tom Kessler (MagicClams@hotmail.com), November 30, 1998.

Tom, you would only find occurances of literals in the program. Things like hardcoded 'windowing'. Example

IF YEAR LESS THAN OR EQUAL TO 99 MOVE 19 TO CENTURY.

This would tell you that you have a year field called YEAR and a Century Field called CENTURY in the program. It would also tell you that you have most likely uncovered a 6 position date field. But there could be 200 additional 6 position date fields left unidentified. Fields that are being manipulated, changed, reformated etc. with no discernible reference to them.

Programs are in use to scan for date candidates. And they are useful, but are no substitue for a line by line review by a human.

Keep in mind that unlike the game, These programs are accessing data bases which are external to the program, infinite in size, and constantly changing. The programs must be changed. The data descriptions must be changed. The data dictionaries must be changed. Programs must be written to convert the data bases. And the data bases must be converted.

I hope this helps. Difficult to explain this stuff sometimes.

MVI

-- MVI (vtoc@aol.com), November 30, 1998.

Oh, and one other thing. The databases could be accessed by an infinite number of programs, with each program making changes to the databases.

-- MVI (vtoc@aol.com), December 01, 1998.

Roflmao, I hosed the hex..

should read:

An easier approach would be to pack the 2 position year

You are right that there are 8 bits to the byte. In hex the represention of a number in character format is F1 for 1, F2 for 2,....F9 for 9. The first four bits comprise the F (1111) and the second comprise the number. For example the hexidecimal representation for the number 1 is 1111 0001.

Packed fields need not carry the F denoting character. Only the significant digit. Therefore, a single byte could carry 2 digits in packed format instead of 1 digit.

So, in a 6 position date field with the date of 010100 (Jan 1, 00 in mmddyy format) stored you could put an 8 position date.

1111 0000 1111 0001 1111 0000 1111 0001 1111 0000 1111 0000 (hex representation of 01/01/00)in a 6 byte field using character representation in all bytes. -------------------------------------------------------------- 1111 0000 1111 0001 1111 0000 1111 0001 0010 0000 0000 0000

(hex representation of 01/01/2000)in a 6 byte field using character representation in all bytes except year.

Doh!. I'm glad I reread this.

MVI

-- MVI (vtoc@aol.com), December 01, 1998.

Tom,

Advice from a graying-haired veteran of mainframe programming:

Don't get caught up in cute little bit-and-byte "solutions".

There are dozens or even hundreds of different algorithms for Y2K date/time calculation/storage/manipulation. It's fun to contemplate the merits of different algorithms. BUT choosing the optimum one ISN'T WHAT'S IMPORTANT!!

What Robert wrote - may be dull, but THAT is what's important.

By this time (December 1998), what's important about Y2K program-fixing is to put in *correct* algorithms, no matter which ones, that satisfy all the interface criteria, test them to make sure they work and that nothing else breaks, carefully and correctly integrate them into the production environment, and move on to the next program in order of priority. Dull, dull, dull -- but important.

The experience of major corporations seems consistently to be that the testing phase of Y2K remediation takes at least 50% of the total time. Think about that. All the earlier phases - awareness, inventory, planning, design, coding, documentation, ... - add up to _no more than 50%_ of the total time, according to actual experience.

The number one consideration now is to use the remaining time efficiently. That means getting it right the first time, so you don't have to repeat the testing. That means coding in a straightforward, non-tricky, reliable manner. That means prioritizing what needs to be done, recognizing that it's too late to fix all the Y2K problems. That means working on software in priority order.

>why can't the date expand within those 2 bytes to allow use of a separate machine-dating method in which the digits are represented in higher bases, such as hexidecimal, or base 256, for that matter?

This means "tricky" code.

It is more important to use straightforward code than "tricky" code.

Some of the Y2K problems were _CAUSED_ by TRICKY CODE!! Think about that.

>That would at least extend the deadline.

The ideas you propose will not save any time, which is the most critical shortage in our Y2K mess. It will take roughly the same time to implement your proposals as it would to just code straightforward, non-tricky Y2K-ready fixes, so there's no advantage worth the risk of the trickiness of cute bit-and-byte proposals.

When extending a deadline will take the same time and effort as solving the problem, why not just solve the problem instead of extending the deadline for solving it?

>If you know what's wrong with this plan, please clarify for me.

1. The plan involves "tricky" code. 2. The plan saves no time, compared to straightforward coding. 3. Since the plan has no advantage in time-saving to offset its disadvantage of "trickiness", there is no good reason to use it.

> I have a program which can be used to scan memory areas in an > arcade game < snip > > I don't see why a similar procedure can't be run in an active > mainframe.

I gather that you don't have much experience with mainframe programming.

Mainframes are not big arcade games. Their programming is more complicated, varied, and subtle than you can imagine until you've had a couple of decades of experience on a dozen different types of computers. This means that the Y2K problems are complicated, varied, and subtle.

Spur-of-the-moment analogy:

Early computer programming was like life in the American West in the 1800s in that it was unruly, lawless, unregulated, individualistic frontier experience.

The pioneers traveling west in covered wagons were NOT planning routes for interstate highways. How many of them do you think ever conceived of the idea of the automobile?

Similarly, some pioneering computer programmers established "trails" of programming standards and practices which, though adequate to the needs of the time, did not allow for proper processing of dates past 1999. They were more concerned with the programming equivalents of deserts, rattlesnakes, and alkali water than with minor details of future date handling.

(Keep in mind that real life in the American West in the 1800s was not as simple as is depicted in movies.)

-- No Spam Please (anon@ymous.com), December 01, 1998.

Hate to rain on parades but:

I know of programmers who called the date routines they wrote by their current girlfriend's first name, any reference to "YEAR" was her middle name, month was her street, you get the idea. I know other guys who called years, months, days by dog breeds.

You HAVE to remember that we are talking about stuff that was written LONG before the whole world started to worship at the shrines to Ed and thte rest of teh structure people (Softech, etc).

Also, these guys LIVED inside their programs, the printouts and cards became their lives,and when the tubes moved in, the lives changed, but not for the better.

Chuck

-- Chuck a night driver (rienzoo@en.com), December 01, 1998.

Doesn't matter which solution you adopt, takes the same time to code and test. Guess you all know that by now.

-- Richard Dale (rdale@figroup.co.uk), December 01, 1998.

First: " AMERICAN" National Standards Instsitute standards do not apply outside "America." This is a global problem. I'm sorry if I'm beginning to sound too much like Paul Milne, but when the hell are you people going to get it? If you don't start getting a bigger picture of the magnitude of the global connectivity, you are as short-sighted as any target of Paul's verbal attacks. PLEASE, get you heads out the the bell jar of American thinking that you are somehow isolated from the global impact of this connectivity.

Second: The existing applications that ferret out date fields are only marginally reliable. A "typical" AS/400 in a "typical"business environment is a Rube Goldberg of programming. It has been my experience that testing, testing and more testing (closer to 60%+ of time) is necesssary to discover the "bonus" routines that call up date fields no person ever dreamed they would access. Nobody is fixing anything--they are only adding more bugs. As simplistic as that sounds, it is the truth.

Third: IMHO, main frame problems are miniscule in comparison to embedded systems problems. People can find ways to prioritize work and complete some essential services. Our industries cannot (I repeat-- cannot) function without these systems. The factory and refinery and chemical plant systems were not designed to be operated by people. People have been eliminated from the process to give you the bountiful, inexpensive and carefree lifestyle you now enjoy. People were expensive headaches. Machines and automated systems were non-union business solutions. Maybe I'm onto something here... The idiot union leaders in the 1970's created this problem. Ironic isn't it? The machines have formed a union and they will start a work stoppage next year.

I apologize. This sarcastic and aggressive style of writing is not my ususal style. I know you are trying to make a positive contribution and searching for solutions to problems. I've just had a very hard day dealing with a group of business executives who were all born without brains. Each of them had so much common sense -- because they hadn't used any yet.

-- PNG (png@gol.com), December 01, 1998.

AND... where the hell is HARDLINER? You are sorely missed. But I can understand your desire for a break (and a casual lurk). The energy you used can be draining. BTW, I know your other name - but I'll never tell.

-- PNG (png@gol.com), December 01, 1998.

Standards have to start SOMEWHERE. And they have to be used. Look at how many of YOU still take the "lazy" way out with writing dates -- just like the programmers and management of the past -- AND OF THE PRESENT. They and most of YOU are still using a date format of 1/1/00 for 2000-01-01 (YYYY-MM-DD). IF YOU ALL DON'T GET IT, HOW DO YOU EXPECT THE UNWASHED TO GET IT.

-- byter (programmer@noyb.com), December 01, 1998.

Tom, I agree with all the posts that occurred after mine. My approach was just not as Milneish (to coin a phrase) as the others. I don't need to be hit over the head with something to get it. I've been 'getting it' for over 20 years.

Maybe Milne is right and the masses don't respond unless hit over the head by a clue-by-four.

At any rate none of the IT pros who post here were able to convince the organization's we have been a part of for the last 30 years that we had a problem. Myself included.

-- MVI (vtoc@aol.com), December 01, 1998.

And these "copper-connected union members" won't listen to their foreman (nor a DC politician) telling them to go back to work will they?

Incredibly stubborn, aren't they? Incredibly rigid? Always follow only the procedures? Sounds like a global strike by a government bureacracy!

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), December 01, 1998.

Well, I'm back in my cave, lair, refuge from the world, and very greatly depressed. I've been off attending to my obligations (which are of import to me) and it feels as if I've attended the funeral of the human race, or at least of Western Civilization. The airports, the cities, the cabbies, the restaurants, no one acts as if they're dying, but they are. It's like watching a children's ward of terminally ill kids. There is a tendancy to let them have their last days in blissful ignorance. . .

The Rhyme Asylum is more to me than a gag. I created it as a further refuge from the world and invited you all in to help me cope with the fears and feelings that I can only begin to describe. You all know by now that I am a Marine. There are only two things that scare Marines--running out of beer and running out of toilet paper--so please realize that I'm not talking about that kind of fear. I lost my fear of Death quite some time ago when I acquired the knowledge that dying is not hard. Living is what's hard. There is something within me that is part inate and part learned, and it will not let me quit. I have seen the truth of the old adage that, "Only the good die young", and although I am no longer young, I expect to be around for quite a while yet. I have rolled enough dice to know that "Snake Eyes" can show up at any time, yet my own life has been played with seemingly "loaded" dice. I've remarked before on this forum to the effect that my life has been unbelievable and it was no exageration. It was, if anything, an understatement. I must take the blame (or credit) for a lot of that. Perhaps some of you will begin to understand the true "looniness" of my soul if I share with you a small aspect of my sense of humor.

Years ago, while stationed at the Naval Air Station in Dallas, I took some leave and I and "Harderliner" (my wife) made a grand driving tour of the Western United States. We visited the Painted Desert, Grand Canyon, Grand Coulee Dam, San Diego, Los Angeles, Yosemite, King's Canyon, Lassen Volcanic, San Francisco, The Pacific Northwest, Yellowstone. . . Well, you get the picture. We were gone for months and we put a lot of miles on that old pickup truck--something over 8,000 as I remember.

Anyway, I got the idea in the visitor's center at the Painted Desert. They had at that time on display, many bits of petrified wood that had been taken from the park in violation of the rules and returned with letters of apology, many to the effect that the stolen artifacts had brought the perpetrator very bad luck. Realizing the ancient nature of such luck (if indeed it existed) I fantasized the following: 30,000 years or so in the future, a geologist (perhaps human, perhaps extra-terrestial) happens on a cluster of rocks somewhere in what is now Texas. To his utter amazement and complete bafflement, he discovers that some of them are identical with those only found in what was then Nevada, California, Colorado, etc. To this end, Harderliner, who is my first and best partner in crime, so to speak, and I gathered about a half ton of miscellaneous rock from all over the Western US and created that cluster in Texas. I am sure that it is still there. I am also sure that in the fullness of Time, it will create the scenario I envisioned, or one suitably similar. I get a laugh out of imagining that geologist's puzzlement every time I think of it, and I think of it often. I wonder too, how many others in Humanity's past have played similar tricks. . . Such is the craziness that is mine.

More relevant to the current thread however, is the fact that I've seen no one allude to on this forum, that computers do what you TELL them to do, NOT what you WANT them to do. And, as long as I'm telling tales from the long ago, I'll tell you another.

This one is from the dim days of yesteryear when computers actually had discrete transistors in them. Integrated circuits were in their infancy and actual transistors were still common. IBM had put on a trade fair in Endicott, NY, for customers and other interested parties, and among other exhibits of "the latest and greatest", was a System 360/30 that one could "converse" with by typing and reading on a 1052 Selectric Console Printer. There was a preset menu of questions that you could ask, two of which were: "Would you care to join me in a cup of coffee?" and "Given the choice of two wristwatches, one of which does not run at all and the other of which is continually and reliably 20 seconds slow, which one should I logically buy?"

The computer answered the first question with, "We would not both fit!", and the second with, "Buy the one that doesn't run at all. It will be correct twice in each 24 hour period but the other one will only be right once every 27,873 years, 7 months, 5 weeks, etc.!" (I don't remember the exact numbers, but I'm sure you get the idea)

The moral here is that we've already told the computers what to do. They are doing it. They will continue to do it until we tell them otherwise. We've waited too long and we're not going to like what they do. But, like the mindless, obedient servants that they are, they will do just exactly as they've been told.

"Millennial Solutions" abound, but they all belong to Nature, not to Man. At this point in time all an individual can do is what Donna's little sister advises and put on a helmet and strap in. It's gonna be a helluva ride. . .

I've spent some time "catching up" with what's been going on in my absence and among other things, I want to tell you that the postings concerning my absence are quite the ego boosters (not that Jarheads need any such thing)! I've missed the intellectual diversity here and the freedom to be myself. It is good to be back.

-- Hardliner (searcher@internet.com), December 01, 1998.

Thank God Hardliner is back !!

Know what you mean about watching the world go by as if in a surrealistic funeral time-capsule. Eerie. Can't even go to the store normally anymore, watch & feel like crying, shaking ppl, but of course won't do that. Certainly hope tis me & y'all that's crazy.

Ashton & Leska in Cascadia, which is getting 50-mph wind gusts now.
xxxxxxx xxxxxxx

-- Leska (allaha@earthlink.net), December 01, 1998.

Hardliner, welcome back! I hope you placed a "pet rock" in your pile, with instructions, sealed in a lead baggie.

Please, please remember, even when/if all the lights go out, the sun still shines daily. We can only ever take it one day at a time.

Diane

-- Diane J. Squire (sacredspaces@yahoo.com), December 01, 1998.