System z & Meltdown/Spectre

[R.S.]

IBM is very unclear here.
Assuming the z processor is vulnerable - how wide the vulnerability is?
Let's assume one has 4 LPARs, and one is Linux with some poorly
controlled application code - Can such code affect security of other
LPARs systems?

In simple words: what about FIPS-certified LPAR isolation???

(BTW: it's not known the z CPU is vulnerable, the above is only logical
assumtion.)

--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Sankaranarayanan, Vignesh]

Hi,

If you sign up for the System z Security Portal, the notice pertaining this vuln will be updated with more details over time.
Right now, it has some detail, but we'll surely see more info soon.

- Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of R.S.
Sent: 10 January 2018 03:11
To: IBM-***@LISTSERV.UA.EDU
Subject: System z & Meltdown/Spectre

IBM is very unclear here.
Assuming the z processor is vulnerable - how wide the vulnerability is?
Let's assume one has 4 LPARs, and one is Linux with some poorly controlled application code - Can such code affect security of other LPARs systems?

In simple words: what about FIPS-certified LPAR isolation???

(BTW: it's not known the z CPU is vulnerable, the above is only logical
assumtion.)

--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone [phone]
Facsimile [phone]

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Dana Mitchell]

IBM Security notification SN-2018-001 was updated yesterday with some Linux and z/VM info. Further mitigation details for z/OS will be released as they become available.

Dana

On Wed, 10 Jan 2018 00:14:10 +0000, Sankaranarayanan, Vignesh <***@MARKS-AND-SPENCER.COM> wrote:

>Hi,
>
>If you sign up for the System z Security Portal, the notice pertaining this vuln will be updated with more details over time.
>Right now, it has some detail, but we'll surely see more info soon.
>
>- Vignesh
>Mainframe Infrastructure
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Sankaranarayanan, Vignesh]

Considering the inefficient exceution path, I wonder how much higher the CPU % will be for z/VM, z/OS, etc.
And more importantly, how it affects 4HRA, and $$$.

If there's a significant CPU hit, maybe shave some % off the top of the bill, after seeing before and after MSU numbers at each customer site?

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Dana Mitchell
Sent: 10 January 2018 21:59
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre

IBM Security notification SN-2018-001 was updated yesterday with some Linux and z/VM info. Further mitigation details for z/OS will be released as they become available.

Dana

On Wed, 10 Jan 2018 00:14:10 +0000, Sankaranarayanan, Vignesh <***@MARKS-AND-SPENCER.COM> wrote:

>Hi,
>
>If you sign up for the System z Security Portal, the notice pertaining this vuln will be updated with more details over time.
>Right now, it has some detail, but we'll surely see more info soon.
>
>- Vignesh
>Mainframe Infrastructure
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone [phone]
Facsimile [phone]

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Pommier, Rex]

And what does "a significant CPU hit" mean for those of us who's 4HRA is already at the top of our machine's capacity? That's where my concern is. Yeah, the money for increasing MSUs is gonna stink, but missing SLAs due to the box no longer being big enough is going to really bite.

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh
Sent: Wednesday, January 10, 2018 10:41 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre

Considering the inefficient exceution path, I wonder how much higher the CPU % will be for z/VM, z/OS, etc.
And more importantly, how it affects 4HRA, and $$$.

If there's a significant CPU hit, maybe shave some % off the top of the bill, after seeing before and after MSU numbers at each customer site?

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Dana Mitchell
Sent: 10 January 2018 21:59
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre

IBM Security notification SN-2018-001 was updated yesterday with some Linux and z/VM info. Further mitigation details for z/OS will be released as they become available.

Dana

On Wed, 10 Jan 2018 00:14:10 +0000, Sankaranarayanan, Vignesh <***@MARKS-AND-SPENCER.COM> wrote:

>Hi,
>
>If you sign up for the System z Security Portal, the notice pertaining this vuln will be updated with more details over time.
>Right now, it has some detail, but we'll surely see more info soon.
>
>- Vignesh
>Mainframe Infrastructure
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone [phone]
Facsimile [phone]

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Dana Mitchell]

If it's a big enough hit, perhaps IBM would redo LSPR tests and adjust tables accordingly. They probably wouldn't re-test anything older than the current generation of machines on the floor, but they could apply the adjustments to previous generations (if so inclined...)

