090318 - zos v1r10 64-bit architecture enhancements

z/OS V1R10

64-bit Architecture

© 2009 IBM Corporation

z/OS v1R10 Enhancements

GSE z/OS Workgroup 18/03/2009

z/OS V1R10

64-bit Common Area Virtual Storage

§ Common area VSCR

– Common area virtual storage use has been a critical constraints issue

over the years and will continue to become a critical limiting factor in

application growth

§ 64-bit common virtual storage overview

– Release-to-Release VSCR savings goals

64-bit enhancements © 2009 IBM Corporation2

– Release-to-Release VSCR savings goals

– Things you can do to alleviate common area constraints

§ Alleviating common area VSCR

– What R10 provides to alleviate the problem

§ RMF 64-bit common support overview

– How to monitor 64-bit common virtual storage usage

z/OS V1R10

64-bit Common Area Virtual Storage

§ IBM recognizes common area virtual storage constraint relief as limiting application growth on System z and has formally committed to alleviate the problem

§ This will continue to require extensive efforts across the z brand from all major z/OS components and middleware involved:


involved:

– z/OS, DB2, Comm Server (TCPIP/VTAM), IMS, CICS, and MQ

§ 64-bit common support is introduced to provide the needed infrastructure for common area VSCR

§ Common area VSCR is an effort in every z/OS release

z/OS V1R10

Agenda

§ 64- Bit VSCR Overview§ 64-Bit Common Storage Overview§ Large Page support z10§ RMF Support


z/OS V1R10

Agenda



z/OS V1R10

31-Bit Address Space Memory Map

2 Gig = 80000000

Extended Nucleus

Extended SQA

Extended LPA

Extended CSA

Extended Private

• Global storage includes Nucleus, Extended Nucleus, SQA, ESQA, LPA, ELPA, CSA, and ECSA

• Global storage managed by VSM includes SQA, ESQA, CSA, and ECSA


PSA

System Region

Private

CSA

LPA

SQA

Nucleus

Extended Nucleus16 Meg = 1000000

6000

2000

0

ESQA, CSA, and ECSA

• Upper boundary of ECSA storage and lower boundary of CSA storage are always on aMegabyte boundary

• Sizes of SQA, ESQA, CSA, and ECSA storage are specified at IPL time via the IEASYSxx parmlibmember

z/OS V1R10

Common Area Below 2 GB

§ 24 bit (below 16M) common storage use continues to grow§ 31 bit (16M-2G) common storage use continues to grow at

about 5%- 20% each release§ Middleware/applications require larger private areas for

optimal operation

– Example: DB2’s DBM1 private area


– Example: DB2’s DBM1 private area

§ LPA areas growing as well (50M-100M)§ “Common Squeezing Private” is a well-known issue

z/OS V1R10

z/OS V1R9 Addressability

Data spaces

(High non-shared)

User Private Area

264

253

250

Region 1st table (R1T)

512 TB

231

x 29


Area reserved for Memory Sharing

(z/OS V1/R5)

(Low non-shared)

User Private Area

Below 2GB

242

241

231

232

0

Region 2nd table (R2T)

Region 3rd table (R3T)

2 TB

The bar

16 M - Line

0

z/OS V1R10

Necessary VSCR

§ Move data out of common, when possible§ Where to move data depends on attributes of the required

storage

– 64-bit common is the direction IBM lab has decided to focus on exploiting

§ Data traditionally in the common area needs to move elsewhere:


elsewhere:

– Private

– Common addressed dataspace (CADS), still a strategic direction

– 64-bit shared

– 64-bit common with z/OS V1R10

z/OS V1R10

Potential Candidates for Storage Relief

§ I/O Supervisor of z/OS§ DB2§ Communication storage manager used by IP Services§ IMS§ Potential future areas of interest:

– MQ, CICS, and WAS


– MQ, CICS, and WAS

§ ISV cooperative initiative

– IBM will assist ISVs in identifying common storage relief opportunities in

ISV code

