I think you are mis-interpreting the remarks from by IBM. "Not wanting
to diagnose problems caused by" does not mean the object is "to protect
IBM". It simply means a desire to not waste resources pursuing unique
and avoidable problems when those resources could be better used to
solve real problems for its customers.
MVS is not like MicroSoft's Operating Systems, which are certainly not
known for data integrity or security. One of the consequences of
"unpredictable action" can be data loss or security exposures, and this
is simply not acceptable on an Operating system like MVS, where such
failures are taken seriously. I side with IBM on this one. The wait
state codes are probably the only level appropriate for such a problem,
because loading enough of the system to bring up enough of the I/O
support to write a more user-friendly message somewhere could also risk
damage to the DASD farm when you have no idea how serious of a problem
exists.
A new z/OS release always requires new IPLTEXT installation. Any
maintenance that requires it should have PTF HOLD data informing of that
need, and if you ignore the HOLD data that's your fault. If
maintenance that requires IPLTEXT rebuild is missing the required HOLD
in the PTF, then you have a legitimate issue with IBM; but the correct
resolution is to fix the HOLD information.
Joel C Ewing
On 09/30/2010 01:46 AM, Tidy, David (D) wrote:
Hi,
We have our sandbox system where we run SMP/E - and it's the only system
where SMP/E is installed. We do choose to apply maintenance on this
running system in general (yes - we know that this may not be the
recommended approach). It's a bit theoretical, but should someone manage
to apply an RSU, and for some reason not have reviewed/understood the
holddata correctly, then we IPL that system to test the maintenance (and
because it is officially 'unstable' between maintenance application and
IPL). 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).
I would prefer the system to issue a warning message + logrec - best of
all a WTO prompt saying the system will struggle on, but at extreme risk
and no applications should be started until the system is reIPLed
correctly. I fear this might start off some other discussion, and I know
the scope and impact and risk is totally different, 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.
As I said - it doesn't particularly affect us, but for some it might be
possible that they can't run the ICKDSF job appropriately - and by
artificially ensuring that the system won't come up in any shape, you
are removing one potential capability of an environment to run that one
job in certain system configurations. And the reason I triggered was
because I don't like the reason "to protect IBM" in this context. I
supppose it is also like instances where customers might choose to run
unsupported, but a vendor puts a block in the product to stop it running
after EOS date, even though it might technically otherwise still work
for a customers needs.
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 Jim Mulder
Sent: 29 September 2010 19:44
To: IBM-MAIN@bama.ua.edu
Subject: Re: IPLTEXT and NUCLEUS dates
IBM Mainframe Discussion List<IBM-MAIN@bama.ua.edu> wrote on 09/29/2010
02:50:34 AM:
Although this isn't too much of a risk for us, I do have to say that
protecting IBM from having to diagnose my problems by putting my SMP/E
system into a wait state doesn't quite match what I would hope for as
a
customer.
I don't understand what you mean by "putting your SMP/E system
into a wait state". The wait state occurs when IPLing the
improperly built sysres, not while running SMP/E.
How would you prefer the system to behave when it detects
mismatched code levels at IPL due to incomplete installation
of maintenance, which could lead to unpredictable and possibly
disastrous results?
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
--
Joel C. Ewing, Fort Smith, AR jcew...@acm.org
----------------------------------------------------------------------
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
