Well gang, the glitches and snafu's just seem to keep building and building. The old death by a thousand cuts problem.

I am seeing an huge increase in the number of postings on a listserver for computer professionals who deal with a specific variety of hardware. It shall remain nameless because of the jerks that populate this forum.

The questions and queries are just a flying. Problems are showing up and people are screaming. Of the great number of glitches and headaches several stand out but one is very nasty for many shops who use this particular application. In other words, this application is toast and no one can get the vendor to reply.

The great number of problems with this application sound like the vendor who wrote the application did not do any serious testing. I find the following snafu to be quite interesting.

It seems the application uses a form of date windowing. The indexed files are sorted on date and the entries are in the form of 'yymmdd'. Well since 00 is less than 99 the application forces the database engine to place the new entry at the head of the sorted chain. OUCH! What do you mean I got to put every new entry at the front of the list? I hope you got a ton of money to upgrade your hardware to meet this new and wonderful system overhead. Most likely your system will just bog down and be real tired all the time.

It is gonna get real interesting!

-- Iglow Inthedark (u235_36@yahoo.com), January 05, 2000

Answers

I'd appreciate it if you could tell me via email what listserver you're referring to. If so, I won't publicize it; I just want to follow the discussion for my own information.

-- Steve Heller (stheller@koyote.com), January 05, 2000.

I believe I know the application your talking about, I posted an example of the glitch yesterday on another thread...

They solved the problem for this particular app by pulling the database, and changing all the "date posted" entries to 05-Jan-00...

It worked for this application, we're back and running, but I can imagine there are more than a few apps that can't take this workaround...

Appears to be an Oracle product... at least in the example I posted..

-- Carl (clilly@goentre.com), January 05, 2000.

Iglow,

The whole purpose of windowing is to add a century to the date for sorts and calculations. If the date had been windowed at all it would be CCYYMMDD

Typical Windowing routine.

If year =>50 move 19 to century else move 20 to century.

This should work for 50 years unless your dealing with dates earlier than 1950, such as birthdates.

Please email me that URL. Thanks Tedddriver@sprintmail.com

-- Infidel (Barbarians@thegate.net), January 05, 2000.

Check the following threads...

=http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl? msg_id=002E6Q

http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl? msg_id=002Dmm

-- Carl (clilly@goentre.com), January 05, 2000.

Infidel,

First of all, you know not of what you speak.

Yes the idea of windowing is to add the CC to YY, but this is done in the application. I am referring to the database engine, NOT THE APPLICATION.

Windowing saved time because the data could be left in the database in the form of YYMMDD. The sort is contained within the database. The date field(YYMMDD) is a key into the indexed file. This key is sorted. Prior to 000101 all new entries were placed at the end of the chain. You know:

991229 991230 991231

Now

000101 000102 991229 991230 991231

The major system overhead comes from the need to place the NEW data at the head of the list in front of ALL the other entries. Ten years of dates to be exact. ANY WAY YOU LOOK AT THIS IT IS BAAAAAAAAAAAAAAD

-- Iglow Inthedark (u235_36@yahoo.com), January 05, 2000.

I wish to squash any unfounded rumors.

This problem is not with Oracle.

No, I will not reveal the name of the forum, even in private.

-- Iglow Inthedark (u235_36@yahoo.com), January 05, 2000.

Window and re sort numnuts.

-- Infidel (Barbarians@thegate.net), January 05, 2000.

Infidel,

Your such an idiot. You probably gots yourself a PC at home. Let the big boys play the rough games.

-- Iglow Inthedark (u235_36@yahoo.com), January 05, 2000.

Way back in the early days of Y2k, before people even STARTED talking about embedded systems, the yy sort key in a database was one of the really BIG boogeymen. This is the glitch that can kill a company.

It'll be another week before the system manager gives up and tells the CIO it can't be fixed, and a couple days later the CIO tells the CEO, and a couple days after that it hits the local paper, and they'll do what they can manually, and around March they go toes up.

We have not yet begun to hear the glitches that can still sink us.

We are scraping the iceberg now ...

-- bw (home@puget.sound), January 05, 2000.

Up yours clown. I've been fixing Y2K mainframe apps for three years. Take your silly problems and shove it where it don't snow.

