Re: Question on PR/SM dispatcher

2011-12-20 Thread Vernooij, CP - SPLXM 
"Shmuel Metz  , Seymour J."  wrote in
message news:<20111220170650.bceecf58...@smtp.patriot.net>...
> In
> ,
> on 12/20/2011
>at 04:53 PM, "Vernooij, CP - SPLXM"  said:
> 
> >Of course, but I suppose you know what I meant:
> 
> You're welcome to suppose what you wish. Just don't be surprised when
> your suppositions are wrong more often than they're right.
>  

Yes, in this case this appears to be a good advise.

Kees.

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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Question on PR/SM dispatcher

2011-12-20 Thread Shmuel Metz (Seymour J.) 
In
,
on 12/20/2011
   at 04:53 PM, "Vernooij, CP - SPLXM"  said:

>Of course, but I suppose you know what I meant:

You're welcome to suppose what you wish. Just don't be surprised when
your suppositions are wrong more often than they're right.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Question on PR/SM dispatcher

2011-12-20 Thread Tom Marchant 
On Tue, 20 Dec 2011 09:19:35 +0100, Vernooij, CP wrote:

>I am quite sure that pr/sm always dispatched Logical CPs and Amdahls
>MDF dispatched entire domains (their word for lpar).

If by "dispatched entire domains" you mean that all of the 
logical processors for a domain were always dispatched 
together, I don't think that is correct.  For one thing, it 
would have made MDF more complicated than it needed to 
be.  For another, it would have meant that if you had 
domain A with 1 LP and domain B with 2 LPs on a system 
with two physical processors, whenever domain A was 
active, one of the processors would have always been idle. 
That would not have been very efficient.

-- 
Tom Marchant

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

Re: Question on PR/SM dispatcher

2011-12-20 Thread Steve Thompson 
"Shane"  wrote in message
news:<20111220123112.2a437a52@xpfs>...
> On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote:
>
> > PR/SM dispatches Logical CPs not Logical Partitions.


- I am quite sure that pr/sm always dispatched Logical CPs and Amdahls
MDF dispatched entire domains (their word for lpar).



PR/SM and LPARs are IBM's answer to MDF (Multiple Domain Facility and 
Domains). In fact, IBM was AMDAHL's second customer to pay for MDF. But 
because the machine they had wasn't ready to be field upgraded, IBM wasn't 
the second customer to have MDF (man, lots of memories have been awakened 
by this posting).

Through the 5990 machines, all LPs were dispatched simultaneously in a 
Domain. The idea was that we did not want to cause a spin lock loop 
problem that would cause ACR. We also were trying to solve a problem with 
I/O elongation (a domain would start an I/O, lose dispatch, the I/O would 
complete and the interrupt would be "hanging" until the Domain was 
dispatched again). We had discussed asynchronous dispatch, but it was 
decided to not implement it. Then came the big layoff of 1989 just after 
Thanksgiving... I have no idea what happened after that as I never saw any 
AMDAHL machines after the 5990-1400s in any shop where I worked.

I do know that IBM implemented asynchronous dispatch. When, I don't know. 
And the particulars I don't know. And I don't work in POK so I don't have 
access to the LPAR - PR/SM logic, so I honestly can't speak to that at 
all.

Regards,
Steve Thompson
Staff Software Engineer
Connect:Direct for z/OS
IBM - Software Group
(469) 524-2622
sthomp...@us.ibm.com

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

Re: Question on PR/SM dispatcher

2011-12-20 Thread Tom Marchant 
On Tue, 20 Dec 2011 10:33:14 -0500, Shmuel Metz wrote:

>If I recall correctly, MDF was implemented in what Amdahl
>called macrocode, 

That's correct.  Very similar to the millicode on current IBM 
mainframes.  A superset of 370 instructions that ran in 
system state.

>not by dedicated hardware.

