This mainframe mindset at both the hardware and software levels is a
critical component of the stability of z/OS.
The slow evolution of MS Windows shows how difficult it must be to
design this kind of capability into an environment after the fact. But
admittedly one of the problems MS has had to deal with is that most of
the Intel platforms on which Windows runs lack the robust hardware error
detection and recovery capabilities that are taken for granted in z/OS
environments.
The first step to successful diagnosing and repair of a software failure
is to be certain it IS a software issue and not some random hardware
glitch. This is made more difficult in the Intel world by the very
thing that makes these platforms affordable - a multitude of
manufacturers of motherboards, memory, hardware interface cards and
peripherals all applying their own concept of "acceptable" engineering
design while trying to make fast and cheap hardware.
The last time I saw a hardware error on an IBM mainframe that was
undetected by the hardware was in the late 1970's. Although I had at
least one instance per year when an application programmer would swear
that the hardware or system had executed their code incorrectly, it was
always an application coding error. One can pretty much discount the
possibility of a hardware error event on an IBM mainframe unless the
hardware reports a problem.
I have seen strangeness even in the last decade with Intel platforms
that suggested some undetected glitch, perhaps power-induced, had caused
a random failure in a memory card or some other hardware component.
Unlike IBM mainframes, one cannot yet rule out that a failure on these
platforms may have been caused by a hardware problem. I suspect that an
even higher incidence of hardware failures on these platforms in the
past may have been responsible for originating the
fix-after-multiple-failure mentality, since a single failure could
always be written off as a random hardware glitch.
Joel C. Ewing
On 01/06/2014 02:42 PM, Dan Skwire wrote:
> I have written a book that explains the 'mainframe mindset'. I think it
> really explains our thinking, in a way that the 'kids' really need to hear,
> and understand, before they (continue to) make all those mistakes we might've
> made, 'way back when...
>
> My main point is: that mainframe systems (software AND hardware) were built
> expecting problems, and that makes them so robust. That is contrasted to many
> non-main-framers who start problem-solving AFTER a problem occurs (collecting
> data, recreating the problem, etc).
>
> I think the point is fundamental.
>
> The book is: "First Fault Software Problem Solving: A Guide for Engineers,
> Managers and Users", available in paper and e-book on amazon, and other
> places (Safari library online). The ISBN number is 1906717427.
>
> I have been trying to get this in front of 'the kids', and get it accepted by
> many of my senior colleagues, endorsed as 'that's important, Dan'.
>
> What do YOU (all) think? Am I off base? is it as significant (as I think it
> is)?
>
> There aren't too many books (I've looked) that explain THIS point.
>
> It is somewhat light reading - with concepts, arguments, examples of
> bullet-proof constructions, even on non-mainframe platforms (yes, there are
> some, not so many...), and illustrations/cartoons.
>
> What do you all think?
>
> Is reaching the 'kids' important? I think it is. I think z/OS and its related
> third-party products will have few supporters once us senior baby-boomer
> main-framers start retiring (hahaha) in 3 to 5 years. Unless we start
> collaborating with 'the kids', NOW.
>
> Dan
>
> (I apologize in advance for this 'commercial' message. Trust me, even if you
> all buy the book, it won't be so lucrative for me. Books rarely make authors
> rich, unless..).
>
>
>
> -----Original Message-----
>> From: "Blaicher, Christopher Y." <[email protected]>
>> Sent: Jan 6, 2014 3:15 PM
>> To: [email protected]
>> Subject: Re: Scary Sysprogs
>>
>> I have been a sys prog or ISV developer for over 45 years. I have always
>> HATED it when someone says "We have always done it this way", or the like.
>> Tell me why the old way is better or why the new way won't work.
>>
>> We all need to open up our minds to new ideas. Most of the people I work
>> with are half my age, some a third. I always look at what they come up with
>> with a positive how can we make this work attitude. Some ideas do work and
>> some don't and some aren't any better than what exists, but they all deserve
>> the light of day.
>>
>> We can still be grumpy old men, just don't stifle anybody's creativeness and
>> try to be nice to the younger crowd until they get to know you.
>>
>> Chris Blaicher
>> Principal Software Engineer, Software Development
>> Syncsort Incorporated
>> 50 Tice Boulevard, Woodcliff Lake, NJ 07677
>> P: 201-930-8260 | M: 512-627-3803
>> E: [email protected]
>>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:[email protected]] On
>> Behalf Of Ed Gould
>> Sent: Monday, January 06, 2014 1:47 PM
>> To: [email protected]
>> Subject: Re: Scary Sysprogs
>>
>> On Jan 6, 2014, at 12:44 PM, Nathan J Pfister wrote:
>>> ------------------------
>>> SNIP___________________________________________
>>> That said, maybe I was just fortunate that I found my internship and
>>> first post-college job within the Federal Government in which it is
>>> nearly impossible to get fired, thus making change and new
>>> ideas/people not as much of a threat as in private industry.
>>>
>>>
>> Nathan:
>>
>> There are private sector companies that are similar (almost impossible to
>> get fired).
>> The cream does not rise to the top as the good people leave faster than one
>> can get used to.
>> The bad stifles all creativity and what is left is a garbage dump.
>>
>> SO I can only imagine what a government place is like and doubly wanting to
>> stay away from such places.
>>
>> Ed
>>
...
>
> Thank you,
>
> Dan
>
> Dan Skwire
> home phone 941-378-2383
> cell phone 941-400-7632
> office phone 941-227-6612
> primary email: [email protected]
> secondary email: [email protected]
>
...
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
