I am told 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.
I also can't find anything on the impact of expand page. I'm suspecting there is some sort of performance impact since you have to have the "original page size" clause in the area definition which implies some sort of addition calculation or i/o to find at least the space management pages if nothing else.
Can you give me the details on the I/O after each of these expansion methods?
You are correct 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, we may need to read multiple pages into the buffer to get to that record. This of course depends on buffer size and if you are using cache 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 your buffers or if you are using cache. 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 you should be aware of 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.
The EXTEND SPACE and EXPAND PAGE were originally created as short term, emergency measures, until an Unload-Reload or REORG can be run.