There was considerable hardware included in the Amdahl 
580 series processors to make macrocode and MDF work. 
There was a separate set of registers that were available 
in system state. System state was a third state of 
operation, in addition to problem and supervisor state. 
There were additional instructions for referencing the 
domain's registers and storage.  Ther was also hardware 
for mapping domain storage and 31-bit or 32-bit addressing.  
I can't remember which.  This was all designed long before 
Extended Architecture.

When IBM introduced XA, the design of the 580 allowed 
Amdahl to implement Extended Architecture relatively 
easily.

There was an ALTA Principles of Operation that described 
the additional registers, instructions, etc.  I turned in my 
copy of the ALTA POO when I left Amdahl, but I studied it 
thoroughly while I was there.

-- 
Tom Marchant

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

Re: Question on PR/SM dispatcher

2011-12-20 Thread Tom Marchant 
On Tue, 20 Dec 2011 09:14:36 -0500, Shmuel Metz wrote:

>How did MDF detect the end of a timeslice if not by an interrupt?

That is how it detected the end of a time slice.  Early MDF code 
would dispatch a different domain as soon as a processor entered 
a wait state.  That was determined to cause performance problems, 
largely due to the effects of cache misses.  By the time MDF was 
delivered to the field, it was changed so that a domain was allowed 
to run on a processor until its time slice ended.  The result was 
improved performance.

-- 
Tom Marchant

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

Re: Question on PR/SM dispatcher

2011-12-20 Thread Anne & Lynn Wheeler 
shmuel+ibm-m...@patriot.net (Shmuel Metz  , Seymour J.) writes:
> Certainly. If I recall correctly, MDF was implemented in what Amdahl
> called macrocode, not by dedicated hardware. So what triggered the
> redispatch at the end of a time slice if not an external interrupt?

the guys doing MDF use to come to baybunch and pump me for information
... I had done time-slice dispatching since my undergraduate days in the
60s and had been involved in design and implementation of ECPS for the
138/148 ...

there have numerous issues over the years with implementations trying to
get around use of timer-based considerations ... hoping that other
events would provide sufficient control not having to resort to the
additional overhead ... this has periodically resulted in monumental
gafs when the various other failed to occur in the anticipated ways.

the other issue was that the MDF implementation for Amdahl was
significantly simpler because of the macrocode use. 3090 had to respond
with pr/sm ... but that was a significantly more complex undertaking
because there wasn't any equivalent facility and they had to fallback to
horizontal microcode.

there was also issue in the early 1980s when somebody having gotten an
award for changes to mvs/xa, contacted me about whether similar changes
could be made to vm. I commented that I had not done it any other way
since my work as undergraduate in the 60s ... and in fact had arguments
with VS2/SVS (precursor to MVS) in the early 70s about they shouldn't be
doing it the wrong way.

past posts mentioning part of the effort for ECPS
http://www.garlic.com/~lynn/94.html#21

past posts mentioning dispatching/scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare

misc past posts mentioning macrocode:
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#48 Linux paging
http://www.garlic.com/~lynn/2003.html#9 Mainframe System 
Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005d.html#60 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned 
programming language
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New 
Instructions for the z9 Processor
http://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#43 POWER6 on zSeries?
http://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries?
http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode
http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
http://www.garlic.com/~lynn/2006j.html#32 Code density and performance?
http://www.garlic.com/~lynn/2006j.html#35 Code density and performance?
http://www.garlic.com/~lynn/2006m.html#39 Using different storage key's
http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email
http://www.garlic.com/~lynn/2006u.html#33 Assembler question
http://www.garlic.com/~lynn/2006u.html#34 Assembler question
http://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2007b.html#1 How many 36-bit Unix ports in the old 
days?
http://www.garlic.com/~lynn/2007d.html#3 Has anyone ever used self-modifying 
microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007d.html#9 Has anyone ever used self-modifying 
microcode? Would it even be useful?
http://www.garlic.com/~lynn/2007j.html#84 VLIW pre-history
http://www.garlic.com/~lynn/2007k.html#74 Non-Standard Mainframe Language?
http://www.garlic.com/~lynn/2007n.html#96 some questions about System z PR/SM
http://www.garlic.com/~lynn/2008c.html#32 New Opcodes
http://www.garlic.com/~lynn/2008c.html#33 New Opcodes
http://www.garlic.com/~lynn/2008c.html#42 New Opcodes
http://www.garlic.com/~lynn/2008j.html#26 Op codes removed from z/10
http://www.garlic.com/~lynn/2008r.html#27 CPU time/instruction table
http://www.garlic.com/~lynn/2010m.html#74 z millicode: where does it reside?
http://www.garlic.com/~lynn/2011c.html#93 Irrational desire to author 
fundamental interfaces

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Question on PR/SM dispatcher

