Re: Buffer pool question...

Eric Pearson

Re: Buffer pool question...
(in response to ritu zee)
CMOS is the chip architecure of the machine, not a type
of memory. CMOS machines typically have more mips/$ and
cost less (electricity, etc.) to run than their predecessors.

You will have the 2GB limit until there is an OS architecture
upgrade (Z/OS?)

regards,

eric pearson
NS ITO Database Support


-----Original Message-----
From: ritu zee [mailto:[login to unmask email]
Sent: Wednesday, December 20, 2000 3:26 PM
To: [login to unmask email]
Subject: Buffer pool question...


Hi!

Have a basic question. I know that Virtual buffer
pools occupy space in DBM1 address space and
hiperpools occupy 'expanded storage'. Someone around
here says that 'CMOS' storage is the latest type of
storage and storage for virtual pools should be
allocated in CMOS storage.

Could someone explain to me what 'CMOS' is and how is
it least expensive? Also, 2 GB is the maximum buffer
pool size; does transferring our virtual buffer pools
to CMOS still have that 2GB limit?

Thanks.
Ritu.

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/








ritu zee

Buffer pool question...
Hi!

Have a basic question. I know that Virtual buffer
pools occupy space in DBM1 address space and
hiperpools occupy 'expanded storage'. Someone around
here says that 'CMOS' storage is the latest type of
storage and storage for virtual pools should be
allocated in CMOS storage.

Could someone explain to me what 'CMOS' is and how is
it least expensive? Also, 2 GB is the maximum buffer
pool size; does transferring our virtual buffer pools
to CMOS still have that 2GB limit?

Thanks.
Ritu.

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/



cliff boley

Re: Buffer pool question...
(in response to Eric Pearson)
Also with the new CMOS machines all memory is the same, main, no expanded.
In the os/390/MVS set up you can allocate some of your main memory as
expanded, but it is not
required.
I've removed all hypepools from my bufferpool allocations.
cliff:-)

