Re: A true discussion in today's world (at least here)

[scott Ford]

Guys,

I totally agree , and as you get older you see more issues like you both
mentioned.

Scott

On Fri, Nov 25, 2016 at 12:34 PM, Jesse 1 Robinson <jesse1.robin...@sce.com>
wrote:

> (It's Friday.) All analogies fail because no two things are alike. OTOH an
> analogy may help someone understand an issue by drawing (an imperfect)
> parallel to something else a person may be more familiar with. Or it may be
> used as a tool to persuade someone to take action in a realm where they are
> otherwise clueless.
>
> I offered the auto analogy for the second reason. Where I live in the
> West, everyone has a car and can relate to the issue. If someone in the
> corporate boardroom actually took umbrage to the comparison, then that
> person could probably be reasoned with on technical grounds. There aren't a
> lot of those folks in the management ranks.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Greg Shirey
> Sent: Friday, November 25, 2016 7:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: A true discussion in today's world (at least here)
>
> Personally, I think the analogy is quite appropriate and I appreciate Skip
> sharing it.   I’m sure most analogies, “in some circumstances” can be
> proven to fail, but car maintenance is a fairly typical consideration for
> most people in the US.  If you live in an area with a dense population that
> mostly relies on public transportation, then modify the analogy to the
> subway system or the busses, or point to the Alaska Airlines wiki article
> to show the dangers of delaying maintenance.
>
> My 2 cents,
> Greg Shirey
> Ben E. Keith Company
>
>
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tony Harminc
> Sent: Wednesday, November 23, 2016 1:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: A true discussion in today's world (at least here)
>
> On 23 November 2016 at 12:33, Jesse 1 Robinson <jesse1.robin...@sce.com<
> mailto:jesse1.robin...@sce.com>> wrote:
> > When I get flak about the churn of staying current with maintenance, I
> climb my soapbox. Look, I say, I've calculated that on balance it's cheaper
> to drive your car as long as it runs rather than take in for periodic
> maintenance, which is both time consuming and out-of-pocket costly. Most
> likely it will fail somewhere down the road ;-) but getting it fixed then
> will be cheaper and quicker overall.
> >
> > Well, I say, if you wouldn't think of managing your car that way, why
> would you think it makes sense for a computer system?
>
> The analogy is cute, but I think it fails The problem is that in some
> circumstances that's a perfectly reasonable way to manage a car.
> Depending on the age, how much you depend on it, whether you ever drive a
> significant distance from home, etc. etc. there may be nothing wrong with
> deferring or not doing some maintenance.
>
> I live in a city, mostly walk or use transit, and I have very little need
> for reliability in a car.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Jesse 1 Robinson]

(It's Friday.) All analogies fail because no two things are alike. OTOH an 
analogy may help someone understand an issue by drawing (an imperfect) parallel 
to something else a person may be more familiar with. Or it may be used as a 
tool to persuade someone to take action in a realm where they are otherwise 
clueless. 

I offered the auto analogy for the second reason. Where I live in the West, 
everyone has a car and can relate to the issue. If someone in the corporate 
boardroom actually took umbrage to the comparison, then that person could 
probably be reasoned with on technical grounds. There aren't a lot of those 
folks in the management ranks.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: Friday, November 25, 2016 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: A true discussion in today's world (at least here)

Personally, I think the analogy is quite appropriate and I appreciate Skip 
sharing it.   I’m sure most analogies, “in some circumstances” can be proven to 
fail, but car maintenance is a fairly typical consideration for most people in 
the US.  If you live in an area with a dense population that mostly relies on 
public transportation, then modify the analogy to the subway system or the 
busses, or point to the Alaska Airlines wiki article to show the dangers of 
delaying maintenance.

My 2 cents,
Greg Shirey
Ben E. Keith Company


From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, November 23, 2016 1:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A true discussion in today's world (at least here)

On 23 November 2016 at 12:33, Jesse 1 Robinson 
<jesse1.robin...@sce.com<mailto:jesse1.robin...@sce.com>> wrote:
> When I get flak about the churn of staying current with maintenance, I climb 
> my soapbox. Look, I say, I've calculated that on balance it's cheaper to 
> drive your car as long as it runs rather than take in for periodic 
> maintenance, which is both time consuming and out-of-pocket costly. Most 
> likely it will fail somewhere down the road ;-) but getting it fixed then 
> will be cheaper and quicker overall.
>
> Well, I say, if you wouldn't think of managing your car that way, why would 
> you think it makes sense for a computer system?

