Re: AW: Re: z/OS and hiperspaces

[David Betten]

Without getting too far into the DFSORT internals, I'll just clarify that
DFSORT generally prefers to use memory objects instead of Hiperspaces.
However, rather than remove the Hiperspace support we kept it there.  Part
of the reason is that often times the memlimit may prevent the use of
memory objects so DFSORT will instead choose Hiperspace if the system
controls and DFSORT defaults allow it.  Similarly our Dataspace sorting
logic is still there though rarely used since we will usually choose memory
objects or Hipersapces over that.  But it's there for backward
compatibility and you never know when someone has set things up such that
it's the only data in memory option available.  We try to make the best use
of available resources while also operating within the system controls in
place (memlimit, IEFUSI, region, etc.)


Have a nice day,
Dave Betten
z/OS Performance Specialist
Cloud and Systems Performance
IBM Corporation
email:  bet...@us.ibm.com

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
11/24/2015 03:35:27 PM:

> From: Martin Packer <martin_pac...@uk.ibm.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/24/2015 03:36 PM
> Subject: Re: AW: Re: z/OS and hiperspaces
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
> It also depends on the DFSORT-specific controls you put in place - as
Dave
> Betten former keeper of the controls (currently on vacation) will tell
> you.
>
> Cheers, Martin
>
> Martin Packer,
> zChampion, Principal Systems Investigator,
> Worldwide Cloud & Systems Performance, 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:   "R.S." <r.skoru...@bremultibank.com.pl>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   24/11/2015 20:31
> Subject:Re: AW: Re: z/OS and hiperspaces
> Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
>
>
> W dniu 2015-11-24 o 21:23, Vernooij, CP (ITOPT1) - KLM pisze:
> > Ah, my mistake. Hiperspaces are addressed differently from dataspaces
> and somewhere I thought I remembered that therefor they could be larger.
> Maybe to allow 24-bit applications to use 2 GB storage areas with
> hiperspaces?
> >
> > I am still wondering what the current value of hiper- and dataspaces
is,
> apart from being supported for older applications that were written to
use
> them.
> >
> > The DFSORT tuning pages state that they make a well calculated decision

> about using hiperspaces, dataspaces, 64-bit storage (addressable) and
> 64-bit objects (which's data must be moved to addressable storage to use
> it, like hiperspaces). Why not use 64-bit storage only, when it is
> available?
> >
> > In my system I did see DFSORT use all 4 area's for its work space.
> > DFSORT people: please explain?
> I'm not DFSORT folk, but I think, I can explain it.
> Some time ago I was fighting with some job consuming to much memory.
> First I limited its storage with MEMLIMIT, but then DFSORT started using
> *spaces instead. Still a lot of memory.
> The conclusion is simple: DFSORT use any of the memory kind which is
> available, with some preferences of course. Details depend on
> availability or given resources.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
> przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by
> jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste
> adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej
> przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie,

> rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie
> zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo,
> prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale
> usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is

> intended solely for business use of the addressee. This e-mail may only
be
> received by the addressee and may not be disclosed to any third parties.
> If you are not the intended addressee of this e-mail or the employee
> authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility
> in your e-mail software and delete pe

Re: AW: Re: z/OS and hiperspaces

[Jim Mulder]

> > Hiperspaces can be much larger than dataspaces, but you can have 
> many of both. 
> 
> 
> I don't think this is correct. Both are limited to the once 
> architectural limit of 2GB per instance.

  The 2GB limit for data spaces and hiperspaces is a z/OS 
implementation limit, not a processor architecture limit.

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY



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

Re: z/OS and hiperspaces

[Jim Mulder]

> One question I would liked answered by the experts is why now with 
> 64-bit storage one would choose to use a hiperspace (or dataspace) over 
> just using storage above the bar?

  TYPE=CACHE hiperspaces continue to provide a function that z/OS has 