On Wed, 10 Jan 2018 16:40:54 +0000, Sankaranarayanan, Vignesh <***@MARKS-AND-SPENCER.COM> wrote:

>Considering the inefficient exceution path, I wonder how much higher the CPU % will be for z/VM, z/OS, etc.
>And more importantly, how it affects 4HRA, and $$$.
>
>If there's a significant CPU hit, maybe shave some % off the top of the bill, after seeing before and after MSU numbers at each customer site?
>
>– Vignesh
>Mainframe Infrastructure
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[R.S.]

1. Older generations (z10, z9...) are not affected.

2. Let's assume one uses EC12 which is affected. Let's assume after the
vulnerability is fixed the capacity went down up to 10%.
Or 20%. 20% is a lot. Now, what about customer who decided to NOT apply
the patch just to have better performance?
Would/should IBM use dual tables, for machines with or without the patch?
BTW: It's worth to remember chances the vulnerability would really
compromise system security are really small. (IMHO)

--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-10 o 18:10, Dana Mitchell pisze:
> If it's a big enough hit, perhaps IBM would redo LSPR tests and adjust tables accordingly. They probably wouldn't re-test anything older than the current generation of machines on the floor, but they could apply the adjustments to previous generations (if so inclined...)
>
> On Wed, 10 Jan 2018 16:40:54 +0000, Sankaranarayanan, Vignesh <***@MARKS-AND-SPENCER.COM> wrote:
>
>> Considering the inefficient exceution path, I wonder how much higher the CPU % will be for z/VM, z/OS, etc.
>> And more importantly, how it affects 4HRA, and $$$.
>>
>> If there's a significant CPU hit, maybe shave some % off the top of the bill, after seeing before and after MSU numbers at each customer site?
>>
>> – Vignesh
>> Mainframe Infrastructure
>>
>

======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Paul Gilmartin]

On Wed, 10 Jan 2018 17:31:37 +0000, Pommier, Rex wrote:

>And what does "a significant CPU hit" mean for those of us who's 4HRA is already at the top of our machine's capacity? That's where my concern is. Yeah, the money for increasing MSUs is gonna stink, but missing SLAs due to the box no longer being big enough is going to really bite.
>
There's a cynical suspicion that when a vendor sees defect repair as a profit center
it provides a disincentive to quality.

This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."

In fairness, we don't know what IBM plans to do.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Pommier, Rex]

Gil,

I don't think this one is necessarily a quality issue. As widespread as the problem is, it appears to me to be more of a huuuge oversight. That said, you are correct in that we don't know what IBM plans to do, or for that matter, even how much of an impact fixing this will be on performance of z/OS. My concern is that since we (as well as probably many of the sites on this board) are bumping against our cap and if we get hit by even a 10% reduction in thruput from this, we're in danger of missing SLAs and other fun TLAs.

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, January 10, 2018 11:52 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre

On Wed, 10 Jan 2018 17:31:37 +0000, Pommier, Rex wrote:

>And what does "a significant CPU hit" mean for those of us who's 4HRA is already at the top of our machine's capacity? That's where my concern is. Yeah, the money for increasing MSUs is gonna stink, but missing SLAs due to the box no longer being big enough is going to really bite.
>
There's a cynical suspicion that when a vendor sees defect repair as a profit center
it provides a disincentive to quality.

This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."

In fairness, we don't know what IBM plans to do.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Mike Schwab]

Yep. I know my site didn't purchase upgrades until running at 100%
all weekday long would slow down batch runs by 4X elapsed time
compared to 90%.

On Wed, Jan 10, 2018 at 1:15 PM, Pommier, Rex <***@sfgmembers.com> wrote:
> Gil,
>
> I don't think this one is necessarily a quality issue. As widespread as the problem is, it appears to me to be more of a huuuge oversight. That said, you are correct in that we don't know what IBM plans to do, or for that matter, even how much of an impact fixing this will be on performance of z/OS. My concern is that since we (as well as probably many of the sites on this board) are bumping against our cap and if we get hit by even a 10% reduction in thruput from this, we're in danger of missing SLAs and other fun TLAs.
>
> Rex
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
> Sent: Wednesday, January 10, 2018 11:52 AM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: System z & Meltdown/Spectre
>
> On Wed, 10 Jan 2018 17:31:37 +0000, Pommier, Rex wrote:
>
>>And what does "a significant CPU hit" mean for those of us who's 4HRA is already at the top of our machine's capacity? That's where my concern is. Yeah, the money for increasing MSUs is gonna stink, but missing SLAs due to the box no longer being big enough is going to really bite.
>>
> There's a cynical suspicion that when a vendor sees defect repair as a profit center
> it provides a disincentive to quality.
>
> This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."
>
> In fairness, we don't know what IBM plans to do.
>
> -- gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Rugen, Len]

