Subject:	Re: Cory, Milne, the Doomsday shills
Date:	1999/08/30
Author:	cory hamasaki <kiyoinc@ibm.XOUT.net>
	Posting History

Will you big brained pollies tell us how in the world "Banks Get It", "We're Ready", "We've broken the back of Y2K", "Prepare for 3 Days"? Banks don't get it. Kosky is like, woooo-woOOoo, lost is space. Lets do the math. There are 50,000 IBM style mainframes in the world. 35,000 run MVS aka OS/390. The other 15,000 run a mix of VSE, DOS/MVT (there's about 400 of these), VM/CMS, ACP. I believe there are still shops running TSS/370, DOS (non VSE), MVT, MTS, AIX, and maybe even UTS. Of the 35,000 OS/390 systems most are *not* current. Maintenance is a tuff job. The shops that are current are the "vanilla" shops, the ones that decant an IPO, reconfigure their IO subsystem, and go. (Note to pollies/debunkies, if you don't understand this post, it's you.) We're talking PUT 9906 and PUT 9907. This is August 30, 1999. There are 123 days left. This should have been resolved at Day 500. It wasn't, we're in deep, deep Van Nuys. Thanks Greg. This is the smoking gun of Y2K. Based on Greg's report, people, *please* take some preventative measures today. I'm not telling you to buy a fine quality assault rifle, which if you don't need, you can always sell later for cash. I'm not telling you to help your aunt fix up the family farm, which will make life nicer for her and give the family a place to come together and relax. I am telling you that Greg's report is ominous given that we have 123 days left. On the cheerier front. Giant Food has a nice sale on Campbells soups, pasta, sauce in glass jars. I eat a lot of this stuff anyway. If you do too, why not buy a bunch, say a couple hundred bucks worth? On Mon, 30 Aug 1999 14:46:43, gregsch703@mailexcite.com wrote: > I'd be happy to talk to you about it, Cory and Bob, they are kicking new > stuff out all the time. Here are some examples from this month, notice > the dates. Let me know when you two will be on. Maybe this evening? > I try to get on Tuesdays and Wednesdays about 9:00 EDT. > Greg S > > ************************************************************************ > * SECTION 4. S E R V I C E R E C O M M E N D A T I O N S > * > > ************************************************************************ > 96. 99/08/23 PROBLEM: (OW40356) MIGRATE VOL(VOLSER DBA(N)) CAUSES > ARC0734I ACTION=DEL-AGE RC0 FO R DATA SETS WITH > 99365 EXPDT EVEN THOUGH DATA SET IS NOT DELETED > USERS AFFECTED: All R120, R130, R140 and R150 users of > DFSMS DBA function against DASD volumes. > RECOMMENDATION: INSTALL UW62039 ON VOLID 1934 (HDZ11B0) > INSTALL UW62040 ON VOLID 1934 (HDZ11C0) > INSTALL UW62041 ON VOLID 1934 (HDZ11D0) > INSTALL UW62042 ON VOLID 1934 (HDZ11E0) > 95. 99/08/17 PROBLEM: (OW40169) SPACE MANAGEMENT OF ML2 DOESN'T HONOR > SPECIAL EXPIRATION DATES (99365, 99366) > USERS AFFECTED: All users who rely on 99365, 99366 or > 99999 to protect Non SMS data sets from > deletion and who run DBA or DBU against > ML2 > volumes. > RECOMMENDATION: INSTALL UW61499 ON VOLID 1933 (HDZ11B0) > INSTALL UW61500 ON VOLID 1933 (HDZ11C0) > INSTALL UW61501 ON VOLID 1933 (HDZ11D0) > INSTALL UW61502 ON VOLID 1933 (HDZ11E0) > 94. 99/08/02 PROBLEM: (OW39815) RETDATE VALUE INCORRECT FOR ALL > VOLUMES > EXCEPT FIRST IN VRSEL REPORT > USERS AFFECTED: All RMM users. > RECOMMENDATION: INSTALL UW61560 ON VOLID 1000 (HDZ11C0) > INSTALL UW61561 ON VOLID 1000 (HDZ11D0) > INSTALL UW61562 ON VOLID 1000 (HDZ11E0) > 93. 99/08/02 PROBLEM: (OW39882) VOLUME WITH EXPDT OF 1960/001 IN TMS > GETS EXPIRATION DATE OF 2060/001 DURING > CONVERSION > TO RMM USING EDGC5LDR > USERS AFFECTED: All users converting from CA-1 Rel. 5.x > to > DFSMSrmm Rel. 1.3 , 1.4 or 1.5 > RECOMMENDATION: INSTALL UW61563 ON VOLID 1000 (HDZ11C0) > INSTALL UW61564 ON VOLID 1000 (HDZ11D0) > INSTALL UW61565 ON VOLID 1000 (HDZ11E0) Come on, Pollies, refute this or give it up. cory hamasaki http://www.kiyoinc.com/current.html 

-- a (a@a.a), August 30, 1999

Answers

Subject:	Re: Major Flaw Found in Navy Document Spin
Date:	1999/08/30
Author:	cory hamasaki <kiyoinc@ibm.XOUT.net>
	Posting History