2011-12-20 Thread Vernooij, CP - SPLXM 
Of course, but I suppose you know what I meant: PR/SM sits waiting for
an LPAR to produce an interrupt and decides then what to do next. MDF
determines that it wants to take action after a certain timeslice,
whether the domains like it or not.

The fact that the end of the timeslice might be signalled by an
interrupt, nominates you for the 'sheesj of the week' posting.

Kees.

"Shmuel Metz  , Seymour J."  wrote in
message news:<20111220151739.9a61ef58...@smtp.patriot.net>...
> In
> ,
> on 12/20/2011
>at 04:15 PM, "Vernooij, CP - SPLXM"  said:
> 
> >Are you serious? 
> 
> Certainly. If I recall correctly, MDF was implemented in what Amdahl
> called macrocode, not by dedicated hardware. So what triggered the
> redispatch at the end of a time slice if not an external interrupt?
>  
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see  
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Question on PR/SM dispatcher

2011-12-20 Thread Shmuel Metz (Seymour J.) 
In
,
on 12/20/2011
   at 04:15 PM, "Vernooij, CP - SPLXM"  said:

>Are you serious? 

Certainly. If I recall correctly, MDF was implemented in what Amdahl
called macrocode, not by dedicated hardware. So what triggered the
redispatch at the end of a time slice if not an external interrupt?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Question on PR/SM dispatcher

2011-12-20 Thread Martin Packer 
Chaucer spelt it "cherl".

Martin

Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:
"McKown, John" 
To:
IBM-MAIN@bama.ua.edu, 
Date:
20/12/2011 13:10
Subject:
Re: Question on PR/SM dispatcher
Sent by:
IBM Mainframe Discussion List 



A "churl" is a very old word for a "peasant" or "free man". But became to 
be used for someone who has no manners or "breeding". To be "churlish" is 
to have "bad manners". Like telling a new mom: "That is one ugly baby!"

http://en.wikipedia.org/wiki/Churl

This meaning held through the 15th century, but by then the word had taken 
on negative overtone, meaning "a country person" and then "a low fellow". 
By the 19th century, a new and pejorative meaning arose, "one inclined to 
uncivil or loutish behaviour".


--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message. HealthMarkets(r) is the brand name for products underwritten and 
issued by the insurance subsidiaries of HealthMarkets, Inc. -The 
Chesapeake Life Insurance Company(r), Mid-West National Life Insurance 
Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM
> Sent: Tuesday, December 20, 2011 2:20 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Question on PR/SM dispatcher
> 
> "Shane"  wrote in message
> news:<20111220123112.2a437a52@xpfs>...
> > On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote:
> > 
> > > PR/SM dispatches Logical CPs not Logical Partitions.
> > 
> > I wonder if it'd be considered churlish to point out this wasn't
> always
> > the case.
> > 
> > Shane ...
> > 
> 
> Shane,
> 
> - what is churlish, I can't find an understandable translation.
> - I am quite sure that pr/sm always dispatched Logical CPs and Amdahls
> MDF dispatched entire domains (their word for lpar).
> 
> Kees.
> 
> 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






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

Re: Question on PR/SM dispatcher

2011-12-20 Thread Vernooij, CP - SPLXM 
Are you serious? 
Kees.