I wonder if the microcode has a little "detuning" so that if they ever have to make patches that would slow down the system, they can remove a little of the detuning to get back to base performance.


Len Rugen

University of Missouri
Division of Information Technology
Systems & Operations - Metrics & Automation Team
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Mike Schwab <***@GMAIL.COM>
Sent: Wednesday, January 10, 2018 8:55:07 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: System z & Meltdown/Spectre

Yep. I know my site didn't purchase upgrades until running at 100%
all weekday long would slow down batch runs by 4X elapsed time
compared to 90%.

On Wed, Jan 10, 2018 at 1:15 PM, Pommier, Rex <***@sfgmembers.com> wrote:
> Gil,
>
> I don't think this one is necessarily a quality issue. As widespread as the problem is, it appears to me to be more of a huuuge oversight. That said, you are correct in that we don't know what IBM plans to do, or for that matter, even how much of an impact fixing this will be on performance of z/OS. My concern is that since we (as well as probably many of the sites on this board) are bumping against our cap and if we get hit by even a 10% reduction in thruput from this, we're in danger of missing SLAs and other fun TLAs.
>
> Rex
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
> Sent: Wednesday, January 10, 2018 11:52 AM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: System z & Meltdown/Spectre
>
> On Wed, 10 Jan 2018 17:31:37 +0000, Pommier, Rex wrote:
>
>>And what does "a significant CPU hit" mean for those of us who's 4HRA is already at the top of our machine's capacity? That's where my concern is. Yeah, the money for increasing MSUs is gonna stink, but missing SLAs due to the box no longer being big enough is going to really bite.
>>
> There's a cynical suspicion that when a vendor sees defect repair as a profit center
> it provides a disincentive to quality.
>
> This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."
>
> In fairness, we don't know what IBM plans to do.
>
> -- gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Mike Schwab]

Unless you bought full speed processor, yes there is room for
improvement. But the waits for data count toward your reduce CPU
costs. I.E. a full speed CPU sees delays due to waiting, versus a
slower processor counts those delays toward the reduced CPU speed.

On Wed, Jan 10, 2018 at 9:34 PM, Rugen, Len <***@missouri.edu> wrote:
> I wonder if the microcode has a little "detuning" so that if they ever have to make patches that would slow down the system, they can remove a little of the detuning to get back to base performance.
>
>
> Len Rugen
>
> University of Missouri
> Division of Information Technology
> Systems & Operations - Metrics & Automation Team
> ________________________________
> From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Mike Schwab <***@GMAIL.COM>
> Sent: Wednesday, January 10, 2018 8:55:07 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: System z & Meltdown/Spectre
>
> Yep. I know my site didn't purchase upgrades until running at 100%
> all weekday long would slow down batch runs by 4X elapsed time
> compared to 90%.
>
> On Wed, Jan 10, 2018 at 1:15 PM, Pommier, Rex <***@sfgmembers.com> wrote:
>> Gil,
>>
>> I don't think this one is necessarily a quality issue. As widespread as the problem is, it appears to me to be more of a huuuge oversight. That said, you are correct in that we don't know what IBM plans to do, or for that matter, even how much of an impact fixing this will be on performance of z/OS. My concern is that since we (as well as probably many of the sites on this board) are bumping against our cap and if we get hit by even a 10% reduction in thruput from this, we're in danger of missing SLAs and other fun TLAs.
>>
>> Rex
>>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
>> Sent: Wednesday, January 10, 2018 11:52 AM
>> To: IBM-***@LISTSERV.UA.EDU
>> Subject: Re: System z & Meltdown/Spectre
>>
>> On Wed, 10 Jan 2018 17:31:37 +0000, Pommier, Rex wrote:
>>
>>>And what does "a significant CPU hit" mean for those of us who's 4HRA is already at the top of our machine's capacity? That's where my concern is. Yeah, the money for increasing MSUs is gonna stink, but missing SLAs due to the box no longer being big enough is going to really bite.
>>>
>> There's a cynical suspicion that when a vendor sees defect repair as a profit center
>> it provides a disincentive to quality.
>>
>> This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."
>>
>> In fairness, we don't know what IBM plans to do.
>>
>> -- gil
>>
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>> The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
>>
>>
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[R.S.]

