When a page reserve for an area is near 30% or more of page size, jobs that store records in the area encounter excessive I/O and runtimes
search cancel

When a page reserve for an area is near 30% or more of page size, jobs that store records in the area encounter excessive I/O and runtimes

book

Article ID: 56535

calendar_today

Updated On:

Products

IDMS IDMS - Database IDMS - ADS

Issue/Introduction

Page reserve should never be 30% or more of page size. 

Environment

IDMS - All Supported Relases

Resolution

Even if set to slightly less than 30% it can cause the problem of greatly increased I/O when storing records if in fact pages in the area cannot actually get to be over 70% full. 

You must choose a Page Size and Page Reserve amount such that every page in the area CAN become over 70% full. You must take into consideration the lengths of records that will target to pages in the area. 

This is also the reason that we recommend no record length be more 30% of (pagesize - 32). 

Most of this is explained in the Space Management section of Administrating IDMS Database. 

In an AREA there are one or more Space Management Pages (SMPs). 

Each SMP has a two-byte Space Management Entry for each page it controls. 

That two byte-entry contains (Pagesize - 32) until the page in question encounters a STORE Failure AND is over 70% full. At this time the Space Management Entry is changed from (Pagesize - 32) to the actual Space available on the page. 

When a record being STOREd cannot fit on its target page we read the corresponding SMP and look for the Next page in the area that indicates it has sufficient space for the record being stored. 

So consider an area definition that violates this recommendation about record lengths or Page Reserve such that pages get to a point where we cannot fit any more record occurrences on the page, BUT the page is NOT over 70% full

For such pages the corresponding Space Management Entry on an SMP will never reflect the actual Space available on that page. It will continue to contain (pagesize - 32) and appear as if there is space available for storing new records. 

So consider this scenario:

We find that a new record to be STOREd will not fit on its target page. 

We read the SMP and see that the next page in the area has enough space available to fit the new record . 

We read that page, BUT find that it actually cannot fit the record

We go back to the SMP and see that the subsequent page can fit the record... 

BUT that won't fit it either... 

This can go on and on if you get to a point where many pages cannot fit the new record but are not over 70% full.

 

ALWAYS be certain all pages in an area CAN get to be over 70% full to avoid the "SMP I/O thrashing" described herein.