On 10 March 2011 18:11, john gilmore <[email protected]> wrote: > The OP wrote: > > | The change was not made by a CICS nor MVS Sys Prog, but from a DB2/DBA. > > Thus--unless of course the version of DB2 in use in his shop is improbably > old--this issue is moot. As others have already noted, the XTIOT was > developed chiefly for DB2; and its use by DB2 obviates TIOT-sizing problems > related to DB2 and any need for a DB2 DBA to make the TIOT proper larger. > > Others may of course go along for the ride, electing to use the XTIOT (as > DFSORT has already done). There is BSAM, QSAM and BPAM support for the use of > the XTIOT in z/OS 1.12; and I/O-intensive applications should use it. >
That's not 100% true. The DB2MSTR address space still uses TIOT (below 16M) for the active logs, BSDS and archive logs. The DB2DBM1 uses XTIOT for tablespace and indexspace linear datasets (which has removed some of the artificial restrictions). I had a SEV1 PMR where a 13-way DB2plex which had VOLCNT=20 for all those datasets. The subsystem blew the 64K TIOT and refused to offload it's active logs to archive (which means that it came to a grinding halt). The ultimate resolution was to delete/define everything for every member with a more sensible VOLCNT. When you run SQL replication the subsystem that runs CAPTURE will read all BSDS and ACTIVE logs from all members. Once DB2 allocates any BSDS or ACTIVE log (even when it belongs to another member) it doesn't deallocate it until the subsystem is closed. TIOT isn't as big a problem as SWA=BELOW (which is an ongoing menace). There's nothing left that requires SWA=BELOW that hasn't reached end-of-support, there's no reason not to move that above 16M into 31-bit storage. -- http://twitter.com/DougieLawson http://facebook.com/DougietheIMSman
