* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
IOPIFLG (R79EGFLG) new bit 6 value. New Variables: R79ECBT ='CU BUSY*DELAY*TIME' R79ECMR ='CMR*TIME' R79ESBS ='SWITCH*BUSY*COUNT' R79ECPXF='CHANNEL*PATH*EXTENDED*FLAGS' R79ECBTM='CU BUSY*DELAY*TIME' R79ECMRM='CMR*TIME' R79ESBSM='SWITCH*BUSY*COUNT' R79ECSST='CHANNEL*SUBSYSTEM*WAIT*TIME'
EXTMQQC these new MXG datasets from the TMMQIN infile: EXTMQQE Dataset Description EXTMQQH TMMQQC CHANNEL STATISTICS EXTMQQMA TMMQQE EVENT EXTMQQMB TMMQQH DEAD LETTER QUEUE (DLQ) PROCESSOR ACTIVITY EXTMQQMD TMMQQMA QUEUE MANAGER - ASID DATA EXTMQQML TMMQQMB QUEUE MANAGER - BUFFER MANAGER EXTMQQMM TMMQQMD QUEUE MANAGER - DATA DATA EXTMQQS TMMQQML QUEUE MANAGER - LOG MANAGER EXTMQQT TMMQQMM QUEUE MANAGER - MESSAGE MANAGER EXTMQQU TMMQQS PAGE SET STATISTICS EXTMQQV TMMQQT THREAD INTERVAL EXTMQQX TMMQQU QUEUE STATISTICS INTERVAL IMACTMMQ TMMQQV DLQ PROCESSOR ACTIVITY SUMMARY TYPETMMQ TMMQQX EXCEPTION TYPSTMMQ VMACTMMQ
VMXGINIT Jul 23, 2003 Change 21.128 If you used UTILEXCL (for CICS Excluded Fields) to create IMACEXCL an IMACEXCL member, or if you tailored the MXG IMACEXCL UTILEXCL member, variables SC24CHWM and SC31CHWM were wrongly Jul 23, 2003 divided by 4 million (4E06 in floating point syntax), and variables SC23COCC and SC31COCC were wrongly not divided by 4E06. Using the un-modified VMAC110 produced correct values for all four variables. Thanks to Art Cuneo, BlueCross Blue Shield of Illinois, USA. Change 21.127 The INFILE SMF statement has FILENAME=INFILENM added, and VMACSMF LENGTH INFILENM $64; so that INFILENM will contain the Jul 21, 2003 MVS DSNAME or the ascii directory/filename of the input SMF file that is being read. INFILENM is NOT kept in any MXG datasets, but is available as each record is read, and could be used to track what DSNAMEs have been read. Although MVS DSN is only $44, I picked $64 because of the typical size of ascii directory and filenames. Thanks to Dr. Alexander Raeder, Karstat AG, GERMANY.
VMAC74 R745CUID (from "CO" segment) and R745DCID (from "DO") Jul 21, 2003 are documented by IBM as "Control Unit ID", but when only two unique values ('1B'x=2105s and '15'x=3390-6s) were found in RMF data, IBM was queried and confirmed that the fields actually contain a unique code for the cache controller type; IBM documentation will be revised. Variable R745DCID is now formatted HEX2. Thanks to Chuck Hopf, MBNA, USA.
VMXGRMFI or SYSPLEXes into a single workload in PDB.RMFINTRV. Jul 22, 2003 You use two WORKnn statements, with different nn values, but with the same first two arguments (workload name, label text), and then the SYSTEM or SYSPLEX arguments control which SRVCLASS observations from TYPE72/TYPE72GO are included in this workload name. For example WORK01=TSOP/TSO Prod//TSOPROD/2//PLEXA, WORK02=TSO/TSO//TSO/2//PLEXA, WORK03=TSO/TSO//TSOPROD/2/PLEXB, would create two workloads, TSO containing SRVCLASS TSOPROD from PLEXA, and TSOP containing SRVCLASS TSO from PLEXA and SRVCLASS TSOPROD from PLEXB. Because PERIODS=2 is specified, the "PERIODS" response variables for two periods will be created for each of these workloads, comprising these variables: TSOP1RSP TSOP1SWP TSOP1TRN TSOP2RSP TSOP2SWP TSOP2TRN TSO1RSP TSO1SWP TSO1TRN TSO2RSP TSO2SWP TSO2TRN In addition, because the workload name starts with TSO, the "TSO" response variables for the entire system: TRIVRESP TSO2RESP TSO3RESP TSO4RESP TRIVTRAN TSO2TRAN TSO3TRAN TSO4TRAN TRIVSWAP TSO2SWAP TSO3SWAP TSO4SWAP (Note: Previously, only the workload 'TSO' exactly was in these "TSO" response variables, but now, all workloads with XXXX starting with "TSO" are included in the "TSO" response variables, and you can use the "PERIODS" response variable for the individual TSO workloads if more than one. The comments documenting the VMXGRMFI arguments was also revised by this change. Note: To use these enhancements, you MUST execute MXG with SAS Version 8.2 or later. Thanks to Shirley Fung, HSBC, HONG KONG. Change 21.124 Support for EntireX user SMF accounting EXXACTR record EXENTIRX creates ENTIREX dataset. FORMATS IMACENTX
TYPEENTX TYPSENTX
VMACENTX VMXGINIT
Jul 18, 2003 Thanks to John Cousins, Bristol City Council, ENGLAND. Change 21.123 Non-duplicate TYPE6156 records were deleted by the NODUP VMAC6156 in MXG's PROC SORT, because all of the kept variables in Jul 17, 2003 TYPE6156 were identical. However, the two records were different, only in the catalog segment E3 (TRUENAME), and one record was for Data, the other for Index, so variable TRUETYPE and TRUEDSN are now decoded from the 'E3'x data, and are kept in TYPE6156, and are added to the _BTY6156 by list, so the non-duplicate records are not duplicates any more. Thanks to Art Cuneo, BlueCross Blue Shield of Illinois, USA. Change 21.122 The +58 in Volume Record from MVSRECLV=01 RMM records VMACEDGS was changed to +122 by Change 19.284, but now records Jul 16, 2003 have been found with MVSRECLV=01 that still have only +58 bytes to skip between MVDCRSID and MVDSN1L, and I can find no flag that indicates how many bytes need to be skipped. Using +122 with +58 record causes STOPOVER, while using +58 with +122 causes no error (and only the variables listed in Change 19.284 to be in error), so I have changed the default back to +58, and have created a new "old-style" MACRO _LNEDGS +58 % in VMACEDGS that can be changed externally, if you have +122 records, by inserting this statement as your first //SYSIN DD *: %LET MACEDGS= MACRO _LNEDGS +122 % ; Thanks to Jim Bentley, AHOLD Information Services, USA. Change 21.121 DB2 Trace IFCID=21 variable QW0021GS, input as $CHAR4., VMAC102 should have been variable QW0021GF, input as $CHAR1., and Jul 14, 2003 variable QW0021CS should have been input as $CHAR1. Both QW0021CS and QW0021GF are now formatted $HEX2. and variable QW0021GS is no longer kept in T102S021 dataset. -IFCIDs 251 and 257 internal QW0251xx and QW0257xx are now input, formatted, and kept. Thanks to Richard Link, BlueCross BlueShield of Illinois, USA. Change 21.120 Condition Code variable NDMSCC is a character variable VMACNDM with $HEX8. format, so it prints '00000000' for a zero Jul 14, 2003 and '00000008' for an 8, but that is messy for testing, so new variable NDMSCCNR, a numeric variable, is added to the NDM datasets that actually contain condition code: AE CH CT DP DT FP GF MC RJ RT PS PT SI WO and is created with NDMSCCNR=INPUT(NDMSCC, &PIB.4.); Variable NDMSCC was incorrectly kept in these datasets: CE CI FI GO IF NL PI SB TI TP that do not contain it, so it was removed from them. Thanks to George Canning, Abbey National, ENGLAND.
TYPETHST and the second one commented out. TYPSTHST Jul 11, 2003 Change 21.118 Support for AS/400 TCP and TCPIEF objects create two new EXQAPTCP datasets: EXQAPIFC dddddd dataset contents IMACQACS QAPTCP QAPMTCP TCP Statistics VMACQACS QAPIFC QAPMIFC TCP-IFC Statistics VMXGINIT
Jul 11, 2003 Jul 23, 2003 Thanks to Roger Zimmerman, Hewitt, USA.
VMACMVCI required changes to the T6ECPRID NE 'F4'x tests to GE as Jul 10, 2003 the new version has T6ECPRID='F5'x. There are a few new Jul 16, 2003 variables that were added to the datafile, including the Jul 17, 2003 GMT Time Zone offset, MVCVTTZ. So with this change: Variables STARTIME,ENDTIME,T6ETKSTR and T6ETKSTO are now converted to Local Time Zone; previously, they were in the GMT time zone. Fortunatly, if you were using datetime variables CMRLBEGN or CMRLENDT in reports, the have always been on the local time zone. -A number of duration variables were not formatted with TIME12.2; all now are. -Variable T6EUCPUT was incorrectly read as PIB8; it is a pair of time and count PIB4 fields, T6EUCPUT & T6EUCPUC. Variable T6EUCPUT is now identical to existing T6ECPUR, and T6EUCPUC counts CPU dispatches. -File data is now correct; the file offset is now used to locate the file data. Thanks to Udo Froehling, Signal-Iduna, GERMANY. Thanks to Reinhold Lehmann, Signal-Iduna, GERMANY. Change 21.116 Major revisions to AIX PTX support. The original TYPEAIX EXAIXCPN member read the "SpreadSheet" format and created only the EXAIXDSK AIXPTX interval dataset, with cryptic variable names and EXAIXFS "room" for only 3 disk drives, etc., because that design EXAIXFSV requires a new variable name for repeated values. The new EXAIXINT code will continue to create AIXPTX from SpreadSheet EXAIXIPN format (recognizable by the text "TIMESTAMP" in 2nd EXAIXLAN record), but that format is no longer recommended and EXAIXMEK AIXPTX will be static (i.e., will be missing data). EXAIXMER
EXAIXMEV This re-design reads the "comma" PTX output format (has EXAIXPRO text "TIME=" in 2nd and following records), and creates EXAIXPSP multiple datasets, properly supporting an unlimited EXAIXPSP number of disks, lans, paging spaces, processes, etc., IMACAIX for objects with multiple instances per interval. New VMACAIX AIXMEMR, AIXMEMV, and AIXMEMK provide data for the MEM VMXGINIT Real, Virt, and Kmem records; other segments that are Jul 9, 2003 written once per interval (CPU, PAGSP, PROC, SYSCALL and SYSIO, at present) are output in AIXINTRV dataset.
DATASET DATASET DATASET SUFFIX NAME LABEL
AIXFS AIXFS AIX FS DATA AIXFSV AIXFSV AIX FS VOLUME GROUP DATA AIXLAN AIXLAN AIX LAN DATA AIXCPN AIXCPUNR AIX CPU/CPUNUMBR DATA AIXIPN AIXIPNET AIX IP/NETIF DATA AIXMER AIXMEMR AIX MEM/REAL DATA AIXMEV AIXMEMV AIX MEM/REAL DATA AIXMEK AIXMEMK AIX MEM/KMEM DATA AIXPSP AIXPAGSP AIX PAGESP/PAGESPAC DATA AIXPRO AIXPROCS AIX PROC/PROCESS DATA AIXPSP AIXPAGSP AIX PAGESP/PAGESPAC DATA AIXINT AIXINTRV AIX INTERVAL DATA (CPU/PAGSP/PROC/SYSCALL/SYSIO) AIXPTX AIXPTX ARCHAIC "SPREADSHEET ONLY" INTERVAL Some data appears to be completely destroyed when names (process, file system, cpu number) are to long to fit in the output file's LRECL; other data is ambiguous when the three variables CPUACC, CPUMS, and CPUPCT are all trunc'd to two positions of 'CP' in the PROC/CPUNUMBR records! There are additional data (ICP/AREA, IP/ROUTING, IP/=, TCP/=, UDP/=, RPC/CLSERV, NFS/SERV, and RTIME) that will be supported (and create more datasets) when test data is received to validate those data. "INVALID OBJECT" messages with numbers for the object are created in the PTX output file for Java processes that have extremely long names; PTX cuts off the process name at a specific maximum assumed length, and important info is lost in the name pattern. One solution is to have the application developer use shorter process names, but the issue is still being investigated in Nov, 2003. Thanks to Sam F. White, CocaCola, USA. Thanks to C. Tim Browning, Coca-Cola Enterprises, USA.
VMAC103 errors in data, adds new variables, and adds options to Jul 7, 2003 "separate" and "sync" SMF 103 records. See extensive notes in the APAR text. Variables added to TYPE1032: APLENVNM='APPLICATION*ENVIRONMENT*NAME' CGIREQST='CGI*REQUESTS' DNSLOKUP='DNS*LOOKUP*DIRECTIVE' PROXYRES='PROXY*RESPONSES' REQCOUNT='REQUEST*COUNTER' SRVICPLG='SERVICE*PLUGINS' SSLHANDS='SSL*HANDSHAKES' SUBSYS ='SUBSYSTEM*NAME' The first and last variables are also added to TYPE1031.
JCLTEST6 MXG2102 that should have been a single single-quote. JCLTEST8 Jul 7, 2003 Thanks to Jim Horne, Lowe's Companies, USA.
UTILRMFI VMXGRMFI parsing of its arguments, and arbitrary limit VMXGRMFI that is now increased to 999 names in each argument list. Jun 27, 2003 -KEEPALL=NO is now specified for the TYPE70 logic, so that the new more-than-16-CPUs-in-TYPE70 logic in VMXGRMFI won't fail if you read an old PDB with VMXGRMFI. Thanks to Jay Brookover, First Citizens, USA.
BUILD005 PDB.SMFINTRV, but it was not kept in PDB.STEPS, and was BUIL3005 not summed into PDB.JOBS, until this change did so. Jun 27, 2003 Thanks to Brenda Rabinowitz, The Prudential Insurance Co., USA.
VMAC28 by GBLSAMPL, to get their average values in NPM dataset Jun 26, 2003 NPMVSVGB (VTAM Global Resourcesd). Thanks to Andre D. Walker, Bank of America, USA. Change 21.110 RMF type 78 subtype 2 "Job-Level Virtual Storage Monitor" VMAC78 sections for "Early Address Spaces" may have invalid data Jun 25, 2003 ('070E000000000000'x) for R782RDTM/R782RDDT, causing the INVALID DATA FOR READTIME messages and dumps on the log. This change adds the "??" modifier to the READTIME INPUT to suppress the message and hex dumps, so READTIME will still be missing, so you could identify which JOBs had invalid values in TYPE78PA. You can identify your Early Address Spaces by looking JOB in TYPE30_6 dataset, as it only contains the obs for your Early ASID jobs. If you find JOBs that are not Early ASIDs, then you probably have CA's CA-7 Job Scheduling Product (which modifies the read date/time of jobs under it's control) and you need to contact CA Technical Support to correct their error. Thanks to Josep Miquel, La Caixa, ESPAGNE.
VMACNTSM was from an NT 4.0 system with Service Pack 6, and NTSMF Jun 25, 2003 was at PRFSENVR=2.4.4 and VERSION=2.2.2. The discovery records show that six fields (five %total xxxxx time and total interrupts) are repeated (just like NRDATA=32 case) so there was no new data, just another exception now covered! Thanks to Xiaobo Zhang, ISO, USA. Change 21.108 -In VMXG70PR, new variables LPnNSW for each LPAR, labeled VMAC7072 LP1NSW ='LPAR 1*PERCENT WHEN*LPAR WAS*SOFT CAPPED' VMXG70PR are created in PDB.ASUM70PR and PDB.ASUMCEC datasets, Jun 26, 2003 from SMF70NSW. -Labels for some capping-related variables were revised: In TYPE70PR dataset: SMF70NSW='PCT WHEN*LPAR WAS SOFT CAPPED*BY WLM' In TYPE72GO dataset: PCTDLCCA='RESOURCE*GROUP*CAPPING*DELAY*PERCENT' PCTDLCDE='CPU*DELAY*PERCENT*INCLUDES*WLM CAP' -Labels for variables PCTLGBY and PCTLGOV were corrected to LPAR 16 and blank variables PCTLNBY and PCTLNOV are now labeled for LPAR 23. Thanks to Harry Price, Florida Power and Light, USA. Thanks to Freddie Arie, TXU, USA.
VMAC120 SMF 120 Version 5.0 records; that APAR pointed to new SMF Jun 24, 2003 record documentation, and I found many new fields were added by Version 5; all are now input and kept. Datasets: TYP120SA,TYP120SI,TYP120JC,TYP120JI,TYP120WI: SM120CEL='WEBSPHERE*CELL*NAME' SM120NOD='WEBSPHERE*NODE*NAME' Datasets TYP120JC and TYP120JI: SM120JME='EJBLOAD*INVOCATIONS' SM120JMF='EJBLOAD*AVG*EXECUTION*TIME' SM120JMG='EJBLOAD*MAX*EXECUTION*TIME' SM120JMH='EJBSTORE*INVOCATIONS' SM120JMI='EJBSTORE*AVG*EXECUTION*TIME' SM120JMJ='EJBSTORE*MAX*EXECUTION*TIME' SM120JMK='EJBACTIVATE*INVOCATIONS' SM120JML='EJBACTIVATE*AVG*EXECUTION*TIME' SM120JMM='EJBACTIVATE*MAX*EXECUTION*TIME' SM120JMN='EJBPASSIVATE*INVOCATIONS' SM120JMO='EJBPASSIVATE*AVG*EXECUTION*TIME' SM120JMP='EJBPASSIVATE*MAX*EXECUTION*TIME' SM120JMQ='AVG*CPU*TIME' SM120JMR='MIN*CPU*TIME' SM120JMS='MAX*CPU*TIME' Dataset TYP120SA: SM120WCP='TOTAL*WLM ENCLAVE*CPU TIME' Dataset TYP120SI: SM120TEC='TOTAL*WLM ENCLAVE*CPU TIME' SM120NHS='HTTP*SESSIONS*EXIST*AT END' SM120NHA='HTTP*SESSIONS*ATTACHED*AND ACTIVE' SM120BTH='BYTES*TO SERVER*FROM ALL*CLIENTS' SM120BFH='BYTES*FROM SERVER*TO ALL*CLIENTS'
VMACWWW raw log values of: [22/Jun/2003:23:32:54 +0400] are Jun 24, 2003 the local time followed by the delta to add to convert to GMT, but I thought the datetime was GMT and the +0400 was the GMT offset, and so ENDTIME ended up back on GMT. The GMT conversion code was removed so ENDTIME is on the Local time zone; new variable GMTOFFTM is created in case you need to convert back to GMT or to know the zone. The above example from Eastern Daylight Savings offset of +0400 will have GMTOFFTM= -4 hours, consistent with all GMT offset values, normally used in conversion: LOCAL = GMT + GMTOFFTM; So to convert WebLob ENDTIME back to GMT, you'd use: ENDTIME = ENDTIME - GMTOFFTM; Thanks to Jim Agrippe, Cleveland Clinic Foundation, USA.
ASUMCICS if the input CICSTRAN was on tape. ASUMCICS has always ASUMCICT caused two mounts (one open to test if CICSTRAN has data, ASUMCICX reading one record, then one open to read the data), but Jun 25, 2003 MXG 21.02 caused the full dataset to be read twice. All of that complexity and exposure was so that ASUMCICS would figure out if you had IBM or Landmark CICS data to be used to create your PDB.CICS summary dataset. But I do not recommend that you use ASUMCICS; with MRO, CICS creates multiple observations in CICSTRAN/MONITASK for one "unit of work", so that a PDB.CICS built from CICSTRAN/MONITASK won't count user transactions, and all CPU time will be under the TRANNAME=CSMI,etc.
(if you have CICSTRAN data), or the ASUMUOWT (if you have the MONITASK data), to first create PDB.ASUMUOW dataset (one obs per "unit of work", correct TRANNAME, etc) and use that for your CICS response measurement. Then include the ASUMCICX member, which used PDB.ASUMUOW as the input to create the PDB.CICS summary dataset.
made an INCOMPATIBLE change, but only if you were using ASUMCICS to summarize Landmark's MONITASK data: Instead of using ASUMCICS to read MONITASK data, you must use new ASUMCICT to create PDB.CICS from MONITASK. If you were (wisely) using ASUMUOWT and ASUMCICX to create your PDB.CICS from Landmark MONITASK, there is no change required to your daily job. To summarize what these members do after this change: ASUMCICS - Reads only CICSTRAN, creates PDB.CICS. ASUMCICT - Reads only MONITASK, creates PDB.CICS. ASUMUOW - Combines CICSTRAN,DB2ACCT, creates PDB.ASUMUOW ASUMUOWT - Combines MONITASK,DB2ACCT, creates PDB.ASUMUOW ASUMCICX - Reads only ASUMUOW, creates PDB.CICS. Verically: use ASUMCICS or ASUMCICT (left pair) if you need the "old" PDB.CICS ("CSMI" tranname, segment counts) but most sites should use one of the right pair, using ASUMUOW/ASUMCICX for IBM, or ASUMUOWT/ASUMCICX for ASG, to first create PDB.ASUMUOW (correct TRANNAME, counts a unit-of-work as a transaction), and then create PDB.CICS from that PDB.ASUMUOW data.
dataset: CICSTRAN MONITASK CICSTRAN DB2 MONITASK DB2 program: ASUMCICS ASUMCICT ASUMUOW ASUMUOWT dataset: PDB.CICS PDB.CICS PDB.ASUMUOW PDB.ASUMUOW program: ASUMCICX ASUMCICX dataset: PDB.CICS PDB.CICS ===wrong TRANNAME=== ====correct TRANNAME===== ==obs per CICS segment= ====obs per CICS UOW==== ==not the recommended = ====the recommended=====
Thanks to Jim Horne, Lowes, USA. Change 21.104 OAM SMF type 85 records R85PVRM '130' caused STOPOVER and VMAC85 INPUT STATEMENT EXCEEDED error condition in subtype 74 Jun 23, 2003 records. Four tests for R85PVRM GE '150' were changed to R85PVRM GE '130' as these new records contain those fields thought to have been added by their 1.5.0 level. Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS. Change 21.103 The copying of WEEK4-WEEK5, WEEK3-WEEK4, WEEK2-WEEK1 and BLDNTPDB WEEK-WEEK2 was relocated to be just prior to building of Jun 12, 2003 the new WEEK pdb on the first day of the week; it will also note on the log what is being done for you. Thanks to Terry Heim, ECOLAB, USA.
VMACICE already supported by MXG; the fix corrects a problem with Jun 9, 2003 records being created that were greater than 32756 bytes; the fix creates multiple records when necessary, and has two new count fields added, but those fields are not needed for MXG to handle the multiple records, so there is no change to MXG needed for those fixes. Records with the fixes have been read and validated. However, SNAPDUR was corrected; it has always been wrong by a factor of ten, because the documentation had it in "hundredths" when it is actually in milliseconds. Thanks to Mikal W. Green, STK, USA. ====== Changes thru 21.101 were in MXG 21.02 dated Jun 9, 2003========= Change 21.101 CICSTRAN variable CPURLSTM was not multiplied by 16 when VMAC110 created by VMAC110 for CICS/TS 1.1 or later, but if you Jun 9, 2003 used UTILEXCL, it correctly multiplied by 16 for all CICS versions. VMAC110 was revised to correctly calculate the CPURLSTM for all versions. CPURLSTM is valid CPU time and is included in variable CPUTM; fortunately, CPURLSTM is usually small. Thanks to Vernon Kelly, IBM Global Services, USA. Yüklə 28,67 Mb. Dostları ilə paylaş:
|