If you have full speed processor then you can have ...more processors.
Let's not talk about models with all 170 processors activated and in use ;-)

However Len suggested the full speed processor can have some hidden
capacity. Well, maybe it has, but there is no evidence for such approach.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-01-11 o 05:33, Mike Schwab pisze:
> Unless you bought full speed processor, yes there is room for
> improvement. But the waits for data count toward your reduce CPU
> costs. I.E. a full speed CPU sees delays due to waiting, versus a
> slower processor counts those delays toward the reduced CPU speed.
>
> On Wed, Jan 10, 2018 at 9:34 PM, Rugen, Len <***@missouri.edu> wrote:
>> I wonder if the microcode has a little "detuning" so that if they ever have to make patches that would slow down the system, they can remove a little of the detuning to get back to base performance.
>>
>>
>> Len Rugen
>>
>> University of Missouri
>> Division of Information Technology
>> Systems & Operations - Metrics & Automation Team
>> ________________________________
>> From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Mike Schwab <***@GMAIL.COM>
>> Sent: Wednesday, January 10, 2018 8:55:07 PM
>> To: IBM-***@LISTSERV.UA.EDU
>> Subject: Re: System z & Meltdown/Spectre
>>
>> Yep. I know my site didn't purchase upgrades until running at 100%
>> all weekday long would slow down batch runs by 4X elapsed time
>> compared to 90%.
>>
>> On Wed, Jan 10, 2018 at 1:15 PM, Pommier, Rex <***@sfgmembers.com> wrote:
>>> Gil,
>>>
>>> I don't think this one is necessarily a quality issue. As widespread as the problem is, it appears to me to be more of a huuuge oversight. That said, you are correct in that we don't know what IBM plans to do, or for that matter, even how much of an impact fixing this will be on performance of z/OS. My concern is that since we (as well as probably many of the sites on this board) are bumping against our cap and if we get hit by even a 10% reduction in thruput from this, we're in danger of missing SLAs and other fun TLAs.
>>>
>>> Rex
>>>
>>> -----Original Message-----
>>> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
>>> Sent: Wednesday, January 10, 2018 11:52 AM
>>> To: IBM-***@LISTSERV.UA.EDU
>>> Subject: Re: System z & Meltdown/Spectre
>>>
>>> On Wed, 10 Jan 2018 17:31:37 +0000, Pommier, Rex wrote:
>>>
>>>> And what does "a significant CPU hit" mean for those of us who's 4HRA is already at the top of our machine's capacity? That's where my concern is. Yeah, the money for increasing MSUs is gonna stink, but missing SLAs due to the box no longer being big enough is going to really bite.
>>>>
>>> There's a cynical suspicion that when a vendor sees defect repair as a profit center
>>> it provides a disincentive to quality.
>>>
>>> This might go a step beyond: "We did it wrong, so we'll raise the price to make it right."
>>>
>>> In fairness, we don't know what IBM plans to do.
>>>
>>> -- gil
>>>
>>> ----------------------------------------------------------------------
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>>
>>> The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
>>>
>>>
>>> ----------------------------------------------------------------------
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>> --
>>

======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Tom Marchant]

On Wed, 10 Jan 2018 21:44:29 +0100, R.S. wrote:

>BTW: It's worth to remember chances the vulnerability would really
>compromise system security are really small. (IMHO)

I agree. Especially since the method of exploiting it involves flushing
cache and testing to see what memory location was reloaded into
cache. In a real system the amount of cache activity is too high for
the technique to be reliable. And the attacking task would use a lot
of CPU, making it unlikely that WLM would allow it to complete its
work without being interrupted frequently.

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Parwez Hamid]

