While discussing this with a colleague, we discovered that a small utility LPAR on our new z13s had the same problem. Two additional issues to consider:
-- Larger real storage requires larger page tables to keep track of it. Someone might consider this wasteful to the point of keeping some unassigned storage offline. I personally can't see the advantage, but it might be a consideration for some. -- When sizing a new box for memory, consider that whatever an LPAR looks like on pre z12 hardware, for z12 onward no LPAR can be less than 2 GB. Hence a lot of small LPARs will occupy more real storage in total than the same set has in the past. Fortunately memory is way cheaper than it used to be. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Barbara Nitz Sent: Tuesday, November 15, 2016 11:50 PM To: [email protected] Subject: (External):Re: Real Storage Display >I discussed this further with Jim Mulder. The z12, where I recently noticed >the 'unassigned' value, introduced 2 GB pages, one of whose consequences is >that LPAR boundaries are rounded up as needed to the nearest 2 GB boundary. If >an image profile specifies any other value, the 'excess' is displayed as >unassigned storage. It can be configured online to the owning LPAR but cannot >be allocated to any other LPAR, hence 'unassigned'. Thanks for sharing this, Skip. We are in the process of increasing real storage assigned to lpars now that we're on a z13, and sure enough, we had a number of odd storage assignments. That has been rectified now. :-) Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
