Re: Does adding real storage require an IPL?
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. 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.
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
Re: Does adding real storage require an IPL?
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. 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.
> 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 po
> dobne
> 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 025237, 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 act
> ion,
> 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
Re: Does adding real storage require an IPL?
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. 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 025237,
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
025237, 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
Re: Does adding real storage require an IPL?
That is exactly how it works: in the activation profile you specify the memory
and reserved memory for an LPAR. That is all it will see after activation with
that profile.
Kees
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Michael Babcock
Sent: 25 June 2020 15:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Does adding real storage require an IPL?
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. 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. Senat
> <https://www.google.com/maps/search/Warszawie,+ul.+Senat?entry=gmail=g>orska
> 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 025237, 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. Senat
> <https://www.google.com/maps/search/d+office+in+Warsaw,+ul.+Senat?entry=gmail=g>orska
> 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 025237, 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
>
--
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead
--
For IBM-MAIN subscribe / signoff / archi
Re: Does adding real storage require an IPL?
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. 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. Senat
> orska
> 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 025237, 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. Senat
> orska
> 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 025237, 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
>
--
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does adding real storage require an IPL?
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 025237,
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
025237, 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
Re: Does adding real storage require an IPL?
CF STOR(nG),ONLINE You may also need: CF E=(storage element),ONLINE Sent from my Verizon, Samsung Galaxy smartphone From: IBM Mainframe Discussion List on behalf of Peter Bishop Sent: Monday, June 22, 2020 9:26:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Does adding real storage require an IPL? Hi Charles, Changing the image profile requires a deactivation and reactivation of the LPAR, so if the LPAR isn't already defined to allow dynamic storage reconfiguration, you will need one IPL to get to the new state where it is. The manual for this is the PR/SM Planning Guide, which has a good discussion of the basics. As Dave says, if the profile already has the storage available, CF STOR will work dynamically. When storage was more expensive, we had some Reserved storage as well as the Initial to allow for CF STOR(E=1) to move it from one test LPAR to another (overnight). Now we just have a single much larger Initial setting and avoid the movement of storage between LPARs (i.e. CF STOR OFFLINE in the donor and ONLINE in the recipient), which was sometimes delayed by tasks holding storage intended to be reallocated. best regards, Peter On 23/06/2020 10:11 am, Jousma, David wrote: > No. Might have to add it to the image profile on the HMC, and if already > there, then a CONFIG command on the console. > > _ > 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 On Behalf Of > Charles Mills > Sent: Monday, June 22, 2020 8:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Does adding real storage require an IPL? > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > 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. > > Thanks much! > > Charles Mills > +1-707-291-0908 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL > EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does adding real storage require an IPL?
Well, in what was apparently a bit of a miscommunication, the box owners IPLed our LPAR, so the issue is now moot. But the storage is there! Thanks all, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Bishop Sent: Monday, June 22, 2020 6:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Does adding real storage require an IPL? Hi Charles, Changing the image profile requires a deactivation and reactivation of the LPAR, so if the LPAR isn't already defined to allow dynamic storage reconfiguration, you will need one IPL to get to the new state where it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does adding real storage require an IPL?
Hi Charles, Changing the image profile requires a deactivation and reactivation of the LPAR, so if the LPAR isn't already defined to allow dynamic storage reconfiguration, you will need one IPL to get to the new state where it is. The manual for this is the PR/SM Planning Guide, which has a good discussion of the basics. As Dave says, if the profile already has the storage available, CF STOR will work dynamically. When storage was more expensive, we had some Reserved storage as well as the Initial to allow for CF STOR(E=1) to move it from one test LPAR to another (overnight). Now we just have a single much larger Initial setting and avoid the movement of storage between LPARs (i.e. CF STOR OFFLINE in the donor and ONLINE in the recipient), which was sometimes delayed by tasks holding storage intended to be reallocated. best regards, Peter On 23/06/2020 10:11 am, Jousma, David wrote: No. Might have to add it to the image profile on the HMC, and if already there, then a CONFIG command on the console. _ 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 On Behalf Of Charles Mills Sent: Monday, June 22, 2020 8:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Does adding real storage require an IPL? **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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. Thanks much! Charles Mills +1-707-291-0908 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does adding real storage require an IPL?
No. Might have to add it to the image profile on the HMC, and if already there, then a CONFIG command on the console. _ 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 On Behalf Of Charles Mills Sent: Monday, June 22, 2020 8:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Does adding real storage require an IPL? **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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. Thanks much! Charles Mills +1-707-291-0908 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
