Bill, you wrote: The performance issue that I remember had to do with any software product that creates a large number of dynamic allocations. Each such allocation requires a new entry in the TIOT for the DDNAME. One example of such a product is DB2. Periodically SMF records may be written to record the cumulative EXCP counts for each DDNAME currently allocated. This is done in order to be able to account for I/O requests from a never-ending job, like DB2. The original implementation of SMF only recorded EXCP counts when the file was closed, which will never happen if the job never ends. A later version of SMF added interval accounting records so that most of the I/O load could be accounted for in the event that the file was never closed properly. If the number of DD statements is exceptionally huge, it was found to be taking a very long time with lots of CPU overhead to consolidate all these DD statements before writing the SMF records. Certain new options were made available to give the installation more control over this overhead. Barry Merrill can give all the sordid details.
The real cause of the performance problem was not moving the TIOT above the 31-bit addressing line but rather having an enormous number of DD statements allocated that are manipulated by SMF at the end of each SMF recording interval, regardless of where the TIOT resides. Moving it above the line merely makes it more likely that the problem will show up. **--> I found that DB2 will bypass CLOSE logic when shutting down. Last-used dates for the VSAM clusters are not being updated. DB2 will do only the minimum required to close all clusters in use. IBM indicated this is done for reasons of speeding up the shutdown process and I think it had to do a.o. with updating catalogs / VTOCs and with the issue you mentioned above. I'm sure others (Dougie Lawson comes to mind) might be able to say more about this even though it's rather off-topic for the assembler list. Cheers, Abe Kornelis. ==========
