Batch Report Writer Parameters
Batch Report Writer obtains input parameters from a file that the SYSPARMS DD statement describes in the batch job stream. IDRWPRMS member to customize is in SOURCE library.
During initialization, the Batch Report Writer obtains the input parameters from a file that the SYSPARMS DD statement describes in the batch job stream. A sample member to customize, IDRWPRMS, is in the
CA SYSVIEW for DB2SOURCE library.
The underlined value (if any) for each keyword is the default value. The default value is used
onlyif no value is specified in the input parameter file.
Parameters are grouped by function. If these parameters are similar to the data collector system parameters, the values you specify should match. Some parameters do not apply to your site, depending on the Db2 version.
Some italicized values (such as
hlq) are initially populated during the
CA SYSVIEW for DB2basic installation using the IDEDIT macro. The DBSUB parameter is set to DB23 for installation verification purposes. Set this parameter to the correct subsystem ID after the verification process.
Unless the first record consists of a comment, DEFAULTS
mustbe the first word on the first input record in the parameter file.
The following list describes the identification parameters:
- DBSUB=db2name|SSIDSpecifies the one- to four-character name of the Db2 subsystem to be reported on. This parameter is optional. If it is omitted, all Db2 records in the file are reported on.Specify the SSID to process data from multiple Db2 subsystems in the same run of the Batch Report Writer. If you specify an SSID, the Batch Report Writer takes the following actions:
mustbe presorted by subsystem, date, and time.
- Looks for multiple subsystems
- Implements a page break
- Updates the subsystem ID in the report header when a new subsystem ID is encountered
- GMT-ADJUSTMENT=nnSpecifies theStandard Timeoffset from the Greenwich Mean Time (GMT) for your location. The value is the signed correction in hours. If your installation is east of Greenwich, enter a positive value. If your installation is west of Greenwich, enter a negative value. This parameter enables you to override the system Time Zone shift. Primarily useful if you are running the job at a location that is different from where the data is collected.Parameters GMT-ADJUSTMENT and DST-LOCATION are used for automatic conversion of the store-clock values that are contained within trace records from GMT to local time. Set GMT-ADJUSTMENT once to the Standard Time offset from GMT for your location anddo notchange it during the Daylight Saving Time period.
- DST-LOCATION=locationSpecifies your location to identify the rules when the Daylight Saving Time (DST) starts and ends:
Default:NOThe following example shows the SYSPARMS settings for different locations:For USA, Washington (Eastern Standard Time (GMT-5)):GMT-ADJUSTMENT=-5DST-LOCATION=USAFor Europe, Czech Republic, Prague (Central European Standard Time (GMT+1)):GMT-ADJUSTMENT=1DST-LOCATION=EUROPEFor Brazil, Brasilia (Brazil Standard Time (GMT-3)):GMT-ADJUSTMENT=-3DST-LOCATION=BRAZILFor Israel, Jerusalem (Israel Standard Time (GMT+2))GMT-ADJUSTMENT=2DST-LOCATION=ISRAEL
- NO—DST time is not applicable for your location
- USA—Uses DST rules for USA
- CANADA—Uses DST rules for Canada
- EUROPE—Uses DST rules for Europe
- BRAZIL—Uses DST rules for Brazil
- ISRAEL—Uses DST rules for Israel
- REQLIB='hlq.mlq.REQUESTS'Specifies the names of the request libraries from which to read the requests and report segments being referenced with an INCLUDE clause. This parameter is required for any batch report that contains an INCLUDE clause. These libraries are dynamically allocated during the report writer initialization, and then freed.This parameter can also use the following syntax:REQLIB= ('hlq.mlq.REQUESTS', '2nd request library', '...','...')
- WAIT239=(max wait seconds, max records waiting)Controls howCA SYSVIEW for DB2waits for matching records:
CA SYSVIEW for DB2chaining records that wait for matching records. Specifying lower values reduces the overhead, but can increase the likelihood of processing records with data.When matching records are produced at similar time, there is little overhead, regardless of the values that are specified in this parameter. However, if your input records indicate that matching data is present but unavailable, the wait overhead can be significant. In this case, lowering the values for this parameter can greatly reduce the overhead of processing the data.Themax wait secondsandmax records waitingvalues are required. These values specify a maximum wait time in seconds and a maximum number of records that are queued up to wait for matching records. If the maximum wait time is reached for a record, the record is processed without complimentary sections. If the maximum record count is reached, the oldest records on the chain are removed. These records are processed without matching sections until the count drops below the maximum record count. If either value is exceeded, waiting records are removed from the wait chain and processed without all the complimentary data.Default:WAIT239=(300,1000)Limits:1 - 2147483647 (for both fields)Default in sample SYSPARMS member:(300,100)
- (003) ACCT records wait for package (IFCID 239) data
- (001) STATS1 records wait for (002) STATS2 records
- (002) STATS2 base segments wait for (002) STATS2 continuation segments
- ZIIP-USE=[YES|NO|SRB]Specifies whether the batch report writer uses zIIP processing. Messages are written to the DBGPRINT during the termination to indicate the zIIP and CP usage. The following values are valid:
Default:YESTypically, over 90 percent of the processing is eligible to be run on the zIIP processors for the most of batch report writer processing. The following factors into the zIIP utilization:
- YES—Uses zIIP processingIf the zIIP processors are not available, an informational message is issued and processing continues with the execution on central processors.
- SRB—Uses SRB mode, but does not use zIIPZIIP-USE=SRB is only used as a migration aid in non-zIIP environments to determine how much CPU can be offloaded to any available zIIP processors. The output of the DCCPU command estimates the zIIP savings that you can achieve once you have migrated to a processor with zIIP engines.
- NO—Does not use zIIP or SRB
Inefficient block sizes on the input and output files can significantly increase elapsed time and CPU costs when ZIIP-USE parameter is set to YES or SRB. To minimize the overhead increase, ensure that the BLKSIZE on the DB2DDN input file and the report output files is at the largest optimum size. If you do not specify the blocksize for the new output files including the SYSOUT output, the batch report writer specifies the optimum size for you.
- The availability and current utilization of zIIP processors.
- The amount of I/O activity. In general, less input (DB2DDN) and output (report output) I/O results in higher percentage of zIIP utilization.
- Input I/O—The number of non-Db2 trace records to be processed increases I/O performed and reduces zIIP utilization
- Input I/O—The number of Db2 trace records not relevant to the report increases the ratio of I/O performed to CPU used
- Output I/O—Trace reports (especially long accounting and statistics reports) produce more output and increases I/O performed to CPU used
- Block size of input/output files—Higher block size results in less I/O and higher percentage of zIIP utilization
- The SAVEIFI file input does not have the same input I/O concerns as the I/O that is processed as a subtask.
- MBCCSID=ccsidWhen Db2 is defined with the zPARM MIXED=YES and unicode IFCIDs are not being used, specify this parameter to translate SQL text encoded in a mixed byte EBCDIC code page to Standard U.S. EBCDIC. The coded value isnotchecked for validity.Example:MBCCSID=1390
Data Set Allocation Parameters
The following data set allocation parameters control the dynamic allocation of data sets by specifying defaults for data set characteristics that are not specified in the request.
- STATUSIdentifies the default data set status that is dynamically allocated for a request when the not specified in the request.Values:NEW, MOD, OLD, SHR
- DISPSpecifies the default disposition that is taken for a dynamically allocated data set when not indicated in the request.Values:UNCATLG, CATLG, KEEP, DELETE
- SPACETYPESpecifies the default space type that is allocated for a new, dynamically allocated data set when not indicated in the request.Values:CYL or CYLINDER, TRACK or TRK,xxxxxxxxmeans that space is to be allocated in blocks whose average length is specified by the value.
- PRIMARYSpecifies the numeric one to four-character default primary quantity of space that is based on the type that SPACETYPE indicates. This space is allocated for a new data set when the quantity is not specified in the request.Default:25 tracks
- SECONDARYSpecifies the numeric one- to four-character default secondary quantity of space that is based on the type that SPACETYPE indicates. This space is allocated for a new dynamically allocated data set when not specified in the request.Default:10 tracks
- DSORGSpecifies the default data set organization for a new dynamically allocated data set when the data set organization is not specified in the request.Values:PS, PO
- UNITSpecifies the default unit type for a new data set to be dynamically allocated when not specified in the request.When an entirely numeric value is specified, it must be enclosed in quotes, such as “3380”.Default:SYSDA
- SYSOUTSpecifies the default SYSOUT class for a SYSOUT data set to be dynamically allocated for a request when not specified in the request.Default:A
- PREFIXSpecifies the beginning prefixes for a dynamically allocated data set specified for use by a request. This prefix is appended to the front of the data set name except when the fully qualified name is given in the request.
- ENFORCE-PREFIXDetermines if PREFIX string is the highest level qualifier for all data sets created from requests:
- YESAny data set name that is used in a request is appended behind the prefix and truncated if too long.
- NORequests can use any fully qualified data set name.
Reporting Control Parameters
The reporting control parameters control what information appears in reports:
- CSV-OVERRIDE=[PRINT|OUTFILE|OFF]Changes behavior of the PRINT or OUTFILE IQL destination. When set to PRINT or OUTFILE, the batch report writer produces report to the PRINT or OUTFILE destination in CSV format instead of regular format unless a CSV destination is already specified.
- DB2VER=vv.rSpecifies the Db2 version of the input trace data.Examples:9.1, 10.1, 11.1, 12.1
- DDF=[YES|NO]Defines whether to include DDF (Distributed Data Facility) information in the reports.
- DATA-SHARING=[YES|NO]Defines whether to include data sharing information in the reports.
- PACKAGE=[YES|NO]Defines whether to include package information in the accounting short reports.
- UNLOAD-FROM-DATE=['YYYY/MM/DD'|TODAY|YESTERDAY]Specifies that you want to process only data beginning from the specified date. The parameter only applies to the //HISTSTAT or //HISTACCT input online history file.
- UNLOAD-FROM-TIME='HH:MM:SS'Specifies that you want to process only data beginning from the specified time. This parameter is used with UNLOAD-FROM-DATE. The parameter only applies to the //HISTSTAT or //HISTACCT input online history file.Defaults:UNLOAD-FROM beginning of file
- UNLOAD-TO-DATE=['YYYY/MM/DD'|TODAY|YESTERDAY]Specifies that you want to process only data up to the specified date. The parameter only applies to the //HISTSTAT or //HISTACCT input online history file.
- UNLOAD-TO-TIME='HH:MM:SS'Specifies that you want to process only data up to the specified time. This parameter is used with UNLOAD-TO-DATE. The parameter only applies to the //HISTSTAT or //HISTACCT input online history file.Defaults:UNLOAD-TO end of file
- IQL-DEFINE=(...)Allows you to define custom IQL variables that can be used in #IF statements. Custom IQL variables can be logical (YES/ON or NO/OFF) or numeric (a number with up to one decimal place). We recommend that youdo not usea reserved word as a custom variable name. When a custom IQL variable is set multiple times, the last definition of that variable is used. You cannot use this parameter to change predefined IQL variables, such as DDF, RLF, or DB2VER.┌──◄──────── , ───────────────────────────┐ ►►── IQL-DEFINE ─ = ─(──┴─ name = ─┬┬── YES ──┬─────────────────┬─┴─)─►◄ │└── ON ───┘ │ ├┬── NO ──┬──────────────────┤ │└── OFF ─┘ │ │ ┌──◄──────┐ │ └─┴─ digit ─┴┬─────────────┬─┘ └─ . ─ digit ─┘Custom IQL variables:
- IQL-DEFINE=(EXCP-LONG376=YES)Enables the tracking of individual statements by the statement ID in IQL exception EXCP0376. Value YES can result in significant CPU overhead and storage shortages.
- IQL-DEFINE=(MOI=YES)Enables sending Db2 metrics to Mainframe Operational Intelligence (MOI). Setting this value to YES is the first step of MOI integration.
- IQL-DEFINE=(MOIDEBUG=YES)Enables online debugging of IQLs for MOI.
- IQL-DEFINE=(MOIHWM=YES)Replaces active thread counts with the interval high-water mark values while sending MOI data. This setting is only recommended, ifCA SYSVIEW for DB2subsystem history interval is set to 1 minute.
- IQL-DEFINE=(IQL-EXCLUDE-ACCEL=YES)Specifies that the accelerator fields do not appear in the IDB2ACCT reports.
- IQL-DEFINE=(THREAD-HIST-INTERVAL=nn)Specifies the interval of Application Interval Summary report, in minutes. If THREAD-HIST-INTERVAL is not set, the report uses HISTORY-STATS-TIME value. The value must be 1 through 60 and must divide 60. Otherwise, value of 15 is used.
- IQL-DEFINE=(THREAD-HIST-GROUP-BY-AUTH=YES|NO)IQL-DEFINE=(THREAD-HIST-GROUP-BY-CONN=YES|NO)IQL-DEFINE=(THREAD-HIST-GROUP-BY-CORR=YES|NO)IQL-DEFINE=(THREAD-HIST-GROUP-BY-PLAN=YES|NO)Specifies the Application Interval Summary report grouping. You can only group byoneof the following values: Authorization ID, Connection Name, Correlation ID, Plan Name. If you set multiple values to YES, the report uses the value that was last set to YES. If no value is set to YES, THREAD-HIST-GROUP-BY-AUTH is set to YES during the data collector initialization.
The date and time parameters are used to override the equivalent date-time and interval masks that are coded in IQL requests.
Page headers, including the job run date and the FIRST RECORD and LAST RECORD date, have the date format according to the SYSPARM "DATE=".