I for one cannot believe that this thread is still going on.   A lot of
effort being expended to argue why or why not something should happen
for something that takes 20 seconds to run if you just include it as
part of a normal process.  Remember that old saying? "if it hurts, don't
do it".

_________________________________________________________________
Dave Jousma
Assistant Vice President, Mainframe Services
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB1G
p 616.653.8429
f 616.653.8497


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Tidy, David (D)
Sent: Thursday, September 30, 2010 4:41 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IPLTEXT and NUCLEUS dates

It is true that there is some exposure in our maintenance strategy.
However we always have multiple versions of our cloned sysres availabe
to IPL from, and we do have a backup strategy to get back to the
pre-maintenance level. That's why I keep saying the wait state itself is
not really an issue for us. My issue is a potentially unnecessary wait
state for a reason of vendor comfort as opposed to other strategies
(e.g. strongly worded WTO) which seems a little less artificial to me if
we're talking about maximising vendor convenience. And I do write solely
from the customer perspective. I admit(ted) the workstation analogy to
be a different scope/impact, although we are looking at the autoipl
statement to be our restart button...  


Best regards,
David Tidy                              
IS Technical Management/SAP-Mf                  
Dow Benelux B.V.                                

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Barbara Nitz
Sent: 30 September 2010 09:17
To: IBM-MAIN@bama.ua.edu
Subject: Re: IPLTEXT and NUCLEUS dates

>That is the IPL that could put us in a wait state. However in our
>case we would be able to create the IPL text appropriately from another
>system in this particular event (that is why I say it is not such a
risk
>for us).
>....
> but for some it might be
>possible that they can't run the ICKDSF job appropriately 

Then they have a wrong maintenance strategy in the first place, IMO. The

thing to do is keep the old system residence (the one that works) around
so 
that it can be re-IPL'd without any changes. Then there is a system
where the 
ICKDSF job can be run from.

>because I don't like the reason "to protect IBM" in this context.
You would, too, if you had had (repeatedly) to look at sadumps where 
something was so much wrong that the system later wait states on some 
seemingly completely unrelated thing that takes forever to debug because
the 
root cause was mismatch in ipltext and nucleus.

>but when I get a
>Windows message saying I must reboot my workstation or the system may
>become unstable, I carry on working, and I've never had cause to regret
>that approach.
z/OS isn't something clickable (yet).

Barbara Nitz

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to