It is understood that extend space acts like IDMS does when it exceeds a 70% full situation. I.e., it tries to fit the record into its calculated page then starts reading pages sequentially until it finds a page with enough space.
Is this also true of expand page? The suspicion is that there is some sort of performance impact since the "original page size" clause in the area definition is required which implies some sort of addition calculation or i/o to find at least the space management pages if nothing else.
What are the details on the I/O after each of these expansion methods?
Release: All supported releases.
It is true that the EXTEND SPACE will be used only for overflow storage. For an EXTEND SPACE, CALC records will still target to the original page range of the area, and VIA records will target to a page based on the CURRENT RECORD OF SET. If the record being stored does not fit on the target page, IDMS will check the Space Management Page for the next page with space available on it. This may be in the extended space file. If the record stored is a calc record, it will be connected to the calc chain of the original target page. So when later, trying to calc to that record, it may be necessary to read multiple pages into the buffer to get to that record. This of course depends on buffer size and if caching is in use or not.
After a while, this could present a performance issue as multiple I/Os will be needed to access these records. This performance issue also depends on the size of the buffers or if caching is in use. Large buffers, or cache, can improve the performance, as pages would not need to be re-read. The area must continue to be defined as being extended until an UNLOAD-RELOAD/REORG is performed where the new database defines the entire extended page range as the original page range. Failure to do this will result in 0326 errors when CALC retrieval is attempted.
The EXPAND PAGE will give more space on each page to fit additional records. This method produces less overflow than the EXTEND SPACE, as more records can be stored on their target page, but will not fix any overflow that has already occurred in the area. So, depending on the current area status, the EXPAND PAGE is a better choice for performance. The EXPAND PAGE would need to keep the ORIGINAL PAGE SIZE parameter, so that the space management pages could still be found. Since the space management pages are created during the FORMAT, the ORIGINAL PAGE SIZE clause needs to remain until the next Unload-Reload/REORG. One thing to note is how many records per page are stored in the area. The default is 255 records per page. If 255 records are stored on the page, and there is still space left on the page, it will be wasted.