-----Original Message-----
From: Pearson, Eric L, [mailto:[login to unmask email]
Sent: Wednesday, December 20, 2000 12:25 PM
To: [login to unmask email]
Subject: Re: Buffer pool question...


CMOS is the chip architecure of the machine, not a type
of memory. CMOS machines typically have more mips/$ and
cost less (electricity, etc.) to run than their predecessors.

You will have the 2GB limit until there is an OS architecture
upgrade (Z/OS?)

regards,

eric pearson
NS ITO Database Support


-----Original Message-----
From: ritu zee [mailto:[login to unmask email]
Sent: Wednesday, December 20, 2000 3:26 PM
To: [login to unmask email]
Subject: Buffer pool question...


Hi!

Have a basic question. I know that Virtual buffer
pools occupy space in DBM1 address space and
hiperpools occupy 'expanded storage'. Someone around
here says that 'CMOS' storage is the latest type of
storage and storage for virtual pools should be
allocated in CMOS storage.

Could someone explain to me what 'CMOS' is and how is
it least expensive? Also, 2 GB is the maximum buffer
pool size; does transferring our virtual buffer pools
to CMOS still have that 2GB limit?

Thanks.
Ritu.

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/













ritu zee

Re: Buffer pool question...
(in response to cliff boley)
All main memory…no expanded !! Well what about the
maxim ' You can allocate a maximum of 2GB for virtual
buffer pool but up to 8GB for hiperpools in expanded
storage'.

Do all these maxims cease to be true now with CMOS? Of
course as I understand, 2 GB limit for virtual buffer
pools is still true. So, we would still want
hiperpools if we want to 'back' the buffer pools up
with additional storage. If you do choose to go for
hiperpools, we would have to allocate some of our main
memory as expanded. Isn't it ?

The 'traditional' buffer pool definition is "Buffer
pools are areas of 'virtual storage' that temporarily
store pages of table spaces or indexes."

Now that all is main, should the definition be
changed.
DB2 Gurus, unfortunately your replies have resulted in
more confusion than clarity. Please elucidate.

Thanks
Ritu.

--- Cliff Boley <[login to unmask email]>
wrote:
> Also with the new CMOS machines all memory is the
> same, main, no expanded.
> In the os/390/MVS set up you can allocate some of
> your main memory as
> expanded, but it is not
> required.
> I've removed all hypepools from my bufferpool
> allocations.
> cliff:-)
>
> -----Original Message-----
> From: Pearson, Eric L,
> [mailto:[login to unmask email]
> Sent: Wednesday, December 20, 2000 12:25 PM
> To: [login to unmask email]
> Subject: Re: Buffer pool question...
>
>
> CMOS is the chip architecure of the machine, not a
> type
> of memory. CMOS machines typically have more mips/$
> and
> cost less (electricity, etc.) to run than their
> predecessors.
>
> You will have the 2GB limit until there is an OS
> architecture
> upgrade (Z/OS?)
>
> regards,
>
> eric pearson
> NS ITO Database Support
>
>
> -----Original Message-----
> From: ritu zee [mailto:[login to unmask email]
> Sent: Wednesday, December 20, 2000 3:26 PM
> To: [login to unmask email]
> Subject: Buffer pool question...
>
>
> Hi!
>
> Have a basic question. I know that Virtual
> buffer
> pools occupy space in DBM1 address space and
> hiperpools occupy 'expanded storage'. Someone around
> here says that 'CMOS' storage is the latest type of
> storage and storage for virtual pools should be
> allocated in CMOS storage.
>
> Could someone explain to me what 'CMOS' is
> and how is
> it least expensive? Also, 2 GB is the maximum buffer
> pool size; does transferring our virtual buffer
> pools
> to CMOS still have that 2GB limit?
>
> Thanks.
> Ritu.
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
> Products.
> http://shopping.yahoo.com/
>
>
> To change your subscription options or to cancel
> your subscription visit the
> DB2-L webpage at http://www.ryci.com/db2-l. The
> owners of the list can be
>
>
>
> To change your subscription options or to cancel
> your subscription visit the
> DB2-L webpage at http://www.ryci.com/db2-l. The
> owners of the list can be
>
>
>
> To change your subscription options or to cancel
> your subscription visit the DB2-L webpage at
> http://www.ryci.com/db2-l. The owners of the list
> can


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/



[login to unmask email]

Re: Buffer pool question...
(in response to ritu zee)
In V5 OS/390 that's 2MB for DBM1 address space (includes Rid pool, sort
pool(s), EDM pool, VBP's) and 2GB (one hiperspace) total for all hiperpools
in one DB2 subsystem, as I recall...

George



Piontkowski Michael ML

Re: Buffer pool question...
(in response to truman.g.brown@VERIZON.COM)
Before CMOS machines, central storage memory was more
expensive ($) than expanded storage memory.

On CMOS machines, central storage memory & expanded storage
memory are the same price and the same physical memory.
Hence, the ROT on CMOS machines is to configure most of the
memory for central storage. I believe there are some OS/390
functions that require expanded storage. Not a good idea
to configure 0MB of expanded storage.


Mike Piontkowski
TP&S Technical Maintenance
Voice: +1 302.886.4612
Fax: +1 302.886.4749


-----Original Message-----
From: Pearson, Eric L, [mailto:[login to unmask email]
Sent: Wednesday, December 20, 2000 15:25
To: [login to unmask email]
Subject: Re: [DB2-L] Buffer pool question...


CMOS is the chip architecure of the machine, not a type
of memory. CMOS machines typically have more mips/$ and
cost less (electricity, etc.) to run than their predecessors.

You will have the 2GB limit until there is an OS architecture
upgrade (Z/OS?)

regards,

eric pearson
NS ITO Database Support


-----Original Message-----
From: ritu zee [mailto:[login to unmask email]
Sent: Wednesday, December 20, 2000 3:26 PM
To: [login to unmask email]
Subject: Buffer pool question...


Hi!

Have a basic question. I know that Virtual buffer
pools occupy space in DBM1 address space and
hiperpools occupy 'expanded storage'. Someone around
here says that 'CMOS' storage is the latest type of
storage and storage for virtual pools should be
allocated in CMOS storage.

Could someone explain to me what 'CMOS' is and how is
it least expensive? Also, 2 GB is the maximum buffer
pool size; does transferring our virtual buffer pools
to CMOS still have that 2GB limit?

Thanks.
Ritu.

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/













III Edward(Ed) J. Finnell

Re: Buffer pool question...
(in response to Piontkowski Michael ML)
At www.s390.ibm.com the LSPR number use 3:1 for 9672 CMOS technology, 1:4
for 3090 bipolar benchmarks. It's a good place to start for a "general workload".
Hiperpools come out of ADMF (Asynchronous Data mover Facility). There's 8Gig
per CEC. The newer processors(I think G5 or higher) have improved hardware and
ADMF comes out of Expanded storage.

The new z/900 "Freeway" 64bit machines are all central and the numbers have been
cranked up significantly for z/OS (next edition after 2.10). Think about it, how are you
going to page some of those humongous dataspaces?


Edward(Ed) J. Finnell,III
eSystems Proj. Mgr.
www.ua.edu


Download the Farscape Browser at http://www.scifi.com/farscape/



James Campbell

Re: Buffer pool question...
(in response to III Edward(Ed) J. Finnell)
Perhaps this will clear up some confusion that seems to exist:

Up to OS/390 V2.9, the memory addressing used allowed 2Gb "real" memory.
Real memory is memory that can be used in normal machine instructions. An
additional type of memory, called "expanded" memory was also available.
However, the only machine instructions that can reference expanded memory
are a set of instructions to copy 4kb pages to and from real memory.

In the "old" days real and expanded memory were physically different and
differently priced. At various times, different hardware manufacturers
changed so that real and expanded memory were physically the same. This
change tended to co-incide with the change to using CMOS technology for both
the processor and memory. The changes were independent, but driven by the
same cost/performance pressures.

In an LPAR type central processor, there are facilities to configure the
actual memory as real and expanded memory to each LPAR.

V2.7 Initialisation and Tuning Guide 3.2.11 Pageable Frame Stealing: "...
For systems with no expanded storage ...". And 1.4.5.5 Recommendations for
Improving System Performance "... Configure as much storage as possible as
central storage. Configure only enough expanded storage to support workloads
that rely specifically on the availability of ES plus a reasonable
additional amount to provide a margin of safety. ..." (Same quotes exist in
the V2.10 version of this manual). Since this implies that there is nothing
in OS/390 itself that mandates expanded memory, once one had carved up the
available actual memory between LPARs, if the memory given to an LPAR was
less than 2Gb, one would make it all real. Only if there was more than 2Gb
would one allocate the rest to expanded.

OS/390 V2.10 with zArchitecture allows 2**64 bytes (16 exabytes?) of real
memory - but you have to give up using expanded memory. And why would you
impose the overheads of using expanded when you could use the same memory as
real?

There has been no announcement on changing the 2Gb limit (actually 1.6Gb) on
total bufferpool size - at least to DB2 V6. <WARNING the following
statement is my personal speculation, not a statement based on some inside
information> However, I can see the bits are coming into place to increase
the limit to 2Gb per bufferpool </WARNING>. (For example, V6 allows
individual bufferpools to be kept in dataspaces outside DBM1.) Beyond that
would require a change to the 2Gb per address space limit and there has been
no indication that this is even being planned except for USS purposes.

/* standard disclaimer */
James Campbell
DBA
Hansen Corporation, Doncaster
+61 3 9843 8442
[login to unmask email]



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



[login to unmask email]

Re: Buffer pool question...
(in response to James Campbell)
Thank you James. As always, a very articulate and informative reply.

Norm Daley
Cinergy

-----Original Message-----
From: James Campbell [mailto:[login to unmask email]
Sent: Wednesday, December 20, 2000 7:58 PM
To: [login to unmask email]
Subject: Re: Buffer pool question...


Perhaps this will clear up some confusion that seems to exist:

Up to OS/390 V2.9, the memory addressing used allowed 2Gb "real" memory.
Real memory is memory that can be used in normal machine instructions. An
additional type of memory, called "expanded" memory was also available.
However, the only machine instructions that can reference expanded memory
are a set of instructions to copy 4kb pages to and from real memory.

In the "old" days real and expanded memory were physically different and
differently priced. At various times, different hardware manufacturers
changed so that real and expanded memory were physically the same. This
change tended to co-incide with the change to using CMOS technology for both
the processor and memory. The changes were independent, but driven by the
same cost/performance pressures.

In an LPAR type central processor, there are facilities to configure the
actual memory as real and expanded memory to each LPAR.

V2.7 Initialisation and Tuning Guide 3.2.11 Pageable Frame Stealing: "...
For systems with no expanded storage ...". And 1.4.5.5 Recommendations for
Improving System Performance "... Configure as much storage as possible as
central storage. Configure only enough expanded storage to support workloads
that rely specifically on the availability of ES plus a reasonable
additional amount to provide a margin of safety. ..." (Same quotes exist in
the V2.10 version of this manual). Since this implies that there is nothing
in OS/390 itself that mandates expanded memory, once one had carved up the
available actual memory between LPARs, if the memory given to an LPAR was
less than 2Gb, one would make it all real. Only if there was more than 2Gb
would one allocate the rest to expanded.

OS/390 V2.10 with zArchitecture allows 2**64 bytes (16 exabytes?) of real
memory - but you have to give up using expanded memory. And why would you
impose the overheads of using expanded when you could use the same memory as
real?

There has been no announcement on changing the 2Gb limit (actually 1.6Gb) on
total bufferpool size - at least to DB2 V6. <WARNING the following
statement is my personal speculation, not a statement based on some inside
information> However, I can see the bits are coming into place to increase
the limit to 2Gb per bufferpool </WARNING>. (For example, V6 allows
individual bufferpools to be kept in dataspaces outside DBM1.) Beyond that
would require a change to the 2Gb per address space limit and there has been
no indication that this is even being planned except for USS purposes.

/* standard disclaimer */
James Campbell
DBA
Hansen Corporation, Doncaster
+61 3 9843 8442
[login to unmask email]



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************








Jon Nolting

Re: Buffer pool question...
(in response to NDaley@CINERGY.COM)
ADMF is a hardware instruction that moves data between main and expanded
storage. It does not define main or expanded storage. It is only an
asynchronous instruction used to minimize the CPU expense of moving pages
between main and expanded by offloading that function to the IOP. ADMF was
introduced specifically to reduce CPU consumption by DB2 in managing
virtual buffers and hiperpools. Use of ADMF is selectable in the partition
activation profile and will be used by DB2 if enabled.

On the newer and faster processors (G5/G6), IBM is backing away from ADMF
with the introduction of Fasy Synchronous Data Mover (FSDM) which returns
to synchronous movement of single pages between main and expanded. With
DB2 APAR PQ38174, DB2 will now disregard ADMF even if enabled on processors
with FSDM.

At 06:13 PM 12/20/00 -0600, you wrote:
>At www.s390.ibm.com the LSPR number use 3:1 for 9672 CMOS technology, 1:4
>for 3090 bipolar benchmarks. It's a good place to start for a "general
workload".
>Hiperpools come out of ADMF (Asynchronous Data mover Facility). There's 8Gig
>per CEC. The newer processors(I think G5 or higher) have improved hardware
and
>ADMF comes out of Expanded storage.
>
>The new z/900 "Freeway" 64bit machines are all central and the numbers
have been
>cranked up significantly for z/OS (next edition after 2.10). Think about
it, how are you
>going to page some of those humongous dataspaces?
>
>
>Edward(Ed) J. Finnell,III
>eSystems Proj. Mgr.
>www.ua.edu
>
>
>Download the Farscape Browser at http://www.scifi.com/farscape/
>
>
>


>
>

Jon Nolting
(925) 672-1249 -- Home office



III Edward(Ed) J. Finnell

Re: Buffer pool question...
(in response to Jon Nolting)
Thanks for the update, I was trying to get out of Dodge before the weather
closed in and didn't look at my notes (or my R26)<g>.


Edward(Ed) J. Finnell,III
eSystems Proj. Mgr.
www.ua.edu


Download the Farscape Browser at http://www.scifi.com/farscape/



III Edward(Ed) J. Finnell

Re: Buffer pool question...
(in response to III Edward(Ed) J. Finnell)
Not sleeting yet....
From the text of PQ38174:

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: All DB2 users using hiperpools. *
****************************************************************
* PROBLEM DESCRIPTION: Currently, DB2 does not allow the use *
* of hiperpools unless the Asynchronous *
* Data Mover Facility is installed. In *
* order to support future hardware, this *
* restriction must be changed. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
Note: Microcode Driver 26 must be on to allow DB2 hiperpools
to be used by the Fast Sync Data Mover Facility.

PROBLEM CONCLUSION:
DB2 startup code has been modified to remove the restriction
for a possible hardware change. Hiperpools still can only be
used on existing hardware when ADMF is installed.

ERROR DESCRIPTION:
Allow hiperpools to be used without using admf.
additional description:
ADMF was invented to improve storage-to-storage movement of
large blocks of data. The continued evolution of CMOS
processor and memory technology in G5/G6 has improved
synchronous data movement using the Move Page instruction to
the point where its performance is on a par with ADMF. The
Fast Sync Data Mover Facility will be implemented on G5/G6 and
future processors as an indicator to DB2 that Move Page should
be used in place of ADMF. This apar causes DB2 to check for
this indicator and use Move Page instead of ADMF. Hiperpools
can still be used even if the ADMF facility is not used. DB2
will continue to use ADMF on pre-G5 machines. DB2 without this
apar will also continue to use ADMF on G5/G6.

Status Detail: SHIPMENT - Packaged solution is available for
shipment.

PE PTF List:

PTF List:
Release 410 : UQ44086 available 00/06/19 (F006 )
Release 510 : UQ44087 available 00/06/19 (F006 )
Release 610 : UQ44088 available 00/06/19 (F006 )










Edward(Ed) J. Finnell,III
eSystems Proj. Mgr.
www.ua.edu


Download the Farscape Browser at http://www.scifi.com/farscape/



III Edward(Ed) J. Finnell

Re: Buffer pool question...
(in response to III Edward(Ed) J. Finnell)
This is it it! I'm outta here.....PQ38174 has been superceded (SUP'd) by PQ42722.

* Synchronous Data Mover. *
****************************************************************
* PROBLEM DESCRIPTION: ABEND04E RC00C200CD in DSNB1GHP, when *
* using hiperpools with bufferpools with *
* a page size of 16K or 32K. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
When the Fast Synchronous Data Mover facility (FSDM) is
available, DB2 avoids the use of the Asynchronous Data Mover
Facility (ADMF) by setting the ADMF threshold to 255. However,
this threshold represents 4K blocks and not pages, so for 16K
and 32K buffer pools there is a chance that a set of pages being
written to the hiperpool will be large enough to cause DB2 to
use ADMF. If ADMF is not installed, this will result in an
ABEND04E RC00C200CD in DSNB1GHP.



Edward(Ed) J. Finnell,III
eSystems Proj. Mgr.
www.ua.edu


Download the Farscape Browser at http://www.scifi.com/farscape/



ritu zee

Re: Buffer pool question...
(in response to III Edward(Ed) J. Finnell)
James, Ed, Michael, Cliff,

Thanks for the reply; though my ordinary senses
responded most to James's 'down to earth' replay.
Things seem to be getting clearer now. But one last
question …..in this scheme of real and expanded
storage, where does 'virtual storage' come into
picture? I know buffer pools reside in virtual storage
but is this real storage or expanded storage.

Appreciate your inputs.

Ritu.

--- James Campbell <[login to unmask email]>
wrote:
> Perhaps this will clear up some confusion that seems
> to exist:
>
> Up to OS/390 V2.9, the memory addressing used
> allowed 2Gb "real" memory.
> Real memory is memory that can be used in normal
> machine instructions. An
> additional type of memory, called "expanded" memory
> was also available.
> However, the only machine instructions that can
> reference expanded memory
> are a set of instructions to copy 4kb pages to and
> from real memory.
>
> In the "old" days real and expanded memory were
> physically different and
> differently priced. At various times, different
> hardware manufacturers
> changed so that real and expanded memory were
> physically the same. This
> change tended to co-incide with the change to using
> CMOS technology for both
> the processor and memory. The changes were
> independent, but driven by the
> same cost/performance pressures.
>
> In an LPAR type central processor, there are
> facilities to configure the
> actual memory as real and expanded memory to each
> LPAR.
>
> V2.7 Initialisation and Tuning Guide 3.2.11 Pageable
> Frame Stealing: "...
> For systems with no expanded storage ...". And
> 1.4.5.5 Recommendations for
> Improving System Performance "... Configure as much
> storage as possible as
> central storage. Configure only enough expanded
> storage to support workloads
> that rely specifically on the availability of ES
> plus a reasonable
> additional amount to provide a margin of safety.
> ..." (Same quotes exist in
> the V2.10 version of this manual). Since this
> implies that there is nothing
> in OS/390 itself that mandates expanded memory, once
> one had carved up the
> available actual memory between LPARs, if the memory
> given to an LPAR was
> less than 2Gb, one would make it all real. Only if
> there was more than 2Gb
> would one allocate the rest to expanded.
>
> OS/390 V2.10 with zArchitecture allows 2**64 bytes
> (16 exabytes?) of real
> memory - but you have to give up using expanded
> memory. And why would you
> impose the overheads of using expanded when you
> could use the same memory as
> real?
>
> There has been no announcement on changing the 2Gb
> limit (actually 1.6Gb) on
> total bufferpool size - at least to DB2 V6.
> <WARNING the following
> statement is my personal speculation, not a
> statement based on some inside
> information> However, I can see the bits are coming
> into place to increase
> the limit to 2Gb per bufferpool </WARNING>. (For
> example, V6 allows
> individual bufferpools to be kept in dataspaces
> outside DBM1.) Beyond that
> would require a change to the 2Gb per address space
> limit and there has been
> no indication that this is even being planned except
> for USS purposes.
>
> /* standard disclaimer */
> James Campbell
> DBA
> Hansen Corporation, Doncaster
> +61 3 9843 8442
> [login to unmask email]
>
>
>
>
**********************************************************************
> This email and any files transmitted with it are
> confidential and
> intended solely for the use of the individual or
> entity to whom they
> are addressed. If you have received this email in
> error please notify
> the system manager.
>
> This footnote also confirms that this email message
> has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
>
**********************************************************************
>
>
> To change your subscription options or to cancel
> your subscription visit the DB2-L webpage at
> http://www.ryci.com/db2-l. The owners of the list
> can


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/



Karthik Ganesh

BUFFER POOL
(in response to ritu zee)
Hi list, joel & sanjeev,

Thanks for the responses;
Things seem to be getting clearer now.

Will get back to you guys once I get into these more.
Appreciate your inputs.


KArthik


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/



Piontkowski Michael ML

Re: Buffer pool question...
(in response to Karthik Ganesh)
Virtual storage is an operating system concept.
Virtual storage is abstract. OS/390, Unix, Linux,
Windows implement it.

Real storage is the physical memory; like the
RAM chips in your PC. Expanded storage is also
physical memory. In the "pre CMOS" days it was
physically separate from real memory. "Post CMOS"
expanded storage is the same physical memory as
real storage.

Real storage and expanded storage are the physical
implementations of virtual storage. All work is
done in real storage. The operating system maps
the address space's virtual storage location &
contents to a real storage location or an expanded
storage location.

Virtual storage allows you to have 20 500MB address
spaces that are supported by 500MB of real storage.
The idea is that typically you don't need to access
all the virtual storage in all the address spaces at
the same time. If you did, then the virtual storage
size equals the real storage size.

Check out the OS/390 Initialization & Tuning Guide
for more on virtual storage concepts.



Mike Piontkowski
TP&S Technical Maintenance
Voice: +1 302.886.4612
Fax: +1 302.886.4749


-----Original Message-----
From: ritu zee [mailto:[login to unmask email]
Sent: Thursday, December 21, 2000 17:54
To: [login to unmask email]
Subject: Re: [DB2-L] Buffer pool question...


James, Ed, Michael, Cliff,

Thanks for the reply; though my ordinary senses
responded most to James's 'down to earth' replay.
Things seem to be getting clearer now. But one last
question .....in this scheme of real and expanded
storage, where does 'virtual storage' come into
picture? I know buffer pools reside in virtual storage
but is this real storage or expanded storage.

Appreciate your inputs.

Ritu.

--- James Campbell <[login to unmask email]>
wrote:
> Perhaps this will clear up some confusion that seems
> to exist:
>
> Up to OS/390 V2.9, the memory addressing used
> allowed 2Gb "real" memory.
> Real memory is memory that can be used in normal
> machine instructions. An
> additional type of memory, called "expanded" memory
> was also available.
> However, the only machine instructions that can
> reference expanded memory
> are a set of instructions to copy 4kb pages to and
> from real memory.
>
> In the "old" days real and expanded memory were
> physically different and
> differently priced. At various times, different
> hardware manufacturers
> changed so that real and expanded memory were
> physically the same. This
> change tended to co-incide with the change to using
> CMOS technology for both
> the processor and memory. The changes were
> independent, but driven by the
> same cost/performance pressures.
>
> In an LPAR type central processor, there are
> facilities to configure the
> actual memory as real and expanded memory to each
> LPAR.
>
> V2.7 Initialisation and Tuning Guide 3.2.11 Pageable
> Frame Stealing: "...
> For systems with no expanded storage ...". And
> 1.4.5.5 Recommendations for
> Improving System Performance "... Configure as much
> storage as possible as
> central storage. Configure only enough expanded
> storage to support workloads
> that rely specifically on the availability of ES
> plus a reasonable
> additional amount to provide a margin of safety.
> ..." (Same quotes exist in
> the V2.10 version of this manual). Since this
> implies that there is nothing
> in OS/390 itself that mandates expanded memory, once
> one had carved up the
> available actual memory between LPARs, if the memory
> given to an LPAR was
> less than 2Gb, one would make it all real. Only if
> there was more than 2Gb
> would one allocate the rest to expanded.
>
> OS/390 V2.10 with zArchitecture allows 2**64 bytes
> (16 exabytes?) of real
> memory - but you have to give up using expanded
> memory. And why would you
> impose the overheads of using expanded when you
> could use the same memory as
> real?
>
> There has been no announcement on changing the 2Gb
> limit (actually 1.6Gb) on
> total bufferpool size - at least to DB2 V6.
> <WARNING the following
> statement is my personal speculation, not a
> statement based on some inside
> information> However, I can see the bits are coming
> into place to increase
> the limit to 2Gb per bufferpool </WARNING>. (For
> example, V6 allows
> individual bufferpools to be kept in dataspaces
> outside DBM1.) Beyond that
> would require a change to the 2Gb per address space
> limit and there has been
> no indication that this is even being planned except
> for USS purposes.
>
> /* standard disclaimer */
> James Campbell
> DBA
> Hansen Corporation, Doncaster
> +61 3 9843 8442
> [login to unmask email]
>
>
>
>
**********************************************************************
> This email and any files transmitted with it are
> confidential and
> intended solely for the use of the individual or
> entity to whom they
> are addressed. If you have received this email in
> error please notify
> the system manager.
>
> This footnote also confirms that this email message
> has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
>
**********************************************************************
>
>
> To change your subscription options or to cancel
> your subscription visit the DB2-L webpage at
> http://www.ryci.com/db2-l. The owners of the list
> can


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/








James Campbell

Re: Buffer pool question...
(in response to Piontkowski Michael ML)
Real memory is the physical place that memory is stored. It is addressed by
a 31-bit address. (I'll ignore zArchitecture and 64-bit addresses for this
reply. The discussion is the same, just a few details different).

In a virtual storage system (of which MVS, OS/390, z/OS is but one) the
address that is supplied in an instruction is not (necessarily, some are)
the real address that will be used. The address goes through a process
called 'translation' that determines the real address to be used. In MVS
(Multiple VS), each address space has its own set of translation tables to
determine the real address, so each one can have its own version of any
given address, and each one will be translated to a different real address.
The reason they are called 'address spaces' is that each one has its own set
of address - even though they look the same as the addresses in other
address spaces. The addresses within an address space are called 'virtual
addresses' and the set of addresses 'virtual memory'. (Some virtual
addresses will be translated using the same translation tables - so, in
fact, the addresses are common to many address spaces. This is called
'common' memory. In OS/390, a dataspace is an address space that doesn't
have this common memory - so the entire set of virtual addresses can be used
for whatever is required in this space.)

Now if you have hundreds of address spaces, each with many megabytes of
virtual memory, it isn't hard to see that the sum of virtual memory across
all address spaces exceeds the 2Gb of available real memory. That is, not
every virtual address can be backed by a real address. To handle this
situation, the operating system copies chunks of virtual memory out of real
memory to 'somewhere' else. When needed (ie an instruction actually uses an
address within a chunk) the chunk is copied back into real memory - and the
translation process is changed so that the virtual address is translated to
the new real address. In MVS, these chunks are 4kb in size and are called
pages, and the process of copying pages in and out of real memory is called
'paging' (there is another process called swaping where all the pages in an
address space are copied in and out). The 'somewhere' else can be expanded
memory or a disk.

So, bufferpools are in virtual memory - because they are in an address
space. However to be used the pages of virtual memory need to be in real
memory. One of the very worst things that you can do is to have too
many/too large bufferpools. If this happens, MVS can page the bufferpool
out of real memory. You can then have the situation where DB2 wants to
write a buffer out to a DB2 cluster - the buffer needs to be paged into real
memory so it can be written out. 2 I/Os when only one is needed. For this
reason one of the statistics you should keep on eye on is paging on the DBM1
address space.

/* standard disclaimer */
James Campbell
DBA
Hansen Corporation, Doncaster
+61 3 9843 8442
[login to unmask email]

-----Original Message-----
From: ritu zee [mailto:[login to unmask email]
Sent: Friday, December 22, 2000 9:54 AM
To: [login to unmask email]
Subject: Re: [DB2-L] Buffer pool question...


James, Ed, Michael, Cliff,

Thanks for the reply; though my ordinary senses
responded most to James's 'down to earth' replay.
Things seem to be getting clearer now. But one last
question .....in this scheme of real and expanded
storage, where does 'virtual storage' come into
picture? I know buffer pools reside in virtual storage
but is this real storage or expanded storage.

Appreciate your inputs.

Ritu.



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************