-- Infidel (Barbarians@thegate.net), January 05, 2000.

Infidel might be working on mainframes, but it sounds like he's clueless on databases. I've worked with some who sound like him, but perhaps I'm misreading Infidel. There are many mainframe guys who go through the motions, when properly pointed, and to them the database is a black box. You tell them what call to make and where the data will appear, and they'll code the record manipulation parts. Whee, look at me, I'm a database programmer. Not even close.

Anybody who suggests windowing a sorted database key sounds like that kind of programmer. Your only course is generally an unload, restructure, reload sequence, along with modifying many if not all programs that use the database. This is no small deal. Most companies could not survive the downtime - easily a month, maybe a couple.

-- bw (home@puget.sound), January 05, 2000.

Infidel,

Perhaps we got off on the wrong foot. I do not wish this discussion to degrade into, well, what it has become.

Explain to me again what part of the problem you do not understand.

It is not the application. The database schema is static in the form of YYMMDD. The windowing occurs outside the database enviroment. I am referring to the DATABASE ENGINE not the application.

Like yourself I am a mainframer. I have been working on them for 15 years.

-- Iglow Inthedark (u235_36@yahoo.com), January 05, 2000.

Thanks to all you database genious's I made a mint the last three years. Don't get insulting with me and I won't with you.

And by the way. Thanks a lot.

-- Infidel (Barbarians@thegate.net), January 05, 2000.

OK, accept my appologies. I am not a database guy. A simple applications programmer sinse 1984. Much of my time is spent in recreating input files using such things as easytrieve and others.

I primarilly use VSAM. Am I restricted to using your input file as is? If so, I am indeed in trouble.

-- Infidel (Barbarians@thegate.net), January 05, 2000.

Infidel,

YOU REALLY ARE AN HORSES ASS.

It is no wonder this forum has lost many of best and informed posters.

Hard to belive someone actually paid a genius like you to work on their applications. I have worked with people like you, spent way too much time explaining the way things work and fixing poor coding.

Tell me again, YOU STILL DON'T GET IT DO YOU? (hahahahaha, you kill me)

-- Iglow Inthedark (u235_36@yahoo.com), January 05, 2000.

Change the fricking data so that the century is part of the date -- YYYYMMDD. Frickin' numbnuts. That is the ONLY real fix. Everything else is blowing smoke.

-- A (A@AisA.com), January 05, 2000.

A,

My point exactly. Three years ago I had to threaten to quit if my company adopted windowing over expansion.

Because we did it right, our application and data are working with zero problems.

-- Iglow Inthedark (u235_36@yahoo.com), January 05, 2000.

"Change ... data so that the century is part of the date". Yup, exactly. With a sequential file it takes half an hour; with a VSAM file that takes hours; with a mainframe database it takes maybe months.

It's a company killer not because it's complex, but because the whole job is so big. There is nothing complex in Y2k, just lots of it.

The question is, how many companies blew off Y2k as hype and haven't yet done this? How many of them depend for their lives on a system which is broken today? How many of them can survive a one-month downtime in their critical systems? What happens to the economy if a few thousand of those companies crash?

We are hitting the iceberg now ...

-- bw (home@puget.sound), January 05, 2000.

20000105 Wednesday

I'll jump in this "fray" ...

The only "horses asses" are those that didn't do one of the following with regard to "databases" and/or (data) sort routines:

THE REAL FIX:

UPGRADE ALL (MAINFRAME) SYSTEM utilities AND -- CHANGE ALL DATES to YYYYMMDD -- NO ONE ON A "REAL" BUDGET DID THIS!. ALTERNATELY: PORT "BIG IRON" SYSTEMS TO INTRA/INTER-NET ENVIRONMENTS. A LOT OF SHOPS DID THIS.

THE "BANDAID" FIX:

License UTILITY SOFTWARE that can handle whatever TEMPORARY WINDOWING METHODOLOGY (DELIMITED WITHIN 100 YEARS) the user chose. (NOTE: SOME THAT CHOSE THIS METHOD HAD SOME HARD DATA "HISTORY" DECISIONS TO MAKE AND/OR FOUND SOME NASTY, UNINTENDED CONSEQUENCES TO (OUT-OF- "REACH") VITAL HISTORICAL DATA!)

