MCLs for z/VM 5.2

[Les Geer (607-429-3580)]

>Our hardware people tell us that J13846.106 is on our z/900 and that the
>other 2 are scheduled for activation on April 2. They also say that they
>have checked the other two and they do not affect anything that we use,
>so it is OK to go ahead and roll 5.2 out before they are activated. What
>say you Les (or surrogate)? Are the MCLs limited enough in scope that
>this could be true?
>

Maybe I created some confusion when I said the MCLs where in the base
of z9. I meant they are in the base of z9-109.


The three MCLs:

- Are not applicable to z800 or z900
- Must be applied to z890 and z990
- Are in the base of z9-109



MCL J13484.112 --> This one must be applied before IPLing z/VM 5.2
MCL J13486.106 --> This has to do with IPLing from SCSI
MCL J13471.007 --> This has to do with the SCSI environment.

So, if you are not using SCSI, only J13484.112 must be applied.

This corrects problems we encountered while testing z/VM 5.2 on
a z990. It has to do with new z990/890 facilities z/VM is taking
advantage of with 5.2 (and not on previous release's). When we went
up on one of our internal production systems, this MCL was not applied
and the system continued to take outages until the MCL was finally
applied. You would not be able to tell how z/VM 5.2 uses these
facilities.


I cannot stress enough the need for this MCL to be applied. It can be
very time consuming to trace outages back to the lack of this MCL


Best Regards,
Les Geer
IBM z/VM and Linux Development

[Alan Ackerman]

You need J13484.112 on if you use data spaces. We got bit by that pretty hard -- data corruption
in the DB2 catalog so bad that DB2 wold not even come up. We didn't have any problems IPLing.

On Fri, 3 Feb 2006 13:04:59 -0800, Schuh, Richard <***@visa.com> wrote:

>Les Geer posted the following dire warning:
>
> Before you attempt to IPL z/VM 5.2 on the z890 (and z990), please ensure you have
applied the following MCLs:
> MCL J13484.112
> MCL J13486.106
> MCL J13471.007
>
>
> You will avoid possible outages and expensive debug of such.
> These MCLs are in the base of z9-109
> Best Regards,
> Les Geer
> IBM z/VM and Linux Development
>
>
>
>Our hardware people tell us that J13846.106 is on our z/900 and that the other 2 are scheduled
for activation on April 2. They also say that they have checked the other two and they do not affect
anything that we use, so it is OK to go ahead and roll 5.2 out before they are activated. What say
you Les (or surrogate)? Are the MCLs limited enough in scope that this could be true?
>
>Regards,
>Richard Schuh
>===========================================================
=============

[Bill Holder]

On Tue, 7 Feb 2006 00:19:49 -0600, Alan Ackerman
<***@BANKOFAMERICA.COM> wrote:

>You need J13484.112 on if you use data spaces. We got bit by that pretty
hard -- data corruption
>in the DB2 catalog so bad that DB2 wold not even come up. We didn't have
any problems IPLing.
>


MCL J13484.112 is required whether or not data spaces are used, though the
problem is indeed exposed by DB2's use of data spaces (which actually uses
the base space of the DB2 server virtual machine quite heavily). The
problem fixed in J13484.112 is not data space specific; for example, the
data space exploitation in SFS (DIRCONTROL directories) may be affected
differently or not at all (though I certainly would not recommend risking it
without J13484.112). All I'm completely sure of is that I'm really not
interested in having to debug any more occurrences of problems caused by the
lack of MCL J13484.112!

:-)

- Bill Holder, z/VM CP Development, IBM

[Schuh, Richard]

I concur. The MCLs are scheduled for 5 March, the 1st VM to be converted following that, and our main VM on 18 March.

Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Bill Holder
Sent: Wednesday, February 08, 2006 10:58 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: MCLs for z/VM 5.2

On Tue, 7 Feb 2006 00:19:49 -0600, Alan Ackerman
<***@BANKOFAMERICA.COM> wrote:

>You need J13484.112 on if you use data spaces. We got bit by that prett=
y
hard -- data corruption
>in the DB2 catalog so bad that DB2 wold not even come up. We didn't have=

any problems IPLing.
>


MCL J13484.112 is required whether or not data spaces are used, though th=
e
problem is indeed exposed by DB2's use of data spaces (which actually use=
s
the base space of the DB2 server virtual machine quite heavily). The
problem fixed in J13484.112 is not data space specific; for example, the
data space exploitation in SFS (DIRCONTROL directories) may be affected
differently or not at all (though I certainly would not recommend risking=
it
without J13484.112). All I'm completely sure of is that I'm really not
interested in having to debug any more occurrences of problems caused by =
the
lack of MCL J13484.112!

:-)

- Bill Holder, z/VM CP Development, IBM

[Bill Holder]

As Karl Malden would say, "Don't leave home without it!" :)

[Rich Smrcina]

Isn't that what normally happens at SCIDS anyway?

Nick Laflamme wrote:
>
>
> I'm picturing a really geeky exchange at SCIDS in Seattle next month....
>

--
Rich Smrcina
VM Assist, Inc.
Main: [phone]
Cell: [phone]
Ans Service: [phone]
rich.smrcina at vmassist.com

Catch the WAVV! http://www.wavv.org
WAVV 2006 - Chattanooga, TN - April 7-11, 2006

[Nick Laflamme]

Bill Holder wrote:
> As Karl Malden would say, "Don't leave home without it!" :)

The service processors now support USB keys?

I'm picturing a really geeky exchange at SCIDS in Seattle next month....

