Reduce shutdown time - allow for reduction of Db2 footprint before STOP DB2

As the Db2 footprint on our mainframe systems has increased (larger bufferpools, larger GBPs, more open datasets), one of the challenges we have faced is that Db2 takes longer to shut down. Our shop has recently focused on reducing down-time and increasing availability by shortening system shutdown times, but we've found that Db2 shutdown times have increased due to:

• More pages needing to be externalized from bufferpools

• More pages needing to be cast out from GBPs

• More datasets needing to be physically closed (often with multiple extents due to -1/-1) and records being written to SYSLGRNX

What we would be looking for is a way to "pre-quiesce" a Db2 subsystem by externalizing all dirty pages and closing all not-in-use datasets, prior to a planned shutdown, without disrupting user work.

My suggestion is an operator-command, something like "-QUIESCE DB2", that would allow operators to tell Db2, essentially, "get skinny" prior to a planned shutdown, so that the actual shutdown takes significantly less time.

Db2 already employs asynchronous processes to externalize dirty pages and to close datasets in response to certain thresholds being set...what I'm suggesting is a method to execute these processes on-command.

Examples:

-QUIESCE DB2 BPOOL(bpid) or (*)

Would initiate an asychronous write task to write all "dirty" pages in the bufferpool to disk, as if DWQT or similar threshold was hit.

-QUIESCE DB2 GBPOOL(gbp-id) or (*)

Would initiate an asynchronous castout process to write all "dirty" GBP pages to disk, as if GBPOOLT or similar threshold was hit.

-QUIESCE DB2 DATASETS

Would initiate an asynchronous dataset close task, which would identify all pagesets without a current thread using/holding a claim, and initiate physical dataset close for them. New dataset opens would continue to be "allowed" under the DSMAX threshold, to insure service is not disrupted to applications.

(we have tried to replicate this by setting DSMAX to a low value dynamically and then back to its startup value, but this runs the risk of causing 00C20113 errors during that small interval, and is "sloppy" - this instead would allow for async close WITHOUT affecting overall DSMAX)

This command would be issued by operations/automated ops prior to a planned Db2 shutdown, and the purpose would be to allow Db2 to "prepare" for shutdown by reducing overall footprint and reducing work needing to be done during the actual STOP DB2 processing.

Customers would need to be cautioned to use this only during "low-volume" periods to avoid any delays caused by the need to re-open a large number of closed datasets, for example...but the asynchronous processes should NOT actually disrupt any ongoing work, even if performance could be affected.

As Db2 expands its use of "big memory" and the number of pagesets a single subsystem can manage, this kind of operational intervention will become more useful.