The analogy is cute, but I think it fails The problem is that in some 
circumstances that's a perfectly reasonable way to manage a car.
Depending on the age, how much you depend on it, whether you ever drive a 
significant distance from home, etc. etc. there may be nothing wrong with 
deferring or not doing some maintenance.

I live in a city, mostly walk or use transit, and I have very little need for 
reliability in a car.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Greg Shirey]

Personally, I think the analogy is quite appropriate and I appreciate Skip 
sharing it.   I’m sure most analogies, “in some circumstances” can be proven to 
fail, but car maintenance is a fairly typical consideration for most people in 
the US.  If you live in an area with a dense population that mostly relies on 
public transportation, then modify the analogy to the subway system or the 
busses, or point to the Alaska Airlines wiki article to show the dangers of 
delaying maintenance.

My 2 cents,
Greg Shirey
Ben E. Keith Company


From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, November 23, 2016 1:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A true discussion in today's world (at least here)

On 23 November 2016 at 12:33, Jesse 1 Robinson 
<jesse1.robin...@sce.com<mailto:jesse1.robin...@sce.com>> wrote:
> When I get flak about the churn of staying current with maintenance, I climb 
> my soapbox. Look, I say, I've calculated that on balance it's cheaper to 
> drive your car as long as it runs rather than take in for periodic 
> maintenance, which is both time consuming and out-of-pocket costly. Most 
> likely it will fail somewhere down the road ;-) but getting it fixed then 
> will be cheaper and quicker overall.
>
> Well, I say, if you wouldn't think of managing your car that way, why would 
> you think it makes sense for a computer system?

The analogy is cute, but I think it fails The problem is that in some
circumstances that's a perfectly reasonable way to manage a car.
Depending on the age, how much you depend on it, whether you ever
drive a significant distance from home, etc. etc. there may be nothing
wrong with deferring or not doing some maintenance.

I live in a city, mostly walk or use transit, and I have very little
need for reliability in a car.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[scott Ford]

My father an engineer in the hard school of knocks would say cars keep the
parts companies in business. Being a ISV, software has bugs, enhancements
which have to be resolved or written and implemented. I can tell you from a
lot of experience some management ppl don't 'get it' ...

My $.02 worth

Scott

On Thursday, November 24, 2016, Mick Graley  wrote:

> I'm a DB2 SysAdm/SysProg and DB2 maint always has reams of hold data. The
> longer you leave it the bigger the job to wade through it all and build the
> required jobs. Multiply it by many DB2 sub-systems and the job gets bigger
> and bigger. You have to have the toleration fixes on the current release of
> DB2 before you can upgrade to the next release (in case of fallback to the
> old release with the new release catalog/directory structure) and that can
> be a big job if you are way back on maintenance.
> Cheers,
> Mick.
>
>
> On 24 November 2016 at 05:35, Edward Gould  > wrote:
>
> > > On Nov 23, 2016, at 8:32 PM, Joel C. Ewing  > wrote:
> > >
> > > I think the car analogy with computer systems  breaks down on a number
> > > of points (at least in the case of mainframes):
> > >(1) while bleeding-edge-current is certainly not essential, the
> > > further you get behind on software maintenance, the more costly it gets
> > > in terms of time and person-hours to get reasonably current; and
> without
> > > being reasonably current you may not be able to utilize new hardware
> > > that could be more cost effective, or needed when old hardware dies, or
> > > needed to adapt to growing business requirements.  The  cost of failure
> > > to do preventive maintenance on a car is bounded by the time and cost
> > > for replacement transportation, no matter how much maintenance was
> > skipped.
> > >(2)software maintenance relating to security or data exposures may
> > > need prompt attention to avoid much more expensive data loss or data
> > > exposure scenarios, which may also have serious legal implications.
> > > Failure to do preventive maintenance on a car doesn't generally make it
> > > more susceptible to hackers or have legal implications, unless you fail
> > > to repair an obvious safety hazard and that results in a
> personal-injury
> > > accident or death..
> > >(3)Unexpected failures of a lesser-maintained car more often than
> > > not just causes a temporary loss of availability which with sufficient
> > > funds can be easily resolved, as there are many ready substitutes for
> > > the basic function of transportation.  A corporate computer system has
> > > company-specific data and company-specific applications which cannot
> > > just be replaced by any generic computer system, and it may be
> > > impossible for the company to stay in business very long without that
> > > data and those applications.  Recovery from some software failures that
> > > result in data loss is only possible with adequate DR planning in
> place,
> > > and if adequate planning was not in place, recovery may not even be
> > > possible at any price.  While I believe a valid argument can be made
> > > against applying maintenance just for the sake of maintenance, some of
> > > the problems addressed by HIPER PTFs are so dire you really don't want
> > > to wait for that failure to occur before installing the fix.
> > >
> > > Even with a car, while it may be cost-effective to avoid or stretch out
> > > some preventive or recommended maintenance, I strongly suspect it would
> > > not on balance be cheaper for you to take that to the extreme and, say,
> > > never change the engine oil (unless of course your plan is to sell
> > > the.car after a few years without disclosing the potential shortened
> > > engine life and cheat the next owner).
> > >Joel C. Ewing
> > about 20 years ago I worked at such a place. They did NOT believe in
> > applying maintenance.
> > Along comes the Y2K problem and they were in a bind (to say the least).
> > They decided to order a servpac (new at the time).
> > They were a  big user of DB2 (I have no knowledge of it) but they were
> > really hurting in order to get up to snuff.
> > They were non going to ORDER COBOL (current as it cost $5 more than the
> > old) then LE hit them in the face and they *HAD* to order that. That
> almost
> > burst their gut.
> > I am glad I got out of there.
> > Ed
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>

--
For IBM-MAIN 

Re: A true discussion in today's world (at least here)

[Mick Graley]

I'm a DB2 SysAdm/SysProg and DB2 maint always has reams of hold data. The
longer you leave it the bigger the job to wade through it all and build the
required jobs. Multiply it by many DB2 sub-systems and the job gets bigger
and bigger. You have to have the toleration fixes on the current release of
DB2 before you can upgrade to the next release (in case of fallback to the
old release with the new release catalog/directory structure) and that can
be a big job if you are way back on maintenance.
Cheers,
Mick.


On 24 November 2016 at 05:35, Edward Gould  wrote:

> > On Nov 23, 2016, at 8:32 PM, Joel C. Ewing  wrote:
> >
> > I think the car analogy with computer systems  breaks down on a number
> > of points (at least in the case of mainframes):
> >(1) while bleeding-edge-current is certainly not essential, the
> > further you get behind on software maintenance, the more costly it gets
> > in terms of time and person-hours to get reasonably current; and without
> > being reasonably current you may not be able to utilize new hardware
> > that could be more cost effective, or needed when old hardware dies, or
> > needed to adapt to growing business requirements.  The  cost of failure
> > to do preventive maintenance on a car is bounded by the time and cost
> > for replacement transportation, no matter how much maintenance was
> skipped.
> >(2)software maintenance relating to security or data exposures may
> > need prompt attention to avoid much more expensive data loss or data
> > exposure scenarios, which may also have serious legal implications.
> > Failure to do preventive maintenance on a car doesn't generally make it
> > more susceptible to hackers or have legal implications, unless you fail
> > to repair an obvious safety hazard and that results in a personal-injury
> > accident or death..
> >(3)Unexpected failures of a lesser-maintained car more often than
> > not just causes a temporary loss of availability which with sufficient
> > funds can be easily resolved, as there are many ready substitutes for
> > the basic function of transportation.  A corporate computer system has
> > company-specific data and company-specific applications which cannot
> > just be replaced by any generic computer system, and it may be
> > impossible for the company to stay in business very long without that
> > data and those applications.  Recovery from some software failures that
> > result in data loss is only possible with adequate DR planning in place,
> > and if adequate planning was not in place, recovery may not even be
> > possible at any price.  While I believe a valid argument can be made
> > against applying maintenance just for the sake of maintenance, some of
> > the problems addressed by HIPER PTFs are so dire you really don't want
> > to wait for that failure to occur before installing the fix.
> >
> > Even with a car, while it may be cost-effective to avoid or stretch out
> > some preventive or recommended maintenance, I strongly suspect it would
> > not on balance be cheaper for you to take that to the extreme and, say,
> > never change the engine oil (unless of course your plan is to sell
> > the.car after a few years without disclosing the potential shortened
> > engine life and cheat the next owner).
> >Joel C. Ewing
> about 20 years ago I worked at such a place. They did NOT believe in
> applying maintenance.
> Along comes the Y2K problem and they were in a bind (to say the least).
> They decided to order a servpac (new at the time).
> They were a  big user of DB2 (I have no knowledge of it) but they were
> really hurting in order to get up to snuff.
> They were non going to ORDER COBOL (current as it cost $5 more than the
> old) then LE hit them in the face and they *HAD* to order that. That almost
> burst their gut.
> I am glad I got out of there.
> Ed
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[David L. Craig]

