Another IBM mainframe problem. : LUSENET : TimeBomb 2000 (Y2000) : One Thread

This is from Not a show stopper if the available patch is applied soon.


cory hamasaki wrote: > > It might be the flu affecting my (limited) ability to reason but aren't > we seeing more than a few system level Y2K problems in the mainframe > world? How could people have tested for a year and not encountered > things like this? > > I make this -4 Days and we've seen several problems with archivers and > schedulers. > > The most popular scheduler for mainframes (kind-a a big boy's Chron) is > CA7. CA7 has a Y2K problem discovered only two days ago. This hasn't > made the newsgroups yet but I ran into it while rejiggering jobs to make > the batch window. So that's my Y2K contribution for the day. > > I understand "Y2K is Over", "Y2K was a Big Nothing" and even > "Waaaa! Milne called me a butthead so I'll take a couple cheap > shots now that I think Y2K is over." but DFSMS is used by thousands > of mainframe shops. It is a key part of enterprise storage strategy. > > These kinds of systems are fundamental in the mainframe world. > > Whatever, I don't care that the pollies think I'm clueless, I'm starting > to think I'm clueless. I never expected multiple problems in storage > management. > > JUrlaub@MICROAGE.COM (Urlaub, Jim) wrote: > > > Ref: apar OW42602 > > > > For all DFSMShsm users, IBM just posted an alert regarding data > > loss if you perform an "AUDIT DIRECTORYCONTROLS VOLUMES(vvvvvv) FIX" > > (where vvvvvv is an ML1 volume). This will result in the > > deletion of the vtoc copies on this ML1 volume that have been > > created in year 2000. All vtoc copies created prior to year > > 2000 are not affected. Migrated datasets are not affected either. > > > > Sample errors that I encountered under DFSMShsm 1.4.0 are: > > ERR 144 HSML1A - HSM.VTOC.T170119.VPSYS05.D00003 NOT IN P RECORD FOR PSYS05 > > ERR 141 HSML1K - SCRATCHED EMPTY DATA SET HSM.VTOC.T311118.VSMSN01.D00003 > > > > A patch fix is now available for 1.3 only. > > Nothing yet on 1.2, 1.4, or 1.5. > > How can this be? This is what? The second, third, fourth, > general mainframe problem we've seen? Didn't anyone test this? > > And yes, Polly Moshe might be right again. They already have a fix > for 1.3, the others will be along real-soon-now. > > Why would I believe that there was anything but the most cursory > testing done? Someone please crosspost this to TB2K. Ed Yourdon > could use a good laugh. > > cory hamasaki I'm heading for bed, sleep for another 10-12 hours. I'm > taking a can of coffee with me. This morning I struggled to get up. I'm > hoping that if I can wake up enough to drink the 6 oz can, I'll be able > to get out of bed in less than an hour, then drag myself in to > fumble around doing whatever clueless thing it is that I do when I'm > not watching Baywatch. >

-- Shuggy (, January 06, 2000



Cory talked about how all of the mainframes would crash, and the one he works on comes up with an unremediated Y2K problem. It looks like he didn't know how to do his job right (why didn't he find and fix it all this time he spent chatting up the end of society?)

Maybe, just maybe he is all talk, and the other programmers knew what they were talking about and fixed their mainframes. But then Cory seems to have said a lot of things about the competence of others......

(December 1999): In the last few weeks, we've seen several unusual IT failures, These include the misplaced forty billion dollars at Chase Manhattan, the payroll problems at the City of Oakland and the District of Columbia. There have also been numerous problems reported with SAP implementations at Hershey's Foods, Whirlpool Corporation, and others. We've seen two incidents where state facilitated child support payments have failed, Nevada and Illinois. Two schools have reported problems with student records.

There have also been numerous reports of cosmetic problems, dates printing as 1900 on legal documents and school children with ages listed as 80 years old.

The problem is, this is the good news. In most cases, these problems are due to companies making mistakes in implementing Y2K compliant solutions. In a month, all companies will hit the wall. Ready or not.

My second concern is the length of time that it takes to fix these problems. Chase Manhattan looked for the cause of their forty billion dollar imbalance for a year. Hershey's estimated that their problem could last for more than 6 months.

Finally, some good news which is also bad news. IBM has issued new Y2K fixes to their software. The good news is that the fixes are available. The bad news is that they released them in November 1999.

It's verified now that there will be problems and that the problems will not be fixed in, oh, 2 or 3 hours. The open question is what percentage of the major systems will take date-hits? If enough fail, the economy collapses. If the failure rate is below some (unknown) threshold, we'll simply see a few companies with reduced revenues and increased costs.

I am working on a more detailed analysis which will be posted on my web page as a DC Y2K Weather Report.

(November 1999): My concern is the large enterprise systems that run the world. Most of these were built in the 1960's and 1970's on second and third generation commercial computers.

These older systems still exist at the heart of most large enterprises.

In 1998 and 1999 there was some effort to replace and update these systems but for the most part, the work was not done. In the last couple months, the news reports and "geek-vine" have both reported on the discovery of critical systems that were overlooked. They have also reported on failures caused by rushing systems into production.

Examples of more-work-to-do are: 1) Social Security, 2) Medicare/Medicaid, 3) the IRS. Public failures include Hershey Foods' recent SAP roll out and the State of Nevada's DMV and family payments systems.

In 1996-7, I surveyed a group of large systems specialists. These were more coffee-house discussions rather than a formal, on a range of 1 to 10, survey.

