Proper Planning Prevents Poor Performance.

Let's start from scratch or from CPC Activate process.
Now it is good moment to properly define LPARs. First, give reserved memory to each one. It is just a definition, it is clause like "I expect I will add memory in the future". And when your system is running the LPAR memory is able to grow up. Your z/OS is also able to get more memory without reIPL. Just use system command. Of course some free (unasssigned) memory must exist in the CPC - that's quite obvious: you cannot add and use nonexistend memory.
Sources of free memory?
Examples:
1. Planning. Assuming you have 1024GB memory and you assigned 768GB to LPARs. So you have 256GB unassigned memory. Available for use. 2. Deactivated LPAR. You deactivated LPAR A - and now the memory from this LPAR is free now. You can add it to another LPAR. 3. Microcode upgrade. You purchased and "unblocked" existing physical memory within ypur CPC. 4. Hardware physical upgrade - possible for some multi-BOOK or multi-DRAWER configurations. Or just another book/drawer is added to CPC.

Regarding to the question, I repeat: in order to add memory to the LPAR without deac/act you have to define the LPAR with reserved memory.

--
Radoslaw Skorupka
Lodz, Poland







W dniu 26.06.2020 o 12:57, Michael Babcock pisze:
You are right.   We added it to the LPAR image profile And that took an
act/deact to add.  We had no other memory allocated to that LPAR (reserved
or otherwise).   How else could we have added the additional memory without
act/deact?

On Fri, Jun 26, 2020 at 3:54 AM R.S. <r.skoru...@bremultibank.com.pl> wrote:

No, you did not that way.
Probably you added some memory to LPAR profile, but this is not an LPAR
itself. It is LPAR definition which is used during LPAR activation. For
active LPAR it has no meaning. To compare: it is like change in JES2PARM
member after JES2 is started.

BTW: LPAR definition may contain more memory that is actually available.
For example you may have 1024GB memory, define 10 LPARs and "assign"
256GB to each LPAR. It will be accepted by the system with no error or
warning msg. However durin system activation (IML) only few of defined
LPAR will be activated correctly. Remaining LPARs will not be activated
due to lack of memory which is described in messages.

Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 25.06.2020 o 15:11, Michael Babcock pisze:
We recently added some unassigned memory to our production LPAR and
IPL’d.
The memory did not show.  We had to deactivate the LPAR and reactivate it
to add the memory.    This was on a z14-ZR1 with z/OS 2.3.


On Thu, Jun 25, 2020 at 5:31 AM R.S. <r.skoru...@bremultibank.com.pl>
wrote:
W dniu 23.06.2020 o 02:07, Charles Mills pisze:
Today is real storage day. Sorry for the elementary questions.

The folks that own the box as a whole have added memory to our LPAR. Do
we
need to IPL to pick that up in z/OS, or is there a command or similar
process? I thought I heard at a SHARE presentation that it could be
done
dynamically, but the box owners are telling us an IPL is required.

PR/SM, not VM, if that matters.

I don't understand details, so my answer is rather general:
1. LPAR can be defined with memory and "reserved" memory. That means it
is possible to get more memory than assingned during LPAR activation
(usually IML process).
2. OS may or may not support dynamic memory change. z/OS does support
it. So, it is possible to dynamically add memory to the system.
Assumpions are: LPAR definition as described above *and* free
(unassigned) storage in CPC. Free storage may come from deactivated
(other) LPAR.
3. It is also possible to buy memory without physical deactivation of
CPC. It is memory which is already inside the CPC, but microcode will
enable it for user. It can be done dynamically, and new memory will
appear as unassigned to any LPAR. Then you can add it do a system as
described above.
4. Amount of "memory for sale" within CPC depend on many factors. As far
as I know IBM want to disable this option ("preplanned memory"), however
AFAIK it is still possible to get a little bit more than ordered and the
gap can be bought and enabled.

Personally I always define LPARs with reserved memory just to have
option to for future unknown need. And I had cases when I really needed
additional memory.


HTH

--
Radoslaw Skorupka
Lodz, Poland


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



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

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

----------------------------------------------------------------------
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