On 16Nov23:1420-0500, Tony Harminc wrote:
> 
> The analogy is cute, but I think it fails The problem is that in some
> circumstances that's a perfectly reasonable way to manage a car.
> Depending on the age, how much you depend on it, whether you ever
> drive a significant distance from home, etc. etc. there may be nothing
> wrong with deferring or not doing some maintenance.

I agree--the automotive analogy is not compelling.  Even the
aerospace analogies fail to make it personal enough for the
average PHB.  A blood pump analogy gets a LOT closer to the
"heart" of the matter, though.  "I've never had a heart attack,
so I don't need to see any expensive cardiologists or pay for
their exhorbitant tests."
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Mick Graley]

I agree with Tony, the analogy doesn't fit. Not fixing a car that isn't
broken makes sense. Not applying fixes for KNOWN errors usually doesn't
make sense. We all know that PTFs can go PE and cause problems, but you
have to weigh up the likelihood of a known error causing you serious
problems. Also your car failing doesn't normally cost your business
millions of £$€.
Cheers,
Mick.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Elardus Engelbrecht]

Edward Gould wrote:

>about 20 years ago I worked at such a place. They did NOT believe in applying 
>maintenance.

I have seen all sides of that attitude: No/few/emergency only maintenance 
against regular maintenance and staying at the front including IPL the sandbox 
nearly weekly/monthly to apply PTFs and to do 'things'.

Then you get 'percussive maintenance' - hitting it with a fist or hammer hoping 
to 'fix' it... ;-)


>Along comes the Y2K problem and they were in a bind (to say the least).

... bind ... ?  Good pun, now you're talking about DB2... ;-)


>They decided to order a servpac (new at the time).
>They were a  big user of DB2 (I have no knowledge of it) but they were really 
>hurting in order to get up to snuff.

Were they backlevel at that stage or is it a matter to fix the applications 
inside DB2, then upgrade?


>They were non going to ORDER COBOL (current as it cost $5 more than the old) 
>then LE hit them in the face and they *HAD* to order that. That almost burst 
>their gut.

Ouch... And their clients? Were they suffering (unneeded downtime + loss of 
money and time) during these drama?

Oh, tell me, LE is a really hard beast to tame, but once you're there, all is 
fine ... until next major change...


>I am glad I got out of there.

I really would also be glad. I rather will not ask about their RACF, JES2, HSM, 
etc. status at that time... sounds scary...

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Edward Gould]

> On Nov 23, 2016, at 8:32 PM, Joel C. Ewing  wrote:
> 
> I think the car analogy with computer systems  breaks down on a number
> of points (at least in the case of mainframes):
>(1) while bleeding-edge-current is certainly not essential, the
> further you get behind on software maintenance, the more costly it gets
> in terms of time and person-hours to get reasonably current; and without
> being reasonably current you may not be able to utilize new hardware
> that could be more cost effective, or needed when old hardware dies, or
> needed to adapt to growing business requirements.  The  cost of failure
> to do preventive maintenance on a car is bounded by the time and cost
> for replacement transportation, no matter how much maintenance was skipped.
>(2)software maintenance relating to security or data exposures may
> need prompt attention to avoid much more expensive data loss or data
> exposure scenarios, which may also have serious legal implications. 
> Failure to do preventive maintenance on a car doesn't generally make it
> more susceptible to hackers or have legal implications, unless you fail
> to repair an obvious safety hazard and that results in a personal-injury
> accident or death..
>(3)Unexpected failures of a lesser-maintained car more often than
> not just causes a temporary loss of availability which with sufficient
> funds can be easily resolved, as there are many ready substitutes for
> the basic function of transportation.  A corporate computer system has
> company-specific data and company-specific applications which cannot
> just be replaced by any generic computer system, and it may be
> impossible for the company to stay in business very long without that
> data and those applications.  Recovery from some software failures that
> result in data loss is only possible with adequate DR planning in place,
> and if adequate planning was not in place, recovery may not even be
> possible at any price.  While I believe a valid argument can be made
> against applying maintenance just for the sake of maintenance, some of
> the problems addressed by HIPER PTFs are so dire you really don't want
> to wait for that failure to occur before installing the fix.
> 
> Even with a car, while it may be cost-effective to avoid or stretch out
> some preventive or recommended maintenance, I strongly suspect it would
> not on balance be cheaper for you to take that to the extreme and, say,
> never change the engine oil (unless of course your plan is to sell
> the.car after a few years without disclosing the potential shortened
> engine life and cheat the next owner).
>Joel C. Ewing
about 20 years ago I worked at such a place. They did NOT believe in applying 
maintenance.
Along comes the Y2K problem and they were in a bind (to say the least).
They decided to order a servpac (new at the time).
They were a  big user of DB2 (I have no knowledge of it) but they were really 
hurting in order to get up to snuff.
They were non going to ORDER COBOL (current as it cost $5 more than the old) 
then LE hit them in the face and they *HAD* to order that. That almost burst 
their gut.
I am glad I got out of there.
Ed 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Joel C. Ewing]

I think the car analogy with computer systems  breaks down on a number
of points (at least in the case of mainframes):
(1) while bleeding-edge-current is certainly not essential, the
further you get behind on software maintenance, the more costly it gets
in terms of time and person-hours to get reasonably current; and without
being reasonably current you may not be able to utilize new hardware
that could be more cost effective, or needed when old hardware dies, or
needed to adapt to growing business requirements.  The  cost of failure
to do preventive maintenance on a car is bounded by the time and cost
for replacement transportation, no matter how much maintenance was skipped.
(2)software maintenance relating to security or data exposures may
need prompt attention to avoid much more expensive data loss or data
exposure scenarios, which may also have serious legal implications. 
Failure to do preventive maintenance on a car doesn't generally make it
more susceptible to hackers or have legal implications, unless you fail
to repair an obvious safety hazard and that results in a personal-injury
accident or death..
(3)Unexpected failures of a lesser-maintained car more often than
not just causes a temporary loss of availability which with sufficient
funds can be easily resolved, as there are many ready substitutes for
the basic function of transportation.  A corporate computer system has
company-specific data and company-specific applications which cannot
just be replaced by any generic computer system, and it may be
impossible for the company to stay in business very long without that
data and those applications.  Recovery from some software failures that
result in data loss is only possible with adequate DR planning in place,
and if adequate planning was not in place, recovery may not even be
possible at any price.  While I believe a valid argument can be made
against applying maintenance just for the sake of maintenance, some of
the problems addressed by HIPER PTFs are so dire you really don't want
to wait for that failure to occur before installing the fix.

Even with a car, while it may be cost-effective to avoid or stretch out
some preventive or recommended maintenance, I strongly suspect it would
not on balance be cheaper for you to take that to the extreme and, say,
never change the engine oil (unless of course your plan is to sell
the.car after a few years without disclosing the potential shortened
engine life and cheat the next owner).
Joel C. Ewing