not provided with 64-bit memory objects.  With TYPE=CACHE, the data you
write to the hiperspace remains in real storage (prior to zArchitecture,
it was in expanded storage) unless the system needs to steal that storage.
When the storage does need to be stolen, the system takes it without
paging the data out to aux .   The data is lost, and presumably the user
has another copy of it somewhere.  HiperBatch is one thing that uses
TYPE=CACHE hiperspaces.  Although I don't know how much HiperBatch is
used these days.  For QSAM, if zHPF is being used, HiperBatch will
not be used (which was done to avoid the development cost of 
implementing HiperBatch for QSAM zHPF).  So you can have the 
I/O performance improvement from zHPF for QSAM, or the I/O reduction
from HiperBatch caching for QSAM, but not both. 

im Mulder   z/OS System Test  IBM Corp.  Poughkeepsie,  NY



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

Re: AW: Re: z/OS and hiperspaces

[Martin Packer]

It also depends on the DFSORT-specific controls you put in place - as Dave 
Betten former keeper of the controls (currently on vacation) will tell 
you.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, 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:   "R.S." <r.skoru...@bremultibank.com.pl>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   24/11/2015 20:31
Subject:    Re: AW: Re: z/OS and hiperspaces
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



W dniu 2015-11-24 o 21:23, Vernooij, CP (ITOPT1) - KLM pisze:
> Ah, my mistake. Hiperspaces are addressed differently from dataspaces 
and somewhere I thought I remembered that therefor they could be larger. 
Maybe to allow 24-bit applications to use 2 GB storage areas with 
hiperspaces?
>
> I am still wondering what the current value of hiper- and dataspaces is, 
apart from being supported for older applications that were written to use 
them.
>
> The DFSORT tuning pages state that they make a well calculated decision 
about using hiperspaces, dataspaces, 64-bit storage (addressable) and 
64-bit objects (which's data must be moved to addressable storage to use 
it, like hiperspaces). Why not use 64-bit storage only, when it is 
available?
>
> In my system I did see DFSORT use all 4 area's for its work space.
> DFSORT people: please explain?
I'm not DFSORT folk, but I think, I can explain it.
Some time ago I was fighting with some job consuming to much memory. 
First I limited its storage with MEMLIMIT, but then DFSORT started using 
*spaces instead. Still a lot of memory.
The conclusion is simple: DFSORT use any of the memory kind which is 
available, with some preferences of course. Details depend on 
availability or given resources.

-- 
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by 
jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste 
adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej 
przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, 
rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie 
zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, 
prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale 
usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub 
zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. 
If you are not the intended addressee of this e-mail or the employee 
authorized to forward it to the addressee, be advised that any 
dissemination, copying, distribution or any other similar activity is 
legally prohibited and may be punishable. If you received this e-mail by 
mistake please advise the sender immediately by using the reply facility 
in your e-mail software and delete permanently this e-mail including any 
copies of it either printed or saved to hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego 
Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 
526-021-50-88. Wedug stanu na dzie 01.01.2015 r. kapita zakadowy 
mBanku S.A. (w caoci wpacony) wynosi 168.840.228 zotych.


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

AW: Re: AW: Re: z/OS and hiperspaces

[Peter Hunkeler]

> Just to complement another subthread: Hiperspace may, but not have to
> use expanded memory.


No, Hiperspaces did not need to use auxiliary storage. This is the kind of 
Hiperspace that Jim mentioned (type=cache). I think it was also called ESO 
Hiperspace; ESO = expanded storage only. Non-ESO Hiperspaces lived in expanded 
storage and were paged out to auxiliary, when expanded was under presure.



--
Peter Hunkeler



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

Re: z/OS and hiperspaces

[Jim Mulder]

> The whole point of expanded storage was that it was less expensive.
> Once IBM started carving out expanded memory from the same pool as
> regular memory, it became pointless, but by then IBM had code in place
> that provided an incentive to go along with the charade.

  That was the original point.  But when the price of real memory 