You talk about 'speeds'. Just to make sure there is no confusion between 'speed' and 'capacity'. In any generation of Z system, the processor cycle (speed) time is always the same. Taking a single CP system as an example. what you have is different CAPACITY SETTINGs e.g. 401 or 501 or 601 or 701 (for the high end systems) and A01 to Z01 (for the mid range systems)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Dana Mitchell]

It sounds like for z/VM at least, that any performance impact will be dependent on the workload and "enablement settings". And application of these MCLs without applying operating system software PTFs will not have an impact on system performance. I would have to assume the z/OS PTFs will show similar behaivor.

Dana

On Thu, 11 Jan 2018 03:34:08 +0000, Rugen, Len <***@MISSOURI.EDU> wrote:

>I wonder if the microcode has a little "detuning" so that if they ever have to make patches that would slow down the system, they can remove a little of the detuning to get back to base performance.
>
>
>Len Rugen
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Scott Chapman]

I agree: from a practical perspective, unauthorized user code running on on a typical z/OS system has many more practical barriers to being able to use the side channel communication methods involved in Meltdown/Spectre. However, "difficult" and "unlikely" doesn't mean "impossible". That's assuming of course that it's even possible. But because it seems that there are some patches coming to Linux on the platform, it seems like there's at least some possibility that recent hardware is at least somewhat susceptible. I suspect (but don't know) that the impacts on z, and z/OS in particular, are not as catastrophically bad as some other platforms.

Having said all that, if there is a chance of it being exploited, it will have to be mitigated. The question comes from how much of an impact that mitigation is going to have and whether it's made optional or not. (Some of the Linux mitigations can be selectively disabled.) If it's optional, then it comes down to a risk assessment, and it's going to take much more information before sites can make a choice. If it's not optional (or if the risk assessment indicates many sites need to enable the mitigation) and if the impact is more than a small single digit impact for typical workloads, then... this will get really "interesting".

I've personally experienced that "interesting" on our main AWS processing server, which was using the older PV virtualization. The impact was significant and definitely pushed us over the edge in dramatic fashion. Fortunately, moving to current-generation HVM instances has more than offset the performance impacts that we were seeing. Unfortunately that move was more than a shutdown and start back up and ran into more "interesting" AWS issues/limitations. It's been an "interesting" week.

Hopefully this all will be less painful on z/OS.

Scott Chapman


On Wed, 10 Jan 2018 15:26:04 -0600, Tom Marchant <m42tom-***@YAHOO.COM> wrote:

>On Wed, 10 Jan 2018 21:44:29 +0100, R.S. wrote:
>
>>BTW: It's worth to remember chances the vulnerability would really
>>compromise system security are really small. (IMHO)
>
>I agree. Especially since the method of exploiting it involves flushing
>cache and testing to see what memory location was reloaded into
>cache. In a real system the amount of cache activity is too high for
>the technique to be reliable. And the attacking task would use a lot
>of CPU, making it unlikely that WLM would allow it to complete its
>work without being interrupted frequently.
>
>--
>Tom Marchant
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Edward Finnell]

Yeah, we put performance bonds on everything from pencil sharpeners to bulldozers. In the past we were able to work out agreements with vendors. Some scale, some fail some just pass it on. In a tort friendly state we usually at least cover the cost of conversion.


In a message dated 1/11/2018 8:19:13 AM Central Standard Time, ***@EPSTRATEGIES.COM writes:

 
Having said all that, if there is a chance of it being exploited, it will have to be mitigated. The question comes from how much of an impact that mitigation is going to have and whether it's made optional or not. (Some of the Linux mitigations can be selectively disabled.) If it's optional, then it comes down to a risk assessment, and it's going to take much more information before sites can make a choice. If it's not optional (or if the risk assessment indicates many sites need to enable the mitigation) and if the impact is more than a small single digit impact for typical workloads, then... this will get really "interesting".

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Walt Farrell]

On Wed, 10 Jan 2018 15:26:04 -0600, Tom Marchant <m42tom-***@YAHOO.COM> wrote:

>On Wed, 10 Jan 2018 21:44:29 +0100, R.S. wrote:
>
>>BTW: It's worth to remember chances the vulnerability would really
>>compromise system security are really small. (IMHO)
>
>I agree. Especially since the method of exploiting it involves flushing
>cache and testing to see what memory location was reloaded into
>cache. In a real system the amount of cache activity is too high for
>the technique to be reliable. And the attacking task would use a lot
>of CPU, making it unlikely that WLM would allow it to complete its
>work without being interrupted frequently.