Regards, Bob Mangus

* * *

-- Robert Mangus (rmangus1@yahoo.com), January 05, 2000.

Excuse me, had to step out and check the lines on my 34 ft sloop that I bought last year.

Dates that are in keys have to be expanded. Unavoidable. A nasty business I agree. You've had three or four years to do it. If you expended every date, Y2K would never get done. Windowing has it's place, expansion has it's.

Almost every shop has had to do some expansion. I don't understand your problem. Well maybe I understand a little better than you think. Primadonna's are a dime a dozen. That's why no one wants them.

Your company probably wishes they had taken you up on your offer to quit.

This problem is old news. You take a lot for granted. When you open your mouth you only show your inexperience and stupidity.

-- Infidel (Primadonnas@are.us.com), January 05, 2000.

Infidel,

Please read the original post again.

I am not suffering any problems, ZERO, the company I work for fixed it correctly. Expansion everywhere. We have no y2k issues.

The issue at hand is a vendor who claims to have fixed the y2k issues in their application. On the surface this may seem correct. The problem arises when the application attempts to put a windowed date into a indexed file and that date field is a key into the file. This has and unless fixed will cripple the system due to the overhead required to accomplish such a task.

Thanks for the conversation, althought heated at times, a pleasure discussing the issue with you.

I should have know you were a "blow boater", my 26 ft. cabin cruser is out of the water and buttoned up tight for the winter on the side of the house. I must admit to wanting a big ol sail boat one of these days.

-- Iglow Inthedark (u235_36@yahoo.com), January 05, 2000.

Listen big guy

I've listened to some pretty obnoxious crap from you today. I realize you have to have a thick skin if your going to participate in discussion. Your insults have been offensive.

I will admit that I did not pay attention to your orrignal issue that you stated. When I saw your example date had no century, I made assumsions and I should have observed a little more closely.

I have worked on Y2K for about six different clients, dates imbedded in keys must be expanded. I have run into this countless times. This is nasty business and nobody wants to face it. But in the bigger schema of things it is small potatoes.

I believe this issue has been dealth with appropriately.

My point was, can you imagine the Y2k effort if expansion was attempted in all applications? Windowing works with minimal effort. Expansion is at times nessasary.

Sorry we came to blows, I understand your concern. I have been jumping up and down about database corruption for years. This is truly the smoking gun of Y2K.

It's a done deal. Let the chips fall.

Cheers,

Down with DBA's, up the Applications.

-- Infidel (Barbarians@thegate.net), January 05, 2000.

A question here. I am just a housewife lurker, who is trying to understand the debate, and want to know if I am reaching the right conclusion. Please correct my misperceptions, but be kind as I am just a housewife who has used good database software for the Mac to help hubbie in the teensie business.