declined to the point where the ESA/390 31-bit real addressing
architecture limit became a practical constraint, expanded storage 
provided a way to have more than 2GB of processor memory 
(real + expanded) in a logical partition. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY



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

Re: AW: Re: z/OS and hiperspaces

[Vernooij, CP (ITOPT1) - KLM]

Ah, my mistake. Hiperspaces are addressed differently from dataspaces and 
somewhere I thought I remembered that therefor they could be larger. Maybe to 
allow 24-bit applications to use 2 GB storage areas with hiperspaces?

I am still wondering what the current value of hiper- and dataspaces is, apart 
from being supported for older applications that were written to use them.

The DFSORT tuning pages state that they make a well calculated decision about 
using hiperspaces, dataspaces, 64-bit storage (addressable) and 64-bit objects 
(which's data must be moved to addressable storage to use it, like 
hiperspaces). Why not use 64-bit storage only, when it is available? 

In my system I did see DFSORT use all 4 area's for its work space. 
DFSORT people: please explain?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, November 24, 2015 7:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AW: Re: z/OS and hiperspaces

W dniu 2015-11-24 o 17:18, Peter Hunkeler pisze:
>> Hiperspaces can be much larger than dataspaces, but you can have many of 
>> both.
>
> I don't think this is correct. Both are limited to the once architectural 
> limit of 2GB per instance.
>
Yes, both were limited to 2GB (can be smaller).

Just to complement another subthread: Hiperspace may, but not have to 
use expanded memory.
Both are functonally stabilized since 64-bit memory arrived.

-- 
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2015 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.840.228 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: Re: z/OS and hiperspaces

[R.S.]

W dniu 2015-11-24 o 21:23, Vernooij, CP (ITOPT1) - KLM pisze:

Ah, my mistake. Hiperspaces are addressed differently from dataspaces and 
somewhere I thought I remembered that therefor they could be larger. Maybe to 
allow 24-bit applications to use 2 GB storage areas with hiperspaces?

I am still wondering what the current value of hiper- and dataspaces is, apart 
from being supported for older applications that were written to use them.

The DFSORT tuning pages state that they make a well calculated decision about 
using hiperspaces, dataspaces, 64-bit storage (addressable) and 64-bit objects 
(which's data must be moved to addressable storage to use it, like 
hiperspaces). Why not use 64-bit storage only, when it is available?

In my system I did see DFSORT use all 4 area's for its work space.
DFSORT people: please explain?

I'm not DFSORT folk, but I think, I can explain it.
Some time ago I was fighting with some job consuming to much memory. 
First I limited its storage with MEMLIMIT, but then DFSORT started using 
*spaces instead. Still a lot of memory.
The conclusion is simple: DFSORT use any of the memory kind which is 
available, with some preferences of course. Details depend on 
availability or given resources.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2015 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.840.228 zotych.


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

Re: z/OS and hiperspaces

[Martin Packer]

On Hiperbatch: I would be surprised if ANYONE was still using it. Related 
(sort of) to zHPF is the fact it didn't support Extended Format VSAM or 
QSAM. And the size limits look puny in today's world.

Possibly not for public consumption: I've no idea if anyone would scream 
if Hiperbatch support was formally removed, nor how much maintenance / 
path length / bug-befuddlement that would save.)

(I remember Bob Rogers in late 1990 demo'ing a PC program that explained 
how Non-Retain Hiperbatch rolled up the carpet after the last reader.)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, 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:   Jim Mulder <d10j...@us.ibm.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   24/11/2015 20:46
Subject:        Re: z/OS and hiperspaces
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



> One question I would liked answered by the experts is why now with 
> 64-bit storage one would choose to use a hiperspace (or dataspace) over 
> just using storage above the bar?

  TYPE=CACHE hiperspaces continue to provide a function that z/OS has 
not provided with 64-bit memory objects.  With TYPE=CACHE, the data you
write to the hiperspace remains in real storage (prior to zArchitecture,
it was in expanded storage) unless the system needs to steal that storage.
When the storage does need to be stolen, the system takes it without
paging the data out to aux .   The data is lost, and presumably the user
has another copy of it somewhere.  HiperBatch is one thing that uses
TYPE=CACHE hiperspaces.  Although I don't know how much HiperBatch is
used these days.  For QSAM, if zHPF is being used, HiperBatch will
not be used (which was done to avoid the development cost of 
implementing HiperBatch for QSAM zHPF).  So you can have the 
I/O performance improvement from zHPF for QSAM, or the I/O reduction
from HiperBatch caching for QSAM, but not both. 

im Mulder   z/OS System Test  IBM Corp.  Poughkeepsie,  NY



--
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: AW: Re: z/OS and hiperspaces

[R.S.]

W dniu 2015-11-24 o 17:18, Peter Hunkeler pisze:

Hiperspaces can be much larger than dataspaces, but you can have many of both.


I don't think this is correct. Both are limited to the once architectural limit 
of 2GB per instance.


Yes, both were limited to 2GB (can be smaller).

Just to complement another subthread: Hiperspace may, but not have to 
use expanded memory.

Both are functonally stabilized since 64-bit memory arrived.

--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2015 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.840.228 zotych.


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

AW: Re: z/OS and hiperspaces

[Peter Hunkeler]

> Hiperspaces can be much larger than dataspaces, but you can have many of both.


I don't think this is correct. Both are limited to the once architectural limit 
of 2GB per instance.



--
Peter Hunkeler



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

Re: AW: Re: z/OS and hiperspaces

[Martin Packer]

IIRC Data Windowing Services could stitch them together - into an object 
larger than 2GB. I suspect we have the architects of DWS present in this 
very newsgroup.

As to the question of why not just go 64-Bit? ...

Philosophically Hiperspaces and Dataspaces are akin to segments - with 
access control to them. This separation MIGHT - for some applications - be 
valuable.

But I'd hope VSM had made the requirement for segmentation/separation less 
pressing over the past 30 years. :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, 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:   "R.S." <r.skoru...@bremultibank.com.pl>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   24/11/2015 18:49
Subject:    Re: AW: Re: z/OS and hiperspaces
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



W dniu 2015-11-24 o 17:18, Peter Hunkeler pisze:
>> Hiperspaces can be much larger than dataspaces, but you can have many 
of both.
>
> I don't think this is correct. Both are limited to the once 
architectural limit of 2GB per instance.
>
Yes, both were limited to 2GB (can be smaller).

Just to complement another subthread: Hiperspace may, but not have to 
use expanded memory.
Both are functonally stabilized since 64-bit memory arrived.

-- 
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by 
jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste 
adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej 
przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, 
rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie 
zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, 
prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale 
usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub 
zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. 
If you are not the intended addressee of this e-mail or the employee 
authorized to forward it to the addressee, be advised that any 
dissemination, copying, distribution or any other similar activity is 
legally prohibited and may be punishable. If you received this e-mail by 
mistake please advise the sender immediately by using the reply facility 
in your e-mail software and delete permanently this e-mail including any 
copies of it either printed or saved to hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego 
Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 
526-021-50-88. Wedug stanu na dzie 01.01.2015 r. kapita zakadowy 
mBanku S.A. (w caoci wpacony) wynosi 168.840.228 zotych.


--
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: z/OS and hiperspaces

[Martin Packer]

No: Expanded Storage DIDN'T become pointless: Hiperspaces, most notably 
DB2 Hiperpools, enabled address spaces to get round the 31-Bit Virtual 
Storage limit. And MVPG / ADMF made this more economical.

Yes: Their economy in using cheaper expanded storage went away. But that 
wasn't all the value.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, 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:   "Shmuel Metz (Seymour J.)" <shmuel+ibm-m...@patriot.net>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   24/11/2015 15:19
Subject:    Re: z/OS and hiperspaces
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