Assuming, of course, that the attack occurs on a heavily-used production system. On a more lightly-used system, perhaps a test system with access to shared data or with a shared security database or shared ICSF data such that credentials "stolen" on one system could be used on another, it might be more successful.

That would come down to other factors of data segregation and security, and require additional analysis.

--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[R.S.]

W dniu 2018-01-11 o 23:03, Walt Farrell pisze:
> On Wed, 10 Jan 2018 15:26:04 -0600, Tom Marchant <m42tom-***@YAHOO.COM> wrote:
>
>> On Wed, 10 Jan 2018 21:44:29 +0100, R.S. wrote:
>>
>>> BTW: It's worth to remember chances the vulnerability would really
>>> compromise system security are really small. (IMHO)
>> I agree. Especially since the method of exploiting it involves flushing
>> cache and testing to see what memory location was reloaded into
>> cache. In a real system the amount of cache activity is too high for
>> the technique to be reliable. And the attacking task would use a lot
>> of CPU, making it unlikely that WLM would allow it to complete its
>> work without being interrupted frequently.
> Assuming, of course, that the attack occurs on a heavily-used production system. On a more lightly-used system, perhaps a test system with access to shared data or with a shared security database or shared ICSF data such that credentials "stolen" on one system could be used on another, it might be more successful.
>
> That would come down to other factors of data segregation and security, and require additional analysis.

IMHO shared sesnsitive data like RACF db or ICSF PKDS is not an issue -
one should not share such information between production and test.
What's much more interesting is:
Is it possible to perform attack from sandbox system (LPAR) to access
data from production system working in another LPAR on the same CPC?
Let's assume all LPARs are lightly used and other assumption helping
attacker to perform the attack...

Regards
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Jason Cai]

Hi all

Could we define a service class in WLM by batch job? Thanks a lot!



Best Regards,
Jason Cai



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[John Arwe]

On 9/27/2018 11:12 PM, Jason Cai wrote:

> Could we define a service class in WLM by batch job? Thanks a lot!

Sure: fetch current service definition, update, store it, re-activate
the currently active policy name (now sporting your new srvclass). Have
a look at the WLM Programming Services pub. IIRC the relevant subset
were named IWMDxxxxx. SAF permissions definitely needed.

At a higher level though, is that action common enough to be worth
automating it, or is there a larger unstated context? It would be
surprising if automating "add srvclass" alone was worth the time -
there's usually a whole ecosystem dependent on the data, with humans
consuming it in the end even if only for exceptions and capacity
planning, so adding/removing srvclasses on a regular basis would
generally be considered "unusual".

The original intent of the APIs was to allow systems management products
to update the entire svdef - and replace the UI, if they felt like it -
programmatically, and activate policies (which *could* easily be much
more common, e.g. you might have different 1st/2nd shift policies) the
same way.

--
John Arwe
IBM Wave for z/VM Development product owner
Former zWLM perpetrator

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Vernooij, Kees - KLM , ITOPT1]

Unless the OP wants to define a serviceclass daily when Prodbatch starts and delete it when it is finished, to prevent illegal use.
So again: what is the thought behind the question?

Kees.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: 28 September, 2018 15:43
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: define a service class in wlm by batch
>
> Short answer ... No.
> Long answer. Yes, if you want to spend a lot more time than it will take
> to do it from within the WLM dialog.
>
> HTH
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf
> Of Jason Cai
> Sent: Thursday, September 27, 2018 10:13 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: define a service class in wlm by batch
>
> Hi all
>
> Could we define a service class in WLM by batch job? Thanks a lot!
>
>
>
> Best Regards,
> Jason Cai
>
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> --------------------------------------------------------------
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
> may contain viruses in transmission. The e mail and its contents (with
> or without referred errors) shall therefore not attach any liability on
> the originator or HCL or its affiliates. Views or opinions, if any,
> presented in this email are solely those of the author and may not
> necessarily reflect the views or opinions of HCL or its affiliates. Any
> form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of HCL is strictly
> prohibited. If you have received this email in error please delete it
> and notify the sender immediately. Before opening any email and/or
> attachments, please check them for viruses and other defects.
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> --------------------------------------------------------------
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN