SSKE is not a facto for the way that z/VM uses Crypto. This would only affect z/OS using ICSF. If you have a z/OS guest that has a queue / domain dedicated, you will want to take a look at this.
____________________________________ Rick Barlow Senior z/VM Systems Programmer Nationwide Services Co., Web-zLinux Support, z/VM and System z Linux Support One Nationwide Plaza MB-02-201 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5213 Fax: (614) 249-3912 mailto:[EMAIL PROTECTED] The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> wrote on 10/29/2007 12:38:08 PM: > IBMVM@LISTSERV.UARK.EDU > > I just received a note from our h/w folks asking if VM is > susceptible to this problem: > CMOS MCL FIX G40963.045 > > Release Date: 2007/10/17 > > Alert: HIPER > > MCL installation: NONDISRUPTIVE > > MCL contents: > This fix addresses an issue that can result in a system checkstop > (SRC 24310002 9801Cxxx). The issue involves use of the "conditional- > SSKE facility" (conditional-Set Storage Key Extended facility). The > issue can occur during a very narrow timing window when SSKE > operations are simultaneously executing on multiple processors. > Exposure to the issue exists when the conditional-SSKE facility is > supported by the machine and the operating system exploits the > conditional-SSKE facility. Driver-67L provides machine support for > the conditional-SSKE facility. The RSM (Real Storage Manager) > component of z/OS 1.7 (with PTF UA24272), 1.8 and 1.9 exploit the > conditional-SSKE facility. As such, z9 systems at Driver-67L and > running z/OS 1.7 (with PTF UA24272), 1.8 or 1.9 are exposed to this > issue. The conditional-SSKE facility is described in "z/Architecture > Principles of Operation" (SA22-7832-05). > Just having returned to work following a bout with the flu, I > thought I would take the path of expedience and ask the list. My > inbox is full of unread mail, so I have plenty to do today without > having to dig too deeply into HIPER MCLs. > Regards, > Richard Schuh
