1. The CPITCBTM and CPISRBTM are not only the result of DDCONS:
The "Initiator" TCB/SRB CPU time is not only due to DDCONS,
but is all of the CPU time that occurs between Initiation
and Program Load time, which includes DSENQ time,
the cost of execution of your SMS Allocation Rules,
HSM Recalls, VAM product, and SMS Trace CPU time,
PLUS
the CPU time after the Loaded Program has terminated,
which includes the DDCONS CPU TIME and Catalog CPU
time.
And, there may be other contributors to those CPU times.
2. But the original issue of size of 30s can also be impacted
by your choice of INTERVAL and DETAIL options in SMFPRMxx:
10. No EXCP data for type 30 subtypes 4 and 5 from STCs.
SMF Type 30 subtypes 4 and 5 for STCs (Started Tasks) do not contain an
EXCP segment when INTERVAL and NODETAIL is specified in SMFPRMnn member
of SYS1.PARMLIB, even though the EXCP segment does exist in subtypes 2
and 3 (the interval records). This is documented under the DETAIL
parameter in Initialization and Tuning (but not mentioned in SMF
Manual). What is not documented is that NOINTERVAL and NODETAIL options
DO create EXCP segment for STCs in subtypes 4 and 5! Thus a site which
had not specified INTERVAL and had NODETAIL by default was recording
EXCP counts in STC step and step termination records, but when the site
decided to record INTERVAL data, the STC EXCP counts all became zero!
The moral: ALWAYS specify DETAIL for STCs so that EXCP counts are in
the subtype 4 and 5 records, no matter what the INTERVAL/NOINTERVAL
parameter specifies. Originally printed in MXG NEWSLETTER SIXTEEN.
26Apr02 revision to the preceding "ALWAYS specify DETAIL":
- IBM Information APAR II07124 discusses why you might need to
specify NODETAIL for your STC's: When DETAIL is specified, the DD
and EXCP information will be stored in 32K memory blocks in SP230,
and those blocks (in virtual storage) are kept for the entire life
of the address space. For an STC like DBM1, which can have 10,000
DDs, its SP230 can grow and run out of private area storage, both
high and low, requiring a restart of the DB2 system to clear the
Sub Pool. Instead, with NODETAIL, the DD information is only kept
for each interval record, i.e., in PDB.SMFINTRV, so the data is
available in SMF, and DBM1's SubPool 230 does not grow over time,
so you don't have to stop and restart your DB2 subsystem.
- That APAR also recommends DDCONS=NO, a parameter that was created
by IBM as a result of an MXG user's discovery of the problem it
corrects, so MXG has always recommended DDCONS=NO be specified.
- Specifying NODETAIL for STCs has no direct impact on MXG logic.
Your STC observations in PDB.JOBS/PDB.STEPS will have zero for the
EXCP/IOTM variables, which might affect your chargeback for STCs,
but STCs are usually an internal charge; furthermore, only those
STCs that are terminated normally (created subtype 4/5) could have
been billed for STC EXCP counts. But the EXCP/IOTM variables for
STCs will exist the PDB.SMFINTRV dataset for each interval, even
with NODETAIL, as long as INTERVAL is enabled to write subtype 2/3
records, (and MXG member IMACINTV was enabled to populate TYPE30_V
and PDB.SMFINTRV datasets). And with a large value for SPINCNT in
your MXG member IMACSPIN, dataset PDB.SMFINTRV will contain the
ACCOUNTn and SACCTn accounting fields for the STC, so those EXCP
counts for your STCs can still be charged back with PDB.SMFINTRV.
12May03 addition:
- To keep DB2 "up forever", you do NOT have to turn off SMF interval
recording, which is a mis-reading of that APAR. As long as both
NODETAIL and DDCONS=NO are specified, the NODETAIL eliminates the
SP230 growth issue, and DDCONS=NO eliminates the CPU spike, so you
can continue to write SMF type 30 interval records for your DB2
that is designed to "never end".
Barry Merrill
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
