On 09/30/2010 08:36 PM, Clark Morris wrote:
On 30 Sep 2010 08:23:14 -0700, in bit.listserv.ibm-main you wrote:
On 09/30/10 09:32, Joel C. Ewing wrote:
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
Learning from the school of hard knocks, whenever I build a new
environment I always reassemble all JES2 exits with the macro libraries
that are on the new sysres, using steplibs so I also utilize the new
assembler and binder executables. Is it necessary, not always but can't
hurt. In the same vain I always write the latest IPLTEXT onto the volume
whether it needs it or not.
Why the heck should IPLTEXT change from release to release? All it
has to do is load SYS1.NUCLEUS and transfer to it. The only change
that should have been necessary is support of large volumes.
Clark Morris
<snip>
...
Good point. I have no idea whether there is actually a frequent need to
make a functional change in the IPLTEXT or if 99.9% of the changes are
just to match dates with Nucleus. If the later, then the Nucleus and
IPLTEXT should obviously contain something that indicates an IPLTEXT
version required by the Nucleus that could be verified instead of the
date, and a differently dated nucleus that still requires the same
IPLTEXT functional level could still indicate the old IPLTEXT version.
That way the IPL process could validate IPLNEXT/nucleus compatibility
without requiring a date match, and the need to update IPLTEXT would be
minimized.
--
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