[Schuh, Richard]

We had already decided that the MCLs will be activated before trying to install z/VM 5.2.

Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Les Geer (607-429-3580)
Sent: Wednesday, February 08, 2006 11:26 AM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: MCLs for z/VM 5.2

>> MCL J13484.112 is required whether or not data spaces are used, though
>the
>> problem is indeed exposed by DB2's use of data spaces (which actually
>uses
>> the base space of the DB2 server virtual machine quite heavily).
>
>To put a finer point on it, please oh please put all of the previously
>referenced MCLs on the box before you run z/VM 5.2.
>
>Hardware problems often manifest themselves in ways that make it difficult
>for us to quickly say "Oh, THAT. That's caused by lack of MCL xyz." So
>we end up spinning our wheels on problem determination. We'd much rather
>work on *new* problems rather than ones we already solved. :-)
>
>We're serious enough about this that we're discussing how to put checks
>for pre-req MCLs into system initialization so the system won't run if a
>required MCL isn't applied!
>

A further spin on this, we cannot predict the characteristics of
workloads which will cause outages without MCL J13484.112 (or any of
the other listed MCLs) applied. Just because DB2 is not being used,
or the fact 5.2 IPLs cleanly and runs without problems, doesn't
mean you will not take an outage without the MCL applied.
Please, just apply them. They do apply concurrently.


Best Regards,
Les Geer
IBM z/VM and Linux Development

[Les Geer (607-429-3580)]

>> MCL J13484.112 is required whether or not data spaces are used, though
>the
>> problem is indeed exposed by DB2's use of data spaces (which actually
>uses
>> the base space of the DB2 server virtual machine quite heavily).
>
>To put a finer point on it, please oh please put all of the previously
>referenced MCLs on the box before you run z/VM 5.2.
>
>Hardware problems often manifest themselves in ways that make it difficult
>for us to quickly say "Oh, THAT. That's caused by lack of MCL xyz." So
>we end up spinning our wheels on problem determination. We'd much rather
>work on *new* problems rather than ones we already solved. :-)
>
>We're serious enough about this that we're discussing how to put checks
>for pre-req MCLs into system initialization so the system won't run if a
>required MCL isn't applied!
>

A further spin on this, we cannot predict the characteristics of
workloads which will cause outages without MCL J13484.112 (or any of
the other listed MCLs) applied. Just because DB2 is not being used,
or the fact 5.2 IPLs cleanly and runs without problems, doesn't
mean you will not take an outage without the MCL applied.
Please, just apply them. They do apply concurrently.


Best Regards,
Les Geer
IBM z/VM and Linux Development

[Tony Harminc]

On Wed 8 February, 2006 14:16 Alan Altmark wrote:

> We're serious enough about this that we're discussing how to
> put checks for pre-req MCLs into system initialization so the
> system won't run if a required MCL isn't applied!

You could go a step further, and include the ucode in CP, and then load any
missing maintenance as needed.

Hmmm... I remember suggesting this at a SHARE around 1980 for 168/3033
machines, which did have an instruction for dynamic microcode loading.
No-one seemed to like the idea.

Tony H.

[Raymond Noal]

Dear Chuckie,

To quote -

As soon as all the world's governments unite under a single authority
(to wit, Chuckie), we'll ship microcode updates with VM. ;-)

This has been done for several decades, if not longer. The "single
authority" you seek is - MONEY !!

So, when can we expect you to start shipping u-code updates with z/VM ??
EH ??

HITACHI
DATA SYSTEMS

Raymond E. Noal
Lab Manager, San Diego Facility
Office: (858) 537 - 3268
Cell: (858) 248 - 1172


-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On
Behalf Of Alan Altmark
Sent: Wednesday, February 08, 2006 2:50 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: MCLs for z/VM 5.2

On Wednesday, 02/08/2006 at 05:25 EST, Tony Harminc
<***@attglobal.net>
wrote:
> You could go a step further, and include the ucode in CP, and then
load
any
> missing maintenance as needed.

Actually, no we can't. We sell hardware and we sell software. Never
the
twain shall meet. Governments and lawyers - who needs 'em? :-)

As soon as all the world's governments unite under a single authority
(to
wit, Chuckie), we'll ship microcode updates with VM. ;-)

Alan Altmark
z/VM Development
IBM Endicott

[Adam Thornton]

On Feb 8, 2006, at 4:49 PM, Alan Altmark wrote:
> As soon as all the world's governments unite under a single
> authority (to
> wit, Chuckie)

...we will all have been fed to the lions anyway, and therefore won't
really care about microcode updates.

Adam

[Gary Eheman]

On Wed, 8 Feb 2006 18:11:03 -0500, Alan Altmark <***@us.ibm.com> wrote:


>Hah! I scoff in your general direction. If you're going to INSIST on an
>actual message, I'd rather have
> HCPMCL0028W HARDWARE ERROR
>(Though I don't know what's wrong with just a wait state code!)
>
>Message: HCPMCL0028W HARDWARE ERROR
>
>Explanation: There is an error in the hardware.
>
>System Action: Issue message HCPMCL0028W HARDWARE ERROR. I mean, really,
>did we have to say it?
>
>User or Operator Response: The users will only know the system is down and
>that it is an attempt to sabotage their work.

<snip>

>
>Chuckie
>=========================================================================

Dang, Chuckie. Talk about cruel. This would certainly start a wild goose
chase in the PCM biz. Hardware error? NOT! :-)

--
Gary Eheman
Fundamental Software, Inc.
http://www.funsoft.com