In
<874b151289704e46a874bf2ae6fdd8d1310ab...@kl126r4b.cs.ad.klmcorp.net>,
on 11/24/2015
   at 02:30 PM, "Vernooij, CP (ITOPT1) - KLM" <kees.verno...@klm.com>
said:

>but I remember reading that expanded storage is now virtualized in
>central storage.

The whole point of expanded storage was that it was less expensive.
Once IBM started carving out expanded memory from the same pool as
regular memory, it became pointless, but by then IBM had code in place
that provided an incentive to go along with the charade.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
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...@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: z/OS and hiperspaces

[Martin Packer]

Of course I meant to say "Hiperspaces DIDN'T become pointless".

Sorry for any confusion. Especially in MY head. :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, 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:   Martin Packer/UK/IBM@IBMGB
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   24/11/2015 19:22
Subject:    Re: z/OS and hiperspaces
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



No: Expanded Storage DIDN'T become pointless: Hiperspaces, most notably 
DB2 Hiperpools, enabled address spaces to get round the 31-Bit Virtual 
Storage limit. And MVPG / ADMF made this more economical.

Yes: Their economy in using cheaper expanded storage went away. But that 
wasn't all the value.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, 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:   "Shmuel Metz (Seymour J.)" <shmuel+ibm-m...@patriot.net>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   24/11/2015 15:19
Subject:Re: z/OS and hiperspaces
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



In
<874b151289704e46a874bf2ae6fdd8d1310ab...@kl126r4b.cs.ad.klmcorp.net>,
on 11/24/2015
   at 02:30 PM, "Vernooij, CP (ITOPT1) - KLM" <kees.verno...@klm.com>
said:

>but I remember reading that expanded storage is now virtualized in
>central storage.

The whole point of expanded storage was that it was less expensive.
Once IBM started carving out expanded memory from the same pool as
regular memory, it became pointless, but by then IBM had code in place
that provided an incentive to go along with the charade.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
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...@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: z/OS and hiperspaces

[Vernooij, CP (ITOPT1) - KLM]

Hi,

I suggest you also consider dataspaces. With regard to what users can do with 
them and what impact they have on the system, they are similar: they use 
virtual (and therefor central storage). E.g. IEFUSI has only one value to limit 
the a user's use of hiper- and dataspaces. A special user is DFSORT, which can 
use huge amounts of it, but takes well care not to the impact the system to 
much.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lindy Mayfield
Sent: Tuesday, November 24, 2015 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS and hiperspaces

Hi,

I want to learn about hiperspaces, especially what sorts of  z/OS tuning 
options there are to control them,  what might be the impact on the system if 
users create too many or too many large  ones, stuff like that.  Where  would I 
read and learn about things like that?

And is there a way to monitor hiperspaces,  like using RMF?

This is a totally new topic for me so I am beginning from the beginning.  
Google and friendly mail lists.  :)

Kind regards,
Lindy

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN

z/OS and hiperspaces

[Lindy Mayfield]

Hi,

I want to learn about hiperspaces, especially what sorts of  z/OS tuning 
options there are to control them,  what might be the impact on the system if 
users create too many or too many large  ones, stuff like that.  Where  would I 
read and learn about things like that?

And is there a way to monitor hiperspaces,  like using RMF?

This is a totally new topic for me so I am beginning from the beginning.  
Google and friendly mail lists.  :)

Kind regards,
Lindy

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

Re: z/OS and hiperspaces

[Vernooij, CP (ITOPT1) - KLM]

Hiperspaces were designed to reside in expanded storage (which was even 
intended to be shared by machines somewhere in a future universe). I think this 
has never been rewritten, but I remember reading that expanded storage is now 
virtualized in central storage.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Tuesday, November 24, 2015 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS and hiperspaces

On Tue, 24 Nov 2015 11:39:19 +, Rob Scott wrote:

>For MVS/ESA and upwards, dataspaces were great for expanding the virtual 
>storage available horizontally

Which I always thought was a monumental kludge - especially as IBM was peddling 
the corporate myth that "our platform" didn't need 64-bit.
I note the 2.1 manuals (at least) still refer to expanded memory usage for 
hiperspaces. Hmmm.

> 64-bit memory objects offer so much more.

Now it does - took a long time to get here. The initial implementation didn't 
even have SMF support.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS and hiperspaces

[Shane Ginnane]

On Tue, 24 Nov 2015 11:39:19 +, Rob Scott wrote:

>For MVS/ESA and upwards, dataspaces were great for expanding the virtual 
>storage available horizontally

Which I always thought was a monumental kludge - especially as IBM was peddling 
the corporate myth that "our platform" didn't need 64-bit.
I note the 2.1 manuals (at least) still refer to expanded memory usage for 
hiperspaces. Hmmm.

> 64-bit memory objects offer so much more.

Now it does - took a long time to get here. The initial implementation didn't 
even have SMF support.

Shane ...

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

Re: z/OS and hiperspaces

[Vernooij, CP (ITOPT1) - KLM]

In impacting the system, there is no difference in whatever storage a user 
consumes largely. It can/will result in heavy page-outs, which are not 
necessarily bad if the pages are old, and consequently heave page-ins which 
will impact your system performance.
Hiperspaces can be much larger than dataspaces, but you can have many of both.
The structure of hiper- and dataspaces are quite different and the techniques 
to use them are evenly different. The same is true for 64-bit storage.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lindy Mayfield
Sent: Tuesday, November 24, 2015 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS and hiperspaces

I was under the impression that hiperspace is a bit better choice over 
dataspace for larger work files.  But actually I'm trying to understand how 
both types of them work, and how users could potentially impact a system if 
they can allocate large amounts of hiperspace or dataspace memory.

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, November 24, 2015 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS and hiperspaces

Hi,

I suggest you also consider dataspaces. With regard to what users can do with 
them and what impact they have on the system, they are similar: they use 
virtual (and therefor central storage). E.g. IEFUSI has only one value to limit 
the a user's use of hiper- and dataspaces. A special user is DFSORT, which can 
use huge amounts of it, but takes well care not to the impact the system to 
much.

Kees.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS and hiperspaces

[Shmuel Metz (Seymour J.)]

In
<874b151289704e46a874bf2ae6fdd8d1310ab...@kl126r4b.cs.ad.klmcorp.net>,
on 11/24/2015
   at 02:30 PM, "Vernooij, CP (ITOPT1) - KLM" 
said:

>but I remember reading that expanded storage is now virtualized in
>central storage.

The whole point of expanded storage was that it was less expensive.
Once IBM started carving out expanded memory from the same pool as
regular memory, it became pointless, but by then IBM had code in place
that provided an incentive to go along with the charade.
 
-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS and hiperspaces

[Lindy Mayfield]

Does it work like this?  If it is a simple batch program then memory allocation 
totals (including hiperspaces) can be controlled by IEFUSI.  I mean, if for 
some reason hyperspace usage becomes a problem on the system.

But what if that address space is dubbed as an OMVS address space? Do the 
BPXPRM memory options then impose the final limits? Like ASSIZEMAX/MAXASSIZE?

Another way of asking, if for some reason hyperspace usage became a problem and 
the problem program ran in a UNIX address space, would BPXPRM limits (or 
corresponding RACF OMVS segment) be a way to tune things?

Regards,
Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, November 24, 2015 4:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS and hiperspaces

In impacting the system, there is no difference in whatever storage a user 
consumes largely. It can/will result in heavy page-outs, which are not 
necessarily bad if the pages are old, and consequently heave page-ins which 
will impact your system performance.
Hiperspaces can be much larger than dataspaces, but you can have many of both.
The structure of hiper- and dataspaces are quite different and the techniques 
to use them are evenly different. The same is true for 64-bit storage.

Kees.

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

Re: z/OS and hiperspaces

[R.S.]