On Mon, 30 Aug 1999 16:10:01, "Ken Winters" <kwinters@olympus.net> wrote:   > As for Chase Manhattan specifically, here's what they said in their latest > 10-Q: > "Chase currently estimates that full year 1999 Year 2000 costs will increase > to approximately $158 million (versus the $127 million reported in the First > Quarter 10-Q). The largest portion of the $31 million increase is directly > related to the cost of IVV" > > So somehow, because they went the extra mile and spent money on IVV, there > are now considered to be following behind?  Yet if they hadn't done IVV, > they would have been accused of not having independent verification.  Kind > of hard to win.   IV&V is *not* the extra mile.  Without IV&V, the independent audit from the Joel Willemssen and the GAO, we wouldn't know about the compliance problems.   I hope everyone took note the Social Security is *not* done.  The GAO has uncovered *more* compliance stretching.  Is it a coincidence that Social Security's Y2K Tzarina retired 4 months before her *success*?   Of course, we in c.s.y2k knew since March that Social Security wasn't done, I've printed geekvine info and updates on their "progress" in the WRPs.   Chase could have realized that IV&V was necessary and planned the cost and time in last year's budget.  The fact that they didn't and, oh, 9906-9907 includes HIPER YR2000 maintenance and just came out last week is a *bad* sign.   Come on people, 123 Days now.  Shaking your clenched fist and saying loudly, "We're Y2K Compliant." doesn't make it so.  It would have taken much more effort than has been expended.   I don't know what's gonna happen but I know that the software and large systems will fail.   cory hamasaki http://www.kiyoinc.com/curr ent.html 

-- a (a@a.a), August 30, 1999.

In a sense, it seems like the old mainframes have always been the "bread and butter" of Y2K problem -- the importance of their function, and complexity of their archaic systems, has always been nearly irrefutable. The only issues are: can they be fixed in time, and if not, then how bad will the hit be?

Embedded systems, minis, PCs, etc., are real iffy, but those mainframes just seem to defy anyone to be able to say, "No problem"....

-- King of Spain (madrid@aol.com), August 30, 1999.

SCADAs big problem too.

-- Ashton & Leska in Cascadia (allaha@earthlink.net), August 31, 1999.

"All users who rely on 99365, 99366"

I just love this, and gotta tell ya the story.

In the early days of IBM OSes, 99/365 was used as the "keep forever" date on disk and tape labels. Well, they realized that on Dec 31 '99 EVERYTHING would "expire" and would be "scratched".

Their answer? Add another day to 1999, day number 366! 99/366 is now a valid date, that really means keep forever, since it will never occur.

An early solution to Y2K. Makes one wonder...

Tick... Tock... <:00=

-- Sysman (y2kboard@yahoo.com), August 31, 1999.

"SCADAs big problem too. "

Yes, SCADA is a problem, but you can operate without it. Just go read all of Dick Mills articles and he spells it all out

-- snore (snore@snore.com), August 31, 1999.

So, SCADA is not a problem???

-- Curious (curious@wondering.com), August 31, 1999.

Re: SCADA

Dick Mills discussed the use of SCADA in certain aspects of electrical power transmission, and, as far as I could decipher, indicated that in that context, the loss of SCADA would decrease the efficiency of the system, but not take it down.

In other contexts, the effects of the loss of SCADA could vary all over the spectrum, depending on the context, IMHO.

Jerry

-- Jerry B (skeptc76@erols.com), August 31, 1999.

Sysman:

It didn't exactly say all users of expiration dates of...

More specifically, it stated:

R120, R130, R140, & R150 users of DFSMS DBA function against DASD volumes

non-SMS data sets DBA or DBU against ML2 RMM users

Converting from CA-1 Rel 5X to DFSMSrmm Rel 1.3, 1.4, or 1.5.

It's also not mentioned to what release(s) of OS/390 these puts apply.

I'd need the complete information to make an assessment. My own experience in situations like this include looking at the APAR descriptions, determining if I have the software or situation addressed, and if I don't, there's NOTHING that needs to be done.

-- Anita (spoonera@msn.com), August 31, 1999.

Loss of SCADA implies all sorts of very nasty long and short-term problems, many of which might be "jury-rigged" to keep power up.

Loss of SCADA (for more than a couple of hours) means essentially no automatic way of monitoring and measuring what is flowing in the wires = wrong bills, wrong payments to customers and suppliers (power plants), overloads and underloads, and greatly increased risk of failure.

Imagine being on a racetrack (going in circles, no other traffic) driving at 60 mph. You can do this, and do it safely, right? Now somebody removes your speedometer, temperature gage, tachometer, gas gage, and rear view mirror. You can still drive safely, right? (For a while, then you begin worrying about fuel....overheating the engine....)

Now, pretend you are driving at 150 mph, and somebody not only takes away your instruments but paints your windshield as well. (It's okay - he'd going to phone in directions from the grandstand to tell you when to turn.....)

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

Minor correction to my post above:

Put a line break between against Ml2 and RMM users.

-- Anita (spoonera@msn.com), August 31, 1999.

Robert:

Thanks for the phone. Do we get a hands free set, or do I need to use one hand to hold the phone?

A few hours, hey? Not any real surprise. Process systems can get pretty weird pretty fast without those small adjustments.......

-- Jon Williamson (jwilliamson003@sprintmail.com), August 31, 1999.