§ Have profiled customers with VSCR issues to help us identify key VSCR areas

z/OS V1R10

Storage Use must be Analyzed

§ Why is the block in common storage?§ How is the block accessed?

– By one address space

– By a set of selected address spaces

– By every and any address space in the system


§ Does the block need fixed storage?

– Is block used for I/O?

§ Does the block need disabled reference storage?§ Do you need to split the block?

– Must block remain in 31-bit storage?

z/OS V1R10

What are Alternatives

§ Move to private

– Need to be in common storage? no, move to private

– Move to 31-bit private if small amount of data

– Move to 64-bit private if large amount of data

– Other address spaces can access the data

– Pages can be DREF, fixed in central storage


– Pages can be DREF, fixed in central storage

– Storage is task/address space owned

§ Move to 64-bit shared memory§ CADS dataspace§ 64-bit common - z/OS V1R10 solution

z/OS V1R10

DREF Storage

§ All virtual pages in z/OS are either:

– Fixed in central storage, pageable, or DREF

– DREF meant fixed in expanded storage

– DREF pages are not backed by central storage frames until they are referenced

– Note: Expanded storage no longer exists

– To keep compatibility, DREF pages are now fixed in central storage


– To keep compatibility, DREF pages are now fixed in central storage

– IBM now recommends that vendors use pageable pages instead of

DREF storage, if possible or consider using the PGSER macro to fix

pages in central storage

z/OS V1R10

Summary of AlternativesStorage Attributes

Private 64-Bit Shared(z/OS V1R5)

64-bit Common (z/OS V1R10)

CADS

Accessed by one space

Ideal Not best solution Not best solution Not best solution

Accessed by a set of spaces

Possible Ideal Possible but- potential foroverlays

Possible but- need multipledataspaces if

data > 2GB

- MAXCAD limit


- MAXCAD limit

Accessed by every space

Possible butcumbersome

Possible butcumbersome

Yes Yes but- see above

DREF Storage supported

Yes for 31-Bit No for 64-Bit

No Yes Yes

Fixed storage supported

Yes No Yes No (for externalcallers)Yes (for internalcomponents)

Storage Ownership

Task/AddressSpace

SystemStorage must beexplicitly freed

SystemStorage must beexplicitly freed

Storage managedby a applicationstorage manager

z/OS V1R10

Virtual Storage Constraint Relief (VSCR)

Without VSCR, zOS images will be capped, limiting customer growth and resulting in outages


customer growth and resulting in outages

z/OS V1R10

Agenda



z/OS V1R10

64-bit Common Storage Area

§ The 64-bit common area size can be specified via the HVCOMMON keyword in IEASYSxx parmlib member:

– HVCOMMON ={xxG} {xxT}

– HVCOMMON value can also been specified by responding to message IEA101A

– Value Range: 2 Gigabytes (2G) to 1 Terabyte (which is 1024 gigabytes) and


– Value Range: 2 Gigabytes (2G) to 1 Terabyte (which is 1024 gigabytes) and resides on a 2 GB boundary

– Default Value: 64 Gigabytes (64G)

§ When reserving the actual amount of common storage consumed is the amount specified with the HVCOMMON parameter plus 2 GB for operating system purposes

z/OS V1R10

z/OS V1R10 64-bit Common

§ Allows sharing above the bar across every address space§ Any address space can access storage without explicitly

having to request access§ Only allows authorized code to obtain storage and storage

can only be assigned system keys 0-7 (to avoid system integrity issues by unauthorized code)


integrity issues by unauthorized code)§ Storage can be DREF or Fixed (as well as Pageable)§ An owner is associated with the storage for diagnostic

purposes§ Storage needs to be explicitly freed

z/OS V1R10

z/OS V1R10 Addressability with HVCOMMON in IEASYSxx Member

Data spaces

(High non-shared)

User Private Area

264

253

250

Region 1st table (R1T)

512 TB

231

x 29


Area reserved for Memory Sharing

(z/OS V1/R5)

User Private Area

Below 2GB

242

241

231

232

0

Region 2nd table (R2T)

Region 3rd table (R3T)

2 TB

The bar

16 M - Line

0

2GBSegment table

Page table

64-bit Common2 TB–66GB

HVCOMMONDefault value: 64G

z/OS V1R10

§ HVCOMMON parameter plus 2 GB for operating system purposes

– Default if not specified in IEASYSxx is 64 GB

D VIRTSTOR,HVCOMMON

IAR019I 16.47.33 DISPLAY VIRTSTOR 470

Operator Commands


IAR019I 16.47.33 DISPLAY VIRTSTOR 470

SOURCE = DEFAULT

TOTAL 64-BIT COMMON = 66G

64-BIT COMMON RANGE = 1982G-2048G

64-BIT COMMON ALLOCATED = 4M

Abbreviate: D VS,HVCOMMON

z/OS V1R10

64-bit Common Storage Monitoring

§ SRM monitors how much of the specified 64-bit Common Storage (HVCOMMON=) is currently in use and alerts the operator when the usage exceeds certain thresholds

§ The following messages get issued by SRM,

– When 80% or 95% of the 64-bit common storage is in use:


– IRA130E HIGH COMMON SHORTAGE

– IRA131E CRITICAL HIGH COMMON SHORTAGE

– IRA132I HIGH COMMON SHORTAGE RELIEVED

z/OS V1R10

Storage Map with z/OS V1R10

Data spaces

264

263

260

242

R2T

R1TUser Private area

Shared area Shared area


2

241

224

0

64-bit COMMON

232

231

16M line

The bar

R3T

User Private area User Private area User Private area

z/OS V1R10

64-bit Common Compared with Other Areas…Like Common Below 2G:

§Are visible at the same address in every address space

§Every address space has access to the memory object once it is created

§Storage Tracker capabilities are provided for diagnostic purposes§Can be pageable, fixed, or DREF§Must be explicitly freed§Same RAS level

…Like Common Data Spaces:

§Must be explicitly allocated§Can be pageable, fixed, or DREF

§At system-scope, number of 1M pages or CADS cannot be changed within an IPL.

…Like 64-Bit Shared:

§Are allocated in 1MB multiples on a 1MB boundary

§Memory objects managed by sys functions

§Can be grouped as a set of related objects by specifying a memory object token§Must be explicitly freed


…Unlike Common Below 2G:

§Memory objects managed by sys functions

§Can not be implicitly fixed at allocation§No subpools

…Unlike Common Data Spaces:

§Virtual storage is addressable by all address spaces at allocation time

§No need to explicitly ask for access to the virtual storage§Can be grouped as a set of related objects by specifying a memory object token

§Must be explicitly freed§No capability-based addressing§Lower RAS level

…Unlike 64-Bit Shared:

§Virtual storage is addressable by all address spaces at allocation time

§No need to explicitly ask for access to the virtual storage§Can be explicitly fixed§Can be referenced while disabled (DREF)

§Lower RAS level

z/OS V1R10

Using 64-bit common storage

§ IARV64 macro

– 1 MB memory objects on 1MB boundary

§ IARST64 macro

– like GETMAIN and STORAGE OBTAIN

§ IARCP64


– manage pools of storage cells

z/OS V1R10

IARV64 REQUEST=GETCOMMON syntax

IARV64 REQUEST=GETCOMMON

SEGMENTS=xsegments

ORIGIN=xoriginKEY=xkey|CALLERKEYMOTKNSOURCE=USER

MOTKN=xmotkn|NO_MOTKNMOTKNSOURCE=SYSTEM


MOTKNSOURCE=SYSTEM

OUTMOTKN=xoutmotknPAGEFRAMESIZE=4K|1MEG|MAX

TYPE=PAGEABLE|DREF

z/OS V1R10

IARV64 REQUEST=PAGEFIX syntax

IARV64 REQUEST=PAGEFIX

RANGLIST=xranglist

NUMRANGE=xnumrage|1LONG=YES|NO

RANGLIST=ranglistRange List Format


Virtual Address Number of pages




………… 1 to 16 pairs

0 8 15

z/OS V1R10

IARV64 REQUEST=LIST syntax

IARV64 REQUEST=LIST

V64LISTPTR=xv64listptrxusertkn

V64LISTLENGTH=xv64listlengthV64SELECT=YESDUMP=LIKERGN

ORDER=ASCENDING|DUMPPRIORITY


z/OS V1R10

Agenda



z/OS V1R10

64-bit Common customization

Address spaces

16 Meg-line “the Bar” 64-bit Common


Real Storage

Large Pages

2TBHVCOMMON

LFAREA

z/OS V1R10

Large Pages

§ Memory architecture to support large (1 MB) pages

– When large pages are used in addition to the existing 4 KB page size,

they are expected to reduce memory management overhead for

exploiting applications

§ With the z10 models, page frames can be allocated with a 4K size


4K size

– The z10 additionally supports a larger page frame size of 1 MB

– It is expected that long running, memory access intensive applications

will benefit from large page frames

– Large pages are treated as fixed pages and are never paged out

z/OS V1R10

Translation Look-aside Buffers (TLB)

§ DAT is hardware contained in each PU in charge of translating virtual address into real address

– During such translation, DAT may access up to 5 CS tables (third region,

second region, first region, segment and page) managed by z/OS

§ To avoid DAT accesses to CS, TLBs were introduced

– TLBs are a fast array memory within each PU


– TLBs are a fast array memory within each PU

– After translating using CS tables, DAT keeps the relation page/frame in a

TLB entry and the next time before going through a CS table translation,

DAT inspects TLBs looking for the referred page

– In case of a hit the translation process is much faster

z/OS V1R10

TLB Performance and 1M Address Pages

§ z10 has 512 TLB entries per PU§ Due to the explosion of virtual addresses because of 64-bit

capability, 512 entries is not enough to generate good performance (a high TLB hit ratio)

§ The introduction of 1M addresses pages decreases the number of pages in virtual storage (fewer larger pages


number of pages in virtual storage (fewer larger pages instead of many small pages), thus improving DAT performance

§ To avoid the reformatting of page data sets and high data rate during ASM paging operations those pages must be fixed in central storage (CS)

z/OS V1R10

Large Page Support

§ Memory reserved for large page support can be defined with a new parameter in the IEASYSxx parmlib member:

– LFAREA=xx% | xxxxxxM | xxxxxxG

– xx% Indicates that the amount of real storage to be used for large pages

is specified as a percentage of all online real storage available at IPL

time. The maximum amount of real storage that can be used to back


time. The maximum amount of real storage that can be used to back

large pages is 80% of the online storage available at IPL minus 2 GB

z/OS V1R10

Large Page Support

§ xxxxxxG - Indicates the amount of online real storage available at IPL time in gigabytes that is to be used for large pages. The maximum amount of real storage that can be used to back large pages is 80% of the online storage available at IPL minus 2 GB. If the amount specified exceeds this value, the specification is rejected and the system issues


this value, the specification is rejected and the system issues a prompt for a new value to be specified on the LFAREA parameter.

– For calculations in gigabytes, x = online real storage at IPL in GB.

MAX_LFAREA = (x - 2G) * .8

z/OS V1R10

Large Page Support

§ xxxxxxM - Indicates the amount of online real storage at IPL time in megabytes that is to be used to back large pages. The maximum amount of real storage that can be used to back large pages is 80% of the online storage available at IPL minus 2 GB. If the amount specified exceeds this value, the specification is rejected and the system issues a prompt for a


specification is rejected and the system issues a prompt for a new value to be specified on the LFAREA parameter.

– For calculations in megabytes, x = online real storage at IPL in MB.

MAX_LFAREA = (x - 2048M) * .8

z/OS V1R10

Large Page Potential Exploiters

§ Future release of DB2 to support for buffer pools§ Java 6.0 SR1 for z/OS planned to support§ With z/OS V1R10, following applies to application use of

large pages:

– Must run on a z10


– Must issue the IARV64 macro

– Must not be dependent upon LE environment

– Must explicitly run in 64-bit mode

– Can take benefit of this large page support

z/OS V1R10

z10 Exploitation

New System z10 functions you

can exploit

z/OS

V1R8

z/OS V1R9 z/OS

V1R10

Hiperdispatch YES YES YES

>128 GB Support YES YES YES

>54 CPs for a single LPAR YES YES


>54 CPs for a single LPAR YES YES

Capacity Provisioning YES YES

Large Page (1 MB) Support YES YES

HiperSockets Multiple Write

Facility

YES YES

zIIP-assisted z/OS Global Mirror (XRC)

YES YES

ARCH(8), TUNE(8) YES*** YES YES

z/OS V1R10

Agenda



z/OS V1R10

RMF Support for 64-bit Common

§ RMF provides new overview conditions for the Postprocessor based on SMF record 71

§ RMF provides support for 64-bit common memory in the RMF Postprocessor and Monitor III on a per address space and system basis:

– By collecting additional data in SMF record 71


– By collecting additional data in SMF record 71

– By collecting additional data in SMF record 78 subtype 2

– By extending the RMF Postprocessor Paging Activity Report

– By presenting system-wide and address space related information in the

new RMF Monitor III Storage Memory Objects report

z/OS V1R10

SMF Record 71§ The following fields are added to the Paging Activity Paging Data

Section of SMF Record 71

Offsets Name Len Format Description

1164 x48C SMF71COM 8 float Min.number of 64-bit common memory objects allocated in the system

1172 x494 SMF71COX 8 float Max. number of 64-bit common memory objects allocated in the system

1180 x49C SMF71COA 8 float Average number 64-bit common memory objects allocated in the system

1188 x4A4 SMF71CRM 8 float Minimum number 64-bit common memory frames backed in real storage


1188 x4A4 SMF71CRM 8 float Minimum number 64-bit common memory frames backed in real storage

1196 x4AC SMF71CRX 8 float Maximum number 64-bit common memory frames backed in real storage

1204 x4B4 SMF71CRA 8 float Average number 64-bit common memory frames backed in real storage

1212 x4BC SMF71CFM 8 float Minimum number of 64-bit common memory frames fixed in real storage

1220 x4C4 SMF71CFX 8 float Maximum number of 64-bit common memory frames fixed in real storage

1228 x4CC SMF71CFA 8 float Average number of 64-bit common memory frames fixed in real storage

1236 x4D4 SMF71CSM 8 float Minimum number of 64-bit common memory auxiliary storage slots

1244 x4DC SMF71CSM 8 float Maximum number of 64-bit common memory auxiliary storage slots

1252 x4E4 SMF71CSA 8 float Average number of 64-bit common memory auxiliary storage slots

z/OS V1R10

SMF Record 71 Continued§ The following fields are added to the Paging Activity Paging Data

Section of SMF Record 71


1260 x4EC SMF71COM 8 float Min number of shared memory objects allocated in the system

1268 x504 SMF71COX 8 float Max number of shared memory objects allocated in the system

1276 x50C SMF71COA 8 float Average number shared memory objects allocated in the system

1284 x514 SMF71CRM 8 float Minimum number of high virtual shared memory frames backed in real


1284 x514 SMF71CRM 8 float Minimum number of high virtual shared memory frames backed in real storage

1292 x51C SMF71CRX 8 float Maximum number of high virtual shared memory frames backed in real storage

1300 x524 SMF71CRA 8 float Average number of high virtual shared memory frames backed in real storage

z/OS V1R10

New overview/exception conditions are available in SMF type 71

Condition Name Source

Average number of 64-bit common memory objects allocated in the system CMOA SMF71COA

Average number of 64-bit common memory frames backed in real storage CFRA SMF71CRA

Average number of 64-bit common memory frames fixed in real storage CFFRA SMF71CFA

Average number of 64-bit common memory auxiliary storage slots CAUXSA SMF71CAA


Average number of 64-bit common memory auxiliary storage slots CAUXSA SMF71CAA

Average number of shared memory objects allocated in the system SMOA SMF71SOA

Average number of high virtual shared memory frames backed in real storage SFRA SMF71SRA

z/OS V1R10

SMF Record Type 78 Subtype 2


440 x1B8 R782SHBY 48 mixed1 Number of shared bytes allocated in storage above the 2-GB-line.

488 x1E8 R782COBY 48 mixed1 Number of 64-bit common bytes allocated in storage above the 2-GB-line.

536 x218 R782TOMO 40 mixed2 Total number of 64-bit private memory objects allocated.

576 x240 R782SHMO 40 mixed2 Number of shared memory objects.


576 x240 R782SHMO 40 mixed2 Number of shared memory objects.

616 x268 R782COMO 40 mixed2 Number of 64-bit common memory objects.

656 x290 R782LGMO 40 mixed2 Number of large memory objects

696 x2B8 R782TOFR 40 mixed2 Number of 1 MB frames.

736 x2E0 R782MEML 8 binary Address space memory limit in MB

z/OS V1R10

SMF Record Type 78 Subtype 2


0 x0 VSDGMIN 8 floating Minimum value

8 x8 VSDGNTME 4 binary Time stamp for minimum value.

12 xC 4 reserved

16 x10 VSDGMAX 8 floating Maximum value

24 x18 VSDGXTME 4 binary Time stamp for maximum value.

28 x1C 4 reserved

Table1


28 x1C 4 reserved

32 x20 VSDGTOTL 8 floating Total all samples (used to calculate the average).

40 x28 VSDGHWM 8 floating High watermark


0 x0 VSDGMIN 8 floating Minimum number of memory objects / frames

8 x8 VSDGNTME 4 binary Time stamp for minimum value.

12 xC 4 reserved

16 x10 VSDGMAX 8 floating Maximum number of memory objects / frames

24 x18 VSDGXTME 4 binary Time stamp for maximum value.

28 x1C 4 reserved

32 x20 VSDGTOTL 8 floating Total all samples (used to calculate the average).

Table2

z/OS V1R10

Postprocessor Paging Activity Report

FRAME AND SLOT COUNTS----------------------------------------------------------------------------------------------------

CENTRAL STORAGE LOCAL PAGE DATA SET SLOT COUNTS---------------------------- ------------------------------------------------

(91 SAMPLES) MIN MAX AVG MIN MAX AVGAVAILABLE 2068166 2074202 2071567 AVAILABLE SLOTS 1,951,191 1,951,191 1,951,191SQA 19,220 19,295 19,263 VIO SLOTS 0 0 0LPA 4,751 4,759 4,757CSA 16,588 16,609 16,601 NON-VIO SLOTS 1 1 1LSQA 49,851 50,763 50,165REGIONS+SWA 454,309 459,554 456,700 BAD SLOTS 0 0 0TOTAL FRAMES 2621440 2621440 2621440 TOTAL SLOTS 1,951,192 1,951,192 1,951,192

FIXED FRAMES SHARED FRAMES AND SLOTS---------------------------- ------------------------------------------------


---------------------------- ------------------------------------------------NUCLEUS 2,385 2,385 2,385 CENTRAL STORAGE 9,119 9,185 9,136SQA 15,622 15,697 15,665 LPA 67 67 67 FIXED TOTAL 38 39 38CSA 8,583 8,599 8,594 FIXED BELOW 16 M 0 0 0LSQA 14,466 14,569 14,516 AUXILIARY SLOTS 0 0 0REGIONS+SWA 36,129 36,693 36,538 BELOW 16 MEG 97 110 102 TOTAL 9,119 9,185 9,136BETWEEN 16M-2G 24,058 24,630 24,467 MEMORY OBJECTS AND FRAMESTOTAL FRAMES 77,388 77,928 77,767 ------------------------------------------------

OBJECTS COMMON 35 35 35SHARED 10 10 10LARGE 5 5 5

FRAMES COMMON 2000 4000 3000COMMON FIXED 1000 2000 1500SHARED 1000 2000 15001 MB 10 20 15

z/OS V1R10

New Monitor III Storage Memory Objects report

RMF V1R10 Storage Memory Objects Line 1 of 10

Command ===> Scroll ===> CSR

Samples: 60 System: TRX1 Date: 11/28/08 Time: 10.41.00 Range: 60 Sec

------------------------------- System Summary --------------------------------

-- Memory Objects -- --------- Frames ---------- --- Area Used % ----

Common Shared Large Common Fixed Shared 1 MB Common Shared 1 MB

3 1 15 512 0 98304 65 0.0 0.0 32.5

-------------------------------------------------------------------------------

Service ---- Memory Objects --- Frames ----- Bytes -----

Jobname C Class ASID Total Comm Shr Large 1 MB Total Comm Shr


Jobname C Class ASID Total Comm Shr Large 1 MB Total Comm Shr

SMSPDSE S SYSTEM 0008 17 0 0 0 0 81.0M 0 0

COMM644K B DISCRETN 0065 9 9 0 0 0 1.00G 1.00G 0

COMM641M B DISCRETN 0064 7 7 0 0 0 150M 150M 0

TRACE S SYSTEM 0004 5 0 0 5 5 5.00M 0 0

GRS S SYSTEM 0007 4 0 0 0 0 132G 0 0

STOR641M B DISCRETN 0066 3 2 0 1 30 330M 300M 0

SMSVSAM S SYSTEM 0009 2 0 0 0 0 6.00M 0 0

THR64EDT B VEL60 0068 2 0 1 0 0 8.10G 0 4.10G

OMVS S SYSTEM 0015 1 0 0 0 0 400M 0 0

STOR644K B DISCRETN 0067 1 0 0 0 0 50.0M 0 0

z/OS V1R10

Postprocessor VSTOR Report

V I R T U A L S T O R A G E A C T I V I T Y PAGE 6

z/OS V1R10 SYSTEM ID TRX1 DATE 11/28/2008 INTERVAL 00.59.998 RPT VERSION V1R10 RMF TIME 10.41.00 CYCLE 0.050 SECONDS

PRIVATE AREA DETAIL JOB NAME - COMM644K MEMORY LIMIT - 20000M NUMBER OF BYTES OF ALLOCATED BLOCKS BY AREA (BELOW 16 MEG) SUBPOOL (AREA) MIN MAX AVG

230 88K 10.41.23 88K 10.41.23 88K 236 (SWA) 84K 10.41.23 84K 10.41.23 84K 237 (SWA) 108K 10.41.23 108K 10.41.23 108K 255 (LSQA) 28K 10.41.23 28K 10.41.23 28K

USER REGION 0 4K 10.41.23 4K 10.41.23 4K


0 4K 10.41.23 4K 10.41.23 4K 121 4K 10.41.23 4K 10.41.23 4K 252 (REENTRANT) 36K 10.41.23 36K 10.41.23 36K

HIGH VIRTUAL MEMORY USAGE (ABOVE 2GB) BYTES MIN MAX AVG PEAK

PRIVATE 0 10.41.23 0 0 0 SHARED 0 10.41.23 0 0 0 COMMON 1.016G 10.41.23 1.016G 10.41.23 1.016G 1.016G

MEMORY OBJECTS PRIVATE 0 10.41.23 0 0 SHARED 0 10.41.23 0 0 COMMON 9 10.41.23 9 10.41.23 9 LARGE 0 10.41.23 0 0

FRAMES (1MB) TOTAL 0 10.41.23 0 0

z/OS V1R10

Thank you!

SG24-7605-00 z/OS Version 1 Release 10 Implementation


090318 - zos v1r10 64-bit architecture enhancements

Documents

common area constraints

common support overview

g common storage use

common squeezing private

required storage

vscr overview

ecsa global storage

lower boundary of csa