W dniu 2015-11-24 o 15:30, Vernooij, CP (ITOPT1) - KLM pisze:

Hiperspaces were designed to reside in expanded storage (which was even 
intended to be shared by machines somewhere in a future universe). I think this 
has never been rewritten, but I remember reading that expanded storage is now 
virtualized in central storage.
Expanded storage was virtualized in the times of 9672 machines - it was 
the same physical memory chips, allocated as expanded by HMC profiles. 
Now it is still done like before, but z/OS does not use expanded memory 
(in 64-bit mode, let's leave z/OS in 31-bit mode). However z/VM is still 
able to use expanded memory.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

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, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: z/OS and hiperspaces

[David Crayford]

One question I would liked answered by the experts is why now with 
64-bit storage one would choose to use a hiperspace (or dataspace) over 
just using storage above the bar?


On 24/11/2015 6:37 PM, Vernooij, CP (ITOPT1) - KLM wrote:

Hi,

I suggest you also consider dataspaces. With regard to what users can do with 
them and what impact they have on the system, they are similar: they use 
virtual (and therefor central storage). E.g. IEFUSI has only one value to limit 
the a user's use of hiper- and dataspaces. A special user is DFSORT, which can 
use huge amounts of it, but takes well care not to the impact the system to 
much.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lindy Mayfield
Sent: Tuesday, November 24, 2015 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS and hiperspaces

Hi,

I want to learn about hiperspaces, especially what sorts of  z/OS tuning 
options there are to control them,  what might be the impact on the system if 
users create too many or too many large  ones, stuff like that.  Where  would I 
read and learn about things like that?

And is there a way to monitor hiperspaces,  like using RMF?

This is a totally new topic for me so I am beginning from the beginning.  
Google and friendly mail lists.  :)

Kind regards,
Lindy

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.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...@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: z/OS and hiperspaces

[Vernooij, CP (ITOPT1) - KLM]

That is something I wondered after studying the DFSORT tuning pages. 

There is however a significant difference between dataspaces and hiperspaces. 
Data in dataspaces is directly addressable, data in hiperspace must be copied 
(causing overhead) to the user's address space to be addressable. DFSORT uses 
64-bit storage in the same 2 different modes.
However DFSORT says it always decides which storage to use, based on the 
current status of the system. Apparently there are parameters that can value 
each of the 4 storage locations above the others in certain situations.

Maybe the DFSORT people can elaborate on these situations and decisions.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Tuesday, November 24, 2015 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS and hiperspaces

One question I would liked answered by the experts is why now with 
64-bit storage one would choose to use a hiperspace (or dataspace) over 
just using storage above the bar?

On 24/11/2015 6:37 PM, Vernooij, CP (ITOPT1) - KLM wrote:
> Hi,
>
> I suggest you also consider dataspaces. With regard to what users can do with 
> them and what impact they have on the system, they are similar: they use 
> virtual (and therefor central storage). E.g. IEFUSI has only one value to 
> limit the a user's use of hiper- and dataspaces. A special user is DFSORT, 
> which can use huge amounts of it, but takes well care not to the impact the 
> system to much.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Lindy Mayfield
> Sent: Tuesday, November 24, 2015 11:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: z/OS and hiperspaces
>
> Hi,
>
> I want to learn about hiperspaces, especially what sorts of  z/OS tuning 
> options there are to control them,  what might be the impact on the system if 
> users create too many or too many large  ones, stuff like that.  Where  would 
> I read and learn about things like that?
>
> And is there a way to monitor hiperspaces,  like using RMF?
>
> This is a totally new topic for me so I am beginning from the beginning.  
> Google and friendly mail lists.  :)
>
> Kind regards,
> Lindy
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.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...@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 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

Re: z/OS and hiperspaces

[Rob Scott]

For MVS/ESA and upwards, dataspaces were great for expanding the virtual 
storage available horizontally, however these days I do not believe I would use 
them in any new code or designs.

64-bit memory objects offer so much more.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, November 24, 2015 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS and hiperspaces

