mortgagesgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
I bought a house in 1979, and it had a 30-year mortgage. Obviously, the computer program had to look ahead into the 21st century. My question is: If banks are at risk because of date problems, why didn't this cause a problem? A friend bought a house three years ago, and he has the same question. He's not really a DGI, but he wonders how there can be a problem in this case. Can anyone answer this for me?
-- Vic Parker (email@example.com), December 30, 1998
Vic I had the same thought and came to the conclusion that mortgage companies probably calculated in months rather than years. So a mortgage will be paid off in X number of months rather than in the year 2010 for example. I suspect if they have a problem it will show up when you send if your final payement in 2000. Just my 2 cents
-- John Callon (firstname.lastname@example.org), December 30, 1998.
Try this: banks and mortgage institutions did run into the Y2k problem years ago.
See the threads about the "Jo Anne Effect?" This occurs when the program bumps up against the year 2000. Mortgage programs began bumping up against 2000 in 1970, as you've noted.
Lenders simply fixed the things.......only one program, only a little code, and voila, they were good. Not a lot of effort.
But, true to human nature, they only fixed what they had to fix.......the mortgage programs.
Ever wonder why banks caught on so quickly and are leading the pack as far as remediation? They didn't have to be convinced that a problem existed since they'd encountered it before.
-- rocky (email@example.com), December 30, 1998.
I have read that mortgage companies did in fact discover the Year 2000 problem back in the 1970s, and fixed the applicable software that was used (though I have also read that the fixes were only on the end-date side, with the start-date side still needing remediation!). In a sense, Y2K problems have actually been occuring in some software for many years now. Its just as we get closer and closer to 2000 that they start to mushroom (and will also affect hardware/firmware).
-- Jack (firstname.lastname@example.org), December 30, 1998.
The occasional occurrences of calendar-related problems that we now collectively refer to as "Y2K" did indeed start quite a while ago.
But there's a difference between:
recognizing that all your 30-year mortgage programs have to be fixed,
recognizing both that (a) calendar-related problems to be triggered at or near 2000 were present in vast numbers of places in all kinds of programs in all areas, even those not obviously date-sensitive, and (b) that by the late 1990s computers would be so ubiquitous in our lives, so heavily involved in controlling all sorts of basic services that our technological society would be massively vulnerable to a systematic flaw.
Though the financial industry may have recognized that their three-decade-forward-looking programs needed to accommodate the rollover to the next century and that this was a common problem throughout their industry at that time, only a very few people generalized this to the case of Y2K problems in other areas and realized that they would have problems in almost all other types of programs as well.
-- No Spam Please (email@example.com), December 30, 1998.
Take it from someone in the mortgage servicing industry - Loan maturity dates have gone in to the year 2000 since 1970. Prepayment dates have gone in to the year 2000 for several years now (this is when you're fortunate enough to make payments way ahead of schedule). Most all financial institutions have been dealing with Y2K for several years now and are quite ready for it.
-- deano (firstname.lastname@example.org), December 31, 1998.
# # # 19981231
Would you entertain quenching some curiosity--mine?
I did a 6-month conculting stint ( May-November, 1997 ) on a _mortage service company_ Y2K project ( IBM MVS, COBOL II [ circa 1965 legacy code; pushed through many upgrades, migration iterations; enhancements; etc. ], and CICS ). It _only_ involved some 1,000 COBOL, JCL, Sort modules, Screens and CICS-related programs for--if I recall the jargonized description--an home builders escrow system. You know, where someone building a new home, borrows the money to disperse as building progresses?
The systems and subsystems were absolutely, mind-bogglingly rent with non-century compliant COBOL date computations for the ( typical ) 18- month ( EV [ Event Horizon; aka "JAE" ] into the future ) terms of these contracts. IOW: Without correcting each and every 2-digit year date computation in this integrated system environment, the system would have been "toast," on and after, July 1, 1998!! ( This explanation for the benefit of newbies and others not familiar with this type of business application! )
One aspect of this particular scenario has troubled me for months. The consulting firm I "retired" from ( Dec. 9th ) directed me to not contact this firm for any reason. ( Why? No explanation offered upon my query! )
Here's my point of curiosity that you may be able to address with _discretion_ ( of course ):
Did the mortgage service company that you work for _experience any major SNAFUs with their systems_ that provide similar business functionalities?
Cynicism--based in large part on the "unusual" directive from my former employer--leads me to suspect that there _may have been_ serious complications with the remediated system upon breaching the "drop dead " EV.
Can you shed any light on this? The suspense is "killing me!" ;-)
Regards, Bob Mangus # # #
-- Robert Mangus (email@example.com), December 31, 1998.
Bob - Our software is old.....very old.......late 60's vintage. We use several methods of storing dates - 2 digit years, 3 digit years (packed) with a century indicator and 4 digit years. We've employed a windowing technique that will take us through 2999 (actually had a client (seriously) ask me what we were gonna do then!!) We did uncover a few bugs during our testing (can't dispute that!) that were Y2K related. But our stance from the very beginning has been 'we are changing as little as possible. We've been dealing with dates beyond 2000 for some time now and we know what we're doing. Some folks accepted that and others had a hard time with it. Fortunately, anyone that audited our project said we were OK in what we were doing.
I don't know why someone would say not to contact us in any way (if we were the one your former employer was refering to). I'm pretty sure we're the only one in the immediate area that does what we do.
We're hoping to come out of the closet (so to speak) next week and announce that we're ready. It will be BIG news in the financial arena for sure! We still have LOTS of testing to do next year (re-certification and industry-wide mainly) but our core systems have been ready for some time now.
Yall have a safe and happy new year. Temp down here in the sunny south is reaching 65-70 today (and all weekend). All you folks buggin' out for Y2K havens really ought to think about relocating SOUTH. Winters down here are a breeze......cold snaps last only a few days. Could make your Y2K plans much easier to deal with.
-- deano (firstname.lastname@example.org), December 31, 1998.
Deano - Thanks for the comments; I was waiting for you to wade in on this. You made a point earlier about financial orgs you know of that will be ready. For balance, tell us a little about the ones who contact you (or your boss, "The Goddess of Gloom and Doom") even now and you know that it's too late for them. All they can really do now is start some serious contingency planning.
-- Mac (email@example.com), December 31, 1998.
Mac/Deano This is the boss (Goddess of etc.). The real problem with the ones who are only contacting us now is that they still don't really have a clue. Many are only contacting us now because a federal auditor showed up on their door step and said that they should have contacted their service providor. Since they're not really sure why they're contacting us or what they should be asking, I've got my doubts that any of them will be doing any great amount of valid contingency planning.
-- BB (firstname.lastname@example.org), January 06, 1999.