On 11/23/2016 11:33 AM, Jesse 1 Robinson wrote:
> When I get flak about the churn of staying current with maintenance, I climb 
> my soapbox. Look, I say, I've calculated that on balance it's cheaper to 
> drive your car as long as it runs rather than take in for periodic 
> maintenance, which is both time consuming and out-of-pocket costly. Most 
> likely it will fail somewhere down the road ;-) but getting it fixed then 
> will be cheaper and quicker overall.
>
> Well, I say, if you wouldn't think of managing your car that way, why would 
> you think it makes sense for a computer system? 
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of John McKown
> Sent: Wednesday, November 23, 2016 5:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):A true discussion in today's world (at least here)
>
> http://www.theregister.co.uk/2016/11/23/stay_out_of_my_server_room/
> [quote]
>
> Administrators spend a great deal of time doing preventative maintenance.
> Keeping the servers running doesn't mean putting out fires as they come, it 
> means planning for hypothetical scenarios with the resources available.
> This type of work doesn't immediately present a benefit, and when the time 
> comes to cut some chaff, perception is key.
>
> Management droids who've never experienced the pain of an outage might not 
> have the same respect for having the hardware on hand as you and me, and the 
> blame cannon is somehow never pointed at the penny-pincher who thought doing 
> without a support contract was an acceptable risk.
>
> [quote/]
>
> --
> Heisenberg may have been here.
>
> Unicode: http://xkcd.com/1726/
>
> Maranatha! <><
> John McKown
>
> ...


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Mike Schwab]

On Wed, Nov 23, 2016 at 12:51 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On 2016-11-23, at 10:33, Jesse 1 Robinson wrote:
>
>> When I get flak about the churn of staying current with maintenance, I climb 
>> my soapbox. Look, I say, I've calculated that on balance it's cheaper to 
>> drive your car as long as it runs rather than take in for periodic 
>> maintenance, which is both time consuming and out-of-pocket costly. Most 
>> likely it will fail somewhere down the road ;-) but getting it fixed then 
>> will be cheaper and quicker overall.
>>
>> Well, I say, if you wouldn't think of managing your car that way, why would 
>> you think it makes sense for a computer system?
>>
> A fortiori, don't apply that reasoning to spacecraft.  Perhaps not even to 
> airliners.
>
> -- gil

Alaska Airlines did.  Cut lubrication schedule, cancelled replacement
of worn out parts.  Until
https://en.wikipedia.org/wiki/Alaska_Airlines_Flight_261

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Tony Harminc]

On 23 November 2016 at 12:33, Jesse 1 Robinson  wrote:
> When I get flak about the churn of staying current with maintenance, I climb 
> my soapbox. Look, I say, I've calculated that on balance it's cheaper to 
> drive your car as long as it runs rather than take in for periodic 
> maintenance, which is both time consuming and out-of-pocket costly. Most 
> likely it will fail somewhere down the road ;-) but getting it fixed then 
> will be cheaper and quicker overall.
>
> Well, I say, if you wouldn't think of managing your car that way, why would 
> you think it makes sense for a computer system?

The analogy is cute, but I think it fails The problem is that in some
circumstances that's a perfectly reasonable way to manage a car.
Depending on the age, how much you depend on it, whether you ever
drive a significant distance from home, etc. etc. there may be nothing
wrong with deferring or not doing some maintenance.

I live in a city, mostly walk or use transit, and I have very little
need for reliability in a car. So generally on my cars I do oil
changes and have safety systems (e.g. brakes) inspected and serviced
*as necessary*, but otherwise I do "drive it as long as it runs". This
works for me and the way I use a car; obviously not so well for
someone who lives in a rural area, drives a long commute to work,
and/or has no easy backup options for transport.

There is even a credible argument that many kinds of so-called
preventative maintenance cause more harm than good. For example,
taking apart and repacking a wheel bearing on a routine periodic basis
may well cause earlier failure than leaving it alone. It depends.

If you want the best possible reliability from a car (which is not, of
course, the only reasonable goal), probably the semiconductor
"bathtub" curve roughly applies: you should buy one that is past its
"burn-in" period, but not too much, and then keep it only until some
time before it reaches its predicted wear-out failure rate increase.
I'm guessing these numbers would be perhaps 3 months and 24 months, or
equivalent distance travelled, respectively.
https://en.wikipedia.org/wiki/Bathtub_curve   But little if any of
this applies to software.

[There is a lot of stuff on Google about maintenance and cost/benefit
analysis as applied to various kinds of hardware, typically industrial
machinery and of course aircraft. Unfortunately a great deal of it is
written by people whose business it is to sell the benefits of PM, so
it takes very careful reading, even of academic articles.]