Hi,

I suggest you also consider dataspaces. With regard to what users can do with 
them and what impact they have on the system, they are similar: they use 
virtual (and therefor central storage). E.g. IEFUSI has only one value to limit 
the a user's use of hiper- and dataspaces. A special user is DFSORT, which can 
use huge amounts of it, but takes well care not to the impact the system to 
much.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lindy Mayfield
Sent: Tuesday, November 24, 2015 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS and hiperspaces

Hi,

I want to learn about hiperspaces, especially what sorts of  z/OS tuning 
options there are to control them,  what might be the impact on the system if 
users create too many or too many large  ones, stuff like that.  Where  would I 
read and learn about things like that?

And is there a way to monitor hiperspaces,  like using RMF?

This is a totally new topic for me so I am beginning from the beginning.  
Google and friendly mail lists.  :)

Kind regards,
Lindy

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: z/OS and hiperspaces

[Art Celestini]

I can speak for Syncsort ...

Dataspaces, Hiperspaces, and 64-bit momory objects are all managed as 
"Strategic Hierarchial Storage" in the MFX (current sort) product.  MFX uses a 
central (Dynamic Storage Manager, or DSM) address space to regulate use of 
storage across all concurrently running sorts and copies.  Part of that process 
is the SYSEVENT STGTEST system call where SRM returns a set of numbers that 
reflect the current real frame availability across the entire system.  A single 
instance of a sort or copy decides the type and how much storage to use based 
on the requirements of the sort/copy, the amounts the job is permitted to use 
(IEFUSI, etc.) and the amounts of storage DSM indicates is safe to use.  

Art Celestini
Technology Architect
Mainframe Development
Syncsort Inc.

=
Mail sent to the "From" address in this post will be refused.  Please send 
off-list email to:  ibmmaincelestinicom.


At 06:39 AM 11/24/2015, Rob Scott wrote:
 
>For MVS/ESA and upwards, dataspaces were great for expanding the virtual 
>storage available horizontally, however these days I do not believe I would 
>use them in any new code or designs.
>
>64-bit memory objects offer so much more.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Vernooij, CP (ITOPT1) - KLM
>Sent: Tuesday, November 24, 2015 10:37 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: z/OS and hiperspaces
>
>Hi,
>
>I suggest you also consider dataspaces. With regard to what users can do with 
>them and what impact they have on the system, they are similar: they use 
>virtual (and therefor central storage). E.g. IEFUSI has only one value to 
>limit the a user's use of hiper- and dataspaces. A special user is DFSORT, 
>which can use huge amounts of it, but takes well care not to the impact the 
>system to much.
>
>Kees.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Lindy Mayfield
>Sent: Tuesday, November 24, 2015 11:28 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: z/OS and hiperspaces
>
>Hi,
>
>I want to learn about hiperspaces, especially what sorts of  z/OS tuning 
>options there are to control them,  what might be the impact on the system if 
>users create too many or too many large  ones, stuff like that.  Where  would 
>I read and learn about things like that?
>
>And is there a way to monitor hiperspaces,  like using RMF?
>
>This is a totally new topic for me so I am beginning from the beginning.  
>Google and friendly mail lists.  :)
>
>Kind regards,
>Lindy

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

Re: z/OS and hiperspaces

[Lindy Mayfield]

I was under the impression that hiperspace is a bit better choice over 
dataspace for larger work files.  But actually I'm trying to understand how 
both types of them work, and how users could potentially impact a system if 
they can allocate large amounts of hiperspace or dataspace memory.

Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, November 24, 2015 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS and hiperspaces

Hi,

I suggest you also consider dataspaces. With regard to what users can do with 
them and what impact they have on the system, they are similar: they use 
virtual (and therefor central storage). E.g. IEFUSI has only one value to limit 
the a user's use of hiper- and dataspaces. A special user is DFSORT, which can 
use huge amounts of it, but takes well care not to the impact the system to 
much.

Kees.

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