"Shmuel Metz  , Seymour J."  wrote in
message news:<20111220144901.d5dcaf58...@smtp.patriot.net>...
> In
> ,
> on 12/19/2011
>at 09:29 AM, "Vernooij, CP - SPLXM"  said:
> 
> >You don't have to wait for it, you can also force it. Amdahl's MDF
> >did it. The main difference was that PR/SM is interrupt driven and
> >MDF was timeslice driven.
> 
> How did MDF detect the end of a timeslice if not by an interrupt?
>  
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see  
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Question on PR/SM dispatcher

2011-12-20 Thread Shmuel Metz (Seymour J.) 
In
,
on 12/19/2011
   at 09:29 AM, "Vernooij, CP - SPLXM"  said:

>You don't have to wait for it, you can also force it. Amdahl's MDF
>did it. The main difference was that PR/SM is interrupt driven and
>MDF was timeslice driven.

How did MDF detect the end of a timeslice if not by an interrupt?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Question on PR/SM dispatcher

2011-12-20 Thread McKown, John 
A "churl" is a very old word for a "peasant" or "free man". But became to be 
used for someone who has no manners or "breeding". To be "churlish" is to have 
"bad manners". Like telling a new mom: "That is one ugly baby!"

http://en.wikipedia.org/wiki/Churl

This meaning held through the 15th century, but by then the word had taken on 
negative overtone, meaning "a country person" and then "a low fellow". By the 
19th century, a new and pejorative meaning arose, "one inclined to uncivil or 
loutish behaviour".


--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM
> Sent: Tuesday, December 20, 2011 2:20 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Question on PR/SM dispatcher
> 
> "Shane"  wrote in message
> news:<20111220123112.2a437a52@xpfs>...
> > On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote:
> > 
> > > PR/SM dispatches Logical CPs not Logical Partitions.
> > 
> > I wonder if it'd be considered churlish to point out this wasn't
> always
> > the case.
> > 
> > Shane ...
> > 
> 
> Shane,
> 
> - what is churlish, I can't find an understandable translation.
> - I am quite sure that pr/sm always dispatched Logical CPs and Amdahls
> MDF dispatched entire domains (their word for lpar).
> 
> Kees.
> 
> 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

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

Re: Question on PR/SM dispatcher

2011-12-20 Thread Vernooij, CP - SPLXM 
"Shane"  wrote in message
news:<20111220123112.2a437a52@xpfs>...
> On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote:
> 
> > PR/SM dispatches Logical CPs not Logical Partitions.
> 
> I wonder if it'd be considered churlish to point out this wasn't
always
> the case.
> 
> Shane ...
> 

Shane,

- what is churlish, I can't find an understandable translation.
- I am quite sure that pr/sm always dispatched Logical CPs and Amdahls
MDF dispatched entire domains (their word for lpar).

Kees.

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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Question on PR/SM dispatcher

2011-12-19 Thread Shane 
On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote:

> PR/SM dispatches Logical CPs not Logical Partitions.

I wonder if it'd be considered churlish to point out this wasn't always
the case.

Shane ...

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

Re: Question on PR/SM dispatcher

2011-12-19 Thread Tom Russell 

PR/SM dispatches Logical CPs not Logical Partitions.
So Question 1 and 2 get the same answer.  Any given Logical partiton can 
have some logical CPs ready to run, and pther logical CPs in the WAIT 
state.  The ready to run CP will be dispatched on a real CP when it is 
the highest priority Logical CP ready to run. The other CPs in the 
partition are not ready to run, and so are not competing for 
resources.   The logical CP priority is the weight divided by the number 
of Logical CPs in the partition.


