I have been asked on numerous occasions where in the wide, wide world of Db2 does it store the sizes and settings of buffer pools and group buffer pools?
Survivability
Naturally, these things must survive a Db2 stop/start and also an IPL – so where do they live?
Buried in the IBM Db2 documentation is one place where it just mentions that buffer pool data is stored in the BSDS. In fact, under ALTER BUFFERPOOL, is this text:
Altering buffer pools
Last Updated: 2024-05-14
Db2 stores buffer pool attributes in the Db2 bootstrap data set (BSDS). You can change buffer pool attributes.
IBM Db2 ALTER Command
Just the Facts, Ma’am
OK, as you are all aware, a DSNJU004 print log map shows this BSDS data:
- The data set name (DSN) of the BSDS.
- The system date and time (SYSTEM TIMESTAMP), and the date and time that the BSDS was last changed by the change log inventory utility (UTILITY TIMESTAMP).
- The ICF catalog name that is associated with the BSDS.
- The highest-written RBA. The value is updated each time the log buffers are physically written to disk.
- The highest RBA that was offloaded.
- Log RBA ranges (STARTRBA and ENDRBA), and data set information for active and archive log data sets. The last active log data set that is listed in the output is the current active log.
- Information about each active log data set.
- Information about each archive log data set.
- Conditional restart control records.
- The contents of the checkpoint description queue.
- Archive log command history.
- The distributed data facility (DDF) communication record. This record contains the location name as defined by Db2, any alias names for the location name, and the LU name as defined by VTAM. Db2 uses this information to establish the distributed database environment.
- The tokens for all BACKUP SYSTEM utility records.
- The ENFM START RBA/LRSN field contains one of the following values:
- In a non-data sharing environment, the RBA when the most recent enabling-new-function mode job started on the subsystem
- In a data sharing environment, the LRSN when the most recent enabling-new-function mode job started on a member
- Information about members of a data sharing group, including deactivated members and destroyed members whose slots were reclaimed.
You may have noticed that in this list the BPs and GBPs are noticeably(!) absent!
Pulled up with Your Own Bootstraps!
Now the BSDS is arguably the most important dataset for Db2 as it literally “pulls itself up with its own bootstraps” – hence the name. It is a simple VSAM dataset with a four-byte key that you can browse while Db2 is up and running or, if you are worried, just REPRO it to a flat file like this:
//*
//* REPRO VSAM OVER
//*
//REPRO EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INDD DD DISP=SHR,DSN=my.db2.BSDS01
//OUTDD DD DISP=(,CATLG,DELETE),DSN=my.flat.file,
// SPACE=(CYL,(5,5),RLSE),
// DCB=(LRECL=8192,RECFM=VB)
//SYSIN DD *
REPRO INFILE(INDD) OUTFILE(OUTDD)
/*
Hidden Secrets
IBM have, to my knowledge, never documented the internal structure of the BSDS – and why should they? It is really just for Db2 internal use, but I love to figure things out. So, I REPRO’d a non-data sharing and a data sharing BSDS and ran the DSNJU004 and just looked for stuff in the BSDS that is not output by the utility.
Differences Aplenty!
What you notice, is that there are quite a few bits of data not externalized, for whatever reason. The aforementioned buffer pools and group buffer pools, of course, and then the full list of DDF ALIASes, and also what I guess are a whole bunch of “recent log checkpoints” but I am not 100% sure and just ignored them!
ISPF F is Your Friend
You can page on down through or you can just do a “F WPAR” as in all my systems this was there and so I guess it is an eyecatcher of sorts! The VSAM key is x’0A000001’ and the start looks like:
Buffer Pool ID
Remember that internally, Db2 uses buffer pool ids to map the buffer pools. These numbers are *not* consecutive or in order for historical and, perhaps, even future growth reasons. Here’s a handy little cross reference table:
| Buffer pool ID | Buffer pool size | Buffer pool name |
| 0 – 49 | 4K | BP0 – BP49 |
| 80 – 89 | 32K | BP32K – BP32K9 |
| 100 – 109 | 8K | BP8K0 – BP8K9 |
| 120 – 129 | 16K | BP16K0 – BP16K9 |
It is HEX Time!
Then at position 60, the data blocks begin with 32 bytes for each Bufferpool. Here is Buffer pool id 0 (BP0):
You can see that we have x’00004E20’ pages – 20,000 and also x’000007D0’ – 2000 simulated pages. The rest of the data is thresholds etc. This then repeats for all buffers out to the right.
And Now in Human-Readable Form
Here’s a -DISPLAY BUFFERPOOL(BP0) for comparison:
DSNB401I -DD10 BUFFERPOOL NAME BP0, BUFFERPOOL ID 0, USE COUNT 751
DSNB402I -DD10 BUFFER POOL SIZE = 20000 BUFFERS AUTOSIZE = NO
VPSIZE MINIMUM = 0 VPSIZE MAXIMUM = 0
ALLOCATED = 20000 TO BE DELETED = 0
IN-USE/UPDATED = 355 OVERFLOW ALLOC = 0
DSNB431I -DD10 SIMULATED BUFFER POOL SIZE = 2000 BUFFERS -
ALLOCATED = 2000
IN-USE = 1988 HIGH IN-USE = 2000
SEQ-IN-USE = 1495 HIGH SEQ-IN-USE = 1734
DSNB406I -DD10 PGFIX ATTRIBUTE -
CURRENT = NO
PENDING = NO
PAGE STEALING METHOD -
CURRENT = LRU
PENDING = LRU
DSNB404I -DD10 THRESHOLDS -
VP SEQUENTIAL = 80 SP SEQUENTIAL = 80
DEFERRED WRITE = 30 VERTICAL DEFERRED WRT = 5, 0
PARALLEL SEQUENTIAL =50 ASSISTING PARALLEL SEQT= 0
DSNB546I -DD10 PREFERRED FRAME SIZE 4K
20000 BUFFERS USING 4K FRAME SIZE ALLOCATED
DSN9022I -DD10 DSNB1CMD '-DISPLAY BUFFERPOOL' NORMAL COMPLETION
Data-Sharing?
If you have data-sharing then you get some bonus lines in the BSDS:
As you can see, it lists out one line per GBP. Note how the VSAM Key is now x’0A0001nn’ where nn is the buffer pool id in hexadecimal. Remember: 0 – 49, 80 – 89, 100 – 109 and 120 – 129.
Now, Again, in Human-Readable Form
Here’s the -DISPLAY GROUPBUFFERPOOL output for comparison:
DSNB750I -SD10 DISPLAY FOR GROUP BUFFER POOL GBP0 FOLLOWS
DSNB755I -SD10 DB2 GROUP BUFFER POOL STATUS
CONNECTED = YES
CURRENT DIRECTORY TO DATA RATIO = 10
PENDING DIRECTORY TO DATA RATIO = 10
CURRENT GBPCACHE ATTRIBUTE = YES
PENDING GBPCACHE ATTRIBUTE = YES
DSNB756I -SD10 CLASS CASTOUT THRESHOLD = 5, 0
GROUP BUFFER POOL CASTOUT THRESHOLD = 30%
GROUP BUFFER POOL CHECKPOINT INTERVAL = 4 MINUTES
RECOVERY STATUS = NORMAL
AUTOMATIC RECOVERY = Y
DSNB757I -SD10 MVS CFRM POLICY STATUS FOR GSD10C11_GBP0 = NORMAL
MAX SIZE INDICATED IN POLICY = 24576 KB
DUPLEX INDICATOR IN POLICY = DISABLED
CURRENT DUPLEXING MODE = SIMPLEX
ALLOCATED = YES
DSNB758I -SD10 ALLOCATED SIZE = 16384
KB
VOLATILITY STATUS = VOLATILE
REBUILD STATUS = NONE
CFNAME = CFSEG1
CFLEVEL - OPERATIONAL = 17
CFLEVEL - ACTUAL = 25
DSNB759I -SD10 NUMBER OF DIRECTORY ENTRIES = 15964
NUMBER OF DATA PAGES = 1595
NUMBER OF CONNECTIONS = 1
DSNB798I -SD10 LAST GROUP BUFFER POOL CHECKPOINT
09:14:08 MAY 22, 2024
GBP CHECKPOINT RECOVERY LRSN =
00DF215E8A4B743F0000
STRUCTURE OWNER = MEMSD10
DSNB790I -SD10 DISPLAY FOR GROUP BUFFER POOL GBP0 IS COMPLETE
DSN9022I -SD10 DSNB1CMD '-DIS GROUPBUFFERPOOL' NORMAL COMPLETION
One interesting bit of info here is the DSNB758I message. Notice the CFLEVEL fields? The OPERATIONAL appears to be “stuck” at 17 as we are on a z16 using ACTUAL 25 and getting the new, in CFLEVEL 25, statistics so OPERATIONAL *should* be 25 as well!
What About the ALIAS?
The final piece is the strange case of the DDF ALIAS definition. If you simply create a DDF ALIAS it is, by definition, disabled until you complete the process. While it is in this state the DSNJU004 output just lists:
Elvis is Dead?
But in the BSDS you actually see:
And then on the same line to the right:
These were two test ALIASes I created for our SAX DBAT support.
Human-Readable Version Again
The SAX DBAT support records all the data from your DDF with the aim to show/warn you if you start running out of DBATs. It shows you all your DDF data like this:
Zooming In!
Primary cmd A for Alias:
So here you see that there are indeed two ALIASes but both are in STOPD status.
I presume that until “enabled” they are “not interesting” for DDF use … In fact, even with STATUS STARTD, I cannot find the data in the utility output…
That’s All, Folks!
These are the little nuggets I have found in the BSDS that I think are pretty interesting really, but for whatever reason IBM do not externalize them. I would hazard a guess, that this data may change at any given time and it is therefore not documented anywhere for “safety” reasons!
Aha!
Do you think it warrants an Aha idea to update the DSNJU004 to actually output the BPs, GBPs and ALIASes?
As usual I would love to hear what you think!
TTFN
Roy Boxwell