These were "real experts", technical specialists who have built commercial products, worked on multi-hundred programmer, multi-year, megaprojects.

The sense of the discussions was that in 1996/7, we were out of time but perhaps enough could be done to engineer a good outcome.

Now, we are just out of time. The outcome from this will be widespread IT failures. A megasystem with fundamental flaws cannot be fixed in, oh, 2 or 3 hours. It will take months to repair these systems. When these systems fail, entire enterprises, corporations, trading associations will fail.

There will absolutely be bad consequences for some individuals. Some will lose their jobs, others will lose money or investments.

The unknown is whether the economy as a whole is resilient enough to recover. Perhaps we will be lucky and the consequences will be localized. What if every state goes Nevada and every food supplier goes Hershey Foods?

How bad will it be? How lucky do you feel today?

(July 1999) "The Y2K news has been uniformly bad, L.A.'s flubbed Y2K tests, Washington DC shifting to a contingency mode that includes 12 hour shifts for the police, Locomotive size generators, and a request for 75 million dollars from the Feds."

"Add to this the grilling that Senator Bennett gave OMB (So far, my analysis in WRP 123 is the only report on this issue.) and the disclosure by the NRC confirming monitoring and engineering systems problems at Nuclear power plants. The picture is not very pretty."

"On the other hand, we still have six months to go."

(May 1999) "There are lots of large organizations racing to complete work on systems by the end of the year. You've seen the reports, 90% done, 98% done, we'll know in 7 months where we stand."

"The history of IT projects implies that most of these efforts will fail."

"Let's give the hardworking programmers the benefit of the doubt but hedge by taking sensible, personal measures."

(March 1999) "I (am) keeping my assessment at 7.0 for several reasons. While the information coming out of large enterprises is worse than I expected, this is being offset by grass-roots level efforts by individuals to prepare for what is about to happen."

If you think about the large enterprise systems, banking, insurance, manufacturing, communications, etc. there is no possibility for a good result. If you factor in the work that people are doing on the local community level, there is hope.

I continue to be optimistic and hope for a good outcome but I also know with absolute certainty that there will be catastrophic failures in every industry and sector of the economy."

(December 1998) "My ranking of 7.0 still holds. Several developments over the last few months causes me to be more certain than ever that "something wicked, this way comes." I do not see any evidence that steps are being taken to solve the infrastructure problems or to work on the essential IT systems. There is more awareness in non-IT managment but this awareness has not produced action. Y2K is a no action, talk only game."

"I would be even more gloomy except that I have a basic optimism for people and our ability to help others in need."

"I am collecting essays on the seriousness of situation at, I caution you, these are not the white-bread, homogenized, PG-rated essays that are found in the popular press and at other websites. Neither are these alarmist ravings of the fans of doom and gloom."

"My reports are primarily analysis by professional programmers who, having examined the situation, have reached the painful conclusion that we are headed for a IT disaster." "You may wish to publicize this... or you may prefer to look the other way, the fact is, we should have had a full court press in 1995, we were out of time in 1997, it will be 1999 in a few days." "The initial major IT failures are scheduled to begin January 31, 1999, this is the Jo Anne Effect, when financial accounting systems for several Fortune 500 companies touch the wall for the first time." (October 1998) "Y2K is unfolding as expected. Although the work overall isn't getting done, the few firms and organizations that started early enough are doing their testing and will complete the work on time. What is an unknown is the status of the other firms and organizations. A few have simple enough DP/IT/MIS requirements that they may be able to complete the work in the time remaining. I suspect that most will not and we will see a very chaotic situation." (June 1998) "The systems will fail in strange and wonderful ways. There isn't enough time left for remediation; we should be engineering bypasses and fallback systems and working within the local community to provide care and support for the needy and helpless."

-- Cherri (, January 06, 2000.

quick, CHERRI-

take a few of these

-- plonk! (, January 06, 2000.

Maybe someone should tell IBM that this Y2K alert on their website only applies to Cory:

DFSMShsm: Do not run the AUDIT function with the FIX parameter until further notice

-- (, January 06, 2000.

Cory was right... I can't post all the info, just a few snippets, for contractual reasons, but if anyone requires confirmation of this as a legit failure, I'll provide info by e-mail to Diane, so long as she promises to keep the additional info confidential...

"The client has discovered two critical programs with date dependencies that are not functioning properly since the change of the year. They are seeking someone who can work through and actually re-write the programs.

The client has two CICS programs that were written using CSP and compiled under an old release of COBOL (compiler no longer available). They were running under OS/390 2.6, but due to some date dependencies, they are no longer functional. They would like to have someone re-write these programs as CICS command level programs in COBOL II. One of the old programs involves 40 screens, while the other involves 10 screens. There are 16 tables used by the applications. Someone familiar with CSP and CICS examined the applications and estimated that it will require about a month's work to recreate them in the desired new environment. There is an assembler subroutine that is called by the programs, but it is not expected that this program will have to be modified. The client has specified that the conversion and testing be done on site, meaning that dial-in access is not allowed."

"ADDITIONAL INFORMATION: This requirement addresses an urgent issue that has arisen as a result of the year change. The client recognizes that it will take some time to fix the problem, but they need to have it addressed as rapidly as possible. Please send questions and/or resumes to the e- mail address identified below."

Not all is rosy in the mainframe world folks, but nobody is going to jump up and down and shout "hey, we got a y2k problem and we're up shit creek without a paddle for the next few months folks..."

Not good for the old stock price....

-- C (, January 06, 2000.

Moderation questions? read the FAQ