The CICS SMF records can be mapped via SDFHMAC(DFHMN*) macros. But be aware that, by default, since CICS TS 3.2, CICS SMF records are written in a compressed format. The only part of a compressed 110 record that is not compressed is the SMF record header (DFHMNSMF), which contains the usual fields for system-id and job-name. You can sift 110 records by z/OS system or CICS region (job-name) by reading the uncompressed 110 header, but no more than that without de-compressing the records (using z/OS Data Compression and Expansion Services (CSRCESRV) ), or to process the performance data.
You'd be better off using a utility that has the ability to de-compress and read CICS SMF records instead of re-inventing the wheel. See CICS Operations and Utilities and CICS Performance Guide, or the documentation of any brand X monitoring / reporting software (e.g. MXG). Ant. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Barry Sent: Thursday, 15 May 2014 12:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IFASMFR On Wed, 14 May 2014 10:09:08 -0400, Dno <snipers5...@gmail.com> wrote: >Hi, >Does anyone know why you cannot map 100, 101, 102 or 110 records with this >macro? I'd like to be able to collect a subset of the DB2 and CICS records, >possibly by subsystem or region, or even down to a thread or transaction >because of volume. We are not using log streams yet. >Thanks >Dean Some of the challenge with these data sources are variability and complexity (to start), as follows: 1) CICS CMF 110/1 has 'tailorable' transaction data (MCT-directed by site/region/version) that is mapped by corresponding DICTIONARY data. 2) DB2 101 (with certain ACCOUNTING TRACE type activation) has the potential to generate a continuation-like record if more than 10 packages occur - that must be mapped back to the primary record since not all fields are present in both. 3) DB2 102 data (at the IFCID level) is comprehensive and larger number of metrics than a bread-basket. 4) Additionally, such as MQ 116/1-2, similar condition to #2 above with continuation-like record generation, based on unique-queue activity. In summary, these are just too comprehensive data sources for simple-mapping, likely without post-processing once the data-records are decoded to map all 'related records' to one transaction instance/event. Scott Barry SBBWorks, Inc. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
