I have not researched this issue for quite a while, but at one time we cut 
storage allocation to a bare minimum on LPARs that did not seem to need more. 
In a few cases to less than 1 GB. At that time storage cost a lot more than 
now, and nobody wanted to revisit the well to ask for more than we 
(justifiably) needed. Then we discovered that actual LPAR storage allocation 
was automatically incremented upward in the hardware to a boundary determined 
by factors we did not understand, but CPU model and actual amount of storage 
physically installed were factors. Queried IBM and learned that 'no man's land' 
storage was essentially wasted: not usable by this or any other LPAR. 

We no longer shave LPARs down to the bone, but I looked at a few that have odd 
values specified. (I didn't set the current values.) I see this for one of the 
few LPARs that have less than 8 GB specified:

IEE174I 11.07.56 DISPLAY M           FRAME LAST   F      E   SYS=xx  
REAL STORAGE STATUS                                                  
ONLINE-NOT RECONFIGURABLE                                            
    0M-7168M                                                         
ONLINE-RECONFIGURABLE                                                
    NONE                                                             
PENDING OFFLINE                                                      
    NONE                                                             
 0M IN OFFLINE STORAGE ELEMENT(S)                                    
 1024M UNASSIGNED STORAGE  <==========================                          
                  
STORAGE INCREMENT SIZE IS 512M                                       

The key here is '1024M UNASSIGNED STORAGE'. As I understand it, this unassigned 
storage is not available to LPAR xx *nor to any other LPAR on this machine*.  
In other words, if you have storage installed, you might as well allocate it. 
Of course big time overallocation could increase system overhead. But as my 
kids' pediatrician used to say, you can't be too rich, too thin, or have too 
much real storage. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of R.S.
Sent: Tuesday, December 10, 2019 12:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: A minimum of 8 GB of real memory is required to IPL

No, AFAIK it doesn't work as you described.
Note: there are two things: CPU weight and memory.
CPU LPAR weight is really "adjusted" somehow, especially for low values 
specified by the user.
However memory is different animal. Here you have explicitly showed memory 
increments which depend on total (LPAR) memory. However the values are 
reasonably low to specify single-GB regions for LPAR and the values are 
honored. If you specify (during LPAR profile definition) something which is not 
multiple of increment, you'll get explicit warning with clear description.

How can one be sure the above is true? Math. Memory assigned to LPAR is also 
reported by z/OS with no "stolen chunks". Sum of LPAR memory regions give total 
memory available for user. HSA is fixed and not counted as user memory.


Regarding reason for using z/OS in low memory LPAR:
1. It works, especially with no workload (think sandbox, simple test, etc.) 2. 
If you are short on memory, you can assign more to prod LPAR. From the other 
hand it should be analyzed whether adding 4 or 5 Gigabytes to prod will cause 
significant change.

Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 2019-12-09 o 20:06, Jesse 1 Robinson pisze:
> It's temping to be parsimonious and reduce storage allocation to a bare 
> minimum, but it can be a losing game. Regardless of how little storage you 
> specify in an LPAR profile, the hardware itself will adjust the 'effective 
> allocation' according to the CPU model. That is, the amount of storage 
> reserved to an LPAR will never be less than the h/w minimum. So if you 
> specify a fraction of the hardware increment, you will effectively lose any 
> remaining storage in that range. It cannot be used by any LPAR.
>
> So you might as well as specify any storage remaining in the increment. It 
> will cost you nothing.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of 
> Jousma, David
> Sent: Monday, December 9, 2019 8:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: A minimum of 8 GB of real memory is required to IPL
>
> I'm pretty sure I've heard it mentioned that Bill Gates said "Who could ever 
> need more than 640K of RAM?"   Haha, how times have changed.
>
> _____________________________________________________________________________________________________
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
> MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of 
> R.S.
> Sent: Monday, December 9, 2019 10:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: A minimum of 8 GB of real memory is required to IPL
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> W dniu 2019-12-09 o 15:56, Burgess, Otto A. pisze:
>> Good to know, thanks
>>
>> Perhaps IBM is more conservative on the recommendations than they need
>> to be
> Well, not so long ago we discussed whether 1GB is really good choice for 
> sandbox z/OS system. The other options were 512MB and .75GB.
> Later we increased 1GB to 2GB.
> Nowadays I have 16GB ...in my PC, which is old and my new PC waiting for use 
> have 32GB. I didn't order anything special, just regular PC.
>
> --
> Radoslaw Skorupka
> Lodz, Poland

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

Reply via email to