Are you guys talking about solving the Y2K sorting problem by writing little formulas that are applied in the database application as adapted by the business (Infidel's approach), or are you talking about changing the way the software package itself does the work beyond the ability of the user to write a formula?

I'm trying to comprehend clearly the issues involved in the debate, and want to be sure I don't misunders

-- housemouse (inlittlehole@nevermind.now), January 05, 2000.

Housemouse,

It is complicated, but generally does not apply to canned PC software. Mainframe software is so massive that intervention is required to expand yymmdd to ccyymmdd so you can calculate required fields from dates.

My DBA friends have a legitimate concern that dates used as key fields will not calculate unless expanded with a century. Expanding the date field in a data base is ugly business. If the data is all bunched together, every field must be moved to the right to accomodate the expanded date.

This causes massive problems for the programs that use these files. All the program code must be adjusted appropriately. Lots of work to spend on millions of programs. It's just not feasible.

This is a simplified explanation for sure. The problem we're having here is that Database people and applications programmers just don't like each other.

The database people started it, the applications people finish it. We're all in big trouble.

Some day we will all work together. Nahhhhhh!!!!!!!!!

-- Infidel (Barbarians@thegate.net), January 05, 2000.

Housemouse,

Sorry, that was not a complete explanation. To avoid moving all your input data to the right, within your program, you temporarily expand in a working area your date to include a century for any date comparisons.

Only where dates are being calculated or compared in your program are you concerned. It is not nessasary to expand your entire working area which in turn would require you to expand your input file.

Sorry if this is confusing. You need to be familiar with programming and setting up your data area.

DBA's are not concerned with these problems. That has always been the root of the problem.

It's like Michigan going for a national championship, but they have to play Alabama. Could get ugly.

-- Infidel (Barbarians@thegate.net), January 05, 2000.

Infidel,

I really must apoligize if any of my statements got out of hand. I am sure they did but as you stated it seems the both of us are in the same boat. I was jumping up and down a long time ago about such issues and was getting no where. The company I worked for was blind to the issue and I placed my job and way of life on the line for what I knew to be the best for all concerned. I truly think that due to my dedication and threats the company I work for is on a solid footing for the next century. Please let us not get into the dicussion as to what year is really the correct one.

Yes it is truly a nasty business that we are in and facing the issues with applications and databases has taken on new meaning. Applications and databases have become so massive that changes to either can be considered as a serious issue for any company. I am reminded of the IRS. In order for them to deal with Y2K, new changes to the tax code were put on hold. Can you imagine this. The legislative process must now be dictated by the capicity of the organization delegated to make the changes.

I am not really sorry we came to blows, a heated discussion is good for all. I think we could have a much better discussion if we had a huge grease board and a submarine sandwich lunch.

Keep up the fight and do not let those damn DBA's push you around.

Iglow Inthedark

ps. I am unsure of your location but do you sail in the open ocean or one of the many inland seas?

-- Iglow Inthedark (u235_36@yahoo.com), January 06, 2000.

Infidel,

I forgot, as a DBA, I have always been concerned with this data issue. I am either underfunded or understaffed. We all work with what the powers that be give us.

I have always be concerned with the problems that my programmers are faced with. You must remember that many schemas given to DBA's are not under our control.

I cannot figure out why DBA's and programmers dislike each other. It is all one huge puzzle. The only way it works is really well is when we can all agree. Too bad there are way too many variables.

Later

-- Iglow Inthedark (u235_36@yahoo.com), January 06, 2000.

Nice to see you guys kiss and make up, and thanks for the explanations. I sort of get what you are talking about. I have no interest in doing the work you do, as I had enough trouble trying to set up Filemaker Pro to run the very teensie but complicated business for mousehubbie... a combination of consulting, project management, and commision-based retail, all supposed to integrate. I hate the detail, but love the conceptual, that is why I read and try to decipher what all of you are talking about...

just a housemouse..

-- housemouse (inlittlehole@nevermind.now), January 06, 2000.

P.S. mousehubbie went to MIT, and when I showed him tthe print-out of the arguement, he chuckled and said that it was nothing compared to some of the arguements that went on there... people would get purple and come to blows, flood each others' rooms, etc...

just a housemouse...

-- housemouse (inlittlehole@nevermind.now), January 06, 2000.

Housemouse, the reason it is REALLY ugly, which the guys left out is that most of those databases are accesed through something OTHER than a 3rd or 4th generation language where you have to define what the data looks like EVERYWHERE in a program.

Most of those languages do NOT look at FIELDS as separate data items. Instead they look at RECORDS and figure the fields by displacement from the first position. If you change the way a record looks, not only do the data definitions provided to the computer by the individual programmer ALL have to change, the WORKING definitions which are RARELY centrally handled have to change, as do the definitions written by EACH programmer inside the programs.

THESE are the issues which lead a LOT of us to the conclusion that Y2K was going to be REALLY REALLY UGLY as NO ONE was going to get into ALL the programs successfully.

THESE are the issues that did NOT go away when the power thrillingly stayed on.

Chuck who has worked up to his keister in IMS DBD's in his dim distant past (Logical views, physical views, bla bla bla)

-- Chuck, a night driver (rienzoo@en.com), January 06, 2000.

Infidel, If you sail out of NEWPORT, Naraganset or environs, drop me an E- or IM me at "chuck drvr" as I KNOW we share at least one acquaintance

-- Chuck, a night driver (rienzoo@en.com), January 06, 2000.