In most cases PR/SM dynamically determines the run time (a.k.a. time 
slice) to be 12.5 ms.  Most LCPs will enter wait state before the 12.5 
ms is reached and will be queued for the event (usually I/O) that will 
make the LCP ready to run again.  Time slices shorter than 12.5 ms 
usually only occur with very low weighted Logical Partitions, or hard 
capped partitions, or both.  LCPs for these partitions can cause a 
drastic reduction in MIP rate, because the first few ms after getting 
dispatched usually involves many cache misses.  By the time the real CP 
has its caches primed with the instructions and data, the short time 
slice ends and the LCP is returned to a queue waiting for a chance to 
get dispatched.  Other ready to run LCPs with higher priority (Weight) 
will be queued before it.


If a low weighted LCP is the only one ready to run, it can consume  more 
than its weight.  I wouldn't call the tracking of consumption 
"averaging", but the accumulation of CPU time and tracking of the 
entitlement based on the weight is measured in seconds.

regards< Tom


On 2011-12-19 12:00 AM, IBM-MAIN automatic digest system wrote:

Date:Sun, 18 Dec 2011 09:50:33 -0600
From:Mauri Kanter
Subject: Question on PR/SM dispatcher

Good day list

I would like to understand something that is not still clear to me regarding 
PR/SM dispatching.
Just to be clear I'm asking only about shared processors (not dedicated) and 
with dynamically determined time slices.

I'm interested to understand the LPAR dispatching (before I understand the zVM 
dispatching and the Linux under VM dispatching;-)

I a-priori apologize if I'm asking too many questions together.

The questions are:

Question 1
==
Does PR/SM dispatches an LPAR only when the number of physical processors 
awaiting allows to dispatch all the logical processors required for an LPAR 
simultaneously?

For example suppose my machine has 3 physical CPUs, and with 3 lpars defined as 
follows:
LPARA – 3 logical processors
LPARB – 2 logical processors
LPARC – 2 logical processors
Option 1 – Am I wasting a physical processor when LPARB or LPARC are dispatched?
Option 2 - Or can the single physical processor left be dispatched to serve 
another lpar?
If option 2 is the true one, are there spin-lock and loop related problems if 
only a subset of CPUs is dispatched by PR/SM?
Option 3 - Or none of the options 1 and 2 are true and it works differently?

Question 2
==
Suppose that an LPAR running z/OS with 2 physical processors is dispatched.
The first physical processor completed its work.
The second physical processor is still burning cycles with for example the CICS 
QR TCB
In other words, my z/OS at some moment got 2 physical CPUs but only one TCB has 
really work to do.
Are both physical processors returned simultaneously to PR/SM or are they 
returned independently to PR/SM as they become idle?
I mean, do the processors return one by one to the pool of available physical 
processors or simultaneously on an LPAR base?

Question 3
==
Suppose that I have 2 LPARs, one with weight 20 and the other with weight 80
The one with weight 80 does not consume all its time slice and returns the 
processor(s) to PR/SM
The one with weight 20 finds a way to use those cycles the other left …
Now the LPAR with weight 80 wants more than its weight …
Over which time interval are the weights averaged? Once a second? Once a 
minute? Not averaged at all?

Thanks in advance for your help.

Mauri.


--
Tom Russell

“Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear
“... and remember to leave good news alone.” — Gracie HeavyHand

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

Re: Question on PR/SM dispatcher

2011-12-19 Thread Vernooij, CP - SPLXM 
You don't have to wait for it, you can also force it. Amdahl's MDF did
it. The main difference was that PR/SM is interrupt driven and MDF was
timeslice driven. Therefor it did not have to wait for the ducks to line
up, but simply took an entire domain from the processors when its time
was up and dispatched a new domain.

Both had their pro's and con's and MDF lost the game, but for totally
different reasons.

Kees.


"Martin Packer"  wrote in message
news:...
> To dispatch entire LPARs would be waiting for 2n ducks to line up in a

> row: An event with progressively high latency in the n>1 case. Which
is 
> one reason we don't do it, I guess. (The 2n ducks would be the n
logicals 
> and n physicals.)
> 
> Martin
> 
> Martin Packer,
> Mainframe Performance Consultant, zChampion
> Worldwide Banking Center of Excellence, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> Blog: 
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> 
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
> 
> 
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Question on PR/SM dispatcher

2011-12-19 Thread Martin Packer 
To dispatch entire LPARs would be waiting for 2n ducks to line up in a 
row: An event with progressively high latency in the n>1 case. Which is 
one reason we don't do it, I guess. (The 2n ducks would be the n logicals 
and n physicals.)

Martin

Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






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

Re: Question on PR/SM dispatcher

2011-12-19 Thread Vernooij, CP - SPLXM 
"Mauri Kanter"  wrote in message
news:<7558267718421282.wa.itzuviem013.net...@bama.ua.edu>...
> Thank you Jim. Crystal Clear.
> 

Mauri,
I was going to reply, that your view on pr/sm was incorrect: pr/sm does
not dispatch entire LPARs, but individual processors, if the LPAR's
weight allows it. But I think Jim's answers made that clear also.

Kees.

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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Question on PR/SM dispatcher

2011-12-18 Thread Mauri Kanter 
Thank you Jim. Crystal Clear.

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

Re: Question on PR/SM dispatcher

2011-12-18 Thread Jim Mulder 
> Question 1
> ==
> Does PR/SM dispatches an LPAR only when the number of physical 
> processors awaiting allows to dispatch all the logical processors 
> required for an LPAR simultaneously?

  No.
 
> For example suppose my machine has 3 physical CPUs, and with 3 lpars
> defined as follows:
> LPARA ? 3 logical processors
> LPARB ? 2 logical processors
> LPARC ? 2 logical processors
> Option 1 ? Am I wasting a physical processor when LPARB or LPARC are
> dispatched? 
> Option 2 - Or can the single physical processor left be dispatched 
> to serve another lpar? 
> If option 2 is the true one, are there spin-lock and loop related 
> problems if only a subset of CPUs is dispatched by PR/SM?

  Option 2, and yes, there can be cases where a 
dispatched logical processor can be spinning for a resource
held by a logical processor which is not dispatched. 
z/OS detects this situation and informs LPAR. 

> Question 2
> ==
> Suppose that an LPAR running z/OS with 2 physical processors is 
dispatched.
> The first physical processor completed its work.
> The second physical processor is still burning cycles with for 
> example the CICS QR TCB
> In other words, my z/OS at some moment got 2 physical CPUs but only 
> one TCB has really work to do.
> Are both physical processors returned simultaneously to PR/SM or are
> they returned independently to PR/SM as they become idle?
> I mean, do the processors return one by one to the pool of available
> physical processors or simultaneously on an LPAR base?

  Logical processors are dispatched and returned independently.
 
> Question 3
> ==
> Suppose that I have 2 LPARs, one with weight 20 and the other with 
weight 80
> The one with weight 80 does not consume all its time slice and 
> returns the processor(s) to PR/SM 
> The one with weight 20 finds a way to use those cycles the other left ?
> Now the LPAR with weight 80 wants more than its weight ?
> Over which time interval are the weights averaged? Once a second? 
> Once a minute? Not averaged at all?

  LPAR calculates the share for each partition based on the 
weights of all of the active partitions.  For a partition which is 
not in hiperdispatch mode, the share is distributed evenly among
its logical processors.  A logical processor which has not 
used its share is given some amount of dispatching preference over 
logical processors which have used more than their share. 
I don't know the time intervals over which the calculations are
made. 
 
Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

Re: Question on PR/SM dispatcher

2011-12-18 Thread zMan 
Great questions. I have no idea of the answers, but will be very
interested to see them!

On Sun, Dec 18, 2011 at 10:50 AM, Mauri Kanter  wrote:
> Good day list
>
> I would like to understand something that is not still clear to me regarding 
> PR/SM dispatching.
> Just to be clear I'm asking only about shared processors (not dedicated) and 
> with dynamically determined time slices.
>
> I'm interested to understand the LPAR dispatching (before I understand the 
> zVM dispatching and the Linux under VM dispatching ;-)
>
> I a-priori apologize if I'm asking too many questions together.
>
> The questions are:
>
> Question 1
> ==
> Does PR/SM dispatches an LPAR only when the number of physical processors 
> awaiting allows to dispatch all the logical processors required for an LPAR 
> simultaneously?
>
> For example suppose my machine has 3 physical CPUs, and with 3 lpars defined 
> as follows:
> LPARA – 3 logical processors
> LPARB – 2 logical processors
> LPARC – 2 logical processors
> Option 1 – Am I wasting a physical processor when LPARB or LPARC are 
> dispatched?
> Option 2 - Or can the single physical processor left be dispatched to serve 
> another lpar?
> If option 2 is the true one, are there spin-lock and loop related problems if 
> only a subset of CPUs is dispatched by PR/SM?
> Option 3 - Or none of the options 1 and 2 are true and it works differently?
>
> Question 2
> ==
> Suppose that an LPAR running z/OS with 2 physical processors is dispatched.
> The first physical processor completed its work.
> The second physical processor is still burning cycles with for example the 
> CICS QR TCB
> In other words, my z/OS at some moment got 2 physical CPUs but only one TCB 
> has really work to do.
> Are both physical processors returned simultaneously to PR/SM or are they 
> returned independently to PR/SM as they become idle?
> I mean, do the processors return one by one to the pool of available physical 
> processors or simultaneously on an LPAR base?
>
> Question 3
> ==
> Suppose that I have 2 LPARs, one with weight 20 and the other with weight 80
> The one with weight 80 does not consume all its time slice and returns the 
> processor(s) to PR/SM
> The one with weight 20 finds a way to use those cycles the other left …
> Now the LPAR with weight 80 wants more than its weight …
> Over which time interval are the weights averaged? Once a second? Once a 
> minute? Not averaged at all?
>
> Thanks in advance for your help.
>
> Mauri.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Question on PR/SM dispatcher

2011-12-18 Thread Mauri Kanter 
Good day list

I would like to understand something that is not still clear to me regarding 
PR/SM dispatching.
Just to be clear I'm asking only about shared processors (not dedicated) and 
with dynamically determined time slices.

I'm interested to understand the LPAR dispatching (before I understand the zVM 
dispatching and the Linux under VM dispatching ;-)

I a-priori apologize if I'm asking too many questions together.

The questions are: 

Question 1
==
Does PR/SM dispatches an LPAR only when the number of physical processors 
awaiting allows to dispatch all the logical processors required for an LPAR 
simultaneously?

For example suppose my machine has 3 physical CPUs, and with 3 lpars defined as 
follows:
LPARA – 3 logical processors
LPARB – 2 logical processors
LPARC – 2 logical processors
Option 1 – Am I wasting a physical processor when LPARB or LPARC are 
dispatched? 
Option 2 - Or can the single physical processor left be dispatched to serve 
another lpar? 
If option 2 is the true one, are there spin-lock and loop related problems if 
only a subset of CPUs is dispatched by PR/SM?
Option 3 - Or none of the options 1 and 2 are true and it works differently?

Question 2
==
Suppose that an LPAR running z/OS with 2 physical processors is dispatched.
The first physical processor completed its work.
The second physical processor is still burning cycles with for example the CICS 
QR TCB
In other words, my z/OS at some moment got 2 physical CPUs but only one TCB has 
really work to do.
Are both physical processors returned simultaneously to PR/SM or are they 
returned independently to PR/SM as they become idle?
I mean, do the processors return one by one to the pool of available physical 
processors or simultaneously on an LPAR base?

Question 3
==
Suppose that I have 2 LPARs, one with weight 20 and the other with weight 80
The one with weight 80 does not consume all its time slice and returns the 
processor(s) to PR/SM 
The one with weight 20 finds a way to use those cycles the other left …
Now the LPAR with weight 80 wants more than its weight …
Over which time interval are the weights averaged? Once a second? Once a 
minute? Not averaged at all?

Thanks in advance for your help.

Mauri.

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