There's also a very good argument that calling software fixes and
their application "maintenance" is a logical or category error.
Software does not "wear out" the way hardware does, and it also cannot
be replaced to solve a problem (at least in the sense of installing an
identical new copy as you can with a car or an aircraft engine), but
rather *must* be fixed.

Please note that I am *not at all* saying that routine fixes should
not be applied to software, or that the management attitudes you
complain of are good. It's the analogy I'm quibbling with, not good
software practice.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Paul Gilmartin]

On 2016-11-23, at 10:33, Jesse 1 Robinson wrote:

> When I get flak about the churn of staying current with maintenance, I climb 
> my soapbox. Look, I say, I've calculated that on balance it's cheaper to 
> drive your car as long as it runs rather than take in for periodic 
> maintenance, which is both time consuming and out-of-pocket costly. Most 
> likely it will fail somewhere down the road ;-) but getting it fixed then 
> will be cheaper and quicker overall.
> 
> Well, I say, if you wouldn't think of managing your car that way, why would 
> you think it makes sense for a computer system? 
> 
A fortiori, don't apply that reasoning to spacecraft.  Perhaps not even to 
airliners.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL: Re: A true discussion in today's world (at least here)

[Jerry Whitteridge]

I like it and plan to use the same analogy.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
623 869 5523
Corporate Tieline - 85523

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, November 23, 2016 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: A true discussion in today's world (at least here)

When I get flak about the churn of staying current with maintenance, I climb my 
soapbox. Look, I say, I've calculated that on balance it's cheaper to drive 
your car as long as it runs rather than take in for periodic maintenance, which 
is both time consuming and out-of-pocket costly. Most likely it will fail 
somewhere down the road ;-) but getting it fixed then will be cheaper and 
quicker overall.

Well, I say, if you wouldn't think of managing your car that way, why would you 
think it makes sense for a computer system?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, November 23, 2016 5:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):A true discussion in today's world (at least here)

http://www.theregister.co.uk/2016/11/23/stay_out_of_my_server_room/
[quote]

Administrators spend a great deal of time doing preventative maintenance.
Keeping the servers running doesn't mean putting out fires as they come, it 
means planning for hypothetical scenarios with the resources available.
This type of work doesn't immediately present a benefit, and when the time 
comes to cut some chaff, perception is key.

Management droids who've never experienced the pain of an outage might not have 
the same respect for having the hardware on hand as you and me, and the blame 
cannon is somehow never pointed at the penny-pincher who thought doing without 
a support contract was an acceptable risk.

[quote/]

--
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Jesse 1 Robinson]

When I get flak about the churn of staying current with maintenance, I climb my 
soapbox. Look, I say, I've calculated that on balance it's cheaper to drive 
your car as long as it runs rather than take in for periodic maintenance, which 
is both time consuming and out-of-pocket costly. Most likely it will fail 
somewhere down the road ;-) but getting it fixed then will be cheaper and 
quicker overall.

Well, I say, if you wouldn't think of managing your car that way, why would you 
think it makes sense for a computer system? 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, November 23, 2016 5:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):A true discussion in today's world (at least here)

http://www.theregister.co.uk/2016/11/23/stay_out_of_my_server_room/
[quote]

Administrators spend a great deal of time doing preventative maintenance.
Keeping the servers running doesn't mean putting out fires as they come, it 
means planning for hypothetical scenarios with the resources available.
This type of work doesn't immediately present a benefit, and when the time 
comes to cut some chaff, perception is key.

Management droids who've never experienced the pain of an outage might not have 
the same respect for having the hardware on hand as you and me, and the blame 
cannon is somehow never pointed at the penny-pincher who thought doing without 
a support contract was an acceptable risk.

[quote/]

--
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

A true discussion in today's world (at least here)

[John McKown]

http://www.theregister.co.uk/2016/11/23/stay_out_of_my_server_room/
[quote]

Administrators spend a great deal of time doing preventative maintenance.
Keeping the servers running doesn't mean putting out fires as they come, it
means planning for hypothetical scenarios with the resources available.
This type of work doesn't immediately present a benefit, and when the time
comes to cut some chaff, perception is key.

Management droids who've never experienced the pain of an outage might not
have the same respect for having the hardware on hand as you and me, and
the blame cannon is somehow never pointed at the penny-pincher who thought
doing without a support contract was an acceptable risk.

[quote/]

-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN